Why NixOS?

Nix is amazing, but the comparisons can be confusing.
June 5, 2016 (nixos)

Nix is one of the most powerful tools that I’m aware of. A huge amount of effort has been and continues to be put into the problems of building and packaging software, of defining environments and dependencies and configurations.

Nix generalizes every other tool in this space. What you can do with another packaging solution you can do with Nix; but at the same time there’s plenty that you can do with Nix that you can’t do with other tools. Here’s a few such tools.

If you’re using emerge to build your kernel from source with customized build flags - Nix can do this for you as well. And it also gives you a transactional system-wide rollback when the power cuts out halfway through the upgrade.

If you’re using pip and virtualenv to define project-specific python dependencies - Nix can do that too, and at the same time fully manage all the C extensions and compilers. And everything can be downloaded precompiled from the build farm, and shared on disk between any number of different projects.

If you’re overhauling Debian to provide multi-arch support, so that you can have two or three special-cased architectures side-by-side on the filesystem, you can instead use Nix, where this is baked into the core and you can have ten thousand flavors of gcc without a hint of interference between them.

If you’re using homebrew to install miscellaneous shell utilities on your MacBook without needing root - you can do that with Nix as well, and by the way your package expressions will parametrically work just the same on your Linux servers.

It’s a similar story with pretty much everything else. There are certainly cases where Nix isn’t yet as polished as a more common and specific tool (for example, Windows support, compared to say OneGet), but it’s never a fundamental limitation, whereas in the other direction it usually is (for example, it’s totally out of scope for Emacs’ package.el to learn how to deal with ruby dependency management).