红帽公司（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 驱动程序必须以同样的方式工作。"

不幸的是，没有简单的解决方案。