Linux Apps: ¿Un paso hacia adelante?

Estamos pasando por una época en la que los grandes cambios de la informática surgen en torno a los dispositivos portáctiles, y muchas cosas que se daban por hechas pasan a repensarse para encajar, de un modo u otro, con la mente puesta en los portáctiles. Los proyectos de software libre sacan de su bolsillo su teléfono Android y sienten, con cada movimiento de la yema del dedo, que los pixeles de la pantalla son dibujados por instrucciones de un software que no es el suyo.

Esto produce una frustración que, tarde o temprano, les lleva a ponerse manos a la obra e intentar hacer cosas para solucionarlo. Los puntos de vista y preocupaciones que predominaban cuando el escritorio tradicional era el rey desaparecen, sus problemas se dan por solucionados, y la atención se centra en los portáctiles y en lo que de una manera u otra lo rodea o se sincroniza con ello: interfaces táctiles, tiendas de aplicaciones.

GNOME, en particular, está muy afectado por esta manera de pensar. La interfaz de GNOME 3 se diseñó con esa mentalidad. Ahora, GNOME ha decidido aplicar ese punto de vista a otros aspectos de la infraestructura del proyecto: Javascript como lenguaje prioritario para aplicaciones, y aplicaciones confinadas.

Respecto a la elección de Javascript como lenguaje oficial para aplicaciones, sólo cabe aplaudir. GNOME lleva demasiados años de devaneo estéril sobre qué lenguaje no-C de alto nivel escoger como "oficial". Y se equivocan los que piensan que no tener un lenguaje oficial no es importante. La falta de un criterio oficial ha dispersado inútilmente los recursos, porque todos se dedicaron a intentar hacer valer el suyo: Sun hacía en Java aplicaciones para su Java Desktop que ya nadie recuerda, Icaza pretendió que se usara C# y sólo consiguió que la gente se devanara los sesos intentando librarse de Mono, reescribiendo aplicaciones C# en C++, o intentando crear un nuevo conjunto de aplicaciones en Vala. Resumiendo, conflictos y trabajo malgastado. Una elección oficial, aunque sea una decisión meramente política, incita a dejar de intentar luchar por el trono. Quien quiera usar otros lenguajes podrá seguir haciéndolo, pero serán decisiones pragmáticas, alejadas de las luchas ideológicas subterráneas.

Hay quien ha argumentado que Javascript es una mala elección, y que lo lógico, por tradición gnomera, hubiese sido Python. Aunque es una postura comprensible, yo creo que lo importante es que se hayan decidido por uno, sea el que sea. Además, recuerden que la inversión técnica ha logrado que los motores de los navegadores (GNOME usa el de Firefox en su GJS) sean por lo general bastante más rápidos que el interprete Python oficial.

Pero el anuncio estrella es el de crear una nueva manera de distribuir y ejecutar aplicaciones, a imitación de las App Stores existentes. Básicamente, las aplicaciones se suministrarán en un archivo-imagen. Este archivo-imagen se montará y se ejecutará en una jaula, construida con infraestructura del kernel, en la que sólo tendrá acceso a sus archivos y a las librerías del sistema que haya declarado previamente en una especie de dependencias de alto nivel ("system" para una aplicación que use librerías básicas como libc, "gnome-platform-1.0" para librerías GNOME, etc. Dado que cada proceso está aislado del mundo exterior, la comunicación entre procesos sucederá a través de una imitación de los Intents de Android que funcionarán sobre el IPC al estilo DBUS que se espera que se incluya en el kernel.

En principio, este sistema no es exclusivo de GNOME, KDE y cualquier otro escritorio podrían usarlo también. De ahí que hayan dado en llamarlo "Linux Apps", y no "GNOME Apps", aunque hayan sido las aplicaciones de GNOME las que les han llevado a poner manos a la obra.

Lo interesante de esta propuesta es que rompe radicalmente con el modelo de distribución de aplicaciones en Linux. En realidad, lo que están intentando es crear lo que mucha gente lleva deseando desde hace muchos años: un entorno de desarrollo y distribución de aplicaciones uniforme entre diferentes distros Linux. Teóricamente, esta uniformización facilitaría a las empresas la programación de software para Linux, al poder olvidarse de .deb, .rpm, o de librerías exóticas. Las distribuciones se limitarían a ocuparse de la infraestructura del sistema operativo y de software no-de-usuario, las aplicaciones del usuario serían una cosa aparte.

La consecuencia lógica de esta clase de aplicaciones tendría que ser alguna clase de "App Store" al margen de las distros, aunque que aun no se ha hablado de eso, y existe la opción de incluir imágenes de Linux Apps en paquetes tradicionales. En su contra, está el hecho de que el modelo de ejecución de aplicaciones en jaulas no tiene por qué ser el mejor del mundo, aunque cabe esperar que permitan la creación de Linux Apps que especifiquen su deseo de ser ejecutadas fuera de la jaula. Todavía es pronto para ver en qué acaba esto, pero es una propuesta que podría llegar a ser muy útil.