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.
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.