nlzy 最近的时间轴更新 nlzy 最近的时间轴更新 |
nlzyV2EX 第 107263 号会员，加入于 2015-03-25 12:34:47 +08:00今日活跃度排名 16477 |
NaLanZeYu
nlzy
nlzy 最近回复了
74 天前 回复了 piero66 创建的主题 › 宽带症候群 › 家宽固定 ipv6 前缀实现静态公网 |
@rulagiti 自己改 odhcp6c 的源代码，其实不算复杂，我改过。
89 天前 回复了 kobeguang 创建的主题 › 路由器 › 接软路由做 ap，红米 AX6000 和小米 AX6000 和小米 AX3600，选哪两个？ |
别再推那破 ax6s 了，mt7622 属于上一代方案，残疾的 wifi 6 有什么好推的。而且 7622 集成度不高，再加上那段时间芯片荒，价格用今天的眼光审视就是贵的要死。我两年前也很满意 ax6s ，但是放在 2024 年下半年 ax6s 的购买价值就是零。
回到楼主的问题，当 AP 的话小米 AX6000 和红米 AX6000 都可以买。红米可玩性极高，开源支持非常好。小米有 2.5G ，当 AP 能跑突破千兆。你是纯当 AP ，不刷机我还是建议买小米。
至于 AX3600 不推荐了，不如上拼多多 80 快钱一个的 mt7981 多买几个。
回到楼主的问题，当 AP 的话小米 AX6000 和红米 AX6000 都可以买。红米可玩性极高，开源支持非常好。小米有 2.5G ，当 AP 能跑突破千兆。你是纯当 AP ，不刷机我还是建议买小米。
至于 AX3600 不推荐了，不如上拼多多 80 快钱一个的 mt7981 多买几个。
201 天前 回复了 kkocdko 创建的主题 › Linux › Linux 笔电的所谓省电技巧 |
基本同意楼主的看法。
我省电的方法基本也都是楼主提到的这些东西，买一台 AMD 7000 系列的核显本，启用 amd-pstate ，启用 conservative ，离电时限制 CPU 睿频峰值，关掉用不到的外设，关掉键盘背光。
我回复这条帖子的过程中电池放电功率基本维持在 5 ~ 6 W ，偶尔会短时跳到 7 W ，容量 71Wh 的电池用个 10 多小时完全不是问题。再加上 100W 功率的快充头，出差时的续航焦虑已经彻底治好了。
不过话又说回来，所有的省电手段都不如买一台搭载新款 AMD CPU 且电池容量在 70Wh 以上的核显本来得靠谱。
我省电的方法基本也都是楼主提到的这些东西，买一台 AMD 7000 系列的核显本，启用 amd-pstate ，启用 conservative ，离电时限制 CPU 睿频峰值，关掉用不到的外设，关掉键盘背光。
我回复这条帖子的过程中电池放电功率基本维持在 5 ~ 6 W ，偶尔会短时跳到 7 W ，容量 71Wh 的电池用个 10 多小时完全不是问题。再加上 100W 功率的快充头，出差时的续航焦虑已经彻底治好了。
不过话又说回来，所有的省电手段都不如买一台搭载新款 AMD CPU 且电池容量在 70Wh 以上的核显本来得靠谱。
350 天前 回复了 GCP 创建的主题 › 机械键盘 › ⌨️机械键盘里是不是 樱桃红轴 都有弹簧音？ |
我的也有，ikbc 的红轴，空格键的弹簧音很明显，其他键没注意过。
363 天前 回复了 baihekong 创建的主题 › 生活 › 必胜客披萨还是铁盘的好吃，手拍的不行 |
必胜客什么披萨都不好吃啊...
2023-06-01 00:12:33 +08:00 回复了 cathedrel 创建的主题 › Linux › Linux 系统，求一个类似 windows 系统下的 ProxyCap 的软件，找了好久没有可用的《顺便看看 chatGPT 有多煞笔》 |
如果想要整个系统的全部流量都走 socks 代理，用 tun2socks ，然后用 ip route 命令手动配路由表
如果只是想要一个支持 UDP 的 proxychains ，用 https://github.com/nlzy/nsproxy ，有编译好的二进制可以直接运行
如果只是想要一个支持 UDP 的 proxychains ，用 https://github.com/nlzy/nsproxy ，有编译好的二进制可以直接运行
2023-04-12 15:34:14 +08:00 回复了 dangyuluo 创建的主题 › C++ › libc++的 call once 为什么用 mutex/cv 而不是 atomic test_and_set |
@dangyuluo libc++ 的这个 static 令我瞬间觉得 Abseil 用 futex 实现的 spinlock 其实挺顺眼的。我收回“在我看来 libc++ 的代码是最合理的”那句话。
2023-04-12 08:04:16 +08:00 回复了 dangyuluo 创建的主题 › C++ › libc++的 call once 为什么用 mutex/cv 而不是 atomic test_and_set |
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 是真的丑陋。
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 是真的丑陋。
Select Language