3 ms·

For some reason, many compilers and build scripts have traditionally been written in a way that's not referentially transparent (a pure function from input to o

For some reason, many compilers and build scripts have traditionally been written in a way that's not referentially transparent (a pure function from input to output). Unnecessary information like the time of the build, absolute path names of sources and intermediate files, usernames and hostnames often would find their way into build outputs. Compiling the same source on different machines or at different times would yield different results. Reproducible builds avoid all this and always produce the same outputs given the same inputs. There's no good reason (that I can think of) why this shouldn't have been the case all along, but for a long time I guess it just wasn't seen as a priority. The benefit of reproducible builds is that it's possible to verify that a distributed binary was definitely compiled from known source files and hasn't been tampered with, because you can recompile the program yourself and check that the result matches the binary distribution.

dane-pgp 5y ago
> There's no good reason (that I can think of) why this shouldn't have been the case all along Well, it's not like developers consciously thought "How can I make my build process as non-deterministic as possible?", it's just that by the time people started to become aware of the benefits of reproducibility, various forms of non-determinism had already crept in. For example, someone writing an archiving tool would be completely right to think it is a useful feature to store the creation date of the archive in the archive's metadata. The idea that a user might want to force this value to instead be some fixed constant would only occur to someone later when they noticed that their packages were non-reproducible because of this. But you're right; if the goal had been thought of from the start, there's no reason why every build tool wouldn't have supported this.
- russfink 5y ago
  Thank you both. I was wondering the same thing.
otabdeveloper4 5y ago
> The benefit of reproducible builds is that it's possible to verify that a distributed binary was definitely compiled from known source files and hasn't been tampered with, because you can recompile the program yourself and check that the result matches the binary distribution. It's not just security. If a hash of the input sources maps directly to a hash of the output binaries, then you can automatically cache build artefacts by hash tag and get huge speedups when compiling stuff from scratch. This was the primary motivation for Nix, since Nix does a whole lot of building from scratch and caching.
- kohlerm 5y ago
  I agree being able to support distributed caching of results is one of the major benefits.

dane-pgp 5y ago

> There's no good reason (that I can think of) why this shouldn't have been the case all along Well, it's not like developers consciously thought "How can I make my build process as non-deterministic as possible?", it's just that by the time people started to become aware of the benefits of reproducibility, various forms of non-determinism had already crept in. For example, someone writing an archiving tool would be completely right to think it is a useful feature to store the creation date of the archive in the archive's metadata. The idea that a user might want to force this value to instead be some fixed constant would only occur to someone later when they noticed that their packages were non-reproducible because of this. But you're right; if the goal had been thought of from the start, there's no reason why every build tool wouldn't have supported this.

russfink 5y ago
Thank you both. I was wondering the same thing.

otabdeveloper4 5y ago

> The benefit of reproducible builds is that it's possible to verify that a distributed binary was definitely compiled from known source files and hasn't been tampered with, because you can recompile the program yourself and check that the result matches the binary distribution. It's not just security. If a hash of the input sources maps directly to a hash of the output binaries, then you can automatically cache build artefacts by hash tag and get huge speedups when compiling stuff from scratch. This was the primary motivation for Nix, since Nix does a whole lot of building from scratch and caching.

kohlerm 5y ago
I agree being able to support distributed caching of results is one of the major benefits.