nlzy

如果想要整个系统的全部流量都走 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 有校验机制，只会下载失败不会下载错误。

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