¿Por qué SystemD es una mierda?

En este artículo voy a presentar los argumentos técnicos por los cuales he concluido hace tiempo que SystemD es una reverenda mierda y no quiero adoptarlo en mis servidores GNU/Linux. Pero no me crean a mí, sino a los expertos en la materia. No voy a explicar mis pensamientos u opiniones personales respecto a SystemD. No se trata de un berrinche producto de la resistencia al cambio. Me tomé la libertad y el trabajo de recopilar y traducir al español los argumentos técnicos de los verdaderos expertos. Pasen y vean.

El contenido de este artículo no es de mi autoría, sino que se trata de una simple traducción al español de los artículos originales publicados por sus autores. El titulo de cada uno enlaza a su artículo original. Los párrafos que no están en itálica son algunas opiniones y recomendaciones personales.

boycott systemd

SystemD es un reemplazo para el demonio SysVInit utilizado en sistemas GNU/Linux y Unix, originalmente creado por Lennart Poettering de Red Hat. Representa un incremento monumental en la complejidad, una abominable y violenta bofetada en la cara de la filosofía Unix, y su inherente naturaleza dominante y viral lo convierte en una especie de "segundo kernel" desparramándose por todo el ecosistema Linux.
El sitio boycott systemd apunta a servir como una síntesis y llamada de atención para tomar una posición en contra de la proliferación generalizada de SystemD, para detallar por qué es dañino, y para persuadir a los usuarios a que rechacen su uso.
Disclaimer: No somos puristas de SysVInit. Reconocemos la necesidad de un nuevo sistema de inicio en el siglo XXI, pero SystemD no lo es.

La síntesis

1. SystemD va en contra de la filosofía Unix: "haz una cosa y hazla bien", representando una colección compleja de docenas de binarios fuertemente acoplados. Sus responsabilidades exceden groseramente las de un sistema de inicio, a medida que avanza sobre el control de energía, manejo de dispositivos, puntos de montaje, cron, encripción de discos, inetd y API para sockets, syslog, configuración de red, manejo de login y sesiones, readahead, particiones GPT, registro de contenedores, manejo de hostname/locale/tiempo, y demás cosas. Keep it simple, stupid.
2. Los archivos de journal de SystemD (manipulados por journald) son almacenados en un complicado formato binario, y deben ser consultados utilizando journalctl. Esto vuelve a los logs de journal potencialmente corruptibles, pues no tienen transacciones ACID. Seguramente no quieres que esto le suceda a tus syslogs. ¿El consejo de los desarrolladores de SystemD? Ignorar el problema. No, en serio. Ah, y además posee integración con un servidor HTTP embebido (libmicrohttpd). Y se sirven códigos QR a través de libqrencode.
3. El equipo de SystemD es notablemente chovinista y anti-Unix, debido a su abierto desprecio hacia el software no-Linux y la subsecuente incompatibilidad de SystemD con todos los sistemas no-Linux. Debido a que SystemD está muy fuertemente acoplado a la API del kernel Linux, esto provoca que las diferentes versiones de SystemD sean incompatibles entre diferentes versiones del kernel Linux (nota del traductor: esto es terrible). Se trata de una política aislacionista que esencialmente suelda al ecosistema Linux en su propia jaula, y sirve como obstáculo a la portabilidad del software (nota del traductor: una de las más grandes cualidades deseables en toda pieza de software).
4. udev y dbus son dependencias forzosas ç. De hecho, udev se fusionó con SystemD hace tiempo. La integración del administrador de dispositivos que fue alguna vez parte del kernel Linux no es una decisión que deba tomarse a la ligera. Las implicancias políticas de ello son altas, y hace que muchos paquetes que dependen de udev, a su vez dependan de SystemD, mas allá de la existencia de forks, como eudev. A partir de systemd-209 los desarrolladores ahora tienen su propia, no estándar y escasamente documentada API sd-bus que reemplaza mucho del trabajo de libdbus, y disminuye aún más la transparencia.
5. Por defecto, SystemD guarda los core dumps en el journal, en lugar del filesystem. Los core dumps deben ser explícitamente consultados utilizando coredumpctl. Más allá de ir en contra de todo razonamiento, esto además crea complicaciones en entornos multiusuario (buena suerte corriendo gdb sobre el core dump de tu programa si se vuelca en el journal y no tenés acceso root), dado que SystemD requiere acceso root para controlarlo. Asume que usuarios y administradores son tontos por igual, pero más críticamente, la fundamentalmente naturaleza corruptible de los logs de journal lo vuelven un severo impedimento.
6. El tamaño de SystemD lo vuelve un punto simple de fallo. Hasta este artículo, SystemD tiene 9 reportes CVE, desde su concepción en marzo de 2010. Hasta ahora no parece mucho, pero su esencial y prepotente naturaleza lo convertirá en un blanco jugoso par los crackers, ya que es mucho más pequeño que el kernel Linux en sí mismo, pero casi igual de crítico.
7. SystemD es viral por naturaleza. Su alcance en funcionalidad y arrastre como dependencia a cientos de paquetes significa que los mantenedores de distribuciones vana necesitar una conversión, o van a quedar a la deriva. Como ejemplo, GNOME ha adoptado a SystemD como dependencia fuerte desde la versión 3.8 para varias utilidades, incluyendo gdm, gnome-shell y gnome-extra-apps. Esto significa que las versiones de GNOME mayores a la 3.8 son incompatibles con sistemas no Linux, y debido a la popularidad de GNOME, ayudará a inclinar a muchos mantenedores a agregar SystemD. El rápido crecimiento en adopción por parte de distribuciones como Debian, Arch Linux, Ubuntu, Fedora, openSUSE y otras muestra que muchos se subieron al tren, con o sin justificación. Tampoco sirve de nada que SystemD se rehuse a iniciar como una instancia de usuario, a menos que el sistema bootee con él (es una coacción descarada).
8. SystemD se encierra a sí mismo en el PID 1. Debido a que controla gran cantidad de componentes diferentes, significa que hay toneladas de escenarios en los cuales puede crashear y voltear al sistema por completo. Pero además, significa que muchas actualizaciones del sistema (sin tratarse del kernel) van a requerir un reinicio. ¡Que disfrutes tu nuevo sistema Windows 9 Linux! Para ser justo, SystemD provee un mecanismo para reserializarse y reejecutarse a sí mismo en tiempo real. Pero claro, si esto falla, el sistema se cae. Hay muchas formas por las que esto puede ocurrir. Esto es otro ejemplo de SPOF (punto simple de fallo).
9. SystemD fue diseñado con glibc en mente, y no se preocupa mucho por soportar otras libcs. En general, la idea de librería C estándar de los desarrolladores de SystemD es una que sea compatible bug-por-bug con glibc.
10. La naturaleza complicada de SystemD lo vuelve difícil de extender y salir fuera de sus límites. Mientras que es posible mas o menos iniciar scripts de forma trivial con archivos, es más difícil implementar un comportamiento que salga de la caja. Muchos usuarios necesitarán posiblemente escribir programas más complicados que directamente interactúen con la API de SystemD, o directamente necesitarán parchar SystemD. Uno debe preocuparse por una mayor cantidad de caminos de ejecución y comportamiento en un programa crítico del sistema, incluyendo la posibilidad de que SystemD no sincronice bien con la cola de mensajes de dbus en tiempo de boot, congelando el sistema. Esto es opuesto al tradicional init, que es determinístico y predecible por naturaleza, dado que mayormente sólo ejecuta scripts.
11. En última instancia, el parasitismo de SystemD es el símbolo de algo más que SystemD en sí mismo. Muestra un cambio radical de pensamiento en la comunidad Linux. No necesariamente positivo. Sino vehementemente postmoderno, monolítico, fuertemente orientado a sistemas de escritorio, limitante de posibilidades, aislacionista, reinventor de la rueda, y un gran anti-patrón en general. Si tu meta es complacer al más bajo denominador común, que así sea. Nosotros sin embargo buscaremos alternativas.
12. SystemD ni siquiera sabe qué mierda quiere ser. Es referido diversamente como "demonio de sistema" o un "bloque de construcción básico para construir un sistema operativo en espacio usuario", las cuales son definiciones bastante ambiguas. Se deglute funcionalidad que pertenecía anteriormente a util-linux, wireless tools, syslog, y otros proyectos. No tiene una dirección clara más que los caprichos de los desarrolladores. Irónicamente, más allá de que apunta a estandarizar las distribuciones Linux, no tiene un estándar claro en sí mismo, y está perpetuamente liberando versiones.
Este es el artículo (por así llamarle) de mayor claridad, donde se exponen los argumentos de forma concisa con una gran cantidad de enlaces a las fuentes. Recomiendo ampliamente visitar el sitio ya que pueden encontrar gran cantidad de material con argumentos y exposiciones de expertos en contra de SystemD. Algo que me gustaría recalcar respecto a la filosofía Unix, es que más allá de la premisa básica de "haz una cosa y hazla bien", el usar archivos de texto plano es otra de las premisas. Y la justificación es que los archivos de texto planos son el formato de transmisión y almacenamiento de información más altamente portable que existe. Es decir, dejar de usar archivos de texto plano es romper con otra de las premisas de la filosofía Unix.
Algo que no deja de asombrarme, es que SystemD esté tan fuertemente atado a la API del kernel Linux, que llegue al punto de que una versión de SystemD no sea compatible entre diferentes versiones del kernel Linux. Esto refuerza la idea de "segundo kernel".

EWONTFIX - Broken by design: systemd

Recientemente ha resonado en foros, canales de IRC, comunidades y redes sociales el tema de SystemD.
A pesar de que las opiniones son mayormente negativas, la mayoría de los argumentos han sido desestimados y tildados de mera resistencia al cambio, o morigerados con la idea de que a pesar de sus fallas, su diseño es grandioso. Esta visión incorpora la noción de que las fallas de SystemD se pueden reparar sin desecharlo y sin incurrir en grandes costos de desarrollo, y por lo tanto no son un mayor obstáculo para adoptar a SystemD.
Esta idea es equivocada: SystemD está roto por diseño ("broken by design"), y más allá de ofrecer mejoras atractivas sobre los viejos sistemas de inicio (initd: SystemV Init), también incorpora grandes regresiones en muchas de las áreas donde se espera que GNU/Linux sea excelente: seguridad, estabilidad, y no tener que reiniciar para actualizar el sistema.

El primer gran problema: PID 1

En los sistemas Unix, el proceso cuyo ID es 1 (PID 1) es especial. Los procesos huérfanos (incluyendo un caso especial: los demonios que se vuelven huérfanos a si mismos) son adoptados por el proceso con PID 1. Existe también una semántica especial de señales hacia con PID 1, y tal vez es más importante, si PID 1 finaliza repentinamente ("crashes") o termina, el sistema completo se cae (kernel panic).
Entre las razones por las cuales SystemD quiere o necesita correr como PID 1, está el hacerse cargo de los demonios cuyo mal comportamiento hace que se vuelvan huérfanos a sí mismos, impidiendo que su inmediato padre conozca su PID para esperarlo (wait) o enviarle una señal.
Desafortunadamente, esto también trae las otras propiedades de PID 1, incluyendo el detener por completo el sistema si crashea. Esto es importante debido a que SystemD es complejo. Mucho más complejo que los sistemas de inicio tradicionales. Y cuando se dice complejo, no se habla en el sentido de líneas de código, sino en términos de las posibles entradas y caminos de ejecución que pueden ser activados en tiempo de ejecución. Mientras que los sistemas de inicio tradicionales básicamente no lidian con ninguna señal excepto SIGCHLD de procesos huérfanos al finalizar su ejecución y cambios manuales de runlevel realizados por el administrador, SystemD lidia con todo tipo de entradas y señales, incluyendo inserción y remoción de dispositivos, cambios en puntos de montaje y sistemas de archivos, e inclusive una API pública basada en DBus. Esto a su vez implica alocación de recursos, parseo de archivos y mensajes, manipulación de strings, etc. Lo que lleva a:

El segundo gran problema: superficie de ataque

En un sistema sin SystemD, luego de haber realizado el hardening queda a lo sumo un único proceso con privilegios de root que tiene una superficie de ataque: sshd. El resto o corre con un usuario sin privilegios, o no tiene un canal para proveer entrada excepto la entrada local de root. Utilizar SystemD al menos duplica la superficie de ataque.
Este riesgo incrementado y poco razonable no es inherente a la meta de SystemD de arreglar el sistema de inicio tradicional. Sin embargo es inherente a la filosofía de diseño de SystemD de poner todo dentro del proceso de inicio.

El tercer gran problema: reiniciar para actualizar

Fundamentamente, actualizar nunca debe requerir un reinicio salvo que el componente actualizado sea el kernel. Incluso, por actualizaciones de seguridad, es posible disponer de un parche en caliente que sea aplicado como un módulo del kernel cargable para mitigar el riesgo de seguridad hasta que sea apropiado reiniciar con el nuevo kernel.
Desafortunadamente, al mover grandes cantidades de funcionalidades que necesitarán ser actualizadas dentro de PID 1, SystemD hace imposible actualizar sin reiniciar. Esto hará que "Linux" se vuelva la burla de los fans de Windows, tal como pasó con Ubuntu tiempo atrás.

Posibles contra argumentos

Respecto a la seguridad, se podría pensar por qué no usar SystemD en los sistemas de escritorio, y dejar a los servidores con algo diferente. Pero esta línea de razonamiento está equivocada en al menos tres formas:

1. Muchas de las características por las que se pondera a SystemD son orientadas a servidores. Gestionar demonios con transacciones no es una característica útil en sistemas de escritorio. El público al que apuntan este tipo de cosas es claramente los administradores de servidores.
2. El escritorio se está volviendo cada vez más rápidamente irrelevante. La futura plataforma será móvil y deberá lidiar con la realidad de ejecutar aplicaciones no confiables. Mientras que el escritorio hace que la distinción de cuentas de usuario locales irrelevantes, la llegada de los ecosistemas de aplicaciones móviles plagados de aplicaciones potencialmente maliciosas vuelve a la "seguridad local" mas importante que nunca.
3. El grupo de desarrolladores que fomenta a SystemD, incluyendo posiblemente a su autor, no se contenta con que SystemD sea una opción entre muchas. Al proveer una API pública para que sea utilizada por otras aplicaciones, SystemD se ha vuelto difícil de no usar una vez que alcance cierto umbral de adopción.

Con respecto a las actualizaciones, la herramienta de control de SystemD, systemctl, tiene un comando daemon-reexec que serializa el estado de SystemD, se re-ejecuta a sí mismo, y continúa sin interrupción. Esto puede utilizarse para pasar a una nueva versión sin reiniciar. Muchos programas ya utilizan esta técnica. Desafortunadamente, esto trae de vuelta al problema del PID 1 siendo especial. Para aplicaciones normales, si la re-ejecución falla, lo peor que puede pasar es que el proceso muera y se reinicie (manualmente o por un proceso monitor) si es necesario. Sin embargo, para el PID 1, si falla la re-ejecución, el sistema completo se cae (kernel panic).
Por cualquier común razón por la que pueda fallar, la llamada al sistema execve retorna failure en la imagen original del proceso, permitiendo que el programa maneje el error. Sin embargo, la falla de execve no es totalmente atómica:

• El kernel puede fallar en configurar la imagen para el nuevo proceso luego de que la imagen original ya haya sido destruida; la principal situación en la cual esto puede suceder es cuando se han agotado los recursos disponibles.
• Inclusive luego de que el kernel haya configurado exitosamente la nueva imagen y transfiera la ejecución al nuevo proceso, es posible que ocurran fallas previas a la transferencia de control a la aplicación. Esto puede ocurrir en el linker dinámico (falta de recursos disponibles u otra falla transitoria mientras se mapean las librerías requeridas o archivos de configuración) o en el código de inicio de libc. Utilizando libc con linkeado estático o incluso linkeado dinámico sin librerías adicionales elimina estos casos de fallo, pero SystemD está pensado para ser usado con glibc.

Además, SystemD puede fallar en restaurar su estado serializado debido a fallos de alocación de recursos, o si la nueva y vieja versión difieren lo suficiente para que el viejo estado no sea utilizable por la nueva versión.
Entonces si no es SystemD, ¿qué utilizar? La discusión del grupo de desarrollo de Debian acerca de si adoptar SystemD o no básicamente degeneró en una falsa dicotomía entre SystemD y upstart. Y, exceptuando a algunos viejos gruñones, mantener el viejo SysVInit no es una opción atractiva. Entonces a pesar de todos sus fallos, ¿es SystemD la mejor opción?
No.
Ninguna de las cosas que SystemD hace bien son revolucionarias. Muchas otras veces han surgido posibles reemplazantes para el viejo initd: daemontools, ruinit, Supervisor, entre otros han resuelto el problema de "el viejo init está no sirve más" (cada uno con sus propios defectos). Su fallo en desplazar al viejo init en las principales distribuciones no tiene nada que ver con su capacidad para resolver el problema, y tiene todo que ver con marketing. No hay nada grande y revolucionario en SystemD. Su popularidad es el resultado de una estrategia de marketing agresivo y dictatorial, que incluye elementos como:

• Deglutiendo otros componentes "esenciales" del sistema como udev, y haciendo que sean difíciles de utilizar sin SystemD (a pesar que existe eudev).
• Configurando un bloqueo de API (es decir, haciendo que las interfaces de DBus provistas por SystemD se vuelvan una API necesaria en que los programas de nivel usuario deban depender).
• Dictando políticas mas que limitando su alcance para que sea el usuario, administrador o integrador (de una distribución) quien se encargue de integrarlo. Esto elimina debates y dificultades para lograr consenso, por lo tanto acelerando su adopción a expensas de la flexibilidad y diversidad.

Entonces, ¿cómo debe hacerse correctamente un init?
La forma Unix: con programas simples auto-contenidos que hagan una simple tarea y la hagan bien.
Primero, se debe sacar todo fuera de PID 1.
La forma SystemD: tomando ventaja de las propiedades especiales de PID 1 en la mayor medida posible. Esto resulta en un alcance siempre en expansión y exacerba todos los problemas descritos anteriormente (y probablemente muchos otros que aún no se han descubierto).
La forma correcta: acabar con todo lo especial acerca de PID 1 haciendo que PID 1 no haga nada excepto iniciar el verdadero script de inicio. De esta manera no hay forma de que init falle en tiempo de ejecución, y no hay necesidad de actualizarlo una vez que haya iniciado correctamente.
Luego, desde el script de inicio, correr un sistema de supervisión de procesos fuera de PID 1 para manejar demonios como procesos hijos inmediatos (sin ejecutar en background). Como se mencionó anteriormente existen diferentes alternativas. No es claro que alguna esté lo suficientemente pulida o sea lo suficientemente robusta para satisfacer las principales distribuciones en la actualidad. Pero tampoco lo es SystemD, sus defensores sólo tienen talento para ocultar la suciedad debajo de la alfombra.
Lo que las alternativas existentes tienen, sin embargo, es un mejor diseño, principalmente en la forma de tener un alcance bien definido, más que un Katamari Damacy.
Si ninguna de ellas está lista para debutar en primera, entonces aquellos deseosos de remplazar al viejo init en sus distribuciones favoritas necesitan avanzar y pulir una de las soluciones existentes, o escribir una mejor implementación basada en los mismos principios. Cualquiera de estas opciones será mucho menos trabajo que arreglar lo que está mal con SystemD.
Cualquiera sea el sistema elegido, el criterio más importante es que sea transparente a las aplicaciones. Por más de 30 años, la elección del sistema de inicio ha sido irrelevante para todos excepto integradores y administradores. Las aplicaciones a nivel usuario no tienen ninguna razón para conocer o preocuparse si se está utilizando SysVInit con runlevels, upstart, o un sistema avanzado de supervisión de procesos (o incluso /bin/sh). Irónicamente, este tipo de modularidad e intercambiabilidad es lo que ha hecho posibles a los sistemas; si hubiésemos comenzado con un sistema monolítico, orientado a un bloqueo de API, cambiar el sistema de inicio por algo nuevo e innovativo hoy no sería una opción.
De este artículo se desprende la idea de que con SystemD han creado prácticamente una especie de segundo kernel. Una pieza insustituible que abarca una cantidad impresionante de funciones heterogéneas, y una vez adoptado pareciera que no hay vuelta atrás. Han tomado una pieza de software simple y efectiva y la han usado como medio para que Red Hat sea quien tenga el control sobre la comunidad.

¿SystemD? Más bien Shit-stemD

System es un componente crítico de muchos sistemas GNU/Linux. Yo lo detesto.
Voy a explicar los por qué, pero primero algunas definiciones:

• Un programa es una secuencia de instrucciones para una computadora.
• Un proceso es una instancia en particular de un programa en ejecución. Los procesos son, aproximadamente, a los programas, lo que los vuelos son a las aerolíneas. En muchos sistemas, los procesos tienen un número, llamado identificador de proceso, o PID.
• Un demonio es un programa que generalmente debe iniciar automáticamente, y se ejecuta de forma continua. No interactúa directamente con el usuario, pero espera por algún suceso y luego actúa en tal evento. Por ejemplo, puede estar esperando por una hora específica para realizar alguna tarea programada, por una conexión, o un archivo o mensaje escrito en algún lugar específico. A veces se encargan del mantenimiento del sistema, limpieza, o tareas de servicio.

Cuando se inicia un sistema Unix, el primer programa que se carga en memoria y se ejecuta se denomina "init". Lo que significa inicialización; y, como su nombre lo indica, su propósito es comenzar a ejecutar los programas necesarios para que el sistema se inicie y los usuarios puedan loguearse. De hecho, en el kernel hay una directiva hardcodeada para buscar y ejecutar un programa llamado "/sbin/init", y apagar el sistema cuando ese programa finaliza su ejecución.
Init es el último proceso en terminar cuando el sistema se apaga, y es responsable por notificar al resto de los procesos que es hora de apagarse, y terminar de manera forzosa cualquier rezagado. Cuando init en sí termina, el sistema lo hace por completo. ESTO ES IMPORTANTE.
Init tiene otro trabajo, que consiste en mantener la tabla de procesos limpia. Cualquier proceso puede crear una copia de sí mismo (llamado "fork" en la terminología Unix); es el paso previo a cargar otro programa en memoria. Un proceso que ha finalizado su ejecución puede despachar un código de estado al proceso que lo creó; éste (llamado padre) generalmente "espera" el código de estado del proceso creado (llamado hijo). ¿Pero qué pasa si el proceso padre muere antes que el hijo? Lo que sucede es que init está diseñado para ser el padre adoptivo de estos proceso "huérfanos", y espera, y descarta, cualquier código de estado que pueda ser retornado por el huérfano al finalizar. Esto previene los llamados "procesos zombies" (slots en la tabla de procesos llenos con códigos de estado que no poseen programas en ejecución asociados). Estos son indeseados debido a que ocupan lugares en la tabla de procesos (nota del traductor: una estructura de datos en el espacio de memoria del kernel) que pueden ser utilizados por otros programas.
Por ende es importante que init se ejecute bien y no crashee (nota del traductor: es lo que hace que GNU/Linux sea tan estable, ¿cuántas veces han intentado, sin éxito, terminar un proceso en un sistema Windows?).
En el diseño de sistemas Unix, es un principio generalmente entendido que una gran tarea no sea realizada por un gran programa, sino más bien por una colección de pequeños programas, cada uno atacando un componente específico y bien definido de la tarea. Se conoce como "haz una cosa, y hazla bien" y es un principio para escribir un programa Unix. Una razón importante para este razonamiento es que un pequeño programa tiene pocos lugares donde un bug se pueda ocultar, en comparación con un programa de gran tamaño.
Hasta hace poco, el programa tradicional de inicio era SysVInit. Su nombre se debe a que supuestamente era compatible con el sistema de inicio del sistema AT&T Unix System V. Generalmente utiliza un conjunto de shell scripts para levantar el sistema. La principal alternativa a SysVInit era BSD init, que corre un único script para levantar todo el sistema.
Algunos sistemas Linux desarrollaron SysVInit "estilo BSD", lo que significa que en vez de una complicada maraña de scripts, hay sólo uno, al igual que los sistemas BSD. Este único shell script en un init estilo BSD a menudo incorpora otros subscripts que setean varios parámetros de configuración; pero incluso con este cambio es bastante más simple que con los scripts estilo System V.
Entonces la mayoría de las implementaciones de SysVInit fueron un desorden. Por ejemplo Canonical, distribuidor del popular Ubuntu, en vez de usar un proceso de inicio estilo BSD, o intentar corregir los defectos del procedimiento de init, lo que decidió fue reemplazarlo con una nueva implementación.
Reemplazar a init es divertido, y es algo que cualquier nerd experto en Unix alguna vez debe intentar. Escribir tus propias utilidades de sistema, incluyendo init, puede ser un proceso muy educativo cuando se trata de entender como un sistema funciona en un nivel fundamental. Y si querés hacer algo loco, se puede inclusive bootear emacs como init e iniciar directo en el editor de texto. Tal sistema sería probablemente poco estable y no recomendado para uso a largo plazo, pero es divertido.
Sin embargo, otro principio de diseño de los sistemas Unix es, si no está roto, no lo arregles. Para sistemas en producción realmente vas a querer dejar tranquilo todo aquello que funcione bien; y el SysVInit que viene con Linux es lo suficientemente simple, bien entendido, y lo suficientemente probado como para no meterte con él cuando se trata de hacer verdadero trabajo.
Pero ese principio nunca detuvo a Canonical. A ellos les encanta meterse donde no corresponde. Upstart es un desastre. En lugar de un script tiene desparramo total de archivos de configuración. En lugar de simplemente correr un programa para iniciar los demonios que necesita levantar, tiene lo que se llama "inicio basado en eventos", en el cual cada programa iniciado o finalizado dispara un evento, que los archivos de configuración mapean en acciones (generalmente iniciando o deteniendo otros programas). Es muy sofisticado y difícil de administrar.
Algunas cargas de trabajo (por ejemplo en servidores de aplicación críticos) tienen necesidades de gestión de procesos realmente sofisticadas. Los procesos pueden caer en cualquier momento, y es necesario otros procesos para monitorear los procesos que trabajan y reiniciarlos a medida que sea necesario si fallan. Si un proceso depende de un proceso que falló, también debe ser detenido y así sucesivamente. Es perfectamente legítimo escribir un programa monitor que siga el curso de todas estas dependencias y tome acciones apropiadas. PERO NO DEBE REEMPLAZAR A INIT. Escribí el programa, hacelo subordinado a init, y luego agregalo al script de inicio de init. El trabajo de init es servir como proceso primordial, iniciando el resto de los procesos necesarios para tener el sistema funcionando, y luego hacer la plancha hasta que sea hora de apagar el sistema. Si se agrega toda esta basura al init (toda esta complejidad e inteligencia) y alguna parte se rompe, causando que init finalice o algo, ¿qué se obtiene? Un sistema inestable. Pues, si init muere, el resto de los procesos también.
Init se debe mantener simple y estúpido. NO existe razón alguna para pensar lo contrario.
Eso es Upstart, que es lo suficientemente malo. Ahora sigamos con SystemD, que toma todo lo malo anteriormente mencionado y le agrega más formas de hacerlo incorrecto. SystemD fue originalmente escrito por un tipo con el Rowlingesco nombre de Lennart Poettering para Red Hat, y es un total desastre. El problema con SystemD es que no sólo es un reemplazo para init; si hay un demonio corriendo en un sistema Linux, SystemD probablemente quiera reemplazarlo. Reemplazó a udev, el manejador de nodos de dispositivos. Reemplazó inetd, el super-servidor de servicios de Internet. Recientemente ganó la funcionalidad de cron, el demonio que corre tareas programadas. Tiene su propio sistema de logging, y debido a que no es más en archivos de texto plano, su propio servidor HTTP para poder leer los logs. Reemplazó a ConsoleKit. No sé qué carajo se supone que haga ConsoleKit, pero los entornos de escritorio lo utilizan. Si tu configuración de escritorio depende de ConsoleKit, ahora depende de SystemD.
Algunos de estos no están en PID 1 sino en pequeños demonios fuertemente acoplados a SystemD. Pero PID 1 ya hace demasiado. Configura las interfaces de red, monta los sistemas de archivos, configura el hostname, abre y escucha en sockets para iniciar demonios a demanda, corre tareas cron, construye y verifica y orquesta un grafo de dependencias para determinar qué demonios iniciar y cuando, y más. Depende en dbus por el amor de Dios (y expone una interfaz a dbus en tiempo de ejecución). Toda esta MIERDA conviviendo en PID 1, más el hecho de que tenés todos estos demonios fuertemente acoplados hace que, un usuario de muchos años con cabeza Unix, vomite. ASÍ NO SE HACEN LAS COSAS EN UNIX. Sólo porque pongas las cosas en diferentes archivos fuente .c no hace que seas modular, o desacoplado, o que hayas seguido al filosofía Unix. Init debe depender en MUY POCO y debe hacer MUY POCO. Simplemente porque ES LO PRIMERO QUE SE INICIA Y LO ULTIMO QUE SE DETIENE. Init debe lograr iniciar el sistema cuando casi nada más (sacando el kernel y libc) esté disponible, y debe PERMANECER en ejecución tanto tiempo como se espera que el sistema funcione (¡lo que puede ser años sin reiniciar o apagarse!). Cuanto más dependas en librerías y otras mierdas, más librerías y más mierdas vas a necesitar para levantar el sistema (lo que no te podés permitir si tenés un pequeño volumen o initramfs para bootear). Cuanta más inteligencia tengas en las librerías de init, mayor es la chance de que pueda ocurrir un crash de init (y por lo tanto de sistema). No me importa cuan inteligente seas. MAS CÓDIGO = ESTADÍSTICAMENTE MAS BUGS. MENOS CÓDIGO = ESTADÍSTICAMENTE MENOS BUGS. Voy a confiar siempre en el init que tenga menos código SIEMPRE.
El resultado de todo esto es lo siguiente:
SYSTEMD ES EL OPUESTO EXACTO DE LO QUE UN BUEN INIT DEBE SER.
De hecho, se siente como una invasión. Se siente como si un día nos hubiésemos despertado y toda la infraestructura de nuestros sistemas Linux hubiese sido reemplazada por el capricho de un par de desarrolladores (Poettering y Kay Sievers). Esto es justamente el caso si tenés Fedora o Arch; ya que se te instaló SystemD con una de las actualizaciones automáticas. Lennart Poettering no encaja con el resto de la comunidad Linux, y no parece que conociera los principios fundamentales de los sistemas Unix antes de comenzar a escribir SystemD. El sólo decidió que las partes críticas de los sistemas Linux de todo el mundo necesitaban ser reemplazadas con su código. ¿Por qué? Porque sí. Por eso. Hay mucho odio por culpa de este sujeto en Internet, y la mayoría injustificado. Es un sujeto inteligente, y SystemD es bastante estable para toda la sofisticación que tiene. Pero si rompés los principios Unix, y tratas de pasar por encima de la comunidad para empujar a tu fuertemente acoplado monstruo en los sistemas de los demás, es esperable que suceda alguna reacción.
Lennart creó un blog llamado "Los 30 grandes mitos acerca de SystemD" en el cual se refiere a estas preocupaciones. Es un intento justo como refutación pero desafortunadamente Lennart, PERDISTE. PERDISTE CUANDO DECIDISTE QUE PID 1 DEBA HACER UN MONTÓN.
¿Es SysVInit una mierda? A menos que lo hagas estilo BSD, sí. ¿Es SystemD mejor en algunos aspectos? Sí. SystemD posee algunas ventajas (al permitir el monitoreo y control sofisticado de procesos, inicio de demonios en paralelo para acelerar el boot time, etc).
Primero de todo, nadie con una workstation de escritorio o inclusive una laptop le importa un carajo el tiempo de booteo. La mayoría de las personas o dejan sus máquinas encendidas o las suspenden cuando no las utilizan, lo que significa que en la mayoría de los casos, si la máquina inicia en 5 o 30 segundos se trata de una micro-optimización. Especialmente cuando se compara con los varios minutos que tarda en iniciar un sistema Windows para poder ser utilizado; e incluso hoy las versiones actuales de Windows fueron ayudadas más por la proliferación de discos de estado sólido que por una mejora en su proceso de inicio. Para el caso de los servidores (nota del traductor: donde Linux pisa fuerte ya que las desktops son IRRELEVANTES), el tiempo de booteo es mucho menos que un problema; ya que tardan muchísimo mas en inicializar todas sus super-especializadas placas RAID e interfaces de hardware de red que lo que tarda en iniciar el sistema operativo.
(Un hecho curioso, una vez tuve que optimizar el proceso de inicio de una plataforma robótica embebida con Linux. Una de las opciones que consideré fue reemplazar init con un pequeño binario que sólo iniciaba los servicios requeridos por la plataforma. Estaba tratando de resolver el mismo problema que Lennart, y AUN ASÍ saqué conclusiones totalmente opuestas a las que él hizo para SystemD).
Mis máquinas Slackware con SysVInit demoran aproximadamente 30 segundos en levantar; y la mayor parte del tiempo lo gasta el kernel detectando hardware. El tiempo de booteo de init demora 4 segundos o algo así. Ayud que los scripts de inicio de Slackware son estilo BSD. En cambio mi workstation con Arch corriendo SystemD no logra un tiempo de boot apreciablemente inferior.
Segundo, a NADIE le importa un sorete que su shell tenga PID bajo cuando se loguea por primera vez. No importa un carajo.
Pero incluso si quisieras estas ventajas, hay formas de conseguirlas sin HACER MIERDA UNIX. Hay un sistema de inicio llamado ruinit que ofrece muchos de los beneficios de SystemD, pero está construido de manera modular, al estilo Unix.
Ruinit permite control sofisticado de procesos, incluyendo inicio, detención, monitoreo, y reinicio de servicios; y un manejo especial en el caso de caidas de servicios. Puede iniciar servicios en paralelo. Utiliza un directorio repleto de scripts para controlar el inicio, detención, y manejo de errores de un demonio; y utiliza pipes en lugar de dbus para exponer su mecanismo de control de procesos al espacio usuario. Las dependencias de servicios son tan simples como iniciar el servicio depend-on en el script de inicio del servicio que posee dependencias.
Esta simplicidad es lo que hace a Unix hermoso, y hace que ruinit sea armonioso con el ecosistema Unix existente. Ruinit corre en Linux y BSD, y está disponible como paquete para diferentes variedades de ambos. Puede correr como PID 1 o se puede evitar el uso de el demonio init de ruinit, y ganar todos los beneficios de ruinit utilizando el resto del mismo junto con tu propio demonio init. En particular, ruinit se integra bien con SysVInit. "sv", el iniciador del servicio ruinit, puede simplemente ser symlinkeado bajo /et/init.d/ con un nombre diferente, y si detecta que está siendo iniciado de esta forma se comportará como un script SysVInit para iniciar el servicio ruinit con ese nombre.
Mi sistema personal no utiliza ruinit. Un script de inicio estilo BSD es suficiente. ¿Pero si estuviese corriendo una granja de servidores? Seguro le prestaría atención a ruinit. Pero he abandonado Arch, una merecidamente popular y bien respetada distribución Linux, debido a que Arch cambió a SystemD (y también por la tendencia de Arch a romper todo en momentos inapropiados). Volví a Slackware, que sigue usando la misma simple y elegante configuración de init estilo BSD que tenía en 1995, cuando comencé a utilizarlo. Y, para ser honesto, no podría ser más feliz. Mi vida es más fácil.
Resumiendo, a la mierda con la hostil toma de posesión de SystemD. Linux es, primero y antes que nada, un Unix; y voy a pelear por preservar el legado de la simplicidad y elegancia que conlleva. Al menos en las máquinas que administro. Podés correr lo que se te cante; después de todo vivimos en un país libre... y se trata de software libre.
Este es el artículo más duro contra SystemD y no puedo esta más de acuerdo con el autor. Lamentablemente en la actualidad quedan unas pocas distribuciones GNU/Linux libres de SystemD, entre las que se destacan Slackware y Gentoo.
Espero que hayan llegado hasta acá y se animen de seguir leyendo las fuentes originales con todos sus enlaces. SystemD es algo grave y peligroso.
¡A la mierda con SystemD, viva Slackware hoy más que nunca!

Más recursos

Systemd: Harbinger of the Linux apocalypse
Choose your side on the Linux divide
Roll up your sleeves, we may need to fork Debian
The End of Linux
The world after systemd
lolnux - Systemd

Tomado de: http://www.linuxito.com/gnu-linux/nivel-alto/431-por-que-systemd-es-una-mierda