Quick Rant on NixOS

Posted on 2022-04-14

I’ve used Gentoo, Ubuntu and many other OSes, but none really worked for me. In many ways Nix has been the only operating system / package manager that I like. The declarative system and reproducible builds with a somewhat functional interface drew me. In later years I now keep nix more on the side as a pipedream of the optimal package manager. The problem I have with Nix these days are:

  • in order to save time on reproducible builds, you spend hours on making *.nix files. Sometimes these may brake (if you let them be updated) because Nix-world changes every so often
  • It’s difficult to sell nix to others: understanding the eco-system takes time, and the /nix/store takes GB of space. HDDs are cheap but its a turn-off for other developers
  • difficult to make standalone libraries: you can bundle into docker images, but I find these often are larger. Maybe there are some tricks I could learn, but I’ve had some > GB images for < 100 MB packages. The reason is that /nix/store/ retains all dependencies. For non-docker images, you can find some tools to make standalone binaries, but these can also be a little tough to get into (occasional breakage with certain dependencies).
  • Unpredictable roadblocks: to me, if I’m obsessed about getting the job done nix doesn’t feel mature enough. I find myself having to read sourcecode or github issues to get through some roadblocks, occasionally having to write overrides to provide specific package versions or work around packages that are marked as broken. In one way this is cool, since you learn a lot, but on the other hand, I don’t feel confident estimating how much time I will use to configure Nix.

The reason that I still use nix is now more about community. I feel the nix environment is much more vibrant than many other alternatives. I love how nix gives you enough power to write your own tools and systems, and how this has enabled the community to be creative. And there is still this nice feeling of achievment whenever your project’s *.nix files work the way you want them too. I also have to give nix some credit: managing Haskell projects in Ubuntu (either native or in Docker) is a pain. In Nix, it is not, outside of long (when not cached) compilation times. There are definitively many use cases where Nix just excels.

The other option is usually Docker. There are many benefits, but if a dockerfile is poorly written there may still be problems for different environments and users. Managing the cache, volumes and network sometimes consume a great deal of time and I end up wondering how much easier it would’ve been if I could just work with native packages. People say its worse for scalability but I’m not entirely convinced (yet). I’ve had jobs where I manage thousands of servers with daily updates and it went fine. There were some problems that we could have resolved if we used docker, but likewise, there were some problems we would have had if we used docker too. If docker is a double-edged sword, I feel better choosing the tool that has a smaller learning curve.

It’s starting to feel more pragmatic to just demand everyone use a late version of Ubuntu and say that whichever build problem they get is their own responsibility. I get the feeling more and more that build tools that promise reproducible builds cost more time to learn and maintain than what they are supposed to save.

Got suggestions, corrections, or thoughts? Post a comment!

Markdown is allowed
Email is used just to show an avatar image and is not displayed or stored
Comments are moderated. They will appear below after they are approved.

0 comments