It’s better to use a bind mount: nix-store --query - Nix Reference Manual
It’s the definition of reproducibility.
OSTree (the technology that powers Fedora Silverblue), just like Docker, Flatpak or Podman, lets you reproduce the outcome of a build. But if you build a 2nd time, you can get a different output.
Nix lets you reproduce the full building process. No matter how many times you build, you’ll get the same result.
Thus, when you package anything with nix, you’re sure that it is exactly what you meant. When you share a devshell with your colleagues, you know it’ll work exactly like locally. When a system update breaks one package build, you can pin that old build while still keeping the rest of the system updated.
Besides, you can have multiple versions of the same library without any conflicts, and each package can use the one supported by it.
NixOS was very influential to the OSTree project, but they still decided to create OSTree because Nix has its downsides too. It’s basically 2 approaches to the same problem, each one with their tradeoffs.
I’ve been a long time Fedora user, and it’s easier to start using nix by just installing the package manager on top of your current known system.
At some point, I plan to switch to NixOS if it proves to be at least as useful as Fedora for a workstation.
I use NixOS on servers these days, and I’m probably never looking back. It’s absolutely awesome.
Contradicting myself, these days a new nix installer exists, with OSTree distro support: GitHub - DeterminateSystems/nix-installer: Install Nix and flakes with the fast and reliable Determinate Nix Installer, with over a million installs.
Once you install Nix, it updates itself. Thus, it’s not very useful to install it through an RPM (outside of the fact that Silverblue users feel that’s easier for them, like myself in the past).