Ketteiron

反重力本体就是坨不可用垃圾，各种功能都是残废

@datocp #5 是的，raid1 的最大缺点就是会同步错误数据。
https://serverfault.com/questions/2888/why-is-raid-not-a-backup

raid1 保证高可用，不保障数据安全，必须定时备份。
有人可能会问，我都拿出一块盘来备份了怎么还得另外备份，这是很常见的误区。
据我在多个 nas 群的观察，大部分人都是被人忽悠去上 raid 0,1,5,10 ，只知道优点，但不去了解这些技术的原理，并且错误地曲解了冗余和备份的关系。
raid 保障的是即使出故障系统也不会挂的高可用性，大多数 nas 玩家其实并没有这么高级的需求，系统挂了数据不丢才是最要紧的事，说实话这跟 raid 没半毛钱关系，反而会因为 raid 引入的硬件复杂度+软件复杂度导致丢了不该丢的数据。

只要问自己一句："当发生意外时，我的 nas 是不是不能停机需要继续提供服务？"
如果答案是 yes ，就去查看各种 raid 的优缺点，选一个合适的，并且依然需要备份兜底。
如果答案是 no ，只需要找一个简单的定时/增量备份方案就行，raid 在这里只会带来害处。

cursor 不就是个更加臃肿的 vscode ，这个标题给我看乐了。
没事可以把旧插件清理下，另外 vscode 一直有残留旧插件的 bug ，打开插件存储的位置会有惊喜。
你觉得 cursor 快是因为插件重装了，如果你把 vscode 也重装会更快。

mac 自带输入法的 keydown 和 composition 事件与其他输入法不一样，吞中文在 github 也算个常见 issue ，草台班子手搓组件碰到这种问题很常见，不正常的是要修两个月这么久，这确实是个很常见的小 bug 。

来晚了，issues 已经关了。
PS: 微信支付的 SDK 我觉得可以争一争世界倒数第一。

@retarded #5 正是因为需要不断执行代码，才需要元编程/高阶函数的语言，而内置 vm 和 eval 的 py/js 无疑是目前最好的选择。不知道你能否理解这里的成本是什么意思，它代表了环境隔离、上下文共享、执行所需的开销
CodeAct 的执行成本越低，能够验证的次数越多，这方面 py>js>其他
CodeAct 模式继续发展下去，需要一个更高效的中间语言取代 py ，当然 CodeAct 是否是最终答案谁也无法保证，还是先 py 糊屎 更保险

Rhai 看了下似乎是个比 rust-script 更好的选择

我个人更看好 js ，cloudflare 的 isolates 实在太便宜了
https://blog.cloudflare.com/code-mode/