Probando Gnome 3

Quedan un par de semanas para que se publique la versión estable de GNOME 3.0, y un servidor ha decidido dárselas de crítico antes de que todo el mundo haga lo mismo. Quede claro, para quienes no lo sepan, que quien esto escribe es usuario y defensor a ultranza de KDE; a pesar de ello he decidido ser constructivo y no hacer correr la sangre porque, en pleno 2011, Gnome siga teniendo un selector de archivos que sólo puede mostrar una vista con tres columnas verticales, con miniaturas ridículas que fuerzan a tener que ir clickando imagen a imagen y mirando en el previsualizador lateral. Si, podrían crear un selector de archivos que reutilice funcionalidad del navegador de archivos para mostrar una vista con iconos grandes, como hace todo el mundo, pero ya han dejado claro que ellos prefieren usar GTK a pelo y no reaprovechar el magnífico código de otras partes de Gnome. No merece la pena insistir en esto.

Gnome Shell

De cara al usuario Gnome 3 tienen de novedoso lo mismo que KDE 4, es decir, reescritura del shell del escritorio y poco más. En el caso que nos ocupa el shell nuevo es el famoso Gnome Shell, una mezcla de lanzador de aplicaciones, gestor de aplicaciones abiertas, gestor de escritorios virtuales, panel, systray e IM. Se basa en GTK/Glib, y se combina con el gestor de ventanas mutter para hacer todo tipo de animaciones mediante una librería de animaciónes OpenGL llamada clutter. Está escrito en Javascript, se apoya en unos bindings Javascript de Glib, y para ejecutar el código utiliza el motor Javascript de Firefox, "tracemonkey". Esto de que utilizen Javascript no es que sea malo a estas alturas -Tracemonkey es por lo general bastante más rápido que CPython, por ejemplo-, pero es notable porque es un paso más en la tradición gnomera de intentar meter en el código base del escritorio todos los lenguajes de programación creados por la humanidad. En el escritorio que me suministra Fedora GTK y los programas con base de código antigua están en C; Gnome Shell en Javascript; el gestor de fotografías, el programa de hacer efectos graciosos sobre imágenes de webcam y la herramienta de copia de seguridad en un dialecto de C# (Vala); el programa "gnome journal" en python, y el programa de notas post-it en C++ (portado de C#).

El panel superior

Nada más iniciar la sesión en Gnome 3, uno se encuentra con un fondo de escritorio negro, completamente vacío, y un panel superior, tal y como se puede ver en la captura. ¿Tal vez cree usted que esta es, como en Ubuntu, una invitación a personalizar su escritorio con iconos, paneles y applets adicionales? Si es así, está equivocado por completo. Primera lección de Gnome 3: Olvídese de personalizar. Quitando el fondo de escritorio, nada de lo que se ve en la captura puede ser modificado. ¿Iconos en el escritorio? No se pueden poner, de hecho el escritorio no tiene ningún menu contextual. En el panel superior es lo mismo, no se pueden añadir, mover o eliminar iconos, ni tan siquiera el de accesibilidad. Cualquier clik en una zona vacía del panel cae en saco roto, y si el cliqueo es sobre un icono, el menu contextual que le aparecerá es el mismo con independencia del botón del ratón. Sólo el escritorio puede personalizarse (a través de un menú que hay en el nombre de usuario). Tengo entendido que desde dconf -sucesor de gconf- pueden configurarse algunas cosas más -algo que no he podido comprobar al ser imposible arrancar el dconf-editor-, pero el mensaje está claro: nada de configuraciones.

Las Actividades

¿Cómo se interacciona con el escritorio? Haciendo clik en la palabra "actividades" en la parte superior izquierda, aunque en realidad basta con llevar el puntero del ratón a esa esquina. Una animación nos conduce a la pantalla de la captura, la cual consiste en un dock vertical y un Exposé de las aplicaciones abiertas en ese escritorio; basta hacer click en una para regresar al escritorio con esa aplicación al frente. Más a la derecha hay otro panel vertical, que aumenta de tamaño si se acerca el ratón, y que contiene miniaturas de los escritorios virtuales. Al hacer clik en ellos se sustituye el Exposé actual por el de ese escritorio. Para crear un escritorio nuevo basta arrastrar un icono del dock a la zona, o una miniatura de una aplicación abierta. El dock, por su parte, muestra todas las aplicaciones abiertas, las cuales se pueden marcar como "favoritas", al estilo Windows 7

En la parte superior se pueden ver dos pestañas, "ventanas" y "aplicaciones". Al pulsar "aplicaciones", el área Exposé y el de los escritorios virtuales se sustituye por lo que puede verse en la captura. Haciendo clik en un icono se abre la aplicación, si en cambio se intenta arrastrar la zona de iconos desaparecerá y se volverá a la vista de "ventanas", para poder soltarle en un escritorio, o en el dock. Además de todo esto, en ambas vistas se puede encontrar un buscador al estilo Spothlight que busca aplicaciones en cuanto se introduce cualquier carácter. También muestra, en la parte inferior de los resultados de búsqueda, botones para buscar en Wikipedia o Google la palabra introducida.

Cambiando entre aplicaciones

Con esto pueden hacerse una idea de este escritorio, y de alguna de las noticias que se han escuchado en los últimos meses. La eliminación del botón de minimizar, por ejemplo, se hizo porque no existe en el escritorio ninguna lista de aplicaciones a la que se puedan enviar ventanas minimizadas. Esto tiene un pequeño efecto negativo: Dado que no hay ningún panel con la lista aplicaciones presentes en el escritorio, se hace imposible saber a primera vista cuántas aplicaciones hay. Por ejemplo, ¿cuántas aplicaciones hay en la imagen de la izquierda? Visualmente solo dos, pero en realidad hay siete, casi todas tapadas por el navegador. Para quienes no usamos muchos escritorios virtuales y solemos tener el navegador maximizado es anti intuitivo tener que ir a la zona de gestión de actividades o pulsar alt+tab (eso no lo han quitado). Y es especialmente absurdo que Gnome Shell fuerce a ello, ya que en el panel superior hay mucho sitio vacío y hay varios iconos que se podrían quitar para albergar una lista de aplicaciones tradicional; si pudiera configurarlo lo solucionaría, pero Gnome Shell y su política anticonfiguración lo hacen imposible.

¿Dos systrays?

Lo único que me falta por mencionar es el systray. Ya hemos visto que en la barra superior hay varios iconos, pero ¿dónde se ubican los iconos de systray de las aplicaciones? Pues no ahí, si no en un panel transparente auto ocultable en la parte inferior de la pantalla, y que aparece al llevar el ratón a la esquina opuesta del botón "actividades". En este panel oculto también se ubican los popups del sistema, así como los de los contactos de IM (yo no lo he probado, pero véanlo funcionando aquí). Mi opinión frente a este sistema es que es confuso. Al ser este panel auto ocultable, el usuario puede pasar por alto los iconos durante demasiado tiempo. Por ejemplo, el icono de Akregator me indica el número de noticias que tengo por leer, pero al no tenerlo siempre a la vista pierdo esa información, tengo que molestarme en mover ratón a esa zona - a pesar de que en el panel superior hay sitio de sobra para más iconos. De nuevo, si esto fuera configurable no sería problema, pero en Gnome Shell no cabe esa opción, se ha dividido el systray en dos sin demasiadas razones para ello.

Conclusiones

En mi caso, Gnome Shell simplemente se entromete en mi manera de hacer las cosas, y no me aporta nada nuevo. Lo de mostrar una vista Exposé de las ventanas al mover el ratón a la esquina superior izquierda, por ejemplo, es algo que ya tengo en KDE desde hace mucho. El diseño general y la eliminación de la configurabilidad parece haberse hecho con la mentalidad "sabemos lo que es mejor para ti", han conseguido que OS X parezca un sistema para geeks que quieren cacharrear con las tripas del ordenador.

Pero no, no saben lo que es mejor para mi: tal es la aleatoriedad con la que se han tomado algunas decisiones que dan escalofríos. Por ejemplo, la decisión de eliminar el botón de minimizar. Cabría esperar que semejante cambio hubiera sido debatido en profundidad, y que una vez tomada la decisión estarían seguros de haber hecho lo correcto. Sin embargo, he aquí que el desarrollador que lo hizo empezó a dudar de la decisión...¡mientras escribía un email! Si esa es la seriedad con la que se han eliminado tantas y tantas opciones, me temo que con Gnome 3 ocurrirá como en Gnome 2. En aquella versión se eliminaron demasiadas opciones, y se vieron forzados a añadirlas poco a poco en versiones posteriores.

Sin embargo, tampoco me imagino una debacle. La simplificación de Gnome Shell es excesiva, pero es manejable: se aprende a convivir fácilmente con las molestias. Aunque a mucha gente no le gustará, cualquier persona puede acostumbrarse a operar el escritorio con él, no se convertirá en una barrera infranqueable. Hay otros aspectos positivos, como las animaciones visuales, que son simples, discretas, y muy, muy fluidas, incluso en mi patata de gráfica integrada Intel. Por último, destacar su gran estabilidad: A diferencia de Plasma en KDE 4.0, Gnome Shell se merece la etiqueta ".0". Es un trabajo terminado, muy estable, preparado para usarse en las grandes distros, que nadie espere a futuras versiones para probarlo.

Las novedades de Linux 2.6.38

(Actualización: He añadido otra característica y eliminado otra que al final se eliminó) Ya se ha anunciado la publicación de la versión 2.6.38 de Linux. Las novedades de esta versión son: agrupación automática de procesos (el "parche que hace milagros"), mejoras de escalabilidad en el VFS, compresión LZO y snapshots de sólo lectura en Btrfs, el protocolo de redes Mesh B.A.T.M.A.N. (que ayuda a proveer de conectividad de red en presencia de desastres naturales, conflictos militares o censura de Internet), soporte gráfico para AMD Fusion, páginas grandes transparentes en lugar de a través de hugetblfs, y muchos otros cambios menores y drivers nuevos. Lista completa en inglés en este enlace.

· Agrupación automática de procesos: La característica más impactante de esta versión es el "parche que hace milagros", que es un parche que hace cambios sustanciales al modo en que se asigna tiempo de CPU a cada proceso. Con esta característica el sistema agrupará todos los procesos que tengan el mismo ID de sesión como una sola entidad. Ejemplo: Imaginemos 6 procesos que están consumiendo CPU continuamente, los 4 primeros con un mismo ID de sesión y los otros dos utilizando otras dos sesiones diferentes.

Sin agrupación automática: [proc. 1 | proc. 2 | proc. 3 | proc. 4 | proc. 5 | proc. 6] 
Con agrupación automática: [proc. 1, 2, 3, 4  |     proc. 5       |     proc. 6      ]

El ID de sesión es una propiedad de los procesos en los sistemas Unix (poco conocida - puede verse con comandos como ps -eo session,pid,cmd). Los hijos lo heredan del padre tras fork(), y pueden empezar una nueva sesión utilizando setsid(3). Bash crea una sesión nueva cada vez que se inicia, lo cual significa que con esta característica se puede ejecutar "make -j20" dentro de una shell en un escritorio, sin que se note mientras se navega la web. Esta característica está implementada sobre la característica "group scheduling" (incluida en 2.6.24). Se puede desactivar en /proc/sys/kernel/sched_autogroup_enabled

· Escalabilidad del VFS: escalando el caché de directorios: Existen actualmente esfuerzos para hacer que la capa VFS ("Virtual File System", el código que va entre las llamadas al sistema y el sistema de archivo) sea más escalable. En versiones anteriores ya se incluyeron algunos cambios preliminares, en esta versión tanto el dcache ("caché de directorios") y el mecanismo entero de búsqueda de rutas se ha reescrito para ser más escalable (detalles en este artículo de LWN).

Estos cambios hacen al VFS más escalable en cargas multihilo , pero lo más interesante (y es lo que le gusta a Linus Torvalds) es que también hacen las cargas con un sólo proceso más rápidas (debido a la eliminación de operaciones de CPU atómicas): En su $HOME, "find . -size" es un 35% más rápido. Ejecutar un "git diff" en un repositorio de kernel cacheado es un 20% más rápido (64 git diff en paralelo en 64 repositorios de kernel son un 26x más rápido). Todo lo que llame a stat(3) con mucha frecuencia es más rápido.

· Compresión LZO y snapshots de sólo lectura en Btrfs: Btrfs añade a su sistema de compresión transparente soporte para el algoritmo de compresión LZO, como alternativa a zlib. Aquí hay una pequeña comparación de rendimiento de ambos.

También se añade soporte para marcar un snapshot como de sólo lectura. Finalmente, los sistemas de archivos Btrfs que encuentren errores serán remontados automática en modo de sólo lectura, lo cual es un paso adelante para hacer al código más resistente errores

· Páginas grandes transparentes: Los procesadores manejan la memoria en pequeñas unidades llamadas páginas (que son de un tamaño de 4 KB en x86). cada proceso tiene un espacio de direcciones de memoria virtual, y hay una "tabla de páginas" donde se guardan todas las correspondencias entre la página del espacio de direcciones de memoria virtual de cada proceso y su página real de RA. El trabajode buscar en la tabla de páginas para encontrar qué página RAM corresponde a cada dirección virtual es muy costoso, así que la CPU tiene un cache de traducciones recientes. Sin embargo, este caché no es muy grande y sólo soporta páginas de 4 KB, asi que muchas cargas (bases de datos, KVM) tienen problemas de rendimiento porque no se pueden cachear todas sus direcciones virtuales.

Para resolver este problema, los procesadores modernos añaden entradas de cache que soportan páginas mayores que 4 KB (como 2 ó 4 MB). Hasta ahora, la única manera que el espacio de usuario tenía de usar esas páginas era con hugetblfs. Esta versión añade soporte para usar esas páginas grandes automáticamente cuando sea posible. Las páginas grandes pueden configurarse para ser usadas siempre o sólo a medida que se pidan mediante madvise(MADV_HUGEPAGE), y su rendimiento puede cambiarse en tiempo de ejecución en /sys/kernel/mm/transparent_hugepage/enabled. Para más detalles, lea Documentation/vm/transhuge.txt

· Tráfico saliente de red se expande automáticamente a varias CPUs con tarjetas de red multiqueue: Esta característica, apodada XPS, implementa un sistema queasigna una CPU a cada queue de la tarjeta de red, con lo cual se reparte la carta entre varios procesadores y se aumenta el rendimiento. Es algo análogo a RPS, que es algo análogo (pero no idéntico) a esto pero para tráfico de entrada. En un benchmark de netperf con 500 instancias de netperf TCP_RR con 1 byte de petición en un sistema AMD con 16 cores:
Con XPS (16 queues, 1 TX queue per CPU) 1234K al 100% CPU
Sin XPS (16 queues) 996K al 100% CP.

· Protocolo B.A.T.M.A.N.: B.A.T.M.A.N. is un alias para "Better Approach To Mobile Adhoc Networking". Una red ad hoc es una red descentralizada que no se basa en infraestructuras previas, como routers o puntos de acceso. En su lugar, cada nodo participa en el enrutado siendo el mismo un router y enviando datos de otros, y de ese modo la determinación de las rutas se hace dinámicamente, basándose en la conectividad que va surgiendo. B.A.T.M.A.N. es una implementación de una de esas redes. B.A.T.M.A.N es útil para situaciones de emergencia como desastres naturales, conflictos militares o censura de Internet. Más información del proyecto en http://www.open-mesh.org/

· Soporte gráfico de AMD Fusion: Pues eso, soporte de las APUs AMD Fusion, que unen GPU y CPU.

(Nota: Característica eliminada al final...) · Limites de memoria sucia en el controlador de memoria: Esta versión añade soporte para controlar los límites de memoria sucia (memoria que está en cache y ha de escribirse al disco) en el controlador de memoria (el controlador de memoria permite crear grupos de procesos y darles características de gestión de memoria diferentes a los del sistema).

Esta es la lista de novedades más importantes (si, es un poco corta, pero no me dio tiempo a más, y de todos modos las dos primeras valen por muchas otras). La lista completa, en inglés, como siempre en este enlace.

Buenas noticias para QT

Esta semana muchos nos quedamos sin aire al encontrarnos con titulares como "Nokia vende QT". Lo cierto es que tras el impacto inicial, la verdadera noticia ha resultado ser mucho menos alarmante, e incluso positiva.

Lo que se vende no es exactamente QT, sino su rama de licencias comerciales y consultoría, y esta para mi es una buena noticia. Nokia se dedica a teléfonos, no a vender licencias de toolkits. Simplemente no era algo a lo que fueran a dar prioridad de ninguna de las maneras, mientras que la empresa compradora, llamada Digia, si tiene interés en ello. De hecho no son nada novatos en estos asuntos: son desde hace tiempo un partner de QT,

Y sobre todo: con esto QT se asegura un "plan B". Además de la (no del todo creíble) afirmación de que será utilizado para proyectos I+D, QT sigue siendo el toolkit para Symbian, que es mejor que nada, y el equipo de desarrollo pasó de 60 a 260 personas bajo la dirección de Nokia, por lo que queda cierto margen para podarlo sin que el proyecto muera. Pero si todo esto no fuera suficiente y QT estuviera en verdaderos problemas, Digia podría contratar a desarrolladores clave y amortiguar la caída. Sus beneficios el año pasado fueron de 17€ millones, no son Nokia pero no parecen tener problemas inmediatos de dinero.

Así que no creo que esta noticia sea un problema.

Los parches de Red Hat

A más de uno se le han alterado los nervios cuando se ha sabido que Red Hat ya no publica en sus .SRPM del kernel los parches individuales de cada característica, driver, o fallo de seguridad solucionado, sino que solamente publica las fuentes del kernel con todos los parches ya aplicados. En mi opinión no es para tanto, incluso se podría decir que es una forma muy ocurrente de generar eso que se llama "valor añadido" sin traicionar el espíritu del software libre.

En su justificación, Red Hat da claramente a entender la motivación de este cambio: que la distro-clon Oracle no pueda hacer competencia a clientes de Red Hat fácilmente. Podrán compilar las fuentes del kernel de Red Hat y ofrecerlo como producto, pero cuando el cliente tenga un problema y pregunte qué hay de lo mio, a Oracle no le será fácil contestar, aunque tenga algunos hackers del kernel muy capaces. No es lo mismo buscar un fallo y adivinar quien lo introduce de una serie de parches perfectamente nombrados y divididos, y solucionarlo sabiendo qué partes del kernel están afectadas por el cambio, que intentar buscar el fallo entre una maraña de parche de diff de varios MB y mantener los cambios durante un periodo de soporte de 10 años. No es imposible, pero desde luego tampoco parece muy profesional.

La distro-clon de Oracle es una prueba de lo mal que Ellison entiende el funcionamiento del software libre. Básicamente fue una reacción infantil a la compra de JBoss, que Oracle creía tener en sus manos y que Red Hat le arrebató en el último momento. Tras ello la prensa quiso alimentar el fuego extendiendo el rumor de que Oracle podría comprar Red Hat, la contestación de Ellison fue: "I don't see how we could possibly buy Red Hat...I'm not going to spend $5bn, or $6bn, for something that can just be so completely wiped off the map". Seis meses después nacía "Oracle Unbreakable Linux" con ese objetivo, ofreciendo contratos de soporte un 60% más baratos que Red Hat (el dinero para él no es problema) y prometiendo recompilar los .SRPM en el preciso instante en que se hicieran públicos.

Sin embargo, Red Hat siguió ganando dinero y 5 años después sigue existiendo: el plan no funcionó. Y ahora Oracle tendrá algo más difícil ofrecer soporte, y tendrá que plantearse cada vez más el seguir siendo una distro diseñada para atraer clientes de Red Hat, o ser algo con algo más de identidad (aunque algún cliente gordo debe haber quitado Oracle a Red Hat para dar este paso).

Respecto a la comunidad, a nosotros, la medida de Red Hat tampoco es un gran problema. Todo el código que Linux tiene de los programadores de Red Hat no se incorporaba mediante esos parches, sino mediante la política "upstream first". No perderemos nada. Y Centos, por su parte, aplica la técnica de distro-clon de Oracle, pero sin importarles un carajo el soporte, por lo que no es un problema. Aquí el que sale perdiendo es nuestro enemigo favorito (Microsoft y Bill Gates ya no son un problema tan grande, creo yo).