xfs 没记错的话即使恢复数据也无法恢复文件名

节哀

是的，Go 文档颇有上世纪风格，在 21 世纪还这么设计，除了故意折磨用户之外我想不出其他理由了。

随便举几个例子：
1. 一眼望去基本就三种颜色，黑色的背景、白色的文字、蓝色的链接，毫无区分度
2. 代码连语法高亮都不给
3. ToC 这种东西放在开头毫无意义，单纯挤占正常阅读空间
4. 边上可以全部展开的导航栏又不展开，到这里又开始省空间了？
5. 搜索界面跟 GPT2 设计的一样，仿佛没学过布局，而且鼠标移上去下划线是竟然是出现在类型上？？
6. 不能跨模块搜索

我觉得这玩意儿能气死 UX 设计师

@ALLROBOT

> 我应该找个不带金融意义且无上限发行的虚拟币，假设每人注册一个虚拟地址就赠与一个 token ，每一次下载别人文件就付小额 token ，分享的文件被别人下载就获取小额 token ，也可以设置 token 不到一定额度就禁止用户下载文件，用于鼓励一些人上传文件互相分享应该可以吧？

你怎么阻止我生成一堆地址而获得无限的 token 呢。而且你这个经济系统里面的 token 「产生」方式只有新地址？这完全难以为继啊，就是在逼着人不断生成地址。

google 的语言设计水平和 MS 比就是一坨翔（用 golang 和 dart 有感

大多数虚拟货币都不追求价值稳定，因为稳定的话就没炒作空间了……

稳定币一般都是有抵押的。纯智能合约实现的也有，这类币叫算法稳定币，比如 UST ，它通过和 Luna 之间套利来维持其价值。然后 Luna 前两年归零了，从 100U 跌倒小数点后几个零。

@heimoshuiyu #41 这是 raid10 吧，那确实坏两块盘有大概率炸。

@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 的设计风格，从这里就可见一斑。

没用过 MongoDB ，不过这类时间序列数据查询的优化方向都是差不多的：
1. 提前按天、按小时聚合数据，根据查询范围来调整返回数据的精度。就像楼上说的，一个月的数据得上百万条了，前端要这么多数据干嘛。
2. 原始数据可以存的时候就按小时打包来存，没必要每秒生成一条记录。
3. 你这数据量也不大，但不知道 MongoDB 存这些数据效率如何，如果太占空间可能要考虑对旧数据降采样（你真的需要查询三年前某分钟内每秒的数据？）或者转冷存储。

不过还是推荐直接用数序数据库，不仅速度更快还节省空间，而且「优化花费的时间」未必比「迁移花费的时间」更少，除了 influxdb 外也可以看看 timescaledb ，对于有 sql 经验的人来说迁移真的方便）

没用过绿联，这玩意儿没有快照功能吗？

而且用同步的话，没有文件历史版本的功能吗？

我不相信 FF 能犯这么低级的错误，这不是实现问题，*.example.com 是明确不应该匹配 example.com 的

建议 LZ 检查一下 FF 访问 example.com 时显示的证书是啥