GNU Guix – The Emacs of Distros [video]
audio-video.gnu.org
audio-video.gnu.org
> 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].
[0]: https://www.gnu.org/software/guix/manual/guix.html#GNU-Distr...
>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.
https://lists.gnu.org/archive/html/guix-devel/2015-02/thread...
>The Guix package list is much smaller than the NixOS list?
Yes. The Guix package list is rapidly growing, though. Patches for new packages come in every day. Our last release had 164 new packages.
Hope this helps!
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.
>Guix, while it claims to support repeatable builds, keeps you in the same restrictive build process as other package managers.
This sentence makes no sense to me. Do you know what "reproducible builds" means in this context? See: https://wiki.debian.org/ReproducibleBuilds/About
>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.
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.
Not true. A sysadmin can modify other users' profiles, e.g. to force-upgrade packages and destroy generations referencing old packages.
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.
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.
With regards to your main complaint, I found this after about two minutes on their site: https://www.gnu.org/software/guix/manual/guix.html#Defining-...
It seems fairly easy to me to use the following to specify your build configurations:
(arguments `(#:configure-flags '("--enable-silent-rules")))
As for saving your configuration locally and on a private server, could you not just save these package specifications you've made?
Really though. Haven't tried anything with dmd, but it cannot possibly be worse than SysV init.
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.
Should make people stand up and pay attention...
Should give pause for thought, but i guess i am expecting too much...
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.
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.
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.