nlzy

Rust 开发人员和（不愿意写 Rust 的）Ｃ 开发人员的矛盾是不可调和的。

内核内部没有稳定 API ，这赋予了维护者想改什么东西就改什么东西的权力，可以随时改进、重构。如果改 X 模块的时候 Y 模块炸了，那 X 的维护者只需要顺带着把 Y 模块弄好就行。这事儿是很常见的。而加入 Rust 之后那可就不一样了：维护者改了 X 的 C 代码，Y 模块那边的 Rust 代码炸了，这谁负责？

按照原有规矩，C 的人就不得不去弄那个 Rust 代码，基本等于强迫 C 的人写 Rust 了，C 的人当然不愿意。所以 Rust 的人就承诺，如果改 C 代码把 Rust 改炸了的话，Rust 代码由 Rust 的人负责修。

这个承诺是很扯淡的。原本没有 Rust 的情况下，改炸了顺手修就完了，反正都是 C 语言。现在 C 的人要重构一下，还得要给 Rust 的人发邮件、等 Rust 的人来修。这要是 Rust 的人回复晚了赶不上合并窗口怎么办，这要是一两个星期都不回复（比如在度假）怎么办，要是跳出来扯皮那怎么办。而且说，有些 C 写的模块，都存在十几甚至几十年了，C 的人也维护了十几甚至几十年了，允许他们随时改进、重构代码，这确实是应该的，原有的规矩也确实如此。现在好了，重构得看 Rust 的人的脸色了。舆论上出事的模块都是这些，什么 FS 什么 DMA ，老模块了，被各个其他模块调用，一改就炸一片，未来哪天炸在 Rust 模块的头上那是必然的。

既然不可调和，那这事儿也简单，Rust 的人和（不愿意写 Rust 的） C 的人两边之间选一边开除就是了。别说什么得罪人，Linus 和 Greg K-H 连 Chinese 和 Russians 都能开除，那没有什么是不能开除的。

但是一转炒币真的有点绷不住。。。

rprx 最早开发的协议都有缺陷，有些缺陷属于前人早就踩过、甚至写进了论文明确指出有坑，然后那几个协议硬是踩进去。

说实话，发明几个不太圆的轮子也完全 OK ，毕竟开源免费，又没收大伙儿钱，不圆就不圆吧。可每次推出新协议，描述里永远是自吹自擂，秒天秒地秒空气，声量大得很。其他人给他指出缺陷吧，也不是好好说话的样子，有问题反正是不会承认的，协议也是从不附带文档的，想审查协议只能去翻代码。

评论区也是一股饭圈味，一边倒帮着说话，这楼里就有一个骂坛友屌毛不如的，粉丝骂人这件事我真的是从 2020 年看到 2025 年，真的无语。“一届一届换了多少新协议了，改过吗？换汤不换药啊！”

@coefuqin 4x V100 我想过。V100 的张量核心只支持 fp16 ，开了量化 tensor core 就是纯摆设，不开量化就更扯淡，64G 显存连 32b 模型都放不下，唯一能期待的就是 NVLink 全互连后低并发 decode 加速。6000 应该买不到 NVLink 底板 + 显卡吧，如果是 SXM 转 PCIe 的话我觉得还不如多买几张 2080 Ti 22G 。

其实也没那么难，这个模拟器只用运行 bootloader 和 hypervisor ，大概率是不需要支持浮点指令和 SIMD 指令的，起码能省下三分之二的工作量。

@qq316107934 楼主的这个问题就是因为 Windows 系统不支持 overcommit 策略导致的，这种情况下换个别的应用照样分配不出内存。

回楼主：
正经的回复是：多开点 swap （ Windows 叫虚拟内存）就能解决。
不正经的回复是：换个好点的操作系统吧，能开 overcommit 的那种，比如 Linux 。