I think you may be confusing deterministic reproducible
builds (that remove randomness and ensure binaries
have the same content hash regardless of who builds
them (so you can reproduce what the maintainers did
and verify the source and binaries) to merely a repro'd
environment where everything still works because deps
are included, which seems to be all that Nix promises
(and in fact there is at least one open issue to add full
deterministic builds to Nix
https://github.com/NixOS/nixpkgs/issues/9731 )
Migrating Debian to nix might be possible, if that was desirable. You could have a compatibility layer for a while, and once everything is using the compatibility layer (in about 200 decades?), you deprecate the old package management details.
It was discussed in the Debian mailing list long ago, when Nix was not so polished [1].
Honestly, I think it's a migration really worth it. Nix (and Guix) are quite mature now. The advantages they bring into the table are massive.
The whole Debian ecosystem would become a lot more integrated and robust. It would be possible to develop packages at their own pace, without having to keep all dependencies in sync with the whole package tree. Besides, no more dist-upgrade breaking your whole system. It would look a lot like a rolling release, but with none of its disadvantages.
It would be also possible to turn all Debian flavours into little declarative Nix blurbs. There are countless advantages.
I think the risk of some software being kept on many versions old, full of security issues libraries is pretty significant, because the major impetus to force an upgrade has gone away, that is it wont even function without updating.
Should this issue be addressed at a technical level or a policy level? No matter how they manage the distro, so stuff is going to come down to policy and process. To me it seems like the sort of thing that should be handled with package audits.
The solution might be to keep nix for system software only and have third-party developers deploy snaps or flatpaks. Auditing package dependencies against a list of invalidated hashes should be easy enough.
I do think that Nix or something like it is the future. Or at least it will be if the tech community as a whole doesn't screw up.
But I also really appreciate the massive effort that Debian maintainers make, and the sheer number of those maintainers.
Combining whatever human processes Debian have in place to keep that going with Nix would be fantastic. Right now, to use Nix regularly, you really have to be willing to read a lot of Nixpkgs source code.
Edit: I should also note that I do actually currently use Nix on top of Debian for my work machine. Servers are all NixOS machines deployed with NixOps though.
I think Nix is the superior package manager, but you can already usw it with Debian for years now and not many people do it, so the problem seems to lie somewhere else...
Nix doesn't integrate with Debian well - you can also use yum on Debian and nobody does that either. If you're using Debian, it's because you want to manage a Debian system with Debian packages.
Yeah, nix doesn't feel right on debian because it can't manage services and doesn't use the "standard" packaging idioms. Is there someone else with a different experience or a workaround?
1. Too few marketing. I only heard of Nix for the first time last year.
2. When you boot a virtual server, the UI usually offers you Debian, Ubuntu and Centos/RHEL images, sometimes Suse/SLES or Arch. So again, less visibility, and if the hoster does not allow you to bring your own image, it's a pain in the ass to install anything else.
3. (Going off topic for a second: I probably would have switched to Nix(OS) already if it wouldn't entail effectively abandoning the configuration management tool that I maintain.)
I had this reflex, but IIRC the reproducible build effort does a few things differently (and some more) than nix. I can't recall which, but there were meaningful differences.
The short version is that they're different kinds of reproducibility.
The reproducibility that this post is about is for auditability ("verify that the binary originated from the claimed source"), whereas the reproducibility in Nix is for reliability ("ensure that the same package either fails or succeeds on every system in the exact same way, regardless of what the environment looks like").
Both are nice to have, but they are only tangentially related.
Nix does not particularly care about the hash of the result of a build, but mostly only the hash of the input.
When you download a package from the binary cache of Nix, you use the input hash. The binary cache contents may differ depending on the system of the build server.
Nix does try to eliminate nondeterminism in their builds though.
