La mayoría de los sistemas operativos modernos se construyen sobre décadas de código acumulado, bibliotecas y dependencias externas. Aunque este ecosistema permite un desarrollo rápido, también introduce complejidad, supuestos ocultos y riesgos de seguridad potencialmente no examinados.

EriX adopta un enfoque diferente.

Se desarrolla como un sistema operativo de sala limpia, lo que significa que cada componente - desde el cargador de arranque hasta los servicios de espacio de usuario - se implementa dentro del propio proyecto, sin incorporar código fuente externo ni bibliotecas de terceros.

Esta publicación explora qué significa el desarrollo de sala limpia en la práctica, por qué es útil y qué compromisos introduce.

Qué significa “sala limpia”⌗

En el contexto de EriX, el desarrollo de sala limpia significa:

  • No se copia ni reutiliza código fuente externo
  • No se incluyen bibliotecas ni crates de terceros
  • Todos los componentes se implementan dentro del proyecto
  • Solo pueden consultarse especificaciones y documentación públicas

El resultado es un sistema donde cada línea de código es:

  • comprendida
  • auditable
  • diseñada intencionalmente

Esto no es solo una decisión legal o de licencias; es una decisión arquitectónica.

Por qué evitar código externo⌗

Evitar dependencias externas puede parecer restrictivo. El desarrollo moderno de software normalmente fomenta la reutilización, y los grandes ecosistemas existen precisamente para evitar reinventar la rueda.

Sin embargo, los sistemas operativos no son aplicaciones típicas.

1. Complejidad oculta⌗

El código externo suele traer supuestos implícitos:

  • sobre la disposición de memoria
  • sobre los modelos de concurrencia
  • sobre el manejo de errores
  • sobre el comportamiento de la plataforma

Estos supuestos pueden no encajar con la arquitectura de un nuevo sistema operativo, especialmente uno construido alrededor de capacidades y aislamiento estricto.

2. Base de cómputo confiable (TCB) ampliada⌗

Cada dependencia aumenta el tamaño de la base de cómputo confiable.

Si se usa una biblioteca de terceros en el kernel o en componentes críticos del sistema, su corrección pasa a formar parte de las garantías de seguridad del sistema.

El desarrollo de sala limpia mantiene la TCB:

  • pequeña
  • controlada
  • definida explícitamente

3. Auditabilidad y verificación⌗

Un sistema construido íntegramente de forma interna puede auditarse sistemáticamente.

  • Todo el código unsafe puede revisarse
  • Todos los invariantes pueden documentarse
  • Todas las interfaces pueden razonarse

Esto es especialmente importante para un sistema como EriX, que enfatiza:

  • autoridad explícita
  • seguridad basada en capacidades
  • diseño mínimo del kernel

4. Libertad arquitectónica⌗

Reutilizar código existente suele restringir las decisiones de diseño.

Por ejemplo:

  • adoptar una biblioteca puede imponer una forma particular de API
  • integrar código existente puede requerir capas de compatibilidad
  • las abstracciones heredadas pueden filtrarse a nuevos componentes

El desarrollo de sala limpia permite que el sistema sea moldeado por completo por sus propios principios, no por restricciones heredadas.

Sala limpia frente a reimplementación⌗

Es importante distinguir el desarrollo de sala limpia de la simple reimplementación.

El desarrollo de sala limpia no significa reescribir sistemas existentes a ciegas.

En cambio, implica:

  • estudiar especificaciones públicas
  • comprender los principios subyacentes
  • diseñar nuevas implementaciones desde primeros principios

Por ejemplo:

  • Un sistema de archivos puede seguir la semántica POSIX, pero implementarse de forma independiente
  • Un cargador de arranque puede seguir las especificaciones UEFI, pero usar una estructura personalizada
  • Una biblioteca estándar de C puede exponer la misma API, pero estar escrita íntegramente en Rust

El objetivo es la compatibilidad donde sea necesaria, sin reutilización de código.

Sala limpia en la práctica⌗

En EriX, las restricciones de sala limpia se aplican en todo el sistema.

Sin crates externos⌗

Incluso en Rust, donde la reutilización de dependencias es común, EriX evita los crates externos.

En su lugar, define componentes reutilizables internos como:

  • utilidades de memoria
  • primitivas de sincronización
  • abstracciones de capacidades

Bibliotecas internas⌗

La funcionalidad reutilizable se organiza en crates internos, por ejemplo:

  • lib-bootimg
  • lib-capabi
  • lib-ipc

Estas bibliotecas están:

  • versionadas
  • controladas dentro del proyecto
  • diseñadas específicamente para las necesidades del sistema

Estructura estricta del repositorio⌗

Cada subsistema está aislado:

  • cargador de arranque
  • kernel
  • IPC
  • gestión de memoria
  • servicios de espacio de usuario

Esto impone modularidad y evita acoplamientos ocultos.

Compilaciones reproducibles⌗

El diseño de sala limpia se extiende al proceso de compilación.

El sistema apunta a:

  • compilaciones deterministas
  • supuestos mínimos sobre la cadena de herramientas
  • pasos de compilación explícitos

Esto garantiza que los artefactos puedan reproducirse y verificarse.

Beneficios de un sistema operativo de sala limpia⌗

1. Comprensión completa del sistema⌗

Cada componente se conoce y se comprende.

No hay dependencias opacas ni comportamientos ocultos.

2. Modelo de seguridad más fuerte⌗

Con una TCB más pequeña y controlada:

  • existen menos superficies de ataque
  • los invariantes son más fáciles de hacer cumplir
  • la seguridad basada en capacidades puede implementarse limpiamente

3. Mejor plataforma de investigación⌗

EriX no es solo un sistema operativo; también es una plataforma de investigación.

El desarrollo de sala limpia permite:

  • experimentar con nuevas abstracciones
  • medir con precisión los compromisos de diseño
  • razonar con claridad sobre autoridad y aislamiento

4. Mantenibilidad a largo plazo⌗

Aunque inicialmente requiere más trabajo, los sistemas de sala limpia pueden ser más fáciles de mantener:

  • sin roturas de dependencias
  • sin cambios upstream que seguir
  • sin conflictos de versiones

El sistema evoluciona bajo sus propios términos.

Compromisos y desafíos⌗

El desarrollo de sala limpia no está exento de costo.

1. Desarrollo más lento⌗

Todo debe construirse desde cero:

  • bibliotecas básicas
  • soporte de runtime
  • servicios del sistema

Esto aumenta significativamente el esfuerzo inicial.

2. Reinventar la rueda⌗

Muchos problemas ya se han resuelto en otros lugares.

Reimplementarlos requiere tiempo y un diseño cuidadoso.

3. Menos atajos⌗

No existe la posibilidad de:

  • importar rápidamente una biblioteca
  • apoyarse en ecosistemas existentes
  • delegar complejidad a código externo

Toda la complejidad debe manejarse directamente.

4. Mayor responsabilidad de diseño⌗

Cada abstracción debe diseñarse deliberadamente.

Los errores no pueden taparse fácilmente cambiando dependencias.

Por qué este enfoque encaja con EriX⌗

EriX se construye alrededor de unos pocos principios centrales:

  • base de cómputo confiable mínima
  • autoridad explícita mediante capacidades
  • separación estricta entre kernel y espacio de usuario
  • reproducibilidad y determinismo

El desarrollo de sala limpia respalda todos estos objetivos.

Garantiza que:

  • la autoridad nunca quede oculta dentro de código externo
  • los invariantes del sistema estén completamente controlados
  • la arquitectura permanezca coherente en todos los componentes

Una base para el self-hosting⌗

El diseño de sala limpia también respalda el objetivo a largo plazo del self-hosting.

Para construir EriX dentro de EriX, el sistema debe incluir:

  • su propia cadena de herramientas
  • sus propias bibliotecas de runtime
  • sus propias interfaces de sistema

Un sistema que depende en gran medida de componentes externos tendría dificultades para alcanzar este nivel de independencia.

Mirando hacia adelante⌗

Diseñar un sistema operativo de sala limpia es un esfuerzo a largo plazo. Requiere planificación cuidadosa, implementación disciplinada y disposición a construir componentes fundamentales desde cero.

Pero también crea un sistema que es:

  • transparente
  • controlado
  • profundamente comprendido

En publicaciones futuras pasaremos de los principios a la implementación, comenzando por el proceso de arranque temprano y el diseño del formato de imagen de arranque del sistema.