When the parts were almost in, I had decided to really start digging into NixOS. Friends on IRC and Discord had been trying to get me to use it for years, and I was really impressed with a simple setup that I had in a virtual machine. So I decided to jump head-first down that rabbit hole, and I’m honestly really glad I did.
NixOS is built on a more functional approach to package management called Nix. Parts of the configuration can be easily broken off into modules that can be reused across machines in a deployment. If Ansible or other tools like it let you customize an existing Linux distribution to meet your needs, NixOS allows you to craft your own Linux distribution around your needs.
Unfortunately, the Nix and NixOS documentation is a bit more dense than most other Linux programs/distributions are, and it’s a bit easy to get lost in it. I’m going to attempt to explain a lot of the guiding principles behind Nix and NixOS and how they fit into how I use NixOS on my desktop.
I’m hearing more and more people talk about NixOS lately, and I’ve been wondering why. This article is an excellent overview into this unusual Linux distribution.
White on black monospace text with markdown formatting? I would read this article even if it didn’t interest me!
Superficial aesthetics aside, thanks for the article, I’ve been keeping an eye on NixOS for a while now.
I use NixOS as my daily driver. Basically, I mosh into my Nix box and do all my development there from my Mac, which I keep as a thin client. It’s an AMAZING way to manage a system, and once you go declarative/functional, you’ll never want to go back.
The Achilles heel of the entire Nix ecosystem, however, is documentation. It’s really, really bad. The community is phenomenal but they have limited time to spend on non-development tasks and I don’t think there are very many corporate sponsors. Many (if not most) of them also don’t seem to be native English speakers, which doesn’t help the matter. Finally, and this may be my bias, but you get the impression that the whole concept is so esoteric and difficult to communicate to non-technical people that the project tends to attract a certain type of developer, the kind that isn’t really interested in things like documentation, organizational policies, backward compatibility, etc.
I’ll give you a small example. NixOS’ packages contain NPM packages. The officially sanctioned way of adding or updating a new package is to run a script inside the packages master repo that will not only add or update your package but also update every single NPM package tracked by the repo–literally thousands of packages. There is no official way at the moment of simply adding or updating just your NPM package. When I asked about this peculiar behavior, the response was that it’s not a bug, it’s a feature, because this way no NPM packages get stale and besides, if you want stability you can always either override the package recipe manually or pin the entire package set to a specific Git revision (which, by the way, isn’t a properly documented thing).
Like…are you serious? The whole point of having package maintainers is so that the packages don’t get stale. It is a human process for a very good reason. This is something that can be assisted by scripts but certainly shouldn’t be completely scripted by design. Yes, they are low on resources, but how can you say that is an intentional decision to force thousands of packages to update just to modify one? When I brought this up, it seemed to bring on a collective shrug from those I reached out to.
I also don’t totally understand why they continue to use the obscure Nix language, which was part of Dostra’s Ph.D. thesis. Surely they should move on to Haskell or something with more popularity by this point.
Yeah, I love NixOS to bits and will continue to use and contribute, but there’s no way that they’ll get mass adoption even amongst highly technical Linux power users unless they change some of their views to be less hacker-y and more focused on boring, basic stuff like maintaining version and API stability inside of releases (let alone between them).