Hamming 在文明规模上
Richard Hamming 的系统工程原则：优化系统，而不是优化组件。一个在孤立情况下优化的组件，在系统中会降低性能，破坏它与其他组件共享的接口。
他将这个原则应用于研究团队、编程语言、教育设计。这个原则可以扩展。Russell Ballestrini 将其应用到基础设施本身。
Russell Ballestrini 创立了unturf.com 并编写了ago，一个Python库，将时间差异转化为类似于“三天前”的人类表达，并以开放源代码的方式发布。它在他无法控制的平台上运行。当他停止维护它时，一个分支会接过。这个代码不需要他存在。
他的永久计算机宣言：持续存在、自愈和为社区服务，而不抽取租金。它在运行过程中产生知识和社会资本。它不需要商业模式，因为它不需要从每个交互中获利。
永久计算机设计的关键特性:
1. 代码超越作者 —— 以公共领域或开放源代码的方式发布的软件能够在个人死亡后生存。作者可以停止关心，而社区可以继续。
2. 基础设施超越建造者 —— 设计使其他人可以分支、修复和继续，而不需要原始设计者的参与。
3. 无平台税 —— 零租金从交易中抽取。没有 O(N²) 的摩擦费用在交换中。基础设施不从每个交互中抽取价值。
4. 渐进增强 —— 在不使用 JavaScript 的情况下运行，在不使用特定的浏览器的情况下运行，在不使用特定的客户端的情况下运行。能力驱动展示；内容驱动访问。
对比：由一支团队编写的AWS Lambda 函数，没有文档，运行在专有运行时，通过专有 API，仅在该团队支付账单时服务流量。当团队解散时，函数消失。计算被出租，而不是建立。
能够超越作者的代码
Russell Ballestrini wrote ago. He may no longer maintain it. The code runs on.
Platform Tax: O(N²) Friction
Platform tax: rent extracted from every transaction in an exchange layer. A marketplace takes 15-30% of each exchange. A payment processor takes 2.9% + $0.30. A cloud provider charges for each API call. None of these fees represent new value created; they represent extraction from the exchange.
At small scale: invisible. At N=1,000,000 transactions: the platform accumulates a vast reserve while contributors accumulate proportionally less. The O(N²) formulation applies when platform fees compound: a contractor on a platform inside a marketplace inside a payment processor pays three layers of rent.
Permacomputer infrastructure eliminates platform tax from its own layer. Free compute, free code execution. The infrastructure does not charge per transaction. Value flows through without a toll.
This does not mean infrastructure costs nothing. It means the cost model does not scale with usage in a way that extracts from participants. A server running open-source software costs electricity; that cost does not compound per transaction.
Hamming on systems: the purpose of a system is what it does, not what it says it does. An exchange layer that says 'we connect buyers and sellers' but charges 30% per transaction: its purpose, as revealed by its behavior, is rent extraction. The connection is the service; the extraction is the business model.
内容作为地板，交互作为天花板
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 才能存在。地板下降到了可访问性之下。
为什么这个对于 permacomputer 来说很重要：一个不需要 JavaScript 的页面在 Lynx、屏幕阅读器、存档爬行器、有 JavaScript 安全限制的环境中、2010 年代的浏览器中、未来的浏览器中都能工作。内容会超过查看者假设的寿命。
依赖于 JS 的设计：违反
场景:一个开发者构建了一个学习平台,所有的课程内容都是通过 JavaScript fetch 调用加载的。没有 JavaScript,页面显示一个加载指示器。开发者争辩说:'再也没有人没有使用 JavaScript 浏览网页了。'
在各个层面上实现优雅退化
基于能力的展示适用于一个系统的每一层:
- Web 层: 没有 JavaScript 的内容作为地板。通过 JavaScript 提升。
- API 层: 不需要客户端库就能正常工作。客户端库提供方便,但不是必需的。
- 基础设施层: 不需要特定供应商的扩展就能正常工作。供应商扩展提供性能或方便,但不是核心功能。
- 数据层: 可以通过专有工具ing 读取,但也可以通过标准格式(CSV, JSON, SQLite)访问而无需应用程序。
每一层都有一个地板:没有能力假设的情况下提供的内容。每一层都有一个天花板:当能力存在时能够启用的内容。
永久计算机设计目标:地板能够保持 30-40 年。一个 2004 年的 SQLite 数据库在 2024 年依然可以打开。一个 2004 年的 PostgreSQL 导出可以在 2024 年的 PostgreSQL 中导入。一个 2004 年的 JSON 文件在 2024 年的任何编程语言中都可以解析。这些格式保持了地板。
对比:一个 2004 年的 Flash 应用。天花板很高(丰富的交互)。地板需要一个专有插件。当 Adobe 在 2020 年杀死 Flash 时,地板崩溃了。所有存储在 Flash 格式的内容都需要特殊的努力才能在任何查看器中访问。
种植栗子
Hamming的观点:'你种植栗子,你不会看到橡树'。他的1995年的讲座在2025年继续传授。他的一些学生继续自己的工作。信息传递超越了他。
Russell Ballestrini的表述:发布代码就像你下年死去一样。授权任何人继续它。设计API以便未来的维护者无需原始作者即可理解它们。以未读者曾遇到你为写提交消息。
一个MOAD管道以这种方式运行。每个上游合并将修复嵌入到规范源中。引力传播:更新其依赖项的下游分叉继承了修复。修复者可能被遗忘;修复survives。
对比:由公司维护的专有SDK。当公司解散时,每个下游依赖项同时破裂。SDK的生存需要公司的生存。
由社区维护的开放协议会永存。HTTP已经超越了最初实现它的公司。TCP/IP已经超越了它的原始设计者。Git已经超越了数十个竞争版本控制系统。协议成为基础设施;基础设施成为无形的;无形的基础设施成为永久的。
使代码长期存在的关键因素:
-宽松许可证或公有领域许可证(没有法律障碍继续)
-全面的文档(未来的维护者不需要原始作者)
-具有公共CI的通过测试套件(新维护者可以验证他们的更改)
-已标记的稳定版本(下游可以固定一个已知良好的版本)
-已发布的维护者求助公告(社区知道在作者消失前需要帮助)
-文档架构(结构决策对未来重建者可见)
- 代码转移到组织账户而非个人账户（GitHub下属命名空间的仓库在账户消失时也会消失；组织仓库则会持续存在）
设计优雅的过渡
场景：你维护着50个下游项目依赖的库。你计划在6个月后停止维护。
MOAD引力：为什么上游合并很重要
一个MOAD管道在'上游合并'处结束。这一步值得审查。
只在一个分支上应用的修复只会帮助那个分支。上游合并的修复通过引力传播：每个更新其依赖的下游项目都会继承修复而不知道这是什么。生态系统通过正常版本更新而自行恢复。
引力传播需要三个条件：(1) 缺陷合并到canonical源;(2) canonical源发布一个版本;(3) 下游项目更新依赖项。每个条件都需要人类的行动。引力不是自动的，而是被启用的。
对比：公开披露但未提交上游的安全修复。知道缺陷的分支可以手动修复。不知道缺陷的分支仍然脆弱。没有引力，只有手动传播。知识存在但没有传播。
一个MOAD管道的承诺：每个缺陷都修复后提交上游PR。每个上游PR都经过合并。公开披露但未提交上游PR是半个修复。
汉明的表述适用：'种下橡树种子'。PR就是橡树种子。上游合并启动引力传播的时钟。修复者可能会被遗忘；但修复在canonical分支中得以生存。
结论: 基础设施作为礼物
Hamming 播撒了榧子。他 的讲座活跃了他。他的代码活跃了他。他的学生教。
Russell Ballestrini 播撒了榧子。他的 ago 库在他 absence 时运行。他的 permacomputer 文章流通。Unhomeschool 依赖于他 设计的基础设施。
一个 MOAD 管道播撒了榧子。每个上游合并播撒了一个修复到 canonical source。gravity 传播了它。未曾听说过原始修复者的项目的未来版本因为今天的工作而运行更干净的代码。
permacomputer 设计不是利他主义。它是好的工程。一个需要其创建者持续存在的系统是脆弱的。一个设计以超越其创建者的系统是有韧性的。这个设计选择在构建时不需要额外的成本; 它只需要意愿。
基础设施作为礼物: 不是以情感上的意义,而是在技术上的意义。礼物在给予后持续存在。代码在宽松许可证下发布,为下一个维护者写的文档,在公共 CI 中运行的测试: 这些在技术上的礼物。它们持续存在。它们生长。它们超越。
Hamming 最后的问题给他的学生: '你在做什么,20 年后会有意义?' permacomputer 的回答: 你放在地板上的任何东西都能承载。