Linux 内核 Rust 实验现状
Rust驱动程序的安全性确实远超C语言编写的驱动。托瓦兹指出，已有呼声要求为Rust代码分配CVE编号，这证明该语言绝非实验性工具
使用Rust编写内核代码的能力是以实验形式明确引入的——若进展不顺，Rust将被移除。在2025年维护者峰会上，特别召开会议评估该实验进展，并决定是否宣布实验成功。结论(或许在意料之中)是实验确实成功，但过程中也提出了一些值得关注的观点。
核心进展
主持会议的Miguel Ojeda首先公布了多项重要进展：NVIDIA GPU的Nova驱动即将问世，部分代码已合并至主线；Android绑定驱动已随6.18版本合并。他透露更重磅的消息是：搭载6.12内核的Android 16系统已开始出货，其中包含用Rust语言编写的ashmem模块。这意味着数百万台真实设备正在运行内含Rust代码的内核。
与此同时，Debian项目终于在其内核构建中启用了Rust支持，该功能将出现在即将发布的“forky”版本中。内核中的Rust代码量正呈现“爆炸式增长”，过去一年间增长了五倍。内核开发者与Rust语言开发者之间的协作日益紧密，使内核项目对语言本身的发展产生了重大影响。他表示，Rust 社区致力于协助内核项目。
将 GCC 代码生成器移植到 rustc 编译器的 rust_codegen_gcc 项目正在推进。与此同时，完全基于 GCC 的 gccrs 项目进展顺利。该项目现已能编译内核的 Rust 代码(不过显然，将其编译为正确可运行代码的工作仍在进行中)。gccrs开发团队将内核构建列为首要任务之一；Ojeda表示明年该项目将带来令人期待的进展。
关于Rust语言版本，当前计划是确保内核始终能使用Debian稳定版发布的Rust版本进行构建。内核的最低版本要求将在对应Debian版本发布后6-12个月内提升。当前内核要求最低Rust版本为1.78，而最新版本(截至会议时)为1.92。鉴于Debian发行版采用1.85版本，Ojeda建议内核迁移至该版本，此举将使若干临时解决方案得以移除。
Jiri Kosina询问最低语言版本的更新频率； 奥赫达重申将在每次Debian稳定版发布后更新，但未来可能改为隔次更新。他表示这主要取决于开发者需求。林纳斯·托瓦兹表示只要不导致开发者被排除在外，他乐意相对激进地提高最低版本要求。发行版对Rust的更新速度已超越传统GCC更新节奏，因此要求更高版本应不成问题。
阿恩德·伯格曼指出，内核本可提前一年将GCC 8设为最低支持版本，但受限于SUSE企业版Linux(SLES)的更新滞后。科西纳回应称SUSE正逐步改进，现已开始提供新版编译器。戴夫·艾尔利担忧企业发行版启用Rust后可能引发问题——它们可能长期锁定陈旧版本。不过Thomas Gleixner指出，如今连Debian都已发布GCC 14，整体形势已有所改善。
仍属实验性？
鉴于上述进展，Ojeda提出是否该重新审视“实验性”标签？他此前一直谨慎对待此项变更请求，但表示随着Android开始部署Rust代码，现在正是时机。艾尔利提议在4月1日宣布实验失败。他严肃表示，移除“实验性”标签将有助于开发者在公司争取更多资源投入Rust开发。
伯格曼赞同宣告实验结束，仅担忧Rust仍“无法在无人使用的架构上运行”。因此他认为当前应将Rust代码限制在支持完善的架构上。奥赫达指出x86、Arm、龙芯、RISC-V及用户模式Linux目前支持良好，主流架构已具备成熟基础。伯格曼询问PowerPC支持情况，奥赫达回应称PowerPC开发者是最早提交拉取请求为该架构添加Rust支持的团队之一。
伯格曼继续追问s390架构的支持问题；奥赫达表示他已研究过该问题，认为理论上可行，但不清楚当前进展。艾尔利指出IBM需要解决此问题，并表示此事终将落实。格雷格·克罗哈-哈特曼强调Rust上游项目支持该架构。伯格曼询问是否预见到大端系统存在问题；克罗哈-哈特曼表示部分驱动程序在该系统上运行异常的可能性极高。
关于核心内核对Rust代码的依赖问题，艾尔利称未来一两年内不会发生。克罗哈-哈特曼坦言曾担忧核心内核与Rust驱动程序的交互问题，但实际情况远比预期更少。他强调，Rust驱动程序的安全性确实远超C语言编写的驱动。托瓦兹指出，已有呼声要求为Rust代码分配CVE编号，这证明该语言绝非实验性工具；克罗哈-哈特曼则表示目前尚未发布相关CVE。
DRM(图形)子系统是Rust语言的早期采用者。然而当Airlie(DRM维护者)透露该子系统“仅需一年左右”便将禁止使用C语言编写新驱动程序并强制采用Rust时，此言仍令人颇感意外。
Ojeda重提最初问题：能否终结“实验性”状态？托瓦兹表示历经近五年发展，时机已然成熟。克罗哈-哈特曼指出编译器开发者日益增长的支持是宣告胜利的有力依据。史蒂夫·罗斯特德询问函数追踪功能是否有效，爱丽丝·瑞尔迅速回应称该功能确实有效，但“符号反解析功能会更理想”。
奥赫达总结道，支持Rust开发的能力成功吸引了新开发者和维护者加入，这正是该项目最初的目标之一。该项目还激发了人们参与文档编写的工作。他表示，许多人希望参与Rust代码的审查工作；他正在组建一支由经验丰富的开发者组成的团队，帮助新成员快速上手。
会议结束时，丹·威廉姆斯表示，他无法想象还有比奥赫达更适合领导此类项目的人选，并向其致以祝贺；全场响起了热烈的掌声。
本文文字及图片出自 The state of the kernel Rust experiment
我一直以为内核层面的决策不会受Debian或任何单一发行版的具体做法影响。
这种情况是否更常见，还是我理解有误？
我认为这可能是因为在所有“主流”发行版中，Debian搭载的Rust版本最为陈旧。
因此这并非内核刻意迎合Debian，而是内核为兼容所有发行版而作出的妥协——Debian因使用最旧版Rust而成为最难满足的对象。
红帽企业版呢？它每3-5年发布一次，比两年一版的Debian更陈旧，而SUSE企业版更新周期更长。
这些商业发行版会发布尖端内核吗？我原以为它们在初始发布后通常只发布补丁版本(含回溯移植)，不会进行重大版本升级，因此理论上无需最新工具链版本。
商业厂商在此无需帮助，若有需求可自行维护。关键任务系统完全依赖Rust内核功能尚需时日。目前可能仅限于CentOS SIG和EPEL SIG的范围。
我认为RHEL在更新构建工具和运行时版本方面规则更宽松(他们将其宣传为“CodeReady Linux Builder”)，但不确定这是否适用于Rust编译器。
RHEL若需要，大可移植最新Rust版本，他们对其他程序也做过类似操作，并非新鲜事
听起来是个明智的选择。几乎所有项目都以Debian(及Ubuntu)为支持目标。
抱歉没提及Rust相关讨论，顺便说一句请别封我号
说实话，这儿根本不需要乞求认可
内核级决策常受Fedora影响，毕竟这是Linus个人使用的发行版。
与C和C不同，Rust没有ANSI C、C99、C11等明确标准。因此内核开发者采用Debian稳定版rustc作为“标准”，来定义Linux Rust代码允许使用的特性。
期待SystemD用Rust完全重写
想想有点疯狂，但C代码终将沦为今日PERL或COBOL般的存在
见证Linux内核如何通过渐进式原地演化适应时代变革与技术进步，着实令人赞叹
情况不会相同，因为此时此刻C语言已实质演变为不同操作系统和语言间沟通的协议。
矛盾的是，这恰恰是C语言无法“被修复”的主因。不妨类比英语：英语拼写体系固然繁琐，但既然已成为世界通用语，如今再大改动便得不偿失——为时已晚。
不过Rust能模拟C的ABI接口，这点值得关注。
没错，而且他们甚至试图用Rust重写libc(颇具讽刺意味)。
这基本印证了我之前评论中提到的“C作为协议”的概念。
看到你的用户名，我突然想到：或许Rust对C++的威胁比对C更大。
我始终将Rust视为C++的替代者，而Zig则试图取代C。
C语言本身无需“修复”。真正的威胁始终来自程序员。
编辑：给那些给我点踩的人：请指出C语言中不源于程序员错误的“缺陷”特性。
任何编译器无明显缺陷的语言都适用此理。看看JS现状：JS语言本身(非生态系统)存在哪些非程序员失误导致的问题？完全可以编写零缺陷的JS代码。C语言的问题在于：尽管它有诸多优点，却缺乏能降低程序员出错概率的特性。
显然他们想表达的是：若要为C语言添加这些特性(如指针借用检查)，必然会破坏现有功能。因此需要创建全新语言——具备复杂强类型系统、借用检查、边界检查等特性。
我理解他们的类比。编程语言虽相互承袭，但Rust或其他语言并非对C的“修正”——它们本质上是截然不同的语言哲学。正如英语无法“修正”德语。
人们有时会试图用C语言做太多事情，比如模拟面向对象编程，或是其他更适合“高级语言”实现的概念。Rust摆脱“实验性”状态并强制新图形驱动使用它，这很棒。或许哪天C语言会被弃用，内核的所有新特性都将用新语言实现。
等等，Perl不再时髦现代了吗？
能否请各位指点迷津：为何Linux开发界如此大力推动用Rust取代C语言？
这是个真诚的疑问，我想理解所有关于“Rust好，C坏”的讨论。
我通读整篇文章试图理解全面替换C语言的优势…却未找到任何实质信息。
看到的全是人们互相吹捧的言论，仿佛在庆祝“Rust正在接管”，更像宗教狂热而非技术文章。
所以再次强调，这是个真诚的问题：实际好处何在？继续使用C语言为何不可取？
据我理解，原因在于Rust编译器和语言机制的设计，它根本不允许那些可能引发漏洞和头疼问题的简单错误存在——而C语言编译时却允许这些错误通过。因此部分维护者认为采用Rust编程更优——尽管初期迁移会引发问题，但长期来看能大幅减少因单行代码错误导致的调试工作。
可参考主题演讲《Rust在Linux内核中的应用：为何选择？》 – Greg Kroah-Hartman — https://www.youtube.com/watch?v=HX0GH-YJbGw&embeds_referring_euri=https%3A%2F%2Fwww.reddit.com%2F&embeds_referring_origin=https%3A%2F%2Fwww.reddit.com& source_ve_path=Mjg2NjY
Rust避免了C代码的诸多缺陷。首先，它在安全代码中保证空间与时间的内存安全。同时它采用强类型系统，这种类型机制便于构建小型状态机，从而更容易验证程序正确性。
感谢简明说明，让我理解更清晰了。视频我会观看。
编辑：看完视频后，大致感觉它类似于C语言，但通过若干机制避免逻辑流程的疏漏(我认为)。挺有意思的。
它并非防止逻辑错误，而是规避内存分配的粗心失误。因此彻底消除了整类漏洞/攻击面。
Rust 虽无法杜绝逻辑错误，但相较于 C 语言，其更强大的类型系统能让你在其中编码不变量，从而预防整类逻辑错误。这正是视频所阐述的核心，也是他们所说的“防止逻辑流程被轻易忽略”的含义。
没错。但正如Greg在演讲中解释的，Rust还能在类型层面以比C更丰富的方式定义API。所以它并非“开箱即用”地预防逻辑错误，而是为库作者提供了防止用户犯逻辑错误的工具。这同样极其宝贵——尤其对内核子系统维护者而言，他们需要审查使用其API的驱动程序。若他们确知“该API绝不会被X、Y、Z方式滥用，因为我就是这么设计的”，维护者就能减少检查驱动程序逻辑错误的时间——这些错误在子系统API的C版本中本会频发。
那些精致的小锁定状态机，终将引发同步领域的巨大灾难。
能否详细说明？
林纳斯本人完全从实用主义角度看待问题，只要代码经过严格审查，他对使用AI毫无异议。Rust产出优质代码，实验成果良好，他的团队认为可与之协作，因此他便推进了。他不使用社交媒体，因此并未关注社交媒体对Rust的评价。
“Rust好，C坏*”这种论调绝对是你过度解读社交媒体了。别把社交媒体的胡说八道当成内核层面的问题。和大多数事情一样，这不过是少数人声音过大造成的现象。
我是Rust开发者。Rust的编译器和内存模型几乎消除了其他低级语言中常见的大量漏洞。例如内存释放后使用或偏移量差错在Rust中几乎不可能发生。该语言确实提供了一个逃生通道(常被误解的
unsafe关键字)，用于处理此类保证会适得其反的场景，例如与硬件寄存器交互的代码；但除此之外，用Rust编写包含内存违规的代码相当困难。该语言的类型系统同样强大，能让你表达强有力的类型契约。在Rust中定义杜绝未定义状态的类型非常常见，由此创建的强接口极难被误用。
该语言的公共API几乎不存在未定义行为，这为你提供了强有力的保证：如果代码能编译通过，那么它很可能“正确”。这里的“正确”指程序能正常运行而不崩溃，并非指逻辑错误完全消除——这仍取决于程序员(参见近期Crowdflare事件)。
我以为Rust完全没有未定义行为，能否举例说明？
目前确实存在一个编译器漏洞，允许某些病态代码编译通过并触发未定义行为。除非刻意为之，否则极少会遇到这种情况。
编译器漏洞不能算作未定义行为。未定义行为是指语言规范明确将某些代码的行为定义为未定义。
讽刺的是，在讨论内核(尤其是驱动程序)时，据我所知存在大量特殊情况：由于需要与硬件交互，必须绕过/禁用某些保护机制(如果我没记错的话)，但具体细节已记不清
因此需区分安全Rust与非安全Rust。安全Rust的设计理念是杜绝未定义行为，无论编写何种安全Rust代码，其本身绝不会引发未定义行为。需注意这不意味着安全Rust代码中的缺陷不会导致依赖该安全代码的非安全代码产生未定义行为——前提是该非安全代码依赖于安全代码无缺陷。
* 当前编译器确实存在至少一个缺陷，允许从安全Rust引发UB，但这是实现层面的缺陷而非语言设计问题，该缺陷及其他相关问题均已修复或将被修复。
另一方面，不安全Rust必然存在UB。这意味着编写不安全Rust代码时必须格外谨慎以避免UB。而与安全Rust的交互接口进一步增加了复杂性。当同时编写安全Rust和非安全Rust代码时，必须确保不违反安全Rust依赖的任何不变性，例如引用机制的限制。
值得注意的是，Rust与C语言对有效性的判定标准存在差异。某些在非安全Rust中100%定义的行为，若在C中执行则会导致未定义行为，反之亦然。一个简单示例是：对于任意类型
T和U，Rust中允许*T与*U建立别名关系，而C语言的TBAA(类型别名)机制会导致此操作成为UB。好的，谢谢，但我仍希望看到Unsafe Rust中UB的具体示例。
指针操作不受检查，可能引发内存释放后使用及越界读写。读取未初始化内存即属于行为未定义。
主要有两大优势：
首先，Rust是唯一无需性能代价即可实现内存安全的系统语言，这意味着彻底消除了某类内存错误。这是众多企业项目中切实可见的优势。
其次，我认为更重要的是它作为现代编程语言获得了新一代开发者的青睐。若新生代程序员不再学习C语言，长期来看Linux的贡献度将下降。采用更现代的语言有助于注入新鲜血液。
编辑：补充了第一点的说明。
第一点有误。多数带垃圾回收机制且禁止直接操作指针的语言(如Java)都具备内存安全性。Rust的核心差异在于它通过规则约束变量使用方式，因此无需运行时垃圾回收(因而更高效)。
他们说的是“系统语言”。任何理智的程序员都不会把Java归入此类。
我不认为Java是系统语言。但已对第一点补充说明。
在JVM中运行的Java相较于相同C代码，性能开销绝对巨大
我清楚，可我绝没建议你去用Java写内核哈哈
明白，只是强调第一点并非无意义——毕竟这是对方的主张。
这是我见过最精辟的解释之一，出自一位在Linux内核中编写大量Rust代码的开发者：
https://vt.social/@lina/113056457969145576
即使你无法理解本说明中所有术语也无妨。关键在于：编写安全的内核代码需要掌握许多在C语言中并不显而易见的知识。Rust具备固有的安全优势——编译器会保证某些类型操作的安全性，同时该语言还提供了更多关于正确使用API的信息。
不妨这样理解：
C语言如同手工制作电子表格——纸笔操作。经验丰富的会计师能胜任，但一旦出错，查找漏洞位置极为棘手，甚至可能需要重做半数工作。
Rust则类似使用LibreOffice Calc或Microsoft Excel等程序制作电子表格。许多操作会自动完成，你还能为电子表格模板添加更多安全机制，防范用户常见错误。
实际应用中，这意味着许多在C语言中能顺利编译、仅在运行时崩溃(甚至引发安全漏洞)的代码，会被Rust在编译阶段直接拒绝。
有人这样形容：C语言中的最佳实践，在Rust中变成了语言强制要求。这大大降低了写出错误代码的概率。编译器能全面检查这些最佳实践是否被遵循，而非强迫开发者自行思考并强制执行。
这种C与Rust的对比实在牵强。Rust更像是带着严苛代码审查员编写C语言，同时拥有进阶版的代码生成器。
你的例子更接近Python——对用户而言它本质上只是在施展魔法。这绝非Rust的本质。
将Rust描绘成简化工具实属不诚实。它并未彻底解决所有内存类问题，Rust代码同样存在诸多引发重大问题的途径，正如C语言那样。请关注近期全球性服务中断事件。
我多次强调过，Rust作为语言存在诸多其他缺陷，使其难以成为C的真正替代品。编写高性能Rust代码比编写高性能C代码更困难——并非不可能，在某些场景下通过大量使用
unsafe甚至能超越C，但此时Rust宣称的优势便荡然无存。我不明白。在电子表格程序里做电子表格怎么能算“简化工具”？这和手工做表格完全一样啊。
这里存在矛盾。你指的是“内存类问题”还是“重大问题”？两者性质截然不同！
Cloudflare故障与Rust旨在防范的内存安全问题类型毫无关联。
两种语言的性能表现绝对不能用如此笼统的结论概括。这完全取决于具体场景分析，而且我认为还需考虑Rust的一个核心目标：让编写正确且高效的代码更容易(即：编写性能正确的Rust代码比编写高效且正确的C代码更难还是更易？)。例如：
iter()替换为par_iter()就能合理确信结果符合预期。在使用足够的
unsafe实现良好性能与过度使用导致其他特性效益递减之间存在巨大鸿沟——事实上，多数代码库根本不会触及后者。例如，那些最可能需要unsafe的低级/高性能代码库，其使用率仍能保持相对较低(据我所知RedoxOS的unsafe使用率≤~10%，Oxide Computing的Hubris内核约为~3%，Asahi Linux的Rust GPU驱动上次查看时约为~1%等)。当然这并非否定此类代码库的存在，但这类案例可能比预期更为罕见。
此处表述一致，含义相同。
Cloudflare事件本质是未处理的无效数据解包，即未捕获的空指针解引用。
性能方面，Rust会强制你进行深拷贝而非引用传递。它还倾向于在逻辑上无需冗余代码的地方增加模板代码。虽然可以重构代码路径规避这些问题，但很快就会变得负担沉重。我绝非在做笼统论断，这里也未详尽列举所有不满之处——性能讨论本就非黑即白。
正如我所言，Rust也有其优点。结构体数据对齐和线程安全是它显著助力的地方——既然你似乎需要我具体表扬某些方面。
那么能否请你进一步解释“内存问题类别”的含义？这与“内存安全问题”是否不同？
我认为这更类似于生产环境中触发的断言/守护语句，但无论如何，这并非Rust承诺防范的内存安全问题类型。
当真如此？我听到的反例更多——Rust的可变xor共享语义恰恰能避免你为防止数据被篡改而做防御性拷贝。
…或许吧？这取决于你的具体考量。
我并非寻求赞美，而是期待更细致的分析！例如，若你说“高效的Rust代码可能比高效的C代码更难编写”，我大概不会多说什么——因为这本就是事实！
最根本的原因很简单：内核开发者们希望如此。推动Rust的正是那些资深且地位稳固的内核开发者，包括Greg KH和Linus Torvalds本人。
支持者们视其为改进内核的利器，尤其能优化他们负责的子系统。
本文未深入探讨原因，因为Rust进入内核已有多年，相关论述早已遍布LWN文章、邮件列表、会议演讲等各类渠道。这个问题的答案早已尘埃落定。
Rust的类型系统基于仿射逻辑，禁止变量重复使用(除非该变量实现了Copy特质)。这种设计能静态杜绝多类内存管理问题，不同于其他内存安全语言依赖垃圾回收和运行时机制。
没错，它确实已成为一种信仰。其次，某些代码中的特定错误已被预防。第三点是吸引新开发者参与内核开发。
实际上林纳斯最初的决策顺序不同——吸引新开发者才是首要目标，他选择Rust纯粹因为当时别无选择。
谈及社区，如今越来越多的人开始厌恶Rust社区(而非语言本身)，只因他们大多不需要这种语言，于是默认将Rust视为糟粕加以抵制。这实则是对Rust狂热教派的反噬——他们四处嚷嚷“你们根本不懂”。更糟的是，由于Rust拥趸滥用各类评分系统，而普通开发者忙于实际工作无暇参与网络争论，这种教派氛围反而被不断放大。
这话说的可好听，Linux内核二把手可是专门做过整场演讲阐述Rust的优越性呢。
那你先看看Linus首次在内核会议提及Rust的演讲就明白了。其实这个决定相当合理。
我无需观看林纳斯的演讲。通过LKML的帖子，我已了解他对该议题的见解。
Rust具备若干核心优势，最常被提及的是增强的内存安全性，但其他特性同样重要。例如强制错误处理机制与无畏重构能力。
Rust无法让差程序员变优秀，但能让差程序员变好些，让优秀程序员更出色。它确保了代码的最低质量标准。
无畏重构还让新开发者更容易贡献代码，也让所有开发者更容易进行重大改动。
这不仅提升代码质量，更大幅减轻维护者的负担。过去有人提交粗制滥造的AI代码时，维护者不得不耗费时间排查——毕竟C语言能编译通过，但运行时会出现各种怪异错误。Rust在编译阶段就拦截了多数问题，这些代码甚至无法通过CI测试，维护者根本无需费心处理。
这简直疯了。
现在正是重温所有关于跨语言复杂性问题的内核讨论的好时机
让内核重要部分用Rust编写，这将是Linux的终结。
呃，为什么？
因为Rust很烂。/s
我看到的Rust长期价值在于让内核开发更易于参与和维护
你论断的依据是什么？
那Linux的继任者会是什么？
Linux 2 又名 Twinux
更妙的是Twinkus 😉
贡献代码需要什么花纹的程序员袜？得跟圣诞老人要一双！
粉紫斑马纹。
你有证据支持这个说法吗？
出自对内核开发毫无影响且毫无佐证的人之手。
为什么？Rust不支持什么重要架构？
你这话什么意思？许多Linux用户需要在30年前的SPARC硬件上运行现代Linux系统。/s
没错。坚持使用C/C++并让老开发者“逐渐消亡”，这样就能拯救Linux内核了。;)
与其支持并转向另一种语言——它不仅具备诸多优势，还拥有新一代开发者作为后盾，且他们乐在其中——不如继续固守现状。
确实处理不当。他们似乎在推动新DRM驱动完全弃用C语言，这实质上是在逼迫所有包含DRM代码的操作系统(FreeBSD、Haiku等)也必须采用Rust，否则将失去对新硬件的图形支持。
因此其他系统面临两难抉择：要么重写GPU代码，要么分叉DRM——这将削弱Linux在微软/谷歌企业生态圈外的价值；要么被迫接纳由科技行业最恶劣行为者(字面意义上的垄断巨头通过恶意手段打压竞争对手)强推的不稳定语言进入代码库。
给那些投反对票的人：你们觉得这段话哪部分不相关？其他操作系统依赖于DRM子系统，若不将谷歌和微软发起并延续的rust-subsystem-for-linux添加到内核中，它们将无法继续使用该子系统。本周我再次意识到这个子版块的用户们其实远不如他们自诩的那般见多识广。
我虽未投反对票，但其他操作系统依赖Linux DRM子系统并非Linux的问题。Linux开发者只关注Linux本身，因此在决策时不会顾及BSD或Haiku系统。
好的谢谢，但我不在乎是否有人反对我，我只是想理清投票数矛盾的原因。这里有人提出“为什么”这类问题竟获得50个赞，说明大家确实想了解为何有人不认同Linux内核开发者这种反C的立场。但与此同时，他们却对唯一敢于用真实信息发声的人投了反对票。
所以我只能告诉自己，这些人大概并不介意Linux开发者从Linux-DRM下游获得更少的免费测试和错误报告，也不在乎除了谷歌安卓设备之外没人使用新驱动，或是(现在到底有多少个了)三个开源NVIDIA驱动中几乎无人问津的某个。要么他们拒绝相信这种排斥C语言的宣言会对更广泛的开源生态系统(Linux主要捐助者间的竞争)产生深远影响，要么他们确实不希望其他项目使用Linux代码，从而有效削弱Linux在生锈的泡沫之外的意义。
简而言之：若仍有读者困惑，请明白——在Linux内核中禁止新增C语言驱动程序的规则，要么是疯了，要么是蓄意敌对。这两种可能性都将摧毁长期互利共生的开源联盟。
BSD和Haiku用户基数太小，对Linux DRM子系统毫无影响。Linux开发者无需关心自身生态圈外的相关性——毕竟这个生态圈已囊括几乎所有开源操作系统的市场份额。这好比说禁止某些游戏在Proton上运行会损害Windows玩家利益——因为开发者无法获得Linux玩家反馈。没错，他们确实无法获得反馈，但当近100%玩家都使用Windows时，这根本无关紧要。
这些说法都成立，但与Linux毫无关联。Linux开发者既非Haiku或BSD开发者，也无需为代码便于移植到其他内核而束手束脚。解决问题是他们的责任。
为何Linux开发者要为便于移植到非自主开发的操作系统而束手束脚？
这些论点毫无意义。你自以为见多识广实则不然。这和Phoronix论坛那些自以为是却知之甚少的发帖者如出一辙。
Rust对操作系统开发、Linux乃至整个计算机科学都是净收益。去草地里滚滚吧。
但你的评论和楼主如出一辙。“我对你错”。拜托大家好好阐述观点行不行？
这纯属阴谋论胡扯！全是无稽之谈。看来你根本不懂行。首先，智能电视运行的是Linux系统…就像其他需要解码DRM媒体的设备一样，若想实现普及就必须支持它。你不能指望它消失。如果没人维护Windows，人们就会继续用它。Rust语言很优秀，真不明白它为何饱受争议。
这里说的DRM指的是Direct Rendering Manager(Linux GPU子系统)，不是数字版权管理。
从他的评论来看，哈哈