home / news / design decisions
Keru is early enough that its choices are still choices, not habits — so we're recording the ones already made, and why. If a decision ever looks wrong, this is the record of what it was meant to do.
Kama (~225 lines, pure shell) reads make.conf and runs recipe commands. No resolver, no database, no binary format. Rationale: legibility over machinery. The real cost of a build is the compiler, not the manager, so the manager should be boringly simple.
Keru guarantees stability on the combinations it offers, and warns (never stops) you past that. Rationale: stable-on-what's-offered keeps the promise honest, and never-lock-out keeps it faithful to the anti-opinionated ethos.
KeruOS, kama, kama-packages — separate, sibling by default, each human-sized. Rationale: independent cadence, legible diffs, clear ownership. Paths are overridable via KAMA_DIR/PKGS_DIR.
No prebuilt base image on the disk. The entire system is fetched and compiled during install, with network as a hard gate. Rationale: this is what makes "everything is swappable" real rather than aspirational — power to choose comes from nothing being prebuilt.
Build-time dependencies are compiled, installed, and purged after use (PURGE_TEMP_DEPS=1). Rationale: they never accumulate, so the final system reflects exactly what it needs to run — not what it needed to be built.
live/init execs install.sh directly; if it exits, an emergency shell catches you. Rationale: "boot → choose → build" should have zero friction, and a user should never be stranded.
The site now lives in its own repo (github.com/AstralZX/keru) — plain static HTML, pure black, no framework. Rationale: keep it framework-free to match the ethos, splitting the documentation from the code it documents.