[microtonal]

For example, I think it's one of the best distros to run a common Linux desktop setup because you can upgrade without fear and you can test new things without adding clutter.

You can use Fedora Silverblue, which also offers atomic upgrades and rollbacks, offers support for regular RPMs as an escape hatch. It provides meaningful desktop security (verified secure boot, kernel lockdown mode, SELinux, some application sandboxing in Flatpaks). But you don't have to learn a functional language and ecosystem that is completely foreign to most people.

Oh, and Steam doesn't break all the time :).

I think Nix is great, but I wouldn't recommend most desktop users to use NixOS on the desktop, unless you are willing to invest a lot of time.

[grumbel]

> You can use Fedora Silverblue, which also offers atomic upgrades and rollbacks

The beauty of Nix with Flakes is not just upgrades and rollbacks, but that it can be completely stateless. You can just run software directly from the Git repository:

   nix run github:JUser/your_app

And if you want an old or newer version, just go:

   nix run github:JUser/your_app?rev=01f352202ad

You can even override dependencies if you like:

   nix run --override-input somlib git+file:///yourlocalfork github:JUser/your_app

There isn't a whole lot of software that has turned their Git repository into a Flake yet (i.e. added a flake.nix), so that benefit is a bit theoretical for the average user, but the potential to completely reshaping the Free Software landscape is certainly there, as Nix finally allows upstream to become a first class citizen in the distributions packaging system.

[microtonal]

There isn't a whole lot of software that has turned their Git repository into a Flake yet (i.e. added a flake.nix)

As long as the project developers are not going to use Nix themselves, there are going to be a lot of unmaintained, broken flakes. All dependencies are pinned, but the project itself may move on from what is specified in the flake. A bunch of my own projects were flakes [1], but they would regularly break, because the project would move on (e.g. requiring a newer version of libtorch), but I forgot to update flake.nix/lock.

Of course, you can still run historical versions, but when the main path doesn't work, many users will just move on. So, including Nix flake files becomes more of a liability to a project than an asset.

(Besides that, it probably fills your store with many, potentially vulnerable versions of glibc and whatnot due to use of many different nixpkgs revisions, a problem that the centralized nixpkgs package set doesn't have.)

[1] I even implemented/contributed the cargoLock functionality, so that you can use buildRustPackage (rather than an external solution) without needing to specify the Cargo vendoring hash to make it easier to use buildRustPackage in your own repositories:

https://nixos.org/manual/nixpkgs/stable/#importing-a-cargo.l...