比较大的开源项目会存在贡献者协议，通常会有给控制项目的组织授予修改项目许可证的权利这样的条款，严格一点的会限制能升级到的协议。反面例子也存在 Linux kernel 就是这样的原因被锁死 GPL2 。但无论如何，一般的开源协议对当前版本代码的授权是不可撤销的。因此单方面修改通常会导致 fork 或重新实现（比如 redis,es)。

对 CLion 的印象主要是比较方便的调试功能和在 ICPC 赛场上崩溃带来的心理阴影。

第二种方案存在将权限和路径绑定的问题。接口需要版本迭代或增加不同参数的版本时容易引发问题。
可以考虑将第二种方案里权限配置改为使用带通配符的路由。不过设计的太复杂又容易因为配置错误导致越权。

如果指 1 楼的情况，那就是一个引用传值，避免反复拷贝一些比较大的 struct 等。如果指 unsafe 里的指针，这个主要是为了方便搞一些强制类型转换和链接 c 语言库。

通过网络连接 USB => 使用 USB/IP 项目 https://usbip.sourceforge.net/
通过网络连接硬盘柜 => 使用 NAS

理论上存在直接在主板上魔改，把网卡到 CPU 之间的连接替换的方案，不过

1. 不知道网卡和 CPU 之间是 PCIE 还是 USB
2. 信号完整性很难保证

@yanqiyu 是这样的，如果在内存里就坏了是无可奈何的。我想表达的意思是由于写入占比较低+视频文件对位错误的容忍度，因此 ECC 的必要性会降低一些。

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

@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 远程控制虚拟机吗？

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