生命不能从谎言之中开出灿烂的鲜花。——海涅

Apollo-11：一份会“说话”的登月代码，把 1969 年的胆量搬进你的终端里

有些仓库一打开，你会觉得它在向你挥手：“来，看看我做过什么。”

而 chrislgarry/Apollo-11 一打开，你会觉得它在低声告诉你：“别吵，我正在执行登月任务。”

它的自我介绍很简洁，却字字带着重量：

Original Apollo 11 Guidance Computer (AGC) source code for the command and lunar modules.
原始阿波罗 11 号制导计算机（AGC）源代码，包含指令舱与登月舱两套程序。

它不是“仿真项目”，不是“致敬复刻”，更不是“灵感重写”。
它就是那份曾经真的参与过把人送上月球的代码（以当年的形态留存下来），以一种很克制的方式站在 GitHub 上，让你能够直视它、翻阅它、甚至尝试把它重新装配起来。

它是谁：指令舱与登月舱的两位“老前辈”

这个仓库保存的是 Apollo 11 任务中 Apollo Guidance Computer 的两套软件：

  • Command Module（指令舱）：Comanche055
  • Lunar Module（登月舱）：Luminary099

README 说得非常明确：这份源代码由 Virtual AGC 与 MIT Museum 的相关工作者数字化整理而来。它的目标之一，是把这些历史材料以可访问、可维护的方式留存下来。

它像两位“任务老兵”坐在你面前：

  • Comanche055 负责指令舱的导航、控制、流程与任务执行，是“稳”和“全局控制”的代表。
  • Luminary099 更贴近登月舱的任务流程与着陆相关内容，它的语气里总带一点“必须精准”的紧绷感——毕竟那段路没有重来的机会。

你甚至能从 Luminary099 的说明里读到硬拷贝成册时的备注信息：
它像一页老日志，写着自己的“装配时间”，提醒你这份文档的日期是硬拷贝制作时间，而不是程序修订或装配的日期。

它从哪里来：从纸、从扫描、从博物馆，走到你屏幕里

这份代码并不是“从某个仓库直接 copy 出来”的那种数字原生项目。它的生命轨迹更像是：

  1. 某个年代的纸质硬拷贝与装配清单
  2. 扫描与数字化（MIT Museum 的硬拷贝、ibiblio 的资料）
  3. 转录、整理、拆分与再拼装
  4. 最终以 Git 版本控制的形式公开

在 Comanche055 与 Luminary099 的 README 里，都提到同一个“整理方式”：
为了组织上的可管理性，RSB 将原本巨大的、单体的源代码拆成多个更易处理的文件片段，然后通过 include 的方式重新拼接起来。

它甚至还会反问你一句——就像一个认真做文档的工程师：

既然拆开了，为什么不各自汇编再链接？为什么要用 include 把几十万行再拼回去？

答案带着时代感，也带着工程取舍的味道：当年的“复用”更像是把一叠打孔卡片插入到某个位置的流程化操作；include 的方式反而能更贴近当时的工作方式与文档结构。

你能感到它在尽量保持“原样”，不仅保存结果，还努力保留过程。

它如何被“装配”：YUL 不在了，但还有 yaYUL

在 Comanche055 的 README 中有一句很关键、也很让人唏嘘的事实：

  • 原始的 Apollo AGC 汇编器 YUL（看起来）已不再可得
  • 甚至在 Apollo 11 之前，YUL 就被另一个汇编器 GAP 替代过

而仓库的主 README 也给出了当下可操作的路径：

如果你对编译原始源代码感兴趣，可以去看 Virtual AGC。

也就是说，这个仓库并不承诺“你 clone 下来就能一键 make”，它更像一套“可考据、可阅读、可追溯”的史料级工程材料；而“如何让它跑起来”，则交给 Virtual AGC 生态去完成。

它的态度是冷静的：
“我负责把原件放到你手上，装配车间在另一边。”

代码不是散落的碎片：它们都有目录、有页码、有秩序

如果你打开 Comanche055/README.md，你会看到一种很“编目式”的严谨：
它给出一个巨大的 Source Code Index，按模块把每个 source file 对应到装配清单的页码。

比如（只举意象，不穷举）：

  • INFORMATION
  • COMERASE
  • COMAID
  • COMEKISS
  • TROUBLE
  • TVCDAPS
  • CHIEFTAN
  • MISCELLANEOUS

这些名字有的像代号，有的像绰号，有的像任务阶段的暗语。它们不会向你解释太多，但它们会把你带到正确的文件。

同样的，在 Luminary099/README.md 里，它也给出了一份更庞大的索引表，甚至明确写了：

Derived from MAIN.agc

它像是在说：“你想理解我？先从 MAIN.agc 的拼装入口开始。”

归属与署名：它把历史责任写得清清楚楚

主 README 有一个 Attribution 表格，非常“正式”，像合同附录一样：

  • Copyright：Public domain
  • Comanche055：作为指令舱 AGC 程序的一部分（提到 Assemble revision 055 …）
  • Luminary099：作为登月舱 AGC 程序的一部分（提到 Assemble revision 001 …）
  • Assembler：yaYUL
  • Contact：Ron Burkey
  • Website：www.ibiblio.org/apollo
  • Digitalisation：转录/适配自 MIT Museum 的硬拷贝数字化图像，数字化由 Paul Fjeld 执行并安排……

这段信息读起来不像“项目致谢”，更像“档案说明”。
它把每一个环节的来源、角色、载体都交代出来——你会知道这份材料为什么可信，它的“出处链”在哪里。

甚至还有一个 Contract and Approvals 的章节���明确指出：

  • 该 AGC 程序也可被称为 Colossus 2A
  • intended for use in Command Module（并引用报告 R-577）
  • 列出提交与审批名单、角色、日期（例如 1969 年 3 月 28 日）

当你在屏幕里看到 Margaret H. Hamilton 的名字，你会突然意识到：
这不是“某个复古项目”，这是“历史工程文件的一部分”。

如何参��：贡献前先读 CONTRIBUTING

它对贡献者的要求同样直接：

Please read CONTRIBUTING.md before opening a pull request.

这句短得像一句“门禁规则”，但也很合理：
当你面对的是历史源代码与整理工程，任何修改都需要更高的谨慎与一致性。

如何开始：从阅读开始，从 Virtual AGC 继续

如果你想以“最快方式”进入这个仓库的世界，它会更希望你这样做：

1）先把它请到本地

1
2
git clone https://github.com/chrislgarry/Apollo-11.git
cd Apollo-11

2）先认识两位主角：Comanche055 与 Luminary099

1
2
ls
# 你会看到 Comanche055/ 与 Luminary099/ 等目录

然后分别去读它们的 README，像读两本任务手册的目录页：

1
2
sed -n '1,120p' Comanche055/README.md
sed -n '1,120p' Luminary099/README.md

3）想编译？去 Virtual AGC

仓库主 README 已经把这条路标出来了：
编译原始源码请参考 Virtual AGC 项目。

它像在把你交接给另一个更专业的车间：

“我这边是档案室，那边是装配线。”

结语：这不是“代码仓库”，它更像一段可触摸的工程记忆

Apollo-11 这个仓库最大的魅力不在于“它有多好用”，而在于它展现出一种罕见的东西：

  • 工程的秩序感（拆分、include、索引、页码）
  • 资料的可追溯性（来源、数字化过程、联系人、站点）
  • 组织的严谨（合同与审批、角色与日期、公开领域声明）
  • 以及一种沉默的自信：它不需要用花哨的宣传证明价值，因为它本身就是历史的证据

你打开它的时候，它不会对你说“欢迎使用”。
它更像会把灯调暗一些，然后把一叠装订好的任务清单推到你面前：

“你想看登月怎么发生的？可以。
但请坐稳，把每一页翻清楚。”