@iX8NEGGn 我在 linux 下用的就是方法 2 ，左 shift 始终是英文（考量到游戏和快捷键一般用左 shift ），右 shift 始终是中文。

@beyondWALL 一直想换 Pixel ，奈何 Tensor 一直不给力啊

我的感觉和你一样，像大型屎山项目，由于你对业务和项目本身都非常了解，当有新需求时，你很快就能判断出最合理的实现方式。但 AI 不行，即便有 RAG 和手写 .cursorrules 的加成，你还是会花费大量的时间来纠正它的思路。
具体到实现上更蛋疼，如果这个项目用了大量轮子或者小众的库，那 AI 生成的代码大概率是错的。Cursor 还好，可以添加自定义文档（论好好写文档的重要性），有些工具压根就没考虑过这个问题。

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