Suboptimal experience

Suboptimal experience

[Dan Partelly]

Hello,


First thanks for the development effort you guys do. Now the issues:

1. I managed to install 0.14 to a Virtual box VM. I used bare-bones configuration.
2. I tried to get familiar with guix / guixSD a bit, I never used it before 
3. Within minutes I managed to break the system completely , due to my misguided idea to execute a guix pull to upgrade the packages to the latest available. This command is a liability, while it should 100% safe given how  central is to the OS.
4. This resulted into an unusable system , the command “system” for guix did not functioned at all after whatever git pull did .  Guix reported: 
5. attempting to fix the issue by pulling from git branch 0.14 where not successful.


Now some  points:

1. Why does exist a tight coupling between guix proper and package definitions  ? It is OK to recompile the package manager to get new functionality, not OK to recompile the package manager proper to get definitions for latest software.
    It exposes the user to all kind of issues, from mundane to unmangeable / unusable systems .
2. Why failing to rebuild guix results into an unmanageable system ? If the OS prides itself with atomicity and safety, then IMO any warning in the build process of this core tool (for any final build artifact ). If the build process results in N 
   artifacts, then care should be taken that those are atomically inserted in the new system so no broken state can exist
3. compilation time of guix at guix pull time is horrendous. I dont know the system good enough, so I can be mistaken, but probably the bulk of is  is because of package definitions . If this is true, then you have an  issue. You are at about 7k packages,
   it will increase linear with n ,  you'll grow old near a computer running this package manager by the time you'll reach 30k + .
4. again, if 3 is true, this can be mitigate by releasing a guix package which is updated automatically in binary form, but it’s a hack IMO. Cutting the dependency of package manager from package descriptions is the only sane way to solve this issue IMO
5. How secure is guix SD ? I see that you use a kernel with no provisions of loading microcode into CPUs. Given the recent rainbow of speculative execution bugs, this is a big issue if kernel mitigations are not enough and updated CPU microcode 
    is required ? How secure is Guix SD and do you plan to do anything about it ? Or do you recommend to use it only in secure physical environments which are air-gapped , give that known bugs might be active ?
6. How do you plan to handle the future with a kernel which does not allow firmware uploads to devices. As of today, for example, virtually no current generation GPU for PCs on the market works in  parameters without firmware. That means that 
	you cannot use Guix SD on server for any computing loads with current gen hardware, and on desktop you are limited to old hardware.  What is the project stance on this ? Is it doomed from start to work only on legacy hardware which in 5 to 10
years will be virtually extinct ? Yes, today you can still use it this way, since you have firmware free legacy GPUs available yet, but what about the future ?  How about in 5 years,  Will it run only on second hand machines using antiquated hardware
7. while I realize that Im inexperienced with guix, I consider that the type of issues I encountered should not be part of a software product in beta stage. It may be acceptable for the first one year in the life cycle of the product, but not on a beta system with what, like  8 -9 years under the belt .   Besides giving a very bad first impression, it wastes human time, and people time is the most precious resource. 
8. if I am mistaken on any point, please correct me. 
9. 

With thanks

Re: Suboptimal experience

[Julien Lepiller]

Le Sun, 17 Jun 2018 13:09:54 +0300,
Dan Partelly <dan_partelly@rdsor.ro> a écrit :

> Hello,
> 
> 
> First thanks for the development effort you guys do. Now the issues:
> 
> 1. I managed to install 0.14 to a Virtual box VM. I used bare-bones
> configuration. 2. I tried to get familiar with guix / guixSD a bit, I
> never used it before 3. Within minutes I managed to break the system
> completely , due to my misguided idea to execute a guix pull to
> upgrade the packages to the latest available. This command is a
> liability, while it should 100% safe given how  central is to the OS.
> 4. This resulted into an unusable system , the command “system” for
> guix did not functioned at all after whatever git pull did .  Guix
> reported: 5. attempting to fix the issue by pulling from git branch
> 0.14 where not successful.

Hi Dan,

congrats on installing GuixSD :)

I think you fell in a bug introduced by a recent change in how guix and
guix pull work. You probably need to run guix pull once more to end up
in a usable state. Sorry for the inconvenience :/

You won't need to run guix pull twice after that, there's only one time
where it's needed to transition to the new architecture.

> 
> 
> Now some  points:

For your other points... I can't really elaborate on them. Some of your
points go against our core values (software freedom) so we won't
implement them, but we're free software. We make it easy for you to
adapt guix packages to build your own, or even fork the project
entirely and create another distribution with different goals.

The rest of your points I think are already solved by the new guix pull
that caused the bug you experienced.

I hope I could help you. Don't hesitate to ask more questions or come
back if running guix pull once more didn't work :)

> 
> 
> With thanks

Re: Suboptimal experience

[Dan Partelly]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

Thanks a lot Julien. 

Well a second pull did not worked, it compiled sucessfully , but now any command results in :

guile: warning: failed to install locale.

Ill try to compile from git, I want to lear enough to solve those annoyance , so I can work a bit with guix sd see first hand what it has to offer

Thanks !	


> On Jun 17, 2018, at 18:40, Julien Lepiller <julien@lepiller.eu> wrote:
> 
> I hope I could help you. Don't hesitate to ask more questions or come
> back if running guix pull once more didn't work :)


[-- Attachment #2: Type: text/html, Size: 2369 bytes --]

Re: Suboptimal experience

[Julien Lepiller]

Le Sun, 17 Jun 2018 22:55:03 +0300,
Dan Partelly <dan_partelly@rdsor.ro> a écrit :

> guile: warning: failed to install locale.

This is a "normal" message. You need to install glibc-locales in your
profile and set an environment variable. Also, that's only a
warning ;).

It's documented here:
http://www.gnu.org/software/guix/manual/html_node/Application-Setup.html#Locales-1

Re: Suboptimal experience

[Dan Partelly]

Ive seen that in manual Julien, but I did not tried it, because the manual says: :When using Guix on top of GNU/Linux distribution other than GuixSD—a so-called foreign distro—a few additional steps are needed to get everything in place. Here are some of them.”       
Note the “… other than GuixSD” formulation.  I use it on GuixSD. Should i understand that he manual is flawed and the step is necessary on GuixSD as well ?

> On Jun 17, 2018, at 23:09, Julien Lepiller <julien@lepiller.eu> wrote:
> 
> Le Sun, 17 Jun 2018 22:55:03 +0300,
> Dan Partelly <dan_partelly@rdsor.ro> a écrit :
> 
>> guile: warning: failed to install locale.
> 
> This is a "normal" message. You need to install glibc-locales in your
> profile and set an environment variable. Also, that's only a
> warning ;).
> 
> It's documented here:
> http://www.gnu.org/software/guix/manual/html_node/Application-Setup.html#Locales-1

Re: Suboptimal experience

[Julien Lepiller]

Le Sun, 17 Jun 2018 23:13:27 +0300,
Dan Partelly <dan_partelly@rdsor.ro> a écrit :

> Ive seen that in manual Julien, but I did not tried it, because the
> manual says: :When using Guix on top of GNU/Linux distribution other
> than GuixSD—a so-called foreign distro—a few additional steps are
> needed to get everything in place. Here are some of them.” Note the
> “… other than GuixSD” formulation.  I use it on GuixSD. Should i
> understand that he manual is flawed and the step is necessary on
> GuixSD as well ?

Oh, you're right. It shouldn't be needed on GuixSD. I guess guix is now
based on a different libc than your system, so it can't find the locale
information. After you reconfigure and reboot, the message should go
away.

> 
> > On Jun 17, 2018, at 23:09, Julien Lepiller <julien@lepiller.eu>
> > wrote:
> > 
> > Le Sun, 17 Jun 2018 22:55:03 +0300,
> > Dan Partelly <dan_partelly@rdsor.ro> a écrit :
> >   
> >> guile: warning: failed to install locale.  
> > 
> > This is a "normal" message. You need to install glibc-locales in
> > your profile and set an environment variable. Also, that's only a
> > warning ;).
> > 
> > It's documented here:
> > http://www.gnu.org/software/guix/manual/html_node/Application-Setup.html#Locales-1  

Re: Suboptimal experience

[Mark H Weaver]

Hi Dan,

Dan Partelly <dan_partelly@rdsor.ro> writes:

> First thanks for the development effort you guys do. Now the issues:
>
> 1. I managed to install 0.14 to a Virtual box VM. I used bare-bones configuration.
> 2. I tried to get familiar with guix / guixSD a bit, I never used it before 
> 3. Within minutes I managed to break the system completely , due to my misguided idea to execute a guix pull to upgrade the packages to the latest available. This command is a liability, while it should 100% safe given how  central is to the OS.
> 4. This resulted into an unusable system , the command “system” for guix did not functioned at all after whatever git pull did .  Guix reported: 
> 5. attempting to fix the issue by pulling from git branch 0.14 where not successful.

A major change was recently made to 'guix pull', and there's apparently
a bug.  I'm sincerely sorry that this was your first impression of Guix.

In general, it's more helpful to report problems like this as a bug
report sent to <bug-guix@gnu.org>, with relevant information.  It would
have been useful to see the error message.  At the end of #4 above, you
wrote "Guix reported:" but I see nothing anything after that.  Did you
forget to include the error message?

> Now some  points:
>
> 1. Why does exist a tight coupling between guix proper and package
> definitions ?

My answer would be: the same reason that Linux (the kernel) has a tight
coupling between its device drivers and the core code.  If they were
separated, then all of the internal programming interfaces used in
device drivers would need to be frozen as public APIs, and it would
drastically curtail our ability to evolve those APIs and to keep the
code in the system clean.

On systems where device drivers and the kernel are separate, the device
drivers need to be written to handle several different kernel versions,
work around bugs in the kernel, etc, and the kernel is not free to
change these interfaces but must always consider backward compatibility
issues with older drivers.

The same issues arise in Guix between package definitions and the core
code in Guix that's used by the package definitions.  When we keep them
together, we retain the freedom to evolve not only the packages, but
also the *way* the packages are written.  We open the possibility of
Guix becoming a far more elegant system in the future.

> It is OK to recompile the package manager to get new functionality,
> not OK to recompile the package manager proper to get definitions for
> latest software.

The package definitions are by far most of the code, so separating them
would not make a huge difference in the time needed to run 'guix pull'.

>     It exposes the user to all kind of issues, from mundane to
> unmangeable / unusable systems .

A bug introduced into package definitions can also result in a
temporarily unusable system.  Keeping the package definitions separate
would not eliminate that possibility.

We are not able to eliminate the possibility that bad bugs will
sometimes be introduced into Guix.  However, what we can ensure is that
it's almost always possible to *roll* *back* to a working version.

In your case, it might have been useful to know that 'guix pull' only
changes ~/.config/guix.  If 'guix pull' gets you into a bad state, you
can always delete that directory as a last resort.

Going forward, recent versions of 'guix pull' include the ability to
list the "generations" of guix that have been compiled by 'guix pull',
and to roll back to an earlier generation, or to an arbitrary commit
from the git repo.

So, once you know your way around Guix, it is almost always possible to
recover by rolling back to older versions until the issue is resolved.

I write "almost always" to cover myself, but in practice I've been using
Guix for years as my primary development systems, and so far I've always
been able to easily roll back.  I can even install an experimental
untested version of glibc, without the slightest worry that it will be
difficult to recover from.  There are not many distros that can say
that.

> 3. compilation time of guix at guix pull time is horrendous. I dont
> know the system good enough, so I can be mistaken, but probably the
> bulk of is is because of package definitions . If this is true, then
> you have an issue. You are at about 7k packages, it will increase
> linear with n , you'll grow old near a computer running this package
> manager by the time you'll reach 30k + .

I agree that it's a problem, but it's not a fundamental problem with
Guix.  There are many ways that we can improve this.  The first
observation is that we needn't recompile all package definitions, only
the ones that have changed.  Also, we could compile package definitions
with far fewer optimizations.  Some work is needed in Guile here as
well.

Also, I should mention that it's possible to run Guix without ever using
'guix pull'.  I haven't run 'guix pull' in years.  Instead, I compile
guix from a git checkout, and updating guix involves 'git pull' and
'make', which is typically quite fast on modern systems.  Occasionally a
longer 'make clean' is required.  You can learn how to do this in the
"Contributing" chapter of the Guix manual.

* * *

I don't have time at the moment to respond to the rest of your email,
except to say that Guix is committed to including only free software,
and more specifically to follow the GNU Free Software Distribution
Guidelines (FSDG), described here:

https://www.gnu.org/distros/free-system-distribution-guidelines.html

    Regards,
      Mark

Re: Suboptimal experience

[Dan Partelly]

HI Mark

> A major change was recently made to 'guix pull', and there's apparently
> a bug.  I'm sincerely sorry that this was your first impression of Guix.

Well, is not all bad, there is a lot to like as well it seems, but I need to experience it first hand as well :P The concept might be very well the future, it reminded me of Plan9 Venti file system and Joe Armstrong’s  “The web of names hashes and UUIDs”. The concept of guix is powerful , maybe a solution to so many problems,  but when wielding powerful things, some care must be taken. Such as not making an util update itself from the bleeding edge of a development repository. 

>  At the end of #4 above, you
> wrote "Guix reported:" but I see nothing anything after that.  Did you
> forget to include the error message?

Yes I forgot. For any “guix system …. “ the message was:

guix: system: command not found . 

It basically could not execute any system command. I dont know yet the architecture of guix componenets . I promise Ill read but it will take time to go through all the docs. I assume guix is a dumb client, and all the work is done by the demon. But is the daemon
loading “plugins” to execute the various tasks ? Or is monolithic ?  Im trying to see how can this happen. Client / server / server plugins are all part of the same system , si it sould make sense to intall them all as a single transaction, i.e an all or nothing to minimize the chance of something like this happening. 

> We are not able to eliminate the possibility that bad bugs will
> sometimes be introduced into Guix.  However, what we can ensure is that
> it's almost always possible to *roll* *back* to a working version.

I agree. This is the nature of software development. But what one can do is to have as many safeguards as possible in place to *minimize* such chanches. Some ideeas would be:

	- do not ever pull a core system utility update from bleeding edge by *default*
	-  introduce regresión testing 
        - solve it socially by introducing rules for development 
	- have an “unstable” branch for bleeding edge from where who wants bleeding edge can pull at their own peril,

> A bug introduced into package definitions can also result in a
> temporarily unusable system.  Keeping the package definitions separate
> would not eliminate that possibility

Well, if you keep them separately , you break one, two, 10 packages, and you can mark them broken and thats it. If you argue that any package which does something important in the OS if bugged I agree. But it’s not about *eliminating* the chances for it is impossible. It is about “minimizing” the chance . The distinction is important IMO. Keeping package definitions separately reduces this risk imo.

> n your case, it might have been useful to know that 'guix pull' only
> changes ~/.config/guix.  If 'guix pull' gets you into a bad state, you
> can always delete that directory as a last resort.


Yes very useful. May I suggest put a resume of basic functionality  the manual as the first page ? The implementation and filesystem paths in guix are very alien for the first several hours of working with. An heads up in manual would be very usefull
to newcomers IMO. Its not that people do not read manuals (OK most people do not). But usally when you evaluate a new thing there is an exploratory direct phase , which is very important for the first impressions. This over, some will go and read on the subject and lear it, but IMO it has to go smooth to maintain the interest in the object.

> Going forward, recent versions of 'guix pull' include the ability to
> list the "generations" of guix that have been compiled by 'guix pull',
> and to roll back to an earlier generation, or to an arbitrary commit
> from the git repo.

Well, I found those commands almost instantly, but I used them in conjunction with system commands. Which was broken as I mentioned. It may have worked in conjuction with papckages for the root store, but until you finish reading the manual and get the concepts it is important to be have a bump free exploratory ride. 

> So, once you know your way around Guix, it is almost always possible to
> recover by rolling back to older versions until the issue is resolved.

Yes, i take your word for it, I almost no flight time on guix so …

> Also, I should mention that it's possible to run Guix without ever using
> 'guix pull'.  I haven't run 'guix pull' in years.  Instead, I compile
> guix from a git checkout, and updating guix involves 'git pull’ and

Thanks.








> On Jun 17, 2018, at 20:31, Mark H Weaver <mhw@netris.org> wrote:
> 
> Hi Dan,
> 
> Dan Partelly <dan_partelly@rdsor.ro> writes:
> 
>> First thanks for the development effort you guys do. Now the issues:
>> 
>> 1. I managed to install 0.14 to a Virtual box VM. I used bare-bones configuration.
>> 2. I tried to get familiar with guix / guixSD a bit, I never used it before 
>> 3. Within minutes I managed to break the system completely , due to my misguided idea to execute a guix pull to upgrade the packages to the latest available. This command is a liability, while it should 100% safe given how  central is to the OS.
>> 4. This resulted into an unusable system , the command “system” for guix did not functioned at all after whatever git pull did .  Guix reported: 
>> 5. attempting to fix the issue by pulling from git branch 0.14 where not successful.
> 
> A major change was recently made to 'guix pull', and there's apparently
> a bug.  I'm sincerely sorry that this was your first impression of Guix.
> 
> In general, it's more helpful to report problems like this as a bug
> report sent to <bug-guix@gnu.org>, with relevant information.  It would
> have been useful to see the error message.  At the end of #4 above, you
> wrote "Guix reported:" but I see nothing anything after that.  Did you
> forget to include the error message?
> 
>> Now some  points:
>> 
>> 1. Why does exist a tight coupling between guix proper and package
>> definitions ?
> 
> My answer would be: the same reason that Linux (the kernel) has a tight
> coupling between its device drivers and the core code.  If they were
> separated, then all of the internal programming interfaces used in
> device drivers would need to be frozen as public APIs, and it would
> drastically curtail our ability to evolve those APIs and to keep the
> code in the system clean.
> 
> On systems where device drivers and the kernel are separate, the device
> drivers need to be written to handle several different kernel versions,
> work around bugs in the kernel, etc, and the kernel is not free to
> change these interfaces but must always consider backward compatibility
> issues with older drivers.
> 
> The same issues arise in Guix between package definitions and the core
> code in Guix that's used by the package definitions.  When we keep them
> together, we retain the freedom to evolve not only the packages, but
> also the *way* the packages are written.  We open the possibility of
> Guix becoming a far more elegant system in the future.
> 
>> It is OK to recompile the package manager to get new functionality,
>> not OK to recompile the package manager proper to get definitions for
>> latest software.
> 
> The package definitions are by far most of the code, so separating them
> would not make a huge difference in the time needed to run 'guix pull'.
> 
>>    It exposes the user to all kind of issues, from mundane to
>> unmangeable / unusable systems .
> 
> A bug introduced into package definitions can also result in a
> temporarily unusable system.  Keeping the package definitions separate
> would not eliminate that possibility.
> 
> We are not able to eliminate the possibility that bad bugs will
> sometimes be introduced into Guix.  However, what we can ensure is that
> it's almost always possible to *roll* *back* to a working version.
> 
> In your case, it might have been useful to know that 'guix pull' only
> changes ~/.config/guix.  If 'guix pull' gets you into a bad state, you
> can always delete that directory as a last resort.
> 
> Going forward, recent versions of 'guix pull' include the ability to
> list the "generations" of guix that have been compiled by 'guix pull',
> and to roll back to an earlier generation, or to an arbitrary commit
> from the git repo.
> 
> So, once you know your way around Guix, it is almost always possible to
> recover by rolling back to older versions until the issue is resolved.
> 
> I write "almost always" to cover myself, but in practice I've been using
> Guix for years as my primary development systems, and so far I've always
> been able to easily roll back.  I can even install an experimental
> untested version of glibc, without the slightest worry that it will be
> difficult to recover from.  There are not many distros that can say
> that.
> 
>> 3. compilation time of guix at guix pull time is horrendous. I dont
>> know the system good enough, so I can be mistaken, but probably the
>> bulk of is is because of package definitions . If this is true, then
>> you have an issue. You are at about 7k packages, it will increase
>> linear with n , you'll grow old near a computer running this package
>> manager by the time you'll reach 30k + .
> 
> I agree that it's a problem, but it's not a fundamental problem with
> Guix.  There are many ways that we can improve this.  The first
> observation is that we needn't recompile all package definitions, only
> the ones that have changed.  Also, we could compile package definitions
> with far fewer optimizations.  Some work is needed in Guile here as
> well.
> 
> Also, I should mention that it's possible to run Guix without ever using
> 'guix pull'.  I haven't run 'guix pull' in years.  Instead, I compile
> guix from a git checkout, and updating guix involves 'git pull' and
> 'make', which is typically quite fast on modern systems.  Occasionally a
> longer 'make clean' is required.  You can learn how to do this in the
> "Contributing" chapter of the Guix manual.
> 
> * * *
> 
> I don't have time at the moment to respond to the rest of your email,
> except to say that Guix is committed to including only free software,
> and more specifically to follow the GNU Free Software Distribution
> Guidelines (FSDG), described here:
> 
> https://www.gnu.org/distros/free-system-distribution-guidelines.html
> 
>    Regards,
>      Mark

Re: Suboptimal experience

[swedebugia]

Hi

On June 17, 2018 9:51:51 PM GMT+02:00, Dan Partelly <dan_partelly@rdsor.ro> wrote:
>HI Mark

[...]

> For any “guix system …. “ the message was:
>
>guix: system: command not found . 

I experienced this as well today after guix pull from 0.14 to commit http://git.savannah.gnu.org/cgit/guix.git/commit/?id=b4eae997fe5b928f179c34d281e9f2c3eccd3670 if I remember correctly. 

I just understood from the previous reply that running guix pull again will solve the problem. I will try later and report back the result. 

-- 
Cheers Swedebugia

Re: Suboptimal experience

[Dan Partelly]

Well, retried again a git pull today. It broke with no backtrace (an exception while printing backtrace)
ERROR: In procedure private-lookup: No variable bound to define-module* in module (guile)

cannot build derivation for /gnu/store/sha…guix-32eb44240-modules.drv: 1 dependencies could not be built
cannot build derivation for /gnu/store/sha…guix-32eb44240.drv: 1 dependencies could not be built

I do not know whats going on, but one two things are sure:

1. If is true that any packager can break the build of guix by commiting a bad package definition, then the whole packaging system design is **FLAWED** in my opinion. A system which is so brittle has no place in an industrial environment, at least until such issues are permanently resolved.  Yes, Mark was nice enough to say you can build it from source and it works better, but to be honest, when I work with an OS I just want tools which do work and make my life easier, not 
spit error after error for days. If I need to build a repository, it must be because i want to modify something or customize some software, not because the OS itself burps .

2. A package manager which fails time and again to build itself doesn't present itself as very trustworthy. It may be very well be, but adoption of software is governed by social factors more than technical excellence. GuixSD for now is very nice and cool, but its a hacking playground, not an industrial strength OS which you deliver without worry. 

So please excuse me if I give a bit of unsolicited advice, please fix all those before going 1.0.  It does not gives a good impression on the OS. I believe its important for your future marketing and your goals to further free software in this world. 






> On Jun 18, 2018, at 14:11, swedebugia <swedebugia@riseup.net> wrote:
> 
> Hi
> 
> On June 17, 2018 9:51:51 PM GMT+02:00, Dan Partelly <dan_partelly@rdsor.ro> wrote:
>> HI Mark
> 
> [...]
> 
>> For any “guix system …. “ the message was:
>> 
>> guix: system: command not found . 
> 
> I experienced this as well today after guix pull from 0.14 to commit http://git.savannah.gnu.org/cgit/guix.git/commit/?id=b4eae997fe5b928f179c34d281e9f2c3eccd3670 if I remember correctly. 
> 
> I just understood from the previous reply that running guix pull again will solve the problem. I will try later and report back the result. 
> 
> -- 
> Cheers Swedebugia

Re: Suboptimal experience

[Julien Lepiller]

Le 2018-06-18 17:01, Dan Partelly a écrit :
> Well, retried again a git pull today. It broke with no backtrace (an
> exception while printing backtrace)
> ERROR: In procedure private-lookup: No variable bound to
> define-module* in module (guile)
> 
> cannot build derivation for /gnu/store/sha…guix-32eb44240-modules.drv:
> 1 dependencies could not be built
> cannot build derivation for /gnu/store/sha…guix-32eb44240.drv: 1
> dependencies could not be built

This is a bug in guix pull. It has already been reported and we're 
working
on a fix. That shouldn't cause any issue on your side: the failure to 
pull
simply means that your guix wasn't updated. As a workaround, you can try 
again
as long as it fails in this way. "guix pull --cores=1" might help too.

The error is not in the package definitions, it's more likely a race 
condition
introduced with the recent guix pull update.

> 
> I do not know whats going on, but one two things are sure:
> 
> 1. If is true that any packager can break the build of guix by
> commiting a bad package definition, then the whole packaging system
> design is **FLAWED** in my opinion. A system which is so brittle has
> no place in an industrial environment, at least until such issues are
> permanently resolved.  Yes, Mark was nice enough to say you can build
> it from source and it works better, but to be honest, when I work with
> an OS I just want tools which do work and make my life easier, not
> spit error after error for days. If I need to build a repository, it
> must be because i want to modify something or customize some software,
> not because the OS itself burps .

Sorry about the bad experience :/ As I said, all this is due to the fact 
that
guix evolves really fast. That's also the reason why we still consider 
it
beta. Had you tested it a few days earlier, everything would have been
going smoothly.

> 
> 2. A package manager which fails time and again to build itself
> doesn't present itself as very trustworthy. It may be very well be,
> but adoption of software is governed by social factors more than
> technical excellence. GuixSD for now is very nice and cool, but its a
> hacking playground, not an industrial strength OS which you deliver
> without worry.
> 
> So please excuse me if I give a bit of unsolicited advice, please fix
> all those before going 1.0.  It does not gives a good impression on
> the OS. I believe its important for your future marketing and your
> goals to further free software in this world.

Thank you for your advice :) I think you're right: we are still beta, so
errors are to be expected from time to time. We should fix them before 
we
go 1.0. That said, the system is robust enough that you can always 
recover
from said errors.

> 
> 
> 
>> On Jun 18, 2018, at 14:11, swedebugia <swedebugia@riseup.net> wrote:
>> 
>> Hi
>> 
>> On June 17, 2018 9:51:51 PM GMT+02:00, Dan Partelly 
>> <dan_partelly@rdsor.ro> wrote:
>>> HI Mark
>> 
>> [...]
>> 
>>> For any “guix system …. “ the message was:
>>> 
>>> guix: system: command not found .
>> 
>> I experienced this as well today after guix pull from 0.14 to commit 
>> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=b4eae997fe5b928f179c34d281e9f2c3eccd3670 
>> if I remember correctly.
>> 
>> I just understood from the previous reply that running guix pull again 
>> will solve the problem. I will try later and report back the result.
>> 
>> --
>> Cheers Swedebugia

Re: Suboptimal experience

[Dan Partelly]

> 
> Thank you for your advice :) I think you're right: we are still beta, so
> errors are to be expected from time to time. We should fix them before we
> go 1.0. That said, the system is robust enough that you can always recover
> from said errors.
> 

Good. Now, give current state of affairs combined with my lack of experience with the system I wont install it for work anywhere as some fo you guys do, but I will install it on an old laptop and I will try to build my Linux recovery images with it. This will give me time to learn it and Ill take it from here. The truth is that despite the negatives of the first encounter  the system has some characteristics that are too good to pass. And you where right when you told me that is very easy to extend and “make it your own”. 

Which is the right mailing list for asking question regarding packaging software, hooking into build system and so on (ofc, packaging discussion in the limit of your core values ) ?

With thanks

Re: Suboptimal experience

[Nils Gillmann]

Dan Partelly transcribed 1.0K bytes:
> 
> 
> > 
> > Thank you for your advice :) I think you're right: we are still beta, so
> > errors are to be expected from time to time. We should fix them before we
> > go 1.0. That said, the system is robust enough that you can always recover
> > from said errors.
> > 
> 
> Good. Now, give current state of affairs combined with my lack of experience with the system I wont install it for work anywhere as some fo you guys do, but I will install it on an old laptop and I will try to build my Linux recovery images with it. This will give me time to learn it and Ill take it from here. The truth is that despite the negatives of the first encounter  the system has some characteristics that are too good to pass. And you where right when you told me that is very easy to extend and “make it your own”. 
> 
> Which is the right mailing list for asking question regarding packaging software, hooking into build system and so on (ofc, packaging discussion in the limit of your core values ) ?
> 
> With thanks
> 
> 
Usually guix-devel, but depending on the matter it might also be help-guix.
We've set up help-guix for (I think) user specific questions in 2016 as well
as usability and general questions. Tinkering around the core and other
topics are for guix-devel, as well as anything development related...
or did we ever define more than a vague scope for them?
-> https://www.gnu.org/software/guix/contact/