红帽公司(Red Hat)的长期直接渲染管理器(Direct Rendering Manager,DRM)子系统维护者大卫-艾尔里(David Airlie)撰写了一篇有趣的博文,将开发人员的类型与筑路工人、寻路者与酒店进行了类比。
鉴于最近一位 Linux Rust 维护者因”非技术性的胡言乱语”而离开的传闻以及最近几天发生的其他 Rust Linux 内核事件,Airlie 撰写了一篇博文,对开发者的类型进行了比较,并说明了他认为开发者应该如何更好地参与和合作。
“我认为[Rust for Linux]项目已经完成了很多出色的寻路工作,有很多寻路工作正在进行中,未来可能还有很多寻路工作要做。有一些不错的酒店已经建成。对于上级部门来说,道路建设过程可能显得缓慢。他们可能认为汽车已经在路上行驶,因此会从不同的角度看待路障。
对于寻路者来说,与维护者互动的过程是令人沮丧和缓慢的,他们并不像寻路者那样享受这个过程,而且由于他们最终仍然只关心酒店,当维护者进入他们特定路口的细节时,他们什么也不想做,只想去住他们的酒店。”
请在Airlie 的博客上阅读全文。
在此之前,Asahi Linux 开发人员 Asahi Lina 也在Mastodon上撰文批评了为 Linux 内核上游化 Rust 代码所带来的头疼问题,以及经常与内核维护者发生的摩擦:
“有一部分 C 内核开发人员似乎一心想让 Rust 维护者的生活变得尽可能困难。他们认为 Rust 没有价值,并希望它就此消失。去年,当我试图将 DRM 抽象推向上游时,这一切都受阻于 Rust 对”设备”概念的基本支持。
这个简单的概念直到最近才终于在一年多之后被合并。
当我编写 DRM 调度器抽象时,我遇到了许多内存安全性问题,这些问题都是由于底层 C 代码的糟糕设计造成的。
我的驱动程序和 amdgpu 不一样,从根本上说,它无法以同样的方式运行。
即使我指出其他 C 语言驱动程序也会引发同样的错误,因为其 API 既糟糕又不直观,而且还有许多秘密隐藏的寿命要求,他也不肯让步。
一个 C 语言驱动程序可以工作,所以 Rust 驱动程序必须以同样的方式工作。”
不幸的是,没有简单的解决方案。