最近，Rust for Linux 專案的開發者之一 Wedson Almeida Filho 辭職了。
在臨別留言中，他連結了一段檔案系統維護者對他大喊大叫的影片。
之後，Linux 版蘋果 GPU 驅動程式（尚未上游化）的開發者 Asahi Lina 在 Mastodon 上釋出了一系列帖子（第一篇），對 Wedson 表示同情，並從 DRM 的角度表達了自己對維護者和 Rust 的不滿。
雖然我們很容易把這看成是 "Rust 仇恨者與 Rust 推動者 "之間的爭鬥，但我認為這意味著 Linux 中存在著更深層次的問題，既有技術方面的，也有文化方面的（兩者往往相互影響）。
在本文中，我將為那些不熟悉的人總結一下這些問題，並推測它可能導致的後果。
Linux文件和介面
Rust 開發人員面臨的最大問題之一是獲取Linux介面文件。使用 C 語言編寫程式碼時需要這些文件，但對於核心的 Rust 部分來說，這更為關鍵。
由於 Rust 將資源生命週期等內容編碼為型別的一部分，因此瞭解這一點對於安全地使用介面至關重要。除了必須閱讀實現或將其牢記在心之外，缺乏這些資訊會損害 API、重構以及 Rust 的所有新消費者。
如果子系統維護者無法幫助解決此類問題（無論是否使用 Rust），那麼就很難放心使用介面。
Linux測試與 CI
幾十年來，單元測試一直是軟體工程的重要組成部分。 持續整合最近開始流行，但它是測試的補充。 沒有測試，你怎麼知道你的更改是否仍然有效？沒有持續整合，你又怎麼知道是否為時已晚？ 對於更換子系統或驅動程式來說，如果你採用的是絞殺模式（strangler pattern），這一點就尤為重要。
不幸的是，核心最近才透過 kunit 等形式獲得了單元測試功能。 CI 也是最近才開始出現，但在整個專案中並不一致，原因我們稍後再談。 對於某些事情來說，這是可以理解的；如果沒有硬體和觀察硬體的能力，驅動程式的單元測試可能會很困難。
開發工作流程
沒錯，就是電子郵件。 Linux 核心郵件列表（Linux Kernel Mailing List）在基於電子郵件的開發工作流程方面是出了名的頑固派，不過也有人嘀咕過要用不同的方式來做事（子系統也有自己做事的餘地）。 這確實意味著貢獻工作更加困難（設定 git-send-email 是一回事，但使用它來迭代稽核又是另一回事），而且如果沒有工具來簡化工作，事情很可能會在收件箱中消失。
總之
我認為 Rust for Linux 專案處於危險之中，這並不是因為技術原因（儘管更大的核心也無濟於事），而是因為社會原因。