Mi caja actual tiene un pequeño fallo de diseño: el conector frontal de USBs está muy cerca de la salida de auriculares, por lo que no puedo conectar a la vez los cascos y mi reproductor de MP3 para grabar cosas en él. Sin embargo, un poco más separada está la conexión de micrófono, por lo que se me ocurrió hacer un par de puentes para que el sonido salga por ésta, y así no tener problemas. Llevaba tiempo queriendo hacerlo, pero hasta hoy no saqué ganas.

¿Y qué tiene que ver ésto con el título? Bueno, la última vez que usé un soldador para hacer alguna chapucilla propia fue hace casi dos años, cuando amplié la memoria de mi Z88, y es también la primera vez que lo uso desde que me independicé. Volver a cogerlo, aunque fuese para algo tan sencillo, ha sido realmente agradable. No te das cuenta de lo mucho que echas de menos hacer algo hasta que lo vuelves a hacer y disfrutas. Llevo tanto tiempo concentrado en mi trabajo y en mis proyectos de programación que tengo la electrónica completamente abandonada.

Después de ésto quiero hacer algún proyectillo nuevo, pero antes tengo que comprar una mesa adecuada. ¿Por qué no hay un Ikea cerca cuando lo necesitas?

Parece que no ha bastando con usar la versión del SVN de Mplayer/Mencoder para solucionar los problemas: al generar DVDs en formato PAL, en algunos casos lo hace en blanco y negro, amén de otros pequeños problemas.

Ante ésto he preferido curarme en salud y he retrocedido a la versión 0.99pre8; para ser más exactos, la que venía en Ubuntu Edgy. Dicha versión funcionó siempre razonablemente bien.

Para evitar más problemas de dependencias, he preferido empaquetar sólo los ejecutables en un tar.bz2, e incluir un script que sustituya los que ya haya en el sistema por los «nuevos». Esto lo hace, además, compatible con cualquier distribución, y no sólo con Ubuntu.

Actualización: por petición popular he añadido otro paquete con Mplayer/Mencoder para 64 bits.

Parafraseando a Germán Poo, la llegada de la nueva Ubuntu Feisty no es para montar una fiesta, precisamente. La razón es que la versión que trae de Mencoder (la 1.0-rc1, actual versión estable) tiene un fallo al codificar el sonido, con lo que DeVeDe es completamente inútil.

El bug lleva tiempo coleando, y la única solución en estos momentos parece ser utilizar la versión en desarrollo, sacada del SVN (en mi web, por despiste y costumbre, hablo de CVS. ¡Perdón, perdón!). Como una cosa es hacer un sudo ./install, que cualquiera lo hace, y otra muy distinta bajarse fuentes de un SVN y descubrir qué bibliotecas son necesarias para compilar un programa tan complejo como MPlayer/Mencoder, he decidido hacer yo mismo un paquete .deb con la versión del SVN del 14 de abril de 2007, compilada sobre Feisty, para que los usuarios no queden atados.

Comentaba en mi anterior entrada «¿Termoqué?» la dificultad que estaba teniendo para encontrar un disipador adecuado para mi nuevo equipo. Y no es para menos: paso mucho tiempo delante de la pantalla y lo último que quiero es una turbina de avión destrozándome el oído.

Después de muchas pruebas y mediciones (de tamaño: la nueva caja tiene un travesaño que limita la altura del disipador) me decanté por un Zalman CNPS8000. Este disipador tiene un tamaño adecuado para entrar en la caja y es muy silencioso (a baja velocidad, claro). El único defecto es que la regulación de velocidad es manual. Afortunadamente mi nueva placa es una ASUS con tecnología Q-Fan. Este sistema, propio de ASUS, permite a la BIOS controlar la velocidad de giro de cualquier ventilador (no tiene por qué tener cable de control de velocidad) en base a la temperatura de la CPU, exactamente igual que hacía mi viejo Artic Cooling. El resultado es justo el que quiero: trabajar con mi ordenador disfrutando en todo momento del máximo silencio posible, y sin tener que preocuparme de si el procesador se puede estar sobrecalentando.

Cuando era joven me gustaba jugar al UFO: Enemy Unknown. En él, tu misión consistía en defender a la tierra del ataque de diversas hordas alien, creando bases, investigando nuevas tecnologías, capturando naves y fabricando nuevas armas. El juego tenía dos modos: uno de pura estrategia, en el que se controlan las distintas bases y se decide qué temas se investigan, qué dispositivos se fabrican, qué nuevos soldados o científicos se contratan, etc. También es este modo se detectan los ovnis y otras amenazas y se pueden lanzar ataques contra ellos.

El otro modo, al que se pasa cada vez que se derriba un ovni o se llega a una ciudad atacada o base alienígena, está basado en un sistema de combate por turnos. En él debes localizar a todos los aliens que hay y matarlos o capturarlos. Si lo consigues, te haces con toda la tecnología que hayan dejado, la cual se puede investigar (para replicarla) o vender (para ganar más dinero).

El juego era endiabladamente bueno, y gracias a sus excelentes gráficos e increíble música conseguía sumergirte de lleno en la historia, así como hacerte dar más de un respingo cuando, en alguna fase de combate por turnos, aparecía de pronto uno de los aliens y atacaba a tus hombres.

Todo ésto viene a cuento porque hace tres días me reencontré UFO: Alien Invasion, un remake del UFO original basado en el motor gráfico del Quake 2. Ya lo había visto hace un año, pero de aquella sólo estaba lista la parte de las misiones de combate. Ahora, sin embargo, toda la mecánica de estrategia está lista también, así como la música, y sólo falta pulir algunos detalles, añadir la UFOpaedia (u OVNIpedia) e implementar el hilo conductor de la historia original. Estuve jugando estos días y el resultado no puede ser mejor.

En la página hay versiones para Windows y para Linux, estas últimas en forma de paquete .DEB (para Debian testing e inestable). En Ubuntu, en principio no se puede instalar porque el paquete depende de la libasound2 versión 1.0.12 o superior, mientras que Ubuntu dispone de la versión 1.0.11. Sin embargo, basta con bajarse la libasound de Debian (añadiendo también, si es necesaria, la libasound2-dev de Debian) e instalarlas con DPKG.

Hace unos días me pasaron un enlace a un libro titulado Designing analog chips. Este libro, disponible en formato PDF, fue escrito por Hans Camenzind. Para los que no le conozcan, diré que es el diseñador de uno de los más famosos cirtuitos integrados analógicos (situado justo después del amplificador operacional): el 555.

El libro comienza con una introducción teoría básica de los semiconductores y su funcionamiento en los principales componentes analógicos (diodo, transistor bipolar, FET…). A continuación entra de lleno en el tema de la simulación dedicándole un capítulo entero, y ya sin más dilación comienza a explicar los principales montajes analógicos: espejos de corriente, amplificadores operacionales, temporizadores…

Estoy empezando a leerlo con calma, pero después de echarle un ojo por encima debo reconocer que tiene una pinta impresionante. Lo más interesante es que se centra sobre todo en el aspecto práctico, y además mediante un lenguage muy asequible que lo hace todavía más interesante.

Creo que hace unos años habría matado por tener este libro, cuando me tuve que enfrentar a Dispositivos Electrónicos (1 y 2) y a Electrónica Analógica.

Llevo una temporada pensando en cambiarme de ordenador. A fin de cuentas, un Durón a 1’3GHz es algo que ya empieza a estar obsoleto. Por otro lado debo reconocer que en el fondo es un capricho, pues salvo porque los vídeos de YouTube van algo justitos, el resto me va perfectamente; por eso mi intención era no gastarme mucho dinero.

Decidí tirar por un Sempron 3000+, pues las últimas versiones tienen soporte de 64 bits y, al estar fabricados con tecnología de 90nm, disipan muy poco, y como soy un fanático del silencio es algo que me viene genial, pues eso significa menor velocidad en el ventilador del disipador. Por supuesto eso implicaba un ventilador termorregulado, similar al modelo de Artic Cooling que tengo ahora, el cual ajusta su velocidad automáticamente en función de la temperatura del procesador.

¡Cual sería mi sorpresa al encontrarme con que no hay disipadores termorregulados para AMD! Bueno, miento: supuestamente, los disipadores que vienen de fábrica con el propio procesador sí son termorregulados, de manera que al combinarlo con la tecnología Cool’n’Quiet se consigue una reducción efectiva del ruído. Pero los disipadores de terceros, como Zalman o Termaltake, parecen dividirse solamente en dos categorías: velocidad regulada manualmente (son disipadores muy poco más grandes de lo normal y que incluyen un potenciómetro para que ajustes tú mismo la velocidad) o «de bajo ruido» (disipadores gigantescos con ventiladores que funcionan a baja velocidad, pero siempre a la misma). No tienen ninguno termorregulado (o, al menos, yo no he encontrado ninguno).

Así pues, sólo tengo tres opciones, y todas tienen inconvenientes, en concreto:

• El disipador «de fábrica»: no se hasta qué punto será silencioso, sobre todo si tenemos en cuenta que algunas placas de Asus incorporan una tecnología que monitoriza la temperatura del procesador y baja aún más la velocidad del ventilador (bajándole el voltaje).
• El disipador de ajuste manual: ni de coña. En pleno siglo XXI no pienso ajustar yo mismo la velocidad cuando es algo que se puede hacer automáticamente y por muy poco dinero. Además, un elemento mecánico como un potenciómetro es mucho menos fiable que un componente 100% electrónico, como es un sensor de estado sólido.
• El disipador «de bajo ruido»: no sirve cualquier placa ni cualquier caja, pues pueden tener diámetros de hasta 15 cm y podrían tropezar con algún condensador. Además suelen pesar más de 600 gramos, cuando las especificaciones de AMD indican que el disipador no debería superar los 450 gramos; esto puede ser un problema al trasladar el equipo en un coche, por ejemplo.

Probablemente lo que haga sea probar el disipador «de fábrica», y si veo que no me convence ir a por uno «de bajo ruido».

Los Pentium 4, por su parte, han resuelto ésto de otra manera: según leí en Tom’s Hardware hace tiempo (lo siento, no tengo el enlace) las últimas versiones llevan ventiladores con cuatro hilos en lugar de tres, usándose el cuarto para controlar la velocidad de giro desde la propia placa (supongo que basándose en la temperatura medida por el sensor interno del procesador). De todas maneras, un Core Duo se sale de presupuesto, y un Prescott se calienta demasiado, así que será AMD.

Como habreis notado, la web, el blog y mi correo han estado caídos durante una semana entera por culpa de una mudanza de mi hoster. Afortunadamente parece que ya vuelve a funcionar todo, así que aprovecharé para sacar una copia de seguridad de las entradas (que los servidores los carga el diablo }:-)

Hace muchos años, cuando aún usaba regularmente mi querido Spectrum, conocí un juego que me impactó: Elite. El juego fue uno de los primeros -si no el primero- en usar gráficos en tres dimensiones para las partes del espacio. Por supuesto eran gráficos simples, formados únicamente por líneas, sin texturas en las caras, pero utilizaba un algoritmo (bastante simple) para borrar las caras posteriores, lo que producía la ilusión de que las naves y estaciones eran sólidas.

¿Y a qué viene ésto? Pues a que hace unos días encontré Oolite, un clon del Elite original escrito en Objective C y que utiliza OpenGL para la parte gráfica.

La mecánica del juego es la misma: comprar barato en una estación espacial, vender caro en otra, y en el viaje entre ambas defenderte de las naves que te ataquen, al más puro estilo arcade. Al igual que en el juego original también se puede vivir del contrabando, de la minería de asteroides, o directamente del saqueo. La gran diferencia, aparte de los gráficos mejorados, es que los enemigos son más listos que antes, y ahora, además, el universo ya no gira en torno a tí, sino que te puedes encontrar con grupos de mercaderes que van a su bola, policía galáctica más atenta a lo que les ocurre a otras naves, grupos organizados de piratas que lo mismo te atacan a tí como a otros…

El resultado es una gran recreación del juego original, pero actualizado a los nuevos tiempos. Aunque no es el primer intento: hace un año ya había encontrado Elite – The new kind. Este programa fue creado directamente a partir del código original del juego para el BBC modelo B, aunque luego se le añadieron algunas mejoras visuales, como por ejemplo gráficos con caras coloreadas, lo que hacía que las naves fuesen realmente sólidas. Sin embargo esa versión no me acabó de enganchar, en buena parte porque de aquella no tenía joystick, y controlar una nave como ésta desde teclado no es sencillo.

Hace unos días recibí un correo-e, proveniente de la mismísima oficina europea de patentes, en el que me preguntaban la fecha en la que lancé GAG 1.0 y, a ser posible, el código fuente de dicha versión para comprobar si se podía considerar arte previo de una patente que estaban examinando. La patente en cuestión es, nada más y nada menos, que la de un gestor de arranque gráfico.

Tras el acojone inicial rebusqué en mis viejos CDs y molesté a varios colegas por teléfono hasta que por fin encontré el mensaje original, fechado el 12 de mayo de 1999… o sea, ocho meses después de la fecha de presentación de la solicitud de patente. Afortunadamente recordé que un colega (hola David) había creado otro gestor de arranque gráfico anterior a GAG. Se trata de MBRMenu y la versión 2.0 se había publicado en marzo de 1998 (en su página no indicaba la fecha de la versión 1.0, pero con esa era suficiente).

Respondí al correo con toda esta información y pedí que me informasen del estado de la patente. Al día siguiente recibí una respuesta dándome las gracias y explicándome que el proceso aún llevaría algunos años más (?). Esa respuesta me chocó bastante: si la solicitud de patente se había hecho hacía siete años ¿cuantos más iban a tardar en concederla? Empecé a considerar que se tratase de una broma, pero no pude encontrar nada raro en la cabecera del mensaje (parece que realmente vino del dominio epo.org), y el dominio espacenet.com parece que está registrado a nombre de la EPO también; además, el texto de la patente no son dos hojas precisamente, y tiene bastante pinta de legal… si es una broma se la han currado mucho. Y además ¿una broma de quien?

Pocas horas después, a raíz de una noticia sobre el registro de arte previo que quiere montar el OSDL, leí un texto en el que Richard Stallman afirmaba que si un revisor de patentes considera que un trabajo determinado no es arte previo, en un posterior juicio de patentes los jueces suelen no aceptar dicho trabajo como posible prueba para anularla, aunque el revisor estuviese bebido (o presionado para aprobar la patente) ese día. Por desgracia me enteré de esto bastante después de responder el mensaje, lo que significa que, quizás, les he dado la patente en bandeja de plata.

Definitivamente las patentes de software son una locura. Tenemos que hacer lo que sea para impedir que se aprueben en Europa, o el software libre pasará a la historia.