Hacker News Reader

Comment by hansvm | Hacker News Reader

Nix's definition of "reproducible" is different from what the author says they want though. Nix gives you a similar system from a given config, when it works, where the author wants bitwise identical results (even when compiled at a much later point in time and on a different machine, which you can't accomplish just from caching (unless the caches are remotely hosted)).

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.

View on HN

"Doesn't even try" is too strong.

"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/

That's fair. Attempting to rationalize my choice of language:

- 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.

I thought nix did perfect bit-for-bit reproductions at any time on any machine so long as you used flakes to lock the versions of inputs (and also I gather that flakes by default lock out some remaining sources of nondeterminism like reading environment vars). Is that not correct? (I don't see flakes mentioned in that link, nor the linked lobsters discussion, and the only mention in HN comments of the past was someone arguing that it doesn't count because some packages still fail to reproduce, which is notable but would still leave it in at least the same ballpark as ex. Debian)

> Is that not correct?

It's not. That would be comparable to magic.

Just writing to agree, since you are getting pushback.

@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.)

>Nix gives you a similar system from a given config, when it works

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.

> Nix is going to do as good, or better a job, than any other solution other there.

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.

> shade

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.

> Not to mention that much of Nix packages are reliably bit-for-bit reproducible.

We don't know that. Nobody has even attempted to build more then an incredibly small fraction of the packages `nixpkgs` provides.

Reply on news.ycombinator.com