Click aqui para ver el video.

Recientemente el equipo de Elive lanzó una versión especial de su distribución basada en Debian con los efectos que habías soñado de Compiz en el gestor de ventanas Enlightenment 0.17 (DR17 ó E17). Este liveCD experimental ha sido desarrollado para correr en maquinas con pocos recursos y no exige una tarjeta gráfica especial o aceleración 3D para funcionar.

Esta versión 1.9 usa Ecomorph, un nuevo “Composite Manager” basado en Compiz para el gestor de ventanas E17 que durante un tiempo fue el gestor de ventanas de Gnome. Puedes bootearlo desde un CD-ROM o memoria USB y funciona bien en el MacBook y la netbook EeePC.

Por su parte los chicos de Softpedia hicieron un prueba de Elive E17 Compiz en un viejo PC con 512 MB de RAM y una Nvidia GeForce FX 5200 con buenos resultados jugando un poco con con los efectos desde el CompizConfig.

Es la primera distribución en utilizar E17 + Compiz que sin duda con el tiempo se convertirá en una versión estable y eficiente.

Link: First Look: Elive E17 Compiz (Softpedia News)

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)

Compiz fue presentado a principios del 2006 como un gestor de ventanas de composición para el sistema X Window, que es capaz de aprovechar la aceleración OpenGL.

Su éxito fue casi inmediato gracias a las maravillas que lograba hacer con las ventanas en el escritorio de Linux, siendo catalogado como uno de los avances más importantes en el desarrollo de la interfaz de este Sistema Operativo.

Pero a poco andar surgieron divisiones al interior del grupo detrás del proyecto Compiz, por lo que surgió una nueva rama denominada Beryl.

Luego de un tiempo de trabajar en forma separada ambas ramas decidieron que era tiempo que se fusionaran, lo que sucedió en Marzo del 2007 bajo el nombre de Compiz Fusion.

Claro que este 24 de Diciembre se anunció el lanzamiento del proyecto Compiz++, una nueva rama surgida a partir de Compiz Fusion que mantiene separadas las capas OpenGL y de Composición, con lo que podríamos utilizar este gestor incluso si nuestra tarjeta gráfica y sus controladores no la soporten.

Una de las desventajas que tendría Compiz++ es que no posee soporte multimonitor, por lo que se tendría que ejecutar un Compiz++ en cada monitor según sea el caso.

Para programar Compiz++ se utilizó C++, lo que se traduciría en diversas ventajas para los desarrolladores detrás del proyecto.

Link: Compiz feature branch compiz++ (vía Phoronix)