试了一下，快是确实快，准确性就不太行了

@kxg3030 我记得在 CCPC/ICPC 等算法竞赛中，java 自带的大整数有时候挺有用的

没毛病，魔力即是能源

@lesismal 大部分人是能够做到根据实际情况做出技术栈的选择的。但是问题在于一部分用语言圣战掩盖自身无知和懒惰的人发出了巨大的噪音。

这部分人无限拥护自己所支持的语言的目的不是为了使某个项目变得更好，而是为了通过语言斗兽棋强行体现自身优越。

内存安全的 rust 是很好，但是如果没有在延迟上有特定的要求，我可能更倾向于支持 GC 的语言。

GO 无脑堆逻辑确实快，但是占一多半的 if err != nil return nil,errr 也确实碍眼。

我赞同你的 curd 是为这个世界服务的观点，在兼具高性能和安全要求的地方推广 rust 无可厚非。

语言的特性是一个事实，没有一个功能或语法就是没有。至于是否属于功能缺失，我觉得判断标准确实要落在是否影响实际工程应用上。

确实是大坑，每个库的 logger 接口都不太一致，需要分别兼容。

在我看来，不管是将 GO 的"功能缺失"强行解释为"哲学优越性"，还是以内存安全为由在各种项目上强行推广 rust ，这些行为都属于忽略实际条件去强行套用解决方法，本质上是编程领域的唯心主义。这种工具崇拜不仅引发争论污染公共讨论空间，也无助于提高自身水平。
必须认识到，编程的价值在于解决实际问题。脱离工程背景无限拔高某些设计取舍只能暴露自身视野之狭隘。
保持对技术本质的清醒认知，才能在快速迭代的生态系统中构建可持续的工程能力。
我最多只能说：在我遇到的某个特定场景下，使用某些语言/工具是合适的。但是绝对无法断言，这些语言/工具能满足任意场景的需要。
不过我倒是不反对在工程上的约束较为宽松时（比如不涉及合作开发的项目、性能不关键的项目等等）使用自己最熟悉/最喜欢的工具。

本来我 IOT 网络是用独立路由单独播一路的，这下得折腾防火墙和路由策略了。

@CapNemo 修正：就视频场景来说，应该是写少读多吧

就视频场景来说，应该是写多读少吧，那 ECC 可能就用处不大了。毕竟只要写入一次成功，内存里再怎么位翻转都不影响数据安全。而且视频本身写错几个 bit 问题也不大。建议将预算投入到冗余电源/高质量硬盘/定期备份等更直接影响数据安全的环节。

如果想一台设备能同时体验不同的操作系统。那么建议直接上 PVE 。Proxmox VE + 黑群晖虚拟机 + ZFS 存储池这样。然后尽可能加大内存。不过虚拟机多了之后主机重启操作的成本也会增加，这就看权衡了。

我猜是开启这个选型后直接调度到关闭超线程的主机上

怕不是某种敏感词检测？

看上去比现有的那个 app 美观。请问能支持 vnc/xterm 远程控制虚拟机吗？

一套问题如果流行起来，很容易被针对优化。基本上是无解的。

建议增加地图视图，收藏的城市增添图钉，用颜色表示状态。

Router1 <-> Server <-> Router2

在两个 Router 的“网络” -> “路由表”中，添加一个新的静态路由，将另一个 Router 的 IP 段指向 Server

Server 里配置两条静态路由，把两个 Router 的 IP 段分别指向对应 Router 的 WireGuard 地址即可

SELECT o.order_id
FROM t_order o
JOIN t_order_detail od ON o.order_id = od.order_id and od.item_name = '电脑'
JOIN t_order_detail od2 ON o.order_id = od2.order_id and od2.item_name = '记事本'
GROUP BY o.order_id

需要 GPU 的时候 Ubuntu ，不需要则 Debian

事前审核的话会不会效率有些低？是希望能配置审核规则吗？还是要求能事后审计？

你会发现，重要的文件没有那么多。多复制几份成本是可以接受的。