Linus 的铁腕决策：技术争议背后的思考

一、事件背景

Linus Torvalds 拒绝了 Kent Overstreet 在 Linux 6.13 中提交的 Bcachefs 拉取请求，这一决定在技术圈内引起了广泛关注。事件的起因可以追溯到今年九月初，Kent Overstreet 在邮件列表中对 SUSE 开发者 Michal Hocko 的不当言论。他在回应中使用了极具攻击性的语言，建议 Hocko “检查下大脑”，这一言论被视为 “人身攻击”，引起了 Linux 内核 CoC 委员会的注意。

随后，委员会要求 Overstreet 遵守 Linux 社区行为准则，并针对这一言论公开道歉。然而，Overstreet 拒绝公开道歉，他认为这只是一次技术讨论的失控，并非恶意针对个人。

这一事件不仅影响了 Bcachefs 的未来发展，也引发了人们对开源社区文化和行为规范的反思。开源项目的发展不仅需要技术上的支持，更需要来自社区的信任和合作。良好的沟通和尊重是保持健康合作氛围的基础，而个人的言论和行为可能会瞬间影响整个项目的未来。

此外，Linus Torvalds 对 Bcachefs 的一些 proposed code 也表示不满。他认为这些补丁把 Bcachefs 代码中的一些元素移到了一些 library-type 的代码中，试图将其作为通用库代码推向市场，这让他感到介意。Linus Torvalds 直言 “stdio_redirect_printf” 和 darray_char 都很 “恶心”，建议 Overstreet 将其保留在自己的代码中。

在合并了实验性 Bcachefs 文件系统的最新一轮修复后，Linus Torvalds 也表达了自己的沮丧。他认为 Overstreet 在开发过程中缺乏与其他开发者的交流与合作，补丁在树之外没有经过充分测试就提交，这让他对 Bcachefs 的未来发展提出了两种选择：要么加强与他人的合作，要么将其从 Linux 内核主线中剥离。

二、事件经过

1. 激烈的技术讨论演变为言语冲突

在 Kent Overstreet 与 SUSE 开发者的讨论中，言语冲突不断升级。事件起因于今年九月初，在一封主题为 “bcachefs: 请勿使用 PF_MEMALLOC_NORECLAIM” 的邮件列表中，Overstreet 对 SUSE 开发者 Michal Hocko 的回应言辞激烈。他认为 Hocko 的观点存在问题，甚至建议 Hocko “检查下大脑”。这种极具攻击性的语言被视为 “人身攻击”，引起了 Linux 内核 CoC 委员会的高度关注。

文件系统领域的开发者最初对 PF_MEMALLOC_NORECLAIM 持反对态度，但在进一步讨论实际影响及查看实际的 GFP_NOFAIL 使用和错误处理路径后，态度似乎有所转变。然而，推动回滚的 mm 维护者并不买账，他表示此事已在幕后讨论中决定，且不愿进行技术讨论。当被要求提供讨论理据时，他仅提供了一份决定的电子表格，却未解释原因。当 mm 维护者希望直接杀死错误使用 GFP_NOFAIL 的进程而非让其返回缺失的错误处理路径时，Overstreet 在气急之下说出了那些过激的话。

2. Linus 的态度及回应

Linus 对 Kent Overstreet 的行为表示强烈不满。他要求 Overstreet 道歉，并在合并代码时展现出严格的态度。Linus 认为，开发者之间应保持尊重，良好的沟通是合作的基础。

在今年 10 月，Linus 在合并实验性 Bcachefs 文件系统的最新一轮修复时，对 Overstreet 提出了严厉批评。他指出 Overstreet 的补丁在树之外没有经过充分测试就提交，这让他感到失望。Linus 直言自己受够了 Overstreet 的行为，并提醒他在 big-endian 机器上的构建失败。Linus 对 Bcachefs 的未来发展提出了两种选择：要么加强与他人的合作，要么将其从 Linux 内核主线中剥离。

三、事件影响

1. bcachefs 的未来变得不确定

由于 Linus Torvalds 拒绝了 Kent Overstreet 在 Linux 6.13 中提交的 Bcachefs 拉取请求，bcachefs 的未来发展确实变得充满不确定性。这一决定让开发者们感到担忧，毕竟 bcachefs 是一个旨在提升 Linux 内核存储性能的文件系统，尤其对于希望利用高效存储方案的开发者和用户来说，bcachefs 曾被寄予厚望。其核心特性包括支持数据快照、压缩及加密功能，与传统文件系统相比，能提供更高的 IO 性能和灵活性，适合大规模数据处理和云计算环境。然而，现在由于合并请求被拒，bcachefs 的发展之路变得不明朗，开发者们不得不重新审视项目的未来走向。

2. 引发对技术争议处理方式的思考

这一事件引发了人们对技术争议处理方式的深刻思考。在技术讨论中，如何在保持专业和尊重的前提下进行交流至关重要。Kent Overstreet 与 SUSE 开发者 Michal Hocko 的争论从技术讨论演变为言语冲突，这种情况在技术社区中显然是不可取的。开源项目的发展需要技术上的支持，更需要来自社区的信任和合作。良好的沟通和尊重是保持健康合作氛围的基础，而个人的言论和行为可能会瞬间影响整个项目的未来。

就像这次事件，Kent Overstreet 的过激言论不仅引起了 Linux 内核 CoC 委员会的注意，还导致了自己的合并请求被拒。这提醒我们，在技术谈判中，尊重与包容是多么重要。技术和人际关系相辅相成，当团队内部的信任受到考验时，技术项目的健康增长将变得岌岌可危。我们应该从这次事件中吸取教训，在技术讨论中，始终保持专业和尊重，以理性的方式表达自己的观点，避免言语冲突，共同推动技术的进步。

四、总结

技术争议本就正常，但需注意方式方法

技术争议在软件开发领域是不可避免的，正如 Linus Torvalds 拒绝 Kent Overstreet 在 Linux 6.13 中提交的 Bcachefs 拉取请求事件所展现的那样。技术争议本身并不可怕，可怕的是开发者在争议过程中失去理性和专业，陷入言语冲突和人身攻击。

在技术合同中，争议的处理方式有协商、调解、仲裁和诉讼等。协商是最佳方式，合同当事人在友好的基础上相互协商解决纠纷；调解则是由第三者主持协商，促使当事人达成解决协议；仲裁是合同当事人根据仲裁协议将争议提交给仲裁机构作出裁决；诉讼是合同当事人依法向人民法院起诉，由人民法院作出判决。

在技术讨论中，我们应该以理性和专业的方式进行交流，避免言语冲突。就像成都中院设立的 “技术调查官流动站”，旨在解决涉高精技术知识产权案件中的技术争议。通过整合司法、行政、高校等多元力量，实现 “技术咨询随时、技术人员随地、技术保障全程”。在技术争议中，技术调查官充当着当事人和审判人员之间的 “技术翻译”，为合议庭查明技术相关事实提供专业辅助意见。

技术争议的解决需要我们保持尊重与包容，以理性的方式表达自己的观点。在技术合同争议中，和解与调解是重要的解决途径。和解通过当事人自行协商达成和解协议，具有简便易行和友好解决的特点；调解则通过第三者主持协商，促使当事人达成解决协议。在技术争议中，我们应该遵循自愿原则，不得强迫任何一方接受调解结果，同时保持公正的立场，不得偏袒任何一方当事人。

当技术争议无法通过和解与调解解决时，仲裁和诉讼是最后的途径。仲裁是合同当事人根据仲裁协议将争议提交给仲裁机构作出裁决，仲裁裁决具有法律约束力；诉讼是合同当事人依法向人民法院起诉，由人民法院按照审判程序作出判决。在选择仲裁或诉讼解决技术合同争议时，当事人应该充分了解相关法律规定和程序要求，以确保自己的权益得到充分保障。

总之，技术争议本就正常，但开发者应该以更加理性和专业的方式进行讨论，避免言语冲突和人身攻击。在技术争议中，我们应该选择合适的争议解决方式，保持尊重与包容，以理性的方式表达自己的观点，共同推动技术的进步。

免费小程序《字形绘梦》上线啦！

欢迎大家体验！