nlzy

基本同意楼主的看法。

我省电的方法基本也都是楼主提到的这些东西，买一台 AMD 7000 系列的核显本，启用 amd-pstate ，启用 conservative ，离电时限制 CPU 睿频峰值，关掉用不到的外设，关掉键盘背光。

我回复这条帖子的过程中电池放电功率基本维持在 5 ~ 6 W ，偶尔会短时跳到 7 W ，容量 71Wh 的电池用个 10 多小时完全不是问题。再加上 100W 功率的快充头，出差时的续航焦虑已经彻底治好了。

不过话又说回来，所有的省电手段都不如买一台搭载新款 AMD CPU 且电池容量在 70Wh 以上的核显本来得靠谱。

我的也有，ikbc 的红轴，空格键的弹簧音很明显，其他键没注意过。

必胜客什么披萨都不好吃啊...

如果想要整个系统的全部流量都走 socks 代理，用 tun2socks ，然后用 ip route 命令手动配路由表
如果只是想要一个支持 UDP 的 proxychains ，用 https://github.com/nlzy/nsproxy ，有编译好的二进制可以直接运行

@dangyuluo libc++ 的这个 static 令我瞬间觉得 Abseil 用 futex 实现的 spinlock 其实挺顺眼的。我收回“在我看来 libc++ 的代码是最合理的”那句话。

ChatGPT 的实现已经完全错了。合理的 call_once 应当会等待其他线程并阻塞的，只要没看到阻塞的代码就肯定是错的。

Abseil 没有保证异常下的语义，所以不能用来代替 C++ 标准里的 std::call_once 。

只有 libc++ 实现了全部的 std::call_once 的语义。

在我看来 libc++ 的代码是最合理的，call_once 里的第一行 acquire_load 已经是一个 fast path 优化了，如果这个 fast path 进不去，没有理由再去利用其他的机制（包括 test_and_set 或者 compare_and_swap ）增加一个 fast path 优化。而且 call_once 是绝对不可能用无锁算法实现的，因为 call_once 会等待其他线程，那在用户态等待其他线程不用 mtx/cv 那还能用啥？在我看来 Abseil 自己包装一个 spinlock 是真的丑陋。

@iamqida 还未支持

@lixile docker 是 C/S 架构，实际操作都是由后台的守护进程 dockerd 完成的。要是用 nsproxy 启动 dockerd 那就可以，启动之后的容器内部也是全部走代理的。