Happy to answer!

Here’s an example commit where I last updated my system packages. I’ve been on summer holiday so it’s already been a month haha.

It’s basically going into my dotfile/configuration repo, running nix flake update nixpkgs which bumps the lock file as seen in the commit and then running nixos-rebuild and committing it. A bit like bumping npm dependencies.

If something doesn’t work, I just git reset the change and rebuild again, which is almost instant as all the previous packages are still stored on my system until I explicitly garbage collect them.

And if there’s a kernel/driver issue I only catch after a reboot, I can just directly boot into the previous build straight from GRUB as nixos automatically manages the grub entries and keeps a history of previous builds.

Of course there’s also sometimes cases where some package breaks but I’d don’t want to postpone updating the whole system just because of that particular package. For those cases I also have a separate input named “nixpkgs-2111” that tracks the current stable branch of nixos. I can then explicitly configure the specific package to be built from that revision of the repo.

Another nice thing is that once I’ve bumped the system on my personal computer, I’ll just pull the commit on my work laptop and run nixos-rebuild on that machine. This way I can guarantee that both the machines have exactly same software versions.

NixOS seems like basically a replacement for any distro + Salt (or any other config management platform) + snapshots

NixOS does accomplish those things. However it has also other benefits, such as running multiple versions of the same software simultaneously, guaranteed complete dependencies and the fact that upgrades and rollbacks are atomic. Immutability also ensures no state drift happens.