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."
As a NixOS user for 3 years, and a Claude user for 1+ year, I agree with you that it's an ideal fit. I've been very happy with, for example, how Claude can configure GNOME via dconf settings: tweaking those settings declaratively requires cross-domain knowledge and knowing where to dig. But Claude just knows.
But trying to set up an environment for one of those perpetually running AIs, and asking it to refactor its own configuration according to some of the high-level abstractions like dendritic flake-parts, and so on, it's just clueless and will improvise without success.
What makes Nix hard for humans also makes Nix hard for AIs: Untyped lambdas that get resolved in some implied out-of-file context means you have to know if you're looking at a NixOS module, a home-manager module, a nix-darwin module, a flake-parts module, and so on. And those modules may make assumptions about what's imported in the parent scope.
So I feel like you need to supply a rather extensive context for your project that details how you want things structured, because the ecosystem is quite fragmented, people don't fully agree on what good patterns are, and so the AI can't know what the good patterns are.
Just to be absolutely clear: I think that supplying an extensive context is absolutely worth it, and I'm having great joy and success building better Nix-based project templates, Nix-based deployment templates, etc. The amount of stable, well-made projects made by other Nix users is just amazing.
I just migrated my personal website to nixos and can second all of this. There's a learning curve, but the time to provision a new server once it's all working is hilariously short.
I use debian + ansible and it requires discipline (you have to make sure you never do manual steps basically) but my entire ansible playbook makes server creation a 3 min process.
I'm sure Nix is better, I just haven't needed it yet.
> it requires discipline (you have to make sure you never do manual steps basically)
Since Nix requires a declarative configuration, you need less discipline, but more up-front specification. For example, making truly idempotent Ansible scripts requires a lot of effort and some strong assumptions about your starting state and what processes piped changes into your state, and what your state changes really mean. Also, running your playbook with newer version of the same software may lead to a different result. For example, migrating from bullseye to bookworm with a cargo-deb that contained dependencies: It turned out that there were implied dependencies taken for granted in bullseye that were removed in bookworm. With Nix this will lead to a build error rather than a deployment error or a runtime error (in most cases).
Nix requires fewer assumptions.
> my entire ansible playbook makes server creation a 3 min process
I'm a big fan of Ansible, and everything has its use.
I like to categorize deployment tools as either "bottom-up" or "top-down" depending on what assumptions you make about the world: Ansible fills the slot where you have no control of how the server got there, but you gotta make use of what you have, and start from scratch. Terraform is the canonical bottom-down tool: You assume you have perfect control of what gets provisioned, and that it won't go away or go out-of-sync without active maintenance.
In this top-down/bottom-up topology, Nix can fill the whole spectrum; most people assume Nix/NixOS is available to them, at which point their automation starts. Others deploy NixOS via various automated processes that can be integrated with both top-down or bottom-up solutions, e.g. distribute via network boot, VM image repository, or via "hostile takeover" (deploy on existing Linux machines via SSH, like Ansible, or using Ansible).
oh yeah AI realy does not seem to actually know which packages exist. I once asked AI to create a devenv for some Julia development and it pulled some packages out of its ass that just plain did not exist.
I've been trying to get nixd LSP to work with Claude Code but I got stuck as they gatekeep it behind their "plugin" system and you can't just configure it in settings.json to point to a nix store path like mcps :(
My usual solution is to just clone whatever I need. e.g. in this case just clone nixpkgs and put in your instructions that it should do a git pull to make sure it's up to date and then refer to that whenever doing anything with nix. Agents are really good at using grep to explore repos even for something completely internal. Then you don't need any config or special tools. e.g. for work I just have a directory with like 30 repos cloned and my base AGENTS file I use says to refer to either them or live system state for ground truth. I basically never encounter hallucinations.
Same goes for the harness itself. Want to know how Codex works or whether it can be configured in some way? Clone it and ask it to look at itself.
This feels like a very high-tech solution to a problem that doesn't really exist. Why involve an LLM to install Hyprland when "sudo dnf install hyprland" works fine? I feel like you're mistaking Nix being 'AI-ready' as a feature, when in reality, you're just forced to use an LLM because Nix is too annoying to manage manually.
The key point is that all such tweaks to the system is managed in a one configuration file. While installing Hyprland may be a one-liner, configuring it and all other services from a single entry point is incredibly liberating.
Reverting changes are guaranteed to not leave behind any cruft, and you don't have to remember what you changed to make X or Y work: it's all visible in the (usually version controlled) system configuration.
Got a new computer? Just copy the configuration and enjoy a bit-identical system in seconds. Have an LLM tweak it and see the changes in the form of git diffs.
Sure, you can do the same with Silverblue and writing Ansible for everything, but it's not free of side effects (unlike Nix).
The problem that exists is that you cannot just willy nilly try out entirely different desktop envs/window managers/audio frameworks on an existing install of any other distro and be certain everything will work exactly as it was when you remove it. Especially as an only moderately knowledgeable user that won't know every single piece of config that needs to be changed back. Unless you're trying everything new out on a fresh install then there's a big risk.
NixOS gives you that just by opting in to using it, and while AI also speeds up config changes and translating your existing knowledge to a new tool you're trialing in other distros as well it really shines with NixOS where you don't even have to care what it messes up while you're trying something new. You just revert and you know that nothing that was done to configure that new thing - which likely would have broken your existing configuration on other distros - has persisted.
I use Nix for my homelab servers, and I'm using AI to be my IT support staff essentially. I don't need to ask AI for help installing hyperland, that is trivial as you say, but setting up nginx port forwarding? samba configs? k3s or k8s? Yeah individually any one of those things isn't very hard. But instead of spending 30 minutes reading through config examples and figuring out where it's setup I can instead spend 30 seconds just telling AI what I want, skimming the output to see if it's looks reasonable, and then doing a good ol' git commit of the config file & kicking off the "now go do it" nix build command.
And, critically, at no point does an LLM ever have access to sudo, shell, etc.. It just works with plain text files that aren't even on the machine I'm deploying it to.
I was looking at hyperland in Fedora this week. I wanted to try out the latest release (released two weeks ago give or take). It wasn't available yet (maybe it isn't still). That's ok, but I checked what would I have needed to do to build it myself, and I didn't want to mess with a bunch of dev dependencies I didn't really care about and that I would have forgotten, so I ended up not trying it
I think they just mean that the fat that they can do it this way says a lot about the os. No need to get into the weeds on exactly how to install hyprland. It was an example.
People who get bogged down by the details of examples/analogies are usually missing the point of why people use examples/analogies.
I literally just fixed a couple of nagging config issues that I couldn't be bothered to find in my (admittedly complex) set of NixOS and HM config files by asking Claude to find and fix them.
I had Claude do the grunt work of shifting parts of my config to a new structure I started but didn't have time to fully implement.
Based on examples I provided, I had Claude use specialisations to set up a couple of different WM and DE test environments.
And the thing is that, now that I have everything set up the way I want, I don't really have to DO anything to keep the system running, other than occasionally update (I'm on unstable, so I do that manually).
Could I turn Claude loose on my .config directory, give it access to apt or dnf (etc.), and let it set up a non-NixOS environment for me? Probably, and it would probably work reasonably well, but I wouldn't trust it the way I trust NixOS.
I waited for AI to get better before adopting Nix as it seemed to be rather arcane, a bit like Arch Linux, and I was worried I wouldn’t have the time for it. In preparation I shifted my development environments entirely to docker scripts where I can copy and paste working snippets from the internet.
Nix and AI is a match made in heaven and I think we’re going to see a lot of good software that’s amenable for us by AI that is both cheaper to build and easier to use.
It's unreal. I've packaged so many super daunting packages that would take myself weeks to package (and some that I've tried and failed to package). I have 6 years of daily driving nixos...So I'm not exactly new to the distro.
Even messing with stdenv or language builders is trivialized. Any software that I want, I can get within a few hours of claude/codex just spinning unsupervised.
It's so nice! Underrated for sure.
I put a Claude Code token on all my machines, local and cloud. Machines now practically fix themselves. Especially with NixOS, as soon as the basic install runs, it gets the Nix claude-code package. It's all downhill after that. OpenClaw hit a few weeks ago, so I took an ancient PC lying around, put NixOS on it, added Claude Code, and then Claude installed OpenClaw. Claude, tell me about the security posture of OpenClaw. "Would you like me to turn on the exec permissions feature and disable dangerous commands?" Claude does that and then turns around and tests that they are really turned off. My Telegram bot gets confused: "I'm sorry, I don't have a shell/exec to run that command. How did I run anything a few minutes ago?"
Sometimes it's nice to throw an LLM at some Nix stuff but I find that unless you're comfortable with the Nix language itself and have spent a tiny amount of time writing a derivation you might introduce quite a few footguns along the way. That said these days when I need a development flake I just point a LLM at the repo and it mostly figures out what's needed. It's just that Nix lends itself pretty well (sadly) to poking around in the dark (yes, I know about the REPL).
I would just like to give this a big ol’ +1. I did not like Nix when I started. The ergonomics are hard to get around, but the power is honestly hard to overstate.
Coding agents actually help with a lot of the ergonomic issues. If you have an evaluation issue, it can be annoying to climb into nixpkgs to diagnose it. But codex will do that for you.
I’ve found agenix in particular to be really great addition for agents: secrets you can copy around without risk of accidental disclosure.
In a day I can now deploy Caddy, Authentik, Fleet, Headscale, Stalwart, jmap-webmail, Forgejo, SFTPGo, Immich, Grafana, Jaeger, PostHog, etc. and have them all work together. I can do this on a tiny VPS, and codex can actually estimate and test performance to minimize cost.
The equivalent Kubernetes setup wastes so much on isolation and a scheduler that is overkill for anything small.
I'm not sure how I would've configured my dotfiles without AI. The nix syntax is a bit daunting, but the rollback feature makes me feel confident in modifying my system agentically. The main setbacks are the non-fhs filesystem, which both applications and agents generally expect.
I recently fixed the pipewire audio stutters by just giving gemini my flake and asking how to fix it. It suggested a few fixes and low and behold they were gone! Here's my flake with impermanence + yubikey login: https://github.com/leonewt0n/nixos
I knew my flake setup could be better but never bothered. Then one day earlier this year I threw Claude at it. Not only did it improve everything, it fixed a small bug that had been bothering me.
My confidence in doing this came from exactly what you said: If it blows everything up I can just rollback.
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.
I tried NixOS a few months ago, when I had to choose a new OS for my laptop.
On the one hand, it's great, as so many others here and TFA have attested. Declaratively specifying your system configuration and using snapshots to keep track of everything is a complete game-changer. Similarly great is the absolutely huge universe of installable packages. The coverage here is so much better than what's on offer from Ubuntu or Fedora.
On the other hand, the current implementation is still a bit of a shit-show.
First, there's nix-the-OS and nix-the-package-manager which is pretty confusing. Effectively it means you manage your OS with one declarative system and your local/home config with another. Then there's "Flakes" which I never quite understood, that seem to offer a different modality altogether.
Second, installing packages is nice, but also confusing. Do you install a package or a service? Often both are available and the difference is not always clear. Eventually I learned to choose a service whenever one was available. In either case, the tendency of package maintainers is to install the smallest possible version of whatever you asked for. For example, I wanted KDE but what I got was a bare minimum version with plenty of missing apps and functionality that could only be fixed by adding extra components, one at a time, after debugging whatever was currently breaking.
I appreciated that services and packages can be configured in the configuration file. But the options exposed are usually a partial set of what's available -- without extending the installations scripts yourself. So now my "declarative" config is a mix of what's in my nixOS config file and what's in my manually edited /etc files.
Third, the documentation, mentioned by others, is a mess. There's all kinds of information about old and new versions. The interfaces of the command-line tools seem to have changed between the 25.05 stable that I chose and the then-upcoming 25.11, which made following-along harder than it needed to be.
I eventually gave up because I needed a working machine and not a new hobby. I was left with the impression that NixOS might be a good choice for system admins, but perhaps not yet ready for desktop Linux users.
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.
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.
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?
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.
I liked NixOS pre-LLM era, since it allowed me to manage a couple of servers in a reproducible way. Ability to reboot back to a stable configuration felt like magic.
Nowadays I love it, since I can let Codex manage the servers for me.
“Here is the flake, here is nix module for the server, here is the project source code. Now change all of that so that wildcard certificates work and requests land through systemd socket on a proper go mux endpoint. Don’t come back until you verify it as working”
I feel the same way about Guix with nonguix channel enabled. NixOS is awesome but I prefer Guile to Nix's language and I enjoy the docs more. But definitely sister OSes.
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?
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.
I still really wish there was a NixOS, but without the quirky filesystem/linking setup.
Declarative, but not trying to solve for the "I want 5 versions of python at the same time" problem. The weird NixOS filesystem is where 90% of my Nix issues come from. And I don't feel like I benefit from it much, if at all. Bonus points if this fictional solution doesn't use a fancy new programming language. Something like HOCON would be perfect.
I just want the same OS, packages and config on all my machines without allowing long-term drift. And I want the time I spend tweaking my Linux setup to be an investment, not a waste of time that gets thrown away when I upgrade. I know I could use home-manager or similar for my user-level config, but that's not enough.
I've been experimenting with the immutable fedora-bootc images and podman+Containerfiles, which works pretty well for this. But there's no "nixos-rebuild switch" command, so changes require a reboot. Fine for daily use, but very painful when experimenting. I did discover its possible to use the older dnf4 --transient flag to temporarily install packages, which is helpful.
I guess its a trade-off between easy tinkering (Nix) but frustrating filesystem vs fussy tinkering (bootc) but standard linux filesystem once booted.
313 comments
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."
But trying to set up an environment for one of those perpetually running AIs, and asking it to refactor its own configuration according to some of the high-level abstractions like dendritic flake-parts, and so on, it's just clueless and will improvise without success.
What makes Nix hard for humans also makes Nix hard for AIs: Untyped lambdas that get resolved in some implied out-of-file context means you have to know if you're looking at a NixOS module, a home-manager module, a nix-darwin module, a flake-parts module, and so on. And those modules may make assumptions about what's imported in the parent scope.
So I feel like you need to supply a rather extensive context for your project that details how you want things structured, because the ecosystem is quite fragmented, people don't fully agree on what good patterns are, and so the AI can't know what the good patterns are.
Just to be absolutely clear: I think that supplying an extensive context is absolutely worth it, and I'm having great joy and success building better Nix-based project templates, Nix-based deployment templates, etc. The amount of stable, well-made projects made by other Nix users is just amazing.
https://simonshine.dk/articles/hugo-static-site-setup/
https://simonshine.dk/articles/vendoring-hugo-themes-with-ni...
My blog is deployed here:
https://github.com/sshine/nix/blob/main/services/nginx.nix#L...
I'm sure Nix is better, I just haven't needed it yet.
> it requires discipline (you have to make sure you never do manual steps basically)
Since Nix requires a declarative configuration, you need less discipline, but more up-front specification. For example, making truly idempotent Ansible scripts requires a lot of effort and some strong assumptions about your starting state and what processes piped changes into your state, and what your state changes really mean. Also, running your playbook with newer version of the same software may lead to a different result. For example, migrating from bullseye to bookworm with a cargo-deb that contained dependencies: It turned out that there were implied dependencies taken for granted in bullseye that were removed in bookworm. With Nix this will lead to a build error rather than a deployment error or a runtime error (in most cases).
Nix requires fewer assumptions.
> my entire ansible playbook makes server creation a 3 min process
I'm a big fan of Ansible, and everything has its use.
I like to categorize deployment tools as either "bottom-up" or "top-down" depending on what assumptions you make about the world: Ansible fills the slot where you have no control of how the server got there, but you gotta make use of what you have, and start from scratch. Terraform is the canonical bottom-down tool: You assume you have perfect control of what gets provisioned, and that it won't go away or go out-of-sync without active maintenance.
In this top-down/bottom-up topology, Nix can fill the whole spectrum; most people assume Nix/NixOS is available to them, at which point their automation starts. Others deploy NixOS via various automated processes that can be integrated with both top-down or bottom-up solutions, e.g. distribute via network boot, VM image repository, or via "hostile takeover" (deploy on existing Linux machines via SSH, like Ansible, or using Ansible).
But the cut-off point in model / harness quality before it hallucinates everything but the general Nix syntax is staggeringly low.
Same goes for the harness itself. Want to know how Codex works or whether it can be configured in some way? Clone it and ask it to look at itself.
Reverting changes are guaranteed to not leave behind any cruft, and you don't have to remember what you changed to make X or Y work: it's all visible in the (usually version controlled) system configuration.
Got a new computer? Just copy the configuration and enjoy a bit-identical system in seconds. Have an LLM tweak it and see the changes in the form of git diffs.
Sure, you can do the same with Silverblue and writing Ansible for everything, but it's not free of side effects (unlike Nix).
NixOS gives you that just by opting in to using it, and while AI also speeds up config changes and translating your existing knowledge to a new tool you're trialing in other distros as well it really shines with NixOS where you don't even have to care what it messes up while you're trying something new. You just revert and you know that nothing that was done to configure that new thing - which likely would have broken your existing configuration on other distros - has persisted.
git commitof the config file & kicking off the "now go do it" nix build command.And, critically, at no point does an LLM ever have access to sudo, shell, etc.. It just works with plain text files that aren't even on the machine I'm deploying it to.
programs.hyperland.enable = true
is your dnf equivalent on nix. But nix also lets you declare all your key bindings, load Noctalia with systemd, etc.
People who get bogged down by the details of examples/analogies are usually missing the point of why people use examples/analogies.
I had Claude do the grunt work of shifting parts of my config to a new structure I started but didn't have time to fully implement.
Based on examples I provided, I had Claude use specialisations to set up a couple of different WM and DE test environments.
And the thing is that, now that I have everything set up the way I want, I don't really have to DO anything to keep the system running, other than occasionally update (I'm on unstable, so I do that manually).
Could I turn Claude loose on my .config directory, give it access to apt or dnf (etc.), and let it set up a non-NixOS environment for me? Probably, and it would probably work reasonably well, but I wouldn't trust it the way I trust NixOS.
Nix and AI is a match made in heaven and I think we’re going to see a lot of good software that’s amenable for us by AI that is both cheaper to build and easier to use.
Even messing with stdenv or language builders is trivialized. Any software that I want, I can get within a few hours of claude/codex just spinning unsupervised. It's so nice! Underrated for sure.
>
it's the only game in townHey now, LLMs are pretty good at Guix, too.
Coding agents actually help with a lot of the ergonomic issues. If you have an evaluation issue, it can be annoying to climb into nixpkgs to diagnose it. But codex will do that for you.
I’ve found agenix in particular to be really great addition for agents: secrets you can copy around without risk of accidental disclosure.
In a day I can now deploy Caddy, Authentik, Fleet, Headscale, Stalwart, jmap-webmail, Forgejo, SFTPGo, Immich, Grafana, Jaeger, PostHog, etc. and have them all work together. I can do this on a tiny VPS, and codex can actually estimate and test performance to minimize cost.
The equivalent Kubernetes setup wastes so much on isolation and a scheduler that is overkill for anything small.
I knew my flake setup could be better but never bothered. Then one day earlier this year I threw Claude at it. Not only did it improve everything, it fixed a small bug that had been bothering me.
My confidence in doing this came from exactly what you said: If it blows everything up I can just rollback.
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)".
On the one hand, it's great, as so many others here and TFA have attested. Declaratively specifying your system configuration and using snapshots to keep track of everything is a complete game-changer. Similarly great is the absolutely huge universe of installable packages. The coverage here is so much better than what's on offer from Ubuntu or Fedora.
On the other hand, the current implementation is still a bit of a shit-show.
First, there's nix-the-OS and nix-the-package-manager which is pretty confusing. Effectively it means you manage your OS with one declarative system and your local/home config with another. Then there's "Flakes" which I never quite understood, that seem to offer a different modality altogether.
Second, installing packages is nice, but also confusing. Do you install a package or a service? Often both are available and the difference is not always clear. Eventually I learned to choose a service whenever one was available. In either case, the tendency of package maintainers is to install the smallest possible version of whatever you asked for. For example, I wanted KDE but what I got was a bare minimum version with plenty of missing apps and functionality that could only be fixed by adding extra components, one at a time, after debugging whatever was currently breaking.
I appreciated that services and packages can be configured in the configuration file. But the options exposed are usually a partial set of what's available -- without extending the installations scripts yourself. So now my "declarative" config is a mix of what's in my nixOS config file and what's in my manually edited /etc files.
Third, the documentation, mentioned by others, is a mess. There's all kinds of information about old and new versions. The interfaces of the command-line tools seem to have changed between the 25.05 stable that I chose and the then-upcoming 25.11, which made following-along harder than it needed to be.
I eventually gave up because I needed a working machine and not a new hobby. I was left with the impression that NixOS might be a good choice for system admins, but perhaps not yet ready for desktop Linux users.
It's also great for the AI era, copilot is really good with that stuff.
It's also simple to setup dev environments with nix.
Nowadays I love it, since I can let Codex manage the servers for me.
“Here is the flake, here is nix module for the server, here is the project source code. Now change all of that so that wildcard certificates work and requests land through systemd socket on a proper go mux endpoint. Don’t come back until you verify it as working”
5 minutes later it came back.
Is the Nix-ism to just reject using such software?
Declarative, but not trying to solve for the "I want 5 versions of python at the same time" problem. The weird NixOS filesystem is where 90% of my Nix issues come from. And I don't feel like I benefit from it much, if at all. Bonus points if this fictional solution doesn't use a fancy new programming language. Something like HOCON would be perfect.
I just want the same OS, packages and config on all my machines without allowing long-term drift. And I want the time I spend tweaking my Linux setup to be an investment, not a waste of time that gets thrown away when I upgrade. I know I could use home-manager or similar for my user-level config, but that's not enough.
I've been experimenting with the immutable fedora-bootc images and podman+Containerfiles, which works pretty well for this. But there's no "nixos-rebuild switch" command, so changes require a reboot. Fine for daily use, but very painful when experimenting. I did discover its possible to use the older dnf4 --transient flag to temporarily install packages, which is helpful.
I guess its a trade-off between easy tinkering (Nix) but frustrating filesystem vs fussy tinkering (bootc) but standard linux filesystem once booted.
A WIP NixOS config for working with agents:
https://github.com/dangirsh/tsurf