This is a simple reflection of the fact that Nix has a steep learning curve. People who persist generally have deep-enough interest or a compelling-enough use case to power through.
I feel like it's more of an indictment than praise; it implies Nix is relatively inaccessible to interested but time-constrained dabblers, which puts a hard cap on Nix's ability to outgrow its niche.
Yes, for me it was 2 or 3 rounds of "its just not clicking" before it did and then there was no looking back. Ive heard the same anecdote from lots of others as well.
I'm the inbetween. I stuck with it for a couple of months, but ended up dropping it. It's just too slow and incurs a massive complexity penalty that I'm not happy about. I'd rather just deal with tarball rootfses and union mounts if I want an immutable system (and overwhelmingly I do not.) The reproducible builds are nice and all, but I'm not in a position to really take advantage of it. I'm sure Nix is killer for a modern sysadmin.
I'd much prefer just Plan 9. WORM filesystem and first-class namespaces.
This is niche and HN is full of these back and forth comments. One thing which a particular type of crowd will appreciate is being able to apply simple patches to constantly-up-to-date packages.
For an example, I love atuin but it, by default, skips commands starting with space. Currently it's not configurable and while I wait for time to submit a PR or for the issue to be resolved, make a single line `patch` which just removes the part of the `if` statement which checks if it starts with space. So easy, took 5 minutes (also had to comment out 1 test).
And now on home-manager debian or nixos server, I get up to date atuin with that one patch. It downloads rust, etc, compiles, and then that's garbage collected away
I'm just curious what your motivation for the patch is, because I too use atuin and see the space-prefix as a feature. It's been around for a while (longer than atuin) to keep certain commands out of my history on purpose, like when running some one-off command with credentials as an arg.
Other than that I very much agree, patching stuff is wonderful in nix-land! Especially when things in nixpkgs-unstable break.
Although I’ve never committed to using nix system-wide, I do enjoy nix-based using https://devenv.sh/ for the very reasons described in the article. It’s much easier than local containers for development.
I don’t any experience with Nix - but how does it handle software which runs its own updating processes outside the package manager? Specifically thinking about software like Discord, Slack, Docker Desktop, Jetbrains Toolbox, etc.
Is the Nix-ism to just reject using such software?
Personally, I don’t see the need for this with NixOS. Setting aside the fact that Omarchy is way too opinionated (Basecamp installed by default?), NixOS is already quite composable, so you can easily build a well-formed experience out of isolated NixOS modules.
Why? Most people’s system configurations are publicly accessible on GitHub. Stuff like Omarchy only makes sense* when the system must be configured imperatively and there is a cost to trying things (accumulation of application residue). When you build your system declaratively you can just copy the bits you like from other people’s configs, or even just run their config as-is.
* IMO Omarchy doesn’t make sense anyway, far too much opinion and too little utility. It’s not a distro it’s some guy’s overly promoted pile of crufty scripts and dotfiles.
Yes, but you can also reclaim your space. I've configured nix to only store two latest revisions and have a ./switch.sh file that automatically clears everything up after applying nix.
I had issues when giving boot partition only 512mb, so I'd recommend going with 1G.
The idea is so good it’s as close to platonic as it gets. The user experience of writing your own nix expressions is so bad that it makes me angry every time I try. Not only that, but at some point the beginner help (!) meta became »use flakes, don’t do what the existing tutorials tell you, yes flakes are unstable beta and there are no tutorials but use it I beg you«. No, please, let me choose my own way to learn!
I haven’t given it a shot in the LLM age yet though, and trying out NixOS in a VM is not only easy, it is practical – in the sense that when you’re happy, you can simply boot that same config/OS anywhere else by just installing that config. And I’ll never forget that one time where I completely borked my everything in the VM, did a kernel rollback with like 3 command line args and a reboot, and the OS was, well, rolled back. As I said, almost platonic.
What I can recommend is using nix-the-package-manager. Whenever I need the newest version of something, `nix-env -i <whatever>` and it’s there and works. If it doesn’t, roll back. If I need a different version, that’s on nixpkgs as well, with the same negligible amount of friction.
Flakes are the defacto standard and you're leaving one huge point out. Flake files come with flake lock files. You cannot get lockfiles without using flakes.
The problem I have with nix is that I just don't need another hobby. Keeping everything up to date in an ever changing environment like an os just looks like chore. I install my system and image it every week and keep maybe the initial and a monthly snapshot. Why would nix be better in my case? Maybe I am missing something essential but I also don't bork my system that often tbh.
Nix isn't really much of a hobby. It does require some learning because it's different, and front-loading the work to build your config, but after that it's amazingly reliable and easily extendable. You can keep everything up to date with a single command.
The advantages:
- Declarative code describes your system. Maybe your install + imaging flow is good enough, but there are many reasons why it's technically inferior. There's no need for imaging Nix, because it's always reproducible by default. Rollbacks are rebooting to a previous config, not a timestamped blob of snowflake state.
- It replaces whatever tools and glue you have to build your system. You don't need to worry about bootstrapping tools, or config management tools' version compatibility, or bespoke ordering of imperative steps to build the system. All the management tools are built into the system. Everything "just works" automatically.
- If you manage multiple machines the benefits are compounding.
- There are other interesting bits that are covered in the article, that you get for free just due to the nature of nix. It's good for building, and has no friction to experimenting with specific tools or environments, without polluting your system.
It's a commitment to get past the initial learning and config build, but afterwards it significantly lessens the "hobby" aspects of computer management. There are just entire classes of problems that don't exist for Nix. Either your config works, or it doesn't, and the rollback guarantee is explicit and built-in.
You know, I used to agree, but what I realized, is I am a software engineer, and I'm used to working in large projects with source-code as the only documentation.
And that's what's great about NixOS, you just clone nixpkgs and treat it like any other underdocumented software you might work on.
I love Nixos. Having a deterministic system is such a great way to know what your system is capable of. The only thing that bothers me is that when I rebuild my system after updating the lock file, if a package is broken the whole upgrade become impossible.
I switched over to Nix about a year ago. I was a Windows user before that for 30 years and tried Linux a couple of times, but it never stuck. Now I know I will never touch Windows again. With NixOS I've finally found a system that actually works for me — and the full OS configuration is in a repo. My god, I love it so much.
Sometimes I even prefer nix-shells over uv for quick one-off Python scripts.
I cannot sufficiently convey how absolutely barbaric everything else feels in comparison. Not having Nix would be like having to work on code without Git — absolutely unacceptable.
And it really isn't that much work — you do it once. The next time you set up a new system, without Nix, you'll have to do the full configuration all over again.
After having done the switch to nixOS, I can confidently say that managing a system any other way (like with apt/brew + 20 handwritten bash scripts) really is neanderthal technology and nix is superior in every single way.
It's also great for the AI era, copilot is really good with that stuff.
> like with apt/brew + 20 handwritten bash scripts
I just use apt, been doing it for 20 years, it works great. I've never in my time, heard of or knew anyone who wrote 20 (or any) bash script wrappers around apt. The one year I was painfully forced to use a Mac for work, brew worked similarly to apt, just used it, no need to wrap it with shell scripts.
Comparing highly functional and capable systems like apt and brew to neanderthal technology sounds like hype.
> It's also great for the AI era
That also sounds like more hype, similar to the pro-nix other comments so far which tout AI and similar to the article which I did read, also sounds like hype.
I've been using apt for 20 years too and was never a fan of it, canonical repos are never up-to-date and managing ppas is a pain. Yes I'm very hype about nixOS (and that's a rare thing for me), but it is just really really good.
I understand that "just check it out" is not the best advice because the setup cost to using nixOS is really high, and the learning curve is really steep, so it's not like you can give it a whirl for a few hours to experience the workflow. But believe me, once you are used to it, it just so so much more convenient. I'm currently managing my dev laptop, home PC, a WSL, and a hetzner server all in the same repository (allowing for a lot of code reuse). Everything is super orderly and split into modules, everything is declarative, I can roll back to a previous build of my system if I mess up installing nvidia drivers or iwd or bluetooth etc.
It's also not like installing software is harder than with apt (oftentimes it is easer, `programs.firefox.enable = true`) so after you've paid the setup cost there is just no downside. It's a bit like react vs jQuery, or Kubernetes vs hand-written deployment scripts.
nix & nixos are by far the worst way to manage system configuration, except for any other way that's been tried. imagine if there was something with declarative system configuration _not_ written in an insane undebuggable recursive nightmare of a language/stdlib? oh well, I'll keep using it, because what other options are there?
NixOS kind of extends the idea of reproducible builds. Any snapshot could be a guarantee that things just work. This can also be extended onto the user base - if one user has solved a problem, it should be solved for all of them. So we can jump from guarantee to guarantee here.
My only gripe with NixOS is Nix. I think that this is also the biggest drawback of NixOS. I don't have an alternative; but perhaps it may be better to allow any format to be used, rather than force nix onto everyone.
Another issue is that, for a reason I don't quite understand, a few years ago NixOS' quality appears to have gone down, e. g. nobody cares about documentation anymore. This is probably not a huge obstacle per se, but I did not feel I should invest that much into nix (which I dislike) when the documentation leaves a lot to be desired. Ironically this also means that the whole idea behind NixOS, falls flat, if the documentation is poor. They really should make the same guarantees for their documentation, just as they do for the software ecosystem too.
Nobody cares about documentation anymore though - AI has won. Just try finding high quality documentation via google search; it is slop world now.
I tried NixOS and failed miserably. I've pointed at to the Fedora Atomic distros, which are also immutable, and apparently incomparably easier to setup.
I'm tempted to give it a shot, with the extra bonus that I've never dabbed with a fedora-based distro.
> There is also community-maintained support for FreeBSD, though I have not used it personally
I have tried to use the nix package manager on FreeBSD recently. I tried doing some basic things without success. Seems quite broken and unusable, which is a pity because nix on macOS seems decent. FreeBSD is much closer to Linux so there is no technical reason why nix can't be a success on FreeBSD.
nix on FreeBSD just needs more contributors to fix bugs and make popular packages work ! I wonder if it will ever happen. FreeBSD is niche and nix is somewhat niche (still). It's a double niche problem !
One thing I love about NixOS is how easy it is to run packages from different sources. For example, I needed an old package that's been removed from nixpkgs several years ago. To run it I just had to add an old release of nixpkgs as input to my flake.nix and add the package from this input. It pulls all its dependencies from that old release and there's zero conflict with the other packages.
The author almost touches on the one more topic that I adore about Nix, but ends up just so missing it: NixOS is absolutely incredible for its ability to be configured through AI tooling. And I don't mean that it's better than other operating systems, I mean that it's the only game in town.
I've been using Nix, both the package manager and the operating system, for years by now. I agree with all of the author's points, it really does deliver, the declarative nature is superb, and there's this constant sense of "hey my stuff is not breaking by itself" when working on it. And it's that declarative, rollback-able, file-based foundation, that makes it the perfect operating system for telling a coding agent to go to town on.
Would I trust Claude to switch my audio stack from Pulseaudio to Pipewire on Ubuntu? Would I trust Codex to install Hyprland on Fedora so I can test out the session? No, in fact I would not trust any agent to do any of those things on any other operating system. But I would trust even goddamn Grok to do that on NixOS, because I can 1) audit the changes before anything is done, and 2) rollback, rollforward, roll-whatever-the-way-I-want-even-on-the-floor-if-I-want-to because of the years of built up confidence proving that IT JUST WORKS.
I concede that this is turning into an unhinged loveletter to Nix, but really, it's the only operating system that lets one operate with this level of confidence. And I know most people don't care about that, since most people don't usually bother to tweak their OSes or switch out window managers, but as someone that does that, I'm never going back to mutable distros. This security is my table-stakes now, and the others aren't willing to pay up.
So for the developers out there on the lookout for their "Year of the Linux Desktop 2026" -distribution, if you're already using AI assistants, give NixOS a try. Maybe start with this in an empty Git repository: "Hey Claude, I wanna try NixOS. Make me a Flake-based starter config using Gnome that I can demo in a virtual machine. If nix isn't yet installed, install it via determinate-systems installer. Include a "vm" target in the flake for building the image, and a small bash script that builds and launches the VM using whatever virtualization is available on my platform."
I've recently switched to nix as a way to encode my environment across my server and work / private devices a bit more than just having some Brewfiles. I know it's not worth it for the computer switch every few years but having a somewhat opinionated place to centralize my config is worth it over regular dot files.
My first impression after a week of using:
- I really dislike the complexity of terraform, and this is very similar
- The UX is pretty bad, the commands and flags are hard to memorize and you basically need a shell alias for any regular commands to clean them up
- The commands you run regularly like applying your nix config to the system after adding some new packages or config options look like: "nix run nix-darwin -- switch --flake /Users/philipp/repos/github.com/dewey/nix#private"". The output is a mix between expected warnings and way to verbose for something that should essentially be the equivalent of "brew update / brew upgrade".
I'll stick with it as I didn't find anything better and LLMs are great for building up the config over time, but there's definitely room for some improvements.
I really want to like NixOS (and I mostly do) but the weirdness of the split between NixOS and HomeManager (and the fact that without HomeManager, you need another solution to manage your user-level configs) made it come up a bit short for me.
67 comments
[ 3.7 ms ] story [ 66.0 ms ] threadI feel like it's more of an indictment than praise; it implies Nix is relatively inaccessible to interested but time-constrained dabblers, which puts a hard cap on Nix's ability to outgrow its niche.
I'd much prefer just Plan 9. WORM filesystem and first-class namespaces.
For an example, I love atuin but it, by default, skips commands starting with space. Currently it's not configurable and while I wait for time to submit a PR or for the issue to be resolved, make a single line `patch` which just removes the part of the `if` statement which checks if it starts with space. So easy, took 5 minutes (also had to comment out 1 test).
And now on home-manager debian or nixos server, I get up to date atuin with that one patch. It downloads rust, etc, compiles, and then that's garbage collected away
Other than that I very much agree, patching stuff is wonderful in nix-land! Especially when things in nixpkgs-unstable break.
Is the Nix-ism to just reject using such software?
Personally, I don’t see the need for this with NixOS. Setting aside the fact that Omarchy is way too opinionated (Basecamp installed by default?), NixOS is already quite composable, so you can easily build a well-formed experience out of isolated NixOS modules.
* IMO Omarchy doesn’t make sense anyway, far too much opinion and too little utility. It’s not a distro it’s some guy’s overly promoted pile of crufty scripts and dotfiles.
My entire config is almost "omarchy", at least visually with hyprland and some other packages.
I had issues when giving boot partition only 512mb, so I'd recommend going with 1G.
I haven’t given it a shot in the LLM age yet though, and trying out NixOS in a VM is not only easy, it is practical – in the sense that when you’re happy, you can simply boot that same config/OS anywhere else by just installing that config. And I’ll never forget that one time where I completely borked my everything in the VM, did a kernel rollback with like 3 command line args and a reboot, and the OS was, well, rolled back. As I said, almost platonic.
What I can recommend is using nix-the-package-manager. Whenever I need the newest version of something, `nix-env -i <whatever>` and it’s there and works. If it doesn’t, roll back. If I need a different version, that’s on nixpkgs as well, with the same negligible amount of friction.
It's also simple to setup dev environments with nix.
The advantages:
- Declarative code describes your system. Maybe your install + imaging flow is good enough, but there are many reasons why it's technically inferior. There's no need for imaging Nix, because it's always reproducible by default. Rollbacks are rebooting to a previous config, not a timestamped blob of snowflake state.
- It replaces whatever tools and glue you have to build your system. You don't need to worry about bootstrapping tools, or config management tools' version compatibility, or bespoke ordering of imperative steps to build the system. All the management tools are built into the system. Everything "just works" automatically.
- If you manage multiple machines the benefits are compounding.
- There are other interesting bits that are covered in the article, that you get for free just due to the nature of nix. It's good for building, and has no friction to experimenting with specific tools or environments, without polluting your system.
It's a commitment to get past the initial learning and config build, but afterwards it significantly lessens the "hobby" aspects of computer management. There are just entire classes of problems that don't exist for Nix. Either your config works, or it doesn't, and the rollback guarantee is explicit and built-in.
A WIP NixOS config for working with agents:
https://github.com/dangirsh/tsurf
Everything seems scattered around a dozen forums, a hundred old blog posts, and a thousand issues of "this work on my machine (3 releases ago)".
And that's what's great about NixOS, you just clone nixpkgs and treat it like any other underdocumented software you might work on.
It's also great for the AI era, copilot is really good with that stuff.
I just use apt, been doing it for 20 years, it works great. I've never in my time, heard of or knew anyone who wrote 20 (or any) bash script wrappers around apt. The one year I was painfully forced to use a Mac for work, brew worked similarly to apt, just used it, no need to wrap it with shell scripts.
Comparing highly functional and capable systems like apt and brew to neanderthal technology sounds like hype.
> It's also great for the AI era
That also sounds like more hype, similar to the pro-nix other comments so far which tout AI and similar to the article which I did read, also sounds like hype.
I understand that "just check it out" is not the best advice because the setup cost to using nixOS is really high, and the learning curve is really steep, so it's not like you can give it a whirl for a few hours to experience the workflow. But believe me, once you are used to it, it just so so much more convenient. I'm currently managing my dev laptop, home PC, a WSL, and a hetzner server all in the same repository (allowing for a lot of code reuse). Everything is super orderly and split into modules, everything is declarative, I can roll back to a previous build of my system if I mess up installing nvidia drivers or iwd or bluetooth etc.
It's also not like installing software is harder than with apt (oftentimes it is easer, `programs.firefox.enable = true`) so after you've paid the setup cost there is just no downside. It's a bit like react vs jQuery, or Kubernetes vs hand-written deployment scripts.
My only gripe with NixOS is Nix. I think that this is also the biggest drawback of NixOS. I don't have an alternative; but perhaps it may be better to allow any format to be used, rather than force nix onto everyone.
Another issue is that, for a reason I don't quite understand, a few years ago NixOS' quality appears to have gone down, e. g. nobody cares about documentation anymore. This is probably not a huge obstacle per se, but I did not feel I should invest that much into nix (which I dislike) when the documentation leaves a lot to be desired. Ironically this also means that the whole idea behind NixOS, falls flat, if the documentation is poor. They really should make the same guarantees for their documentation, just as they do for the software ecosystem too.
Nobody cares about documentation anymore though - AI has won. Just try finding high quality documentation via google search; it is slop world now.
I'm tempted to give it a shot, with the extra bonus that I've never dabbed with a fedora-based distro.
> There is also community-maintained support for FreeBSD, though I have not used it personally
I have tried to use the nix package manager on FreeBSD recently. I tried doing some basic things without success. Seems quite broken and unusable, which is a pity because nix on macOS seems decent. FreeBSD is much closer to Linux so there is no technical reason why nix can't be a success on FreeBSD.
nix on FreeBSD just needs more contributors to fix bugs and make popular packages work ! I wonder if it will ever happen. FreeBSD is niche and nix is somewhat niche (still). It's a double niche problem !
I've been using Nix, both the package manager and the operating system, for years by now. I agree with all of the author's points, it really does deliver, the declarative nature is superb, and there's this constant sense of "hey my stuff is not breaking by itself" when working on it. And it's that declarative, rollback-able, file-based foundation, that makes it the perfect operating system for telling a coding agent to go to town on.
Would I trust Claude to switch my audio stack from Pulseaudio to Pipewire on Ubuntu? Would I trust Codex to install Hyprland on Fedora so I can test out the session? No, in fact I would not trust any agent to do any of those things on any other operating system. But I would trust even goddamn Grok to do that on NixOS, because I can 1) audit the changes before anything is done, and 2) rollback, rollforward, roll-whatever-the-way-I-want-even-on-the-floor-if-I-want-to because of the years of built up confidence proving that IT JUST WORKS.
I concede that this is turning into an unhinged loveletter to Nix, but really, it's the only operating system that lets one operate with this level of confidence. And I know most people don't care about that, since most people don't usually bother to tweak their OSes or switch out window managers, but as someone that does that, I'm never going back to mutable distros. This security is my table-stakes now, and the others aren't willing to pay up.
So for the developers out there on the lookout for their "Year of the Linux Desktop 2026" -distribution, if you're already using AI assistants, give NixOS a try. Maybe start with this in an empty Git repository: "Hey Claude, I wanna try NixOS. Make me a Flake-based starter config using Gnome that I can demo in a virtual machine. If nix isn't yet installed, install it via determinate-systems installer. Include a "vm" target in the flake for building the image, and a small bash script that builds and launches the VM using whatever virtualization is available on my platform."
My first impression after a week of using:
- I really dislike the complexity of terraform, and this is very similar
- The UX is pretty bad, the commands and flags are hard to memorize and you basically need a shell alias for any regular commands to clean them up
- The commands you run regularly like applying your nix config to the system after adding some new packages or config options look like: "nix run nix-darwin -- switch --flake /Users/philipp/repos/github.com/dewey/nix#private"". The output is a mix between expected warnings and way to verbose for something that should essentially be the equivalent of "brew update / brew upgrade".
I'll stick with it as I didn't find anything better and LLMs are great for building up the config over time, but there's definitely room for some improvements.