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!
Banning of discussion of alternative apps is too dystopian for me. Pass.
I’ve been researching Chez (a variation on Guile) and I think this is better choice than Guile. Here are eight advantages of Chez compared to Guile: Chez is much faster than Guile Chez is cross platform Chez is rock-solid, in terms of not having bugs The only Scheme compiler to produce executables directly, without first compiling to C compiled with a nano-pass compiler Chez has true posix threads https://groups.google.com/g/racket-dev/c/2BV3ElyfF8Y/m/4RSd3XbECAAJ “As expected, Chez runs the matcher about 2 times as fast as Racket, putting it generally on par with the C implementation that’s currently built into Racket.” https://news.ycombinator.com/item?id=21305570 “The other lesson… Read more »
I’ll take your word for it (about Chez), though your comment 8 at least isn’t quite correct. Guix has binary substitutes available, or you can create your own of course. But 99%+ of that time compiling is the same you would do for any source distribution, compiling programs, the kernel, etc. The actual Guile/Guix part is very small (and also can be binary substituted). Anyway, Chez sounds interesting, but is there any distro built around it from bottom to top?
If you read the article on HN you will see that he says the following: Compiling guile from scratch was, by the way, insanely slow, and because I struggled to get Guix working right on my first try, I had to compile it over and over again, which took about a day each time. What I would like to make clear is that compiling Chez Scheme from scratch is perhaps the fastest process of all the programming languages that currently exist. When I read the article, it seems that there are really many things built in Guile, or adaptable via… Read more »
I don’t doubt you that Chez might be faster, but again, that is not really a limiting factor here. If you were building everything from scratch (I bet the vast majority of users don’t), then you’ll still be waiting a long time for the other big pieces on such a machine: GCC, llvm, the kernel, big desktop programs, crypto/security stuff, and so on. The comment is also nearly 3 years old and doesn’t specify much that is helpful. If they were on, say, riscv or a low powered arm system, that is unfortunately how it is and why binary substitutes… Read more »
I will pass on my proposal to the developers. For example, Testing equal takes exactly 0m0.734s at Chez and it takes 4m59.999s at Guile. Which means Guile is about 400 times slower there. Guile is really not a suitable programming language for programming parts of an operating system. I’m sure users are going to save time if they were to switch. What I regret is that none of the Guix users published benchmarks of their system in games or applications compared to other operating systems such as Clear Linux, Arch or Fedora. It could well be that Guix only gives… Read more »
I doubt you’ll notice a difference in things like benchmarks, compilation, games, etc. unless you are looking at system operations (that actually use the guix binary). I don’t have numbers off hand, but when I ran some Phoronix benchmarks, I was right in line with other users with the same hardware. Likewise with games. But of course some set of benchmarks to compare distros would be interesting, I just doubt you’ll see a difference in anything that really depends on hardware over some system daemon.
You would expect that there would be no major differences between distros but that is not always the case: https://www.phoronix.com/scan.php?page=article&item=clear-steam-linux&num=1 At BioShock Infinite at 1080p and low quality settings, Clear Linux is 49% faster than Ubuntu. That’s no small difference.. Recent results suggest that Clear Linux may still be significantly faster for gaming than other distros: https://www.phoronix.com/scan.php?page=article&item=h1-2022-linux&num=8
Sure, but that is something very different than what language the distro is built with: Clear uses different compilers, configuration flags, patches, etc. to achieve that. It has nothing to do with what language the package manager is written in. So yes, there can be differences in distros, but that really comes down to what drivers, kernel, configurations, etc. Another comparison would be to use the exact same kernels, binaries, and so on, which would (should) not show any real differences. That’s my guess, but really it couldn’t be another way based on how things work.
I believe the Clear Linux optimizations are extensive and have proved difficult for other distributions to copy (or they all would have by now). If Guile is also used for system services, then it may well have an impact on gaming performance. I don’t know if this is correct, but Guile is used for the init system and for the package manager. As far as I know, both are slow because of this: 1. https://www.reddit.com/r/GUIX/comments/hxcq7d/comment/fznp65i/?utm_source=share&utm_medium=web2x&context=3 2. https://distrowatch.com/weekly.php?issue=20190624#guixsd
I prefer Pure OS or Trisquel for my FSDG distros. I liked the install process for GUIX but found it too terminal focussed for my liking. Why would you setup a nice FSDG distro to just pollute it with closed source software like Steam though ?
In short, I use the freedoms of the FSDG to install what I want and am well aware of what’s non-free. I applaud efforts to use as much free software as possible (and I do my best outside of Steam/games). Unfortunately the reality is that it is (probably) impossible to live a life with technology that all fit the FSDG. Best, I would say, to know exactly where that is and make your own decision. (More on that front coming from me soon.)
I don’t agree that it’s impossible, just annoying – provided you plan your purchases with this goal in mind. Some people don’t take this important step and then give up since they’ve boxed themselves into a situation where they have little choice. For me, all the proprietary software I have is the odd game (Wine or native) + launcher (Steam, UPlay, etc.) + Flatpak app (Slack, Discord – mostly free software for the local apps all still proprietary SaaS products at the backend), all containerised and restricted (Steam runs under firejail). Plus microcode for amdgpu. Slack could run in the… Read more »
Yup, I agree! By “impossible” I mean if you want to take this to the logical end (extreme?): what about the hardware and software in all the other electronics you use? or what was used to produce other products: closed source CAD that was used in furniture design, produced with proprietary hardware, and so on and so on. That’s what I mean by “impossible,” even if that’s not our day-to-day meaning for only using free software, at some point, we’ve assumed a line beyond which we don’t look or care. But that “ideal” is worth keeping in mind as we… Read more »
I love the way Guix does containers. I was looking at Guix back when Docker was just getting started, and I felt that the way Guix handled them was far superior to the Docker offering – being more efficient in terms of disk space used, memory used (fewer files to cache), the ability to create containers “instantly” just by creating some symlinks to exiting files, etc. It’s simply mind blowing. Docker is only winning because it has better tooling (networking options, command line options, clustering, etc.), marketing and lower barrier to entry (and containers don’t seem to be the main… Read more »
Interesting. Have seen ’em working in the shed on GUIX but haven’t stopped in for a chat. That Gnu is one beast. Good write up. THX.
you should quote “$HOME” in your cmd quoting, proper shell usage
ill definately try guix somewhen, first other os than win or debian since y2k
I should quote “$HOME” when I say Guix is my “forever $HOME”??? 😛 I was gonna say that alas that is not a command, but apparently if you want Node.js applications to run forever it is. Definitely not my intention!
Why waste time with a short-lived distro? For professional engineers there are only two real viable options: RHEL and Debian. Both have been around forever are well supported and will continue to be around for some time to come. The only issue is whether or not you want to pay for support. Don’t waste precious time and resources learning some esoteric configuration. The goal of all of this should be to “get sh1t down”.
Podiki explained in details how Guix is superior in many ways to the way of working of other distros – with a secure core, proper updating process that prevent breakage, some amount of reproducibility of packages, and configurations you can recreate with a single line. You get none of that with the “professional” distros. This is bleeding edge design.
Es un troll, porque semejante comentario es una pérdida de tiempo… ( seguro ni terminó el tercer párrafo o tiene incapacidad para procesar lo que lee).
Saludos
I’m not a professional engineer, nor do I want to be. This is my hobby and something I do for fun 🙂 , and I certainly hope we don’t only have things just for “professionals” (though Guix is used professionally in things like scientific research, which is closest to what I have done, so I guess I’m in the right place after all).
I hope your journey is not over yet. 😉 NixOS was the final destination for me 🙂
For those who are not familiar, Guix is only 64% reproducible (1) in x86_64-linux whereas NixOS is 100% reproducible (2). It was a monumental work to get here!
1: https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/package-reproducibility
2. https://r13y.com/
As I wrote, I love Lisp and the land of parens, so Nix is decidedly less exciting just on that front. They have led the way in very exciting directions that Guix has picked up, so I definitely appreciate what Nix has done.
By the way, I don’t think those links show the same thing. The one for Guix is for all of its packages, while the Nix is for the minimal iso (not sure how to compare those).
NixOS is not 100% reproducible.
First, [2] is about iso_minimal, i.e., a tiny subset of NixOS; whereas [1] is about entire Guix. Therefore, the comparison is apple to orange. I do not know what is the reproducibility ratio of Guix about its minimal iso; probably not 100% though.
Second, some Nix packages do not build; especially the ones coming from massive CRAN import. So NixOS cannot be 100% reproducible. 😉
Fantastic read ! It seems like the future ! Well, I won’t test it myself until it’s mainstream (like in “Ark is mainstream” 😀 ) but really interesting to discover out-of-the-box features provided by this new distro.
Cool write up. I have to check it out now.