Grupo Linuxero del Bajío

systemd

Víctor Manuel Jáquez Leal

En la esfera del software libre han existido muchas guerras “santas”, donde los proponentes de un software se enzarzan con los proponentes de otro software que tiene objetivos similares la primero: emacs vs vi, KDE vs GNOME, etcétera.

Una de estas épicas batallas, y la más reciente, es la lucha por ser el primer proceso de usuario al iniciar el sistema operativo, en este caso, Linux.

Cuando iniciamos una computadora, lo primero que se ejecuta es el cargador del sistema operativo: un software, por lo general sencillo, cuya única responsabilidad es validar las piezas necesarias para que el kernel se inicie correctamente. El más ubicuo en x86 sería GRUB, mientras que en ARM sería U-Boot.

Una vez que el kernel (Linux) es ejecutado y el sistema de hardware/software arrancado correctamente, el kernel ejecuta el primer proceso del usuario: conocido como init o como PID 1, ya que ese sería siempre su número identificador de proceso. ¿Qué hace dicho proceso? Fácil, lo que el usuario quiera: puede ser un shell, un simple código que devuelva un 1 y nada más, o puede ser un complejo software para lanzar, controlar y monitorizar un sistema computacional multiproceso y multiusuario.

Por defecto el kernel busca, dentro del sistema de archivos, el binario /sbin/init para lanzarlo como proceso de inicialización. Tradicionalmente existían dos estilos de inicialización: el estilo BSD (usado por las variantes de BSD) y el estilo System V (usado por las distribuciones de GNU/Linux hasta muy recientemente). El segundo especifica niveles de ejecución (1, single mode; 3, multiusuario; 5, gráfico; etcétera) y de acuerdo a ellos ejecuta los scripts dispuestos. Estos scripts son lo encargados de lanzar y monitorizar los diversos procesos.

A pesar de su ubiquidad, el sysvinit pronto mostró su rezago frente a las nuevas demandas. La primera gran necesidad era reducir el tiempo de arranque lo más posible. Para lograr esto, la primera estrategia es paralelizar el lanzamiento de servicios, lo que también obliga a llevar un fino control de las dependencias entre sí (un servicio de red necesita tener configurada una interfaz de red primero). Otra estrategia es la de retardar la ejecución de servicios hasta su utilización; por ejemplo, el servicio de impresión, no tiene caso iniciar el servicio cliente de impresión sino hasta que se manda a imprimir algo y a esta estrategia se le llama activation. La activación de procesos puede hacerse por socket, por D-Bus o por dispositivo. Otra gran necesidad es la del control del entorno de ejecución: las limitaciones de recursos a utilizar por un procesos específico, su aislamiento del resto del sistema, su prioridad, etcétera.

Debido a lo anterior, Canonical (mejor conocida por su distribución, Ubuntu) en el 2006 comenzó a desarrollar un reemplazo de init llamado Upstart. Pero también comenzaron a surgir otras implementaciones con objetivos similares, como OpenRC para Gentoo, launchd para Mac OS X, etcétera. Sin embargo, la mayoría de estos reemplazos seguían basándose en scripts en BASH o algún otro lenguaje.

En 2010, Lennart Pottering y Kay Sievers comenzaron a trabajar en nuevo init al que llamaron systemd. Su objetivo era la paralelización, el lanzamiento de procesos basados en mecanismos de activación, el control del entorno de ejecución, eliminar el uso de scripts, con programas declarativos, para utilizar formatos descriptivos (decir qué quiero, no cómo se hace), entre otras características.

Lennart Pottering es un personaje controvertido en la comunidad del software libre, comenzando por que es autor de PulseAudio, software que generó mucho sentimientos negativos. Pero el discurso de odio llegó al paroxismo con systemd. Hubo alguien que organizó una vaquita de [bitcoins para contratar a un sicario]<(https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/J2TZrTvu7vd) que lo asesinara.

Tal vez el punto más álgido llegó cuando se discutió en la comunidad de Debian la adopción de systemd. Este debate llevó a que un grupo de inconformes hicieran un fork de Debian. No obstante, actualmente, la mayoría de las grandes distribuciones usan systemd como sistema de arranque y la tendencia continúa.

Otra razón por la cual mucha gente tiene sentimientos adversos hacia systemd es porque, en el curso de sus desarrollo, ha ido sustituyendo otras herramientas clásicas de Unix, como cron, dmesg, login, udev, entre otros. Además, el desarrollo de daemons ha cambiado, ya que muchas tareas que eran responsabilidad de cada daemon se han integrado a systemd.

En lo personal, a mi me gusta mucho systemd y no tuve ningún problema de migración cuando mi debian testing cambió. Con systemd, GNU/Linux tiene muestra sus capacidades de una manera unificada y con interfaces claras. También, en lo personal, admiro mucho a gente con Lennart Pottering con la energía necesaria para mover a una comunidad con un lastre tan reaccionario como la del software libre.