NixOS uses a naming convention for packages that keeps them all separate from each other, that’s how you get /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-118.0/. /usr isn’t used for packages and only contains /usr/bin/env for compatibility, nothing else.

The whole system is held together by nothing more than shell scripts, symlinks and environment variables, standard Unix stuff. Making it very easy to understand if you are already familiar with Linux.

“Declarative” means that you whole configuration happens in one Nix config file. You don’t edit files in /etc/ directly, you write your settings in /etc/nixos/configuration.nix and all the other files are generated from there. Same is true for package installation, you add your packages to a text file and rebuild.

If that sounds a little cumbersome, that’s correct, but Nix has some very nice ways around that. Due to everything being nicely isolated from each other, you do not have to install software to use them, you can just run them directly, e.g.:

nix run nixpkgs#emacs

You can even run them directly from a Git repository if that repository contains a flake.nix file:

nix run github:ggerganov/llama.cpp

All the dependencies will be downloaded and build in the background and garbage collected when they haven’t been used in a while. This makes it very easy to switch between versions, run older versions for testing and all that and you don’t have to worry about leaving garbage behind or accidentally breaking your distribution.

The downside of all this is that some proprietary third party software can be a problem, as they might expect files to be in /usr that aren’t there. NixOS has ways around that (BuildFHSEnv), but it is quite a bit more involved than just running a setup.sh and hoping for the best.

The upside is that you can install the Nix package manager on your current distribution and play around with it. You don’t need to use the full NixOS to get started.