Oils - 回顾我们4年来的NLnet资助

# 回顾我们的 NLnet 资助：四年之后 来源：https://oils.pub/blog/2026/06/grants.html \|[博客](https://oils.pub/blog/) \| [oils.pub](https://oils.pub/) 2026-06-01 我们在 **2022 年 6 月** 获得了第一笔 [NLnet](https://nlnet.nl/) 资助，此后又陆续获得了三项资助。四年、四项资助之后，值得回头看看我们都做了什么。 所以，我为本篇文章制作了一些**图表**！ 遗憾的是，第四项资助我们将无法完成。因为三月份提到的家庭问题，我提前结束了它：[项目暂停](https://oils.pub/blog/2026/03/status-update.html)。实际情况是，越来越多的贡献导致 pull request 积压，我无法逐一审核。 此外，我也会分享一些关于项目现状的宏观想法和感受。 ## 新图表 2022 年 3 月，就在我们获得第一笔资助之前，我发布了 [Oil 正在“从中间向外”实现](https://www.oilshell.org/blog/2022/03/middle-out.html)。 里面有一个关于我们 [spec 测试](https://oils.pub/cross-ref.html?tag=spec-test#spec-test)指标的[图表](https://www.oilshell.org/blog/2022/03/middle-out.html#plot-progress-in-two-directions)。 我当时写道，灰色矩形显示了 [OSH](https://oils.pub/cross-ref.html?tag=OSH#OSH) 开发中的一个**“休耕期”**。OSH 的进展不如以往快，因为我开始着手开发 [YSH](https://oils.pub/cross-ref.html?tag=YSH#YSH)（当时称为 Oil 语言）。 换句话说，很明显项目变得过于**庞大**，我需要帮助！那么，在我们获得资助、更多人参与之后，发生了什么？ ### OSH —— 速度与兼容性 我重新启用了生成那个 2022 年图表的代码（包括 shell、Python 和 R 脚本！）。这是更新后的版本： OSH 进展 不错，我没想到故事会看起来如此**清晰**！ - 蓝色线和红色线在 **2023 年初** 汇合，这意味着 Python 实现和 C++ 实现通过了所有**相同的测试**。换句话说，我们完成了 Python 到 C++ 的翻译工作。 - 这意味着我们可以“只写 Python”，然后得到一个快速、原生代码、无依赖的 shell。这就像用 C 编写的 shell 一样。 - 我们还在 2023 年 1 月完成了垃圾回收器：[一个工作中的垃圾回收器图片](https://www.oilshell.org/blog/2023/01/garbage-collector.html)。这是一个巨大的成就，图中没有体现。我们现在拥有比用 C 编写的 shell **更好**的东西：垃圾回收意味着我们的代码是内存安全的！ - 汇合后的线条的**斜率**增加了。这意味着一旦翻译完成，我们在 [OSH](https://oils.pub/cross-ref.html?tag=OSH#OSH) 上的进展更快了。 - 我提到的休耕期是蓝色线条**更平缓**的那部分——从 2020 年中到 2023 年。 所以，来自 [NLnet](https://nlnet.nl/) 的资助确实帮助了 [OSH](https://oils.pub/cross-ref.html?tag=OSH#OSH)。 ### YSH —— 优雅的升级，以及一门新语言 但这还不是全部！在第一项资助之后，贡献者们对 [YSH](https://oils.pub/cross-ref.html?tag=YSH#YSH) 感到很兴奋，于是我又申请了另一项资助。（我还在 2023 年初[重命名了项目](https://www.oilshell.org/blog/2023/03/rename.html)。） 这是 YSH 进展的类似图表： YSH 进展 注意几点： - [YSH](https://oils.pub/cross-ref.html?tag=YSH#YSH) 实际上直到 **NLnet 资助之后** 才存在。之前根本没有红色线，我也不建议使用纯 Python 版本。 - [YSH](https://oils.pub/cross-ref.html?tag=YSH#YSH) 在 2024 年初完全翻译为原生代码——即红色和蓝色线在那时汇合，比 [OSH](https://oils.pub/cross-ref.html?tag=OSH#OSH) 的汇合晚大约一年。 - 汇合后线条**斜率**的增加表明，从 2023 年中到 2025 年，我们在 [YSH](https://oils.pub/cross-ref.html?tag=YSH#YSH) 上取得了很大进展。那时正是该语言大部分功能被开发出来的时期。 所以这些图表描绘了一个清晰而积极的画面。资助确实有帮助！在制作图表之前，我不确定它们看起来会如何。 ### Alpine 软件包分歧 —— 从 139 到 11 好了，现在让我们看看过去一年左右发生了什么。第四项资助的目标是对 [OSH](https://oils.pub/cross-ref.html?tag=OSH#OSH) 进行压力测试，将其作为完整 Linux 系统（Alpine Linux）上**唯一**的 shell 来运行。我在十二月份描述了这项工作： - [Oils 0.37.0 - Alpine Linux、YSH 和 mycpp](https://oils.pub/blog/2025/12/release-0.37.0.html) 贡献者们写了关于一些修复的博客文章，我在三月份链接了它们： - [八篇贡献者博客](https://oils.pub/blog/2026/03/writing.html) - [另外四篇贡献者博客](https://oils.pub/blog/2026/03/writing2.html) 我们通过这个仪表板（用 Markdown 和 shell 脚本制作）跟踪工作： - https://op.oils.pub/aports-build/published.html - `regtest/aports` 的结果 以下是该数据的可视化（限于 Alpine `main` 仓库）： 2025年 regtest/aports 的进展 所以从八月份使用 [OSH](https://oils.pub/cross-ref.html?tag=OSH#OSH) 构建时出现的 **139** 个分歧，减少到十二月初的 **11** 个。（在最后一次测量出 12 个分歧之后，至少还有一个分歧被修复。） 这是一个非常好的**势头**，但有一个注意事项。我**合并**了许多 pull request，但未审核的 pull request 积压也增加了。 而在同一个月，我的大部分空闲时间消失了。 ## 评价 老实说，在写这篇文章之前，我对项目感到有点**沮丧**。我向 [NLnet](https://nlnet.nl/) 发送了不止一封电子邮件，解释资助的提前结束，这些邮件可能过于悲观了。 但现在我对我们所做的事情感觉还不错。 我的看法是，我们实现了**资助**的目标，但这并不一定意味着整个**项目**已经成功。所以让我们先谈谈资助，然后再谈项目。 ### 我们实现了资助的目标吗？ 是的，图表基本上展示了这一点，但它们并没有讲述全部故事。我认为真正的故事是我们做了很多本可能失败但最终成功了的**困难**事情。 - 我们本可能无法通过将类型化的 Python 翻译成 C++ 来**加速**代码 30 到 50 倍。但这事确实发生了，在第一项资助期间。 - 我们本可能无法编写一个垃圾回收器。但我们做到了，并且它现在已经稳定运行了好几年。 - [YSH](https://oils.pub/cross-ref.html?tag=YSH#YSH) 的**设计**本可能失败，例如由于兼容性限制。但这并没有发生：- 当我开始这个项目时，许多人认为升级 shell 是不可能的！但现在，多个人已经编写了数千行 [YSH](https://oils.pub/cross-ref.html?tag=YSH#YSH) 代码，包括在专业环境中！感谢 Will Clardy 和其他许多人的代码和反馈。 - 也许没有人愿意以每小时 50 欧元的价格为 Oils 工作。但实际上，我收到了大量的回应。我们选择的贡献者非常有技能——在很多方面比我更有技能。 所以，我持续在这个项目上工作了 **10 年** 的一个原因是事情一直在进展。虽然有过几次“走弯路”和一些回退，但我们从未长期卡在任何事情上。 而且我认为，只要我们有时间正确完成，我们基本上**没有风险**无法弥合剩余的 11 个分歧。 ### 项目是否实现了目标？ 但即使我们实现了这些较小的目标，我认为是时候重新评估**项目**目标了。 （重要的是，**我可用时间的减少**影响了整个讨论。我希望情况会改变，但可能不会很快改变。） 那么，让我们回到口号： > 从 bash 到更好语言和运行时的升级路径 我们确实做了许多人认为不可能的事情：以原则性的方式实现一个兼容 POSIX 和 [bash](https://oils.pub/cross-ref.html?tag=bash#bash) 的 shell；然后将其升级到新语言 [YSH](https://oils.pub/cross-ref.html?tag=YSH#YSH)（尽管有一些注意事项）。 但是，我不确定这在实践中是否真的是一条升级路径。我低估的是，这种策略需要**发行版**做大量工作。而大多数发行版的基础设施不会轻易改变，原因显而易见。许多基础的 shell 脚本处于维护模式，维护者只了解其中的部分。 另一方面，我会说，例如 [systemd](https://en.wikipedia.org/wiki/Systemd) 证明了基础架构可以以一种相当激进的方式改变。而且发行版**拉取**了 systemd，显然是因为它为他们节省了大量工作。但我也看到，目前，还没有一个杀手级理由让发行版拉取 Oils。更像是我们在**推送**，我认为，没有一些大的改变，这在某种程度上是根本性的。 ### 更大的目标 所以，我可能不再相信“从 bash 升级路径”这个框架。目前，它看起来不太现实。 但我仍然相信项目**更宏大**的目标： - “压缩”许多领域特定语言到一个通用 shell 语言：[YSH 功能草图](https://www.oilshell.org/blog/2023/06/ysh-sketches.html)（2023 年 6 月） - 我们在让 YSH 成为 DSL 宿主方面取得了一些进展，但还不够。 - 为什么这仍然有趣？当编写代码变得廉价时，**阅读**代码变得更有价值。到目前为止，我还没有发现谁喜欢阅读由 shell、awk、make、CMake、YAML 混杂而成的东西——也就是 [Unix 污泥和云污泥](https://oils.pub/ysh.html)。 - 分布式 shell - 我们自己在 `regtest/aports`、Soil CI 以及在云中发布版本时遇到了这个问题。请参见下面的 TODO 列表。 - 分布式 shell 的补充是分布式文件系统。与 [J8 表示法](https://oils.pub/cross-ref.html?tag=j8-notation#j8-notation)一样，从**数据**而非计算的角度重新思考问题会有所帮助。 - 本博客上[最受欢迎的文章](https://www.oilshell.org/blog/2021/07/blog-backlog-2.html)以 [Kubernetes 是我们这一代的 Multics](https://news.ycombinator.com/item?id=27903720) 的标题传播（5 年前，也就是项目开始 5 年后！） - 无头 shell / GUI 界面 - [截图](https://www.oilshell.org/blog/2023/12/screencasts.html#headless-protocol-oils-web_shell) 和 [Wiki](https://github.com/oils-for-unix/oils/wiki/Headless-Mode) - 像 Claude 和 Gemini 这样的 LLM Web 界面在我看来很像一个 shell。这一点并没有被很多人忽略，例如 Filip Pizlo 的 [yosh](https://yoshell.ai/) 和 Warp 终端。LLM 是十年来编程领域最大的一件事，它们与 Unix shell 紧密纠缠。 但我真的不知道如何在我拥有的时间和我们拥有的资源下在这些目标上取得进展。但说实话，追求它们让我非常**开心**。 ## 我写给 NLnet 的其他内容 本文中的大部分观点我已经在给 NLnet 的邮件中提到了。以下是一些来自那些邮件的其他想法。 ### 项目管理 我们没有找到足够多的人来开发 [YSH](https://oils.pub/cross-ref.html?tag=YSH#YSH) 本身。Aidan 实现了 [YSH](https://oils.pub/cross-ref.html?tag=YSH#YSH) 的关键部分，并提供了关于[闭包](https://www.oilshell.org/blog/2025/01/release-0.24.0.html)等特性的重要设计反馈，但本可以需要更多帮助。 一个可以观察到这一点的方式是：我们从未解决过如何同时推进 [OSH](https://oils.pub/cross-ref.html?tag=OSH#OSH) 和 [YSH](https://oils.pub/cross-ref.html?tag=YSH#YSH) 的问题。例如，第四项资助完全集中在 [OSH](https://oils.pub/cross-ref.html?tag=OSH#OSH) 上，而在此期间我们在 [YSH](https://oils.pub/cross-ref.html?tag=YSH#YSH) 上没有取得太大进展。 图表**确实**显示了进展的加快，所以资助确实有帮助。但我认为项目的范围一直太大。 ### 设计瓶颈 / 去中心化的 FOSS 模型 我也觉得我对 FOSS 模型下能做什么有点天真。我之前没有足够关注项目的组织。在 NLnet 资助之前，我自己一个人工作了六年！也有其他贡献者，但没有一个接近全职的。 另一种说法是，从历史上看，我感兴趣的是像贝尔实验室 Unix 这样的东西，而不是 GNU/Linux。我对新的系统**设计**思想感兴趣，不亚于对现有系统的原则性实现。 这里有一个相关的评论： > 我认为 Linux 欠贝尔实验室一笔巨大的设计债 [2] ... > 我实际上想知道 LLM 生成的代码是否是系统崩溃的迹象。也就是说，我们有这些巨大的杂乱的开源代码，理论上应该非常有价值，但很大一部分新程序员只能通过向 LLM 抛出代码来理解它…… 换句话说，我想说，在引入 LLM 之前，我们的集体软件基础设施状况并不好。 ## 总结 由于我们提前结束了第四项资助，我认为发表我的想法是合适的。在过去四年中，我们取得了巨大的进展，但项目目前处于“暂停”状态。仍然会有更新和发布——参见下面的 TODO 列表——但会变得缓慢且按需进行。 也就是说，我希望人们会出现在 [Zulip](https://oils.pub/cross-ref.html?tag=zulip#zulip) 上聊天，但我不会在相当一段时间内“推动”项目。 ### 感谢 感谢所有贡献的人！不仅仅是那些在资助下工作的人，还有所有其他人。 - Jesse Hughes, Melvin Walls, CoffeeTableEspresso - Chris Watkins, Aidan Olsen, Samuel Hierholzer - Justin Pombrio, Koichi Murase - Andriy Sultanov, Bram Tertoolen, Gabriel Stang, Adejumo David Adewale 也感谢 NLnet！ - Michiel Leenaars, Bob Goudriaan, Lwenn Bussière, Gerben, Layla Otter，以及其他所有在幕后帮助的人。 --- 请随时在 Zulip 的评论中提问或提供反馈 [在 Zulip 上](https://oilshell.zulipchat.com/#narrow/channel/392989-blog-comments/topic/Reviewing.20Our.20NLnet.20Grants.20After.204.20Years/with/599284299)！ ## 附录 ### TODO 列表 这是我目前正在考虑的事情。 - 解决 [YSH](https://oils.pub/cross-ref.html?tag=YSH#YSH) `try` 设计中的问题，来自 Will Clardy 和 Samuel Hierholzer。 - 我认为我们可以让 Oils 解析器在 Python 3 下运行，用于 [resholve](https://github.com/abathur/resholve) 用例（Travis Everett）。 - 我想合并**部分** pull request，其中大部分与 [OSH](https://oils.pub/cross-ref.html?tag=OSH#OSH) 相关。带有新测试的更改应优先处理。 - 发布另一个版本。 - 这让我想起 [#容器 > 在云中发布版本](https://oilshell.zulipchat.com/#narrow/channel/308821-containers/topic/Make.20Release.20in.20the.20Cloud/with/530390147)，这是一个 [#分布式 shell](https://oilshell.zulipchat.com/#narrow/channel/348521-distributed-shell) 用例 - 我希望除了我之外的人也能发布版本。 - 回复一些 GitHub 问题 - 抱歉，我不再喜欢 GitHub 了：[#oils-discuss > 关于 Codeberg/sourcehut 的讨论](https://oilshell.zulipchat.com/#narrow/channel/121540-oils-discuss/topic/Threads.20about.20Codeberg.2Fsourcehut/with/564761044) ### 未来的文章 以下是我从本文中删除的一些主题。 #### LLM 帮助我处理了糟糕的旧语言：VimScript 和原始 SQL 在 2025 年初，我用 **VimScript** 编写了 YSH 语法定义，结果产生了文档 [YSH 语法高亮的三种算法](https://github.com/oils-for-unix/oils.vim/blob/main/doc/algorithms.md)。 基于我大约 2008 年对 VimScript 的经验，我可以肯定地说，如果没有几十次向 Claude 的查询，这不会发生。（但你可以从文档中看到，这不是“氛围编码”。相反，我通过编写一个认真的递归下降解析器来学习该语言。Vibe 编码本身就很难。）