Asus y Linux, no tan amigos

A veces estás tan ilusionado con algo que, cuando menos te lo esperas, te llevas un batacazo de los gordos por confiarte demasiado.

Esto es lo que me ha ocurrido estas navidades con Asus. Después del apoyo que dio a Linux con el EEEPC y con tecnologías como Express Gate, lo último que me esperaba era encontrarme con que un portátil suyo diese, bajo Linux, una serie de problemas muy serios. El modelo en cuestión es el Asus F5GL.

¿Qué es lo que ocurre? Todo parece apuntar a que las tablas ACPI de la BIOS contienen errores, y por eso no funcionan cosas tan básicas como que el ordenador se apague cuando finalizas la sesión (hay que apagarlo «a mano» manteniendo pulsado el botón durante cuatro segundos). Y ya ni hablo de funcionalidades más «avanzadas» como el indicador del nivel de las baterías, o las teclas específicas para control de volumen, brillo… las cuales, obviamente, tampoco funcionan.

La razón de este fallo parece venir del hecho de que han usado un compilador de Microsoft para crear dichas tablas. Tal y como podemos leer en http://forums.gentoo.org/viewtopic.php?t=122145, el compilador de ACPI de Microsoft «tolera» una serie de errores en el código. Dichos errores incumplen el estándar ACPI, y de hecho ese código nunca compilaría en el compilador oficial de Intel (que sigue el estándar punto por punto). «Casualmente», el intérprete ACPI de Windows tolera perfectamente dichos errores, mientras que el interprete de Linux (que intenta seguir al pie de la letra el estándar ACPI, como debe ser), no. Que el lector saque sus propias conclusiones.

Lo peor de todo es que, tras explicárselo al servicio on-line de ASUS, su respuesta fue, literalmente, que ese no era un fallo suyo, y que era responsabilidad de mi distribuidor de Linux el resolver ese problema. Personalmente no estoy de acuerdo: creo que si una empresa saca un equipo del que afirman que cumple el estándar ACPI, pero sus tablas contienen errores no permitidos por dicho estándar, la culpa es de ellos. Intenté insistir y su segunda respuesta fue un simple close! (literalmente).

Tras rebuscar por Internet encontré la página de LinLap.com sobre el F5GL (para los que no la conozcan, dicha página informa sobre la compatibilidad de los portátiles y Linux), y allí se comentaban todas y cada una de mis desdichas. Sin embargo, comentaban también dos detalles interesantes:

  • Con la última KNOPPIX (5.1.1, del 1 de abril de 2007) el apagado funcionaba perfectamente.
  • Había un parche en http://patchwork.kernel.org/patch/1478/ para el kernel 2.6.27 (el que lleva Ubuntu 8.10) que pasaba de los errores en las tablas y hacía que las funciones ACPI funcionase de nuevo.

Revisé el código de todos los núcleos (el de la KNOPPIX, el actual y el parche) y llegué a la conclusión de que dicho parche era un rodeo que ya había para este problema, pero que por alguna razón fue eliminado.

Un par de meses después de encontrar todo esto salió el núcleo 2.6.29, incluyendo un rodeo mucho más depurado para este problema (en concreto, el código es específico para ASUS). Por desgracia, Ubuntu 9.04 llevará el núcleo 2.6.28, el cual todavía no incluye dicho parche. Quien sí trae el nuevo núcleo es Fedora 11 (aún beta, no saldrá hasta el 26 de mayo de 2009), y de hecho la he probado usando un Live-CD y todo parece funcionar perfectamente. Por desgracia el portátil es de un colega y no me atrevo a meterle esta distribución, principalmente porque ya está muy acostumbrado a usar APT.

¿Qué soluciones hay? La más inmediata creo que será, cuando salga Ubuntu 9.04, instalar el núcleo de la versión de desarrollo 9.10 usando pinning. La segunda, que puede que funcione o puede que no, es pedir a los empaquetadores de Ubuntu que hagan un backport del parche del 2.6.29 al 2.6.28, en la página https://bugs.launchpad.net/ubuntu/+source/linux/+bug/333064. Con suerte lo añaden y en un mes estos portátiles vuelven a funcionar al 100%. La tercera, más complicada (sobre todo por los drivers extra de la tarjeta de vídeo e inalámbrica) es compilar yo mismo el núcleo 2.6.29.

Y para terminar, un consejo para todos aquellos que se vayan a comprar un portátil al que pretendan instalar Linux: pasaos antes por http://www.linlap.com y aseguraos de que el modelo que habeis escogido no da problemas. Os ahorrareis muchos disgustos.

Buscando en el baúl de los recuerdos

Hoy me llegó un mensaje de un usuario que estaba portando FBZX nada menos que a OS/2. Y como no podía ser, me entró la morriña, porque yo fuí un Warper en mis tiempos mozos.

Manual de OS/2
Manual de OS/2

Esta es nada menos que la portada del manual de uso de mi OS/2 Warp 3.0, que tengo original y correctamente registrado (me había costado 5.000 pesetajas en el 96).

Pero lo que más me sorprende es que todavía estén mis mensajes y la captura de mi viejo escritorio en la lista TeamOS/2 españa. También encontré la vieja revista EDM2, que trataba sobre OS/2 y traía un montón de artículos sobre como programar con él. Y los comentarios sobre WarpGlobe, y Radio Maceda BBS,…

Pero como siempre, todo llega a su fin: las últimas declaraciones de IBM sobre el futuro de OS/2 dejaban ver a las claras que lo iba a dejar en la cuneta (como, en cierto modo, fue). Esa fue la razón de abandonarlo y pasarme a Linux. Visto en retrospectiva, fue una decisión muy acertada.

Actualizado: Incluso encontré mi mensaje de despedida en la lista de TeamOS2 España. Dentro de poco hará 10 años que me pasé oficialmente a Linux.

To buy or not to buy (un netbook)

Son pequeños, ligeros y tan monos que todo el mundo se quiere comprar uno. ¿Pero hasta qué punto se adapta a las necesidades diarias? ¿Son suficientes para mí, o mejor me compro un portátil más grande? La pregunta no es estúpida, y la respuesta no es trivial.

Lo primero que hay que entender es que un miniportátil no sirve como equipo principal: su pantalla es bastante pequeña (entre 7 y 10 pulgadas) y tiene poca resolución (1024 x 600 o menos), y su teclado es más bien justo. Por otro lado su memoria suele estar entre 512 y 1024 megas, lo que para un sistema XP o Linux puede ser suficiente, pero no para Vista. El procesador suele ser un Atom, el cual tiene un consumo muy ajustado (ideal para un portátil) a costa de una potencia de cálculo bastante escasa.  Finalmente, su disco duro suele ser de tipo Flash y bastante parco. Es cierto que ya hay modelos (como el EEEPC 1000H, por ejemplo) con discos duros «de verdad» y ampliables hasta 2 gigas de RAM, pero aún así, como ordenadores, no son algo para tirar cohetes.

«Pero entonces no sirven para nada, son una estafa»

En absoluto; lo que pasa es que hay que entender que no son equipos diseñados para ser usados como ordenador principal. Para esa función hay que tener un equipo decente, con un monitor razonable (mínimo 15″), un procesador de, al menos, doble núcleo, y 2 gigas de RAM como mínimo.

La razón de ser de los netbooks es servir como ordenador de apoyo: cuando queremos irnos por ahí y poder leer el correo, ver una página web, o escribir un texto sencillo sin necesidad de llevar un armatoste y dos baterías extra para tener una autonomía razonable. Esa es su función. Se han reducido las prestaciones al máximo para poder hacer un ordenador lo más pequeño y ligero posible. Que nadie espere poder usar AutoCAD o 3D Studio Max cómodamente en un netbook, porque no están diseñados para eso.

Así pues, antes de comprarse uno de estos equipos es fundamental sopesar qué uso se le va a dar realmente; puede ocurrir que no estemos comprando lo que necesitamos.

Al rico teclado de piña para el niño y la niña

Actualizado. Si ya tuve una entrada sobre ratones, ahora le toca el turno al teclado. Y es que el de mi flamante Asus EEE PC tiene un detalle algo molesto. Véase la siguiente fotografía:

Resulta que la tecla Mayúsculas derecha está completamente a la derecha y es corta (en lugar de larga, como en los teclados normales), y la tecla Cursor arriba está justo a la izquierda. El resultado es que, cuando se teclea al tacto, es inevitable pulsar con el meñique el cursor cuando se quiere poner una mayúscula.

La solución a este problema es tan sencilla como intercambiar el funcionamiento de dichas teclas, lo cual es muy sencillo gracias a XModMap. Para hacerlo no tenemos más que usar el siguiente script:

#!/bin/bash

xmodmap -e "remove Shift = Shift_R"
xmodmap -e "keycode 62 = Up"
xmodmap -e "keycode 111 = Shift_R"
xmodmap -e "add Shift = Shift_R"
xset -r 111
xset r 62

Los cuatro comandos de XModMap se encargan de remapear los códigos de las teclas con las nuevas funciones deseadas. Luego usamos xset, primero para eliminar la autorrepetición de la nueva tecla Mayúsculas derecha, y luego para añadirla a la nueva tecla Cursor arriba. Es precisamente el hecho de  que la autorrepetición no se pueda controlar desde XModMap lo que obliga a utilizar un script en lugar de un fichero .Xmodmap, como cuando cambiamos los botones del ratón.

Grabamos el script en un lugar cómodo, le damos permisos de ejecución, y ¡voila! Problema resuelto.

O quizás no, porque cada vez que arrancamos el ordenador tendríamos que ejecutar a mano este script para intercambiar las teclas. Lo interesante sería, sin embargo, que se lanzase él solo cada vez que entrásemos en nuestra cuenta. Por fortuna es muy sencillo de hacer en Gnome (en KDE habrá otra manera igual de fácil, pero como no lo uso, no conozco los pasos. ACTUALIZACIÓN: según comenta CoskiBukowsky en los comentarios, se puede copiar el script en ~/.kde/Autostart): basta con ir a Sistema -> Preferencias -> Sesiones y pulsar el botón Añadir, para añadir un nuevo script a ejecutar durante el arranque. Nos saldrá una ventana como ésta, en la que sólo debemos poner la ruta a nuestro script (que, en mi caso, se llama teclas.sh):

¡Y ahora sí, todo listo!

Re-retocando

Y no hay dos sin tres, como ya viene siendo habitual en DeVeDe: me acaban de enviar un par de correcciones extra para la traducción francesa, y además me han avisado de que no actualicé el fichero CHANGELOG.DEBIAN en el paquete DEB. Por eso acabo de lanzar DeVeDe 3.12c, que corrige ambos.

Retocando

Al poco de sacar DeVeDe 3.12 me llegó la traducción a italiano, así como un comentario (en la entrada anterior) en la que me comentan un par de errores en la versión francesa. Por eso acabo de sacar DeVeDe 3.12b, añadiendo dichos cambios (no todos, en realidad. En la traducción francesa sólo corregí el detalle de las marcas HTML; el resto esperaré a que me lo envíe el traductor oficial).

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.