github与软件的犯罪 一篇由Efron Licht撰写的软件文章 2026年5月 所有文章 许可 订阅 feed RSS ATOM JSON 引言 如果一栋房子在着火，可能只有两个立场。一个支持灭火。另一个支持房子烧毁。 ——亚伯拉罕·林肯 当我开始这篇文章时，GitHub又一次宕机了。尽管有很多文章谈论GitHub在可靠性、安全性和性能上的挣扎，比如The Verge的这篇，但这些文章只是触及了表面。GitHub在一定程度上是Github自身及大科技软件服务世界基础设施衰退的“信号”。虽然我可以指出几乎每个大型科技企业服务中的类似衰退，从AWS到Google搜索，但GitHub由于与软件开发几乎同义而成为一个特别显著的例子。我记得在2022年和一位招聘人员的对话，他们根本不相信我是真正的“程序员”，因为我没有GitHub账户。 GitHub本应是一个高性能、高可用性、高容量的分布式系统 - 这正是我的个人专业，所以我可以比普通的科技记者对这个问题给予更多的见解。这不仅仅是可用性：GitHub充满了问题。这些问题包括但不限于（加粗部分将得到证明）： 最近关于GitHub问题的一小部分样本 - 根据他们自己的公开通信，GitHub每月发生数十起事件，这意味着实际发生率可能在数百起。 - GitHub没有公开的错误列表或任何问题页面，将问题深藏在邮件交流中。 - GitHub不断对其用户撒谎关于它的正常运行时间和优先事项。 - 即使按照自己的标准，它也违反了其服务水平协议（SLA）。 - GitHub明显优先考虑花哨的AI功能，而不是基本的可靠性。 - GitHub上“代理负载”的增加直接源于他们自己的行为和母公司微软的行为，这使得可靠性问题成为他们自己的责任。 - GitHub在Firefox和Safari浏览器上经常出错，后者有数百万用户。 - GitHub容忍明显的“跟随者购买”和“明星购买”行为，并推广明显的虚假仓库：实际上有一个名为githubstars.com的网站公开宣传购买明星，参见卡内基梅隆大学发布的这篇论文，尽管引用：“虚假明星与恶意活动高度相关”。 - GitHub的拉取请求页面（尤其是评论/审查页面）反应缓慢且极其占用内存（我见过堆内存峰值超过512 MiB！）。 - GitHub经常重置或更改项目和用户设置：新功能“默认开启”，即使是极其危险的。 - GitHub明显优先考虑花哨的“AI”项目，而非真正的付费客户。 - GitHub Actions设计糟糕、运行缓慢且文档欠佳，可能是“以YAML编写的shell脚本”式构建系统中最糟糕的，我见过数十种。 - GitHub Actions日志泄露内存，多年来导致我的浏览器崩溃，仍然没有办法将stdout管道输出到某处。 - GitHub的“默认”动作（例如，setup-go）的默认缓存行为荒谬幼稚，甚至不如什么都不做；其中许多根本不进行缓存失效。 > 我可以继续谈下去。这是一个糟糕设计的分形，引用著名的关于PHP的谩骂。 GitHub的前端……相当臃肿和缓慢，经常在Safari和Firefox上出错，毫无预警或解释地不断改变用户体验，常常故意用越来越多指向其“AI”系统的漏斗替换掉以前有用的功能。 目录 - 2026-05-29自动生成 - 引言 - GitHub近期问题的小样本 - GitHub不断对其用户撒谎关于它的正常运行时间和优先事项 - GitHub上的“代理负载”的增加是其自身行为和母公司微软行为的直接结果 - GitHub前端代码杂乱不堪 - GitHub、GitLab和Codeberg的比较 - 图像：GitHub、GitLab、Codeberg的仓库登录页面 - 实验设计 - 实验过程 - 运行实验 - 创造仓库 - 上传仓库到GitHub、GitLab和Codeberg - 收集网络样本数据 - 在负载后收集堆内存使用情况 - 堆内存使用分析及历史比较 - 使用testcompress收集关于压缩支持的信息 - 分析网络归档har与anhar - 1部分的解释 - 这个“恶化”的例证 - 第三方分析-pagespeed-web-dev - 移动pagespeed给出了关于如何改进性能的优秀建议，我将在我们进行时强调一些更有趣的建议和自己的想法 - GitHub、GitLab和Codeberg的比较 - GitLab总结 - 成绩：D - 开发者建议 - 用户建议 - Codeberg、Forgejo总结 - 1成绩：C - 开发者建议 - 用户建议 - 评论 - GitHub总结 - 2 成绩：F - 评论 - 1 开发者建议 - 用户建议 - 2 - eblog-fly-dev-startingsystems3-html总结