都是“开源”，但不同方式之间差异很大

有一些是软件本身开源但不接受贡献 or 不维护社区，这种就只是公开代码而已，开发都在内部仓库，每次发版后就直接往 Github 上的仓库提个只有一条 commit 的上万行 pr 完事。

大部分商业项目开源都是将组件设计为可插拔的，高级功能的组件是单独维护的，这样核心部分可以按正常的开源项目来维护和管理社区。或者内核完全开源，但产品化功能（例如管控平台、云服务）闭源，就我接触到的数据库、存储开源项目而言大多是这样

@imes 生态不够成熟，语言本身也在快速发展，经常有新特性和新设计模式冒出来，所以被 Rust“重写一切”的也包括这些库自身

@xue777hua 写过 Rust 就知道，nightly 才是真正能用的，Databend, TiKV, RisingWave... 这些大规模生产使用的项目都是要 nightly toolchain 编译的，我反而找不到几个不用 nightly 的非玩具项目

用 Rust 做过分布式数据库和存储引擎，比 cpp 体验好太多了... Rust 最主要的问题是招人难； 其次是生态上各种库永远是 0.x 版本，每次一升级依赖 一大堆 breaking change ，包括语言本身不上 nightly 也一堆特性没法用

share 下 JuiceFS 的一篇文章，有提到对 Go 做的内存优化：[极限挑战：使用 Go 打造百亿级文件系统的实践之旅]( https://juicefs.com/zh-cn/blog/engineering/go-build-billion-file-system)

"单体应用开发，微服务部署"，感觉想法有点像 Google 的 Service Weaver

share 一个概念：确定性模拟。很多 bug 难以复现主要是由于系统中不确定性的因素太多了，例如网络延迟，进程调度等等都会导致不同的执行历史，而某些 bug 只有在特定的执行历史下才会复现。

特别对于我们做分布式系统的人来说，平均半年才复现一次的 bug 也不少见，写过共识算法的人应该都能理解。而如果故障现场的日志和信息不足，基本没有排查的可能。

确定性模拟的方案就是通过模拟器，将一切不确定的事物转变为确定性的，整个系统在模拟器上运行 结合故障注入，当 bug 出现时，只要记录模拟器最初的 seed ，使用同样的 seed 再次运行 就能复现当时的执行历史。同时，时间也是输入的一部分，系统相当于一个随着时间不断变化状态的状态机，因此在模拟器上并不需要真正等待时间流逝，模拟器可以直接跳转到系统这个状态机的下一个状态，实现时间加速的效果。

具体实践可以看看这个项目： https://github.com/madsim-rs/madsim?tab=readme-ov-file
及其在 RisingWave 的落地： https://risingwave.com/blog/deterministic-simulation-a-new-era-of-distributed-system-testing/，https://risingwave.com/blog/applying-deterministic-simulation-the-risingwave-story-part-2-of-2/

@godmiracle #11 我也是...直接把整个硬盘写满了，关了 Spotlight 相关的所有功能才好

我是 16 年第一批的大王卡，19 月租，流量 1 元 1G ，别的啥也没...

动手。学计组就设计 CPU ，学 OS 就写内核... 本科这些课程应该都有对应实验吧，没有就上名校的公开课就好了： https://csdiy.wiki/

为了 iPhone 镜像功能把 macOS 也更新了，结果根本打不开 直接闪退

@MasterLei #7 wechat 有 shadow ban ，我被 ban 过半个月；微信用户会无法看到你的群消息和朋友圈，只对 wechat 用户可见。但至少号不用怕被封

@kk2syc 我之前也担心过，但小程序里都可以选择手机号，额外添加一个+86 的就可以了，没遇到过任何不能用的情况

点进来前很惊喜，但看完后代码后感觉有点标题党嫌疑，当作 go 入门项目还可以，但作为一个"Complete" Distributed File Storage 过于玩具了。如果对这两个方面感兴趣的可以去刷这两个课程： https://github.com/skyzh/mini-lsm & https://github.com/pingcap/talent-plan

pikpak

@zjiajun 指的是 K8s 可能跑在 VM 或物理机上？那对应的 node 一般都有 label 吧，可以通过 label 筛选就能指定部署位置了，大部分 Operator 都能支持这种程度的配置。另外按我们的经验，这些东西跑在 K8s 上完全不会有任何问题，一些云厂商的 RDS 都是这样跑在 K8s 上的，我们也在容器里跑 SPDK 这种性能和时延极度敏感的组件，有问题的可能只是对运维人员的会有更高的门槛。如果你要在 K8s 外上做这样的操作的话，只是部署可以用 ansible ，而一旦要做复杂的管控逻辑，最后也只是重新造了一套 K8s 的子集，这种你可以参考下 Pigsty

没太理解具体需求，不过你说的基本上就是一个管控面的工作，K8s 上用对应的 Operator 就可以了