Este artículo es una traducción libre de una sección del artículo Systemd invasion into Linux Server space publicado por el Dr. Nikolai Bezroukov. Se trata de un autor muy respetado en el mundo Unix, fundador de Softpanorama (la revista online en lenguaje ruso que existió desde 1989 a 1996) y Webmaster de softpanorama.org (desde 1996). Está consagrado a publicar material y artículos un tanto escépticos orientados a la educación en Ciencias de la Computación, con un enfoque en el pensamiento crítico acerca de la administración de sistemas y el desarrollo de software como profesiones, revelando la elegencia oculta en Unix y sus conceptos y ponderando al importancia de lenguajes de scripting tales como Perl y Python. Es reconocido por haber creado una de las primeras clasificaciones de virus de computadora y un libro al respecto en 1991. Desde el año 2000 en adelante ha publicado una serie de papers en los cuales ha analizado el modelo de desarrollo del software libre, Linux y Solaris. En definitiva, un autor más que autorizado para criticar a systemd, por ello resulta muy interesante conocer sus pensamientos respecto al mismo.

Systemd representa una alarmante, pero bastante comprensible tendencia en el mundo GNU/Linux, una tendencia inspirada en Windows hacia el tipo de usuarios y administradores de sistemas de la cultura "siguiente, siguiente, siguiente..." ("push button"). Aquellos que parecen creen que leer manuales y entender el funcionamiento interno de los sistemas operativos es algo malo, y debemos tener una limpia y elegante (y completamente opaca) capa de administración con lindas interfaces gráficas similares a Windows, que permitan administrar el sistema de forma "fácil". Y ver su sistema como un artefacto para realizar cierto conjunto de tareas como si fuese una especie de "caja negra", sin preocuparse por cómo efectivamente se realizan. Esta visión es un drástico contraste con la vista tradicional de UNIX/Linux como plataforma de desarrollo y presupone diferentes decisiones en diferentes capas, no sólo en las de inicio, registro de errores y demás, las cuales systemd trata de "mejorar".

En otras palabras, este desarrollo puede ser visto como una señal de advertencia de la pérdida de integridad arquitectónica de Linux. Con algunos desarrolladores Linux tratando activamente de "reinventar Windows" por carecer de entendimiento de la filosofía UNIX, al igual que la ausencia de ideas propias relevantes. Systemd es un reemplazo para algo que muchos usuarios Linux piensan que no necesita ser reemplazado, y las travesuras de sus desarrolladores no ganan mentes y corazones precisamente. Más bien el opuesto, como fue evidenciado en aquel famoso hilo en LKLM donde el mismísimo Linus Torvalds mandó a la mierda y vetó del desarrollo del kernel Linux al desarrollador Kay Sievers.

El resultado neto de la introducción de systemd apunta a un problema más grande, al que yo llamaría "traición de la filosofía Unix". Unix promueve la idea de maximizar el uso de archivos de texto, incluyendo archivos de configuración y logs, al igual que la idea de utilizar herramientas simples que hagan una cosa y la hagan bien, y puedan ser combinadas a través de pipes o sockets. También es acerca del uso de scripting como alternativa a la programación en lenguajes compilados como C.

Este conjunto de ideas clave (a pesar de sus propias limitaciones y desventajas) ha probado ser sorprendentemente poderosa y exitosa a lo largo de los años.

Ahora se ha roto claramente esta tradición. Systemd promueve no sólo un nuevo sistema de inicio de servicios similar a inetd, sino también varias ideas claramente inspiradas en Windows, incluyendo el uso de logs binarios. Sí, logs binarios. En serio. En términos religiosos es un anatema para Unix. Y a pesar de esos trucos bonitos como la firma de registros, eso en realidad introduce un poderoso mecanismo para poner un troyano en el proceso de logging que pueda filtrar o suprimir ciertos mensajes. La NSA probablemente adora este cambio. Y me gustaría que alguien me explique por qué esto es más seguro, y una mejor forma de realizar estas tareas, en comparación con, digamos, almacenar logs remotamente en un servidor especial (logserver) protegido de manera adecuada.

Este tipo de soluciones se parecen mucho a la típica mentalidad Windows de "aprender es duro" que está dañando a Linux como plataforma para servidores, pues hace poco claro por qué deberíamos preferir Linux en vez de Windows sobre plataformas Intel. Al parecer, el efecto que tiene el celo sin sentido de aquellos "programadores C no reformados" con antecedentes en Windows y mentalidad Linux puede ser devastadora.

No hay que negar que es posible realizar mejoras sobre init. Después de todo, Unix es el más antiguo sistema operativo aún en uso (después de System/360). Tiene más de 40 años de edad. Y Linux en sí mismo tiene casi 25 años. En otras palabras Linux es "otro sistema operativo antiguo". Y esto se observa en las desventajas obvias de los sistemas de inicio clásicos en laptops y dispositivos similares.

Pero existen mejoras y pseudo-mejoras. El primer intento fue utilizar pseudo-comentarios escritos en un lenguaje especial en cada script de inicio (similar a cómo PHP es utilizado en páginas Web). Esos pseudo-comentarios eran en realidad programas funcionales interpretados como directivas de alto nivel acerca de las dependencias y el comportamiento de init. Esta estrategia era bastante flexible y tuvo cierto nivel de éxito a pesar de sufrir la falta de estandarización del "meta lenguaje" para los comentarios y baja calidad de su implementación en Red Hat y SUSE.

Otra forma de extender los scripts de inicio fue mover estos pseudo-comentarios a un archivo separado, uno por cada script. De esta forma se puede utilizar XML o cualquier otro lenguaje descriptivo para especificar dependencias, orden de inicio, orden de detención, etc. Esta estrategia permite al mismo tiempo extender la funcionalidad sin destruir completamente el mecanismo previo. Fue introducido en Solaris 10 hace más de una década. No es la mejor solución pero al menos tiene cierta integridad conceptual.

Systemd, en cambio, no posee ninguna integridad conceptual. Es una mezcla de muchas ideas diferentes con una implementación que tira a la basura todo concepto clásico de Unix que funcionó razonablemente bien por cuatro décadas, y ofrece poco a cambio. Los usuarios de laptops son los ganadores pues acelera el tiempo de inicio (el mismo o mejor tiempo de inicio puede ser logrado de diferentes formas), pero eso es todo. Los administradores de sistemas son los perdedores definitivos pues se introduce un sistema más complejo y menos transparente que hace agregar de forma "honesta" un nuevo demonio personalizado sea más dificil (por supuesto, es posible evitar systemd y correr una imitación de init mediante la directiva @reboot de cron).

No hay duda de que para servidores esto es perjudicial. Agrega complejidad y dependencias. Si algo falla, es por lejos mucho más difícil encontrar los errores con systemd que sin él. Lo único positivo es que facilita el uso de cgroups, los cuales son la implementación propia de Linux de los contenedores (zona de Solaris). Llegaron 10 años después que Solaris, pero mejor tarde que nunca.

En este punto existen varios problemas:

  • La actitud "no fue hecho aquí" hacia la solución SysV. La cual fue bastante elegante y no agotó completamente su potencial (utilizando comentarios escritos en pseudo-lenguaje en las cabeceras de los scripts se puede lograr casi lo mismo que pretende systemd y más; pero claro, sin el peso de Red Hat es difícil estandarizar tal lenguaje y asegurar su adopción masiva).
  • Esta es una solución "anti-scripting". Systemd fue creado por una persona que sabe C y sólo C. Así que para él (al igual que para un martillo todo es un clavo) todo es mejor escrito en C y compilado en binarios. Ese es el mundo donde se siente cómodo. Pero desde el punto de vista de la arquitectura, es más que cuestionable reemplazar una solución basada en scripts (altísimamente portable) por una solución en C, cuando la eficiencia no es importante. Y en este caso no lo es para nada. Como tal, esta solución es inferior al uso de lenguajes de scripting, y por cierto, se puede utilizar un lenguaje más moderno para interpretar un lenguaje funcional personalizado que provea un conjunto más rico de características que bash o sh, por ejemplo, Python.
  • Eliminar los runlevels es un problema. Se puede solucionar, pero es menos aceptable para aquellos Sysadmins que utilizan el cambio de runlevels a diario (por ejemplo usan el runlevel 3 para producción y el runlevel 5, con X11, para debugging, patching, etc).
  • Perdida de flexibilidad. Systemd es un subsistema inherentemente orientado a sistemas de escritorio que no funciona bien con demonios que proveen servicios y no resuelve ninguno de los problemas a nivel servidor que existen en GNU/Linux. Iniciar servicios sólo cuando se necesitan, y detener cosas de forma agresiva cuando ya no son necesarias, puede ser perfectamente entendible para ahorrar batería en una laptop, pero no tiene ninguna importancia o necesidad en un servidor. La principal importancia en un servidor es la facilidad para descubrir problemas, y si no se puede correr servicios como programas aislados, pues requieren algún servicio adicional provisto por systemd, esta facilidad desaparece.
  • Afirmar que con esta solución se logra un inicio más rápido y una sistematización del sistema de inicio es de alguna forma falso. Primero, para servidores la velocidad del inicio es irrelevante (NDT: de hecho en un servidor se desea que el inicio sea pausado y secuencial, iniciando de a un servicio por vez, para descubrir fácilmente qué falla en caso de error). De todas formas no hay evidencia sólida de mejoras dramáticas en cuanto a tiempos de inicios. Segundo, la sistematización alcanzada de esta forma es perversa a pesar del hecho de que sea amigable para laptops.
  • Para aprovechar la ventaja de la pre-alocación de sockets de systemd (al estilo inetd), muchos demonios deberán ser parchados para recibir el descriptor de archivos desde systemd, en vez de desde el kernel.
  • Estas soluciones vienen de los mismos desarrolladores de pulseaudio y avahi :-). Ambas soluciones proveen el argumento clave en contra de la adopción de systemd: es evidente que su autor es un pésimo arquitecto definitivamente incapaz de ver el panorama más amplio, que no comprende el valor de los lenguajes de scripts (NDT: portabilidad) y que esencialmente trata de imitar las peores características de la arquitectura PAM de Linux.

Existen múltiples formas de acelerar la velocidad de inicio de Linux. Sin embargo, reescribirlo en C y forzando a que se comporte como inetd huele a Windows. El único punto positivo es el intento de estandarización de los archivos de configuración típicos. Pero tales esfuerzos pueden proceder por fuera del desarrollo de systemd sin problemas.

Una vez más, no es el primer intento de mejorar init. Han habido varios intentos previos para reemplazar el viejo sistema de inicio SystemV. Uno de los intentos más radicales fue SMF de Solaris 10. Introdujo el directorio "shadow" con archivos XML para suplantar scripts de inicio. Para mí no quedó claro si el remedio fue mejor que la enfermedad. Después de todo, los scripts de inicio son bastante simples en la actualidad, y con sysconfig y niveles codificados, uno de los problemas más importantes de init fue resuelto. Las dependencias también pueden ser manejadas con pseudo-comentarios. Por lo tanto la cuestión es por qué molestarse en destruir una solución antigua, perfectamente funcional y flexible. La solución de Solaris 10 fue continuada por upstart.

El artículo es muy extenso e incluye información y enlaces a muchos otros sitios más. Con esta introducción simplemente quise demostrar los puntos más interesantes, pero es muy recomendable leer el artículo completo en su sitio original, donde continúa hablando de la responsabilidad de Red Hat en la puja por su adopción, de la aparición inicial de systemd en Fedora, del comando systemctl, de detalles técnicos de la implementación de systemd, de la crítica hacia systemd, y de por qué se ha esparcido como un virus entre todas las distribuciones:

Systemd invasion into Linux Server space


Tal vez pueda interesarte


Compartí este artículo