Actualizado: A veces, por casualidad, cuando sólo pretendes pasar un buen rato, te tropiezas con una obra maestra. Hablo nada menos que de Tiempos modernos, el film de Charles Chaplin. En tono de comedia, aunque con un trasfondo dramático (pues, como dijo Roberto Benigni en una entrevista, la comedia sin drama no es comedia, sino bufonada), realiza una gran crítica social de la Gran Depresión, en los años 30; un período, en mi opinión, de grandes paralelismos con el actual por culpa de la (maldita) crisis que estamos sufriendo.

No diré nada más sobre ella porque, como cualquier otra gran obra, lo mejor es pasar de leer críticas y verla directamente. Por eso lo único que haré será animaros a que la consigais como podais, bien comprándola en alguna oferta de grandes almacenes, pidiéndosela prestada a un amigo, o bajándotela de tu eMule más próximo. O, como comentó Anónimo en el primer comentario, podeis probar en la Biblioteca más próxima.

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.

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.

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.

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.

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.

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.

El otro día fuí al cine del centro comercial Gran Vía, y me encontré con este cartelito:

Ante el que uno no puede evitar preguntarse ¿para qué lo ponen si se olvidan de escribir ante quien puedo ejercer mis derechos?

Mientras termino de recuperarme de una recaida de mis adorables cervicales, aprovecharé para subir una entrada que tenía escrita desde hace tiempo. Y es que a veces uno encuentra cosas divertidas o curiosas en la vida real, como por ejemplo el famoso Quick Stop de Clerks (el cartel de la derecha)… pero en Valencia (a la izquierda):

Otro caso es el parecido entre el logo de Nvidia, famosa por sus tarjetas gráficas, y el de una empresa de gestión, promoción y construcción cuya furgoneta encontré en Vigo mientras daba un paseillo, y cuyo nombre he decidido omitir:

Por último, cabe destacar el curioso parecido entre el fondo por defecto de Ubuntu (a la derecha), y el que aparece en la promoción de reproductores de DVD de una conocida marca de foagrás (o foie gras para los puristas) a la izquierda. La foto la hice con mi viejo móvil, por eso tiene tan poca calidad.

¡Y yo que renegaba de los móviles con cámara de fotos!

Hace unos días estuve en la Guademy. Necesitaba tomarme un par de días de descanso para quitarme de la cabeza el trabajo y las molestias de cuello, y nada mejor que Valencia, a casi mil kilómetros de distancia y con un clima mucho más benigno que el de Vigo para mis cervicales. Un viajecito en avión con escala en los Madriles y directo para la Universidad Politécnica. La verdad es que se nota la diferencia con la de Vigo, aunque sólo sea porque allí todo es llano 🙂 A ver cuando pasamos el Bulldozer por aquí…

Hubo varias charlas, aunque las que más me interesaron fueron, sin duda, tres:

• La charla sobre GTK 3.0: en ella, Carlos Garnacho nos explicó los grandes problemas que la compatibilidad binaria está suponiendo de cara a añadir nuevas funcionalidades en la versión actual de GTK. El principal problema es que, en muchos casos, se accede directamente a los datos de las estructuras que definen un widget. Eso, unido al sistema que usa Gobject para implementar la herencia obliga a que el orden de los elementos y el tamaño de éstas permanezca invariable. La solución actual consiste en reservar varios punteros, que apuntarán (valga la redundancia) a los nuevos datos que se necesiten en el futuro, con todos los problemas que ésto acarrea. Para solucionarlo de manera definitiva han propuesto convertir en privadas absolutamente todas las propiedades de los objetos que forman los widgets, de manera que cualquier acceso que se quiera hacer «desde el exterior» sea a través de métodos. De esta manera los programas simplemente trabajarán con un puntero a la estructura, sin importarles lo que haya dentro. Han elaborado además un plan de transición que facilite la migración de las aplicaciones.
• La charla sobre el futuro de QT y WebKit. Aunque adoro GTK, reconozco que el metacompilador de objetos de QT es impresionante. Holger Freyther nos hizo una demostración de como usarlo para ampliar WebKit, permitiéndole acceder a objetos QT desde JavaScript con unas pocas líneas de código. Pero lo que más me gustó y sorprendió fue, sin duda, las nuevas capacidades de concurrencia de QT4, por su elegancia y simplicidad. La idea es aprovechar más los múltiples núcleos de los procesadores actuales, simplificando la creación de procesos concurrentes en los casos más habituales. El sistema que mostró era muy sencillo, pues sólo permitía repetir una misma misma tarea X veces de manera concurrente, cada una con un conjunto de datos diferente (el ejemplo era redimensionar todas las fotografías de una carpeta). Aunque es cierto que no permite hacer cosas complejas, como dependencias (el proceso C sólo debe ponerse en marcha cuando el A y el B hayan terminado), es cierto que es un primer paso hacia el aprovechamiento de los nuevos procesadores en el escritorio.
• Por último, me gustó mucho la charla de Will Stephenson sobre el Akonade PIM, un gestor de datos personales para KDE con una interfaz DBUS. El problema actual en KDE es que un componente gestiona las direcciones de correo, otro las citas, etc, con lo que el acceso a los datos puede volverse muy lento si lo que se pretende es cruzarlos entre ellos. Además, al ser procesos independientes, el consumo de memoria se dispara. La solución propuesta es Akonade, un pequeño gestor de bases de datos que aglutina toda esa información en un único servidor, y permite hacer búsquedas muy complejas. Lo interesante es que lo que ha «estandarizado» es la interfaz DBUS en lugar del servidor en sí, de manera que ésta se podría implementar en, por ejemplo, Evolution, y los programas de KDE podrían acceder a los datos de Gnome y viceversa de manera sencilla.

Por supuesto, la segunda parte buena fueron las estupendas charlas informales con el resto de la gente en los descansos, durante las comidas, en la cena del sábado y en la playa el domingo. ¡¡¡¡Un saludo a todos!!!!

El resultado es que vengo cargado de nuevas ideas y ganas de seguir programando. Ahora sólo me falta encontrar tiempo material para ponerme 🙂

Parece que estoy incubando algo. Espero que sea un simple resfriado y no una gripe. En este momento, después de tomarme una aspirina, ya estoy mejor, por eso aprovecho para añadir una nueva entradilla aquí.

Hace unos días, mientras ultimaba la nueva versión de DeVeDe, encontré un molesto bug en el widget Gtk.FileChooserButton; en concreto en el método set_filename(). Cuando el usuario pulsa el botón Propiedades para cambiar las propiedades de una película (tasa binaria, resolución…), uso ese método para rellenar dicho FileChooserButton con la ruta completa del archivo correspondiente; sin embargo, a veces (no siempre) fallaba, quedando el widget vacío. Tras hacer varias pruebas llegué a la conclusión de que era totalmente aleatorio: no dependía de la longitud del nombre, ni del directorio en que se encontrase, ni del número de niveles… el mismo archivo a veces aparecía correctamente en el widget y otras veces no. Con Ubuntu 7.04 (que usa GTK 2.10) dicho fallo no ocurría (que yo recordase, al menos).

Dado que no tenía claro si el error estaba en GTK o en los bindings para Python (PyGTK), durante el fin de semana hice un pequeño programa de prueba en C. El resultado es que, efectivamente, el error es de GTK. Además probé el mismo código en una Ubuntu 7.04 y, tal y como sospechaba, no falla (por lo que vi en la lista de cambios de GTK 2.10 a 2.12, los desarrolladores hicieron muchas mejoras en la clase FileChooser). El problema realmente gordo es que todos los intentos por esquivar el problema han fallado, lo que significa que mientras no lo corrijan, DeVeDe no funcionará correctamente 🙁

De momento he notificado el bug y he añadido una nota en la FAQ de DeVeDe. Mañana o pasado (cuando la cabeza deje de darme vueltas) publicaré la nueva versión.