28 de julio de 2014

X.Org Server 1.16: Ahora empezaba a ponerse interesante

No deja de ser paradójico que, ahora que Wayland se está consolidando, nos vengan con una nueva versión del servidor gráfico de X.org, la 1.16, que incorpora unas novedades que, de no existir Wayland, causarían muchísimo más ruido del que hemos visto.

Me refiero, por supuesto, a la inclusión de Glamor. Se trata de un proyecto con ya unos añitos de edad, consistente en utilizar OpenGL en todas las APIs 2D de X.org. Las ventajas son múltiples: por una parte, se aprovechan las capacidades de aceleración del hardware moderno, por otra, ofrece la oportunidad de consolidar la forma de acelerar esas APIs en una sola solución para todas las GPUs que elimine optimizaciones particulares para cada GPU, y de ese modo establecer una arquitectura de aceleración definitiva que resuelva los problemas de rendimiento de la extensión Render que las anteriores arquitecturas nunca resolvieron del todo.

El problema de Glamor y la razón por la que esto no se hizo antes es que que, como es sabido, las impresionantes capacidades del hardware gráfico moderno no son siempre capaces de implementar con buen rendimiento las tradicionales y aparentemente estúpidas operaciones "2D". Sin embargo, parece ser que a base de trabajo duro (Keith Packard ha escrito bastante sobre ello: 1, 2, 3, 4) han conseguido una solución decente.

Y lo curioso es que un titular como "los gráficos de Linux pasarán a estar completamente acelerados vía OpenGL" hubiese causado sensación hace sólo unos años. Pero hoy la gente está más interesada en Wayland, que ofrece eso y más.

Lo mismo pasa con otra de las novedades: integración con systemd-logind, que no sólo permite a X.org funcionar mejor como servicio de sistema, permite ejecutar el servidor de X.org sin privilegios root.

Esta versión del servidor de X.org es, sin duda, una de las más importantes en mucho tiempo. Pero el hecho de que su otra gran novedad sea la inclusión de XWayland, da una pista de por dónde van los tiros.

14 de julio de 2014

Avanzando a golpe de actualizaciones de systemd

El debate frenético que generó la adopción debianera de systemd, seguida de la consecuente adopción ubuntera, ha consumido los flamewars sobre sistemas de inicio. No es que haya desaparecido: el tema sigue viéndose, y se discute -y más que se discutirá-, pero se trata de una discusión aislada y repetitiva, desapegada de los eventos del mundo del software libre, que ya ha pasado página. Systemd ha ganado, y el ruido de la oposición no se ha transformado en proyectos capaces de sustituirlo (y por capaces no me refiero a openrc), , lo cual es un indicativo fiable de que, en realidad, systemd es una mejora bienvenida por la mayoría.

Tenemos, por tanto, un mundo Linux que, en su gran mayoría, usa systemd o lo usará en próximas versiones. Las consecuencias de este cambio son muy importantes y son, de hecho, la que probablemente es la mayor ventaja de systemd, y la menos discutida: la unificación del sistema base de la mayoría de las distros en un mismo proyecto, una utopía soñada que existía literalmente desde el nacimiento de las primeras distros, y que sólo systemd ha logrado materializar.

Y esta es una ventaja que Lennart Poettering tiene toda la intención de utilizar. Sin ningún complejo, hace tiempo que proclama a los cuatro vientos que systemd ya no sólo un sistema de inicio y de gestión de servicios, sino una plataforma, e incluso el pegamento que une a las aplicaciones con el kernel. Casi nada. Entre sus últimas novedades y sus planes de futuro se encuentran un pequeño sustituto de network-manager, de ntpd, una implementación simple de containers, sandboxing de aplicaciones y servicios, gestión de servicios de todas las instancias de un proyecto albergado en la nube o de todos los containers que estén siendo ejecutados en el sistema...características que la práctica totalidad del mundo Linux conseguirá con una simple actualización. Y esto es lo verdaderamente novedoso: que el sistema base de Linux pueda evolucionar con una simple actualización.

Como ejemplo de esto último están las últimas novedades que están trabajando. Consiste en convertir a todo sistema que use systemd en un sistema "sin estado", un concepto que consiste en esencia en hacer lo necesario para que todo el software de la distribución se instale en /usr, y que en /etc y /var se almacene exclusivamente la configuración y datos generados por el usuario - el "estado" del sistema. Esto permite características curiosas, como un "reseteo del sistema": bastará vaciar el contenido de /etc y /var, y el sistema regresará al mismo estado inmaculado que tendría tras haber reinstalado la distro de cero. Es decir, se eliminará la necesidad de reinstalar la distro, bastará utilizar esta función de reseteo. También ayudará a la implementación de instaladores que distribuyan un sistema reseteado como método de instalación. Y como /usr pasa a consolidarse como el lugar donde reside el software de la distribución y donde normalmente nunca se escribe nada, se podrán crear instaladores que consistan simplemente en actualizar /usr, y tener varios snapshots de /usr, y garantizar mediante cifrado la integridad de /usr.

Antes de systemd, cosas así eran difíciles de ver. Cada distribución se lo hubiese montado a su manera, con sus propios scripts, sin fuerza agregada suficiente como para forzar a programas upstream a adoptar los cambios necesarios que las hiciesen posible. Pero systemd si tiene la fuerza necesaria para implementar estos cambios, y para animar a upstream a incorporar cambios que harán más fácil la adopción de estas características en todas las distros. Se trata de un círculo virtuoso que hace más fácil hacer cambios revolucionarios con cada vez menor coste para las distros. Sólo hay un precio a pagar: vender el alma a systemd.

8 de julio de 2014

Noticias Wayland (III)

Como continuación de los dos posts anteriores (1, 2) sobre noticias de Wayland, he aquí lo sucedido desde el último post (ocho meses):

  • Wayland/Weston 1.4 (24 Enero): Wayland: Aparte de mejoras de fiabilidad, el único cambio importante en Wayland es que se ha incluido en su repositorio la característica "sub-superficies", lo cual lo eleva al rango de API oficial y estable. Las sub-superficies permiten que una ventana pueda estar compuesta diferentes "superficies" (porciones de la pantalla en las que se dibujan cosas y que reciben eventos). La gracia está en que las diferentes superficies que componen una ventana son visibles para el compositor, lo cual permite ceder al compositor la tarea de mezclarlas y dibujarlas como crea conveniente en lugar de obligar a ello a la aplicación. Esto permite que el compositor pueda explotar las capacidades de aceleración de hardware al máximo.
  • En Weston 1.4, por su parte, destaca el inicio de la implementación de xdg-shell. xdg-shell es un protocolo utilizado para las funciones de un shell de escritorio,. También se ha iniciado implementación de un protocolo experimental para extender y recortar superficies (que una vez estabilizado se moverá a wayland), se ha mejorado el soporte para interacción táctil, se usa logind (lo cual permitirá usar weston sin permisos de root), se permite que un compositor anidado dentro de otro pase sus buffers al compositor principal, y otra serie de mejoras menores.
  • Wayland/Weston 1.5 (20 Mayo): Wayland apenas tuvo cambios relevantes. En Weston la principal novedad es la inclusión de soporte para XWayland (que será incluido en Xorg 1.16), lo cual permitirá a las aplicaciones X11 funcionar bajo Weston. La otra gran novedad es que se siguió mejorando la implementación de xdg-shell, con la esperanza de completarla en 1.6, coincidiendo con la publicación de Gnome 3.14. También se ha añadido soporte para que una aplicación pueda mostrase a pantalla completa, algunas animaciones y soporte de diferentes formatos de color.
Eso por parte de Wayland y Weston. Aunque pueda parecer (erróneamente)poca cosa quisiera insistir en que Wayland y Weston están en gran medida preparados, y que la principal medida de progreso de estos proyectos no es Wayland ni Weston -que tan sólo pretende ser un compositor de referencia-, sino la creación de compositores alternativos y el portado de toolkits, librerías y aplicaciones gráficas a APIs de wayland. En este sentido, estas han sido las principales noticias sobre Wayland en todo este tiempo:
  • Se publicó Gnome 3.12, con soporte muy mejorado de Wayland. Esencialmente, mejoras en mutter (el gestor de ventanas/compositor wayland), en GTK y la implementación de xdg-shell, pero tengan en cuenta que, aunque parezca una sola cosa, dentro de xdg-shell se encuentran multitud de características que son las que implementan un escritorio completamente funcional.
  • XWayland ha sido incluido en el repositorio principal de X.org y será publicado en X.org 1.16. En el proceso, ha sido rediseñado, e incluye soporte de DRI3 y utilizará la arquitectura de aceleración glamor.
  • WebKitGTK+ mejoró el soporte para Wayland.
  • XMBC ha incluido el soporte para Wayland en el repositorio del proyecto.
  • Un emulador de OpenRISC añade soporte para ejecutar Wayland dentro del emulador.
  • El compositor Wayland "Green Island", parte del escritorio Hawaii para Wayland, basado en QT5, tuvo una nueva versión.
  • Posteriormente, ese escritorio Hawaii publicó su versión 0.2, y anunció sus planes para la versión 0.3.
  • Parches experimentales para el soporte de DRI PRIME en Wayland.
  • Trabajadores de Intel publicaron una primera versión (experimental) del navegador Chrome con soporte de Wayland. Posteriormente el port a Wayland ha ido incorporando más características, unos meses después presentaron un vídeo mostrando una versión bastante completa, y continuaron publicando más versiones.
  • Samsung anunció que Tizen 3.0 cambiará de X a Wayland.
  • Parches para implementar un alternador de aplicaciones ALT+Tab en Weston.
  • Bindings de Wayland para Perl.
  • Jolla empezó a vender su primer teléfono, que usa Wayland.
  • El proyecto Enlightenment publicó la versión 1.8 de sus librerías EFL, con soporte muy mejorado para Wayland.
  • Parches para que Wayland tenga soporte de red a través de RDP.
  • Apareció Termistor, un terminal para Wayland basado en QT 5.
  • El principal mantenedor de Kwin anunció que, tras trabajar en kwin para QT5, se centraría en mejorar el soporte de Wayland en los próximos meses. El resultado empezó a verse pronto, la Alpha 2 de KDE Frameworks 5 estuvo centrada en el soporte de Wayland, muchas aplicaciones importantes de KDE funcionan ya bajo Wayland sin grandes problemas. Sin embargo, también se anunció que a pesar del progreso en otras áreas de KDE, las primeras versiones del shell Plasma de KDE 5 no se centrarán en soportar Wayland.
  • Parches para el soporte de "DMA-BUF" en Wayland.
  • El desarrollo de Enlightenment 19 se ha centrado en gran medida en mejorar el soporte de Wayland.
  • Publicación de swc, una librería que tiene el objetivo de permitir crear compositores Wayland. Está por ver si algún otro proyecto se anima a usarla.
  • Versión 0.1 de Orbital, un shell implementado como plugin de Weston.
  • Soporte de Wayland en GStreamer 1.4.
  • El escritorio MATE, fork de Gnome 2, está trabajando en ser portado a Wayland.
  • La especificación EGL 1.5 incluyó "extensiones de plataforma" para varias plataformas gráficas, incluida Wayland.
  • Nvidia dejó bien claro que están trabajando en soportar Wayland.
  • Se anunció Maynard, un shell Wayland específico para la Raspberry Pi.
  • Fedora aprobó la incorporación de soporte para sesiones GNOME Wayland en Fedora 21, aunque el soporte no será completo.
  • Apareció Motorcar, un compositor Wayland para el Oculus Rift.
  • Primeras versiones experimentales de Firefox portado a GTK3 y funcionando en Weston.
Eso es todo.

21 de junio de 2014

Lo que se espera de un sistemas de archivos moderno

Recientemente ha corrido por internet este post de un tipo que ha perdido 28 archivos de un total de 15264 debido a corrupción en el disco duro en el que guarda una de las copias de seguridad. El post, sin embargo, está dedicado casi íntegramente a quejarse de lo malo y viejo que es HFS+. Y no deja de ser curioso, porque en este caso HFS+ no tiene la culpa de nada.

En realidad, el autor lo ha reconocido a posteriori en una edición al final del artículo, reconociendo lo obvio: que la corrupción es debida a fallos en el disco duro, no a una corrupción causada por HFS+. Pero eso no es suficiente para esconder la tendencia del artículo, que queda bien patente en la frase "HFS+ lost a total of 28 files over the course of 6 years", resaltada en negrita. Es errónea, HFS+ no ha "perdido" nada, ha sido la corrupción del disco duro. Si hubiese utilizado ZFS hubiera recibido advertencias de la corrupción, pero sin tener configurada algún modo de duplicación de datos, las corrupciones hubiesen sido igualmente irrecuperables.

Aun así, el autor podría tener algo de razón destacando que la culpa es de HFS+, ya que al carecer HFS+ de checksum de datos, si se corrompe un archivo esa corrupción se puede extender a las copias de seguridad sin que nadie lo note. Es cierto, pero resulta un tanto dramático. Windows, que está infinitamente más extendido que OS X, tampoco tiene ningún tipo de checksums ni para datos ni para metadatos (sólo el raid integrado de storage spaces), y hay millones de personas que hacen copias de seguridad en sistemas Windows (bueno, quizás no tantas...), y sin duda debe haber personas a las que los discos duros les corrompen algún archivo. Si la gente en Windows está acostumbrada a esta realidad, debe ser a que han logrado acostumbrarse a ello, o que los programas de copia de seguridad utilizan checksums por su cuenta.

Pero dejando este dilema de lado, lo que destacaría es el efecto que ha tenido ZFS: la gente acepta como algo natural exigir que su sistema de archivos sea capaz de detectar y gestionar correctamente la corrupción. Hace unos años esto no pasaba.