I wrote recently about building my new gaming desktop where, if you weren’t blinded by all the lights, I also noted that I’ve moved from Arch to GNU Guix as my distro of choice. Why? And what is Guix? (And no, it is just coincidental that Valve is going all-in with Arch on the Deck.)

While I’ll get to details on both below, perhaps the simplest answer to “why” is because I just like tinkering. As I’ve written before, that’s very much at the heart of why I love to use Linux and can’t seem to just let a computer be without messing with it in some way. There’s plenty of good reasons why I think this is valuable (from learning to openness), but perhaps foremost it is fun.

So let me lead with this: Guix, for me, is the most fun I’ve had in Linux in a long time. There are some clear epochs in my Linux life, like being on the bleeding edge as 64-bit went mainstream, compiling kernels (and everything else) on Gentoo, to more recently VFIO and then Proton. Distros in my life have mostly gone from Debian to Gentoo to Arch, to what I think is now my “forever $HOME”: GNU Guix. I’ve always wanted to see what the latest and greatest is: Guix is new and different in a way that truly moves the Linux scene forward.

What is GNU Guix?

Let’s start with Guix (pronounced like “geeks” according to the manual; I prefer “gu-wiks” because I’m silly) in its own words, from the About page:

The GNU Guix package and system manager is a free software project developed by volunteers around the world under the umbrella of the GNU Project.

Guix System is an advanced distribution of the GNU operating system. It uses the Linux-libre kernel, and support for the Hurd is being worked on. As a GNU distribution, it is committed to respecting and enhancing the freedom of its users. As such, it adheres to the GNU Free System Distribution Guidelines.

GNU Guix provides state-of-the-art package management features such as transactional upgrades and roll-backs, reproducible build environments, unprivileged package management, and per-user profiles. It uses low-level mechanisms from the Nix package manager, but packages are defined as native Guile modules, using extensions to the Scheme language—which makes it nicely hackable.

Guix takes that a step further by additionally supporting stateless, reproducible operating system configurations. This time the whole system is hackable in Scheme, from the initial RAM disk to the initialization system, and to the system services.

In short, GNU Guix is both a package manager you can use in any distro and a full-fledged GNU/Linux distribution, that is modern and advanced (see features below; formerly called “GuixSD”). It is built with and customized with the Guile (GNU’s Ubiquitous Intelligent Language for Extensions) programming language from the bottom up for a unified system. That also means there’s no systemd but instead GNU Shepherd to manage system services, also written in Guile.

So you can try out Guix right now as a separate package manager that won’t interfere with whatever you use on your distro. This is called running Guix on a “foreign distro.” Everything Guix does will live in /gnu/store and won’t interfere at all with the host distribution. You get the benefits of Guix package management and most things Guix can do, other than managing the system configuration and services itself. That means you can have some very different versions of say python and python packages, without touching what happens on the host. I have Guix on top of Arch on my laptop for some testing or running some programs as a “one-shot” of sorts: Guix installs the program temporarily to run something and then cleans it up after you exit, nothing left. Here are the instructions from the manual (or, of course, the Arch wiki). Guix as a package manager is used similarly to any other you may be familiar with, like guix install <package> or guix pull to get the latest package definitions.

A perhaps better known package manager/distro that works in basically the same way is Nix. In fact, Guix was originally based off of Nix, but very little of that remains. There are many similarities between the two, though I don’t have any experience with Nix to comment further here.

One important aspect of Guix is that it follows the Free System Distribution Guidelines (GNU FSDG) and runs on the Linux-libre kernel. As I noted in my recent article about building my new computer (and will go into again later), this means that everything included must be free software (as in freedom). There can be no closed source binaries or proprietary firmware, or anything that isn’t suitably licensed.

Guix is a source-based distribution, but has binary (precompiled) substitutes available. In practice that means you have the option of only downloading prebuilt software and not compiling it on your own (though you may need to wait after updates for the build farm to build everything). Furthermore, with the emphasis on reproducible builds (more below) you can verify that what you receive is the same as you build locally.

A brief description of how Guix works will give a sense of how Guix is very different from your standard distro, as well as what that can bring as tangible benefits. Guix foregoes the usual Filesystem Hierarchy Standard (FHS) (think /lib, /usr, etc.) for a sea of symbolic and hard links. This allows mixing versions, roll-backs, and other features just by changing links.

The above diagram shows how a Guix profile (what you have installed) and filesystem is built up, in this case for the /bin directory. Your user ~/.guix-profile is a symlink to a particular profile, where both older and newer ones may be available. In this case profile 42 has both bowtie2 and samtools installed, while profile 43 has removed bowtie2. However, the program still exists as another profile uses it, until all profiles that use it are deleted, allowing it to be garbage collected. You can see with multiple profiles using the same program it is not stored multiple times (it is deduplicated). To undo the removal of bowtie2 it is as simple as changing the profile to point back to the previous one, doing a roll-back. This set of symlinks is how bin is built up, rather than something like /usr/bin being a giant folder everything installs into. Also, only the bin folder of what you wanted will be added, any intermediate binaries (from dependencies) typically aren’t included, keeping it cleaner and only what you requested. (The program can access dependencies in the store to run, without polluting your user environment.)

This link structure leads to isolation between different programs and profiles, while still benefiting from deduplication. Everything is installed into the “store” which is only written to by the Guix daemon. Programs will only see their dependencies, for instance, allowing normally conflicting versions or libraries to be simultaneously used. There is a hash before each package name in the store, uniquely specifying how it was built (dependencies, build tools, and so on). Nothing else can write to the store so you are assured it can be entirely reproduced by Guix; all you have to worry about is your home directory.

Guix is sort of a hybrid between a full rolling and standard release cycle distribution. Generally whenever a package is updated it is available immediately (as soon as someone updates the package on Guix), with the exception of packages that would require many other packages to be rebuilt with the new version (e.g. polkit, gtk+, Mesa). These packages are often batched together with other large changes to how Guix works and come out as a new Guix version. Of course, you can easily make your own Guix channel with these updates (and build them locally). When running on the main package branch (other branches are for work in progress) of Guix I’ve rarely seen a major package breakage or problem caused by Guix, and response time is quick for fixes. A build farm for all the packages is also a check that everything continues to at least build properly.

(Advanced side note: as a functional package manager, dependencies for building come in as inputs. Meaning if you change a package you need to rebuild everything that depends on it. However, Guix has a very cool technology called grafts that can just substitute a reference to the newer package in whatever depends on it, rather than fully building it again. This allows for timely security updates and for sometimes updating packages without causing huge rebuilds.)

Finally, as you may have guessed from the name, Guix is a GNU project. There are currently five core maintainers, but many others contributing small and large changes. And that includes me, with a handful of commits updating and fixing some packages! In particular, I helped get Mesa updated after it languished a bit and updated and fixed Flatpak.

And what’s so great about it?

Guix is an advanced operating system. While you may be able to get some of these features through other tools, like Docker, filesystem snapshots, etc., they are not part of the core OS design and functionality.

One immediate feature you’ll notice about Guix is that you don’t need root permissions to install or remove packages, only for system configuration. In other words, only for say updating the kernel, changing system services, adding users, or changing the boot configuration. These days I so rarely use sudo (or reboot) that I almost forgot my password!

Other stand out features are easy development environments or isolated containers (like Docker, or even exporting a full Docker image), mixed versions of programs (different profiles or users can use different versions of the same program), transactional upgrades (either succeeds or does nothing), partial upgrades (just upgrade a program individually), roll backs to previous profiles for packages, easy package transformations, package importers to make adding new packages easy, tools to quickly update a package definition, and more.

What are package transformations? Package transformations let you easily and quickly change how a package is built. You can try out a new or previous version, different git branch, add patches, and more. For example, I’ve used this to install a newer version of something for testing and until my patch makes it into Guix and to use the experimental branch of picom. While editing a PKGBUILD on Arch, for example, is also not difficult, Guix lets you do this with the same command you use to install something. Even better, this transformation is stored so you can replicate this same transformation on another machine or to persist with upgrades.

The system configuration is also all defined in a single file (in Guile, of course). Running Guix’s system configuration with this file produces your system, from boot device to filesystems, users, and everything else. Just like package profiles, system configurations can be rolled back, which will also show up on Grub’s boot screen (never fear kernel upgrades!). The configuration is stateless, meaning everything is generated by Guix from your configuration file; you could replicate your setup on another computer or virtual machine with one line. No more random configuration files in /etc or worrying about what part of an upgrade changed how your system works. This also makes it possible to deploy an identical system to multiple computers, using guix deploy.

Reproducibility is a core theme for Guix. Not just reproducing what a user configures, but the entire process of building packages and the core system is aiming to be reproducible. There’s much to say about why this is important, from preservation to security, and the challenges in this space, so do take a look at reproducible-builds.org for more. While bit-for-bit reproducible packages are not possible for all programs, Guix is one of the few distros to focus on this area and provide tools directly to the user to check anything built or installed, just a guix check <package>. Once you have something that works, you can be assured you can always go back to it and reproduce that state at another time or machine (yes, the command is called guix time-machine).

Part of the joy of Guix for me is that it is all built on Guile, starting from the RAM disk on up. This means there is one language to hack on your system, from how you configure it to changing internals to making packages. As a big fan of Lisp family languages, this is a huge benefit to me. I find the language very readable and powerful, great for building a system. This has made it very easy for me (with Common Lisp experience especially) to make my own packages and work on Guix itself.

Last but not least, is the Guix community. From the mailing lists to IRC, it is very active while being welcoming for newcomers and friendly to work with. At this point I’ve spent countless hours lurking and discussing on IRC, getting lots of help to learn Guix and contribute back. While Guix could certainly use more people working on it, I’m enjoying the size of the community where it is easy to get involved but there are long-time experts from the very beginning of Guix there to help.

What’s not so great?

Nothing is perfect; there are trade-offs with any system. Since Guix is different from most other distros in how it operates, that can entail running into issues with how programs may expect to interact with the system (like expecting FHS or hard coding expected paths to tools), or in packaging something from source (ideally in a bit-for-bit reproducible way).

That means some packages are currently missing, the biggest gap being in the JavaScript space, like Electron applications. Apparently trying to truly package JavaScript applications from source (rather than prebuilt or minified) is rather dystopian. For these programs, or many other things where packages aren’t forthcoming, there’s always other tools, like Flatpak, or even using Nix on top of Guix (Nix has a ton of packages, but on JavaScript just downloads the prebuilt package).

Guix is still pretty new (the first alpha was released in 2013) and with a different paradigm than most other systems, there’s a lot to learn and get used to as a user. While I find this to be refreshing and enjoy this process, it can be a new hill to climb when your old ways of doing things may not apply.

There are also some rough edges in this still-growing project. Backtraces from Guile often are a bit cryptic for debugging, shepherd is still rather limited compared to systemd in areas like logging, and package updates can vary between immediate on new upstream releases to languishing. The development ecosystem is done through mailing lists and patches, which certainly has advantages, but is likely less familiar for newer developers used to the GitHub/Lab pull request model. The documentation and cookbook are generally detailed and helpful, but there isn’t any resource for Guix on par with the amazing Arch Wiki (there’s a nice reference card, though).

On the other hand, much of this is mitigated by learning some Guile and the active and helpful community (both on the mailing lists and IRC). Built-in features like package transformations, the ability to use custom channels for more packages, a very hackable code base (just git clone Guix and you have the entire system and package definitions to modify at will), and a willingness to learn and experiment offset a lot of these rough spots to me.

What if GNU is not enough?

Before delving into the non-GNU world in relation to Guix, we should all appreciate the strong stance GNU and the FSDG take in regards to freedom. The insistence of user’s rights to use software and hardware as they like is something I strongly value as well. We’ve certainly come a long way with regards to hardware support on Linux, but we still have a long way to go, especially when it comes to hardware like GPUs.

To respect these principles the Guix project (and others) asks to not discuss non-free software, hardware support, or related matters on official channels. These questions and non-free packages are best left to any number of other venues. Guix does not actively hamper a user’s ability to load non-free software or firmware (see freedom 0), but will not support this in any official capacity. That said, the community is very nice and will not kick you from IRC if it comes up (more likely you’ll get some private messages directing you or helping you out), but better to remember their rules.

Alas, principles and reality often collide, leaving you with a choice. Unfortunately, for many gamers this will mean choosing between these freedoms of doing what you want and the principles of libre software. There are, of course, many games that can be enjoyed with open drivers and hardware that are open source themselves, but unfortunately that is the minority of offerings out there.

As I discussed in my desktop build article, the FSDG forbids loading binary blobs or firmware that is often needed for (some) Wi-Fi and modern GPUs. GNU Guix uses the Linux-libre kernel, which doesn’t include these non-free bits and will not load them if otherwise provided to the kernel.

In my case, I didn’t run into any problems other than not getting full functionality of my AMD 6700 XT (I could boot and still get a lower resolution display at least). For that and other hardware needs, there is the full Linux kernel available through the Nonguix project. Nonguix also has packages for the full Firefox browser (Guix has Icecat, an entirely free software version) and Steam. Note that this package of Steam currently doesn’t support Proton version 5.13 or newer due to sandboxing issues. However, I do think this will be sorted out in the near future. In the meantime, Flatpak Steam works perfectly well.

Gaming on Guix

I’ll dive more into the specifics of how I use Guix and my experiences in a part two, but for now, how is it to use GNU Guix as a gaming OS? The big caveats are above, in needing to go to Nonguix for full hardware support and using Flatpak for Steam. That is simple enough to set up and works as well as anything else I’ve done (and this is my first experience with Flatpak). I have my VR and Steam gaming just as before on Arch. Overall then, GNU Guix can work as well as other setups. There are also some Guix gaming channels to provide game specific packages.

But does it gain you anything for gaming specifically? I think it does. Having reliability in knowing you can always roll back your system or package configuration means you have to go out of your way to really break something. Mixing versions means you can stay on certain versions for packages and do a partial upgrade. Nonguix’s Steam runs in an isolated environment as well, so you can better control dependencies if needed (perhaps somewhat moot as Steam has its own runtime now). Add in containers and isolation, and Guix would work well to preserve and reproduce game setups.

I find Guix a better OS all-around with its advanced features; the learning curve of a new kind of distro and the hacking needed is a bonus for me. For just anyone looking to game on Linux it may not be the easiest to set up yet, but that’s not what I’m looking for exactly. I do think it is a bright future for Linux with Guix helping lead the way.

Why GNU Guix is the one for me

Am I in love? Maybe a little obsessed? Have I forgotten for months to run pacman or yay on my Arch machines?

Yes. Definitely. And yes again (sorry, Arch).

My love for Lisp has been going strong for several years now, and I look for just about any excuse to use it. So when my brother briefly mentioned Guix (as a Nix-like but built on Guile Scheme), I knew I had to try it. Add to that its advanced features, declarative system configuration, and ease of hacking, and I was quickly hooked.

While waiting to put together my new desktop build, I spent some time learning a bit about Guix and trying it out to see if it could at least cover my basics. It did, and the work it required from me was fun, leading to me getting involved with the project itself (albeit with some minor contributions so far). I frequently check in on the IRC channel, browse recent issues, and look at the mailing lists.

This was also a huge plus, finding a project with free software and reproducibility goals that I support and could help shape both on my own machine and for the larger project. GNU/Linux has become an essential part of my life (I live in Emacs, after all), and I enjoy supporting GNU to help give back all that its free software has given me.

So that’s the basics of GNU Guix and why it has become my distro. You can expect more on Guix from me, starting with Part 2 on my Guix setup and some tips on using Guix for your system. And in my previous article on building the new computer, I discussed a bit of what it was like getting started with Guix, which I’ll expand on in the upcoming piece. Stay tuned!