NixOS 22.11 'Raccoon': Like a proof of concept you can do things with

Another Linux OS – but this time it's all about the software packaging

NixOS is a distro built with a new sort of software build tool. You can install it and it works, but oddly that isn't really the point.

This is not a conventional Linux distribution, and so this is not a conventional distro review. We know that one of the most irritating types of statement is "if you have to ask, then you won't understand." Attempting to understand Nix and NixOS, as an outsider, are a little bit like that: the virtues and benefits that its website and wiki talk about, or even early coverage, for instance here on Linux.com, are rather theoretical. There appears to be little overlap between the sort of things that the Nix community seems to consider important, and things an ordinary desktop OS user might consider important, that it is hard to bridge the gap.

Here at The Reg FOSS desk, we've been meaning to take a look at NixOS ever since the second part of our feature on Linux software packaging, which followed on from our story about containerized packaging. Well, a window of opportunity became available, so we downloaded it and installed it, and it works, with some major caveats. Oddly, though, this may not be the point.

The NixOS live install medium comes in GNOME and KDE Plasma flavors, but you can install whichever desktop you prefer

NixOS is a Linux distribution built with the Nix packaging system. A new version of the OS, NixOS 22.11 "Raccoon", was released at the start of this month. It supports x86-64 and AArch64 computers, and its packages can also be used on other Linux distros and macOS running on those architectures.

One of the key points here is that the Nix packaging system is what is important; NixOS itself is almost a proof of concept. The top three advantages listed on its website – reproducible builds, declarative configuration, and reliable installation – are properties of the packaging system, not of the distro itself. Normal Linux distro considerations such as ease of installation or user-friendliness or hardware support don't feature at all.

This makes it a little hard to review because the questions that reviewers concern themselves with don't apply. So let's get them out of the way: it's a Linux OS. It will run on things that Linux runs on, and it won't run on things Linux won't run on. It will do things any other Linux will do, and it won't do things Linux won't do. You can choose the desktop you want, and it will run that desktop. This release includes GNOME, KDE Plasma, Xfce, Pantheon, Cinnamon, MATE, Enlightenment, and LXQt. The project offers preconfigured download images with GNOME and KDE Plasma, for 64-bit Arm and x86, as well as a minimal installation image that has no GUI. We tried the GNOME image, and it booted into GNOME without issues, from which we were able to install an Xfce system and it worked perfectly.

Part of the problem is that, judging by its quite active subreddit, the sort of issues that the Nix community care about are different questions to those around many distros. This is not unique: for example, Gentoo users care passionately about things most users are barely even aware of, such as compiler flags and code optimization settings.

Nix is about specifying and building sets of software, reproducibly. You write a configuration file, and the Nix tools will work out how to build that, and then do it, and the result will be exactly the same, every time: in other words, builds are reproducible. The NixOS project is involved with the Reproducible Builds organization, which is backed by the Software Freedom Conservancy.

The core issue here is guaranteeing that if you take the same source code, and built it with the same settings, you will get exactly the same result. Unlike Gentoo, most Linux distros are based around binaries: they build the software, and users install it. There's only one Ubuntu and for the most part, its various remixes take those binaries and put them together to make installation media that you can install. If you choose to use Ubuntu, you are choosing to trust Canonical, which is what its founder meant in his famous "we have root" blog post, which resulted in considerable controversy at the time.

The situation for some other distros, like rebuilds of RHEL such as Rocky and Alma Linux, is different, and for them, reproducible builds matter. If you are using such a distro, it's probably because it's guaranteed to be compatible with the rather expensive paid-for upstream, so you care that the binaries in RockyLinux really are identical to those in RHEL. That way, if something works with RHEL, such as a particular piece of exotic hardware, you can be sure it will also work with AlmaLinux or Rocky Linux. This renders questions of compatibility somewhat moot: you don't care if it's compatible with a particular model and configuration of server. If that server is certified compatible with RHEL, then you care that the other distro is compatible with RHEL, because that means it will be compatible with the server.

To put it another way: if you download Google Chrome from Google, that means that you must trust Google, because you can't build Chrome yourself. If as a result you chose the Chromium browser instead, which is open source, you might want a particular set of configuration files to build a binary of Chromium from the public source code, and know that you will get an identical result. So that, to give a hypothetical example, means all your sites around the world can build their own copies, and you won't be dependent on building it in one place and then distributing it yourself to all your branches. Since there are about 35 million lines of code in Chromium, that's a significant undertaking. There are, literally and figuratively, a lot of variables.

Of course, one specific build of one specific version of Chromium is just one relatively small part of a whole Linux distro. Building the whole OS is much much more complicated: you need the browser, and all the tools to build the browser, and all the tools to build its code in its 18 constituent programming languages, and the various libraries the result needs to run, and that the build tools need to run.

It's very complicated. Which is, in part, why tools like VMware's SaltStack and Red Hat's Ansible exist: to automate installing and configuring machines. You write a configuration file, point the software at some machines, and the tool does the installation and configuration for you. The author briefly worked for Red Hat nearly a decade ago, and personally knows some past and present Red Hatters who maintain their own Ansible "playbooks" to automate the process of setting up their own personal laptops.

Nix moves solving this problem further down the software construction stack. Rather than one organization building and packaging binaries, with various toolchains, and then other tools installing and configuring that software, the Nix tools let you specify what you want the end result to be, in a custom programming language also called Nix, and the Nix tools make that happen for you. If the end result isn't what you wanted, or it doesn't work quite right, Nix can roll back the changes, undoing everything and putting the whole OS back to where it was.

That is something that conventional package managers such as DNF or APT cannot do, which is why the SUSE family of distributions use Btrfs snapshots to provide comparable functionality. This next-gen functionality is why SUSE is betting the business on its MicroOS-based Adaptable Linux Platform. While the Fedora project uses the same filesystem, it doesn't use the snapshot functionality at all – there are separate Silverblue and Kinoite editions for that, which use Red Hat's OStree tool for image-based deployments.

Nix uses the filesystem to accomplish this, in a way that's very un-Unix-like. In the SUSE family, you can't see the different snapshots directly in the Linux directory tree: they are only visible using the Btrfs tools. In NixOS, the whole OS is built and managed by Nix, so while some of the conventional directories exist, their contents are not what you might expect. As the screenshot shows, there is one combined /bin directory, and it only contains a single file: a symlink to provide sh.

The NixOS /bin directory is startlingly empty: the only thing in it is a symbolic link to provide a Bash shell

If you're familiar with the Unix filesystem layout and know your /bin from /usr/local/bin, NixOS will come as a shock. There is a package-management command, nix-env, and you can use it to install software, but amusingly, to find a particular package, the Nix wiki's suggestion is to look on search.nixos.org.

If when you think of a ready-to-go Linux box, you can easily call to mind a particular end result: a particular set of tools, perhaps of certain specific versions, and you know what to type to open them, then NixOS could work for you. You learn how to specify the packages you want in a config file, and NixOS will make that happen for you, and then keep it updated. You just have to learn to let go of the idea of things being in particular known paths: they won't be. They will be in some very long folder directly under /nix/store/ and you need to let the OS manage that for you.

If you don't yet know which desktop is right for you, and you want to explore, to learn, to add programs, try them, remove some of them, and so on, NixOS is almost certainly not for you. It's also not for you if you already have deep muscle memory for where things should be on a Unix box.

But we can see a lot of potential if you already have solid knowledge but are also willing to let go of what you know and learn new ways. Saying that, a lot depends on the maturity of the tools, and starting with zero previous experience, we found that grabbing the GNOME ISO, installing it in Virtualbox, and choosing the Xfce desktop resulted in a fully functional installation with no big problems. A default install provided the desktop, Firefox, and the basic accessories one might expect. Adding LibreOffice was as simple as typing nix-env -iA nixos.libreoffice and seconds later, version 7.3.7 was installed and working. We needed to reboot for it to appear in Xfce's applications menu, though. With LibreOffice, it took under 6GB of disk, and under Xfce it idled at about 350MB of RAM.

In a way, NixOS means taking the DevOps approach to your own computer. Don't worry about where things are located or dependencies or the commands you need to run to install stuff. Make a list of what you need, tell Nix to do it, and then relax and let the OS worry about what goes where, where it came from, if it needed to be compiled, whatever.

Compared to reports of NixOS from just two or three years ago, we found it was very simple to get it installed and working. This suggests that the tools are maturing well and reaching a certain level of polish, but from a first-time perspective we have no prior baseline to compare against. This is very much not a traditional distro, or even a traditional Unix, but it works and we can see the appeal.

If you are in a position where you can throw out your preconceptions and start over, NixOS looks very impressive. If you need to keep your current OS, you can put the Nix package manager in a subfolder on an existing distro, and it will do its stuff inside that tree. If you are in a position where individual Linux boxes come and go constantly and what you care about more is that certain expected tools are there and work, and you're more bothered about the time it takes to make that happen, then NixOS is worth your consideration. ®