The Polyglot Nixos
Key topics
The debate around NixOS's simplicity is heating up, with some users raving about its straightforwardness, while others argue it's actually a complex system with a lot of "magic" under the hood. On one hand, users like teekert and rowanG077 swear by NixOS's ease of use, citing their past frustrations with other package managers like apt. On the other hand, commenters like xnoreq and sigmonsays point out that NixOS's simplicity is actually a result of its unique approach to package isolation and declarative configuration. As users like vegabook and embedding-shape chime in, it becomes clear that NixOS's holistic configuration management is a major draw, making it hard to go back to other package managers like apt or brew.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
3d
Peak period
40
72-84h
Avg / period
9
Based on 54 loaded comments
Key moments
- 01Story posted
Dec 20, 2025 at 2:39 AM EST
14 days ago
Step 01 - 02First comment
Dec 23, 2025 at 2:02 AM EST
3d after posting
Step 02 - 03Peak activity
40 comments in 72-84h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 26, 2025 at 7:02 PM EST
7 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Recently a customer wanted me to use Fedora (I never visited the RPM side of the world before), and after truly the worst installer I've ever used, the actually system was nice. I do like Cockpit.
But then I needed to install an initrd that would me unlock the full disk encryption via SSH (it's a remote headless box). It took me half a day and a forum post to get it to work. I wrote a full page of notes for next time. Then the Firewall: I hit a bug (plus user error) which left me wrestling with a non-existent Tailscale interface for a while (it warns you for non-existing interfaces, but the warning is not case sensitive), but after some hours I was done setting the zones.
These configurations are both 1 or 2 lines in a NixOS config file. And that "work" is now done for all my servers.
You could argue that NixOS hides a lot of complexity, but so do Dracut and Firewalld of course.
In terms of all the linux systems I have used, NixOS seemed to least magical to me in terms of what is happening under the hood.
Simple package based distros like Arch basically just extract archives. Very few packages trigger post-install steps which usually just (re)generate something like initrd.
Afaik, bricking Ubuntu is either due to user error (e.g. mixing incompatible package sources) or the devs released broken/buggy packages...
This combined with the fact that the full source code for the system is contained within a single monorepo that I can checkout and grep through makes NixOS the easiest to understand and most transparent distro I have ever used.
Well, the updates themselves yeah, but not what data they use. You cannot always rollback database upgrades for example, without also having to rollback the data source of the database. In most cases you're right though.
I'm saying this as someone who is a fan of NixOS and use it on all my servers because I tend to forget what I do if I just ssh in and fix stuff. Although I'm on Arch/CachyOS on all other hardware.
Sure it's simple, just like 80% solving the problem is usually significantly simpler than solving it 100%. Nix (and its generation) is the only package manager that actually works.
Try installing kde and gnome, then uninstalling both and check how many packages remain.
Nix can do that with the whole world with nothing residing.
Sounds like a package manager or package problem. Competent package managers (e.g. dnf) remove unneeded packages and all their owned files. Albeit, I think with apt you need to do a manual autoremove to remove orphaned packages.
Not suggesting that they're equivalently powerful compared to nix, but this specific thing shouldn't be a problem with traditional package managers.
I'm comparing it to my experience with Ubuntu where packages can have complex install dependency flows that can destroy your system. They also pollute your entire system. In NixOS installing a package is literally unable to touch anything outside of it's own designed nix store folder. That is why it's so easy to understand for me. I can check the nix store path and see what a package has. I can fearlessly install a package without worrying my system will break. It's just so much simpler. The nix language itself ain't it though.
- in traditional package manages, the dependency is global, and potentially breaks everything else installed.
- in nixos, package is isolated to the environment and can co-exist on its own, for the purpose of one application.
Then nix layers way more nicety on top by offering modules, but nothing prevents you from ignoring all that and just using installing packages.
I try to install all software via homebrew, mise (https://mise.jdx.dev/), and scoop (https://scoop.sh/), and setting up a new machine now takes me minutes. Meanwhile I don't need to deal with Nix language.
for homebrew, while Nix configuration is for everything. I never used a Brewfile before, so looked at https://github.com/Lissy93/Brewfile/blob/master/Brewfile but it just looks like a list of packages. What about the configuration for those packages? Or your own custom patches for them? Runtime parameters? Environment variables?
There is so much more going on in the typical developer environment that it doesn't seem like (to me, an uneducated fool) Brewfile would be enough to actually serve as a declarative source of truth, except for Homebrew-specific things.
But like you said, I can't ever imagine going back. Once you're over the learning curve (and... yeah, that learning curve) the upside are just so huge. Nothing compares, at all.
Part of me wonders if maybe one day a bootc-based framework will offer something like 20% of the benefits of NixOS with only 10% of the downsides. But other than that, we're totally stuck with Nix forever. (And once I had switched to bootc, I bet my next thought would be "I should find a way to generate this config from Nix"...).
[1] I have a very complex config so this may be an extreme case. On the other hand, everything about Nix is basically designed as an invitation to create an extremely complex config.
They both have the same complexity in that scenario. Underneath it's very comparable configuration for both but Nixos provides an easy abstraction for that specific case.
If you can stay on the happy path with nixos then it's pretty lovely. I've even adopted nix-darwin for my mac's too.
I'd still deploy Redhat/Fedora over nixos on anything revenue generating though. The problem is when you have to come off the happy path in nixos and now you're debugging some interestingly written c++ code that evaluates a language that has a derivation expressing what you wanted done. Contrast with the redhat situation, it's simpler but less convenient in the general case.
I agree that Nix or NixOS are risky tools.
But it's not a problem that the `nix` program is written in C++.
A lot of the friction comes from the tension between NixOS's idiosyncratic design & its constraints, against the often 'dirty' way software is practically written.
For example, roughly, Nix's ideal software follows `./configure && make && make install`, where nix can then symlink the dependencies & maintain these in a read-only store. -- Whereas, say, Python wheels break this (because the precompiled binaries assume shared libraries are available globally).
When you run into friction with NixOS, you may need to understand things with a depth and breadth which aren't required with more common Linux distributions. (Including e.g. maybe needing to understand the rather large and obscure nixpkgs).
Definitely this is a real issue; you can see it especially with something like the nginx module, where a very deep and expressive underlying nginx.conf language has been collapsed down to a handful of with-arguments that are all adding multiple flags or behaviours for what some nixpkgs maintainer thinks are "smart" defaults:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/ht...
In other cases, though, use of the toINI generator also allows a reasonable interface to mutate and overlay the underlying keys of the config:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/ht...
Setting up systemd units is similar, where at the nix level it's just an attrset (dict) of the kv pairs in the unit file, and the module takes care of rendering it out to the proper format of text file. No indirection, no half-baked mapping between key naming conventions, just a 1:1 translation.
Hopefully this can be the direction things continue to move in order to continue reducing and eliminating this problem.
NixOS is an improvement over RH et. al. even if you stray a small amount from the happy path; to use the GP example, if they couldn't do what they needed with the nixos LUKS options, they can click on a link from a related option definition and end up with https://github.com/NixOS/nixpkgs/blob/nixos-25.11/nixos/modu... which will describe much of how luks is configured. Often a small change there can widen the happy path, and with a PR, it can be made upstream in unstable relatively quickly and a release in the next several months.
Just curious. I haven't run into anything like that myself.
Using nix for three months now, the main "pain" I run into is that I want app config files to remain writable by the app, but home-manager ethos is understandably against that.
So I've had to vibe-code my own HM module for claude code, keepassxc, cursor, etc. and use activation to merge my nix settings into those files if they exist.
Though I put pain in quotes because it's still 10x better than what I was doing before, and an LLM can do it just fine.
No other system provides this in that sane way. I used countless configuration systems, from custom bash hacks, ansible, chef, puppet, salt - I have seen a lot.
Nix is just on another level. Never going back
1. That the error messages for them i find to be awful. They really need to take inspiration from Rust to help users know exactly where the API error is happening relative to your code. I've spent quite a lot of time toggling things on and off to try and find which part of code, or which package, is causing a specific failure.
2. I've not found the APIs that the abstractions provide to be stable in the same way my Rust crates/etc are. Something can randomly break between updates and i'm not sure what caused it. Takes me quite a while of digging through source to find the root cause, and digging through Nix source i find extra painful.
All around i hate this side of Nix. A lot. However it's enough of "another level" that i stay with it and don't switch away.. I use it for my Linux machines and my Mac laptop. It makes so many things so easy, the majority of the time.. but when something goes wrong.. it's super painful.
I've not had issues with Nix APIs, at least not Nixpkgs or the language builtins. When something does break for me, it's usually some random JavaScript package that had some external dependency change. Nixpkgs is pretty well organized and I find navigating it not that hard once you read the packaging guidelines and learn how to use `find`
Disagree somewhat on 2. Yes, there are frequently small breaking changes, but the massive upside of nix is I can either just rollback or pin a specific package at a specific version and move on.
Yes, this is an understated benefit.
The declarative interface is nice.
That NixOS configs are modular allows you to create those abstractions. -- In the same sense terraform modules are "infrastructure as code", NixOS modules are "system configuration as code".
I'd like to read more about this. Are you open to sharing your notes?
Those ternary blobs tend to be cross-platform, I hear.
https://nix.dev/manual/nix/2.20/command-ref/nix-store/optimi...
Unlike in FHS distros where you get some of the separation for free with usr/lib vs usr/share, most nix packages don't have separate store paths for binary vs non-binary files. At most you'll get the headers and build scripts split off in a separate dev path.
If you want to be really pedantic, you can get completely different behavior if you built your system image in February in C with just:
It kind of feels like this should have been the default across all architectures - a single disk that supports multiple instruction sets. 32 bit? 64 bit? Intel x86? Intel x86_64? RISC-V? Imagine how much simpler it would be for the end-user.
I still believe to this day that it has been a massive mistake to not ship ARM devices with some form of BIOS/UEFI chip to allow the system to boot without a bootable image.
https://github.com/nix-darwin/nix-darwin
Great project, but I had to discontinue using it on my dev machine because of some issues getting the correct versions of dependencies installed.
I haven't looked deep into it, but my impression is that most system recovery images target just x86_64 and maybe 32-bit x86 if they're cheeky.
I remember I had G4 Mac mini and one of the first gen intel macbook pros - you could have use one of them as a hard-drive and boot from it via Firewire. Work magically.