云厂商这些 SDK 基本都是生成或外包随便写的，根本没人去管，质量差的很

@tool2dx 我觉得没啥问题，文件系统的空间分配和管理没那么简单。回收站这个东西也不适合由文件系统来实现，应该由业务层（文件管理器等）来做

+1 ，我是在微信点开视频的时候很容易破音，用过的 15, 19, 21 款的 MBP 都是这样，感觉是通病。不过最近好像很少出现了，不知道是不是更新了 macOS 15 的缘故

自带的「屏幕共享」就很好用

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

有一些是软件本身开源但不接受贡献 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 用户可见。但至少号不用怕被封