氧化 Ubuntu：默认采用 Rust 实用工具
如果一切按计划进行，Ubuntu 项目很快就会用 Rust 编写的实现来取代许多传统的 GNU 工具，比如我们在二月份报道过的 uutils 项目创建的工具。作为 Linux 发行版核心的核心实用程序的全面替换并非小事
如果一切按计划进行，Ubuntu 项目很快就会用 Rust 编写的实现来取代许多传统的 GNU 工具，比如我们在二月份报道过的 uutils 项目创建的工具。作为 Linux 发行版核心的核心实用程序的全面替换并非小事，这也是 Canonical 工程副总裁乔恩-西格（Jon Seager）发布 oxidizr 的原因。这是一个命令行工具，可以帮助用户轻松启用或禁用基于 Rust 的实用程序，以测试它们的适用性。Seager 呼吁用户帮助进行测试，并在 Ubuntu 25.10（计划于 2025 年 10 月发布的临时版本）可能进行切换之前提供经验反馈。到目前为止，Ubuntu 社区的反应似乎是积极的，尽管对如此重大的改变略有怀疑。
Ubuntu的下一个20年
Ubuntu去年庆祝了自2024年首次发布以来的20周年。西格尔对这一里程碑进行了反思，并在今年二月发表了他对Ubuntu未来20年的展望。他对未来的主题之一是现代化，呼吁项目根据用户需求不断评估发行版的基础：
我们应该深入研究Ubuntu默认提供的工具，选择那些以弹性、性能和可维护性为核心的工具。在开源社区中，有数不清的例子表明，人们正在使用最近才出现的工具和实践对工具进行重新设计和想象。我个人最喜欢的例子包括 eza、bat 和 helix 等命令行工具，新的 ghostty 终端模拟器，以及更基础的项目，如用 Rust 重写 coreutils 的 uutils。这些项目的成熟度各不相同，但都展示了一种类似于 Unix 的更现代体验的愿景，即强调弹性、性能和可用性。
3月12日，Seager发表了一篇后续文章，介绍了他开始采用其中一些工具作为默认设置的计划–目的是在下一个Ubuntu长期支持（LTS）版本26.04中使用这些工具。转换的理由主要是 “使用 Rust 端口更容易增强弹性和安全性”。他引用了 Rust 核心开发者 Niko Matsakis 的一篇博文。简而言之，这篇文章讲述了 Matsakis 使用 Rust 编写（或重写）基础软件的愿景，即 “支撑其他一切的软件”。
那些一直关注有关使用 Rust 的持续辩论和讨论的人，会在 Matsakis 支持 Rust 的论点中找到熟悉的主题： Rust 既能提供 C/C++ 的性能，又不要求开发人员做到尽善尽美；它提供了可靠性，无论开发人员的经验水平如何，它都能提高开发人员的工作效率。它的可靠性使其特别适用于基础软件，因为 “当基础失效时，上面的一切也会失效”。鉴于 Ubuntu 被广泛采用，Seager 写道，”我们有必要绝对确定，我们正在开发的软件是最有弹性、最值得信赖的”。
Seager还认为，采用Rust将有助于实现他为Ubuntu设定的另一个目标，即增加贡献者的数量。这并不是因为 Rust 一定比 C 语言更容易使用，而是因为它提供了一个框架，让贡献者更难提交可能不安全的代码。
oxidizr
Rust实用程序对Ubuntu来说更好甚至可行的抽象可能性并不能取代实践经验。为此，Seager创建了oxidizr，以便在风险相对较低的情况下，快速更换（或移除）Rust实用程序，以取代传统的对应程序。他于 3 月 7 日发布了第一个版本 1.0.0。该版本在 Apache 2.0 许可下发布，正如人们所预料的那样，是用 Rust 编写的。
该项目尚未打包到 Ubuntu 上，Seager 也没有为用户设置个人软件包归档（PPA），以便他们使用 APT 安装 oxidizr。GitHub上有二进制版本，用户也可以使用cargo安装该工具：
$ cargo install --git https://github.com/jnsgruk/oxidizr
二进制版本可能是最容易上手的方法，因为oxidizr需要fs模块中的exists函数，但exists是在Rust 1.81.0（2024年9月发布）中添加的，而Ubuntu 24.10的Rust版本仍是1.80.1。我用 rustup 安装了最新的 Rust 稳定版，然后用 cargo 安装了 oxidizr。
oxidizr 工具会调用一组实用程序，这些实用程序可以独立替换为一个 “实验”。实验是 Rust 模块，定义要安装（或移除）的软件包，并处理实用程序的重命名，以启用或禁用 Rust 版本。当前的实验包括用 uutils coreutils、findutils 或 diffutils 替换 GNU coreutils、findutils 或 diffutils，以及用基于 Rust 的 sudo-rs 替换传统的 sudo。
例如，用户可以运行以下命令试用 sudo-rs
# oxidizr enable --experiments sudo-rs
这将从 Ubuntu 软件包库中安装 sudo-rs 软件包，备份 sudo 二进制文件，并创建一个以 Rust 二进制文件（/usr/lib/cargo/bin/sudo）为目标的 /usr/bin/sudo 符号链接。要启用所有实验，用户可以使用 all 目标来代替：
# oxidizr enable --experiments --all
最后，将系统还原为传统实用程序，并从系统中移除替换软件包：
# oxidizr disable --all根据 Seager 的说法，oxidizr 适用于 Ubuntu 24.04 LTS 之后的所有版本，但 uutils diffutils 实验只支持 Ubuntu 24.10 或更高版本。为了安全起见，他建议用户在虚拟机或其他非生产工作站或服务器上开始测试。Seager 报告说，他没有遇到太多问题，但遇到了一个不兼容问题：uutils 的 cp、mv 和 ls 替代程序还不支持 -Z 标志，该标志用于设置文件的 SELinux 上下文或（在 ls 的情况下）打印文件的安全上下文。
在我的简短测试中，uutils 版本的实用程序或 oxidizr 为替换它们而对系统进行的改动都没有给我带来任何问题。不过，我注意到 oxidizr 并没有对系统的 man 页面进行任何修改。即使 GNU 工具被替换为 uutils 版本，GNU 的 man 页仍然保留，因此 “man cp “仍然显示 GNU 版本。为了让用户了解 uutils 文档和实用程序本身的不足之处，最好也能更换 man 页。
反响
Fern Dziadulewicz问，转向uutils是否意味着 “Ubuntu实际上正在走向无GNU”，就像其他一些Linux发行版一样，避开GNU组件。Seager 回答说，人们不应该过多地解读这一变化：
这并不意味着要放弃 GNU 组件，而只是用更现代的组件替换 coreutils。
当然，许可证不同也是一个考虑因素，但这绝不是决策的驱动力。
约瑟夫-埃多西（Joseph Erdosy）对这一回应并不满意，他在信中写道，如果Ubuntu继续做出改变，他将迁移到Fedora或Rocky Linux。他说，他喜欢 Rust，也喜欢更好、内存更安全的替代方案，但最大的 “氧化 “项目是对 GPL 许可代码的 MIT 许可重写，这让他很不高兴。
这一决定似乎与更广泛的趋势一致，即公司通常以 “现代化 “为幌子，废弃 GPL 软件，转而使用许可更为宽松的替代品。然而，现实世界的影响是显而易见的：自由软件越来越多地被纳入专有生态系统，削弱了使 Linux 取得成功的原则。
其他几位用户很快表示同意 Erdosy 的观点，然后 Ian Weisser 宣布他将把这个话题转入 “慢速模式”，以 “在开发者有机会回应并保持这个话题的建设性之前，防止喧宾夺主”。不久之后，Seager回应说，他并不同意这一潜在举动会对Ubuntu或其社区构成威胁。他重申，这并不表明有政治目的或更广泛地放弃 GPL 软件，并表示 Canonical 自己的大部分软件现在和将来都是 GPL 的。
Ubuntu是一个软件集合，我们将其整合为一个发行版。它是一个致力于提供我们所能找到的最新、最好的开放源代码的项目。没有证据表明uutils的维护者有任何违法行为、不良行为或不良意图–他们是一个有思想、有奉献精神的社区，他们正在构建自己的软件，甚至在某些情况下还为GNU coreutils做出了贡献。我认为在未来几年里，Ubuntu应该实现我所期望的目标，而我也将继续致力于为Ubuntu提供一个成功的机会–我们和其他人将需要与他们紧密合作，以解决本地化、selinux支持和其他方面的问题。
如果目前的情况发生了变化，我们认为 uutils 项目的利益不再与 Ubuntu 的利益一致，我们可以改变我们选择与 Ubuntu 一起发布的 coreutils 软件包。
谢尔盖-戴维多夫（Sergey Davidoff）想知道为什么 Debian 的替代系统（用于在安装了多个具有相同功能的程序时指定默认应用程序）不能满足 Rust 实用程序的实验要求。朱利安-安德烈斯-克罗德（Julian Andres Klode）回答说，替代系统不合适，因为现有软件包需要合作。他还回应了另一位用户 “rain “提出的允许用户调换个别命令的想法。Klode 说，允许用户在每个命令层面上选择 Rust 和非 Rust 实现是个坏主意，因为这会导致系统难以支持。
Liam Proven询问了Ubuntu对x86_64和Arm以外架构（如s390和ppc64le）版本的支持情况，因为 “LLVM Rust工具链还有些不成熟，缺乏针对其他架构的代码生成”。Uutils 项目创始人兼 Ubuntu 开发人员 Sylvestre Ledru 询问 Proven 是否有任何错误报告需要分享，因为多年来火狐一直使用 LLVM Rust 工具链在这些架构上发布火狐。他指出，uutils 以这些架构为目标在 Debian 和 Ubuntu 上成功构建也有几年了。
下一步
Seager 说，他曾与 Ledru 讨论过让 uutils coreutils 在 Ubuntu 25.10 中成为默认设置的想法，Ledru 认为该项目已经准备好在这一级别上曝光。他说，现在只是具体细节的问题，Ubuntu Foundations团队已经在制定计划，以便在下一个版本周期中实现这一目标。他也承认需要谨慎行事，并坦言如果转换意味着影响Ubuntu LTS版本的稳定性或可靠性，他可能需要 “降低雄心壮志”。如果转换不成功，也很容易在明年的LTS版本中及时恢复。
迄今为止，Ubuntu 似乎是第一个认真考虑改用 uutils 的主要 Linux 发行版。如果 Ubuntu 25.10 能搭载 uutils coreutils，这对 uutils 项目来说将是一次重大胜利，因为它能接触到比以往更大的用户群。氧化 Ubuntu “实验有可能加速 Rust 的普及，并激励人们进一步尝试用 Rust 来取代基于 C 语言的实用工具，或者在 Ubuntu 遇到严重问题时产生寒蝉效应。无论如何，这个项目对整个社区都会有启发意义。
本文由 TecHug 分享，英文原文及文中图片来自 Oxidizing Ubuntu: adopting Rust utilities by default。
共有{224}条精彩评论
>当然，在 Rust 中，它们被认为是有问题的。>而在 Rust 中，泄漏很难被意外编码。> …
我从评论中很喜欢这个 gem 及其后代。相反，我经常看到的是，即使在大型 Rust 项目中，也很容易意外地定义出比你想要的寿命更长的东西。这其中有些是意外发生的（当语言根据静态检测释放未使用的东西时，没有意识到这里和那里的额外引用的影响）。更多的情况是因为编译器与有趣的数据结构作斗争–例如，将 vec 作为伪 RAM 进行分配，将索引作为伪指针使用，并且在容器本身未使用之前从不释放任何东西。
这些技术本身并没有什么问题，但如果你不是非常优秀、非常谨慎的话，这种语言往往会把你逼入绝境，所以在我见过的所有主要 Rust 项目中，即使不是由 BurntSushi 这样的人编写的，泄漏也是不争的事实，而同样的项目在 GC 语言中是不会出现泄漏的。
我认为无论你有哪些引用，Rust 都会在其词法 “范围 ”的末尾释放值。
例如，在下面的链接代码中，x 在第一行之后明显未被使用，但其 “Drop ”实现却在函数末尾的 print 语句之后执行。
这给我们的启示是，如果你想提前删除某个值，只需明确地 “删除 ”它。借用检查器将确保您没有任何悬挂引用。
https://play.rust-lang.org/?version=stable&mode=debug&editio…
一般来说，我认为 “生命周期 “只存在于借用检查器的上下文中，对 Rust 代码的语义没有影响。这种语言的设计初衷就是可以省略借用检查器，而所有代码的编译和运行都是一样的。
这是正确的。
不过，vec 模式也有一些优点，尤其是你通常可以使用 32 位索引（而不是 64 位指针），这使得它对缓存更友好一些。我使用这种模式是为了重码 AST，因为重码 AST 应该是哈希协整的，所以在整个匹配器[0]死掉之前，永远不需要死掉。
一个更复杂的例子是，解析器中的 Earley 项指向语法规则内部（所有规则都在平面向量中），并返回到先前的解析器状态，因此我有 2 个 u32 偏移量。如果我有指针，我可能会有一个指向语法规则的指针、语法规则内部的索引和指向先前状态[1]的指针，因此可能需要 3 倍的空间。
在这两种情况下，指针都更简单，但速度更慢。但令人讨厌的是，Rust 并不允许你做出选择……
[0] https://github.com/microsoft/derivre/blob/main/src/hashcons…. [1] https://github.com/guidance-ai/llguidance/blob/main/parser/s…
当然可以。这是我经常使用的一种模式，不仅仅是在 Rust 中（经常使用远小于 32 位的索引）。你提到了这一点和/或暗示了这一点，但我的核心抱怨是
1. 你在这个问题上没有太多选择
2. 在实施该策略时，默认情况下（快乐的路径编码），你对底层内存何时被回收几乎没有选择权
这种模式并不一定会泄漏，但尤其是当你在 Rust 中实施这种模式以规避借用检查器的限制时，我所见过的大多数版本都非常容易泄漏，甚至不支持收缩/大小/复位/……操作，以试图至少让用户手动更小心地处理泄漏。
当你想这样做时，也许应该使用类似 https://docs.rs/generational-arena/latest/generational_arena… 的东西。
我知道问题并不在于工具的存在，而是有些 Rust 用户并不了解这个概念及其多年来的演变，我认为这并不是 Rust 独有的问题。
>当语言根据静态检测释放未使用的东西时，没有认识到这里和那里的额外引用的影响
也许我理解错了，但借用检查器的意义不就是在引用 “超过 ”它所引用的内存时抛出错误吗？
额外的引用如何能延长生命周期？
Rust（大多数情况下，我现在根本不是在争论故障模式，我们就当它是完美的）会在你用完项目后丢弃它们。如果你使用项目的时间更长，你的隐式生命周期也会更长。它所引用的内存也会被占用更长的时间（引用不会超过其对应内存的寿命）。
要解决这个问题，只能在编写代码时明确考虑生命周期–添加具体的生命周期，让编译器在你犯错时告诉你（作为一种整体策略很难做到，所以没人这么做），或者直接 “git gud”（有些人这么做了，但这需要时间，而且不是常规做法；你可以在很高的水平上编写代码，却不需要开发这种特定的技能子集，其结果几乎是不可避免的，那就是 “泄漏的 “Rust代码，但在其他方面却相当不错）。
我不知道你是从哪里得到这个想法的，但这是错误的。
>你使用项目的时间越长，你的隐式生命周期就越长。它所引用的内存也会被占用更长的时间
这只在堆栈帧级别上是正确的，你不能将变量扩展到堆栈帧之外，在这种特殊情况下与 GC 没有区别（GC 永远不会删除堆栈上有变量指向的元素）
>你只有在编写代码时明确考虑生命周期，才能解决这个问题
生命周期参数不会改变行为，如果情况不明确，它们要么是强制性的，要么是完全多余的。而且它只在函数边界起作用，在那里生命周期扩展无论如何都不会发生。(见上文）
，请停止散布毫无根据的胡言乱语（Rust 和其他任何东西一样都存在实际缺陷，但散布无稽之谈是不行的）。
谁说过要扩展 “变量”？
如果你在堆中分配了某个对象并存储了对它的引用，那么 Rust 绝对会让该对象继续存活，直到所有引用都消失为止。这不是 “没有现实基础的废话”。
是的，这个特性是你在 GC 语言中会看到的（例如，如果你试图使用内置的 DI 从长寿命对象创建短寿命对象，那么 C# 中的 Entity Framework 就会出现泄漏，因为 EF 存在一个错误，它会将这些对象的强引用与外部对象的寿命挂钩）。据我观察，在 Rust 中，人们往往比在 GC 语言中更倾向于这样做，因为编译器让其他编码模式变得更加困难。
Rust 在引用消失之前不会让变量存活。它会检查以确保任何引用的寿命与其引用对象的寿命一样长或一样短。如果引用的寿命比引用对象的寿命长，那就是编译错误。
你能分享一个 rust playground 链接，并举例说明你所描述的内容吗？
我还是不明白引用是如何延长某些内存的寿命的，即使是在堆上。
听起来你描述的是一种使用引用计数来管理内存的语言，我不确定借用检查器在引用计数语言中有什么作用。
> 谁说过要扩展 “变量”？
> 如果你堆分配了某个对象并存储了对它的引用，那么 Rust 绝对会让这个对象继续存活，直到所有引用都消失为止。
不会的。
这说明你根本不了解 Rust 是如何工作的。GC 可以做到这一点，但借用检查器不会，它做不到，它能做的就是对你大喊大叫，让你的变量活得越久越好。
请看这个 playground，看看当你在堆上分配一个东西并试图返回对它的引用时会发生什么： https://play.rust-lang.org/?version=stable&mode=debug&editio…
如果你能停止对一门连基础知识都不懂的语言胡说八道，那对大家都好。
>当你用完项目时就会丢弃它们。
这就是 GC 语言的作用。太
如果粗心大意，任何语言都可能出现严重的资源泄露
Rust 所保证的是，你不能反引用一个空指针
当然，但这不是 Rust 的重点。许多有 GC 的语言也保证没有东西可以为空。
为什么没有人用一种能被 GraalVM 编译成本地二进制文件的语言重写这些工具，并享受 Java 的所有安全保障？会不会太慢了？难道这样做的好处还不够多吗？
既然可以使用 .NET，为什么还要使用 Java？或者 Go？.NET 的性能似乎与 Java 相当，而且似乎生成的可执行文件更小，而 Go 总体上似乎更快。
就我个人而言，我并不关心常用工具是用什么语言编写的（用 C(++) 编写的程序除外，但我很乐意在这些程序经过几年的使用后再使用它们，因为它们可以捕捉到大部分不可避免的内存错误）。
我认为不同之处在于，并没有多少语言的项目最终会编写全套的替换程序。简单的二进制文件中隐藏着许多意想不到的复杂性，需要以兼容的方式来实现，这样脚本才不会爆炸，而这是相当繁琐的工作。据我所知，Rust 和 Zig 中的一些项目打算完全兼容，但我不知道 Java+GraalVM 或 Go 中是否有这样的项目。不过，在 Zig 语言进入 1.0 之前，我不会选择 Zig 作为发行版。
如果这些项目确实存在，也许有人可以将它们放在兼容性和性能矩阵中进行比较，找出哪个发行版最快、最小，但我怀疑 Rust 可能最终会在这两个方面都胜出。
能用 Rust，为什么还要用 Java？说实在的，对于这类通常没有复杂生命周期或所有权语义的工具来说，使用 Rust 是一件乐事。
此外，您还能获得更好的性能，二进制文件也可能更小。但对于 CLI 工具，我还是会选择 Rust，而不是 Java，这只是基于语言本身的优势。
你也可以用现有的 C 语言做类似的事情，将其编译成 WASM，然后再编译成机器码。
Rust 是潮流，Oracle 则相反。
当然，这并不是什么细致入微或聪明的观点，但肯定是事实的一部分
除了成熟度之外，它在我能想到的几乎所有方面都更好。
因为它根本不是一个很好的平台。
内存泄露在 Java 中很容易被意外编码，所以在 Rust 中肯定更糟糕。
声称的是 “安全”，而不是相当于 GC 或内存最小。你说得对，所有东西都有取舍，借用检查器也不例外。
主张是 “泄漏很难被意外编码”。我同意 gp 的观点，这是错误的。
防止泄漏显然不是 rust 的目标，而且要使生命周期正确，往往需要放弃并创建不必要的静态生命周期。我经常在异步 rpc 流中看到这种情况。
我认为在非异步 Rust 中，泄漏确实更难被意外编码，这也是 Rust 最初的开发环境。我不敢说绝对困难（这确实取决于架构的复杂性），但这种说法似乎有些道理。
虽然泄密在 Rust 中的难度不亚于 GC。
也就是说，泄漏并不是不可能发生的，你最终还是会在工作中遇到一个令人讨厌的泄漏，但总比没有 GC 或 borrowck 要好得多。
我不认为这是对的–在 Rust 中，Rc 或 Arc 的循环会泄漏。在 GC 语言中，循环会被正确删除。
在 Rust 中，使用引用计数指针的循环是造成泄漏的原因，这也是 Rust 所特有的，但 GC 也有自己的泄漏源，根据我的经验，它们的发生频率与 Rust 中的循环大致相同（虽然很少，但也不是特别频繁）
当一个类型是 “静态 ”的时候，并不意味着它在程序的生命周期内都是泄漏的。它只是意味着它拥有自己所需的一切，不会借用任何东西。当它被释放时，它仍然会释放它所拥有的一切。
https://doc.rust-lang.org/rust-by-example/scope/lifetime/sta… 说：
> 作为引用的生命周期 “static ”表示引用所指向的数据在运行程序的剩余生命周期内有效。
你的链接中关于“&’static T”（引用的生命周期）的说法是正确的。GP 所说的`T: ‘static`是正确的，它是一个类型约束。它们都使用了 “关键字”‘static，但意义不同。
是的，在我看来，这是 Rust 最大的设计缺陷之一。T：“unbounded ”会好得多。
`’unbounded`不是一个坏主意。在我的团队中，当有人刚接触 Rust 就遇到静态类型约束时，我通常会告诉他们一句过于简化的 “is not a reference（不是引用）”，然后说 “The data does not have any constraints (or bounds) on its lifetime that this code needs to worry about”。
我不知道刚接触 Rust 的人是否能立即理解 “unbounded”，但它捕捉到了 “T: ‘static ”是一个否定断言。也就是说，它在很大程度上说明了它不可能是什么。
除非你正在写的东西不能有停顿，哪怕是微小的 µs，否则我看不出有什么理由急于使用仿射类型系统或其变体。
CLI 应用程序就是一个例子，在这种情况下，停顿根本不重要，参见 Inferno 和 Limbo。
我真的不明白为什么这条评论会被置顶，因为它几乎完全是胡说八道，作者混淆了借用检查器的行为和 GC 的行为（讽刺的是，作者声称 GC 可以解决这个问题，而事实上这个问题在 GC 的世界之外并不存在）
借用检查器和 GC 的作用并没有混淆。借用检查器通过向有效程序集添加约束来加强安全性，这样它就能静态地知道在哪里分配/卸载内存，还有其他好处。而 GC 则是动态地找出需要丢弃的内存。我的观点是，Rust 的这些约束迫使你以不同于其他方式的方式编写代码（因为不安全是不受欢迎的，这看起来就像经常使用 vecs 作为一个选项的手卷指针），这有时是好的，但对于更有趣的数据结构，它鼓励人们编写泄漏，而如果没有这些约束，编写相同的程序是不会存在泄漏的，因此在 GC 语言中也不会存在泄漏。
当东西被丢弃时，借用检查器不会改变。
>借用检查器和 GC 所做的事情并没有混淆
有的，在 Rust 中，你不能通过保留对对象的引用来延长对象的生命周期，而这正是 GC 会发生（并导致泄漏）的事情。
>这看起来就像经常使用 vecs 作为一种选择的手卷指针
强调是我的。我不知道你怎么会认为这是经常发生的事情，但这确实是一个可以用来管理循环引用数据的选项，也确实被很多做这类事情的代码板使用，但在实践中你永远不会用到它。
(我是以一个在各种可能的环境中编写 Rust 十年的人的身份这么说的，从嵌入式到前端网络，我还在大学教授 Rust）。
>将一个vec作为伪RAM分配，将索引作为伪指针使用，并且在容器本身未使用之前永远不释放任何东西的模式
你是在说手卷arena分配吗？我看不出 GC 语言会有什么不同的行为，只要你也使用竞技场分配并保持一个可达引用。
>这些技术本身并没有什么问题，但如果你不是非常优秀和非常小心的话，这种语言往往会把你逼入一个死角，所以在我所见过的所有主要 Rust 项目中，只要不是由 BurntSushi 这样的人编写的，泄漏都是一个不争的事实
如果我随机抽取 3 个主要 Rust 项目，如 Serde、Hyper 和 Tracing，其中没有一个是由 BurntSushi 编写的，你的说法是它们都存在内存泄漏问题？
当你把别人捧上天的时候，他们肯定会让你失望。:-) https://github.com/BurntSushi/aho-corasick/commit/474393be8d…
如果这种类型的泄漏比人们想象的更普遍，我也不会感到惊讶。这是非常微妙的。但据我所知，在我维护的箱子中，该链接是唯一一个出现如此程度泄漏的实例。也许还有其他情况。这就是为什么我在可能的情况下尽量使用 “Box<[T]>”，因为你知道它不可能有额外的容量。
我认为 GP 的总体论点似是而非。他们缺乏具体的例子。
很好奇你为什么说这是内存泄漏？内存仍在 Vec 中，并且会在取消分配时正确释放，不是吗？在我看来，这是在优化内存使用，而不是在堵漏。
如何定义泄漏？
如果你坐下来认真思考一下，我想你会发现泄漏的准确定义其实有点困难。
我不是第一个提出这个观点的人。
我指出这一点是为了避免出现一个长篇大论，让我们争论 “泄密 “一词的含义。你完全可以给 “泄密 “下一个定义，说我的例子不是泄密。但我更倾向于 “泄密 “确实包括我的例子的定义。
我不想对这个定义进行争论。如果你想把我的例子重塑为 “空间 “泄露，而不是 “内存 “泄露，我也不反对，而且我不认为这会改变我的例子的相关性。(尤其是，我不认为 “内存泄漏 “在这个主题中是以一种非常精确的方式使用的。
如果不使用不同的数据结构，我不知道你如何摆脱这个问题。我想说的是，如果使用一种有 GC 的语言，就可以避免某些泄漏（”泄漏”？据我所知，不管有没有 GC，大多数现代语言的 Vec 对应程序都会做同样的事情。
我是在回应这个问题：
>所以在我见过的基本上所有主要的 Rust 项目中，泄漏都是一个不争的事实，而不是由像 BurntSushi
这样的人写的。是的，我说过我认为他们的整体论点似是而非。
>这并不意味着要放弃 GNU 组件，而只是用更现代的同类产品替换 coreutils。当然，许可证不同，这也是一个考虑因素，但绝不是决策的驱动因素。
对不起，我一点也不相信。我非常感谢 Canonical/Ubuntu 在 20 年前所做的一切，但还是不谢了。我是一个热爱 Rust 和它所带来的一切的人。不过，自由太重要了，不能不把任何看似对自由的攻击当作自由。
Ubuntu很久以前就迷失了方向。默认推送 Snap、Unity Dash 搜索中的广告、终端中的广告…… Unity本身就是个错误，也是我觉得这个发行版开始走下坡路的时候。
现在我不怎么关注它了，但 Canonical 已经没有什么能让我感到惊讶了。他们就像其他公司一样榨取自由软件的利润。
关于Ubuntu默认包含ZFS模块的争论到底发生了什么？在最初提出这个建议的时候，我记得除了Canonical之外，基本上所有人都认为Linux和ZFS的许可证都不允许这么做，但他们还是这么做了，而且据我所知，他们基本上都逃过了这一劫。
除非我记错了，否则我一点也不奇怪他们会在此之后不再担心许可问题；也许这就是 “大而不能倒 “的软件许可等同于 “大而不能倒”？
>关于Ubuntu默认包含ZFS模块的争论到底发生了什么？在最初提出这个建议的时候，我记得除了 Canonical 之外，基本上每个人都认为 Linux 和 ZFS 的许可证不允许这样做
，我觉得你的回忆有很大的偏差，或者你只是从一个特定的泡沫中读到了一些东西。在我的记忆中，有一些非常有说服力的论据与此相反，而且我也同意这些论据。比如，民事法庭案件的基本概念是 “诉讼资格”，而诉讼资格几乎无一例外地归结为遭受损害的一方。法院不是解决抽象哲学争论的场所（至少在美国是这样），那是公民社会的职责所在，法院是运用国家对暴力的普遍垄断来纠正伤害。甲方声称他们受到了乙方（法定的、实际的或两者皆有）违反法律的损害。但如果开放源代码许可 GPL 代码与开放源代码许可 CDDL 代码一起发布，而且两者的源代码都可以完全访问，那么谁会因此损失金钱？谁受到了损害？损失的是什么权利？谁有资格对此提起诉讼？无论如何，“禁用 ”这一观点在法律上都没有得到验证，但更根本的是，如果没有造成损害，就根本不存在任何诉讼案件。假设你明天决定对 Ubuntu 中包含 ZFS 感到非常生气，并决定在周一提起诉讼，当法庭问 “这让你损失了多少钱，你想让我们怎么做 “时，你会怎么回答，即使撇开 “你的法律理论是什么 “不谈。
>据我所知，他们基本上逃脱了惩罚？
如果根本就没有什么案件，这也是意料之中的事，对吗？
你的解释似乎与（我所理解的）作为合同法一部分的知识产权许可的运作方式不符。如果我通过 torrent 传播受版权保护的音乐，RIAA 不会浪费时间去调查接收者是否打算以其他方式购买 CD。如果你收到的软件许可证对你来说限制太多，那么你总是可以选择付钱给权利人，让他给你一个更宽松的许可证，以换取金钱。
(我并不赞成这种制度，我只是在描述我所看到的现状）。
>（我不赞成这种制度，我只是在描述我所看到的现状）。
正如有人所说，作为自由和开放源码软件的 “拥护者”，你可能会在任何版权问题上站在许多方面。
>RIAA不会浪费时间去调查接收者是否打算购买 CD。如果你收到的软件许可证对你来说限制太多，那么你总是可以选择付钱给权利人，让他给你一个更宽松的许可证，以换取金钱。
你的比较没有理解这些说法的不同之处。首先，这些 CD 的包装盒上都标有价格。也就是说，这种索赔会有 “实际损失”，而这是很容易确定的。其次，你推测 Linux 或 OpenZFS 有可能获得新的许可证，但我认为，考虑到权利人的数量，没有人会认为这两种许可证是现成的。如果甲骨文提出以已知的合理价格 X 美元重新授权（BTW 仅授权其 ZFS 源代码部分），就像你的 CD 光盘一样，那么你的比较可能更有意义（但请继续阅读，提供另一种授权并不排除非侵权的认定）。
当然，值得庆幸的是，在无法轻易证明实际损失的情况下，版权法规定了法定损害赔偿，就像这里一样。但这些名义/法定损害赔偿在 Linux 权利人之间的分配几乎是微不足道的，因此上面这位发帖人的观点很可能是正确的–这可能不是一种法律上可确认的损害。
虽然我同意这位网友的损害分析，但我甚至不确定这就是 ZFS 论点的最佳形式。在我看来，任何人只要创建了功能性软件接口，无论是通过游戏机的手推车还是内核模块，合理使用都允许创建软件并使用该接口。就这样。你的许可证可以随心所欲。你的许可证可以说 “你的所有软件现在都归我使用”，但在我看来，这是完全无法执行的。在我看来，法院多年来一直支持软件的互操作性和合理使用。
例如
在世嘉企业有限公司诉 Accolade 公司案中，法院拒绝为 “与 Genesis 游戏机兼容的功能要求...... ”提供版权保护。根据这种方法，内核模块作者创建兼容模块的权利高于该作者创建内核代码的静态或动态链接时产生的任何名义上的版权侵权。世嘉的 “创世纪 ”控制台没有任何公开的 API，无论是否稳定，但法院仍然拒绝保护这些功能元素。无论兼容性所需的 API 或系统接口的状况如何，开发者为了创建一个与 Linux 兼容的内核模块而必须复制的程序的任何部分--如内核头文件、定义文件、变量或强制性 Linux 内核函数调用--都不会受到版权保护。[0]
与 ZFS 有关的案件要强得多，因为在世嘉案中，法院明确保护反向工程，而在本案中，Linux 内核开发者已经公布了他们接口的代码。
请注意，世嘉甚至向 Accolade 提供了一份许可（正如我们在上文讨论的替代许可的可能性），允许 Accolade 制作世嘉兼容游戏。尽管有此提议，法院仍拒绝认定 Accolade 在未获得许可的情况下制作世嘉兼容游戏的行为侵犯了版权。
[0]: https://www.networkworld.com/article/836041/smb-encouraging-…
> 如前所述，作为自由和开放源码软件的 “拥护者”，你可能会在任何版权问题上站在许多方面。
>你的比较没有理解这些主张的不同之处。
比较什么都不明白。我的意思是让大家注意到两种不同事物的共同点。
>我不认为有人会因为权利人的数量而认为这两种事物都是现成的
我也不认为，但我认为这并不相关。为什么？
最后，你提出了一个关于接口的论点，但我认为这里的问题是 CDDL 许可代码的使用，而不是接口的（再）实现。在我看来，世嘉诉 Accolade 案的结论与本案无关。
>我的意思是提请注意两件不同事情的共同点。
是的，我明白你的意思是通过类比进行推理，而且我也告诉过你，我认为你的类比是有缺陷的。当你用类比推理时，也许你应该做好别人说 “这个类比在这种情况下没有意义 “的准备。主要是因为 — 你的类比在这种情况下没有意义。一个是实际损害赔偿案件，另一个是法定损害赔偿案件。当我们严格讨论损害赔偿时，你的比较是苹果和橘子的比较。
你说：
>>>>如果你收到的软件的许可证对你来说限制太多，那么你总是可以选择付钱给权利人（原文如此），让他给你一个更宽松的许可证
你说 “你总是可以选择付钱给权利人（原文如此），让他给你一个更宽松的许可证”，而我却说在这种情况下这是不可能的？对被许可人来说，没有一站式服务。没有 50 站式服务。
在你的设想中，我们可以想象存在不相容的情况，你也可以想象一个理论上的替代许可证会与法院有关。而我要说的是，同样相关的是，实际上不可能获得所有 ZFS 许可证持有者或所有 Linux 许可证持有者的同意。
我们通过共同使用自由和开放源码软件，创造了有效的永久许可软件。而现在，我们可以想象有一方会说–实际上，这两个作品将永远不兼容。你认为法院不会认为这很荒唐吗？
更重要的是，整个论证过程就像针尖上的天使。GPL 和 CDDL 是 Canonical 已经选择的许可证，因为 Canonical 并没有像你一样，在 CDDL-GPL 组合中解读出不兼容。>我认为这里的问题是 CDDL 许可代码的使用问题
正如讨论的那样，我认为代码的许可方式并不重要。如果这样说更容易理解的话，可以把 CDDL 授权的代码想象成一个封闭源代码的专有文件系统。因此，Linux 提供了一个模块接口，但它可以是任何接口。就像世嘉公司一样，在我看来，即使是专有代码也可以使用提供接口的 GPL 许可代码，以实现互操作性。为什么？因为 “合理使用”。
我不同意你所说的任何内容。谢谢你的论证。
>据我所知，他们基本上逃脱了惩罚？
还是他们正确地解释了法律？
我们中很少有人愿意承认这种 “法律共识 “大多是胡说八道。相反的证据很多，但就像现在的政治一样，这确实是一个吸引人的幻想。
我并不自诩对此事有任何法律专业知识。我所知道的只是，我记得我读过一些东西，让我觉得大家一致认为许可证不允许这样做，而且他们这样做了，我却没有注意到任何后果。也许这是废话，但我认为也可以说，软件中有相当多的许可条款尚未通过法院的先例完全确立，相反，大多数最终都是出于风险规避而不是任何人完全100%确定法院将如何裁决（这不是人们在任何给定问题上都能预测到的，而不是特定于软件许可证的东西）。
如果大家的共识是 “BS”，那么我认为这并不影响我想表达的更重要的观点；我可能在最后过于热衷于文字游戏而分散了注意力，但我的本意是想表达 Canonical 可能只是有意决定他们并不关心人们在这里讨论的有关 coreutils 的许可问题。如果我的理论是正确的，那么是出于合理的法律判断还是故意不遵守，我并没有什么深刻的见解；我主要是认为值得提出的是，这里的人们对此的看法可能并不那么重要，因为在我看来，他们不可能被说服改变计划，也不可能因为继续执行他们的决定而遭受重大的负面影响，不管它是对是错。
当 Ubuntu 不再是棕色的时候，它就不再是 Ubuntu 了。
我今天才意识到这一点。当我试图用 “do-release-upgrade ”来升级一台已停用的 Ubuntu 机器时，它完全瘫痪了。现在我正在寻找一个支持 GPU、滚动发布、没有 systemd 的替代发行版。也许是 OpenSUSE？
如果有任何 SV 亿万富翁，请资助 OpenBSD 上的 CUDA：-P
你可以运行 Trisquel Mate，但需要自行设置专用内核和 CUDA。你可以使用 Xanmod 内核、头文件和道具 NV 安装程序，但在 freedoom 上的自由度会降低。使用英特尔和 OpenCL（或英特尔目前使用的任何技术），你可能会损失性能，但你会获得兼容性，而且不会受制于英特尔 X86，以防你想进一步尝试基于 Power9 的工作站。
我不知道它是否支持良好的 GPU，也不是滚动发布版本，但 Devuan 是不含 systemd 的 Debian 衍生版本，你可能会感兴趣
没有 systemd 确实限制了选择（包括 OpenSUSE 使用它，所以我不确定如何理解你的评论）。也许是 Artix Linux？那是滚动发布的无 systemd 版本，不过我不了解图形驱动程序。我本来想推荐 Pop！_OS，它的名字很难听，但基本上就像 Ubuntu，没有不好的东西，而且图形驱动也很好，但它有 systemd，而且没有滚动发布，所以你自己看着办吧。
哎呀，我的理解是，使用 OpenSUSE 可以选择不使用 systemd，不会有太大问题。
我使用 Nonguix 和 RTX2080，对此非常满意。与 Nix 类似，它也非常出色，但并不适合胆小的人。
你为什么不相信呢？
从我的角度来看，这似乎是可信的。谁会关心授权问题？
但我对你得出相反结论的原因很感兴趣。
>谁会关心许可证问题。
首先，基于 Rust 的实用工具的作者已经关心到足以改变它（或者说不再重新采用 GPL，但在我看来这是一样的）。我们为什么不能关心许可问题呢？
是的，我是在说笑。（或者只是过于轻视了）
，我知道人们确实关心许可问题，但这也有可能不是任何特定项目最关注的问题。
哪些自由受到了侵犯？
GPL 确保软件永远免费。而 “许可 “则不然。许可证允许任何人创建不免费的衍生版本。没有源代码，就会受到版权保护。
如果说人们需要明白一件事的话，那就是企业总是竭力索取尽可能多的东西，回馈尽可能少的东西。在过去的几个世纪里，每家公司都是这么做的，如果认为他们不会再这么做，那就太天真了。得寸进尺，他们就会得寸进尺。你不会真以为像微软和甲骨文这样的公司，还没对社区用许可协议重写 GNU/Linux 垂涎三尺吧？
这并不是说这种特殊情况是 “自由受到攻击”。而是自由不断受到无情的攻击，我们一刻也不能放松警惕。GPL 是我们的保护伞，主动放弃 GPL 无异于自杀。
你是说不久前在 mit 协议下发布.Net 专有代码的微软？即使在大型企业中，也不全是这样。Windows 现在也搭载了 wsl–他们现在能从非gnu Linux 中获得什么？
他们之所以做这两件事，是因为这是他们竞争的唯一途径。你真的认为，如果开发者不是成群结队地离开他们的平台，他们会开放这些东西的源代码吗？WSL 只是他们利用 Foss 来弥补自己的不足。
.NET 案例主要是重写，许多组件都是从头开始重写（迟早的事）。Roslyn 是对编译器的重写，目的是让 C# 自托管，据我所知，从一开始就打算让它成为开放源码软件。.NET（当时的 Core）是从 RyuJIT 开始的。据我所知，RyuJIT 也主要只适用于 .NET，而 .NET Framework 使用的是较早的、不同的编译器代码库。
没错，为了不给 Novell/Mono 带来麻烦，我们还提供了额外的许可保证–这一直都得到了积极的对待。
还记得 Red Hat 试图将源代码锁定给用户吗？我认为他们宁愿完全不提供源代码，但由于 GPL 代码的庞大基数与所有内容纠缠在一起，这一点并不现实。
我想我们真的会怀念在强大的版权保护下提供系统基本部分的日子，而且很难再回到过去了。
红帽可能是世界上最大的 GPL 软件提供商。他们始终如一地选择 GPL 来编写和发布软件。他们自己创建并资助 Fedora 项目，就是为了成为一个独立于其商业努力的社区驱动发行版。他们为自己的产品提供完整的源代码，即使很大一部分代码是 MIT、BSD 或 Apache 代码，也不要求他们这样做。尽管 GPL 并不要求他们这样做，但他们还是提供了生产 “合计 “完整产品所需的一切。
我现在就公开预测，如果 uutils 流行起来，Red Hat 将是最后一批脱离 GNU 的公司之一。他们可能是 glibc 和 GCC 的最大贡献者。
你有什么证据证明他们 “宁愿不提供源代码”？因为他们有大量证据证明并非如此。
作为个人用户，红帽会向你提供他们旗舰产品的免费许可证。然后，他们会告诉你如何下载每一行代码。我没有许可证。我不使用红帽（除了偶尔使用也是完全免费的 RHEL9 容器）。
“还记得红帽曾试图将源代码锁定给订阅者吗？
我不记得他们改变过你所说的政策。如果你认为他们这么做了，那就说明当时的反应有多夸张。红帽公司的改变带来的最大影响是，Alma Linux 现在是一个更好的项目，可以真正进行创新和做出贡献。
有两件事让我印象深刻。
红帽公司在提供内核源代码时，只遵守法律条文，不遵守法律精神，从而阻碍了甲骨文 Linux 的发展。我们（Ksplice）会以一个巨大的补丁文件的形式获得从 Redhat 版本到其他版本的改动，所有改动都混在一起。他们内部的内核开发人员根本不可能这样工作，但源代码就在那里，所以 GPL 的字面意思已经得到了满足。
他们做的另一件事是关闭源代码库。首先，你必须是订阅者才能获得二进制文件，因此根据 GPL，你可以获得源代码。但是，如果你与其他人共享源代码，被他们发现，他们就不会让你在第二年续签许可证，所以你就无法获得更新的版本、二进制文件或源代码。这在技术上并不违反 GPL 的规定，但很难让人认为这符合 GPL 的精神。
很难把 Redhat 看成是一个仁慈的 GPL 开放源代码供应商，在现实世界中却有这样的商业行为。我并不是说这是他们的错，这只是商业行为。
Oracle Linux – 这就是他们吹嘘的无漏洞版本？
无法破解的内核。
你为红帽辩护，但现在是蓝帽了。他们可能还没有毁掉自己的传统，但我们正在警惕。
IBM 是世界上最大的开源贡献者之一。你们到底在关注什么？
你错过这个了吗？
https://arstechnica.com/information-technology/2023/06/red-h…
请再次注意，不要将过去的 RH 行动归因于 IBM。是的，IBM 在上世纪 90 年代及后来的发展中提供了很多帮助，但你不能完全相信一家公司的下一份财务报表，当然也不能完全相信公司领导层的三番五次更迭。
我是否错过了红帽公司应用其软件的许可证以及许可证赋予他们的权利？不，我没有，我支持它。GPL 与商业和有利可图的商业模式完全兼容，这个例子恰恰说明了这一点。你更希望开源软件公司血本无归，被他人利用？我不喜欢。我希望看到一个健康的开源生态系统，在维护用户自由的同时兼顾盈利。GPL 完美地体现了这一理想。
上面的 Fragmede 详细描述了我们与 IBM 保持健康距离的原因。
uutils 中的所有内容都遵循 MIT 许可。你唯一忽略的是 GPL 的 “病毒 “特性。在 BSD 的世界里，似乎没有人会因为 `chown` 和 `mkdir` 未发布的分叉而感到特别痛苦。
你所说的 BSD 世界到底是什么？一个被企业开采多年却从未回报任何东西（除了苹果股东的价值）的世界。与之相比，Linux 被企业采用，并在法律上被强制回馈。哪个进步更大？
> never gave back anything
你是说除了 Clang/LLVM 和 WebKit 之外？
好吧，平心而论，KHTML 的 LGPL 许可证是 WebKit 源码可用的一个重要原因（长期以来，它只是不情愿的压缩包转储），但我不认为 LLVM 是这种情况。
我并不认为 GPL 真的意味着企业对 Linux 的重大回馈。仍然有很多封闭源代码的驱动程序。回馈的主要动机是维护树外修改（如 Android 的粘合剂）的成本极高。
LLVM 已经催生了大概一打供应商提供的工具链，而这些工具链的源代码你永远都看不到。如果你能找出程序无法正确编译的原因，或者为所提供的工具/语言之外的东西添加支持，那就祝你好运了。
在开源方面，LLVM 的编译器和工具链确实走错了方向。
是的，苹果的 clang 奇怪的版本控制也导致了各种各样的问题
>好吧，平心而论，KHTML 的 LGPL 许可证是 WebKit 源码可用的一个重要原因（长期以来，它只是不情愿的 tarball dump），但我认为 LLVM 并非如此。
https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00…
是的，如果每个人都使用 BSD 而不是 Linux 作为服务器，那么甲骨文就不会以高价向你出售 Oracle BSD。当然，甲骨文和红帽公司已经在用自己的方式绕过 GPL 来做这件事了，但更宽松的许可证只会让他们做得更多。
在甲骨文或其他公司销售高级操作系统并取消互惠许可的所有构成价值广告的东西中，核心实用程序并不在其中。大多数工具都已经有了许可版本。如果人们想拥护 GPL 等等，那么这并不是一座可以让人去死的小山，它甚至算不上是一座小山。这只是一座蝼蚁之丘。这并不是说我低估了这些实用工具的价值，但它们并不是人们愿意花高价购买的东西。
你不需要想象。苹果公司的 macOS 采用的是 BSD 用户空间。天并没有塌下来。
如果 Linux 和 macOS 一样，没人会用它。他们会使用 macOS，这对苹果公司大有裨益。
相比 Linux，我已经更喜欢 MacOS 作为我的桌面，这对苹果公司大有裨益
我真的不明白你的意思。
也没有什么能阻止甲骨文公司以优惠的订阅价格向我们出售 Oracle Linux。GPL 并不是为了阻止软件的商业化。
红帽公司（Red Hat）始终如一地支持 GPL 和开放源代码，并比其他公司投入更多资金。
他们把企业操作系统的下载放在登录屏幕后面（学生和个人开发者许可证仍然可以免费获得），这一点我完全理解，也有点同情。
我知道这不符合某些人对自由软件的定义，但我一直对人们免费再分发红帽子公司作品的方式有道德问题。合法并不代表道德。
这不是 Canonical 可以做的事，仅仅因为该软件使用的是许可协议而不是版权许可协议。如果他们拥有版权，他们就可以这么做（我无法想象他们会这么做），但如果他们拥有版权，他们就可以做任何他们想做的事，没人有发言权。因此，这同样与许可证无关。
Canonical 所能做的，绝对只是开始制作一个不发布源代码的软件分叉。但在这种情况下，原始代码仍然存在。任何时候都不会失去自由。
原始代码并不重要。重要的是你正在运行的二进制文件的代码。这才是关键所在，而且这种特定的保证会产生深远的影响，即使你显然无法想象。
戴维-奇斯诺（David Chisnall）访谈的最后两段确实让我对此有了不同的看法：https://lobste.rs/s/ttr8op/lobsters_interview_with_david_chi…
特别是：
>我认为 GPL 导致了世界上专有软件数量的显著增加，因为那些乐意采用 BSDL 组件的公司决定创建内部专有版本，而不是采用 GPL 组件。
这也与我的经历不谋而合：我所在的公司找不到一个不属于 GPL 的 LZO 压缩库，因此只能决定是在公司内部实施一个还是砍掉这个功能。我们最终将该功能的使用限制在内部使用，但开放我们的核心源代码绝不是一个选项。
如果有许可选项，我们很可能会捐赠（就像我们捐赠其他几个依赖项一样），并将任何修复贡献回去（因为这比 “这是我们的补丁版本 ”更容易向客户解释）。
我非常同意这一点，但还要更进一步：
很多人担心 BSD 许可组件会导致所有大型专有软件将一切都锁死。但如果你真正使用过大型软件，你就会发现维护自己的分叉其实很费事，于是你就会开始推动更多东西向上游发展。因为毕竟，如果你的代码是私有的，那么如果有人破坏了它，你的任务就是修复它，但如果它是上游的，那么他们的任务就是修复它。
一个有趣的数据点是 LLVM/Clang，很多公司都有自己的 Clang 专有分叉。但在大多数情况下，这些公司仍在上游开发大量的东西：该项目的大多数最大贡献者都是拥有专有分叉的人。此外，据我所知，基本上所有依赖 EDG 的人都已经或正在努力从 EDG 迁移到 Clang。也就是说，如果 EDG 死了，那么拥有许可的 Clang 在消灭专有编译器方面所做的贡献将超过拥有版权许可的 GCC。
抵御专有软件的最好办法就是让专有软件的竞争成本太高，而使用许可授权意味着你可以欺骗专有软件公司来帮助你做到这一点。
>一个有趣的数据点是 LLVM/Clang
这也是 GPL 无法阻止企业构建（并以更宽容的许可证发布）非 GPL 软件的一个例子。
在苹果公司构建 Clang 之前，他们制作了一个 GCC 插件[0]，将 AST 从 GCC 前端转入 LLVM 后端。当然，他们在 GPL 下发布了 GCC 修改的源代码，但这与完全新颖的后端相比，简直是小巫见大巫。
与此同时，Stallman 多年来[1] 拒绝公开 GCC 的 AST，以防止类似事件发生，从而给 Emacs 等 GNU 项目造成了束缚。
[0]https://dragonegg.llvm.org
[1]https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00…
> 在苹果公司构建 Clang 之前，他们制作了一个 GCC 插件[0]，将 AST 从 GCC 前端转出，然后输入 LLVM 后端。
但他们没有！Dragonegg 是一个 GCC 插件，而当 Clang 的开发工作开始时，GCC 插件还不存在–GCC 插件可以追溯到 2010 年发布的 GCC 4.5，也就是 Clang 成为自托管程序的那一年。
时间轴是这样的： LLVM 最初依赖于名为 llvm-gcc 的 gcc 4.2 hacked-up 版本从源代码中创建 LLVM IR。当 GCC 增加了对插件的支持后，人们试图将前端转移到一个更可靠的框架上，这就是 Dragonegg。据我所知，苹果公司从未对 Dragonegg 项目本身做出贡献。Dragonegg 并没有持续太久；到 2014 年，该项目已经彻底死亡。>与此同时，Stallman为了防止类似事件发生，多年来一直拒绝公开 GCC 的 AST，给 Emacs 等 GNU 项目戴上了手铐[1]。
在这则消息发布的时候，RMS 最糟糕的噩梦已经在 Dragonegg 上实现了……只是由于需求不足，Dragonegg 已经寿终正寝。
你说得对，我把 Dragonegg 和 llvm-gcc 弄混了。但我的观点仍然有效–GPL 完全无法阻止有人用它来引导一个新的编译器基础架构，而这个基础架构需要更宽松的许可证。
所以，该公司希望我们相信他们–相信他们不会利用 BSDL 做 GPL 禁止他们做的事情。我们应该相信他们，因为这样做意味着会有更多的 “人手”（例如，现在大家都在使用的通用 LZO 压缩库，因为它是 BSDL）。
很抱歉，在这些情况下，信任经常被破坏，而且更多的人在同一个库上工作的好处并不完全清楚。
我理解许多公司不想成为 GPL 许可的软件库的一部分，这是他们的权利。但不要试图把它说成 “如果只有 BSDL 才是通用的，那么对不同软件库的利用率就会更高”。这也许是对的，但前提是 tivo 化始终是一种选择，而这对我们中的某些人来说意义更为重大。
这与信任无关，而是10%的东西，甚至是10%的机会，总比100%的保证要好。如果有人按规定使用 BSD 许可证，你就不会被利用。
如果我在某人面前摆出两个选择，一个是 Copyleft（版权），另一个是专有许可，他们总是会选择专有许可，或者我给他们一些许可，他们至少有机会做出贡献，严格来说，第二个选择更好。这就相当于征收不产生任何收入的财富税，我宁可让你在这里有所贡献，也不愿让你移居国外却一无所获，即使这种好处更间接
也不是百分之百的一无所获。如果因为自由和开放源码软件是 GPL，在法律上他们不能从自由和开放源码软件中揩油，所以选择了专有软件，那么有关公司仍然需要向开发人员支付编写替代软件的费用。这仍然是积极的，没有任何损失。许可授权只是授予自由使用的自由，仅此而已。
我认为至少在我们这里不会这样。实际上，我很喜欢我们的开放源码软件政策：基本上，我们不想从事维护分叉的业务，所以所有的变更都应尽可能地向上游迁移。这也是一种很好的客户服务：当我们的客户询问我们使用的库时，我们更愿意告诉他们 “最新的公开版本”，而不是 “这是我们的分叉版”。
我们还希望参与我们使用的项目，并为其提供捐赠，这主要是出于风险管理的考虑：如果这些项目无人维护，对我们来说也不是好事。
如果你真的想上游修改库，我不明白为什么 lgpl 代码不是你的选择。如果你愿意，可以在你的专有代码中使用它，不做任何改动。如果你做了修改，你只需要上游或提供源代码。
>如果你真的想上游修改库，我不明白为什么 lgpl 代码不是你的选择。
再仔细读一下 LGPL。LGPL 要求你以特定的方式使用它，允许任何用户将你的版本换成他们的版本，这基本上意味着你只能将它作为共享库进行动态链接。即使你没有对该库做任何改动！
>，任何用户都可以将你的版本换成他们的版本，这基本上意味着你只能将它作为共享库进行动态链接。
我原以为根据许可证，动态链接要求是唯一的选择，但显然不是。根据 LGPL v2 的 6.a. 和 v3 的 4.d.0.，只要让用户访问主程序的源代码/目标代码以及非开源条件下的编译脚本就足够了，这样他们就可以根据自己版本的库进行重新编译和静态链接。
我认为财富税的比喻非常棒，因为有些人真的非常讨厌富人，宁愿他们离开这个国家。
他说了什么：
>GPL导致世界上专有软件的数量明显增加
他做了什么：
>开放我们的核心源代码从来不是一个选项。
正是那些认为开放其软件源代码 “绝不是一种选择 ”的公司–即使是其中的 LZO 压缩部分–才导致了 “世界上专有软件数量的明显增加”。他们只是在用 GPL 这个恶棍为自己的决定找一个薄薄的借口。
他含沙射影地说，如果你只是将你的代码 MIT，这样大的科技公司就可以使用它，如果他们最终需要你的帮助，他们甚至可能会雇用你，这似乎是超级卑鄙和近乎剥削的行为，尤其是在当前的就业市场上。
是的，现在存在更多的专有软件，但无论如何你都想用它来创建专有软件，所以这就是父母所说的有些人不想要的东西。
部分相关。如果该项目提供付费的非 GPL 许可，你会付费吗？
实际上，我们（工程师）想为另一个 GPL 项目付费！但由于他们没有 CLA，律师们不肯签字–他们认为主要/当前维护者没有权利为我们重新授权。
我们可能也会为 LZO 重新授权，但不知道为什么没有成功。
>因为他们没有 CLA，所以律师不会签字–他们认为主要/当前维护者无权为我们重新授权。
在这种情况下，MIT 等许可软件的法律论据会有什么不同？律师们会同意使用没有 CLA 的 MIT 许可软件吗？难道他们不会认为软件的来源不可靠，因此其许可也不可靠吗？似乎唯一重要的是谁有权为软件提供许可证，而不是许可证是什么。
他们只是想让 CLA 支持（付费）再授权。
我认为他们的理由（正如他们向我解释的那样）是，当人们做出原始贡献时，他们同意了当时的许可证（在本例中是 GPL，但在其他项目中是 MIT）。但其他贡献者从未同意主要维护者可以有偿重新许可他们的贡献。
结果，我们采用了内部完全专有的替代方案。成本更高，质量可能更低。
我亲眼见过这种情况。谷歌不允许将 GPL 代码导入到庞大的 monorepo 中。如果我需要一个库，而唯一好的开放源码软件选项是 GPL，我会从头开始写。如果不是开源项目的一部分，我通常也不会开源这些东西，因为这不值得花精力。
用户自由。在所谓的 “更宽松 “的许可证下，这些自由是不存在的。
我认为 Rust 没有问题。问题出在许可证上。新项目与专利兼容。
那又怎样？对 coreutils 的专有扩展毫无兴趣。这不是 Linux 或 GCC；它们只是基本的命令行工具。
此外，任何真正感兴趣的人都可以使用 BSD 版本。
[deleted]
Stallman 为捍卫我们的自由所做的贡献，比所有评论家和乐于利用他的工作的公司加起来还要多。
他还极具先见之明，领先时代数十年。面对无情的攻击，他坚持自己的立场，而其他许多人却出卖和背叛了他们自以为的道德。
这些评论令人恐惧，因为它们抛弃了数十年的努力和稳定，却换来了现在所倡导的一切。当 Rust 开发人员似乎热衷于追随当前最流行的东西时，我们怎么能相信他们会积极维护一个项目呢？旭Linux的首席开发者在暂时受到压力时退出，也是同样的情况。我们无法相信他们会真正致力于此。
>当他们似乎热衷于追随任何最新的东西时？
Rust的1.0版本*10年前*就发布了。还需要多少年，人们才能停止不断影射人们使用它只是因为炒作，而不仅仅是因为它是一种比 C 语言好得多的语言？
我的问题与语言无关，我认为它很棒。但是那些 Rust 的布道者却到处宣扬 Rust 语言，而不管它是否合适，也不管维护者是否真的想使用它。所以是的，大多数鼓吹使用 Rust 语言的人主要是为了炒作，而不是为了它的好处。尤其是当人们表现得好像不使用 Rust 是道德上的错误时。对于一门语言来说，10 年根本不算长。
我经常看到有人表达这种情绪，但我不认为这种说法有任何道理。
它可以归结为 “这种语言可能有优点，但我不喜欢人们鼓吹它的方式”。这就是语气警察。而 “语气警察 ”的问题在于，他们设定的标准模糊不清，因此不可能令人满意。
你心中有某种 “正确的宣传方式”。其他语气警察也有其他 “正确的方式”。但倡导者不是读心者，他们也不可能同时满足你的所有要求。
>把语言推向各处，不管它是否合适
，语言哪里不合适？注意，你没有说，所以虽然听起来你在做技术上的论证，但听起来就像一个养老金领取者在抱怨孩子们在他的草坪上。
这才是真正的问题所在。发牢骚的人没有任何技术性的论据，他们只是老保守派，他们喜欢事物一直以来的样子，并希望保持这种样子。他们用 “在数以百万计的Rust开发者中，我不喜欢其中一些人的一些评论 ”这样的傻话来代替技术论据。酷毙了
你指责所有与你意见相左的人都是 “老保守派”，这一事实表明你的出发点是如此不诚实，以至于我不想与你有任何瓜葛，也不想相信你的任何论点。这就是一个典型的例子，说明了 Rust 布道者是如何把不使用 Rust 视为道德错误，以及 Rust 开发者为何令人难以忍受。我宁愿用一种所谓的次优语言来写作，也不愿和你这样的人打交道。
哈哈，换句话说，你反对我的语气。明白了。
瞧，你完美地证明了我的观点。>我宁可用所谓的次优语言写作，也不愿和你这样的人打交道。
说白了，你可以免费下载编译器，编写所有你喜欢的程序，同时与 0 人互动。你跟我说话是因为你在 HN 上，而不是因为你在写 Rust。这还不明显吗？
语气很重要。你让人难以忍受。我今年 21 岁，我也宁愿写 C 语言，和那些 “老保守派 “混在一起，也不愿意和那些像你这样议论别人的人在一起。
让我们弄清楚我在骂什么。我更喜欢技术性的讨论。让我们来谈谈性能、安全性、可维护性、易学性等技术优点。所有这些都是评判一项技术的有效参数。
“我不喜欢某些人说话的方式 ”不是技术理由，在技术讨论中也没有任何地位。这尤其毫无意义，因为在数百万人的群体中，没有人会喜欢每个人的说话方式。
如果一个人回避技术讨论，而只关心语气，我是不会认真对待他的。如果你想和这样的人在一起并向他们学习，我祝你好运。你的年龄并不重要。一个 20 岁的人和一个 60 岁的人一样，都可能思维僵化。
部分原因是，它的一些拥护者会说：
>它是一种比 C 语言好得多的语言
，而他们本可以只说 “它有一些 C 语言没有的重要特性，而且很可能永远不会有”。
我不明白。所以你认为它不可能是一种比 C 语言好得多的语言，而人们这么说的唯一原因是炒作？
“更好 “意味着一个明确的 “好坏 “衡量标准，而这个标准并不存在。因此，仍然使用这种语言的人是在暗示，他们的观点和他们对 “好 “的定义是唯一正确的。
诚实的回答：当它的第一批拥护者完全退休后，我们才能真正看到它是否对下一代工程师有持久的吸引力。C 已通过测试。
Rust 据说是后 1.0 时代，但它仍然没有一个标准，而不仅仅是记录编译器的输出。
GNU 项目有多少是由 Stallman “提出 “的？如果数字较大，使用它将是不可接受的，但如果数字较小，使用它又是可以的，您的阈值是多少？
我并不太关心那些实际上是商品的许可版本（如 coreutils）。我仍然非常希望像内核这样的东西保持 GPL，因为它没有真正的替代品。
uutils 项目的目标是正确的–与 GNU coreutils 实现 1:1 的兼容性，任何功能上的差异都是 bug。
LWN 上的第一条评论是关于 uutils 的 more(1) 中的一个 bug。我查看了那段代码，发现了一些奇怪的地方（比如在 path 上执行 stat()以检查它是否存在，然后再执行 open()），并对照 GNU coreutils 的做法进行了检查。
结果发现 coreutils 根本不会这么做，因为 more(1) 来自 util-linux。
我认为这是一个很好的观点，很多人都忽略了这一点。
GNU 工具有很多。就目前而言，Ubuntu只使用了coreutils中的实用工具。这些都是 uutils 认为 “可以投入生产 “的工具。
> > Klode 说，允许用户在每个命令级别上选择 Rust 和非 Rust 实现是个坏主意，因为这会让生成的系统难以支持。
这不就意味着这些实际上并不是 1:1 的替换吗？
这意味着并非所有的替换都是完整的和/或没有错误的，文章在前面给出了这样的例子，但这并不意味着这些替换缺乏 GP 所说的 1:1 替换的目标。
这似乎也是创建 oxidizr 的驱动因素之一：允许测试组件的就绪程度，以方便进行替换。您可以在 jnsgruk https://discourse.ubuntu.com/t/carefully-but-purposefully-ox 的链接博文的这一部分中阅读到更多相关信息…
uutils 的目标是成为 GNU utils 的直接替代品。与 GNU 的差异将作为 bug 处理。
— https://github.com/uutils/coreutils?tab=readme-ov-file#goals
这很有趣，因为就在今天，我在阅读 std::fs::File 的 Rust 文档时，看到了一个关于 TOCTOU 错误的警告，于是我不得不修正我的代码，使其不会发生
std::fs 通常不是一个好的 API，因为它完全没有目录句柄。
>uutils项目的目标是正确的
他们的目标是_取代GPL的代码_。这是对自由软件的一种微妙攻击，它为企业提供了一种变通办法，使它们不必遵守许可证条款。
没有人会认真怀疑 GNU Coreutils 的效率和安全性。它们已经经过了 30 多年的实战检验，安全或优化方面的风险几乎可以忽略不计。
the more you know
不知道为什么你会被降权，但我很好奇为什么。我很欣赏这个花絮，谢谢。
然后呢？怎么做到的？
我检查过了。它先打开文件，然后进行 fstat。所以它不会受到 TOCTOU 的攻击。
不过，TOCTOU 在这里是完全无害的。它只是 Rust 打开文件前的额外检查，所以如果你试图 “利用 “它，唯一会发生的事情就是得到不同的错误信息。
>如果你试图 “利用 “它，唯一会发生的事情就是你会得到不同的错误信息
无法重现。如果我在一个终端上执行
sudo strace -e inject=stat:delay_exit=30s:when=2 ./coreutils more foo
，在另一个终端上执行
rm foo ln -s /etc/passwd foo
，我可以在第一个终端上看到 /etc/passwd 的内容。
Uhm yeah well now try
ln -s /etc/passwd foo sudo more foo
OMG！原始版本也 “易受攻击”！
(我还不知道跟踪功能呢–太酷了，谢谢！)
我还以为会出现错误，因为统计的文件和打开的文件不匹配。真令人失望
不，这只是意味着你检查错了文件，所以你可能不会从初始检查中得到漂亮的错误信息。
但在实际打开文件时，它仍然不会做任何错误的事情。
TOCTOU 只有在实际检查重要内容时才会起作用。在这里，它不是；它只是给出更漂亮的错误信息。如果绕过它，就会失去那些漂亮的错误信息。
所以在这里它不是一个问题。
这是最糟糕的忙碌工作。为了重写而重写是很糟糕的做法。
在 Rust 的编码者中，有很多人都渴望开发出更好、更现代的命令行工具。这很了不起，对每个人来说都是实实在在的好处。但是，重写简单的、有几十年历史的、功能完善的工具，并不以改进它们为明确目标，这只是一种自我陶醉式的爱好。任何新代码都会包含错误，而避免错误的最好办法就是在没有必要的情况下不要编写代码。
这不是为了写代码而写代码，而是为了拥有 MIT 许可的 coreutils。GPL 对任何想要 EEE 的人来说都是眼中钉。
这还远远不够。关键是要有 GPL，而不是逃避 GPL。Canonical 再次表明他们没有理解这一点。无论如何，我都会继续使用 gnu coreutils，因为我看不到任何好处，也没有理由更换。
这不是动机。这是关于 “弹性、性能和可维护性”。
我怀疑他们能否获得明显更好的性能（主要的 GNU 工具已经非常优化了）。我不确定它们是否真的缺乏弹性。我也不认为内存安全是一个重要因素。
不过，维护绝对是一大优势。888/3/psd1
目前这些工具需要多少维护，与付出的努力相比如何？
我对这种暗示感到惊讶
如果你看得更深入一些，这个项目实际上非常关心它的许可证，并在不遗余力地选择它正在使用的许可证，无视投诉，避免最终使用 GPL。
https://www.youtube.com/watch?v=5qTyyMyU2hQ
在接受《FOSS 周刊》采访时，Sylvestre Ledru（主要开发者，奇怪的是他曾有过 Debian 和 Firefox 的工作背景，最后被 Clang/LLVM 生态系统所吸引）坚定地表示 “这与安全无关”。
要澄清的是，你认为几个组织显然想要的明显好处并不是动机，而改进 3 个可能不会改进的东西才是真正的动机？
Toybox 和 BSD 已经存在，可以满足那些想要获得许可的实用程序的需求，GPL 并不是一个主要的动机。
它们确实存在，但都是最小版本，不能与 GNU 版本一一兼容。
每个专有的 Linux 操作系统（如大多数安卓手机）都在使用 busybox，这对它们来说有点不利，因为它们无法处理使用 GPL3 coreutils 的问题。现在，他们将使用 MIT 许可的 drop-in 替代 coreutils。
是的，因为非 GPL coreutils 不存在。
我不想承认这一点，因为我并不特别喜欢 Rust，但我正在慢慢接受它应该取代其他东西的观点。
最主要的变化是我最近发表的一条评论，我在评论中畅想了一个由法学硕士编写大部分代码的未来。这并不是一个必然的结论，但最近在编写 LLM 方面的进步表明，它并不像我曾经考虑的那样遥不可及。
我的想法很简单：如果我使用 LLM 来完成生成代码的大部分工作，这会如何改变我对所使用编程语言的看法？我选择语言的标准是否会改变？
经过思考，Rust 可能是最佳选择。它的严格性是其他语言所不具备的。而且，如果 LLM 要为保持类型和生命周期的有序性支付大部分成本，那么我还会在乎语法是否难看吗？只要我能读取 LLM 的输出并对其进行验证（代码审查），那么我就真的想要严格性。因为我对 LLM 的信任度很低，所以我想要尽可能多的可静态分析代码。事实上，Rust 还非常快，这是锦上添花的好事。
除此之外，我还想到了模块化内核，比如 Minix。我在想，我们是否可以把 Ubuntu 正在尝试的用户界面应用到 Minix 中。然后用 Rust 编写的模块慢慢取代操作系统模块。我觉得 Minix 这样的模块化可能是一个优势，但这可能只是因为我太天真了。
LLM 编写的 Rust 相当糟糕。它过于啰嗦（遗漏了组合器），而且经常出现微妙的错误（在不应该出现错误的情况下吞下结果类型上的错误）。一个错误的 collect 或 clone 调用就能毁掉你的性能，而 LLM 会无缘无故地将它们洒在你身上。
除非你对 rust 有丰富的经验，否则你根本无法发现 LLM 在生成 rust 代码时所犯的错误。
我刚有一个 LLM（3.7 的东西）提出了一个 100 行的实现，在我盯着东西看了一会儿之后，我把它缩减到了一行。我相信我是少数不接受增加 100 行的人。
你能详细说明一下吗？这些线是做什么用的？
很多行都在安全地取消引用 JS 中的东西，而在 JS 中你只需要做……就可以了，在周围放上 try/catch 块（每次都这样！），并以单行就够了的方式调用东西。我差点就截图来搞笑了。
说实话，为了便于阅读，这一行应该分成三行。这种恶毒的诽谤必须停止，只有 97% 的法律硕士成果是垃圾，而不是你所说的 99%。
> 除非你有丰富的 rust 经验，否则你根本不可能发现 LLM 在编写 rust 代码时所犯的错误。
我想说的是，这与其他语言不相上下…… LLM 生成代码的正确率大约为 95%，但这还远远不够。
而花时间去发现哪 5%看起来不错但实际上是错误的，则是一种令人沮丧的经历。
这些程序所犯的错误与人类不同，我发现它们更难发现。
随着 LLM 的功能越来越强大，这种缺陷是否会长期存在？
我认为其中一个问题是可供训练的现存 Rust 代码较少。随着更多 Rust 代码的编写和发布，理论上 LLM 应该会变得更好。
我听说现在大多数代码都是由 LLM 写的。我希望这不是真的，但如果是真的，那么未来的改进将会很慢（除非真的教他们阅读文档）。
LLM 真正提供了 “垃圾进，垃圾出 ”的体验
你花了这么长时间才用 LLM 代替 “初级程序员”，这很有意思。隐含的安全性同样适用于由容易出错的人为开发人员组成的团队。
我也有过类似的想法。从能耗的角度来看，Rust 或 C 也是理想的候选语言，因为它们的能耗远远低于 Python，而根据我的经验，LLM 最常使用的语言就是 Python。
不过，LLM 不太可能生成大量的 Rust 代码。这些 LLM 生成的都是最有可能的下一个标记，基于它们所接受的训练。而在它们的训练集中，Python 和 JS 代码的数量可能远远多于 Rust 代码，原因很简单，因为这些语言更流行。因此，与 Python 相比，Rust 更容易产生幻觉和犯错误，因为 Python 的路要好走得多
不过，与 Python 这样的解释型语言相比，Rust 更容易进行静态分析，而且 Rust 具有编译时验证功能。这使得用 rust 编写带有编译修复循环的代理 llm 代码比用 python 更容易。
根据我的经验，与 python 相比，rust 的 llm 并不是特别糟糕，尽管我只是对它们进行了少量的尝试。
虽然我很幸运没有花过一段时间去重构/修复 LLM 生成的代码，但我在尝试对人类编写的 Rust 代码进行重大重构以修复较大的问题时，绝对要比其他语言容易得多。编译器显然不会捕捉到所有的问题，但当我们试图对代码库进行级联式修改，以修复我所见过的重构试图解决的问题时，编译器_能够_捕捉到的问题似乎非常常见，而我的直觉是，这些问题可能也是 LLM 生成的代码最终需要修复的问题类型。
在本主题的其他地方，有人提到 LLM 生成的代码性能很差，经常收集迭代器之类的东西，并指出修复这类问题通常需要大量的 Rust 专业知识，我对此并无异议。不过，在我的印象中，对于一个经验丰富的 Rust 程序员来说，从糟糕的代码中抓回一些内存的工作量，最终还是要少于一个在 Rust 之外的其他语言上有类似经验的人在自己的语言代码库中工作的工作量。我曾见过三四个 Go 工程师花费数周时间试图追踪并减少分片内存开销的问题，这是因为并不总是很容易分辨给定的分片是在堆上拥有自己的内存还是在引用不同的内存；而寻找所有调用 `collect`（或其他已知堆分配的类型）的地方相对来说要简单得多。也许 Go 比 Rust 简单得多，会让 LLM 生成的代码好得多，从而让人类更容易调试和修复，但至少在某些类型的问题上，我对人类编写的 Go 代码的体验恰恰相反，所以我现在对做出这样的预测还不是很有信心。
在实践中，情况并非如此。我做人工智能辅助 Rust 已经有一段时间了，很有说服力。我预计 6 个月到 1 年基本可以实现全自动。
Rust 有大量代码，而且代码质量很高。这与 js 或 Python 不同，它们有大量低质量甚至纯垃圾代码。
我也一样。我认为 rust + llm 组合是无与伦比的。
前情提要：
https://news.ycombinator.com/item?id=43360969
https://news.ycombinator.com/item?id=43353240
太神奇了，这又是一个避免使用Ubuntu的理由。
这些工具中有很多都存在逻辑错误，你可以在 GitHub 上的问题中找到它们。
我敢打赌，这些工具并不能替代 GNU 工具，也就是说，它们的功能更少，可能也没有经过优化，甚至可能有不同（或更少）的标志/选项。
我写过很多 Bash 脚本，我想知道在 Ubuntu 上使用 Rust 工具的效果如何（如果有的话）。
真是无知的评论。GitHub 上的 uutils README 在第一节就明确指出，与 GNU 实用程序有关的任何差异都会被视为 Bug。
这是一种实用主义的评论，而不是无知。
无论如何，请在这里随意查看：https://github.com/uutils/coreutils/issues?q=is%3Aissue%20st…
到目前为止，它还不是 GNU coreutils 的替代品。
当然，在 “目标 “中写道：”uutils 的目标是成为 GNU utils 的直接替代品。与 GNU 的差异将作为 bug 处理”，但请查看已打开（和关闭）的问题（因为它们应该能告诉你已出现的主要但简单的逻辑 bug）。它肯定还没准备好，我也不确定它何时能准备好。
另外，README 中还提到：”可能会缺少某些选项或出现不同的行为”。
未来会有答案，但现在，用 Rust 的 uutils 替代 GNU coreutils 是个极其糟糕的主意。你不这么认为吗？如果是，请详细说明原因。
你的第一句话完全没有必要，而且是基于对他们所说的话的不公正解读。他们完全有可能知道这个项目的目标是把每一个差异都当作一个 bug 来处理，并表示他们认为还有很多 bug，而且没有证据表明这些 bug 会被全部解决。
另外，当我们把 README 放来放去的时候，这里有第一段：
> uutils coreutils 是 GNU coreutils 在 Rust 中的跨平台重新实现。虽然所有程序都已实现，但可能会缺少某些选项或出现不同的行为。
上述 “无知的评论 “实际上只是指出了开发人员认为人们最需要知道的第二件事–仅次于它是重新实现的事实。
> uutils 的目标是成为 GNU utils 的直接替代品。与 GNU 的差异将被视为 bug。
>某些选项可能会丢失，或者会出现不同的行为。
这两种说法不可能同时成立。
它们完全可以： “旨在 “是指 “将来会是这样”，而不是 “现在是这样”。这就是 “差异是 bug “的意思，即你目前可能会遇到不正确的行为，但这是为了在未来得到修复。
根据 GitHub 上的问题和该项目目前的状态，“未来 ”是很久以后的事了，为什么现在会有人用这个项目取代 GNU coreutils 呢？这毫无道理。我希望他们至少能给用户一个选择权，但话说回来，这对我并无影响，我不使用 Ubuntu，也永远不会碰它。
Canonical再次对授权问题轻描淡写，这一点也不奇怪。
这完全是别有用心。最好的结果是：什么都不会发生。
我有个疑问： 为什么他们需要用 Rust 编写实用程序？大多数实用程序都不需要面对网络，也不需要 root 权限。见鬼，它们大多是一次性程序，甚至不需要程序员释放内存。它们可以退出并将所有内存空间归还给操作系统。
>大多数实用程序不必面对网络
诚然，但这些实用程序的代码最终可能会在网络中使用（例如，通过复制功能和共享库）。此外，创造性的流水线实际上也可能涉及到它们（想想 Unix 的理念）。
最终，纯 C 语言必须消亡，或被归入不可避免的地方，就像汇编案例中那样，即使 Rust 毕竟不是最好的替代方案。
这是基于人们对 CVE 与实际被利用情况的一种常见谬论。我会回去再读一遍让你如此积极地加入内存安全列车的论文，看看你是否能发现动机不明的推理。
如果你有论据，就提出来。这里不是课堂，你也不是教员，给不同意你观点的人布置作业不是有效的论证技巧。
具体是什么谬误？
因为事物需要不断发展，我们看到一些很棒的新创意来自于添加进度条、进行彩色输出、了解 .git 结构等的工具。在我看来，目前的状况相当停滞不前。
有趣的是，git 结构支持经常被认为是一项很好的功能，它被嵌入到一个应该比 git 本身寿命更长的工具中。
但这个项目的明确目标不是进化，而是 1:1 重写。
另外，制作进度条和颜色并不需要 Rust，C、C++、Zig、Go、Swift 等语言同样可以实现。
它已经添加了一些新功能，比如给一些实用程序添加进度条。
因为人们从互联网上获取输入并通过它们运行。
直接面对网络只是程序处理不信任输入的一种方式。
我一直希望有一天，有人开始用 Rust（或者任何东西）取代基于 perl 的 Debian 基础架构。
我做过不少 mod_perl，喜欢&；尊重 perl，但在 2025 年，Debian 的主要依赖是相当可观的 perl 运行时，这对我来说非常可怕。似乎没有什么办法能改变这种状况。整个生态系统是建立在一种很少有人感兴趣的语言之上的，这种语言的兴趣和活动远远低于其他现代替代语言。
如果我们开始将用户 env 迁移到更流行的基于 Rust 的实用工具上，那也没什么问题。但我真正想要的是操作系统本身的现代化，开始摆脱其古老的、看似不可动摇的传统。我并不反对 Perl，但我很希望看到这个操作系统家族不再只使用 Perl。
在 Debian 的其他发行版中，基本上所有用 Perl 编写的系统实用程序都有非 Perl 的替代品，但就目前的情况而言，用 Perl 编写的 Debian 版本仍然是无与伦比的。
有人用 Rust 构建了 Busybox 吗？这对嵌入式系统很有帮助。
从技术上讲，uutils/coreutils 仍然足以实现这一目标，因为它可以像 busybox 一样构建成单个二进制工具（事实上，默认情况也是如此）
虽然 Busybox 对这些工具进行了非常基本的实现，以控制其大小。
你的所作所为只会让人们陷入更持久的 bash-dash 灾难。难道你就没有更有用的事情可做吗？比方说，让拖放在 Snaps 中起作用（另一个非故意的灾难）？
Wayland、Snaps 和 Flatpaks 的 “安全性 “开始让我恼火。宏无法正常工作，剪贴板忘记了我的副本，拖放功能不稳定–像光标这样的应用程序图像甚至无法在Ubuntu上打开。这些没人要求的 “功能 “应该是选择性的。
在某种程度上，它们是选择性的，因为你选择使用Ubuntu，就意味着你选择了加入，而选择使用其他东西就意味着你选择了退出。
没错，就是这样。整件事就是在演戏。我讨厌这样。我知道我可以直接使用X11（我也这么做了），但在未来几年里，Linux开发者的胃口会越来越小，我们很可能只能使用Wayland应用程序。不过，好的一面是，Wayland 可能会让自己变得非常垃圾，以至于人们忽略了为它开发应用程序（我并没有把只针对 kde/gnome 的应用程序计算在内，反正它们与 Wayland 协议的差异已经足够大，值得单独提及）。因此，我们将为Linux应用程序提供X11/KDE/Gnome支持。这可能是最好的情况。
你认为 Android 和 iOS 应用中的应用权限没有帮助吗？权限模式在手机上有意义，但在桌面上没有意义，这并不是一个真正的理由。桌面应用程序本质上更值得信赖。事实上，安全功能会妨碍你的工作，这更像是一个产品精细度的问题，一般来说，开源项目都会遇到这个问题。这项技术在概念上并没有缺陷。
>桌面应用程序本质上更值得信赖
为什么？如果说 30 年来 Windows 作为联网最多的操作系统已经证明了什么，那就是 99% 的桌面可执行文件在进入磁盘写缓存之前就应该被删除。
移动平台表明，强制沙箱对防止恶意软件大有裨益。桌面操作系统拒绝走这条路，因为存在破坏现有工具的风险，这也是为什么没人愿意使用沙盒 API，这也是为什么许多第三方沙盒尝试不断被破坏的原因。
台式机没有理由不通过虚拟文件系统或专门的共享 API（如在移动设备上）交换文件。我的计算器不需要摄像头，我的音乐播放器也不需要生物识别。台式机还停留在上世纪 90 年代的权限模式（对于喜欢 Unix 的人来说，则是上世纪 70 年代的模式），因为人们已经习惯了这种模式。
我使用 Steam Deck 的经验是，在只读系统镜像上使用 Flatpak 沙盒绝对没问题。如果桌面应用程序能遵循现有标准并实现标准化，效果会更好。当然，如果你是一名 Linux 内核开发人员，你会觉得这样做不够好，但受这些限制影响的 0.01% 用户不应该限制其他人。
有些台式机用户可能认为自己太聪明了，不会被黑客攻击，尤其是在 Linux 系统上，但他们的台式机与智能手机并无太大区别。
我打错了，应该是 aren’t。我同意你的说法。
我同意，他们应该用 Rust 重写内核
>他们应该用 Rust 重写内核
我喜欢 Rust
请不要这样做！
我们能不能在前人的基础上继续创新，而不是重新发明……
是啊，那叫一个完全不同的项目
这是 Canonical 的品牌。
将边缘测试版（alpha？）软件置于其系统核心
让我想起他们将Gnome换成Ubuntu One时的情形，如果你进行 “aptitude full-upgrade”，就再也回不去了。
这是一个漏洞百出的POS
亲爱的朋友们，请再次注意……
它看起来就像一个企业项目，所有必要的炒作和行话都有。Ubuntu 在第 10 版左右还算不错，但随着间谍软件、Snap 等的出现就开始走下坡路了。
“在开源社区中，使用最近才出现的工具和实践对工具进行重新设计和想象的例子数不胜数。
最近？你可以使用 Ada 或 OCaml，后者是更好的 Rust。你可以使用带有形式化证明的 C 语言，而不必不断重写一切。
当然，这才是重点。不重写，企业开放源码软件 “开发者 “就能轻松赚钱。
我喜欢我正在学习的 ml 语言，并认为它比我使用的任何其他语言都要好，但我对 “ada 和 ocaml，哪个是更好的 Rust “感到困惑
从未写过 Rust，只在博客上看过一些片段，但它在视觉上看起来与 ml 非常不同
我是被表面的语法差异迷惑了吗？
您能解释一下吗？
使用 Rust 是一种政治解决方案，目的是淘汰一代编码员，用低成本劳动力取代高成本劳动力
推动使用 Rust 不仅仅是一项技术决策，更是一种经过深思熟虑的经济策略。通过强制使用新语言重写稳定的系统，公司可以有效地重置开发人员的经验和专业知识。
当一个拥有 30 年系统知识的 C/C++ 代码库被重写为 Rust 时，拥有几十年经验的资深开发人员突然与刚毕业的后辈们站在了更平等的起跑线上。你 15 年的 C++ 优化知识？现在还不如一个 22 岁的年轻人接受六个月的 Rust 训练营培训来得有价值。
这不是内存安全的问题，而是人力成本的问题。公司称其为 “现代化”，却悄悄抹去了他们为经验支付的溢价。这些技术上的论据完美地掩盖了真实情况：公司故意制造一种情景，用 8 万美元的初级工程师取代 25 万美元的高级工程师。
对于观察过其他行业的人来说，这种模式并不陌生。人为地淘汰现有技能，然后利用由此造成的混乱来重新设定薪酬预期，消除专业知识带来的杠杆作用。
这就是为什么语言转型似乎总是与招聘冻结和 “结构调整 “同时发生。这从来都不是技术优势的问题，而是打破劳动力谈判能力的问题。
这更像是用 1-2 名 Rust 人员取代 4 名 C++ 软件人员，因为当你不需要不停地编写脚枪代码时，工作量会减少一半。
剩下的就真的是锡箔帽了。我看到了才会相信，在此之前，很难将 Rust 看作是一种桌面化。这种语言需要不同的技能而已。
这是一个有趣的阴谋论，我以前从未听说过。不过，我怀疑投资重写大型项目是否具有经济意义，即使目标是赶走专家。重写需要数年的时间，即使初级人员做起来更便宜，而且迁移是一个存在的商业风险。
如果这 15 年的 C++ 优化与一个 22 岁、参加过半年新兵训练课程的人相比，并没有优势可言，那么也许真的到了停止使用 C++ 的时候了。
编程作为一种职业，不幸的事实是你需要与时俱进。如果 C++ 即将被淘汰（我对此深表怀疑），那么是时候学习 Rust 了。大多数 Visual Basic 程序员都已经转行，大多数 Fortran 程序员也是如此，当 Java 出现时，许多 C++ 程序员也转行了。
当你拿劳动力的议价能力说事时，你是在假设年轻劳动力会对有经验的劳动力构成威胁。也许在某种程度上确实如此，因为导致软件业工资高得离谱的编程技能人才短缺问题正在慢慢消失，但对该行业进行把关并不是什么支持劳工的举动，这只是自私而已。
GNU 可以自由采用比 C/C++ 更好的工具。我喜欢 GNU，但我拒绝支持明目张胆、顽固不化的白痴行为。利用许可证敲诈人们支持 C/C++ 只是卑鄙的行为。在过去的十年里，你到底在做什么？相反，我们得到了该死的 systemd 和地球上最烂操作系统的十几个山寨版
你有权不使用 GNU 工具或 GNU/Linux，你知道吗？
没人强迫你。
Rust和 “记忆安全 “是当前企业专制的一种表现形式。令人啼笑皆非的是，最强烈的拥护者很可能也是那些抱怨现任政府专制的人。
记忆安全并不那么企业化，AFAIK。我认为这只是当前程序员的一种时尚，就像 pearl 的 dwim、python 的 “pythonic”、JavaScript 为每一个可以想象的单行函数提供 5 种不同的库，Haskell 的 um … 我从来没学过 Haskell 等等。
每当一种语言开始腾飞，人们就想用自己的语言重写一切。Rust 只是在性能和一些优势方面比 C 语言更胜一筹，我想这也算是一种酷吧。
这是企业的想法，因为他们意识到，通过提高 “安全性”，越狱和root等行为很容易被阻止。
发表回复