Boycott a 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.

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.