Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I maintain the reproducible builds effort for my company and, please, let me tell you that this is the main pitfall of the whole effort.

There is always going to be a degree of un-reproducibility just due to the nature of math. If you don't have the same system, same compiler version (down to the minor or patch level), same dependency versions, same build flags, filesystem ordering, OS handling etc. . .you're going to get differences.

The RB project has readily disclosed that there is a degree of "significantly reproducible" sussing that each end user is going to have to do. The fact that the Debian maintainers chose not to display the degree of reproducibility is probably because showing low reproducibility scores undermines the efforts to evangelize the movement.

I think that's understandable, but also is a bit of a two edged sword. If we don't disclose scores, we allow for the misrepresentation that "this is safe because it has the word reproducible in it". If we disclose scores, we get articles like this saying "wow, thats a really low score, wtf" and short lived paranoia gives way to ambivalence about the whole thing.

It's difficult to capture the nuance in this in pithy tidbits, hence blog post on HN with me explaining this :).



The reproducible builds effort means same input (code, libraries, compiler, flags, build-environment), should give the same output (build artifacts). I don't think RB is trying to get reproducible across platforms and across varying compilers/dependencies -- that is a much bigger and much harder goal.

> There is always going to be a degree of un-reproducibility just due to the nature of math.

Fundamentally the math is deterministic (reproducible): if you do the same sequence of mathematical operations you get the same result. I gather you're getting at the non-associativity of floating point (eg additions), which is a fair point, but if you arrange to do your floating point operations in the same sequence then it will be reproducible.


Multithreaded code can easily be non-deterministic, with things like OS preemption leaking into the sandbox. Guaranteed determinism is hard, it needs a deterministic emulator.


Not really for building code, at least. It's a common problem, but it's not insurmountable. Use the equivalent of 'make -j1' or whatever...

This requires engineering on the part of compiler writers, but ultimately is solvable, given enough funding.

(About the compiler writers part: I'm thinking about GHC Haskell and the like... the Clangs/GCCs of the world will have no problems because of Translation Units. Things may change when Modules are a practical choice.)


You're gonna need a better programming language if you want to get to that level.


For these sorts of things, please do not assume hardware is reliable and compilers are bug free.


Bug free is less important for reproducible builds, so long as the bugs are reproducible. Compiler bugs are of course still a problem for other reasons.


My point is only that even when the software is correct, the reproducible build rate will either be 100% or we've got a representative sample set.

Until then, those issues will continue to be lumped together with all the software reasons it wasn't reproducible.


Sounds like a mechanism to test for bad hardware (akin to memtest86) and find compiler bugs =)


In a slightly different form, this has already happened: https://julialang.org/blog/2020/09/rr-memory-magic/


Bingo - even if we do everything right the percentage of matching builds isn't expected to be 100%. If it is, there just aren't enough samples.

My first Pentium could usually but not always math correctly until Intel replaced it during a recall.


From my experience, you either go full reproducible builds with nix, or none at all.

Sitting in the middle results with additional downsides from modifying pipeline without core upsides of reproducible builds.


Since hardware is the most difficult piece to replicate exactly for a reproducible build, should we say that for a complete reproducible environment we need an abstract virtual machine?


So we need our toolchains to run in WASM, too. Haha, only serious.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: