关注+星标公众号，不错过精彩内容
来源 | 网络
Linux已经走过了33个年头，而时到如今，创始人Linus在一直为了推动其发展而争吵不断，是一个出了名的“暴君”。然而对于Rust进入Linux内核遇挫这件事上，Linus似乎变得平和起来，甚至有些“理智的消极”。Linus坦言：自己搞不懂为什么到现在，Rust竟然还会有如此大的争议！9月初，一位Linux内核维护者Wedson在网上发布了帖子，自曝跟Rust语言贡献者发生了冲突，因为难以忍受适配Rust的C插件问题过程中的“非技术性的技术废话”愤而辞职。这一场Linux内核的C语言和Rust语言贡献者之间发生的冲突，Linux创始人Linus Torvalds将其定性为“几乎带有宗教战争色彩的争议”。在本周三举行的开源峰会主题演讲中，托瓦兹表示，尽管争议中不乏健康的辩论，但有些辩论变得非常消极。Linus将这一争议比作vi与emacs之间的文化战争，即哪种文本编辑器更优越，这也被称为“编辑器大战”。“我实际上很享受这种争论。我喜欢辩论。我认为Rust的一个优点在于它让一些讨论变得生动有趣，虽然有些争论变得很难听……但这表明人们是多么在意。同时，我不太确定为什么Rust会成为如此有争议的话题，”托瓦兹说。“这让我想起了我年轻的时候，人们争论vi和emacs哪个更好，但不知何故，整个Rust与C的争论在某些方面几乎带上了宗教色彩。”然而，对于选择哪一种编辑器，抑或哪一种语言，相信大多数程序员最后都会回答：我并不care。因为程序员并不需要用最难的工具来证明自身的技能。一个好的程序员是懒惰的！一位知情人透露，一小部分C内核开发人员似乎决心让 Rust 维护者的生活变得尽可能艰难。他们认为 Rust 毫无价值,宁愿Rust消失。“去年，当我尝试将DRM 抽象上游化时,Rust 中对"device”概念的基本支持全部受阻。即使只是 struct device 的存根包装器也足够了。直到最近，也就是一年多之后,这个简单的概念才终于得以实现。”一个概念用了一年多才得以实现，可想而知Rust融入C版的Linux将有多难。
一方面是技术上的问题，“当我编写 DRM 调度程序抽象时,我遇到了许多由底层C代码设计不良引起的内存安全问题。生命周期竟然没有记录,而就是简单归结为‘像 amdgpu 一样设计驱动程序以使其工作，或者其他’。”但由此体现出的更多是人的问题：这位知情人其他C驱动程序也会因为糟糕的API问题触发相同的错误，需要查询隐藏的生命周期时，C维护者们依旧不为所动。在原来的这位C维护者看来，一个C驱动程序可以work，那么Rust驱动程序也必须以相同的形式work。没错，表面上看是两种语言的特性冲突，但实际上看是C版内核维护者在向Rust贡献者宣示自己对于Linux贡献的绝对主权。新王未成，旧王维稳。就如同Linux通过30余年建立起开源霸主的地位一般，C语言这位王者在与Rust这位未来极具挑战性的后起之秀的关系上多少有些尴尬：一方面自己需要Rust来解决自身积累多年的内存安全等方面的问题，另一方面在引入Rust的同时又面临着被新语言思想适配所带来的被重构的尴尬与不安。这种“尴尬与不安”可以形容为“甘道夫级别的C巫师因为要重新披上一个新手巫师的Rust道袍而顿感羞耻”。一些C内核的维护者认为自己的开发信念受到了攻击，让他们突然接受自己的代码或自己喜欢的代码马上就要变过时了，并没有那么容易。一、Linux内核的C接口不会分享给Rust，但当Rust接口提出时，就会被指出它是错误的，而且不给出任何修复建议；二、即便Rust接口被同意合并了，它也不过是二等公民。在重构C接口时，Rust接口却得不到更新，所以更没有人会去用Rust接口写的驱动程序；三、一个有毒的工作环境。比如——在Rust版内核演讲中，C版内核维护者用看似闲聊实则极其激烈的方式进行嘲讽：“你们只不过是想让更多人皈依你们的Rust宗教！”直至让工作人员精疲力尽，对项目产生倦怠。这里，不得不展开提一下Wedson离职还暴露了另一个我们往往忽视的问题：Linux的工作环境正在变得“不和谐”甚至“有毒”。本月初，他在宣布“卸任Linux项目的Rust语言维护者一职”中提到了YouTube上一个关于Rust中文件系统的视频：“重申一遍，没有人试图强迫任何人学习Rust，也没有人阻止C代码的重构，”Wedson写道。这个视频是Wedson和另一位开发者Kent的演讲会议，坐在下面有一些C语言的Linux内核开发者。这些开发人员似乎并不关心30分钟的演讲内容，更多地是嘲讽某一页的幻灯片。Wedson本身是一名C程序员，但他对Rust for Linux项目充满着热忱。“Linux项目的Rust团队：谢谢你们，你们很棒。与你们所有人一起工作是我的荣幸；我们一起讨论技术问题、寻找解决漏洞的方法等时光，都是我一直喜欢并期待的。我很幸运能与这样一个才华横溢、友好的团队合作。”“我祝愿项目一切顺利。我真的相信内核的未来在于内存安全的语言。我不是一个先知，但如果Linux不将其内化，我担心其他内核会对其做出与Unix相同的事情。”问题的核心在于C语言和Rust语言在跨语言边界提交更改时产生的文化冲突。正如Linus今天所描述的那样，C语言是一种相对“简单的语言”，这也是“我喜欢C语言，以及为什么许多C语言程序员喜欢C语言的原因之一。当然简单也是有代价的，因为简单，所以也很容易出错。“而Rust则完全不同。有很多习惯于C语言模式的人，他们不一定喜欢这种差异，这也没关系。”从Rust的角度来看，为Rust用户修改某个C接口可能是有意义的，而C语言用户则希望Rust能做出贡献，以便与C语言结合使用。这一争议可以追溯到三年多前，当时有人提出Rust语言因提供C语言所不具备的某些安全优势，可以成为内核的一部分，甚至可能取代C语言。尽管如此，该项目并未因此停滞不前。例如，以前用C语言和CPU可以制造的著名缓冲区溢出黑客攻击或漏洞，现在几乎已经过时了。虽然Rust提供了一些安全特性和不足，但相比之下，它比C语言更难学，而C语言则更容易掌握。有人会想到另一个解决方案：既然Rust融不进去C版Linux，直接做一个Rust版的Linux内核不就好了吗？正如思科公司 Isovalent 的首席开源官 Liz Rice 认为，Rust 是一种较新的语言，具有“非常强大的优势，但并不是所有人都会立即知道如何编写 Rust 代码。很多在内核的 eBPF 子系统上工作的人不会突然转去学习 Rust，以便完成工作，对吧？”Rice 还提及了一个看起来幼稚但非常有代表性的场景：“我见过人们这样说，‘哦，好吧，那我们为什么需要 eBPF 验证器？如果我们用 Rust 完成所有工作，那就可以移除它了‘。” 但很明显，当提问者这么说时，并没有完全理解 eBPF 验证器的全部目的。开发不止是编程，更多还需要考虑代码所服务的需求和场景。对于这一点，Polar Signals 的首席执行官兼创始人 Frederic Branczyk 也表示赞同：“在 Rust 中有很多例子，你不得不做一些不安全的操作，然后在其基础上构建安全的抽象。”“所以，我当然不是认为 Rust 会是一切问题的救星。我其实是 Rust 的大粉丝，但我认为 C 实际上是一种编写操作系统的非常好的语言，而 Rust 也可以完成很多工作。”王者与新秀并存的场面，起初往往都是这样，难以平衡。王者积累了相对稳定和成熟的基本框架和路径，但也滋生了难以逾越仅凭自身就能解决的问题；而新秀虽然在王者难以专注的领域异军突起，但往往缺乏必要的、难以察觉的时间经验。在技术领域更是如此。因为在技术领域，基本规则一开始变化往往难以察觉，随后又将会指数级迅速变化。整体上看，C 语言非常适合快速发展、资源受限的环境。但在稳健性、安全性和可维护性与硬件性能过强和大量共享的环境相结合的情况下，情况就不那么理想了。所以Linus才寄希望于Rust的加入。然而，Rust for Linux项目给内核开发者带来了新的基本规则变化。遗憾的是，对于Linux而言，Rust和C内核贡献者之间似乎存在着某种难以逾越的鸿沟。毕竟，数十年来在复杂环境中高效工作所获得的知识、经验和观点并不局限于某一特定语言，而这也正是Rust融入Linux所需要的。悲剧的是，C版内核维护者能否接纳Rust的开发方式，为Rust提供宝贵的开发经验，至少现在看也是一个很难接受的问题。
不得不说，在Linux内核融入Rust上面，Linus碰到了一个硬钉子。C语言和Rust语言两大阵营的分歧相当大。“有些人就是不喜欢Rust的概念，也不喜欢Rust侵入他们的领域……人们甚至谈到了Rust集成的失败。”Linus对此也是无解：“有很多人习惯了C模型，但他们不一定喜欢差异......没关系……有些人关心特定的架构，有些人喜欢文件系统，这应该是这样的。这就是我看待Rust的方式。”但Linus对于这个项目充满期待：“我们已经做了几年了，所以现在甚至说这些还为时过早”。不过他也没有说太满：“但我也认为，即使它失败了（而我认为它不会），这也是一种学习的方式。所以，我认为这种推广活动是有积极意义的。”毕竟，时间是一切问题的良药，在这场讨论中，主持人在临近尾声时开了一个调侃的玩笑：“Torvalds在过去33年里一直是Linux项目的傀儡，但不太可能再担任33年。希望到那时，关于Rust的争论会得到解决。”https://www.theregister.com/2024/09/02/rust_for_linux_maintainer_steps_down/
https://www.theregister.com/2024/09/19/torvalds_talks_rust_in_linux/
声明：本文素材来源网络，版权归原作者所有。如涉及作品版权问题，请与我联系删除。------------ END ------------
回复“加群”按规则加入技术交流群，回复“1024”查看更多内容。
