<div dir="ltr"><div>Hello Julien,</div><div><br></div><div>I'm glad you enjoyed the work!</div><div><br></div><div>Your understanding of DetTrace is correct. Our container abstraction is very lightweight in the sense that we just piggyback off Linux namespaces + chroot to provide isolation. Currently, to provide reproducibility, someone using DetTrace should download a chroot image (e.g. via debootstrap) and use this as the canonical filesystem image to use for the build. This is a bit clunky, and I believe it is not a 100% satisfactory solution. I don't know of any other ways to "normalize" the filesystem environment though.</div><div><br></div><div>This may seem a little heavy handed, so I'm curious how Guix handles a build process that tries to read arbitrary filessystem data? I'm reading more about Guix now, so I'll have smarter things to say about it later (hopefully).</div><div><br></div><div>For Dettrace we set out to see if it was feasible to create a 100% (foolproof) dynamic determinism enforcement system. I believe we succeeded at this goal (modulo some CPU instructions). However, I don't believe the full-proof solution is necessary or practical (tangent: our solution attempts to be foolproof for mostly academic reasons, not practical concerns about solving real problems, this is part of the fun of being in academia).</div><div><br></div><div>The point being: we attempt to sequentialize execution of threads, this is extremely difficult, and we can't do it properly. The biggest sources of unsupported packages (more details in the paper!) are Java, sockets, and intra-process signals. Java always ends up deadlocking due to our attempts to sequentialize thread execution in the JVM. With our current methods I don't think this can ever work properly.<br></div><div><br></div><div>Not all is lost though: I don't expect package builds to be nondeterministic from thread scheduling, sockets, or signals. So the simple solution is just to allow these things to happen in DetTrace and call it good enough. We still get all the other benefits of DetTrace but relax the paranoia and thus allow a wider set of packages to build. DetTrace could certainly be modified to support this.</div><div><br></div><div>I don't have any immediate plans to improve this, but would certainly not be against it either. I like to think the biggest contribution of DetTrace toward the reproducible builds effort is the ideas and methods, rather than the implementation.</div><div><br></div><div>I'll definitely let you know when it is available, the implementation is not as robust as it could be. So I want to set expectations accordingly!</div><div><br></div><div>Omar<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 11, 2020 at 3:37 PM Julien Lepiller <<a href="mailto:julien@lepiller.eu" target="_blank">julien@lepiller.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le 11 février 2020 05:54:13 GMT-05:00, Chris Lamb <<a href="mailto:chris@reproducible-builds.org" target="_blank">chris@reproducible-builds.org</a>> a écrit :<br>
>Dear all,<br>
><br>
>> Ugh, sorry about that!<br>
>> <br>
>> It should work now!<br>
><br>
>Thanks; works for me… as you can see here:<br>
><br>
>   <a href="https://i.imgur.com/UEqbiR4.png" rel="noreferrer" target="_blank">https://i.imgur.com/UEqbiR4.png</a><br>
><br>
><br>
>Best wishes,<br>
><br>
>-- <br>
>      o<br>
>    ⬋   ⬊      Chris Lamb<br>
>   o     o     <a href="http://reproducible-builds.org" rel="noreferrer" target="_blank">reproducible-builds.org</a><br>
>    ⬊   ⬋<br>
>      o<br>
>_______________________________________________<br>
><a href="mailto:rb-general@lists.reproducible-builds.org" target="_blank">rb-general@lists.reproducible-builds.org</a> mailing list<br>
><br>
>To change your subscription options, visit<br>
><a href="https://lists.reproducible-builds.org/listinfo/rb-general" rel="noreferrer" target="_blank">https://lists.reproducible-builds.org/listinfo/rb-general</a>.<br>
><br>
>To unsubscribe, send an email to<br>
><a href="mailto:rb-general-unsubscribe@lists.reproducible-builds.org" target="_blank">rb-general-unsubscribe@lists.reproducible-builds.org</a>.<br>
<br>
Hi Omar,<br>
<br>
I was able to download and read the paper after all. It was an interesting read, thanks for posting it here :). If I understand correctly you and your co-authors built a tool, DetTrace, that implements a container technology similar to docker, but whose conception allows for the deterministic behavior of its content. While I have my doubts on containers in general, the introduction resonnated strongly with the guix user inside me :). I think your tool could be seen as a way to transform a process with side-effects into a pure function!<br>
<br>
In Guix (and Nix), treating a build procedure as a pure function is the core of the packaging model we use. In fact we already use a similar technology to remove most of the non determinism sources when building (user names and ids, filesystem paths and content, network). I especially liked section 5 with the list of non determinism sources, since it shows where our own tooling is lacking. In fact, I'm pretty sure we could use DetTrace in Guix without too much work, and finally get to 100% reproducibility.<br>
<br>
Your evaluation section though suggests that it's not yet practical to use DetTrace for building an entire distribution as ~25% of packages couldn't be built using DetTrace. Do you think it would be a lot of work to get to 0%? Do you plan to improve it?<br>
<br>
Let me know when your tool is available, as I'd like to experiment with it :).<br>
</blockquote></div>