Sure.

Both distros build an "immutable system," but in very different ways. Keep in mind that both of these effortlessly deal with rollbacks.

Nix

With NixOS you declare your entire OS in a script, something along the lines of Ansible or Terraform. This can even go as far as configuring your user settings, with dotfiles, gsettings, or various other things (often the modules will expose settings in the native nix language and write out the yaml/toml/json/whatever else that is required). The idiomatic way to do this is to use the built-in NixOS configuration (under /etc/nixos) to set up system-level things: mounts, drivers, users, system-level packages (e.g. greetd+sway), and things that change rarely. You then use a project called home-manager to manage everything inside your user configuration (including applications you use), which itself uses nix. By separating it like this, I can sync my entire experience between my laptop and desktop with Git.

I am currently flighting using a separate "nix flake" for both, which allows you to pin versions of packages (with a lockfile). It also allows you to easily pull in other repositories. It hasn't really taken off yet, and the NUR (Nix User Repository, analogous to the amazing Arch User Repository) is still in infancy. I'd offer up my nix configs as an example, but I am currently in the "make it work" example. I have been yoinking several great ideas from this fantastic nix repo: https://github.com/ymatsiuk/nixos-config

The main challenge with Nix is that it doesn't have an FHS: there is no `/usr`, `/bin`, and what you would typically expect. The advantage here is that conflicting dependency versions are not a problem. The problem is that you need to either build any binaries yourself, or wrap them in an FHS helper.

Nix has a virtualenv system `nix develop` and it's very powerful, especially for teams.

Silverblue

Imagine having a 2-layer container. One contains all the system stuff and is read-only, the other contains your home directory (basically). You can swap out the bottom/system layer at any point to upgrade the system without affecting whatever the user has done. Silverblue "merely" does this efficiently. The problem is, how do you now install packages? Flatpak and Toolbox (or Distrobox if you prefer, which I do).

I have been genuinely amazed at how much stuff now works in Flatpak. You'll get 90% of what you need from there. Distrobox is how you'll approach everything else. It's simply a container with complete access to the host, that also behaves like the host (e.g. the home dir is mounted). It uses containers as a layer, not a sandbox. You do all your development in that and use the container's native package manager to install what you need (apt, dnf, whatever). I actually configured `distrobox enter` as the default shell in my terminal emulator, you should rarely need the host shell.

You can also install packages to the system, but this is strongly discouraged. The only packages I layered in were fish, starship, and a custom kernel. Updates take zero compute (unless you are using a custom kernel, but it's not much), are are applied by restarting. That's also a major disadvantage, if you layer in packages (i.e. by not using Flatpak or Distrobox) you need to reboot in order to use them - it could be argued that a bad practice should involve friction.

Silverblue has done the craziest thing I've ever seen an OS do: I rebased to its sibling distro Kinoite (KDE-based) in almost exactly the time it took to download the system layer, plus the time it took to reboot - so about 2 minutes.

dotfiles are your problem in Silverblue.

I'm currently using Nix, but I am carrying over Distrobox to it and using that instead of `nix develop`.

HTH