Nix – Death by a Thousand Cuts

Trying to get Eduroam working soured me on NixOS as a desktop/laptop OS. If conventional methods fail, you're left with a completely non-standard OS designed to prevent quick hacks.

But NixOS spoiled my entire mindset around Linux. Going back to anything else feels like a massive downgrade. We would be better off today if declarative operating systems became the standard back when they could.

I use NixOS, one of the annoying things to me is the documentation and error reports.

I swapped my installation to a Flake managed install a few months ago, and parts of my Nix files that were perfectly fine before started throwing out errors (specifically HomeManager), which no amount of Googling the error message that gone thrown got me any closer to a solution.

I looked at documentation recently to try and enable PGO/LTO and Zen 3 optimizations (don't mind compiling everything) and I think I saw at least 10 ways and none worked (gcc errors, etc).

I found getting started quite easy.

But then you discover there are like 4-5 different ways to manage packages and not much consensus in the community on what the correct way is. That was kinda discouraging

I think this is quite a fair commentry (although I quite like the Nix language personally) - as a nixpkgs developer even I don't use NixOS on the desktop. For me it shines on servers and development environments.

> ZFS on Linux [...] The recommended way to do this is to use LUKS, not native ZFS encryption.

FWIW I've been using native zfs encryption on nixos and it works great. It lacks neat features like being TPM-backed or having multiple keys, but if all you need is password-based encryption then I think native ZFS encryption is better since you'll be able to do encrypted zfs send/recv, you'll have granular control over which datasets are encrypted (or encrypted with different passwords), you'd get cross-platform support for the encryption (for example, my FreeBSD home server can receive and decrypt my laptop backups), and you aren't adding another layer of complexity.

I'd like more clarity on this:

> The advantage over docker here is that (when using Flakes) Nix builds are completely reproducible. Docker containers may be isolated, but surprisingly they are not deterministic out of the box. With some work you can make docker deterministic, but thats what you need, its much easier to use Nix.

as the whole purpose of the Dockerfile is to create a reproducible environment.

My setup is a smorgasbord of dotfiles and symlinks. It's been built up over 13 years, so it's very well seasoned and has served me well, but I've long been meaning to move to Nix to make my setup cleaner. The bad in this article isn't that bad, so now I'm amped even more to do this!

Thoughts on a love/hate relationship with Nix on the desktop.

I've been daily driving nixOS on my desktop, and manage my work and personal macOS machines with flakes. I love this ecosystem, and have even managed to make folks at work use nix devShells -- frankly, the learning curve is pretty steep; the payoff is that I've learned so much. I've been very happy with it -- I run a windows VM with libvirt/KVM/QEMU when I want to game, and use the same to run "local" LLMs. While docker is a great technology, I actually prefer using nixOS containers (which are, under the hood, systemd-nspawn containers).

When I worked on my startup briefly, I built nixOS images with everything needed for raspberry pis; all I needed to do was use dd to burn the image to an SD Card.

For me, nix is a wonderful and perfect solution for building stable software.

Nix for me has been a great source of stability. I used to run ubuntu and was never happy. Packages randomly broke, the UI lagged a lot, I always had to dig to get things working. One day when I head a uni deadline an automated updated destroyed my wifi funcionality. I had some experience with nix from work so in anger I installed NixOS. Wifi worked and I finished my uni assignment. Haven't installed anything else on my computers since, and that was 6 years ago. Sure things can be a pain. But NixOS has never broken in unexpected ways. I know if I update things may go wrong. But I can always go back and try again a newer version a few weeks later.

The biggest drawback is really that "random executable from the internet" does not work out of the box. And sometimes you have to spend a lot of time to package something yourself. But all in all It has saved me time and a lot of pain. I dare even say I no longer have a toxic relationship with my OS.

I don't think he touched on whether server side is a more valid use case, but was nice to read someone elses take on using it for a desktop. Thanks for the contribution.

He did find functional programming to be sort of mystic so I don't know if I trust his take on assesing the nix language itself.

TLDR; just stick with ubuntu or arch unless you feel like experimenting

I dabbled with NixOS many years ago for a much shorter time than the author has spent on it, so I have much less experience with it. My main problem with it was that the problem of declarative config is basically solved at the software-level already.

System services have always been able to be configured by dropping files in /etc. Lots of software also specifically supports config dropins, so that merging configs from multiple sources is even easier. Even stuff like creating users and groups can be done on systemd distros by dropping in config files. Similarly configuring user software is mostly about dropping files in ~/.config etc.

Package managers vary. Alpine's apk is the best in that `/etc/apk/world` is the list of packages you want, and every run of `apk upgrade` will install and uninstall packages accordingly to match that list, but it doesn't have dropins. apt and zypper don't even have a config file, only an opaque database that you can only interact with using the commands. But you can maintain your own packages list and then script apt/zypper to diff against that list and install/uninstall accordingly. (zypper in particular does maintain a list of packages, except it's a list of packages that you *don't* install explicitly but are just auto-installed as dependencies of the ones that you did, which is funny to me.)

I get declarative config on all my devices (a mix of OpenSUSE, Debian, Ubuntu and postmarketOS, across servers, desktops, laptop, phone) with just an Ansible-like setup. For each device I have a `$hostname.roles` file that contains one role per line. Each role corresponds to a `role.$role` directory that contains any files that should be deployed as part of that role (both under homedir as well as at the system level) as well as a `packages` file that lists any packages that should be installed for that role. Then there's a small shell script that matches the hostname of the machine against this directory and ensures that all files exist, and that all the required packages are installed and no extras are installed. Also the entire directory is in version control so I have a log and reasoning recorded for every change.

The author mentions rebuilding a laptop to do another laptop's job by applying the other's Nix config. I have also used my script to rebuild a few devices after their disks died and I had to reinstall the OS from scratch, so it ticks that checkbox too. And of course I've added and removed roles occasionally to add/remove features from individual devices.

NixOS would give me a way to rollback the entire config, but I can also do that with this. In case I need to rollback to packages that no longer exist in the distro repository, I have btrfs snapshots to roll back to.

NixOS would give me a way to install multiple versions of packages, but this is something I've never needed. I primarily stick with distro software so it is always consistent, and if two distro softwares require different versions of the same dependency, distros already know how to solve that (make two coinstallable packages).

The one time I tried to build someone else's Nix project (and they even had a Dockerfile with nix in it to do the build so it would be completely independent of the host), it didn't build for me, so I'm not sure how reproducible it really is. But that might've just been a problem for that one project.

I'm sure Nix(OS) has benefits for other people, but for me the benefits that I would care about are handled entirely by dropping files in the right places, and I don't have to use a different OS or package manager or bespoke programming language to do that.

[dead]