Verified vs. Verifiable Reproducible Builds

[Dan Shearer]

On Tue, Apr 29, 2025 at 01:03:55PM -0700, Larry Doolittle wrote:

> Long-term availability of toolchains is the use case that
> was the bread-and-butter cash-cow for VMware back in the day.

That is part of a class of use cases where reproducibility has traditionally been a
side-effect/nice-to-have, which includes keeping software going to test & certify
long-lived hardware (eg aircraft, large medical machines, steel rolling mills etc). It is
peculiar that there is often a requirement to run ancient software in order to precisely
test and certify these important machines, yet the means of making the ancient software
run can be any ad hoc glue so long as it appears to run correctly.

In 2025 this should be framed as reproducibility first, and the boundary of
reproducibility expanded appropriately.

> Virtualized, documented, isolated, archivable environments at various levels
> like Docker, podman, and chroot are clearly essential now.

I like your list of properties.

However under "documented", the description of the environment is tricky so it's often
mostly human-readable documentation even if you are strictly within one type of
simulation. You can have a collection of Incus config files and images today and you need
very little additional information (eg version of Incus, base hardware arch if using
containers, base OS and version.) But as time goes by that list of required information
will get longer. 

Decades ago I used the metaphor of "Email me your computer as an attachment", because it
made people think about what information would need to accompany the image or indeed that
it was possible at all. Maybe that still has some educational use today.

--
Dan Shearer
dan at shearer.org