kuanat

如果前后端现在的工作模式无法改变，有一个解决方式是加一层 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 有自己的问题，下一个帖子就到了。