index.html (14305B)
1 <!DOCTYPE html> 2 <html> 3 <head> 4 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 5 <meta name="viewport" content="width=device-width, initial-scale=1" /> 6 <title>Syllabus: systemd sucks</title> 7 <link rel="icon" type="image/png" href="/favicon.png" /> 8 <link rel="stylesheet" type="text/css" href="../article.css" /> 9 </head> 10 <body> 11 <header> 12 <p class="title"><i>Syllabus</i> de <i>systemd</i> y alternativas <i>init</i></p> 13 <p class="date">1 de noviembre de 2021 • fjbalon</p> 14 </header> 15 <p><emb>systemd</emb> -como muyahidín- expande su propio orden, su estado, su gran complejidad monumental, haciendo la guerra contra la filosofía Unix. Su inherente naturaleza dominante y viral le convierte en un segundo kernel, que se extiende tentacularmente por todo el ecosistema GNU/Linux, como golpe de estado e intruso que toma el control del sistema, y fuerza al usuario a claudicar ante él.</p> 16 <p>Tiempo he pasado utilizando distribuciones en base a este malware de Poettering, y cuanto más profundizo y adquiero conocimiento técnico, más detesto la forma en la funciona y está diseñado. Las siguientes palabras, a modo de <i><a href="https://es.wikipedia.org/wiki/Syllabus">Syllabus</a></i> recopilan los que yo considero los errores de <emb>systemd</emb>, que cada vez se expande más -lo que considero altamente preocupante- en el mundo de GNU/Linux.</p> 17 <ol type="I"> 18 <li> 19 <p><emb>systemd</emb> se enfrenta a la filosofía del «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, absorbiendo de forma absolutista el control de energía, manejo de dispositivos, puntos de montaje, cron, cifrado de discos, <emb>inetd</emb> y api para sockets, syslog, configuración de red, manejo de login y sesiones, readahead, particiones GPT, registro de contenedores, manejo de hostname, locale y tiempo, etcétera.</p> 20 <p><emb>systemd</emb> 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.</p> 21 </li> 22 <li> 23 <p>Los archivos de journal de <emb>systemd</emb> son manipulados por journald son almacenados en un complicado formato binario que debe ser consultado utilizando <emb>journalctl</emb>. Lo que vuelve los logs de journal potencialmente corruptibles, sin transacciones ACID. El consejo de los desarrolladores de <emb>systemd</emb> es irracional: ignorar el problema. Además posee integración con un servidor HTTP embebido <emb>libmicrohttpd</emb>. Y se sirven códigos QR a través de <emb>libqrencode</emb>. Un caos.</p> 24 <p>Además, por defecto, <emb>systemd</emb> guarda los core dumps en el journal, en lugar del filesystem. Los core dumps deben ser explícitamente consultados utilizando coredumpctl. Esto es irracional y crea complicaciones en entornos multiusuario, dado que <emb>systemd</emb> requiere acceso root para controlarlo.</p> 25 </li> 26 <li> 27 <p><emb>systemd</emb> muestra un abierto desprecio hacia el software no-Linux en subsecuente incompatibilidad con todos los sistemas de la familia Unix no-Linux. Esto es debido a que <emb>systemd</emb> está fuertemente acoplado a la api del kernel Linux, lo que provoca que las diferentes versiones de <emb>systemd</emb> sean incompatibles entre diferentes versiones del kernel Linux. 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. 28 </p> 29 </li> 30 <li> 31 <p><emb>udev</emb> y <emb>dbus</emb> son dependencias forzosas. De hecho, <emb>udev</emb> se fusionó con <emb>systemd</emb> 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 implicaciones políticas de ello son altas, y hace que muchos paquetes que dependen de <emb>udev</emb>, a su vez dependan de <emb>systemd</emb> (una estrategia maestra para llevar a cabo la yihad), mas allá de la existencia de forks, como <emb>eudev</emb>. A partir de <emb>systemd-209</emb> los desarrolladores ahora tienen su propia, no estándar y escasamente documentada api sd-bus que reemplaza mucho del trabajo de <emb>libdbus</emb>, y disminuye aún más la transparencia.</p> 32 </li> 33 <li> 34 <p>El tamaño de <emb>systemd</emb> lo vuelve un punto simple de fallo, un riesgo. Su esencial y prepotente naturaleza lo convertirá en un blanco jugoso, ya que es mucho más pequeño que el kernel Linux en sí mismo, pero prácticamente igual de crítico.</p> 35 </li> 36 <li> 37 <p>system es viral por naturaleza: su alcance en funcionalidad y arrastre como dependencia a cientos de paquetes significa que los mantenedores de distribuciones necesitarán una convertirse a la fe de Lennart Poettering, o quedarán a la deriva. La rápida adopción y conversión por parte de distribuciones como Debian, <emb>Archlinux</emb>, <emb>Ubuntu</emb>, <emb>Fedora</emb>, <emb>openSUSE</emb> denota una clara lealtad por parte del pueblo.</p> 38 </li> 39 <li> 40 <p><emb>systemd</emb> se encierra a sí mismo en el <emb>PID 1</emb>, por lo que hay toneladas de escenarios en los cuales puede crashear y tumbar al sistema por completo (kernel panic). No sólo eso, a consecuencia, muchas actualizaciones del sistema (obviando el kernel) van a requerir un reinicio. Para ser justo, <emb>systemd</emb> provee un mecanismo para reserializarse y reejecutarse a sí mismo en tiempo real; pero claro, si esto falla, el sistema cae por completo. Hay muchas formas por las que esto puede ocurrir. Esto es otro ejemplo de SPOF (punto simple de fallo).</p> 41 <p>Entre las razones por las cuales <emb>systemd</emb> quiere o necesita correr como <emb>PID 1</emb>, 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 <emb>PID</emb> para esperarlo (wait) o enviarle una señal.</p> 42 </li> 43 <li> 44 <p><emb>systemd</emb> fue diseñado con <emb>glibc</emb> en mente, y no se preocupa mucho por soportar otras <emb>libcs</emb>. En general, la idea de librería C estándar de los desarrolladores de <emb>systemd</emb> es una que sea compatible bug-por-bug con <emb>glibc</emb>.</p> 45 </li> 46 <li> 47 <p>La naturaleza complicada de <emb>systemd</emb> lo vuelve difícil de extender y salir fuera de sus límites. Mientras que es posible más 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 <emb>systemd</emb>, o directamente necesitarán parchear <emb>systemd</emb>. 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 <emb>systemd</emb> 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.</p> 48 </li> 49 <li> 50 <p>El parasitismo de <emb>systemd</emb> es el símbolo de algo más sí mismo: muestra un cambio radical de pensamiento en la comunidad Linux, una apostasía y una lealtad a lo vehementemente postmoderno, monolítico, fuertemente orientado a sistemas de escritorio, limitante, aislacionista, reinventor de la rueda, y un gran anti-patrón en general.</p> 51 </li> 52 </ol> 53 <p>Tras este <i>Syllabus errorum complectens praecipuos nostrae aetatis errores</i>, es evidente que desde hace tiempo anhelo liberar mi sistema de <emb>systemd</emb>, que como bien sabe el lector -o eso espero- ha extendido su oscura influencia en gran parte del mundo GNU/Linux, haciendo difícil experimentar y probar con otros demonios. Aunque tengo un profundo apego y experiencia con <emb>Archlinux</emb>, debido a su dependencia de <emb>systemd</emb>, me he visto prácticamente obligado a buscar alternativas libres de éste.</p> 54 <p>Tras investigar posibles opciones, como <emb>Devuan</emb>, <emb>Alpine</emb>, <emb>Slackware</emb> o <emb>void</emb>, ha aparecido ante mí <emb>Artix</emb>, una versión de <emb>Archlinux</emb> libre de <emb>systemd</emb>. Esto trae una serie de ventajas para mí, como la fácil adaptación entre <emb>Archlinux</emb> y <emb>Artix</emb>, mantenimiento de la comunidad de <emb>Archlinux</emb>, mantendría el sistema de paquetes <emb>pacman</emb>, etc.</p> 55 <p>Sin embargo, esta elección no vendría exenta sufrimiento. <emb>Artix</emb> me obliga a enfrentar una de las decisiones más complicadas de mi vida técnica en el mundo de GNU/Linux y Unix: elegir el proceso init para mi sistema operativo. Sabía que esto requeriría un arduo trabajo de investigación, reconocimiento y pruebas, pero estaba dispuesto a asumir cualquier reto para alcanzar la libertad. Así, como caballero medieval enfrentando a un dragón, me adentré en la búsqueda del init perfecto. Los nombres de <emb>Runit</emb>, <emb>Dinit</emb>, <emb>OpenRC</emb> y <emb>S6</emb> <sup>1</sup> resonaban en mi mente como las leyendas de antaño, y estaba dispuesto a poner a prueba cada uno de ellos para encontrar el que más se adaptara a mi uso.</p> 56 <p><emb>OpenRC</emb> es conocido por su simplicidad y estabilidad. Para usuarios venidos de distribuciones como <emb>Gentoo</emb> parece la opción más obvia. De todos los init fuera de <emb>systemd</emb>, parece ser el que tiene mejor soporte, es fácil de entender y tiene un comportamiento predecible. Además, permite la ejecución de scripts personalizados durante la fase de inicio. </p> 57 <p><emb>S6</emb> es muy rápido, simple y eficiente, pero no es particularmente fácil de usar. El uso de recursos es mínimo, cuenta con una arquitectura modular y es muy estable y confiable, lo que le hace un sistema idóneo para sistemas críticos. Sin embargo, su simplicidad proviene del hecho de que es relativamente pequeño y divide la funcionalidad entre diferentes procesos, lo que hace que cualquier cambio en el sistema requiere compilar una base de datos (aunque su enfoque de compilación teórica lo hace más ligero y menos propenso a errores). Está íntimamente ligado al mundo Unix, pareciendo estar diseñado para ser una capa lo más delgada posible sobre el sistema operativo, algo deseable.</p> 58 <p><emb>Runit</emb> es extremadamente simple, especialmente si lo comparamos con el resto. Su estructura sencilla lo hace poco propenso a errores, sin embargo no ofrece muchas características, lo que hace que la complejidad se delega en los scripts de shell que inicia. <emb>Runit</emb> inicia rápido y tiene un uso de recursos mínimo, es muy estable, configurable y confiable.</p> 59 <p><emb>Dinit</emb> es muy liviano y ligero, lo que le permite mantener una altísima velocidad de arranque y apagado. Es fácil de usar, teniendo una sintaxis sencilla de adaptar desde <emb>systemd</emb>, y además, constituye una mejora significativa de características y herramientas con respecto a <emb>Runit</emb>. Su curva de aprendizaje puede ser elevada.</p> 60 <p>Teniendo en cuenta que mi uso de init y gestión de procesos puede definirse en la simplicidad, aun entendiendo la ambigüedad de la palabra, lo considero elemental y convergente con ligereza y legibilidad. El uso que a mi máquina me exige iniciar y parar regularmente distintos procesos, que de hecho no quiero tener iniciados de forma defectuosa si no es por una razón concreta. Por ello, la gestión y administración de procesos y demonios debe ser sencilla y elegante. Y aunque no lo considero determinante ni fundamental, mantener una buena velocidad de arranque es algo deseable e interesante.</p> 61 <p>Evidentemente, no hay respuesta correcta y no se basa ni siquiera en mi experiencia, sino en la de otros en la comunidad. Mis conclusiones a raíz de estas lecturas, podrían ser que <emb>S6</emb> sería la opción más apropiada para un servidor, por su estabilidad, seguridad y estructura Unix, así como robustez.</p> 62 <p>Por otro lado, para un uso de escritorio, me habría decatado por <emb>Runit</emb>. La decisión ha sido complicada con respecto a <emb>Dinit</emb>, debido a que el segundo mantiene una funcionalidad similar a <emb>Runit</emb>, pero ofreciendo características adicionales, como soporte para programación de tareas, capacidad de gestionar dependencias complejas entre servicios, API de control, etc.Pero en búsqueda de simplicidad y eficiencia, considero la filosofía de diseño de <emb>Runit</emb> más cercana a mí, y a mi fórmula de uso.</p> 63 <p><sup>1</sup> Desgraciadamente he dejado fuera de artículo a <emb>SysVInit</emb>, puesto que no constituye una opción por defecto en <emb>Artix</emb>.</p> 64 65 <h1>Bibliografía y enlaces de interés</h1> 66 <ul> 67 <li><a href="https://nosystemd.org">nosystemd.org</a></li> 68 <li><a href="http://ewontfix.com/14">Broken by design: systemd</a></li> 69 <li><a href="https://wizardofbits.tumblr.com/post/45232318557/systemd-more-like-shit-stemd">Systemd? More like Shit-stemd</a></li> 70 <li><a href="https://ihatesystemd.com">ihatesystemd</a></li> 71 <li><a href="https://the-world-after-systemd.ungleich.ch">The world after systemd</a></li> 72 <li><a href="https://www.linuxito.com/gnu-linux/nivel-alto/431-por-que-systemd-es-una-mierda">¿Por qué systemd es una mierda? - Linuxito</a></li> 73 <li><a href="https://www.reddit.com/r/artixlinux/comments/xr0uih/about_your_init_choices_runit_openrc_s6_dinit/">About your init choices (Runit, OpenRC, S6, Dinit...)</a></li> 74 <li><a href="https://www.reddit.com/r/artixlinux/comments/11d990e/void_vs_artix/">Void vs Artix</a></li> 75 </ul> 76 77 </body> 78 </html>