Debian 13 把 /usr/bin/login 的实现从 shadow-utils 换成 util-linux 了，后者的手册里有一句话：

If one uses the command login, then the surrounding shell gets killed by vhangup(2) because it’s no longer the true owner of the tty. This can be avoided by using `exec login` in a top-level shell or xterm.

钢笔是一种没太多技术含量的消费类工业品，这种东西老中永远能卷出新高度。

前段时间 70 块钱买了支小品牌的国产钢笔，写感、做工、质感方方面面全部完爆我读书那会 200-300 的外国品牌钢笔。国外品牌？不好意思我现在真看不上了，就像机械键盘用过国产轴就再也看不上 cherry 轴一样。

哟，庙前冰室，连续几年拿过大陆 TOP1 酒吧的，没预约能喝上就不错了，虽然我觉得他家的特调相当一般。。。

@kaidong21 一楼正确个锤子，这种车轱辘话回答上到点子了？有半点信息量？ GGUF 的量化的资料特别少，学术界也不怎么研究，答案基本都只在代码里，问大模型能问出个锤子。

回楼主：

对单个张量而言，GGUF K-量化方法常见的只有 Q2_K / Q3_K / Q4_K / Q5_K / Q6_K 。而同一个模型里面包含了多个张量，每个张量的精度都可以不同。

而后缀 _S / _M / _L / _XL 的意思就是，如果这个量化模型里含有的高精度张量越多，就把他的规模标得越大。比如 Q4_K_M ，大部分张量是 Q4_K ，但对于小部分重要的张量（如注意力部分），就使用 Q6_K 。比如 Q4_K_S ，默认 Q4_K ，重要的张量用 Q5_K 。所以 Q4_K_M 的大小和精度都比 Q4_K_S 要好一些。

但是 _S / _M / _L / _XL 的具体定义可从来没有标准而言。这些规模根本不能说是一个标准，只能说这是一个预设。甚至 llama.cpp 中根本就没有预先定义好 Q4_K_L 和 Q4_K_XL 这两个预设，所以某某预设下的 _XL 甚至不如另一种预设下的 _M 大，也是正常的，因为这些东西本来就没有标准。

回到你说的那个模型，你点进 huggingface 的文件详情能看到每个张量的格式，Q4_K_M 中的张量有 Q4_K 和 Q6_K ，这应该是 llama.cpp 默认的预设。而那个 Q4_K_XL 中的张量基本只有 Q4_K 和 Q5_K ，是 UD 自己定义的预设。所以前者体积大，就这么简单。

这就是楼主想要的准确的回答（并且撰写过程中完全没有使用任何 AI ）

停产了所以涨价了，停产前全新价格最低 300 不到。

目前的价格已经没有购买价值了，同样的 SoC 方案不如买磊科 n60 pro ，国补后的价格也是 300 出头，同样能刷机，但是还带双 2.5G 的网口，规格就比红米的高一档。

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 。

@geelaw 谢谢提醒，之前只知道 return std::move(local_variable); 会有不好的效果

这个和 move 没有任何关系，std::move(std::string(...)) 中的 std::string(...) 本身就已经是可移动的右值了。在这个场景下有没有 std::move 都是一样的

file_ 变 eof 是因为 istreambuf_iterator 把文件流的内容读完了，读完之后就是 eof 。