16 de febrero de 2014

La sombras de sysvinit

La burocracia debianera ha elegido finalmente systemd, y como consecuencia de ello Ubuntu abandona upstart. Como dice el refranero, para este viaje no hacían falta alforjas. Quizás lo más destacable de todo es una de las ventajas menos comentadas, que es la unificación del sistema de inicio a lo largo y ancho de la mayor parte de distribuciones.

Es buen momento para recordar que la defensa del actual sysvinit como supuesta encarnación de un ideal Unix no tiene fundamentos sólidos. Cada vez es más rechinante la obsesión con considerar "esencia Unix" una especie de nihilismo informático en el que la regla principal es diseñar todo a base de comandos comunicados por tuberías, incluso cuando los programas resultantes son horribles. Como ya conté aquí, esa manera de pensar es un lastre cultural que ignora que la concatenación de comandos comunicados por tuberías era literalmente la única manera de hacer cosas complejas en Unix, en aquel entonces no había otros sistemas de IPC.

Hace tiempo que los sistemas Unix se dieron cuenta de esas limitaciones y adoptaron el concepto de librerías compartidas, ausente en sus inicios. Llevamos décadas apuñalando por la espalda la idea de comandos simples + tuberías. Ningún sistema Unix moderno se construye únicamente así, ni lo hará en el futuro. Hoy en día las librerías compartidas predominan como manera de crear programas locales complejos a partir de elementos más simples.

Eso no quiere decir que el shell esté obsoleto, o que no sea útil. Pero proponerlo como fundamento para crear un sistema complejo como systemd o upstart no tiene por qué ser la mejor idea.  SysVinit es más bien un manojo de herramientas pegadas con celo que suelen funcionar la mayor parte de las veces, otras simplemente explotan por los aires, como podemos ver en este PDF de los programadores de upstart, en el que citan una serie de bugs típicos de sysvinit.

Sin embargo, la principal característica de systemd no está resultando tener que ver tanto con su implementación, sino con el modo de integrar diferentes partes del sistema. systemd requiere kernels compilados con una serie de opciones del kernel (cgroups, inotify, seccomp...), va a requerir en breve kdbus, proporciona un sistema de logging propio, proporcional logind, una alternativa a xinetd, deja obsoletos varios comandos de gestión del sistema, proporciona un sistema de gestion de sesiones de usuario que reemplaza a cosas como gnome-session...todo ello con el objetivo de que todo sistema que adopte systemd tenga una serie de funcionalidades y de manera de integrar servicios básicos del sistema estandarizados. Aunque muchas de esas funcionalidades son configurables y se pueden desactivar o dejar de lado, es obvio que quien adopta systemd lo hace generalmente para activarlas.

Esto es, en realidad, lo que más rechazo genera contra systemd. Pero en este blog se ha destacado en el pasado la importantísima y frecuentemente denostada función de la integración de diferentes partes de software: aunque haya quien se queje de que systemd impone, fuerza o anima a hacer cosas que no a todos podrían gustarle, también hay que tratar de ver el valor que proporciona toda esa integración y uniformidad. Como cuentan en este blog, systemd ha ganado porque se ha preocupado por los usuarios más que nadie.

Ese es un aspecto en el que los sistemas basados en shell no pueden alcanzar a systemd: obsesionados con supuestos espíritus que han distorsionado o que en realidad no existen, se han olvidado que la prioridad es crear sistemas útiles. No se trata sólo de cómo crear las cosas, sino en qué cosas deben crearse. Paradójicamente, el dejar de lado una visión "top-down" de las cosas les ha llevado posteriormente a hacer mal las cosas. El mejor ejemplo de esto último lo he visto en una historia que Lennart Poettering contaba sobre como algo en apariencia tan simple como el proceso de matar todos los procesos y apagar el sistema es mucho más complejo de lo que parece, y como, de hecho, systemd es el único sistema de inicio que apaga el sistema de manera total y absolutamente segura. El OpenRC en Gentoo, que se ha erigido en bastión de resistencia contraria a la adopción de systemd, no hace las cosas ni la mitad de bien, ni en ese aspecto ni en otros: eso si, lo hace en shell, que para sus desarrolladores es la principal medida de éxito.

12 comentarios:

  1. Perdón por el offtopic, ¿pero no crees que la decisión de Debian ha tenido más que ver con la CLA de Canonical que con los méritos extrictamente técnicos?

    ResponderEliminar
    Respuestas
    1. upstart no tiene ninguna gran ventaja respecto a systemd, puestos a sustituir el sistema de scripts actual no tiene mucho sentido utilizar un sistema de inicio que todas las demás distros excepto ubuntu habían abandonado por systemd.

      En el comité técnico de Debian había varios miembros de Canonical, uno de ellos programador de upstart. De no ser por ese peso, dudosamente upstart hubiera tenido alguna relevancia.

      Eliminar
  2. Diego, la critica a OpenRC me parece gratuita. Es más limitado, no lo dudo. Pero tiene algunas ventajas claras sobre systemd, como la facilidad de configuración y el soporte a BSDs. Además, OpenRC precisamente se cambió por Sysvinit porque permitia realizar llamadas al sistema basadas en C, asi que eso de que "lo hace en shell" es un tanto confuso. Y el que quiera sustituirlo por systemd, puede hacerlo perfectamente y está documentado en la Wiki oficial de Gentoo.

    ResponderEliminar
    Respuestas
    1. A mi no me parece gratuita, openrc simplemente es peor. Desde luego no creo que sea más fácil de configurar, y aunque utilizan programas en C cuando lo requieren, lo hacen precisamente porque no tienen más remedio y ellos mismos admiten que lo evitan en la medida de lo posible. Respecto a la portabilidad a BSDs, es completamente irrelevante.

      Me parece bien que gentoo quiera evitar el "abrazo del oso" de systemd, pero el precio que pagan es tener un sistema de inicio inferior. No creo que tenga nada de injusto señalarlo.

      Eliminar
  3. Anónimo7:29 p. m.

    Aquí desde gentoo, usando openrc y eudev, hace un tiempo he probado systemd en gentoo, así que voy a decir que le veo de malo a systemd.
    Systemd hace lo que quiere con los servicios o demonios, un demonio puede iniciar parar y hacer lo que quiere a otros demonios (se pierde el control manual de lo que uno quiere que se ejecute) esto suena casi como a spyware, un programa o servicio que no obedece a su administrador ¿como se lo puede llamar?
    Openrc podrá ser peor en velocidad, pero no en seguridad, para que quiero seats? mi pc es computadora personal no computadora comunitaria.
    El journald de systemd es una vergüenza total, pelea de continuo con syslog-ng al punto de no andar ambos a la vez, además porque usar un formato binario para guardar los logs cuando el de texto de toda la vida se lo puede ver con cualquier editor y filtrar con un simple $ cat |grep -i
    Sinceramente veo fardos de billetes pasando por debajo de las mesas....si señores, el dinero lo compra todo, pero por favor no sean tan ingenuos.

    ResponderEliminar
    Respuestas
    1. "un demonio puede iniciar parar y hacer lo que quiere a otros demonios"

      Si esto te parece un problema, mucho me temo que lo que necesitas no es un gestor de inicio....

      Eliminar
  4. Anónimo12:42 a. m.

    Un solo tipo arrasa con todo el sistema de inicio y servicios, de paso se lleva puesta la compatibilidad con otros unix y nadie dice nada...este mundo si que esta patas arriba, por supuesto que me parece un problema que alguien decida por mi que y como se deben iniciar los servicios de mi pc, jamás se escucho decir que hayan dependencias de un servicio con otro y en todo caso si los hubiera es el administrador el que debe activarlos y determinar su orden de inicio, caso contrario se pierde el control de como y cuando se activan esos servicios. Sinceramente no entiendo mas nada, todos ven esto y nadie dice nada.
    A todo esto muy buen blog, muy buenos artículos, lo tengo en marcadores...te felicito.

    ResponderEliminar
  5. Anónimo1:58 a. m.

    http://lamiradadelreplicante.com/2014/04/05/linus-torvalds-estalla-contra-uno-de-los-principales-desarrolladores-de-systemd/

    https://plus.google.com/111049168280159033135/posts/Kd57G8s1cTD

    ResponderEliminar
  6. Anónimo2:22 a. m.

    Que forro que sos, te molesta hasta que pase un link donde muestran pruebas de que systemd es una reverenda cagada. Dime, quien te paga por no querer ver la realidad ?

    ResponderEliminar
    Respuestas
    1. No me molesta, es blogger quien ha bloqueado tu comentario como spam, no sé por qué.

      Quien no es capaz de ver la realidad eres tú. Que te atrevas a criticar la existencia de dependencias dice mucho de lo que sabes de sistemas de inicio: precisamente, las dependencias es una de las cosas que no son particularmente un invento de systemd. Incluso los sistemas de inicio tradicionales como openrc tienen dependencias, tan configurables como cualquier otras. En este aspecto, systemd lo único que innova es hacer que gestionar las dependencias sea más sencillo.

      Eliminar
    2. Anónimo5:54 a. m.

      Las personas como tu me aburren:
      http://hackingthesystem4fun.blogspot.mx/2014/09/por-que-systemd-es-una-mierda.html

      Eliminar
  7. Anónimo4:07 a. m.

    Te debo un disculpa, veo el comentario que hice, lo veo y me avergüenzo...disculpame pensé en ese momento que no aprobaste su publicación.
    Siguiendo con systemd, tampoco lo veo tan mal, tengo una notebook con archlinux así que se bien como viene systemd. Como comentario final, lo que veo de bueno es que muchas distros hallan adoptado systemd, mejorará mucho con todo el aporte de cada distro, pero es justo esa la parte mala de systemd, no es un sistema maduro, están usando a la gente forzándola con versiones de systemd con bugs para avanzar mas rápido y eso fue lo que me toco a mi, terribles problemas de inicio y cuelgues.
    Veremos que pasa en un futuro aquí a uno o dos años más, seguramente se hará estable.
    Gracias nuevamente por no tomártelo a mal y explicar que paso con blogger.

    ResponderEliminar