14 de marzo de 2013

¿Qué hay de Mir?

Llevo unos días pensando en escribir algo sobre el servidor gráfico de Canonical y, la verdad, no se me ocurre demasiado. Lo único que se puede hacer es desbarrar un poco sobre lo esencial que ya se ha comentado en otros sitios: las alegaciones que hacen sobre la toma decisión de crear Mir por motivos técnicos son, a todas luces, un montón de malas excusas. Una cosa es que hayan querido escribir su propio servidor gráfico, y otro que hayan intentado convencernos de que no tenían elección: esto último es una gran falacia.

Para argumentar, la gente de Canonical se ha inventado argumentos claramente absurdos, del tipo "Weston no encajaba bien en nuestra suite de tests, hubiera sido difícil adaptarlos y los tests de Weston nos parecen inferiores". Ajá. Y por eso tomas la decisión alternativa de escribir un servidor gráfico de cero. Debe ser una suite de tests bastante buena para preferir reescribir el código a testar que adaptar los tests, o contribuir a los tests existentes en Weston (que hubiera beneficiado a todo el mundo).

O aquel de "Weston prácticamente no tenía gestión de dispositivos de entrada cuando tomamos la decisión". Ajá. ¿Y como Weston no tenía gestión de dispositivos de entrada, tomas la decisión de escribir un servidor gráfico de cero que requerirá escribir todo, incluyendo esa gestión de dispositivos de entrada de cuya ausencia te quejas? Al final, lo que ha ocurrido es que la comunidad ha añadido a Weston esa capacidad mucho antes de que Canonical anunciara Mir, con lo cual han hecho un ridículo espantoso mencionando en el wiki que la gestión de dispositivos de Weston no estaba a la altura, cuando resulta estar más avanzado que Mir: no habían vuelto a mirar Weston desde hace meses.

La realidad de esta historia es que Canonical se ha convertido en una organización bastante introvertida que está demasiado ocupada haciendo realidad su visión y no se entera bien ni se preocupa demasiado de lo que ocurre fuera. Lo más probable es que no hayan puesto demasiado empeño en Weston y simplemente hayan dado rienda suelta a la imaginación porque si, y cuando han venido las críticas han decidido construir el razonamiento "weston-no-estaba-preparado", argumento falaz teniendo en cuenta que, por muchas carencias que tenga Weston, empezar un servidor gráfico de cero, por definición, tendrá más y habrá menos gente trabajando en él.

Podrían haber resuelto muchas de sus dudas simplemente preguntando en las listas de correo si alguien estaba trabajando en tal punto, coordinándose con otros, algo de primero de comunidades de software libre, pero no se molestaron. Y si algo de Weston estuviera mal y no les gustase, o tuviesen alguna necesidad especial, podrían simplemente decirlo, pero no se han pasado por allí ni a decir buenos días.

Lo triste es que Canonical simplemente se está complicando la vida inútilmente, porque un servidor gráfico simplemente no es tan importante como para molestarse en hacer lo que están haciendo. Puedo entender lo de Unity, algo que el usuario ve y es vital para el uso de Ubuntu, pero el servidor gráfico es infraestructura y no añadirá nada de valor a Ubuntu, sólo deuda técnica acumulada y sueldos de programadores que se hagan cargo de ella. Podría perdonarse si tuviera alguna gran ventaja técnica (como los hechos se lo perdonaron a systemd respecto a upstart), pero no la tiene, de hecho es más que probable lo contrario.

Respecto al futuro de Wayland, no hay que tener ningún miedo, ya que está condenado a existir y progresar. Para que Mir pudiera desplazarlo, a Canonical tendría que importarle las necesidades y opiniones de otras personas que no sean ellos mismos, y eso no va a ocurrir. Wayland es un proyecto comunitario, y no me refiero a frikis, sino a que es un proyecto donde hay comunicación entre los programadores del servidor gráfico, los de Mesa, los de los drivers del kernel, los de los toolkits, gestores de ventanas, aplicaciones, distros. Mir es un servidor gráfico desarrollado a puerta cerrada, sin colaboración con nadie, diseñado por y para Unity, pasando absolutamente del resto del mundo. ¡Ah, y para contribuir en él se requiere cesión del copyright del código! Wayland está para quedarse, Mir mientras haya dinero detrás.

13 de marzo de 2013

Google Glasses y el intento de generalizar la tecnología

Frente a la información publicada sobre Google Glasses, hay dos clases de reacciones: la de quienes creen que es algo maravilloso, por lo que pagarían cantidades insospechadas de dinero, y los que no le ven gran interés e incluso lo están prohibiendo en sus establecimientos.

Yo soy más bien de estos últimos. Google Glasses me parece un invento genial para situaciones y usos específicos, pero que se convierta en un gadget de uso generalizado entre toda la población, como teléfonos móviles, me parece improbable.

Empecemos por el formato. Este servidor de ustedes no tiene una vista de piloto de aviones y usa gafas desde pequeño, pero últimamente sólo me las pongo para conducir porque cada vez me molestan más. Llevar unas gafas permanentemente sin necesidad alguna es algo que no estoy dispuesto a hacer bajo ninguna circunstancia, por muy maravillosas que sean, y para quienes nunca han llevado gafas tampoco va a ser cómodo. De gastarme dinero en algo, lo haría en una de esas operaciones láser, para dejar de utilizar gafas. Y aunque no soy un experto en estética y modas, la popularización masiva de las gafas me parece bastante improbable: guste o no, la mayoría de la gente va a querer ir por la vida sin llevarlas. Los smartphones, en cambio, son la mar de cómodos, se meten en el bolsillo y no molestan a nadie (si a Sergey Brin le molestan, debe estar usándolos mal).

En segundo lugar está el aspecto social, tan ignorado. Google ha creado varios vídeos-demostración, en uno de los vídeos (nota, este es una parodia), el portador acude a una cita con una chica, la cual desconoce claramente la funcionalidad de las gafas. A lo largo de la cena, el chico utiliza sus Google Glasses a escondidas para adivinar aspectos de la personalidad de la chica, fingir que tienen intereses compartidos y, en general, hacerse el interesante. Todo muy bonito.

El problema es que es una situación de ficción que sólo muestran el punto de vista del portador. En un mundo donde las Google Glasses estuviesen generalizadas, la chica conocería perfectamente la naturaleza de esas gafas, y el portador no podría disimular su uso. Sobre todo, la chica sabría que esas gafas tienen una cámara que puede grabarla en cualquier momento. Esta no se trata de las situaciones que se crean con un smartphone, en las que si alguien quiere grabar algo tiene que dejar clara sus intenciones de hacerlo, se trata de que habría una cámara apuntándote constantemente, y no sabrías si te están grabando o no. Imagínense que alguien les apuntara con la cámara de un smartphone toda una cena, ¿se sentirían cómodos?. Que la cámara sea pequeña y disimulada es secundario, un objetivo es un objetivo.

No sé ustedes, pero a mi me parece algo bastante inaceptable socialmente, no sólo pueden llevar Google Glasses un millonario en una demostración tecnológica, la gente desagradable también podría llevarlas, imagínense a absolutamente todo el mundo con ellas. En el vídeo de Google, se muestra cómo el chico hace una foto disimulada al escote de la chica, si las mujeres supieran que todos los usuarios de Google Glasses pueden hacer cosas así, seguramente serían más suspicaces con quienes las llevan. ¿Se atreverían a mostrarse ante estas gafas del mismo modo que lo harían sin su presencia? No sorprendería que se exigieran regulaciones para que fuese obligatorio un led parpadeante en las gafas cuando graban. Que un bar haya prohibido las Google Glasses en su establecimiento no tiene porque ser sólo marketing. Lo más probable es que la mayoría de la gente acabe asumiendo que quien va por la vida apuntando con un objetivo continuamente a todo el mundo es o un aspirante a director de cine, o un tipo raro (valga la redundancia).

Tercero, y quizás más importante: Si se fijan, el verdadero protagonista de los vídeos de demostración de Google Glasses no son las Google Glasses en si, sino Google Now: la tecnología de reconocimiento de voz e interfaz natural de Google, es decir, el equivalente al Siri de Apple. En los vídeos se ve a un tipo que puede gestionar sus mensajes y contactos con la voz, lo verdaderamente emocionante es eso, el hecho de poder interaccionar con el ordenador con la voz, las gafas son secundarias (de hecho, los vídeos intentan vender prácticamente el mismo mensaje que los vídeos de promoción de Siri). No hace falta decir que esa tecnología de reconocimiento de voz puede funcionar igualmente en un smartphone.

No quiero decir con esto que las Google Glasses sean una chapuza, por supuesto. Sin dudan van a ser muy útiles para muchos trabajos en los que uno podría consultar cosas sin tener que moverse. Serían imprescindibles en aquellos casos en los que las manos estén ocupadas. Por descontado, serían útiles a los mancos. Y qué decir de los juegos, o de la Ley de Kerenski. ¿Pero un gadget generalizado entre la población? No lo veo.

(Por cierto, no sería de extrañar que el tan rumoreado Apple Watch fuese cierto y se tratase de un intento de facilitar el acceso directo al móvil y a las notificaciones y a Siri de un modo análogo a Google Glasses, pero sin colgar de las orejas todo el rato ni apuntar con una cámara a todo el mundo. Si así fuera, desde luego tendría mucho más sentido que Glasses)

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.