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