My Experience with GNU Guix

Introduction to Guix

Guix (pronounced “geeks”) is a GNU/Linux package manager aimed largely at reproducibility. Like the “cousin” project Nix, Guix aims to achieve this goal by having the state of the computer system defined as Guile Scheme code. The package manager can be trivially installed alongside most mainstream Linux distributions, where it can work alongside the native one. Guix also has a standalone distribution, Guix SD, which builds on the concept to include a init system (shepherd, also in Guile) and service configuration based on the same Guile code.

I was mesmerized - you can have your entire OS, from your users to your sshd configuration to your packages that are installed specifically for your user, all defined in Scheme. After doing some reading and hyping myself up, I grabbed a flash drive and my Thinkpad T480 and got to work. Pretty soon, I had a functioning Guix System up and running. And that’s when the issues started, culminating in me frustratingly reinstalling Arch Linux in bed next to my sleeping girlfriend after a couple of weeks of use.

My struggles with Guix

Non-Free Software

To start off, I primarily use Free and Open Source Software throughout my day, including at work. I think it’s great to have the ability to dig into source code to fix an issue, or to hack on the software that your computer runs. It’s my opinion that if you can’t do this, the computer only partially belongs to you. The unfortunate other side of free software is that there isn’t a lot of money in things being free. Every so often, you may be forced to use software that is proprietary, simply because it’s better than free alternatives, and that’s the truth of it.

Since GNU Guix is an official GNU product, Guix’s channels (jargon for repository) only supports free software. As such, the default kernel is linux-libre. Additionally, discussion of non-free software is prohibited in official GNU Guix IRC channels and mailing lists.

Where am I going with this? Well, a historic issue of running Linux on laptops is lack of Wifi drivers, and this tradition continues on with linux-libre. The Guix solution is to install a new channel containing the mainline linux kernel. This is fine, but without wifi it was a bit of a pain to carry out. My T480 has an ethernet port, but I would have had a much worse time if I was using my T14s, as the latter lacks the wired connectivity.

To be fair, I think this is a pretty minor point and I might be grasping at straws, but it’s not a great experience to have something like Wifi not work out of the box.

Package Availability

Since Guix has a relatively small community compared to Arch, it goes without saying that the channels are not going to be as well stocked as Arch’s package repositories.

Furthermore, the documentation is more of a reference than a guide at times. An example I had recently was attempting to install a program I had written in common lisp. Relevant documentation to install something with the asdf build system did say what was needed, but there wasn’t any direct examples on how to implement this, and I ended up having to use the package definition for stumpwm as an example.

The Cool Stuff

Contribution opportunities are everywhere

As someone interested in FOSS, I’ve always wanted to be able to meaningfully contribute to large projects. I think Guix is in that sweet spot of where it has most of what a user would need, but not everything, leaving room for contributions. Once I become more familiar with the Guix ecosystem and idioms, I think it’d be a great community to work with and to help grow.

Safety in your system

Having your entire OS defined as code is great - as a DevOps Engineer, the value of “Configuration as code” is pretty much always in my face. If something catastrophic ever happens to your system (and you already have filesystem backups), you can just roll back to the last working version of the Guix system, or you can deploy a whole new install all together, and it will be close enough to where you left off at.

Miscellaneous neat features

  • Guix supports building OCI containers containing a list of packages.
    • I haven’t done any specific testing against a Dockerfile written by hand, but this might be a great path to reproducible docker builds.
  • Guix supports isolated development environments with whichever packages you’d need
  • Software Builds can be offloaded to an external server.
    • Need to compile Firefox? Want to do it fast? Why not deploy a server in AWS with 32 cores, and tear it down after the packages are transferred back?
    • Use a homelab? Why not have your builds there, and create easy LAN-local packages?

My Future with GNU Guix

I uninstalled the GNU Guix System after using it for a few weeks. In my hubris, I thought that I could learn everything I needed to on the fly. Evidently this was incorrect, but I’m happy to say that I didn’t entirely give up. I’ve decided to take on a roadmap for deepening myself into Guix:

  1. Install Guix as a package manager on all the hardware that I typically use
  2. Get familiar with the basic workflows, and don’t feel shame in reverting to distribution-native package management as needed
  3. Migrate installed packages to Guix managed packages
  4. Install GuixSD back onto my T480, with an image built from the guix system command
  5. Once comfortable, perform the same on my Desktop and Homelab.

We’ll see where that plan takes me. I expect it to take at least 6 months, but I guess I’ll see how it goes!

If you’re interested, I’d encourage you to check out Guix - it’s a great piece of engineering, and I think it’ll help me create a computer system that I enjoy using.