Linux 内核爆发 C / Rust 大战，核心开发者愤然离职

darklinden

ryanz 发表于 2025-2-13 18:59
别瞎说，现在的 nodejs 粉大概确实消散完了，对于这些争论只能说时间证明一切吧

说到时间，最近 10 年的 ...

请问对于zig编写的bun存在各种奇特内存泄漏的问题怎么看？

zig编译太好使了以至于目前最常见的时候都是在干编译的活儿…



—— 来自 S1Fun

d2loader

darklinden 发表于 2025-2-13 19:58
请问对于zig编写的bun存在各种奇特内存泄漏的问题怎么看？

zig编译太好使了以至于目前最常见的时候都是 ...

zig可能靠这个这个独门绝活活下去的

希望rust这边早点造好allocator-api 2

—— 来自 鹅球 v3.3.96

GJRstone

一切皆政治，世界最大的开源运动皇冠上的明珠linux内核实际上就是靠林纳斯这个象征从外围凝聚起来的，在林纳斯通过秘密集会认定一部分俄罗斯开发者是敌我关系并依托美国法律对这些人进行政治迫害时，linux社区在二十年尺度上发生分裂的不确定性肯定会增加。

而林纳斯客观来说55岁，说长寿能活20年，那么他自然需要考虑权力交接的问题。延续c/c++，是继续把心智负担叠加在管理者上，引入rust，是把心智负担解放到一部分rust贡献者头上——或者更具体的说rust委员会头上。
往下有几层问题：①rust委员会的稳定性②作为某一个特定象征发生时，c/c++开发者缺乏核心领导散兵游勇而rust开发者作为尖刀部队显著夺权造成生态动荡的可能性。

社交媒体逼宫毫无疑问是②的风险发生的指示物，而rust委员会在23年重组本身就说明rust“命不久矣”。林纳斯55岁不是75岁，身后还有c++委员会（除社区支持外还特指美国政府那部分影子）撑腰，肯定不会鸟rust的逼宫行为。

yikaa

bcxzzz 发表于 2025-2-12 18:02
从技术上来说，可能给一种语言留后门么？ 比如考虑下：1、语言的解释器、编译器是公开代码的么？ 2，即使 ...

https://wiki.c2.com/?TheKenThompsonHack

如果仅说有没可能，那是有可能的

—— 来自 鹅球 v3.3.96

ryanz

darklinden 发表于 2025-2-13 19:58
请问对于zig编写的bun存在各种奇特内存泄漏的问题怎么看？

zig编译太好使了以至于目前最常见的时候都是 ...

选择工具比较保守就没用过，写前端还是 vite react 默认的那套脚手架。我感觉是最近两三年的东西吧，年轻的应用有各种问题很正常，就像当初 swc 和 esbuild 运行效率导致的那些争论，前期没优化完全并不足以说明什么。

万恶淫猥手

darklinden 发表于 2025-2-13 19:58
请问对于zig编写的bun存在各种奇特内存泄漏的问题怎么看？

zig编译太好使了以至于目前最常见的时候都是 ...

zig 本身就是显示管理的，写着写着就忘属于老问题了…

星空天神

以后都是ai的世界,编程语言算个球. 加个功能ai想怎么搞就怎么搞,纯汇编都行.

Midnight.Coup

Hector "marcan" Martin 宣布辞去 Asahi Linux 项目负责人的职务
https://marcan.st/2025/02/resigning-as-asahi-linux-project-lead/

UNICORN00

唉

—— 来自 鹅球 v3.3.96

darklinden

https://lore.kernel.org/rust-for ... uJ4-@infradead.org/

https://rust-for-linux.com/rust-kernel-policy

仅附上机翻

d2loader

linus最后还是忍不住下场了



我曾抱有希望，并试图看看这个漫长的讨论是否能产生一些建设性的结果，但现在看来，事情似乎在倒退（或者至少没有进展）。
事实是，你反对的那个拉取请求根本没有触及 DMA 层。 它只是另一个使用 DMA 层的用户，位于完全独立的子目录中，没有以任何方式改变你维护的代码。
我感到不安的是，你竟然在抱怨新用户使用你的代码，然后还不断提出这些完全站不住脚的论点。 老实说，你一直在做的，基本上就是在说“作为 DMA 维护者，我控制 DMA 代码的用途”。
而这根本不是这样运作的。 接下来是什么？说某些驱动程序不能使用 DMA，因为你不喜欢那个设备，而作为 DMA 维护者，你控制谁可以使用 DMA 代码？
这正是你试图对 Rust 代码做的事情。
说你不同意 Rust——这没问题，没有人要求你编写或阅读 Rust 代码。 但随后你采取了一种立场，认为 Rust 代码甚至不能使用或与你维护的代码交互。 所以让我非常明确地说：如果你作为维护者认为你可以控制谁或什么可以使用你的代码，你错了。 我在技术上尊重你，也喜欢与你合作。 不，我不是在寻找应声虫，我喜欢你指出我的错误。我有时会说一些愚蠢的话，需要有敢于站出来告诉我我错了的人。
但现在，我要指出你的错误。 所以这封邮件不是关于某些“Rust 政策”。这封邮件是关于一个更大的问题：作为维护者，你负责你的代码，没错——但你并不负责谁使用最终结果以及如何使用。 你不必喜欢 Rust。你也不必关心它。这一点从一开始就很清楚，没有人被迫突然学习一门新语言，那些只想在 C 语言方面工作的人完全可以继续这样做。
所以回到你声明的核心：  “该文档声称没有任何子系统被强制要求采用 Rust” 这一点非常正确。 你没有被强制要求接受任何 Rust 代码，或关心 DMA 代码中的任何 Rust 代码。你可以忽略它。 但“忽略 Rust 方面”也自动意味着你在 Rust 方面没有任何发言权。 你不能两者兼得。
你不能说“我不想与 Rust 有任何关系”，然后在下一句话中说“这意味着我将忽略的 Rust 代码不能使用我维护的 C 接口”。
想要参与 Rust 方面的维护者可以参与其中，通过参与，他们将对其 Rust 绑定的外观有一定的发言权。
他们基本上也成为 Rust 接口的维护者。 但选择“我不想处理 Rust”的维护者显然也不必费心处理 Rust 绑定——但因此他们在 Rust 方面也没有任何发言权。
所以当你更改 C 接口时，Rust 方面的人将不得不处理后果，并修复 Rust 绑定。这就是这里的承诺：对于那些不想处理 Rust 问题的 C 开发者来说，有一个“保护墙”，承诺他们不必处理 Rust。
但这“保护墙”基本上是双向的。如果你不想处理 Rust 代码，你在 Rust 代码上就没有发言权。 换句话说：“没有人被迫处理 Rust”并不意味着“每个人都允许否决任何 Rust 代码”。
明白了吗？ 不，我实际上并不认为这需要如此黑白分明。
我上面用非常黑白分明的术语陈述了这一点（“成为 Rust 绑定的维护者”与“完全不想处理 Rust”），但在许多情况下，我怀疑这条线会不那么严格，子系统维护者可能知道 Rust 绑定，并愿意与 Rust 方面合作，但可能不会非常积极地参与。
所以这真的不必是一个“全有或全无”的情况。

tonyunreal

我还以为这种争执是为了迁就女人管人搞出来的
没想到真有这么多人捍卫编程语言
我还是太年轻了

Hieda

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7d5db965f3e

Hellwig辞去DMA mapping维护者职务