Acabo de subir la versión 7.1 de ftp_bt4lxmedia, el paquete que incluye los clientes Transmission y bFTPd para discos multimedia basados en procesadores MIPSel. El cambio es que incluye la versión 2.13 de Transmission. Como de costumbre, se puede encontrar en la correspondiente sección de programas de mi página web.
A disfrutarlo con salud.
¡Ah, y feliz año nuevo a todos mis lectores!
Hace mucho tiempo, cuando empecé a programar en C, leí una curiosa advertencia sobre los operadores de desplazamiento de bits, los famosos >> y <<. Se afirmaba allí que, al desplazar una variable con ellos, los bits que salían se perdían (lógico, siendo un desplazamiento), pero que los bits que entraban por el lado opuesto tenían un valor indefinido, que podía ser cero o uno según la implementación.
Es cierto que todos los programadores asumen que lo que entra es cero siempre; pero pese a todo, yo, que tiendo a ser demasiado cauto, opté por añadir siempre una máscara AND para poner a cero los bits entrantes y así evitarme sorpresas.
Sin embargo, hace unos días, mientras optimizaba unas rutinas que hacen uso de desplazamientos, decidí investigar más a fondo el tema, porque a fin de cuentas una máscara consume ciclos de reloj, así que si había alguna forma de evitarla siempre sería una mejora. Y lo que descubrí me dejó gratamente sorprendido, porque en realidad el valor de los bits que entran no depende del compilador, sino que está perfectamente definido en el estándar.
Cuando se utiliza el desplazamiento hacia la izquierda (<<), por el lado derecho siempre entran ceros. Ahí nunca hay problemas. Por otro lado, cuando se utiliza el desplazamiento hacia la derecha (>>) en una variable sin signo (por ejemplo, en un unsigned int), por la izquierda también entran siempre ceros.
Sin embargo, cuando utilizamos variables con signo (por ejemplo, short int) en un desplazamiento hacia la derecha, los bits que entren por la izquierda serán una copia del bit de mayor peso del valor original. Así, si teníamos un número negativo (su bit de mayor peso está a uno), al desplazarlo hacia la derecha seguirá siendo negativo, porque los bits entrantes serán unos; en cambio, si era un número positivo (su bit de mayor peso está a cero) los bits entrantes serán cero.
Supongo que la razón de hacerlo así es que, si se utilizan rotaciones para hacer divisiones, se conserva el signo.
Este código ilustra perfectamente lo dicho aquí:
#include <stdio.h>
void desplaza(unsigned int o) {
signed int s1,s2;
unsigned int u1,u2;
s1=s2=u1=u2=o; // asignamos el mismo valor a las cuatro variables
s1>>=4; // desplazamos cuatro veces cada una de ellas
s2<<=4;
u1>>=4;
u2<<=4;
printf("Con signo:ntdesplazamiento a la derecha %08Xn",s1);
printf("tdesplazamiento a la izquierda %08Xn",s2);
printf("Sin signo:ntdesplazamiento a la derecha %08Xn",u1);
printf("tdesplazamiento a la izquierda %08Xnn",u2);
}
int main() {
printf("nDesplazamiento de 4 posiciones.n");
printf("Valor original: 0xA50000A5 (bit de mayor peso a uno).n");
desplaza(0xA50000A5);
printf("nValor original: 0x5A00005A (bit de mayor peso a cero).n");
desplaza(0x5A00005A);
return 0;
}
La salida es la siguiente, donde se aprecia claramente como el bit superior se replica en los desplazamientos a la derecha de las variables con signo, pero no en el resto de los casos:
Desplazamiento de 4 posiciones. Valor original: 0xA50000A5 (bit de mayor peso a uno). Con signo: desplazamiento a la derecha FA50000A desplazamiento a la izquierda 50000A50 Sin signo: desplazamiento a la derecha 0A50000A desplazamiento a la izquierda 50000A50 Valor original: 0x5A00005A (bit de mayor peso a cero). Con signo: desplazamiento a la derecha 05A00005 desplazamiento a la izquierda A00005A0 Sin signo: desplazamiento a la derecha 05A00005 desplazamiento a la izquierda A00005A0
Acabo de lanzar una nueva versión de FTP_BT4LXMedia. La gran novedad viene de la mano de CTransmission, un pequeño programa residente que gestiona las descargas, permitiendo limitar el número de ellas que estarán activas simultáneamente.
La razón de añadir este programa es que, debido a las limitaciones de memoria del media center, si se ponen varios ficheros a bajar de manera simultánea éste se satura, y la velocidad de descarga baja a valores ridículos. La solución consiste en bajarlos de uno en uno. Por desgracia, Transmission todavía no permite limitar el número de descargas simultáneas, por lo que he tenido que escribir este programa, que aprovecha las capacidades de control remoto para la tarea. Además, hace el mismo proceso para la subida: los activa de uno en uno hasta que alcanzan un ratio de compartición de 1.0, momento en que vuelve a repetir el ciclo hasta que todos tengan un ratio de 1.5; luego de 2.0, etc. Gracias a él, se pueden añadir todos los torrents que se deseen, y éstos se bajarán de manera ordenada y a la máxima velocidad posible.
Por supuesto, el programa es completamente configurable, y se pueden escoger otros límites mayores si se desea (en el caso del LX Media, lo óptimo es hacerlo de uno en uno, pero en otros equipos la cifra máxima puede ser mayor).
CTransmission es GPL, y se incluye el código fuente en el mismo paquete. Además, puede controlar clientes Transmission de manera remota, simplemente indicando su dirección IP y puerto.
Nueva versión del cliente Transmission (2.12) y de bFTPd (3.1) para los LX Media de MemUp. Como de costumbre, se puede descargar en mi sección de programas.
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.
Llevo una temporada sin publicar nada ni actualizar mis programas (sobre todo Devede) porque estoy bastante liado con un proyectillo nuevo, basado en OpenTom (que publicaré, espero, en un mes más o menos). Sin embargo, hace una semana se murió el disco duro de mi LX Media. Tras cambiarlo, decidí aprovechar para intentar mejorar el entorno de desarrollo que tenía para él, y tras mucho esfuerzo conseguí meter una Gentoo autónoma; esto es, ahora dispongo de portage en el disco, con lo que añadir nuevos paquetes es más sencillo. En unos días subiré el sistema completo.
Mientras tanto, ya podéis disfrutar con la nueva versión de FTP_BT4LXMedia, la 6.0, que incorpora la versión 2.10 de Transmission BitTorrent y la 3.0 de bFTPd, además de corregir un detallito de nada en la instalación. Como de costumbre, está en la sección Programas de mi página 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.
Cuando actualicé mi sistema a la nueva Ubuntu 10.04, ocurrió un detalle bastante molesto: el applet de sonido desapareció. Ni rastro. Probé a añadirlo desde la lista de applets y nada, no existía. Busqué con APT, instalé paquetes, y tampoco. Hasta que, finalmente, descubrí como recuperarlo.
Lo primero que necesitamos para que funcione el applet de sonido es tener en nuestra barra de tareas un área de notificación. Esta tiene esta forma:
Aquí vemos el área de notificación (que, en realidad está delimitada por esas tres rayitas de la izquierda), mostrando además el icono de conexión de red. Si no tenemos un área de notificación, basta con pulsar con el botón derecho en la barra, seleccionar Añadir al panel, hacer doble click en Area de notificación, y listo.
Si ya os aparece el icono de un altavoz, ya está todo hecho; pero si, como en la imagen de arriba, no aparece, eso es que os falta el applet en sí, en concreto el gnome-volume-control-applet. Dicho programa viene en el paquete gnome-media. Sin embargo, no es un applet a la antigua usanza, sino que es un demonio que utiliza el área de notificación para mostrarse. Si ya instalasteis el paquete y, desde una linea de comandos lanzáis dicho applet (con gnome-volume-control-applet & para que, al hacer un exit del terminal, siga en marcha), veréis que por fin aparece en control de volumen. Pero esa solución sólo sirve para esta sesión, y tan pronto se reinicie el equipo habrá que volver a lanzarlo. Para resolverlo vamos a hacer que se lance automáticamente cada vez que entremos en gnome. Vamos a Sistema -> Preferencias -> Aplicaciones al inicio, pulsamos Añadir, y rellenamos los campos con estos valores:
(obviamente, en el campo Orden hay que poner gnome-volume-control-applet; ahí está recortado). Una vez hecho esto, siempre que iniciemos tendremos, por fin, el applet del control de volumen, así de hermosote él.
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.