

GNU Guix 0.8.1 - taylanub
https://savannah.gnu.org/forum/forum.php?forum_id=8193

======
loevborg
I tried out nixos (the complete distro based on nix) on the weekend -- it's
not saying too much that it's a revelation. I can see myself completely
switching for my development machines and possibly for servers as well.

The amazing thing is that the whole set up of your linux machine is
encaptulated in one declarative text file (that you can put in version
control). Give it a try by installing it using VirtualBox:
[https://nixos.org/wiki/Installing_NixOS_in_a_VirtualBox_gues...](https://nixos.org/wiki/Installing_NixOS_in_a_VirtualBox_guest).
You can log in (demo/demo in the 14.10 vm) and play around, essentially be
editing `/etc/nixos/configuration.nix`.

I recommend trying the configuration of an experienced user. Here's the result
of a simple search on github:

[https://github.com/sitano/configuration.nix](https://github.com/sitano/configuration.nix)

[https://github.com/Hinidu/configuration.nix](https://github.com/Hinidu/configuration.nix)

[https://github.com/garbas/nixos-
configuration](https://github.com/garbas/nixos-configuration)

You can also get started very easily using a ec2 tiny instance (free tier):
[https://nixos.org/wiki/NixOS_on_Amazon_EC2](https://nixos.org/wiki/NixOS_on_Amazon_EC2)

~~~
agumonkey
Reminds me of archlinux early days when one of their main arguments was that
configuration was done in a single file (as BSDs). Nix is like a typechecked
version of that.

------
dangirsh
Awesome to see this here! I've been using Nix/Nixos (which Guix is heavily
based on) on my personal laptop for several months now. I'll never look back
from the purely declarative system configuration - I finally feel like I have
full control of my machine's state.

It looks like Guix provides a significantly more expressive interface with
Scheme than Nixos does with Nix expressions. IIRC, there's also better
integration with the system (Nixos auto-generates plenty of bash), which will
surely accelerate development / debugging.

Does anyone here have Guix experience to share?

~~~
ArneBab
I ran Guix as user-specific overlay on my Gentoo box for some time. It was
pretty neat and I thought about using it for cross-distro deployment of
libraries I need for development.

About half a year ago I ran into problems with updating and did not have the
time to fix it (stuff simply did not build - I did not try the --with-source
trick).

I hope that a reinstall with the new version fixes that.

What sold it to me was that when the system breaks during update, everything
is still in a working state. → [http://draketo.de/light/english/install-gnu-
guix-03](http://draketo.de/light/english/install-gnu-guix-03) My son once
found the power-connector of my Gentoo box while I was running updates and hit
the pretty red glowing button. It took me three days to recover the system…

~~~
aidenn0
Do you have a specific guide you followed for trying that? I've been using
gentoo for a while, and this sounds like a good way to try guix or nix.

------
drdaeman
Everyone talks about advantages. Would love to hear about disadvantages. Not
obvious ones (like having to learn configuration language semantics or package
missing stuff myself), but things that don't lie down in a plain sight right
away and only discovered after a few days, weeks or months of usage.

Anyone to share their experiences?

(Migrating from Arch to NixOS at the moment, but thought maybe I'd detour a
bit and try Guix.)

~~~
taylanub
From my understanding, the biggest disadvantage to purely functional package
management is that you can't just swap out a package in isolation when many
others depend on it. If I upgrade a package, I have to upgrade its whole DAG
of dependent packages if I want them to use the new version (I could however
delay that; they would simply continue to use the old version which hasn't
been garbage-collected yet because they still use it).

So lots and lots of compilation (on build farms at least), and lots of
bandwidth usage. Though something like ccache can help with the compilation,
and binary diffs could help with the bandwidth.

Immutable data structures in FP are probably a good analogy.

Edit: argh, this was supposed to be a reply to the question about the
disadvantages of the purely functional package managers specifically, not the
OS in general.

~~~
knome
To save compilation time and bandwidth the authors might be able to make their
package dependencies sort of inside out, using a smaller program simply to
perform the needed library loading and dependency injection on the core of the
software.

Then if you're going between versions, you can avoid having to update the
lion's share of code just because the dependencies change.

    
    
        jabberwork-1.2
          jabberwock.core-1.6
          jabberwock.apache.interface-0.3
        
        jabberwock-1.3
          jabberwock.core-1.6
          jabberwock.apache-interface-0.4
    

Instead of having to update all the hefty ".core" modules, you could get away
with only updating the hopefully lighter launchers / library loaders and the
specific interface code being updated.

~~~
taylanub
I also started thinking things along the lines of that when I first looked
into how Guix does things, but after annoying the developers a little (many
thanks to Ludovic's patience) I've come to understand that things like that
beat the whole purpose of having pure packages not only in _binary content_
but also in _run-time behavior_.

Basically, reproducible builds are a red herring here. A package's identity is
not only the hash of its byte-by-byte contents, it also includes ("closes
over") the identities of all packages it "references" (depends on), meaning it
will always have the exact same run-time behavior everywhere because even all
its dependencies count as part of its identity.

------
taylanub
Version 0.8.1 of GNU's purely functional package manager Guix has been
released.

The project develops, at the same time, GNU GSD (Guix System Distribution), a
GNU operating system.

GNU GSD is an avant-garde GNU system utilizing Guix as its package manager,
and the similarly Guile/Scheme based dmd as its init system.

~~~
josteink
First of all: Guix (and Nix) seems like really interesting projects, I'm just
not there yet that I'm going to nuke what I know and love for it.

I probably will one day, but not right now.

But: I'm not sure you're doing your work any justice by labelling it "avant-
garde". I think you risk looking "weird" or more dangerous than you need to
and might detract people from looking into it.

~~~
taylanub
Someone else just pointed that out to me too. I didn't know of all the
connotations of the term, sorry about that. :-)

------
Zardoz84
Could someone explain in a simple way, why this is better that using, for
example, apt-get ?

~~~
chriswarbo
Guix is based on Nix, so the following applies to both.

apt-get allows at most one version of a package to be installed at a time; if
you want two versions, you need to ask the maintainers to split the package
into two. Guix doesn't suffer this problem; packages are given an ID based on
a hash of their contents and dependencies, so two versions will happily sit
side-by-side. An "update" is treated more like installing a separate package.

If two applications depend on two different versions of some library, you
can't install both applications. In Guix you can, since each can use the
version it needs.

apt-get affects the whole system. All users are affected by a change; if some
other user installs/removes/updates a package, you have to just deal with it.
In Guix, every user gets a "profile" package, which can depend on anything
they like. Installing/removing/updating packages just creates a new version of
your profile, with its dependencies added/removed/changed according to what
you asked for.

apt-get is stateful: the contents of /usr, /etc, etc. are changed as packages
are installed/removed. Guix is immutable: packages live in their own read-only
directories, so nothing can break them after installation.

apt-get can't roll back: packages can't be down-graded, all kinds of actions
are taken by pre/post install scripts which can't be undone, etc. Since Guix
is immutable, "rolling back" just means going back to the old selection of
packages; ie. installing the old version of the profile package.

~~~
pmahoney
> if you want two versions, you need to ask the maintainers to split the
> package into two

This is still true in Nix (and Guix I assume), although there are facilities
for overriding, say, just the source tarball (to a different version) without
needing to create a whole new Nix package (and worst case, creating a whole
new Nix package is an order of magnitude easier than creating a Debian package
in my experience).

In the "nixpkgs" set of packages, a few packages come in multiple versions
(gcc, autotools come to mind), but most are only available in a single
version.

Of course, once you've managed to _install_ package-version-1, even as nixpkgs
moves to version 2, 3, and so on, your version 1 can remain installed forever
if you wish, and nothing can swap out the libpng, or libc or whatever it may
depend on, since as you say all these can live side-by-side with other
versions of themselves.

------
rekado
We are going to use Guix as a package manager on a bioinformatics cluster.
Managing various different scientific applications at different versions with
very different dependencies for different user groups is something that is
incredibly painful with traditional packaging systems. Guix greatly simplifies
this whole process and writing package definitions in Scheme is so much nicer
than, say, writing RPM spec files.

~~~
ArneBab
that sounds pretty cool!

I tried using Guix to deploy to the cluster in Karlsruhe (more than a year
ago) but back then it was still missing most of the libraries I needed. When
you finished making it work for your cluster, that could be a pretty good base
for many other people, too.

------
housel
To try the downloaded USB image in VirtualBox, first decompress the .xz file
and then run

    
    
        vboxmanage convertfromraw ~/Downloads/gsd-usb-install-0.8.1.i686-linux gsd-install.vdi --format vdi
    

The resulting VDI file can then be attached to a VirtualBox machine as a
primary IDE disk. Be sure to enable PAE/NX in the System settings.

------
gkya
It seems that Guix&Nix have many advantages. Could anyone also elaborate some
disadvantages of this system in comparison with traditional package managers
like debian's or rpm? [Edit] I'm considering a switch to one of Guix or Nix,
and I'd like to know if the pros outweigh the cons.

~~~
rekado
One disadvantage compared to RPM and apt-get is that there are not as many
packages available yet.

------
agumonkey
Nix and Guix begin to have some momentum, it's a joy to see. I'm now wondering
if that momentum will revive.. Hurd development. That's right, I said it.

------
ArneBab
It’s great to see a new release!

