Just glancing at it (FYI, I run NixOS on my main dev machine), it looks like it uses ABRoot which gives you 1 install to fall back on if 1 fails. I love that NixOS gives me N installs to fall back on (where N is whatever you configure it to be) because I've often needed to go back more than 1 to identify a problem that I didn't notice until 2-3 updates later.
Actually, as a natural tinkerer, what I call the "NixOS seatbelts" (being able to pick any of the last N updates via GRUB to boot into) have saved me numerous times already. I no longer feel comfortable using any other Linux distro. The declarative config and per-project dev environments are cake as well (once you get past the Nix language, which is basically just "JSON-like, plus pure functions")
My main problem with Nix isn't the language, which is fine. My problem is that Nix shoehorns everything into it; I have to write my nginx config (for example) in Nix for some bespoke nixpkg.
I would much rather just version my nginx config written in nginx config, and let Nix pull that up, or something like that. Then you get all the benefits of Nix (I think?) but my configuration is also readable for someone who doesn't know Nix. Plus I can use my existing knowledge (as well as the wealth of online available docs), instead of something obscure.
NixOS needs to handle generating the config to make service configurations composable. If you don't want that, you might as well write your own systemd unit.
That being said, most services have an option to use verbatim configuration files[0] or fragments[1][2][3].
> If you don't want that, you might as well write your own systemd unit.
This might sound glib, but it's a great idea for a simple workaround for users who want to use some other system to template their config files. Wouldn't take much boilerplate at all.
