Bye bye Guix, see you in 12 months

9 minute read Published: 2023-01-08

In this post I'll detail my attempt to install and play a little bit with Guix, how I failed to become friend with it and why.

A bit of context first (as usual, courtesy of Wikipedia): GNU Guix System (previously GuixSD) is a rolling release, free and open source Linux distribution built around the GNU Guix package manager. It enables a declarative operating system configuration and allows reliable system upgrades that can easily be rolled back.

Guix (the operating system) has a few peculiarities that will determine the user experience and expectations:

I am a strong believer in F/LOSS software and became interested in Guix after reading a few days ago about Guix 1.4.0 release, perfectly coincidental with a few days off from my duties.

§ First installation: good but don't walk out of the path

The installation process shows pretty soon the constraints imposed on Guix.

I've tried installing Guix on a virtual machine, the procedure went totally smooth, pretty much what am I used from the Debian installer (click, click, yes, click, finished). However, installing Guix on a recent Thinkpad might lead to this screen:

The Intel wireless AC9560 has no FOSS firmware so the installation didn't configure the network and basically blocked the process (packages cannot be downloaded) unless there other means to get a network to the PC.

The unofficial solution is to build your own Guix system starting from the nonguix version (supporting non-free drivers), prepare a ISO9660 image on a USB stick and install that. What is nonguix? It's basically a Guix shipping a kernel with non-free drivers. nonguix gives you instructions on how to build the installer with non-free drivers.

There are nonguix package sources but are hard to discover because the first rule of the Guix Club is do not talk about nonguix channels.

The least I can say is that all this dance and bad UX is sub-optimal and is a point where people can just ragequit trying Guix.

§ Don't know Scheme? Tough luck

I don't know Scheme, not even a "hello, world". When learning new things my usual approach is to quickly skim the documentation, start with the smallest possible task, brute-force things into making them work anyhow (included shameless copy-pasting stuff from various sources) and then backpedal to understand why they work. Iterate on this process while keeping the documentation by my side until I acquire the necessary knowledge I am comfortable with.

I failed to do this with Guix because:

  1. there are very few examples in the documentation and on the internet (few users == few examples)
  2. Scheme errors are obscure and difficult to debug and the toolling around the language is still somehow crude (example: I failed to find a good linter for my broken Scheme scripts)
  3. while the documentation is great and completely offline thanks to a detailed Info manual (HTML version), it's more a systems reference i.e. something that you consume after sitting down, breath in and breath out, learn a lot more than you need in that moment then go back to your problem with the acquired knowledge. But after jumping back and forth into the documentation I often forgot what I was looking for in the first place!

In order to learn the least possible amount of Scheme to use Guix you have to go through a learning phase and not haphazardly try things until they works. I like tutorials with simple, self-contained working examples to be used right off the bat as starting point.

There is a Scheme primer on the official Guix cookbook but it lacks quite some stuff that is needed to hack your Scheme files (example; it doesn't explain what these keywords mean: local-file, plain-file, computed-file, gexp, etc.).

Tutorials and Scheme primers that I bookmarked and plan to read and digest:

Christine Webber Lemmer deserves a special mention because she co-authored the ActivityPub protocol and created GNU MediaGoblin among other things.

§ Packages are hit and miss

Packages can only be installed by downloading them from channels (distribution servers with "recipes" that resolve dependencies) for a local build of the package or the so-called "substitutes", pre-packaged builds out of a CI. It's a very convenient way to have package reproducibility.

Though the situation improves over time, it does not have the same numbers of ArchLinux and some packages are not updated fast enough. Since packages cannot be installed outside of channels sometimes the user has to find other ways to install them: one option is using flatpak, the other is installing them in a container and emulate FHS in the container (guix shell --container --emulate-fhs). The FHS emulation however suffers from a blocker bug I filed (does not preserve env vars from the host to the container). The author of the patch introducing FHS emulation was very kind to quickly start working on it.

Still, because of this chain of complexities I cannot reliably install and run the latest Rust compiler (1.65) - the latest Guix package published is 1.60 (at the time of writing). Another often mentioned issue is building stuff that depends on JavaScript.

Both these workarounds to get a "classic" filesystem and be able to install stuff feel a bit like cheating, in my personal opinion: it's an admission that these guys are paddling against the winds.

However, I also need to point out that Guix shows how hard is to stubbornly wanting a complete system reproducibility when you try hard (files and directories in Guix have UNIX timestamp of 0 i.e. 1-1-1970). Why have some systems become so complex? How does this affect reliability? What are the consequences of our inability to produce two builds of something, bit by bit identical? I hear JavaScript developers laughing their asses off from afar.

§ Tiny community in its early stages

By watching some talks from the Guix Days 2022 conference (February 2022), one get the idea that the few people on Guix are working at capacity, issues and patches are not followed up fast enough.

I've sent two emails on Dec, 30th, one with a tiny patch (to test the waters) and one with a question: my emails appeared on the mailing list 4 days later (on Jan, 2th); at first I assumed there is a human approving emails on these mailing list and this human rightfully took a few days off around New Year's Eve but when asking on IRC (#guix) people were equally puzzled. The patch was merged on Jan, 3th (the maintainer provided useful tips to improve my contribution).

The issue tracker is weird. Every patch sent to automatically opens a ticket on the issue tracker. Again, not a problem per se but I usually send a cover letter with my patches with some verbiage explaining why I've sent an unsolicited patch. This process creates two emails and therefore two tickets on the issue tracker. I could not close the ticket created by the cover letter.

Delayed replies on IRC during Christmas / New Year's Eve festivities are totally fair but that suggests a small community. The technical delays on the mailing list and the issue tracker are instead something that can be detrimental to the experience of new contributors.

§ So, why learning Guix?

Lack of a concrete use-case. I use Ansible and can already provision servers and even my laptop with that. I am looking for a better Ansible because I don't like writing YAML configuration files.

So, I don't really need Guix, I just want to explore how it feels using it, I am fascinated by Guile. Also, I use a pure Wayland desktop (with no xwayland emulation): can I have the same on Guix?

§ Conclusions

This article is unbalanced towards what did not work because I could not get a glimpse of the good parts. I'm fine with learning a bit of a lisp-y language but I need a better UX. I'm sure my understanding of Guix is still spotty and I got some things wrong - the Guix system is not immediate and familiar when coming from other classic Linux distros.

I perfectly understand that the Guix project is making progress thanks to a handful of heroes (git statistics report about 50% of the commits contributed by 6 authors), they have all my respect and I applaud their efforts, the blog posts explaining the philosophy behind Guix are really interesting.

I'm also fine with the imposed restrictions due to licensing: having some Linux distributions stubbornly refusing non-free software and hardware is important because it reminds us how the lack of FOSS drivers / firmware is crippling the ecosystem. Debian, however, provides unofficial installation ISO images that work on any hardware. Would Guix also evaluate that in the future?

However, the current state of the project at this time is just not ready enough for me, therefore bye bye Guix, see you in 12 months: I will be happy to write a follow-up to this article.