Este sitio tiene por objeto servir como un llamado de alerta,
para ayudar a posicionarse en contra de la adopción generalizada
de systemd, detallando por qué es perjudicial, y persuadiendo a
los usuarios para renunciar a su uso.
-
1. systemd se opone diametralmente a la
filosofía Unix: "haz una cosa, y hazla bien", comprendiendo
una compleja colección de docenas de binarios fuertemente
acoplados1. Sus competencias exceden holgadamente
a lo que debería considerarse un sistema de inicio,
extendiendo sus pérfidos tentáculos a la administración de
energía, la administración de dispositivos, los puntos de
montaje, los intervalos regulares cron, la encripción de
disco, el socket API/inetd, los logs del sistema syslog,
entre otros.
-
2. El sistema de registro de eventos de
systemd (gestionado por journald) se guarda en archivos
binarios2 , y solamente legibles a través de
journalctl - a diferencia del texto plano, estos archivos
son susceptibles a corrupción. Subyacentemente, systemd
ejecuta un servidor HTTP embebido para facilitar la lectura
de los logs, así como la posibilidad de imágenes QR para
enlazarlos. Es una funcionalidad tan improcedente como
costosa.
-
3. El equipo de systemd es notablemente
chauvinista y opuesto a Unix, dada su manifiesta
indiferencia por el software no perteneciente a Linux, y la
subsecuente incompatibilidad con todos los sistemas no
basados en Linux. Además, en tanto que systemd está
estrechamente ligado al API del kernel de Linux, el
desarrollo sucesivo de systemd genera incompatibilidades con
diferentes versiones del kernel. Esta es una política
aislacionista, que esencialmente constriñe al ecosistema de
Linux a su propia jaula, y sirve como un obstáculo para la
portabilidad del software.
-
4. udev y dbus son dependencias forzadas. De
hecho, udev se fundió con systemd hace mucho tiempo3.
-
5. Por defecto, systemd guarda los volcados
de memoria en los registros de eventos, en vez de
devolverlos al sistema de ficheros. Los volcados de memoria
deben ser explícitamente consultados mediante
systemd-coredumpctl4. Además de ir más allá de
toda razón, también crea complicaciones en entornos
multiusuario (buena suerte ejecutando gdb en tu volcado de
memoria si ha sido introducido dentro del sistema de
registro y no tienes acceso de superusuario), en tanto que
systemd requiere acceso de superusuario. Asume que los
usuarios y los administradores son estúpidos5.
-
6. El tamaño de systemd lo convierte en un
punto
único de fallo. A la fecha presente, systemd tiene 9
reportes CVE desde su concepción en Marzo de 2010
6.
Hasta el día de hoy no parece mucho, pero su carácter
despótico lo hará un suculento objetivo para los crackers,
teniendo en cuenta que es más pequeño en comparación con el
kernel de linux propiamente, pero igual de crítico.
-
7. systemd es virulento en su máxima
expresión. Su amplitud de funciones así como su sujeción a
numerosos paquetes obliga a los mantenedores de las
distribuciones a imponer una conversión en sus sistemas Para
muestra, el entorno de GNOME ha implementado systemd como
una fuerte dependencia en varias de sus utilidades desde la
versión 3.8. En consecuencia, las versiones superiores o
iguales a la 3.8 son incompatibles con sistemas no basados
en Linux; y debido a la popularidad de GNOME, ello ha
participado en que muchos mantenedores se han decantado por
incorporar systemd. Su rápida adopción en distribuciones
como Debian, Arch Linux, Ubuntu, Fedora, openSUSE ente otros
demuestra cuántos se están subiendo al carro, con o sin
justificación. Nótese que systemd se rehusará a
iniciar como una instancia de usuario a menos que el sistema
lo inicie con él también8.
-
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 subvertir al sistema por completo.
Pero además, significa que muchas actualizaciones del
sistema (sin tratarse del kernel) van a requerir un
reinicio, como cuando se realizan actualizaciones de Windos.
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 ocurrir9 Esto
es otro ejemplo de SPOF (punto simple de fallo).
-
9. systemd está diseñado con glibc en mente,
y no es perfectamente compatble con otras libcs10.
-
10. La naturaleza compleja de systemd se
antoja más complicada para extender y salir fuera de sus
límites. Pese a que puedes ejecutar scripts más o
menos triviales, es más difícil describir un comportamiento
que escape fuera de la caja con tantas implementaciones
infladas. . Muchos usuarios necesitarán posiblemente
escribir programas más complicados que directamente
interactúen con la API de systemd o directamente necesitarán
modificar systemd.
-
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.
