The philosophy that describes how and why we consider design choices the way we do effects everything downstream of it.
We consider some traits essential: Reliability. Reviewability.
// Note: this page is a draft.
// also “referential integrity”
like a (old, brick-and-mortar, filled with books) library. we expect to be able to refer to things, and once having a reference, we expect it to not change. we need to be able to embed this reference in other documents, and having them construct a chain of facts which are themselves referencable.
(the “things” here will turn out to be not just data, but computation as well; especially the computations that compile our tools for more computation on more data!)
supports reasoning about its overall flow statically
undecaying, uncorruptable, without deterioration.
temporal context may not be bound.
that “ability to reason about statically” property must hold regardless of time.
(spoiler alert: this is why the whole project is called “the timeless stack”.)
temporal context may not be bound!
this is to some degree a restatement of “referencable”, but explicitly more expansive: we want to be able to use our references to construct plans to produce more data; and we want to be able to reasonably expect – or failing that, at least test – or best yet, both – that these plans will be for processes that are reproducible.
it is important not just to state this principles, nor merely to follow them to the best of our abilities: it is critical to build tools that force us to notice quickly should we falter.
sort of the converse of composable; we want the products of our systems to be usable without a support network.
each package should be a prepper xD
this doesn’t come up quite so much in repeatr and core tools, but it’s a huge piece of guidance when it comes to packaging style recommendations and the radix project.
social! no presuming of monorepos.
using a random spray of repos on e.g. github isn’t a workable solution: it utterly punts on providing useful information to version selection processes, so it’s a half-solution at best… and half solutions are none solutions, really.
timeless stack designs are based upon data storage and metadata indexing which are decentralized, configurable, and easy to distribute… but still offer consistent single views.
the value comes from tooling which updates those single consistent views based on data from other (individually each consistent) views. and furthermore, on the schema and hashing choices which makes them stitchable.
“builds” are a function from fileset to fileset.
builds are not the only thing that matches this description.
this is a large distinction from most other projects currently pursuing reproducible builds: (linux-)distribution driven approaches consider builds a function from packages to package, and the result is a system that’s much less reusable, has much more emotional baggage, is more likely to capture other properties regarding which there are validly distinct PoVs, much higher complexity, a greater tendency to culturally slip into (crippling) acceptance of side-effects (for reasons that may be valid for some user stories in a distro, but are entirely orthagonal to the question of builds/fncompute)…