- el-gnulinux-que-se-viene
Demonios del sistema y el sexo de los ángeles
Las filosofía Unix, la que impera en esta familia de sistemas operativos desde que apareció allá en los 70, se puede resumir en estas tres frases:
- Los programas deben tener una única función y hacerla bien.
- Los programas deben funcionar en conjunción con otros.
- La interfaz de comunicación es el texto plano.
Me parecía una buena forma de empezar el escrito, el recordar cual es esta filosofía que tantos esgrimen en contra de systemd, nuestro demonio más polémico. También me parecía correcto recordar el famoso significado de las iniciales GNU, “GNU’s not Unix!”, que en nuestra lengua diríamos algo como:
¡Ñu no es Unix, ostia! Algún ñusero
Y es que han corrido líneas de código y ríos silicio desde que se fundó la filosofía Unix y el panorama que tenemos ahora es bastante distinto al de los 70, 80 y 90, se me ocurren dos diferencias significativas, primero que casi todos los sistemas son multinúcleo y segundo que hay mucha mayor diversidad de dispositivos, sobretodo por la aparición de los dispositivos empotrados, móviles, tabletas, relojes y todo lo que viene con la Internet de las Cosas.
Esto hace que los programas ya no se conecten unos a otros de forma secuencial mediante fontanería software, si no que pueden correr en paralelo y comunicarse mediante un protocolo de paso de mensajes, para esto se ha estandarizado DBus que ha pasado de ser una utilidad para los escritorios a ser una de las herramientas más útiles que tiene GNU/Linux. Este uso de DBus ha hecho que la premisa 2 de la filosofía Unix, siga siendo válida, pero de una nueva forma. La premisa que invalida por completo es la 3, la comunicación en DBus es de forma binaria, no me voy a meter a discutir sobre que es mejor, si el texto plano o el binario, porque es igual que la bizantina discusión entre XML y JSON, ambos tienen ventajas e inconvenientes, defensores y detractores acérrimos de cada uno y sinceramente creo que va un poco por modas la opinión mayoritaria sobre el tema, en el sistema de tuberías de Unix tenía su lógica usar siempre texto plano, ahora ya no tanto.
Y con esto llegamos a la premisa número 1, la que nadie quiere poner en duda, yo tampoco lo haré. Como desarrollador creo que el desacoplamiento de una pieza de software de otras algo extremadamente necesario en un buen diseño y hay que buscarlo siempre que se pueda. Mi opinión sobre systemd es que se ha malinterpretado cual es su función única en el sistema, sí es posible que en un principio aspirara a sustituir al tradicional Init, pero vamos, pensémoslo bien, desde el principio se llama systemd, demonio del sistema, está claro que era algo más que un simple arrancador. Para mí systemd es un administrador de demonios y como tal se encarga del ciclo de vida de los procesos no atendidos por los usuarios, es decir, los demonios. ¿Y journald, udev, logind, networkd y otros? Son dependencias de systemd, cierto, algunas las necesita para funcionar, si no quieres usarlos eres libre de no usar systemd o de desarrollar una adaptación del susodicho demonio para otros sistemas de este tipo y enviar un pull request al upstream.
No me quiero olvidar de porqué estoy aquí contando esta historia, vino por alusiones de @[email protected] sobre un artículo en etccrond.es, buen blog por cierto, donde se criticaba la última decisión del equipo de desarrollo de systemd, matar los procesos que queden corriendo al cerrar una sesión de usuario. A algunos administradores de sistemas esta decisión no les ha gustado nada, su argumento es que ellos día a día cierran sesiones ssh con procesos corriendo y vuelven para comprobar que el proceso ha terminado correctamente. Esto lo realizan redirigiendo las salidas estándar y de error a un archivo que luego revisan. Siento ser duro en esto, pero las cosas por su nombre, es una chapuza, si has llegado hasta aquí sabrás cual es la diferencia entre un demonio y un proceso de usuario, un proceso de usuario se supone que va a estar monitorizado por el usuario mientras se ejecuta y un demonio está preparado para correr sin la atención de ningún usuario, pero está en comunicación con el sistema de logs para dejar constancia de cuando se producen ciertos eventos deseados o indeseados. Hacer correr procesos de usuario como si fueran demonios y crear logs manualmente no está dentro de ninguna filosofía Unix ni lo estará nunca. Lo que necesitamos realmente es una utilidad que demonice un proceso al vuelo y se integre con el sistema de logs que se esté usando. En el ecosistema systemd esto se llama systemd-run.