5 de marzo de 2013

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.

14 comentarios:

  1. ¿Esto es sólo un proyecto, una idea o ya hay conversaciones avanzadas del tema?
    Saludos.

    ResponderEliminar
  2. Anónimo5:45 p. m.

    bueno yo tengo unapregunta: al no ser el kernel que lepermite usar ciertas librerias y las otras no a mi modo de ver el kernel esta mas expuesto a virus ??

    ResponderEliminar
    Respuestas
    1. Al contrario, la seguridad mejora notablemente.

      Eliminar
  3. Anónimo7:13 p. m.

    Excelente análisis... como de costumbre

    ResponderEliminar
  4. Anónimo8:28 p. m.

    Hola Diego.
    Primero decir que me encanta tu blog, uno de los más interesantes e instructivos del mundo linux en español, en mi opinión.

    Me gustaría saber tu opinión respecto a esto:
    https://wiki.ubuntu.com/MirSpec

    ¿Llevamos años esperando Wayland y ahora esto?!!
    ¿Qué pensarán en Steam al respecto?

    Un saludo.

    ResponderEliminar
    Respuestas
    1. Eso lo comentaré más adelante. Steam será práctico (si tiene que soportarlo, lo soportará), pero ten en cuenta que a Steam no le va a importar demasiado uno u otro, su lucha está en la pila opengl (mesa), no tanto en el servidor gráfico

      Eliminar
  5. como los bundles de chakra no , asco , vale , esto es software libre pero la norma fundamental es que tiene que aparecer el nombre del autor , y la idea a sido de chakra , curiosamente solo echa en kde

    ResponderEliminar
    Respuestas
    1. Anónimo12:34 a. m.

      ¿La idea ha sido de Chakra? A mí esto del Linux Apps me suena un poco a 0install, Autopackage o sobre todo a Klik ( http://klik.atekon.de/indexold.php )

      Klik en particular me parecía una gran idea: se reutilizaban los paquetes de las distros para crear un paquete autocontenido, que funcionaba montando un filesystem overlay sobre el FS real. De forma que la aplicación se integraba con el sistema existente, pero sin poder modificar el sistema original: http://klik.atekon.de/wiki/index.php/User%27s_FAQ

      Lo gracioso del tema de los sistemas de paquetes autocontenidos es que los "linuxeros talibanes" repetían una y otra vez que no hacia falta perder tiempo en esas tonterías, que APT es lo mejor del mundo y no hace falta nada más. ¡Esos sistemas autocontenidos duplican librerías y nos hacen perder preciosos kilobytes de disco!

      ¿Tal software no está empaquetado para tu distro? Busca un PPA y reza para que no se descontrolen las dependencias.

      ¿La versión de Firefox de tu Debian stable no sabe ni lo que es HTML5? Backport no-oficial desde Sid y a correr.

      ¿Quieres tener dos versiones del mismo software que se ejecuten de manera independiente? Esto... Nadie quiere eso. Deja de tocar las pelotas, usa APT y cállate. ¡APT mola y el resto de alternativas son siguiente-siguiente-siguiente que es una mierda!

      Eliminar
    2. Anónimo1:23 p. m.

      Buena suerte para conseguir lo mismo que hace apt. Si lo talibanes le tenemos cariño es por algo.

      En escritorio podría ser una opción todo eso de lo que hablas, pero y en los servers? Acabaremos con un sistema de empaquetado distinto en los escritorios y otro en los servidores?

      Eliminar
    3. Anónimo4:34 p. m.

      APT está muy bien, pero hay cosas que no hace. Podemos asumirlo y buscar soluciones para esas situaciones donde no llega (como hacer que APT y el nuevo sistema de paquetes autocontenidos "hablen" y se coordinen) o seguir repitiendo que APT es lo más mejor y que no hace falta cambiar nada.

      La idea de los sistemas autocontenidos es que se pueden combinar y usar en paralelo con el sistema de paquetes nativo. No hace falta tirar APT a la basura, ni nada parecido.

      Eliminar
  6. Con esto, la preocupación que crecía sobre el camino que estaba tomando GNOME dan la razón a distros como Ubuntu, Debian, Linux Mint entre otras, ya que se propusieron migrar a otras interfaces o crear la suya propia a partir de los fork de GNOME hace ya algún tiempo. Definitivamente GNOME vive en un muy mal momento.
    VPN For Linux

    ResponderEliminar
    Respuestas
    1. Anónimo8:13 p. m.

      Debian no hizo fork de ninguna interfaz gráfica ni cambió la que utiliza por defecto. De hecho, en Wheezy, la interfaz gráfica por defecto va a seguir siendo GNOME 3.X. En algun momento, hubo un rumor que decía que Debian iba a utilizar por defecto a XFCE en lugar de GNOME, por problemas de espacio en un CD, pero luego fue desmentido.

      Saludos!.

      Eliminar
  7. Hay que tener en cuenta que tanto Gnome como KDE, son proyectos muy grandes, que al final y al cabo solo generan, duplicidades, innecesarias. Como filosofía de diseño el concepto de Gnome siempre me a gustado más, que KDE, ya no solo en la forma del escritorio, si no en las app's asociadas, varias aplicaciones que solo hacen una cosa, y lo hacen razonablemente bien, Rhythmbox es mucho mas simple que Amarok. Nautilus, Cheese... Pero claro las librerías GTK, pues me parecen que en muchos casos están desfasadas y generan mas problemas, que facilidades. QT, como librerias, es muy buena, y dan un rendimiento muy superior, por eso pueden poner tantos efectos y brillitos, dado que el rendimiento se lo permite, cosa que a mi no me atrae.

    Me gusta lo que puedo ver de Canonical, que piensan:
    -Bueno, nos creamos nuestro escritorio, y usamos una interfaces MESA, pero con integración y estándares de KDE, y ofrecemos una integración decente con Widget y mini app's que se programan facilmente gracias a Qt y que ademas dan un rendimineto y consumo aceptable, ya que para mi entender, de mi pc, lo que menos me interese que me consuma recursos, sean las aplicaciones del KIT con el SO.
    Imaginaros en el año 96, que la calculadora de W95 consumiera el 30% de recursos. No hubiésemos evolucionado del MS-DOS.
    El futuro mas interesante para mi, seria que con el tiempo QT, integrara aceleración para driver MESA, pero no solo en el dibujado, sino, en la integración de tecnologias OpenCL, para tareas de alto consumo de CPU, compresión de video, audio, render, cifrados, ya que son tareas, que rara vez se ejecutan con un juego 3D funcionando, con lo cual aprovechemos ya de una vez, un tipo de procesador, super potente, como las graficas actuales.

    ResponderEliminar
  8. Anónimo8:19 p. m.

    No me queda claro si las aplicaciones distribuídas mediante "Linux Apps" serían capaces de compartir librerías entre si. ¿Cómo es el tema?

    ResponderEliminar