Re: Suboptimal experience

[Mark H Weaver]

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