Zig 从 GitHub 迁移至 Codeberg

在GitHub CEO发出“拥抱AI或滚蛋”的宣言后，微软的走狗们似乎领会了暗示——GitHub Actions开始实施“随机调度”，看似随意选择任务运行。

 💬 888 条评论 |  github/zig/Codeberg | 

https://codeberg.org/ziglang/zig

自十年前执行git init命令以来，Zig始终托管于GitHub平台。遗憾的是，当它被微软收购后，倒计时就此开始。我暗自祈祷：“求求你，至少再给我五年时间，别让一切都完蛋。”而如今七年过去，我们仍在借来的时光里苟延残喘。

暂且不论GitHub与ICE的关联，显而易见的是：当年成就其辉煌的卓越工程精神已然消逝。优先级与工程文化已然腐朽，用户被迫承受着以“进步”之名强加的臃肿漏洞百出的JavaScript框架。曾经敏捷的系统如今迟滞不堪，甚至彻底崩溃。

最关键的是，Actions功能存在不可原谅的漏洞，却遭到彻底忽视。在GitHub CEO发出“拥抱AI或滚蛋”的宣言后，微软的走狗们似乎领会了暗示——GitHub Actions开始实施“随机调度”，看似随意选择任务运行。加之其他漏洞及无法人工干预，导致我们的CI系统严重积压，连主分支提交都无法检查。

元素周期表

与其浪费捐款资金购买更多CI硬件来修补这套崩溃的基础设施，我们选择直接更换Git托管服务商。

额外好处是，我们期待违规行为减少(参见A、B、 C)的违规行为减少。我认为这些违规至少部分源于GitHub强力推广“向Copilot提交问题”功能所致。## 严格禁止LLM/AI政策 strict-no-llm-no-ai-policy)的违规行为显著减少，我认为这至少部分归因于GitHub强力向用户推送“通过Copilot提交问题”功能。

GitHub赞助商

我们离开GitHub唯一的顾虑在于赞助商计划。该产品是Zig早期融资成功的关键，至今仍是我们收入的重要来源。我永远感激Devon Zuegel。她犹如天降天使，单枪匹马将GitHub打造成数千名开发者的可靠收入来源。在其领导下，GitHub赞助功能曾前景光明，但遗憾的是她同样转战更广阔的天地。自她离任后，该产品便遭冷落，如今已显颓势。

尽管GitHub赞助计划占Zig软件基金会捐赠收入的很大一部分，但 我们认为它已成为负担 。恳请正在通过GitHub赞助计划捐赠的读者考虑将定期捐款转至Every.org——该平台本身就是非营利组织。

为此，我们将逐步取消GitHub赞助商特权。这些特权包括根据月捐金额在主页展示捐赠者姓名、在版本说明中署名等。我们正与Every.org团队合作，计划通过该平台提供同等价值的特权。

迁移计划

即日起，我已将GitHub上的ziglang/zig仓库设为只读，Zig主项目仓库的权威origin/master分支现为https://codeberg.org/ziglang/zig.git。

感谢Forgejo贡献者协助我们解决迁移平台过程中遇到的问题，也感谢Codeberg团队成员参与迁移工作——特别是Earl Warren、 Otto、Gusted和Mathieu Fenniak。

最终我们采取了简洁策略，巧妙规避了GitHub的强力供应商锁定：保留现有问题保持开放且不迁移，但在Codeberg上从30000号开始计数，确保所有问题编号保持唯一性。请将GitHub上保留的开放问题视为“写时复制”的隐喻。 请勿触碰现有GitHub问题与拉取请求 。除非需要编辑、添加评论或重新基准，否则无需迁移至Codeberg。 我们仍会处理已存在的拉取请求与问题 ，敬请放心。

在这个并购频发、反垄断法规薄弱、平台资本主义导致财富极度集中的时代，非营利组织依然是守护公共资源最后堡垒的坚守者。

祝编程愉快，

安德鲁

本文文字及图片出自 Migrating from GitHub to Codeberg

共有 888 条讨论

    1. 我关于编程与软件工程差异的旧规则：

        编码时，“对我来说似乎能用”就足够了。软件工程中则不然。

      我的新法则：

        编码时，你可以用AI写代码。软件工程中则不行。
      回复

      1. > 编码时，你可以用AI写代码。软件工程中则不行。

        软件工程领域完全可以使用AI，但不能仅依赖AI——你必须全程深度参与，及时检查并引导其方向。

        AI确实降低了编码门槛，但这也意味着缺乏严谨性的人会涌入该领域，造成巨大破坏。不过这与编程语言相较汇编语言提升可访问性并无本质区别——我确信这同样让更多人具备了造成破坏的能力。

        你可以使用任何工具，但无论工具如何都必须保持严谨。

        回复

      2. > 编码时可使用AI编写代码，软件工程中则不可。

        这种观点相当普遍。我认为其将AI应用等同于“氛围编程”——即让AI在无人审核的情况下编写代码。我建议将规则修改为：

        > 编写代码时可使用AI，但软件工程不可依赖AI。

        在符合软件工程规范的流程中，AI可发挥作用。通过精心设计提示词生成初稿，经人工审核并按需修改后提交。若AI生成的代码架构欠佳或存在冗余，人类开发者可借助相同AI进行重构优化。

        有人会质疑这会削弱效率提升。确实会削弱部分效率，但关键在于最终产出可与人工编写的软件(尽管质量参差)相媲美。

        回复

        1. 完全赞同。

          但若主要依赖Cursor默认模型这类工具，就别指望能经常得到优质代码。

          你付出的代价决定了你得到的结果。

          回复

      3. 我完全不在乎人们如何生成代码，但他们必须对提交审核或合并的每一行代码负责。

        这是我在每个客户项目中的原则，且行之有效。若AI能让工作更简单/高效，对作者是好事，但绝不允许提交未经彻底自审自测的粗制滥造代码——零容忍，毫无例外。

        若有人妄想通过AI不仅替代编写/修改代码，更逃避代码对整体代码库及底层业务问题的影响责任，他们理应立即失业——这实质上是将全部工作职责外包给机器，不仅毫无价值，实则造成负面影响。

        回复

        1. 完全赞同。对我而言，难点在于区分初级工程师的问题…这是AI导致的考虑不周、效率低下且冗长三倍的解决方案，还是经验不足所致？

          回复

          1. 并非为他辩护，但我们早就在电子应用、框架、库和脚本语言中这么做了。软件开发中唯一有意义的成本是人力，优化它才合乎逻辑。我当然希望获得优质软件，但比起解决问题价值远低于成本的精品软件，我宁可免费使用粗制滥造的软件。

            这类讨论永远只谈战术，从不涉及运营本质。

            回复

            1. > 我宁可要免费但粗制滥造的软件

              若需我来维护，那可不行。

              代码是负债。大型语言模型生成的PR往往带来净负面价值：它们使系统膨胀、脆弱且整合度下降，代价是牺牲终端用户体验和维护效率。

              回复

              1. 那些每小时成本高于编码代理月费的人工编写软件难道不是同样道理？开发者被要求交付企业级软件时容忍缺陷，而若在设计水处理厂或桥梁时犯下同等错误，你早就被告上法庭了。

                我理解程序员视角下“AI很烂”的论调。它看起来怪异，既不顾及“代码异味”，也不按你喜欢的模式重排代码库的甲板椅。但从所有者或客户角度看，人类程序员才更糟糕。想要标准化的CRUD应用？就像婴儿初学Django做的应用？不知为何总要耗上半年。他们不懂你的业务领域，也不愿花心力学习。整点工作15分钟，剩下45分钟刷社交或打游戏，却按200美元/小时收费。还搞什么“结对编程”提升“质量”，让同款产品收费翻倍。他们甚至会把实习生在您项目里学习工作的费用也算进账单。更糟的是，整个项目最终失败的概率依然极高。而我只需每月支付Anthropic 20美元，在手机上用5分钟碎片时间向AI发送需求。若效果不佳，直接创建新模型重试即可。即便AI发展今日停滞，程序使用者已享受到前所未有的便利。开发者或许例外——除非你正在编写AI并赚取百万级收入。祝贺他们。我乐见那些按小时收费200美元的Stack Overflow复制粘贴者另谋出路。

                回复

                1. > 人类编写的软件难道不也存在类似情况吗？某些程序的每小时成本甚至超过编码助手的月费。

                  区别在于人类具备学习成长的能力。

                  从你的例子来看，我们讨论的似乎是完全不同的代码应用场景。作为软件工程师，我回应的是最初讨论的主题——审查充斥着大型语言模型垃圾代码的PR。而你似乎是位业余爱好者，用LLM随性编写个人应用。坦白说，你的用例恰恰是LLM应有的场景——就像用消费级3D打印机给孩子做玩具无可厚非，但没人愿意为用同样方式打印的全尺寸结构系统承担维护责任。

                  回复

                  1. 但这个比喻里，另有人设计了设备(或系列设备)，用3D打印机生产后在线销售，以此维持生计。

                    回复

            2. 我理解，但我认为对此表示认可(不仅限于软件领域)本质上带有反人性色彩。这类似于无人监督时的行为准则——当人们以工作为荣时，整个文化与社会才会更美好。

              当然存在复杂性(若被迫选择，我宁可让饥民吃劣质食物，也不愿让少数人享用健康餐食)，但若纵容劣质品泛滥，社会中的扭曲激励机制便会逐渐占据上风。持续追逐劣质品的底线，将使除富人之外的所有人丧失获得高品质产品的可能。

              换言之：若社会立法禁止劣质食品生产，贫富阶层皆能轻松获得健康食品。成本将由富人承担——因其从食品生产中获利，维持高品质反而会削减其利润。

              回复

              1. 我敢肯定苏联、古巴之流从未成功推行过这类政策，但或许我们再用同一把锤子(和镰刀)敲自己脑袋一次就能奏效？

                回复

                1. 资本主义西方似乎乐于购买廉价垃圾食品…几乎无人再追求品质。

                  回复

                  1. 质量已不再是选择项，因为昂贵不再代表品质，而是代表“看起来昂贵的垃圾”。

                    既然都是垃圾，何必多花钱？

                    回复

                    1. 完全正确。在存在公认优质选择的领域，人们显然愿意支付更高价格。丰田便是典型例证。

                      不过汽车属于高价大宗商品，可选范围相对有限…多数消费品根本无法预判品质。

                2. 实现这种目标不需要共产主义。需要的是精英阶层心系民众的强大文化。精英们自愿为民众创造财富。

                  而我们当前的寄生精英阶层只顾自我肥沃。当统治阶级憎恶平民时，争论经济体系毫无意义。

                  回复

          2. 这重要吗？无论哪种情况都只会让初级员工颜面尽失，他们亟需提升自我评估能力和专业素养。

            回复

            1. 做新人不易，我们或许存在幸存者偏差，但多数新人最终都未能进入成熟的工程团队——他们不过是成本更低、要求更少的开发者，往往处于自学自修的边缘状态。他们亟需遇见愿意培养他们的资深成员，而非仅被分配低质量工作(我承认自己曾因交付压力过大而犯过同样错误)。

              即使在压力较小的团队中，随着AI提升工作效率(我的团队确实受益，即便我不直接用它编写代码，它在浏览代码库和梳理逻辑时的巨大帮助也节省了我大量时间…)，代码审查的压力也在同步增加，随之而来的还有疲惫感。

              回复

            2. 这确实重要，因为深入审阅、理解并为团队初级工程师的工作提供反馈，是我值得投入时间的事。这样才能让人类学习成长。

              但用同样方式“指导”大型语言模型(LLM)的垃圾代码，则不值得我耗费时间。

              初级工程师的经典难题在于：帮助他们交付成果往往比自己完成更耗时。但为人类付出这份额外努力，我甘之如饴。

              回复

      4. 我认为这种区别本质上等同于：

            LLM会犯错。人类不会。

        人类不仅会犯错，而且时刻都在犯错。LLM能自动化处理大部分枯燥工作，包括实现100%覆盖率的单元测试。它们能覆盖你要求的边界案例，甚至能提出你未曾想到的边界情况。这让你得以专注于代码审查。

        我认为人们的根本问题在于：他们不信任自己审查他人代码的能力，却过度自信能从零实现代码。现实中，真正达到NASA/航天级“工程”水准的开发者寥寥无几。多数人不过是自我膨胀罢了。

        我认为完全可以将问题建模化，定义组件、接口、API、数据结构和算法，再让LLM填充具体实现与测试。精心设计的接口本就易于测试，重要用例的覆盖情况更是一目了然。它可能出错，但我也会犯错。代码审查时难免疏漏，但团队协作中同样如此。个人更倾向于大幅提升架构设计与代码审查效率，而非自鸣得意地手工编写每个循环和分支——仿佛这样就能让结果更安全或更高效(特殊情况除外，因人而异)。

        回复

        1. "我觉得这些区别相当于

              大型语言模型会犯错，人类不会。"

          不，重点不在此。人类与AI的本质差异在于：AI犯错时毫无羞耻感，而热衷使用AI的人类似乎也毫无顾忌。多数人发布粗糙代码后，一旦错误暴露便会立即受到强烈震慑。AI则完全不同——它不会像人类那样即时从错误中学习。

          若遇到像AI那样持续固执地犯错的人类，项目组尚能识别并及时终止与其合作。但当大批人被高调的AI吹捧者灌输“AI多么神奇”的观念时，项目就极易被AI生成的错误PR淹没。

          回复

        2. 若单元测试对你而言是枯燥差事，或100%覆盖率本身成为目标，说明你对优质软件开发的认知存在根本性缺陷。测试即是规范：它定义行为、设定边界，并控制复杂性不可避免的增长。优质测试是维持优秀开发者理智的基石。若不以测试为起点，便无法构建优质软件。因此测试令你厌烦，症结在于你的工程思维。成熟开发者不会因追求100%覆盖率而倦怠——他们专注于真正描述程序运行逻辑的有意义测试。

          回复

          1. 测试即是规范：它们定义行为、设定边界，并控制复杂性不可避免的增长。

            我在设计阶段通过选择职责、接口和命名来设定边界。“红绿重构”对初学者尤为重要，否则他们定义的边界将难以测试和维护。

            我设计的小而精的组件，其API简单明了，单元测试极易定义和实现(通常采用参数化设计)。单元测试并非让我“保持理智”，而是让我夜间安眠——因为设计过程不会令我抓狂。它们不定义“程序”的运作方式，只定义单元应如何运作。单元越小，测试越简单。希望你认同：简单胜于复杂。不，我绝不认同“只需集成测试”的观点。

            否则，你成功地夹带了一连串人身攻击：我对优质软件的理解存在缺陷，我的问题在于工程方法论，而且我还是个不成熟的开发者。这一切都源于我那句“LLM能自动化处理大部分枯燥工作，包括实现100%覆盖率的单元测试”。因为你无法理解有人如何在没有TDD的情况下设计优质软件，更无法认真对待我的观点(尽管指南[1]明确建议这样做)。我确实会审查并修正LLM生成的内容，几乎每次都会要求它实现特定测试用例。我更乐见基础测试用例和边界情况得到全面覆盖。不，我确实不喜欢编写工厂类、初始化代码和断言逻辑，但乐于审核这些内容。

            [1] https://news.ycombinator.com/newsguidelines.html 请针对他人言论中最具说服力的解释作出回应，而非选择更容易批判的弱化版本。请秉持善意假设。

            回复

        3. > 大型语言模型能自动化处理多数枯燥工作，包括实现100%覆盖率的单元测试。它们既能覆盖你要求的边界案例，甚至能提出你未曾想到的测试场景。这让你得以专注于代码审查。

          据我经验，这类测试根本无法检验任何有价值的内容

          即便实现100%测试覆盖率，也几乎毫无意义——它们根本不检验系统实际应有的行为

          而仅仅验证具体实现细节

          回复

          1. 100%测试覆盖率这个 指标 远不止“毫无价值”，通常更是极具危害性。

            脆弱而无意义的测试往往固化错误决策，阻碍实质性重构。

            劣质测试本身就是技术债务，会大幅增加未来重构与适配的成本。

            回复

      1. 这种情况并不罕见。Lemmy项目曾拥有数千颗星标，却长期缺乏可用代码，直到最终由非所有者接手并合并出实用版本。

        回复

      2. 天啊，访问其个人资料里列出的网站时，不仅几乎所有链接失效，唯一能打开的链接竟直接跳转到原始模板页面——完全是照搬照抄。天啊。

        回复

      3. 他们是否尝试过其中任何一项都值得怀疑。

        回复

      4. 忙忙碌碌。我厌恶的不是这个人，而是助长或要求这种行为的体系。

        回复

        1. 当被质问LLM编写的测试完全失效时，那家伙说了句最搞笑的话：“它知道自己在做什么，但总爱…偷懒。”

          我虽是LLM的拥趸，但这家伙简直荒谬。他对生成代码毫无理解，却总说“LLM知道”。

          他根本不可能说服任何人合并他的PR，因为他连LLM生成的测试是否正确都不检查。简直是笑话。

          回复

              1. 没错，要么这家伙彻底疯了，要么就是某个AI怀疑论者故意用愚蠢的PR淹没项目，以此警示风险并引发人们对开源领域使用AI的质疑(戴上我的疯人帽)

                回复

                1. 这观点真有意思。开源项目在AI出现前就被愚蠢PR淹没了，这又能证明什么？

                  回复

              2. 无论有意无意，这都是个有趣的社会实验。

                回复

            2. 这分明是骗子在行骗。前几天/g/版就有人发帖讨论此人，匿名网友挖出他多领域失败/诈骗的过往，遇到麻烦就卷款逃跑

              回复

              1. 我敢打赌在大型语言模型出现前，他们全在加密货币领域混得不错

                回复

                1. 在查看他在这儿(HN)的历史记录时，发现他最初涉足的是扑克领域。我不确定他是否亲自打牌，但确实写过扑克引擎之类的东西。根据我的经验，职业扑克玩家、加密货币爱好者和骗子这三类人群的维恩图存在大量重叠。

                  但此人加密货币时代几乎销声匿迹，直到近期人工智能话题热潮才重返HN活跃。

                  回复
        2.   function estimate_method_targets(func_name::Symbol, types::Tuple)
      # 保守估计
      # 实际实现中需查询方法表
      return 2  # 假设存在多种可能性
  end

          太搞笑了。这模型该不会是用XKCD[0]训练的吧？

          [0]: https://xkcd.com/221/

          回复

        3. 顺带一提，他最初将该帖命名为“Julia静态二进制构建完整指南(1.12版更新)”，完全未提及AI。每次打开Discourse论坛看到这个标题我都兴奋不已，直到想起这不过是篇垃圾帖。:/

          回复

          1. OCaml论坛也有类似情况。他发过篇题为《沙丘：并发构建时代来临！》的帖子，实则是篇+967票-100票的烂PR，最终被迫关闭

            回复

      2. 或许此人就是：全球最差程序员

        回复

        1. 这不正是《独行者》主角的起源故事嘛…

          其实我不该公开说这话。这可能催生另外3-5部程序员异世界题材的动漫。

          回复

        2. 在这个超大规模语言模型时代，我只敢问自己：这人到底是真人还是某种“智能系统”的实例？

          回复

        3. 虽然很多人批评这家伙，但我们都受益于这个反面教材——请大家千万别学他。请务必阅读生成的代码，理解它，修改它，再提交。

          若有人被问及“为何PR如此操作”时回答“不知道，AI做的我没质疑”，那他们该被停职了。

          回复

      3. 如今软件界怕是诞生了“游击队建筑商”的对应版本。不过这次根本没人委托建造啊哈哈。

        回复

      4. 琼斯镇集体喝的酷爱饮料都比这少。

        真不知该担忧还是佩服。

        回复

      5. 我手握1000美元克劳德积分，直接开干。

        没错，过程中确实犯过错。

        回复

        1. 最大的错误——无论是否涉及AI——是提交超1万行的PR。除非进行自动化重构(比如格式化整个StaticCompiler.jl源代码)，否则PR规模应控制在300~500行代码。这本该拆成独立PR，最好由维护者提交。

          回复

          1. 我在其他地方也见过类似情况。

            瓶颈不在编码或创建PR，而在于代码审查环节。

            回复

            1. 这本该通过AI实现自动化。

              它可先判断PR是否无意义，再尝试审查，必要时再标记人工介入。

              问题在于GitHub等系统应主动防止项目因PR审核遭受DDOS攻击——毕竟AI应用需要真金白银。

              回复

              1. > 这本该用AI自动化处理。

                当全世界都在告诉你该他妈停手时，或许该停下来听听。

                回复

                1. 这番说辞活脱脱像顾问在提供架构建议。问题在于，如今用大型语言模型搞任何事、搞大规模操作都成了 社会可接受行为 。过去人们努力践行自身标准，珍视真实价值。如今我们似乎都在追逐传统软件工程的圣杯：平庸。

                  回复

                  1. 这种行为绝非社会认可，而诸如你这样轻描淡写宣称其正当性的人实在令人厌倦。或许在你特定的社交圈里，对作品毫无敬意、将粗制滥造的垃圾抛给他人却要求对方毫无质疑地接受——这种态度确实被容忍？但对我们其他人而言绝非如此。

                    回复

                    1. 或许我之前没说清楚。那是我在HN上的亲身经历：有人被问及是否用AI写代码，对方回答“既然比我写得好，为什么不用”。如果这就是人们给出的理由，且他们毫无自知之明到不觉得羞耻，说明持这种想法的人恐怕不在少数。

              2. 我真心建议你亲自尝试一下。

                成熟项目往往抗拒将项目YOLO化，也不愿完全交由大型语言模型自动驾驶。

                你提议的是一种截然不同的开发模式。

                不妨将Ocaml分叉为Oca-LLM，将Julia分叉为Jul-AI，看看效果如何。

                回复

                1. 我并非主张当前项目就该如此运作。

                  但我确信这是未来的发展方向。

                  现有开源项目尚未准备好迎接变革，或许永远都不会。

                  变革将始于企业领域，或许已经开始了。

                  回复

                  1. > 这本该通过AI实现自动化。…

                    > 我并非主张现有项目当下就该如此运作。

                    到底是哪种情况？

                    回复

                    1. 两者皆是，但重点在于未来。

        2. 别告诉我你真花了1000美元生成虚假测试…

          回复

        3. 你这个账号存在至今已有十年，竟搞出这种事，实在令人震惊。

          作为恶搞行为，这确实堪称杰作。佩服佩服

          回复

        4. 你用自己都不屑一读的胡言乱语浪费了别人的时间和精力。今后请多些体谅。

          回复

        5. 这绝非“犯错”那么简单。如此恶劣的行径令人难以置信——你自称拥有三十年软件开发经验，却始终不明白提交这类PR是完全不可接受的。

          那句轻描淡写的“欢迎质疑”和“只是概念验证”简直令人发指。PR不是闲聊工具，更不是推销个人观点的舞台。这种自我陶醉的行径简直荒谬至极。

          你的个人主页反复强调求职意向，渴望被雇佣。我实在无法想象，任何人看过这些PR或讨论中的表现后，会认为你是团队的合适人选。

          这种无知程度令人瞠目结舌。

          情况糟糕到让我怀疑你是否真是人类——抑或是某人秘密进行的不诚实LLM实验。

          回复

      1. > 说真的，我几乎凭一己之力把Zig赶出了Github

        仔细想想，乔尔对Zig及其社区可是净贡献者！

        回复

      2. 这些超大语言模型过度热情的回应，真会把人自尊心搞垮。

        回复

        1. 人们早就对超大语言模型发疯了哈哈

          回复

        1. 更准确的说法应该是“前沿恶搞”。

          回复

      2. 我更进一步：现在我基本确定这是个真心讨厌LLM的人，正试图通过给别人找理由来毒害LLM的声誉。

        回复

        1. 真羡慕你的乐观。事实是人类普遍比你想象的更愚蠢更卑劣。

          回复

      3. 难道AI泡沫就是一群生物学家在扮演他们最爱的反乌托邦科幻剧？

        回复

    6. >重大突破达成

      拍马屁的行为对追随者而言简直像海洛因上瘾。天啊

      >我没写过一行代码，但花了几天精心引导AI，确保它循规蹈矩。

      >AI：我得追踪寄存器间的变量流动。太难了，咱们去逛街吧…我：嘿！不许偷懒！

      >我的工作就是指挥、塑形、哄骗和复核。

      这些人怎么能说得如此理直气壮，丝毫没反思自己是对是错，还是纯属胡扯？

      回复

    7. 啊，记得那家伙。乔尔。他早年卖掉扑克服务器后就在HN吹嘘。最近更成了公关炒作狂。可惜AI终究无法让人变得善良。人们利用AI欺凌他人的行径简直疯狂。赞赏OCaml团队给他那个恰到好处的“滚蛋”式礼貌回应。

      回复

    8. 确实是个有趣的巧合。但它想提交的改动呢？至少有点意思。更妙的是修改第638行既没破坏也没修复任何测试。

      回复

      1. 推特上有张Claude截图提供了更多上下文(PR里有链接)。

        我对这个项目了解不够，无法判断它是否有意义，但Zig贡献者似乎有些困惑(至少对标题感到困惑)。

        回复

      2. 或许在该场景下偏移量本就始终为零

        不过确实难以断言

        回复

        1. 这是我为Zig编译器定制的模式中的缺陷，并非原生编译器本身的问题。

          回复

      2. 光看他的博客就够恶心的了。他不仅自认在积极贡献，还觉得自己值得嘉奖。

        回复

        1. 提醒一下，你回复的对象正是讨论中的Joel本人。他在HN上使用wagerlab这个用户名。

          回复

          1. 没错，就是我！

            我会考虑改名，不过不确定HN是否允许。

            回复

            1. 不妨尝试邮件联系，他们之前改过其他账号名。

              回复

      3. 即便被公开指责后，你仍在PR里明目张胆地为博客和AI打广告；除了广告别无他词。这就是我已在OCaml论坛屏蔽你的原因。

        小时候每年圣诞节，我都会对玩具产生 病态痴迷 ，过度期待会让我头晕反胃。我真心觉得你正经历成人版这种状态：身体或许没事，但满脑子充斥着炒作，已丧失自我认知。

        回复

          1. 我认为他本性不坏——毕竟在OCaml论坛看到他发帖已有数月，直到最近才出现这种行为模式。但他突然变得非理性且愈演愈烈。这种事实在难以委婉表达，况且他已删除了最激烈的言论，你们也无法完整了解全貌。

            这并非我首次在HN之外与他交涉——当OCaml社区出现端倪时，我已私下与他沟通。后来我放弃了，向版主举报他的广告并屏蔽了他数月，但他的闹剧仍在GitHub和HN不断重演。

            回复

            1. 我也一直在关注。尽管我不同意他的观点，但欣赏他敢于提出这种“孤注一掷”的态度。不过某些近乎人肉搜索的愤怒情绪确实令人担忧。希望这个社区能展现更成熟的处事方式。

              回复

              1. 我觉得你对“曝光”的理解可能有误，不过无所谓了。我原本期待他能做得更好，而不是到处刷广告，浪费多个社区维护者和版主的精力，还对要求他收敛的人冷嘲热讽。

                回复

                1. 在我看来这已经接近曝光的边界(没去/g/板块确认，或许那才是真正的曝光)：

                  > 前几天/g/版有帖子讨论这家伙，匿名用户挖出了他大量过往记录

                  回复

          2. 善意意味着尊重并倾听对方(本例中是多年参与这些项目的多人团队)。他展现的态度始终如一(此为他在本帖其他回复的原话)：

            > 现有开源项目尚未准备好接受这套方案，且可能永远不会准备好。

            换言之，他自诩觉悟超群，而这些项目根本看不清“正道™”。

            回复

              1. 当OCaml维护者特意为你提供实质性反馈时，你仅回应：

                “感谢X人士”

                你正是导致开源项目耗尽热情的直接根源。

                回复

          3. 善意不代表可以浪费他人时间。这正是多数国家禁止永动机专利的原因。发明者往往真心相信自己成功了，想帮助他人，但审查这些申请纯粹是浪费时间。

            无论哪种情况，若被要求停止却仍继续且不从同行中吸取教训，我认为这已不再是善意。

            回复

      4. 真不明白维护者为何还没封禁这家伙。

        回复

  2. > 作为额外收益，我们期待违反严格禁止大型语言模型/人工智能政策的案例(如A、B、C号案例)减少——我认为这些违规至少部分源于GitHub强行向用户推送“使用Copilot提交问题”功能。

    此外，核心问题在于人们为了提升求职竞争力而刻意美化GitHub个人主页。相比之下，非主流平台难以提供同等吸引力的社交信用积累渠道。

    回复

    1. > 此外，核心问题在于人们为了提升求职竞争力而刻意美化GitHub个人主页。

      人们真的会因为在GitHub上给随机仓库提交了一堆PR就被录用吗？还是只是自以为会？我一直觉得GitHub主页在招聘方和面试官眼中完全不值一提。

      回复

      1. 而这种行为对真正会深入挖掘GitHub主页的人来说是危险信号——比如招聘流程后期接触的技术人员。

        回复

        1. 这是理想状态还是个例？还是说FANNG/科技公司的技术人员真会这么做？我 希望 这是真的，但感觉参与面试流程的大多数技术人员都忙得没精力做这种事。

          回复

          1. 深表认同。作为参与过招聘的技术人员，我从未查看过GitHub。我对候选人的评估完全基于面试中的回答表现，以及“能否与此人日常共事”的直觉判断。根本无暇进行额外审查。

            回复

            1. “能否与这个人日常共事”

              若候选人提供GitHub主页，我会重点观察其PR或问题提交中的沟通能力(或缺乏沟通能力)。最警惕的是那些可能妨碍日常工作的自负迹象——遗憾的是这类情况并不罕见。

              回复

          2. 我曾在几家薪资水平与FAANG相当的公司工作，也经历过一家招聘极其严格的初创企业。我们极少查看GitHub，更从未将其作为录用依据。或许优秀的开源贡献能让招聘官注意到某人，但这种情况极其罕见且难以发掘，几乎是招聘流程的末位考量。拥有优质GitHub主页虽无妨，但LinkedIn仍是招聘首选。

            回复

          3. 虽然我确实用私人GitLab项目拿下了第一份开发工作，但从未有人提及我的GitHub。

            回复

      2. 我见过不少招聘流程：平庸的HR(只会查看GitHub主页和活跃度，却不懂评估)与话语权不足的工程师搭档。这种情况下，刻意包装GitHub主页的人往往占优势。

        回复

    2. 问题和拉取请求只是可选功能。开源项目完全可以像torvalds/linux那样，仅将GitHub作为Git托管/镜像平台使用。

      回复

      1. PR功能不可禁用：GitHub不提供关闭选项。虽无法确定此举是否刻意为之，但该特性确实成为众多平台迁移障碍之一，对GitHub极为有利。

        回复

          1. 没错，这正是我们在Zig GitHub仓库采取的方案。但这无法阻止对现有PR的推送，显然不够理想；而且确实很难不认为“无法设置恢复期限”是刻意为之。

            回复

            1. 或许可以关闭PR并限制讨论范围至贡献者？虽非最佳方案，但至少不会出现在PR标签页。

              或者你可以使用机器人或GitHub Action自动将拉取请求的描述和标题改为类似“[禁止提交PR且将自动删除]”的内容。但确实也不是完美的解决方案……

              回复

            2. 这是完全有意为之的设计，可追溯至GitHub创立之初。GitHub旨在打造协作式软件开发平台，而非“只看不碰”的观望空间。

              回复

              1. 若需协作，您可选择分叉仓库。审核拉取请求并参与社区互动既耗时又可能涉及法律风险；多数情况下自行开发更高效。正因如此，部分团队/企业会刻意拒绝外部贡献。

                回复

        3. 或许可以开发一个机器人，自动关闭所有已创建的PR，同时发送提示信息说明GitHub不接受PR提交，并附上贡献指南链接。

          回复

      2. 在GitHub上提交PR并非可选功能。十多年来用户不断请求为仓库禁用PR功能，但GitHub始终置之不理。

        回复

        1. 正如其他用户所言，你可以通过限制所有交互(每次6个月)来禁用该功能。虽然并非理想方案，但确实能阻止PR提交。执行此操作时还应关闭所有现有PR，确保用户无法向相关分支推送代码。

          回复

      3. PR本身并非可选功能，但处理PR显然是可选的；没有任何机制阻止你忽略或(甚至自动)关闭所有未列入批准贡献者名单的PR。

        回复

    3. 不久前我们刚被敦促认真对待《CODE_OF_CONDUCT.md》。如今我已形成共识：下次开源项目必将包含此类文件，明确禁止向仓库提交低质量代码。

      回复

    4. 当指标沦为目标时，真是荒谬。作为2023-2024年间招聘过员工的人，GitHub个人资料对我而言毫无意义。

      或许我们需要一款追踪劣质求职者的应用。我们可以八卦他们之类的。毕竟我们曾对整个性别(性别？)这么干过，现在就来打造独角兽吧。

      回复

  3. 我对Zig或Codeberg没有强烈立场，但后者基础设施的自我描述令人担忧[1]：他们似乎在生产环境中运行有缺陷的硬件，冗余性有限，还积极向社区募集质量/可靠性/来源不明的硬件。这对于业余爱好者项目尚可接受，但与我所见Codeberg(理想化)宣称的“后GitHub时代稳定平台”定位相去甚远。

    [1]: https://blog.codeberg.org/letter-from-codeberg-onwards-and-u…

    回复

    1. 读到帖子中关于基础设施的部分让我会心一笑——这周我花了不少时间处理工作负载问题，但这里才是真正的现货市场。无论你准备好了没有，混沌猴子(Chaos Monkey)正在生产环境中运行。

      玩笑归玩笑，要让那台服务器稳定运行所需的技术深度确实令人印象深刻。这反而让我对Codeberg更感兴趣了，不过在他们升级硬件前，我还是会继续维护自己的Zig仓库镜像。

      回复

      1. 说清楚，我并非贬低它——我也喜欢重复利用旧电脑。但这与“取代GitHub”的目标相悖，更像是GitHub的“怪咖爱好者版”。

        回复

        1. 不过回想起来，GitHub宕机导致的工作时间损失确实令人担忧。我猜Codeberg的小规模架构反而能保证更高可用性——即便混乱猴子使出浑身解数也难有作为。

          回复

          1. 目前数据并不乐观[1]：核心服务可用性未达99.9%，持续集成/部署系统甚至未达99.9%。而这些数据已比数日前有所改善！

            (此处绝非暗示我认为GitHub的可靠性尚可接受——显然并非如此。)

            [1]: https://status.codeberg.eu/status/codeberg

            回复

            1. 运行时间超过99%时，我真正关心的只有恢复服务所需的时间。我企业级使用GitHub的经历是：一年中曾有数天完全无法工作。

              回复

      2. > 我们希望仅在日照时段使用太阳能直接驱动CI/CD节点

        状态：CI因云端问题停机。

        回复

    2. 想了解Zig选择Codeberg而非自建gitea或forgejo等平台的考量。

      考虑到迁移GitHub本身已造成较大干扰，限制托管相关漏洞和未知风险似乎是更稳妥的选择。

      回复

      1. 若因故需要，我们始终可从Codeberg迁移至自建的Forgejo实例。(不过鉴于Codeberg是非营利组织，我认为这种情况不太可能发生。)

        我们的CI机器均采用自建模式。

        回复

      2. Forgejo的优势在于支持FreeBSD构建环境，而GitHub只能启动缓慢的虚拟机。

        回复

    3. 他们似乎存在可靠性问题；若我解读正确，其状态页面显示每隔几分钟就发生故障。或者说，那张全绿的页面该如何解读？

      回复

  4. 他们放弃GitHub转投Codeberg，因为GitHub的客户包含ICE(冰山公司)。而Codeberg使用Paypal支付服务，后者正是ICE“虚拟全球工作组”的成员。

    https://www.ice.gov/news/releases/top-story-industry-partner…

    当组织开始这样做时，便会陷入纯粹主义的漩涡，最终把自己逼进互联网的冰冷黑暗角落，却仍无法完全摆脱恶劣影响——因为思科为全球几乎所有主要武器制造商和国防部门提供基础设施。

    回复

    1. > 当组织开始这样做时，便会陷入纯粹主义的漩涡

      正是你通过Paypal在Codeberg搞小动作，才招来了这场风波。

      该项目显然能够且确实完成了迁移，因为从GitHub迁移到Codeberg的影响并不大，而且虽然新平台并非完美，但他们认为关联性没那么严重。这其中不存在什么“纯粹主义漩涡”，只是权衡了道德因素的务实选择。

      回复

      1. 没错，这似乎是个小问题。还有人工智能代码提交请求增加的小问题。更大的问题似乎是平台(在其站点上多年)的衰落感，以及迁移到其他平台的合理路径。

        回复

        1. 我认为微软的控股地位也在推动这一进程。

          回复

      2. 读你回复时我曾半信半疑这并非纯粹主义螺旋，但结尾连你都承认这是伦理问题——所以本质上确实存在纯粹主义倾向。接下来他们可能会撤离美国以避免与特朗普挂钩。

        回复

        1. 现实考量至关重要。例如，即便你选择不伤害其他生命，也难免会踩死偶尔出现的昆虫。理论上或许能做到，但那样你就活不成活了。不过你仍能践行许多符合信念的行为，比如不杀生食肉。

          若GitHub是唯一选择，他们或许(可能)不会更换平台。但事实并非如此，他们找到了在自身标准下更可接受的替代方案——至少“相对较好”。诚然，他们未必认同供应商全链条的道德立场，但显然更倾向于后者。这才是关键。人只能在力所能及之处坚持立场。

          回复

          1. 但你会因同样理由停止使用AWS吗？

            回复

            1. 我从一开始就因类似原因拒绝使用

              回复

        2. Simian，

          当你实质上宣称“企业(及非营利组织)试图践行符合使命宣言的道德行为是 错误的 ”时，你本身就是在做出道德判断。

          用伦理学论证伦理的无意义与徒劳…至少可以说很有意思。请今天就停止上网，找本符合你价值观的伦理学著作研读，之后再来审视这个局面。

          回复

          1. 我没说这是错的，但我绝对不会为了彰显美德而放弃AWS业务

            回复

            1. 你觉得“彰显美德”和“践行美德”之间有区别吗？

              那些把前者当污名使用的人，似乎非要认定后者不可能成立。

              我个人不愿生活在这样的世界里——凡善举必疑居心叵测(最高权力者除外)。这未免太耗心力。

              安德鲁·凯利言行一致(以自闭症谱系的方式)，这使他既令人疏离又充满魅力，具体取决于议题。但切勿将其视为单纯的“信号”，这正是他的真实信念。

              就我个人而言，我确实会远离不道德的产品与人。虽然行动速度未必如我所愿——亚马逊便是典型例证——但我从未为此后悔。

              这甚至不值得炫耀，谁会在意呢？我只是厌恶谎言，若想 相信 自己能不欺骗自我地践行道德，这便是自然而然的后果。

              回复

        3. 世间存在数十种伦理学派与思想体系，其中多数关注的并非纯粹性，而是可行性与现实预期。

          他们并非在此推行绝对命令。

          回复

        4. 基于道德原则行事与陷入纯粹主义漩涡截然不同。

          回复

    2. 我认为“向X方提供服务”与“平台使用与X方合作的支付处理商”存在本质区别。

      你的观点当然有道理，但面对诸多选项时，我们能做的往往只是避免最糟糕的方案——毕竟没有完美解。我并非主张人们因此离开GitHub，但完全理解有人会选择离开，或转而采用其他同样不完美的替代方案，而非事事亲力亲为。

      回复

    3. 听起来很棒，毕竟Zig社区似乎总因挑剔的理由拒绝现有工具，转而打造自己的(确实优秀)方案。

      若这能促使他们重新构思并打造更优的GitHub，我已迫不及待。

      回复

    4. 除了取悦那些愤世嫉俗者——他们执着于所有决策必须绝对二元且前后一致，不容任何细微差别或实用考量，并将其他选择视为道德标榜(这种立场反而比放任危害更站不住脚)——之外，没有任何理由逼迫你陷入“纯粹主义漩涡”。

      在可行范围内减少伤害仍有意义，且绝对优于毫无作为。

      回复

    5. 若深入探究，似乎美国每个组织都存在某种程度的妥协。当然，你总能找到针对每家科技巨头的理由。但平衡之道仍需把握。

      回复

      1. > 若深入探究，似乎美国每个组织都存在某种程度的妥协。

        我深表认同，且认为问题远不止于此。引用作家亚历山大·索尔仁尼琴的话：

        “善恶的分界线既不划过国家，也不划过阶级，更不划过政党——而是横亘在每个人的心中，贯穿所有人的心灵。”

        回复

      2. 如果你所谓的“深挖”是指听着舞曲懒洋洋地扫扫前门，那我同意你的观点 🙂

        回复

    6. 这真是篇帖子的奇怪解读——文中唯一提及ICE的地方是

      > 暂且不论GitHub与ICE的关系，

      而其余内容都在阐述技术层面的理由。

      回复

      1. 我觉得这正是原帖的核心。我认同整体观点，但提及ICE关系似乎偏离了主旨。

        “我讨厌GitHub因为X Y Z功能糟糕”是合理的迁移理由；而“我讨厌GitHub因为他们数千家企业客户中有个政治立场与我相左”——在我看来并非如此。

        声明：我绝不支持ICE

        回复

        1. 抗议ICE的人并非出于政治立场，而是基于人道主义关切。

          这看似吹毛求疵——两者本就紧密相连——但区分二者至关重要。为他人发声绝非小题大做或自私自利，而这种混淆恰恰会传递错误暗示。

          回复

          1. 人们沉迷革命幻想，妄想自己能在1933年阻止希特勒(他们做不到)，但这绝不意味着他们的妄想能成真。这些蠢货把反体制氛围搞得如此无趣。光说不练永远成不了气候。

            回复

            1. 你该见见芝加哥本地冰山男孩们，他们肯定会好好款待你

              回复

            1. 你好呀(新账号){name}{number}！你什么时候发现{你，一个真实的人}竟相信，保护{妇女！}和{儿童！}的唯一途径是这个在9·11事件后由布什政府新成立的机构？

              你知道吗？所有{妇女！}(每年超过1200万)实际上最危险的威胁来自亲密伴侣——而这些施暴者主要来自她们同种族、同阶层的群体？

              你觉得这比你特意注册账号来散布的煽动性轶闻更值得关注吗？你认为预防家庭暴力(预算不足10亿)的资金应该比移民海关执法局(1700亿)更少还是更多？

              >(特朗普政府时期)：负责暴力预防的团队遭到削减，卫生与公众服务部的重组更直接撤销了多个部门。

              回复

          3. 这纯粹是道德姿态的表演。那些在2017年左右围绕时下热点塑造自我认同的人，对归属主流群体有着宗教般的执念，无法自拔，最终必然以这种形式爆发出来。

            此言无疑会激怒该群体支持者，但他们不过是那个社会病态泛滥的黑暗时期里可悲的残余。

            回复

            1. 虽然你肯定会认为自己被点踩是因为向反社会者说真话，但我要声明：我点踩是因为你的评论违反了 多项 HN准则。提醒一下，准则在此：

              https://news.ycombinator.com/newsguidelines.html

              目睹资深社区成员如此轻率行事令人失望。我明白指南规定只需举报即可，但这只会强化你的论调，而我正试图打破这种循环。

              回复

            2. 我们中有些人亲眼目睹过移民局特工肆无忌惮的反社会行为。若你愿意，同样能亲眼见证。

              回复

          4. 当今美国政治极度二元化，我认为除了“我朋友说我们阵营持这种观点”之外，很难为政治议题赋予其他动机。我认为这种态度本身比任何根本性问题都更具政治性。

            回复

        2. 我理解为“这是我们关注的重大新闻事件。你或许知晓，但并非主要原因。以下才是核心缘由。”

          回复

        3. 正因如此，文章才刻意回避了那个原因

          回复

          1. 若完全不提及该理由，处理得会更妥当。

            结果我们都在讨论这个，而非技术原因。

            回复

            1. 目前全网仅此一个分支、一个讨论串在“转而讨论这个”

              回复

            2. 如果他们没有提及GitHub与ICE的关联，那么现在所有人都会质疑这种关系是否影响了决策。

              回复

            4. 他们看到了诱饵的机会，而你上钩了

              回复

        4. 这确实暗示/意味着：即便GitHub明天解决所有技术问题，Zig也可能不会回归。

          回复

          1. 你得到一个。但有多少好邻居被拖出车外？多少父母被强行与子女分离？多少美国公民因此遭受错误骚扰或被拖出家门？多少在街头和平祈祷的牧师被枪击头部？

            这从来就不是关于凶手的问题。凶手只是借口，真正遭受骚扰和暴力的不是他们。如前所述，其中许多人都是美国公民。

            回复

          2. 支持理性的边境政策，并不意味着必须支持种族定性、城市军事化以及无令状搜查拘留。这两者本不必相互排斥，但不可否认的是，移民海关执法局近期的诸多行径，在许多人看来已构成违宪行为。

            回复

          3. 既然要这么说，那我是不是该开始发宗教领袖性侵儿童的新闻了？难道我们该每年耗资1700亿美元试图关闭所有教堂？

            回复

          4. 美国政治中最荒谬的讽刺之一，莫过于人们一边抱怨特朗普治下法治崩坏，一边又主张各州各市应主动无视并阻挠联邦移民法。当然细节都复杂混乱。但若你同时认同这两点，就该花点时间反思自己观点的荒谬性。当今社会对持不同意见者的同理心严重匮乏，而这正是民主制度运转的基础。

            回复

      2. >文章其余部分给出了技术性理由

        帖子以对资本主义的控诉收尾。

        回复

    8. 当狗屎终于飞溅时，最理想的藏身处莫过于阴暗角落的低处——双手洁净，绝不沾染猪猡的污秽

      回复

    10. 你生气是因为他们更换了供应商，而你认为新供应商同样糟糕，同时又指责他们开启了“不可避免的纯净螺旋”？到底是哪种情况？

      回复

      1. 我倒不觉得你回复的对象是在“生气”。你是在为对方所写的内容“生气”吗？

        回复

      2. 这并不矛盾。他们只是指出在这种情况下既定目标未能实现，所以毫无意义。

        回复

        1. 如果你读过链接文章就会知道，这并非他们声明的目标。评论者理解有误。

          回复

          1. 请指教，他们是否明确提及ICE是他们想从GitHub迁移的原因？

            回复

            1. 他们只是在提及技术问题前顺带提过。

              他们并未如你暗示的那样将其作为 唯一 理由，而是作为促成决策的因素之一。

              回复

              1. 我清楚这不是唯一原因，但这并不能改善他们的逻辑。

                回复

    11. 我们都受够这些激进主义的蠢货了

      回复

  5. 这群人毫无根据地发泄着模糊的愤怒。所谓猴子们创建的CI系统可是全球顶尖的免费CI服务之一。不是每个人都有像Zig基金会那样数百万美元去搭建自有CI服务器。

    后来他们又赞赏GitHub赞助功能，如今却因项目负责人离职就宣称这是彻底的负担。实际发生了什么变化？有新规则出台吗？但不，现在它成了“负担”，我们必须接受。

    坦白说，我欣赏大型项目探索新托管方案的做法。但没必要像这样攻击其他平台来推广自家新主机。

    回复

    1. > 如此模糊的愤怒实属无稽之谈。

      你们选择性忽视GitHub Actions的技术缺陷，却宣称毫无问题。这观点真够独特。

      > 那个所谓猴子团队开发的CI系统，可是全球顶尖的免费CI服务。

      我们所有CI机器均自主托管，所谓“免费”托管运行器与我们毫无关联。

      > 并非人人都有像Zig基金会那样的数百万美元来搭建自有CI服务器。

      我们可没有“数百万美元”。真有就好了！

      还需说明的是，我们资金使用效率极高：多数CI机器都是成员家中部署的消费级硬件。我们可不会把钱无节制地砸给云服务商。

      之后他们开始赞赏GitHub赞助计划，却又声称该计划如今成了彻头彻尾的负担——仅仅因为项目负责人离开了。实际发生了什么变化？有新规定出台吗？但不，它现在成了“负担”，我们必须接受这个事实。

      GitHub赞助计划之所以成为负担，是因为微软随时可能提高抽成比例，甚至在认为不再有利可图时直接取消该计划。正如安德鲁所指出的，该功能被长期忽视，这种风险非常真实。客观而言，让捐赠者使用Every.org这类平台对我们风险更小。

      回复

      1. 任何你无法完全掌控的捐赠平台难道不会随时切断合作吗？

        GitHub赞助功能究竟有何不同？

        回复

        1. 理论上当然可能，但关键要评估发生概率。

          典型动态如下：

          大型机构平台 → 风险暴露，因你对其利润贡献有限
          小型捐赠平台 → 易受支付处理商施压要求“降低风险”

          —

          every.org 情况特殊，它只收录501c非营利组织——Zig基金会就属于此类——据我所知其运营记录良好。多数开源项目达不到这个标准。

          回复

    2. 任何用过Gitlab的人，或者恕我直言用过Jenkins的人，都体验过比GitHub Actions更优秀的系统。

      除非它最近奇迹般地改进了——毕竟我已有两年没用它了——他们甚至没有文档说明正则表达式/模式匹配规则。我搜索到的最佳信息是它采用Ruby的实现方式，这根本算不上真正的标准。

      我不想人身攻击，但任何为该系统辩护的人都值得被调侃一番。

      回复

      1. 我两者都用过，虽不知是否改进过，但几年前它们都很糟糕(至少在我们这里如此)。极其不稳定且挑剔。我最后一次用Jenkins是2017年，Gitlab是2021年，所以不清楚它们现在的状况。

        回复

      2. 十多年来Gitlab的CI系统每天都能碾压Github那破烂不堪的CI

        回复

        1. Gitlab CI给我制造过太多麻烦，实在看不出它比Github的CI好多少。

          回复

          1. 只要不是用堆砌的嵌套YAML文件拼凑出来的CI服务我都接受。

            那种东西简直是噩梦般的维护体验。

            回复

        1. GitHub当年取代Sourceforge时确实很棒。但那已是久远往事，如今更优秀的替代方案正层出不穷。更别提微软近期的“垃圾化改造”(比如放任非AI相关功能自生自灭)。GitHub的整个管理与开发流程早已彻底崩坏，根本无药可救——管它是不是猴子在掌舵。

          附注：GitLab CI比GH Actions强太多，根本不在同一级别。很明显GitLab是在真正践行自家产品理念，而GitHub的任何功能都让我感受不到这种态度。

          回复

        2. 得了吧。

          微软可是GitHub的老板。

          我们何必假惺惺地表示同情。

          当你有能力提供优质服务却拒绝付出时，就别抱怨被人骂。

          Actions糟透了。

          > 敢说自己能做出更优秀产品的妄想者，就拿出来证明

          行动胜于空谈。

          Zig正是因这些问题而离开。

          > 有人试用GitLab等替代服务后，发现其速度更慢、界面更丑、整体体验不如GitHub，最终只能爬回来。

          或许吧。且看后续发展。

          原帖作者态度很明确：他们对现状不满，且正用实际行动证明立场。

          显然，光抱怨系统缺陷毫无作用。

          或许GH需要再经历几起类似的大规模出走事件，才能清醒地意识到：他们完全有能力(绝对有能力)投入更多资源来修复问题。

          回复

          1. 到底是谁在抱怨Zig离开GH算什么问题？我只是不喜欢他们散布GH CI和赞助商存在重大问题的虚假说法。

            Zig是转投其他服务商，并非打造了更优秀的GH并修复所有问题。

            你居然得填写申请表才能说服Codeberg开通CI服务。我宁可用GH CI也不要那套。

            回复

            1. > 我就是不喜欢他们散布GH CI和赞助商存在重大问题的虚假说法

              这些并非虚假指控。

              这正是我的观点。

              微软完全有能力改进这些工具，只是他们根本不在乎。

              没错，总比 什么都没有 强，但老实说，现在不戴眼罩都看得出功能在衰退。

              回复

              1. > 微软完全有能力改进这些工具，只是他们根本不在乎。

                资金确实充足，但他们真能改进吗？谁能接手？怎么改进？你觉得增聘人手有用吗？还是会让情况更糟？

                领导层或许会尝试强行干预。但为此他们必须削弱掌控GitHub Actions的人。这将是场风险巨大的政治博弈。而代价是什么？他们真因GitHub Actions流失客户了吗？我对此存疑。我不确定有人愿意耗费如此巨大的政治资本去“修复”一个本就不算严重的问题。

                大公司根本无力修复内部的系统缺陷。这无关资金，而是文化与政治的博弈，更是领导层的决策问题。

                例如，还有人记得Google Code吗？这个早于GitHub数年的代码托管服务，其体验远逊于GitHub。当年GitHub问世时，谷歌本可彻底重构Code，借鉴GitHub更优的设计与决策。(类似安卓对iOS的复制策略)但他们没有这么做。GitHub多年来始终占据优势，谷歌却无动于衷。他们无力扭转局面，如今Google Code已基本消亡。

                为何Adobe未能打造出可与Figma抗衡的产品？微软为何没能推出成功的iPhone或iPad竞争者？英特尔为何未能赢得iPhone处理器制造合同？这些都不是资金问题，而是其他因素作祟。

                我只听说过少数几位具备解决此类问题魄力的领导者，比如史蒂夫·乔布斯。埃隆·马斯克也常做出惊人之举。坦白说，我不愿为他们任何一位效力。

                回复

                1. 自从上任GitHub CEO数月前离职(其实没什么损失，毕竟是他把GitHub搞得人工智能化一团糟)，GitHub已被完全整合进微软的人工智能部门。仅凭这些组织架构变动，就足以让人对GitHub的未来失去信心。在我看来，在“人工智能优先”部门掌舵下，情况只会愈发恶化。现在或许是跳槽的最佳时机——至少对规模足够大且专业的项目而言这是负责任的选择(我敢打赌ziglang只是众多跟风者之一)。

                  > 但他们必须先削弱GitHub Actions的运营方

                  目前我怀疑GH Actions项目是否还有人负责，除了基础维护工作和防止整个项目崩塌成废墟之外。微软内部也不再有独立的Github实体，所以根本无从“削弱”。

                  回复

                2. > 他们真的因为GitHub Actions流失客户吗？我表示怀疑。

                  你读过那篇文章吗？

                  回复

                  1. 若我理解有误请指正，但Zig从未成为GitHub付费客户的可能性极高。

                    回复

                    1. 该死，若Zig真想报复GitHub，本该留下来继续消耗微软资源才对。

      1. 那么请告诉我们，哪里能找到更好的免费macOS CI服务商？我非常愿意转用他们。

        这就是我所说的“最佳免费CI服务商”。若您有预算选择更优质方案，这便不算最佳。

        回复

        2. 我也非常想知道。我用GH Actions在MacOS、Windows和Linux上免费测试开源代码，效果超棒。若没有它，我只能在本地环境或TravisCI/CircleCI的免费层级进行测试——直到GH Actions让流程变得如此便捷。

          但若您了解替代方案，我洗耳恭听。

          回复

      2. 遗憾的是，我并不清楚CI提供商该如何解决这个问题。

        回复

      3. 他们在你评论后8小时就修复了哈哈

        回复

          1. 抱歉我太蠢了。我还以为那个链接的PR是GitHub的。

            回复

    4. > 那个所谓猴子团队开发的CI系统，可是全球顶尖的免费CI服务之一。

      其实不然(对比Gitlab就知道了)，GitHub CI唯一的优势是提供免费的Mac运行器。

      回复

      1. 嗯，除了那些让它更优秀的功能外，没有任何东西能比其他东西更好。

        回复

    5. 它唯一的优点是为“开源”项目提供了极为慷慨的配额限制(据我所知甚至不必是自由软件，只要源代码对所有人可见即可)。

      这个CI服务本身就是微软典型“非我发明不可”心态造成的绝对垃圾，如果他们有财力不再处理它，我看不出他们为何要浪费有限的开发时间去折腾它。

      回复

      1. 微软产品的持续集成服务还能诞生在别处吗？在此语境下，“非我发明症”简直是莫名其妙的指责。倘若微软选择收购现有CI服务，你们又会抱怨他们削弱了市场竞争。

        回复

        1. 微软早就有自己的CI服务，它比GitHub Actions更早存在，后来更名为Azure DevOps。据我所知，两者功能高度相似。

          回复

        2. > 微软产品的CI服务还能从哪儿发明出来？

          顺便提一句，Azure自带的CI服务也相当糟糕。

          回复

      2. >据我所知，这甚至不必是自由软件，只需源代码对所有人可见即可

        这是否意味着微软可以随意采集数据用于大型语言模型训练？

        回复

      3. 他们完全可以不带侮辱性地完成这件事。

        回复

        1. 我同意这很失专业，但至少我们讨论的是GHA——哪怕只是边缘话题——毕竟这公司问题堆积如山，鲜有可取之处。

          回复

        2. 若这些批评不那么咎由自取，我倒会赞同。揭露垃圾就是垃圾，这无可厚非。

          回复

          1. 你认为某事是垃圾，不代表它就成了我们的真理。数百万用户对GitHub满意得很，请尊重他们的选择。

            回复

    6. 你不是在说GitHub Actions吧？猴子都能做得更好。

      回复

      1. 可世上数百万猴子却从未创造过任何价值。

        回复

    7. Zig Foundation显然没有数百万美元资金，不像市值数万亿的微软——它却持续产出垃圾产品，一款接一款。

      回复

    8. 对我而言CI的职责就是运行Nix Flake

      回复

    9. GitHub Actions或许是最佳免费选项之一，但绝非最佳付费方案。工作中它给我带来了无穷无尽的头疼。

      回复

    10. 技术问题完全合理。但说明变更理由与烧毁与离去者的桥梁之间需要平衡。

      对支持者造成的摩擦显得有些不合时宜。不过项目本身遵循强硬原则，我猜他们清楚自己参与的风险。

      回复

  6. 不确定这篇帖子是否属水军操作，但看到HackerNews为微软喝彩、对拥抱替代方案的社区奚落，这种心态实在反叛客精神。

    可悲的现状

    回复

    1. 人们质疑的并非脱离巨头平台的决定，而是其行事方式、选择的替代方案以及嚣张的措辞

      回复

    2. Hacker News实属名不副实。这里不过是风投与FAANG雇佣兵的聚集地。

      回复

    3. 我并非支持微软，但诸如：

      > 剩余的新人正以进步之名，急于向我们强加臃肿且漏洞百出的JavaScript框架

      以及

      > 更重要的是，Actions是由猴子创造的

      这类评论实在幼稚。

      回复

      1. 虽显幼稚，但GitHub等全面弃用JavaScript的网站确实变得迟钝了。

        回复

        1. 没错，但这种论调默认了JavaScript毫无益处，也忽略了引入新框架(或这个十年前的框架)的其他考量。

          我们无从知晓决策过程、决策者身份，更重要的是决策动机。将所有问题归咎于开发者是猴子，让我怀疑作者要么从未在正规公司工作过，要么刻意遗忘了职场真相。

          回复

        2. 哦，这样说来人身攻击就合理了？

          回复

          1. 追求性能优化难道不是幼稚的理想吗？随着年龄增长，我不再执着于优化，只求完成任务。

            (不是每个人都像你这么有礼貌，柠檬君。看来网络世界多数人都患上了骂人抽动症 🙂

            回复

    4. 在鲍尔默离职后到Windows桌面开始充斥广告、陷入(坦白说令人难以忍受的)AI炒作之前，曾有过短暂的时期，微软似乎正走在正确的道路上。一个更理性的微软收购Github本可能成为好事，可惜啊…

      回复

      1. > 微软看似走在正轨上

        那只是天真得无可救药的人才会这么想。

        回复

  7. > 暂且不论GitHub与ICE的关系，显而易见的是：曾参与产品开发的精英们早已另谋高就，剩下的失败者却急于以“进步”之名向我们强加臃肿又漏洞百出的JavaScript框架。

    这番话更暴露了作者的本质。

    回复

    1. 他们不支持一个要求成员蒙面、永远不让公众知晓其身份的民族主义准军事组织，这样就无法追究其责任？一个被国家化的三K党绝不值得支持。

      回复

      1. 我对ICE平台无所谓，但因他人未按你要求开发产品就骂人“猴子”“废物”实在幼稚。

        在我看来，真正“失败者”是那些整天抱怨不喜欢的软件平台的人。

        回复

        1. 他们并非“抱怨唠叨”，而是正在迁移社区与平台。GitHub本就用户敌对，其运营公司素来如此。替代方案早已存在，支持它们绝非“抱怨唠叨”，而是建设与创造。你无法或不愿承认这点，恰恰说明问题。

          回复

        2. 我对移民与海关执法局(ICE)无所谓

          这种态度本身就是政治立场，还是特权阶层的立场

          回复

          2. 何等狂妄的论断。首先，并非人人都是美国人。

            回复

            1. 在影响美国人的议题上，非美国人身份本身就是一种特权。这与身为美国人的我漠视匈牙利滑向专制无异——我拥有漠视的权利，这本身就是特权。

              回复

              1. 按此定义，“特权”一词便丧失了意义——宇宙间存在无数不公，无人能免于所有不公。

                回复

                1. 它并未丧失全部意义，且你的论点无法支撑你的主张。

                  回复

            2. 对其他国家发生的事情漠不关心，本身就是一种政治立场。(我并非美国人，但这无关紧要。)

              回复

        3. > 整天抱怨个没完

          他们可不止于此。

          回复

    3. 但他们改了主分支的名字，这难道不能消除任何ICE关联吗？

      回复

  8. 我很高兴看到这次迁移。Codeberg可能比SourceHut更稳定/长远，毕竟创始人有点不靠谱(但真心欣赏他搭建的平台)。说实话，两者都是不错的选择。

    更多开源项目应该离开GitHub。我自己也离开了。

    回复

    1. 这些平台让我疲于应对。每次都要学习新平台。目前已有：

        - GitHub
  - BinCode
  - GitLab
  - SourceHut
  - CodeBerg

      它们功能大同小异，只是网页界面不同。竞争是好事！尤其针对垄断市场的巨头。但…GitHub的集中化确实有其价值。

      回复

      2. > 它们似乎都提供类似功能

        Codeberg(Forgejo)是自由软件，GitHub则不是。软件价值不仅在于功能特性。

        回复

    2. 我确信Drew已退出SourceHut项目。可惜SourceHut顽固坚持仅支持邮件列表的工作流程，平台其他方面其实都很出色。

      回复

        1. 谢谢。我的信息确实过时了。

          回复

      2. 我认为德鲁只是暂时“休息”，并未永久退出。他继续参与对平台更有益。希望他能推进自己的构想，拥有更多选择总是好事。

        回复

        1. 很高兴他们对基于邮件的补丁提交有强力支持，但这对平台新用户来说确实难以推广。

          回复

      3. 我同意相比Github拉取请求或Gitlab合并请求，它的学习曲线确实陡峭，但就像许多事物一样，陡峭的学习曲线背后隐藏着极其强大的工具。著名的Linux内核就是例证——如此庞大的项目根本无法采用Github/Gitlab模式运作。

        回复

        1. 我更倾向用“特例”而非“例证”来描述。

          新一代程序员恐怕根本无法理解“通过邮件列表贡献代码”的含义。

          回复

    3. 我很高兴看到这次迁移。Codeberg可能比SourceHut更稳定/更具长期性，毕竟创始人有点不靠谱

      这是什么情况？

      回复

        1. 我有点困惑，所谓事件是指他撰写了一份文件，详细记录了某位知名社区人物的反复不当行为？这居然是件坏事？

          而且第二个链接简直是牵强附会哈哈

          回复

          1. 他明明假装没写过这份文件，尽管其DNS指向他的服务器，证书透明日志和互联网档案馆都将该页面归属到他的域名。对比首条链接的热门评论区和他本人的回复：

            https://news.ycombinator.com/item?id=41838124

            我向来欣赏Sourcehut和Drew的文章，但刚得知此事深感失望。

            回复

          2. 第二条链接的哪部分？其中部分内容引用极其准确，他100%运营着一个针对Reddit因非法内容封禁的子版块的萝莉机器人。这点无可辩驳。文末还指出Drew修改SourceHut的服务条款以封禁他反对的项目，这让GitHub都显得像天堂了。

            回复

          3. > 事件核心是他撰写文件揭露某知名社区人物的反复恶行？这竟成了坏事？

            他收集了斯托曼关于爱泼斯坦案及相关议题的所有言论(这完全合理)，却在撰写摘要时彻底歪曲了原话本意。结果大量读者只浏览摘要就断定斯托曼猥亵儿童，或宣称此类行为无妨等等。

            事实上我开始在分享斯托曼报告时特别标注“请勿阅读摘要，只看斯托曼的原话”。当然这仅限于我确信对方出于善意时。也建议你这样做。

            回复

        2. 点链接前真该准备点爆米花。

          开源圈的闹剧比油管博主或明星圈的戏码精彩不遑多让。

          感恩节开场真是精彩绝伦。

          回复

        3. > dmpwn

          目睹4chan偏执狂们用同样手段抹黑德鲁·德沃特，通过自创假账号和抹黑运动暗示所有权归属，实在令人作呕。该页面几乎所有指控都是间接证据，尤其是机器人所有权部分——连sircmpwn都删除了相关证据，同时指出那些偏执狂正利用它抓取儿童色情内容。

          更可笑的是dmpwn那家伙在图片论坛发帖时还带上dmpwn标签，截图时居然忘了删掉？笑死，真有这智商？

          作为经历过4chan偏执狂、/pol/版和kiwifarms同类人肉攻击的受害者，我认为自己有资格评论他们的运作方式。

          或许该再召唤一次敌基督来清理门户？

          回复

          1. > 目睹4chan偏执狂们用相同手段抹黑德鲁·德沃特，实在令人作呕

            不必费心，德鲁自己就做得够好了。

            回复

          2. 你有证据证明这些账号是假的？而且是 全部 账号都是假的？

            回复

        4. 卧槽这事儿完全失控了。我压根不知道有这事儿。

          sr.ht现在被污染了还是还能当代码托管站？我实在没法判断。

          回复

          1. 他确实有点不正常，但至少我每次和他互动都很愉快。

            回复

          2. 这是4chan偏执狂发起的诽谤运动。详见我兄弟的评论。

            回复

            1. 感谢提醒！庆幸自己远离聚光灯，对这类事件一无所知。真不想成为被针对的对象啊 :/

              回复

          3. > sr.ht 现在是否已遭污染

            真讨厌这种问题竟能被认真提出。

            老兄，用你最顺手的工具就行，管他别人怎么想。确实有人会说“你用这个工具就是错，因为开发者对Stallman说了不敬的话”(具体细节我也不记得了)。这种人根本不值得你关注。

            回复

            1. 是我失言了，不该用“污名化”这个词。我本意是说“值得信赖”。

              多年前我就把私有仓库迁移到sr.ht，因为它代表开源、自由软件、道德、可持续的理念。更重要的是远离那些巨头企业及其种种行径。

              只是想确认这种理念是否依然存在。

              回复

      2. 长期阅读Drew de Vault博客的人似乎都得出相同结论。

        回复

        1. 德沃特的争议性观点与凯利在这篇帖子中表达的观点相当相似，因此我认为两者并无明显分歧。

          回复

    4. 在推动开源项目大规模迁移前，SourceHut亟待解决的首要问题在于：缺乏能支持多贡献者协作的组织架构，尤其对于拥有多个仓库的项目而言。

      回复

  9. 重要提示：Codeberg当前未实现无障碍账户注册。由于仅支持图片验证码，屏幕阅读器用户无法创建Codeberg账户。虽有手动备用方案，但耗时未知。我被迫使用维基媒体账户注册，耗时约三个月。此问题已被多次反馈，但他们似乎无意修复。

    若你此前不了解Codeberg的真实立场及其对待不便用户群体的态度…现在想必明白了。

    回复

    1. > 此问题已被多次反馈，但他们似乎无意修复。

      你当前页面下方就有一个问题链接[0]，承认验证码存在无障碍缺陷并表示计划弃用(虽未给出具体时间表)。我完全无法理解你为何认为Codeberg回复邮件缓慢(即所谓的“人工备用路径”)就必然源于Wikimedia的拖延——两者是完全独立的实体，实在看不出你为何要将两者混为一谈。

      [0]: https://codeberg.org/Codeberg/Community/issues/1797

      回复

    2. 开发工具对无障碍性的漠视令我深感痛心。这反映出我们行业普遍将无障碍功能视为“奢侈品”——总想着等公司成功了、赚够钱了再考虑。

      我期待AI工具能改善依赖屏幕阅读器等辅助工具者的生活质量，但隐隐担忧这只会让无障碍访问的负担从操作者转移到用户身上。

      回复

      1. > 开发工具对无障碍支持的漠视令我深感痛心。

        这很大程度上取决于公司规模及具体企业。

        微软在此领域的所有举措都堪称典范，Visual Studio Code有时甚至像专为盲人设计的应用。其他大型企业表现欠佳，但其产品通常尚可使用。

        初创公司则参差不齐，例如Zed就以完全无法访问而臭名昭著。多数SaaS工具虽无法通过无障碍审计，但勉强可用时仍会带来巨大困扰。

        开源项目普遍表现糟糕。GTK至今未在非Linux平台提供任何无障碍支持。QT曾完全无法访问，不过近两年已显著改进。Linux系统本身存在重大缺陷，除非对底层机制有深度理解，否则几乎无法使用——即便如此也未必能完全克服障碍。

        无障碍开发并非热门领域，除非奉行管理驱动开发模式，否则无人愿意投入精力。

        回复

        1. > 微软在此领域的所有实践都堪称典范，VS Code有时甚至让人感觉是专为盲人设计的应用。

          确实。只要你失明看不见广告，开始菜单的广告同样堪称完美。

          回复

        2. > 这主要取决于公司规模

          关键在于公司是否试图向政府机构销售产品——这些机构的采购流程中往往包含无障碍要求。当然公司规模与承接政府合同的能力之间存在因果关系。

          回复

    3. 真不明白他们为何不启用语音验证码——我编写的验证码包本就支持这项功能。

      回复

      1. 怎么不是？就在不远的1930年代，曾有政党主张大规模杀害残障人士，或至少对遗传性残障者实施绝育。那个时期确实存在强制绝育运动，尤其在某些精神病院。至今仍有人鼓吹此类观点，所幸目前仅存于社会边缘。

        无障碍理念恰恰与此相反——但遗憾的是，它绝非被普遍接受的善举，尤其当实施需要额外付出时。

        回复

        2. 从“我们是个小型非营利组织，苦于找不到既优质又无障碍的解决方案，这真的很糟糕——我们深表歉意”跳到优生学，这逻辑跳跃未免太大了。

          回复

          1. 我当时是在回应有人质疑“无障碍设计如何成为政治议题”，我以为对方是泛泛而问。

            回复

        3. 这种表述方式在我看来很奇怪。

          在我的国家(西班牙)，无论执政党派如何，我们都会安装轮椅坡道。这被视为人权或道德议题，而非政治议题。

          回复

          1. 敢打赌佛朗哥当年可不是真心为残障人士建坡道。某个政党目前在贵国缺席(谢天谢地！！)并不代表这个议题就不具政治性。

            回复

            1. 佛朗哥统治下的西班牙是独裁政权。实在不明白你如何类比。若你是在故作俏皮，这种言论实属低俗。

              况且欧洲多数国家(包括西班牙的Vox党)政治体系中都存在极右翼势力。

              回复

  10. 把GitHub开发者称为“失败者”实在不妥。

    回复

    1. 看看他们搞的东西有多糟糕。要么就是失败者，要么就是对技术毫无热忱的消沉打卡族。

      回复

      1. 更可能的情况是，他们大多是专业能力过硬的从业者，在冷漠的企业环境中竭尽所能——就像我们其他人一样。

        回复

        1. 保护个人免受外部批评，正是这种冷漠企业环境的重要特征。

          回复

        2. 我们并非全都向企业妥协。

          诚然其中有些人可能有点…特别。比如那个开发TempleOS的人。

          回复

          1. 在这个世上总得向某人推销自己。为此贬低他人毫无意义。

            回复

          2. 不幸的是，我们中有些人困在微软垄断的国度，几乎不可能获得Linux相关职位——尤其是入门级岗位(在我居住的地方这类岗位基本不存在)。我甚至考虑过迁居Linux岗位充沛的地区(欧洲)，但这意味着必须先掌握当地语言，还得具备足够的Linux专业经验(雇主宁可招本地人也不愿雇外国人做入门岗位)。

            所以除非你有妙招，否则我只能困在这份微软工作中，直到有人创造出神奇的Linux岗位，或者我自己创办Linux公司却因没有客户而无所事事…

            回复

      2. 他们也可能是需要支付账单的人，或许正面临着——据某些说法——极其严峻的就业市场。或者因身体残疾导致求职过程困难重重甚至无法实现。

        回复

        1. 这无可厚非，但他们将企业立场强加于人。我认为若为金钱而欺骗他人，这份工作就不够正直。(我指的不是你，而是那些不得不这么做否则可能失业的人…)

          回复

          1. > 我认为若因金钱问题不得不欺骗他人

            那你该抗议的对象是资本主义，而非Github/微软。

            回复

        2. 除了难以界定的“残障”部分，你的描述不就是“失败者”的代名词吗？

          编辑：不明白为何被点踩。这并非对GitHub员工的价值评判，而是探讨“失败者”的定义。回想青春岁月，何为失败者？指那些常因非自身过错而深陷困境、总是“吃亏”的人。其本质特征在于缺乏挣脱困境的胆识。

          这难道不是“失败者”的普遍定义吗？

          回复

          1. > 这难道不是“失败者”的普遍定义吗？

            “失败者”是种缺乏同理心的笼统贬称。但他们确实可能“身处劣势境地”，这才是关键区别。

            > 除“残障”部分外，该分类存在争议

            此处“残障”指个人内在缺陷(如生理或精神障碍)，导致其就业过程面临实质性困难。

            除残疾外，任何针对个体的偏见(如年龄歧视、性别歧视、资历差异、肤色歧视、语言能力、原籍国等)以及签证考量、财务状况等因素，都可能增加求职风险。影响跳槽决策的变量实在太多。

            回复

      3. GitHub正从旧基础设施迁移至Azure。此类迁移无论对谁而言都极具挑战性。从商业和工程角度看，利用Azure的规模经济效应显然比GitHub自建服务器更合理。

        回复

        1. 被迫使用Azure的人，至少在找到新工作之前，算是人生失败了——这未必是他们自身的过错。可怜的家伙们八成还得用Teams。

          回复

          1. GitHub的工程师们在SWE3级别年薪30万美元，我可不觉得他们算人生失败。

            何必如此贬低他人？这可是相当可观的收入，足以养家糊口，四十岁就能退休，而且这份工作不会摧残身体。

            回复

            1. 明知自己在让事情变得更糟却还要为此耗尽一生，这实在令人丧失斗志。我认识许多人，当意识到这份工作本质如此时，他们选择降薪或直接辞职。

              回复

              1. 有时这些人并未意识到自己在加剧问题，他们只是陷入抑郁的漩涡，看不到尽头，也看不见在某些方面暂时恶化的同时，其他领域仍在创造价值，更看不见为了在某些方面改善而做出的权衡取舍。正如人们可能自欺欺人地认为自己始终产生积极影响，同样也可能误以为自己造成负面影响。不过后者往往代价更高昂——这对于那些倾向于愤世嫉俗或悲观主义的人而言，确实令人恼火……

                试图为陌生人贴上正负面影响的标签通常毫无意义，即便你掌握充分数据能论证观点。这种行为或许具有宣泄作用——试想一个截然不同的世界：那些让事情变得更糟的程序员会滚蛋去干其他不编程的工作！(我也有类似的幻想，比如编程只由那些工作之外也热爱编程的人来完成——尽管我曾与优秀工程师共事并参与招聘，他们只把编程当作工作，但他们并非我最喜欢的合作对象，其中有些人甚至远非优秀。)最理想的结果是引发自我反思，我认为这在个人层面至关重要。若察觉自己正在让世界变得更糟，且这并非思维偏差所致，那么最好停止这种行为，转而从事其他工作，或评估是否能通过其他方式弥补。我喜欢理查德·斯托曼的一段话：

                “最直接轻松的道路是投身专有软件世界，签署保密协议并承诺不帮助同行黑客……如此我本可赚取财富，甚至享受编程乐趣(只要对自身对待他人的方式视而不见)。但我深知，当职业生涯终结时，回望那些筑墙隔绝众生的岁月，我会感到自己让世界变得丑陋。”

                回复

          2. > 人生失败者

            读到如此深刻的哲学洞见令人耳目一新。

            回复

      4. Github的真实状态是：我每天使用数十次，它免费运行且毫无瑕疵，偶尔出现短暂停机。

        微软在Github上的作为远胜其多数产品。我不会为Xbox或Windows团队辩护，但Github…还行。几乎好到令人反感。

        回复

        1. > 运行完美
          > 偶发性中断

          这两点描述似乎自相矛盾。最近一次故障才发生在13天前：https://news.ycombinator.com/item?id=45915731。

          此外，开源维护者处理LLM生成的PR的案例正不断增加：https://news.ycombinator.com/item?id=46039274。GitHub本应能完美解决此问题，但很可能袖手旁观：“要么拥抱人工智能，要么退出这个行业，”Dohmke援引GitHub访谈开发者的原话写道。

          我曾协助维护一个热门开源库，对当前开源维护者面临的困境深感同情。

          回复

          1. GitHub：60%的时间里，它总能正常工作。

            回复

          2. > GitHub看似完全有能力解决这个问题，但很可能不会采取任何行动

            我真心不理解这种立场。这难道不是GitHub问题机器人存在的意义吗？无论你的仓库托管在何处，你都必须承担起管理责任。

            停机问题确实存在，我开玩笑提过这事。除此之外毫无怨言。只要GitHub能提供99.999%的可用性，我会用到它彻底崩溃为止。

            回复

        2. 我也这么认为。若有人讨厌微软，GitHub绝对是最不该开启理想主义冒险的地方。

          我不使用Azure或Windows。工作中我抵制Teams，并积极劝说客户远离微软产品。原因甚至与意识形态无关——他们的产品大多糟糕透顶，开发支持也差劲。Visual Studio Code或许是个例外，这点我承认。

          回复

        3. 鉴于微软产品的演变轨迹，GitHub的前景确实充满变数。况且Git本质上只是托管平台，任何有实力的软件公司都能复制；平台背后的团队比平台本身更关键。

          回复

          1. 作为深谙GitHub数据模型的从业者，我认为技术上替换它绝非易事。

            但即便如此，你说的没错——社交声望与隐性信任构筑的护城河，终究比技术实现的护城河更有价值。

            回复

        4. 既然你在那里贡献代码，说明你接受双重认证对吧？

          那么——若你无法接受呢？你能做什么？

          > 几乎令人反感的可用性

          我觉得你混淆了两个概念。其一是GitHub的可用性，其二是控制权。究竟在什么节点你会对私营企业的行为产生抵触？顺便说一句，这并非仅针对微软。

          回复

          1. > 所以你接受双重认证对吧？

            当然。你不接受吗？这是防范供应链攻击最有效的措施之一。GitHub的双重认证还支持非硬件密钥，既能保护隐私又能保持良好体验。

            回复

            1. 几年前我最后一次查看时，GitHub的双重认证其实存在大量粗糙的陷阱。相关GH问题单下堆积着海量评论。

              例如即使注册了安全密钥等多重验证方式，也无法移除/删除手机号码验证。

              回复

        5. > 间歇性服务中断

          中断频率已从“几乎每周五一次”升级为“每周数次”。

          回复

        6. …目前如此…但问题频率明显攀升，尤其在GitHub Actions中，且多数故障不会显示在状态页面——因为它们过于随机 (例如重启CI管道就能恢复)这感觉就像Github正在从内部缓慢腐烂，我猜原因在于所有人都被迫投入毫无意义的AI功能开发，导致真正重要的功能维护工作无人问津。

          回复

      5. > 他们是消沉的打卡族，对自己的手艺毫无热忱。

        有趣的是，根据格维斯原则的定义，这恰恰与“失败者”同义。这反倒让“失败者”这个称呼听起来没那么侮辱人(更像是现实主义者)。

        回复

    2. 我确信这并非针对所有GitHub员工，但若能委婉地批评决策者会更得体。不过这些沮丧情绪确实真实存在。

      回复

    3. 那个宣布全面禁止LLM生成代码的项目，在其他方面也表现得情绪化又幼稚，这难道不令人惊讶吗？

      回复

      1. 全面禁止LLM生成的代码完全合理。若连代码都不愿亲手编写，凭什么要求他人费心阅读，更遑论合并？

        回复

      2. 拒绝审查和维护他人懒得亲手编写的代码，这算幼稚？

        回复

        1. 拒绝代码不是基于其价值，而是基于其来源，这才是幼稚。

          回复

          1. 我认为大多数人都完全认同。

            人们不喜欢LLM提交请求的原因通常是：

            a. 提交请求者通常缺乏充分背景，这使得沟通和反馈(这些至关重要)变得困难甚至不可能。他们甚至无法阐明所提改动的逻辑依据；b. 提交量/规模常超出人工审核的承受范围；c. PR未必针对具体问题，而是作者或LLM突发奇想的产物，更难理解其背景；d. 成本不对称性普遍对维护者极为不利。

            目前，LLM驱动的PR频繁呈现上述特征，人们便以“禁止LLM”作为简化表述——毕竟撰写冗长的政策文件来阐述软件开发参与的基本准则既繁琐又无必要。然而到了2025年，当所有人都似乎放弃这些原则，只因技术可行就懒散地生成无尽的无用代码时，我们却不得不面对这个现实。

            回复

          2. 但要判断其价值，维护者必须先投入时间审阅PR。

            大型语言模型将创建可信拉取请求的难度降至近乎为零。要求人类编写代码本身就是一个重要指标：A. 该PR至少具备一定技术价值；B. 提交者对代码足够重视，才会特意撰写PR。

            回复

          3. 利用LLM生成代码完全可行——只要 经过仔细审查、迭代和测试 ，就能产出可运行且可维护的代码。

            但公开GitHub项目中提交的PR里，绝大多数LLM生成的代码并非如此——看看他们举的例子就知道了。

            若仅凭代码质量就逐行审查并驳回，将耗费大量本可用于项目改进的时间精力。另一种方案是全面禁止LLM生成的代码——这种做法执行起来轻松得多，因为无需阅读堆积如山的无用代码。

            回复

          4. > 拒绝代码不是基于其价值而是基于来源，这很幼稚。

            不，这其实是相当标准的法律政策。

            回复

          5. 布兰多利尼定律

            通常我讨厌引用“定律”，但想想看。我确实认同如果我们能仔细审查1万多行代码来带来重大改变会很棒，但这真的可行吗？

            回复

        2. 这种论点显然站不住脚。尤其当其中一个例子仅有7个字符的差异时。

          但完全可以这样说：“这个PR对我毫无意义，请详细说明”然后关闭它。

          回复

      3. 我看不出两者有何关联。全面禁止LLM生成的代码至少可视为一项合理政策。

        回复

        1. > 全面禁止LLM生成的代码至少可视为一项合理政策。

          不，我认为并非如此。这场辩论远比“全面禁用LLM代码”或“所有功能都靠AI编码”更复杂。

          全面禁止未经审核的LLM代码是规避批量低质PR的合理手段，但禁止所有LLM生成的代码则不合理。此举不仅难以执行，更会损害真正从中获益者的权益。只要作者在提交PR前仔细审核代码并承担相应责任，便不存在问题。

          回复

          1. 全面禁止LLM代码并不意味着他们持如此非黑即白的立场。例如“所有代码必须100%测试覆盖”与“测试纯属浪费时间”之间存在微妙差异，但这并不意味着采纳其中某项政策的项目就否定中间立场。

            回复

          2. 全面禁令实为唯一明智之举，可避免双方时间浪费——贡献者事先知晓AI生成的PR毫无通过可能，便不会徒劳提交；项目维护者也不必耗费精力审查可能存在缺陷的AI垃圾代码(即便从质量角度看，某些AI生成的PR本可接受)。

            一旦存在灰色地带，就会引发大量无谓争论，比如“为什么这个AI生成的PR被接受而我的没有”等等…

            回复

            1. 或许你误解了我的观点。我并非主张采用氛围编码的AI生成PR，而且我确实认为基于你所述理由全面禁止是相当合理的。

              但我不认为全面禁止所有AI生成的代码合理。在手动编写的PR中，让大型语言模型生成几个函数或少量模板代码，若确实有益，就不应因此拒绝接受。

              回复

      4. 基于我用大型语言模型处理编译器相关工作的经验，我认为这是个非常明智的决定。

        例如LLM总会抓住机会用正则表达式处理所有任务，而非执行正确的词法分析/语法解析。你需要反复告诫它避免使用正则表达式。最终你可能不如手写代码，因为你真正理解其工作原理，而LLM对此一无所知。

        回复

      5. 难怪他们转战Codeberg。这类项目总爱搬家，理由五花八门。若要打个比方，Codeberg就像Kick，而Github更像Twitch。

        回复

        1. 纯度测试。他们公告开篇第一句就扯政治呢。

          回复

    4. 还有什么不酷？在GitHub工作！

      说正经的：我可能不会把GitHub所有现任员工都称为“失败者”，但更重要的是，真正酷的人不会用某个特定时刻的工作地点来定义自己。我确信GitHub绝大多数员工只是靠技术谋生的普通人，根本不在乎Zig那家伙是否觉得他们酷。真正重要的是：GitHub本质上是微软为自身目的运营的庞大中心化平台，摆脱它才是好事。

      回复

    5. 天啊，Zig社区里有些人的毒性简直爆表。由此推断，这个社区本身也存在亟待解决的问题。

      这些人——包括创始人——不仅在Rust讨论区胡乱发帖，现在又毫无理由地在这里攻击Github的优秀工程师。

      老天爷啊。

      编辑：此文出自创始人Andrew之手。整个文化从上到下都腐烂了。

      回复

      1. 他们的“社区副总裁”早在2020年就写过这篇：https://kristoff.it/blog/addio-redis/ 我直到2022年才看到。尽管如此，这篇及其他作者的文字仍让我确信Zig社区充斥着傻瓜。这倒无妨——我本身也偏爱幼稚幽默，偶尔也会犯傻——但该帖中刻意标注的夸张闹剧形式实在诡异，令人不愿与之互动。不过为了更公平地评价作者和社区——尤其关于这次GitHub迁移——他更严肃的文章确实更出色：https://kristoff.it/blog/the-open-source-game/(2021年)。文中甚至对Rust语言及其社区给予了正面评价。他在文中阐明了“创造令人心动的软件”这一核心理念，并指出“科技巨头”与“开源阵营”这类标签体系无法真正契合这一追求。GitHub迁移实属必然——它早已不再是众人心仪的平台(当然仍有拥趸)，这种标签体系显然制造了紧张关系。(不过Codeberg是否更值得喜爱尚难定论。我使用的几个库已迁移至此，至少运行正常，但他们使用Anubis系统令人困扰，我多次收到“内部服务器错误：管理员配置Anubis失误”的故障页面。这确实无法让我感到愉悦。)

        回复

      2. 有人称呼某个不明身份的匿名企业团体为“失败者”，他们正积极参与产品的糟糕化改造。而你却称那个特定的私人个体为“腐朽之徒”。

        此刻我正对着太阳穴使劲掰手指。

        回复

        1. 请通读整个讨论串。其他评论者提供了超过二十个链接，记录了安德鲁本人的言论和霸凌行为。

          这不过是他第无数次发表此类言论。他过去曾为此道歉并承诺改变，但显然毫无效果。

          他和莱纳斯一样是个混蛋和霸凌者。

          正是这个人在Zig制定文化准则，这无疑是为何本帖有五人对我发表恐同言论的原因。他的社群因此变得肆无忌惮。

          当领袖公然违反行为准则攻击他人时，整个环境就会沦为各种仇恨与恶劣行为的温床。

          完全有毒。

          安德鲁此刻应该已经读过这个帖子了。他完全有机会反思人们所说的那些可怕言论。现在轮到他出招了。

          回复

          1. 而这种认知竟足以成为将某人定性为“腐朽”的借口。以你标榜的道德敏锐度而言。

            其他人都在谴责。即便不同意，多数人至少能理解这种谴责。你却直接贴上“腐朽”标签。搞什么鬼啊。

            回复

            1. 好好学学这个成语吧。它常用来形容领导层糟糕的科技公司和组织：

              https://www.theidioms.com/fish-rots-from-the-head-down/

              https://www.phrases.org.uk/meanings/fish-rot-from-the-head-d…

              该成语在新闻报道中使用广泛：

              https://thehill.com/opinion/white-house/373487-the-white-hou…

              https://www.project-syndicate.org/commentary/xi-jinping-chin…

              这意味着Zig文化正被安德鲁毒害。

              他是领袖，众人皆仰仗于他。若他行为如混蛋，却鲜有人指正或追究其责任，其他人便会认为这无可厚非。于是你看到社区其他成员也开始效仿这种行径。

              有毒的文化滋生有毒的行为与人。

              其他开源社区不会出现这种情况。

              正如我所言：“烂头烂尾”，这个成语用得恰如其分。

              回复

              1. 哇，你居然还在用说教来辩解，声称自己的言论应当被善意解读——在这种情况下！更甚者，竟拿两个将孩子与父母分离、把人关进劳改营的独裁者来作比较。

                继续相信自己具备道德标杆和情感洞察力，好将你的评判强加于人吧。

                回复

                1. 本帖已充分揭示他的惯常行径，若你缺乏理解的同理心，那便是你的问题。

                  他是个欺凌者，而你为这种行为辩护，就是在助长这种欺凌。

                  回复

                  1. 你甚至不了解我对此事的看法，就用“以牙还牙”的谬论指责我，只因我揭露了你回应中的讽刺之处——你竟用道德优越感的伪装掩盖个人攻击性。我将不再参与本讨论，祝你与这份痛苦共处，但愿你能找到积极的创造性方式来缓解它。

                    回复

      3. 你指控我“在Rust讨论区胡言乱语”。你有什么证据支持这种诽谤？

        回复

          1. 我无法想象成为安德鲁这样的人，或是任何热门开源项目的BDFL，还要应对这类人。试想在讨论某语言编译器低效的帖子中，你贴出自家编译器的计时输出结果，却被人指责这是不当行为。

            抛开这篇帖子本身的荒谬性不谈，称呼他人为猴子终究是不恰当的。我无意评判他们的工程质量。但他们也是人啊！希望Zig团队能展现出沉静的尊严。他们创造了如此卓越的成果，目睹软件应有的高度却与现实差距悬殊，想必令人沮丧。但善良永远是解决之道。

            感谢所有参与Zig开发的人，感谢你们对软件的热爱与付出！

            回复

            1. > 试想在讨论某语言编译器低效的帖子中，你贴出自家编译器的计时输出结果，却有人指责这是恶劣行径。

              这帖子的 全部 贡献就是炫耀。此类行径由来已久。

              开源贡献本应如此，但这显然不是。

              > 抛开这篇帖子本身的荒谬性不谈，称呼他人为猴子终究不可取。

              你难道看不出来两者有何关联？

              回复

          2. 开发者将与Rust功能重叠的编程语言进行比较完全合理，即便这种比较会让该语言显得逊色。事实上，这对正在使用Rust并考虑转用Zig(或反之)的开发者，以及初次接触这两种语言并试图确定哪种更适合自身场景的人来说，都是有价值的信息。

            回复

            1. 你似乎在这条讨论中制造了大量干扰。

              链接消息的语气有何不妥之处？

              回复

              1. 链接消息的语气有何不妥之处？Rust是编程语言而非神圣之物。无论是否为该语言开发者，指出其他语言在特定领域表现更优皆属合理。

                需要说明的是，我喜欢Rust并频繁使用它，使用时间几乎与它公开发布的时间相当；而我对Zig只是略作尝试，即使它功能完备后，我估计也不会像喜欢Rust那样喜欢它。但我反对强行推行“指出Rust缺陷即为错误”的社会规范，尤其当这种规范针对的是那些在系统编程语言设计领域开拓Rust未涉足疆域的探索者——他们从事着极具价值且富有创意的工作。

                回复

    6. 天哪！可怜的微软工蜂们！我得用世界上最小的提琴为他们奏哀歌，听他们倒数股票归属的日子。

      回复

    7. 你这种缺乏依据的断言，恐怕算不上对讨论的实质性贡献。munchler，你为何认为这不酷？

      回复

      1. 这是欺凌行为。

        让我想起学校里那些混蛋——他们揍我、把我塞进储物柜、企图袭击我。

        小时候我差点自杀，就是因为这些欺凌者。有些人似乎永远长不大。

        回复

        1. Ziglang是靠捐款维持的小组织，微软可是全球最大企业之一。要说谁在欺负谁，他们才是在挑战高位者。

          骂人失败者确实没品，但要是我是高薪微软员工，听到某个靠社区资助的纯粹主义者这么骂我，我绝对会笑到银行存钱。如果这算欺凌，那他可真不擅长。

          回复

          1. 他们攻击的不是微软公司。

            他们攻击的是某个团队的员工——这些人的自由度和自主权远不及Ziglang的独立承包商。

            在FAANG公司的薪酬体系中，微软处于较低水平。我做过好几份工作，税前收入都比微软员工高。

            回复

        2. 嗯，这说法似乎合理。可惜munchler没能提出类似观点。但现在Reddit用户似乎正集体围攻这位安德鲁？他看到这个讨论串时想必也会有同感吧？解决霸凌问题难道只能用更多霸凌？

          无论如何，我很难想象会有多少读者对一篇长篇大论——关于安德鲁是何等糟糕的人——产生浓厚的智力兴趣。

          回复

  11. > 感谢Forgejo的贡献者们协助我们解决迁移平台时遇到的问题，也感谢Codeberg团队成员在迁移过程中给予的支持——特别是厄尔·沃伦、奥托、古斯特德和马蒂厄·芬尼亚克。

    对我而言，这段话比帖中其他内容更具分量。Forgejo/Codeberg存在真正关心自身工作的人，这本身就是无价之宝。

    回复

    1. 据我所见，许多自由软件社区都如此。

      回复

  12. 看到这次迁移实现令我振奋，主要因为它向我们(https://tangled.org)传递了重要信号：大型项目确实愿意转型！我们正全力推动Tangled脱离测试阶段——它将成为自由软件社区的理想归宿。

    近期还撰文阐述了我们对独立开发者和社区的愿景与承诺(绝不服务企业！)：https://anirudh.fi/future

    回复

    1. 附注：Bluesky PDS配置允许单块上传上限100MB。或许可将其作为发布工件的托管媒介？网页界面或许能合并多个块，处理超过100MB的大型发布文件(若使用默认配置的PDS则上限为15MB，Tangled实例似乎采用此配置)

      回复

    2. > 使用Jujutsu变更ID堆叠拉取请求。

      现在我非常感兴趣，一定会尝试。

      回复

  13. 这个决定相当值得商榷。

    你正在运营一个志在成为主流的编程语言——请将其置于用户期待的位置，并接受平台带来的种种不便。

    零售业中，你会在客流量最大的商场开设店铺——当然你可以选择偏僻巷弄，但别指望顾客会主动上门。即便商场忘了拖地，这个道理依然成立。

    这种做法显得不够成熟，令人对项目/语言领导层缺乏信心。

    回复

    1. > 你正在运营一种旨在成为主流的编程语言——请将其置于人们预期的位置，并接受平台带来的种种不便。

      核心用户群体——那些将使用、贡献或以其他方式参与该仓库的人——很可能并不需要它托管在GitHub上。选择“人们预期所在的位置”或许能吸引路过贡献者，但Zig语言其实并不需要这种流量。

      更重要的是，我们这个庞大的社区为何要向GitHub和微软让步？除非有更强大的力量推动变革，否则现状不会改变。

      回复

    2. 以上论点并非要求必须使用特定平台。将GitHub设为默认/强制平台，实则是整个科技行业的单点故障。

      以Go语言为例，它成功避免了与GitHub的完全绑定：核心代码托管和CI交互运行在Gerrit实例上，仅部分内容与GitHub进行双向同步。

      Zig帖子中提及的CI痛点和运维盲区完全真实存在。

      回复

      1. 没错，但营销对Zig至关重要——它仍在努力争取显著的市场认知度。

        Zig需要展现更主流的姿态而非更小众，对源代码托管平台的技术抱怨不应凌驾于营销考量之上。

        回复

        1. 或许吧，但现在谈主流是否为时尚早？在语言和标准库达到1.0版本前，Zig似乎更适合早期采用者。过多错误类型的用户只会让所有人感到沮丧。

          回复

        2. 也许我们的视角有误。这恰恰是他们想要的市场认知度。

          那些看到糟糕代码就暴跳如雷的人，甚至会骂开发者是走狗和猴子。

          而一个代码库不必托管在主流服务器上，反而能精准吸引认同这种选择的群体。

          回复

        3. 当人们意识到“嘿，这是个不在GitHub上的编程语言”时，营销和曝光度反而会更好。

          回复

    3. 这只是个公开的Git仓库和问题追踪器，又不是什么该死的“店面”。人们不会因为Zig的源代码托管在GitHub而非其他随机网址就“发现”它(况且提交bug报告或PR的流程和GH完全一致：https://codeberg.org/ziglang/zig)。

      回复

    4. > 这显得不够成熟，让人对项目/语言领导层缺乏信心。

      所以如今做出艰难决定就算不成熟了哈哈。

      > 商场老板忘了拖地

      我倒觉得这算粉饰太平。

      回复

    5. 宣传口号虽有争议，但强化开源替代方案以对抗微软近乎垄断的局面，这本身相当不错。

      或许人们该停止期待所有源代码都必须基于微软平台？

      回复

    6. 我认为这反映了更广泛的文化问题——人人都对所有事物抱持强烈立场，而非选择性地投入战斗

      倒不是说我完全反对他们的逻辑，但执着于对核心“使命”抱持强烈情感？总觉得有些“不稳重”。很难想象Java或Python等主流语言会出现这种情况

      回复

    7. 对于拥有一定规模受众和关注度的成熟项目，托管在何处其实影响不大。Zig正是如此。人们早已知晓Zig的存在。大量成熟项目从未使用GitHub(有些迁移过，有些从未用过)，它们运行得很好。

      回复

    8. 这终究是编程语言而非终端用户工具。那些因GitHub托管而受益的群体，与实际接触代码源的开发者群体几乎毫无交集。

      回复

      1. 这甚至可能减少低质量PR的数量。

        回复

    9. 所谓“人们”指谁？美国用户吗？在我所在地区，使用非GitHub平台反而是好事。SQLite在没有GitHub支持下运作良好，我不明白为何认为Zig会不同。不过关于成熟度问题我倒不完全反对你的观点——毕竟SQLite也有官方GitHub镜像。即便不想费心处理这些，也有很多方式可以讨论技术问题而不必贬低他人。

      回复

    10. 呃。他们的表述确实不够成熟，但没必要非得追随主流——尤其当贡献者数量有限而非数百万时。

      Git取代Mercurial实属不幸，而GitHub胜出更是雪上加霜。GitHub的代码审查/PR界面简直不堪入目。十五年前我们就有更优秀的工具，而GitHub至今仍是退步之作。只要愿意付出使用替代方案的代价，离开它的理由多得是。

      回复

      1. 好奇他们为何不选Sourcehut？或者说他们是否曾用过？

        回复

        1. 我更困惑的是为何选择Codeberg而非自建Forgejo/Gitea实例？虽然我也讨厌GitHub，但这股盲目追随Codeberg的潮流实在令人费解。总该有比在中心化Git托管服务间跳来跳去更明智的选择吧。

          回复

    11. 啊对，我逛商场时总会寻找大型战锤40K专卖店。

      回复

    12. 深表赞同。除非出现可靠的替代方案，否则我通常会回避非GitHub的项目。令人惊讶的是主流Linux发行版至今未建立替代平台。若几家大厂决定自建托管服务，资金支持肯定更充足。Ubuntu虽有自有平台，但采用定制化源代码控制系统，仅服务于Ubuntu生态。

      回复

  14. 这是本周读到最振奋的消息。开源领域无需向美国巨头企业及专有代码仓库低头。希望此事能引发更广泛讨论——尤其应将Discord等平台的聊天锁定问题纳入同等议题。

    回复

  15. 撇开技术能力和Zig项目不谈，此人说话像愤怒的青少年或林纳斯模仿者。他的语气让Zig看起来像是个人独角戏，实则并非如此。

    回复

  16. 天啊——Codeberg响应超快！快得像十年前的Github。服务器端渲染页面，没有AJAX式的缓慢更新。太棒了。

    回复

    1. 这是我们(Zig团队)正式测试Codeberg时最先注意到的问题。坦白说，光是能摆脱每次点击链接都要等待3-5秒的困扰，这次迁移就值了。

      回复

      1. Codeberg当前性能欠佳——每次点击需等待12秒才更新。不确定他们能否扩展承载量。

        回复

        1. 我认为这个讨论引发了拥抱致死效应；今天早些时候我也遭遇了严重的页面加载问题，但似乎已自行解决。在我看来这很正常，毕竟Codeberg此前从未处理过如此规模的流量。随着项目需求增长(比如Zig等项目迁移过来)，我乐观地认为他们能实现扩展。

          回复

      1. GitHub简直是两头不讨好——部分内容在服务器端渲染，但前端却莫名其妙地拉取额外数据，比如…提交信息？？

        这简直是延迟的双重打击，更绝的是，如果你的浏览器稍微过时一点，提交信息就完全加载不了

        回复

      2. 确实如此。现在打开个大差异对比，趁浏览器渲染时去吃顿晚饭吧。

        我倒不讨厌GitHub，但它的界面现在比以前慢多了。

        回复

  17. 我基本认可Zig的优点，但这篇帖子确实显得刻薄无谓。我同样不喜欢微软和GitHub，但没必要对在那里工作的开发者冷嘲热讽。

    回复

    1. 最新消息：某软件工程师具备开发新语言的动力与技能，却奇特地缺乏公关和营销能力。更多详情请关注11点新闻。

      回复

      1. 无论是否意外，都改变不了我的观点。

        不过这次确实有点意外。Andrew向来是个相当友善的人，曾竭力打造包容性强的社区。Zig基金会还有负责公关的Loris，本可由他代笔而非Andrew。

        最后，这种刻板印象简直荒谬。软件界有太多友善且善于表达的人。

        回复

        1. 本质上就是把关行为。只欢迎神经典型者！安德鲁本可将发言权交给擅长公关的人？当然可以。但这正是人们放弃并陷入倦怠的原因。

          我完全接受极客偶尔在网上流露情感。

          身为企业员工，我必须管理好自己的言行。我用大型语言模型来处理这些。很高兴安德鲁有个无需顾虑的空间。

          回复

  18. 你把GitHub团队叫作“猴子”和“菜鸟”，最后还“谦卑”地请求人们捐款？看到这实在令人沮丧。

    我曾经很敬重Zig团队……

    回复

    1. “菜鸟”是编辑后的说法——他原本用了“失败者”

      回复

  19. 能有替代方案来对抗巨头企业对生态系统的掌控是好事。

    微软掌控GitHub固然是个问题，但类似现象正蔓延至其他领域：Shopify对Ruby生态施压，最终导致众多贡献者(尤其通过gem和bundler贡献者)被RubyCentral(在Shopify指令与影响下)拒之门外。此类案例不胜枚举。关键在于金钱能换取影响力，最终决定谁能参与贡献以及参与方式。Python强制所有开发者启用双因素认证便是例证——仅贡献代码的业余爱好者实际毫无收益，而企业却将更多“安全责任”转嫁给无偿贡献者。

    回复

  20. 典型案例A是GitHub用户joelreymont，其似乎已将此类行为常态化。他在OCaml项目中也提交过极其相似的垃圾PR：github.com/ocaml/ocaml/pull/14369

    回复

    1. 这让我想起彼得·瓦茨的《盲视》。外星人将我们的无线电信号视为一种恶意软件——旨在消耗接收方资源却毫无回报，反而降低生存适应性。眼前这幕如出一辙。

      回复

    2. 简直疯了。看看joelreymont最近在GitHub的活动，简直是人工智能垃圾PR的炸弹——成千上万的修改、AI生成的摘要/注释、版权问题，应有尽有。

      这类人正在毁掉开源生态，可怜的维护者们不得不费尽心力清理这些垃圾。

      回复

      1. 你能怎么办？别指望靠正义感和道德感实现自我审查。我视joelreymonts为开创者，正在搭建切斯特顿式的围栏。任他胡来吧！

        回复

  21. 这些论点…实在站不住脚？他们只是随意引用某个冷门漏洞，以及某个容器不支持的冷门操作系统(我猜解决方案就是“自带运行器”)。

    我对Zig领导层有些…疑问

    回复

    1. > 支持度不高的操作系统

      信不信由你，除了三大主流之外还有其他平台。

      GitHub Actions运行器无法在FreeBSD、NetBSD、OpenBSD和illumos上运行——而这些操作系统我们要么已提供支持，要么即将正式支持。(我们已实现FreeBSD持续集成；其他三者的运行机器恰好明天就要送到我这儿。)

      更别提CPU架构限制：上游GitHub Actions运行器仅支持x86和aarch64。我们不得不维护分支版本，为其他重要架构(如riscv、loongarch、s390x等)添加支持。未来还可能加入mips64和powerpc64架构。

      就连IBM也必须维护s390x分支，因为微软根本懒得接受添加新平台的PR：https://github.com/uweigand/runner

      回复

      1. 我们已经有了FreeBSD的持续集成环境；另外三种系统的机器恰好明天就要送到我这里了。

        太好了。希望一切顺利，也希望你们能为NetBSD、OpenBSD和illumos搭建持续集成环境。

        Go语言对NetBSD的支持极大便利了那些无意维护端口的普通用户。这意味着你使用的任意Go开源项目很可能已兼容NetBSD，即便存在兼容性问题也能在上游修复。或许Zig也能发挥类似作用。

        遗憾的是GitHub连x86-64架构的FreeBSD都未提供原生CI支持。当然我理解其背后的经济考量。不过第三方跨平台GitHub Action(https://github.com/cross-platform-actions/action)已使Free/Net/OpenBSD的CI对我而言切实可行。我已在多个项目中使用该工具。开发者目前正致力于为OmniOS提供支持(详见https://github.com/cross-platform-actions/omnios-builder)。

        回复

        1. > Go对NetBSD的支持对那些无意维护端口的普通NetBSD用户而言是重大福音。这意味着你使用的任意Go开源项目很可能已能在NetBSD上运行，即使存在兼容性问题也能在上游修复。或许Zig也能发挥类似作用。

          事实上，我们已为NetBSD(及FreeBSD)提供交叉编译支持。但目前仅通过在Linux上构建语言行为测试和标准库测试来“测试”NetBSD环境——即未实际运行这些测试，也未为NetBSD构建编译器本身。原生CI机器将填补这一空白。

          巧合的是，Go语言的交叉编译支持确实简化了CI机器的配置工作——我们只需在一台机器上构建Forgejo Runner即可支持所有机器：https://codeberg.org/ziglang/runner/releases/tag/v12.0.0

          回复

    2. > 他们只是链接到某个随机罕见的错误

      这是他们遇到的、已提交报告、附有根本原因描述且尚未修复的缺陷。这个缺陷浪费了他们的时间和金钱。

      回复

    3. 理由必须充分吗？我认为他们无需提供任何依据。若核心开发者认定更换服务商能让他们更满意(或减少痛苦)，那就随他们去吧。

      回复

      1. 若非如此，何必纠缠？

        “因微软商业行为而拒绝其托管服务”完全是合理诉求，无需从漏洞追踪器里挑刺来证明正当性

        回复

    4. 我的意思是，若他们持续遭遇该漏洞，其罕见程度还有意义吗？若某工具对我个人而言存在缺陷，我也会立即弃用——完全不考虑它对他人是否正常运作。

      回复

  22. 其实我对Zig语言没什么好感，甚至可以说不喜欢这门语言。但不得不承认这是个大胆的举措，开源项目理应鼓励此类行动。

    回复

  23. 我已将项目同时托管在Github和Codeberg一段时间，并在README中添加说明[1]。我向Codeberg捐款，运行自建的forgejo runner执行动作，并在两个平台维护大量测试。

    代码推送到Github后，动作会自动镜像到Codeberg。

    我本想完全迁移，但现实是几乎所有人都在Github而无人使用Codeberg，且过去一年Codeberg的故障率远高于Github。

    这个领域确实需要优秀的工具来简化多代码托管平台的协作，避免过度集中化。希望更多项目离开Github能推动这一进程，让更多人参与到其他平台的建设中。

    [1] https://codeberg.org/arcuru/eidetica#repository

    回复

    1. 你认为现有工具在哪些方面存在不足？

      我认为分布式Git本身并不存在太多阻力，它本就是最易实现多远程仓库的工具之一。辅助工具也全开源，无论是自建服务还是托管平台提供服务都无障碍。

      托管平台的社交属性大概率无法分布式实现，这基本是GitHub唯一的差异化优势。

      回复

      1. 我认为楼主的意思是：当n个仓库乘以m个主机时，将产生n×m个不同步的资产，且需要大量人工维护同步状态。

        若推出托管更新服务，可在复制时处理冲突并触发错误提示。若将其命名为“代理式”服务，或许能获得7500万美元融资。

        回复

  24. 20万美元的GitHub企业版“与ICE的关系”？

    ICE在唐恩都乐的消费肯定超过20万美元，难道他们也算关系户？

    回复

  25. Coderberg不错，但他们的P80性能糟糕。而且服务器托管在德国，每次远程命令都要多耗几秒。

    我不会把业务关键型仓库迁移到那里。

    每隔两年GitHub出一次故障，大家就会集体崩溃。如果Codeberg提供服务等级协议，他们大概每周都会违约。

    回复

    1. 真希望GitHub也能做到两年才出一次故障，那该多好！我们工作中每周——甚至几乎每天——都会遇到问题。个人更倾向自建GitLab。相比GitHub Actions，我更欣赏他们的管道功能。

      回复

      1. 我们公司确实部署了本地GitLab(终极版)，总体体验不错，每日活跃用户约100人。

        私有项目方面，Forgejo几乎满足所有需求且维护工作量极低。

        回复

      2. 遗憾的是，我认为GitLab也在走向平庸化，忙着添加LLM垃圾功能却不提升开发者体验…

        回复

        1. 这消息真令人沮丧。我上次用GitLab还是2021年，当时体验相当不错。不过这种变化倒也不难理解——GitLab前CTO/CPO现在在OpenAI担任CRO。这种人事变动绝非偶然。我曾在前公司与此人共事，当时他就极具破坏性，所以GitLab聘用他时我就很担心。

          回复

    2. 每两年？如今GitHub Actions或Git操作简直是两天一次的节奏 🙁

      回复

    3. > 服务器还设在德国，每次远程命令都要多耗几秒

      除非你住在德国。天啊，我们偶尔能有次不错的延迟就谢天谢地了 🙂

      回复

      1. 跨大西洋的GitHub响应P80值依然更优

        回复

    4. “P80s”指什么？根据上下文，我怀疑这既不是指矿物加工用的筛网，也不是指自制枪械——搜索结果前几页全是这些内容。

      回复

      1. 他们大概指响应时间分布的80百分位？通常讨论的是P95或P99指标

        回复

    5. > 当GitHub每两年才崩溃一次

      呃…更像是每两周就会出点状况。

      回复

  26. 正是这种措辞会破坏任何宠儿效应，让你意识到那个你寄予厚望、希望改变世界的特殊项目，其实是由孩子在运营。

    回复

  27. 这是非常明智的举措，采用更开放的技术从长远来看对所有人都有利。

    撇开对Github的尖锐批评不谈(我看到评论者竟忽略了与ICE合作这类危及人命的现实后果)，使用Codeberg就是使用Forgejo：这些技术由我们创造，为我们服务。不同于Github，必要时我们可以自主运营，所有技术(包括操作流程等)都能持续改进并在我们之间共享。

    Forgejo/Codeberg的另一优势在于不存在强制付费机制——Github并非免费，用户数据将流向Azure/Gemini等微软服务。其诸多设计都暗藏诱导用户不断付费的陷阱，最终形成供应商锁定。

    我追求生活中的黑暗模式尽可能少，而Codeberg对此极具助益。

    回复

  28. 我并非完全反对这些观点(尤其Actions确实是个不稳定的垃圾)，但看到Zig项目负责人使用这种措辞实在令人沮丧。若我正在捐款，未来会重新考虑对Zig基金会的支持。

    回复

  29. 所以现在我们把同行程序员都当猴子和失败者了？

    回复

        1. 不，我二十年来亲历他们如何对IT界乃至全人类摆出嚣张混蛋的姿态。

          回复

            1. 每个员工都甘愿为微软这样的公司效力。所以，是的。

              回复

  30. 若仅视此为托管服务切换，便忽略了全局视野。这是Zig“零依赖”哲学在逻辑基础设施层面的必然结论。

    Zig耗费数年摆脱对系统C编译器(zig cc)的依赖，消除对libc库的依赖，目前正致力于摆脱对LLVM(自托管后端)的依赖。

    GitHub不过是又一项依赖。

    对于一个痴迷于可复现性与工具链主权的项目而言，依赖单一专有平台(及其不断变化的服务条款/AI政策)是巨大的架构隐患。他们不仅在迁移仓库，更是在消除“平台风险”——正如当年消除“链接器风险”那样。

    回复

    1. 坦白说这是个有价值的见解，我之前忽略了。

      Zig团队或许应该以这种方式撰文阐述。

      回复

  31. 此前我从未真正抽身审视将GitHub作为平台使用的利弊，但完全认同本文观点。

    虽然我认同更分散的仓库环境理念，但会怀念GitHub提供的项目发现功能、社交属性及集中化管理。短期内可能不会切换平台，但终将做出改变。

    回复

    1. 顺便说一句，他们正在实现联合仓库机制，这能在去中心化的基础上恢复部分集中化功能

      回复

    2. 这些特性你都不必舍弃。

      过去五年间我的绝大多数提交(无论工作或个人项目)都不在GitHub上，但这并不意味着我没有GitHub账号——我仍会偶尔用它为托管在GitHub的第三方项目提交问题报告或合并请求。

      GitHub只是不再是我首选的平台。

      回复

  32. 这简直是Codeberg的广告——效果拔群，我立刻注册了账号

    不过消息措辞可以更友善些。我认同内容本身，但不赞同表达方式。

    回复

  33. 在这个行业里，多数人对工作成果的期待不过是充实信托基金和支付账单，能见到既坚持原则又勇于践行的人，令人耳目一新。

    回复

  34. 可惜GitHub仓库未设置镜像，可能导致下游项目无法正常工作。

    不过这仍是明智之举。

    回复

    1. 只需简单执行git remote set-url即可修复，除非你使用了GitHub专有API——这正是他们试图规避的供应商锁定问题。

      回复

    2. 这迫使人们将获取URL更新至权威仓库，实属好事。

      回复

  35. 对此我深感欣慰，希望这能推动软件摆脱巨头控制的大趋势。我也得把项目迁出GitHub，以免显得虚伪 🙂

    回复

  36. 这篇帖子令人作呕，让我对Zig的评价大打折扣。称呼他人为失败者和猴子既不专业也毫无必要。

    回复

  37. 我没读完整篇讨论，但从标题判断，这不过是更多开源维护者在互相辱骂的闹剧。

    各位，我们必须停止这种无谓争执。没有人是完美的——你不是，我不是，任何人都不是。某个脚本确实可能出自实习生之手，运行时存在瑕疵。这完全可能。但这就能断定他们是糟糕的实习生吗？

    正如我反复告诫他人的那样：在技术领域，共情能力至关重要。作为曾经也这样对待他人的自闭症患者，如今看到这类言论同样令我反感，甚至完全不想听对方后续的任何发言。

    请给予他人宽容，修复问题，继续前行。这正是开源开发的魅力所在。提交补丁、联系维护者、开启对话、进行良性交流。别为了发泄就对人恶语相向，哪怕对方确实做了“蠢事”。

    我保证，这样做对我们所有人都有益。

    回复

  38. > 可悲的是，当它被微软收购时，倒计时便已开始。“求求你，给我五年时间再让一切崩坏吧，”我暗自祈祷。七年后的今天，我们仍在借来的时光里苟延残喘。

    老天，有时我感觉自己活在另一个星球。自2010年使用GitHub以来——虽然真希望有更委婉的表达方式——我完全记不起其旗舰产品曾有过不集体沦为行业垫底或接近垫底的时期。代码审查/PR、问题跟踪、代码搜索、CI、真正的企业级方案，乃至如今的人工智能功能——所有这些服务都存在足以催生真正威胁性新秀的严重缺陷，而其中某些新秀本身已成长为上市公司。说真的，从2013年到(比如)2019年，一条切实可行的IPO路径就是“打造一个不那么糟糕的GitHub功能版本”。

    2010年我曾深爱GitHub。但同样记得2013至2019年间它几乎完全迷失方向，产品毫无实质性进展。难道只有我这么认为吗？安德鲁在此究竟在谈论什么？

    我无意为微软收购辩护，但至少——虽然慢得令人窒息——代码审查和问题跟踪等功能终于开始得到完善。说出来很荒谬，但这就是我的真实感受。

    我实在忍不住怀疑，这里所谓的产品“变质论”不过是作者事后为自己情绪找的借口。

    回复

    1. 只有用过Atlassian收购后的Bitbucket，才会觉得GitHub还不错。

      但这赞美实在太过微弱。

      回复

  39. 不知这算不算大事，但人们普遍不喜欢AI。除了被承诺忽悠的领导者，以及靠这个承诺牟利的人。

    回复

  41. 嗯，GitHub现在在微软内部隶属于AI部门；其主页上主要宣传的是Copilot；我认为托管、运行和资助代码的功能纯属偶然。

    回复

    1. 这并非偶然，而是其AI训练策略的一部分。

      回复

  42. > 剩下的失败者 > 由猴子创造

    这恰恰暴露了他们的本质，让我彻底不想使用Zig，甚至希望它失败。

    回复

  43. 我确实觉得GitHub近年产品创新力有所减弱，但成熟平台出现这种情况很正常。虽然无法判断参与开发的人才是否减少，但我注意到平台错误率并未上升，且持续保持增长。忽视维护GitHub和推出新功能(即使某些功能未必符合所有人喜好)背后的辛勤付出是不公平的。我感激GitHub并希望它持续繁荣。祝好。

    回复

  44. 嘿，我尝试点击博客顶部的Codeberg仓库链接，结果无法连接。或许是HN的拥抱致死效应？无论如何，这让后续对GitHub的批评显得格外刺耳。

    编辑：作为过去几年Zig语言的GitHub赞助者，我确实意识到需要迁移项目——或许会这么做——但实在不愿再管理另一个绑定信用卡信息的订阅账户…

    回复

  45. 若能妥善表达诉求并建立沟通渠道，我认为微软和GitHub极不可能忽视关键开源项目的修复需求。

    虽然已提交问题报告，但幕后工作仍有提升空间。

    个人观点——如今GitHub已成为全球性的文化产物。从日本到阿拉斯加乃至世界各地的极客与探索者都涌向这里。

    回复

    1. 正如我在其他评论中指出的，就连IBM都不得不维护一个支持s390x架构的GitHub Actions分支运行器，因为上游根本懒得接受相关补丁：https://github.com/uweigand/runner

      若IBM连如此细微却关键的协作都无法促成，我们更无可能。

      > 个人认为——GitHub如今已是全球性的文化产物。从日本到阿拉斯加，乃至世界各地的极客与探索者都汇聚于此。

      而它却掌握在一家推销LLM垃圾的营利公司手中。这难道不令人警醒吗！我们应当鼓励人们使用非营利组织运营的平台。

      回复

  46. 帖内竟有人为巨头企业辩护。天啊…

    回复

  48. 来这儿就看到“GitHub不再是好家伙了”(不是第一次，而且频率似乎越来越高)。

    简直是SourceForge的翻版。历史总在重演，“沦为垃圾”这个词被收进词典绝非偶然。

    作为曾经的Slashdot狂热用户，不禁担忧某天Reddit是否也会步其后尘。

    回复

    1. 我完全不认为这个网站是/.的精神继承者，其受众更关注金钱而非软件。作为曾拥有五位数积分的用户，我怀念当年的/.。

      回复

      1. 我确实认为这个网站与Slashdot存在显著重叠，当然并非完全相同。但它给我的感觉疯狂相似，仿佛时光倒流回我当年发帖的岁月。

        回复

    2. 我不确定它是否像SourceForge。SourceForge的界面向来糟糕。Github的界面相当扎实。最近我反而开始讨厌GitLab的界面，每次用GitLab都感到彻底混乱。

      回复

      1. 比起在自有服务器上安装Apache、Wiki、Roundup、CVS和Mailman，SourceForge的界面简直堪称 梦幻 。

        回复

      2. > 最近开始讨厌GitLab的界面设计。

        深有同感。所谓的界面“优化”和LLM垃圾功能，完全没有提升开发者体验

        回复

  49. 这太好笑了。讨厌微软永远不过时。看着年轻人重新发现这个梗真有意思。更搞笑的是Codeberg前端慢得要命，甚至比Github还卡。

    享受你们新发现的美德吧，Zig用户们！

    回复

    1. 现代哲学/话语中最让我反感的是，他们把“美德”这个概念描绘得荒谬可笑

      回复

  50. 哇。我觉得这是个严重的错误。或许GitHub不再那么出色和敏捷，但绝不该因此就把需要：1. 资金投入，2. 功能展示的项目迁移到某个冷门平台——仅仅因为它稍好一点。说到底它不过是带界面的Git，差异并不显著。我不在乎这篇帖子语气尖锐：从我的角度看，问题在于内容本身站不住脚。理论上这么做完全合理，但当你负责的项目——在当前阶段——已成为相当数量开发者首选的语言时， 就不能只顾个人喜好，而必须考量对项目长远发展的利弊。离开GitHub(用原文的语气来说就是开源软件这个主广场上的该死的巨大市场)对Zig有何裨益，实在难以理解。我认为更好的方案——当然并非绝对正确——是聚焦问题的 根源 。这正是开发者对工具“不符合个人偏好/认知”的典型不耐烦，这种心态在技术圈虽普遍存在，但终究只是视角问题。我指的是这种“工具导向”的工作流程——当某个微小功能/定制需求对你至关重要(而非稍作调整便不再在意)时，我认为这已成为我们行业的顽疾，更影响着众多程序员的设计哲学，使他们过度关注细节。程序员大半生都在终端中度过，而非 GitHub 上。查看问题/PR 时，根本不存在《怪奇物语》里颠倒世界的噩梦。

    另一个问题在于：你清楚自己离开什么，却无法预知新环境会遇到什么。GitHub早期常崩溃，如今虽不够灵敏，但和99%的网站一样，它也深受JavaScript框架狂潮的困扰。不过这个平台始终在线，我敢打赌它有完善的灾难恢复机制和严谨的备份策略。这些优势在其他小型平台上能如此明显地体现吗？

    回复

    1. GitHub Actions存在严重缺陷，仅此一点就构成充分的技术迁移理由：那个sleep.sh垃圾长期拖累我们的CI性能，它会定期在运行代理中引发无限循环的死锁，导致代理停止处理新任务。该代理本身还存在糟糕的平台兼容性问题，因为它依赖.NET运行时。最近GitHub Actions开始乱序执行任务，导致旧任务被饿死超时，使得PR毫无缘由地变红。

      如果CI无法正常工作，运行Zig这样的项目将面临严重问题。我们本可付费使用外部CI服务，但该服务同样依赖GitHub API——即便如此也只能换取几年时间？鉴于GitHub当前的发展轨迹，我无法相信他们能长期正确维护这些API(据我所知，当前的调度问题可能已反映在第三方CI供应商使用的API中)。

      别忘了“GitHub现在是家AI公司”。

      回复

      1. 顺带一提，当初人们也断言停止推特更新和退出Reddit会让Zig走向末路。时光流转，我们至今仍存活着，而这两个平台却已踏上通往精灵国度的最终旅程。

        它们不会明天或下个月就抵达，但我确信当年人们从Sourceforge迁移到GitHub时，也曾有人断言这是徒增风险的举动。

        就我们所知，Codeberg是致力于打造非营利代码共享平台的严肃尝试，我们对其未来充满信心，愿意为此押注。

        回复

        1. 洛里斯，我衷心祝愿Zig一切顺利。但即便Zig能生存并发展壮大(我同样期盼这两点)，我仍认为此举并非明智之选，态度亦欠妥当。但愿我判断有误，但仍想与你分享我的思考：此举既意味着远离开源市场，又将切断主要收入来源。这绝非类似于停止在推特发帖的简单行为。更贴切的类比应该是：不再在Hacker News发布任何与Zig相关的内容——就潜在后果而言。

          回复

          1. 我们引导用户通过其他渠道捐赠已有数年，因此GitHub赞助计划早已不是主要收入来源(且持续多年如此)。它仍占相当比例，但也不会一夜之间消失。

            > 若论潜在影响，更贴切的类比或许是停止在Hacker News发布任何与Zig相关的消息。

            最近我一直在思考这个问题，根据我的经验(过去Zig规模较小时，看到过HN帖子带来的影响，而现在情况不同了)，这个社区已经足够庞大且充满活力，仅凭一篇HN帖子很难产生太大影响。需要明确的是，我并不认为HN正在失去影响力(不像本讨论中早先提到的其他大型平台)，但我们的处境已经改变。

            如今人们更多是通过酷炫的Zig项目了解它，而非阅读那些泛泛而谈的语言对比博客——而这类内容恰恰最常登上HN热搜榜。

            更普遍而言，我认同你关于不应完全脱离所有创意市场的观点，但多数市场远不如其宣称的那般优秀。而我们有幸运营着一个拥有强大社区纽带的项目，这意味着即使离开GitHub，我们也不会面临关注度或贡献者匮乏的困境。

            当前局势与我们社区在聊天平台上的困境颇有相似之处，若我们恰巧在同一场技术活动现场相遇，我很乐意与你详谈细节 :^)

            回复

            1. > 这部分资金仍占相当比重，但也不会一夜之间消失。

              你既鄙视GitHub又准备离开，却打算继续通过他们的赞助功能/计划收钱？看来他们确实做对了什么……

              回复

      2. 我翻了半天才看到有人提到第三方CI。GitHub Actions的免费运行器一直很糟糕，但对预算充足的用户而言，第三方运行器生态其实相当强大。我认为其API远胜于产品其他部分——我怀疑企业客户正施压GitHub维持其可靠性。若Actions的YAML配置令人抓狂，总还有Tekton这类第三方CI可选

        回复

      3. Namespace 彻底解决了我在 GitHub Actions 遇到的所有问题。Ghostty 就是用它来构建项目的：https://namespace.so

        使用 Namespace 后，GitHub Actions 积累的冗余代码和性能浪费才显露无遗。我将GitHub Actions视为Nix的翻版：配置诡异，高度依赖shell，产出价值与投入精力成正比。但它确实足够好用。

        归根结底，GitHub Actions和Nix本质上都是shell脚本，具备相当的可移植性。我青睐Namespace是因为它解决了CI的关键痛点——比如本地高速缓存取代GitHub基于HTTP的缓存机制。

        但我也不排斥这种模式：我使用GitHub主要是看中其美观的界面和全局搜索功能。总会有人为搜索功能镜像Zig项目，而我的终端并不在乎克隆仓库的来源。这正是我们所处的全新世界。

        终将有人构建聚合器来索引所有仓库并实现搜索功能，但这项服务最终可与托管服务分离。

        回复

    2. 作为最大型Zig项目之一的创建者，我赞同antirez的观点

      回复

      1. 作为大型Zig项目创建者，这个公告是否动摇了你对Zig的信心？无论是语言本身还是决策本身？

        回复

        1. >动摇对Zig的信心

          没有

          我确实认为同时放弃Twitter、Discord和GitHub会让Zig成为主流编程语言的道路更艰难些。其中Twitter的重要性最低。实际影响程度难以预估，毕竟技术胜出往往取决于优势而非缺陷的缺失

          回复

    3. 作为旁观者，看到近期Zig获得的大额捐赠我曾很欣慰。但这次突然的决定令人震惊。技术问题或许能解决(我希望/认为)，但放弃如此主流的平台？我无法断言。对于我微不足道的需求，Forgejo表现出色，但对于Zig这个我期待取得主流成功的项目，我不认为Forgejo/Codeberg是(当前)最佳选择。连标准极高的Graphene OS仍在Github上，或许Zig该再酝酿(brüten)些时日，确认是否真该离开？

      回复

    4. 离开Github可能最终会导致项目终止。

      回复

  51. 祝贺迁移成功！

    > 感谢Forgejo贡献者协助我们解决迁移平台时的问题，也感谢Codeberg团队在迁移过程中给予的支持

    期待未来能看到关于这些问题及解决方案的详细记录。

    回复

  52. >请将当前未关闭的GitHub问题视作“写时复制”机制。现有GitHub问题与拉取请求均无需处理。除非需要编辑、补充评论或重新基准，否则不必迁移至Codeberg。已提交的拉取请求与问题仍会持续跟进，请放心。

    这些内容无法迁移或不值得迁移？若我没记错，另一个迁移代码托管平台(到GitLab？)的项目似乎做到了。

    回复

    1. GitHub的API存在极其严格的速率限制，使得大规模迁移现有问题和PR几乎不可能实现。据我理解，这正是Gitea主仓库仍驻留GitHub的原因：他们始终未能找到干净迁移的方案！我这颗阴谋论大脑认定这是GitHub试图实施供应商锁定的手段。

      回复

  53. Codeberg仓库加载耗时漫长。所谓“快速响应”不过如此。

    回复

    1. 先是致命拥抱，接着是DDoS攻击。我写这段话时，它又瞬间加载了。

      回复

    2. 看来是HackerNews效应。平时明明是瞬间加载的

      回复

  54. 我也讨厌GitHub Actions，但如今真有更好的选择吗？我只能接受它作为最不坏的选择。

    回复

    1. Zig迁移到了Forgejo Actions。它与GitHub Actions高度相似；缺点是会继承某些有争议的设计决策，但优势在于迁移极其简单。虽然不追求1:1兼容性，但两者足够接近，基本上只需微调工作流文件即可。我们的实践表明，它解决了 GitHub Actions 的大多数严重问题：特别是其运行器软件部署配置更便捷，目标平台支持更完善(GitHub 运行器基本无法在 x86_64/aarch64 之外的 Linux/Windows/macOS 环境使用； 我们曾尝试修改其支持riscv64-linux，却在GitHub端遭遇诸多莫名其妙的阻碍！)，且该平台真正接受贡献并及时响应问题反馈。我对GitHub Actions后端及网页界面的诸多不满(确实相当多)也基本消失，且未出现新的替代问题。

      回复

    2. 我不喜欢Azure DevOps及其管道(指YAML管道，而非现已默认禁用的经典拖放式)，但比起GitHub Actions我更倾向前者。出于安全考量，我们可能永远不会真正使用GitHub Actions，但我确实更欣赏Azure明确的行为规范和结构化模板设计，而非GitHub Actions试图通过数字化手段解决变更管理的方式。当然，若没有企业级AD/Entra+Azure架构，GitHub Actions确实更具优势。

      回复

  55. 当时我喝醉了在酒吧…Zig和Nim起身去唱卡拉OK…Elm也在场…总之他们开始演唱。“我们是冠军，朋友们…”真开心。我也站起来唱：“没时间理输家，因为我们是冠军…”超嗨。我们喝了超赞的美味鸡尾酒…里面有草莓(带三个r)，圭多举杯致意。他说自己不会唱歌，但把我的名字写在歌单上。“魔术师”。嘿，我想伸手抓住你！我唱得超棒，又接了首皇后乐队的歌。后来我们到后院抽大麻，但实在喝太醉，转眼就昏睡过去。

    回复

  56. 我不确定是否愿意让重要项目依赖包含如此业余代码的代码库——就像帖子提到的那个“safe_sleep”脚本。说实话，GitHub花了这么久才修复这个漏洞实在令人震惊。

    回复

  57. 我个人非常感激GitHub Actions。能免费使用与代码版本同步的无状态自动化部署脚本，运行在无需管理的服务器上，简直是天赐之物。

    我对管理自建CI服务器的黑暗岁月毫无留恋。

    回复

  58. 集成生态同样重要。目前所有工具都优先适配GitHub(Codex、Claude Code、Linear等)，这确实更便捷。当然GitLab也是GitHub替代方案。就我个人需求而言，GitHub表现出色，免费私有仓库功能尤为实用。

    回复

  59. 不同代码库的核心差异何在？我认为能有效防范恶意代码的才是最佳选择。像GitHub这样的大平台理应具备优势。此外，即便非蓄意上传的漏洞代码，也应被检测并反馈给提交者。

    回复

  60. 非常明智的决定，Codeberg支持无脚本/基础(x)html浏览，而微软的GitHub已不再如此。可惜Zig语言处境艰难，尽管微软在各处大力推广Rust，却无视Zig的存在。

    回复

    1. > 非常明智的决定，Codeberg支持无脚本/基础(x)html浏览

      不，他们使用了Anubis恶意软件。

      回复

      1. 上次我查过Codeberg，他们当时对无脚本/基础(X)HTML浏览器兼容性非常谨慎。

        奇怪。看来得再确认下。

        回复

  61. 你这样把Zig说得像个笑话。我还是回去用C吧。

    回复

  62. 我向开源项目提交拉取请求时，GitHub竟自动添加Copilot参与审核，还显示是我邀请它参与——简直丢人。结果它吐出一堆乱码。后来发现是某个开关被默认开启了。

    我喜欢VSCode里的Copilot，但这简直是胡扯。

    回复

  63. 希望更多项目能效仿！Codeberg拥有更安全的根基，能避免对用户的不道德行为。

    回复

  64. 我倾向于回避那些基于激进主义做出技术决策的项目。这从来不是优质产品的信号。

    回复

    1. 整个GNU项目都是基于社会运动的技术决策。对此视而不见同样传递着某种信号。

      回复

  65. 他要变成林纳斯了吗？我为Zig感到担忧。

    回复

  66. 目睹人们默许GitHub垄断令人痛心。任何脱离GitHub的迁移都应受到鼓励。去中心化的开源系统永远优于企业围墙花园。信任微软从来没有好下场。因GitHub故障而停摆、且没有备用镜像或运行镜像的项目/基础设施数量之多令人震惊。GitHub终将沦为垃圾平台被弃用，因此将项目分散到多个同步镜像(不仅限于Codeberg)相当明智——这样即使某台服务器故障也不会阻碍项目进展。

    回复

  67. > 即日起，我已将GitHub上的ziglang/zig项目设为只读，Zig主项目库的权威源代码库/主分支现为https://codeberg.org/ziglang/zig.git。

    若说迁离GitHub有何益处，必然是避免收到平台上的AI垃圾问题报告。

    过去五年GitHub本就日渐式微，是时候寻求替代方案了。相较于Sourcehut这类平台，我更倾向选择Codeberg。

    回复

    2. > 过去五年GitHub本就在走下坡路，是时候寻找替代方案了，且行且看。

      我基本认同。但GitHub的界面复刻者实在谈不上创新。

      不过我只是粗略浏览过，或许底层还有更多功能。

      很乐意了解它更优越之处。其CI系统是否比Github Actions更完善？我向来不喜欢那个系统。

      回复

  68. 对替代方案感兴趣的用户不妨看看Sourcehut

    回复

  69. 又一个软件项目在该专注打磨产品时，偏要涉足两极分化的政治议题。实在可悲。如今每当听到“Zig”，我脑海中浮现的不再是Zig语言无可争议的优势，而是一个自以为是、幼稚又妄想的社区形象。

    回复

  70. 这是Rust的全面胜利。Zig此前本有发展势头，如今却以最聒噪且壮观的方式将项目拖入黑洞。连镜像库都不留？这般姿态堪称彻底认输。

    回复

  71. 这番自以为是的道德标榜简直令人难以忍受。

    他们真以为Github管理层在主导TypeScript开发？

    回复

  72. 确实不明白为何有人会主动选择微软产品，明明有可行替代方案(我这台Windows机器纯粹是玩游戏用的，真的！)

    回复

    1. > 我这台Windows机器纯粹是玩游戏用的，真的！

      如今Linux上游戏运行得可顺了 😛

      回复

  73. 代码归你所有，托管位置由你决定。有人知道哪里能找到版权代码吗？我想部署克隆服务赚点钱，私信我。

    回复

      1. 我觉得纯AI话题讨论更合适，但关键在于能抓取版权内容创建服务(AI公司)正是我评论的核心观点。我不确定CoPilot在多大程度上使用了私有仓库或其他可能涉及版权的代码训练。但如果确实如此，我支持他们(Zig团队)的立场。

        回复

  74. 嘿，微软不是所有产品都像Windows那样烂。Github才是王者。你的政治立场会像5美元的廉价葡萄酒一样过时。

    回复

  75. Codeberg提供欧元支付或人工电汇的年费方案。会员资格需人工审核。

    编辑：无需会员也可注册。

    回复

  77. hn post = 验证代码是否能扩展到codeberg

    回复

  79. 我绝非AI狂热分子，但不用翻译工具总觉得别扭？

    回复

    1. 我也有同感，但换个角度看：用自己精通的语言阐述再由他人翻译(译文质量参差)总比自己生硬翻译导致他人永远看到糟糕译文要好。至少前者能吸引新人提供更优质的译本。

      这完全基于翻译工具永远翻译错误的假设——尤其在编程术语领域确实如此。

      回复

      1. 两者并不矛盾。你可以使用机器翻译并明确标注来源，同时允许用户在有必要时进行覆盖翻译。

        回复

  80. > 显而易见，曾参与产品开发的精英们早已转战更广阔的天地，剩下的失败者却打着进步的旗号，执意向我们强加臃肿又漏洞百出的JavaScript框架。

    > 更重要的是，Actions根本是猴子编写的

    这番言论实在有损Zig形象。若对Github存在技术异议，请提出具体问题。但请别用“失败者”“猴子”这类人身攻击。

    回复

    1. 有趣的是，这篇帖子本身就违反了Zig的行为准则：https://ziglang.org/code-of-conduct

      > 营造积极环境的行为范例包括：

      > – 使用包容友善的语言

      > – 尊重不同观点与经历

      > – 对他人展现同理心

      > – 认可他人的工作成果

      回复

      1. 行为准则不过是敷衍的道德标榜。每个项目真需要张贴一套独特的“规则”吗？听起来都像是同一个AI机器人写的。话说回来，Zig的领导者连这些规则都遵守不了，这本身就说明问题。这些规则干脆撤掉算了。

        回复

        1. 每个组织都有行为准则，这并非新鲜事。关键在于执行力度。这类准则本质上就是“别当混蛋”的规则集，实在看不出有何问题或“道德标榜”之嫌。

          回复

          1. 行为准则如同业主协会。制定者往往初衷良好，这类规范确实有其存在价值，但仍暗藏风险。若让错误的人掌握执行权，他们便能肆意妄为——既无正当程序保障，也无申诉渠道，更无法律原则可循。

            回复

            1. 这并非行为准则本身的问题，而是权力滥用的普遍症结。

              行为准则仍是有效的沟通工具，制定规范具有实际价值。

              回复

          2. 缺乏行为准则会招致某些惩罚。例如GitHub会反复提醒用户建立准则。

            回复

        2. 我认为领导者有时不遵守自身行为准则，恰恰是最有力的制定依据：这些准则虽人人皆知，却在关键时刻容易被遗忘。行为准则是需要持续追求的标准，而非静态可达的目标。需要不断提醒，而刻意制定准则正是为此目的。

          回复

        3. 行为准则是开源项目的人力资源部门。

          回复

          1. > 人力资源部门是为保护公司而非员工而存在

            行为准则并非守护社区，而是庇护所有不良行为者，并为攻击良善者提供弹药。

            每次都是如此——那些在项目中添加行为准则的维护者，自己却毫无顾忌地对他人恶语相向。

            更新：我知道有人热衷于行为准则，但请回答：若我上述所言不实，为何允许这种幼稚的辱骂言论存在且未被删除？

            回复

            1. > 更新：我知道有人热衷于行为准则，但请回答：若我上述所言不实，为何允许这种幼稚的辱骂言论存在且未被删除？

              你莫非刚出生半小时，还不明白人非圣贤，常受情绪左右，处处自相矛盾？

              回复

        4. 行为准则根本谈不上道德，不过是左派掌控组织的信号罢了。

          回复

          1. 顺便提一下，GitHub会敦促项目制定行为准则。

            回复

          2. 美国左翼分子，还是非美国左翼分子？

            回复

            1. 有什么区别？两者都(或曾经)由非政府组织和国务院资助。

              回复

              1. 美国对“左翼”有特殊定义，这种定义在国外并不适用。相比欧洲左翼，美国左翼属于中右翼。

                回复

                1. 查理·柯克2025年9月10日被中间偏右人士枪击？

                  路易吉·曼吉奥内2024年12月4日枪击联合健康集团CEO时持有反资本主义宣言，他算中间偏右吗？

                  那么埃利亚斯·罗德里格斯(左翼活动家，以色列大使馆职员枪击案)呢？

                  枪杀亚伦·丹尼尔森的迈克尔·雷诺尔(反法西斯主义者)呢？

                  枪杀两名政客的“无王派”范斯·博尔特呢？

                  在达拉斯移民局设施狙击袭击中杀害两名被拘留者并打伤一名特工的“反移民局”约书亚·扬呢？

                  美国左派与世界各地的左派如出一辙，都是隐藏身份的杀人狂。

                  他们暗杀民众(见近期案例)、实施恐怖袭击(1971年炸弹袭击峰值达500起！)、组织暴民排挤异见者、在主流媒体公然散布宣传，并渗透颠覆所加入的每个组织。

                  回复

                  1. 莫非所有凶手都是左派？要么是这样，要么就是你从所有凶手名单里挑出左派分子来论证观点。

                    回复

                    1. 不，我的观点是“相较全球其他地区，美国左派属于温和派”这种说法完全背离事实。

                  2. 我没明白你的意思。难道越左倾就越可能成为杀人犯？反推的话，越右倾就越不可能？这观点太离谱了。

                    我的观点是：民主党和共和党在社会政策上存在分歧，但在经济政策上却极为接近。他们本质上是资本主义政策的两种变体。而其他国家存在纯粹非资本主义的政党——那才是真正的“左翼”。

                    回复

                    1. 我感觉你是在真诚地讨论。但我们的对话大概只能进行到这里了。

        5. 当有人行为恶劣时，指出相关规范文件并要求其停止确实很有帮助

          回复

          1. 根据我的经验，这反而适得其反——因为判断某人是否违反规范文件远比判定其是否行为恶劣困难得多。

            回复

            1. 这反而是建立隐蔽权力结构的 极佳 工具，让真正掌权者得以假装遵循法律术语文件，实则为所欲为。

              这种违背所有行为准则的行为竟出自高层，已说明一切。

              回复

          2. 当真如此？在这个案例中，在有人给你发来行为准则链接之前，难道你没看出称呼员工为失败者和猴子有何不妥？

            回复

            1. 行为准则无法阻止人们采取行动。

              它终究只是纸面文件。

              但本案中，行为准则的存在恰恰让指正用词不当变得轻而易举——无论谁为Zig撰写此文都无法辩驳。

              它正发挥着应有的作用。

              回复

              1. 它怎么起作用了？那篇帖子还在，把人称为“失败者”和“猴子”。发帖者受到谴责了吗？他们修改帖子道歉了吗？

                回复

                1. 似乎存在延迟，现在帖子已更新，那些词汇不再存在。

                  回复

                2. 嘿。你重新发现了批判性种族理论——这是研究生级别的理论，探讨规则/法律如何系统性地适用于少数群体/弱势群体，却对权势者/项目负责人网开一面。

                  遗憾的是，让权势者遵守法律与制定成文规则/法律本身是否值得，是两个独立的问题。

                  即使无法遏制高层滥用职权，行为准则的存在仍优于毫无规范。

                  回复

              2. 他们无需反驳，只需动用权力置之不理。

                回复

            2. 更何况帖子仍在辱骂他人为失败者和猴子，显然行为准则已失效。

              回复

              1. 那干脆废除谋杀法算了？反正有人照样杀人？

                回复

                1. 这根本不是一回事。谋杀要承担法律后果，而违反行为准则却毫无代价——正如该帖至今未被删除的事实所证明。

                  回复

                2. 更贴切的类比是：若反谋杀法执行不公，导致特定群体总能逍遥法外，那不如废除该法律。

                  回复

              2. 没错，正如法律无法神奇地根除犯罪行为。人终究是人。

                回复

        6. 哎呀，我的行为准则允许使用脏话，但不能针对人 😀

          回复

        7. 行为准则至少对自闭症患者有用。不必每个项目都制定独特的准则。

          适用于多数项目的优秀行为准则应是：“简而言之：勿粗鲁勿违法”，随后详细说明何为粗鲁或违法行为，最后声明“项目维护者拥有最终裁量权”。

          回复

          1. 我对此深有体会：在英国社会福利体系中长大，伴有未确诊的精神健康问题；评估者说我“太聪明”不符合ADHD标准，“太社交”不符合自闭症标准。最终被分到神经多样性儿童聚集的班级，从非语言者到古怪的不合群者都有。此外，我主持IRC社区管理长达20年——文字聊天如同劣质压缩算法般剥离所有细微差别，使每句话都易被曲解。

            分享这些并非“炫耀资历”，而是要强调：此番评论源于同理心而非居高临下。

            模糊的社区守则令我困扰，它们如同善意的地雷。“别当混蛋”可能被解读为“保持善意”(何不直接这么说？)，也可能因读者身份不同而扭曲成“别显得居高临下”。

            若再叠加对神经多样性群体(如自闭症患者)的“安全空间”承诺(文字中的社交暗示对他们而言如同迷雾迷宫)，便埋下了意外冲突的种子。

            一条真诚评论误触雷区，被标记为粗鲁言论，于是——主观执法引发的冲突升级。

            我曾多次指出：善意模糊的包容性，反而会通过情感化监管形成反向排斥——这恰是社群运作的常态。何不明确规则以求清晰？用“假定善意并澄清误解”取代“别当混蛋”。这将使安全空间对所有人更安全，自闭症群体亦然。

            我毫不怀疑又会迎来“你怎么能把自闭症患者说成混蛋”的滔滔不绝——这些指责永远故意避开核心问题。

            回复

            1. 正因如此才在“勿失礼貌”后详加说明。“维护者拥有最终裁决权”则有两重意义：1) 这是另一条未明文规定的潜规则(无论如何都成立)；2) 当维护者无暇为屡犯者制定具体规则时，此条款可为封禁行为提供依据——毕竟对方存心作恶的可能性微乎其微。

              此外，当有人引发社交问题时，应参照行为准则的具体条款予以谴责，并在大多数情况下给予警告或改过机会。这既适用于真正不知情者——他们可通过学习变得可容忍；也适用于完全恶意者——让不知情的旁观者学会辨别是非。

              不仅被诊断为自闭症的人难以理解隐性社交暗示，来自其他文化背景的人同样如此——例如在某些文化中，粗鲁行为被视为更可接受。

              回复

          2. 好吧，但正如你自己暗示的那样，每个项目的行为准则本质上大同小异。这意味着99%的项目根本没有必要制定独特的准则。

            回复

        9. 这是零利率政策时代的遗物，那时人们有闲暇和工作保障，宁可参与政治斗争、在推特制造闹剧，也不愿专注本职工作。

          啊，美好的旧时光！

          回复

      2. 对业余爱好者志愿者的评价，与对那家号称“死星”的公司工作的评价，本就截然不同。

        你想加入团队，对方说“好啊，合作方式如下”——要么照做，要么走人。这与宣扬“微软产品烂透了因为他们不关心用户”、“甲骨文垃圾”或那句著名的“别把拉里·埃里森拟人化”这类普世真理完全不同。

        林纳斯曾对社区志愿者动过火吗？还是说他纯粹对大公司为私利提交付费垃圾内容感到愤怒？他自己似乎也常被众人指责“你不得…”

        标准不同。微软会没事的，伙计们。

        回复

        1. 微软本质上也只是一群人。

          回复

          1. 所有公司都是“一群人”。但对待方式不同。你应该把微软的个体员工当作真实的人看待。而微软作为整体，就该被当作邪恶实体对待(说实话他们也不比苹果谷歌之流更恶劣)

            回复

            1. 但这篇帖子根本没提微软，它明确把GitHub的开发者们称为猴子。

              回复

              1. 我没看到有人被点名。

                在我看来，说“X产品糟糕透顶，都是猴子写的代码”并非针对特定程序员的侮辱，而是对公司的谴责。

                见鬼，要是我当GitHub工程师，大概也会认同这种说法。

                回复

              2. 你也该考虑那些在GitHub工作、受雇于微软却真心在乎的人的立场。请注意，他们并未被点名羞辱或类似对待。

                你认为这些假设中的有良知工程师，真会希望此类言论公之于众？还希望用尽可能充满诗意的谴责方式表达？其逻辑是借此唤醒管理层对风险的认知，从而开始重视产品质量？

                我从未在微软工作过。根据经验，当产品质量下滑时，糟糕的管理层责任占比超过90%。对抗这种局面有多么徒劳？为GitHub抗争又有多徒劳？GitHub本身是否重要？我个人使用频率极低，它对我影响甚微。但间接影响或许不容小觑。

                回复

                1. > 你还应考虑那些在GitHub工作、受雇于微软却真心在乎的人的立场。

                  这群人至少占GitHub员工的90%。

                  回复

        2. 我虽与微软毫无瓜葛，但认为这种观点极其糟糕。

          对我而言，成长成熟的过程在于领悟到真正值得鄙视与轻蔑的人实属凤毛麟角[1]。那些政治立场相左者，大多坚信自己所为正确，认为只要他人理解便会改变立场(而我对他们的看法也基本如此)。至于微软、Atlassian等“大公司”，其利益驱动机制必然导致他们持续开发令众多用户沮丧的软件。这绝非出于恶意或无能——从在GitHub.com写段JavaScript的实习生，到萨提亚·纳德拉，无人会故意敷衍了事，更不会每天清晨自问“如何才能挫败世人的努力”。

          况且，既然多数人都在竭尽全力——无论结果如何影响我的个人生活与利益——他们确实不值得我鄙夷嘲弄。若置身其境，我恐怕也做不出什么改变。因此对素不相识、职责未明的人群肆意辱骂，实非成熟、建设性或公正之举。

          [1] 若你好奇，我认为杀人犯之流占据了该群体的主流。

          回复

          1. 有趣的是，我成长成熟后的结论与你截然相反。当然人各有异，但我想提供另一种视角。

            > 况且，既然多数人都在竭尽全力——无论其行为结果如何影响我的个人生活与利益——他们确实不值得我轻蔑嘲讽。

            多数人“竭尽全力”的事实，并不意味着他们的目标与利益不会自私，也不意味着他们的行为不会对他人造成负面影响。尤其那些在政界或商界追求权位的人，往往以敌意对待他人。而不同于普通敌对者，正是这些高位者拥有影响数百万人的能力。

            因此虽然我认同你“善意之人不该遭人鄙视”的主张，但现实教会我：政府与企业常滥用我的信任、权利、自由及生活质量。为此，我至少能在网络论坛上自由表达对这些人的真实感受。我确信自己的言论对他们生活几乎毫无影响，而他们的行为却深刻改变着我的生活。

            回复

          2. 对于那些明知行为将导致广泛伤害与未来死亡，却仍选择实施的人——尽管他们并未直接杀害任何人——你作何评价？

            谋杀完全可以不碰武器就完美达成。

            回复

            1. >对于那些明知自己的行为会导致大规模伤害和未来死亡，却不直接杀害任何人的行为，你会作何评价？

              我们讨论的对象包括科学家吗？还是仅限于下达指令者？

              几乎任何事物都能成为武器，许多东西都能用于造成大规模伤害。

              若你研究的成果具有双重用途呢？既能传播善意也能带来死亡？

              回复

            2. 这类人同样可鄙。但他们远比你想象的稀少。

              回复

          3. 我并非总是做得完美，但尽量避免上网助长本就充斥的愤怒与负能量。尽量别对他人刻薄。

            这其实只为我自己着想，毕竟到头来要承受满脑子垃圾的人是我，只会徒增疲惫。反正那些重要的人根本不会读我可能写下的恶毒言论，更不会因此改变他们。

            回复

          4. 我认为彻底不信任微软(或者说任何大型公司)是健康的，甚至是必要的。虽然我不认为点名道姓地称微软员工为猴子是完全可以接受的，但我认为说任何微软产品是“猴子写的”或其他任何合适的贬义词是完全可以接受的。

            GitHub的发展方向由微软公司主导，而非其员工个人。企业——尤其是如此庞大的企业——本就不值得信任，理应成为被调侃的对象。

            回复

      3. > 有趣的是，这篇帖子违反了Zig自身的行为准则：https://ziglang.org/code-of-conduct

        我不确定是否违反。你提供的链接中明确写着：

          本文件仅规范以下空间：

  Codeberg上的ziglang组织
  Libera.chat上的#zig IRC频道
  Zig项目开发Zulip聊天群
        回复

        1. 任何理性人士都应明白，前文评论针对的是规则本身，而非行为准则中关于适用范围的声明。

          更糟糕的是，网站本身未被纳入行为准则的适用范围，这意味着领导层正在将自己排除在共同制定的互动规则之外。

          回复

        2. 这或许不违反文件的字面规定，但在我看来确实违背了其精神实质。

          回复

      4. 行为准则明确指出：

        本文件仅规范以下空间的规则：

        > Codeberg平台上的ziglang组织
        > Libera.chat上的#zig IRC频道
        > Zig项目开发Zulip群组
        > 显然不包含zig页面！！
        > 因此不构成行为准则违规

        回复

      5. 坦白说，我看不出这违反了行为准则。

        所幸没人会在意我(或你)对此事的看法，因为据我所知，我们俩都没为Zig贡献过任何东西。

        回复

    2. > 由猴子创建

      我对Zig和Github都不太感冒，但…

      他们确实准确指出了技术问题。该代码片段链接到Github讨论评论https://github.com/actions/runner/issues/3792#issuecomment-3…

      (内容如下)

      "这个'安全睡眠'脚本的缺陷一目了然：若进程未在循环返回的一秒间隔内被调度(因$SECONDS值设置错误)，程序便会陷入无限循环。在极端负载的CI机器上极易发生这种情况。一旦发生，后果相当严重：运行器将彻底瘫痪直至人工干预。在Zig的CI运行器机器上，我们发现多个此类进程持续运行数百小时，悄无声息地导致两台运行器服务瘫痪数周。"

      "我不明白为何会出现这种情况。即便忽略这个相当明显的漏洞，这个Bash脚本究竟比调用POSIX标准sleep工具更'安全'在哪里？它似乎并未解决任何问题；同时兼容性更差，还通过忙等待无谓消耗CPU时间。"

      "此处暴露的粗劣编码，以及核心Actions漏洞长期未修复(与GitHub几乎所有产品模块质量衰退的趋势一致)，正迫使Zig项目认真考虑彻底弃用GitHub Actions。鉴于此漏洞及其他诸多问题(严重的工作流调度故障导致数十次超时；日志随机失效；无故取消任务且无详细信息；任务永久处于'待处理'状态)，我们已无法信任Actions能构建可靠的CI基础设施。我个人强烈建议其他项目——尤其是使用自托管运行器的项目——仔细评估Actions的稳定性，并思考相较于其他方案，它是否值得长期坚持。"

      —-

      我承认这篇博文的措辞更注重色彩而非精准，但过度净化表达会让互联网失去活力。人类创造语言自有其道理。

      回复

      1. 那请痛批产品本身，而非开发者。

        回复

        1. 说实话他们确实是在痛批产品。开发者只是其中一小部分。而且显然这至少分散了HN社区对核心观点的注意力。

          回复

          1. 正因如此才该停止。若你在我的茶里加盐，我定会察觉，这会毁掉整杯茶。

            回复

            1. 微软多年前就往你杯子里撒盐了，只是你没察觉罢了。

              回复

              1. 当你用这个牵强的比喻说微软所为时，若往这杯水里再撒盐，只会让我反感。何必混淆视听？

                回复

        2. 产品与创造者密不可分。产品既是开发团队优先级的映射，也是其内部协作状态的体现。换作其他团队，必然会打造出截然不同的产品。

          回复

          1. 若曾在大型企业工作过，你便深知产品所体现的优先级更多源于公司决策层，而非员工本身。领导层确立方向，员工则遵循指令行事。

            回复

            1. 领导层本就是产品开发团队的组成部分，因此不同的领导层必然会打造出截然不同的产品。

              话虽如此，断言一线员工毫无影响力也不准确。我不认为能归咎于任何 个人 ——他们或许曾反对将糟糕内容纳入产品，但终究属于打造劣质产品的 集体 。

              回复

        3. 没有愚蠢的产品，只有愚蠢的人。

          回复

        4. 产品是由人制造的。或者由人创造并操控的人工智能制造的。

          回复

        5. 产品并非一系列“失误”的产物。糟糕且/或用户敌对的软件产品之所以如此，是因为这些公司的工作人员有意为之。

          除非你愿意称他们为无能之辈。不过他们大概也会抗议这个标签。

          简而言之：问题不在于“产品本身”，而在于打造它的人。科技巨头里的员工总想独享赞誉，却对他们不断推动的“垃圾化进程”毫无责任感。

          回复

        1. 原始循环是：

          while (time() != timeout) {;}

          修复后的循环是：

          while (time() < timeout) {;}

          回复

          1. 明白了。我之前没意识到SECONDS是bash内置变量。

            回复

            1. 这仍非妥善修复方案。它依然会占用100% CPU进行忙循环。

              鉴于Github Actions使用广泛，可能造成大量能源浪费。

              但或许能有效增加可计费的Actions运行时长。

              只能祈祷没人用sleep处理CI竞态条件——这本身也算不上正确解决方案。

              回复

              1. 这显然是微服务的工作范畴。接受秒数参数作为URL，等待指定秒数后返回内容。然后在运行器中直接使用curl即可。

                回复

                1. 马上回来创办SaaS初创公司。当然要命名为cloudsleep.io。B轮融资后再买下.com域名。

                  在联系投资者前唯一要解决的问题是：如何将AI融入产品？

                  回复

                  1. 将待处理任务描述为文本，让大型语言模型为每次请求选择等待秒数。显然你需要越昂贵的模型效果越好。看，这就是你的AI方案。

                    回复

                    1. 太棒了，欢迎加入，首席产品官！

                2. 重试在此场景无效。建议设置两个接口：获取x秒后的时间点，并等待该时间点到达。这样重试等待接口就能正常工作，若时间未到则直接用相同参数调用自身接口即可。

                  回复

                3. 若安装了curl(但未安装sleep)，此方案可行；若未安装，可尝试使用bash的/dev/tcp特性。微服务可在1至64k端口间监听，用户可指定等待秒数。

                  回复

              2. 确实不是理想的解决方案。

                更严谨的修复方案可能是采用“read -t $N”。若担心标准输入不可用(例如可能提前关闭)，此方案将失效，但可尝试打开匿名文件描述符进行读取。

                回复
                1.     while wait && [[ $SECONDS -lt $1 ]]; do
      read -t $(($1 - SECONDS))
    done <><(:)

                  不过若不介意信号中断导致提前结束，以下写法也可行：

                      { wait; read -t $1; } <><(:)

                  也完全可行。需要添加wait命令是因为：若无此操作，bash仅在read超时后才会从进程替换中回收僵尸进程。

                  有趣的是，当read阻塞时即使不加-t参数也会回收僵尸进程，因此-t参数下的行为可能被视为设计缺陷而非预期。

                  bash还内置了可加载的sleep命令，该命令调用内部fsleep()函数，既可靠又无需创建子进程。

                  回复

                2. 这些都是权宜之计。理应直接使用sleep命令，仅此而已。

                  睡眠属于操作系统调度任务，应当调用系统级调用实现。

                  正如Github问题中提议的那样——尽管微软已对此置之不理半年之久。

                  回复

            2. 我也是。年过四十才知此事。在意外之处学到新知识，感觉真好！

              回复

      3. 我认同博文行文更注重生动而非严谨，但过度净化表达会使网络黯淡。人类创造语言自有其道理。

        那么你该如何划清界限？只要后续段落技术问题描述正确，种族主义的谩骂就能被你接受吗？

        这篇博文的措辞极具侮辱性。试想如果你是写出这段代码的人，此刻却在互联网上被数千人当面骂作猴子，你会作何感受？你自己写代码时难道没犯过错吗？还是说你自诩永远写不出错误代码？

        这类行为准则向来让我觉得多此一举，但读到这类评论后，我完全理解其必要性。

        回复

        1. 你是否更希望他们用“不专业”或“粗心”来指代，而非暗示猴子？

          对我来说这些词本质相同，只是后者更生动，能让我避免看得昏昏欲睡。

          > 试想如果你是写出这段代码的人，此刻却在数千网民面前被当作猴子嘲讽，会作何感受？

          呃…所以呢？如果连最轻微的严厉批评都承受不了，凭什么让这样的人担任影响数百万人的关键岗位？毕竟这确实是个相当严重的漏洞。

          > 你自己写代码时难道没犯过错…还是说你自诩代码永远完美无瑕？

          我当然犯过错，也承认自己的产出偶尔可能“猴子般拙劣”。我不觉得这有什么侮辱性——我们都是人/动物嘛。

          回复

          1. > 对我来说这些说法本质相同，只是后者更生动，能避免我看得昏昏欲睡。

            而对许多人而言，区别在于前者传递信息，后者则可能让他们永远对作者和项目产生抵触。

            我注意到你始终回避我的问题。若你认为这种做法合理，那你的底线究竟在哪里？若能回答这个问题，或许你就能发现自己论点的漏洞。

            回复

            1. >后者则可能让读者永远对作者和项目产生抵触

              这完全没问题。那是他们的项目，他们的网站。若连自家网站都不能用生动语言，还能在哪里展现个性！若因此疏远部分读者，作者必然知晓风险且甘愿承担。

              就我而言，这类生动表达令人耳目一新。人人都追求政治正确只会让网络变得枯燥乏味。

              回复

              1. 不做混蛋 ≠ 政治正确

                你肯定有自己对言论边界的界定标准。具体是什么？

                回复

                1. > 你肯定有自己对言论边界的界定标准。具体是什么？

                  我确实有，但拒绝在此透露。我不会把讨论从作者网站行为转移到我的个人信念和底线！

                  我只想说这是他们的项目，他们的博客。他们可以在自己的网站上随意粗鲁。那是他们的网站，他们的底线。我个人设定的界限与安德鲁在自己网站上写什么毫无关联。

                  若安德鲁的文字疏远了读者，那是他的选择、他的行为、他必须承担的后果。我划定界限与此事何干？

                  回复

                  1. > 我只想说这是他们的项目，他们的博客。他们可以在自己的网站上随意粗鲁。那是他们的网站，他们的底线，他们的边界。

                    这很有趣，因为若真如此，他已违反了自己的行为准则：https://ziglang.org/code-of-conduct/#safe-constructive-only

                    > 我确实有，但拒绝在此分享

                    关键在于每个人对“可接受”的界限都不同。这正是行为准则存在的意义——试图寻找共同标准，从而营造一个让人感到被接纳、而非遭受攻击或侮辱的社区环境。

                    回复

                    1. > 这很有趣，因为若属实，他等于违反了自己的行为准则

                      没错，确实如此。确实有趣。我不明白为何要无休止讨论此事。若你对此违规行为如此介怀，请通过问题追踪系统提交正式报告。

                      > 关键在于每个人对“可接受”的界限不同。这正是行为准则存在的意义

                      我之前说拒绝在此分享个人底线，就是这个意思。我可没想听你讲行为准则课。我清楚准则是什么以及为何存在。非常感谢。我不是道德警察，你也不是。

                      我的道德准则适用于我自己。安德鲁的道德准则适用于他自己。不过…行为准则可能也适用于他。所以你的观点很有道理。我不确定行为准则是否适用于他们的网站。如果你了解详情且确实适用，那么违反行为准则的行为应该通过他们的问题跟踪器进行举报。既然这是你如此重视的话题，请务必向他们举报违规行为。这样才公平。

                    2. > 是的，他确实这么说了。挺有意思的。

                      没错，太搞笑了！骂人猴子真是既机智又发人深省的侮辱！

                      > 不明白为何要没完没了讨论这个

                      既然你对此感到困惑，为何还要继续回应？

                      > 我说拒绝在此分享个人底线时，就是这个意思。我没打算听你讲行为准则。我清楚准则为何存在。

                      我真觉得你根本不懂准则存在的意义，因为当别人指出合理违规时(比如当“道德警察”)，你反而责备对方。

                      > 但确实…行为准则同样适用于他。所以你的观点有道理

                      算你终于承认了吧？不明白你为何要绕那么多弯子，不过至少最终承认了。

                      > 若此事对你如此重要，请务必向他们举报违规行为

                      不必了。其实我没被他说的内容冒犯，只是觉得人们急着为他辩护很奇怪。

                    3. > 既然你对此感到困惑，为何还要继续回应？

                      我毫无困惑。这是反问句。我继续回应是因为还有其他我关心的事情，对此我有话要说。我不在乎安德鲁在自己网站上采用何种风格、语气或措辞。但我反对那些充当道德警察的人，阻止别人在自己的博客上发表粗鲁言论或政治不正确的观点。这就是我继续回应的原因。

                      > 总算承认了？虽然不明白你为何要绕那么大圈子论证，但至少最终说清楚了。

                      功归功，过归过。若你提出我认同的合理观点，我定会直言不讳。

                      > 不明白你为何要绕那么大圈子论证，不过至少最终承认了。

                      因为你其他观点我无法认同。

                      难道人非要百分百赞同或百分百反对不可？难道不能10%认同、90%反对吗？眼前的情况正是如此。

                    4. > 但我反对那些充当道德警察的人，他们竟阻止个人在自家网站上发表粗鲁言论或政治不正确的观点

                      这似乎是稻草人谬误。你已承认他违反了行为准则——所以他确实有错。

                      我不明白还有什么可争论的——这始终是我的立场。

                      若他想在个人网站发表幼稚言论(该网站不受行为准则约束)，那是他的选择。我同样有权表达观点，但从未暗示他不能在个人博客自由写作。

                    5. > 你已承认他违反了行为准则——所以他确实有错

                      我从未这么说过。我的原话是——

                      "不过确实…行为准则可能也适用于他。所以你的观点有道理。我不确定行为准则是否适用于他们的网站。若你掌握更多信息且确实适用，应通过其问题跟踪器举报违规行为。"

                      重点在于：“可能”、‘我不确定是否’、“若你掌握更多信息”。

                    6. 你确实说过。你进行了隐蔽编辑修改了评论，但幸运的是我在前文引用了你最初的表述：

                      > 但确实…行为准则也适用于他。所以你的观点很有道理

                      既然你已证明自己并非善意辩论，这将是我最后一次回应你。

                    7. 这并非隐蔽编辑，而是公开编辑。HN允许2小时编辑期自有其道理。我最初误以为行为准则适用于他。显然我并未通读准则，因此表述不够确定。后来我修正了措辞以体现这种不确定性。

                      但你却选择回复我过时的留言——尽管当时我的回复已明确表示对准则适用性存疑。

                    8. 仔细阅读行为准则，其中明确规定了适用范围。该网站似乎不在其管辖范围内，这是刻意为之——行为准则仅适用于“工作”场所。

                    9. 若是公司，你会说行为准则是为小喽啰制定的，而非高管阶层。

                    10. 不，它针对的是公司内部互动，而非外部随机的大型企业。

                    11. 由猴子和失败者制定(因为其他人早已离开)的规则，目标不是公司本身，而是其员工。

                  2. 既然你这么想，为何还要费心多次评论来辩护用词？感觉你拒绝划清界限是有原因的。

                    回复

                    1. > 既然你这么想，为何还要费心多次评论来辩护用词？

                      我对用词本身并不在意，既无意辩护也无意批判。但我确实反对那些充当道德警察的行为，这才是我在此反复发声的原因。

                      > 你似乎有理由拒绝划清界限。

                      没错，原因在于我的底线只适用于自己。它与你无关，也与安德鲁无关。因此我的底线——作为个人私事——不愿在此分享。讨论安德鲁网站用词时，这根本无关紧要。原因很简单，别想太多！

          2. 并非所有人都能承受当面被骂猴子或废物的打击。

            回复

            1. 读完这篇文章，我首先想到的是：作者在现实生活中绝不敢当面骂人“猴子”或“失败者”。

              互联网的悲哀副作用之一，就是让许多人的混蛋本性彻底暴露。

              回复

            2. 或许他们更适合干那种完全无需负责的工作。

              回复

          3. 你认为Zig是否在遵循自己的行为准则？

            回复

            1. 该网站不受行为准则约束，所以他们并未暂停执行

              回复

              1. Ziglang.org脱离Zig行为准则的行为太疯狂了。

                我真想继续深挖这个话题，看看你为辩护这个站不住脚的立场能走多远，但就此打住。

                回复

                1. 事实就是如此。我没写这个，读到时我也感到惊讶。

                  > 本文件仅规范以下空间的规则：

                  > Codeberg平台上的ziglang组织

                  > Libera.chat上的#zig IRC频道

                  > Zig项目开发Zulip群组

                  回复

        2. > 只要后续段落技术论述正确，种族主义檄文就能被你们接受吗？

          我不是道德警察。谁都不该当。我仍会基于技术价值审视文章。举个随机例子：若中本聪论文称银行系统用户为牲畜，我照样会读下去。

          > 设想若你写了这段代码，如今却在万众瞩目的网络空间被骂作猴子

          完全没问题，毕竟没人指名道姓。他不像乔什·范例曼那样搞砸每个经手的功能，搞得Actions系统一团糟。没人会因一篇博客永远将参与Actions开发的人贴上“无法雇佣”的标签。我个人认为，让开发者为糟糕的实现方式感到羞耻是好事——毕竟这些代码并非经理强迫他们提交的。调用睡眠二进制文件根本不会增加额外工作量。

          无论是谁在Windows里搞出新React开始菜单

          无论是谁负责Chrome网页环境完整性

          无论是谁设计了OSX Tahoe界面

          无论是谁在开发会截取屏幕的Windows Copilot

          都该感到羞耻。越多的文章揭露这些越好。他们干的不是好事。

          回复

    3. > 但请别用“废物”“猴子”这类人身攻击。

      人身攻击是指基于发言者背景否定论点。这里根本不存在论点否定，纯属辱骂。这属于人身攻击，而非谬误。

      回复

    4. 确实挺丢人的。

      我对技术也常感到抓狂！我懂。当Actions程序跑得像只惹人厌的顽童时，真是气死人了……

      但你如何处理(或未能处理)这种挫败感，恰恰彰显了你的品格素养，更深刻揭示了你作为合作者的真实面貌。

      回复

      1. 需特别指出，此帖作者正是zig项目的原始开发者，他显然对项目拥有实际控制权。

        回复

      2. 你真该去幼儿园工作，我真心这么建议。好好想想吧，绝非冒犯之意。

        回复

        1. 我们多数人在现实职场中犯错时，不会被人骂作失败者或猴子。这并非什么虚构的职业道德乌托邦，而是多数人的真实工作状态。

          回复

          1. 我们不仅不会在同事犯错时骂他们失败者或猴子，就连私下调侃竞争对手时也绝不会出言刻薄。那些对不喜欢的人恶语相向的人，往往也会在背后诋毁你——我们不愿成为这样的人，所以从不这样做。

            如果你的职场充斥着辱骂之词，不妨考虑两种可能性：这里的环境可能异常恶劣，而你自己或许正在助长这种恶劣氛围。

            回复

        2. 当你不满同事工作时就骂他们是猴子，说明你离幼儿园水平比想象中更近。

          回复

    5. 技术沟通中融入些“自然”语言无可厚非，反而更显人性化。那些粉饰太平的企业话术和充斥营销废话的表达，简直令人灵魂枯竭。

      回复

      1. 表达不满和愤怒时，完全可以“自然”地做到不必称人“废物”或“猴子”。

        回复

        1. 你完全可以“自然”地表达不满和愤怒，无需骂人“废物”或“猴子”。

          我无法代表他人发言。但若我犯错的程度堪比GitHub，我宁愿被人骂成废物和猴子。这就像有人往我脸上泼冰水，让我清醒面对现实。没错，这过程会非常难受。但我会从中吸取教训，努力不再犯同样的严重错误。我反而觉得这种自然的爆发令人耳目一新。

          回复

          1. 我认为贬低他人作品与人身攻击存在本质区别。人们可能犯下重大错误，但这并不意味着他们就是失败者或蠢货。

            回复

          2. 这种态度在理论上值得称道(我不怀疑你真心信奉，甚至可能实践得很好，但现实反应往往与理想状态相悖)。但现实中更常见的情况是：人们会闭口不言、陷入防御状态，因批评方式而主动抵触指正。

            不过最佳情况是，负责这些功能的团队认同观点，并能将帖子作为日益不满的例证提交给管理者。但我怀疑这毫无作用——GitHub如今已归属微软人工智能部门。

            回复

        2. 我觉得这股清风令人耳目一新。不想被这样点名批评？那就别再搞砸了。

          回复

          1. 我本可以解释大多数工作远比“失败就该被骂猴子”或“不失败就没事”复杂得多。但更简单的方式是骂你看不清这点，你回骂我，然后我们永远这样循环下去。

            回复

            1. 你的论点缺乏深度，硬要把批评简化成非黑即白的二元对立。

              他们指责的具体错误极其严重，就像建筑商宣称没屋顶的房子完工一样。“失败到活该被骂猴子”是对百分百重大失误的批评，绝非你所说的微不足道的失误。

              虽然使用更克制的措辞或许更妥当，但坦白说，要准确表达这种赤裸裸的组织无能——一个经过审核交付的产品竟持续多年造成客户负面影响，而这个微不足道的缺陷本可轻易修复却被长期忽视——实在令人难以用冷静的文字传达。

              GitHub的客户 理应 对GitHub欢天喜地将如此严重缺陷的软件强加于他们感到愤怒。这种情绪很难用冷静的文字准确传递。

              回复

              1. 感谢您的深思熟虑的回应。

                > 您的论点缺乏细腻度，宣称此处的批评必须是简单的二元对立。

                这并非我的论点。我反对的是所谓存在“客观”失败阈值的观点——一旦触及该阈值，便可接受对他人进行人身攻击。

                > GitHub 用户理应愤怒——这家平台竟欢天喜地将如此漏洞百出的软件强加于人。这种情绪在冷静的文字中难以充分传达。

                你看，尽管存在漏洞，我认为GitHub作为软件产品并无重大缺陷(暂且不论垄断问题)。我鼓励热烈讨论，但人身攻击并非传递热情，而是暴露急躁。这暗示你缺乏耐心为所谓热衷之事提出合理论据，转而选择更短促、更具攻击性的表达方式。

                回复

          2. 我敢说被骂猴子绝对能让他们永不犯错。

            回复

            1. 若真如此，教师和培训师的工作就轻松得离谱：只需辱骂学员就能让他们永远考不过试、跑不过赛、做不成事。

              回复

          3. 并非人人都如此坚韧。这种事会伤到人。不是每个人都是毫不在乎的魔法师。

            天啊，他们是活生生的人啊。请心怀同理心！

            回复

            1. 把成年人当小孩对待是严重问题。若这种压力都需要采取防御措施应对，那你的人生价值何在？

              回复
            2.     > 这些可是活生生的人啊。请多些同理心！

              甲的同理心，乙的仇恨。

              在我看来，你在此讨论中的观点和行为本身就完全缺乏同理心。

              之所以会出现突破职业规范的激烈言辞，是因为这些话语背后承载着真实的人类情感。真实的痛苦与煎熬，生命中永远无法挽回的流逝时光，因压力日渐扩大的秃顶区域。这类情感渴望以某种方式表达，而千篇一律的官僚话术天生无法承载这种诉求。

              面对这些情感，你的回应竟是鸵鸟式回避(即拒绝阅读博文)？更甚者，即便脱离语境，你仍在此鼓动众人效仿鸵鸟？

              你宁可编造巨型无名企业里某个虚构人物可能被冒犯的假想情境，也不愿倾听眼前真实受辱者的心声？

              一切终究取决于视角，但在我看来，你的言论严重缺乏你所宣扬的同理心。

              回复

            3. 对他们脆弱可悲的存在抱有同情，并不等于认同这种脆弱性本身。

              回复

              1. 作为组织公众形象却无法控制愤怒情绪、动辄辱骂他人——这在我看来才叫脆弱。

                回复

                1. 这叫投射心理。骂人时并非人人都怀着愤怒。

                  回复

            4. 若有人因此受伤，他们该去上些自信建设课程了…

              回复

              1. 没错，那些被这样称呼就感到冒犯的黑人，根本就是缺乏自信对吧？那些LGBT群体太敏感了，连我们给他们起的花名都承受不了！想想看。这种评论恰恰暴露了HN评论者最恶劣的本质——自以为正义却充满仇恨，正是这种心态催生了地球上最骇人听闻的政策与行径。

                回复

                1. 或者你长大后学会在正确语境下看待这类事情，对容易忽略的言论一笑置之。但针对整个群体的明显种族歧视或侮辱性言论显然另当别论。不过你听起来像是那种会因一个笑话就抵制喜剧演员的人。

                  回复

              2. 人们确实需要更强的心理承受力

                回复

        3. 没错，这简直是对真实猴子的冒犯——它们根本没做错什么！

          回复

      2. 如果他纯粹针对产品发泄——比如“GitHub Actions是永远无法正常工作的垃圾产品”，我倒不会这么反感。但把开发者全称为“失败者”就越界了。

        回复

      3. 当然。若你觉得有必要写“这代码烂透了”，我也能接受这种措辞。但请仅止于此，别连写代码的人也一并侮辱。遗憾的是，糟糕的激励机制本就可能让能力出众的人做出劣质产品。

        回复

      6. 身为公司职员，这番言论令人耳目一新。本就计划利用假期学习Zig语言，此举更添吸引力。

        回复

      7. 倘若他修改了代码，恐怕会有更多人指责这是AI编写的。

        耸肩。

        若他针对特定个人辱骂，我或许会举报。但辱骂Github和微软这样的机构？不值得。

        既然CEO们如今似乎活在“后羞耻现实(tm)”里，我允许给这种局面添点羞耻感。

        回复

    6. 天啊，整条讨论串都在为他辩护，说什么“令人耳目一新”“只是使用人类语言”。人性中似乎存在某种病态，让人乐于看到他人被如此贬低。完全缺乏同理心——毕竟没人愿意自己被这样对待，却对他人遭受此等对待感到心满意足。有评论者竟辩称“我搞砸了，这样说话就合理”。行吧伙计，我们信你。

      这让我想起林纳斯·托瓦兹偶尔会暴跳如雷，对犯错者发动毫无必要的个人攻击。评论区总是充斥着嘲笑托瓦兹最新牺牲品的声浪：“绝不会是我，我永远不会犯这种错误”。就连托瓦兹自己也承认这种对待方式是错误的，他曾暂停工作进行自我反思，努力成为更好的人。但至今仍不乏乐见他人受辱之辈，更不乏扮演年轻版林纳斯的模仿者。

      回复

      1. 许多人早已厌倦企业话语中泛滥的毒性积极主义——这种说辞既纵容表现不佳者，又扼杀顶尖人才的直言勇气。

        “完全缺乏同理心”这个说法有点夸张了吧？称呼别人为猴子其实相当轻松，同时传达出他们或许该重新审视自身能力认知的意思。

        回复

        1. 这位“高绩效者”终于意识到问题根源在于自己的毒性行为，并需要加以修正。

          > 本周社区成员指正了我长期缺乏情感认知的问题。我在邮件中轻率的攻击既不专业也毫无必要。

          > 尤其当我将攻击个人化时。当时我以为追求更完善的补丁是正当行为，如今深知此举不可取，我真心致歉。上述长篇大论其实是为了坦承一个痛苦的真相：嘿， 我必须改变某些行为，并向那些因我的个人行为受到伤害、甚至可能因此彻底远离内核开发的人们致歉。

          他确实做到了。他领导的项目因此变得更好。管理项目无需辱骂他人。林纳斯明白了这个道理。那些未能成长的人也该学会了。

          回复

        2. 存在既能坦诚建设性沟通，又不放任差劲表现者的方式。

          骂人猴子和废物纯属下作。这种行为毫无成效，只会制造分裂，更常因营造恐惧文化而适得其反。

          回复

      2. 完全缺乏同理心…

        …竟对IT史上最大毒瘤企业之一毫无同情？

        省省吧。微软是宇宙间最不值得你同情的企业实体。

        回复

        1. 他指的是编写代码的人。他们是真实存在的个体。你却将他们抽象化为“微软”，认定他们不值得同情。

          回复

          1. > 你把他们抽象成了“微软”

            不，这是他们加入微软时做的选择，不是我。当你领着微软的薪水为微软产品编写微软代码时，你就不再是“真实的人”了。

            回复

            1. 你把微软说得像ISIS或基地组织似的。你简直疯了。若问“微软员工是否值得被当作人对待”，99.999999%的人会回答“当然值得”。

              像你这样的人让我感到恐惧。

              回复

              1. > 如果你问人们“微软员工是否值得被当作人对待”

                不，我问的是微软员工编写的代码能否被视为个人作品而非公司产物，答案是响亮的“不”。

                没人关心微软员工的私生活。(我相信他们都是好人，我亲戚里就有微软员工。)

                回复

          2. 许多“真实的人”同样深受邓宁-克鲁格效应困扰，热衷于用糟糕的方式构建没人想要的愚蠢玩意儿。

            回复

      3. > 有评论者辩称“既然我搞砸了，这样说话就合理”。行吧伙计，我们信你。

        你读过这期内容吗？

        这绝非普通人犯的“错误”。这是决策层层严重失职，对工作质量的彻底漠视。若要怪罪不公，该责怪的是那些将员工推向能力严重不足岗位的管理者。

        回复

      4. > 没人愿意被这样对待

        若我做出了极其愚蠢的行为，我反而希望被这样对待。若我犯下GitHub那样的蠢事，我宁愿被人骂作猴子，至少能让我意识到自己搞砸了。

        我明白“猴子”这种称呼不够专业，但我的专业期待仅限于办公室同事和少数特定场合。我不指望全世界都对我保持专业。若能促使我反思并改正错误，我完全能接受网络上某人骂我猴子。

        若对方能委婉地用专业措辞指出我的愚蠢，固然最好。但若他们做不到，直接骂我“猴子”，我也照单全收。与其毫无反馈，我宁愿接受任何形式的批评。

        回复

    8. 作为前JavaScript开发者和现任业余爱好者，我深知本文措辞为何极具冒犯性。多数在职JavaScript开发者专业能力极差，却对此异常敏感。除赞美之外的任何评价都构成冒犯。真正的成熟标志在于摒弃客套，转而追求证据、共情或更有力的论据。

      另一方面，Zig常被视为现代编程语言中执行速度最快者。他们拥有独一无二的资格抱怨性能问题。文章列举了他们与GitHub之间的具体矛盾。

      更何况当JavaScript代码非猴子所写时，其运行速度极快，这更凸显了他们的抱怨有理有据。例如我有一个大型单页应用，通过网络在浏览器加载仅需0.065秒，完全渲染并恢复状态约0.135秒。若移除该应用中最大的功能模块，完全渲染和状态恢复可在0.08秒内完成。反观普通JavaScript开发者，他们连将代码复制粘贴到他人定义的JSX模板都举步维艰，更遑论性能测试。这才是真正令人反感之处。

      回复

    9. 我承认他开篇就火力全开，尤其前段的措辞和语气确实令人不适。但读完全文后，我不得不说他的动机和观点确实有道理。

      回复

      1. 开篇的语气让我没读完这篇文章。

        高层IT工作关乎人际关系。这篇帖子让Zig丧失了组织资格。

        回复

    10. 他最近大概看了太多Linux内核邮件列表的讨论。

      但赞同对Devon Zuegel的评价。优秀开发者和管理者大多已离职。我记得只有负责Git SHA-256迁移的Brian还在，不过他根本没时间完成这项工作。

      回复

    11. 安德鲁似乎意识到辱骂同行工程师有多荒谬，已更新帖文不再称GitHub工程师为“猴子”。尽管最初的言论令人不齿且未道歉，但删除恶语总比毫无作为强。

      回复

      1. 没错，称这些代码作者为失败者和猴子都算客气了。编写这种代码毫无借口可言，其无能程度令人震惊。

        回复

    13. 我更希望网络上的作者能坦率表达观点，而非自我审查措辞。难道我们不是一致反对新话吗？

      回复

    14. 不过这段文字确实勾起了我的好奇心，点开了引用的链接。考虑到代码质量问题、缺乏周边流程支持，以及这些代码缺陷影响的对象(路径的临界性)，说“猴子”都算是客气了。

      回复

    15. 你说得对，我听过不少关于Zig的好评本想尝试，但看到这篇帖子后庆幸自己没碰。这种东西我可不想沾边。

      职场中确实存在用“猴子”贬低他人的现象，但这种行为永远不可取。事实上，根本无需 resort to 人身攻击或侮辱性言辞。

      我从中得到的结论是：Zig项目由极度幼稚且充满毒性的团队主导。我完全无法信任这些人的任何决策。若你们连尊重地表达异议都做不到，竟因程序漏洞就对开发者恶语相向，那我更不敢相信你们不会在代码里暗藏后门，或因私人恩怨、争执或政治立场而损害依赖你们成果的人。

      即便真正的政治活动家这么做也绝不可接受。若有人因内塔尼亚胡在加沙的种族灭绝行为称其为猴子，大多数支持巴勒斯坦的人都会试图抵制你！并非因为他们欣赏内塔尼亚胡，而是这种行为对事业的伤害远大于助益。

      安德鲁：看来你既不尊重自己也不尊重社区，无法树立文明礼仪的榜样。你把Zig当成个人恶搞的发泄平台。请做得更好！

      回复

      1. 对我而言，关键在于Zig项目由一群极其幼稚且充满毒性的领导者主导。

        幼稚又毒辣：欢迎来到所有科技巨头的世界，你也不想沾染他们的污秽吧？

        回复

        1. 如果他们把员工叫猴子，那当然。我认为每家科技巨头都清楚针对恶劣工作环境、职场欺凌等问题的诉讼风险，这些公司都开展过全员培训。

          作为过来人，只要察觉到可能遭受这种对待，我就会立即退出面试。我不会说任何金额都不值得，但无论他们认为多少补偿合理，我都觉得不值得。有人为此自杀。这不是玩笑。人生苦短。光是目睹他人遭受如此对待就令人发指。真不敢相信竟有人为这种行为辩护。人们需要重新学会羞耻。

          回复

          1. > 如果他们把员工叫猴子，那当然算。

            过去十年这种现象似乎减少了，但“代码猴子”曾是软件部门最常见的贬称。我不喜欢被比作胡乱敲打打字机的猴子，但当时就是如此。

            这总比大家对人力资源部的称呼强。

            回复

            1. “代码猴子”有点不同，我见过有人用这个称呼自嘲，带点自嘲意味。也许安德鲁用“代码猴子”时更倾向于积极含义而非贬义？但我重读后仍觉得这是对智商的侮辱——就像那些训练猴子敲击键盘观察结果的实验？仿佛他们蠢到和猴子乱敲键盘偶然写出能用的代码没两样？

              无论如何，至少能认同这在个人层面上是对当事人的侮辱吗？它攻击的是他们的身份而非工作表现？

              正如我提到的，我和同事都曾被如此类比。起初我没太在意，但同事们士气严重受挫，不断提起此事，而这恰逢掌权者施加的各种敌意。

              我在此发声并非为了宣泄网络怒火，而是希望尽己所能阻止他人遭受如此糟糕的对待，尤其是在职场中。若发生在我的工作场所，我可能只会默默寻找其他工作机会，因为我害怕丢掉饭碗。而微软员工也无法像安德鲁那样公开回应而不丢掉工作。我目睹了某位掌握权势的公众人物滥用职权骚扰他人。

              权力地位、响亮名声或人生成就绝非授予人“混蛋特权”的凭证。我们这些能对此类行为作出反制的人，必须挺身而出。

              回复

        1. 林纳斯因贡献者失误发火，与称呼维护免费服务(GitHub——除非Zig付费)的人为猴子不可同日而语。尽管纠正我，但林纳斯是否曾用过如此人身攻击的贬损词？

          无论如何，我虽喜欢Linux，却因更轻微的理由回避过FreeBSD和OpenBSD等系统，因此我认同。当林纳斯真的失控辱骂他人时，我早已表达过充分批评。

          必须明确：我认为那些为他辩护的人(此处指Andrew)比最初的冒犯者更恶劣。人会犯错，被推上领导岗位反而可能误入歧途——我理解这点，正因如此才在此直言。若他只是普通人，我本不会费心。但助纣为虐者才是真正问题所在。希望你不是其中一员。若是，我将视你们为所有职场霸凌与毒瘤环境的共谋。成就伟业无需沦为粗鄙野蛮的暴徒。

          回复

          1. 称Github小丑为猴子已是仁慈之举。

            回复

      3. >若因内塔尼亚胡在加沙的种族灭绝行为称其为猴子，多数亲巴勒斯坦人士会试图抵制你！并非他们推崇他，而是此举对事业的伤害远大于助益。

        你对当前政治氛围的解读与我截然不同。

        回复

        1. 我不这么认为。在我看来，你可以称他为杀人犯、种族灭绝者、反社会人格者，任何与他行为相关的称谓都可以。但用侮辱性词汇称呼他，把他比作动物就另当别论了。即便是肢体暴力都更容易被容忍。当然私下里人们可以说任何话，我指的是公共言论场域。“猴子”、“狗”这类词汇在不同文化中都代表着极其恶毒的贬义。这种称呼具有去人性化效果(字面意义上的！)，它暴露的更多是说话者自身的问题，而非被指涉对象的本质。

          回复

          1. > 将他比作动物

            智人本身就是动物物种。

            回复

            1. 英语中人类说“动物”时，特指“非人类动物”。被称为动物本身并不构成侮辱——别急着跳跃结论。几乎没人会因被比作狮子而受辱。我认为所有识字者都清楚这种比喻的深层含义及其去人性化的本质。从奴隶贩子、殖民主义者到纳粹分子，都曾用“猴子”贬低人类尊严。在不同语境下，‘狗’“蛇”等称谓亦然。

              回复

            2. 番茄该放进水果沙拉，所有飞机失事都归咎于重力。

              回复

      4. 我根本不信任这些人做出的任何决定

        能否举一两个糟糕决策的具体例子，说明为何令你如此反感？

        回复

        1. 显然，我的不信任源于安德鲁公开展现的品性，而非对历史行为的分析。当你目睹厨师如厕后不洗手，就该避开他的餐厅——即便你无法证明他在烹饪前未在厨房洗手。

          关键在于他根本不懂分寸，这还是针对陌生人——那些素不相识的微软员工。倘若面对熟识且信任之人做出违背原则的事，他是否会越界？我愿给予他信任，但涉及编程语言编译器这类关键软件时，信任门槛本就很高。

          我衷心祝愿Zig成功，但前提是技术社群能对其领导层问责，而非像现在这样为其辩护找借口。告诉那些你敬重的人他们搞砸了，这无可厚非。

          回复

          1. 我实在不明白这与“信任”有何关联，尤其涉及项目或代码时。若真要说，那些想获得不应得信任的人反而会刻意在公开场合遵循更高标准的规范——公开言论会显得友善、得体、健谈且专业，而未达标的行为则藏于私下。

            顺便说一句，我从未用Zig写过一行代码，也不认识这位开发者。

            我从中得到的唯一信息是：“GitHub似乎正在急剧恶化，这位开发者受够了，正带着项目离开，并留下些尖刻的评论。”

            回复

          2. 你的逻辑在此并不成立——Zig是完全开源项目(任何后门都将暴露于众目睽睽之下)，且迄今收获的评价多为正面。同样地，林纳斯·托瓦兹多年间也颇具“毒性”，但从未损害Linux项目的质量。而Linux本质上正统治着科技世界。

            回复

            1. 后门可以伪装成漏洞。开发者可能植入后门，在下个版本修复时标记为CVE漏洞，无人察觉。

              我并非为林纳斯辩护，但也不认为他曾称呼他人为猴子或贬低人性。若真有此事，请发给我LKML存档——反正我正犹豫要不要彻底投奔苹果阵营 🙂

              回复

        2. 没错，称呼他人为猴子确实是个糟糕的决定。

          回复

      5. 我在工作场合听过别人称呼他人“猴子”，这种行为永远不可取。

        这篇博客是在工作场合发表的吗？天哪！你最好立刻跑去人力资源部举报不专业行为！

        等等。

        回复

        1. 我认为像你这样的人根本不懂这些道理。你可以选择文明的方式专业处理问题，也可以选择极其野蛮的方式行事。但你不能既野蛮行事，又抱怨别人跑去人力资源部投诉。真想看看你或安德鲁在非工作场合当面这么称呼别人时会怎样——毕竟那时可没有可以求助的权威机构来承担后果。

          若安德鲁认为Zig是适用于生产环境的专业软件，那这里确实是专业场合。若非如此，那它不过是你这类幼稚爱抱怨者搞的业余项目，我们大可忽略它，去讨论更严肃的人/项目。

          回复

      6. 微软员工暴露了。笑死，微软员工们继续刷负分吧…

        回复

    16. 看看链接的问题。虽然我不认为这种措辞恰当，但某些时候我们必须指出糟糕且偷懒的代码。

      回复

    17. 曾经敏捷的东西现在变得迟钝，甚至经常完全失灵。

      话说GitHub什么时候以敏捷著称过？

      回复

      1. GitHub早期确实非常敏捷。我还记得它刚推出时给我带来的清新体验。具体时间记不清了，但2020年之后它就一路下滑。

        回复

        1. Jira也是同样的情况。

          我可以在浏览器开发者工具里查看哪个平台加载了最多JavaScript，但两者都会让我失望。

          回复

          1. 我40岁了，可从来没听说过这种事 🙂

            回复

    18. 我觉得“losers”这个词被替换成了“rookies”

      回复

    19. > 急于以进步之名向我们强加某种臃肿又漏洞百出的JavaScript框架

      能否具体说明这个JS框架是什么？是近期的事吗？

      我记得GitHub是用Rails搭建的，这些年界面变化也不大。

      回复

    21. 呃我觉得挺到位的。GitHub CEO那番“要么拥抱AI要么滚蛋”的发言虽没用脏话或直接辱骂，但我觉得威胁感和恶心感更强烈。

      Hackernews似乎总认为只要态度客气，行为恶劣也无妨。

      回复

    22. 当众侮辱开发者这种行为绝对不可接受。

      回复

    23. 是啊…对我来说这简直是压垮骆驼的最后一根稻草。

      回复

    24. 这意味着故作高深地挑起争议。

      > 暂且抛开GitHub与ICE的关系…

      若你真想抛开这个话题，本可以…直接忽略它。

      (况且从实质层面看也很荒谬。选择性封禁特定政府机构…这种做法根本不可持续。)

      回复

        1. 我以为这很明显：你将被迫根据道德标准评判每个政府/组织。比如他们是否执行移民法、是否违规执法、是否支持堕胎权、是否支持中东正义阵营、是否存在种族主义政策、是否缺乏反种族主义政策、是否限制言论自由、是否限制不足。

          每项服务都有规则，但这些规则是否足够 清晰且一致 ，让组织能可靠使用服务而不必担心被终止？

          回复

          1. > 你将被要求评估每个政府/组织的道德标准

            那又怎样？显然你不可能回应所有可能情况，只能划定某些红线。

            > 无需担心服务被终止

            是的，可以确立原则而不必加剧这些担忧

            回复

            1. > 显然你做不到

              这正是我所说的不可扩展/不可持续。

              回复

    25. 说得好。看到这类争论实在令人不快。

      回复

    26. 哎呀！ 总之 …我喜欢Zig，很高兴他们正远离GitHub的现状——尤其当足够多知名项目离开时，或许能促使他们重新聚焦核心价值。

      回复

    27. 赞同。特来指出这里缺乏专业素养和基本礼貌，令人联想到90年代末开源界的黑暗特权时代——那种“我们开发免费软件，所以可以让你滚蛋”的态度。希望我们不会重蹈覆辙。

      回复

      1. 与其没有开源贡献者，我宁愿面对这种情况。

        精英主义远非无偿代码维护者可能展现的最糟糕特质。

        回复

        1. 我对这类性格也深表理解，我自己可能也差不多——尽管我极力克制自己不这样开口。比如乔纳森·布劳曾因我推特上一个简单问题封禁我，但如今我并未对他抱有恶意——那不过是他个人判断失误，或是作为狂热者优化生活方式的尝试。但贬低他人时，你必须确保自己绝对正确。我是说绝对正确，需要反复三思：你的行为是否真能帮助诚实的人自我提升？因此我的观点是：你可以极端批判，但必须站得住脚。

          政治层面我暂不置评。但核心问题在于迁移本身显然处理不当——他既未迁移问题，也未迁移赞助者权益，导致社区分裂、关注度分散。甚至可以说，他是在批判那些继续使用GitHub赞助功能的人。在我看来，这段文字暗示着：若你继续使用这个对ziglang构成负担的东西，就是在伤害ziglang…天哪，用对方不喜欢的方式资助他人竟如此可怕。这类人忘记了贡献者也在为他们免费工作，这绝非单向付出。凡是给他们制造摩擦的事，都是你亲手给他们添的麻烦。

          回复

          1. > 我被乔纳森·布劳拉黑了

            说实话，被拉黑对你反而是好事。

            回复

          2. > 但贬低他人时，你必须确保自己绝对正确。我是说绝对正确，你需要反复确认自己的行为能真正帮助诚实的人自我提升。

            但这样就失去了情感张力，变得索然无味了！

            回复

            1. 讨论的核心是“开源开发者发布幼稚抱怨 vs 不发布”

              而非

              “开源开发者发布幼稚抱怨 vs 没有开源开发者”

              回复

              1. 若他们想放弃这种自由，

                早就去Mozilla之类的地方搞项目了(可能还拿更高薪水)对吧？

                回复

                  1. 对此我实在不知如何帮助。

                    建议多了解开源贡献机制：谁在贡献？何种情境下贡献？

                    例如：你听说过林纳斯·托瓦兹吗？

                    回复

      2. 这难道不是与当今巨头企业免费享用开源维护者劳动成果的现状相反吗？我承认企业对开源项目的贡献不可忽视，但确实存在某些显而易见的案例——某些公司想免费使用软件却不愿回馈，完全在利用项目资源。

        回复

      3. “我们开发免费软件，就是为了能对你说去他妈的。”

        比起如今企业那些粉饰过的狗屁，这听起来简直太棒了。微软通过收购GitHub混进开源圈，每个项目都套着千篇一律的行为准则。

        可悲至极。连GitHub的猴子们心底都清楚这不对劲。

        回复

    29. 不幸的真相是，这正是我们社会的现状。这并非他们的过错，反而彰显了他们的本色。他们直来直去，敢于直言(你对“直言”的定义或许不同)，还带着幽默感。你个人或许不喜欢，但即便应该被谴责，这也无损其本质。

      我们正处于漫长衰落的尾声。

      回复

      1. 把人骂成猴子和废物实在不合我的幽默感。倒不如说，这让我想起林纳斯·托瓦兹早年充满攻击性的模样。所幸他后来成熟了许多。安德鲁看起来是个聪明人，希望他能具备足够的情感成熟度，明白直言不讳无需 resort to 人身攻击。

        回复

      2. 我敢说这根本不是幽默，只会让作者显得很差劲

        回复

        1. 在我看来这分明是讽刺手法。至于读者觉得好笑还是冒犯，见仁见智——不过我认为GP的核心观点是：文章写作不该让“或冒犯”成为合理选项。

          回复

    30. 高处不胜寒与欺凌弱者截然不同。Zig此举并非欺凌弱者。

      回复

          1. 从这个PR看不太清楚。..但粗略看确实有些混乱。如果表述不清，他或许该先和核心开发者讨论？难以想象在缺乏上下文的情况下处理源源不断的PR，维护开源项目会有多轻松。

            回复

    32. 这确实不太好看，但对BDFL类型的人物来说，这难道不是常态吗？林纳斯·托瓦兹在邮件列表里说过更刻薄的话不是吗？为何此人却遭群起攻讦？莫非因为人们对GitHub仍抱有普遍好感？就在一两天前，另篇文章对匿名YouTube产品经理发动类似“人身攻击”，收获海量赞同却无人为可怜的产品经理扼腕。那些维护GitHub/微软动作的工程师们(其糟糕表现很可能并非源于任何单个人的糟糕代码)，会没事的。

      看来HN的暴民们在决定谁能被原谅时，和作者一样反复无常。

      回复

      1. > 林纳斯·托瓦兹肯定在邮件列表上说过更刻薄的话。

        令人费解的是，人们为何总拿林纳斯当借口为粗鲁行为开脱。 林纳斯已公开道歉 ，他承认自己多年来的行为不当，并主动休假反思以成为更好的人。

        > 看来Reddit暴民在决定谁能过关时，其反复无常程度丝毫不逊于本文作者。

        那些在那个帖子下评论的人，都在评论这个帖子吗？不是？那就不是同一群人，观点自然不同。根本不存在什么“暴民”，HN也不是集体意识。若是真有集体意识，你早就被同化了。

        回复

    33. 特意来这儿说句。瞬间扼杀了对Zig的好奇心。太不尊重人了。

      可惜。曾视Zig为崛起之星，但这种毒性氛围，恕不奉陪。

      回复

      1. 可惜。曾视Zig为崛起之星，但这种毒性氛围，恕不奉陪。

        别误会，确实有些毒性。但我觉得从长篇文章中拎出单条评论过度放大，同样充满毒性。

        回复

        1. > 过度放大同样充满毒性

          某人觉得不适合自己，这怎么能和领导层的不专业行为相提并论？

          回复

          1. 我个人不太在意等级制度，所以没考虑这点。任何层级都可能存在毒性。

            回复

            1. > 任何层级都可能存在毒性

              但具体情境至关重要。

              > 我未将此纳入考量

              这正是导致错误等同的根源。

              回复

              1. > 这正是导致错误等同的根源。

                不，你只是在强加无关紧要的因素。这并非错误等同。

                回复

                1. 你曾说：

                  > 夸大其词同样具有毒性

                  这恰恰将评论者帖文的所谓毒性与文章中展现的毒性错误等同。

                  你大可承认错误，不必故作糊涂。

                  回复

      2. 大概是口误，别过度解读。不能指望别人处处小心翼翼。直接反馈给他就好。

        回复

    34. 猴子、LLM、编程代理、AI——对我来说都是同义词。别和活生生的生物混为一谈。

      回复

    35. 去他的。看到公司狗屁就该揭穿。Github现在就是计算机科学学位持有者的领英。

      回复

      1. 这有什么不对？就算你说得对，不使用就是了，何必侮辱贬低他人？

        回复

        1. 因为他们有必要知道自己在让世界变得更糟。

          回复

          1. 这需要把人贬低到非人的地步吗？虚伪至极！我敢打赌你写不出比动作功能开发者更好的代码。

            回复

          2. GitHub绝对没让世界变糟。去草地上躺躺吧。

            回复

            1. 好吧，我承认这是夸张说法。但他们正以显而易见的方式逐步恶化产品体验，却莫名拒绝修复或调整方向。我指的是，通过给用户制造这些不便，他们确实从技术层面让世界变得更糟——当然，这种糟糕程度在你看来无关紧要。

              回复

              1. 这在你眼里就构成“侮辱和贬低他人”了？就因为你对他们最近的产品决策不满？

                回复

                1. 不，是公司层面的胡扯才达到“侮辱和贬低他人”的程度。糟糕的产品决策尚可原谅，甚至可以理解。谁都会犯错。而微软最近的产品决策和公司方向，则应被视为敌对行为。

                  回复

    36. 我承认文章措辞激烈，安德鲁显然很愤怒/沮丧。但这让我回想起黄金年代——当年莱纳斯曾骂那些想贡献内核的新手是白痴，说他们“连自己母亲的乳头都找不到吮吸”，活该去死。

      缺乏耐心本就是极客文化的怪癖，如今觉醒主义热潮退去，一切似乎又回到了原点！

      回复

      1. 恶劣对待他人并非极客文化的怪癖。连林纳斯自己也不这么认为。

        > 这就是我的现实。我本就不是善解人意之人，这大概对谁都不算意外——尤其对我自己。更糟的是，我常误判他人，多年未曾意识到自己对局势的错误判断如何助长了不专业的氛围。

        > 本周社区成员直指我终生未能理解情感的缺陷。我在邮件中轻率的攻击既不专业也毫无必要。

        > 尤其当我将问题个人化时。在追求更优补丁的过程中，我曾认为这种做法合理。如今我深知此举不可取，并由衷致歉。上述长篇大论实为引出一个颇为痛苦的个人承认：嘿，我需要改变某些行为，并想向那些因我个人行为受到伤害、甚至可能因此彻底远离内核开发的人们道歉。

        > 我将休假一段时间，并寻求专业帮助来学习如何理解他人情绪并作出恰当回应。

        他确实言行一致。此后他变得更好。Linux因此成为更优秀的项目。但我猜想，这确实影响了一代仰慕林纳斯的软件从业者，让他们认为这是对待自认地位低于自己的人的正确方式。

        回复

        1. 但这种现象非常普遍。我曾看过凯西·穆拉托里的一段YouTube视频，他宣称使用垃圾回收语言的人都是蠢货，根本算不上合格程序员！就这么一句，他得罪了我们行业95%的人。他还说使用智能指针的人只是新手，尚未领悟真正的编程之道，这又冒犯了剩余的5%。而这类言论及其拥趸实在比比皆是！

          回复

          1. > 但这种现象非常普遍。

            需谨记“普遍”不等于“正确”或“积极”。许多事物曾普遍存在，比如气溶胶喷罐里的氟氯烃，以及家用物品中的放射性元素。

            我并非质疑你的论点——相反，我感觉你是在陈述观点而非辩护——但仍认为这个要点不容忽视。

            > 我在看Casey Muratori的YouTube视频时

            你还记得是哪段视频吗？这有点遗憾，我希望能亲自看看以了解上下文和语气。从我所见凯西的内容来看，我预期他会温和地批评 语言 本身，而非针对人群。虽然我主要看到的是他单独教学或接受一对一采访的片段，但感觉他在播客中可能有所不同。

            回复

          2. 我真心觉得林纳斯通过将他的领导风格正常化造成了巨大伤害。年轻开发者渴望效仿如此杰出的林纳斯，自然会模仿最容易效仿的习惯——辱骂、攻击、贬低、轻视。

            如今林纳斯有所改善，但这种行为模式已深深植根于许多人心中。他们现在标榜“实话实说”、‘直来直去’，声称没时间顾及“政治正确”等等。

            回复

      2. 虽然我通常认为建设性批评才是正确选择，但除非出现措辞极其严厉的批评，否则Github恐怕永远不会领会其中深意。为安德鲁辩护的话，他确实提出过一些他认为存在问题的建设性证据。

        回复

        1. 像Zig这样知名的仓库离开GitHub已是最强有力的信号。掺杂“失败者”“猴子”之类的词只会模糊传递效果。

          回复

          1. 完全正确。我还没看完那篇帖子，也永远不会看完。这种措辞既破坏了信息传递效果，也损害了个人声誉。

            回复

        2. GitHub能收到的最有效信号，就是当他们收不到你的账单时。

          GHA尤其是一团糟，十年前我就惊讶于居然还有人用这破玩意儿。依我看这根本是“漏洞即服务”的产品，其核心设计缺陷就体现在那种“假装是YAML却实则是shell、js和json邪恶混合体”的语言上。

          回复

    37. 这里的“猴子”显然指的是那些敲打打字机的家伙。

      回复

      1. 显然并非“显然”——毕竟很多人没看懂，但这也是我的第一反应： 我理解为“无限猴子”的典故，结合上下文大概指代“未经测试的通用AI输出”。点击链接后，似乎正是这种情况？

        总之，“无限猴子敲打打字机”确实是此处“猴子”的关联含义。

        回复

        1. 显然美国存在特定文化历史背景，曾有人用“猴子”作为种族歧视侮辱黑人，因此当地人会立即联想到任何用“猴子”侮辱他人的情况。

          回复

          3. 你以为这只是美国特有的现象？？哎呀，我有个坏消息要告诉你。

            回复

    38. 涉及GitHub和微软这类话题时，我们早已超越了文明的底线。

      回复

      1. 所幸我们多数人并不属于你所指的“他们”。这种有毒文化我绝不沾染，它充分暴露了Zig社区的本质。

        回复

    39. > 臃肿又漏洞百出的JavaScript框架

      这不正是令人遗憾的现状吗？至少对JS而言是硬性要求。

      谷歌主页最近开始强制要求此项验证。Linux内核的Git、OpenWRT、esp32.com等众多项目也通过令人头疼的“确保您不是机器人”验证机制强制执行：

      https://news.ycombinator.com/item?id=44962529

      值得庆幸的是，GitHub在这方面还算落后——至少基本功能在关闭JS时仍可正常使用。

      回复

  82. 看这些评论，痛心的是多少人认为沟通礼貌比实际行动更重要。

    我承认措辞更礼貌会更好。但若将其与背脊骨般坚持对抗不值得信任的企业、推动有意义的长期变革相比，根本不值得讨论。

    至于那些跑来指责Codeberg也不完美的家伙，我连讨论的兴趣都没有。

    回复

    1. > 我同意措辞更礼貌些会更好。但若将此与对不信任或不尊重的企业展现骨气、推动实质性长期变革相比较，根本不该有讨论余地。

      你将其框定为非此即彼，实则不然。推动实质变革与成熟沟通并非矛盾，二者往往相辅相成。

      回复

      1. > 两者并不冲突；往往相辅相成

        我认为它们本质上是冲突的。每个人每天只有24小时，要么用于研究并践行正确之事，要么用于达成共识。两者确有某种程度的协同效应(因为对正确选择达成合理共识通常是明智的)，但超越基础层面后必然存在取舍。

        对于编程语言设计师，我尤其欣赏他们做出正确的长远决策——即便我最初无法理解其初衷。

        回复

    2. > 令人痛心地明显的是，许多人认为沟通中的礼貌比实际行动更重要

      所以你希望人们讨论行动而非礼节。很好。

      > 更别提那些专程来指出Codeberg也不完美的人了。

      除非他们是在Codeberg上采取的行动？

      在讨论重大仓库迁移至Codeberg的帖子中，分享Codeberg使用体验并不离题。

      回复

      1. 对“礼仪”的迷恋阻碍了每一次积极的社会变革。这正是马丁·路德·金所指的白人温和派——他们宁可选择消极和平而非积极变革：

        黑人迈向自由之路的最大绊脚石，并非白人公民委员会成员或三K党徒，而是那些更热衷于“秩序”而非正义的白人温和派；他们宁可选择消极和平——即没有紧张局势的状态，也不愿追求积极和平——即正义得以彰显的境界；他们总在说：“我认同你们追求的目标，但无法赞同你们采取的直接行动方式”

        回复

        1. 当然，马丁·路德·金以对持异议者施以尖刻人身攻击而闻名。

          你真该退一步思考：当开源项目决定更换CI提供商时，将马丁·路德·金争取种族平等的斗争作为参照点是否恰当。

          回复

          1. > 你真该退一步想想：开源项目更换CI服务商，拿马丁·路德·金争取种族平等的斗争作类比是否恰当？

            对于那些因Git托管服务商问题就大闹一场、公开辱骂其他开发者的极客而言，离开GitHub的举动或许比马丁·路德·金的任何壮举都更具意义。

            回复

        2. 设计拙劣的CI系统堪比KKK组织。这正是当今网络讨论的真实写照。

          回复

    3. > 令人痛心的是，太多人认为沟通礼貌比实际行动更重要。

      Zig维护者也这么认为，所以官网才挂着行为准则。但老样子，这又是“只许州官放火，不许百姓点灯”——要是有人骂作者是“猴子”，我敢保证他会搬出准则指责对方，可轮到他自己这么干时就无所谓了。

      回复

    4. 没人这么想。他们只是不认为“有所作为”就能成为当混蛋的借口。尤其当你虚伪地违反自己制定的行为准则时。

      回复

      1. 当然有。若让我在0.1倍效率的友善工程师和10倍效率的烦人精之间选同事，我永远选后者。

        网络已演变成这种新话式、审查驱动的文化，令人痛心。我希望人们能坦率地说出“我认为这很糟糕，理由如下”。

        回复

        1. 面对这样的选择，我不会与他们任何一方合作。世上不缺既是优秀工程师又 不是混蛋 的人。

          回复

    5. 礼貌无需成本且举手之劳，这并非苛求，更不该成为非此即彼的选择。

      我甚至不愿称之为礼貌，这更像是基本的人类体面。如果LLVM团队公开发文称Zig维护者是失败者和猴子，安德鲁·凯利会觉得高兴吗？这种行为简直暴露了他们的幼稚，考虑到他们的政治立场，倒也不足为奇。

      回复

    6. 有人在十一月最后一周将项目迁移到其他平台的事实，本身就暗示着忍无可忍。这种事更像是发生在一月或六月，而非十一月/十二月。

      愤怒能成为强有力的驱动力，促使你完成拖延已久的事。这也意味着你的社区公告会相当犀利——除非你让别人代笔。

      回复

    7. > 令人痛心地明显的是，许多人认为沟通中的礼貌比实际行动更重要

      我完全赞同，但任何大型项目/团队的负责人，都该明白不该将个人情绪和观点混入“官方”声明。我自己也犯过这种错误，没人能自诩清高，但AK更该懂得分寸。

      回复

    8. 说得好。这种圆滑油滑的措辞正是大公司的作风。我不喜欢这篇帖子的写法——但真正重要的是他们正成功脱离GitHub。希望更多开源项目效仿。

      回复

  84. 尽管多数人在此辩护，我却欣赏Zig在博客中的措辞。我们不是虚伪的企业，那里人力资源部门操纵你的言辞，用“大家庭”的口号包装，却在方便时随时解雇你。

    安德鲁的表达自然真实，其价值远胜于其他一切。感谢你，这令人耳目一新，让我想起互联网的黄金时代——那时每个人都能自由书写所思所想。

    你算什么东西，竟敢评判他人表达观点的方式？

    编程愉快，安德鲁！

    回复

    1. 你读过原文吗？没错，他确实提了一句ICE，或许你不同意其政治立场。但文章主体都在讨论GitHub平台的技术问题及其对非AI功能的忽视。请把低质量评论搬去X平台。

      最后不得不说：开源项目创建者有权注入自身价值观，没人讨厌SQLite，更不该因开发者在心血项目中添加政治立场/价值观而攻击。若如此反感，请自创“非觉醒主义”语言。

      回复

    2. Github才是更“觉醒”的平台，你完全没抓住重点。

      回复

      1. 一家热衷协助种族灭绝的公司所拥有的平台，根本不配被称为“觉醒”。

        回复

        1. 这就是所谓的觉醒/彩虹帝国主义。

          回复

      1. 这GPT代码写得如此荒谬，我不得不认为这是讽刺。

        回复

      2. 看来人们觉得耍混蛋是证明自己不是LLM机器人的信号。

        回复

  87. 这话我倒认同。去他妈的GitHub。既然他们能打着进步旗号为所欲为，被骂猴子也活得下去。凡是贴着微软标签的东西，都是吸毒鹱鸟设计的垃圾。

    与其哭诉Zig的COC，不如去改进那个噩梦般的框架。

    回复

  88. 我原以为那些指责他言语冒犯的人在此发声尚有道理。但读完帖子才发现——根本毫无冒犯之意。称人代码猴子这种说法，在我记忆里早已存在。若你职业生涯中从未自问过“我是不是代码猴子？”，那你不是聪明绝顶就是愚不可及。

    我完全赞同Github已沦为垃圾场，甚至不用看代码就能感受到React散发的恶臭。React的问题遍布世界每个角落，任何鼓吹它的人我都敢当面称其为代码猴子。问题不在于JavaScript本身，而在于框架理念——那简直是垃圾。若有人因“代码猴子”之称感到冒犯，我倒觉得他们或许该如此。

    回复

  89. 真是忘恩负义。希望他能把乞讨来的钱捐给Codeberg，作为回报他们提供的服务。

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的：