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 <address@hidden> wrote:
> 
> Hi Dan,
> 
> Dan Partelly <address@hidden> 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 <address@hidden>, 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