alt Hacker News>> You could argue that NixOS hides a lot of complexity
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.
Replies
Do you have examples of times you've had to dig into the nix language like that, at least at a high level?
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 -- and this is what you want on servers.
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. That way when I rebuild, my nix config can assert a subset of the config I care about without locking the app out of writing to config -- and this makes more sense for personal desktop computing.
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.
I do agree with that. But as a result I've gotten pretty good at whipping up podman containers with various bases to solve such issues.
> 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.
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).