[mrslave]

It's more like the whole upgrade is either successful, or it is not, and you are not left in an indeterminate state.

E.g. A depends on B. In a large update, B updates, something unrelated fails to install and the update fails, and now A doesn't run because it wasn't upgraded and the still installed old version of A depends on the no longer available previous version of B.

In NixOS, you either enter the new environment with all packages updated, or you don't. In the situation where you discover run-time - not install-time - errors, you can simply roll back to the previous set of packages. If the new packages cause a system crash, you can enter previous states from the bootloader.

Now none of this magically solves the software defects themselves. But it gives you a consistent system state that can be transactionally upgraded, or reentered at any time. And then you can raise the appropriate bug tickets.

Your system configuration is in a single file and the need to reconfigure different services in a particular order is gone.

Also your dependencies are all nicely pinned with Flakes. This makes importing arbitrary dependencies - open-source or proprietary - a breeze. This has removed any previous appetite we had for a monorepo, which was primarily to ease access to our other libraries.

It's all very nice, once you are over the not insubstantial learning curve that is.

[pdimitar]

Yes, the updates treated like a DB transaction are the main draw of Nix and I agree they're nice. However, Fedora and recently Manjaro started offering the so-called "immutable" versions that do nearly the same: you can install and delete and do whatever you like but you also have to explicitly opt in to commit those changes to your bootable image. If you don't do it they're just discarded after you reboot.

That's quite awesome and saves me from 99% of the problem you described... without having to learn the Nix's weird language or be willing to read cryptic error messages and get roasted on Reddit for not knowing them by heart.

[1oooqooq]

i guess i cannot imagine the kind of problems you were having before :)

but from the description they seem runtime errors. do you have a functional test of sorts after nix creates the new state?

[mbrock]

Look at Debian's official instructions for how to upgrade to a new major release. The wiki page begins with this casual disclaimer:

"DANGER!!! DANGER!!! DANGER!!! DANGER!!! DANGER!!!

DANGER!!! DANGER!!! DANGER!!! DANGER!!! DANGER!!!"

The release notes for each version has the detailed instructions for how to upgrade from the previous version. They very strongly emphasize backing up the entire system, because the upgrade process is absolutely not guaranteed to leave the computer in a state that works correctly or boots at all, and there is no way to undo it.

That's what's different about NixOS: if the new configuration doesn't work properly, you can just choose the previous configuration in the bootloader menu. It's as straightforward and foolproof as switching to another branch in a Git repository. The whole point of NixOS is that you can have any number of system configurations in the Nix store and switch between them in a way that's atomic in the transactional sense.

If you know how Nix works, you can feel safe turning off the power supply at any point during a full system upgrade. You'll never end up in a state where half of the packages are upgraded. It's either upgraded or not. As far as I know there's no other distribution that works like this other than GuixSD.

[JamesSwift]

NixOS supports adding tests which are selenium-style integration tests run on VMs