Re: Guix vs GuixSD

[Jookia <166291@gmail.com>]

On Tue, Feb 16, 2016 at 03:26:01AM +0000, Chris Marusich wrote:
> (Apologies for top-posting; my mobile email client doesn't seem to let me
> post in any other way...)
>
> Regarding your diagrams, I guess the one that shows GuixSD using Guix makes
> a little more sense to me than the one that shows GuixSD as a total
> replacement for Guix. However, I'm not sure exactly how GuixSD uses Guix
> when managing the system, so I will defer to the opinion of others on the
> mailing list who know more about theses things than me.
>
> It isn't clear to me what you want to know. Perhaps if you can ask a more
> concrete question, it will be easier for the others to answer?
>
> To reiterate what I said before: my current understanding is that Guix is a
> functional package manager (with a lot of fantastic features) that you can
> run anywhere. That's all, really. And GuixSD is a full GNU operating system
> which currently uses Linux-Libre as its kernel, Guix as its package
> manager, and Shepherd (formerly DMD) as its init system. Similar to a
> GNU/Linux distribution, the GuixSD system comes with some extra "glue"
> which makes all those separate components work together out of the box. But
> the way that those components are glued together in GuixSD allows you to
> enjoy certain benefits that you don't get with other systems (software
> freedom, system configuration in guile, easy rollback of system upgrades,
> etc). I don't yet know much about how GuixSD's "glue" is implemented, but I
> think that's the gist of it.

I can see how this is confusing, after all, how would a package manager be used
to package things like an initramfs or SSH configuration? Well, the trick is
that GuixSD effectively 'packages' your os-configuration.

If we look at a Guix package we can see it takes a configuration of sources,
a build system, maybe some build phases and maybe some more things like patches.
From this a few derivations are built, which are basically things put in the
Guix store. These derivations include the patched source code and the final
binaries. Then Guix takes these final binary derivations and puts them in your
profile so you can use them if it's something you installed explicitly.

The key here is that Guix generates a lot of things, though most often this is
hidden by substitute downloads of the final binary unless you compile everything
yourself. How could you build an operating system out of this? Well, think of
the operating system as one giant package that Guix generates a ton of
derivations for then links them to your system's profile. So if you have SSH
running it'll make you a cool SSH configuration derivation then link that in.

"Why would you do this?" is probably your next question. Well, let's say you
update a ton of Guix packages and it breaks half way. This is okay since it
won't change your Guix profile until you actually have a working set of
packages and all their dependencies. You can also rollback in case the latest
version of your favourite browser Icecat breaks an add-on you absolutely need.

Now if we apply this to the operating system 'package', or derivation, you can
switch between all the things that make up your system in much the same way or
roll back. The switching here is done using 'guix system reconfigure' or at boot
through GRUB if the latest version of a system configuration, such as a Shepherd
service somehow kills your entire system. Guix also has support for installing
your os-configuration not just to your drive, but to a VM or a container.
Imagine looking online for Guix configurations to try in a VM then setting that
up as your main system configuration!

Perhaps I went a bit off topic there but I hope this give some understanding.
Jookia.