Zig退出GitHub，称微软对人工智能的痴迷已毁掉该平台
在GitHub CEO提出’拥抱AI或离开’后，微软的走狗们似乎领会了暗示，因为GitHub Actions开始’氛围调度’——看似随机选择任务运行
Zig基金会抱怨“氛围调度”问题，安全睡眠漏洞长期未获修复
推广Zig编程语言的基金会已退出GitHub，其领导层认为该代码共享平台正走向衰落。
这场风波始于2025年4月，GitHub用户AlekseiNikiforovIBM发起题为“safe_sleep.sh偶尔无限期卡死”的讨论。GitHub虽在8月修复了问题，却未在讨论组中说明，该问题直至本周一仍未解决。
该代码持续占用100%CPU资源，将永久运行
这一时间节点颇具深意。上周，Zig软件基金会总裁兼首席开发者Andrew Kelly宣布，Zig项目将迁移至非营利性代码托管服务Codeberg，理由是GitHub已不再展现对工程卓越性的承诺。
他援引的佐证之一正是“safe_sleep.sh极少无限期卡死”的讨论帖。
“最关键的是，Actions存在不可原谅的漏洞，却遭到彻底忽视，”凯利写道。”在GitHub CEO提出’拥抱AI或离开’后，微软的走狗们似乎领会了暗示，因为GitHub Actions开始’氛围调度’——看似随机选择任务运行。加上其他漏洞和无法人工干预，导致我们的CI系统严重积压，连主分支的提交都无法检查。”
更久远更深层
凯利的抱怨似乎有理有据，因为该讨论线程提及的漏洞似乎是在 2022年2月某次代码变更后才显现，此前用户已在错误报告中标记该变更。
该代码变更将posix的“sleep”命令实例替换为“safe_sleep”脚本，但该脚本未能如预期运行。其本应允许GitHub Actions运行器(执行GitHub Actions工作流任务的应用程序)安全暂停执行。
Zig核心开发者马修·拉格在评论中指出：”这个’安全睡眠’脚本的缺陷一目了然： 若进程未被调度至循环返回的1秒间隔内(因$SECONDS值不正确)，该脚本将陷入无限循环。”Zig核心开发者Matthew Lugg在4月漏洞讨论串的评论中写道。
“在极端负载的CI机器上极易发生这种情况。一旦发生，后果相当严重：运行器将彻底瘫痪直至人工干预。我们在Zig的CI运行器机器上观察到多个此类进程持续运行数百小时，悄无声息地导致两个运行器服务停摆数周。”
修复方案已于2025年8月20日合并，该修复源自2024年2月提交的独立问题报告。2025年4月提交的相关漏洞报告直至2025年12月1日星期一仍处于未解决状态。另一项CPU使用率漏洞至今未修复。
Answer.AI与Fast.AI联合创始人Jeremy Howard在系列社交媒体帖子中表示，用户关于GitHub Actions维护状况不佳的指控似乎确有其事。
“这个漏洞”，他写道，“以一种极其明显的方式实现——几乎任何人一眼就能看出它会持续占用100% CPU资源，除非任务恰好在正确秒数时检查时间，否则将永远运行下去。”
我实在想不出还有什么比这更离谱的系列操作能让人拍案叫绝
他补充说明，去年二月提出的跨平台CPU问题修复方案滞留一年未获审阅，最终于2025年3月被GitHub机器人关闭 处理，直至2025年3月才被重新激活并合并。
“虽然有人可能认为这只是孤立事件，但我实在无法想象任何正常运作的组织如何能制造出如此离谱的系列事件，” 霍华德总结道。
GitHub尚未立即回应置评请求。
尽管凯利已就其帖子煽动性言论公开致歉，但Zig并非唯一与GitHub公开决裂的软件项目。
上周末，Dillo浏览器项目创建者罗德里戈·阿里亚斯·马洛表示，因担忧平台过度依赖JavaScript、 GitHub拒绝服务的能力、可用性下降、监管工具不足，以及“过度关注大型语言模型和生成式人工智能，这些正在摧毁开放网络(或其残余部分)”等诸多问题。
Codeberg平台自今年1月以来支持会员数量翻倍，从600余名会员增至上周的1200余名。
GitHub尚未披露当前付费用户数量。微软首席执行官萨蒂亚·纳德拉在公司2024年第二季度财报电话会议上表示，该代码托管业务拥有“超过130万付费GitHub Copilot订阅用户，环比增长30%”。
2024年第四季度GitHub公布年化营收达20亿美元时，Copilot订阅业务贡献了公司年度营收增长的约40%。
纳德拉在微软2025年第三季度财报电话会议中给出了不同数据：“当前GitHub Copilot用户已突破1500万，同比增长逾4倍。” 目前尚不清楚有多少GitHub用户为Copilot付费，或为那些本应休眠却消耗CPU周期的运行脚本付费。
该公告的编辑历史堪称惊心动魄：
> [2025-11-27T02:10:07Z] 显而易见，曾参与产品开发的精英们早已转战更广阔的天地，而残留的失败者却打着进步的旗号，急不可待地要向我们强加某种臃肿又漏洞百出的JavaScript框架[1]
> [2025-11-27T14:04:47Z] 显而易见，曾经参与产品开发的精英们早已转战更广阔的天地，而留下的菜鸟们却打着进步的旗号，急不可待地要向我们强加某种臃肿又漏洞百出的JavaScript框架[2]
> [2025-11-28T09:21:12Z] 显而易见，曾缔造GitHub辉煌的卓越工程力已不再是其发展引擎[3]
—
1: https://web.archive.org/web/20251127021007/https://ziglang.o…
2: https://web.archive.org/web/20251127140447/https://ziglang.o…
3: https://web.archive.org/web/20251128092112/https://ziglang.o…
记得在之前的Hacker News文章里，不少评论都提到应该修改这些内容，抛开政治/负面因素，因为这对Zig社区形象不利。
看来他们采纳了这些建议，放下自尊，通过编辑做出了对Zig社区最有利的决定。我赞赏他们为社区利益做出牺牲，即使这意味着要进行自我检讨式的编辑。
我常发现人们往往低估了坦然承认错误并改变立场者的价值。但现实往往相反：人们反而崇尚那些“固执己见”或在明显错误时加倍坚持的人。正如你所言，关键在于具体情境——这些修改似乎是吸取了反馈教训，而非为挽回颜面，因为核心观点依然成立，只是表达方式不再刻意针对特定对象。
我也始终不解这种心态。若有人曾犯错作恶，如今却努力行善，我们理应为此喝彩。不仅因其本身值得称道，更要为未来他人提供改进的机会与动力。
倘若无论是否试图改变，所有人都被视为恶人，那他们还有什么动力去改变？这根本不合逻辑。
这种激励更多关乎自我保护，而非道德层面。
面对网络暴民时，只要目标对象流露丝毫悔意，就会引来鲨鱼群的狂欢盛宴。受审者往往沦为公开的“斗争会”对象。除了避免犯错，经验证最有效的应对策略就是绝不道歉，静待风暴平息。
就个人观点而言，我认为最初的公告既幼稚又对产品开发者过度苛责(这与他们宣称的《行为准则》相悖，我认为既可笑又虚伪)，而他们更新帖文时将批评措辞得更为专业，这令人耳目一新。
我认为真正的坦诚只要配得上坚守自我的品格就行得通。毫不动摇的自我剖析——既表明认清错误又展现纠正决心——几乎永远是正确选择。
承认错误本身不会引发群体性攻击，除非伴随摇摆不定、自怜自艾或乞求宽恕。自我保护应是本能而非目标——一旦流露出任何掩盖、淡化或推诿的迹象，群情激愤便会乘虚而入，从此再无回旋余地。
问题的另一面在于：若恶人行善后仍能逍遥法外，则必须确保其先作恶后行善的回报，既高于持续作恶的收益，又低于始终行善的回报。且这种回报应随其不再作恶的时间推移而递增。
我认同这种观点(人们会改变主意)，但其反面就是迎合他人。那些稍受压力就妥协的人，其实和固执己见者没什么两样。
当然，问题在于改变(或不改变)主意的动机往往不明确，人们很容易通过曲解事实来博取赞誉。
工程师向来不以迎合他人见长。管理层或许如此，但工程师？顶多是些初出茅庐的菜鸟吧？
我并不认为低概率事件的存在，就能合理化某种更常见(且负面)事件的常态化——比如好斗的工程师在设计会议上大发雷霆。我甚至愿意说，工程领域需要更多迎合他人的人。
另外，顺便提一句，若想知道他人为何改变立场，直接询问并评估答案即可。若有人动不动就改变主意，我猜想其最初立场本就不够坚定。
你我经历显然不同，因为我遇到的好斗工程师远少于那些积极主动、面对挑战时不愿掀风浪的人。
我以为自己只是提出了相当中立的观点，甚至不认为是在特指工程师群体。
你无法读懂他人心思，所以存疑时请假定对方善意。
(作为非Zig相关背景的随机HN读者)他们为何纠正错误并不重要，只要他们做了，我就认为这是积极的(至少比在帖子中留下猴子评论要好)。
读心技术已成现实——查查无线电肌电图和解读神经网络的脑电图技术。不过你最好别这么做，未经许可可不行
这并非非黑即白的简单问题，更不能套用在人类历史所有争论中。有时保持开放心态并能改变观点反而更明智。有时坚持理性且/或道德正确的立场反而更可取。
后者之所以常被推崇，正因其践行难度更大——尤其在逆境中，固守立场可能直接耗费金钱、时间、理智，甚至在极端情况下危及自由。通常这意味着个体或小群体对抗无形巨头，更显艰难。当然，我们应当尊重那些对抗企业的勇者。
注：若对方“明显错误”则另当别论。
试想政策制定者改变立场时的处境。他们可能是基于新信息转变观点，或通过深度反思、亲身经历或思想成熟调整立场。反对者却会指责其“摇摆不定”或“立场反复”，暗示其缺乏可靠性或原则(甚至直接质疑收受贿赂)。民选官员肩负着表达选民意愿的责任，因此若其主要由某议题X的支持者选出，那么像普通公民那样保持思想动态，某种程度上可被视为背叛。
这与内幕交易的原话题略有偏离——后者的腐败具有结构性/系统性特征，类似于“利益冲突”客观描述情境而非个人行为的本质。
妖魔化“立场反复”简直愚不可及。兄弟，我 希望 政客在新证据出现或民意转向时改变主张。我们最不需要的就是那些固执己见、拒绝调整任何立场的教条主义政客。
虽然我认同你的观点，但很难反驳“选民是基于政客竞选时的立场才投票支持”的说法。当选者或许会改变立场，但支持他们的选民不会集体转变立场。对那些立场未变的选民而言，这确实像是背弃了原则。理性政客出于自身利益考虑，自然不愿背负这种声名。
我更愿意持续支持那些能以坦诚明智方式解释政策立场转变的政客。政客们发表听起来真实诚恳、像成年人对话的演讲实在罕见——似乎很少有人想要这样的政客。但我想要。
这让我想起斯蒂芬·科尔伯特在2006年白宫记者晚宴上调侃乔治·W·布什的段子：
核心问题在于：
选民投票并非基于逻辑与理性判断，而是凭主观感受。当他们对现状不满时，就会投票给同样宣称不满的人选——无论对方是否真正具备解决方案。
即使对于那些希望基于合理原则投票的少数群体，也很难将信息传递给他们。如果政客改变主意，就必须向选民解释。政治辩论中真的存在能进行深度对话的平台吗？
每间大学教室都配备白板和投影仪。因为需要绘制图表、示意图等。必须先阐明整体框架，再聚焦细节，同时把握全局脉络。
可有哪个国家的政客在与同僚或选民交流时会使用这些工具？
并非立场转变，只是将真实想法的表述改为更平淡的官话
这是(网络)文化特有的现象——无论做什么总会招致非议。
若无人反感你的所作所为，很可能说明你根本没做什么实质性工作。
那番言论将人比作猴子并斥为失败者，实属赤裸裸的人身攻击。在博客上发文就像在集市上向数百人公开喊话。现实中除了想煽风点火的人，没人会用这种措辞。人们总忘了自己是在公共场合发言——这种情况下，不仅代表自己，更代表着他人。
有人说若你始终坚持己见且愈战愈勇，说不定能当上总统。
对我而言这很大程度上取决于语境。
特来此处表述此见。我们应当承认他采纳了我们的反馈并有所改进。这是好事。
因为这触及了人类认知中一个奇怪的缺陷。当某些混蛋因错误决策成为领导者，待风向转变后他们恍然大悟并自我检讨时，总有一群人宣称他们反而更配得上领导地位——因为他们具备改变的能力。他们指责那些始终坚持正确观点的人固执己见，质问“若改变立场就会遭受如此对待，谁还愿意转变观点？”
若连我刻意构造的这个荒谬场景都看不透问题所在，那才是真正的隐患。我们之所以关注此人，纯粹是因为他喋喋不休且处处错误。如今却要求我们为其正确而自豪，并确保其承认错误后不失地位。这反而成为先前攻击正确者的人继续攻击的借口——这些正确者如今被正式贴上教条主义清教徒的标签，问题在于他们“正确得不够正确”。
这是社会现象，而非领导者的个人缺陷。人可能先错后对，也可能无所谓是非，只为博取关注或牟利而追随潮流。我认为这两种行为本身并无道德问题。症结在于存在这样一群人：他们盲目追随某个个人，复述其言论，随其变幻立场，首要目标就是攻击任何批评该人物的人。他们根本不在乎议题本身(通常也知之甚少)，只是像守护家人般捍卫那个偶像。
当议题涉及审美或消费等无足轻重之事时——比如“他曾痛恨新版蝙蝠侠电影，如今却声称自己误解了它们”——这种现象本无伤大雅。但当涉及生死攸关的事务，或关乎他人生活与职业的重大损害时，少数激进分子对这种人格崇拜的痴迷便成了毒瘤。
这种现象如此普遍，如今任何议题前都仿佛排着长队的新生信徒在发表意见。 先生，您三年前还是撒旦教徒呢 。
你论点的谬误在于提及“永远正确”之人。
这种人根本不存在。正因如此，面对新信息时能改变观点的能力，才是优秀领导者的关键特质。
应是“始终正确看待此事的人”而非“永远事事正确的人”。
但我们关注安德鲁·凯利，恰恰是因为他在诸多问题上判断正确(例如Z字形设计)。
我认为当人们因舆论压力彻底转变立场时，很难分辨其转变程度究竟源于真心改变，还是对真实想法的掩饰。
淡化激进措辞并非“彻底转变立场”，将“GitHub只剩失败者”改为“工程卓越性已然消逝”的表述称之为谎言，未免显得虚伪。
我回应的是普遍观点：
> 我常发现人们不够欣赏那些勇于承认失败、改变主意的人。不知为何，我看到的恰恰相反：人们反而尊重那些“固执己见”或在明显错误时加倍坚持的人。
并非针对具体事件。
依我之见，真正“听取反馈、放下自尊”的人，会在帖文末尾附注修改说明。承认错误需要保留原话证据，而非抹去痕迹。
(他确实发布过模糊的致歉声明https://ziggit.dev/t/migrating-from-github-to-codeberg-zig-p…，但措辞模棱两可，受冒犯者可自由解读为撤回冒犯性指控，亦可视作未撤回。在当前社交媒体环境中，这或许是求生的最佳选择——向一群代表素不相识者表演式愤怒的暴民道歉，最多徒劳无功，通常还会适得其反，因为这会让你沦为脆弱的受害者。但即便最佳选择，也往往会削弱而非强化我们所讨论的那种正直品格。
> 承认错误并不意味着抹去言论证据。
我认为没有义务向新读者声明“嘿，这篇帖子的早期版本过于煽动性”。但当有人就错误指正你时——正如你链接的论坛帖中所发生的情况——你应当坦诚承认过失。我认为这些做法都无可厚非。
若这些新用户是通过评论旧版本的用户链接进入的，我认为有必要说明。
若你代表公司发言并在公开平台发表批评，或许该换种表达方式。但那些刻薄的推文，往往远不及某些商业决策对客户和开发者造成的伤害。
我认为这里的开发者对这些变更可能完全无辜。产品经理必须推动整合否则就会被替换——这在微软已是长期存在的主题。
我认为此处无需特别说明，因为原内容本身并无谬误，且有充分证据佐证。问题仅在于措辞不当且毫无缘由地粗鲁，故修改为更礼貌的表述，这不构成更正或撤回。
事实是他的观点本身并无谬误，只是不愿理会Reddit等平台那些纠正措辞的网络喷子。
这完全是他原文的合理解读，没错。
证据并未被删除，因为证据依然存在。
你是指某个第三方网站？该网站目前恰好保存了Zig团队无法控制的页面快照，而这个快照随时可能消失？
该网站是开源的，提交记录依然存在。不必如此大惊小怪。
https://github.com/ziglang/www.ziglang.org/commit/c8d046b288…
哦，谢谢，我还以为watwut指的是archive.org。这个diff在codeberg上也能链接吗？
表达对某个过程或事件的惊讶/担忧是有用的。我们完全可以将所有沟通扁平化，把一切简化为极其中立的“赞”、“踩”和“精准到位”。
发现这幅画歪了0.00001º：踩
发现酷刑与大屠杀：踩
显然这种状态荒谬至极。现实中的细微差别远比这丰富得多。
或许受荷兰文化影响：我认为这次改写糟透了。原句远胜于此，虽然首次改写(将“newbies”改为“rookies”)算是进步。
Zig团队深感震惊，认为这种状况值得高度关注，并希望在措辞中传达这种更具情感冲击力的直觉反应。
人类创造丰富多彩的语言和形容词绝非偶然。 所有语言都如此 。因为这很有用！
而这次改写却剥夺了这种力量。这绝非好事。互联网文化显然已被美国化到如此地步，任何稍带色彩的语言都会被瞬间视为人身攻击，进而将整个讨论彻底引向无谓的礼仪争执和“是否得体”的争论——这种行为简直幼稚至极。我多么希望现实并非如此。
在人际交往中，美国人以情感表达的单薄著称——即便在友好互动时亦是如此。若非要从人类学角度解读：当背景迥异的大批移民涌入广袤土地时，文化误解极易发生且代价惨重，此时最稳妥的做法莫过于挂上灿烂笑容，尽可能保持外交辞令！
以实际案例为例：林纳斯·托瓦兹那些著名的沟通方式。“英伟达？去你妈的！”这句堪称经典。它以极其精炼的方式表明，林纳斯不仅对当时英伟达显卡驱动团队的质量和行为持负面评价，这种负面评价更覆盖了广泛领域且极其强烈。这句三字箴言恰如其分地引发了必要的震动。
(互联网普遍难以应对犀利言辞的现象，未必是网络美式化的过错：互联网本质上酷似早期美国社会——至少在文化误解风险方面，远高于地球上大多数地区的面对面交流。)
若能为你点赞，我定当如此。我向来厌恶那群主张人人都该成为超级外交辞令的公关话术师的群体——他们事事推诿搪塞，认为不如此便是“冒犯”或“不专业”。我完全不认为原文句式或用词有问题，因为它并非针对特定个人蓄意冒犯，而是指向微软公司本身。即便真有冒犯意图，在网络世界里总会有人感到不快——你就算措辞再得体，也总有人能找到被冒犯的理由。若处在普通情境下，我也会指出用词不当，因为确实不必要。但考虑到原文所指的所有证据，很难说GitHub不值得被批评。我也实在看不出这种措辞在此情此景下有何不妥。有时要表达观点，“不专业”(无论这个词如今意味着什么)反而是唯一途径。
赞同楼主观点。更关键的是，最终修订稿删去了所有实质性的“原因”。或许他们本可以/应该更委婉地表达厌恶，但完全省略反而让问题变得更显眼。
不过话说回来，前端重构(GitHub曾为此大肆宣传许久)和对AI胡扯的执着，让我彻底停止在个人项目中使用GH，也不再为托管在GH的项目贡献代码。
> 看来他们采纳了反馈，放下自尊，通过这些修改做出了对Zig社区最有利的决定。
确实如此。文章甚至提供了链接。
https://ziggit.dev/t/migrating-from-github-to-codeberg-zig-p…
感谢指出！我查看了编辑历史，未核对时间戳就误以为是倒序排列。发现自己搞错时不禁莞尔。
我欣赏安德鲁及其他Zig团队成员对项目、目标及其背后的理念怀有真挚热忱。但近期爆发的负面事件令我深感沮丧，这些行为严重损害了他们的目标。值得称道的是，他们正在倾听反馈并努力保持高姿态(尽管对行业走向深感沮丧)。
我确实更欣赏那句关于臃肿、漏洞百出的JavaScript框架的 坦率 表述。否则还不如让大型语言模型吐出套话道歉文案来解释更换供应商的决定。就像万千如出一辙的模板照搬。任凭双眼舒适地发呆，零记忆留存。
人们难道忘了ReactJS移植曾让GitHub变慢吗？https://news.ycombinator.com/item?id=44799861
你执意采用的这种政治正确、经过净化后的重新表述，完全未能传达这个至关重要的信息。
言论自由的存在自有其道理——直率的诚实能传递重要信息，而被动语态则无法做到。
或许最终版本本应保留对“漏洞百出的臃肿JavaScript”的批评，因为这是个相当实质性的问题——现在我无法确定他们修改内容是出于“语气”考量，还是认为技术性批评不妥，抑或另有其他问题？
Zig是一种刻意设计为在Windows换行符处报错而非解析的语言(与所有现有语言相反)。他们开发了Windows版本，却让它无法兼容任何Windows文本编辑器。他们的解决方案是“换更好的编辑器”、“编写预处理程序去除换行符”或“别用Windows”(尽管他们提供了Windows可执行文件)。
这个团体从诞生之初就缺乏社群意识和实用主义精神。
至少这次变更会导致源文件无法移植，这显然很糟糕。
说真的，这条评论真让我很想试试Zig！
你想要的语言是：先在特定平台发布编译器，再因琐事故意破坏所有人的使用体验，只为恶搞和惹恼用户？
我欣赏这种语言——它极力阻止人们在Windows记事本里写代码。
Windows所有文本编辑器默认都添加换行符。
你根本没给出合理依据，既然讨厌Windows为何还要用它？又何必在意别人用什么编辑器？
在某个平台发布产品却故意折磨自家用户，这合理吗？
据我所知连苹果都迁移到LF了。或许是时候让Windows停止当异类了？无论如何：
据我所知，Visual Studio Code和Notepad++均支持自定义换行符。这已覆盖多数使用场景。就连内置的记事本也支持CR或LF格式长达八年之久。
或许是时候让Windows停止当异类了？
这和zig的谬论如出一辙。Windows本就是异类。若要在Windows平台发布软件，只需在行尾添加一个字节即可。这并不困难，连最简单的玩具语言都做得到。这只是行分割的环节，甚至不属于语言层面的问题。
据我所知，Visual Studio Code和Notepad++都能配置行尾格式。
上次我查证时发现这完全没必要——毕竟没有其他语言会针对特定平台发布时故意惩罚用户。这类选项本该用于跨平台文件兼容，而非让编译器借机折磨用户。
> 这和zig的胡扯借口如出一辙。
你大概没经历过网页开发早期，那时光是支持IE就得钻各种荒谬的牛角尖。至少当年还有个借口——IE占据市场主导地位，企业用户众多。
整个行业被迫支持IE的做法，严重限制了网站/应用的实现能力。大约2012年左右(恰逢我离开网页开发领域)，越来越多的核心团队开始 停止 支持早期漏洞百出的IE版本(这主要得益于Chrome浏览器的崛起)。此举极大推动了网页应用的进步，也迫使微软认真改进其浏览器。像Zig团队这样的行动，才是推动微软改善现状的唯一途径。
或许你会辩称“但Windows用户占比高达70%！”但此问题仅影响Zig应用程序的开发者，而非运行者。若你是对Zig充满好奇的初级开发者，这类错误或许能成为良性提示——或许Windows并非你理想的开发平台。
你或许会辩称“但Windows用户占比高达70%！”但此问题仅影响开发者而非运行Zig应用的用户。
没人会搞不清编译器的工作原理。当你创建语言时，那些被故意戏弄的人正是你的用户。
若你是对Zig充满好奇的新手开发者，这类错误或许能再次提醒你：Windows可能并非你理想的工作平台。
既然如此，他们为何还要推出Windows版本？任何理智的人都会意识到：不该将时间投入到故意刁难新用户的编程语言上。
你至今仍未给出任何解释，关于Internet Explorer的那些离题之论毫无关联。你整段评论没有半句说得通。你凭什么在意别人的操作系统和文本编辑器？究竟是何等偏执，才会因为某语言故意针对与你无关的事物而恼怒，就执意要使用它？
整件事本质上就是“这东西毫无价值可言，我只是决定讨厌某些人，他们做了让我不快的事——尽管他们其实只是在自掘坟墓”。
莫非我漏看了微软的正式指令？还是说纯粹因为有人胆敢违背你的标准就暴跳如雷？
根本没人受罚。配置开发环境是所有编程语言的常规操作。请理性看待：我们讨论的不过是文本编辑器里的某个运行时选项。大不了。更关键的是，为什么你的编辑器或IDE不支持Zig文件？
我是不是漏看了微软的正式指令？还是说你们只是因为有人敢做不符合你们标准的事就愤怒了？
这只是技术规范使然，与个人标准无关，任何检测换行符的软件都必须如此。
没人受到惩罚。配置开发环境是所有语言开发者都会做的事。
根本无需为此问题配置环境——全球所有软件都能轻松解决并处理这种情况。编写错误提示耗费的时间，远比正确拆分换行符更长。
让我们换个角度看：我们讨论的不过是你选用的文本编辑器里某个运行时选项而已。
让我们换个角度看：他们故意破坏自家软件，只为激怒72%的潜在用户。
更关键的是，为何你的编辑器或IDE不支持Zig文件？
没人需要关心Zig，这门小众语言根本不在乎用户体验，除了Hacker News讨论帖外毫无存在价值。
倘若某门语言突然要求你必须用回车符保存所有文本文件，否则就会报错，你会作何感想？
你听起来更像在抓救命稻草的律师，而非能经得起反向推敲的理性人士。
什么律师腔调？你不过是在为自己一手造成的局面发脾气。Zig存在Windows端口且用户基数足以支撑其存续的事实，已充分证明你的夸张言论并不如你宣称的那般具有代表性。
若我需要处理不支持LF换行符的文件，要么调整开发环境，要么另寻工具实现需求。
所以当你选工具时就无人需要关心？可当别人做出你反对的决定时就成了世界末日？明白了。别勾选那个复选框。继续生气吧，兄弟。
世界末日？
你根本没反驳我任何观点，只是编造了没人说过的话。我唯一指出的就是zig故意敌视自家用户——事实确实如此。
若你真能应对我的论点，早就回击了。
在我看来，你该从这个话题里抽身休息了。
看来我们已进入“指责对方情绪化以回避实质内容”(并修改帖子)的对话阶段。
这反Windows用户的水平也太业余
不如在文件名加冒号，或者把工具链命名为“aux.exe”
https://help.interfaceware.com/v6/windows-reserved-file-name…
效果超赞
相关：kennel源代码中的aux.c https://bugzilla.kernel.org/show_bug.cgi?id=68981
换个真正的操作系统不就解决问题了？
倒也不尽然，他们本质上仍受原始自我/骄傲驱动，只是把博客文章改头换面罢了。
“不想被微软的发展方向束缚”这个理由已足够充分，不明白他们为何要编造借口，纠缠于无关紧要的细节来为自己开脱
没错，我同意。我觉得这本来会是更好的理由，不过——反正我也不觉得这很重要。
核心问题依然存在：企业掌控的权力实在太大了。
哎，看来他们想掩盖自己把人叫作 猴子 和 失败者 的事实。
如果他们能坦诚承认并道歉，那你的观点才成立。但事实并非如此。
> 我完全赞同。我在这个维度上表现极差，向Zig社区致歉。我会承担责任，继续推进std.Io及其他路线图工作。[1]
[1] https://ziggit.dev/t/migrating-from-github-to-codeberg-zig-p…
> 伤害你的感受确实令我难过，但我坚信你不该为在微软工作感到自豪——尤其是在GitHub的这五年。我真心致歉，但必须指出你的问题。
鳄鱼的眼泪。
https://hachyderm.io/@andrewrk@mastodon.social/1156234452984…
感谢分享。 🙁
他们真这么做了？我短期内不会注册使用Codeberg。那地方根本是座鬼城，更何况Zig项目本身已是仅次于他们自家Forgejo平台的第二大热门项目。他们连问题记录都没迁移。这简直像有人因无法言明的缘由心生不满，草草完成半吊子的迁移(远程/推送)操作后就宣称胜利。
说不清，他们确实不太受HN用户欢迎。我以为他们对GitHub的痛点表达得很清楚。
ICE、Actions和微软——没有一条针对Git本身的抱怨。我看到的只是他们存在CI问题，还搭配着最愚蠢的反AI政策——这种政策根本无法执行。放弃捐赠并失去半数社区成员，实在不是明智之举，明明只需更新CI系统就能解决。
> ICE、Actions和微软，没有一条针对Git本身的抱怨
Codeberg也是基于Git的项目托管平台，甚至不支持其他仓库类型。你为何期待它支持后者？
当项目公告或文章标题宣称某人/某项目正在退出GitHub时，合理推断其问题源于GitHub本身(且这种推断通常正确)。
我指的是他们从Git SaaS迁移到另一个Git SaaS服务，却对即将弃用的Git SaaS平台毫无异议——这种行为多么讽刺。明白了吗？
> 明白了吗？
只有当他们纯粹将其作为Git SaaS使用时才成立，但实际并非如此——该平台同时兼具问题追踪器和讨论论坛功能。即便是PR(拉取请求)也并非严格意义上的Git概念。考虑到他们同时使用这些功能，且反对集成AI特性，我完全不觉得这有什么讽刺意味。
这不算讽刺。
若他们因GitHub上的Git问题而离开，转投同样需要使用Git的Codeberg，那才真正奇怪。
但事实是他们因GitHub问题离开GitHub，这完全合乎逻辑。
你混淆了GitHub平台与GitHub服务捆绑的概念。持续集成是可选的、可替换的，并非GitHub专属。而赞助基础设施和发现机制则不可替代。批评针对的是可选层，迁移却牺牲了粘性层。这种本末倒置的举动充满讽刺意味，显然是刻意作秀。简直像因为轮胎漏气就把车卖掉，笑死。
他们确实这么做了——迁移本质是将CI升级到Codeberg Actions，据称更可靠。所有Git工作流保持不变。
…
更新CI系统仅解决了你们提出的问题之一，而且你们忽略了前端层面的投诉——这些问题同样无法通过“更新CI系统”解决。
全是虚张声势，他们压根不在乎ICE或微软，直到能拿来当愤怒诱饵。
试想当任何SCM界面的奴隶——命令行工具和桌面客户端早已存在多年，更别提几乎集成到所有IDE中。他们描述的“随机”工作流不过是经典的CI构建机离线后恢复运行。
无论如何，祝他们好运，但愿不再遇到“猴子”——那可就糟透了。
关于声明中这个无关紧要部分的讨论又开始了…
他们应该明白，糟糕的软件很少像文本初版描述的那样是故意为之——你所获得的，正是他们在现有环境下所能构建的成果(环境同样重要)。能力与环境。
Reddit移动网站团队或许是个例外。他们打造的产品属于特定类型的难以使用，据我所知，有证据表明他们曾讨论过这种设计是故意的。
Reddit正竭力引导用户使用其移动应用，该应用会尽可能多地窃取个人数据。我通常不热衷于刻板的反派形象塑造，但鉴于他们此前关闭所有第三方应用的行径，这次指控其蓄意恶意也无可厚非。
据我所知，他们最近禁止用户创建自有API密钥——此前用户正是通过这种方式绕过封禁进入第三方应用，每个应用副本都被注册为单用户应用。如今若想开发任何应用或机器人，你只能选择屏幕抓取、窃取API密钥，或是获得Reddit管理层的批准。
凯利愤慨的态度和对“工程卓越性”的执着，预示着Zig的光明前景。看到技术项目负责人对平庸之作勃然大怒，实属可喜。
[..] 针对产品而非人。侮辱他人绝非解决之道。
有时人们需要被震醒。现实很残酷，温和言辞改变不了这点。
我在餐厅厨房待过，身边主厨们都信奉“有些人需要被震醒”。
被吼叫的人事后表现未必明显改善，但他们对同事和主厨的态度绝对更差了。
我询问过的厨师们，除了“我入行时就是这么干的”这种说辞外，根本拿不出更合理的解释。
组织内部影响结果的方法存在一个连续谱，未能充分利用这个谱系的广度，永远只会适得其反。
若要衡量语言表达对预期成果的成效，建议对比两类评论比例：一是针对GitHub严重缺陷的CI和UX问题的讨论，二是对公告措辞表达异议的数量。事实证明，缺乏 tact 和尊重的表达方式对目标推进的阻碍更大。
我猜你会把反对者贬为玻璃心…但这说明你根本不在乎目标推进的效率对吧？你只是想为自己的刻薄开脱，毕竟这不影响 你 。
你为何认为这是有效指标？毕竟挨打的狗才会叫。
> 你为何认为这是有效指标？毕竟挨打的狗才会叫。
你自己这么认为…
> 组织内部影响结果的方法存在一个连续谱，未能充分利用该谱系的广度必然适得其反。
还是说你期待的是另一种结果？那种你认为不靠侮辱就能实现却反而适得其反的结果？
我原以为 ark 意在为 codeberg 提供支持，鼓励他人审视 github 现状之恶劣并考虑替代方案。而非为 github 的行为争取更多支持与辩护。
我做了什么？
我从未对任何人使用过激烈言辞，所以不明白你的意思。我在HN待得够久，深知强烈负面情绪的表达在此处会受到惩罚。但这完全不能说明组织内部不同影响手段的有效性。
我认为，若有人因某些触怒自己的言论而非客观技术价值而挺身捍卫GitHub，那他们作为工程师已彻底迷失方向。
至于Andrew的目标，我认为他在注意力经济框架内相当成功。
我指的是那些占据他人思维空间的观点、讨论和对话。
> 那么他们作为工程师就彻底迷失了方向。
我认为自称软件工程师的大多数人，早已偏离了工程学的本质。
那些视而不见的人同样如此——工程存在的唯一意义是为人类创造价值。多数工程师根本无力思考他们所谓“为之建造”的人类群体。
核心在于让事物变得更好，而非更糟，更不该变得更不人道。
若你无端殴打狗，被它咬伤也别惊讶。
确实有人需要当头棒喝，但施加“电击”者也可能是虐待狂、施虐者或精神病患者。
你又不是在挖煤，清醒点。要么用高效方法让人完成实现目标所需的智力工作，要么你就只是自欺欺人地当什么“现实专家”，实则是个混蛋——他们或许照样会干活，但那纯粹是无视你的领导，而非仰仗你的领导。
为什么智力工作就意味着对干活不灵光的人得像对待娇弱小鸟似的？
智力工作需要些许创造力(在我能想到的所有领域都如此)，任何形式的虐待都会增加压力，压力则会削弱创造力、解决问题的能力以及韧性(即承受解决难题困难的能力)。
即便上述结论不成立，直面现实残酷性与主动让现实更糟糕的行为之间存在本质区别。每个人都值得获得尊严与基本尊重。
若因他人抗拒侮辱、反对随意剥夺人性尊严的行为，就断言其脆弱软弱，实属荒谬之论。
我认为将所有功能移植到React框架…导致网站变慢、臃肿且漏洞百出，这算不上“创造力”。
我认同人应被尊严对待…但群体思维与从众心理往往剥夺了人的本质。
因此批评的本质在于文化与抽象吸引子…而非那些在系统框架内往往理性行事的个体。
两年前我开始开发srctree，正是因为GitHub变得太糟糕。我认为这种趋势本身没什么创造力…但问题在于：“为何侮辱从事智力工作的人是错误的”。并非“你认为GitHub的变革具有创造性”，但我确实认为这些变革需要一定智力投入，且无论GitHub变得多么糟糕，无端攻击他人都是不合理的。
难道只能通过人身攻击才能对劣质工作给出清晰直接的反馈？
不，但我对顽固分子不排除这种方式
好吧，但这依然不是有效的领导行为。骂人或许能让你内心觉得自己很厉害，仅此而已。这毫无实际意义，只为个人满足，对项目、产品和团队毫无裨益。
事实上，若完全排除严厉手段的可能性，等于默许自己被践踏，让标准降至冰点。这或许让你内心觉得自己是个开明的大人物，但恰当运用坚定与压力在领导力中绝对有效。
当其他途径失效时，嘲讽是改变行为的正当手段。
恶意行事的理性者可通过说理停止行为。
善意行事的非理性者无法通过说理停止行为，因为他们愚蠢。
当说理失败后，指出对方行为愚蠢并非人身攻击或侮辱。
>侮辱他人绝非解决之道。
此言未必绝对正确。
世间无绝对真理，但此例确属例外
微软内部的投资者与管理层都读过这则新闻报道。
若非他们最初嘲讽了那些愚蠢决策者认为可接受的决定，此事本不会发生。
愤怒是心灵的杀手。怀着热爱开发软件吧——热爱工程技术、创新创造，更要热爱与志同道合者共事。
持续的愤怒确实如此。但它有时也是绝佳的火花，关键不能任其发酵。
愤怒直接催生了自由软件运动：
https://www.gnu.org/philosophy/rms-nyu-2001-transcript.txt
我认为唯有愤怒才能推动任何进步。过度的仁慈意味着妥协、迁就与宽恕，这些恰恰与系统性变革背道而驰。
唯有那种对所有人竖起中指、“让我展示真正该怎么做”的能量，才能成就真正有意义的事业。科技史上所有伟大的建设者，几乎都是/曾经是充满愤怒的人。
正义而炽烈的愤怒，有时与爱难以区分。拥有并为之奋斗的事物——无论征途多么血腥——能让生命获得与修习克己静默、沉思、接纳等修养同样的意义。爱之所以为爱，正因它必须悖论般地接纳其对立面：爱可以是愤怒，愤怒可以是爱。真正的思想杀手，是陈腐的道德主义！
查拉图斯特拉如是说云云……
> 正义而炽烈的愤怒可能与爱无异……爱可化作愤怒，愤怒亦可化作爱。
这不过是文字游戏。模糊混淆不同词汇所指的含义。想表达什么？激情形态各异，能成为极强的驱动力？无人质疑这点。
愤怒与爱显然存在差异。GP正是在探讨这种差异，并建议专注于二者中更健康的那种。这是良言。
当你所爱之人因暴力或不公而受伤时，你心中燃起的怒火是什么？这难道不是爱的表达？
那种对相伴多年的伴侣产生的特殊愤怒呢？唯有建立在深厚亲密关系与坚定忠诚之上才能产生的愤怒？难道你感受不到那份始终如一的爱，只是以不同的色彩呈现？
目睹重大不公时的愤怒又是什么？仇恨犯罪、种族灭绝、侵犯自由的罪行…这难道不是某种人文主义的爱吗？
若将爱简化为“更健康的选择”，便是彻底摧毁了爱！这至多使爱沦为实用主义准则，至多沦为怪异的强制性要求(毕竟我们“应该”保持健康……)。但爱并非强制，而是(美丽、惊人、自然的)存在状态。它未必总是“健康”，未必永无愤怒，但永远“美好”——追随它绝不会错。
愤怒与爱当然存在差异。二者可独立存在，偶尔交织碰撞亦不改变本质区别。
你在玩弄文字游戏假装它们相同。这很诗意又戏剧化，但希望你明白：爱不等于愤怒，二者也无需彼此依存。
若处理得当，爱能吞噬愤怒；若处理不当，愤怒将吞噬爱，并吞噬更多。这两种结果截然不同。正因如此，这场游戏才变得严肃，也正是我对你所写内容如此苛责的原因。
好吧，我确实认为这终究只是语义之争。换言之：若将爱定义为一种可进入或不进入的状态，若它更像是我们 主动践行 而非被动体验的事物，那么愤怒状态与爱之状态确有不同，而后者显然更值得追求。我之所以觉得这个定义“夸张”，纯粹是因为它实在不够令人满意！就像情歌有时也是悲伤的旋律。我只是拒绝这种心理/行为学的起点，主张我们所称的“爱”应当是更广阔、更深邃、更复杂的存在——仅此而已。
不过此刻我们讨论的已是玄乎其玄的领域，对此类观点存在分歧完全正常！我明白你大概会继续将这些视为诡辩或玩弄文字之类，但无论如何请知晓：我确实认可并尊重你的观点！这或许可视为一种选择：爱可以是令人向往的状态，亦可成为戏剧性的存在理由。选择前者者，你大概是位快乐的僧侣/斯多葛派；选择后者者，则更像经典浪漫主义者、艺术家之流。
引用我前日关于识别他人帖子中AI痕迹的论述：
https://news.ycombinator.com/item?id=46114083
"这种文风更像是LinkedIn而非大型语言模型，是那种若写出个性化内容就会挨批的风格。
当今世界多数人已默契地模仿机器说话。"
针对AI的猎巫行为确实是个问题。唯一可靠的识别标志是当AI说出极其愚蠢的话时——它不仅无法理解自身论述的内容，甚至连词汇本身的含义都搞错。
例如：毫无意义的比喻、无法提供实质洞见的陈词滥调(如“那是个风雨交加的夜晚…”)，且这些表达并非自嘲式幽默而是严肃使用。
我最爱的AI特征案例来自某段关于连环杀手的YouTube视频——当时我正把它当背景音播放，结果它某句开头竟是：“但最初看似无害的连环杀人夜，很快便演变成某种不祥之兆。”
这实在可惜，因为在AI时代之前，“但起初看似无害的连环杀人夜，转眼间却变得阴森可怖”，不过是个有趣的文字段落罢了。
简直像直接摘自黑色侦探小说。
在我看来，“企业/专业”领域向来如此。
如今“外行”也更容易调整自己的表达方式。我预测人们很快会厌倦这种风格(你的评论就是明证)
问题：你会冒着被揍脸的风险，在公共场合当众骂听你讲话的人是废物或猴子吗？
企业发布公告时面临四面楚歌的诉讼风险，普通人在公共场合会谨慎措辞。但在网络空间，公共场合似乎适用不同规则。普通人并非在模仿企业话术，而是日益意识到网络的公共属性并相应调整行为(多数人如同现实生活般保持沉默)
另
> 更重要的是，Actions是由猴子创造的…
vs
> 最重要的是，Actions存在不可原谅的漏洞…
我赞赏作者修正错误的行为。但依我之见，若能公开说明而非默默修改会更好。
总之，各人有各人的选择，我为Zig社区感到高兴。
他承认了。文章里有链接。
他删除了自己的评论，并向Zig社区道歉。但他从未向受伤害的人(此处指GitHub上的“失败者”)道歉。
[已删除]
你参加派对一定很有趣。
伤害即健康损害。他损害了他们的健康。
谢谢
这很侮辱人，因此我受到了伤害。
编辑：我给你点赞是因为我喜欢派对。
“臃肿又漏洞百出的JavaScript框架”
财大气粗的公司正高薪雇佣“软件工程师”来开发维护它
数百万用户因无法禁用它而成为“活跃用户”
使用Github服务器时，我仅下载源代码(zip包或tar包)，从不运行任何JS
本地正向代理在下载时会跳过重定向
对我有效
编辑间隔真够长的。作为自己帖子的唯一贡献者，我通常几分钟就能完成一次迭代。难道每次修改前都要开董事会？真是保守的流程。“菜鸟”们，太棒了
无论措辞如何，他们在GitHub上展示的内容真实反映了问题。代码显示功能存在诸多缺陷…这些功能原本运行良好，或者根本不该以如此漏洞百出的状态上线。
代码折叠功能故障频发。遇到包含嵌套函数或可折叠元素(如带方法的类，方法内部可能还有嵌套函数)时，折叠按钮会随机出现，毫无规律可循。
基础文本编辑功能也失灵：“双击拖拽”操作常出问题/产生怪异效果，标识符检查功能更会干扰文本选取。
问题搜索功能同样愚蠢，经常无法找到搜索内容。
搜索还必须登录才能正常使用。
大部分功能都依赖于运行JavaScript。
简而言之，这展现了平台日益JavaScript化的典型特征：臃肿的框架导致功能半吊子，且未经过充分测试以确保符合合理标准行为。
但问题不止于此。那些愚蠢的AI机器人自动关闭问题：“状态机器人”、“Dependabot”——全是垃圾功能或半吊子的烦人(误)功能。最近我在Hacker News看到，项目维护者居然能编辑他人提交的内容！这完全暴露了微软典型的权限管理问题，根本没经过周全考量。内部肯定有人在强推这些垃圾功能。
真有人用GitHub查阅代码吗？我觉得只要不是一秒钟能看完的内容，还不如直接浅层克隆仓库，用自己定制的编辑器查看。
倒不是说他们的实现不烂，只是我根本无从判断——就算没有bug，体验恐怕也差强人意。
处理自己的PR时，我习惯在界面里重读修改内容。
这几乎像请他人校对——毕竟我的大脑无法像在编辑器里编写代码时那样，自动补全代码中的空白。
我最喜欢第一个版本。
太疯狂了！他本该保留原始版本。
需要三次修订才能淡化煽动性言论的事实，可能引发人们对领导层决策冲动控制能力的质疑(他们总是将意识形态立场置于务实稳定之上)。考虑到Zig自2015年开始开发，截至2025年8月仍停留在0.15.1版本，这一点尤为值得注意。
读到初版时我震惊了。若你是网红尚可理解，但作为编程语言，人们理应期待你能管理情绪并保持客观。
该是更多人谴责臃肿又漏洞百出的JS框架了哈哈
GitHub不就是个大量使用服务器端渲染的Rails应用吗？
现在不是了。那个毁掉性能的重写版本用了ReactJS https://news.ycombinator.com/item?id=44799861
最糟糕的是新手开发者以为这种糟糕状态一直存在…所以Zig等语言转向替代平台是好事。
坦白说我不常用GitHub。所以如果他们错了，那他们抱怨搞砸了——本可以转向其他众多网站的。
说得对！明确一点：Rails应用和臃肿的JS应用并非互斥关系。不过据我观察，GitHub感觉卡顿纯粹是自身问题，跟JS垃圾没关系
清理代码固然好，但Andrew总给人感觉比Notepad++开发者更不稳定，这对BDFL可不太好看。比如前阵子他还在演讲中途突然哭出来。
GitHub有哪天不是~有点bug？
把软件质量问题归咎于框架是能力问题
至少他修改成更可接受的说法了。比起死不认错的人，我更欣赏能承认错误并修正言论的人。后者态度在近年已变得过于普遍。
政治正确性对社区/开源项目蓬勃发展有必要吗？
Linux似乎运作得很好。
我个人对此无所谓，但我不认为初版内容会真正损害社区。
你对待他人的方式完全反映你自身，与对方无关。
此案例中，不必要的侮辱性言论削弱了本应重要的信息传递，更损害了Zig的形象。编辑处理是正确的。
对Zig不满者大可另择工具，无需参与社区互动。
若他仅在Zig社区发表言论，而非在社交媒体四处贬低GitHub员工，你的观点才成立。
你在社交媒体表达对GitHub员工的负面看法是自由的。
明白了。
另一方面，某些知名开源领袖确实是尖锐的混蛋。Linus、Theo、DHH，这三个例子立刻浮现在我脑海。我认为若对项目愿景有清晰认知，那么对不符合该愿景的观点采取强硬否定态度是必要的——这能有效抑制噪音干扰。
没错，别人的恶劣行为不能成为你犯错的借口。
>政治正确对社区/开源项目蓬勃发展有必要吗？
完全不需要，但这更像是幼稚行为而非政治正确。
这些和政治正确有什么关系？
不做混蛋和政治正确是两回事。
这让我不禁思考：网络上大量纷争与混乱，有多少纯粹源于人们根本不懂自己用词的含义？
>这让我不禁思考：网络上大量纷争与混乱，有多少纯粹源于人们根本不懂自己用词的含义？
或者被故意误导。那些乐于以各种方式作恶的人，总想把反对意见贴上“政治正确”的标签，好方便贬低或嘲笑。绝大多数使用“政治正确”这个词的人，目的就是贬低或嘲笑它。
这与政治正确性息息相关。如今坦率直白的语言被贬低，取而代之的是被动、无菌、充斥AI垃圾的语言，这些语言已无法传递重要信息。修订后的帖子刻意回避了臃肿且漏洞百出的JavaScript框架这一关键问题，只因它会“冒犯”某些人。
宁可选择直率坦诚的混蛋，也绝不接受虚伪客套的骗子。
称呼Actions开发者为“猴子”与政治正确无关，纯粹是粗鲁且极具侮辱性的行为。此类言论绝不该出现在公开声明中。
此外，托瓦兹因其公开言行受到正当批评后已作出修正。
嗯，我认为这些修订并非出于政治正确，而是避免发表幼稚言论。林纳斯确实对他人说过许多尖锐煽动性的话，我认为这种做法不妥且暴露其性格缺陷，但至少对我而言，他更像个聪明傲慢的混蛋——说话方式不当，但观点通常有其核心价值。
Zig的评论显得极其幼稚，或许因为是针对陌生人的攻击——称呼别人“失败者”或“猴子”在我看来已越界。叫人“闭嘴”虽不妥，但把群体贬为“猴子”更令人反感。
众所周知，当有人用愚蠢行为激怒他时，林纳斯会严厉斥责并爆粗口。
论沟通之道，他确实算不上榜样。
GitHub可以去死，我觉得这是最合适的反馈
我花了一个多月试图删除GitHub账户，至今未能成功
或许他该当个榜样。这种认为我们应该容忍糟糕事物并仅以礼相待的想法，似乎总会产生糟糕的结果，原因不明。
任何将GitHub功能问题归咎于个人能力不足的分析，都是严重错误且充满侮辱性的。任何在大公司工作过的人都清楚顶尖人才推动变革有多艰难，这绝非因他人愚钝所致。至少根据我的经验，抱持“他们必定愚蠢”观点的人，几乎都不了解大型组织如何决策，更不懂组织架构中不同层级的激励机制如何导致次优决策与结果。我认同过度客气无益于事，但坚持正确立场确有价值——而对方最初的论述不仅错误，更充满侮辱性。这种言论毫无价值可言。
但你真该关心微软的内部运作吗？
产品无用，请另寻他处。把同情心留给真正需要的人吧。
因为人们宁愿微软修复问题也不愿迁移。
迁移固然痛苦，但他们肯定不是未经请求/等待微软修复就贸然行动的。
不知道在企业环境中能否产出好产品，这听起来像是能力问题。
> 顶尖人才推动变革有多难
那你就不算顶尖人才了？
道理很简单
> 他们肯定蠢
人可以不蠢但依然无能
我对此存疑。粗鲁冒犯他人智商绝非美德。林纳斯之所以能如此行事，源于特殊背景：他是极具影响力的开源项目领袖，掌控着大量项目准入权限。
我始终质疑他的行事方式：即便看似高效，我们无从知晓若他不再对他人破口大骂“蠢货”，实际效率能否更高。
况且这似乎并非岗位必需：众多项目负责人以礼相待却未引发问题。
现实是，当辱骂不针对自己时，人们总幻想更多人能如此出言不逊。但一旦成为被辱骂对象——尤其作为志愿者——你很可能因此丧失继续贡献的意愿。
我认为这种表述很到位，完全赞同。Linus就是个混蛋，我绝不想和他共事。那些称其他群体为“失败者”或“猴子”的Zig维护者更是如此，这充分暴露了他们缺乏成熟度和思考能力。
呃。Linus长期对Linux贡献者有辱骂行为，但据说他已为此道歉并开始改正。至于Zig那位，我仅闻其名未曾谋面。仅凭他根据反馈修改的一篇帖子，不足以让我做出如此判断。若真要说，他更新内容的行为恰恰证明了相反的成熟度——成年人难免沮丧，关键在于如何应对。
成年人不该在社交媒体上称人“失败者”或“猴子”。我并非评判是非，这种行为本身就是不可接受的。
当真？你真想不到任何情境下这行为可能合理？
更关键的是，若有人仅犯一次就停止，我们是否该永远将此人逐出社会？
谨记：唯有西斯信奉绝对。
完全不明白你的论点，请解释清楚。
我原本是赞同你的立场，并补充了个人经历——那些帖子最初的排版方式实在令人反感。这种人我可不想共事。如果你愿意这样做也无妨。这又不是星球大战，纯粹是我个人的选择，毕竟其他人都不这么做。
成年后我也从未想过要在公开场合指责一群人是失败者或猴子。
我的观点是，在我心中Linus和Zig那家伙属于不同范畴。将他们混为一谈未免有些天真。
比如那些挥舞提基火炬的白人至上主义者，我绝对会公开称他们为失败者。事实上我实在想不出更贴切的称谓。这个标签同样适用于臭名昭著的骗子罪犯、声名狼藉的国会议员乔治·桑托斯，或是任何在游乐场暴露自己、殴打妻儿的人。
我认为Zig最初的发帖略显夸张。但他确实改变了立场，在我看来这总比固执己见强。Linus也是如此，尽管他多年行为恶劣。我的观点是：你们的回复将世界描绘成非黑即白的二元对立，而中间存在大量灰色地带。有时公开羞辱是有效的沟通方式，但更多时候并非如此。这绝非“永远适用”或“永远不适用”的绝对标准。
我没意识到我们竟把微软工程师与白人至上主义者、恋童癖混为一谈。当然，对于这类人，我能理解人们会用这种描述。
我们没有这么做，至少我没有。
> 我成年后也从未想过要在公开场合称某群人为失败者或猴子。
看来这算是你的第一次：
> 当然，对于那类人，我能理解人们会用这种描述。
总而言之，我想我们基本认同：尊重他人总比粗鲁待人更好。而某些缺乏尊重的人，也不值得获得尊重。就此打住如何？
既然想就此打住，那你别再回复了？我只认同你最初的观点，可你却不断质疑我的立场。你毫无缘由地揪着我的措辞不放。注意我说的是“能理解别人使用这种措辞”，可没说我自己会这么做。更何况，面对针对一群陌生微软工程师的粗鲁言论，我怎么可能联想到恋童癖？
我的观点是：绝不愿与那些在评论里骂工程师是猴子或废物的人共事。我见过这种行径，这类人绝非我愿意合作的对象。
问题永远出在人身上。
因为某人总在谴责他人“恶劣行径”前就自以为有资格开火，这种心态会扭曲其客观判断力。
比如当项目走红后，他们获得更多权力和名望，自我认知便会发生改变。
因此保持技术讨论的理性、避免恶语相向，通常更有利于社区建设。
人身攻击不仅破坏性极强，更会纵容其他(可能能力不足的)人将恶意倾泻于文字。
这是礼貌问题，而非政治正确。
他用侮辱性言辞代表自己的社群向世界发声。在IT高层领域，沟通至关重要。他用不当言辞向那些决定是否采用Zig的领导者表明：他们不愿与他/Zig社群交流。
作为项目/技术领袖，沟通本就是他的职责所在。他对此心知肚明。详见文章链接。
政治正确与粗鲁无礼之间存在巨大鸿沟。本案中社区代表完全能在不冒犯他人的前提下表达关切、阐明动机并说明决策依据。此类评论既不明智也不合理——任取百人以上组织，我都能找出其产出的重大缺陷或糟糕决策。难道我该给该组织所有现职人员贴上“脑残白痴”之类的标签？
> “热衷于施加”
热衷于做什么？糟糕就是糟糕，但这种表述方式极其幼稚，没人是故意或出于恶意行事。这种无谓的争执损害了项目形象。不过我猜是翻译问题吧。
连林纳斯都不会再这么做了。这是他几年前的表态：
> 本周社区成员指出了我长期缺乏情感理解的问题。我在邮件中轻率的攻击既不专业也毫无必要。
尤其当我把事情个人化的时候。在追求更完善补丁的过程中，我当时觉得这样做合情合理。现在我明白这绝非妥当之举，我深表歉意。以上长篇大论其实是为了坦承一个颇为痛苦的个人认知：嘿，我需要改变某些行为方式，并想向那些因我的个人行为受到伤害、甚至可能因此彻底远离内核开发的人们致歉。
> 我将休假一段时间，寻求专业帮助来学习如何理解他人情绪并作出恰当回应。
他休假后已有所改善。你们所谓的“政治正确”，在我和同行眼中是“基本职业素养”。林纳斯花了25年才明白这个道理。但愿那些曾盲目崇拜他并效仿其态度的人也能成熟起来。
是啊，这种状态没持续多久。
https://lore.kernel.org/lkml/CAHk-=wjLCqUUWd8DzG+xsOn-yVL0Q=…
> 在合并窗口关闭前一天提交大型拉取请求，指望我忙得顾不上处理——这绝非明智之举。
真希望这话是我说的。
但遗憾的是，把重大PR拖到影响日程时再提交，确实是逃避审查的好方法。
但不得不承认，他确实擅长早期发现缺陷——那些可能累积成严重漏洞或安全隐患的问题。固然耍混蛋不可取，但身居要职者必须具备这种果断性。
我坚定支持林纳斯；内核比个人感受更重要，他的做法确保了高质量标准。
请注意，他批评的是代码垃圾，而非作者本人。以代码质量之差来看，这次互动完全合理。这恰恰体现了林纳斯自我改进的进步。
即便严格来说没有必要，人也可以避免当混蛋。事实上，若在非必要时仍当混蛋，那你就是个混蛋。
不称其他软件工程师为“失败者”并非政治正确。他们是“失败者”，仅仅因为他们选择的产品方向不合你意？得了吧。Linus在帖子中情绪化是因为Linux是他的“孩子”。
这只是在这里，他在Mastodon上越发强硬
https://mastodon.social/@andrewrk
这种态度已然且持续地接近对全球最大经济体的无血政变。
事实上，这种常态化相当成功。整个硅谷都默许了它。
你好像在说人们不会因这种行为获得回报似的。
他们对有效性只字未提。
我个人欢迎下一个林纳斯·托瓦兹的出现。
这种充斥着虚假微笑的美国企业文化，正是导致产品沦为垃圾的根源——因为无人敢直言批评。若反馈过于温和，问题就会被掩盖。
我们需要的不是更多自我审查，而是更少。
不，修改后的版本更好。原帖存在无端臆断，且刻意使用了不准确的措辞。这客观上属于沟通失当。
这并非在“人身攻击(激化冲突、破坏理性决策)”与“隐瞒观点”之间二选一的困境。所谓“机智”二字，正是为此而生。若有人无法在这两种失败模式间找到平衡点，那纯粹是沟通技巧的问题。
完全赞同。虽然目前还不能点赞(功德值不足)，但我认为除非法庭等特殊场合，官僚腔绝非解决之道。
这篇帖子的意义何在？羞辱作者吗？
说真的，为何尤其在西方世界，当有人直言不讳时总会引发如此震惊？
在我看来，这种表达方式恰恰证明发声者是拥有真实经历的活生生的人，而非营销部门的产物。他因生活被恶化而愤怒是情有可原的，辱骂那些人也是人之常情。辱骂是信号而非噪音。它昭示着问题存在，警示人们需要关注。
我听过诸如“不够专业”之类的批评。那又如何？我绝不愿生活在这样的世界——每个人说话都必须经过过滤，以符合某些任意制定的限制，而制定者往往连实际工作都做不好。
我认识的真正有能力的人，几乎都这样说话。
他们无法忍受那些因无能而拖累我们的人。当本该正常运作的事物失灵时，他们会愤怒。他们追求卓越品质，面对缺陷绝不沉默。若有人搞砸了，他们会直言不讳指出错误并要求修正。
我更欣赏这种作风。
原始版本完全没问题。
GitHub是众多项目的关键基础设施，强推低质AI产品绝不可接受。
他们完全有能力支付高质量开发所需的时间成本。
作为多年来持续警示微软收购GitHub风险的人，我必须指出…Zig社区近期的闹剧实在过火。原以为Rust社区对纷争的高容忍度已然自毁形象，但如今Zig的闹剧程度甚至超越了Rust。
目睹他们群起围攻Zig书籍作者的场景令人痛心。据我观察，这位作者或许只是个尚未成熟的青少年。但整个社区竟因怀疑其使用AI就举着叉子围攻——这般景象实在令人作呕。
Zig持续采用垃圾营销手段早已令我反感。如今更出现手持叉子的暴民和反AI的狂热抨击，整个社区仿佛正靠着负能量维系。或许他们还能扭转局面，但可能需要彻底整顿或制定更完善的贡献者规则。
> 似乎是个可能不够成熟的青少年。
你为何这么说？难道不能是位不够成熟的成年人？
> 因为他们怀疑你可能使用了AI
这就是原因？据我所知(信息可能不完整)，投诉点在于：他们明知使用AI却声称未使用，窃取其他项目代码却宣称原创，在提交PR要求署名时拒绝添加，还试图在open-vsx占用命名空间…
到了某个节点，这些行为就显得纯粹恶意了。不懂“规则”但愿意在被指出错误后改正是一回事，撒谎、混淆视听并坚持恶劣态度则是完全不同的另一回事。
我只想指出：即便你所言属实，作为Zig外部观察者，这些问题都难以被察觉。整件事看起来就是很糟糕。
我确实是Zig外部观察者。我通过阅读相关讨论(主要发布在HN)来了解背景，因此也强调过自己可能掌握的信息不完整。
若能透过表象看本质——这是形成理性判断的前提——明显是Zigbook方面形象受损。其官网甚至已无法访问，现仅显示DMCA版权声明。
此类事件在局外人眼中呈现的样貌，取决于向他们展示的事实框架。
选择聚焦于戏剧冲突和霸凌行为，却不探究引发如此负面反应的根本原因，正是这种现象的典型体现。
轻则剥离了理解事件动态所需的背景，重则构成隐瞒事实的谎言。
关于使用AI的指控毫无根据且纯属臆测，这已被包括我在内的语言学家指出。如今社区竟利用MIT署名权侵犯事件，将Zigbook作者推上DMCA滥用指控的受害者席位。
在我看来这实在不光彩。这绝非我愿意推荐他人参与的社群。
> 曾试图在open-vsx主张命名空间所有权
zigbook命名空间理应归属作者所有。这不正是命名空间的基本运作规则吗？https://github.com/search?q=repo%3Aeclipse%2Fopenvsx+namespa… https://github.com/eclipse/openvsx/wiki/Namespace-Access。在我看来，这和“但他们对加密货币感兴趣！”的论调如出一辙。Zigbook作者只是在做普通软件工程师的工作，但社区却试图将其扭曲成某种阴谋。这种阴谋论从未被明说——因为它显然荒谬——但明显存在暗示不当行为的企图。遗憾的是，这反而让社区看起来像是在舆论法庭上竭力迫害无辜者。
> 到某个程度，这种行为就显得纯粹恶意了。
恶意意指“具有或源于恶意；蓄意伤害；刻薄”。在我看来，Zig社区在此事件中表现得充满恶意。与您一样，我掌握的信息并不完整。但根据现有信息，社区的反应显得恶意、惩罚性、骚扰性，甚至可被视为诽谤。我从未在任何开源社区见过类似行径。
再次强调，在麻省理工学院提出归属主张之前，没有任何证据表明Zigbook的作者做过任何不当行为。尤其值得注意的是，没有任何证据表明他们对人工智能的使用存在欺骗行为。如今恶意且错误地指控他人使用人工智能的情况屡见不鲜，包括在HN平台上。
从舆论反应的激烈程度、指控的站不住脚以及对Zigbook作者动用法律手段的意愿来看，我推测该书引发争议另有尚未公开的原因。结合时间节点，可能与Anthropic收购Bun有关。
> 关于使用AI的指控毫无根据且纯属臆测
起初我也这么认为，但很快真相大白。连提交者查阅Git历史记录后也认同此观点。
https://news.ycombinator.com/item?id=45952436
> Zigbook命名空间归属其作者似乎合情合理。命名空间通常就是这么运作的吧？
没错。不良行为者总试图通过尽可能少地投入精力、尽可能快地囤积域名和命名空间来获取合法性。他们购买的域名数量就让我起了疑心。
> 我觉得这和“但他们对加密货币感兴趣！”的辩解如出一辙。
完全不明白你在说什么。Zigbook作者对加密货币感兴趣还因此受到批评吗？
> 恶意行为从未被明说，因为这显然荒谬，但明显存在暗示不当行为的企图。
事实并非如此。相关指控已被反复明确提出。
https://zigtools.org/blog/zigbook-plagiarizing-playground/
他们窃取代码据为己有，拒绝署名，还篡改第三方评论让原作者看起来像在说他们“自闭又狂热”——这些行为你觉得没问题？
https://news.ycombinator.com/item?id=46095338
你真觉得这无可指摘，还认为批评这种行为是站不住脚的荒谬之举？
> 我从未在任何开源社区见过类似行径。
我当然不是在为恶劣行为开脱，但这连开源领域毒瘤行为的前100名都排不上。多年来网上和HN上提交的案例多不胜数。
> 如今恶意且错误地指控他人使用AI的情况屡见不鲜，HN上也不例外。
我明白。我一直在反驳这种论调，尤其当有人仅凭破折号就妄下结论时。我最初也质疑Zigbook投稿中的牵强指控，但随着证据不断涌现，我很快撤回了反对意见。
> 考虑到时间节点，这可能与Anthropic收购Bun有关。
我不认同。收购公告是在之后发布的。
若能退一步审视并克服确认偏误，你会发现自己提出的论点相当薄弱。
你还在移动目标。起初你质疑占用命名空间的正当性，现在又转向质疑域名持有行为。人们购买域名变体本就是常态。
这绝对是开源界最恶劣事件的前五名，甚至可能稳居榜首。要知道，这可能只是某个就业市场糟糕的国家里，试图为社区创造资源并提升知名度的年轻人。而Zig社区却试图毁掉他的生活——他们自我煽动陷入狂热，坚信存在某种暗示曾使用过AI的隐秘迹象。
我从未见过开源社区如此群起而攻之——仅因忘记为22行代码添加署名就毫无证据地欺凌他人。这类疏漏在开源领域屡见不鲜，但这次竟被当作伤害个人、使其承受痛苦的借口，实属首例。这种蓄意施加的残酷，以及强势群体故意欺负弱势者的行径，在我看来远比开源领域其他粗鲁行为更恶劣。
这本质上是内部群体向外界宣告：你们不受欢迎，不仅如此，若我们不喜欢你，就会伤害你。
没错，他们多次提及对加密货币的兴趣，包括在本讨论串中。
> 你还在移动目标。起初你指责占用命名空间有问题，现在又改口说拥有域名有问题。
请不要曲解我的话。这是恶意辩论。我从未声称“占用命名空间很可疑”，我只是列举了他人提出的质疑。所谓“据我所记得(…)的投诉内容”正是这个意思。提及域名时，只是因为它们在我看来有问题。这里既无矛盾也无偷换概念。请秉持善意辩论。
> 说不定这只是某个就业市场糟糕的国家里，想为社区创造资源并打响名号的孩子。
但说不定并非如此。老天，说不定就是你。无论如何，这都不能成为不良行为的借口——那些行为多如牛毛且有据可查。你唯一的辩护理由是 猜测 ，即便属实也无法开脱。
你可能没看到我发帖后补充的背景，在此重申：
> 他们窃取代码据为己有，拒绝署名，还篡改第三方评论让原作者看起来像在说他们“自闭又疯癫”——你觉得这样没问题？
> https://news.ycombinator.com/item?id=46095338
> 你真觉得这些行为无可指摘，批评者纯属无稽之谈？
请回答这部分。你觉得这样可以吗？你认为这无可厚非？你觉得这是“为社区创建资源”的典范？这难道不是有毒行为？
尽管尽情批评Zig社区，但请也留意你如此热忱捍卫的对象。
> 目睹他们群起围攻Zig书籍作者的场景令我痛心。据我观察，这位作者似乎是个可能尚未成熟的青少年。但整个社区竟因怀疑你可能使用AI就举着叉子围攻你…这景象实在令人作呕。
你的推测大错特错。人们愤怒的根源在于：他明知自己发布的网站内容多由AI生成，却反复谎称“不含AI成分”。但这并非他遭受谴责的真正原因。
除了反复撒谎，这个账号还长期从事域名抢注行为，侵占众多团体(尤其是大量加密项目)的域名资源；其名下存在大量cursor/getcursor账户；曾侵犯现有社区团体(该团体以倾力帮助其他zig用户著称)的版权，抄袭代码却拒绝署名； 更恶劣的是，当有人要求他在PR中标注代码来源时，他竟以人身攻击和辱骂回应——仅仅因为对方要求他为试图窃取的代码标注出处。与此同时，他还公然为抄袭他人的成果募捐。
更令人发指的是，他似乎正计划对Zig用户实施拼写域名抢注，因为他掌控着GitHub上的
zigglang账户。所有这些行为绝非“状态不佳时的小失误”所能解释。这是蓄意恶意行为，源于某人企图蹭他人劳动成果。众人愤怒的根源在于此人是个自私的混蛋——他不仅有抄袭前科、直接辱骂他人的恶劣记录，更公然企图冒充核心ziglang团队/组织…而非因为他敢用AI。
我部分认同。
确实觉得过度聚焦AI本身很奇怪。无论你喜不喜欢，AI都将渗透未来所有领域。说实话谁在乎呢？这要么是优质的学习资源，要么不是——判断标准应基于内容本身而非AI是否参与创作。
不过部分批评确实源于他窃取交互式编辑器的代码却声称自主开发——这种行为显然不可取。
更严重的问题在于 他们声称未使用AI 。这种赤裸裸的谎言让人质疑其所有内容的可信度。
> 说实话谁在乎呢？这资源要么值得学习，要么不值得。你必须自己判断，而非依据是否使用AI辅助写作。
除非投入时间实践，否则你无从判断资源是否优质。若最终发现毫无价值，不仅浪费时间，更可能学到错误观念需要重新纠正。若内容由大型语言模型生成，你根本无法分辨哪些部分正确或错误。
我赞同你的观点。明知是AI生成的内容却声称非AI所作，这种行为确实恶劣。
但我也认为，现阶段我们应当默认所有内容都存在AI辅助成分。
关于你最后提到的观点，我认为这在LLM出现前就已存在。虽然如今伪造写作中的道德感确实更容易了，但当你掌握辨别技巧后，识别AI生成的粗劣内容也变得更简单了，对吧？
> 我同意你的观点。明知是AI生成的内容却声称非AI所作，这种行为实在卑劣。
> 但我也认为，现阶段我们应当默认所有内容都部分使用了AI辅助创作。
此处使用“但是”暗示第二句是对第一句的部分反驳。若他未刻意撒谎，本不会引发众怒。让人恼火的并非使用AI本身，而是被直接欺骗(很可能是为了规避Zig各社区严格的“人类创作”规则)。随后他还通过恶意公关编辑攻击他人，似乎因此遭到封禁。更别提他长期从事拼写错误域名抢注行为——从各类加密货币平台域名到cursor域名，甚至抢注了zigglang的域名账户。人们愤怒的根源在于此人自私卑劣的行径，而非他敢于使用AI。
我所写内容从未借助任何AI辅助，且我认识多位坚持相同原则的同行。这种默认假设并不合理。
若我理解有误请指正，但据我所知实际争议点在于：Zigbook未遵守MIT许可证中关于代码归属的条款——有人认为其抄袭了他人代码。MIT许可证仅要求对“实质性代码片段”的复制进行署名，而被指控抄袭的代码仅22行。
这算“实质性”吗？我虽非法律专家，但这本质上是归属条款定义的争议——涉及的代码量甚至少于人们从Stack Overflow随意复制的程度。当指控出现时，Zigbook作者已遭社区围攻，被迫采取防御姿态。
需要明确的是，我认为作者的应对方式确实欠妥。但互联网中充斥着年轻软件工程师——若他们为社区撰写书籍却遭社区反噬，恐怕也会做出类似反应。我不愿以个人最糟糕的表现来评判其为人。但我确实认为，社区本身具有独特的行为模式与文化氛围，这需要有意识地加以引导。
> 若我理解有误请指正，但据我所知实际争议点在于：有人认为Zigbook未遵守MIT许可证对代码的署名条款。MIT许可证仅要求对“实质性代码片段”的复制进行署名，而被指控抄袭的代码仅有22行。
未标注正当署名即构成典型侵权。不过我个人不会将版权侵权称为“盗窃”。
试想MIT许可证的慷慨程度： “你可以随意使用这段代码，我将其赠予世界，你只需给予正当署名” 。然而有人读完条款后，不断取用却连署名都不愿给。
> 需要澄清的是，我认为书作者的回应方式确实欠妥
关键在于：或许这只是个疏忽？作者本以专业礼貌的方式提出请求——并非要求停止使用代码，仅需正确署名。更贴心的是附上了PR链接，只需批准即可完成补救！
侵权者对善意帮助的回应，恰恰印证了这并非失误，而是蓄意为之。我认为人该早早学会说 “我错了，我很抱歉，我会改正，绝不再犯” 。认错之时，尊重自会涌来。
> 指控出现时，Zigbook作者已遭受攻击
据我记忆(可能有误！)，事实并非如此：直到作者礼貌直接联系侵权方提出协助后，社区才知晓此事——而对方竟以敌意回应，表现得如同患有对抗性违抗障碍。
> 被Zig持续的垃圾营销手段反感
？什么？据我所知Zig的营销手段相当中规中矩，根本没达到Rust那种程度。
天啊，Rust传教突击队的行径让我至今仍厌恶Rust及其所有推广者。
你假设对方是青少年却毫无根据。他们盗用代码拒不署名，被要求时竟篡改注释嘲讽提议者。现在竟指责Zig社区欺凌？他们还谎称未使用AI。这种不诚实行为绝不容忍。
害处？Rust正席卷全球，而他们至今基本毫无建树(Rust诞生的项目Servo竟落后于Ladybird)。每个糊涂的开发者及其追随者都认为Rust超级安全又强大，可这门语言诞生19年后，实证依据依然寥寥无几。
Zig语言的支持者们渴望Zig“获胜”。如今他们几乎每天都会出现在Hacker News上，为此这类宣传手段比语言本身的优势更重要。尽管我认为该语言确实具备诸多优点——远胜于Rust——但它发展尚早且未经实战检验，不该获得如此多的关注。
> 实证证据寥寥无几
证据其实很容易找到并引用：
https://security.googleblog.com/2025/11/rust-in-android-move…
https://www.cisa.gov/news-events/news/urgent-need-memory-saf…
https://www.microsoft.com/en-us/msrc/blog/2019/07/a-proactiv…
https://www.chromium.org/Home/chromium-security/memory-safet…
https://hacks.mozilla.org/2019/02/rewriting-a-browser-compon…
顺便提一句，上述所有链接对比的都是Rust与1980年前创建的语言，且这些项目大多异常独立于crates生态系统，动态链接对其影响甚微。既然要使用现代语言，就该尽职尽责地将其与Swift这类语言进行对比——正如Ladybird团队当前所做的那样，甚至可以参考Koka这类研究型语言。目前Rust与其他现代语言的对比证据严重匮乏，我们应当深入探究，以免再次陷入选择最终被普遍认为糟糕的语言的困境。
微软在与C#对比后得出结论：https://www.theregister.com/2024/01/31/microsoft_seeks_rust_…
微软不会放弃C#，只是坚持“对症下药”。虽然某些场景确实需要更底层的金属级操作，但用Rust编写所有代码同样愚蠢——就像用C#编写所有代码，更别提用JS了。
我并非持相反观点。只是指出Rust语言能实现的价值在于节省数亿美元的计算成本。
读起来像白宫官方声明[0]。
[0] https://www.whitehouse.gov/articles/2025/03/yes-biden-spent-…
这似乎不公平；我没看到任何糟糕(概念和执行都差)的AI生成艺术作品伴随他们的声明出现。
依我之见，GitHub的核心优势在于其生态系统。这就像一把精心设计的瑞士军刀：开创性的(但已非新颖的)PR系统、便捷的问题管理功能，以及具备丰富开发动作和自由运行器的完善CI系统。此外，仅凭网页浏览器就能实现代码导航堪称绝妙——你编写代码，几乎所有功能都能无缝运作。赞助系统同样出色，开发者无需另寻外部捐赠平台，也不必在个人主页/仓库里贴奇怪的链接。
所有这些优势，正是开发者如此青睐它的原因。虽然对AI的痴迷让我有些不安，但对我这样的普通开发者而言，现有优势仍占上风。至少目前如此。
我完全不同意这种观点。GitHub之所以如此突出，在于它围绕Git构建的社交网络特性，这种强大的网络效应让多数开发者不愿割舍。维护者不愿失去星标，用户也不愿失去GitHub社群的集体“审核”机制。
仓库的星标数、分叉数、已解决问题数、账户关注数——这些指标都是强大的质量标识，无论你是否认同，它们已成为现代软件工程的组成部分。开发者更倾向于使用星标数高于替代方案的仓库。
我明白代码本应自证价值，开发者应当审核依赖项而非依赖GitHub星标，但现实情况并非如此——我们终究依赖着社区。
这些正是我使用GitHub的唯一理由。对学生和非开发者而言的易用性也是加分项。
完全不明白楼上评论所说的“完善的CI系统”指什么。GitHub Actions绝对是我用过最糟糕的CI工具。目前GitLab已完全复制了GitHub所有核心功能，且在我看来GitLab在各方面都做得更好。但问题在于——若把项目放上GitLab，根本没人会看到。
关于GH CI的评论令我惊讶。我最初在GL上使用CI，后来转用GH，发现GH的CI让我更轻松地完成工作。
多年使用下来，简单操作的便捷性并不总能反映复杂任务的处理能力。往往恰恰相反…
这正是现代互联网平台的核心问题。某个领域一旦由赢家(或少数赢家)主导，用户便难以摆脱其掌控——无论付出的是实际代价、道德代价还是劳动代价，通常三者兼而有之。而这些公司根本无意提升产品品质，只顾竭尽所能榨取用户价值。
Facebook沿着这条路走了十多年，后果昭然若揭。其服务本身糟糕透顶。用户之所以留存，只因熟人圈和兴趣社群都在此扎根，他们只能忍受被强行灌输的人工智能垃圾信息和监控。但Facebook并未因此增长，它正像其老龄化的用户群一样缓慢衰亡。而Facebook毫不在意——当今企业管理者们的目光，永远只停留在下个季度的财报电话会议上。
这是社会经济层面的问题，非互联网平台同样可能出现。例如人们最终选择聚居城市的现象便是如此。任何拥有地址、账户或身份标识的系统都可能产生强大的网络效应。
我认为你的观点是对我论述的补充，我也持相同看法。这正是GitHub广受欢迎的另一原因。
至于我，这并不否定我最初提到的便利性。
Github早在添加那些“社交媒体功能”之前就已成功，仅仅因为它为开源项目提供了免费托管服务(而在2000年代初，免费托管服务仍是稀缺资源)。
此前流行的免费代码托管平台是Sourceforge，它最终进入了如今所谓的“垃圾化阶段”。Github恰逢其时地取代了Sourceforge，其余的便是历史了。
从功能演进和用户热度来看，GitHub确实经历了几个阶段：
基于此脉络，其在AI领域的新尝试符合发展轨迹，但我认为他们需要明确定位：究竟要提升专业开发者的生产力，还是打造氛围式编程平台？
若选择后者，或许该分拆为独立平台并重新命名。(微软最爱命名了！不妨叫“Codespaces 365 Live!”)
技术上BitBucket也曾面临类似抉择，但它最初选择了Mercurial而非Git。资深开发者或许还记得当年两者对比评测中Mercurial略占上风的旧文。
至于那些不记得SourceForge的人，它在开发者体验方面存在两大缺陷：首先，开源项目无法直接发布，必须经过审核。即便通过审核，生成的URL也极其丑陋。而GitHub的URL设计美观得多。
记得在GitHub诞生前发布首个开源项目时，我曾严格遵循长长的清单要求：完善手册页、详尽文档、准确构建指南、规范变更日志。但目睹人们直接将代码扔到GitHub——没有手册页、文档匮乏、构建指南错误百出、变更日志杂乱无章——我意识到时代正在改变。
GitHub比BitBucket更快，无论是否启用JavaScript都能流畅运行。但最近似乎在退步。我尝试过多种替代方案，它们都更慢，但GitHub确实有退步迹象。
Mercurial曾是/仍是不错的选择，在我看来它能磨平许多git不必要的棱角。
但版本控制领域始终偏好标准化方案，因其核心价值在于协作，使用异构工具会带来诸多困扰。
而SS Linux内核这艘巨轮的庞大体量，让任何非git方案都难以匹敌。
我记得主要区别在于GitHub提供免费公共仓库和有限私有仓库，而BitBucket恰好相反。
因此若主要从事开源项目，GitHub在这一点上更具优势。
GitHub初创时还获得了Engine Yard的免费托管和技术支持。记得当年把他们从共享主机迁移到三台超级微型专用服务器时，可是件大事。
可惜社交网络功能至今仍价值巨大。要改变现状，必须有重大变革才行。
仓库的星标数量、分叉次数、已解决问题数、账户关注者数——这些指标都是衡量质量的有力标尺，无论你是否认同，它们如今已成为现代软件工程的组成部分。
我厌恶这种普遍认知的正确性。星标可以被刷量操纵，且其价值不会随时间衰减。问题可能被自动关闭，或以敷衍回答后关闭。关注者数量本质是社交网络/平台机制(通过关注高关注者账号彰显自身重要性)。
> 开发者更倾向于选用星标数量高于同类库的项目。
若真要说，星标数量反映的是先发优势而非代码质量。开发者在众多竞争包中选择时，本应考量远不止星标数量。可惜决策者的时间压力(及其固有假设)导致深度评估罕见发生，星标数仍成为项目是否采用仓库的主要依据。
星标数、已关闭问题数、PR数、提交数——这些指标毫无意义。
真正有价值的指标恰恰是他们无法获取的，比如依赖该库的项目数量。
他们追踪的指标不过是用户反馈的表面数据，不过是游戏化机制维持用户关注的噱头。
那么PyPI/npm等平台的日/周下载量呢？
这些数据都是流行度的替代指标，而流行度本身具有价值。我见过代码质量卓越的项目，但因依赖项更新、外部API变更或运行环境升级而最终失效；也见过代码质量平平却广受欢迎的项目，其所有怪癖和异常问题都有已知的解决方法。以ffmpeg为例：其代码堪称晦涩难懂。但你会仅因代码美观就选择某个用JavaScript编写的随机视频转码器吗？——尽管该代码最后更新于2012年。
我赞同你的观点。这既体现了社会认同的力量，也反映了多数开发者面临的时间压力。
在非编程社交圈中，社会认同更被广泛接受。因此我认为，对多数代码库而言，社会认同就足够了。
它们根本不是！许多垃圾AI项目都有5万+星标。
无需在GitHub开发也能实现，只需镜像你的仓库即可。
这还不够，我仍需在GitHub上与贡献者互动，至少要处理问题和拉取请求。
多数人用Codeberg的Forgejo(或自建服务器)就够用了。
> 仓库的星标数、分叉数、已解决问题数、账号关注者数——这些都是衡量质量的有力指标
哈哈哈哈哈哈哈哈哈哈哈哈…
好吧，这些是关注度的指标。你会押注于无人问津的项目吗？
若将软件工程纯粹视为押注行为，我当然不会这么做——但这正是我们分歧的核心。我并非故意找茬(好吧可能有点，告我啊)，那位前辈的评论明确提到了“软件工程”。
我可以举例：某些GitHub仓库星数虽低却品质卓越，反之也有星数惊人的垃圾软件。但我想你明白我的意思。
你押注的是项目能否持续维护；未来充满未知。若项目稍具复杂度，而你显然还有其他职责，就不可能独自完成所有工作——你需要社区支持。
有些项目或仓库的目标受众极其狭窄，有时甚至屈指可数。对少数真正需要者而言，这些仓库至关重要且无可替代，比如解码罕见且无文档的备份格式之类工具。
> 维护者不愿失去星标???
认真的吗？
> 这些都是质量的有力指标
我的经验并非如此….
你为何如此惊讶？
人们分享观星图并非“图好玩”，而是因为它承载着特殊意义。
我拥有GitHub账号17年，从未见过“观星图”。能举个例子吗？
> 人们分享观星图不仅是“图个乐子”，更因其中蕴含着特殊意义。
这有什么区别？
> 先驱性的(但已不再新颖的)PR系统
十年前用过Gerrit后，如今GitHub的PR系统没有任何地方让我更喜欢。
> 仅需在网页浏览器中即可实现代码导航
确实很棒，千真万确。
> 你编写代码时，几乎所有功能都能轻松运行。
要是真能这样就好了。GHA简直一团糟，因为不知怎的我们陷入了伪YAML(实则是shell-js-jinja-python混合体)的局部最优解，这些年来他们每隔几周就会遭遇大小不等的故障。
> 开发者为何如此青睐它
其他平台至少有一项功能远逊于此，而最关键的是它已成为行业标准。没人会因使用GitHub而被解雇。
我最欣赏GitHub的PR功能在于：这是我熟悉且已有账号登录的系统。参与项目贡献时，发现还得注册学习新系统实在太麻烦。
我多年前用过Gerrit，倒不算完全陌生，但Go语言项目用它处理PR时依然操作别扭。值得注意的是，该项目最终因用户体验摩擦放弃了它——而他们本是最可能坚持己见使用非主流工具的群体之一。
> 值得注意的是[go]最终放弃了[gerrit]
此说法不准确。他们至今仍基本只使用Gerrit。他们虽开放Github PR接收通道，但实际并未真正接纳，详见https://go.dev/doc/contribute#sending_a_change_github
> 需使用Gerrit账户回复审阅者，包括将反馈标记为'已完成'(若按建议实现)
评论区仍基于Gerrit，请务必避免使用Github。
若PR来自Github，Go审核者更可能默认你能力不足，导致审核速度变慢且更易被拒。所有Go核心贡献者都不会采用Github这种奇怪的PR流程。
> 若PR来自Github，Go审核者更可能认为你能力不足
我 始终 采用这种方式提交， 从未 遭遇过这种待遇。
Github PR的拒绝率确实更高
考虑到这是多数人最便捷的提交方式，这种现象不足为奇。几乎任何门槛都能筛除底层X%的低投入垃圾提案。
相关性不等于因果关系。
最低标准的提交方式必然导致最差的质量
确实是相关性，但信噪比低到这种程度——若通过GitHub PR提交，很可能被搁置数月甚至数年才有人审阅。
哦对。感谢指正——我还以为他们已更多转向GitHub。看来没我想的那么普遍！
许多人混淆了能力与投入度。
有能力的开发者更可能选择零摩擦的工具提交PR，而非耗费额外数小时注册账户并摸索使用某个冷门工具。
你同样犯了混淆能力与(缺乏)投入度的错误。
奉献精神与能力往往无关，反之亦然。若你宁可放弃任务也不愿使用现有工具完成工作，这说明了什么？
我无权评判此事，但能理解奉献精神可作为PR质量及后续互动的有效指标——这对热门开源项目或许有参考价值。并非断言此法绝对正确，只是值得考虑——某些维护者或许有过类似的经验教训。
有能力的开发者不会把Gerrit说成冷门工具。
这种态度很糟糕，简直就是挑起争端的诱饵。许多开发者根本没有接触过这个工具的必要。
合格开发者理应了解行业常用工具。
我并非要求开发者精通Gerrit操作，但至少该知道它并非冷门工具——这是谷歌资助的项目，处理着谷歌内部及外部数百万行代码。这就像你只用过Java或TypeScript，却说Go语言冷门。
仅因自己熟悉某工具而断定他人能力不足实属荒谬。反之亦然。
这是否暗含某种谷歌中心论？多数开发者既不在谷歌任职，也不参与谷歌项目，他们本无必要了解Gerrit。
> 大多数开发者既不在谷歌工作，也不参与谷歌项目，因此他们没有必要了解Gerrit。
多数开发者从未接触过Solaris系统，但若我询问Solaris相关知识时你连它是什么都不知道，这恰恰说明你的开发能力存在问题。
大多数开发者从未认真使用过Prolog、Haskell或Smalltalk，但若连这些语言的存在都一无所知，说明他们对编程语言范式缺乏好奇心——这绝非好兆头。
真正专业的开发者都会参与代码审查，在使用审查工具时难免遇到问题，因此他们会主动探索现有解决方案。
开发者没必要了解专业领域外的冷知识(比如“PNG默认采用哪种压缩格式”)，但文本编辑器和代码审查工具属于基础开发工具——基础到我认识的每位合格开发者都足够好奇去了解现有工具。编程语言、命令行界面和操作系统亦是如此。
这些都是荒谬的门派口号。我认识Solaris是因为我是个老古董，但我从未使用过它，也无需了解它。即使从未听说过它，我的能力也不会因此改变。
> 我最欣赏Github的PR功能在于它是我熟悉的系统，已有登录账号。参与项目时发现还得注册新系统、学习新流程实在令人厌烦。
codeberg支持GitHub账号登录，PR界面完全相同
你无需学习任何新东西！
没错，Forgejo最让我反感的就是这种对GitHub现有PR结构(我认为是残缺的)的盲目效仿。不过也罢，我还是把项目迁移到Codeberg了。
GitHub的PR系统对开源项目勉强可用，但对任何规模的商业软件团队来说简直不堪使用。
正如其他评论者所言：我怀念Gerrit和规范的评论
<->变更追踪功能。赞同，GitHub的“创新”——即拉取请求界面——除了小改动外简直不堪使用
希望Codeberg能在此基础上开发出“高级”选项
工作中曾短暂使用Gerrit，但每次参与需要它的开源项目时，我只会附上修复补丁发消息就走人——这种额外操作对临时贡献者实在太麻烦，我懒得折腾。
团队内部代码审查尚可，但完全不适合GitHub式的“用户发现漏洞→修复→提交”贡献模式
> 十年前用过Gerrit，如今GitHub的PR系统毫无亮点可言
我钟爱补丁堆栈审查系统。我理解它们为何不普及——理解起来稍难且编写耗时，但一旦掌握便是绝佳体验。在Phabricator完成代码审查后，我的补丁集整体质量大幅提升，而补丁集的优化反过来又提升了我的沟通能力。
> 完善的CI系统
Man 😐 不行。我确实理解使用Actions的便利性，但这简直是个糟糕的产品。
或许我的标准较低——毕竟从未接触过GitLab或CircleCI的产品——但相较于我过去使用Buildbot、Jenkins和Travis的经历，我认为它远胜于这些工具。
难道我错过了真正更好的替代方案？还是说所有CI系统都这么麻烦？
我对Buildbot和Travis了解不够，不便评论，但Jenkins？
我明白它曾是完成任务的标准工具，但现实中我见过的每个Jenkins实例都是个冒着热气的…未打补丁、无人维护、充满隐患的烂摊子。后来我明白问题未必出在Jenkins本身，而是团队总把基础设施当作事后补丁来“运行”，再加上总在“错误时机”搞砸配置的风险——这种情况简直无处不在。根据我的经验，这种模式几乎无处不在。
Github Actions确实存在缺陷和功能缺失，但我永远会选择托管构建服务而非Jenkins。
Jenkins本质上是容器化之前的构建工具，因此大量功能(除非你刻意让任务使用容器)都依赖于运行Jenkins的机器配置。这确实让某些操作更简单，但要实现可重复性就困难得多——你几乎需要配置管理方案来维持Jenkins机器配置的稳定性。
没错，“懒得打补丁直到出问题”是缺乏运维人员督促开发人员及时更新的本地基础设施常态，但这更多是SaaS与本地部署的本质差异，而非Jenkins的缺陷。
我对Github CI的质疑在于它不支持容器化运行代码。你只能使用 github-runner-1 用户，需要手动检出仓库、执行构建，并在完成后清理环境。这种方式既肮脏又不可预测。以上描述适用于自托管运行器。
> 我对 Github CI 的不满在于它不支持容器化运行代码。
这难道不是你想要的？
https://docs.github.com/en/actions/how-tos/write-workflows/c…
> 你只有 github-runner-1 用户，需要手动检出仓库、执行构建，并在完成后清理环境。这种方式既肮脏又不可预测。这是自托管运行器的操作方式。
确实每次检出都像小伤口，但这种方式能掌控全局——有时无需检出，或需要浅/全克隆。若自动检出，恐怕会有其他麻烦。
我用官方运行器，无需清理，每次都是全新环境。
Gitlab 明显更胜一筹
好奇有哪些更优选项。我觉得它和 Jenkins、CircleCI 竞争时表现不差。
具体哪里？除了服务中断我从未遇到过问题。
> 它糟透了，我每天都在用 > 替代方案很棒，但我从不用它们
每次都是。
你认为这个领域的好产品是什么？
我宁愿用brainfuck语言解Advent of Code，也不愿再调试他们的CI工作流。
难道不该让工作流避免嵌入逻辑，转而调用任务管理器？这样本地也能实现相同功能？
那为什么99%的GH Actions功能还存在呢？
将逻辑置于CI之外是相当普遍的做法，几乎可称工程最佳实践。只需让CI调用任务运行器，你就能在本地执行相同命令进行调试等操作。不妨将CI视为“服务化命令行”——你不过是付费让他人为你输入命令，这些操作完全可以在本地复现。
更进一步，可采用环境管理工具将工具安装环节从CI中剥离，从而实现本地/远程环境一致性并获得更多优势。
这是为了锁定用户。
因此我宁愿用brainfuck语言编写CI程序。
GitHub的核心问题在于从未否认过向AI提供私有仓库数据(例如GitLab在被问及时曾否认)。仅此一点就让许多用户心生怨怼，即便那些本身不使用私有仓库的组织也不例外。
>一个结构完善的CI系统，拥有众多开发行动和自由运行器。
我感觉人们对此依赖过度(尤其将本可本地完成的任务强行塞进CI)，对运行器也信任有加(记得有恶意软件报告)。
>此外，代码导航最好直接在网页浏览器中操作。
我始终觉得他们的导航功能笨拙且漏洞百出。
Github的PR和CI堪称最糟糕的系统之一。
> 此外，代码导航最好直接在网页浏览器中进行。
个人认为原生Github界面浏览代码体验极差——速度极其缓慢，搜索功能也毫无用处(集成版Web-VSCode体验好得多，例如在Github项目内按'.'即可调用)。
> 同时需要完善的CI系统，配备丰富的开发动作和免费运行器
Github CI系统唯一亮点是免费运行器(含Mac版)，其余功能客观上逊于Gitlab CI等替代方案。
> 此外，代码导航功能最好直接在网页浏览器中使用
如何定义“代码导航”？虽然选中符号自动高亮功能稍有改善，但源代码查看器却变得极其卡顿，且近几年存在一个诡异的横向滚动时光标错位的问题。我发现自己越来越频繁地使用“原始代码”按钮，甚至为临时查阅而克隆仓库。
编辑补充：更别提那个与浏览器内置搜索功能相互抵触的责任追溯视图了。
提示：在任意代码页面或PR中按下'.'键。
现在它居然打开…浏览器里某个VSCode风格的编辑器，还要求我登录？我为什么要用这种更耗资源又复杂的工具，就为了偶尔查个随机内容？
如果你熟悉VSCode，这个功能相当实用。若你因某些原因讨厌VSCode，那就别用它。
> 先驱性的(但已不再新颖的)PR系统
现在用过Forgejo和AGit后，我认为在GitHub上为新项目贡献代码时，PR体验实在不佳。流程实在没必要搞得这么复杂。
你最喜欢agit的哪些功能？
就是操作直观。GitHub的分叉-提交流程需要我克隆、分叉、为本地分叉添加远程仓库、推送至该远程仓库，最后才打开PR。
而agit流程只需克隆目标仓库，完成修改后直接推送(推送至特殊引用，但本质仍是推送至目标仓库)。
当Guix项目还通过邮件接收补丁时，我曾做过些微小贡献。这种方式(即直接向上游发送补丁)比GitHub推崇的模式更符合我的习惯。而agit就像是这种邮件工作流在Git原生环境中的实现。
我不明白大家在抱怨什么。除了Copilot在视图中作为选项出现外，我没遇到过这些AI问题。除此之外它似乎和以往一样正常运作
还有其他问题吗？
> 赞助系统也很棒
他们对个人用户完全免收费用，这太棒了。正因如此，当我的项目发布在这里时，我获得了第一个赞助商。真希望赞助收入能支付账单啊。
你认为GitHub在这方面有显著优势吗？我始终觉得两者势均力敌，各自存在增量优势。
我最爱的GitHub功能是全站代码搜索，记得以前用GitLab时没这个功能？
即便GitLab支持全站代码搜索，当大量优质仓库仍集中在GitHub时也收效甚微。真正有价值的搜索需跨平台索引仓库。但若担心用户因此跳槽至其他代码托管平台，向用户提供此功能就存在矛盾。
被低估的功能是代码搜索。初始阶段大家都以为只需在代码前端加个Elasticsearch之类的工具，但实际远比这复杂。GitHub曾打造专属代码搜索引擎，并事后发布过详细技术博客。
嗯，我猜也是。LinkedIn和GitHub同属一家母公司本就不意外。两者都在沦为扎克伯格式社交网络的互动黑客工具，以及伪简历式的自我吹捧作品集。若开源的价值沦为“它能帮我找到工作”，那也罢。但这绝非我们投身自由软件开发的初衷。
GitHub作为优质开源托管平台的进化早在数年前就已停滞。其优势在于社交网络效应，而非技术基础设施。
但从技术和用户体验角度看，这种侧重正引发日益严重的问题——据我观察，这正是Zig团队迁移的原因。
我近期迁移了自己的项目(https://codeberg.org/timbran/)，目前体验令人满意。抛开意识形态因素(自由软件理念、对微软的抵触、希望摆脱美国基础设施[胳膊肘上翘]等)，两大核心优势在于：无需付费即可创建专属“组织”，并能通过自有服务器运行项目操作。
迁移后，项目参与度未见下滑，新用户关注度也保持稳定。GitHub的“星标”根本是衡量项目成功的垃圾指标。
支撑Codeberg的Forgejo与GitHub足够相似，多数人根本不会察觉差异。
我个人不喜欢这些平台(GitLab、Forgejo或GitHub)的代码审查工具，因为它们不支持像Gerrit那样规范追踪审查提交——不过也无所谓了。至少Forgejo/Codeberg对社区贡献持开放态度。
先拥抱，再扩展，最后扼杀。
你眼前这玩意儿可不是维氏军刀，而是用几十年前的旧套路拼凑的廉价劣质山寨货(呜呜呜)。
他们只顾着搞“赞助按钮”和新功能，却不修补漏洞，简直浪费我的时间。
关于Codeberg的补充说明：这个项目本身很棒，但我好奇他们运行的基础设施如何，对于大型企业仓库的可靠性如何。
2025年11月22日 https://blog.codeberg.org/letter-from-codeberg-onwards-and-u…
官网声明摘录：
基础设施状态 […] 我们运行在3台服务器上：1台技嘉服务器和2台戴尔服务器(型号R730和R740)。
当前硬件配置如下：https://codeberg.org/Codeberg-Infrastructure/meta/src/branch…
[…] 尽管设备已使用多年，其性能(甚至能效)往往与我们能负担的新硬件相差无几。为减少硬件制造过程中的碳排放，我们认为使用二手硬件是更可持续的选择。
[…] 我们正在研究如何将损坏的苹果笔记本电脑改造为持续集成运行器。毕竟，自动化持续集成的使用并不依赖于人类使用计算机时所需的相同因素(如正常工作的屏幕、扬声器、键盘、电池等)。若您拥有故障的M1/M2设备或认识相关人士，且认为常规维修不具价值，我们非常乐意接收您的硬件捐赠并尝试改造！
[…] 虽然设备通常运行稳定，但每隔数日会出现性能骤降现象。通常只需重启Forgejo清除查询积压即可“修复”。
既透着早期谷歌的科技感，又带着创客空间的粗犷气息——这算不算好事，见仁见智。
https://status.codeberg.eu/status/codeberg
可惜其可靠性欠佳。目前主站24小时运行率仅89%，当前状态已部分降级。
虽然14天运行率达98%，但我认为这主要是因为部分辅助系统表现优异，主站实际运行状态似乎从未达到如此水平。
他们正处在艰难时期：https://social.anoxinon.de/@Codeberg/115652289949965925
https://news.ycombinator.com/item?id=46131693
是啊，上周他们也挂过。由小型志愿者团队运营开放式Git代码托管平台实属不易，面对海量读写请求和永无止境的“客户”(或机器人)，工作负荷极其沉重。
公平地说，Codeberg本就不是为企业仓库设计的，而是面向自由开源软件项目。看看他们的使用条款就知道了——他们根本不打算成为商业服务商，恰恰相反。
哇哦，我五年前二十岁时拥有的集群规模都比这大。既然成本如此低廉，或许我也该推出些免费服务——毕竟目前个人集群闲置硬件的电费就超过600美元。若有任何想法欢迎邮件联系：news.ycombinator.com.reassure132@passmail.net
或许可以联系Codeberg团队借他们一台服务器？听起来他们正需要各种支援。
顺便提一句，Codeberg是非营利组织
捐款通道：https://donate.codeberg.org/
Liberapay定期捐赠设置：https://liberapay.com/codeberg/donate
或在此成为会员：https://join.codeberg.org/
恕我直言：这更像是任性发泄。漏洞确实存在，修复速度有时不如预期，但考虑到GitHub生态的庞大规模，这很可能只是众多未解决问题之一。归咎于AI毫无根据——并非不可能，但这个结论似乎仅基于单一问题得出。
这对Zig项目意味着什么？我此前未曾听闻Codeberg，或许它很出色，但对于热门开源项目，我认为在决定迁移或权衡不同托管方案的利弊前，应当展开充分讨论。据我所知，Zig在技术层面无可挑剔，但似乎缺乏沉着成熟的领导力。这并非个例：许多由天才工程师发起的开源项目在成长过程中都面临困境，亟需建立新的领导架构。这种转型过程可能充满痛苦，甚至损害项目普及度。
> 漏洞确实存在，修复速度有时不如我们所愿
我认为更关键的问题在于：根本无法让任何人真正重视。我们放任微软这类科技巨头膨胀到可以无视服务缺陷的地步——作为用户，无论你是否付费、支付多少金额，对微软而言都微不足道。你付出的代价不仅是产品的直接成本，更包括产品任何问题对你造成的间接损失——比如这次虚拟机因基础缺陷持续空转。但你说得对，用Github的人从来不会因此被解雇。
对我而言，转向小型平台的最大优势在于：他们至少有动力帮助你成功。
我认为大多数CI脚本应尽可能保持纯粹脚本形态(字面意义上的脚本)，这不仅能促进本地运行，还能推动迁移至其他CI平台。
> 漏洞确实存在，修复速度有时不如预期，但考虑到GitHub生态系统的庞大规模，这很可能只是众多未解决漏洞中的一个。
恕我直言，你根本没说出任何实质内容。要回应实际批评，你需要解释为何他们列举的这些“不可原谅的漏洞”在你看来是可原谅的。否则，如果整个网站瘫痪数月，你那句“存在漏洞，修复速度不如预期”的声明同样适用且毫无意义。
> 我没听说过Codeberg
这其实更多是你的问题。
> 我以为迁移前会进行充分讨论
难道你不知道讨论根本没发生过？
[已删除]
我几乎可以肯定，Zig项目即便没有你追随也能生存下去。
现在你总算知道GitHub之外还有非营利替代方案了！太棒了！
我理解部分针对GitHub的抱怨。不过刚去尝试注册Codeberg就发现它宕机了…过去两周的运行率才95%？
https://status.codeberg.org/status/codeberg
若需严格控制服务等级，用户始终可以自行托管Forgejo。而GitHub连这个选项都不提供。
我甚至认为，将所有数据从单点故障转移到另一个单点故障，并非明智之举。
> GitHub连这个选项都不提供。
GitHub确实提供自托管产品：GitHub Enterprise Server
Forgejo采用GPL 3协议，而GitHub相关服务即便在自有设备上运行也需按用户每月付费，且仅通过查看[https://azure.microsoft.com/en-us/pricing/details/githubente…]无法确认代码是否可供编辑。](https://azure.microsoft.com/en-us/pricing/details/githubenterprise/)
商业软件支持并非免费。外包专业服务或调用内部开发者修复开源软件问题同样需要成本。
人的注意力并非免费。人的权利并非免费。仅用金钱视角思考终将付出代价。
没错，GitHub Enterprise Server 并非免费。确实需要按用户每月支付许可费(按年计费)，最低购买门槛为10个用户，费用约为21美元/用户/月。符合资格的微软折扣可降低成本。付费换取的是技术支持——虽非常需，但关键时刻不可或缺。
即便管理1.5万用户也轻松自如，只要为所有活动分配充足内存和CPU资源，系统基本能自主运行。
从GitHub下载虚拟硬盘映像虽易，解密其中代码更是轻而易举，但我不会协助任何人实施此操作——毕竟我从未需要过。
作为服务器产品，它表现优异。若预算允许，我推荐选用。但需注意：该产品并非面向个人用户或非营利组织设计。它面向的是希望将代码部署在本地环境的企业用户，在这方面表现相当出色。
作为GitHub Actions的用户，根据个人体验，GitHub频繁出现的问题反而让这点不足显得微不足道。
Reddit上也有用户对此提出过抱怨。我最近注册了账户，最烦人的是不断弹出的“确认非机器人”验证。目前暂无迁移必要，但Forgejo的自托管方案确实颇具吸引力。
https://tangled.org/ 基于ATProto构建
1. 使用git或jj
2. 数据以网络拉取请求形式存在
3. 提供UI界面，但用户可自由构建界面且生态系统共享
我正考虑用Gerrit进行git代码审查，而当私有数据/仓库成为现实时，Tangled将很有前景。目前暂不打算同时使用多个git托管服务
我也对Tangled的开发极感兴趣，但怀念GitHub的两项功能——全局搜索和版本发布。Tangled的网页前端快得让我还在适应，而jj首创的堆叠式PR功能简直绝妙，让人联想到Linux补丁提交机制。
它之所以快，是因为功能缺失
比起jj，我更关注Gerrit/Git-CodeReview的堆叠提交功能。对新手来说只需多学几个命令，无需完全掌握新工具和术语体系
当前最令人振奋的三大去中心化GitHub替代方案：
Codeberg支持哪些去中心化协议？
我最近从自建GitLab迁移至Forgejo，其体验远超预期且操作更简便。性能表现也显著提升(可能因我无需GitLab的多数高级功能)。
我对此已思量近两年。Gitlab日益臃肿，即便在配置中禁用了多项服务，其计算资源和内存需求仍持续攀升——我们甚至根本没用过内置的Postgres数据库。
仍有几项因素让我留用Gitlab，但核心在于其CI/CD系统和Gitlab Runner的卓越品质。
我考察过Woodpecker，但它似乎过于依赖Docker，而我们，呃，并非如此。
另一大鸿沟在于问题管理功能。Gitlab CE表现糟糕：存在奇怪限制(付费版才支持史诗级任务)、功能故障、用户体验噩梦，但Forjego在这方面似乎更欠缺？尽管如此，我们仍经常使用“在提交中引用问题编号”来关联工作项。对此我明白答案是“亲力亲为——为Forgejo贡献代码”，我也确实愿意这么做。但目前这仍是阻碍。
发布此评论的初衷是希望征集其他建议或我忽略的见解？
> 但我承认Forgejo确实很适合自托管。
我自托管它已有数年，绝对值得推荐。其稳定性极佳，我甚至部署了运行器。完整教程详见https://huijzer.xyz/posts/55/installing-forgejo-with-a-separ…。
我的意思是，他们一直在应对DDoS攻击。我在Mastodon上关注了他们的账号，他们对此相当坦诚。
我认为正确的问题应该是：“既然他们不重要，为什么会遭受如此大规模的DDoS攻击？”
想关注的朋友请移步：https://social.anoxinon.de/@Codeberg
连他们的状态页面都遭到攻击。恕我直言，这到底怎么回事？
太疯狂了。谁会愿意耗费资源对Codeberg发动DDoS攻击？唯一能想到的只有Github。我知道经济领域普遍存在冷酷无情和赢家通吃的思维模式，导致犯罪行为不可避免，但这仍让我难以理解。
不止他们。比如两周前Qt自托管的cgit就遭DDoS攻击。完全搞不懂为什么随机开源项目会成为攻击目标。
https://lists.qt-project.org/pipermail/development/2025-Nove…
听起来像是经典的人工智能爬虫DDoS攻击——顺便说一句，目前没有任何证据表明这与人工智能有关
八成是些自以为是精英黑客的小混混，用老妈的信用卡付费购买现成的DDoS服务。
如今DDoS攻击便宜得离谱，可能是某个无聊人士图个乐子，或是单纯测试演示(不过我怀疑Codeberg根本不够格当演示目标)。
难道是因为物联网(IoT)里的“s”代表安全？我真心在问。这些请求到底从哪儿冒出来的？
我认为有四大原因：
– 互联网规模已大幅扩张
– 存在大量安全防护薄弱的物联网设备
– 普通家庭网络带宽显著提升，尤其是上传速率
– 各类放大攻击技术层出不穷，能利用配置不当的服务成倍放大攻击带宽
搜索“住宅代理”就明白了。
这似乎就是僵尸网络的同义词。
更准确的表述是“为自身利益规避管控的匿名化欺骗性AI爬虫大军”。
成本低廉但被抓风险大？我理解15岁少年可能为寻求刺激而为之，但难以想象这能带来街头信誉，更不明白为何执着于此。AI机器人更合理，不过这类威胁可被有效应对。
科技巨头对数据囤积的兴趣远胜于发起DDoS攻击。
评论区问题——关联PR的评审意见、实现功能的提交堆栈、后续处理意见的提交记录——这些数据对训练编程智能体极具价值。
获取这些数据并非简单克隆仓库，而是需要调用其(公开且有文档的)API接口，运行成本可能更高。
若他们对爬虫实施速率限制，那些无良之徒就会把请求分散到整个互联网。
>目前唯一可能的来源方是Github。
我认为这并非恶意，而是愚蠢。物联网让脚本小子都能操控庞大僵尸网络，足以对除CloudFlare外的任何目标发起DDoS攻击。
> 谁会愿意投入资源
威胁分析不是这么运作的。这是阴谋论。你得考虑实现难度。
否则我就能开始猜测哪家大型NAS供应商在对我发动DDoS攻击，而实际只是脚本小子所为。
至于谁的动机最强？毫无底线的人工智能抓取者。每个缺乏防护的网站都会遭遇AI爬虫/机器人的洪流攻击。
我认为目标尚不明确，但后果将是Codeberg会被视为缺乏真实稳定性的替代方案。入侵行为虽非我本意，却会产生相同甚至更严重的破坏效果。若这本就是预设效果，我希望自己不必相信这个事实。
故事时间：
记得当年我曾持有某个热门关键词的域名，在谷歌自然排名中表现优异。某天突然遭遇黑帽SEO猛烈攻击，各类无关网站涌入海量外链。结果域名遭到惩罚，彻底跌出搜索首页。
其实我认为威胁分析的运作逻辑大致如此。
进行威胁分析时，需明确自身防御的坚固程度、攻击动机以及潜在对手身份。
针对每个潜在对手，列出风险应对策略——这是威胁分析的基础。
例如：你有一扇锁门和贵重物品，而对手是国家级别。风险策略：放弃防御——任何你能负担的门都挡不住国家行为体。
我同意“谁会动用资源对Codeberg发起DDoS攻击？”这个问题混淆了动机与资源的概念。但这依然属于威胁分析范畴，只是实用性欠佳。
为大型企业服务的AI爬虫，难道不比竞争对手更有动机窃取你的代码吗？
微软收购Codeberg并关闭它，比耗费时间金钱进行DDoS攻击更简单
如何收购一个e.V.？
https://en.wikipedia.org/wiki/OpenAI#Transition_from_non-pro…
这种操作只适用于法治存疑的国家
就像收买标准委员会那样。
去研究下Office格式ISO标准化流程就明白了。
我并非暗示微软会收购Codeberg，只是想说明他们对这种操作模式并不陌生。
试问存在这样的标准委员会吗？拥有786名投票成员，却需要说服至少三分之二成员背弃他们主动加入的协会理念，才能促使协会解散或停止履行使命？
我认为你的类比站不住脚。
约800名成员？这消息令人欣慰。我支持Codeberg，希望它能成功并免受外部影响。
话虽如此，我认为我的类比成立。约800名成员构筑了有效护城河，足以阻挠外部势力损害Codeberg。
但理论上该机制仍可能失效。微软当然不会采取如此赤裸裸的手段，但若e.V组织失去这道护城河，随着Codeberg人气攀升，微软完全可能且有意动用某些手段。
数据来源见此：https://blog.codeberg.org/letter-from-codeberg-onwards-and-u….)
我认为另一个重要“护城河”在于Codeberg仅由自然人组成(至少投票权限如此)。真实用户具有价值观，而他们必须通过某种方式积极参与Codeberg才能获得投票权，这意味着其价值观很可能与Codeberg的使命相契合。虽然我不了解您提及的标准化流程细节，但这点差异至关重要。
此外，粗略浏览Codeberg章程后，我认为其中内置了多重安全机制作为额外保障。首先，你不可能简单地花钱雇佣约1600人注册来冲击全体大会——每份会员申请都需事先获得批准。该组织还要求成员“以适当方式支持协会及其宗旨”，并设有机制驱逐违反此原则或损害Codeberg利益的成员，而此类敌意攻击显然属于后者范畴。
当然仍需保持警惕，但我认为Codeberg在防范敌意接管和关停方面已做好充分准备，以至于DDoS攻击反而成为更易实施的手段(正如最初讨论的主题)。
你去比亚迪经销店了？？？
我说的是e.V.，不是EV。Codeberg是德国的e.V.，即“注册协会”。我其实不确定从技术层面能否收购e.V.，但可以百分之百肯定Codeberg e.V.的所有成员都不会对微软的敌意收购企图善罢甘休。所以，收购Codeberg绝不会比对他们发动DDoS攻击更容易。
他们无法收购组织本身，但可以收购Codeberg或其成员
本质上是同一回事
你所说的“组织”具体指什么？“Codeberg”又指什么？
当然，他们可以尝试贿赂Codeberg e.V.的活跃成员改变协会宗旨或直接解散组织，但这需要在全体会议上获得三分之二多数票——而只有参与协会运营或其项目的成员才有投票权。我认为这种操作成功的可能性极低。
问题部分在于Codeberg/Gitea的API接口文档完善，存在专门抓取Gitea实例的机器人。这类似于在22号端口运行SSH或托管流行PHP论坛软件——只要API被识别，就会持续遭受各类实体的自动化攻击。
这可真够呛…外界环境实在险恶。
试试把无密码SSH服务器暴露到外部看看会怎样。攻击会立刻开始，永不停歇。
现在我运行的所有服务器都不再开放公共SSH端口。这也是我不将家庭服务器暴露到互联网的原因——我不想让这种混乱出现在自家门口。
用IPv6的22端口暴露服务，简直如同隐形。日志干净得前所未有。
是啊，我也考虑过在家庭服务器上托管小型互联网服务，但实在不愿承担风险。我宁可用独立网络连接，也绝不在主网路上做这种事。
你可以租用小型Hetzner服务器(紧急时也可用Oracle免费云服务器)，在所有主机安装Tailscale，构建点对点隐形网络。但需确保面向互联网的服务器安全防护到位，若网络存储个人数据还需在Tailscale层面设置访问控制列表。
我可能会直接SSH连接Hetzner服务器，而不将其接入tailnet。
tailscale或cloudflare能实现这个需求吗？让它们连接到服务器即可。
确实无需开放公共SSH端口。若必须使用，请随机选择端口并启用fail2ban防护，更优方案是仅将当前会话使用的IP加入白名单。
要避免SSH操作，只需将日志和指标导出，配合安全自动部署方案即可大幅减少远程操作需求。或者直接用k8s 🙂
单IP白名单(最好是静态IP)听起来合理。
个人基础设施用Kubernetes，就像钓鱼用航空母舰。
简单系统用快照和备份就够了。管理千台机器的集群当然另当别论。
我两类系统都管理过，所以绝不会在小型主机上使用大型软件栈。:D
这纯属恐吓宣传。仅开放密钥认证的SSH服务器对外网开放并无风险。扫描器固然会持续探测，但没人会特意为你的家用服务器开发SSH零日漏洞。
几年前，某个存在漏洞的压缩库险些被主流Linux发行版用于链接其OpenSSH实现。这纯属侥幸被发现。我确信还有更多我们尚未察觉的隐患存在。
> 这纯属恐吓宣传。
不，这只是操作安全规范。
> 扫描器固然会持续探测，但没人会拿SSH零日漏洞去攻击你的家用服务器。
以我所见之事，对此我不敢断言。
宁可稳妥也不要后悔。你若坚持暴露SSH端口也罢，但别让你的服务器连入我的网络。
“操作安全”包含威胁建模、风险评估等明确规范，所谓“我见过的案例”和模糊的“宁可错杀不可漏网”并不在此列。
操作安全有两条黄金法则：
具体操作可参考我的个人资料。
只需使用随机SSH端口即可解决
所有服务为方便访问始终开放，但绝不使用标准端口(HTTP除外)
这确实能减少干扰，但无法阻止决心已定的攻击者。
长期管理服务器集群后，我绝不会这么做。访问“登录”端口时，Tailscale或其他VPN对我而言是强制要求。
温馨提示：Codeberg仅限开源项目使用，部分配置文件等内容亦可存放。此规定已明确载于其首页及服务条款。
99.95%的可靠性是我工作所需的底线，不可妥协。
反正你也不会用它工作，Codeberg只适合开源项目
GitHub的运行时间也不完美。若你的雇主不仅将其用于“存储Git仓库”，例如使用GHA进行构建部署、打包等操作，你就会发现这些不时发生的故障。
什么？它显示过去两周的运行时间是98.56%。
那大概是平均值。但若Codeberg Translate以99.58%的亮眼数据出现，反而会损害“Codeberg.org实际92.42%”的真实情况，纯属多余。
典型的大科技替代方案。解决不了问题，无法扩展，用户体验糟糕，但至少由狂热分子运营。
Forgejo确实解决了我的问题，虽然 目前 无法扩展(我非常期待ForgeFed)，用户体验良好，而且至少由真正关心平台的人运营。
正因其秉持Codeberg精神，我敢断言他们从哲学层面抵制使用Cloudflare这类云端DDoS防护服务。遗憾的是，至今无人提出真正有效的替代方案。
面对攻击者预先设置邮箱响应的恶意账户创建行为，Cloudflare能提供多大防护？
大型语言模型固然实用，但“人工智能”本身已是开始褪色的营销术语。它正迅速沦为令人厌烦的潮流标签，而非前沿概念。
我敢断言，约24个月后，多数应用仍会保留某种形式的人工智能功能，但“人工智能优先”的营销话术将彻底消失。
> 人工智能本身就是个开始褪色的营销术语。它正迅速沦为令人厌烦的潮流标签，而非前沿概念。
过去十五年你躲哪儿去了？不过我认同你的预测。可口可乐用AI制作广告几年前或许还有噱头，如今却成了蠢事。
你最近看过电视广告吗？每一条都是AI生成的。仔细观察就会发现破绽：拼接的3秒片段存在连续性问题，所有对决场景都来自固定的镜头组合等等。只是普通观众比可乐广告更难察觉罢了。
我记得AI作为营销术语普及不过两三年。此前它只是偶尔出现的模糊技术概念，如今每个应用都重新包装成AI智能体业务。
在LLM时代之前，人工智能至少经历过三波浪潮：70年代、80年代和90年代末。
https://en.wikipedia.org/wiki/AI_winter
2010年代初神经网络AI技术蓬勃发展，虽形成小规模炒作周期，却为当前LLM浪潮奠定了基础。
我明白，但那些浪潮主要局限于科技企业和学术界。而这次浪潮似乎渗透到所有领域。
2014-2016年间还出现过小型聊天机器人泡沫(微软Tay事件彻底击垮了它，此后再未恢复)，不过当时企业似乎对使用“AI”这个词有些顾虑。
没错。“大数据”‘数据挖掘’“机器学习”
另一方面，尽管“个性化广告”这个概念本身令人反感，但它依然风头正劲。
他们还对仪表盘信息流做了灾难性更新，导致首页基本失去实用价值。
https://github.com/orgs/community/discussions/65343
最新更新直接用近期更新的PR和问题列表取代了原有内容。自上线以来我一直在深度使用这个功能，这是近期少数真正让人感觉明显改进的改动。
哇哦。我不得不连续点击十次“体验新界面！”按钮才终于加载成功，但这次更新我 很满意
虽然只是个例，但…谁会用首页？我上那里就是为了处理项目。除了组织和项目页面，我从不浏览其他页面。
仪表盘我好多年没用了。现在的首页内容或许更有用。对我来说，首页应该直接跳转到通知中心。
反正信息流功能还在，通过浏览器自动补全就能访问。我直接在地址栏输入“not”就能打开GitHub通知页面。
我们正目睹微软收购GitHub并获取影响力的实时后果。回溯推特被收购后的境遇便能理解其中深意。多年前我就停止在GitHub托管代码，即便私有仓库也不例外。想到大型语言模型会吞噬这些信息，简直是场隐私噩梦。我认为Zig避开微软在GitHub上的下一步动作是明智之举。这就像避开地雷——当某事物开始偏离核心用途走向营利化时，及时抽身便是明智之举。抛开“Zig需要大型项目支撑”或“必须保持小众定位”的争议，Zig为内存与系统操作带来的诸多便利，对像我这样无法驾驭Rust的开发者而言尤为珍贵。只需安装试用，你便能亲身体验。我希望我们能回归探索精神，而非过度聚焦经济利益和职业发展——这些领域往往被企业操纵着所谓“正确”的标准。
我认为Codeberg一旦实现联邦化，必将吸引大批用户。
目前GitHub在项目发现与追踪方面表现出色，其星标和分叉系统能有效反映项目成长(尽管近年略显失灵)。
若为这些GitHub替代方案叠加联邦层，用户只需在Codeberg注册账号，就能追踪分散在各平台的项目。如今我看到大量forgejo服务器，却不愿在每个平台重复注册。
+1 – 若Forgejo加入联合功能，它完全有潜力成为新的Stack Overflow
SO的核心问题在于它与实际维护项目的社区脱节。联合解决方案既能保持网络效应，又能将所有权交还给原始社区(而非社区在SO上的独立分支)
Codeberg最令人称道的是页面加载速度。浏览GitHub时常感觉非常迟缓。虽然两者规模存在差异，但希望Codeberg能保持这种速度优势。
确实如此。当我在英国火车上使用不稳定的4G网络时，GitHub简直是噩梦——页面只能加载一半。
相比Linear这类平台简直天壤之别。
这很意外。我的体验恰恰相反。
更优的基准测试需通过浏览器检查器(网络标签页或性能标签页)完成。在网络标签页中(缓存已禁用)我获得以下数据：
我认为 GitHub 相较 Codeberg 启用了大量缓存机制。
我觉得你理解反了。在skydhash的测试中，Codeberg数据缓存率为72%，GitHub为28%。你可能想说GitHub缓存的4.28MB在绝对值上超过了Codeberg的1.41MB？
GitHub部分区域采用SPA架构，因此DOM加载迅速，但随后需等待JavaScript文件及其调用的请求。Codeberg支持禁用JavaScript运行，且额外请求极少(几乎所有内容都在服务器端渲染)。
传输量统计指的是gzip压缩传输。若数据主体为HTML(我未核实)则该数据合理。
我已禁用网络请求的缓存功能。
哦，感谢指正。这是我犯的低级错误。
没错，正是这个意思。Github的策略似乎是先推送所有需要缓存的初始数据，以此优化后续请求。
这取决于地理位置。GitHub Pages即使在获取HTML后，仍需较长时间执行所有JavaScript才能呈现可用页面；而Codeberg页面所需JavaScript极少，即使禁用JavaScript也能基本正常使用。
以下是我的测试结果供参考：
当然，这取决于你的网络连接。但在Codeberg上，我看到空白页面持续3-4秒才显示内容。像Zig这样的大型仓库延迟更严重。
Github的页面会逐步加载，初始阶段就不会出现空白页面。
尝试在审查PR时切换标签页。基础PR通常需要5-10秒
GitHub首页确实非常快，但浏览仓库时有时会出现超过一秒的加载时间，尤其当访问冷门仓库时，这些仓库不太可能被缓存。
此时不妨提及Fossil——这款由SQLite开发者打造的卓越SCM工具，内置多项类似GitHub的功能：
https://fossil-scm.org/
单个约6MB的可执行文件，运行迅捷如风。我已愉快使用多年。
Fossil没有代码审查系统，因为SQLite的创始人并不认同正式的代码审查流程。它也没有完善的外部贡献接收机制(除.patch/bundle文件外)，因为这位创始人认为除了自己之外，无人具备持续贡献代码的资质。
对于个人项目或许很适合——业余爱好者用用也行——但除非你像Richard Hipp那样走运，能成为高薪隐士，在实质上一人主导的“大教堂模式”中工作，否则对大多数项目而言并不适用。
极简虚拟主机：下载可执行文件，复制粘贴Apache配置，激活即可运行。某些服务商甚至无需购买域名。
个人及中小型项目占所有项目的99%。
Fossil 非常出色。我鼓励大家在下次个人项目中尝试使用它。
GitHub 的核心功能本质上是宣传或展示作品。我会将 GitHub 问题、星标等作为衡量库质量的(不完美指标)。这并非源于GitHub功能本身，纯粹因其规模最大、知名度最高。当然我清楚存在购买点赞的行为，所以这些指标只是评估因素之一而非全部依据。
如今zig已获得相当知名度和信任度，因此在迁移过程中他们对此的顾虑自然会减少。
公平地说，这更多是GitHub Actions的问题而非GitHub本身——后者从一开始就不可能真正与专业解决方案抗衡。
Zig团队应该使用专业的CI工具，而非依赖大型服务商附带提供的次要功能。
我们的CI工作流本质上只是调用一个普通的旧式shell脚本(该脚本可在CI环境外运行)。我们实在不需要过度复杂的专业级CI/CD方案。
切换到Forgejo Actions的优势在于其运行器轻量、快速且稳定——这些都是GitHub Actions运行器无法比拟的。但即便如此，它仍比我们理想中的方案臃肿得多；我们根本不需要YAML工作流语法和基于Node.js的动作带来的复杂性。若CI系统能与https://codeberg.org/mlugg/robust-jobserver集成就更好了，Zig编译器和构建系统即将支持该接口。
因此未来我们很可能自建运行器，并使其对接Forgejo Actions接口。
除了服务中断，GitHub Actions还有什么问题？我自己从未遇到过故障。
天啊，该从何说起。
我的意思是……服务中断确实是主要问题。但更糟的是这些故障还会波及我自己的硬件(比如上述占用我自有计算资源的漏洞)，简直雪上加霜。
但作为产品本身，它就是糟糕透顶？漏洞百出？以下问题不分先后：
* 构建产物API在运行期间会返回垃圾结果。需注意：这些API与GHA操作中交互构建产物的API是分离的，后者使用未公开的API——大概是因为公开API漏洞百出。
* 需要…操作若输入有误，就会返回垃圾数据。
* 操作构建不支持缓存导致速度极慢。许多GH官方操作通过将标签/分支(如@v4)指向预构建工件来规避此问题。
* 定价 偏高 ，相较于其他同类产品。
* 界面简直一团糟：例如标准输入是 管道 ，这会破坏某些通过管道传输时行为改变的命令。标准输出和标准错误也是 管道 ，虽然GHA表面支持彩色输出，但这基本使其形同虚设。
* 任务、步骤、操作的概念混乱不堪。虽然包含“执行此操作”等核心理念，但逻辑完全混杂重复。容器设置需按任务配置，若需在同一任务内部分步骤使用不同容器，用户将束手无策。
* 密钥管理困难重重，更难避免泄露风险。
* 表达式语言存在诸多陷阱，例如强制类型转换和具有 解析时副作用的函数！
以上仅是我遇到的部分缺陷。
我的意思是……服务中断确实是主要问题。但这些中断还波及到我的自有硬件(比如通过上述消耗自有计算资源的漏洞)，简直是雪上加霜。
虽然从未需要运行自己的运行器，但服务中断确实令人恼火。
> 构建产物API在运行期间会返回垃圾结果。需注意这些API与GHA操作中交互构建产物的接口是分离的，后者使用未公开的API——大概是因为公开API存在严重漏洞。
我从未遇到过问题，因为只用GitHub CLI将构建产物上传到发布版本。
> 需要……如果输入有误，就会返回垃圾数据。
此前不知情，但我从未出过错。不知像actionlint这样的代码检查工具能否检测到这种情况。
> 动作构建不支持缓存，导致运行相当缓慢。许多GitHub官方动作通过将标签/分支(如@v4)指向预构建工件来规避此问题。
难道没有可用的缓存动作吗？
> 相比其他同类产品，定价偏高。
试试 blacksmith.sh，价格减半，速度更快且支持无限并行处理等功能。
> 界面简直一团糟：例如 stdin 被设计为管道，这会破坏某些通过管道输入时行为改变的命令。stdout 和 stderr 同样是管道，虽然 GHA 表面支持彩色输出，但这基本让该功能形同虚设。
我始终调用任务运行器，工作流内不包含命令，因此从未遇到此问题。
> 任务、步骤、操作的概念混淆不清。其中包含若干核心概念(如“执行此操作”)，但整体结构混乱且存在重复。
难道不是每个任务包含多个步骤，而每个步骤即为一个动作？
> 容器设置按任务配置，因此若想在同一任务中部分步骤使用一个容器、部分使用另一个容器，你将束手无策。
确实无法实现，不过我也从未遇到过这种情况。可通过调用脚本挂载卷，再用
docker run在容器中执行命令来绕过。或者干脆拆分任务，避免使用多个作业即可。> 密钥管理困难重重，防泄露更是难上加难。
个人账户确实如此，不可能为每个仓库设置密钥。最近我采用的方法是：
` gh repo list –json name,owner –limit 100 | jq -r '.[] | “(.owner.login)/(.name)”‘ | while read repo; do if gh secret list –repo “${repo}” –json name | jq -e ’.[] | select(.name==“EXAMPLE”)' > /dev/null 2>&1; then gh secret set EXAMPLE –repo “${repo}” –body “${EXAMPLE}” fi done “`> 表达式语言存在各种特殊情况，比如强制类型转换和具有解析时副作用的函数！
我工作流内部其实没有逻辑处理，都是调用Make或脚本之类，所以从未遇到过问题。
你更倾向哪种专业解决方案？
我用Jenkins，虽然这里争议不少，但它多年来对我来说稳定可靠。
市面上还有许多专业解决方案，其商业模式纯粹围绕CI构建。
Buildkite才是新高度
Google Workspace也让我做同样的事。不，我不想“生成镜像”，只想用自己的镜像，谢谢。他们把AI功能放在 所有地方 的首位，损害了产品和用户体验。
原因有些奇怪。在我看来，Zig似乎只是立场非常鲜明。个人认为迁移到Codeberg的决定与微软是否构成问题无关。我并不否认微软是问题所在，只是目前尚未看到多少能替代GitHub的优秀方案。作为用户，GitLab始终不如GitHub好用。
更大的问题在于这些巨头企业掌控了太多资源。如今我认为谷歌在这方面比微软更令人担忧。人工智能加剧了这一问题，但即便没有AI，这种垄断本身早已构成隐患。
如今Bitbucket表现如何？它是否已退出竞争？
这么说吧，没有工程师会主动选择Bitbucket。你使用它，只是因为十年前某位高级副总裁错误地选择了Atlassian软件，且拒绝更换。
我曾用过它，但后来离开是因为明显看出Atlassian在软件和商业层面都日益无能，两方面都严重失灵。
多样性固然可贵，但我认为很多人低估了GitHub的质量与服务，尤其是免费服务。纵使商业供应商也未能长期维持免费服务(Docker Hub、Bintray、Sourceforge皆然)。它们本可通过商业产品和广告盈利，最终却不得不削减免费服务。我至今好奇Codeberg将如何应对激增的运营成本。
此前讨论详见：https://news.ycombinator.com/item?id=46064571
将Zig主仓库从GitHub迁移至Codeberg – 883条评论
不知道Codeberg是什么，甚至无法访问…是这个吗https://codeberg.org/？？
没错。它经常宕机。https://status.codeberg.org/status/codeberg
92%的正常运行时间？剩下8%的时间你们在做什么？难道只是循环执行git push命令并让电脑保持运行？
既然Git是去中心化的，你完全可以继续工作。
你也可以本地运行Forgejo实例(驱动Codeberg的软件)——只需一分钟就能安装完成的单一二进制文件——并设置本地代码库镜像，包含代码、问题等内容，这样在Codeberg恢复前你仍能访问问题、维基等功能(不过后续需要手动更新)。
希望Codeberg能应对这波热潮，但
> 只需一分钟就能安装的单一二进制文件——并为你的Codeberg仓库创建包含代码、问题等内容的本地镜像，让你能访问问题、维基等功能
这设计实在太酷了！本地镜像还能让你构建自定义工具，按最适合的方式分组、浏览和查看内容，这将极大简化工作流程。
> 后续需要手动更新
这里的“手动”具体指什么？只需记得执行
forgejo fetch(或等效命令)同步即可？如本帖其他讨论所述：他们正遭受DDoS攻击，且已公开承认此事。
“要么拥抱AI，要么离开这个行业。”——Dohmke。Dohmke于11月卸任GitHub首席执行官职务。
他离职后创办了人工智能初创公司
CEO践行自身建议实属罕见
现任CEO是谁？
完全同意，微软正用AI毁掉一切。其实早在LLM时代之前，微软所有产品就已持续衰退多年，如今更是加速崩盘。
看到GitHub也遭遇同样困境令人痛心，人们被迫使用各种半吊子的替代方案。要在多个代码仓库中追踪心仪的开源项目实在不易。真希望有人能从微软手中收购GitHub，清除他们添加的所有垃圾功能。
或者创建一个统一界面，跨多个代码托管平台追踪项目动态。
> 在多个代码托管平台追踪心仪的开源项目绝非易事。
多数开源项目的公共代码库实例和网站都提供RSS订阅功能。
看吧，AI加速生产力，微软正借此更快地毁掉自家产品和品牌！
从技术角度看GitHub在Actions中的衰落确有其事，但Actions本身始终存在缺陷。早在正式的临时模式出现前(仅靠官方不支持的易引发竞争条件的–once标志)，我们就尝试过让自托管运行器超早期运行。效果糟透了。该代码无法生成稳定状态码，频繁因模糊的Azure错误代码连接调度器失败，且在任务接收与超时处理中存在大量竞态条件。运行器无法获取新任务，任务会滞留一小时后超时，运行器直接崩溃需重新配置(我们使用GCP实例组中的临时虚拟机)。这一切都源于Actions本质上是Azure DevOps Pipelines的换标产品。
相比当年，如今这款产品已相当成熟。但必须指出，GitHub内部始终存在着开发糟糕产品的团队——这些产品虽不属于开源核心，却被众多开源工作者所目睹。企业级云服务充斥着无数尖锐缺陷，总会让你忍不住高声质问“为什么”。启用SAML的通知功能存在无数缺陷(我当前12条通知全未送达)，新用户会被引导点击“请求Copilot”按钮——该操作会向管理员发送无法禁用的邮件，某些政策开关被拆分后默认值设置不当。后两项尤其明显，纯属诱导用户使用Copilot的黑暗模式黑客手段。这可是企业级产品。
我虽未用过GHES，但想必情况更糟。
GitHub的纯Git功能是否正常？由此可见，Actions和运行器已近乎无法使用。但仓库本身是否仍安全？
服务中断导致
git push失败。我不喜欢界面中的人工智能应用，浏览代码时侧边栏也常常碍事。把GitHub当作笨拙的Git后端也并非良策——看看Linux内核的PRs吧，几乎全是垃圾信息。为什么PR功能不能被禁用呢？https://github.com/torvalds/linux/pulls?q=is%3Apr+is%3Aclose…
幸好搞砸不属于自己的东西更难
或许该趁机问问：你会从GitLab迁移到GitHub吗？我个人不会，但组织里有人提议迁移，感觉纯粹因为GitHub与AI工具的集成优势——可我的实际体验比GitLab更糟糕。
我们自建GitLab服务器，若有人提议迁移到GitHub，我会拼尽全力反对。GitLab在几乎所有方面都更胜一筹，尤其是CI/CD功能。
我们采用自建GitLab模式，而GitHub不支持这种部署方式。
对我来说两者都差不多烂，但GitHub有个漂亮的提交日历可以拿来向招聘官炫耀——所以在我看来GitHub胜出。
我认为GitLab每个用户个人资料页也有完全相同的功能。
在Codeberg维护代码，同步到GH。通知所有人通过CB提交贡献
搞定。
问题在于GitHub不提供关闭PR的功能。即便你用大号粗体标注“请在Codeberg而非GitHub提交PR”，人们仍会因“被忽略的PR”闹情绪，反复给你添麻烦。
可以效仿@torvalds/linux的做法，用机器人自动回复/关闭PR。说实话，对那些为PR闹事的用户置之不理或许更好。
你可以自己忽略他们，但人们会恼火，转战社交媒体，发布“这个项目无视PR”‘死项目’“他们不包容”等缺乏背景的言论，这些言论可能毫无征兆地发酵并产生实际后果。而且目标会不断转移，从“直接迁移到GitHub”变成“为什么偏要固执地拒绝GitHubPR”，然后越演越烈。
Linux内核不太可能遭遇这种情况，即便遭遇也能挺过去，但普通开源项目在声誉、贡献、使用率等方面都可能因此遭受重创——即便你只想将其视为“社交媒体的喧嚣”。保持项目环境整洁统一才是更稳妥的选择。
我认为这方案可行。GitHub正是依托开源项目崛起，开源赋予的，开源也能收回。
欣喜看到codebrg获得认可。依赖营利性企业维护数字公共资源的时代必须终结。
深有同感。上周我卡在一个bug里，明明要求ARMv8镜像，GitHub Actions却拉取ARMv7镜像。本地环境也完全无法复现。
未经维护者同意就用GitHub仓库训练Copilot，这简直是背叛——正是这种行为让许多项目转投GitLab。
任何用于训练的内容都适用同样的质疑。
不仅适用，更应当如此。
越来越多的项目迁移至Codeberg，我不禁思考：何时才能形成临界规模？还是说最终会演变成碎片化的生态系统？
天啊，我们的去中心化版本控制系统将变得……更去中心化！
说正经的，核心难题在于模块托管的三重逻辑空间导致的“占位者”问题。若需迁移项目，这将引发严重冲突。
我更希望在出现Git的真正替代者后再进行迁移——比如内置更完善项目追踪功能的平台，这样迁移会简单得多。
> 说真的，核心难题在于模块存在三个逻辑托管位置时可能出现的占位者问题
我猜专注自由软件的Codeberg会对此不悦。他们已禁止镜像服务。
> 他们已禁止镜像服务。
具体是怎样的？(我本想亲自验证但他们网站挂了…)这听起来不太开放啊。
我稍有误解。手动镜像功能仍可用，但他们移除了自动镜像外部仓库的功能。该功能原本是为简化迁移设计的，但最终消耗了过多资源。
根据其常见问题解答：
> 为何无法镜像其他代码托管网站的仓库？
> 从其他代码托管服务拉取内容的镜像对Codeberg造成困扰。随着时间推移，这类镜像消耗了海量资源(流量、磁盘空间)，因为尝试Codeberg的用户离开时不会删除这些镜像。
> 详细说明可参阅此博客文章[1]。
[1]: https://blog.codeberg.org/mirror-repos-easily-created-consum…
啊，谢谢。他们的观点很有道理！
这反而会加剧占用资源的问题，而非缓解。
> 碎片化的生态系统
这听起来像是自相矛盾。我认为更多多样性只会促进生态系统发展。
你说碎片化，我说去中心化。
我说“才不要再注册新账号来报这个bug”。Tangled正试图解决这个问题，但效果如何还得看。
这正是基于邮件方案的妙处。只需克隆、修改，再执行
git send-email，搞定。我认为围绕这个流程构建一个带邮件集成+补丁预览工具的优质GUI，远比添加activitypub简单得多，不过也罢。
> 我认为围绕这个流程构建一个带邮件集成和补丁预览工具的优质GUI会简单得多，而非添加activitypub，不过也罢。
看看Sourcehut(https://sourcehut.org/)。它采用邮件列表工作流，提交代码或错误报告相对轻松，且无需注册Sourcehut账户。
不需要完整的ActivityPub功能，只需一个统一登录入口
或许可以采用联合身份验证方案：“这里是我的域名，这里是指向身份服务器的DNS记录”，这样既不依赖单一身份服务商，又能让用户仅需单次登录即可访问所有服务器。
基于邮件的方案存在的问题远不止需要创建账户。我宁愿再创建一个账户，也不愿再碰git send-email。那简直糟透了。
https://news.ycombinator.com/item?id=33730417
我直接用GitHub账号登录了Codeberg。整个过程只需点击两下鼠标。
对Codeberg来说确实方便，但多数网站都没做到这么无缝衔接。话说设置SSH密钥时你花了多少次点击？
[已删除]
等等，Tangled VC到底由谁掌控？据我所知它在atproto上实现了真正的去中心化，几乎不依赖蓝天协议？
它不是由芬兰注册的有限责任公司支持吗？他们不是获得了风险投资公司Antler的种子前轮融资吗？
那么当GitHub尚未彻底取代它时，你在SourceForge提交过多少个错误报告？
当年我提交过不少。Sourceforge上还有多少项目在积极维护？我上次去那里是为了获取GPC(通用多边形裁剪器)库，其最后修改时间是2014年。
或许我表达得不清楚。作为开源作者，错误报告正是让开源工作变得像一份正经差事的原因。这是因为Github营造了一种理所当然的氛围：开源项目必须接收bug报告，开发者作为“维护者”理应修复问题。
不。你是遇到问题的人。你完全有能力解决问题——源代码已共享给你。现在请自己修复bug，然后按许可协议将源代码分享给用户。
注意我甚至不太在意“拉取请求”。这是Github带来的另一有害观念——认为开源项目作者必须审查变更请求并合并代码。
伙计，开源许可证并未要求你将衍生代码分享给上游。它们要求你向用户分享代码。作为原始作者，我通常并不在意，因为我编写的原始代码对我而言已足够。
当然，向上游提交修复是种礼节，也是对原作者的致谢。但这既非强制要求，也不必指望修复会被采纳或审阅。
希望分布式拉取请求的构建计划能取得进展，让GitHub之外的所有代码托管平台实现互通协作。
这将是他们能做的最棒的事，让离开GitHub成为能力提升的契机。
所有这些不同的“Git代码托管平台”都使用Git作为版本控制系统，采用相同的issue和PR工作流。根本不存在碎片化问题——除非你把不同Git网址视为“碎片化” 😉
分布式版本控制系统(DVCS)的“分布式”特性正发挥着预期作用。
在我看来，Git本身就是一款高度去中心化的工具。
我更倾向于众多代码托管平台并存，而非由单一巨头掌控的垄断局面。垄断或准垄断的危害性有目共睹。
你是大佬——就不需要GitHub来吸引粉丝和贡献者。你是小人物——GitHub带来的粉丝远比贡献者多。
GitHub的CI/CD功能也不够好。
当前的核心问题在于发现机制。若采用联合搜索引擎，具体的代码托管平台就不再是问题了。
我不明白，为何允许GitHub机器人自动修改和合并拉取请求？虽然我认同微软正用AI毁掉一切，但这个问题本可避免——只要关闭机器人的自动合并功能，或彻底禁用该功能。他们转投不知名Git服务商的行为，更像是营销噱头。
> 我不明白，为什么他们允许GitHub机器人自动修改和合并拉取请求
他们并没有这么做，是《注册报》的措辞有误。该拉取请求是被机器人因长期闲置而关闭的。
再次强调，这完全可以避免。
呃，我们讨论的是针对 safe_sleep 的拉取请求吧？不明白为何当轶事证据与你的立场相悖时，你竟摆出居高临下的态度。
> 他们转投知名度较低的 Git 服务商，听起来更像是营销噱头。
我们遭遇了 GitHub 无意解决的技术问题，且多年来对该平台积累了诸多细微不满。
从一个被商业化搞砸的平台跳到另一个平台，无异于自掘坟墓——未来注定要重蹈“被搞砸→迁移”的覆辙。
这绝非噱头。
这下说得通了，我原以为你们迁移是出于政治立场。
顺便问下，为什么不选GitLab？
你指的是哪部分？我可能漏看了文章某句，但主要似乎围绕GitHub Actions的长期漏洞和平台发展方向展开。
那…别用GHA，转投其他CI/CD/工作流平台。
试用后不喜欢就别用，GitHub本来也没强制要求使用GHA。因其发展方向而弃用GitHub，听起来更像政治运动。就像有人抵制沃尔玛不是因为商品差，而是因为它支持共和党，转而光顾有时会突然关门的本地小店——这逻辑实在站不住脚。
推动变革。为大义而战。
如今的GitHub已沦为臃肿的蠕虫软件。在Graphite中加载PR的速度至少是GitHub的2-3倍。我现在极力避免直接访问他们的界面。
这些强行植入的“AI”功能本质上就是强化版Clippy。更理想的做法是聚焦技术真正能支持的场景，采取更审慎的整合策略。
我喜欢GitHub的AI功能算少数派吗？能对任何开源代码库进行智能查询简直__太棒了__，仅这项功能就帮我节省了好几天的工作/研究时间。AI代码审查虽不值一提，但偶尔能发现我忽略的问题，对我而言净收益。实在不解为何众怒难平…诚然，满屏弹窗的“AI助手”确实令人厌烦，但至少在GitHub上它不显眼且常有实际用处。
…你完全可以克隆仓库，用自己喜欢的AI工具在本地进行代码审查。
每个应用或网页都自带AI集成，这绝对是计算机史上最愚蠢的创意之一(本该将应用与AI工具分离，通过标准化接口协同工作)。
GitHub Copilot的设计如此简洁——可选的用户体验——作为功能存在很有道理。我很喜欢它。
GitHub Actions简直糟糕透顶。
自托管运行器主机是个可怕的.NET C# Mono怪物，而所谓的“语言”不过是JavaScript封装的垃圾，在执行基本shell命令时还多此一举地创建了半吊子的领域特定语言。
界面倒是漂亮，仅此而已。
我厌恶这些无休止的炒作帖，但支持市场竞争。顶级公司提供同类服务是好事，尤其在Git领域——除了Github之外，其他平台的表现实在乏善可陈。Bitbucket确实不错，但Atlassian和Jira嘛…Github在CoPilot时代席卷前基本避免了跨产品推广，真好奇他们还能靠品牌认知力撑多久。
目睹顶级AI公司们在激烈竞争中仍竭力维系用户粘性，同时奋力保持领先(或紧追不舍)，同样令人感慨。这种局面(至少目前)主要惠及用户。倘若OpenAI独自开辟道路，如今我们连最基础的GPT都得付出天价。
> 我认为由几家顶尖公司提供相同服务是好事
“顶尖”这个词我不会用来形容微软
Zig此举的精妙之处不在于戏剧性——而在于能实时见证项目完成平台迁移的全过程。
多数开源项目嘴上说着要降低对GitHub的依赖，却因切换成本过高始终未能付诸行动。问题跟踪、PR处理、CI集成、贡献者肌肉记忆——所有环节都构成巨大阻力。Codeberg虽稳健，但网络效应尚未形成。
好奇这是否会促使其他项目至少制定应急方案。AI训练的担忧确实存在，但我怀疑更大的长期风险在于平台普遍的“垃圾化”——功能臃肿、性能衰退、强制升级销售。
如今又见Zig大用户被AI公司收购。这故事老套得像时间本身。
没错，我所有新项目都迁移到Gitlab了。
[重复内容] 源讨论链接：https://news.ycombinator.com/item?id=46064571
Zig采用MIT许可证发布。微软完全有权从Codeberg克隆Git仓库，并对源代码进行任意操作——包括将其输入AI算法。迁移到Codeberg并不能真正解决这个问题。我理解有人希望限制他人对源代码的使用(包括用于资本主义目的或AI/机器学习)。但众多开源许可证(尤其是MIT许可证)的核心宗旨恰恰相反：允许人们自由处置源代码。
Zig对AI应用的态度在我看来有些特立独行，这种观点并不普遍。不过他们坚持己见也无可厚非。
Codeberg平台倒是让我颇感兴趣。直到几天前我才听说这个平台，它似乎正在我居住的柏林发展。虽然我不打算将其用于商业项目，但开源项目应该没问题。不过我对它的融资模式存疑——长期依赖捐赠运营，对严肃项目可能存在隐患。迁移开源社区本身会造成一定破坏性，而且很可能排除商业用途。
个人认为，那种“GitHub邪恶反资本主义”的立场有些站不住脚。我支持市场多元化与更多参与者，这本是好事。但许多替代平台同样是营利公司，这或许正是人们对GitLab等平台产生幻灭的原因。Codeberg的架构似乎更具抗风险性。
除此之外，GitHub仍具价值。我正从盈利性AI公司那里获得巨大收益——它们提供的服务显然是基于GitHub存储的代码库训练而成。我甚至为此付费。这种可能性本身就很酷。
> Zig采用MIT许可证发布。微软完全有权克隆Codeberg的Git仓库并自由处置源代码，包括将其输入AI算法。
MIT许可证要求署名，而据我所知AI算法无法提供署名。因此要么(a)这是合理使用，微软可无视许可证自由操作；要么(b)微软无权这么做。无论如何，这确实不是Zig团队对GitHub的争议焦点。
> Zig采用MIT许可证发布。微软完全有权从Codeberg克隆其Git仓库，并对源代码进行任意操作，包括将其输入AI算法。迁移至Codeberg并不能真正解决问题。我理解有人希望限制他人对源代码的使用(包括用于资本主义目的或AI/机器学习)。但众多开源许可证(尤其是MIT许可证)的核心宗旨恰恰相反：允许人们自由处置源代码。
微软用Zig训练AI并非他们的核心诉求。他们指责GitHub服务质量恶化，因为微软不再专注基础建设，只顾追逐AI梦想，而让AI代写代码的尝试正产生恶果。
更准确地说应是投资不足。早在人工智能热潮之前，平台就存在大量简单而明显的缺陷，例如这个自2021年就存在的恼人漏洞：https://github.com/orgs/community/discussions/6874
这个改动几乎只需一行代码(严格来说YAML文件需要额外添加一个标记，但这并不复杂)：https://github.com/orgs/community/discussions/12882#discussi…
话虽如此，我依然认为Github表现良好，免费CI服务无可挑剔——尤其在Windows/Mac平台。若其终止免费服务，我定会考虑转投Codeberg。或者当Codeberg支持堆叠式PR(即PR间的依赖关系)时，我立刻加入！Github竟不支持如此基础的工作流，实在令人沮丧。
不投入维护资金是错误的。
既不投入维护资金，又把大量资金砸在多数人不需要的功能上，更是糟糕透顶。这分明在说：我们有钱，但根本不在乎。
AI失败的铁证就是这些用户苦苦哀求微软修复的低难度维护问题，AI代理却始终无动于衷。AI不是号称能替代十倍工程师吗？既然有这么多AI帮手，为什么GitHub没变好？
这不就是微软一贯的标准操作吗？堆满伤人的小毛病，加上堆满没人要的功能？
我认为这是微软内部“追逐积分”机制的必然结果。
依我看，蝎子已过半河，你们即将沦为那只青蛙。十五年来我没碰过Windows设备，真想把这纪录保持到坟墓里。Gaben正努力成为我新宠的科技人物——他正拼命把游戏从PC平台掰走。真心希望他成功。
> GitHub居然不支持这么基础的工作流，简直令人抓狂。
其实它支持。
我在多个岗位都用过这种方法提前处理关联工单：只需在现有分支基础上创建新分支(即向另一个PR分支提交PR)。
人们可以在父PR合并前审查子PR。虽然需要掌握一些非基础的Git知识才能高效管理，但绝非高深技术。任何基于Git的分层PR方案都需具备此能力(或定制工具)。
我认为这次我站在他们那边。从Git角度看，这完全符合预期。其他需求或许更适合交由JIRA或项目管理工具解决。
这似乎与我理解的嵌套PR机制相反？比如有人先提交功能PR#1，再提交PR#2到PR#1分支——但若不了解PR#1上下文就无法理解PR#2，因此需先审核PR#1。待PR#1合并后，GitHub会自动关闭PR#2？
PR#1：面团
PR#2：配料
你先提交PR#1，再基于PR#1提交PR#2。
PR#1的差异显示面团相关改动，PR#2的差异则显示配料相对于面团的改动。
审核人员可异步审查。若合并PR#1，PR#2将自动指向主分支(面团已合并的位置)。
在此流程中，我习惯通过PR编号交叉引用(双方均存在链接)。通常将第二个PR保留为草稿状态，但具体取决于团队惯例。
我不理解为何要在PR#1合并后关闭PR#2。正确分支操作下，依赖关系应自动解除——这正是预期行为。
> PR#2的差异对比将按面团关系展示配料。
问题在于PR#2的差异对比会将面团和配料混杂显示。除非切换到提交视图，但操作极其繁琐且容易丢失评论。
这令人沮丧，因为实现该功能所需的工作量微乎其微。实际只需让Github像识别
修复#123那样识别依赖#1，然后：a) 以#1的HEAD作为#2的差异基准；b) 在#1合并前阻止#2合并。这其实并不复杂，但我不会抱太大期望。
“混合在一起”指什么？
PR#2只会显示面团和配料之间的变更。
若合并后，它将并入PR#1。你把依赖关系变成了单一整体。
因此若不想混合，应先将依赖项(面团)合并到主分支(或其他目标分支)。
Codeberg应该也支持相同机制，这是Git特性而非GitHub专属。正因如此我才说它完全符合预期——Git本身就支持依赖关系，GitHub只是遵循规范。
若要阻止合并，可创建将含依赖PR转为草稿的工作流。但既然是PR间合并操作，我看不出这样做的必要性。若需撤销合并，操作起来很简单。
从表面看，你似乎在错误节点创建分支，并向主分支提交了两个PR——其中一个包含重复内容。这并非我建议的做法。
这篇文章简直难读得要命，一边全是广告，每隔一句就塞个链接。我甚至搞不清Zig跑哪儿去了…有人能写个简短版吗？
编辑：翻评论看到个叫Codeberg的东西，但为什么我连不上去？
再编辑：哦原来Codeberg挂了。我不得不翻首页别的帖子才发现这事…
听说GitHub现在所有人要么搞AI，要么负责让GitHub完全迁移到Azure上。
说真的，没有持续的AI噱头，数字怎么可能增长？难道没人考虑股东利益吗！
微软尤其_真的_像是在罗科巨蜥祭坛上献祭自己；他们似乎完全丧失了做_任何_非AI相关事情的能力。
今日另一则消息：Zig语言最大项目之一Bun加入了Claude Code背后的公司Anthropic，并对AI赞不绝口。若Zig对AI态度日益敌视，我猜想双方可能产生“摩擦”。
Zig为何在意用其语言编写的项目被用于AI？
编程语言通常需要杀手级项目来推广，而非仅供语言极客把玩，Bun正是此类项目。
Bun至今仍在运行，tigerbeetle也是。
收购之后能维持多久，且看吧。
就算真有摩擦，他们又能怎样？
鉴于Bun大量使用Zig语言，预计他们会在Zig论坛相当活跃，持续提交补丁和功能请求。
我设想的情景是：Bun向Zig项目提交AI生成的补丁，或为AI特定用例提出功能需求…若Zig基金会持续拒绝这些贡献/请求/讨论，恐将导致双方关系恶化。
另可参考用户从Windows转向Linux的现象。
微软需要专注于满足用户需求，而非强行灌输未经请求的功能，指望用户被迫接受。
微软需要有人能在问题初现时就严厉制止相关行为。
确保基础安全、易用且可靠的操作系统应是首要任务。
强行推销用户根本不需要的服务只会滋生怨恨，不仅针对被强迫者，更波及所有知情者。
若W11的宣传是“嘿，我们做了些优化，修复了些漏洞，对了！若您有TPM2.0芯片，我们还能帮您加固设备安全！”，抗拒情绪会小得多。
其他功能亦然：征询用户意见，说明益处，若用户拒绝就别再纠缠。而不是“默认开启功能，再让用户费劲寻找关闭方式”，更别像当前Teams的Copilot功能那样，每隔几天就弹窗询问，唯一选项竟是“稍后提醒我”。
或许我跟不上潮流，但大家对AI的“痴迷”究竟毁了什么？GitHub对我来说依然如常运作。其他人怎么用GitHub的？
等等，我以为他们离开是因为GitHub软件工程师都是“猴子”。
小众语言搞出点动静，挺有意思
现在可不止是小众语言了。
Bun是用Zig开发的，他们刚被Anthropic收购。
Ghostty是另一款值得关注的Zig开发软件。
我猜Bun的收购案是最近Zig新闻爆棚的主因。首页就有四篇关于Zig的文章。
在GH上没注意到任何AI问题或困扰。
上周搬家的理由是“坏人用微软工具”，今天AI成了新替罪羊。借用名言：“要么做要么不做，反正我还有事要忙”。
原帖重点在于技术层面的不满，“坏人使用微软工具”只是顺带提及。
https://ziglang.org/news/migrating-from-github-to-codeberg/
> 暂且不论GitHub与ICE的关系
仅此而已。六个字。
此外，本文是独立投稿， 非出自Zig ，旨在报道原始事件并补充背景信息。
> 借用一句名言：“要么做，要么不做，反正我还有事要忙”。
你究竟在抱怨什么？Zig最初发文时搬迁已完成。他们确实这么做了。
两篇帖子并无矛盾。你不满的本质或可能受影响之处，完全无法看清。
记得在播客里看到过某AI工具的广告，号称能用AI技术反制诈骗。
我们确实到了这样一个境地：AI既是问题根源，又是解决问题的方案。
> 我还有事要忙
比如在Hacker News刷帖发帖？
别评判：我们也在这里。
我坦白说没地方可去
我喜欢AI带来的改变。能通过UI修改文件，还能自动填充提交信息。太棒了。
我超爱这些沸腾的评论——因为某个经营优秀项目的聪明人做了事，惹恼了几个隐形的GitHub员工，尽管这事根本不影响他们。各位，你们根本不用Zig啊。各位，你们也不必认同安德鲁的观点啊。
说实话挺幼稚的。我不会因为不认同公交司机的政治立场就拒绝乘车。
为什么每个HN讨论帖都像是在刻薄地吐槽《热门科幻系列》最新续作？
GitHub很棒。它几乎毫无变化，却依然让这群原教旨主义者难以接受。