谁杀了网络交换机？一个 Hubris Bug 故事

对这个故事和 Oxide 工作的总体反应

• 许多读者认为这篇调试文章异常清晰且鼓舞人心，称赞了工程深度和系统稳定性，即便存在这个 bug。
• Hubris（RTOS）被描述为干净、结构良好的 Rust 代码，与 C 内核里那种“ifdef 汤”形成了清新对比。
• 一些人提到 Oxide 以及像 Tailscale 这样的工具是“冷门但令人印象深刻”的努力；也有人反驳说，这类工具即使不是自己会用到，也同样非常实用或值得钦佩。

Rust、内存安全与这个 bug

• 有一条讨论试图把这次事件解读成“Rust 还是会有内存覆盖 bug”，但多条回复强调：
  • 这个 bug 不是 Rust 特有的，也不是某种“新型” bug。
  • Rust 消除了许多常见的内存错误类别，但不能阻止所有逻辑错误。
• 几个人指出，这种失败模式（崩溃，而不是静默损坏/CVE）其实是一个积极结果。

C 语言文化、标识符与注释

• 一段很长的子讨论在争论 C 文化：短变量名、简略的标准库函数，以及回避注释。
• 解释包括历史约束（80×24 终端、6 字符标识符限制、电传打字机 I/O）以及可读性的权衡。
• 也有人认为，习惯和教学比语言机制更重要；语言会塑造“典型”代码的样子。
• 有些人批评“不要写注释”的教条，而另一些人强调“不要相信注释”，但仍然重视良好的文档。

Hubris 与其他嵌入式 Rust 栈

• 与 embassy 的比较：
  • Hubris 使用静态、提前配置的任务设置，没有运行时的“spawn task”。
  • Hubris 避免 async Rust；embassy 则拥抱它。
  • 评论者认为它们是在解决不同问题，而不是谁更优。
• RTIC 被提到为“类似 embassy，但没有 HAL”，在精神上与 Hubris 更接近一些。

内核设计与测试细节

• 讨论涉及 MPU 限制、TLB，以及“软填充”的 TLB 风格方案；有人认为即便对软实时也可行，另一些人则更偏好简单性和可调试性。
• 一个小小的 API 设计挑刺引发了关于不变式、文档放置，以及通过构造函数强制执行顺序的价值的讨论。
• 将 can_access 移到自己的 crate 里，以便进行宿主机 cargo test，也引发争论；有人觉得有“left-pad 的味道”，另一些人则认为这在测试 no_std 跨编译代码时是很实际的做法。

组织、文化与招聘

• 文章对紧密、无孤岛式协作的描述引起了兴趣。
• 一条详细回复解释道：
  • 确实有明确的最终权威（CEO），但文化强调自主性和开放性。
  • 采用统一薪酬是为了避免由薪资差异驱动的等级排序和“影子层级”。
• 招聘被描述为经过深思熟虑且以价值观为导向（例如看重调试思维，而不只是 Rust 年限）。
• 远程招聘并不限于美国；员工分布在欧洲、加拿大及其他地区，但要求与太平洋时间有约 4 小时的重叠，这一点一些人指出对有孩子、且处在遥远时区的人来说很难。

杂项

• 有些人很欣赏这篇文章里微妙的“我们在招聘”信息，认为这是很出色的招聘广告。
• 命名方案（“Hubris” 操作系统和 “Humility” 调试器）被认为既幽默又自知。
• 对内部 I2C “probe” 板的好奇引出了解释：那是一个由 Hubris 驱动的微型制造工具，用于给 EEPROM 编程，而不是通用开发板。