<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 9, 2016 at 12:45 PM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":xu" class="a3s aXjCH">I think we need repeatable builds so that if we compile the same<br>
module several timeswith the same macros and library versions we<br>
should get<br>
a bit identical beam file (so we can hash the beam content and use the hash<br>
as the key in a version control system)</div></blockquote></div><br>Other valuable things you can do:</div><div class="gmail_extra"><br></div><div class="gmail_extra">* Catch compilers which have been built incorrectly or are executing on faulty hardware</div><div class="gmail_extra">* Verify that two different compiler installations are the same. Sometimes this can lead to situations where you are hunting a bug only to learn later different compilers are used</div><div class="gmail_extra">* Catch maliciously altered compilers</div><div class="gmail_extra"><br></div><div class="gmail_extra">The same model is what drives BitTorrent. A BitTorrent file is essentially a map:</div><div class="gmail_extra"><br></div><div class="gmail_extra">#{ info => ..., trackers => [{tracker, ...}, ...] }</div><div class="gmail_extra"><br></div><div class="gmail_extra">The "infohash" is the SHA1 checksum of the "info" block, but certain parts are left out of that block, notably the tracker list. It allows operators to alter the tracker list and add their own tracker, without changing the content of the torrent file. In other words, integrity is provided where it matter, but freedom is given to alter the parts around the integrity-protected parts if necessary. </div><div class="gmail_extra"><br clear="all"><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div></div>