Skip to main content

max / mountaineer

manifesto: add principle 17 — backwards compatible with hardware, not software Lifts the existing "no backwards compatibility with our own past defaults" position into a named principle that also covers the hardware half: Mountaineer does not narrow Alpine's arch support and resists defaults that would obsolete machines that physically still work. Cross-project stance shared with EveryCycle and MNW.
Author: Max J. <87768334+MaxJMath@users.noreply.github.com> · 2026-05-23 02:44 UTC
Commit: 0426a1ab6c492118fa8e459d519528ed3ac2b97c
Parent: 83f1de2
1 file changed, +2 insertions, -0 deletions
@@ -66,6 +66,8 @@ We call this **the dull edge**: ahead of the consensus, behind the frontier, rid
66 66
67 67 16. **Tight scope beats extensibility.** When a project ships a thriving plugin ecosystem and an unconfigured base, it has usually pushed its design decisions onto its users — and every operator ends up with a slightly different, slightly broken assemblage. Mountaineer prefers tools whose authors made the calls themselves — helix over neovim, zellij over tmux-plus-tpm — and uses them close to their default configuration. The deeper bet: in an era where the meaningful contribution of most projects is the *idea*, a clean re-expression of an idea (helix, nushell, s6) is more valuable than a legacy project patched to bolt the idea on. We back the rebuilds. This applies to Mountaineer itself: someday someone with better taste will come along and express this idea more clearly, and the people running Mountaineer will move on. That is the project working as intended.
68 68
69 + 17. **Backwards compatible with hardware, not with software.** Operators are expected to run the most recent Mountaineer release. We do not maintain LTS branches, support shims, or migration scaffolding for users on stale versions; if a better default arrives and Alpine packages it, we adopt it and the old behavior goes. Principle 11 is the upstream face of this: Alpine's release train is our release train. The downstream face is that we ask operators to stay current and we make staying current cheap by writing the migration notes for every break. Hardware is the opposite. We do not narrow Alpine's architecture support, we do not require recent silicon to use the system, and we resist any default that would obsolete a machine that physically still works. The cost surfaces are different — software backcompat costs maintainer time per release, hardware backcompat costs runtime detection code we write once and amortize — and the asymmetric stance is how a small team ships forward motion without leaving operators stranded on yesterday's hardware.
70 +
69 71 ## What we pick, and why (summary — defenses live in `STACK.md`)
70 72
71 73 - **Package manager**: apk. One of the best-designed in existence. `/etc/apk/world` treated as a first-class config file.