This useful reference says "GNU Guix1 is a functional package management tool for the GNU system", so it's not a "Distro" as the title here declares? but rather, it's an aptitude replacement via guile? It's always nice to get from protracted video, and odd headline, to: "ok, but what is it? what's its function?"
> Last but not least, Guix is used to build a distribution of the GNU system, with many GNU and non-GNU free software packages. The Guix System Distribution, or GNU GSD, takes advantage of the core properties of Guix at the system level. With GNU GSD, users declare all aspects of the operating system configuration, and Guix takes care of instantiating that configuration in a reproducible, stateless fashion. See GNU Distribution[0].
How does Guix compare to NixOS? Now that both have been around a little while, what are the relative merits of Guile and the Nix expression language, in practice? How big is each community? The Guix package list is much smaller than the NixOS list?
I'm a Guix core developer, so my answers below will of course be biased towards Guix.
>what are the relative merits of Guile and the Nix expression language, in practice?
Nix is a DSL, whereas Guile is a general-purpose programming language. In practice, I find it better to use a general-purpose language, because you have access to all of the features of that language and its libraries for free.
>How big is each community?
I don't have any stats, but the Nix community is definitely bigger. Both communities are very active. The guix-devel mailing list and the #guix IRC channel are busy places.
Guix is not as old as Nix. Guix reuses parts of Nix but replaces the various languages in use for Nix packages and tools with Guile Scheme, both in the "frontend" as well as the "backend". Packages are just regular Guile modules, so the whole thing can readily be used as a library as demonstrated by Guix web, a browser interface.
IIRC, Guix uses dmd as 'init' while NixOS uses systemd, which is full feature (for better or worse), documented and communiti-fied. dmd felt cryptic to use even after a little RTFM session. People on #guix are happy to review our patches though ;)
Unfortunately, guix seems to fall into the problem so many source distribution systems fall into. Looking through the documentation, they make it entirely too difficult to customize compilation options. For example, FreeBSD's packaging system has make.conf, which allows one to set environment flags for the package build system, its ports tree lets you make custom builds of software for things like additional library support, and generally supports options that let you make your systems your own.
Guix, while it claims to support repeatable builds, keeps you in the same restrictive build process as other package managers. It's hard to configure how your packages are built, hard to maintain your custom options between updates, and from the scant documentation, and hard to maintain a server for private packages. Add in its poor capabilities as a package manager, such as the bizarre requirement to upgrade the distribution to upgrade your package list, and you just have a poor mess of an operating system.
>It's hard to configure how your packages are built
In Guix, packages are Scheme objects, giving you maximum flexibility. You can easily customize configure/make flags, along with many other things, to make custom package builds. It's also easy to maintain your own separate package recipes. Guix makes packaging easy. That said, there are folks that are interested in a global configuration system, so maybe we'll see that some day. Guix is alpha software, it doesn't have every bell and whistle that you might like.
>and hard to maintain a server for private packages
First of all, you don't need a server for any packages. There is no single point of trust in Guix. You can build every single package on your own computer. Now, you could run your own Hydra instance like https://hydra.gnu.org, and soon you'll be able to run 'guix publish' from any guix machine to spawn a server that exposes a Hydra-compatible web service for serving binaries.
>Add in its poor capabilities as a package manager
Transactional upgrades, rollbacks, and per-user package installation are poor capabilities?
>the bizarre requirement to upgrade the distribution to upgrade your package list
The package recipes ship with Guix, so upgrading Guix via 'guix pull' gets you the new package recipes, too. This does not upgrade the system, only the version of Guix for the user who ran 'guix pull'. The "package list" isn't a package list, it's a collection of Scheme modules.
Yes, I know what reproducible builds are. Debian, and FreeBSD have them for default configurations, and OpenBSD is working towards that direction. However, FreeBSD and OpenBSD also make it easy for a user to customize their builds through well-documented commands. The two goals are not mutually exclusive, but the decisions made by your software make that hard.
Your argument about packages being Scheme objects completely misses the point. How are the configuration options maintained between versions? With systems like FreeBSD, the package build configurations are saved elsewhere. This means that when I do update, my configuration options are saved, without me needing to patch the build recipe every time a new version's released.
Yes, I know I don't need a package server if I'm just pulling packages other people wrote, and all that software plays nicely together. There are a lot of cases, though, that require that different machines have mutually incompatible configurations. For example, your webservers could all be nginx, except for the two servers in the corner that are serving up an old mod_perl app. Having a server that can serve packages and dependency chains for these two cases can be invaluable. For that, I'm going to need a server that my machines can poll to figure out what packages are indeed available. From everything you've stated, guix doesn't have that capability.
Transactional maintenance is definitely interesting, and something I'd love to see other OSes do. Per-user package installation, on the other hand, is something a lot of other packaging systems have. NetBSD's pkgsrc, Gentoo's build system, etc, all support it without any problem. Your system, requires what should be metadata -- package build instructions -- to be intermingled with code -- the package manager program. Additionally, its querying capabilities seem lacking; there doesn't seem, for example, to be any option to figure out what package installed a particular file. Additionally, there is no way for a systems administrator to easily audit those packages installed by users; if a user is running an insecure, out of date program because they haven't done an update in six months, this could lead to some pretty big problems.
I know that the package list is a collection of scheme modules. At the same time, those modules almost certainly are not interwoven into the base guix system. Additionally, there are many packages, like daemons, suid software, etc, that will need to be updated by the root user. Furthermore, as vulnerabilities like heartbleed and shellshock have shown, there are times when one can't wait for scheduled releases to push patch updates. Intermeshing the software from the data is just going to lead to problems.
>Your system, requires what should be metadata -- package build instructions -- to be intermingled with code -- the package manager program.
Package build instructions are code. C Packages builds in Guix are a pure function of their dependencies and the version of Guix being used, so it makes perfect sense to ship the package recipes with Guix itself.
>Intermeshing the software from the data is just going to lead to problems.
So far it's lead to a lot of solutions. As Lispers often say, code is data, and data is code. I think you have a disagreement with this notion, so it's obvious why you would not like Guix or Nix.
> Additionally, there is no way for a systems administrator to easily audit those packages installed by users; if a user is running an insecure, out of date program because they haven't done an update in six months, this could lead to some pretty big problems.
Not true. A sysadmin can modify other users' profiles, e.g. to force-upgrade packages and destroy generations referencing old packages.
There is a bit about customizing packages in the linked video, at about 21 minutes in. It explains how you can make a derivative package by inheriting from a package spec and only specifying changes.
I think the title of this was misleading, but in essence it seems Guix is a system for specifying packages and OS dependencies in a way that allows for easy customization.
They show, at ~36 minutes in the video, how to specify OS dependencies and from that create a virtual machine instance automatically.
Systemd just doesn't integrate well into our system. The big advantage of using dmd is that it is also written in Scheme, giving us access to all of the features and libraries that Guile has. Our initrd is also written in Scheme, giving us the same advantages.
There is a GSoC proposal out there to add support for some of systemd's file formats to dmd, for interoperability (and being able to run GNOME, notably). If any student reads this and wants to hack on an init system this summer, subscribe to our mailing list or hop on #guix on freenode and let us know.
People keep comparing systemd with sysv, as if they are both "just" inits. But one has grown way beyond being considered just as a init.
To me at least it seems more and more that replacing init has become a sour pill people accept for getting some sugary candy elsewhere within the systemd sphere of influence.
This is like complaining about too much biodiversity.
Accept that computing is a vast and complex topic, and that there are far too many ways of doing even basic things than you will be able to learn completely.
This does mean giving up the idea that you will be the master of the topic with all of the answers. It also means that you need to practice humility in the face of different customs. What can you learn from this strange distro? What does it do better than the tools you have?
Remember that your way is not the only way, and that it is statistically unlikely to be the best way. No matter how clever you are.
It's really not fragmentation. Each project serves a different set of users. They share the low-level concepts and technology, but differ quite a lot in methodology and higher-level details.
Specifically, it uses Nix as the underlying system, but implements a new syntax and maintains a separate package tree written in this new syntax. I'm not entirely certain why.
It's told very clearly on both the project's website and in the linked video that they consider the Scheme language to provide a more hackable interface for package specification and management. It's also demonstrated that it all integrates very nicely into Emacs.
On top of that it's also stated in the comments here, by a Guix developer, that while having a DSL for package specification is nice, they think having a whole general purpose language for it is better.
