Debian强制要求APT采用Rust语言，重塑Ubuntu及其他Linux发行版
无论你是否愿意，若为Debian开发软件，都必须开始使用Rust语言。
无论你是否愿意，若为Debian开发软件，都必须开始使用Rust语言。
作为全球历史最悠久且最具影响力的Linux发行版之一Debian， Debian正式宣布将采用Rust作为系统级工具及未来软件包的核心语言，以此重构其开发战略。
长期担任Debian开发者及高级软件包工具(APT)首席维护者的Julian Andres Klode在Debian开发者邮件列表中宣布： Rust将成为Debian核心APT包管理器的强制依赖项。
克洛德特别说明计划“在2026年5月之后引入APT的硬性Rust依赖关系及Rust代码，初期将涵盖Rust编译器、标准库及红杉生态系统”。
红杉项目是Debian旗下致力于用Rust实现OpenPGP的项目。
为何选择Rust？Klode解释道：“解析.deb、.ar、.tar文件及HTTP签名验证的代码，将极大受益于内存安全的语言特性和更强大的单元测试机制。”
对 Ubuntu、Mint 及其他 Debian 衍生发行版的影响
APT 是 Debian 的核心组件。所有基于 Debian 的 Linux 发行版(如 Ubuntu、 Mint和MX Linux，均依赖APT进行软件包管理。这意味着Rust代码将进入所有这些发行版。部分发行版架构师对此表示完全支持。例如Canonical公司已将Rust整合至Ubuntu sudo系统。
这些举措的根本目的是提升操作系统的安全性和稳定性。Rust的内存安全架构能有效杜绝缓冲区溢出、空指针解引用和竞争条件等常见缺陷——这些问题困扰C/C++代码库已长达数十年。
决策依据：强化安全与稳定性
若您不认同？很遗憾。Klonde补充道：“若您维护的移植版本尚未配备可用的Rust工具链，请确保在未来六个月内完成部署，否则该移植版本将被淘汰。”
哎哟。
部分开发者对此表示不满。约翰·保罗·阿德里安·格劳比茨对[选择“如此对抗性的方式”发布APT公告感到失望。
与此同时，比约恩·莫克质疑将APT迁移至Rust能否真正有效。“重写代码必然引入新漏洞，”他指出，“即便工具能捕获部分问题。” 但假设重写后的软件最终能减少严重缺陷——这需要耗费多少时间？……难道要我们暂时接受功能退化，只因Rust重构版终将追平现有版本？”
开发者社区的反应与担忧
在Debian开发者邮件列表的后续讨论中，Klonde不以为然地表示：“Rust已是多数Debian移植版本的硬性要求，这毫不意外。”
他还指出，目前仅有四种旧架构——alpha、hppa、m68k和sh4——尚未跟上Rust的步伐。若这些平台的开发者无法提供Rust支持，正如ebee_matteo在《Linux周刊新闻》(LWN)中所言： “这再次表明这些架构缺乏足够开发者来支撑跨平台兼容性的持续投入。……这甚至不是Rust与非Rust的争论，而是’该移植版本是否拥有足够的开发者和用户群体？’”
展望未来，Debian下个重大版本Forky(即Debian 14)计划于2026年中发布。该版本不仅将在APT中深化Rust集成，还可能将其应用于其他核心工具、构建基础设施及安全关键模块。
至于那些无法或不愿采用Rust的Debian发行版，它们始终可以效仿基于Debian的Linux发行版antiX——该项目持续基于旧版Debian(如Debian 12 “Bookworm”)构建，以支持32位硬件。
大多数开发者终将效仿Klode拥抱Rust。说真的，这门语言并不难学，它确实能轻松编写内存安全的代码。作为曾经为C代码头疼不已、屡次尝试却屡屡失败地试图让程序实现内存安全的人，我个人非常欢迎Linux及其发行版如今正将Rust纳入体系的做法。
哪些架构会被淘汰？
所有有活跃维护者的架构都不会被淘汰。
Rust工具链支持所有有活跃维护者的Debian架构。
好问题。根据公告中的这段说明：
若您维护的端口尚未配备可用的Rust工具链，请确保在未来6个月内完成配置，否则该端口将被淘汰。
面临淘汰风险的架构是那些在2026年5月前仍未配备可用的Rust工具链的架构。由于当前所有发布架构均已配备可用工具链，此举最多只会影响非发布架构，更具体地说，是当前在该页面标注为“BD-Uninstallable”的架构：
https://buildd.debian.org/status/package.php?p=rustc
这些架构对应的源代码包“rustc”无法成功编译。
这并非Debian淘汰架构的常规流程。
能否详细说明具体机制？因为
这段表述几乎排除了除淘汰四种无可用Rust工具链架构外的其他解释空间。
与楼主所述并无矛盾。
最终目标是什么？
这将导致 GNU/Linux 不再适用于嵌入式/小型系统，仅支持 x86/ARM 架构，并终结对 68k、SuperH 等架构长达 20 多年的支持。
没错，LLVM支持其他平台，但其代码生成质量往往糟糕透顶——MIPS、POWER等架构就是典型例子。除Itanium和TileGX这类小众ABI外，GCC才是开源编译器的终极选择。
关键是你开篇提到的那位在Canonical工作。说实话，他们根本不在乎这些平台。
当然啦，他这分明是在说“祝你们这些混蛋好运”
我在Mastodon上和他聊过，其实感觉是个挺靠谱的人。
有位关注者指责我“为了支持这些平台而让维护者痛苦不堪”，Klode回应道： “希望你能友善些，没必要对一个因爱好日益艰难而沮丧的人发这么大的火。他本质上是在哀悼，落井下石可不酷。”
所以没错，他明白自己在增加你的困难并表示同情。这根本算不上“祝你们这些混蛋好运”。
他的语气里连一丝同情都谈不上，我质疑他的动机。他指责我在给他添麻烦，那他为何还要继续当维护者？
根据你的描述，我几乎觉得他在博取同情。
虽然这不直接影响我，但他的语气确实缺乏同理心。我之所以感到愤怒并撰文记录今年的情况，是因为我厌恶Rust语言，更厌恶它在我们基础设施中的蔓延。十年前它就已证明是个问题，虽然未必会消失，但我仍会尽我所能提高人们的认识。
我们正以惊人速度奔向一个未来——数百万完好机器将被锁定在电子垃圾的命运中。你或许不知，这些废弃物大多被运往非洲和东南亚焚烧，导致癌症蔓延。我多么希望这并非事实，但亲眼目睹过海南岛的电子垃圾焚烧厂。焚烧日当天，人们被要求用纸口罩捂住口鼻…这有什么用呢。
LLVM同样是问题根源之一。其糟糕的代码生成机制正将我们推向与多种架构的冲突轨道，尤其考虑到GCC的Rust编译器可能永远无法与rustc持平。而Rust社区热衷于拥抱实验性功能的做法，更令人难以信服。
我几乎觉得Rust体系正违背开源软件的历史发展之道，这令人不安。许多系统的可访问性正在消亡，作为nekoware维护者——它本就需应对GCC的ABI问题——如今还要面对该死的LLVM(我大概永远无法在IRIX上运行它)，这简直是雪上加霜。难道不久的将来Perl也要强制使用Rust了吗？短期内或许还能靠旧版本凑合，但终将被时代洪流吞没——当大量软件强制要求新版Perl时，即便系统完全支持运行，整套软件生态也将彻底崩塌。这正是Rust的运作模式，而我对此坚决反对。
Debian/Apt ≠ GNU Linux。
你以为事情会就此止步？
我的意思是这两者完全不同，而决定是否就此止步的又是完全不同的群体。嵌入式和利基架构社区最终将决定他们的发展方向。见鬼，你完全可以分叉代码推出自己的版本。
说了这么多话，却没回答一个简单的“是”或“否”。
你以为它会止步于apt？才不会呢。他们总会找到其他借口，转眼间Linux内核半数代码就会用Rust编写。到那时它或许依然存在且流行，但许多人早已离去。而托瓦兹始终坚定支持Rust的加入，这简直滑稽可笑。用不了多久，你们就得给Linux内核加装货运系统了，那场面简直荒诞至极。
到那时我早就消失无踪了。
我的答案是：无所谓。人们总会创造他们需要的东西
你就是个不诚实的混蛋。连个简单的是非题都答不出实话。
Rust在嵌入式系统上表现良好。
GCC早已支持Rust编译。
纯属胡扯，你连自己贴的链接都没看懂。
请别散播虚假信息。
SuperH，68k。管他呢，滚蛋。
说实话，如果J-Core真心要搞SuperH，花点时间做个LLVM后端就行。至少RISC-V这方面做得挺好。
部分代码库正逐步从C语言迁移至Rust。这能减轻内存安全方面的困扰，且工具链成熟现代化，编译器实际使用体验相当不错。
网上技术讨论区的那些书呆子们，又在寻求他们惯常的戏剧性冲突了。
Rust开发者总在“解决”不存在的问题，反而制造新麻烦…
此前核心工具集替换还搞砸了自动更新——因为date(1)处于实验阶段尚未准备就绪
我超爱他们搞砸
date的方式这简直是pulseaudio事件重演…至少这次不会让我遭受声学冲击和听力损伤。
啥？大声点！
你根本读不完每年报告的漏洞数量——这些漏洞本可通过内存安全语言避免。这里解决的问题非常现实。
问题在于你无法控制他人使用什么，而Rust绝非所有场景的最佳解决方案。遗憾的是，许多人存在“Rust至高无上”的妄想。
我99%的工作场景都无法使用Rust。根本行不通。因为我常为特定架构开发，即便像奴隶般拼命让LLVM运行，生成的代码也糟糕透顶——还不如把代码喂给ChatGPT让它猜汇编代码。
更何况，面对存在三十余年的基础设施，突然要求人们“跟上时代步伐”的做法既不专业又卑劣。
我并不反对Rust的存在，但绝不允许它取代我的基础设施。为此，我将持续对Rust信徒们进行猛烈抨击。
我不明白，所以如果apt开发者选择其他内存安全的语言，且工具链不被你的项目支持，你不会生气——仅仅因为那是Rust？
至少我会更宽容些。嘿，Yum基于Python。我虽不喜欢Python，但至少能在大多数环境构建Python版本，而Yum版本并不完全依赖于RPM兼容性。
我主要的问题在于Rust莫名其妙地与LLVM捆绑。我反对Rust的普及，因为它不断证明这种语言正在扼杀优秀架构和优秀系统接触现代世界的机会。LLVM并不适用于所有架构，而要为所有架构永久构建高质量的LLVM所需的技术实力和工程投入根本不存在——尤其当它必须依赖企业赞助时。
GCC历史上无需此类支持，虽非完美编译器，但在MIPS或Alpha等架构上却毫无悬念地胜出。
Rust开发者？这位 Debian维护者 正向你阐述他正在解决的切实问题：
特别是，我们用于解析.deb、.ar、.tar文件以及HTTP签名验证的代码，若采用内存安全语言并加强单元测试机制，将获得显著提升。
内存安全根本是狗屁借口。比如OpenBSD运行了几十年，安装库漏洞少得可怜甚至根本没有。说什么需要借用检查器，还得搭配Rust那套愚蠢机制，简直蠢到家了。
那个老是来捣乱的蠢货，我懒得理他。
Rust很酷，但它的用户有点像邪教信徒。简直像Java初期的翻版。他们连训练轮都没卸就敢编程，可最让我烦的是他们硬要别人也这么干。当代码库不是一堆垃圾时，写内存安全代码他妈的简单得很。
教派？他们让山达基信徒都显得正常了。
Rust的核心特性借用检查器，本质是编译器强迫开发者做额外工作(这在C/C++里本该是良好实践)。自动化和进步居然让我工作量增加，真是太棒了！
编辑：我说的没错。C虽非完美语言，但Go确实具备我想要的特性，而且不会毫无理由地随意重命名C中的类型。
被迫显式编写
unsafe代码块却无从规避的次数多到让我头疼。将C与Rust链接简直是场噩梦。OpenBSD“缺乏”漏洞更多是因为用户基数不足以暴露问题或产生足够报告。
这些功能完全可用C++实现，无需引入全新工具链。如提案所言，在系统级场景中审慎使用C++和Rust可提供等效功能。Rust固然精妙，但若为提升系统开发体验，C++已绰绰有余。
标题能否别带个人观点？
自从Debian允许注册性犯罪者在DebConf演讲且至今仍庇护他，我就不再关心这个项目了。去研究杰里米·比查吧，这家伙很有意思。
那你用什么替代方案？
目前必要时用Rocky Linux，但我的系统群是NetBSD、Rocky、部分老旧FreeBSD和Solaris的混合体。
既然必要时用Rocky，那非必要时用什么？还是说只是对Linux的轻微嘲讽？哈哈。可惜除了防火墙之外，我对BSD的专业经验实在有限。这些工具确实很棒。
NetBSD、Solaris，还有我挚爱的IRIX
这不就是某个维护者越权行事吗？真心希望社区能妥善处理此事。
(对我而言这无关Rust，而是关乎个人私心。)
正是如此。原帖作者正借此在讨论中散布大量虚假信息，并煽动对Rust的敌意。
简直是小题大做。不过考虑到楼主向来讨厌Linux的立场，倒也不足为奇。
哇，你可不是在开玩笑。
任他妄为。滚蛋吧
[已删除]
或许吧，但他的居高临下态度让我反感。就像那些在项目里非要用最新C++标准的白痴，那种“我比你懂，事情就该这么办”的傲慢姿态。
科技圈普遍的精英主义，正是我如今干体力活的原因之一
这又是一个强推Rust的典型案例——满口空谈安全性却拿不出具体漏洞实例。重写确实有时必要，但必须有充分理由。重写耗费大量资源，而开源社区资源本就有限，往往导致功能被砍。
顺便提一句，几十年前就有内存安全的语言了。Ada和Modula 2就是例子。
那为什么它们没能像这样普及？
原因不胜枚举。Ada在国防部广受欢迎，被视为军事应用的通用语言。但GNAT/GCC的构建难度较大，尤其需要交叉编译时。不过相较于将LLVM移植到所有现有架构并确保其代码生成质量不逊于GCC，我认为这算不上什么障碍。
Modula-2曾长期受DEC专利限制。
Rust支持者还会辩称这两种语言均未采用借用检查机制，因此不够完善；对此我的反驳是：借用检查绝非唯一解决方案。存储池机制早在80年代就已存在。
说实话，这些理由都站不住脚。你真以为LLVM移植到其他架构纯粹是为了支持Rust之类的东西？这本来就是必然趋势，你根本不用为此付出代价，所以这根本算不上反对理由。Ada编译器“难以构建”的说法毫无意义——毕竟99%的程序员都在使用现成包。GNU Modula 2自2010年就已存在，其免费时间甚至比Rust的实用期还要长。
再深入想想。Rust能取得这两者未曾企及的成就，必定存在实质原因。
绝非如此。编译器多样性固然可贵，但除企业赞助平台外，LLVM的表现从未令我惊艳——比如任何非x86、ARM或POWER架构。
代码生成至关重要。而开源编译器在此方面向来表现欠佳。GCC在安腾架构上糟糕透顶，Open64也好不到哪里去。LLVM则从未支持过该架构。若编译器生成的代码无法与同类产品竞争，那它几乎毫无价值。
新颖性确实是关键因素——这正是Rust的核心卖点。此外，这里投入了巨额企业资金。原因之一或许在于Rust具有反编译特性。
“哇，这很新颖”的因素确实存在，这正是Rust的核心卖点。此外还有大量企业赞助资金投入其中。另一个原因可能是Rust反GPL…我可不是开玩笑。你可以查查为何GPL在Rust项目中不受欢迎，这是真实存在的现象。
好吧。如果你觉得代码生成太糟糕(我对此存疑)，大可自由使用或编写替代Rust编译器——语言本身并非问题根源，或者直接改进现有项目。甚至可以维护一个不使用Rust的apt分支。这不正是自由软件的精髓吗？
每种语言都有“哇，新奇”的阶段。这是时间流向的必然。但这无法解释人们为何因新奇而采用它，却又持续在实际项目中使用它。
GPL协议流失并非全因邪恶大企业。相比普遍自由，版权左派机制确实更难操作。
你混淆了不同问题。我原则上也不喜欢这门语言，更因其社区精神失常。
至于代码生成，确实糟糕透顶。能运行吗？能。但在缺乏企业赞助的编译器目标平台上，性能完全依赖中间表示层。但后端优化不可或缺——不同架构的寄存器分配机制各异，性能瓶颈并非架构通用概念。
若你不信，那也无妨。唯一验证方式就是尝试在非x86或ARM架构上实现这些功能。可使用spec等客观测试套件，因为编译器对特定测试的影响极为显著。
LLVM的情况并非如此。要合并大量补丁——尤其是那些可能深入改变架构底层的补丁(这类项目往往需要此类改动)——你可能需要企业赞助。而我只是个懂编程的蓝领工人，获得这种资源的可能性微乎其微。
我无需这样做，因为我不使用Debian。无论是否影响到我，我都有权表达观点——这并非滑坡谬误，因为我们已经目睹这种现象发生，且明显趋势正在形成。
即便我想这么做，也缺乏专业能力。我必须移除软件包签名代码，因为目前根本无力审核此类代码。
它极其年轻，且背后有企业赞助支持。以编程语言发展周期衡量，它仍处于蹒跚学步阶段。十年常规使用根本不算什么——例如Algol语言至今已有六十余年历史。
实际上这正是主要原因之一。我绝非GPL拥护者，但连我都注意到某种规律： 追踪资金流向。若将开源项目纳入专有软件更便捷，这正是LLVM选择Apache许可证而非BSD许可证的原因：此举能与企业利益达成兼容。
哇，开发这种规模的软件居然需要这么多资源，简直疯了。
整篇帖子就因为某个你不用的发行版想用你“原则上”不喜欢的编程语言？老兄，我觉得这次发疯的不是Rust社区。
没错，但这半个世纪我们对编程语言的认知已有了长足进步。更何况即便当时它真是完美语言(其实并非如此)，如今我们面临的问题规模、软件开发实践都已发生翻天覆地的变化。
数十年来，Ada语言就具备多数语言(包括Rust)所缺乏的安全特性。但直到最近，它才拥有类似借用检查器的功能——正是这种机制让Rust能在保持C语言式内存管理的同时，有效防范内存安全问题。
借用检查器并非绝对必要，尤其当采用其他内存管理方式时。C式的内存管理系统既非万能之选，亦非唯一途径。Ada提供了若干替代方案。
我认为脱离C语言的核心动因在于类型安全与编译器检查机制。但认为Rust在所有场景下都是完美选择的观点荒谬至极，总体而言我持反Rust立场。我随时会选择C语言而非Rust，尤其考虑到Rust与LLVM的绑定关系。
正因如此我才特别强调“在保持C语言式内存管理的前提下”。我清楚存在无需借用检查器就能证明内存安全的方法，但这些方法比使用借用检查器更具限制性，且可能影响性能。
借用检查器是确保内存安全的同时保留常规编程范式的一种相对简洁的方式。你或许更倾向其他机制，但若非其具备独特价值，Ada语言也不会将其纳入实现。
Ada并非“跟风”采用Rust机制；数十年来它始终通过强类型、范围检查、受控类型及形式化验证实现内存安全。Ada 2022的所有权模型并非Rust式的借用检查器，而是符合Ada静态验证目标的轻量级可分析机制。Rust的模型虽具创新性，却存在限制性强且难以形式化推理的缺陷，而Ada的方法始终保持着明确性、可认证性和可预测性…这些特性在Ada的目标应用领域更为重要。
这并不意味着Rust的借用检查器是设计的巅峰。它只是实现内存安全的多种方案之一，各有取舍。其优雅程度未必胜过GC或范围所有权机制(D语言、Ocaml、Java)。
我确信针对煽动性误导标题的讽刺回应，定能助长原帖作者的轻蔑态度。
该死，这么多年过去我居然还得安装Gentoo。不过好在终于能摆脱systemd了
像个真男人，装个BSD系统吧
这段话是在FreeBSD上写的，我的局域网全是OpenBSD，这样算不算？:) 这就是我回归Gentoo满足Linux需求的原因。自从Daniel离开后我就没用过它，确实很久没碰了。
我压根没来这儿争论Rust的优劣，但这种态度让我对项目相对保守的历史感到恶心。
所谓“不会强加于人”的承诺，不过如此。
总的来说，我对Rust社区日益反感，他们执意推行“拥抱、扩展、消灭”的策略。
你真明白这是什么意思吗？
随他去吧，他正兴致勃勃…
m68k有支持，详见：https://doc.rust-lang.org/beta/rustc/platform-support/m68k-unknown-linux-gnu.html
那么剩下哪些架构？最后一款DEC Alpha处理器发布于1998年？HPPA属于PA-RISC架构。SH-4或许最值得关注，因为它应用于1999年发售的世嘉Dreamcast主机。
所以——即便不是Rust语言，也会有其他替代方案。
我理解大家对复古计算的热爱，但树莓派的性能已远超这些平台。我们该适时放弃这些支持，还是需要自行维护？各位会支持哪些平台？
我作为唯一维护者支持整个操作系统软件包发行版(nekoware)，其中90%的软件包甚至不用GCC编译器。
所以你觉得Debian就该为你支持SH-4和Alpha架构？
如果你是维护者，应该明白这个机制。维护者有权选择维护对象。谁能有无限时间去支持天下所有事物？
实际存在LLVM/rustc移植版本，并不代表它实用。LLVM在许多架构上的代码生成效果糟糕透顶。
不仅如此，这本质上是为了一己之私——为了内存安全，竟要舍弃三十余年积累的成熟工具链。
我并非Debian用户。主要使用Rocky系统，但深切关注Rust如何彻底破坏了长期积累的工具生态。客观而言它并未带来实质改进。若Debian执意要丧失更多用户信任，随它去吧。
那又如何？相关 Debian 维护者这么做的主要原因，是为了那些你永远无需处理、但他必须应对的后台进程？
你管得着吗？
重申：此人并非无名之辈，而是Debian维护者为简化自身工作所做的选择。
所以——你完全没有利害关系？
据我所知Rocky也不支持SH-4等架构。你开始明白维护者的工作原理了吗？
Debian维护者想用基于Rust的东西。他们到底在搞砸什么？对早已淘汰架构的支持吗？
你纯粹是为争论而争论。我有权发表意见，而你只想因为我“没有利益相关”就对我抱怨。
我多次表明过不喜欢Rust。若不喜欢我相关帖子，请点击我的个人资料并屏蔽。因为我不欣赏那些因认为我无权发表意见就对我抱怨的人
你可以发表牢骚满腹的意见？但当有人指出你情绪化又荒谬的观点时，可别哭哭啼啼地抱怨啊？
[已删除]
这是开发者自主选择用于个人项目的决定。??
所以你宁可选择更糟糕的发行版也要标新立异？那就享受折磨吧，反正你也不打算彻底离开Linux。
[已删除]
他们曾说“我们不会替换你的工具”
现在却食言了。太可笑了，十年前我就预言过。
我并不讨厌Rust这门语言。但在以稳定兼容著称的主流Linux发行版强制推行Rust工具链，简直是疯了。
就像我以前有个老板，硬要跟我争辩用CW-14切割轮加工Schlage钥匙是错误的…明明设备制造商HPC在文档里明确规定，CW90只能用于Falcon等型号，结果他搞坏半数钥匙还纳闷为什么。这种态度可能让我丢了饭碗，但我宁可丢饭碗也不愿纵容无能。
还有基于RPM的发行版根本不在乎这些。
我知道，我长期使用这类系统。但若以为这意味着长期安全，那就大错特错了。
更甚者，基于pacman的发行版同样漠不关心。将核心工具重写为强制要求Rust工具链的做法，简直像某种“拥抱、扩展、消灭”策略。