There is a similar question on the site which must not be named.
My question still has a little different spin:
It seems to me that one of the biggest selling points of Nix is basically infrastructure as code. (Of course being immutable etc. is nice by itself.)
I wonder now, how big the delta is for people like me: All my desktops/servers are based on Debian stable with heavy customization, but 100% automated via Ansible. It seems to me, that a lot of the vocal Nix user (fans) switched from a pet desktop and discover IaC via Nix, and that they are in the end raving about IaC (which Nix might or might not be a good vehicle for).
When I gave Silverblue a try, I totally loved it, but then to configure it for my needs, I basically would have needed to configure the host system, some containers and overlays to replicate my Debian setup, so for me it seemed like too much effort to arrive nearly at where I started. (And of course I can use distrobox/podman and have containerized environments on Debian w/o trouble.)
Am I missing something?
In this comparison, the devil is in the detail.
With Ansible, you have an initial condition onto which you add additional state through automatically executed steps dictated by you until you (hopefully) arrive at a target state. This all happens through modification of one set of state; each step receives the state of the previous step, modifies it and passes the entire state onto the next step. The end result is not only dependant on your declared steps but also the initial state. A failure in any step means you're left in an inconsistent state which is especially critical for the case of updating an existing state which is the most common thing to do to a Linux system.
In NixOS, you describe the desired target state and the NixOS modules then turn that description into compartmentalised bits of independent state. These are then cheaply and generically combined into a "bundle"; wrapping them into one big "generation" that contains your entire target state.
Your running system state is not modified at any point in this process. It is fully independent, no matter what the desired system is supposed to be. It is so independent in fact that you could do this "realisation" of the NixOS system on any other system of the same platform that has Nix installed without any information about the state of the system it's intended to be deployed on.
This "bundle" then contains a generic script which applies the pre-generated state to your actual system in a step that is as close to atomic as possible.
A good example for this are packages in your PATH. Rather than sequentially placing the binaries into the
/usr/bin/directory as a package manager would when instructed by ansible to install a set of packages, NixOS merely replaces thebinsymlink with one that points at an entirely new pre-generated directory which contains the desired packages' binaries (well, symlinks to them for efficiency). There cannot possibly be an in-between state where only some of the binaries exist; it's all or nothing. (This concept applies to all parts that make up a Linux system of course, not just binaries in the PATH. I just chose that as an easy to understand example.)By this property, your root filesystem no longer contains any operating system configuration state. You could wipe it and NixOS would not care. In fact, many NixOS users do that on every boot or even use a
tmpfsfor/.(Immutability is a property that NixOS gains almost by accident; that's not its primary goal.)
Nice, thank you very much for this great summary!
In my own words, you describe the difference between declarative vs. imperative configuration and the joy of atomic updates. :-)
I just want to add one point: Theoretically I totally agree, that one might have a bad state in Ansible and the updated state is spoiled, and of course configuration drift is a theoretical problem via Ansible. In practice I never run into this problems in 10+ years of using Ansible. (Of course I treat servers/desktop as cattle, so every major revision of Debian means a complete/clean new installation.)
If it works for you, that's great.
I find it a lot more convenient to treat every change about my system as a nearly complete/clean new installation though and NixOS allows you to do so. An upgrade between major versions becomes a walk in the park due to this; it's the M.O. The last one didn't require any modification of the config on my NAS. I remotely rebuilt the system from my MacBook Pro with the new channel, rebooted to get the newer kernel and everything worked just like before.