如果前后端现在的工作模式无法改变，有一个解决方式是加一层 BFF(backend for frontend)，让前端的请求先走到带缓存的 BFF 层，前端自己去做 BFF 的缓存策略。

Intel dg1 估计是最便宜的了，最低不到 200 。能买到的基本上都是 HDMI DP dvi ，或者一个 dvi 换成 dp ，可以考虑上个转接头。

这个卡没什么优点，就是驱动省心功耗低，Intel 显卡的硬件加速还是到位的。

@HTravel #9

COM 本身是个好技术，有问题的是建立在其之上的 OLE 之类的技术。COM 技术的核心就是契约化的 ABI ，但契约化 ABI 不一定只有 COM 这一种实现方式。

我写这篇文章的一个目的就是以史（经验）为鉴，桌面图形系统才不过二三十年，谁知道下一个十年会是什么样子。如你所说到 XP 的系统还称得上成熟，能支持消费和工业场景，那为什么后面的系统就不成熟了，是微软不想吗，会不会是因为之前的设计决策把自己的路封死了？ Windows 在除开 PC 的工业或者消费场景中，存量市场很大，但新增市场几乎 100% 被 Android 和 Linux 瓜分了。

现在这个系列还没有讲到 Windows 的部分，我一直在强调一个观点，这个世界上就没有十全十美的东西，既要性能又要好用，还要兼容性同时想容易维护，那么代价是什么。还是那句话，停留在好于不好的争论上没有什么意义，了解和学习背后的设计理念更具有价值。

@imldy #19

M1 是 4P4E ，M1 Pro 有 6P2E 8P2E 两种配置，到了 M2 之后都是 4E 起步了。

@Saniter #6

我个人的观点是 D-Bus 的安全性问题更多是“时代局限性”，本身还是比较好解决的。

这篇文章上 HN 的时候我就看过，作者 vaxry 是 hyprland 的作者，也是有名的喷子了（非贬义）。

早期计算机系统（ Unix ）所谓的多用户，是建立在 UID/GID 逻辑上的，那个时候是真的一个人一个 UID 。当个人 PC 逐渐成为主流之后，UID 这个概念就不够用了，现在的 UID 已经不再对应某个人，而是用来区分不同的进程或者权限实体。

D-Bus 在设计的时候，是基于 ACL 方式将 UID 作为权限隔离的依据，这个逻辑在设计之初没问题，只是跟不上时代了。

文章中讲了 IPC 设计的第三条原则，不再使用 ACL 而是采取 capability 声明的方式来对权限做细分和隔离，这已经是个标准化共识。对于当前的 D-Bus 来说，比较大的问题是如何过渡到新的方案上。另外 Linux 内核也不是对内核 IPC 完全不接受，也许未来会有一个基于 io_uring+eBPF 的标准化 IPC 机制也说不定。在纯用户态做也不是不可以，只是形成共识会比较困难，最终可能还是红帽的人主导一个方案，然后慢慢等生态迁移。

@sjdhome #5

是这样的。我前两天看见说豆包训练输入法，虽然没有专门训练，但还是基本学会了双拼，不得已还要专门写代码让单字全拼的权重提高。（大意是这样）

所以就算是无文档的数据结构，让 LLM 来猜也问题不大，只要数据够多。

我想表达的重点不是 MCP 这样设计是错的，而是说作为设计者很难想象最终用户会怎么用。作为协议来说需要重策略轻机制，作为标准来说用机制保证它被按照设计意图来使用，不给出错的机会是很重要的。

我猜测保持不到一分钟这个现象应该是与 watchdog 看门狗机制有关。

Fn+P 能够提高功率说明这个按键大概率是 EC 直接拦截并应用生效的，此时 EC 可能会发送某个 WMI Event 给操作系统，它会期待操作系统回复一个响应信号（或者可能是某个调整风扇转速的指令），如果在 30s 或者更长时间里没有收到，就会出于保护机制将之前的功耗模式修改修改回去。

根据 Firmware Bug 的描述来看，可能 BIOS 就是有问题的，所以模拟 acpi_osi 也没用，很可能是 windows 里面默认安了一个驱动，因为厂家的开发知道 BIOS 里这个代码是有问题的，然后绕开做了修复。

@june4 #2

我个人认为 COM 本身问题不大，但是它是建立在一个不合理的基座之上的。本身这种规范还是比较有意义的，可以理解成如果 D-Bus 有类似 IDL 契约的化，有可能不会出现今天各种绕开 XML 定义的情况。

真正过度设计的是 OLE ，但对 Windows 来说属于“不可抗力”了，这个之后会展开讲。

@iamzuoxinyu #1

XML 的问题在于对人来说可读性和书写都是比较不友好的，JSON 可读性还过得去但一般也不适合手写，后面 YAML 也有类似的问题，后面 TOML 做得稍微平衡一些。不过这些都不重要，文章里也说了 D-Bus 协议还是二进制的，XML 是专用于自省接口的。

Linux 生态中通用的 payload 格式就是 stream ，无论 socket/pipe 都是二进制流，纯文本反倒是少见的。

D-Bus 混乱的确与用了 XML 之后，开发者不买账然后自己瞎传有关。

但是 D-Bus 的低性能 XML 只占了非常小的原因。核心在于 D-Bus 本身是在内核之外的，相对内核 IPC 至少多两次上下文切换。实现方面，daemon 实际是个星型总线，需要额外处理广播订阅以及安全机制，早期为了线程安全锁粒度也比较粗。今天正常用到的版本已经和二十年前完全不一样了，性能完全够用，只是类似 Wayland/PipeWire 都因为别的原因选择了不用。

Windows COM 有自己的问题，下一个帖子就到了。

@dlyxy #15

如果你的目的是学术或者研究性质的，Google Fuchsia 的 Zircon 内核是个很好的学习对象。如果是应用向的，那么 C/Rust 什么的不重要，重要的是要清楚你在做什么，想要解决什么问题，如何落地。

我在文章中提到的“过早”优化，反映的也是这样一种现状。很多提案想法都是空中楼阁一样的存在，设计者并不知道下游实际上是如何使用某种功能特性的，也不清楚他们真正的痛点与需求。就比如 DPDK 是个非常小众的领域，我前两年讲 Go 的帖子就提到过将 DPDK 用 Go 重写的例子，实际上用今天的眼光来看 AF_XDP+io_uring 已经不需要内核绕过了，eBPF 提供了非常好的基础。

目前 Linus 领导下的内核开发是非常务实的，所有想要进入内核的内容都要回答一个极其严肃的问题，是不是一定有必要。

@Maboroshii #10

最早 Linux 是 Linus 的个人项目，说弱鸡不至于。在 1992 年确认使用 GPLv2 开源许可证的时候，关键的子系统比如 ext 文件系统，网络栈就已经可用，只是比较粗糙，这个时期几乎所有代码都是 Linus 本人写的。1993 年的时候红帽成立之后就开始卖 Red Hat Linux 了。直到大概 1998 年之前，多数代码还是来自于用爱发电的个人。之后 RH/IBM/Oracle 几乎都在同一时间加大对 Linux 的投入，这之后的代码贡献逐渐以这些公司的雇员为主了。用爱发电不是不行，只是效率上肯定没有砸钱来得直接。

@chingyat #20

systemd 会在后面的章节里面。

@moudy #5

如果只是说内核的性能，一般是关注上下文切换、IPC 、锁和 IO 。其中锁和 IO 多数与资源有关，上下文切换主要与硬件相关。所以内核能做的优化或者说实现方案主要是减小锁的粒度和范围，异步/缓冲/零拷贝 IO ，剩下的就是 IPC 设计相关了。嵌入式领域如果能用主线内核最好了，但多数时候可能绕不开上游厂家的 bsp 。我个人理解多数情况下不需要关心这些系统层面的安全和性能，毕竟关心了可能也没办法动。如果有极高的 io 类性能需求，多数可能要走类似 dpdk 这样的用户态方案。

@zzxx3322 #17

Wayland 从纸面设想走到实用也用了二十多年，关于发展史方面我也没见过什么资料。由于大部分的贡献都来自红帽的员工，所以邮件列表中的讨论反倒成了历史记录。这些内容过于分散，你可以试试问 ai 更具体的问题然后验证再总结。

尽管在桌面上 wayland 推进没有那么快，但据我了解，嵌入式领域（特别是车机）很早就有应用了。对于嵌入式设备来说，基于 wayland 跑轻量化合成器比跑 X 性能更好，也要更容易开发维护。工程化方面反倒走在桌面前面。

@xtreme1 #7
@levelworm #8

单独说图形系统有点笼统，还要拆分之后做比较。对未来方向的理解三家都差不多，只是改不改得动的问题。

@hronro
@craftsmanship

就只发在 V2EX 上，我认为文章内容的价值是一方面，这里的讨论同样重要。对我自己来说这些内容更多是总结整理，放在这里比放在个人博客更有生命力。（我确实没有写博客的习惯）

@levelworm #1

是的，我认为他和 Linus 一样都是能兼具工程管理和技术开发能力的人，而且在几十年前就对未来的技术发展有非常深刻的洞察。NT 有很多优秀的设计都是出自他本人。

我感觉这个实现和 podman/macOS 非常像啊，应该是基于 libkrun 的封装吧。

没来得及看代码，请教几个问题。如果是 rust 的库，那调用 gvisor 网络栈应该是直接打包二进制子进程的形式吧，有考虑过用 go 吗？问这个主要是我不清楚它运行时需要哪些依赖，有没有可能做到完全的静态链接。

对 oci 镜像的支持是如何实现的？我能想到的是找个临时路径展开，不过这样做好像比较麻烦，其他方案要支持 macOS 比较难。

这个实现里有跑 guest 应用吗？感觉处理 tty 也比较麻烦。

在讨论安全之前，要先定义什么是安全，或者说要应对的威胁模型是什么。

- 如果是 token 伪造，那 session （也就是你说的 token+redis ）和 JWT （双 token ）没区别，都是后端签发的。

- 如果说是身份冒用，两者也没区别，只要持有合法 token 就视作有效。

- 如果指的是 token 撤销，那么 session 比 jwt 好一点，因为它可以实时撤销，而 jwt 只能等它过期。



“性能也不见得差”这句话有毛病。session 方案的逻辑是有个中心化的实时鉴权后端，要负责对所有业务请求进行身份认证。现实里这个单点是极其脆弱的，水平扩展能力也非常有限。

由此诞生的 JWT 之类的方案，并不是要做得比 session 更安全，而是要解决 session 方案的性能瓶颈。

准确来说，解决性能瓶颈靠的是通过无状态 AccessToken ，将鉴权转移到每个业务单元，业务单元只需要解码而不需要实时后端查询。

为了让 JWT 方案也能达到和 session 方案一样的安全水平，那就要将 AccessToken 的有效期设定得越短越好。

但是 JWT 方案是无状态的，如果要获得新的 AccessToken 是无法像 session 一样自动更新的，必须要走一遍完整的登录验证过程。


所以就有了 RefreshToken ，它解决的是方便获得短时效 AccessToken 的问题。这个“双”token 的重点是方便。

PS 稍微补充一点：如果是 web 应用场景，RefreshToken 多数存储于 HttpOnly/Secure/SameSite=Strict cookies 中，防止 js 读取，也避免 XSS 攻击（因为即便后端被注入恶意代码，这个代码被当前用户执行后也无法获得 cookie 内容）。AccessToken 存储于内存变量中，通过 js 代码以 header 的形式传递，这样可以防止 csrf 攻击（因为跨域的时候不可能带上这个 header ）。