用Rust重写的 coreutils 漏洞导致Ubuntu 25.10自动更新功能失效

部分 Ubuntu 25.10 系统无法自动检查可用软件更新。受影响的机器包括云部署环境、容器镜像、Ubuntu 桌面版及 Ubuntu 服务器版安装环境。
💬 289 条评论 | //|
linux-backdoor 后门 安全漏洞

Ubuntu项目已宣布，Ubuntu 25.10随附的基于Rust语言的uutils版本date命令存在漏洞，导致自动更新功能失效：

部分 Ubuntu 25.10 系统无法自动检查可用软件更新。受影响的机器包括云部署环境、容器镜像、Ubuntu 桌面版及 Ubuntu 服务器版安装环境。

公告中提供了受该漏洞影响用户的修复指南。安装rust-coreutils包版本0.2.2-0ubuntu2及更早版本的系统存在该漏洞，该问题已在0.2.2-0ubuntu2.1及更高版本中修复。使用apt命令或其他工具进行的手动更新不受影响。

Ubuntu为推进发行版“氧化化”计划，在25.10版本中启用了uutils和sudo-rs，旨在验证基于Rust的工具是否适用于明年四月发布的长期支持版本。LWN于三月对此项目进行了报道。

元素周期表抱枕

共有{289}条精彩评论

  1. 若说有什么，整个项目恰恰暴露了软件界测试工作何其匮乏，简直可悲

    这并非Rust独有问题，而是我们行业普遍存在的顽疾

    回复

    1. Uutils的coreutils实际上采用了GNU coreutils测试套件。从其Github可见，这些年测试通过率呈线性稳步提升，预计两年内就能通过所有GNU coreutils测试。

      但这对Ubuntu来说太迟了——他们计划在26.04版本中采用Uutils coreutils，而该版本已是下一个LTS版本。

      回复

      2. 等等，这听起来很熟悉。是音频相关的某个东西。

        回复

        1. Ubuntu 进行过大量实验。PulseAudio 确实一度成为主流标准，直到最近才被 Pipewire 取代。

          他们还尝试过用upstart替代启动脚本，用Mir替代X窗口系统；而最终取代它们的分别是systemd和Wayland。

          由此看来，这其实对Uutils是个好兆头——说明当Ubuntu不固执己见时，他们确实有能力选中赢家。(只是行动太早惹恼了所有人。)

          回复

    2. 确实这是核心问题。测试环节存在明显缺口，而该方案却在未经充分测试的情况下被推向如此重要的应用场景。

      大型Rust重构项目也有成功案例，比如fish-shell，但关键差异在于他们拥有庞大的测试平台，能够逐步验证每个步骤。

      构建全面的测试套件需要巨大投入，而编写维护这类工作通常“毫无乐趣”。因此开源项目往往缺乏完善测试。老实说我不确定现状如何改变，但本以为Ubuntu会强制要求。

      回复

      1. 这种情况下你的优势在于已有参考实现，可通过模糊测试确保各实现行为一致。这样就不必手动创建庞大的测试套件了

        回复

        1. 有意思，之前从未这么想过。看来我在这方面还不够成熟。

          回复

        2. 简单，直接让chapgpt帮你写测试就行。

          开玩笑的。(基本是)

          回复

          1. 我公司同事最爱写完代码就让AI代写单元测试。我一直在耐心解释：除非他们完全理解测试逻辑，否则AI只会把错误代码转换成形式稍异但依然错误的版本。

            管他呢，100%覆盖率才是王道！！！

            回复

            1. 在多数编程场景中，追求100%覆盖率可能是最愚蠢的指标。极少数模块需要这种覆盖率。

              若代码涉及业务关键环节，更应仔细审查AI生成的测试用例。

              回复

            3. 管他呢，100%覆盖率！！！

              只要代码存在缺口，就能轻松达到100%代码覆盖率…

              回复

            4. 对于简短/简单的测试用例，若你清楚测试功能且验证速度快于手动编写，这才是大型语言模型为数不多的合理应用场景。

              其响应可被验证——只需阅读代码或手动运行即可。正因如此，它仅适用于简短/简单的测试用例。

              结果非真即假，不存在影响响应的灰色地带。

              它无需高度优化或符合你的编程风格偏好。

              它不会被赋予关键决策权。你会在亲自决策前先验证其响应。

              即便如此，亲自编写测试用例仍更可取——既能保持技术熟练度，又可避免过度依赖AI而陷入盲目自信的陷阱。

              回复

      2. 你在说Ubuntu的测试吗？自动更新功能显然是至关重要的核心特性，理应重点测试。

        测试中永远存在“明显漏洞”。非穷举测试无法证明程序正常运行，只能揭示其缺陷。

        反之，穷举测试(即100%路径覆盖)又难以实现。uutils的tests目录包含20万行Rust代码，而实际代码仅10万行。

        回复

      3. 没有这些测试。

        不不，Uutils使用的是GNU测试套件，且明确声明尚未通过全部测试。甚至按 coreutils组件细分了测试结果。

        Ubuntu仍知情地将其纳入25.10版本，很可能是为了在下次LTS发布前，至少用一个常规版本进行烟雾测试/测试驱动。

        如果他们过去几年的进展能持续下去，我估计大约两年就能达到平价水平，参考他们README中的图表。测试套件的最后部分可能难度更高；也可能由于进入Ubuntu 25.10版本带来的曝光度提升，各方会投入更多精力确保通过测试。我无法确定。

        但他们确实 在 进行测试。

        回复

        1. 换言之，我将把此文作为证据提交给Linux运维团队，证明我们应加速清除环境中所有Canonical组件——这不过是他们又一次脑残的改动。

          回复

          1. 我怀疑你们的管理团队不会如此情绪化。

            若他们像我共事过的Linux管理员那样行事，我预计他们会坚持使用LTS版本，即便如此也不会安装刚发布的LTS版本。这个漏洞是在版本命名当月就被发现并修复的。

            我们多数人都会等到.1版本或同等版本发布后才进行升级。

            (Canonical除外，毕竟Uutils至今连1.0版本都没发布过，笑。)

            回复

            1. 我特意说“加速清理”是有原因的。我们正逐步迁移到Rocky Linux，而Canonical对 coreutils发布未经测试的变更，无异于再钉上一颗棺材钉。

              回复

            2. 我们正逐步转向Rocky Linux，而Canonical对 coreutils发布未经测试的变更无异于雪上加霜。

              这些变更并非未经测试；它们经历了与GNU coreutils完全相同的测试场景。若不想当实验品，就别用实验版——道理就是这么简单。

              回复

            3. 单元测试不等于系统测试。这次变更未经系统测试。单次系统测试本可发现问题。

              因此Canonical确实未进行系统测试。

              回复

            4. 世上不存在系统覆盖率达100%的操作系统。

              回复

            5. 但最基础的操作系统功能集成测试本应能发现此问题。

              回复

            6. 啊，明白了。虽然我不确定自己是否会登录Ubuntu 26.04机器，但我们团队正转向Flatcar和Talos这类发行版(即更侧重Kubernetes/Linux而非GNU/Linux)。

              回复

            7. 我们有大量供应商提供的软件，他们仅支持Rocky、Red Hat、Ubuntu或SUSE系统。因此可选运行环境受限。此外，除网格计算环境外我们基本不使用容器——出于多重原因，该场景下我们采用Singularity/Apptainer方案。

              回复

      4. 有时会出现软件(无论有意无意)依赖旧版软件非预期行为的情况，此时自动化测试便力有未逮。因此它永远无法完全替代在尽可能多的真实场景中进行实际测试。但我们程序员秉持“一切皆可自动化”的思维定式——毕竟这是我们的本职工作——这种现实确实令人难以接受。

        回复

        1. 我正在开发一款测试工具，它能捕获所有生产环境流量，通过预发布环境进行回放/模拟并对比结果，从而在真实客户场景中检测退化问题，或验证预期改进效果。

          回复

            1. 这套测试架构相当基础。多数交易公司都设有实验室环境，与生产环境并行运行，用于对旧版与新版软硬件进行A/B测试。

              回复

      5. 另一个陷阱在于：当测试达到某个临界点后，即使是优质改进也会被严重拖累，因为没人愿意更新测试环境来匹配新版本。

        回复

        1. 没错，《SRE手册》也警示过过度追求高可用性的风险。设定容错预算和缺陷分级机制才是良策。

          这种情况似乎不会获得CVE编号，但会让热衷于运行最新版Ubuntu并使用自动升级的用户感到困扰。

          回复

      6. 但我本以为Ubuntu会强制要求安装。

        若你明知在LTS版上使用不稳定的最新版本，却抱怨其…不稳定，那你实在不够认真。uutils随.10版发布的初衷正是为了在LTS版发布前捕获这些实际环境中的漏洞。若你稍作研究看过README文件，就会发现uutils还拥有“庞大”的测试平台。

        天啊我讨厌这个网站

        回复

        1. Ubuntu所有版本都是稳定的。非LTS版本并不等于不稳定。

          回复

        2. Ubuntu的版本并不不稳定。LTS版本是为偏好运行旧版软件的用户设计的，但任何版本都适用于所有追求稳定软件的用户。这并非Nightly版本的缺陷：他们发布了Ubuntu更新却未测试其自动更新功能。这充分揭示了Ubuntu的测试实践存在问题。

          此外，uutils测试套件虽优秀，却再次印证其不应纳入正式操作系统。开发者明确声明该套件大量测试未通过，且显然未选择1.0版本。Ubuntu竟在最新版本中将整个系统工具切换至明确声明“尚未准备好发布”的软件包，实属荒谬之举。

          回复

      7. 更何况在如此关键的用例场景中强行推进，却未进行充分测试

        没错，但你可曾考虑过这是用Rust重写的版本？

        回复

      8. 这简直“无趣至极”

        不是“unfun”而是“unfun”。

        回复

    3. 我经理刚提议降低单元测试覆盖率以加快代码提交速度。我不得不向他解释单元测试的价值。他担任软件工程师十年才晋升管理这个团队。

      回复

      1. 我的意思是，100%单元测试确实有点像愚人金，容易带来虚假的安全感。关键在于测试的编写方式——函数级测试远比那些BDD垃圾有效得多。

        回复

        1. 我们不追求100%。正因如此我才觉得没道理。100%覆盖率要求太高了。我认为80%左右才是最佳平衡点——既能促使开发者(希望如此)更深入理解组件实际功能，又能捕捉到至少部分回归问题。

          回复

        2. 覆盖率是100%毫无意义的指标，因为它与执行路径覆盖率毫无关联。

          它还会导致浪费时间测试低价值功能，而这些时间本可用于为高价值功能增加更多测试。

          每月运行的后台报告不应获得与登录页面同等的测试投入。

          资源并非无限，切勿浪费。

          回复

          1. 没错，测试覆盖率的荒谬之处在于：若某行代码调用第三方库的方法，假设该方法有10个参数，即使仅设置其中一个参数而其余为空值，该行仍会被视为覆盖。

            或者你可以设计一个测试：模拟所有可能情况，同时静默忽略异常，以此最大化覆盖率却最小化测试价值。

            操纵测试覆盖率指标的方法五花八门，这正是该指标先天缺陷的根源。

            回复

      2. 这种观点完全正确——尤其当存在大量脆弱且无用的测试(通常只是实现的镜像，几乎毫无意义)时，这种情况在许多地方都存在。我们专注于实现近100%的集成测试功能覆盖率(即功能所有方面均被测试)，同时仅进行严格必要的单元测试，以覆盖那些集成测试难以触及或无法覆盖的次要逻辑缺陷。只要能通过集成测试验证功能有效性，我乐意删除那些充斥模拟对象的单元测试。测试模拟对象的有效性不仅毫无意义，反而有害。对于高度隔离于其他组件的代码部分，我仍高度依赖单元测试，但这类情况通常占少数。

        回复

      3. 我猜你们应该不受FDA监管吧。

        回复

        1. 再过几个月，FDA就什么都不管了。

          回复

      4. 若非开发关键软件，确实不必过度关注测试，尤其考虑到测试覆盖率本就是个糟糕的指标。

        回复

        1. 目前负责旗舰产品开发，绝对属于关键领域。

          回复

    4. 我在Autodesk工作时，办公室有个测试员要负责四个不同产品的变更测试。
      这意味着一个人要测试约80名开发者的变更！
      不用说，那位可怜的姑娘根本无力测试所有变更…
      有次会议上，我们老板竟说出这样的话：“各位能不能少写点bug？”
      而这位老板早前还拒绝了我申请采购静态代码分析软件的请求…
      没错。测试确实是整个行业的大问题。

      回复

      1. 我们不需要额外的理由来讨厌Adobe

        回复

      1. 甚至只需一个集成测试就够了。

        回复

    6. 25.10是新版 coreutils的测试平台。

      25.10是测试版平台。

      这就是测试的实践。

      回复

      1. 你是说他们通过替换核心程序进行测试，却不检查新程序是否具备旧版所有必要功能？直接发布版本再看哪里出问题？这操作有点蠢。

        回复

        1. 我只能想象coreutils留下的足迹有多深。在操作系统的测试版中进行测试，正是为了验证各种使用场景和应用程序——这正是操作系统测试版的意义所在。测试版。操作系统的测试版。用于测试软件和新功能集成。测试版。测试发生的地方。

          回复

          2. 25.10并非测试版，而是正式发布版本。

            回复

            1. 非LTS版本的Ubuntu被Canonical视为测试版本。

              回复

            2. 那干脆直接叫测试版不就得了？有那么难吗？

              尤其现在Linux世界涌入了大批对Windows(包括更新机制)失望的新用户，而Ubuntu是最受欢迎的发行版。

              老实说我受够这种扯淡操作了。

              回复

            3. 当你想下载Ubuntu时，官网首屏展示的版本就是LTS版。

              回复

            4. 那又怎样？它依然没标注测试版。

              况且说法也不完全准确。虽然标注了LTS，但点击按钮跳转的页面提供三个版本选项。其中24.10版本明确标注“搭载支持最新硬件的Linux内核6.17”和“HDR亮度控制”功能，却未提及测试版/Beta版属性，甚至未标注稳定性较低。

              我原以为他们会比微软做得更好。

              回复

        2. 抛开讽刺不谈，这个问题对我们而言之所以“显而易见”，是因为我们拥有后见之明。

          但总体而言，尽管单个 coreutils程序相对简单，它们在实际环境中的交互却极其复杂。当然，针对性的集成测试或许能提前发现问题，但要为相当于半套操作系统的系统设计完整的集成测试套件，那简直是痴人说梦。我认为《实用程序员》提倡的“追踪子弹调试法”在此情境下完全合理。

          回复

          1. 所有缺陷在事后看来都显而易见…同理，所有测试方案在发现缺陷后也显得理所当然。我认为某些人从未真正参与过大型复杂系统的交付工作。

            测试版发布阶段总能挖掘出真正影响用户的缺陷，而数以万计的用户使用系统所暴露的问题，远比系统测试和集成测试更快更大量地浮出水面。

            我玩PC游戏纯属娱乐，但那些认为游戏不该有bug、开发者只需增加测试人员数量的人，让我不得不暂时忘记自己的职业身份才能不发火(诚然，某些游戏开发者确实需要增聘测试人员)。现在开始吐槽：请重视现有的测试流程和测试人员…

            回复

    7. “我们有测试人员，他们叫做用户”

      回复

      1. 我的意思是普通用户应该使用LTS版本(当前是24.x系列)。

        回复

        1. 我个人观察到：普通用户多用最新RELEASE版，企业用户则用最新LTS版。

          LTS版本通常落后于用户需求。Rust coreutils集本应同步发布测试版，这样就不会让大量普通用户实际运行测试版了。

          回复

        2. 我强烈反对这种观点。非LTS版本并不等于不稳定。

          回复

          1. 那我们对“普通用户”的定义可能存在分歧

            回复

    8. 这个方案从一开始就显得愚蠢。为何要如此仓促地一次性替换所有 coreutils？应该经过充分测试后分批次替换。

      回复

    9. 那些周一早晨的后见之明者总爱从无限覆盖率里翻出“相关案例”指责——明明他们本该实现的。

      远处有人尖叫：“我敢打赌他们连团队阅读的构想都没文档化——我们从不做文档。”

      那日软件远未臻完美。而开发者察觉到了！

      回复

      1. 这种说法简直荒谬。人们常把重写当作爱好或实验。对你而言或许毫无意义，但对从中获得乐趣和知识的人却并非如此。

        责任在于那些将业余项目投入生产环境却未充分测试的人。

        回复

        1. ……这根本不是正式版，只是测试版软件。

          回复

          1. 恕我直言，说Ubuntu 25.10是测试版简直愚不可及

            回复

            1. 它也不具备生产环境级质量，Canonical将非LTS版本定位为测试用途，明确不建议在生产环境中使用。

              回复

          1. 他们并非为Canonical/Ubuntu重写 coreutils集。这纯粹是六个人作为业余爱好在做的事。最早的提交可追溯至2013年，比Rust 1.0发布还早两年。其本质就是如此实验性/业余化的项目。Canonical决定采用该项目，除非其自身投入资源开发uutils，否则不会改变项目本质。

            回复

    11. 整整一代Github PR“LGTM”(没问题)少年。

      回复

      1. 不，这不是“世代”问题。

        若前辈开发者更懂行——这往往是个大前提——是因为他们早已犯过同样的错误。

        回复

      2. 是啊，毕竟90年代的软件测试得可严谨了。毕竟Windows从来不会出现内存不足错误、蓝屏死机之类的问题，对吧？

        回复

        1. 8分钟前的评论竟有5个赞。你从哪个Discord服务器冒出来的？

          回复

    12. uutils使用GNU Coreutils测试套件验证兼容性，而Canonical的非LTS版Ubuntu属于测试版本。这就是测试。

      回复

    13. 各位知道.10版本和LTS版本的区别吗？

      回复

      1. 作为20年的Ubuntu用户，LTS意味着更长的支持周期。仅此而已。我从未见过任何说法称中间版本不稳定之类的说法。事实上，Ubuntu在LTS版本中也常引入不稳定功能。

        回复

      2. 这有什么区别？LTS版本照样有漏洞，只是承诺修复周期更长而已。

        Ubuntu可不是十个人在车库里搞的发行版，这可是价值数百万美元的公司，根本不该发布这种垃圾。

        唉…他们确实这么做了。

        回复

      3. 关键在于缺乏测试套件；这类问题本应在测试阶段被发现，而非由25.10版本的用户来揭露(即便最终仍需执行此测试步骤，但在非LTS版本中进行才是正确做法)。

        回复

    14. 而这正是人工智能真正能发挥作用的领域。你只需编写脑海中浮现的测试用例，再指示智能体持续添加测试直至覆盖率达100%。

      回复

    15. 当然，你们会付钱让我们做测试吗？

      很遗憾，人生苦短。公益事业固然美好，但人们终究需要谋生。

      回复

  2. 等等，他们居然用date命令显示文件修改时间而不是stat？

    回复

    1. 另外我觉得更新检测器无论采用何种实现，都该用能直接调用stat()的语言编写，而不是调用外部工具。

      回复

      1. 虽未实际验证，但我敢打赌这只是个shell脚本，十有八九是Bash写的。

        回复

        1. 虽未实际验证，但我敢打赌这只是个shell脚本，十有八九是Bash写的。

          目前尚不明确具体是哪款软件出了问题。

          至少unattended-upgrades是用Python编写的。因此我认为它更可能采用stat()方式而非调用外部命令。

          但我觉得可能是其他软件调用了date命令。我猜是那个在你启动shell时弹出广告的程序？

          至少unattended-upgrades

          回复

          1. 自我更正：我之前判断有误。根据最新信息，问题确实出在unattended-upgrades。

            回复

            1. 看来没人接受我的赌约真是太好了！😂

              既然如此，他们依赖date命令行工具的行为就更令人费解了。

              回复

            2. 没错，我最终启动了Ubuntu 25.10容器并安装了unattended-upgrades，脚本确实是用Python编写的，且似乎并未调用date命令。

              unattended-upgrades包里还有其他文件，但我猜自己没足够好奇心去追查哪个依赖date。

              回复

    2. 这正是我最初的困惑——date 到底凭什么自带这种功能？

      这完全违背了Unix核心理念“专注做好一件事”。若需格式化文件修改时间，就该用专用工具读取时间值，再通过date进行格式化。

      回复

  3. 但这不算bug…至少在uutils里不算。项目README首行就明确说明：目前缺少若干GNU特有的参数，正在积极添加中。他们对此相当坦诚。

    既然Canonical决定替换coreutils，现在的问题出在他们那边——没好好测试/更新自己的东西。

    回复

    1. 我同意uutils确实坦诚说明了缺失的标志。

      但添加-r/--reference=file却未实现该功能的决策确实是个错误。

      用户完全有理由期待：向任何工具传递未支持的标志时，系统应抛出错误而非默默忽略该标志。

      回复

      1. 是的，默默忽略事情通常是个糟糕的主意。不过忽略一个标记尤其不寻常。我实在想不通为何要这么做？我唯一见过忽略标记的用例，是作为彻底移除标记的替代方案(避免影响现有用户)，而这种做法仅适用于不影响核心功能的标记(例如改变操作方式而非操作内容的标记)。

        回复

        1. 这并非刻意为之。五年前曾批量添加大量未实现的标记功能，当时本意是后续补全。后来开发者分心了。这只是个业余项目，根本不可能发展成正式产品，难免会显得杂乱无章。

          回复

          1. 这…在我看来，即便作为业余项目也实在像个错误。

            回复

      2. 说得对。遇到不支持的标志时报错才是更好的用户体验。但这个特定标志似乎是在2020年添加的，那时谁都还没把uutils当成业余项目之外的东西(严格来说它至今仍是)。所以我不会太怪维护者。

        回复

      3. 完全同意。“成功时静默，失败时高调”才是正道。

        规则11与12：

        沉默法则：当程序无意外信息可传达时，应保持沉默。

        修复法则：必须失败时，应尽早且高调地失败。

        回复

      4. 若该标志明确标注为不支持，或许这次重写就不会被纳入发布版本

        回复

    2. BSD与GNU标志的差异依然令人头疼。每当看到同事使用 sed ，我都忍不住皱眉——它总需要if-else语句，而真正简洁的跨平台文本替换工具至今仍缺席(难道现在有了吗？)

      回复

    3. 糟了。Rust重写者和Canonical都难辞其咎——双方都对这个漏洞负有责任。

      让我们重温赫勒姆定律：总有一部分下游用户会以意想不到的方式使用软件。如果Rust爱好者选择重写 coreutils集这类关键软件，他们就有责任确保行为一致性。若无法实现，就不该贸然开始。

      与此同时，Canonical显然在发布前未能进行充分测试。这基本反映了2025年软件工程的现状。

      回复

      1. 我并非在指责uutils团队。据我所知，他们从未游说发行版在1.0版发布前采用这个副项目。

        他们有责任确保行为一致性。若无法实现，就不该启动项目

        按此逻辑，任何重写工作都不该启动，因为行为一致性需要时间积累。这是个荒谬的标准。重申：uutils项目尚未达到1.0版本，最新发布版本为0.2.2。

        回复

        1. https://jnsgr.uk/2025/03/carefully-but-purposefully-oxidising-ubuntu

          本周早些时候，我与@sylvestre会面，讨论将uutils coreutils设为Ubuntu 25.10默认工具的提案。欣慰得知他认为该项目已具备相应曝光度，现只需敲定具体方案。Ubuntu基础团队已着手制定下个周期的计划。

          虽未正式提议，但他们同意推进此事并认为项目已准备就绪。

          回复

          1. 这提供了重要背景。uutils维护者热衷于推广他们的业余项目合情合理。但即便他们宣称项目“已准备好推广”，这并不等同于能100%兼容地直接替代现有工具。

            更重要的是，Canonical有责任验证其发布的工具是否真正满足自身需求。与上游协作固然可贵，但发行版基础设施的正确性责任应由发行商承担，而非志愿者项目。他们拥有员工、质量保证流程，理应更了解自身基础设施。

            回复

        2. 好吧，我换个说法：没坏的东西就别去碰它，哈哈。

          回复

          1. 那我也改个说法：这观点简直狗屁。若有人乐在其中且觉得重构 coreutils集很有价值，那正是他们与生俱来的权利。没人非得用它不可。

            回复

      2. 与某些回应相反，行为一致性(指输入输出层面)确实是该项目的明确目标。他们正使用 GNU Coreutils 的官方测试套件来衡量进展，并在文档中公布当前覆盖率：https://uutils.github.io/coreutils/docs/test_coverage.html

        但他们从未声明过自己已真正达到与GNU套件的功能对等。

        参数解析器中包含尚未关联任何逻辑的标志确实令人遗憾。我认为这是程序设计上的疏漏，不过将已知缺失的计划功能视为“错误”仍显得奇怪。

        回复

      3. 我的意思是，如果包的读我文件里明确写着“缺少x标志请注意”之类的内容，这根本算不上bug

        回复

      4. 倘若Rust爱好者选择重写 coreutils集这类关键项目，他们就有责任确保行为一致性。若无法实现，就不该启动这个项目。

        恕我直言，这种要求有些荒谬。归根结底他们只是把代码扔到GitHub上，根本不承担这种责任。他们可以随心所欲地实现功能，甚至随时放弃整个项目。

        回复

  4. 每次看到Ubuntu急于推出新功能(似乎试图超越Fedora)，总感觉这些功能未经充分测试就仓促发布，问题重重。

    诚然Fedora早在2016年就支持GNOME Wayland，但他们早期发布的其他功能似乎都运行良好，或仅存在少量缺陷。

    我认为Ubuntu本应采取更渐进的方式发布新工具集。每次发布仅选择5个二进制文件，并确保前后版本切换便捷——比如提供命令级切换功能。当 coreutils集这类重要组件被替换时，更应谨慎处理替换流程。

    回复

    1. 这并非意图超越Fedora。只是新负责人上任了，忘了他的头衔。但他热衷Rust语言和NixOS系统，并希望推动Ubuntu现代化。

      切换回coreutils只需一条命令且受官方支持。实际上两者都预装在系统中。

      回复

      1. 我个人并不确定是否支持单独选择，只在某些投诉中看到有人专门抓取gnu coreutils的特定包。

        我本人确实欣赏Rust，但必须质疑Ubuntu在此事上追求的惊人速度。

        回复

            1. 用“卑劣”形容这种在集成测试中漏网的普通漏洞，实在是个极端怪异且道德化的措辞。

              回复

    2. Ubuntu 搞这种操作简直是家常便饭。早在2008年，他们就仓促将尚未成熟的PulseAudio作为默认音频系统发布，导致该项目在相当一部分Linux用户中声誉扫地长达数年。

      若想避免更新破坏系统，请使用Debian。

      回复

      1. 我绝对不会主动在服务器上安装Ubuntu，服务器环境只选Debian。但对于日常使用的普通系统，Debian对我而言过于保守。

        回复

      2. 他们不也是我们被迫接受systemd的主要推手吗？我对过去的时代记忆模糊，毕竟在这粪坑里干活太久了。

        回复

        1. 不，他们曾有自己的启动系统(upstart)，和systemd竞争了一阵子但败下阵来。反正/etc/rc.d里那些质量参差不齐的shell脚本时代本就该结束了(我记得那段历史，好在终于告别了)，但Ubuntu搞了个“非我发明症”。

          他们还曾尝试用Mir取代X窗口系统，而非采用Wayland。

          这次至少看起来没再搞“非我即非”。

          回复

          1. Ubuntu搞了“非我即非”

            Upstart比systemd早四年问世，所以并非对systemd的“非我即非”反应。

            2013年宣布Mir时Wayland尚不存在，因此并非选择项，而Canonical需要能在智能手机上运行的方案。

            回复

    3. 我的意思是他们特意在25.10版本中加入它，以便在四月LTS发布前完成修复。

      回复

    4. 想象一下竟想超越那个叫Fedora的垃圾发行版。想想看。

      回复

        1. 我的毛茸茸暗讽。真有意思。

          回复

  5. 人们真会因为一个公开兼容性追踪器显示项目尚未完全兼容就发火吗？明明追踪器明确标注了兼容状态。

    若真要发火，该怒斥那些用过时系统发泄的Linux发行版——它们用陈腐的bash实现关键系统，运行着滞后六年的Python和Perl版本，简直是编程语言界的拉丁语。

    这倒是个好主意，用你新掌握的Rust能力来修补这个漏洞吧。说不定 coreutils集就能摆脱关键任务的桎梏了。

    回复

    1. 难道大家真的在气：一个拥有公开兼容性追踪器的项目，明明追踪器显示完全兼容，却仍未实现完全兼容？

      我认为人们愤怒的原因在于Ubuntu在该技术尚未成熟时就仓促采用。这将引发更多安全漏洞，而非解决现有问题。

      回复

      1. 这确实是值得对Ubuntu(及其一堆残缺的bash脚本)发怒的正当理由。

        但这不足以成为对Rust工具链甚至Rust语言本身的愤怒依据。

        回复

        1. 有趣的是，该标志虽被纳入uutils的参数解析器，却未实际关联任何逻辑，这解释了为何Ubuntu的更新检测逻辑会因无效标志静默失败而非报错。

          这显然是个缺陷，而非功能缺失，可能导致Ubuntu过早切换到Rust uutils

          回复

    2. 落后6年的python和perl版本

      需注意：编程语言版本更高未必意味着更好。新版本可能引入新漏洞，例如破坏旧代码的兼容性。这始终是权衡取舍的问题。

      我赞同关于bash的评论。要是人们能停止编写shell脚本就好了…

      回复

      1. 新版本可能引入新漏洞，例如破坏旧代码的兼容性。这始终是权衡取舍的问题。

        不过这取决于语言特性及其变更管理机制。Rust的处理方式对终端用户相当友好：

        1. 他们执行crater运行，将crates.io上的所有内容(及更多代码)进行编译，确保系统仍能正常编译。
        2. 可能导致破坏性变更的内容会被移入版本，每三年发布一次。不同版本的仓库可相互依赖，开发者也可选择使用旧版编写代码——编译器仍能正常处理。
        3. 代码升级至新版同样高度自动化，通过cargo fix --edition命令即可确保代码在新版本中保持原有行为(若需新特性，可撤销该命令的修改)。

        由此形成极强的“已发布代码永不破裂”保障机制。

        我赞同关于bash的评论。要是人们能停止编写shell脚本就好了…

        shell脚本自有其适用场景，但确实希望发行版能采用更注重正确性的工具，将shell脚本编写权交给用户。

        更令人惊讶的是它们依赖date -r命令；这本应使用stat函数，或者干脆不用bash编写； stat功能理应存在于任何语言的标准库中。Python完全可替代shell脚本；该功能在Rust或Go等现代编译语言中实现也应轻而易举。

        (Rust其实没有多数人想象的那么难，对于shell可处理的复杂度级别程序，借用检查问题 真的 不该成为障碍。)

        回复

  6. 不过根据你引用的来源，该句式应使用过去时而非现在时，因为开头写着：

    由于date命令中现已修复的错误。

    这更像是通知Ubuntu 25.10用户需要手动执行一次更新才能恢复自动更新功能：

    若您的系统使用的是rust-coreutils <= 0.2.2-0ubuntu2版本，可通过手动更新rust-coreutils包解决此问题：

    sudo apt install --update rust-coreutils

    若您一直通过apt或其他方式手动更新系统，则可能不受此问题影响。

    回复

  7. 值得注意的是，该标志虽被纳入uutils的参数解析器，却未实际关联任何逻辑处理，这解释了为何Ubuntu的更新检测机制在遇到无效标志时会静默失败而非报错。

    你们居然敢发布基础命令行工具却不为每个标志编写测试用例？

    回复

    1. 他们使用的是GNU coreutils测试套件。但目前测试通过率尚未达100%，Canonical竟认为可以发布，实在令人费解。

      回复

      1. 尚未达到100%通过率

        搞什么鬼？这种状态居然敢发布？

        回复

        2. 他们尚未决定是否采用。26.04最终仍可能搭载GNU coreutils集。

          回复

          1. 26.10不是一周前左右的当前“临时版本”吗？

            回复

            1. 25.04和25.10才是当前的临时版本。26.04将是下一个长期支持版本，随后26.10作为临时版本发布。

              回复

            2. 抱歉，我确实搞混了版本号。但我不理解你关于26.04的评论； 25.10版本已搭载Rust coreutils集，且显然默认启用——因为升级功能已失效：https://discourse.ubuntu.com/t/questing-quokka-release-notes/59220

              您是否在暗示26.04可能完全不包含GNU工具集？我不太明白这与您前文评论的关联性——那位用户质疑为何要预装尚不完整的Rust版本。

              回复

            3. 它们是25.10的默认配置，但能否成为26.04的默认配置尚待观察。25.10正是验证这一决策的试验场。过渡版本向来是残缺功能的试水场…这并非首次。

              回复

            4. 啊，明白了，这说得通；谢谢。

              回复

        3. 搞什么鬼？为什么要发布这种东西？

          答案你心里有数。

          因为Rust教条——只要是用Rust写的，就必须更优秀，毕竟Rust有魔法属性。

          (这根本是邪教，和兽迷圈如出一辙，简直如出一辙)。

          回复

          1. 我完全不理解这个类比。兽迷圈有这种意识形态吗？我一直觉得他们只是粉丝群体，既不试图改变世界，也不刻意扩张。

            回复

            1. 不，兽迷群体并非如此，他们只是喜爱拟人化动物的爱好者。

              楼主不知为何硬要把Rust和兽迷扯上关系(？？我从未见过这种关联)，同时又把兽迷说成邪教。在我看来相当诡异。

              回复

      1. 换言之：Rust版本的失败暴露了原始GNU coreutils测试套件的覆盖率漏洞。

        回复

  8. 我欣赏Rust的理念，甚至(或许)认同重写Rust的初衷，但整个努力显得毫无意义。

    回复

    1. 俗话说得好：没坏的东西，重写成Rust版，说不定就能坏掉

      回复

      1. 但想想速度提升——以前更新要花几小时，现在瞬间搞定！

        回复

        1. 看看速度对比吧，现在很多场景反而慢多了 😀

          回复

          1. 谷歌搜索“uutils vs coreutils performance”得到：

            • Rust Coreutils 0.1发布，性能大幅提升
            • Rust Coreutils性能竟逊于GNU coreutils
            • uutils 因子比 GNU coreutils 因子慢得多 #1456
            • Rust Coreutils 0.0.28 带来更优性能与…
            • Rust Coreutils 0.2 发布，实现“巨大”性能提升…

            唉。

            回复

            1. 我的意思是，这些说法都正确，他们每次发布的新版本都比前一版快得多，但每个版本都比 GNU coreutils慢得多

              回复

        2. 这个版本 快如闪电 ，而且 用 Rust 编写！

          回复

    2. 纯粹为了重写而重写毫无意义。但若怀着明确目标重写——比如提升内存安全性，同时让更多人能参与项目(依靠Rust避免C语言的陷阱)，并实现代码库现代化——那就值得了。

      然而，所有重写本质上都是糟糕的，因为你把一个“稳定”的程序再次搞得“不稳定”；所以如果你真需要重写，最好搞清楚自己在搞什么鬼 🤣

      回复

    3. 如果你感兴趣，我记得Ubuntu核心成员发布过一段15分钟的视频解释重写理由。其中一半内容纯粹是想吸引不用C语言的新开发者。

      回复

      1. 我知道这种文化因素(即你所说的)是理由之一。

        这论点倒不算糟糕，但现有C代码量依然庞大，我们仍需要能用C编程的开发者。

        回复

      2. 能分享链接吗？我很想看看这个视频。

        回复

    4. 我通常喜欢Rust重写项目。至少它们很有趣，而且往往确实实用。云云。

      但这次coreutils重写让我反感。它不像大多数Rust重写项目那样具有独特性。而且它犯了Rust重写项目最大的毛病：取消了GPL许可！

      作为从1.0版本就开始使用Rust的铁杆粉丝，最让我恼火的就是这个社区根本不遵守GPL——这可是开源项目得以蓬勃发展的根本原因！没有它，许多曾经开放的系统早就变成封闭系统了！

      这只会加剧这种现象——他们急于替换GPL许可的代码。这些代码本已稳定且基本不会变更，而据我所知，新代码甚至没有像其他Rust重写版本那样添加任何功能。

      到底为什么？！

      (因为这样就能摆脱GPL许可，这就是原因。)

      回复

      1. 我也厌恶Rust不采用GPL许可证的做法。但另一方面，Rust似乎不支持动态链接——这意味着若使用LGPL库，最终程序必然成为GPL项目；而在C语言中，这类库仍可用于专有程序。

        回复

        1. 这种情况在更广泛的生态系统中确实存在，但对终端用户工具的重写影响不大。

          不过多数Rust开发者会自然选择MIT+Apache许可证，毕竟这是行业惯例。

          回复

      2. 我认同规避GNU(更准确地说，规避GPL)的做法实在糟糕。

        这些工具采用GPL许可，恰恰是相对健康的软件生态系统中至关重要的一环。

        回复

        1. 没错，我不认同“GPL限制库开发”的论调，即便有人这么认为——但这些可是 应用程序 啊。

          回复

      3. 对成千上万的我们而言，取消左派版权极具吸引力——我们深知RMS初衷虽好，却身处截然不同的世界。GPL代码难以商业化，因此难以与GPL代码关联，除非取消左派版权，否则我们既无法构建基于Linux的世界，也无法支付房租。

        倘若开源世界彻底转向专有化，尽管尽情指责我们——但我们并非如此。我们正走向 更 宽松的许可。没错，资本家可以使用MIT和BSD许可的代码。但这并不意味着我就是资本家。这让我成为真正的社会主义者——坚信我和同类人应当无需咨询版权律师，无需绕开某个社会功能失调的怪胎的极端立场，就能收获劳动果实。

        回复

        1. 不知为何我加了你好友标记你，大概是喜欢过你某条评论之类。但在此事上我强烈反对你的观点。

          Copyleft并不意味着你不能开发和销售软件，它只是规定该软件不能成为闭源产品。

          这意味着如果你开发了一个库，成群结队的公司程序员会拿走你的成果却毫无回报。他们的公司从中获利，而你运气好的话，在软件出问题时还能收到愤怒的报错单。

          与此同时，我们拥有Linux。这个庞然巨物无法被复制。它迫使企业程序员公开并 标准化 其代码。如今企业甚至愿意付费参与贡献。无数设备因此获得Linux支持，而非仅限于原生系统。而其他开源机制的存在，使得即使是高度定制且锁定的安卓手机，最终仍能让终端用户获得远超封闭系统的可修改性和可控性。否则它将彻底封闭。

          倘若Linux被转为宽松许可协议，所有分叉版本都将拒绝开源。失去凝聚力的激励机制，Linux必将分崩离析。

          诚然，企业更倾向于向宽松许可的仓库贡献代码。但相较于它们获取的资源，这种贡献微不足道。

          作为另一名企业程序员，这确实更便利，但若仅在内部使用GPL代码而不公开，同样可行。

          我欣赏那些“付费即免GPL”的框架——在我看来这堪称两全其美。

          但最终我仍持异议。这不过是宽容悖论的体现：要维持开源世界的开放性，必须确保人们有义务保持开放。否则企业凭借资金优势终将将其封闭。

          回复

          1. 我们无法坦诚讨论资金问题实在令人恼火，因为只要我稍作暗示——而非像往常那样重复百遍你心知肚明的论调——你那套说辞就会如期而至，而这些话完全偏离主题：

            “抄左”根本不禁止商业化！你这散布恐惧、不实信息、挑拨离间的混蛋！

            这谁不知道？若你无法坦诚参与讨论，请让开道路。其他人都在努力寻找既能编写自由开源软件又能支付账单的途径。正是这种狗屁言论，让众多高薪同行认为我们是可笑的理想主义者。

            回复

            1. 那我直说吧：开源确实存在资金问题。编写开源代码并销售软件简直难如登天。人们唯一能从中获利的方式，就是将代码闭源。

              我确实想就这些事坦诚交流。或者说，我更希望看到你对此展开更多论述。请问你是否还有那篇论文的链接？

              看着我们的设备被层层锁死，看着无数人的无偿劳动被肆意窃取，实在令人沮丧。

              我认为我的视角与众不同——站在所有不被付酬却遭剥削的业余爱好者立场。而你的立场则是作为开发者，将开源作为主业，需要采用MIT/Apache许可证才能销售/提供支持，或将其纳入可售的闭源软件。

              但就开头那篇帖子而言，我认为取消GPL许可确实很糟糕。Ubuntu从 coreutils移除GPL许可并不会带来更多收益。不过随着时间推移，他们或许能通过打造专有操作系统获利——既可销售系统本身，又能提供付费支持。他们长期以来推出的那些怪异定制版Ubuntu软件就是明证，这正契合了他们的战略布局。

              我认为这与开发者为可售软件采用部分甚至多数MIT/Apache许可证(而非GPL)的情况截然不同。别误会，我虽不赞同这种做法，但完全理解其合理性。普通开发者未深思此问题也情有可原。

              我确信你那边还有我尚未理解的视角，很乐意听你进一步阐述。

              回复

      4. 到底为什么？！

        因为撰写这些内容的Rust拥护者更在意流行度和覆盖面，而非用户实际遇到的问题。

        他们根本不在乎GPL和BSD的区别——他们只在乎Rust运动本身。

        回复

    5. 我不认为这是浪费。只是在达到临界点前，它看起来像浪费。

      就像重写任何东西——当下不会产生价值，但当整个内存安全系统完成时，其价值将无比巨大。

      仅实现1/10的内存安全系统毫无吸引力。除非达到临界规模，否则无法创造价值。

      回复

      1. 现有 coreutils(coreutils)存在显著内存安全问题吗？比如内存泄漏或释放后使用漏洞？

        内存安全在此似乎毫无意义，这更像是为解决虚构问题而设计的方案

        回复

            1. 这份项目存在理由清单中，显然没有任何一项与内存安全相关——这恰恰印证了我的观点：该项目远不止于解决内存安全问题。你忽略了其扩展功能(进度指示器就相当实用)，这些特性未来完全有可能真正超越 coreutils集。

              回复

            2. :uutils coreutils旨在成为GNU实用工具的直接替代品。与GNU的差异均视为缺陷。

              我们的核心目标包括：

              • 完全匹配GNU的输出(标准输出与错误代码)

              这并非重写的正当理由。这基本是重写成功的最低要求。

              • 优化错误信息
              • 提供全面国际化支持(UTF-8)
              • 提升性能
              • 适时扩展功能(例如：–progress)

              所有这些(尽管我不明白UTF-8部分的意义)似乎都是 向上游贡献 而非 重写 的合理依据。更何况uutils目前已知存在多种性能退化问题，距离实现该目标还差得远。

              我能想到的重写理由仅有三点：

              • 个人动机
              • 许可证问题
              • 与其他生态系统的兼容性(但实际行不通，C语言仍是FFI基础)

              或许最后一点尚有参考价值——我近期编写的格式化脚本曾调用jq工具，后由Claude用Go重写以提升性能，又由Claude改用Go原生重构的jq实现(仅在必要时回退)，最终进一步提升了效率。但我不了解Rust生态是否支持将所有uutils作为库使用。

              回复

            3. 谁让你当重写的正当性仲裁者了？

              回复

            4. 为重写而重写仅具有个人动机价值。你明确(或至少暗示)要以目标为依据判断正当性。目标或许良好，但不足以证明项目合理性。

              回复

            5. 为什么你总能断定项目目标不足以支撑这个计划？Ubuntu显然认为重写是合理的

              回复

      2. 据我所知， coreutils过去十年从未出现过内存安全问题。既然这次重写可能导致行为模糊、破坏现有工作流程，甚至引入像这样的新漏洞，它究竟有何价值？

        回复

        1. 若我没记错， coreutils过去十年从未出现过内存安全问题。

          你记错了。2025年5月27日就有过一例。

          既然重写可能导致行为模糊、破坏现有工作流程，甚至引入此类新漏洞，为何仍认为其具有价值？

          实际重写采用GNU测试套件，数据显示过去数年测试通过率呈线性增长，预计两年内即可通过全部测试。

          然而Ubuntu下一版LTS计划于2026年4月发布，显然他们不愿再次使用GNU coreutils，因此2025.10版可视为测试版——旨在验证能否在2026.04版最终决策截止前让Uutils coreutils达到满意运行状态。

          回复

        2. 你的观点存在若干误区：

          你将Rust编程的唯一动机归结为内存安全，实则不然。该语言兼具卓越的易用性、运行速度与内存安全性，其人性化设计正是广受欢迎的关键因素。

          你认为软件重写必须具备明确目的。虽然这里很多人只针对Rust这么说，但重写软件本身就是宝贵的学习经历，有时其价值不言而喻。Uutils最初只是学习Rust的项目，后来却发展出独立价值——它已能满足日常使用，并可替代 coreutils完成多数工作流程。这并非强制要求替换 coreutils，只是证明其可行性。

          你似乎认为软件项目必须实现完全等效才能算成功。Uutils理应、也必将支持所有命令行选项，但许多人却因少数漏洞或未实现功能就大惊小怪。未来还会有更多问题出现，没必要对一切都如此消极。

          在Unix生态中，实用工具乃至系统调用都存在显著差异。它并非众人想象中那种完美系统——实现posix及posix工具并不意味着百分百向后兼容。

          回复

          1. 该语言兼具卓越的人体工学特性、高速运行与内存安全性，其人体工学设计正是广受欢迎的关键。

            “人体工学”难道不是极主观的评价吗？此外，我认为Rust在速度上并不比C语言更具优势，仅在内存安全性方面有所提升

            回复

            1. 易用性远不止于对语法的个人感受。Rust在系统编程领域的 客观优势 在于：它比C语言更具表达力，通过易用的高级抽象机制，引导开发者明确定义并强制执行约束条件。C语言不存在“拥有指针”(Box<T>)、‘字符串切片’(str)甚至“引用类型”(&T)的概念，而这些在Rust中无处不在，且各自附带明确保证(分别是唯一性、utf8有效性、活性)。

              通过类型系统使无效状态无法表示，原本隐含的假设可转化为程序中真正可强制执行的属性。这往往能生成无需深度优化的高性能代码——尽管Rust正因如此在优化领域同样卓越，其抽象设计更允许你随心所欲地贴近底层(代价是冗长性，因为所有假设都需显式声明)。或者在使用unsafe时可能需要自行维护这些假设)。一旦熟悉这种开发体验，你就会理解Rust开发者为何如此痴迷于这门语言。

              另一部分优势在于泛型、完善的模块系统、卫生宏、默认常量、别名与可变性的互斥、生命周期追踪、强制穷举等特性，这些也都是客观上更优的设计。

              回复

        3. 这全是夸大其词——不过是担心内存安全罢了。

          回复

        1. 因为无数人痴迷于内存安全概念却从不自问：若你重视“安全性”并将其纳入考量，就该追问“为何在乎安全性？”

          多数时候你会发现答案是…其实根本不需要。或是本不必在意，却因某些奇怪的个人原因执着于此。

          回复

    6. 有趣的是，当coreutils移植到FreeBSD时无人关注，而这次却因“Rust”成为新闻。

      回复

      1. 我不清楚你指的是什么，但这两者完全是两回事。

        将coreutils移植到FreeBSD，是让该操作系统能够使用coreutils工具集，而此前该系统无法使用。

        而为同一操作系统重写Rust版的coreutils，则有些毫无意义。我尚能理解sudo-rs的必要性，但doas更令我信服。然而仅为[内存]“安全性”重写代码却未明确威胁模型，实属荒谬。

        更糟的是鲜少有人提及——许可证变更了。据我所知从GPL改为MIT许可证。虽然我也常使用MIT软件，但许可证差异确实会影响软件的普及与采用。

        回复

        1. GNU coreutils本身就是对既有工具的重写，而这些工具又被多次改写过

          回复

          1. 没错，GNU本身就意味着“GNU不是Unix”，干脆叫“难以置信的非Unix”或“法律上独立的Unix”更贴切。

            除Unix家族(AT&T、BSD、HP-UX、AIX、IRIX、Xenix、Sun/Solaris、OSX等)外，还有Busybox等衍生版本。

            这确实是相当庞大的家族谱系。

            回复

          2. 当然，其存在意义正是将这些工具移植到新平台。重写是合理的，因为移植本身就需要重新编译，且在许可/版权层面必须保持法律上的独立性。

            如果uutils想成为“MIT许可的 coreutils”，这无可厚非，选择Rust语言也完全合理。但为满足下游需求而 替换 现有工具则毫无必要。无论是uutils自身还是下游发行版选择Rust，若 仅因追求“更安全” 则毫无意义。重写本质上会引入逻辑错误或至少导致兼容性问题——我曾亲历工作电脑上的bsdtar无法解压tar文件，最终通过brew安装了gnutar替代。

            为实现良性进程的内存安全而引入新逻辑漏洞和兼容性问题，值得吗？不值得。重申一次，我勉强能接受sudo或systemd的改动，但 coreutils绝不可动。

            苹果从bash切换到zsh、从nano切换到pico，源于(至少被认为存在的)许可要求。但这绝非所有Linux发行版的考量因素。试想在Arch系统上给别人发tar包，结果在Ubuntu上解压失败——甚至更糟，解压出错——那场面可就滑稽了。

            回复

          3. GNU coreutils本就是开源重构项目。多年来它创造了巨大价值，为Linux成功铺平道路——毕竟多数关键组件都以可移植开源形式存在。

            回复

    7. 对参与者而言或许很有趣？在我看来这并不无意义。

      回复

    8. 我本以为给比祖父母更古老的东西刷层新漆会不错。

      但实际查看后发现他们基本在逐位精确重写，就像让大型语言模型把C代码转成Rust。我原以为他们会处理io_uring底层实现、移除争议性参数、添加长期待办功能或完善文档。

      结果更糟。不过确实用Rust实现了。

      回复

      1. 你从哪儿得出这种结论？我虽不精通Rust，但他们的代码看起来很正常，并非敷衍了事地从C语言移植过来。

        回复

        1. 虽不至于如此极端，但“用Rust重写以获得现代架构、优质代码、先进特性和安全保障”与他们所做的“用Rust重写以获取编译器安全而非测试安全”存在本质区别。前者显然是更有价值的努力。

          回复

      2. 最初开发这个项目是为了学习Rust，所以代码可能存在某些不够优化的地方。

        但即便抛开这点，我觉得你还是没抓住重点。uutils的初衷就是成为coreutils的替代品，而非对coreutils进行彻底改进或重新构想。

        已有其他Rust和Go项目实现了更优的coreutils版本，比如ripgrep或fd。这并非对coreutils的批评，两类项目都应并存。

        回复

    9. 这和运行Cobol主机的人说的是一模一样！

      回复

    10. 这并非浪费，只是需求太过庞大。

      试想用C语言编写整个操作系统——根本无法管理。Rust能引发的崩溃概率远低于C语言，系统不会因存在本身就发生段错误。它让团队能在保持内存安全的前提下加速迭代。

      切记莫要操之过急

      回复

      1. 试想用C语言编写整个操作系统——根本无法管理

        你真懂自己在说什么吗？你用的是哪个操作系统？

        回复

        1. Linux、Windows、MacOS。随需而用。

          你到底懂不懂自己在说什么？

          我的话有什么问题吗？如果让两支经验相当的开发团队比拼，Rust团队永远会胜出。迭代更快，内存问题更少。

          除了单纯更快之外，C语言还有什么优势吗？

          回复

          1. 我的话有什么问题吗？

            Linux发行版主要用C语言编写，35年来运行良好，BSD及其他Unix系统亦是如此。

            你试过Redox吗？听说它非常稳定。

            回复

            1. Linux发行版主要用C语言编写，35年来运行良好，BSD及其他Unix系统亦是如此。

              BSD系统直接源自原始UNIX，因此拥有55年历史而非35年。

              回复

            2. 我清楚它们更古老，我的重点在于它们是用C语言编写的且这并非问题。我回复的对象似乎认为用C语言编写的操作系统不够优秀？若有误解还请见谅。

              回复

            3. Linux的稳定性是尽管使用C语言而非因为C语言实现的。这个区别很重要。

              我热爱C语言。但Reddit和phoronix上充斥着将C语言奉为神奇法宝的人，认为它能造就伟大软件。其实三十年前人们就已知晓C语言的所有缺陷和陷阱。

              回复

    1. 用Rust无谓重写 coreutils的年份。

      回复

      1. 用毛茸茸语言无谓重写 coreutils包的年份。

        回复

    1. “Perl 6语言[…]规范包含约15.5万个测试用例，通过该测试套件的任何程序皆可自称'Perl 6编译器'。” 试想若“ coreutils也采用这种机制。

      可以说POSIX正是如此。

      回复

    2. 我认为这是好事——至少能确保符合测试标准——但这并非语言本身的特性。我认为应该采用其他方式进行测试。虽然我也不清楚具体方法；天真的想法是让AI自动测试所有情况。但现有AI可能无法真正理解当前问题领域。它本质上是通过查看现有数据来“作弊”，因此并未真正“理解”任何内容。它只是基于LLM、马尔可夫链等技术进行复制粘贴和重组。这并非真正的理解。

      回复

  12. 提醒下，我们为何要重写所有内容？

    回复

    1. 最初纯粹是大家图个乐子，并没有什么宏大计划。

      回复

    2. 因为 coreutils包太稳定又久经考验，我们需要更多漏洞！/s

      再说Canonical就爱搞砸Ubuntu。看看mir、Unity、snap、终端里的ubuntu-pro等等。

      回复

      1. Rust 兼具 C 和 C++ 的实际经验优势。

        回复

          1. 我觉得增强内存安全性本身不会惹恼任何人。

            显然你从未看过Phoronix的评论区。

            回复

    5. Rust默认解决了潜在的安全隐患。

      Rust并非比C更快，而是更安全——它强制执行正确的拥有权机制，并为线程和共享内存设置了更少出错的处理方式。

      我认为这些错误源于测试覆盖率不足。我曾参与要求100%覆盖率(分支和行数)的项目和库开发，这有助于优化设计可维护性，避免全局变量隐藏功能等问题，并实现所有组件的可注入性。

      常见情况是截止日期压力，要信任那些能交付优质PR的人。

      我认为这并非大问题，只是优化流程、完善迁移机制的手段。

      回复

      1. Rust与C的运行速度相当，Zig和C++等相关语言亦是如此。若察觉C与Rust存在差异，很可能是GCC与LLVM编译器导致的。

        回复

          1. 没错，但不明白你的论点

            回复

      3. 100%覆盖率？！要么你在撒谎，要么大部分测试代码是垃圾。证明我错了。🤣

        回复

        1. 这更说明你的问题而非我 🤷‍♂️

          回复

          1. 🤣 声称代码库有100%测试覆盖率的人要么在撒谎(要么用无用测试凑数)。你自己信吧兄弟。

            回复

    6. 因为Rust比GNU coreutils主要使用的C语言更新潮。

      我个人在等待AI增强版ls命令。

      回复

      1. 个人而言，我期待的是AI增强版ls命令。

        抱歉，我无法列出名为“pr0n”的目录内容，
因为其中充斥着命名极其不当的MP4文件。您是否需要
改为列出~/Documents目录？
        回复

    7. 抛开文化变革和所谓的内存安全优势不谈——Rust让性能优化比C语言轻松得多，比如能轻松实现多线程操作而无需担心数据竞争。这已助力部分工具重构，比如(我记得是)grep和sort

      值得吗？说不准。该做吗？何乐不为！

      回复

        1. 这是我用过最愉悦的编程语言，而我尝试过很多。技术问题？

          回复

    9. 道德标榜。这才是唯一真实原因。

      回复

  13. 我弃用Ubuntu了，用非LTS版本感觉像实验品。不行。

    回复

  14. Ubuntu每次发布都出问题，但这次的故障原因堪称史上最荒谬。

    回复

  15. 耐人寻味的是，该标志虽被纳入uutils的参数解析器，却未实际关联任何逻辑——这解释了为何Ubuntu的更新检测逻辑在遇到无效标志时会静默失败而非报错。

    按理说应该有个环境变量，让uutils在遇到未实现的标志时报错。

    回复

  16. 奇怪的是，该标志虽被纳入uutils的参数解析器，却未实际关联任何逻辑，这解释了为何Ubuntu的更新检测逻辑会静默失败，而非因无效标志报错。

    其实没什么好好奇的。显然他们打算后期再实现该功能。这个版本本不该在准备就绪前就作为Ubuntu组件发布，但软件移植过程中这种做法相当普遍。

    回复

    1. 与其文档描述实际未实现的功能。

      若采用clap的structopt风格派生宏，未使用的字段本会触发dead_code警告，从而提醒开发者补全实现并强制添加todo!()。在我看来，整个问题本质上是clap构建器API的缺陷。

      回复

  17. Rust正在破坏我们的系统！

    虽然C语言也可能发生类似问题。或许现在是时候让两种语言的大型项目确保此类问题不会成为设计缺陷了。目前看来，这些问题大多取决于编写代码的开发者有多聪明，而并非所有人写代码时都足够聪明。

    回复

    1. 事实证明 coreutils缺少测试，而通用工具集存在占位标志。双方都修复了这个小问题。

      回复

  18. 这又一次让那些毫无意义的重写计划回归现实

    回复

  19. 直言不讳地说，date -r本就非标准命令，未纳入Posix规范，从一开始就不该被使用。

    不过这个新项目声称要实现与 GNU coreutils 的完全兼容(包括所有已知缺陷)，而不仅限于 Posix 标准，因此至少应该为 date -r 设置测试用例。

    我怀疑还有更多兼容性问题等待发现(某些情况下 uutils 本身行为正确，但其他组件依赖于 GNU 实现中的历史缺陷)。真是有趣的时刻 🙄

    回复

    1. 他们并未宣称实现100% GNU兼容性，只是将此作为目标。根据其README文档和官网声明，目前尚未达成。他们采用coreutils的测试套件，并透明地公布uutils通过测试的程度。

      回复

    2. 但这个新推出的uutils项目宣称要实现与GNU coreutils的逐个漏洞兼容性，而不仅是Posix合规性，因此至少应该为date -r设置了测试项

      GNU coreutils测试套件本身并未测试-r选项，直到最近几小时才新增相关测试。由于uutils基于coreutils套件进行测试，该漏洞未被察觉。

      https://github.com/coreutils/coreutils/commit/14d24f7a530f587099057fa5411ebcf3cfc55e7d

      换言之：Rust版本的失败揭示了原始GNU coreutils测试套件中的覆盖率漏洞。

      回复

    3. https://pubs.opengroup.org/onlinepubs/9799919799/

      我认为这里很多人误以为posix规范详尽完善。事实并非如此，所有规范都存在扩展。Linux的难点之一在于glibc充斥着被库程序广泛使用的扩展，这使得实际移植变得困难——例如使用musl时。工具集同样存在此问题。

      回复

        1. 我不确定你是否在讽刺。正因如此我才提供了链接。规范仅定义了一个开关，其余均为扩展功能。

          回复

  20. 没错，在确保尽可能稳定且经过充分测试前不会切换。

    回复

  21. 但有人告诉我，Rust编译通过的软件就不会有bug？s

    回复

    1. 我也听过这种说法。“能编译就行得通”。所以uutils不可能有bug，否则根本编译不了。

      回复

    2. 编程二十年，供职于多家财富500强和FAANG企业。我敢断言：语言若难以阅读理解，永远无法普及，更会导致调试困难。C语言简单易懂，Rust短期内无法取代它，希望这种局面能持续下去。

      现在就要挨Rust狂热粉的差评了😂

      回复

      1. C++显然是您规则的例外。Rust也已具备广泛应用基础。

        回复

        1. FAANG企业确实广泛采用Rust。各大云服务商都在使用它。如今Linux和Windows内核都包含Rust代码；据传闻及苹果招聘信息显示，他们也在使用Rust。

          更别提Android的蓝牙协议栈多年来一直用Rust实现，而Android手机的出货量可是相当惊人。

          回复

      2. 我能肯定的是：如果一种语言难以阅读/理解，它永远无法实现大规模普及，更糟的是会让调试变得极其困难。

        我实际生产环境使用Rust近五年，认为作为系统语言它并不特别难读难懂。调试过程中极少遇到困难。

        C语言简单易懂。

        它之所以易懂，是因为规则极少。但为避免行为未定义，你必须额外添加隐含规则和约定。正因其过于简陋，开发者不得不不断重复造轮子，最终代码总量往往超过多数语言。这两点都算不上优势。

        Rust短期内不会取代C语言，我希望这种局面能持续下去。

        虽属实，但我认为C语言显然已呈衰落之势。如今选择学习C语言的人寥寥无几。这恰恰是Linux采用Rust实验的重要依据。当老派C开发者退休或离世后，终将缺乏新鲜血液来延续这些项目。

        回复

      3. 不过我投了赞成票 🙂 我的帖子也开始被点踩了，之前短暂保持正评分后 🙂

        回复

        1. 没错，软件工程确实像个教派(某种程度上，我们人类终究是猿类，总会追随自己的族群吧🥴)。我相当确定Rust不会超越C语言。这不过是代际更替——那些未曾深入学习C的新生代程序员，只是盲目追逐他们自以为更优的语言。但他们不明白的是，每种语言都有致命缺陷，Rust同样无法幸免。

          在我看来，程序员的操作体验至关重要。若某种语言难以阅读和编写(C语言易读且编写难度不高)，它终将昙花一现，沦为一时风潮。

          回复

      4. Rust比C更易读。C语言语法脆弱性曾引发重大安全漏洞(如心脏出血漏洞)，最近Cups也因此出现远程代码执行漏洞。

        你已经错了——Rust早已普及。

        回复

  22. 去他妈的Ubuntu，去他妈的Canonical。

    回复

    1. 完全同意。但这次要骂的是Rust狂热粉和Rust重写项目。

      (爱Rust语言，恨其社区)

      回复

    2. Coreutuls并非Canonical出品，难道要揪住信使的胳膊？

      回复

    1. 企业强制要求用Ubuntu，SDK和工具也常为Ubuntu发布…放弃它不容易

      回复

      1. Canonical那群无能蠢货干过最疯狂的事，就是在LTS版Ubuntu里塞非LTS内核。值得花时间学会弃用它，总比冒险强。

        回复

      2. 我可以明确告诉你，我所在的团队 绝对 会停止使用Ubuntu，因为我对这个决策有很大影响力。

        回复

    2. 求求你们别再用这种梗语言重写经过实战检验的代码搞破坏了。

      用内存安全语言开发新软件我理解，但重写现有软件毫无意义。绝大多数潜在内存问题早已修复。

      回复

      2. 如果有人想重写代码，那没问题，但问题在于发行版们毫无理由地过早跟风采用。

        回复

    3. 有没有简单又好的替代方案？

      回复

  24. 请添加单元测试。你用的是Rust，没有理由不做。

    回复

  25. 今天这些工具更新了。大概是修复这个问题？

    回复

  26. Ubuntu 25！上次尝试时Steam运行时卡在Ubuntu 12版本。

    回复

    1. 此说法不准确。Steam运行时存在多个版本。

      回复

      1. 这是我运行Steam客户端(Steam客户端无法工作)时，自动下载运行时文件的steam-launcher发送给我的版本。如何获取真正的运行时文件而非这个？要么就是他们忘记重命名某些目录，比如“~/.local/share/Steam/ubuntu12_64”和ubuntu12_32

        find -iname ‘ *ubuntu12* ’

        ./.local/share/Steam/package/bins_codecs_ubuntu12.zip.vz.d90bc1494b8e64074dc29b184b2287dbc7ee7853_12581393 ./. local/share/Steam/package/webkit_ubuntu12.zip.vz.440105ef91ab79444bb3e3c66a4b8ecec34400fc_89751002 ./. local/share/Steam/package/steam_client_ubuntu12.manifest ./.local/share/Steam/package/bins_ubuntu12.zip.vz.6650885139d98627876a152227f8222d88f6314b _38804586 ./.local/share/Steam/package/runtime_scout_ubuntu12.zip.a6b9a46de150a1d0169900718228f708b3920955 ./. local/share/Steam/package/sdl3_ubuntu12.zip.vz.41ce9175cf38af9cd7178b742126ac1b20179821 _11412960 ./.local/share/Steam/package/runtime_steamrt_ubuntu12.zip.vz.8a18225d08af42c4d06d07b844bd71cc05f4a596_77023730 ./. local/share/Steam/package/miles_ubuntu12.zip.vz.5093ef941e6e5195a60ab3259077694dec994016 _295496 ./.local/share/Steam/package/steam_ubuntu12.zip.vz.5327d80304b67c5a628c1167804fd972930ec8d7_3311372 ./. local/share/Steam/package/bins_misc_ubuntu12.zip.vz.6170aa6d40572898c134fc0d24a9f2a1db2ff4c3_18843500 ./. local/share/Steam/package/bins_sdk_ubuntu12.zip.vz.10e660b142958ea4c61d4265f9d930e8d7034b18_22674445 ./. local/share/Steam/package/steam_client_ubuntu12.installed ./.local/share/Steam/ubuntu12_32 ./.local/share/Steam/ubuntu12_64

        回复

        1. 这是Steam运行时的首个版本。请查看~/.local/share/Steam/steamrt64目录。

          回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的：