Desmitificando systemd

Mi distro de cabecera (Debian GNU/Linux) ha decidido bajo una votación que algunos llaman errónea cambiar el gestor de inicio desde su anterior hacia systemd lo cual ha traído mucha polémica entre los que gustamos de esa distribución. Algunos usuarios basan su desacuerdo con systemd en solo repetir lo que escuchan de otros usuarios, lo cual ha creado varios mitos sobre este gestor de inicio que voy a intentar “desmitificar” en esta entrada.

Antes de comenzar debo decir que no me gusta nada la decisión de cambiar las cosas en Debian pero, en ningun momento planeo abandonar mi querida espiral. Solo intento que, si vamos a discutir un tema, por lo menos lo hagamos lo más preparados posible aún cuando yo mismo no me considero pro-systemd. Para lograr la desmitificación de systemd me apoyaré en un sitio web donde los desarrolladores dan su punto de vista el cual llegó a mis manos por un colega que si parece ser pro-systemd aunque no sea usuario de Debian. Dicho esto creo que puedo pasar a intentar desmitificar lo que se dice sobre systemd.

systemd es a base de binarios

Quizás este sea uno de los aspectos que más nos choquen, ¿si todo es a base de binario como monitorear las cosas que usualmente hacemos a travez de logs?. No tengo ni idea de como nació este mito, pero no es absolutamente cierto.

systemd se configura casi exclusivamente a través de archivos de texto simple. Unos ajustes que también pueden alterar con la línea de comandos del kernel y a través de variables de entorno. No hay nada binario en su configuración (ni siquiera XML). Sólo un simple, sencillo y fácil de leer archivo de texto.

Esa cosa es monolítica y lo controla todo

Antes de llegar a la web mencionada anteriormente confieso que yo mismo pensaba de esta manera pero luego de leer lo que dicen sus desarrolladores mi opinión ha cambiado algo…

Si usted hace una build de systemd con todas las opciones de configuración habilitadas usted construirá 69 binarios individuales. Estos binarios sirven para diferentes tareas, y se separan cuidadosamente por un número de razones. Por ejemplo, se ha diseñado systemd pensando en la seguridad, por lo tanto, la mayoría de los demonios corren con privilegios mínimos (utilizando las capacidades del núcleo, por ejemplo) y son responsables de sólo tareas muy específicas, para reducir al mínimo su superficie la seguridad y el impacto. También, systemd paraleliza el arranque más que cualquier solución anterior. Esta “paralelización” se crea ejecutando varios procesos en paralelo. Por lo tanto queda visto que systemd está muy bien dividido en muchos binarios y por lo tanto los procesos. De hecho, muchos de estos binariosse separan tan bien, que son muy útiles fuera de systemd.

Un paquete que incluyó 69 binarios individuales difícilmente pudiera ser llamado monolítico. Lo que es diferente de las soluciones anteriores sin embargo, es que enviamos más componentes en un único tarball, y los mantenemos encadenados en un único repositorio con un ciclo de lanzamiento unificado.

Eso no se parece a Unix

Ciertamente hay algo de verdad en eso. Los archivos de las fuentes de systemd no contienen una sola línea de código procedente de las líneas originales de UNIX. Sin embargo, se deriva la inspiración de UNIX, y por lo tanto hay un montón de UNIX en systemd. Un ejemplo sería la idea de UNIX “todo es un archivo” el cual se encuentra reflejado en que en systemd todos los servicios se exponen en tiempo de ejecución en un sistema de archivos del kernel, los cgroupfs. Entonces, una de las características originales de UNIX fue el soporte multi-seat, basada en el apoyo integrado en el terminal. Con systemd trajimos el soporte multi-seat de forma nativa nuevamnte, pero esta vez con el soporte total para el hardware de hoy, que cubren gráficos, ratones, audio, cámaras web y más. De hecho el diseño de systemd como una suite de herramientas integradas que cada uno tiene sus propósitos individuales pero cuando se usan juntos son más que la suma de las partes, que más o menos en el centro de la filosofía UNIX. Entonces, la forma en que nuestro proyecto se maneja (es decir, el mantenimiento de la mayor parte del núcleo del sistema operativo en un único repositorio git) es mucho más cercano al modelo BSD (que es un verdadero UNIX, a diferencia de Linux) de hacer las cosas (donde la mayor parte del sistema operativo central es mantenerse en un único repositorio CVS / SVN) cosa que nunca fue asi en Linux.

En última instancia, la cuestión de si algo es UNIX o no importa muy poco. Siendo técnicamente excelente es apenas exclusivo de UNIX. Para nosotros, UNIX es una influencia importante (de hecho, el más grande), pero también tenemos otras influencias. De ahí que en algunas zonas systemd serán muy UNIX, y en otras un poco menos.

Es que eso es muy complejo…

Ciertamente hay algo de verdad en eso. Las computadoras modernas son bestias complejas y el sistema operativo que se ejecuta en ellas obviamente también lo será, por lo tanto tienen que ser complejo. Sin embargo, systemd ciertamente no es más complejo que las implementaciones anteriores de los mismos componentes. Es más sencillo, y tiene menos redundancia. Por otra parte, la construcción de un sistema operativo sencillo basado en systemd implicará mucho menos paquetes que los que usa un Linux tradicional. Menos paquetes hace que sea más fácil de construir su sistema, se deshace de las interdependencias y de gran parte del comportamiento diferente de todos los componentes involucrados.

Eso no me va a dejar usar scripts de Shell

Esto es totalmente falso. Simplemente no los usamos para el proceso de arranque, porque creemos que no son la mejor herramienta para ese propósito específico, pero eso no significa systemd era incompatible con ellos. Puede ejecutar fácilmente los scripts de shell como servicios systemd o demonios, puede ejecutar scripts escritos en cualquier idioma como servicios systemd ya que a systemd no le importa lo más mínimo lo que hay dentro de su ejecutable. Por otra parte, en gran medida utilizamos scripts de shell para nuestros propios fines, para la instalación, construcción, pruebas de systemd. Y usted puede pegar los scripts en el proceso de inicio temprano, se utilicen para los servicios normales, se pueden ejecutar en la última parada, prácticamente no hay límites.

Llegados a este punto supongo que algunas de las principales creencias pueden haber sido aclaradas, a pesar de no sentirme un defensor del cambio y tener mis recelos sobre eso de “un demonio para controlarlos a todos” creo que al final nadie se atreverá a decir que por lo menos no funciona, incluso conozco algunos usuarios que notan que con systemd “la PC camina mas rapido” pero ya esas serían otras cosas que pudieran discutirse. Por el momento solo me resta invitarlos a debatir aquí los puntos de vista que tengan sobre el gestor de inicio que muchas distribuciones han adoptado aunque ahora las mayores reacciones se estén viendo dentro de la comunidad de Debian el cual hasta le ha nacido un nuevo fork con todo esto. Si gustarle o no es una cuestion de cada uno, yo por mi parte solo quiero poner mi granito de arena en la desmitificación de systemd que al final va a estar presente en Jessie, la próxima versión estable de Debian.