Estoy en proceso de migración a un nuevo servidor, por cortesía de StudioCero (muchas gracias, Pablo), así que en los próximos días, mientras el DNS se estabiliza, puede que haya algunos problemillas de acceso a la web y al blog.

Me acabo de levantar esta mañana con la noticia de que Dennis Ritchie, co-creador de Unix y del lenguage C, ha muerto.

D.E.P.

Mañana es la manifestación del 19J en contra del Pacto del Euro, la cual entronca directamente con la original del 15M. Para los que quieran ir, pueden buscar donde va a ser la de su ciudad en una de las muchas páginas que publican la información, como por ejemplo la de spanishrevolution. En Vigo será a las 18:00 horas desde la Plaza de España, aunque la gente de la acampada saldrá a las 17:30 desde la Plaza del Rey para unirse a esa hora con el resto.

Por último, una nota publicada en N-1 con una recomendación de protocolo de actuación en caso de violencia por parte de manifestantes. Es sólo una sugerencia, pero personalmente me parece perfecto.

Hace unos días subí el código de Devede a un repositorio en GitHUB para hacer accesibles de manera más rápida las correcciones que voy haciendo ante los bugs que reporta la gente. En estos momentos ya hay varias correcciones, alguna de ellas bastante importante pues permite utilizar Devede con las últimas versiones de Mencoder (que necesitan usar el modificador AC3_FIXED en lugar de AC3 a secas para que funcione el sonido), así como con las últimas versiones de DVDAuthor (necesitan que se defina una variable de entorno con el tipo de vídeo por defecto -PAL o NTSC-).

También empiezan a llegar parches para el código, que iré añadiendo progresivamente.

Ahora quiero añadir algún sistema para facilitar la traducción. Me han recomendado Pootle, pero no tengo muy claro que pueda añadir ahí un proyecto cualquiera. Se aceptan sugerencias.

Tras un aviso del autor de Gelide, he procedido a corregir un pequeño bug en los parámetros de línea de comandos de FBZX. Simplemente ocurría que, al activar la opción de double scan, sólo se podía desactivar desde el menú interno, quedándose activa incluso al salir y volver a entrar, además de no hacer caso al parámetro -ds. Ahora ya responde a él, y además incorpora el parámetro -ss para forzar el desactivar el double scan.

Una nueva versión de FTP_BT4LXMedia, en la que he actualizado a la versión 2.22 de Transmission.

Como muchos ya sabréis, el próximo año se retira definitivamente el transbordador espacial. Eso significa que casi no quedan oportunidades para poder verlo en vivo, por lo que hace una semana me lié la manta a la cabeza y me fui hasta Cabo Cañaveral para poder ver el lanzamiento del Discovery.

El lunes estuve en el centro turístico del Kenedy Space Center, donde tienen un montón de atracciones sobre el espacio. Por ejemplo, tienen varios cohetes de los utilizados en la carrera espacial tripulada: un atlas-mercury, un redstone-mercury, un titan-gemini, y un Saturno IB (el cohete con el que probaban los lanzamientos del Apolo). También tienen una réplica a tamaño natural del transbordador espacial y del tanque y los aceleradores laterales. Estoy harto de verlo en fotos, pero no es hasta que lo ves así, en «real», que te das cuenta del inmenso mamotreto que es. ¡Es gigantesco! Parece imposible que eso pueda planear, mucho menos subir para arriba.

En esta foto se ve el transbordador al fondo (es lo más cerca que nos podíamos acercar). Por desgracia está detrás de la Rotating Service Structure (desde donde se instala la carga útil). Esta parte de la torre se retira horas antes del lanzamiento, cuando ya no admiten turistas, por lo que no es posible sacar mejores fotos (al menos desde donde pude estar).

En esta otra foto, a la izquierda, está el Vertical Assembly Building, el edificio en donde se montaban los Saturno V y se ensambla el transbordador. A la derecha está la torre de lanzamiento del Ares, la cual, por desgracia, no va a utilizarse ya. Y por último, en primer plano, el crawler, que es el encargado de llevar sobre su lomo al transbordador desde el VAB hasta la zona de lanzamiento.

El plan original era lanzar el Discovery el mismo lunes, pero debido a una fuga en uno de los motores de maniobra orbital se pospuso el lanzamiento hasta el miércoles; volvió a retrasarse hasta el jueves por culpa de un fallo eléctrico en uno de los motores; el jueves hizo un día de perros, lo que obligó a moverlo hasta el viernes; finalmente, una fuga de hidrógeno durante el llenado del tanque principal hizo que se pospusiese toda la operación hasta el 30 de noviembre (e incluso es posible que se retrase hasta febrero del próximo año), con lo que, al final, me quedé sin fuegos artificiales 🙁

Pese a todo, ha sido una experiencia única, y tengo claro que quiero repetir. Y aún quedan dos lanzamientos como mínimo…

Acabo de subir la versión 2.11 de Transmission para el LX Media. Se puede encontrar, como de costumbre, en la sección Programas de mi web.

Hace unos meses, en plena discusión mundial sobre si el uso de Mono en Linux suponía un riesgo para el software libre o no, publiqué una entrada ofreciendo mi punto de vista. Sin embargo, lo que conté era sólo la mitad, porque en ese momento me pareció que no era adecuado echar más leña al fuego, así que decidí limitarme a la parte puramente técnica. Ahora que ya ha pasado un tiempo y las cosas están más calmadas he decidido escribir la segunda parte. Preparaos para un articulo de opinión, y encima largo.

Lo primero, decir que Mono, estrictamente hablando (esto es, la implementación libre de los estándares ECMA-334 y ECMA-335), no tiene por qué ser un problema para el software libre, gracias, principalmente, a la promesa de Microsoft de no ejercer esas patentes (vamos a pecar de confiados y, a pesar de no ser abogados, supondremos que realmente es universal, definitiva e irrevocable).

Sin embargo, el primer gran problema que encontramos es que esos dos estándares sólo cubren una parte de .NET, en concreto la máquina virtual, el lenguaje C# y la biblioteca estándar de dicho lenguaje. Pero .NET es mucho más que eso, porque está ASP.NET, ADO.NET y las WinForms, entre otros muchos componentes. Un argumento que esgrimen los defensores de Mono es que éste no pretende ser compatible con .NET hasta el punto de poder ejecutar todas sus aplicaciones (eso es sólo un efecto colateral), sino simplemente ser un entorno de desarrollo moderno para GNU/Linux, que aumente la productividad. Esto se puede ver perfectamente cuando leemos el Mono Rationale y algunas entrevistas a Miguel de Icaza: todo el énfasis lo ponen en el soporte de múltiples lenguajes y en la mejora del rendimiento en el desarrollo, pero no lamenta que no vaya a haber compatibilidad completa porque no hay nadie que se anime a escribir determinadas bibliotecas, sino que incluso recalca que hay muchos módulos específicos de Mono que permiten escribir programas que no funcionarían en .NET.

¿Y qué problema hay, entonces, en utilizar un entorno de desarrollo basado en dichos estándares, y completándolos con herramientas y bibliotecas libres (como GTK#, por ejemplo) para rellenar los huecos que faltan, y sin buscar compatibilidad con el .NET de Windows? Personalmente tiendo a alinearme con la gente que defiende que no hay ninguno (aunque me remito a las razones técnicas que esgrimo en mi anterior entrada): por una parte el riesgo de patentes es prácticamente nulo, porque Microsoft se ha comprometido a no atacar con ninguna de ellas (aunque pienso que la razón es que, estratégicamente, sería peor para ella); y por otro lado, aunque .NET avance demasiado rápido para mantenerse a la par (cosa que ni siquiera hoy en día se está consiguiendo con Mono) o si Microsoft cambiase las APIs creando problemas de compatibilidad, tampoco sería un problema porque el objetivo no es ser compatibles con ellos.

Pero…

Obviamente hay un pero, porque si no, el título de este post no tendría ningún sentido. Ese pero surge del hecho de que la misma existencia de .NET, tan abierto, tan estandarizado, tan portable, no parece tener sentido viniendo de una empresa que ha monopolizado la web durante años, que ha intentado poner trabas al software libre mediante tácticas cuanto menos discutibles, y que ha sido acusada de mantener una posición de monopolio en el mercado de los sistemas operativos y navegadores. ¿Por qué sacar un producto que puede beneficiar tanto a tu rival, y además darle tantas facilidades, cuando tu historial habla siempre de acciones totalmente opuestas? ¿Se está regenerando Microsoft?

La respuesta, en mi opinión, está en Silverlight: Microsoft perdió el control que tenía sobre la web y ahora quiere recuperarlo, pero la gran cantidad de navegadores disponibles hoy en día, así como la sensibilización que hay hacia el uso de estándares, le impide repetir la táctica de añadir sus propias extensiones a HTML. Por otro lado están Java y Adobe Flash. El primero, a nivel web, está hoy de capa caída, aunque intenta recuperar el terreno mediante JavaFX. El segundo es un peso pesado, pero está perdiendo terreno gracias a HTML5 y al peso de la comunidad, que intenta incentivar el uso de estándares. Y es justo aquí donde Microsoft intenta atacar con Silverlight: crea un nuevo plugin para que los desarrolladores hagan lo que hacían con Flash, pero con la ventaja de que es tecnología basada en .NET, lo que significa que se puede reutilizar código de otras aplicaciones aunque no sean aplicaciones web (cosa imposible con HTML5); es una plataforma agnóstica respecto al sistema operativo y a la arquitectura gracias al uso de una máquina virtual (igual que Java y Flash), y encima se basa en estándares abiertos (ECMA-334 y ECMA-335), lo que permite a terceros hacer implementaciones propias, como por ejemplo Moonlight, que se basa, como no, en Mono.

¿Y donde está el problema? Pues en que Silverlight no está dentro de ningún estándar. Como dije al principio, los dos estándares ECMA cubren únicamente el lenguaje C# y su biblioteca estándar, así como la máquina virtual, pero todas las bibliotecas específicas de Silverlight están fuera, por lo que Microsoft tiene libertad absoluta para cambiarlas y ampliarlas a su antojo.

Con esto echamos por tierra el principio de que no importa que cambie la especificación porque la compatibilidad no es un objetivo: si Mono no es 100% compatible con .NET, Moonlight no lo será con Silverlight y no servirá para nada. Y si hay que garantizar la compatibilidad, el software libre siempre irá a remolque, y a buena distancia, de Microsoft, por lo que la gente se verá obligada a utilizar la máquina de .NET, pues Mono y Moonlight no implementarán todo lo necesario (y la especificación se mantendrá en continuo aumento). Para aquellos que piensen que exagero, me remito a los diversos clones de Flash que se han intentado hacer en el mundo del software libre: ninguno funciona lo suficientemente bien como para reemplazar sin problemas al plugin oficial de Adobe. Y que no se me interprete mal: hay un gran trabajo detrás de todos ellos; simplemente es una tarea muy grande sobre un blanco muy móvil.

Hace tiempo ya nos topamos con el primer aviso cuando el SIGPAC se pasó a Silverlight: la respuesta de los creadores comenzaba diciendo que los datos ya están disponibles en formato WMS, que es un estándar para acceso a información cartográfica, aunque sí se puede alegar que no son los datos, sino el servicio, el que también debería ser accesible desde cualquier sistema operativo. A continuación, añadía que la versión en Silverlight es accesible desde multitud de sistemas operativos, incluido Linux, gracias a Moonlight, aunque luego aclaraba que, en este último caso, se conocían algunos problemas porque el SIGPAC necesita la versión 3 de Silverlight, y Moonlight implementa sólo la versión 2. Cinco meses después sólo hay una versión preliminar de la 3, todavía en fase alfa, mientras que Silverlight ya va por la versión 4: el software libre siempre irá a remolque si la especificación depende de una única empresa en lugar de ser un estándar oficial.

Lo mismo ocurre con los mundiales de fútbol en Telecinco: para verlos necesitas Silverlight, y Moonlight todavía no sirve (aunque la versión alfa de la 3.0 parece que sí lo soporta, pues en la página oficial dice textualmente: “With Moonlight you can watch the Olympics on Linux with our 3.0 preview”). Por otro lado, vemos que también quiere integrarlo en televisores y otros dispositivos, lo que parece indicar ya la estrategia de Microsoft: meter Silverlight en todos los ámbitos que pueda.

Y si alguien aún se pregunta qué gana Microsoft consiguiendo que todo el mundo utilice una plataforma que se consigue gratis o de la que cualquiera puede crear una versión alternativa (aunque siempre vaya a remolque de la oficial), la respuesta (aparte de vender más herramientas de desarrollo y de que, como su versión será siempre la más avanzada y sólo la hay para windows, se asegura de que windows se utilice más, que ya es bastante) es que tiene el poder de forzar el uso de otras tecnologías en las que colabora, muchas de ellas de pago. Por poner un ejemplo, Microsoft forma parte del MPEG-LA, que cobra los royalties por el uso de H.264, codec de vídeo que se utiliza en Silverlight para realizar streaming. Al ser Silverlight su tecnología, ellos deciden qué entra y qué no, pudiendo eliminar a la competencia (por ejemplo, a Theora o a WebM) y ganando ellos dinero con las licencias de esas tecnologías. De hecho, la licencia de Microsoft por la que promete no perseguir implementaciones libres de Silverlight excluye expresamente el pago de royalties por codecs patentados. Por otro lado, que actualmente sea gratis no significa que, en el futuro (cuando esté extendido y sea casi obligatorio integrarlo si quieres vender), no haya que pagar por poner Silverlight en el último modelo de televisor.

Y esto es lo realmente peligroso para el software libre, pues no solo iremos siempre a remolque de la implementación privativa, sino que, en muchos casos, podremos vernos completamente atados (baste ver los problemas que tiene Debian o la Mozilla Foundation para incluir algunos codecs de serie en países con patentes de software).

Por todo esto, aunque no rechacemos a Mono en sí, creo que sí deberíamos rechazar con todas nuestras fuerzas a Silverlight y a Moonlight, y exigir que se utilicen únicamente estándares abiertos como HTML5 para realizar las páginas web, en lugar de sistemas privativos controlados por empresas. Precisamente ahora que tenemos las herramientas necesarias para ganar la batalla a Flash no debemos cometer el error de caer en un nuevo plugin privativo.

O esa es, al menos, mi opinión.

Acabo de actualizar a la versión 3.0 de wordpress, y aprovecharé para ver si ya han corregido el bug que hacía que cada vez que intentaba publicar algo, fallase, y tuviese que ir a los borradores y publicar desde ahí…

[Actualizado] Pues sí, ya funciona.