entramado.net

Posts tagged “El GNU/Linux que se viene

Ubuntu hacia la auténtica convergencia

Ubuntu al fin ha abandonado el desarrollo de su escritorio alternativo con Unity+Mir, para volver a Gnome, esta vez con el muchísimo más moderno gestor gráfico Wayland, quizá es má correcto llamarlo protocolo gráfico. Esto reconcilia a Ubuntu con gran parte de la comunidad, se acaba con una división inútil y confirma la falta de carisma de Canonical para formar una comunidad a su alrededor, cosa que por el contrario sí ha conseguido RedHat, no sin falta de polémica.

Ubunto ha abierto un camino hacia una auténtica convergencia, la de las distribuciones GNU/Linux, quizá solo unidos se le pueda hacer frente al imparable Android, el que creo es el auténtico enemigo del Software Libre. Respecto a la convergencia hacia el móvil veremos nuevas soluciones construidas desde la comunidad, no me cabe duda.

Pero resuelta la parte gráfica en todas las distribuciones mientras tanto se ha abierto un nuevo frente, el auge de las aplicaciones en contenedores ha puesto en evidencia los antiguos gestores de paquetes de las distribuciones, para solucionar este problema se han creado soluciones como Flatpack y Snap, que complementan a los anteriores y nos permiten instalar aplicaciones de terceros de forma segura en nuestros sistemas. Esto puede derivar en la creación de tiendas de aplicaciones para todo el ecosistema GNU/Linux, con este objetivo creó Canonical Snap, paralelamente Flatpack se desarrolló desde Gnome, RedHat y toda la comunidad, mi apuesta en este asunto es una vez más por la solución más abierta, Flatpack, una que no te ata a la tienda de aplicaciones que Canonical decida, pero queda mucho camino por recorrer, veremos como evoluciona este tema.


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.


El Linux que se viene

Estos últimos meses el ecosistema GNU/Linux está tomando carrerilla. El núcleo Linux se ha diversificado muchísimo con la normalización de los sistemas empotrados producida por móviles, tabletas y todo lo que está por venir. El tipo de computación que se hace hoy tampoco es el mismo que cuando nació Unix. Los sistemas ahora son multinúcleo y las tarjetas gráficas se han convertido en los procesadores secundarios del PC o del móvil, eso que se llama aceleración hardware ha cambiado la estructura de las computadoras, que pasan de ser sistemas monolíticos a un conjunto de múltiple hardware conectado por distintos buses. Y todo ello sin que nos hayamos metido aun en computación distribuida o incluso ubicua.
Los retos de GNU/Linux son enormes, pero ya empezamos a vislumbrar las soluciones que propone la comunidad. Vamos a pegarles un repaso.

  • KDBus: D-Bus es un estándar de paso de mensajes entre procesos que se utiliza desde hace tiempo en los escritorios libres. KDBus es la integración de D-Bus en el Kernel Linux. Esto normalizará su uso en Linux y hará posible el resto de mejoras que voy a nombrar a continuación.
  • Wayland: Hasta ahora el sistema gráfico de Linux siempre ha venido de la mano de las X, un sistema que lleva tanto tiempo entre nosotros que ha ido acumulando funciones que hoy en día ya no se usan gracias a la aceleración por hardware entre otras cosas. Para aligerar el sistema gráfico se ha decidido sustituir por Wayland, un estándar que gestiona la parte gráfica de cada aplicación sin tener que utilizar un único y pesado núcleo. Al final se resume en una librería en la aplicación de usuario y un compositor que mezcla las imágenes de todas las aplicaciones, el compositor lo suelen implementar los escritorios así que no notaremos prácticamente ni el cambio. Ubuntu por su lado está desarrollando su propio sistema gráfico, Mir, pensando únicamente en su sistema operativo, lo que lo hace poco atractivo para la comunidad, veremos como acaba el tira y afloja.
  • Systemd: Un tira y afloja que ya se ha dado por zanjado es el de Upstart, la alternativa de Ubuntu a Init, el gestor de arranque tradicional de Linux. El problema de Init es su incapacidad de utilizar varios núcleos en el arranque, por eso han aparecido nuevas soluciones, a pesar de que siempre hay críticas. Finalmente se ha impuesto SystemD, una solución técnicamente superior, que se está extendiendo a todas las distribuciones, lo que va a permitir una compatibilidad entre distros que no se ha visto nunca antes.

Espero que a base de estandarización y modernización, GNU/Linux se popularice como una opción real tanto para escritorio como para móviles y no nos conformemos con derivados no libres como Android, ni con el dinosaurio de Microsoft.


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