Something that’s been discussed a lot in the past few weeks is the concept of a substrate bedrock, I’ve collected each point that people have written about and wrote a kind of summary.
The term initially came from LoperOS’s famous You have made your bedrock, now lie in it, and inspired a whole swath of runtimes. I think it relates to Malleability on different vectors like bootstrapping(thread), but one that is most important to me is software legacy as outlined by Chris Martens in Is truth futureproof?
Bedrock computing is a system designed to remain usable, reproducible, and maintainable over time.
A bedrock computer is a small, complete and independently implementable core with a reproducible way to build it, a test suite that validates its behavior and a governance that permits anyone to carry it forward. Its survival does not depend on an original author remaining alive, interested, solvent, or in charge.
| Preservation Guarantees | |
|---|---|
| Preservation | Evidence |
| Source | Can I keep it? A complete archive of the software, tests, and documentation. If a company disappears, changes its license, or deletes a repository, you still possess a complete version of the source. Source code that you can keep is not necessarily source code that you can build, modify or redistribute. A license can permit inspection while restricting redistribution or commercial use. |
| Build | Can I rebuild it? A bootstrap path from the source that works on a range of hosts, without network access. You can turn the preserved source into a working executable with the available hardware and software. Source code can be intact while its build process depends on a compiler that only runs on a discontinued operating system, a package that has vanished, or a library whose source is unavailable. |
| Behavior | Can I reproduce it? A precise specification and a test suite that let independent implementations reproduce the same observable behavior. Two implementations can pass the same incomplete test suite and still share the same bug. Independent implementations are most valuable when they are developed against a specification rather than copied from the same codebase. |
| Governance | Can I carry it forward? A license permitting independent maintenance, a specification that can be independently maintained, and enough documentation to continue without the original author. No single organization can unilaterally revoke your practical ability to use, maintain, implement, or extend the system within the freedoms it promises. If the original organization became hostile, disappeared, or abandoned the project, maintainers might become unable to keep the project alive. A project may be legally forkable but practically impossible to sustain if one organization controls essential infrastructure, expertise, funding, or release processes. |
Designing for bootstrapping is to make a system which does not depend on a binary seed that cannot be built from source. The goal is to start from a minimal, easily inspectable binary which should be readable as source and bootstrap into a practical and reproducible user interface. A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts. To accomplish this:
- The build system needs to be made entirely deterministic. Transforming a given source must always create the same result. For example, the current date and time must not be recorded and output always has to be written in the same order.
- The set of tools used to perform the build and more generally the build environment should either be recorded or pre-defined.
- Users should be given a way to recreate a close enough build environment, perform the build process, and validate that the output matches the original build.
