¿Quién mató al switch de red? Una historia de un bug de Hubris

Artículo original ↗ Discusión en Hacker News ↗

Reacción general a la historia y al trabajo de Oxide

  • Muchos lectores encontraron que la explicación de depuración era excepcionalmente clara e inspiradora, elogiando la profundidad de la ingeniería y la estabilidad del sistema a pesar del bug.
  • Hubris (el RTOS) se describe como código Rust limpio y bien estructurado, y como un contraste refrescante frente al C de “ifdef soup” en los kernels.
  • Algunos señalan que Oxide y herramientas como Tailscale son esfuerzos “de nicho pero impresionantes”; otros objetan que esas herramientas son ampliamente útiles o admirables incluso si no se necesitan personalmente.

Rust, seguridad de memoria y este bug

  • Un hilo intenta presentar el incidente como “Rust sigue teniendo bugs de sobrescritura de memoria”, mientras que múltiples respuestas subrayan:
    • El bug no era específico de Rust, ni una “nueva clase” de bug.
    • Rust elimina muchas clases comunes de errores de memoria, pero no puede impedir todos los errores lógicos.
  • Varios señalan que el modo de fallo (crash en lugar de corrupción silenciosa/CVE) es, de hecho, un resultado positivo.

Ética de C, identificadores y comentarios

  • Un largo subhilo debate la cultura de C: nombres de variables cortos, funciones concisas de la biblioteca estándar y evitar comentarios.
  • Las explicaciones incluyen restricciones históricas (terminales de 80×24, límites de identificadores de 6 caracteres, E/S por teletipo) y compensaciones de legibilidad.
  • Otros argumentan que los idioms y la enseñanza importan más que la mecánica del lenguaje; los lenguajes moldean cómo se ve el código “típico”.
  • Algunos critican el dogma de “no escribas comentarios”, mientras que otros enfatizan “no confíes en los comentarios”, pero aun así valoran una buena documentación.

Hubris frente a otras pilas Rust embebidas

  • Comparación con embassy:
    • Hubris usa configuración estática de tareas, anticipada en tiempo de compilación, sin “spawn task” en tiempo de ejecución.
    • Hubris evita Rust asíncrono; embassy lo adopta.
    • Los comentaristas consideran que resuelven problemas distintos, en lugar de que uno sea superior.
  • Se menciona RTIC como “similar a embassy pero sin HAL”, algo más cercano a Hubris en espíritu.

Diseño del kernel y detalles de pruebas

  • Se discuten límites de MPU, TLBs y esquemas de TLB “soft-filled”; algunos sostienen que son viables incluso para tiempo real blando, mientras que otros prefieren la simplicidad y la facilidad de depuración.
  • Un pequeño detalle de diseño de API deriva en una discusión sobre invariantes, ubicación de la documentación y el valor de constructores que impongan el orden correcto.
  • Se debate mover can_access a su propia crate para permitir cargo test en host; algunos ven “vibras de left-pad”, mientras que otros lo justifican como algo práctico para probar código no_std compilado en cruz.

Organización, cultura y contratación

  • La descripción del artículo sobre una colaboración estrecha y sin silos atrae interés.
  • Una respuesta detallada explica:
    • Sí hay una autoridad final clara (el CEO), pero la cultura enfatiza la autonomía y la apertura.
    • Se usa una compensación uniforme para evitar el stack-ranking y las “jerarquías sombra” impulsadas por diferencias salariales.
  • La contratación se describe como deliberada y centrada en valores (por ejemplo, en la mentalidad de depuración más que en los años de experiencia con Rust).
  • La contratación remota no es solo de EE. UU.; hay empleados en Europa, Canadá y otros lugares, pero se requiere solaparse con la hora del Pacífico durante unas 4 horas, lo que algunos señalan que es difícil con hijos en zonas horarias lejanas.

Notas varias

  • Algunos aprecian el sutil aspecto de “estamos contratando” del post como un excelente anuncio de empleo.
  • El esquema de nombres (“Hubris” para el SO y “Humility” para el depurador) se percibe como humorístico y autoconsciente.
  • La curiosidad por una placa interna de sondeo I2C lleva a aclarar que es una pequeña herramienta de fabricación impulsada por Hubris para programar EEPROMs, no una placa de desarrollo de propósito general.