aloxaf

@LnTrx 小米此举确实忘记了初心。但是这和粉丝运营有啥关系，小米用户总不至于全是被刷机吸引来的吧。

@heimoshuiyu

你说的「缓存因为意外无法写入」，任何文件系统都存在这个问题，对缓存利用越激进（如 ZFS ）就越容易有这个问题。但 btrfs 和 zfs 一样是抗断电的，它和 ZFS 一样有校验、有 CoW ，元数据默认存两份，虽然会炸，但也不是这个原因炸。

zfs 通常性能确实比 btrfs 好，这类 CoW 文件系统都无可避免地存在碎片化问题，zfs 靠缓存来弥补。btrfs 在这方面只能根据负载来手动优化。

比如你说 ls 一个 10000+ 文件的目录要 5s+，我猜是你没有启用 noatime 挂载，导致每次访问都会修改 atime ，在 HDD+小文件+CoW 的组合下，这简直就是灾难。
又比如你说 sqlite3 很慢，这也是碎片的锅，btrfs 确实不适合数据库这种负载。如果要用，建议使用 chattr +C 对数据库关闭 CoW ，可以有效提升性能。

btrfs raid1 没有读取加速是真的，但是 4 坏 2 就会导致数据全部丢失没听说过，那 2 块盘 raid1 岂不是一坏就炸 。btrfs 在降级状态默认会拒绝挂载，是不是和这个搞混了？

最终结论我没什么意见，我自己也是 nas zfs + PC btrfs 。

看了下前面人说的猫咪大战争，这个游戏就是每个账号初始生成一个种子并且永久不变，而且用的还是非密码学安全的随机算法，而且计算最终抽卡结果用的还是简单的取模，这才被人做到了预测自己的抽卡结果，而且也只是预测，无法控制。

如果想做到控制结果，那必须得有其他方法来影响这个种子，但是这样你能猜到算法的难度就大大增加了。我觉得只有阅读了服务端代码的拉普拉斯抽卡妖能做到。

挺难的，不安全的伪随机数生成器最多让你能预测下一个数字。但你不知道服务端具体是怎么使用这个生成器的，更不用说为了减少极端的抽卡体验，不少游戏都不是真正的随机。

rust 的借用检查器一直在改进

它早期是基于词法作用域的，所以会出现你书里说的那种情况，你在 godbolt 里测试早期的 rust 版本就能看到报错了。当时写 rust 程序常常需要把一些创建临时引用的代码用大括号另起一个作用域，看起来莫名其妙的，就是为了规避这个问题。

后面引入了 non-lexical lifetimes (NLL) 版本，会智能分析这个引用和其他引用之间是否存在冲突，而不是粗暴地看作用域，大部分情况下都能给出复合直觉的结果。少量 edge case 可能要等下一代检查器 polonius 了，不过这几年都没啥动静。

LZ 用的是啥手机啥安卓版本

跳过编译器，直接生成机器码？你有考虑过 AI 的感受吗，编译器能干的脏活累活让 AI 来干的意义是什么？

最能说服我的理由是——你不信任使用 at 的客户端。

比如第三方提供的集成服务，我不希望它能拿到有效期很长的 at 。短 at + 长 rt 就能确保用户不使用服务后它能迅速失去对用户资料的访问权。

关于 Go 有个有趣的点，那就是它官网的文档和 Playground 都不提供语法高亮，因为 Rob Pike 不喜欢语法高亮。

Go 的设计风格，从这里就可见一斑。