别再推那破 ax6s 了，mt7622 属于上一代方案，残疾的 wifi 6 有什么好推的。而且 7622 集成度不高，再加上那段时间芯片荒，价格用今天的眼光审视就是贵的要死。我两年前也很满意 ax6s ，但是放在 2024 年下半年 ax6s 的购买价值就是零。

回到楼主的问题，当 AP 的话小米 AX6000 和红米 AX6000 都可以买。红米可玩性极高，开源支持非常好。小米有 2.5G ，当 AP 能跑突破千兆。你是纯当 AP ，不刷机我还是建议买小米。

至于 AX3600 不推荐了，不如上拼多多 80 快钱一个的 mt7981 多买几个。

基本同意楼主的看法。

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

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

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

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

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

你写的程序有问题，SHA-1 在现代 CPU 上不用硬件加速也能跑几百兆每秒，git 算 SHA-1 的性能完全就是合理水平。

既然你是 go 用户，那为什么不看看 go 标准库里的实现呢？手写的汇编，广泛验证的质量，详实的注释，连参考文章都列的清清楚楚。完全值得一看。

如果想要整个系统的全部流量都走 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 那就可以，启动之后的容器内部也是全部走代理的。

@yanzhiling2001 我发的这个是另一种思路，不用 ptrace 的

光猫卡瓶颈的可能性比局端搞鬼的可能性大得多。没桥接的时候基本都是硬件加速，改了桥接还有没有硬件加速可就不一定了。

@lambdaq 文件大小无论是一样还是不一样，选择前缀攻击的方法和算力成本都大差不差。

我一直很好奇 V 站网友对 MD5 以及文件大小来抗碰撞的迷信到底是从哪来的。两年前有人在 V 站发帖，问 MD5 作为唯一标识可不可行，当时也是不少人觉得加上大小就可行了。（笑

> https 有校验机制，只会下载失败不会下载错误。

对的。严谨点说这叫数据完整性，不叫可靠性。

a) 修改常量对象属于未定义行为
b) 若程序出现未定义行为，则程序可以做任何（匪夷所思的）事，整个程序失去意义

用 fish 还是会有些影响的，实际使用下来有一点感觉是，网上找到的比较复杂的 one line 的 shell 命令放在 fish 上大概率跑不了的，特别是设置成默认 shell 之后还会导致一些软件不兼容。建议像 #4 说的，不要在 /etc/passwd 里设置默认 shell ，而是在自己常用的终端模拟器上设置。

@jousca 人们受 NAT 荼毒已久，甚至忘了 IP 网络最初的形态，以至于切换到 IPv6 之后变得无所适从。

IPv6 不能用 IPv4+NAT 那样的“LAN 口和连接到 LAN 口的设备是私网，用私网地址，WAN 口是公网，用公网地址”去理解，这是错误的。

正确的理解是，LAN 口和连接到 LAN 口的设备都分配了公网 v6 地址，这些地址全球可达，LAN 口和这些设备所组的网是互联网的一部分。这也是为什么路由器的公网 v6 地址显示在 LAN 口而不是 WAN 口的原因，这不是显示 bug 。

至于 WAN 口和 WAN 口连接的对端有没有分配全球可达的 v6 地址，这点不重要，反正都会有本地链路地址能作为路由的下一跳的。