max / mountaineer
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. |