5 ms·

> The goal is to ensure that builds can be deterministic despite non-determinism ...by using non-determinism? Very mind bending for me, I'm not sure I underst

> The goal is to ensure that builds can be deterministic despite non-determinism ...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.

agwa 6y ago
You use disorderfs as part of a CI process. The CI builds the package once without disorderfs, and once with disorderfs. If they produce the same output, the package is reproducible (at least with respect to filesystem order). Otherwise, something in the build process is depending on filesystem order and should be fixed to sort directory entries before using them. You wouldn't use disorderfs when building a package normally. (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!)
- lambda_obrien 6y ago
  Thanks! That makes more sense now.
- amelius 6y ago
  I think you need to build many times to be sure. Therefore (the original question), instead of using "disorderfs", why not write and use an "orderedfs" for every build?
  - cyphar 6y ago
    Because doing it that way will make building (and verifying) a deterministic build more difficult for users, while forcing the builds to be deterministic in the face of randomised non-determinism means that anyone can build the project and get the same output without needing any complicated build configuration. That end goal (all builds are deterministic even if you don't have some magical reproducible build machine) is the holy grail of reproducible builds. 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.
  - agwa 6y ago
    The original behavior of disorderfs was to randomly shuffle directory entries, but we quickly realized that this meant that sometimes the shuffle wouldn't do anything, so I changed the default behavior to simply reverse the directory entries instead. Therefore, you only have to build twice. (Ironically, disorderfs' "non-determinism" is actually deterministic.) 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).
  - CyberRabbi 6y ago
    Because then your software is relying on guarantees not provided by the POSIX API and it would be incorrect.
sneak 6y ago
It's to root out "works [deterministically] on my machine" bugs earlier.
pabs3 6y ago
Repro build folks are introducing variation in the build environment (inc with disorderfs) in order to uncover reproducibility bugs and then fix them. Here are the variations Debian is introducing: https://tests.reproducible-builds.org/debian/index_variations.html 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.

agwa 6y ago

You use disorderfs as part of a CI process. The CI builds the package once without disorderfs, and once with disorderfs. If they produce the same output, the package is reproducible (at least with respect to filesystem order). Otherwise, something in the build process is depending on filesystem order and should be fixed to sort directory entries before using them. You wouldn't use disorderfs when building a package normally. (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!)

lambda_obrien 6y ago
Thanks! That makes more sense now.
amelius 6y ago
I think you need to build many times to be sure. Therefore (the original question), instead of using "disorderfs", why not write and use an "orderedfs" for every build?
- cyphar 6y ago
  Because doing it that way will make building (and verifying) a deterministic build more difficult for users, while forcing the builds to be deterministic in the face of randomised non-determinism means that anyone can build the project and get the same output without needing any complicated build configuration. That end goal (all builds are deterministic even if you don't have some magical reproducible build machine) is the holy grail of reproducible builds. 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.
- agwa 6y ago
  The original behavior of disorderfs was to randomly shuffle directory entries, but we quickly realized that this meant that sometimes the shuffle wouldn't do anything, so I changed the default behavior to simply reverse the directory entries instead. Therefore, you only have to build twice. (Ironically, disorderfs' "non-determinism" is actually deterministic.) 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).
- CyberRabbi 6y ago
  Because then your software is relying on guarantees not provided by the POSIX API and it would be incorrect.

sneak 6y ago

It's to root out "works [deterministically] on my machine" bugs earlier.

pabs3 6y ago

Repro build folks are introducing variation in the build environment (inc with disorderfs) in order to uncover reproducibility bugs and then fix them. Here are the variations Debian is introducing: https://tests.reproducible-builds.org/debian/index_variations.html 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.