Mark Shuttleworth y Canonical han elegido al ocelote como parte del nombre de la próxima versión de Ubuntu que remplazará a Natty Narwhal. Se trata de un felino que habita en Centro y Sudamérica, tiene la apariencia de un gato doméstico pero con un pelaje similar a un leopardo o jaguar.

Como ya es costumbre, el nombre se elige con una combinación de dos palabras que sigan la secuencia de un orden alfabético otorgado a una versión estable. En este se eligió “Oneiric Ocelot” que significa ocelote soñador.

La versión 11.10 de Ubuntu que se lanzará en noviembre de 2011 usará el escritorio Unity en lugar de Gnome Shell y un sistema de ventanas basado en Wayland en lugar de X Window System. Sin mencionar que utilizará varias aplicaciones de forma predeterminada, incluyendo Banshee para reproducir música.

“El escritorio se ha unido muy bien, y en la próxima versión vamos a completar el ciclo para hacerlo más accesible a todos los usuarios, con una experiencia en 2D basado en OpenGL para complementar Unity y poder manejar el hardware. La introducción de Qt significa que estaremos dando a los desarrolladores más opciones de cómo se puede crear interfaces que son funcionales y estéticamente atractivas”, dijo Mark Shuttleworth.

Shuttleworth también señaló que las versión después de 11.10 a 12.04 serán LTS (Long Term Support), que se liberan cada dos años y reciben soporte de tres años en sistemas de escritorio y cinco en servidores.

La última versión LTS de Ubuntu fue 10.04 (Lucid Lynx), publicado el 29 de abril de 2010, mientras que la última versión normal será Oneiric Ocelot.

Link: Beyond Natty: The next version of Ubuntu Linux (ZDnet)

Kristian Høgsberg / Wayland / Linux Foundation

A principios de año les contamos sobre un nuevo sistema gráfico para Linux llamado Wayland. La idea es crear un nuevo sistema gráfico más pequeño, sencillo y eficiente que X, el sistema gráfico actual. Si bien Wayland no ha avanzado tan rápido por si mismo, si ha provocado cambios que afectan en forma positiva a todos los sistemas gráficos que pudieran existir.

X.org, la implementación de X que se usa en Linux, cada vez se reduce más en tamaño y complejidad.  Atrás quedaron los días en donde podíamos hablar de una gran cantidad de código en donde podíamos encontrar desde protocolos de comunicaciones hasta sistemas de render de fonts y control del bus PCI/AGP. Hoy en día, X.org se ha ido simplificando, delegando algunas tareas al kernel y otras a bibliotecas o aplicaciones que funcionan en forma independiente.  Gracias a estos cambios, se ha logrado mejorar enormemente la arquitectura de aceleración, el tipo de aplicaciones que se pueden crear y la convivencia con otras aplicaciones que también necesitan acceder al hardware de video.

Esto ha producido que el código que usa X.org y que se encarga de varios aspectos complejos, ahora esté centralizado y compartido, lo que permite ser reutilizado en Wayland (u otro sistema gráfico).  De esta forma el desarrollo de Wayland se simplifica ya que no es necesario construir y probar código desde cero.

Si se revisa el código de Wayland, se puede ver que no hay mucho avance, pero esto lleva a engaños ya que su principal desarrollador ha estado trabajando en la funcionalidad que ahora es compartida con X.org.  Esto quiere decir que en vez de trabajar en mejoras que afectan a Wayland, se está trabajando en mejoras que afectan a todos los sistemas gráficos, incluyendo a X.org y por supuesto Wayland.

Como parte de este trabajo se está mejorando la forma en que se produce el dibujado de las aplicaciones y el dibujado final en la pantalla visible, con el objetivo de eliminar completamente el dibujado parcial (tearing) que ocurre cuando no hay una sincronización entre lo que se está dibujando y cómo esto se lleva a la pantalla visible.

Gracias a Wayland, en el kernel se han creado los mecanismos necesarios para que las aplicaciones y el sistema gráfico puedan notificar y ser notificados cuando el área de dibujo está lista para ser desplegada y cuando se ha desplegado finalmente.  Esta nueva funcionalidad está planificada para ser integrada en el kernel 2.6.33, por lo que es muy probable que el famoso tearing sea cosa del pasado dentro de los próximos meses.

Presentación de Wayland en Linux Plumbers Conference

Link: Wayland – a new display server for Linux (Linux Foundation)

El héroe se llama Chia-I Wu, y tiene bastante experiencia en Mesa gracias a su trabajo para implementar OpenGL ES, que es la especificación de OpenGL dirigida a dispositivos móviles.

En su estado actual, Mesa para Android  es capaz de acelerar el compositor de Android, equivalente funcional al famoso Compiz de Linux, y también ya permite que las aplicaciones actuales para Android puedan correr con aceleración 3D por hardware sin que se les tenga que hacer ningún cambio.

Básicamente el trabajo de Chia-I ha sido mejorar el soporte de OpenGL agregando nuevas extensiones y escribiendo un nuevo driver EGL llamado egl_android.  EGL es básicamente el driver de bajo nivel que se encarga de conectar Mesa con el hardware y la plataforma subyacente.

El trabajo de Chia-I incluso va más allá de Android, ya que ha tenido que hacer modificaciones para que Mesa funcione correctamente en sistemas que no usan X.org, por lo que sus cambios también beneficiarán al sistema gráfico Wayland.

Link: Mesa comes to Android-bases x86 netbooks (Phoronix)

Hace poco, muchos sitios especializados hicieron eco de la noticia sobre el desarrollo de un nuevo sistema X para Linux llamado Wayland, y como ya había sucedido en otras ocasiones, se escucharon muchas voces acerca de lo innecesariamente grande y complejo del sistema existente (X.org).  La noticia era bienvenida, pero no había mucha información acerca de qué se trataba exactamente.

Un poco de historia

X Window System (o simplemente X) es el componente del sistema que se encarga fundamentalmente de dos tareas : desplegar las aplicaciones en pantalla y recibir los eventos del usuario (teclado, mouse, etc).  X no es una aplicación en particular, sino que es una específicación que puede tener múltiples implementaciones, su origen data de mediados de los años 80 y se creó inicialmente con la idea de tener una interfaz gráfica para los sistemas Unix, sin embargo su diseño es independiente de la plataforma y gracias a eso es que hoy tenemos implementaciones de X para Windows, Linux, OSX, Unix’es, etc.

Cuando se diseñó X, el hardware era bastante diferente a lo que usamos hoy en día.  En esos años los chips de aceleración de video no era algo que estaba al alcance de cualquier mortal y el uso de servidores compartidos era algo común, la computación personal era un sueño de pocos.  Para usar los sistemas Unix se acostumbraba a conectar a muchos usuarios mediante terminales de texto y X agregaba capacidades gráficas a esta interacción.  Una de las características naturales de X es poder desplegar en un sistema las aplicaciones que se están ejecutando en otro, actuando en forma remota.

Hoy en día no es necesario compartir los computadores y cada usuario puede tener uno completamente dedicado a él, tanto las aplicaciones como el servidor X corren en la misma máquina en forma local, el uso remoto es opcional.  Por otra parte el hardware de video ya no sólo despliega un conjunto de pixeles, sino que cuenta con procesadores dedicados a generar imágenes en espacios 2D y 3D.

En el caso de Linux la implementación de X más utilizada es X.org, ésta surgió cuando un grupo de desarrolladores de XFree86 se separó del proyecto porque consideraban que existían muchas restricciones para hacer fuertes cambios en X. Esto ocurió en el año 2004 cuando un cambio a un licenciamiento más restrictivo fue la gota que rebalsó el vaso.

Los cambios que se han realizado en X han sido considerables.  Por muchos años se puede decir que los cambios se limitaban a agregar drivers, pero el resto de las ideas originales se mantenían a pesar de los avances en el hardware gráfico, especialmente a finales de los 90.  Cuando surgió X.org, héroes como Keith Packard y Jim Gettys pudieron llevar adelante los cambios que se necesitaban para convertir a X en un sistema moderno.

Keith Packard y su pandilla

Uno de los cambios fuertes fue cambiar algunos aspectos del despliegue para que los pudiera realizar la aplicación y no el servidor X, es el caso del sistema de fonts.  Con eso lograron crear interfaces WYSIWYG, suavizado de fuentes, mejoras sustanciales en el rendimiento y capacidad de usar la aceleracón por hardware a la hora de desplegar texto.  La base de este cambio (xrender) también permitió mejorar la forma en que se manejan los dibujos vectoriales, dando capacidad de usar alpha blending, antialias y todo acelerado por hardware.

Otro de los cambios fuertes es el modelo de composición.  En pocas palabras se trata de una nueva forma de desplegar las ventanas para que no exista el redibujado y una aplicacion independiente se encarga de presentar todas las ventanas en la pantalla, se conoce como Composite Manager y su implementación más conocida es Compiz (+derivados).  Gracias al nuevo modelo de composición se pueden aprovechar las capacidades 3D de los procesadores modernos, que son increiblemente poderosos para las necesidades de un sistema de escritorio.

Cambios recientes en X

Recientemente se agregaron un par de cambios que permitieron mejorar dos aspectos que siempre fueron criticados en X.  Uno de ellos es que ahora X ya no se encarga de configurar el modo de video, sino que lo hace en el kernel, esta funcionalidad se le llamó ingeniosamente Kernel Mode Setting (KMS).  Los beneficios directos de este cambio son al menos dos : ya no es necesario que X se ejecute con privilegios de root, lo que siempre es un riesgo de seguridad, y el otro es que otras aplicaciones pueden solicitar un cambio en el modo de video, esto significa por ejemplo que si hay dos X server corriendo al mismo tiempo antes se tenia que “apagar y encender”  el X server para cambiar de uno a otro, en cambio ahora el kernel podría simplemente cambiar el contexto entre uno y otro, sin reiniciar el video ni causar esos molestos pestañazos.  Otra ventaja es que otras aplicaciones de despliegue podrian pedir al kernel el control del video sin pasar por X, por ejemplo un screensaver o una aplicación dedicada a la reproducción de videos en pantalla completa.

El otro cambio es relativo al manejo de memoria de las aplicaciones que usan el servidor X.  Se implementó un sistema centralizado en donde las aplicaciones pueden incluso compartir objetos gráficos.  Este sistema se conoce como Grapics Excecution Manager (GEM). ¿En donde interesa? justamente un Composite Manager es uno de los que necesita este tipo de funcionalidad.  En pruebas realizadas con hardware antiguo (i915) se produjo un incremento de más de un 50% en el performance al probar aplicaciones 3D.

Wayland entra a jugar

Con todos estos cambios, X.org se ha convertido en un sistema que cada dia se aleja más de lo que se diseño originalmente en los 80.  El problema es que por motivos de compatibilidad, y para poder ser un X con todas las de la ley, tiene que mantener una gran cantidad de funcionalidad que ya no es relevante.  Se sabe que se han eliminado algunas características obsoletas y según dicen, nadie se ha quejado, pero no se puede hacer una limpieza total porque se desconoce cuantos usuarios podrían salir afectados.

Kristian Høgsberg, un empleado de RedHat, ha comenzado a trabajar en un proyecto por su cuenta para crear un nuevo sistema gráfico llamado Wayland. Kristian ha desarrollado tanto en X.org como en el kernel así que conoce bien lo bueno y lo malo de cada uno de ellos.

Lo primero que se debe decir de Wayland es que no se trata de un X server como erróneamente lo titularon varios sitios.  Wayland busca aprovechar todas las características que ya no son parte de X para crear un nuevo sistema de despliegue con un diseño actual, este aspecto es bastante importante porque una de las limitaciones que existían hasta hace poco era que para hacer un nuevo sistema de despliegue (X u otro) se necesitaba implementar una gran cantidad de funcionalidad.

Wayland en vez de partir de cero, tiene como base todo lo que se eliminó de X para integrarse al kernel y bibliotecas externas.  No es una duplicación de trabajo, es una comienzo limpio sobre una base sólida.

Como Wayland no es un X, las aplicaciones existentes no pueden funcionar directamente en él, pero es algo que se puede solucionar ya que al usar toolkits como QT y GTK que son independientes de X, en teoría sería cosa de que hicieran los ports respectivos a Wayland.   Otra alternativa es que se ejecute un servidor X rootless sobre Wayland, y así las aplicaciones no se darían cuenta que es otro quien dibuja sobre la pantalla, es el mismo sistema que utiliza OSX en la actualidad para desplegar apicaciones que usen X.

En diciembre del 2008, Kristian ya tenía andando X.org sobre Wayland.

Wayland propone que el Composite Manager sea independiente del sistema de despliegue como es en X, pero que sea parte del mismo proceso.  Si se mezcla esta idea con la anterior de usar un X sobre Wayland, sería posible hacer transiciones de usuarios como las que hace OSX mediente este Composite Manager integrado.

Hasta ahora Wayland es un prototipo experimental muy pequeño, no tiene fines muy ambiciosos y no hay seguridad sobre su futuro, pero sin embargo puede ser un cambio radical en el área de interfaz gráfica.  Linux en un comienzo estaba en las mismas condiciones y ya sabemos lo que pasó.

Los valientes que quieran contarle a sus nietos que probaron este sistema cuando comenzó, pueden descargar, compilar y probarlo desde su repositorio oficial.

Links:

- Grupo de discusión sobre Wayland (groups.google.com)
- Preguntas frecuentes sobre Wayland (groups.google.com)
- Blog de Kristian Høgsberg (hoegsberg.blogspot.com)
- New Wayland X server looks to how a modern desktop works (Heise Online)