Ladybird Ports to Rust Using AI

Ladybird 网页浏览器已通过 AI 机器人移植到 Rust。这是一个真实的新闻标题，因为这是一件真实的事情。我今天早上大约 6:30 醒来，这是我读到的第一个新闻标题。我读到的第一件事是来自 Andreas Clling 的这篇博客文章，他是 Ladybird 网页浏览器的创始人，他以前也上过节目，他写道：“Ladybird 采用 Rust，并在 AI 的帮助下。”我读到这个标题时，我的大脑崩溃了。我坐在那里读着，心想：“等等，我曾有过这种时刻。它不是完全的认知失调。更像是我的大脑从耳朵里完全涌出来，这是愚人节吗？不，不是愚人节。现在是二月，对吧？我反复阅读了这个标题几次，以确保它能被理解。然后我读了博客文章。在我们继续之前，我将在这里读一些博客文章的内容。我想说几件事。我想在开始之前先说明一点，作为经验法则，我相信 Andreas Clling 会做出他认为正确的工程决策。总的来说，对吧？他参与了足够多酷炫有趣的项目。他愿意承受来自所有正确的人的批评，包括大多数 Rust 开发者社区的成员。但话又说回来，我认为这是一个非常非常糟糕的举动。我敢肯定 Andreas 预料到了我会有这种个人看法。所以，我现在将读一些他的博客文章，这样你就可以从他自己的话中了解他们为什么做出这个改变。再次强调，这篇博客文章是今天早上发布的，星期一，2 月 23 日。我们一直在寻找一种内存安全的编程语言来替换 Ladybird 中的 C++。我们之前探索过 Swift，但 C++ 的互操作性从未真正达到预期，并且在 Apple 生态系统之外的平台支持有限。Rust 则不同。对于系统编程，Rust 的生态系统更加成熟，而且我们的许多贡献者已经了解这门语言。今后，我们将用 Rust 重写 Ladybird 的部分内容。

现在，我在这里停一下，因为我们即将深入探讨他为什么选择 Rust。我将完全不同意他在几个关键点上的工程评估。但是，他说了一点，这是选择 Rust 的一个非常有效的理由，那就是我们的许多贡献者已经了解这门语言。在选择任何项目的良好编程语言时，这一点都值得一提。你选择你了解并且能够高效工作的语言。如果那是 Rust，很好。选择 Rust。如果那是 GW basic，也很好。选择 GW basic 或 Pascal 或 Forran 或任何语言，对吧？你了解并且能够高效工作的语言，对于绝大多数项目来说，通常会是正确的选择。好吧，你可能不会用 GW basic 开发一个网页浏览器引擎和 JavaScript 解释器，但你懂我的意思。所以，这是选择任何语言的一个非常有效的理由，无论它是什么，即使是我可能不会选择的 Rust。

好了，他说：“为什么选择 Rust？当我们最初在 2024 年评估 Rust 时，我们拒绝了它，因为它在 C++ 风格的面向对象编程方面并不出色。”这是真的。Web 平台对象模型继承了许多 90 年代的面向对象编程风格，包括垃圾回收、深度继承层次结构等等。Rust 的所有权模型与此并不匹配。这非常有道理。到目前为止，我与他一致。但在又一年原地踏步之后，是时候做出务实的选择了。Rust 拥有我们所需的生态系统和安全保证。Firefox 和 Chromium 都已经开始在他们的代码库中引入 Rust，我们认为这对 Ladybird 来说也是正确的选择。

好吧，我在这里停一下。因为他说的没错，Firefox，Rust 实际上就是从那里开始的。Rust 最初是 Mozilla 的一个项目。Firefox 在过去几年里已经将一部分，不是大部分，甚至不是接近大部分，但足够多的 Firefox 代码迁移到了 Rust，这实际上给 Firefox 在广泛的系统上移植带来了问题。过去，在 Rust 出现之前，你可以看到 Firefox 的各种版本被移植到经典的 Mac OS。我是说，这是真实存在的。我记得好像叫 Clesilla。在 Mac OS 8 和 9 上，你可以运行一个 Firefox 版本，而且它运行得相当不错，尤其是在较新的 Power PC，你知道的，高端的 G4、G5 Mac 上。但是一旦开始移植到 Rust，这种情况就消失了，因为虽然 Rust 在技术上对相当广泛的 CPU 架构和操作系统有初步支持，但实际支持却非常有限。非常有限。他们网站上有一个图表，我记得是分为三个级别：一级支持、二级支持和三级支持。一级支持的 Rust 通常工作得相当好。我是说，它仍然是一个不断变化的目标，并且有 Rust 的所有注意事项，但编译器本身通常能很好地支持这些平台。二级和三级支持则不然。三级支持，直接排除。如果你想让现代 Rust 在广泛的平台上正常工作，任何在三级列表上的平台，通常都无法工作。你也许能编译一些示例代码，但任何规模较大的东西都基本不可能。任何开发过大型应用程序的人都可以证明这一点。二级支持则是一个混合体，是 Rust 中的中间层，即使 Rust 对任何给定平台都有二级支持，实际上你也会遇到很多麻烦才能在该平台上运行。因此，由于这一点，由于 Firefox 将足够多的代码迁移到 Rust，使其成为一个强制性依赖，我们失去了在广泛平台上的 Firefox 支持。这意味着 Ladybird 由于其构建过程的强制性部分需要 Rust，它将不可避免地限制其未来的平台支持。这可能不是问题。Ladybird 可能在其愿景中并不希望支持，你知道的，太阳下的每一个操作系统和 CPU 架构。他们可能就是不想。但通过转向 Rust，他们消除了这个选项。他们说我们不想支持所有其他平台。我们只专注于，你知道的，这一个或两个非常大的平台。这可能没问题，但这是一个重大的缺点。而 Ladybird 的可移植性大大增强，这确实比 Firefox 和 Chromium 略有优势，尤其是 Ladybird 已经成熟到可以成为一个越来越可用的网页浏览引擎。与一年前相比，这是天壤之别。但是，剥夺了这种可移植性，那就是失去了 Ladybird 可能拥有的一个主要优势。所以我认为这是一个错误。从那个角度来看，我认为这是一个战略性错误。

他继续说：“我们的第一个目标是 libjs，Ladybird 的 JavaScript 引擎。词法分析器、解析器和字节码生成器相对独立，并且我们通过 test 262 拥有广泛的测试覆盖率，这使它们成为一个自然的起点。”这确实有一定道理。他们有如此多的测试用例，可以自动运行他们的 JavaScript 引擎，是的，如果他们要进行这种大规模的架构更改，从那里开始确实有道理。

这里就变得非常奇怪了。这就是双重打击的由来。引用：“我使用了 AI 代码和编解码器进行翻译。这是人类指导的，而不是自主代码生成。我决定了移植的顺序以及 Rust 代码应该是什么样子。我通过数百个小提示来引导 AI 完成需要完成的工作。在初步翻译后，我进行了多轮对抗性审查，让不同的模型分析代码中的错误和不良模式。”我的天哪。好吧。所以，我们正在迁移到 Rust。好吧，可以。荒谬，但我会接受。但这样做是借助 AI。而且不仅仅是借助 AI，而是借助许多不同的 AI 系统来调整代码。我的天哪。约翰·康纳想和你谈谈，伙计。什么？好吧。好吧。好吧。我暂且不提。

我确实想挑一个很小的毛病。引用：“这是人类指导的，而不是自主代码生成。”好吧，人类指导和完全自主，说到底只是同一枚硬币的两个面。AI 正在生成代码，无论我们在这里谈论的是什么，AI 生成代码的幅度有多大。所以，AI 仍然在生成所有代码。根据这个说法，结果是 25,000 行 Rust 代码。整个移植大约花了两个星期。AI 仍然在生成这 25,000 行代码中的大部分。在我看来，这相当自主。我是说，将它分成小块并说，“不，不，不，不，不。生成得更好。”这仍然相当自主，伙计。这并不是人类指导的，但好吧。我意思是，有点，但不是真的。这就像有人雇了一个 Door Dash 送餐员，从一家当地餐馆把餐送到家，然后打开吃，然后说，这是人类指导的，所以我基本上是厨师，因为我通过 Door Dash 网站指导餐馆为我做饭。你指导了 Door Dash。不，不，不，不，不，不，不。你没做饭。你没写代码。你没做汉堡。这就是它的运作方式。

结果。从一开始的要求就是两个管道产生逐字相同的输出。这是合理的。结果大约是 25,000 行 Rust 代码。整个移植大约花了两个星期。同样的工作，我手工完成需要几个月。我真的毫不怀疑这一点。我们已经验证了 Rust 解析器生成的每一个 AST 都与 C++ 的相同，并且 Rust 编译器生成的每个字节码都与 C++ 编译器的输出相同，所有方面都没有回归。这很好，这很好。他们运行了 52,898 个 test 262 测试，以及超过 12,000 个 Ladybird 回归测试，没有任何回归。在我们跟踪的任何 JavaScript 基准测试中也没有性能回归。

好吧，我在这里停一下，因为我想称赞 Ladybird 团队和 Andreas Clling 在这一点上。Rust 的决定和 AI 的决定。不，错了。但是，如果你要做一个重大的举动，你必须确保最终结果经过充分测试，并且没有退步，没有回归。他们做到了。我是说，我们看到了总共大约 65,000 个测试运行，没有回归。这很棒。这就是你应该做的方式。我指出这一点是因为最近有大量的开源软件项目说，“哦，我们要把所有东西都迁移到 Rust。”然后他们用大约 14 个测试用例来做，其中一半失败了。然后他们说，“哦，够了。准备好了。运行得很好。”在这些情况下，不，他们做得不好，因为在这种特定情况下，无论你移植到什么语言，如果你迁移一个大型代码库，上面有很多东西，对吧？一个真正基础的代码部分，像 Rust 对其 JavaScript 引擎所做的那样基础工具，你真的需要对其进行充分的测试，以确保它已准备好替代你正在替换的东西。所以，就像 Ubuntu 对其核心工具的替换所做的那样，他们最近采用了 uutils，以及其他一些项目一直在尝试用 Rust 等价物替换他们的一些遗留 C 和 C++ 基础工具，而没有充分测试它们，这只是一个巨大的软件工程管理错误。Ladybird 没有犯这个错误。他们在进行充分的测试。所以，在这方面，我赞成。因为这就是你应该做的那种事情，对吧？所以，我对 Ubuntu 处理方式的批评在这里 Ladybird 上不存在，因为他们在测试。所以，这是好事。我仍然不喜欢这个选择。工程决策不是，它有一些重大的缺点，但他们正在按照你应该做的那样进行测试。

他继续说：“除了测试套件，我还通过锁定模式进行了广泛的测试，其中 C++ 和 Rust 管道同时运行，验证流经它们的每一段 JavaScript 的输出都是相同的。如果你看代码，你会注意到它有很强的从 C++ 翻译过来的感觉。这是因为它是从 C++ 翻译过来的。这次首要任务是与我们的 C++ 管道兼容。Rust 代码有意模仿 C++ 的寄存器分配模式，以便两个编译器产生相同的字节码。正确性是第二位的。我们知道结果不是惯用的 Rust，一旦我们能够舒适地淘汰 C++ 管道，还有很多可以简化的地方。这些清理工作将来会到来。”

好的。接下来是什么？这并没有成为项目的重点。我们将继续用 C++ 开发引擎，并将子系统移植到 Rust 将是一个长期的侧线。新的 Rust 代码将通过明确的互操作边界与现有的 C++ 代码共存。这对我来说似乎很奇怪，因为如果你将一部分代码从 C++ 移植到 Rust，这意味着你的项目的大部分仍然不是 Rust 内存安全的，如果那才是真正的目标的话。如果那不是真正的目标，为什么还要选择 Rust 呢？所以，目标必须是内存安全。如果你要追求内存安全，为什么在也使用 Rust 的同时继续使用 C++ 呢？这有一些注意事项。我们稍后会回到这一点。但你为什么要这样做？对我来说，这似乎不是一个合理的做法。如果你要用 Rust，就用 Rust。全力以赴。让你的应用程序完全内存安全。说实话，这有点夸张了，但如果你要追求这个，就全力以赴，因为目前来看，这意味着 Ladybird 不是一个内存安全的软件。它有一些小的内存安全组件，但大部分组件不是内存安全的。我必须经常使用引号。但是，你现在有了多种语言，多种不同的编译器。你现在增加了两种语言和工具集之间互操作性的复杂性。而且，你大大降低了软件的可移植性。对我来说，这似乎不是一个好的权衡。如果我是一名工程经理，我不会选择这个。这似乎很愚蠢。

他继续说：“我们希望有意识地决定哪些部分以及按什么顺序移植，以便移植工作由核心团队管理。在开始任何移植工作之前，请与我们协调，以免任何人浪费时间在我们无法合并的事情上。我知道这将是一个有争议的举动。是的，他知道他在做什么。但我相信这是 Ladybird 未来正确的决定。”笑脸，老式表情符号。Andreas Clling，创始人兼总裁。

我读完了这一切，然后我联系了 Andreas。我以前请过 Andreas 上节目。我联系了他，我说：“伙计，伙计，你还好吗？Ladybird 浏览器在 11 点嘲笑 Lunduke 电影，你想评论一下吗？”他只提供了一句话评论，我现在提供给你。引用：“Rust 社区仍然很烦人，但技术很好。笑脸表情符号。”结束引用。

好吧。好吧。所以，这是真实发生的事情。提交已经完成，在我录制这期节目的时候，大约 4 小时前。我还没有构建和编译最新的 Ladybird 版本。说实话，我不知道我什么时候会这样做，因为我通常会尽量避免 Rust，很大程度上是因为我不信任 Rust。但我要说的是，我确实信任 Andreas Clling。Andreas 参与了足够多的项目，并且在技术上取得了巨大的成就，他在 Serenity OS 和 Ladybird 等多个项目上都取得了巨大的成就。当他说，我正在出于工程原因做出这个决定时，我确实相信他。我仍然认为负面因素大于正面因素。在我看来，这似乎不是一个明智的举动，但我绝对相信他是出于技术原因做出这个决定的，而不是出于某种意识形态原因，对吧？我们正在听说它现在被移植到 Rust，但我的猜测是，我没有看到任何理由认为 Andreas Clling 是 Rust 邪教的一部分，对吧？所以，我不会期望 Andreas 发布一个又一个的更改，宣布，“哦，这个新功能是用 Rust 编写的。”我不会期望这样的声明一次又一次地出现。所以，这是值得一提的一点。另一件事是，就技术实现、架构和编译器、语言选择的相对优点进行技术分歧是完全合理的。我讨厌这个作为 Ladybird 浏览器项目的选择。从多个角度来看，仅仅是可移植性对我来说就是一个大问题。语言和编译器的不断变化的目标是另一个问题。Ladybird 领导层内部的相对不稳定，Rust 基金会和 Rust 项目内部的相对不稳定。有很多问题，我会犹豫在 Rust 生命周期的这个阶段，将我项目的核心部分，我关键的、宏大的、雄心勃勃的项目建立在如此不稳定的东西之上。再次，我想说清楚，这样人们就能理解我的意思，当我说不稳定时。我不是说崩溃。我说的是变化。就像 Brian Kernighan 最近，就在几个月前，他评论说他试图学习 Rust，并且在做一个简单的项目时遇到了一些问题。他试图做一个“Hello World”之类的项目，然后把它放下了。两周后他回来时，他试图完成的很多东西在语言和编译器中都已经改变了，这让他非常沮丧。这只是几个月前发生的事情，就在去年。所以我认为这只是在小规模项目上，Rust 目前仍然是一个不稳定的基础。它将来可能不是不稳定的基础。事实上，如果我是 Rust 基金会的一员，我会立即稳定下来。因为有这么多人采用它，保持这种不稳定，保持这种变化，这种摇摇欲坠的果冻状状态，将对 Rust 的未来采用以及所有决定使用它的平台造成严重问题。这不是一个好的决定。我是说，它……因为最近，NetBSD 项目发表声明说，他们很大程度上不会采用 Rust，原因正是如此。他们指出，他们喜欢支持 NetBSD 的一个版本很多年。我不记得是多久了，我记得是四年左右。一位主要开发人员指出，如果他们在四年前采用 Rust，那么变化将是如此之大，以至于当前的 Rust 编译器无法编译他们四年前发布的代码，因为实际上，即使是两年的代码变化也是如此。所以，你真的不能在 Rust 上标准化这些大型项目，而不承诺定期进行 Rust 维护，以使其与 Rust 编译器协同工作。我认为这对 Ladybird 浏览器的开发团队来说是一种糟糕的时间利用。

那么，我推荐什么？只是为了非常清楚地说，如果，而且我并不完全相信内存安全的东西，我只是诚实地告诉你。我理解内存安全背后的概念。很好。很好。我没有问题。但我认为这被大大夸大了。非常夸张。只是写出好的代码，伙计们。但是，如果你真的担心使用一种内存安全至关重要的语言和编译器，那为什么不考虑 Phil C 呢？所以，Phil C，FIL-C，它是一种 C 语言，具有内存安全。它是 C 和 C++，具有内存安全。以至于一位主要开发人员，Philip Jersey Pislo，抱歉如果我发音错误，伙计，他已经将 WebKit 移植到了一个基于 WebKit 的浏览器。我相信这是 Epiphany，GNOME 浏览器，使用 Phil C。这意味着目前这是唯一一个 100% 内存安全的浏览器，而且它没有使用 Rust。我想非常清楚地说这一点，因为 Ladybird 将部分代码迁移到 Rust 意味着 Ladybird 的大部分仍然不是内存安全的，而 Rust 最初的 Firefox 的绝大部分也不是 Rust，这意味着它不是非常内存安全的。对吧？所以，真正的问题是，问题陈述是缺乏内存安全。而解决方案 Rust 并没有真正解决陈述的问题。最多就是说，“哦，你砍掉了一条腿，部分截肢了一只胳膊，鼻子也断了。好吧，我会在你的耳朵上贴一个创可贴。”这就是 Rust。这就是 Rust 的精髓。因为他们还没有让这些网络浏览器中的任何一个应用程序完全内存安全。一个都没有。一个都没有。但是 Phil C 正在持续开发中，就像 Rust 一样，我是说它在这方面仍然有点变化，它将现有的 C 代码编译成一种使用内存安全的东西，所以你有一个内存安全的浏览器，使用你已经拥有的预先存在的代码。而且你可以争辩说 Phil C 的做法可能不是最好的架构解决方案。有非常合理的工程争论，但最终结果确实解决了采用 Rust 的根本原因。所以，从我的角度来看，我认为这样的变化从 Rust 的角度来看是巨大的工作量，并且提供了更少的代码移植能力，并且没有真正解决陈述的问题。现在，我认为陈述的问题并不是真正的问题。它更像是有人拼命寻找一个问题。抱歉，内存安全的东西有点……然而，如果你真的担心这一点，Phil C 似乎比 Rust 更像一个解决方案。Phil C 仍然存在一些问题。它绝对有。我是说，它目前在地球上并非所有平台上都可用。所以，这肯定也是另一个问题。我是说，我未必会选择这些东西中的任何一个。因为我并不真正担心内存安全，而且很多人已经在网上对我大喊大叫了。然而，然而，如果你担心，我不明白选择 Rust 的原因。我就是不明白。

现在，AI 的事情是另一回事了。我们已经看到像微软、谷歌等大公司宣布，我们已经生成了，你知道的，我们 20-30% 的代码都是由 AI 编写的，我们的新操作系统也是由 AI 生成的。当他们做出这些声明时，人们嘲笑他们。人们嘲笑他们，因为，是的，这不会有好结果。我看到这种情况在开源和 Linux 世界中越来越普遍。Ladybird 绝不是唯一采用 AI 的。我是说，嘿，Linux 内核现在有了官方的“让我们使用 AI”的政策。Fedora Linux 有官方的“让我们使用 AI”的政策。Red Hat，它拥有 Fedora 并拥有它，字面上有一个政策，他们支付更多钱给使用 AI 的人。这真的不是开玩笑。你写的 AI 代码越多，你写给 AI 编写代码的提示越多，Red Hat 支付给你的钱就越多。他们将奖金、薪酬激励和晋升等与达到 AI 特定目标、使用 AI 和推广 AI 联系起来，对吧？所以，这在整个开源领域都在发生。现在，开源领域有一些部分正在以强烈的方式拒绝 AI，一些项目说这里不允许使用 AI，等等。但其他项目则说，是的，请多用 AI。然后我们听到关于 AI 机器人出现并为项目编写代码的故事，以及各种疯狂的事情。我认为这有点……我将犹豫。这是我个人的建议，给 Andreas Clling 和任何其他在开源世界中听到的人。我将犹豫允许 AI 生成的代码在这个阶段。为什么？因为它仍然没有经过充分的审查。如果你在构建小的工具，对吧？我只是要构建一个一次性的休闲视频游戏，对吧？一个小小的 Flappy Bird 克隆游戏之类的。你知道吗？如果你想玩玩 AI 代码生成，这可能是一个有趣的项目。如果你在 AI 领域工作，并且想了解 AI 代码生成如何在大型项目中处理，并且你想用它作为实验，是的，请随时将其添加到……使用 AI 代码生成来开发网页浏览器或操作系统。但是，如果你是运行浏览器、操作系统、办公套件或任何大型代码库的人，AI 代码生成目前正在迅速变化和发展，就像 Rust 一样，它是一个不稳定的基础，在此之上构建工程流程。我将犹豫继续下去。

现在，我个人对 AI 代码生成项目有很多红旗，非常约翰·康纳式的，天网式的红旗。所以，我个人会完全避开它，但至少，我不会全力以赴。我不会一头扎进……用 Rust 重写或编写一个网页浏览器的整个 JavaScript 解释器的大部分内容。在我看来，这太可怕了。这是一个可怕的举动，尤其是当我们还在谈论基于 Rust 的时候，Rust 在编译器工具链方面存在一些安全问题。所以，那里有很多很多问题。

但我会说，这些都是我们应该进行的合理的工程和技术争论。我们在这里看不到的，我认为非常值得注意的是，这是一个政治声明，对吧？Ladybird 网页浏览器并没有站出来，并采用 Rust 作为一种政治声明。事实上，Andreas Clling，我需要重复一下，他说：“Rust 社区仍然很烦人，但技术很好。”笑脸。好吧。好吧。我们将拭目以待。我们将拭目以待。我将让它发展，就像我别无选择一样。我将观察它如何发展，然后我们将拭目以待。我认为这是一个错误的选择。我认为……我认为 Andreas Clling 知道我知道这是一个错误的选择。我知道我知道这是一个错误的选择。我认为两年后，这可能会被撤销，也许是使用 AI。我认为这是一个不必要的举动，浪费了时间，在一个本已非常出色的项目中，这个项目显示出巨大的潜力。

现在，现在的问题是，随着 Ladybird 网页浏览器在日常使用中变得越来越可行，而这可以用任何编程语言来实现，使用 AI 或 Rust 或两者都用于开发网页浏览器，对我来说是否是一个交易破坏者？答案是否定的。至少目前是这样。我对在大型项目中使用 AI 存在一些担忧，尤其是在这种关键应用程序中。许多担忧，主要是安全担忧，以及许可问题。但我也对 Rust 编译器的使用有一些担忧。同样，主要是安全担忧。所以，这些担忧将会被提出。但是，尽管有红旗，Ladybird 也可能是……在所有主要的网络浏览器中，未来最令人兴奋和最有趣的东西。但我们将拭目以待。我们将拭目以待。我愿意观察并被证明是错误的。我不会。所以，感谢 Lond Journal 的订阅者让我能够进行这种报道。前往 lunduke.com，在 Lond Journal 发布的所有平台上成为免费订阅者。我们几乎到处都发布。你知道的，你现在甚至可以在 TikTok 上看到 Lond Journal。我在 lunduke.com 上没有链接，但我们有一个 Londuke Journal 在 TikTok 上。这对我来说很疯狂。但为什么不呢？我们在 Facebook、TikTok、YouTube、X、Substack 和 Patreon 上都有，还有播客。它无处不在。但是，如果你想在经济上支持 Lond Journal，使其完全不受广告商支持，没有赞助的剧集，也没有任何公司可以告诉我们该想什么或说什么，请考虑成为订阅者。同样，所有这些都在 luk.com 上。感谢那些终身订阅者，他们让这一切成为可能。月度和年度订阅者也很棒，但他们不能上墙。终身订阅者会登上墙，现在有四位。第五面墙将在本周某个时候首次亮相。以及我为一到四面墙做了一些小的改动。我把一到四面墙都挂起来了，它们都有不同的主题，对吧？比如墙二是 DOS Word，墙三是 Windows 311 记事本，等等。一旦它们挂起来，几个人就说，“伙计，我真想登上那面墙。”所以，我将允许几个人进行一些更改。如果你需要进行更改，请今天提交。我将移动一些名字，因为有些人说，“伙计，我必须登上记事本.exe 墙，我必须这样做。”我明白了。你懂的。这可能看起来是件小事，但我完全理解。有一个人目前，我不会说出他的名字，在 DOS 墙上，他说：“不，不，不。把我放到 Mac OS 9 墙上。我想登上那面墙。”好的，你明白了。所以，本周晚些时候，我将推出这些墙略微修改的版本，移动一些名字，修复一个拼写错误，因为我实际上是手工输入了所有这些名字，因为这些都是截图，运行在……不同的机器和平台上。然后，我将推出第五面墙，以及另一个新主题，我认为你们会喜欢的。所以，再次感谢所有订阅者。没有你们，我做不到。

就这样，女士们先生们，男孩女孩们，书呆子们，以及互联网上的书呆子们，我宣布广播结束。