GNU Guix Package manager & OS

guix shell is definitely one of the top features of Guix. It allows you to quickly download any program and run it. Compared to apt or such, where downloading one package is an arduous process and might just break your system because of a conflict or something else, it is quick, reliable and has no side effects on your system besides the files made by the program (which can be eliminated via the usage of --container). Well, almost - there is one side effect of the command - it does fill out your disk space. Usually not a concern but worth mentioning.

The other feature that I consistently use, is profiles. My computer has several profiles, such as the emacs profile that contains all emacs-related packages, chromium profile with ungoogled chromium and ublock origin, latex that just contains TexLive, etc. It allows you to partition packages and manage them all separately as if they were on a different machine. I very rarely update my emacs profile, because there is little point; but reasonably often I add some packages to my guix-home profile.

The way I use profiles is primarily through manifests, which are just lists of packages. For example, my chromium manifest looks like this:

chrome.scm
(specifications->manifest '("ungoogled-chromium" "ublock-origin-chromium"))

I keep all profiles under a $HOME/profiles directory, which makes it easy to activate them at startup (by running the $PROFILE/etc/profile script; note that this requires GUIX_PROFILE to be bound to that profile).

I can run guix package -m chrome.scm -p ~/profiles/chrome to update or reinstall it. These manifests are a great way to manage packages - I both keep track and partition the packages amongst them reasonably. They also allow arbitrary Guile code execution, which offers some interesting possibilities for install-time scripts.

There's of course some jank related to using profiles. As a seasoned GNU/Linux user, I am quite tolerant of jank - have to be. With Guix profiles, it mostly stems down to one of these issues:

Guix System is a great concept, and something I got involved in at first - it appeals to the distro-hopper, who is looking for a new system, and if you have a proper amount of time, it can work. Ultimately, I settled down for Debian+Guix on my user computers for a number of reasons - primarily related to desktop environments and my various troubles with them on Guix that I don't even recall anymore.

However, that is not to say I abandoned Guix System. To the contrary, I've been running my server on it - a formidable cause, since the server has a mere 1Gb RAM and 20Gb hard disk space on the main disk. Guix is not really fit for these scarce resources, but it can work. (I did have disk corruption issues for a few months, possibly Guix-related, but it is hard to pinpoint the exact cause).

There's a lot of nice things you can say about Guix System: the guix deploy interface, for one, is absolutely brilliant. You configure the entire system on your local computer, and deploy it to the server. Almost all configuration is right there! It's quite awesome.

It's not magic - you still have data files on the system and there's all sorts of state that makes deploying the system something to do with care. For one, at least last time I tried, you have to take care to instantiate the SSL certs before you set up a http server for that URL - a classic mistake. That led me do make a "minimal-server.scm" that serves as some sort of a bootstrap that I deployed sometimes when I made radical changes - ultimately the better strategy is just commenting out some code sometimes.

Which, speaking of services, is still a great feature. Guix services are easy to write and easy to get a grasp of. I wrote a few services, with little involvement - you just write the program to execute, eventually add some config file, or extend the log-rotation service. It's worth it.

My review of Guix System, for these use cases, has to be positive. Using it on a server has little jank and is genuinely a great experience. My only negative experiences were unfortunately often caused by an uncooperative shepherd, which is not as reliable as systemd and had caused me some hardships in the past.

I had decent experience contributing to Guix - it was limited to some minor package updates or addition. The manual has a precise description of how to contribute, and it is fairly straightforward. I don't have a great grasp on the Guix internals despite all my time using it, but I do have some knowledge of how to write packages - you hardly get around without it.

Why? Sometimes, packages are broken and you have to go around it. It happens - there's tens of thousands of packages in the repo, and fixing a broken package is often unfortunately highly non-trivial. When such an event strikes, it's pure jank, but even with limited knowledge of Guix and Guile you can probably get around it.

That being said, it happened a few times to me, so it's a fairly rare situation, only affecting complex packages. (The most notable one was qBitTorrent, which was very annoyingly broken for a while. The simple workaround was just using an older version.)

The guix import tool is nice for the various situations when there is simply no package - it handles importing from a few classic sources. I mostly used it to import MELPA packages, which mostly works flawlessly.

Despite all the years of Guix, there's few "user" resources - and by that, I mean resources specifically made by the users of Guix. I hope this can change - I don't see non-technical users using Guix any time soon, of course, but casual users like me are adopting Guix on a decent scale. The project is progressing all the time, and most of the jank I describe is actively fought, with varying success - with a project like this, there's always going to be some jank (as there is on all software). It's definitely usable, and for many cases, quite optimal.