Who killed the network switch? A Hubris Bug Story

Original Article ↗ Hacker News Discussion ↗

Overall reaction to the story and Oxide’s work

  • Many readers found the debugging write-up exceptionally clear and inspiring, praising the depth of engineering and system stability despite the bug.
  • Hubris (the RTOS) is described as clean, well-structured Rust code and a refreshing contrast to “ifdef soup” C kernels.
  • Some note Oxide and tools like Tailscale as “niche but impressive” efforts; others push back that such tools are broadly useful or admirable even if not personally needed.

Rust, memory safety, and this bug

  • One thread tries to spin the incident as “Rust still has memory overwrite bugs,” while multiple replies stress:
    • The bug was not Rust-specific, nor a “new breed” of bug.
    • Rust removes many common classes of memory errors but can’t prevent all logic mistakes.
  • Several point out that the failure mode (crash rather than silent corruption/CVE) is actually a positive outcome.

C ethos, identifiers, and comments

  • Long subthread debates C culture: short variable names, terse standard library functions, and comment avoidance.
  • Explanations include historical constraints (80×24 terminals, 6-char identifier limits, teletype I/O) and readability tradeoffs.
  • Others argue idioms and teaching matter more than language mechanics; languages shape what “typical” code looks like.
  • Some criticize “don’t write comments” dogma, while others emphasize “don’t trust comments” but still value good documentation.

Hubris vs other embedded Rust stacks

  • Comparison with embassy:
    • Hubris uses static, ahead-of-time task configuration with no runtime “spawn task.”
    • Hubris avoids async Rust; embassy embraces it.
    • Commenters see them as solving different problems rather than one being superior.
  • RTIC is mentioned as “embassy-like without a HAL,” somewhat closer to Hubris in spirit.

Kernel design and testing details

  • Discussion of MPU limits, TLBs, and “soft-filled” TLB-style schemes; some argue they’re viable even for soft real-time, others prefer simplicity and debuggability.
  • A small API design nit leads to discussion of invariants, documentation placement, and the value of constructors enforcing ordering.
  • Moving can_access into its own crate to allow host cargo test is debated; some see “left-pad vibes,” others justify it as practical for testing no_std cross-compiled code.

Organization, culture, and hiring

  • The article’s description of tight, non-siloed collaboration attracts interest.
  • One detailed reply explains:
    • There is a clear final authority (CEO), but the culture emphasizes autonomy and openness.
    • Uniform compensation is used to avoid stack-ranking and “shadow hierarchies” driven by pay differences.
  • Hiring is described as deliberate and value-focused (e.g., on debugging mindset rather than years of Rust).
  • Remote hiring is not US-only; employees exist in Europe, Canada, and elsewhere, but overlapping with Pacific Time by ~4 hours is required, which some note is hard with children in distant time zones.

Miscellaneous notes

  • Some appreciate the subtle “we’re hiring” aspect of the post as an excellent job ad.
  • The naming scheme (“Hubris” OS and “Humility” debugger) is seen as humorous and self-aware.
  • Curiosity about an internal I2C “probe” board leads to clarification that it’s a tiny Hubris-powered manufacturing tool for programming EEPROMs, not a general-purpose dev board.