>This concept of reproducibility is not only very comfortable, but has profound ramifications in security (you know no compiler or library has been tampered with malware)

If you want to "profoundly" improve security, you verify the whole install against a cryptographic hash on every boot, and you refuse to boot if the verification fails, and you keep the hashes in tamper-proof hardware -- like Android and ChromeOS do, but no other Linux distro does except for a distro specialized for cloud servers called Bottlerocket that is poor in resources (e.g., attention from developers).

NixOS's security is pretty poor even compared to the low standard of popular Linux distros because although it does incorporate one very good idea (and it is not reproducibility -- its refraining from giving packages as much ambient authority most OSes give them), security is mostly about paying attention to dozens of boring details, which the NixOS project does not care about as much as for example Fedora does. E.g., here is the project not caring about supply chain integrity: https://news.ycombinator.com/item?id=36268776.

Another example: if you install Google Chrome onto Fedora the standard way (namely, dnf install google-chrome-stable) it points your Fedora install to an RPM repo hosted by Google, so that from then on, even if everyone in charge of the Fedora servers lost their minds, your Fedora install would continue to keep your browser up-to-date in a very timely manner (because it has been configured to look directly to Google's servers for updates, and Google's Chrome team is well-paid and has a stellar reputation for security and in particular for timely delivery of security updates). In contrast, when I installed NixOS's Chrome package, it arranged things so that every time I updated my NixOS install (using nixos-rebuild IIRC) it would look to NixOS's servers, so the security of my browser (and the browser is the source of many, many security vulnerabilities) depends on a NixOS maintainer getting the update from Google, then providing it to me. But you see, the Fedora way of handling that package has a single point of failure (namely, Google) whereas the way NixOS chose has two points (namely, Google and a NixOS maintainer who is probably a volunteer and might quit or die at any time -- and the NixOS project has not system in place to respond to that event in a timely manner if my experience with the NixOS project is any indication).

NixOS's machinery for updating packages is very flexible, so I'm sure it would've been pretty easy to arrange for NixOS's Chrome package to work the way Fedora's does, but the relevant decision maker at NixOS simply didn't think of it. But security consists in large part in paying attention to details like that. ADDED. Actually, now that I think of it, the Chrome project's servers provide only RPMs and DEBs, so for NixOS's maintainer of the Chrome package to handle updates to Chrome the way Fedora does would require that the installation of the Chrome package causes (as part of dependency satisfaction) the installation of RPM or dpkg and maybe parts of dnf or apt (so that later on, the nixos-rebuild command can look for updates on Google's servers), so it is not as easy as I was envisioning when I wrote that "it would've been pretty easy". (Still, that is probably how I would do if I were the NixOS maintainer.)