NixOS: A Personal Post-Mortem

NixOS: A Personal Post-Mortem
nathan-kim.org

In the end, I realized I was just still using ArchWiki for help and also that my Arch installation on my desktop was still fine after 5 years. I ended up switching back and felt much more at home. Personally, I would consider nix again if the language and scripts had less learning curve (I couldn't get vim code completion to work, ctags doesn't support nix either). Otherwise, I'd love to see a similar distribution in concept that used a more standard language that might be more accessible.

Granted, it's not ideal that this kind of hint is needed for such an important workflow. Oh well. All the rest still makes it easily worth it for me.

With the whole "your system is read-only" bit, I'll add that Nix can make trial and error editing of config files quite tedious. Editing and reapplying the configuration is fast, but not as fast as editing a file and `systemctl restart`ing the service in question.

On development environments I've also had similar problems. My workplace uses a combination of Python and C++. While Python has an established package management system, C++ is still in the early days. The traditional is just use what your OS provides, but the production OS is different from the development OS, the former being much more "stable" (and therefore with older package versions) than the latter. This has caused plenty of headaches with features not being available, and is holding us back from using newer C++ features, or even adding dependencies easily.

Being keen on Nix, I've been testing out using it locally for dependencies.

With C++ it mostly works. Some annoyances have been packages not providing CMake or pkglib config files. Some packages don't quite have all the possible features enabled, and it's not trivial to enable them (I struggled with arrow and liborc).

Then comes Python, which introduces the same nightmares which the author experienced. Python packages that use system shared libraries are troublesome. The buildUserFHS solution seems like the right approach when mixing and matching, but it introduces a few more problems (the details of which elude me right now).

An additional problem is portability. Theoretically one could use `nix bundle` to ship whole applications, but a shared library is a different matter. We've got a Python module written in C++ module, I'm not sure a module built by Nix would be compatible with the host's Python, given the libstdc++ differences and so on.

This struggle is topped with the fact I'm the one going against the grain, trying to sort out the issues I hit, for my own purposes only. I do hope I manage to prove to myself that it's a tenable approach, and eventually can propose it to the wider team. But for now I know it's a dream.

The first issue you describe is that you already have alternative Nix-like solutions in particular domains (R packages), and Nix let you continue using them. Is this not desirable though? You have the choice of letting Nix handle this, or carving out a Nix-less niche to continue using existing / more cross-compatible solutions.

The second issue is that support for games is weak in NixOS. But is this surprising? You're running games via emulation on a niche OS, where neither the game or the emulation tools you're using officially support NixOS. I'd say the fact NixOS can run these games at all is very impressive. Other alt-OSes, like Haiku, would not be able to do so.

The third issue is that you seem to need to edit /etc/hosts to be able to connect to captive portals on public WiFi. Do you? I'm on Linux, and I don't.

It honestly seems like Nix requires more tinkering than you were willing to do to get it set up, and that's an absolutely valid decision to make - it's the reason I don't use Arch, for example - but I feel like your article frames this as an issue with Nix, which seems a little disingenuous.