About two years ago I wrote an article on trying to use GNU Guix on a Thinkpad x230. By chance, the opportunity has arisen for me to try it out again and to compare what has changed.

To summarize my previous article: Guix the package manager worked well, but Guix the software distribution had too many rough edges for everyday use (at least to someone used to Debian stable).

My needs are mostly the same, with the exception that I have since purchased a Intel NUC that I use for most of my computing needs, and my Laptop is therefore less critical – it still needs to work when it should, and I don’t want to be messing with configuration files when I should be giving a presentation. But if an icon doesn’t render perfectly, it will be a lot less annoying than it was previously.

Installation

GNU Guix provides a TUI installer that is mostly straightforward. The only issue I experienced was that the installer “crashed” (?) while configuring the disks, without giving an error.

I solved this by overwriting the entire disk

$ dd if=/dev/zero of=/dev/sda

whereafter the rest worked as expected. It would be nice to have a more robust error check and indicate that something is wrong (I assume my issue was related to partitioning), instead of just restarting the installer.

Usage

The base operating system

Compared to it’s predecessors, the x230 is more locked down and I cannot just replace the WiFi radio with e.g. an Atheros chip that wouldn’t require the nonfree Intel drivers. My last attempt at fixing this resulted in damage to the frame, and I haven’t done anything more in this direction since.

The consequence is that I need regular Linux instead of the default Linux-libre, and the only Linux kernel distributed in the official package repository. To use this, I had to enable the “NonGuix” repository maintained outside of the Guix project. The instructions work, and after having to wait a while until the Guix daemon built a fresh kernel, I could restart with the necessary firmware and WiFi worked.

It might be interesting to investigate if I can make use of me having to rebuild the kernel, to trimming it better to my system using Guix (leaving out modules I don’t need and enabling what my hardware can make use of, perhaps optimising the compilation).

Sad but I understand that an operating system by the GNU project takes this position. The blame is on the hardware manufacturers, and I hope to one day be in a position where I don’t have to struggle with these issues.

The desktop interface

Initially I tried out XFCE, my default desktop environment. Guix distributes version 4.16, which I prefer but has the downside of using the more intensive GTK3 along with client side decoration for some of the setting apps. Not terrible by any means, but not my preference either.

I played around a bit and configured my usual setup (similar to the one in the screenshot from my last article). This is standard procedure for me and didn’t take long. What I would like to find out is if the premise of functional package management could make this step easier/more reproducible.

For the sake of it, I decided to try out LXQt too. This requires a quick switch from xfce-desktop-service-type to lxqt-desktop-service-type in /etc/config.scm, and after rebuilding and rebooting the system it worked as expected. It seems LXQt works slightly better and faster, so I decided to stick with it for now¹.

For the sake of completeness, I tried MATE and GNOME too. I had both good and bad experiences with both, depending on the distribution. Sadly in the case of Guix it there were too many issues or minor annoyances (mis-rendered icons and window borders, applications not starting (GNOME Terminal)).

Generally speaking LXQt is pretty nice, and I don’t feel like I am compromising anything by using the desktop environment.

Issues with SSH and related issues

Initially I had an issue with configuring the SSH agent to cache my key passphrase. It turns out this was easy to solve (following this article), by just creating this .xsession file in my home directory

#!/bin/sh
exec ssh-agent "$@"

and marking it as executable. GDM, the default display manager will silently fail if anything is done wrong. No error message is displayed so you have to guess what the issue is. To fix this issue you have to log in via a TTY and update the file using a terminal editor.

While trying to solve this issue I considered switching to SLiM, a more light-weight display manager, but due to a misconfiguration in /etc/config.scm (I changed a few things vi so the parentheses were not balanced), I wanted to revert the change and use the default GDM again.

After rebooting, I had to discover that GDM was not starting at all anymore. Not only that, I couldn’t access any TTY to inspect the issue either. After some research, I found a few bugs on the mailing list that indicated something along these lines can happened when switching back and forth between SLiM and GDM. The essence of the problem is that while re-configuring the system the UIDs for the gdm agent are not preserved, but the files in /var/run/gdm/ are. To fix this I had to reuse the installation image, start a live eshell session, mount my SSD and inspect /etc/passwd to find out what the current gdm IUD was and then update the file owner manually:

$ chown -R $(awk -F: '$1 == "gdm" { print $3 }' /etc/passwd) /var/*/gdm/

and it did actually work. Annoying behaviour for a reproducible system, nevertheless.

Trying out “Guix Home”

A feature was recently merged that allows the user to configure their local environment similarly to the entire system. This is called “Guix Home”². As implied above, this is interesting because it could allow me to declare and specify my preferred user space configuration (desktop, shell, programs, …) and summarise everything in one file. The usage is similar guix system, given a file home.scm I can run

$ guix home reconfigure home.scm

and a few after some symbolic link magic (which involves overwriting preexisting configuration files such as .profile, .bashrc (!), etc.) everything should be set up.

From what I understand Guix home is still in it’s infant stage, with a small number of programmes that can yet be configured via it’s interface.

An interesting one is only a few shepherd, Guix System’s init manager can be run both as PID 1 but also by the user when you want to manage user services. I have considered using this to manage Syncthing, but haven’t seriously experimented with this yet, because LXQt lets me easily list programmes to automatically start with the user session.

So regarding Guix home: I like the idea, but I will wait to see how it evolves before investing too much energy into it.

Conclusion

My last attempt at trying out Guix ended after a day or two while with this recommendation:

My tip for those engaged in Guix development would be not even primarily to increase the number of packages, but the work on their quality and interoperation.

I can certainly say with 1.3.x, this has improved a lot. While there are rough edges from time to time, I can live with them – because I have the necessary *nix experience to handle them! I don’t see this GNU system becoming a general replacement for Debian, Fedora or Ubuntu just yet. For me it has become a serious contender, and the fact that I haven’t overwritten the installation with Debian surprised me.

Guix is fun and I have to say that like using it. I get to tweak but I am not forced to³. My hope is that this will stay this way (or even improve) with coming updates.

My compliments to the Guix team on their advances, and my thanks to the people on #guix on Libera. In terms of software freedom, Guix is very interesting, because it has the potential to make these more concrete. If anyone had shared my previous experiences with Guix, I can recommend giving it another try.

Finally I can say that I would like to contribute to the project one day, when I have a more solid grasp of how it works.