DeVeDe again

Tras casi diez días de espera, hoy llegó la última traducción pendiente para la nueva versión de DeVeDe. Los cambios son más bien pequeños (ya llegarán los grandes en la próxima):

El primero es soportar caracteres HTML (<, >, & …) en los nombres de fichero. Hasta ahora no expandía dichos caracteres en los ficheros XML que se usan en DVDAuthor, por lo que daba un error al intentar usar un fichero que contuviese uno de ellos en su nombre.

El segundo es no mostrar la previsualización de la imagen de fondo de menú cuando se escoge un directorio. Esto ha sido necesario para que el programa no se cuelgue al escoger un directorio o un fichero que no es una imagen en la ventana de selección de fondo para el menú del DVD.

El tercero, muy reclamado por los usuarios, consiste en comprobar si existe algún archivo o directorio con el mismo nombre que la imagen ISO (o algún fichero temporal) que se va a crear, en cuyo caso pregunta antes de borrarlo. Yo siempre di por supuesto que la gente no pondría un nombre igual a algo que ya existiese en el directorio final, pero no ha sido así. Dado que DeVeDe tiene que crear, al menos, una carpeta con el nombre genérico (para DVDAuthor) y otros archivos (XML, MPEG, etc) temporales, las probabilidades de colisión son muy grandes. Para resolverlo he decidido que se cree primero una carpeta con el nombre genérico, y meter dentro absolutamente todos los archivos que se generen. Y, por supuesto, preguntar antes en caso de que dicha carpeta exista.

El cuarto y último es una petición que viene de muy antiguo: rehacer la pantalla de selección de tipo de disco. Mucha gente se quejaba de que era muy fea y poco profesional. La he cambiado por un diseño que Jonathan Estrella subió a gnome-look.

Como viene siendo costumbre, está disponible en TAR.BZ2 y en DEB.

Caprichos

No, ni estoy embarazado ni me he aficionado a la música clásica. Simplemente me he comprado un Asus EEE PC, en concreto el modelo 1000H. Las razones para ir por éste y no otro han sido:

  • Tamaño del ordenador: llevaba tiempo queriendo comprarme un portátil, pero los tremendos tamaños de los modelos de 15 pulgadas me echaban para atrás. A fin de cuentas, para trabajo serio ya tengo el equipo de sobremesa. Yo lo que quería era un equipo pequeño y manejable, fácil de llevar por ahí; no un mamotreto.
  • Tamaño de teclado: aunque los modelos 701 y 901 son más pequeños que el modelo 1000, el teclado es demasiado pequeño, y no es cómodo teclear (y menos cuando tienes los dedos como morcillas). Estuve a punto de tirar por un Acer Aspire One, precisamente porque, al medir dos centímetros más de ancho, tiene un teclado perfecto, pero fue entonces cuando Asus sacó el modelo 1000.
  • Batería de seis celdas: el resto de miniportátiles tienen baterías de tres celdas, con lo que la autonomía es menor. Yo quería que la batería me durase algo más, cosa que me ofrecía este modelo.
  • Disco duro de 160GB: es cierto que es mecánico; pero a fin de cuentas, mi intención es usarlo como portátil, así que nunca está de más tener espacio extra.
  • 1 GB de memoria.
  • Pantalla de 10 pulgadas: ¿quien le hace ascos a una pulgada extra? 😉
  • Soporte garantizado de Linux: hace más de nueve años que abandoné oficialmente Windows, no voy a volver a estas alturas.

Y precisamente este último es el tema central de esta entrada. Y es que, aunque el hardware está soportado en Linux, no lo está en la versión oficial de la mayoría de las distribuciones, sino que hay que meter algún que otro driver aparte para que todo funcione (fundamentalmente partes del ACPI, y los botones específicos del equipo). Pero como en el mundo del software libre siempre hay un roto para un descosido, ya hay gente que ha empaquetado todo de manera fácil.

Alguno dirá: Pero si el equipo ya trae Linux ¿qué problema hay? Bueno, en realidad hay dos problemas: por un lado, los equipos que traen Linux traen Limpus, y parece ser que una versión algo antigua, y puede ser deseable meter una más reciente o con otra interfaz más clásica. Por otro lado, el modelo 1000H trae Windows XP, por lo que es fundamental poder meter otra cosa.

Tras buscar por Internet encontré Ubuntu-EEE (renombrada al curioso nombre de EasyPeasy), que es una versión de Ubuntu para miniportátiles. Por desgracia está pensada para los equipos con 512MBytes de memoria, por lo que la interfaz de usuario que trae es bastante simplona. Además, cuando la probé sólo había versión basada en Ubuntu 8.04.

Entonces seguí buscando y encontré entonces EEEbuntu, otra distribución basada en Ubuntu para miniportátiles. Lo interesante es que hay tres versiones: una básica, con lo mínimo para funcionar; una mini, similar a Ubuntu-EEE, y otra completa, con el escritorio clásico de Gnome. Esta última fue la que probé, pero le hicieron varios cambios al escritorio y tampoco me gustaba. Yo quería una Ubuntu como la de mi equipo de sobremesa.

Entonces fue cuando descubrí que ambas distribuciones estaban basadas en un mismo proyecto de núcleo Linux para miniportátiles Asus: el kernel Array. Este trae todo lo necesario para funcionar en cualquiera de los EEE PCs, pero además se integra directamente con la Ubuntu clásica, por lo que era justo lo que buscaba.

La manera de instalarlo es sencilla: se baja la ISO de Ubuntu 8.10, y se utiliza la opción «Create a USB startup disk» del menú de Sistema->Administración para copiarla a una memoria USB. Una vez copiada, se conecta dicha memoria al EEE PC y, al encenderlo, se escoge arrancar desde USB (pulsando ESC), procediendo a instalarla en disco duro como siempre.

Una vez que tenemos una Ubuntu normal, vamos a la página de instalación del kernel Array y seguimos los pasos desde una terminal, y listo.

Retocando

Dos nuevas versiones con pequeños cambios.

El primer programa modificado es FBZX. Me había puesto en contacto con el mantenedor de la página de FBZX en Launchpad  para que actualizase la información, y resultó que era un viejo usuario que ya me había hecho un montón de buenas sugerencias, y como no podía ser de otra manera, me hizo dos más: por un lado, un nuevo icono, y por otro lado, utilizar las imágenes ROM en el mismo formato y directorios que el resto de emuladores.

En efecto, FBZX tenía las imágenes en un sólo fichero por modelo (una imagen de 16Kbytes para el Spectrum original, una imagen de 32Kbytes para cada uno de los modelos de 128K «clásicos», y una imagen de 64KBytes para el +2A/+3). Sin embargo, el resto de emuladores usan ficheros de 16Kbytes, dividiendo las imágenes en varios ficheros, cada uno con una página.

La razón de hacerlo así es que, de esta forma, no hay que duplicar los ficheros en distribuciones como Debian, en donde éstos están en un paquete separado: SPECTRUM-ROMS. Así, además, se eliminan de un plumazo muchos líos de licencias, porque el paquete FBZX será 100% GPLv3, y el código propiedad de Amstrad estará claramente separado en un paquete distinto, con sus condiciones de distribución bien claras.

El otro programa modificado es mi viejo Z88Transfer. El cambio fundamental es que ahora ya permite transferir ficheros binarios al Z88 en windows. La razón de que fallase es que, por costumbre, abría los ficheros de disco sin forzar modo binario porque en Linux da igual (siempre los abre en binario). Por desgracia en Windows ésto no es así, sino que si no se especifica el modo binario lo abre en modo ASCII, con lo que si aparece un byte 26 creerá que ha llegado al final de fichero y parará.

Otro fallo corregido es que ahora permite enviar ficheros cuyo nombre contenga mayúsculas: por un fallo, convertía el nombre de fichero siempre a minúsculas, con lo que en sistemas de archivos que distinguen unas de otras (como por ejemplo, EXT3), si el nombre tenía alguna mayúscula daría error.

Otro cambio importante es que ahora también permite enviar ficheros que contengan un guión en su nombre, y que controla mejor qué nombres son válidos para el Z88 (en base a la longitud del nombre, de la extensión, etc).

Por último, no muestra los ficheros cuyo nombre termina en ~. Estos ficheros suelen ser copias temporales de ficheros, y de hecho buena parte de los navegadores de ficheros los ocultan por defecto (así tenía la carpeta DESKTOP llena de ellos sin saberlo).

A disfrutarlo con salud. Ah, y que tengais una feliz newtondad y porrompompero año nuevo 🙂

!Libre!

Después de cinco años de vida, FBZX por fin es totalmente libre. Efectivamente, cuando escribí mi emulador de Spectrum, había intentado sin éxito escribir también el emulador de Z80. Por desgracia la tarea era muy pesada (sobre todo por repetitiva y propensa a errores), así que al final decidí usar uno hecho por un programador llamado Marat Fayzullin.

Por desgracia había un serio inconveniente: las condiciones de uso de este código eran incompatibles con la GPL (y mucho). Esta situación nunca me agradó demasiado, pero dado que escribir desde cero y depurar un emulador de un procesador era una tarea demasiado árdua, al igual que intentar adaptar el código de FBZX a otro emulador de Z80 diferente, lo fuí dejando de lado durante años.

Así estuvo la cosa hasta que hace un mes, más o menos, recibí un mensaje de un empaquetador de ArchLinux que se encontró con el problema: en efecto, no podía seguir manteniendo el emulador en el repositorio por culpa de la incompatibilidad de licencias.

Ante ésto decidí que ya era hora de tomar cartas en el asunto, así que me puse a escribir un emulador desde cero. Sin embargo, tenía claro que no podía limitarme a teclear largas listas de sentencias CASE XX:, sino que tenía que emplear una aproximación más inteligente si quería hacerlo en un tiempo razonable y con unas mínimas garantías de éxito. Así, se me ocurrió que podía partir de una lista de opcodes de Z80, la cual podría parsearse con un pequeño programa que generaría por mí el código en C. En efecto, partiendo de una lista como:

LD A,B
LD A,C
LD A,(HL)
CP (HL)

es posible separar el comando (LD, CP…) de los parámetros (A, B, C, (HL)), y generar automáticamente código que realice las operaciones. De esta forma sólo tuve que escribir una vez el código que implementase la lectura y escritura de cada uno de los 51 posibles parámetros, la comprobación de las 8 posibles condiciones, y el funcionamiento de cada uno de los 81 comandos diferentes, y dejar que el parser se encargase de generar los 1792 opcodes posibles que puede ejecutar el Z80. Además, una ventaja extra es que cualquier error que cometiese sería más fácil de corregir, porque sólo tendría que hacerlo en el parser, y automáticamente se arreglarían todas las instrucciones afectadas.

El resultado es que he necesitado tan sólo unas cuarenta horas netas, repartidas en tres semanas, para escribir desde cero un emulador de Z80 plenamente funcional, y que, además, emula el juego completo de instrucciones del Z80, tanto las oficiales como las no oficiales. Y gracias a él, FBZX ya es completamente libre.

Dado que la idea del parser puede ser útil para hacer otros emuladores diferentes, he tenido especial cuidado en escribirlo de manera que se pueda cambiar fácilmente la lista de comandos, parámetros, etc, y así poder adaptarlo a otros procesadores como el 6502, el 6800, ARM…

Otros cambios

Aprovechando la nueva versión, también añadí soporte para sonido mediante los controladores ALSA, y la emulación del Spectrum 128K español (el original de Investrónica y Sinclair Research). Además, también almacena el nivel de volumen que se está usando, de manera que no haya que ajustarlo cada vez que se ejecute el programa de nuevo. Por último, he cambiado la licencia a la GPLv3.

SuperShow

También aproveché para sacar una pequeña revisión de SuperShow. El único cambio que hice fue traducir las variables de la plantilla que se usa para generar los scripts de Flash, de manera que si alguien que no hable castellano quiere mejorarla, lo tendrá más fácil.

La nueva Ubuntu y mi viejo ratón

(Actualizado 2. Ver al final del artículo) Ayer actualicé mi sistema a la nueva Ubuntu 8.10 y me encontré con el primer problema: mi ratón empezó a funcionar correctamente.

Para explicarlo un poco mejor: mi ratón tiene un total de siete botones: los dos de siempre, el central en la rueda, y dos extra en el pulgar. La rueda, además, se puede mover a derecha e izquierda: dos botones más. Hasta ahora Ubuntu (o más concretamente, las X-Windows) no reconocían los botones extra, y los interpretaba como si fuesen el botón central, lo que para mí era muy cómodo. En efecto, si uso el botón central de la rueda para pegar texto o abrir un enlace de Firefox en una nueva pestaña, es raro que no se me mueva algo y acabe pinchando donde no quiero, problema que resuelvo usando el botón del pulgar.

Por desgracia la nueva versión utiliza HAL para detectar y gestionar el ratón, y éste sí reconoce los nuevos botones, con lo que el botón del pulgar ahora me lleva a la página anterior cada vez que lo pulso.

Por suerte el nuevo sistema también permite reconfigurar el sistema con más comodidad, y lo que es más interesante, sin necesidad de reiniciar las X, sino simplemente desenchufando y volviendo a enchufar el ratón. La manera es mediante unos ficheros XML (con extensión .fdi ) almacenados en /etc/hal/fdi/policy. Estos ficheros permiten modificar y personalizar completamente el funcionamiento de cualquier dispositivo, aunque la documentación es algo confusa.

Para los impacientes, la solución es tan simple como crear un fichero cualquiera en ese directorio (por ejemplo, /etc/hal/fdi/policy/mouse.fdi ) que contenga las siguientes lineas:

<device>
    <match key="info.capabilities" contains="input.mouse">
        <merge key="input.x11_options.ButtonMapping" type="string">1 2 3 4 5 6 7 2 2</merge>
    </match>
</device>

Para los que quieran personalizarlo más, la asignación de eventos es:

  1. Botón izquierdo
  2. Botón central
  3. Botón derecho
  4. Rueda arriba
  5. Rueda abajo
  6. Rueda izquierda
  7. Rueda derecha
  8. Página anterior (en un navegador)
  9. Página siguiente (en un navegador)

En el fichero anterior lo que hago es especificar que los eventos 8 y 9 deben responder como un evento 2, mientras que los demás permanecen inalterados.

Actualización: modifiqué el fichero FDI para que filtre los dispositivos, quedándose sólo con los ratones (tag match).

Actualización 2: Por desgracia la solución no sirve porque sólo funciona cuando primero se cargan las X y luego el módulo del ratón (por ejemplo, al desenchufarlo y volverlo a enchufar con las X ya cargadas). Cuando se arranca el ordenador desde cero, como se carga primero el módulo USB y luego las X, no hace nada.

La solución, al final, es más sencilla:

  • Se crea un fichero .Xmodmap en el directorio del usuario, que contenga la línea pointer = 1 8 3 4 5 6 7 2
  • Se sale de las X y se vuelve a entrar
  • Preguntará si se quiere utilizar un fichero Xmodmap, y mostrará la lista de los que ha encontrado (estará el que acabamos de crear)
  • Lo seleccionamos y lo añadimos a la lista de activos, y nos aseguramos de marcar la opción «No volver a preguntar».

Y con esto sí se resolverá el problema. El único defecto es que no se pueden repetir eventos, por lo que tuve que, simplemente, invertir los eventos 2 y 8, en lugar de asignar el 2 a todos los que me interesaba. Pero menos da una piedra…

Bailando Samba

En el trabajo han montado un servidor windows para compartir ficheros e impresoras, y como la mayoría de los servidores de este tipo, utiliza el protocolo SMB de Microsoft.

Acceder a estos servicios desde Linux parecía tan sencillo como abrir Lugares->Red y navegar gracias a SAMBA; pero, como de costumbre, las cosas nunca son tan sencillas. En efecto, el firewall que utilizo no me dejaba acceder, así que tras rebuscar en Internet encontré que tenía que abrir los puertos 135, 137, 138, 139 y 445. Me parecía extraño que, queriendo trabajar sólo como cliente (sin compartir yo nada) tuviese que abrir puertos, pero de todas formas lo probé. El resultado: ni con esas funcionaba, aunque si quitaba el firewall entonces iba como la seda.

Bastante mosqueado volví a buscar en Internet, pero no encontré absolutamente nada, así que me armé de paciencia y de Wireshark y empecé a ver qué demonios pasaba con los paquetes. Así fue como descubrí que el problema estaba en la resolución de nombres. En efecto, cuando un recurso no está en el DNS (un servidor, una impresora), SAMBA utiliza su propio servicio para descubrir su dirección IP, para lo que envía una petición UDP a toda la red usando la dirección de broadcast. El problema es que la respuesta no viene de la dirección de broadcast, sino de un equipo concreto (el buscado), por lo que el firewall la bloquea.

Pensando que era un bug del módulo ip_conntrack escribí a los desarrolladores para avisarles. Su respuesta, sin embargo, fue que cargase el módulo nf_conntrack_netbios_ns. Y efectivamente, con dicho módulo, y sin necesidad de abrir ningún puerto, todo ha funcionado perfectamente.

Lapsus linguae

Acabo de lanzar la versión 3.11b de DeVeDe que corrige un par de fallos en las locales EL, SV, SK y PL. En las dos primeras el fallo impedía que se mostrasen los iconos en los botones; en la tercera una frase no aparecía en negrita; y en la cuarta, la más grave, directamente no arrancaba el programa.

También actualicé el paquete DEB, como debe ser, y añadí una respuesta extra en la FAQ sobre como hacer DVDs sin menú.

Esguince cervical

Como ya habreis leído, sufrí hace unos meses un esguince cervical por culpa del clásico «alcance por detrás». Después de todo este tiempo he aprendido bastantes cosas, y creo que no está de más compartirlas porque pueden ayudar a mitigar las molestias de, o incluso evitar, el esguince cervical.

¿Qué es un esguince cervical?

El esguince cervical se produce cuando, por culpa de un impulso brusco, la cabeza se mueve violentamente, generalmente adelante y atrás. El caso más habitual es cuando estás en el coche, parado, y alguien te embiste por detrás: la espalda está perfectamente apoyada en el respaldo, pero la cabeza suele estar suelta, sin apoyarse en nada. Además, al no prever el golpe, los músculos del cuello están relajados, con lo que, en el breve instante que dura el golpe no les da tiempo a tensarse y sujetar convenientemente la cabeza.

¿Como puedo prevenirlo?

Dado que no conducir no es una opción, es importante entonces buscar la manera de prevenir en la medida de lo posible los resultados de un alcance por detrás. Lo ideal sería comprar un coche que obtuviese una buena puntuación en las pruebas específicas de alcance por detrás. Por desgracia, si vemos las tablas de los test del International Insurance Whiplash Prevention Group, vemos que en 2005 (cuando me compré el mío) menos de la mitad consiguen una puntuación buena o aceptable. En 2008, afortunadamente, la cifra sube a algo más de la mitad, pero aún así sigue siendo, bajo mi punto de vista, escandaloso. Normalmente el diseño del asiento y el reposacabezas es fundamental para conseguir una buena protección, pero parece que los fabricantes no se preocupan demasiado, salvo los de gama alta. Y uno no siempre se puede permitir un coche así (no es sólo comprarlo, sino también mantenerlo: un Audi no lo dejo durmiendo en la calle ni harto de vino).

Una vez que ya tenemos un coche, bueno o malo, es fundamental ajustar correctamente el asiento y el reposacabezas. Por muy bueno que sea el sistema, si está mal ajustado no servirá para nada. La idea es que, en caso de alcance por detrás, impida que la cabeza se mueva violentamente, sirviendo de apoyo y haciendo que siga el movimiento del resto del cuerpo. Para ello es necesario que esté ajustado en altura para que su parte superior quede igualada con la parte superior de nuestra cabeza, y (muy importante) en distancia, de manera que quede, como mucho, a cuatro centímetros de nuestra cabeza. Y, como la colonia, mejor cuanto más cerca.

Y es aquí en donde la gran mayoría de coches fallan estrepitosamente. En mi caso me compré un Citroen C2 porque quería un coche pequeño y  manejable, que pudiese aparcar con facilidad en cualquier hueco. Pero si echamos un vistazo a los resultados de la tabla vemos que son desastrosos: obtiene la peor puntuación posible. Parte de la culpa se debe a que no hay manera de ajustar el reposacabezas en sentido horizontal; sólo se puede subir y bajar; y la otra a que el respaldo tiene una forma… digamos que singular: si ajusto la inclinación del respaldo para sentarme cómodo, el reposacabezas queda a unos diez centímetros de mi cabeza. La única forma de que se acerque es echando el respaldo hacia adelante; pero en ese caso la zona lumbar queda separada casi diez centímetros, y no hay quien aguante más de cinco minutos parado (no digamos ya conducir), porque sólo apoyas los hombros en el respaldo. Ya mucho antes del accidente me había hartado de probar combinaciones y no hubo manera de conseguir que el reposacabezas quedase en una posición adecuada. Los asientos tienen una forma muy extraña. A veces me pregunto si los fabricantes llegan a probar sus propios vehículos.

Tras el accidente empecé a buscar y encontré dos posibles soluciones al problema: la primera, un añadido acolchado para el reposacabezas (disponible en tiendas de complementos para el coche). Este reduce la distancia lo suficiente como para poder apoyar cómodamente la cabeza en cualquier momento.

La segunda solución es un soporte lumbar. Se coloca en la zona de los riñones y la separa del asiento, haciendo la postura más cómoda y permitiendo, en mi caso, que toda la espalda se apoye cuando se pone el respaldo en la postura necesaria para que la cabeza quede a una distancia razonable del reposacabezas, manteniendo la curvatura natural de la columna.

Al principio el añadido del reposacabezas me parecía la opción más cómoda, pero después de probar bien el soporte lumbar (y, sobre todo, de ponerlo bien: no tiene que estar abajo del todo, sino a un par de centímetros de altura) me he decantado definitivamente por él, porque es más cómodo. El añadido del reposacabezas lo pasé al asiento del acompañante para que proteja cuando lleve a alguien.

Lo que más me molesta es que no parece haber ninguna solución oficial por parte de Citroen. He preguntado en concesionarios y talleres y la respuesta es siempre la misma: los asientos son así y no hay nada que cambiar.

DeVeDe 3.11

Acabo de lanzar una nueva revisión de DeVeDe, la 3.11. Los cambios en sí son pocos, aunque necesarios, por tratarse de algunas correcciones.

El primer cambio importante es de apariencia: en efecto, hubo varias quejas en la zona de comentarios de GnomeFiles sobre ella, y me dieron varias sugerencias interesantes, entre ellas limitar el tamaño vertical de las ventanas para que se pueda utilizar cómodamente en equipos con resolución vertical de 800 pixels (como muchos ultraportátiles).

Otro cambio es que ahora puede trabajar indistintamente con mkisofs o genisoimage, con lo que no habrá problemas para usarlo en el futuro en el caso de que alguna distribución se niegue a instalar el primero o hacer un enlace al segundo (para los que no sepan de qué va la movida: el autor de mkisofs cambió la licencia de algunas partes a CDDL, que es incompatible con la GPL, ante lo que la gente de Debian decidió coger la última versión GPL y hacer un fork). Esta corrección la he extendido al paquete DEB, en donde exijo uno cualquiera de los dos paquetes para que funcione.

Respecto a la corrección de errores, el primero es limitar el número de archivos que se pueden añadir a un DVD a 61. En efecto: el estándar de DVD sólo permite un máximo de 128 comandos en cada título. Dado que el código que añado necesita dos comandos por cada fichero que se añada, además de 6 comandos extra para inicialización, ese es el número máximo que se puede meter. En el futuro espero poder cambiar el sistema para elevar el máximo a 99 archivos, igual que en VCD, sVCD, CVD y DivX.

Otro error corregido es que no recuperaba las opciones del menú al cargar una estructura de disco por culpa de un despiste tonto. Ahora ya lo hace. Ahora también muestra la fuente en el botón para escoger el tipo de letra del título del menú. Por último, al previsualizar el menú en formato NTSC usa una ventana un poco más pequeña para que no quede la ventana medio vacía.

Actualización: acabo de subir la revisión 2 del paquete DEB, en donde quito la dependencia de ImageMagik. Esto me pasa por reciclar los ficheros de control de paquetes viejos O:-)