Lo que no mató a Linux en el escritorio

Miguel de Icaza ha escrito un post, titulado "What killed the Linux Desktop", que ha hecho cierto ruido. Como me va la marcha, voy a comentarlo un poco.


El post comienza contando la instalación de un nuevo disco duro. Llegado al punto de conectar a los altavoces, Icaza piensa esto:

"[...] when I got to the speakers cable, I just skipped it. Why bother setting up the audio? It will likely break again and will force me to go on a hunting expedition to find out more than I ever wanted to know about the new audio system and the drivers technology we are using"

Tan autocríticos somos en el mundo del software libre, que no contentos con quejarnos de los problemas que tenemos, también nos quejamos de los problemas que sospechamos que podríamos tener. ¿No enchufar el cable de sonido sólo porque "probablemente" no funcionará?

La verdad es que nunca he entendido la obsesión que hay con el tema del sonido y su supuesta inestabilidad. Linux 2.6.0 incorporó ALSA hace ya casi 9 años, que además se proporcionaba compatibilidad con la anterior API, OSS. ¿Dónde está el infierno de cambios y reescrituras? Desde aquello el único gran cambio ha sido Pulseaudio, que causó cierto impacto, fundamentalmente por la baja calidad de drivers y de la implementación de sonido del plugin de Flash, que ya han sido resueltos. Pero de eso ya han pasado 4 años y medio. A día de hoy hay gente que usa cascos bluetooth en Linux sin muchos más problemas que los que sufren algunos usuarios de Windows cuando tienen que andar lidiando con software de bluetooth de escandalosamente baja calidad proporcionado por el fabricante. Pero sigamos:

"Linus, despite being a low-level kernel guy, set the tone for our community years ago when he dismissed binary compatibility for device drivers."

Este mito estúpido de que en el kernel la compatibilidad binaria no importa empieza a ser cansino. Linux mantiene la compatibilidad binaria en las llamadas al sistema. Que es, al fin y al cabo, lo que tiene que ofrecer todo sistema operativo al mundo, y que es lo que verdaderamente importa. Es más, no sólo la mantiene, sino que la mantiene mejor que las librerías. En todos estos años, Linux no ha cambiado la compatibilidad binaria de las llamadas al sistema ni una sola vez.

Existe cierta obsesión con que esto mismo debería aplicarse con los drivers, que son en realidad plugins del kernel, y no aplicaciones construidas encima de una libreria. La verdad, no entiendo por qué. Desdeñar la participación privativa en materia de drivers fue algo arriesgado, pero ha tenido éxito. Linux tiene un soporte de hardware de consumo muy bueno, hay varios fabricantes importantes que facilitan ellos mismos los drivers libres, y el hardware que no se soporta es minoría. ¿A alguien le parece razonable obsesionarse con facilitar el trabajo de los drivers propietarios para agradar a minorías, en lugar de apostar por el sistema que ha proporcionado mejores resultados hasta hoy? Eso por no mencionar las consecuencias para el kernel de limitar su capacidad de evolución interna.

"The attitude of our community was one of engineering excellence: we do not want deprecated code in our source trees, we do not want to keep broken designs around, we want pure and beautiful designs and we want to eliminate all traces of bad or poorly implemented ideas from our source code trees"

No deja de ser curioso que esto lo diga alguien que ha dedicado muchos años a implementar una tecnología que en el universo Microsoft representa exactamente ese espíritu de mandarlo todo a paseo y empezar de cero, como bien dijo Joel Spolski. ¿Recuerdan Silverlight y su intento de reinventar nada menos que la web, recuerdan como Mono lo copio con su Moonlight, y como ahora han tenido que dejar de darle soporte porque ni Microsoft apuesta por ello? Es una definición perfecta de reinventar por reinventar. Por no hablar de Windows Phone 7, que mandó a paseo gran parte del software disponible para Windows CE sólo para mayor gloria del imperio C#.

Pero respecto a Linux, al margen de que eso de que la compatibilidad se rompe constantemente y es imposible desarrollar nada está muy exagerada, lo cierto es que la búsqueda de la excelencia técnica fue, es y seguirá siendo una característica muy deseable, muchas veces por encima de la compatibilidad. Linux ha sido un sistema operativo retrasado técnicamente en lo que al escritorio se refiere, por lo que la mejora técnica a base de reescrituras puede dar sensación de inestabilidad, pero también lo es de evolución. En realidad nadie puede evitarlo, incluso Microsoft rompió la compatibilidad binaria de los drivers de tarjetas de vídeo para rediseñar de cero un nuevo subsistema gráfico.

Si se paran a pensar, se darán cuenta que muchas de esas "obsesiones técnicas" nos han proporcionado beneficios a largo plazo. ¿Dónde estarían KDE y GNOME de haber tenido que conservar la compatibilidad con sus versiones 1.0? Además, dado que en Linux casi todo es software abierto, romper la compatibilidad es mucho más sencillo, y si una aplicación deja de poder usarse porque nadie se molesta en portarla a nuevas APIs, se puede afirmar que hay muchas posibilidades de que esa aplicación no merezca la pena y esté completamente desmantenida. Icaza menciona que en Windows 8 será posible utilizar el Photoshop que se publicó hace 8 años, pero cabría preguntarse si tiene tanto sentido dar prioridad a los que quieren utilizar software de hace 8 años.

The second dimension to the problem is that no two Linux distributions agreed on which core components the system should use

Red Hat tampoco se ha puesto de acuerdo con nadie para decidir qué componentes usar, y no parece haberles afectado demasiado. Una vez que una distro se hace un hueco en su campo, los fabricantes de software privativo no tienen problema en prestarle atención. 

We alienated every third party developer in the process. The ecosystem that has sprung to life with Apple's OSX AppStore is just impossible to achieve with Linux today.

Quizás porque, en realidad, Linux nunca ha pretendido ser una plataforma donde el software propietario pudiese hacer su agosto, salvo excepciones. Siempre ha sido una plataforma en el que la prioridad la tiene el software libre. Si Linux ha de tener éxito entre desarrolladores de código propietario, no lo hará porque el ambiente de los proyectos libres sea tal o cual o la compatibilidad se rompa mucho o poco, lo hará gracias a que una empresa haga lo que Red Hat hizo en los servidores. Es decir, gracias a algo como Ubuntu/Canonical.




Y para terminar, hay que señalar que el post de Icaza habla en todo momento en un tono de "guerra perdida". Aun siendo una anécdota, el escritorio Linux nunca tuvo mejor posición que hoy, y el futuro es esperanzador. Ubuntu se ha convertido en una alternativa que la gente normal es capaz de usar e incluso disfrutar. Y aunque en materia de smartphones el software verdaderamente libre lo tiene de momento bastante negro, de cumplirse la analogía Jobsiana de los escritorios y los camiones, es previsible que las compañías comerciales se dediquen a los dispositivos móviles y que Linux empiece a campar por el escritorio con más comodidad.

Historias de Gnome

En un documento sobre la historia de Gnome se comenta la creación de la fundación, y varias de las actividades iniciales:

After the Gnome foundation was announced, a number of initiatives from the founding members was announced:

• Sun Microsystems adopts GNOME technologies for their user environment in the Solaris OS
• Hewlett-Packard adopts GNOME for their user environment in the HP-UX operating system
• Sun will port their recently OpenSourced StarOffice suite to the Gtk+ toolkit and will integrate with the GNOME Bonobo component architecture
• IBM contributed the SashXB rapid development environment to GNOME
• GNOME would adopt and integrate Mozilla as part of its desktop strategy.
• The GNOME project would adopt OpenOffice technologies.

A día de hoy, Gnome no tiene suite ofimática (Openoffice es externo y no está integrado en Gnome más allá de GTK), ni un motor web que se pueda utilizar más allá de epiphany (aunque eso puede cambiar con la inclusión de la versión GTK de WebKit, el motor de renderizado de Safari heredado de KDE), ni OpenOffice se ha integrado con Bonobo (afortunadamente, porque Bonobo es un error que Gnome recomienda dejar de usar). Con respecto a SashXB, tambien ha fracasado, aunque está Anjuta.

La verdad es que la historia de Gnome es curiosa. Cuando Icaza comenzó Gnome, lo hizo en parte extasiado por el resplandor del sistema de componentes de Microsoft, COM. Aquello era el futuro y el software libre en particular y Unix en general debían usarlo para no quedarse atrás tecnológicamente. Además, despues de haber considerado crear un clon de la entonces propietaria QT y haber jugado con GNUStep (Objetive-C) comenzaron su proyecto utilizando C y trocitos (según tengo entendido) de C++ y Objetive-C, pero C prevaleció, porque al fin y al cabo, la orientación a objetos se podía imitar en C sin problemas ni contraprestaciones, y permitía crear bindings más fácilmente.

Las flamewars de "usar C para la base de un sistema de escritorio es estúpido" no cesaron durante todo el crecimiento de Gnome, especialmente fomentadas por el uso de C++ de su más directo competidor, KDE, y el núcleo y entorno de Gnome defendio en todo momento sus decisiones pasadas, su criatura, y el hecho de haber elegido C. Hasta que se empezó a oir de C#. Icaza quedó extasiado por el resplandor del nuevo lenguaje y plataforma de Microsoft, .NET. Aquello era el futuro y el Gnome en particular y el software libre en general debían usarlo para no quedarse atrás tecnológicamente; un Gnome basado en .NET sería la leche. De repente, escribir aplicaciones en Gnome pasó a considerarse improductivo, era mucho mejor hacerlo con Mono. Aunque a la hora de compararse con otros escritorios, Gnome no sufría problemas de improductividad. Sólamente es criticable si lo comparas con Mono, no con otros. Por otra parte, resultó que Bonobo, el futuro, solo lo utilizaban unas pocas aplicaciones. Los mismos ingenieros de Microsoft que inventaron COM dijeron en una entrevista, hablando sobre el futuro framework de comunicación entre aplicaciones en Vista, que COM en realidad no tenían demasiado sentido, que no eran una buena idea, y que Microsoft proporcionaba compatibilidad, pero abandonaba su desarrollo. Vaya por DIos, lo que había sido el futuro tuvo como único futuro convertirse en pasado, y resulto que uno de los pilares de la fundación de Gnome en realidad no era tal, y se recomendó dejar de utilizarlo.,

Recientemente, Microsoft anunció Silverlight. Los millones que Microsoft gastá en hacer marketing de sus tecnologías entre dueños de empresas y programadores hizo efecto, y todos los medios empezaron a hablar de ello. Icaza, asiduo a conferencias de desarrolladores de Microsoft, se enteró, y le gustó. Aquello era el futuro y para no quedarse atrás tecnológicamente que mejor que implementar un clon de Silverlight libre. En 21 días, consiguieron una implementación inicial. El apartado gráfico no se hizo en Mono, en C#, en ese lenguaje del futuro tan ideal para toda la familia, sino en C++, con bindings a C#. Y aun no se ha producido, pero me juego el espaciador de mi teclado a que veremos discusiones sobre si integrar silverlight en Gnome como base para crear aplicaciones.

En fin, una historia ajetreada e interesante, comentada a vista de pájaro. Mas lo que nos queda, porque es obvio que Microsoft va a seguir sacando frameworks de desarrollo revolucionarios, y si la Historia es un libro de predicciones del futuro está muy claro lo que va a seguir sucediendo. Como se puede comprobar, no soy entusiasta de Gnome, y no porque sea un troll, sino porque considero que toda su fundación tecnológica está un tanto...descentrada. Pero sobre todo lo que menos me gusta no es tanto su fundación tecnológica actual - el kernel Linux fue una mierda durante muchos años, pero su desarrollo estuvo siempre fundamentado en un fuerte deseo de mejorar a toda costa y hacerlo bien - que a día de hoy es un intento de imitar visualmente a Mac OS X utilizando para ello tecnología de Microsoft, sino que no haya una dirección de futuro única, poderosa, inequívoca que pueda enderezarlo. Existe un preocupante conformismo con el estado actual de las cosas, a pesar de que hoy en día estamos contemplando los mayores avances en tecnologías relacionadas con las interfaces gráficas desde que éstas fueron inventadas. Me asombra que la gente se atreva a hablar del "año del escritorio Linux": Es muy obvio que ni el GNOME ni el KDE de hoy van a conseguir una adopción masiva de Linux. En temas de escritorio estamos igual que Linux en servidores cuando el kernel estaba por su versión 2.0: funcionales y progresando pero aun lejos de conseguir la adopción masiva.

Air 1.0

No ha salido mucho en las noticias, lo cual dice quizás mucho sobre Adobe, pero hoy se ha anunciado uno de los productos que más influirá en el devenir del futuro de la Web: la plataforma Adobe AIR 1.0.

¿Que es Adobe AIR 1.0? Pues el equivalente del Silverlight de Microsoft y la evolución de Flash. Al igual que Microsoft, pretende reemplazar la web con su propia solución propietaria. La diferencia es que lo de Adobe es algo menos propietaria: Utiliza como base partes de software libre (webkit, sqlite, la vm de javashit que donaron a mozilla; HTML javascript y demás estándares web), y van a lanzar una versión para Linux a lo largo de este año (de momento solo está disponible para Mac y Win), pero tambien utiliza flash y sus librerias de javascript ActionScript como base, y sus APIs no están estandarizadas. Otra diferencia es que Silverlight a día de hoy no es más que un plugin para el navegador, mientras que AIR, además de eso, permite crear aplicaciones que se ejecuten en el escritorio, fuera del navegador (en este sentido, se parece a Mozilla Prism). Estas aplicaciones tambien son multiplataforma (no serán aplicaciones nativas, las ejecutará el runtime), de nuevo positivo para Linux. Cabría preguntarse aquí si Microsoft sacó Silverlight primero como una mera imitación de flash, antes de esperar a mejorarlo (ya están haciendo marketing de Silverlight 2.0), solo para intentar llevarse el gato al agua.

AIR es el runtime, y tiene su kit de desarrollo correspondiente llamado FLEX, cuya versión 3 ha sido publicada simultaneamente con AIR 1.0. FLEX está basado en Eclipse y licenciado bajo la MPL, y parece ser una mezcla de toolkit (la interfaz de usuario y widgets que se verán en AIR) y algo de middleware para que los servidores enlacen con las aplicaciones del servidor para dar servicio a las aplicaciones AIR clientes. Aunque por un módico precio de 249$ puedes acceder al Adobe Flex Builder 3, que se supone que es aun mejor que la historia gratuita de Eclipse.

¿Y quien ganará? Yo tengo mis dudas: Microsoft es el gigante, pero en lo que se refiere a desarrollo Web. Adobe tiene una fuerza enorme. ¿Cuantos millones de páginas utilizan flash? ¿Existe algún ordenador conectado a internet que no tenga el plugin de flash instalado? Y, ¿el triunfo de quien será mejor para el usuario de software libre medio, AIR o Silverlight? Como ya dije, yo creo que Air: Adobe se ha basado en estándares y software libre y aunque ha construido sobre ellos un runtime y un SDK/API propietario que no tiene pensado estandarizar, y mucho menos liberar, eso es menos malo que lo de Silverlight. Aunque no es el paraiso que los que apoyamos el software libre deseamos, hay que reconocer que muchos de nosotros utilizamos el plugin propietario de flash en Linux sin demasiados problemas y sin que se nos caigan los anillos; comparen con lo que ha hecho Microsoft por nosotros durante toda su existencia. Y sobre todas las cosas, tengamos esto muy claro: Microsoft felizmente erradicaría a Linux de la faz de la tierra y nos consta que ha movido y mueve piezas constantemente para intentarlo. Adobe sin embargo no tiene ningún interés en ello; incluso esta ligeramente interesado en fomentar a la competencia de Windows, razón por la cual AIR se porta a Linux. No se dejen engañar por la copia de silverlight 100% libre de Icaza: quien controla Silverlight y Air son Microsoft y Adobe y son a ellos a quienes debemos juzgar por sus obras, no a Icaza, y se ha visto aun ninguna señal de Microsoft que no haga pensar que no son El Enemigo.

Gnome 3.0...¿malo?

A estas alturas ya habrán oido ustedes hablar de Gnome 3.0/GTK 3.0. Consiste básicamente en romper la compatibilidad y crear un escritorio Gnome mejorado, y una plataforma GTK idem. El caso es que Miguel de Icaza ha expresado su opinión al respecto y piensa que los planes de GTK 3.0 son malos. ¿Por qué? Esencialmente, porque parece pensar que romper gratuitamente la compatibilidad para dar hipotéticamente paso a una aparición de supuestas características nuevas y revolucionarias no tiene porque tener éxito, y sobre todo: Fastidia a los ISVs. Es decir, fastidia a las empresas que utilizan GTK como interfaz para sus propios productos.

Y en parte tiene razón. Es decir, no hay más que leer el famoso documento de Joel Spolsky "How Microsoft lost the API War" para darse cuenta de que romper la compatibilidad por el simple placer de hacerlo no va a traer nada bueno a la relación de Gnome con sus ISVs, aunque GTK 3.0 sea el toolkit más avanzado del planeta. Y sin embargo, el razonamiento de Miguel me parece erróneo. Si, la compatibilidad es importante. En parte es lo que convirtió a Microsoft en monopolio, y eso ya dice mucho de por si. Tener compatibilidad es la hostia. Pero...

Díganme: ¿Con quien tiene que mantener la compatibilidad Linux? Oh, si, hay compañías que usan Linux. Es decir: ¿Qué empresa puede resistirse a una cuota de público del 1%?

Por si no lo captan, se trata de ironía. Seamos sinceros, los ISVs que utilizan GTK son más bien....pocos. Y no parece que haber conservado la compatibilidad en GTK 2.x todo este tiempo haya ayudado gran cosa a que ese número aumente de forma significativa. Es bastante evidente que la razón primordial que aleja a los ISVs de Linux es la falta de usuarios. Y la falta de usuarios es primordialmente una consecuencia de no ser una alternativa muy atractiva a Windows.

Empezemos por el principio: Solvéntense en GTK y Gnome todos los problemas que impiden que el escritorio Linux sea el primero del mundo. El primero por delante de los demás (¿por qué aspirar a menos?). O como mínimo, tan bueno como el mejor (creo que todos estaremos de acuerdo con que los escritorios Linux actuales no llegan ni a eso). Entonces, pero solo entonces, el respeto por la compatibilidad será importante. No ahora. La compatibilidad es buena cuando se trata de conservar lo bueno. Conservar lo malo no va a servir a Linux de nada. Me dirán que Windows 9x era una caca y que su éxito se debió en parte a la compatibilidad: falso, aunque la implementación de windows 95 dejara que desear, la funcionalidad que ofrecía de cara al usuario era revolucionaria. La novedad de la GUI era igual de rompedora aunque se colgara cada cinco minutos.

Además, no se pueden aplicar los mismos principios a todos los casos. Miren a Microsoft: Necesita conservar la compatibilidad para no espantar a la gente a las plataformas alternativas emergentes, pero al mismo tiempo necesita innovar -lo que implica romper la compatibilidad en mayor o menor grado, miren lo de Vista- para no quedarse atrás de esas plataformas. Linux sin embargo está en la privilegiadísima posición de poder romper la compatibilidad en el escritorio a todos los niveles que se le antoje, porque solo le importará a los cuatro frikis que lo usamos. Eso da libertad de creación total a los programadores. Es más, miren OS X, considerado generalmente como el mejor escritorio tecnológicamente hablando: ¿Podría haber surgido OS X como evolución de OS 9? ¿O si hubiera tenido como requisito inicial no romper la compatibilidad? Dificil hubiera sido, lo que está claro es que no surgió de ahí: Al irse de Apple y fundar Next, Steve Jobs tuvo la oportunidad de crear un sistema operativo de escritorio de cero, sin importarle un carajo la compatibilidad con nada. La compatibilidad con OS 9 solo se añadió posteriormente y mediante emulación, y la API Carbon se implementó encima de la base que ya había sido creada. Paradójicamente el abandono temporal de Jobs puede considerarse como una clave del éxito actual de Apple (¿qué seria de Apple, del iPhone, sin OS X?

En resumen, no creo que la obsesión por satisfacer a los ISVs de Miguel de Icaza - quien curiosamente en su día fomentaba el cambio radical de usar Mono- sirva a Linux de mucho. Puede servir -y sirve- en el software para servidores, donde existe una amplia base de usuarios, pero no en escritorio. Por supuesto, esta es mi opinión, ustedes son libres de no estar de acuerdo conmigo y por tanto de equivocarse.

La buena estrategia de exigir que todos los drivers sean de código abierto

Desde sus inicios se ha criticado a Linux el hecho de no facilitar la creación de drivers propietarios. No sólo porque la propia licencia hace que cualquier driver propietario sea probablemente ilegal, sino por el hecho de no tener una API/ABI estable. Desde sus inicios hay gente que ha predicho que Linux no conseguiría buena compatibilidad de hardware hasta que abandonara esa senda de despreocupación de aficionados y espíritu hacker y se pusieran a hacer las cosas en serio, con profesionalidad, preocupándose por las peticiones de los fabricantes de hardware.

Sin embargo, tras tantos años sin hacer ni caso a esas exigencias, el soporte de hardware es cada vez mejor y más completo, un curioso hecho fácil de constatar al que que los críticos rara vez prestan atención.

Hasta Nvidia está cediendo últimamente y publicando cada vez más información sobre sus tarjetas para ayudar a los desarrolladores del driver libre Nouveau, a pesar de que es el mejor driver propietario para Linux. Los drivers para tarjetas gráficas de AMD cada vez tienen mejor rendimiento, e Intel sigue invirtiendo tiempo y dinero en los suyos. Mesa va a introducir soporte de OpenGL 3.2 y 3.3 en la próxima versión. Se ha tardado, pero están ahí, y una vez que se ponga al día -ahora mismo Mesa tiene que desarrollarse con rapidez sólo para ir disminuyendo la distancia-, soportar hardware de última generación será más fácil.

La guinda del pastel puede ponerla Steam OS: Al igual que ocurrió con los servidores, una vez que Linux se populariza en un sector, los fabricantes de hardware de ese sector tienen la necesidad de que su hardware funcione sin problemas en Linux.

Al final, tras tantos años, no facilitar la creación de drivers propietarios no sólo no ha causado los problemas que muchos predecían, sino que además ha traído ventajas. La ventaja de la portabilidad, o de que los drivers tengan tiempos de soporte y mantenimiento mucho más largos (mucho hardware antiguo que funcionan sobre Linux sin problemas dejaron de hacerlo hace años en versiones modernas de Windows). La ventaja de que no se eliminen características por capricho de un directivo. Y, sobre todo, la ventaja de que no mantener una ABI interna ha permitido a Linux evolucionar con flexibilidad todos estos años para llegar a todos los rincones donde ahora llega.

Y es que los críticos de la ausencia de una ABI de drivers estable, como por ejemplo, Miguel de Icaza, olvidan que los drivers no son un especie de programa que utiliza el kernel como quien utiliza una librería, sino que son parte misma del kernel; y olvidan que los drivers no deberían ser un asunto de fabricantes de hardware, que por definición sólo piensan en vender hardware nuevo y siempre les pesa gastar dinero en soportar el viejo, sino de programadores, a quienes les pagan por soportarlo lo máximo posible.

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.

Buenas y malas noticias en la compra de Novell

La retahíla de ventas empresariales que inició la crisis se ha llevado por delante a otra de las grandes candidatas que se murmuraban últimamente: Novell, histórica compañía de IT donde las haya, y dueña de SUSE Linux.

El comprador, "Attachmate Corporation", va a pagar 2.200$ milloncejos por ella. De esa cantidad hay que sustraer los 450 que les va a dar un consorcio liderado por Microsoft a cambio de su propiedad intelectual. Estas son las "malas noticias": Novell posee cientos de patentes (882 en total) relacionadas con las tecnologías que la hicieron famosa: redes (en su sentido más original), servicios de directorio, y cosas así. Del tipo de cosas que todo SO lleva haciendo desde hace décadas. ¡Sin olvidar el famoso copyright de Unix que reclamaba SCO! Si, UNIX podría pasar en su sentido legal a manos de Microsoft (no está claro si traspasan toda la propiedad intelectual o sólo patentes).

Una verdadera joya legal que Microsoft se mete en el bolsillo por cuatro duros: en el famoso trato de patentes con Novell/SUSE ya tuvieron que apoquinar 348$ millones, y en esta ocasión van a pagar 450$ millones, apenas 100 más, por meterse las patentes en cuestión en el bolsillo, con la posibilidad de recuperarlos con creces haciendo el tipo de cosas que las multinacionales de software suelen hacer con las patentes. Casi mejor no pensar lo que puede venirnos encima.

Respecto a la empresa en si, va a ser dividida en Novell y SUSE. Vuelta a los orígenes. En realidad, SUSE era la única división de Novell "sana", era la única que crecía con fuerza, las demás poco a poco iban hundiéndose. Esta es la parte buena de la noticia: Que SUSE sea tratada con miramientos y puesta en una división para ella sola es señal de que los compradores creen en ella y conocen su valor (Icaza ya anuncia que Mono seguirá desarrollándose como antes). Veremos que tal les va a partir de ahora.

"cosas dichas por adelantado" 2006

No se han visto muchas predicciones por ahí, no tantas como solían verse otros años, predicciones de cosas que iban a pasar. En general siempre he pensado que las predicciones son una mierda, y que quienes las escriben son idiotas. Por eso yo no voy a predecir nada: En vez de eso, voy a decir cosas que van a pasar, que es ligeramente distinto.

• Gnome se centrará en Mono. Ahora que Fedora finalmente ha aceptado incluir mono, la pelea "mono vs java" se acabará resolviendo a favor de mono, no de forma oficial (C# no será un "lenguaje oficial" sino un binding muy usado). Gnome tiene miles y miles de lineas de código C suyos que cuesta hacer evolucionar un huevo y parte del otro. Con mono Icaza se dió cuenta - a buenas horas - que programar aplicaciones para escritorio en C es un disparate, asi que la única salida de Gnome es tirar de Mono. No por elección, sino porque es su única alternatica. Se harán buenas aplicaciones gracias a mono, y ese será el valor de Gnome.
• Las consecuencias de KDE 4 revolucionarán el mundo linux, dado que a día de hoy parece ser el único entorno de escritorio linux en desarrollo (no lo digo yo, sectores de gnome dicen que es posible que no haya un gnome 3.0 sino que se siga extendiendo 2.x, windowmaker está estancado en los 90, Enlightenment no quiere ir más allá de hacer un sistema de ventanas, y asi todos. Solo KDE mantiene en desarrollo verdaderamente activo sus pilares a día de hoy que yo sepa). Como consecuencia KDE seguirá teniendo una base tecnológica impresionante.
• LLVM se integrará en GCC y demostrará que es una idea mil veces mejor que las "máquinas virtuales" estilo java/C# (bueno, esta es más para el 2007)
• Se sabrán cosas sobre Mac OS X 10.5, y apple sacará algo análogo a edje/XAML
• Despues de que tras 30 años Apple haya empezado a saber vender de verdad y ayudado por la pérdida de valor de la API Win32 de Microsoft, las ventas de Macs incrementarán sus ventas de forma sustancial y convertirá a Apple en un jugador de más peso de lo que es hoy, y como consecuencia extenderán sus actividades a más campos.
• Como consecuencia de lo anterior, y de su lucha con google, y con IBM, y con Linux, y con Sony, y con Sun, y con Oracle, y con Openoffice, y con todo cristo, Microsoft no recuperará la posición que tuvo en los 90. Office 12 no le ayudará a mantener ese 30% de ingresos, la xbox 360 será eclipsada por la PS3, Linux seguirá evolucionando, Google seguirá jugando a lo suyo. Microsoft será víctima de las ansias de sus inversores y seguirá decayendo
• A pesar de todo, Windows Vista saldrá. Y a pesar de todo lo que le criticamos y del ridículo que han hecho estos últimos años y de que tendrá un monton de fallos y de cosas absurdas que nos harán seguir prefiriendo no tocarlo, tendrá sus saquito repleto de cosas buenas y dará en las narices - una vez más - a linux en el tema de escritorio.
• Se publicarán o al menos se oirán noticias sobre esas iniciativas que estaban surgiendo sobre la aplicación del concepto de bittorrent al streaming de video/audio (poder distribuir video a miles de personas sin tener una conexión de varios GB/s ni granjas de servidores). Si no existen algoritmos capaces de hacer que el streaming distribuido de video en tiempo real sea una realidad, esperaré 5-10 años a que las redes mejoren la latencia (el verdadero inconveniente creo yo) y lo volveré a predecir
• A alguien se le ocurrirá de una puñetera integrar bittorrent como sistema de descarga de paquetes de forma oficial. ¿Ubuntú, donde estás tú?
• Me aburriré y gracias a FUSE haré un "bittorrentfs" para montar sistemas de archivos remotos, en el que un "cat ~/sistemadearchivosremoto/archivo" hará que automaticamente un cliente bittorrent se ponga a descargarse el archivo de forma transparente. Montaré una distro que no esté basada en paquetes, en la que todo el software esté ya instalado por defecto pero que se baje automaticamente via bittorrent según se va necesitando (y se cachee localmente). Todo el mundo pensará que es una gran idea y todas las distros y sistemas operativos se rendirán a mis pies, me haré rico y mataré a Bill Gates
• Spam VOIP
• El DRM y las patentes seguirán avanzando.

Y esto es todo por hoy.