Zig 退出 GitHub，称微软对AI痴迷毁了这项服务

GitHub-extender ZenHub may add GitLab support, claiming platforms are 'unapproachable' for non-technical types • DEVCLASS

负责推广 Zig 编程语言的基金会已经正式退出 GitHub，原因是其领导层认为此代码共享网站正在衰落。

这场风波始于 2025 年 4 月，当时 GitHub 用户 AlekseiNikiforovIBM 发起了一个名为“safe_sleep.sh 很少无限期地挂起”的讨论帖。GitHub 在 8 月份解决了这个问题，但并未在讨论帖中提及此事，该帖子一直开放到周一。

上周，Zig 软件基金会主席兼首席开发者 Andrew Kelly宣布，Zig 项目将迁移到非营利性 Git 代码托管服务 Codeberg，因为 GitHub 已经不能再体现其对卓越软件工程的承诺。

他提供的佐证之一是“safe_sleep.sh 很少无限期挂起”这个线程。

“最重要的是，GitHub Actions 存在着这样不可原谅的漏洞，却完全被忽视了，”Kelly 写道。“ GitHub 的 CEO 曾说过‘要么拥抱 AI，要么滚蛋’，看来微软的那些走狗们领会了其中的含义，因为 GitHub Actions 开始‘随机调度’——看似随机地选择要运行的任务。再加上其他漏洞以及无法手动干预，这导致我们的持续集成系统严重积压，甚至连主分支的提交都无法检查。”

更古老、更深沉的故事

Kelly 的抱怨似乎充满道理，因为该帖子中讨论的错误似乎是在 2022 年 2 月的代码更改之后出现的，用户在之前的错误报告中指出了这一点。

此次代码更改将 posix “sleep” 命令替换为 “safe_sleep” 脚本，但该脚本未能按预期工作。它原本应该允许 GitHub Actions 运行器（即运行 GitHub Actions 工作流中作业的应用程序）安全地暂停执行。

Zig 核心开发者 Matthew Lugg 在 4 月份的错误讨论帖中写道：“这个‘安全睡眠’脚本中的错误显而易见：如果进程没有被安排在循环返回的 1 秒间隔内运行（因为 $SECONDS 具有正确的值），那么它就会一直循环下去。 ”

“在负载极高的持续集成（CI）服务器上，这种情况很容易发生。一旦发生，后果非常严重：它会彻底摧毁一个运行器，直到人工干预。在 Zig 的 CI 运行器服务器上，我们观察到多个这样的进程已经运行了数百小时，悄无声息地导致两个运行器服务宕机数周。”

该修复程序于 2025 年 8 月 20 日合并，其源自 2024 年 2 月提出的一个独立问题。相关的错误报告（2025 年 4 月提交）一直开放至 2025 年 12 月 1 日星期一。另一个 CPU 使用率错误到现在仍未解决。

Answer.AI 和 Fast.AI 的联合创始人 Jeremy Howard 在社交媒体X上的帖子中表示，用户关于 GitHub Actions 状况不佳的说法似乎有理有据。

他写道：“这个漏洞的实现方式非常明显，几乎任何人一眼就能看出它会一直占用 100% 的 CPU，并且除非任务恰好在正确的时间检查时间，否则它会一直运行下去。”

我实在无法理解，这样一系列令人瞠目结舌、匪夷所思的事件是如何产生的。

他补充说，去年 2 月提出的针对 CPU 问题的平台无关修复方案，在一年多的时间里都没有经过审查，并在 2025 年 3 月被 GitHub 机器人关闭，之后才被重新启用并合并。

“虽然有人可能会说这只是一起孤立事件，但我无法理解，在一个正常运转的组织中，怎么会发生如此一系列令人瞠目结舌的事件，” Howard总结道。

GitHub尚未对此事作出回应。

Kelly已经为他那篇煽动性帖子道歉，但 Zig 并不是唯一一个公开与 GitHub 分道扬镳的软件项目。

上周末，Dillo 浏览器项目的创建者 Rodrigo Arias Mallo表示道，他计划离开 GitHub，因为他担心 GitHub 过度依赖 JavaScript、GitHub 的拒绝服务能力、可用性下降、审核工具不足，以及“过度关注 LLM 和生成式 AI，这些正在摧毁开放网络（及其剩余部分）等等问题”。

Codeberg 方面，自 1 月份以来，其支持的开发者会员人数翻了一番，从600 多名会员增加到上周的1200 多名会员。