As a developer, I always dreamed of an OS setup that can be easily version controlled, replicated on new machines, install and uninstall software packages without leaving garbage files around, upgrade to a new OS version without busting the whole OS.

NixOS delivers many of these promises but comes with its own type of issues.

When I first learned about Nix, I was very curious. I have been mostly using Debian based systems like Ubuntu, and they tend to have old versions. Stable old versions are good for databases and standard tools. But the day-to-day work happens in different programming languages with different versions that are likely not the same as the one that comes with the OS. So I tend to use various tools like asdf, rvm, etc to manage programming language versions.

The idea of using a single tool to manage all these appealed to me. I installed the Nix package manager on Ubuntu and started to use it. It was flawless for managing command line tools, but once I tried to use it for managing GUI apps, I started to face many issues. The main issue seems to be the Gnome installed by Ubuntu might not be playing well with the Nix installed GUI apps as they might be built against different Gnome versions.

NixOS is supposed to solve the GUI related issues, so I decided to give it a try. The idea of all the OS configuration controlled by a single file /etc/nixos/configuration.nix appealed to me. It’s trivial to keep this file under version control.

After a couple of days, I tried to install an npm package that downloaded pre-compiled binary. The binary failed to run which turns out to be an issue with NixOS not following the FHS standard.

Another major issue is, except /bin/sh and /usr/bin/env, none of the binaries will go under /bin or /usr/bin directory. That means, all the bash scripts out there with hard-coded #!/bin/bash shebang will not run.

As much as I like NixOS, both of the above issues introduce a lot of friction on daily usage. There are some escape hatches available for both of the issues like steam-run and buildFHSUserEnv, but you still need to figure the issue is due to the above and not something else. This is easier said than done when the issue happens somewhere deep and the error message doesn’t reveal much.

All that said, I am still using NixOS as my daily driver for all development related work for the last six months. I am not sure how long it will last till I run into something I can’t fix.