Cómo elegir un sistema de init, y por qué 0dyssey usa runit

Todo sistema operativo empieza con una base, y la parte de esa base que menos puedes permitirte equivocar es el sistema de init. 0dyssey se está construyendo sobre Void Linux, que usa runit. Este es el razonamiento, y la mitad que se generaliza: la propiedad con la que juzgamos a los candidatos vale lo mismo si algún día tocas Void como si no.

El sistema de init es el cimiento, trátalo como tal

El sistema de init es el primer proceso de la máquina y el padre de todo lo demás. Nunca desaparece. Si es complejo, esa complejidad vive para siempre en la raíz de tu árbol de procesos, y cada fallo que depures después lo depurarás a través de él.

systemd es la opción por defecto en casi todas partes, y hace muchísimo. Esa es justamente la propiedad que conviene sopesar. Es un sistema de init, un gestor de servicios, un demonio de registros, un gestor de dispositivos, un configurador de red, un seguimiento de sesiones de inicio y un planificador de temporizadores, reunidos en un todo estrechamente acoplado que quiere ser dueño del PID 1 y de casi todo lo que se ejecuta por encima. Para una distribución de escritorio de uso general es una contrapartida razonable: funciona, y casi nadie tiene que leerlo. Para una base sobre la que quieres construir un producto coherente, es mucho comportamiento que ni controlas ni entiendes del todo.

La propiedad que vale la pena juzgar: ¿es legible el estado?

La pregunta a la que volvíamos una y otra vez no es qué sistema de init es más rápido ni cuál tiene más funciones. Es si puedes responder, desde la propia máquina y sin un manual, a tres cosas: qué se está ejecutando, por qué arrancó y qué pasa cuando muere.

Un sistema de init supera esa prueba cuando su estado vive en un lugar que puedes leer: un directorio, un archivo, un enlace simbólico. La suspende cuando su estado es un grafo de resolución calculado en el arranque a partir de archivos de unidad, ajustes adicionales, generadores y preajustes, y la única forma de inspeccionar el resultado es preguntárselo a la herramienta que lo calculó. El segundo tipo no es necesariamente malo, pero significa que la herramienta es el único testigo de su propio comportamiento.

Un servicio supervisado es una carpeta. Para activarlo, creas un enlace simbólico a la carpeta. Para comprobarlo, preguntas. No hay estado oculto, ni generadores, ni un grafo de resolución de archivos de unidad: lo que escribiste es lo que se ejecuta.

Cómo es runit en realidad

runit es lo bastante pequeño como para leerlo entero en una tarde. Un servicio es un directorio que contiene un script run. La supervisión es un enlace simbólico dentro del directorio de servicios activos. Ese es todo el modelo mental, y vale la pena ver un ciclo de vida completo en un solo bloque.

# un servicio es un directorio con un script run, y nada más. uno mínimo,
# /etc/sv/sshd/run, son tres líneas: unir stderr con stdout y luego hacer exec
# del demonio en primer plano para que runit supervise el proceso que lanzó
#!/bin/sh
exec 2>&1
exec /usr/bin/sshd -D

# instalar el paquete. xbps es el gestor de paquetes de Void
$ sudo xbps-install -S openssh

# activarlo: un enlace simbólico mete el directorio en el conjunto supervisado
$ sudo ln -s /etc/sv/sshd /var/service/

# pedir su estado. sv informa de si está en marcha, y de su pid
$ sudo sv status sshd

# arrancar, parar, reiniciar: todo explícito, todo síncrono
$ sudo sv restart sshd
$ sudo sv stop sshd

# desactivar la supervisión: eliminar el enlace simbólico. No hay daemon-reload
$ sudo rm /var/service/sshd

Sin secciones [Unit] / [Service] / [Install]. Sin un paso de recarga que deje en silencio la configuración en ejecución desincronizada del archivo que acabas de editar. Un servicio está activado cuando existe el enlace simbólico y supervisado cuando runit lo ve. El sistema de archivos es el estado, lo que convierte ls en una herramienta de depuración.

Cuando puedes leer tu sistema de init en una tarde, puedes razonar sobre cada modo de fallo que tiene. Para un sistema que pensamos entregar y mantener, eso no es un lujo. Es un requisito previo, y es la razón por la que esta decisión se tomó antes que casi cualquier otra.

Lo que costó la elección

Ninguna base es gratis. Una decisión que merece ser documentada nombra lo que costó antes de afirmar lo que compró, así que aquí va la cuenta:

• runit es desconocido para la mayoría de los usuarios de Linux, así que nuestra documentación tiene que cargar con un peso que un sistema basado en systemd habría heredado del resto del ecosistema.
• Los proyectos originales publican unidades de systemd, no scripts run de runit. Todo lo que empaquetamos y asume systemd es trabajo de empaquetado que hacemos nosotros.
• El repositorio de paquetes de Void es más pequeño que el de Debian o el de Arch, lo que de vez en cuando significa compilar nosotros el software original.
• Una comunidad más pequeña significa menos respuestas para copiar y pegar a las tres de la madrugada cuando algo se rompe.

Aceptamos las cuatro, porque la alternativa era heredar un peso que pasaríamos años intentando quitar.

Es más fácil añadir con criterio a una base mínima que restar de una máxima. Esa asimetría decidió.

No es un fork, es una composición

0dyssey no es un fork de Void ni un simple cambio de aspecto de nada. Es una composición cuidadosa de capas probadas: el kernel de Linux, runit para el init y la supervisión, xbps para los paquetes, i3 para la gestión de ventanas, sobre una base Void, con nuestra propia capa de experiencia de usuario encima. Cada una hace su trabajo y pasa el relevo limpiamente a la siguiente.

Ese planteamiento es deliberado, no modesto. Un fork hereda toda la carga de mantenimiento de un proyecto y su política interna. Una composición hereda solo las interfaces, lo que deja cada capa reemplazable el día en que el razonamiento que la eligió deje de sostenerse. Escribir ese razonamiento es lo que lo hace posible: una decisión que no puedes reconstruir es una decisión que nunca podrás revisar.

No hay nada que descargar. 0dyssey está en desarrollo, y esto es el registro de una decisión, no una nota de versión. Lo que se puede publicar hoy es la decisión y el argumento que la respalda, que es también la parte que merece discusión.