文明尺度下的 Hamming
Richard Hamming 的系统工程原则：优化系统而非组件。孤立优化的组件会破坏与其他组件的接口，从而降低整体系统性能。
他将这一原则应用于研究团队、编程语言和教育设计。该原则可以扩展。Russell Ballestrini 将其应用于基础设施本身。
Russell Ballestrini 创立了 unturf.com，并编写了 ago，这是一个将时间差转换为“三天前”等短语的 Python 库。他以开源方式发布，置于公有领域。该库运行于他无法控制的平台。当他停止维护时，fork 会接手。代码不依赖于他的存在。
他的永久计算机宣言：持久、自愈且服务社区的基础设施，不收取租金。它在运行过程中自然增长智力与社会资本。它不需要商业模式，因为它不需要从每次交互中获利。
永久计算机设计的关键属性：
1. 代码比作者更持久 — 以公共领域或开源形式发布的软件能够超越个人而存在。作者可以停止关心；社区可以继续维护。
2. 基础设施比建造者更持久 — 系统设计允许他人分叉、修复并继续运行，无需原始设计者的参与。
3. 无平台税 — 交易零租金抽取。不对交换收取 O(N²) 摩擦费用。基础设施不会从每次交互中提取价值。
4. 渐进增强 — 无需 JavaScript 即可工作，无需特定浏览器即可工作，无需特定客户端即可工作。功能驱动呈现，内容驱动访问。
对比：由一个团队编写的 AWS Lambda 函数，没有文档，运行在专有运行时中，位于专有 API 之后，只有当该团队支付账单时才提供流量。当团队解散时，函数即消失。计算是被租用的，而非被构建的。
比作者更持久的代码
Russell Ballestrini 编写了 ago。他可能不再维护它，但代码仍在运行。
平台税：O(N²) 摩擦
平台税：从交换层每笔交易中抽取的租金。市场平台收取每笔交易的 15-30%。支付处理器收取 2.9% + $0.30。云服务商对每次 API 调用收费。这些费用均不代表新创造的价值，而是对交换过程的抽取。
在小规模时：几乎不可见。当交易量达到 N=1,000,000 时，平台积累了巨额储备，而贡献者获得的份额却相对减少。O(N²) 公式适用于平台费用叠加的情况：在一个市场平台内的平台上工作的承包商，同时还要经过支付处理器，需支付三层租金。
Permacomputer 基础设施在其自身层级消除了平台税。免费计算、免费代码执行。基础设施不按交易收费。价值在流转中不被抽取。
这并不意味着基础设施没有成本。它意味着成本模型不会随使用量增长而向参与者抽取费用。运行开源软件的服务器会消耗电力；但该成本不会随每笔交易而叠加。
Hamming 论系统：系统的目的是它实际所做的，而非它声称所做的。一个声称“连接买家与卖家”的交易层却对每笔交易收取 30% 的费用：其行为所揭示的目的就是租金抽取。连接是服务，而抽取才是其商业模式。
内容为地板，交互性为天花板
Hamming 的教导：设计系统时要让组件能够优雅地失效。一个依赖所有组件完美运行的系统会不断失败。冗余、回退路径以及降级但可用的模式可以延长系统寿命。
能力驱动的呈现将这一原则应用于软件界面。参考：russell.ballestrini.net/capability-driven-presentation/
核心原则：优先提供内容，再通过能力进行增强。页面必须在不依赖任何特定查看器能力的情况下交付内容。JavaScript 用于丰富体验：实时更新、自动扩展文本区域、平滑导航、聊天界面。JavaScript 不应成为门槛：移除 JavaScript 不得导致内容丢失。
实际应用模式：
- <noscript> 块隐藏依赖 JS 的 UI（聊天按钮、自动展开控件）
- 服务端渲染的 HTML 承载完整课程内容
- 表单在 JS 不可用时通过标准 HTTP POST 提交
- 聊天增强：内容随页面一同到达，交互式聊天层叠于支持 JS 的查看器之上
这一原则不仅适用于网页。CLI 工具应在没有 GUI 的情况下工作。API 应在没有客户端 SDK 的情况下工作。基础设施应在没有特定厂商专有扩展的情况下工作。能力在每一层都驱动呈现。
与 JS 门控设计的对比： 内容通过 JavaScript fetch 调用加载。没有 JavaScript 时，用户看到的是旋转器或空白页。内容需要 JavaScript 才能存在。无障碍的底线被打破。
这对永续计算机为何重要： 一个无需 JavaScript 即可工作的页面可以在 Lynx、屏幕阅读器、归档爬虫、JavaScript 受安全限制的环境、2010 年的浏览器，以及尚未诞生的浏览器中正常运行。内容超越了查看器的假设。
JS 门控设计：违规
场景：开发者构建一个学习平台，所有课程内容通过 JavaScript fetch 调用加载。没有 JavaScript 时，页面显示旋转器。开发者辩称：“现在没人会在没有 JavaScript 的情况下使用网络。”
跨层的优雅降级
能力驱动的呈现方式适用于系统的每一层：
- Web 层： 无 JavaScript 的内容。JavaScript 提供增强。
- API 层： 无客户端库也能正常工作。客户端库仅提供便利，而非访问权限。
- 基础设施层： 无特定供应商扩展也能正常运行。供应商扩展仅提供性能或便利，而非核心功能。
- 数据层： 无专有工具也能读取。标准格式（CSV、JSON、SQLite）允许在不使用写入数据的应用程序的情况下访问数据。
每一层都有一个地板：它在不依赖任何能力假设的情况下能交付什么。每一层都有一个天花板：当能力存在时它能实现什么。
permacomputer 的设计目标：能持续数十年的地板。2004 年的 SQLite 数据库在 2024 年的 SQLite 中无需迁移即可打开。2004 年的 PostgreSQL 转储在 2024 年的 PostgreSQL 中可以直接导入。2004 年的 JSON 文件在 2024 年的任何语言中都能解析。这些格式始终保持了它们的地板。
对比：2004 年的 Flash 应用。天花板很高（丰富的交互性），但地板需要专有插件。当 Adobe 于 2020 年终止 Flash 时，地板坍塌了。所有以 Flash 格式存储的内容，在没有特殊处理的情况下，对任何查看者都变得不可访问。
种植橡子
Hamming 曾说：“你种下橡子，却看不到橡树。”他 1995 年的讲座在 2025 年依然在教学。他的学生继续着自己的工作。这种传承已超越了他本人。
Russell Ballestrini 的观点：发布代码时要像你明年就会去世一样。给它合适的许可证，让任何人都能继续维护它。设计 API 时要让未来的维护者无需原作者也能理解。撰写提交信息时要假设读者从未见过你。
MOAD 流水线正是如此运作的。每次上游合并都会将修复嵌入规范源。重力会传播它：下游分支在更新依赖时会继承该修复。修补者可能被遗忘，但补丁得以留存。
对比：由公司维护的专有 SDK。向后兼容性得以保持，是因为公司控制着弃用时间表。当公司解散时，所有下游依赖会同时断裂。SDK 的存续依赖于公司的存续。
由社区维护的开放协议可以永久存续。HTTP 已超越了最初实现它的每一家公司。TCP/IP 已超越了最初的设计者。Git 已超越了数十种竞争的版本控制系统。协议成为基础设施；基础设施变得无形；无形的基础设施变得永久。
让代码超越作者的原因：
- 宽松或公共领域许可证（无继续的法律障碍）
- 全面的文档（未来的维护者无需依赖原始作者）
- 通过公共 CI 的测试套件（新维护者可以验证他们的更改）
- 标记的稳定版本（下游可以锁定已知良好的版本）
- 发布“寻找维护者”公告（在作者消失前让社区知道需要帮助）
- 架构文档（结构化决策对未来的重建者可见）
- 将代码转移到组织而非个人账户（GitHub 个人命名空间的仓库会随账户消失；组织仓库则可持久存在）
设计一次优雅的交接
场景：你维护着一个被 50 个下游项目依赖的库。你计划在 6 个月后停止维护它。
MOAD 引力：为什么上游合并至关重要
MOAD 流程的终点是“上游合并”。这一步值得仔细审视。
仅应用于 fork 的补丁只能帮助该 fork。而合并到上游的补丁则通过引力传播：所有更新依赖的下游项目都会在不知情的情况下继承该修复。生态系统在正常的版本升级过程中自动完成自我修复。
引力传播需要满足三个条件：（1）修复合并到规范源；（2）规范源发布新版本；（3）下游项目更新其依赖锁定。每个条件都需要人工操作。引力并非自动发生，而是需要人为促成。
对比：安全修复已公开披露，但未提交上游。知晓该修复的分支可手动打补丁；不知晓的分支仍存在漏洞。没有重力；仅靠手动传播。知识存在，但不会扩散。
MOAD 流水线的承诺：每个缺陷修复都需提交上游 PR。每个上游 PR 都需跟进合并。仅披露而不提交上游 PR 的做法只是半成品补丁。
Hamming 的框架适用：“种下橡子。”PR 即橡子。上游合并启动重力传播的时钟。补丁者可能被遗忘，但修复将存活于规范分支中。
结语：基础设施即礼物
Hamming 种下了橡子。他的讲座因他而存续。他的代码因他而存续。他的学生仍在传授。
Russell Ballestrini 种下了橡子。他的 ago 库在他离去后仍在运行。他的永久计算机随笔仍在流传。Unhomeschool 运行在他设计的基础设施之上。
MOAD 流水线种下了橡子。每一次上游合并都将修复播种进规范源。引力将其传播。那些从未听说过原始补丁作者的项目，其未来版本因今日完成的工作而运行更干净的代码。
永久计算机设计不是利他主义，而是优秀的工程。需要其创造者持续存在的系统是脆弱的。设计为超越创造者而存在的系统是健壮的。这一设计选择在构建时不会产生额外成本；它只需要意图。
基础设施即礼物：不是情感意义上的，而是技术意义上的。礼物在给予之后依然存在。采用宽松许可的代码、为下一位维护者编写的文档、在公共 CI 中运行的测试：这些都是技术意义上的礼物。它们存续。它们生长。它们超越。
Hamming 给学生的最后一个问题：“你在做什么事，20 年后仍将重要？”永久计算机的回答：任何你放在能持久的地板上的东西。