我的 CPU 过热就自动降频，那就没那么热了。

投屏软件也是有莫名其妙的 BUG ，CPU 突然会跑满，无语。又不能完全关闭，只能写了一个定时重启监控。

@bclerdx DNS 出状况的情况不多，一开始没往哪儿想。

@duan602728596 楼主说请求都是实时的，估计用 br 很难，这算法太慢了。

zstd 可以，gzip 也可以。

我个人网站 SSL 挂了，最近为了性能，修改了一下发送缓存大小，但是 SSL 没改。

最后问 GTP4o ，他告诉我 HTTPS 下，APPLICATION_DATA 不能大于 16384 字节，改了网站就恢复了。

AI 真是越来越聪明了，赞一个。

我看老外升级开发机器，用 AMD 也挺多的。便宜大碗。

“现在经常编译速度会比较慢”，可以按照自己需求微调一下，我以前安卓编译也慢，后来发现 cpu 主要卡在 zlib 打包阶段，把压缩比调成非压缩，速度就很快了。

有些狗比较神经质。不牵绳子，99 次不咬人，有 1 次咬人，这狗生就完蛋了。

建模场景很温馨。去这个兄弟的 github 主页看了一下，竟然是 threejs 的讲师，厉害的。

但是现在 web 技术演化，应该向 wasm+webgpu 靠拢了。

threejs 写个小游戏 DEMO 没问题，写大游戏的成本投入，一点都不比传统游戏开发低。

@wwd179 "电源风扇噪音。"

好一点的电源，都有风扇启动功能，如果你真的买 N100 ，说不定平时风扇都不转的。

"缺点就是硬盘容量不够。usb 接口带不动多个 HDD 硬盘。"

有外置 20W 独立电源的 SATA 硬盘转 USB3.0 接口外设，能解决供电问题。机械硬盘也就是启动电流很大。

我家里几台 24 小时的机器都是 arm ，省电没得说，比 x86 强。性能是 RK3588 ，不弱就是了。

我以前也是手动启动程序，第一这个是低频操作，只有更新服务器版本时才需要。第二有可能启动失败，需要查看 log 日志查原因（内存不足之类的，服务器配置很菜，运行了太多的后台程序）

后来随着技术迭代，渐渐换成了服务器模块热加载，同时限制了一些占用内存的大户的使用量，就没关心过这些了。

你这 350W 电源 overkill 了吧，硬盘功耗很低的，就算 5W 一个，你才两个 8T 硬盘。

N100 也是超低功耗，又没显卡，用普通外界笔记本电源足够了。

用双向同步软件就可以，我就是。

但是流程和提交代码类似，两边同时改，同步时难免会有冲突。90%的情况下是新文件覆盖老文件，但是还有 10%的情况，需要手工干预。

程序员玩合约，你需要自己爬取历史数据，用算法自动回测一下，看看利润和胜负概率是多少，最后才能加大资金。

你这个一拍脑袋就入局，和把钱丢水里基本没区别。

@gamexg 是加盐啊，但是传统加随机盐，一个用户算起来还是太快了。

而 OP 的默认算法，一个用户在我机器上最起码要 3 秒才出结果，实在是够慢的。

我简单科普一下，可能有些新人不了解 PBKDF2

一个 hash 函数，比如 sha256 为了防止被破解，需要加入密码，起名为 HMAC 。

而 PBKDF2 ，就是针对于 HMAC 递归计算，次数就是 OP 里的 1000 万次，计算量的增加，大大加强了 HMAC 的安全性。

而网页登陆的用户名，就是 hash 函数的密码(也叫 salt)

这样做有什么好处呢，那就是针对用户名 A 建立的彩虹表，无法用于用户名 B/C/D 。不同用户名只能单独计算，这就增加了密码防撞的安全性。

@Chad0000 没有固化，现在的 hash 和以前的 hash 不一样了，都是加密码的。

比如 wireguard 协议，里面用的是 blake2s 算法，和 OP 这个类似，你密码一变，hash 结果天差地别。

这算法自古以来就有，早在 linux 还叫 unix 年代，password 就为了防止本地账号密码破解，启用了递归 hash 算法，那时候是 md5 递归 1000 次，代码里还专门注明了一句：just to make sure things don't run too fast 。

iterations: 1e7, 那么大的递归数值？绝了，确实普通 PC 没办法轻易破解。

就是怕老 arm 手机浏览器，会算不过来。