4 ms·
> There might be actions that are not order-independent, and the state of the CPU might result in slightly different binaries, but all are correct. Well no: th
by TacticalCoder 3y ago
> There might be actions that are not order-independent, and the state of the CPU might result in slightly different binaries, but all are correct.
Well no: that's really the thing reproducible packages are showing: there's only one correct binary.
And it's the one that's 100% reproducible.
I'd even say that that's the whole point: there's only one correct binary.
I'll die on the hill that if different binaries are "all correct", then none are: for me they're all useless if they're not reproducible.
And it looks like people working on entire .iso being fully bit-for-bit reproducible are willing to die on that hill too.
- kaba0 3y agoSee my reply to the sibling post — binary reproducibility is not the end goal. It is an important property, and I do agree that most compiler toolchains should strive for that, but e.g. it might not be a priority for, say, a JIT compiler.
- mike_hock 3y ago"Correct" does not mean "reproducible" just because you think lowly of irreproducible builds. A binary consisting of foo.o and bar.o is correct whether foo.o was linked before bar.o or vice versa, provided that both foo.o and bar.o were compiled correctly.