La retahíla de ventas empresariales que inició la crisis se ha llevado por delante a otra de las grandes candidatas que se murmuraban últimamente: Novell, histórica compañía de IT donde las haya, y dueña de SUSE Linux.
El comprador, "Attachmate Corporation", va a pagar 2.200$ milloncejos por ella. De esa cantidad hay que sustraer los 450 que les va a dar un consorcio liderado por Microsoft a cambio de su propiedad intelectual. Estas son las "malas noticias": Novell posee cientos de patentes (882 en total) relacionadas con las tecnologías que la hicieron famosa: redes (en su sentido más original), servicios de directorio, y cosas así. Del tipo de cosas que todo SO lleva haciendo desde hace décadas. ¡Sin olvidar el famoso copyright de Unix que reclamaba SCO! Si, UNIX podría pasar en su sentido legal a manos de Microsoft (no está claro si traspasan toda la propiedad intelectual o sólo patentes).
Una verdadera joya legal que Microsoft se mete en el bolsillo por cuatro duros: en el famoso trato de patentes con Novell/SUSE ya tuvieron que apoquinar 348$ millones, y en esta ocasión van a pagar 450$ millones, apenas 100 más, por meterse las patentes en cuestión en el bolsillo, con la posibilidad de recuperarlos con creces haciendo el tipo de cosas que las multinacionales de software suelen hacer con las patentes. Casi mejor no pensar lo que puede venirnos encima.
Respecto a la empresa en si, va a ser dividida en Novell y SUSE. Vuelta a los orígenes. En realidad, SUSE era la única división de Novell "sana", era la única que crecía con fuerza, las demás poco a poco iban hundiéndose. Esta es la parte buena de la noticia: Que SUSE sea tratada con miramientos y puesta en una división para ella sola es señal de que los compradores creen en ella y conocen su valor (Icaza ya anuncia que Mono seguirá desarrollándose como antes). Veremos que tal les va a partir de ahora.
22 de noviembre de 2010
19 de noviembre de 2010
Novedades en systemd, II
La última vez que Leenart Poettering habló sobre las últimas novedades incorporadas en el desarrollo de systemd, este blog se hizo eco. Ahora que D. Lennart ha publicado una nueva compilación de novedades incorporadas en los últimos meses lo justo es volver a hacer lo mismo.
La principal novedad, que no se menciona en el blog, es que al final systemd no fue incluído en Fedora 14 y lo será en Fedora 15. A pesar del legítimo enfado de su autor, este retraso tiene la ventaja de que podrán tener tiempo para implementar un puñado de cosas que había dejado temporalmente de lado por motivos de estabilidad. Como viene a demostrarse en los cambios implementados en los últimos dos meses:
· systemd es capaz de iniciar el sistema sin ningún script shell de por medio (exceptuando algunas configuraciones y casos atípicos). Por lo visto, esto hace ganar algunos segundos en el inicio, y además hace que el inicio sea mucho más "limpio" estéticamente (el primer número de PID disponible nada más iniciar es mucho más bajo)
· Se ha implementado un apagado del sistema totalmente en C, capaz de gestionar la matanza de procesos, desmontado de sistema de archivos, dispositivos loop y volúmenes de manera correcta. A diferencia, al parecer, de los scripts shell, que no tienen en cuenta las dependencias que ese tipo de actividades pueden tener entre ellas.
· systemd ha implementado un sistema de readahead, capaz también de defragmentar en sistemas de archivos Btrfs.
· systemd es capaz de administrar la ejecución de fsck y las quotas de usuario.
· Cada servicio, usuario y sesión tiene su propio cgroup. Este es el equivalente al "parche mágico de 200 líneas" que tantas portadas ha llenado estos días. Este sistema tiene el efecto de que si un servicio ejecuta 100 hijos ejecutando un loop cerrado, y un usuario en el escritorio ejecuta una aplicación haciendo lo mismo, los 100 procesos tendrán un 50% de CPU a repartirse entre todos, y la aplicación de escritorio el otro 50%.
· systemd provee desde su inicio el socket /dev/log desde el inicio del sistema. Si syslog aun no se está iniciando, los mensajes se envían al buffer de dmesg. Cuando syslog se inicia, recoge en su log el dmesg y por tanto también todos los mensajes enviados a /dev/log. Cuando syslog se apaga, se vuelve a redirigir /dev/log a dmesg. Se garantiza la disponibilidad de logs desde el primer al último instante.
· systemd es capaz de cargar políticas de SELinux. Lo cual, por lo visto, permite soportar inicios con y sin initrd, que al parecer es importante.
· El locale del sistema es configurado (como variables de entorno del proceso) en el PID 1 y por lo tanto heredado por todos los hijos, es decir, todos los procesos del sistema.
· systemd soporta discos encriptados, tanto como si son parte del inicio, como si son memorias USB con el contenido encriptado. Para ello han creado una infraestructura básica capaz de preguntar la clave en en X11 o en la consola (¡incluso ahí te avisan mediante wall(1)! ), según haga falta.
· Una especie de sistema de plugins (es como ha sido implementado el soporte de discos encriptados).
· Limpieza automática de directorios temporales.
· Cada vez que se inicia el sistema, systemd escribe al log cuánto ha tardado el sistema, y qué parte de esa ha sido en iniciarse el kernel y cual en iniciar los servicios.
· systemd se encarga de matar todos los procesos de una sesión de un usuario cuando se sale de ella. Era algo de lo que hasta ahora no se preocupaba absolutamente nadie y que causaba que procesos de usuario se quedaran sueltos por ahí hasta el mismo momento del reinicio.
· Se pueden enlazar archivos de servicios a /dev/null para desactivarlos por completo.
· Se pueden activar unidades (el archivo básico de configuración de systemd) si un directorio está vacío o si está presente una determinada opción en la línea de comandos del kernel.
· Se puede reiniciar el systema mediante kexec.
En fin, que systemd se está convirtiendo en toda una joya. Y todavía le queda mucho para lograr sus objetivos, entre los cuales se encuentra reemplazar a gnome-session como sistema de inicio de sesión...
La principal novedad, que no se menciona en el blog, es que al final systemd no fue incluído en Fedora 14 y lo será en Fedora 15. A pesar del legítimo enfado de su autor, este retraso tiene la ventaja de que podrán tener tiempo para implementar un puñado de cosas que había dejado temporalmente de lado por motivos de estabilidad. Como viene a demostrarse en los cambios implementados en los últimos dos meses:
· systemd es capaz de iniciar el sistema sin ningún script shell de por medio (exceptuando algunas configuraciones y casos atípicos). Por lo visto, esto hace ganar algunos segundos en el inicio, y además hace que el inicio sea mucho más "limpio" estéticamente (el primer número de PID disponible nada más iniciar es mucho más bajo)
· Se ha implementado un apagado del sistema totalmente en C, capaz de gestionar la matanza de procesos, desmontado de sistema de archivos, dispositivos loop y volúmenes de manera correcta. A diferencia, al parecer, de los scripts shell, que no tienen en cuenta las dependencias que ese tipo de actividades pueden tener entre ellas.
· systemd ha implementado un sistema de readahead, capaz también de defragmentar en sistemas de archivos Btrfs.
· systemd es capaz de administrar la ejecución de fsck y las quotas de usuario.
· Cada servicio, usuario y sesión tiene su propio cgroup. Este es el equivalente al "parche mágico de 200 líneas" que tantas portadas ha llenado estos días. Este sistema tiene el efecto de que si un servicio ejecuta 100 hijos ejecutando un loop cerrado, y un usuario en el escritorio ejecuta una aplicación haciendo lo mismo, los 100 procesos tendrán un 50% de CPU a repartirse entre todos, y la aplicación de escritorio el otro 50%.
· systemd provee desde su inicio el socket /dev/log desde el inicio del sistema. Si syslog aun no se está iniciando, los mensajes se envían al buffer de dmesg. Cuando syslog se inicia, recoge en su log el dmesg y por tanto también todos los mensajes enviados a /dev/log. Cuando syslog se apaga, se vuelve a redirigir /dev/log a dmesg. Se garantiza la disponibilidad de logs desde el primer al último instante.
· systemd es capaz de cargar políticas de SELinux. Lo cual, por lo visto, permite soportar inicios con y sin initrd, que al parecer es importante.
· El locale del sistema es configurado (como variables de entorno del proceso) en el PID 1 y por lo tanto heredado por todos los hijos, es decir, todos los procesos del sistema.
· systemd soporta discos encriptados, tanto como si son parte del inicio, como si son memorias USB con el contenido encriptado. Para ello han creado una infraestructura básica capaz de preguntar la clave en en X11 o en la consola (¡incluso ahí te avisan mediante wall(1)! ), según haga falta.
· Una especie de sistema de plugins (es como ha sido implementado el soporte de discos encriptados).
· Limpieza automática de directorios temporales.
· Cada vez que se inicia el sistema, systemd escribe al log cuánto ha tardado el sistema, y qué parte de esa ha sido en iniciarse el kernel y cual en iniciar los servicios.
· systemd se encarga de matar todos los procesos de una sesión de un usuario cuando se sale de ella. Era algo de lo que hasta ahora no se preocupaba absolutamente nadie y que causaba que procesos de usuario se quedaran sueltos por ahí hasta el mismo momento del reinicio.
· Se pueden enlazar archivos de servicios a /dev/null para desactivarlos por completo.
· Se pueden activar unidades (el archivo básico de configuración de systemd) si un directorio está vacío o si está presente una determinada opción en la línea de comandos del kernel.
· Se puede reiniciar el systema mediante kexec.
En fin, que systemd se está convirtiendo en toda una joya. Y todavía le queda mucho para lograr sus objetivos, entre los cuales se encuentra reemplazar a gnome-session como sistema de inicio de sesión...
12 de noviembre de 2010
En defensa de X.org
Entre la última entrada y los planes de Ubuntu -cuyo anuncio fue claramente planificado para fastidiar mi entrada- de usar Wayland en el futuro, se han dejado oir mil voces contra X.org. No tendría nada de malo (yo también lo hice un poco) si no fuera porque se han vuelto a repetir los mismos tópicos sobre la lentitud de X.org, sin especificar por qué razón en concreto. O, peor aun, achacándoselo a la "transparencia de red", el recurso favorito de quienes no tienen mucha idea de cómo funcionan las X.
Aunque fue diseñado como un protocolo, a X11 no hay que verlo como tal, sino más bien como una API cualquiera, expuesta por el servidor y utilizada por los clientes. En un sistema remoto, la librería libX11 abstrae las llamadas a esa API y las envía a través de red, pero en un sistema local se envían a través de un socket Unix. Que son muy rápidos, más que suficiente para implementar un sistema gráfico de alto rendimiento. ¿Adivinen que sistema de IPC utiliza Wayland para comunicar a los clientes con el servidor? Exacto, sockets Unix. De hecho, no sería difícil hacer que Wayland funcionara a través de un socket de red (aunque haría falta algún protocolo adicional para comunicar los buffers).
Es cierto que X11 es un protocolo anticuado, pero no es menos cierto se ha conservado bastante bien: No hubiera durado tanto de no ser así. Si, incluye cosas obsoletas y estúpidas como el dibujado de fuentes dentro del servidor, pero a día de hoy nadie utiliza eso (las aplicaciones dibujan las fuentes en su propia ventana mediante freetype, ignorando por completo la API original de X11). Lo mismo con las operaciones gráficas (se recurre a Cairo). Para estar al día han sido necesarias las famosas extensiones, que en realidad son un ingenioso sistema para extender el protocolo (la API) sin romper la compatibilidad. Las extensiones pueden ser bastante radicales en cuanto a los nuevos modelos que introducen, por ejemplo, la extensión XRender se presentó como "un nuevo modelo de renderizado para X", y en la práctica, aunque sea retrocompatible, efectivamente viene a ser un servidor gráfico nuevo. Igual de radicales son la extensión Composite, Damage, Randr o DRI2. Incluso hay una extensión XFixes, cuyo objetivo es resolver problemas en el core de X11. Por extender, hasta sería posible intentar introducir un hipotético X12 como una extensión de X11.
Con esto quiero decir que X.org no está especialmente anticuado: parcheado hasta la saciedad si (lo cual no equivale a "bloated": mi /usr/bin/Xorg pesa tan solo 1.6M, y las extensiones no son mucho más grande), pero no "anticuado", al menos en el sentido de obsoleto. En la práctica, lo que más ha determinado el mal rendimiento de X.org han sido los drivers. X.org tiene un montón de código, una especie de subsistema, que los drivers utilizan para implementar las peticiones gráficas del servidor. Esta arquitectura y los drivers nunca han terminado de madurar, hace relativamente poco que se empezó a invertir en drivers libres para Linux, y gran parte de ese tiempo se ha dedicado a implementar KMS/GEM (el driver de Intel incluso perdió rendimiento en la transición). Es triste decir que aun hoy, hay tookits que en algunos casos son más rápidos haciendo por software lo que XRender hace mediante aceleración por hardware (además, XRender no tiene manera de notificar si los drivers están acelerando por hardware una operación gráfica o si se está recurriendo a un "fallback" de software, por lo que los toolkits algunas veces pasan de atreverse a usar XRender)
Pero si estuviera bien implementado, si hubiera una buena arquitectura y unos buenos drivers, un escritorio X.org no tendría grandes problemas de rendimiento. Hubo un intento (Xgl, del mismo autor de Compiz) de implementar el servidor X.org sobre OpenGL (básicamente, sustituir los drivers por Mesa), tras él hubo un intento de hacerlo de otra manera (Glucose). También hay quien ha experimentado con hacer con un Cairo-drm (con resultados muy prometedores). Ninguno de ellos maduró -y no porque no fueran buenas ideas-, pero hay que tener presente que nada, absolutamente nada de esto indica un problema en X11 como protocolo/API. De hecho, de haber tenido éxito quizás Wayland no existiría.
Con todo esto quiero decir que el principal problema de los gráficos en Linux es, y seguirá siendo, los drivers. Wayland tiene razón de ser, pero es solo una minúscula pieza de todo el sistema (9.332 líneas de código, incluyendo ejemplos). Para dibujar utiliza OpenGL-ES/Mesa, que no va a ser mágicamente mejor por el hecho de utilizarla un servidor gráfico nuevo, y cuyos drivers están sufriendo o van a sufrir reescrituras masivas debido a Gallium3D. La ventaja es que Wayland puede provocar un revulsivo que de más impulso a Mesa, a los toolkits y al resto de proyectos implicados, pero por lo demás, X.org no está tan maldito como algunos quieren hacer creer.
Aunque fue diseñado como un protocolo, a X11 no hay que verlo como tal, sino más bien como una API cualquiera, expuesta por el servidor y utilizada por los clientes. En un sistema remoto, la librería libX11 abstrae las llamadas a esa API y las envía a través de red, pero en un sistema local se envían a través de un socket Unix. Que son muy rápidos, más que suficiente para implementar un sistema gráfico de alto rendimiento. ¿Adivinen que sistema de IPC utiliza Wayland para comunicar a los clientes con el servidor? Exacto, sockets Unix. De hecho, no sería difícil hacer que Wayland funcionara a través de un socket de red (aunque haría falta algún protocolo adicional para comunicar los buffers).
Es cierto que X11 es un protocolo anticuado, pero no es menos cierto se ha conservado bastante bien: No hubiera durado tanto de no ser así. Si, incluye cosas obsoletas y estúpidas como el dibujado de fuentes dentro del servidor, pero a día de hoy nadie utiliza eso (las aplicaciones dibujan las fuentes en su propia ventana mediante freetype, ignorando por completo la API original de X11). Lo mismo con las operaciones gráficas (se recurre a Cairo). Para estar al día han sido necesarias las famosas extensiones, que en realidad son un ingenioso sistema para extender el protocolo (la API) sin romper la compatibilidad. Las extensiones pueden ser bastante radicales en cuanto a los nuevos modelos que introducen, por ejemplo, la extensión XRender se presentó como "un nuevo modelo de renderizado para X", y en la práctica, aunque sea retrocompatible, efectivamente viene a ser un servidor gráfico nuevo. Igual de radicales son la extensión Composite, Damage, Randr o DRI2. Incluso hay una extensión XFixes, cuyo objetivo es resolver problemas en el core de X11. Por extender, hasta sería posible intentar introducir un hipotético X12 como una extensión de X11.
Con esto quiero decir que X.org no está especialmente anticuado: parcheado hasta la saciedad si (lo cual no equivale a "bloated": mi /usr/bin/Xorg pesa tan solo 1.6M, y las extensiones no son mucho más grande), pero no "anticuado", al menos en el sentido de obsoleto. En la práctica, lo que más ha determinado el mal rendimiento de X.org han sido los drivers. X.org tiene un montón de código, una especie de subsistema, que los drivers utilizan para implementar las peticiones gráficas del servidor. Esta arquitectura y los drivers nunca han terminado de madurar, hace relativamente poco que se empezó a invertir en drivers libres para Linux, y gran parte de ese tiempo se ha dedicado a implementar KMS/GEM (el driver de Intel incluso perdió rendimiento en la transición). Es triste decir que aun hoy, hay tookits que en algunos casos son más rápidos haciendo por software lo que XRender hace mediante aceleración por hardware (además, XRender no tiene manera de notificar si los drivers están acelerando por hardware una operación gráfica o si se está recurriendo a un "fallback" de software, por lo que los toolkits algunas veces pasan de atreverse a usar XRender)
Pero si estuviera bien implementado, si hubiera una buena arquitectura y unos buenos drivers, un escritorio X.org no tendría grandes problemas de rendimiento. Hubo un intento (Xgl, del mismo autor de Compiz) de implementar el servidor X.org sobre OpenGL (básicamente, sustituir los drivers por Mesa), tras él hubo un intento de hacerlo de otra manera (Glucose). También hay quien ha experimentado con hacer con un Cairo-drm (con resultados muy prometedores). Ninguno de ellos maduró -y no porque no fueran buenas ideas-, pero hay que tener presente que nada, absolutamente nada de esto indica un problema en X11 como protocolo/API. De hecho, de haber tenido éxito quizás Wayland no existiría.
Con todo esto quiero decir que el principal problema de los gráficos en Linux es, y seguirá siendo, los drivers. Wayland tiene razón de ser, pero es solo una minúscula pieza de todo el sistema (9.332 líneas de código, incluyendo ejemplos). Para dibujar utiliza OpenGL-ES/Mesa, que no va a ser mágicamente mejor por el hecho de utilizarla un servidor gráfico nuevo, y cuyos drivers están sufriendo o van a sufrir reescrituras masivas debido a Gallium3D. La ventaja es que Wayland puede provocar un revulsivo que de más impulso a Mesa, a los toolkits y al resto de proyectos implicados, pero por lo demás, X.org no está tan maldito como algunos quieren hacer creer.
10 de noviembre de 2010
Red Hat 6
Red Hat acaba de anunciar la publicación de Red Hat 6. No dejaría de ser una noticia más sobre distros si no fuera porque Red Hat es la punta de lanza de la implantación comercial del software libre y el mayor contribuidor de código de varios proyectos críticos.
Técnicamente, Red Hat 6 no ofrece ninguna novedad para quienes seguimos la evolución de la distros de Linux, pero para quienes usan Red Hat 5 -publicada en 2005, con kernel Linux 2.6.18- supone enfrentarse de repente a las novedades de los últimos 3 años (¡gestor de procesos CFS!), y también supone que otros SOs comerciales pasarán a tener que compararse con esta versión en benchmarks.
Quien busque información, aquí hay material promocional de todo tipo.
Técnicamente, Red Hat 6 no ofrece ninguna novedad para quienes seguimos la evolución de la distros de Linux, pero para quienes usan Red Hat 5 -publicada en 2005, con kernel Linux 2.6.18- supone enfrentarse de repente a las novedades de los últimos 3 años (¡gestor de procesos CFS!), y también supone que otros SOs comerciales pasarán a tener que compararse con esta versión en benchmarks.
Quien busque información, aquí hay material promocional de todo tipo.
4 de noviembre de 2010
El estado de Wayland, aspirante a reemplazar X.org
La última vez que se mencionó en este blog al servidor gráfico Wayland, fue con la descripción de "revolucionario y raquítico a la vez". No era una apreciación del todo errónea; tengo la manía de clonar los repositorios de proyectos interesantes para ojear de vez en cuando su actividad, y como proyecto con la no precisamente leve vocación de ser alternativa a X.org, la evolución de Wayland no era muy esperanzadora (13 commits en 8 meses, todos menos dos de su creador). Me equivocaba, fue escribir esa entrada y aumentar el número de commits y buenas noticias.
Aunque la actividad no se haya disparado por las nubes, en los últimos meses se ha visto que Wayland progresa más rápido de lo esperado. Para empezar, MeeGo tiene interés en él a largo plazo para usarlo como servidor gráfico en dispositivos móviles-táctiles (un detalle interesante es que Kristian Høgsberg, el autor, creó Wayland en la época en que trabajaba en Red Hat, pero no como algo de la compañía, sino durante su tiempo libre, mientras que ahora trabaja en Intel, en parte en Wayland). Pero lo más determinante para el futuro de Wayland no es algo que esté ocurriendo en su código. Lo más difícil para un proyecto así es conseguir apoyo de los toolkits y proyectos relacionados con el escritorio. Yo creía que se tardarían años en ver progresos en este sentido, pero ha resultado ser al contrario: Ya se están portando QT, GTK y Clutter (capturas). Claro que, teniendo en cuenta el enormemente intrincado mundo del vídeo es difícil imaginar una transición fácil y breve. Pero incluso para eso hay buenas noticias, Wayland puede usarse para mostrar servidores X completamente funcionales, lo cual permitiría compatibilidad al estilo de XQuartz (X11 sobre OS X).
Probablemente, parte de la aparente sencillez en portar QT y GTK se debe a su diseño (eso, y que en el mundo gráfico de Linux hay cada vez más inversión). Wayland es muy simple, se limita compartir buffers de memoria con las aplicaciones clientes, las cuales notifican a Wayland de los cambios, quien a su vez envía la imagen final al hardware vía OpenGL ES. Esa función de coordinador de buffers, mas el envio de eventos desde dispositivos de entrada a las ventanas, son prácticamente sus únicas funciones, por eso es tan pequeño, simple e ideal para dispositivos táctiles. El renderizado de las ventanas en si, en el que X.org, con su anticuado diseño, trata de tomar parte (la propia API nativa de dibujado, las obsoletas fuentes en el servidor, extensiones como Composite para hacer posible software como Compiz), se deja completamente en manos del cliente.
Afortunadamente, todos los toolkits modernos están diseñados para funcionar de acorde con lo que Wayland espera, por lo cual portarlos significa (a los ojos de este humilde servidor no experto en gráficos) implementar el código que envie los contenidos a Wayland, e interactuar con él cuando hay que redibujar algo. El divorcio con X.org es tal, que el concepto de "gráficos a través de la red" del protocolo X11 en realidad no queda excluido ni obsoleto, pasa a ser asunto de las aplicaciones clientes, como algo opcional.
Todo esto suena muy bien para Wayland, y hay que tener en cuenta que este servidor no es por si mismo una revolución, más bien es el punto final a todas las novedades de los últimos años en APIs de acceso a hardware (KMS) y las novedades y capacidades de los toolkits y el progreso en Mesa: Wayland es el broche final que une ambos mundos de manera correcta, prescindiendo del obsoleto X.org. Pero tampoco hay que darlo todo por hecho: Imaginen que a alguien se le ocurre añadir una extensión a X.org implementando algo similar. En un mundo tan atacado por el relativismo moral, no hay que descartar semejantes desvaríos.
(PD: Ubuntu ha anunciado, precisamente justo después de publicar esta entrada, que pretende usar Wayland en el futuro)
Aunque la actividad no se haya disparado por las nubes, en los últimos meses se ha visto que Wayland progresa más rápido de lo esperado. Para empezar, MeeGo tiene interés en él a largo plazo para usarlo como servidor gráfico en dispositivos móviles-táctiles (un detalle interesante es que Kristian Høgsberg, el autor, creó Wayland en la época en que trabajaba en Red Hat, pero no como algo de la compañía, sino durante su tiempo libre, mientras que ahora trabaja en Intel, en parte en Wayland). Pero lo más determinante para el futuro de Wayland no es algo que esté ocurriendo en su código. Lo más difícil para un proyecto así es conseguir apoyo de los toolkits y proyectos relacionados con el escritorio. Yo creía que se tardarían años en ver progresos en este sentido, pero ha resultado ser al contrario: Ya se están portando QT, GTK y Clutter (capturas). Claro que, teniendo en cuenta el enormemente intrincado mundo del vídeo es difícil imaginar una transición fácil y breve. Pero incluso para eso hay buenas noticias, Wayland puede usarse para mostrar servidores X completamente funcionales, lo cual permitiría compatibilidad al estilo de XQuartz (X11 sobre OS X).
Probablemente, parte de la aparente sencillez en portar QT y GTK se debe a su diseño (eso, y que en el mundo gráfico de Linux hay cada vez más inversión). Wayland es muy simple, se limita compartir buffers de memoria con las aplicaciones clientes, las cuales notifican a Wayland de los cambios, quien a su vez envía la imagen final al hardware vía OpenGL ES. Esa función de coordinador de buffers, mas el envio de eventos desde dispositivos de entrada a las ventanas, son prácticamente sus únicas funciones, por eso es tan pequeño, simple e ideal para dispositivos táctiles. El renderizado de las ventanas en si, en el que X.org, con su anticuado diseño, trata de tomar parte (la propia API nativa de dibujado, las obsoletas fuentes en el servidor, extensiones como Composite para hacer posible software como Compiz), se deja completamente en manos del cliente.
Afortunadamente, todos los toolkits modernos están diseñados para funcionar de acorde con lo que Wayland espera, por lo cual portarlos significa (a los ojos de este humilde servidor no experto en gráficos) implementar el código que envie los contenidos a Wayland, e interactuar con él cuando hay que redibujar algo. El divorcio con X.org es tal, que el concepto de "gráficos a través de la red" del protocolo X11 en realidad no queda excluido ni obsoleto, pasa a ser asunto de las aplicaciones clientes, como algo opcional.
Todo esto suena muy bien para Wayland, y hay que tener en cuenta que este servidor no es por si mismo una revolución, más bien es el punto final a todas las novedades de los últimos años en APIs de acceso a hardware (KMS) y las novedades y capacidades de los toolkits y el progreso en Mesa: Wayland es el broche final que une ambos mundos de manera correcta, prescindiendo del obsoleto X.org. Pero tampoco hay que darlo todo por hecho: Imaginen que a alguien se le ocurre añadir una extensión a X.org implementando algo similar. En un mundo tan atacado por el relativismo moral, no hay que descartar semejantes desvaríos.
(PD: Ubuntu ha anunciado, precisamente justo después de publicar esta entrada, que pretende usar Wayland en el futuro)
Suscribirse a:
Entradas (Atom)