Moving to NixOS

Tuesday 24 December, 2024


Disclaimer

This post will be rather more technical compared to what I normally write about. I will be using a lot of technical jargon specific to the Linux desktop space. If you are not familiar with this world, then I suggest you skip this post, there are more coming soon (tm).


I recently migrated my (main and only) system from Alpine Linux to NixOS. In this post I will explain why I made the switch and why I consider Nix to be – currently – the best Linux distribution available.

Nix is a project that has been on my radar of quite some time now. It is a system designed around the principles of reproducibility, build-isolation, and declarative design, while also boasting one of the largest and most up-to-date software repositories in the Linux world.

Of course, there is a lot of hype around Nix, and this tends to be a dangerous thing. In fact, I switched away from Arch Linux a few years ago exactly because it was increasingly flooded with novice users drawn in by the hype who considered the forums their personal large-language-model[1]. Aside from the hype though, there were a number of aspects which seemed really attractive to me. Rollbacks, Software availability, and Reproducibility being the main ones. On their own, these were not enough to overcome the cost of switching, that is until I encountered some problems with my existing Alpine installation.

Alpine

When I initially switched from Arch to Alpine, I was very pleased for various reasons. The Alpine Package Keeper (apk) is -- to this day – the most pleasant, fast, and reliable package manager I have used, Alpine’s bi-yearly stable releases allowed me to have a more stable system, and the installer that came with my flavour of Alpine (PostmarketOS) allowed me to recover from catastrophic breakages faster than with Arch.

Out of these benefits, stability and recoverability were the most important ones. These values are important for two main reasons. Firstly, I only have one laptop at my disposal, and it is an arm laptop at that. If my OS breaks in some catastrophic manner, I will need to borrow someone else’s laptop, take out the EMMC storage, and re-flash the operating system. A process that could take several days if none of my friends’ laptops are available. Faster installations (that can be done from windows or mac) massively increase the chances that I will be able to recover my system in a reasonable amount of time. Secondly, I do not generally have a lot of time to tinker with my system outside of holidays. For this reason, I have gotten in the habit of only running updates every half year or so. If I would do this on Arch, everything would rather quickly break, and I would likely not be able to install anything in-between because there would be a dependency mismatch.

In other words: Alpine stable is perfect for me. There is one problem however: I can’t use it. ‘Can’t’ is a big word of course, and I must admit that I could theoretically live with a stable alpine release. But as it stands, I use a lot of software from Alpine’s ‘testing’ repository, which requires one to be on Alpine Linux ‘edge’, the rolling-release side of Alpine. In other words, almost the entire previous paragraph can be thrown out. I will say that Alpine’s apk handles infrequent updates better than Arch’s pacman, but it still is not ideal that I need to be ‘edge’ at all..

This leads us to today: the start of the winter holidays. I tried running an update and it did not go well. Firstly, apk updates itself, so far so good. Secondly it tried to instal ‘mesa-asahi’ for some reason. I have still not figured out which program introduced this new dependency. For those who do not know ‘mesa-asahi’ is the graphics driver for Apple’s arm-based macs which recently landed in alpine-testing. I do not have an arm-based mac, and so I don’t know why this should have been installed. The reasons are however meaningless because ‘mesa-asahi’ introduced a conflict with ‘mesa’ generally (the graphics drivers I actually need) because the former was already on version 24.3 while the rest was still on 24.2.

I tried running ‘apk fix’ which is generally a good idea when you encounter a conflict with apk. This command (for some reason) updated ‘qt6’ and nothing else. This meant that any app using qt6, like my web browser, document viewer, file manager, music player, video player, tormenting client, and others, would not work until they-too were updated.

Since I didn’t think I needed mesa-asahi in the first place (I never installed it up to that point, and I didn’t see why I should start now), I decided to simply tell apk to exclude the package and update as usual. This seemed to have... weird effects. Firstly, none of my graphical programs were working anymore. GTK applications gave some sort or error which I cannot at the moment recall while QT applications just segfaulted – a great start. Secondly, the system was incredibly slow: both in being sluggish to use and taking three times longer to boot than usual.

Now – clearly – I messed something up by telling apk not to include mesa-asahi in the update. Indeed these problems may be attributable to missing graphics drivers – with the system falling back to software rendering. However, the dependency introduction and version-mismatch were both out of my control, and the fact that ‘apk fix’ updated QT6 and broke all my graphical applications meant that I couldn’t just wait for the version conflict to be resolved[2].

I though for some time about what to do – re-installing Alpine-edge might work, or I could try Alpine-stable and make-do without half of my software – and ultimately decided that I could not stay on Alpine due to the simultaneous need to be on ‘edge’ while also needing a rock-solid system. Which brings us to Nix.

NixOS

I managed to download the NixOS installer ISO with ‘curl’ and install it to a borrowed USB-stick using ‘dd’ while still on my broken Alpine install. According to the wiki, I should just be able to use the graphical installer on my system. Easy peasy.

This was not the case. The graphical installer does not have a menu to select the bootloader, and nix’s default loader ‘grub’ does not work well on arm based systems. Luckily the wiki-page for installing NixOS on arm single-board-computers had the correct instructions for a manual install, and a few minutes later I had a fresh install of NixOS.

My initial impressions of Nix were rather positive. It was remarkably easy to learn, and there were a lot of resources available, notably the wiki and the forums. At first I had some trouble to get things working properly. Every time I ran an update, the updater itself would be broken on the new install[3]. Everytime though, I could just roll-back to the previous version and try again[4].

I spent some time getting my usual configuration set up using nix and noticed just how helpful the nix-rebuild command was. For instance, when I tried to install flatpak, nix informed me that for flatpak to be functional, I needed to enable the xdg-desktop-portal service. After doing this, it told me that I didn’t have an actual portal configured and/or installed. For context. If you do this on Arch or Alpine, you are pretty much left to your own devices in figuring out how to get these working, especially if you are not using a pre-configured desktop environment.

A second immediately noticeable difference was the sheer size of the nix repositories. Every piece of software which I use, with the exception of one[5], was in the nix repositories, and I use a lot of niche and obscure software. The only somewhat strange thing I noticed is that the font which I like to use for my desktop: droid, was not in the stable repository, but only the unstable one[6]. This didn’t matter though as nix allows me to add just this one package from the unstable repository while keeping my others on version 24.11.

Nix handily beats Alpine in terms of software availability. I think this is in large-part to to the fact that alpine requries more porting work due to its use of musl-libc and openrc, rather than the more standard glibc and systemd Nix also beats Arch if you look only at the main repositories. The arch user repository still has an edge over nix in some cases, but this is not so much as repository as much as it is a collection of build scripts which – in my experience – work about as often as they do not.

Lastly is recoverability. I already mentioned nix’s rollback feature, but even if my laptop dies in its entirety, if the drive gets corrupted, or if I want to move to a different system, I will be able to get back on track in no time whatsoever. This is because an entire NixOS install is essentially defined as a configuration file. I have this configuration backed up in a public Github repository[7] and can therefore recover my system in minutes, rather than hours or days.

All in all I am loving nix so far, and I will probably keep using it for quite some time.


[1]: As a quick aside, I think the classic Arch-user-forum response ‘RTFM’ (Read the F Manual), is harmful to the community as a whole, though I cannot deny that most of the questions raised by new uses are described extensively on the excellent wiki pages.

[2]: As of writing, the mesa package has still not been updated and the version conflict persists. It has been about a week.

[3]: This is 100% a case of user-error, and not a problem with Nix or NixOS.

[4]: I recall when I first installed Arch constantly messing things up and re-installing from scratch. Even on Alpine I once managed to remove any means of connecting to wifi and needing to re-install.

[5]: I can’t even blame nix for this. The program in question is a niche add-on to a niche program which has not been updated in over a year. The only reason this program is in the Alpine repositories is because I added it there.

[6]: I don’t know exactly what it means for a typeface to be ‘unstable’, but I believe it has something to do with the fact that droid is designed for small-screen-interfaces which are currently under heavy development.

[7]: https://github.com/user18130814200115-2/riverbed



All of my writing and software projects are available free of charge under CC-BY unless stated otherwise. I do not accept monetary donations, but if my work has brought you value I ask you to donate to a charitable cause or high-impact fund, organisation, business, institute, or individual driving moral progress.

For more information about making a moral impact, search for “giving what we can’’, “give well’’, or “effective altruism’’.