Entrevista con Andreas Kling de Serenity OS (2022)

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

El entusiasmo por los sistemas operativos de aficionados está alimentando el debate sobre qué podría hacer de forma distinta un SO “desde cero” frente a los diseños al estilo Unix, desde sistemas de archivos transaccionales y APIs unificadas de suscripción a eventos hasta almacenamiento respaldado por bases de datos o centrado en objetos. Los comentaristas intercambian recursos y anécdotas sobre cómo empezar con kernels, bootloaders y programación de bajo nivel, mientras contrastan este aprendizaje práctico con simplemente personalizar Linux u otros sistemas existentes. Bajo las ideas técnicas subyace una tensión entre los proyectos impulsados por la nostalgia y los esfuerzos que buscan replantear genuinamente la arquitectura del SO, el rendimiento y la experiencia de usuario.

Motivaciones para nuevos SO / SO de juguete

  • Varios comentaristas sienten la tentación de construir SO “de juguete” o experimentales para explorar ideas que no encajan bien en los kernels existentes (especialmente Linux).
  • Las motivaciones incluyen el valor educativo, la diversión visceral del trabajo de bajo nivel y la insatisfacción con las abstracciones actuales (POSIX, “todo es un archivo”, pipes de flujo de bytes).
  • Algunos preferirían basar el trabajo en kernels/distro existentes e innovar principalmente en APIs de userland y UX.

Sistema de archivos, bases de datos y transacciones

  • Fuerte interés en semánticas de sistema de archivos más adecuadas para bases de datos y seguras ante fallos:
    • Barreras de escritura o I/O transaccional para evitar la sobrecarga de fsync y la corrupción de datos.
    • Persistencia estructurada a nivel de kernel en lugar de E/S de archivos cruda para la mayoría de las apps.
  • Debate entre DB y sistema de archivos:
    • Algunos argumentan que las bases de datos grandes deberían usar dispositivos crudos o particiones dedicadas; otros señalan que esto no ayuda a las “pequeñas DB” ubicuas dentro de las apps.
    • Se proponen sistemas de archivos encima de bases de datos reales (metadatos ricos, etiquetas, triggers, búsqueda rápida); se mencionan intentos pasados como WinFS y varios modelos de mainframe / AS/400.
    • Otros advierten que los sistemas de archivos transaccionales anteriores tenían un rendimiento terrible y deadlocks, lo que sugiere que las semánticas de BD pueden no ser adecuadas para sistemas de archivos de uso general.

APIs unificadas de eventos y suscripción

  • Deseo de una única API coherente del kernel para “obtener estado y suscribirse a cambios” para cualquier recurso (archivos, dispositivos, procesos, etc.), en lugar de la mezcla heterogénea actual (sondeo de procfs, inotify, syscalls ad hoc).
  • Preocupación por carreras TOCTOU; las ideas incluyen reservar acceso a recursos o flujos de eventos al estilo snapshot.
  • La objeción señala que los mecanismos síncronos de autorización y reserva (como en algunos productos de seguridad) pueden bloquear el sistema; cualquier diseño debe evitar ralentizaciones visibles para el usuario.
  • Sugerencias relacionadas: señales al estilo Fuchsia, colas de comandos tipo io_uring (con conciencia de sus problemas de seguridad), ejecución especulativa con commit/rollback transaccional.

Modelo de ejecución e aislamiento

  • Una idea: ejecutar todo el espacio de usuario como WebAssembly en ring 0, usando comprobaciones de límites por software en lugar de aislamiento por hardware; evita flushes de TLB/cambios de contexto, pero probablemente sería más lento para código intensivo en cómputo.
  • Debate sobre cuándo esto podría superar a procesos nativos y sobre compartir un único espacio de direcciones.

Dificultad y vías de entrada al desarrollo de SO

  • Consenso: escribir algún SO es factible; la parte difícil es evitar un desorden inmantenible y alcanzar la sofisticación de los sistemas modernos.
  • Recursos y caminos sugeridos: wiki de OSDev, tutoriales bare-metal de “hello world”, xv6, tutoriales de Rust en Raspberry Pi, Linux From Scratch (para ensamblar un sistema, no para diseñar el kernel), QEMU/Bochs para experimentar con seguridad.
  • Algunos abogan por empezar con hardware simple o kernels existentes; otros impulsan diseños desde cero.

Modelos alternativos de SO e inspiraciones

  • Referencias a Plan 9, BeOS, seL4, sistemas de capacidades, Inferno, Haiku, Redox, Fuchsia, Nix/Guix e ideas de lenguaje-como-SO (Smalltalk, Forth, sistemas tipo Lisp).
  • Propuestas para replantear los archivos como objetos inteligentes, escritorios espaciales/de primeras en 3D y imágenes de sistema sin estado, al estilo Git, con actualizaciones y reversions transaccionales.

Debate sobre valor, nostalgia y UX

  • Los entusiastas ven los SO hobbyistas como algo valioso para aprender y explorar modelos nuevos.
  • Los escépticos consideran que los proyectos retro al estilo Win95 están impulsados por la nostalgia y tienen poco valor social, argumentando que el esfuerzo debería ir a trabajos más orientados al futuro o con mayor impacto.
  • Debate lateral continuo sobre si la UX de escritorio ha mejorado de forma significativa desde los 90; algunos ven retrocesos, otros destacan que los lanzadores basados en búsqueda, el acoplamiento/ajuste de ventanas y la estabilidad general son mejoras reales.