entramado.net

Demonios del sistema y el sexo de los ángeles

Pieter_Bruegel_the_Elder_-_The_Fall_of_the_Rebel_Angels_-_Google_Art_Project

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:

  1. Los programas deben tener una única función y hacerla bien.
  2. Los programas deben funcionar en conjunción con otros.
  3. 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 @jordila@lamatriz.org 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.

20 respuestas a “Demonios del sistema y el sexo de los ángeles”

  1. Demonios del sistema y el sexo de los ángeles http://litox.entramado.net/2016/07/07/demonios-del-sistema-y-el-sexo-de-los-angeles/ 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…

  2. jordila dice:

    @litox … antes de leerlo, me encanto lo tecnopoético del título …

  3. @jordila gracias! Hoy estaba inspirado. No recordaba que gusto da enviar a publicar un post 🙂

  4. jordila dice:

    en él estoy… aprendiendo de blog en blog sobre #
     “nuestro demonio más polémico … “
    .-  @litox

    http://litox.entramado.net/2016/07/07/demonios-del-sistema-y-el-sexo-de-los-angeles/

     

  5. jordila dice:

    @litox ya veo… algo más de luz en todo este galimatías que tantas tecnopasiones desata .
    “La chapuza” … de las sesiones SSH… ya me parecía a mí…
    Más orden y limpieza en los procesos de arranque … ¿mejor orquestados? ¿que otras ventajas tendría # vs init  en tu óptica ?

  6. @jordila principalmente la gestión de procesos de forma descriptiva, no imperativa como antes por scripts. Scripts que por cierto tenía que ordenar el gestor de paquetes, es decir que era apt el que hacía una función que no era la suya. Con systemd solo es necesario un archivo describiendo las dependencias de ejecución del demonio y listo! Todo funciona como debe. Lo de crear mejores demonios para la administración de sistemas creo que traerá muchas mejoras, el caso lo vemos por ejemplo en los nuevos sistemas de paquetería (Snap y compañía) que funcionan mediante demonios y el proceso de usuario es solo una interfaz.

  7. Omar dice:

    Hay sistemas mucho mejores que systemd, pero como a Red Hat se le ocurre que hay que usar sus herramientas aqui estamos, OpenRC es incluso más veloz y eficiente que systemd….

  8. @omarlibre no he probado OpenRC, me parece buena opción, pero no creo que Red Hat haya influido sobre Debian en esto.

  9. Juan Ruiz dice:

    @litox Fantástica imagen! Qué bien elegida en relación con lo que nos dices.

  10. Omar dice:

    @litox bueno Red Hat presiona desde el momento que anda detrás de todo tipo de proyecto exigiendo que lo adapten para funcionar con systemd, ellos quieren demostrar que o es systemd o es la jungla……. para mi lo más espantoso de todo esto de romper con la filosofia Unix no es el hecho en si, sino que estan generando que mucho software en el afán de volverse compatible con systemd, se vuelva incompatible o de dificil ejecución en ambientes que no lo usan, y eso incluye no solo distribuciones GNU/Linux sino tambien toda la gama de los sistemas BSD.

  11. @omarlibre creo que es más bien que la comunidad systemd ha rescatado proyectos con poco o nada desarrollo para adecuarlos a systemd, los que nombro en el post, conveniente enlazados, pero si te refieres a algún otro que no conozco, por favor, infórmanos.

  12. Omar dice:

    Ejemplo tmux que querían se adaptara y ellos los mandaron a pasear a los de systemd @litox @ziggys

  13. jordila dice:

    charlando con @litox y su pizarra … ya me pica la curiosidad lo de # https://lamatriz.org/attachment/215602 como empaquetamiento de aplicaciones … ¿ comentó @manuel en un encuentro de un jueves cualquiera en @lasindias @club que Ubuntu 16 ya lo incorporaba o lo habré soñado ?

    Eh… Venía leyendo algo al respecto…

    https://lamatriz.org/url/190814

    pero no jugué con ello aún .. mmh

    ¿ alguien con experiencia en ellos ‘en la sala’ ?

      # # # …  #  packages ?

    @gustavo @elbinario @chemalonso @fanta  @zero 

    https://lamatriz.org/url/190814

  14. @jordila @manuel @lasindias @elbinario @gustavo @club @fanta @zero creo que sí! Y flatpack que es su contrapartida. Tengo que hacer otra entrega de “El GNU/Linux que se viene”, que la última se quedó desfasada.

  15. jordila dice:

    @litox la leeremos con avidez … 🙂

  16. jordila dice:

    @litox … ¿ te refieres a este blog post en la pizarra ?

    @manuel @lasindias @elbinario @gustavo @club @fanta @zero

  17. jordila dice:

    juass … quise decir … ¿te refieres a este blog post en la pizarra de @litox  ?

    @manuel @lasindias @elbinario @gustavo @club @fanta @zero

  18. jordila dice:

    ja,ja !… a ver si a la tercera va la vencida … pues parece que mis manazas en el teclado tienen vida propia…

    ¿te refieres a este blog post en la pizarra de @litox  ?

    mmh… leamos…

    http://litox.entramado.net/2014/07/25/el-linux-que-se-viene/

    @manuel @lasindias @litox @elbinario @gustavo @club @fanta @zero

    esperamos segunda versión… 🙂

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Todos usamos cookies, acéptalo ya. más información

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close