@gigishy 提高可靠性到百年是加钱能解决的问题，但这要看愿意付出多少对应的成本。

只考虑单一技术方案肯定是不可行的。磁带也只能保存 30 年左右。就目前的科技水平，还是考虑每 10 年挪一个地方储存最安全。

我想到的一些措施：

软件的：

1. Parchive 添加奇偶校验恢复记录
2. 机械硬盘组 RAIDZ
3. 至少上两个云服务，里面至少一个企业级服务，例如 Amazon S3/Backblaze B2/Onedrive/iCloud…，Amazon 、阿里云、腾讯云都有冰川深度储存，价格相对比较低。

硬件的：

1. 光盘可以看看 M-DISC 蓝光，声称可保存一千年
2. NAS 加 UPS 防断电，监控健康度。机械硬盘 10 年是下限，在此期间内若坏了属产品质量问题
3. 歪点子：有一些有公众历史意义的文件（例如家族族谱、百年前的个人记录），可捐一份给当地博物馆或图书馆，或者打印成胶片储存

> 尝试过光盘、磁带、机械硬盘（包括 nas ）（都有过丢失数据的惨痛经历）

想听听你的光盘和磁带是怎么丢数据的。保存不善？

@okakuyang

> 现实中很多人都不知道安卓边缘返回的手势这个操作

？？？我满头问号，请问你活在哪个平行世界？

口口声声「理性讨论」「不要上升人身攻击」，然而自己把「方向反了」上升到「不跟手」，继而滑坡到「不优雅」。这个「不优雅」和「真正优秀的交互」是谁来定义的？你吗？

那我也来定义一个：真正优雅的交互，应当是便利且容易学习的，而不是为了所谓的一致性增加交互成本。综上，我认为 iOS 所谓的“随处放返回，一会左上角一会右滑”特性，并不是一种优雅的设计。

反驳观点没有价值，因为全是不客观的定义和推断

@yiyiniu 就按照上面日志的 Flutter fix 里写的操作啊。先看看你的 Gradle 是什么版本，然后对照 Compatibility Matrix 看看需要什么 Java 版本。Java 21 只有 Gradle 8.4 以后才支持，要么升级 Gradle ，要么降级 Java

这不是说得很清楚了，你运行 Gradle 的 Java 版本和 Gradle 支持的版本不匹配

特定 IP 不知道，这里有个 CDN 测速

https://www.cdnperf.com/

@listenfree V2EX 禁止发送 AI 生成内容，一举报一个永封

@ffc 复议，可以看我的使用体验 https://www.v2ex.com/t/1121167

@Gilfoyle26 通用量子计算还没实现，现在的量子计算和冯·诺依曼提出的「计算机」完全不是一个东西，先了解一下物理学再大胆预测吧。

现在的量子计算是非常 specific 的设备，只能解决某些特定问题。对绝大部分算法，尤其是那些非概率性过程，量子计算机只会更慢而不是更快。例如，quantum memory 永远只能同时访问所有位，而且在物理上不可复制。在安全通信领域这是优势，但在其他算法领域，你肯定不会想要一个没有 memcpy 的计算机。

量子计算不是魔法，不会神奇地让数值求和、网页渲染加速 100 万倍。

@x4gz 借楼问问这个性价比怎么样？我还在观望，和 mac mini m4 同价位的小主机选择太多了，这个有什么优势呢？功率低？接口多？性能高？内存焊死的 16+256 ，后面想扩展很麻烦吧

有个 Long Animation Frames API ，可以在动画和响应掉帧的时候调用指定回调： https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/Long_animation_frame_timing

可以设置一个 threshold ，比如掉帧在 5s 内超过 10 次就改为弱动画。

不允许重载运算符的语言都是这样的，然而重载运算符也有别的问题。

我觉得比较好的处理方法是中缀函数（ Infix Operators ），比如 Kotlin 、Scala 、Swift 和 Haskell 都有这样的功能：

```kotlin
infix fun Int.foo(x: Int) = this + x * x

print(2 foo 3) // 输出 11
```

感觉可以用 Python 、C++ 之类的自己写一个，zip 库都是内置的。

至于现成的解决方案，确实没听说过。关于「文件太大不好解压」这个问题，倒是可以用分卷来解决：我之前测试过，分卷之间是独立的，可以解压完一个、删除一个，反复给解压出的文件腾空间。

@kneo

> 这玩意不就是 redis 的 fork 吗

照你这么说，Android 一定不如 Linux ，MariaDB < MySQL ，OpenJDK < Oracle ，LibreOffice < OpenOffice…

> 能说下哪比 redis 强

我举几个主要的：多线程支持更好，性能高得多（部分场景相比 Redis 提升三倍： https://valkey.io/blog/unlock-one-million-rps-part2/ ）。

另外一个有趣的事实是，在 Redis 项目中，Redis 公司实际上只参与了 20% 的提交，而目前 Valkey 上的前 Redis 开发者比 Redis 还多。因此，说 Valkey 才是正统的 Redis ，而现在的 Redis 已经被转手卖给商业公司，比较合适。

用 Valkey 一年多了，挺好的。除了文档不如 Redis ，哪哪都比 Redis 强。

@laikick 已 block ，魔怔了

粗略看了一下文档，感觉不是 Python 的问题，而像是 DiceDB 的问题。

DiceDB 本身就不严格限制类型，看起来更像是「所有对象统一作为 string 存取。但如果 string 能被解析成整数，也支持数值操作」，甚至它的 GET 命令也是 returns the value as a string 。

那你这里的设计和上游保持一致就行了，def get(key: str) -> Optional[str]。如果真需要转型，可以加一个命名参数：

def get(key: str, auto_convert_type: bool = False) -> Optional[Union[str, int]]