It's odd that the article didn't mention nix, at least to say "We didn't like it for this reason".
The reason they don't like Nix should be obvious; it blatantly and vocally doesn't even try to do the thing the authors want. It'd be just as relevant to bring up Gentoo or something -- another fine project, like Nix, but not especially helpful for the stated problem, and so obviously so that it shouldn't be worth paying lip service to in the article.
"When compiling from the same source on independent infrastructure yields bit-by-bit identical results, this gives confidence that the build infrastructure was not compromised and the artifact really does correspond to the source." - https://reproducible.nixos.org/
- Their homepage defines reproducibility to be something other than bitwise identical results.
- Getting actual bitwise reproducible builds is still hard for most large projects, even with the work Nix has done (note that the quote you pulled doesn't actually say that Nix _does_ provide such builds, and the rest of that linked text just tries to highlight some of the tools you have at your disposal to achieve that).
They do "try" insofar as they're aware of the desire for bitwise identical results, provide them in some cases, and provide tools to diagnose problems. They're also 20 years old and more than happy to call the current results reproducible. At the very least, it doesn't look like one of the top properties for the project.
Not going to lie, I either don't understand what you're saying, or don't understand the shade you're trying to throw.
Nix is going to do as good, or better a job, than any other solution other there. Probably with a lot less duck-tape.
Not to mention that much of Nix packages are reliably bit-for-bit reproducible.
Not to not to mention that bit-for-bit reproducability is really only beneficial for "trust", not reliability or re-playability.
And no, comparing Nix to Gentoo in this case only very much confirms you don't understand Nix. Maybe you should check out the talk from a past NixCon where the speaker rebuilds Firefox from 10 years ago and boots up Flash swfs.
Bazel does this sort of thing remarkably well. Internal to google, it provides a multi-billion line monorepo with deterministic, highly-concurrent, bit-wise identical builds.
I'm not as familiar with Nix, but knowing what it takes for Bazel to do it, I would be surprised if Nix is as good.
> Probably with a lot less duck-tape.
And that is probably true.
There is none. Nix does lots of great things, like that Firefox demo you mentioned. TFA wants bitwise identical builds, and Nix isn't great at that in general, by their own admission.
> various praises for Nix
Yep, Nix is great.
> downplaying TFA's wants
That's worth writing somewhere probably, but not when arguing that Nix solves their problem. If their problem isn't real then potato peelers solve it just as well. Nix isn't really relevant at that point.
> Nix compared to Gentoo
The commonality is that neither solve TFA's problem, and neither try very hard to do so.
We don't know that. Nobody has even attempted to build more then an incredibly small fraction of the packages `nixpkgs` provides.
@Foxboron wrote a compelling if clickbaity post a few months back to poke at the bit-for-bit interpretation of what reproducibility means in nixland: https://linderud.dev/blog/nixos-is-not-reproducible/
It didn't get much traction here (https://news.ycombinator.com/from?site=linderud.dev) but there was more lively discussion on lobsters: https://lobste.rs/s/jpoy4q/nixos_is_not_reproducible
(That said, the nix ecosystem does have levers and practices for working to weed out common sources of build reproducibility problems and the community is reasonably interested/active here. But there isn't any magic in it that fixes all bit-for-bit issues. People still have to catch, tag, and fix them.)
It's not. That would be comparable to magic.