Instead of introducing non-determinism, shouldn't it instead try to enforce determinism in any possible way? (E.g. running all processes under ptrace or by using virtualization and thereby making the OS behave in a deterministic way during a build).
That would only fix the build machine's problem, it wouldn't fix anyone else's builds.
A repeatable build without determinism is a fix for all people everywhere.
It would fix everyone else's builds if they added determinism in their builds (as opposed to adding non-determinism in the test-procedure). Besides, a test-procedure never gives a guarantee because a bug depending on non-determinism can be subtle.
That's the point - to uncover bugs dependent on nondeterminism by using a filesystem that introduces it. This is for fuzz testing at the filesystem level, not literally reproducing the builds correctly multiple times.
From the linked README:
"This is useful for detecting non-determinism in the build process."
Once such criterion is enforced, then everybody can reproduce the build with that set of source files and build instructions, without requiring a special environment that forces a specific order of events.
...by using non-determinism?
Very mind bending for me, I'm not sure I understand, but I'm glad smart people are figuring this stuff out.
(At least this is how Debian uses disorderfs. I wrote the first version of disorderfs 6 years ago in a hacking session at DebConf15 in Heidelberg. I never expected to see it on the front page of HN!)
Therefore (the original question), instead of using "disorderfs", why not write and use an "orderedfs" for every build?
And since this is run as part of a CI process, you will get lots of builds over time and will root out all sorts of issues caused by non-determinism.
As to your original question, there are so many sources of nondeterminism that trying to emulate them all away would make builds more complicated, less performant (FUSE adds overhead), and less safe (since there would be more components that could potentially be backdoored).
https://tests.reproducible-builds.org/debian/index_variation...
It is similar to how Chaos Monkey increases the resilience of Netflix's service by introducing random failures and then for each of those failures working out how to prevent the failure from affecting the overall status of the service.