Salió en Slashdot que Pine, el venerable programa de correo electrónico, va a perder su sitio de parches.

Pine tiene en primer lugar un sitio de parches porque no es Software Libre. Se podría discutir si es o no Open Source (yo creo que sí lo es), pero ciertamente no es lo suficientemente libre como para que alguien tome el código y comience a mantenerlo si así lo desea. Se necesita permiso especial de la Universidad de Washington, que es la “dueña” del código.

En general, esta noticia no me interesa en lo más mínimo; pero me hizo recordar mi breve uso de Pine al inicio de la carrera, y los distintos clientes de correo electrónico que he utilizado desde que tengo correo… que son sorprendentemente pocos, por cierto (descontando clientes webmail).

Al inicio de la carrera yo no utilicé mi correo electrónico. No lo necesitaba en ese entonces; no conocía a nadie fuera de la Facultad que usara correo electrónico, y dentro de la Facultad no era necesario utilizarlo: la única materia de la carrera era Matemáticas Discretas, y ahí no había laboratorio. En las materias de Matemáticas era aún menos necesario.

Comencé a usar mi correo (cpelaez@ada.fciencias.unam.mx, creo que aún sirve, por cierto) hasta segundo semestre cuando tuve mi primer materia de la carrera que necesitaba laboratorio. Siguiendo a la manada, utilicé Pine para leer mi correo; casi todos los newbies era lo que usábamos.

Pine sin duda alguna funcionaba. Era feo y triste; pero era puro amor. Yo creo que hubiera seguido usándolo si no fuera por dos razones: comencé a utilizar mucho Emacs (todavía no XEmacs, creo), y descubrí con horror que meter acentos en Pine era ligeramente engorroso. Era 1998.

Como a mí siempre me ha interesado escribir en español, no en espanol, y como ya había descubierto cómo escribir caracteres acentuados y eñes en Emacs, no tardé mucho en descubrir rmail y pasarme de volada a ese cliente. Rmail, debo hacer la aclaración por si no es obvio, es un programa escrito en elisp, y que corría dentro de Emacs.

Eso tiene ventajas y desventajas. Las ventajas son obvias; uno utiliza Emacs para escribir correos. Todo el poder de Emacs (y elisp) están ahí para que uno pueda escribir los tres párrafos que en promedio tiene un correo. Las desventajas también son obvias: uno utiliza Emacs para escribir correos. Todo el consumo de memoria y procesador que utiliza Emacs son necesarios para escribir los tres párrafos que en promedio tiene un correo.

Rmail funcionaba. Mejor que Pine, debo decir, si bien le faltaban ciertas cosas que cualquier cliente de correo moderno tiene: en particular hilos (threads); que una serie de correos sobre un mismo tema se aniden. En rmail (y Pine, en esa época) todos los correos sencillamente aparecían uno detrás del otro. Eso era inconveniente, por decir lo menos. Especialmente si uno comenzaba a suscribirse a listas de correo como degenerado, que fue lo que yo hice.

Por esa razón, y porque me mudé a XEmacs, decidí pasarme a Gnus. Gnus también corría dentro de XEmacs, pero tenía soporte para hilos (dado que, originalmente, era un cliente para news, no para mail), y de hecho tenía una cantidad ridícula de cositas que lo hacían increíblemente poderoso. A partir de que comencé a usar Gnus, de vez en cuando veía otros clientes de correo electrónico, pero era dolorosamente obvio que ninguno le llegaba a los talones a Gnus.

Y así seguí durante años; y tal vez así hubiera seguido si no fuera por una combinación de circunstancias. La primera es que comencé a usar GNOME en serio, y quería un cliente de correo que utilizara Gtk+ 2. La segunda es que descubrí GnuPG, y quería empezar a firmar digitalmente mis correos. Con este punto debo hacer la aclaración de que estoy seguro de que se puede utilizar GnuPG con Gnus… y también estoy seguro de que en ese entonces (hace unos tres años) era una desmadre hacerlo. La tercera circunstancia es que en Gnus es, para motivos prácticos, imposible mover un correo de una “carpeta” a otra. Lo cual tiene sentido si uno comprende que Gnus no era originalmente un cliente de correo, sino uno de news.

Gnus por lo demás hacía todo lo que ahora hago con Evolution; se podía filtrar SPAM con SpamAssassin, se podía poner cualquier script para generar firmas (lo que va al final del correo; yo utilizo fortunas), etc. Y ciertamente fue Evolution el primer cliente que encontré que hacía eso y más. O lo hacía más fácil; por ejemplo, en Gnus borrar un correo era particularmente engorroso (una vez más, legado de ser un cliente de news originalmente).

Evolution me gusta bastante; se integra sin ningún problema con GnuPG y con SpamAssassin; mis contactos y calendario se sincronizan con mi Palm; puedo utilizar cualquier script para firmar mis correos; puedo verificar firmas digitales apretando un botón; firmo digitalmente mis correos de forma transparente; si así lo deseo puedo cifrar un correo completamente; etc., etc., etc.

Evolution también tiene sus broncas, claro. En primer lugar, sí es pesado en memoria y procesador. Y en segundo lugar, sí me gustaría tener un cliente de correo electrónico, un programa para manejar contactos, un programa para mi calendario y un programa para memos y lista de tareas; no tenerlo todo junto en un programa enorme.

Pero quitando eso, es un excelente cliente de correo electrónico.

Ahora, lo obvio es preguntar: ¿por qué no utilizar un cliente de webmail? Sí lo utilizo, y el que yo creo que es el mejor: GMail; pero no es mi correo electrónico principal.

Las razones son varias. Primero, aunque GMail da tres gigas (casi) de espacio, el punto es que tengo espacio limitado. Si quiero conservar mis correos para siempre, lo único que me garantiza espacio suficiente es tenerlos en una máquina que yo controle. Segundo, no hay manera de usar GnuPG, a menos que yo a pie cree los adjuntos necesarios al correo, lo cual está de hueva. Y tercero; estoy muy orgulloso de que mi correo termine con “unam.mx”, y es algo que no quiero dejar de usar nunca para mi correo principal. Que además sea “ciencias.unam.mx” es un bono extra.

Las ventajas de un correo webmail son obvias; principalmente la capacidad de consultar y responder o mandar correos desde cualquier máquina con un navegador. Mi cuenta en Ciencias tiene un cliente web, que utilizo para emergencias. Para otras cosas, como listas de correo y cosas así, utilizo mi cuenta de GMail (no quiero guardar en mi máquina mis correos de listas; ya hay archivos en la red).

Pero mi correo principal, el que uso exclusivamente para cosas académicas y con el que uso Evolution como cliente, es el de Ciencias. Y Evolution es un gran cliente de correo electrónico.

No sé si eventualmente aparezca un mejor programa (ya no llegué a probar Thunderbird, por ejemplo), pero a menos que Evolution me de algún tipo de problema, yo creo que seguiré usándolo indefinidamente.

Hace ya casi 10 años, instalé Linux en mi casa por primera vez; una versión modificada de RedHat Linux que unos chavos aquí en México hacían.

En ese entonces no había de otra: uno instalaba Lilo porque no existía ninguna alternativa. Y de hecho, el paso de que Lilo quedara bien era el fundamental; si después de todo el desmadre que era instalar Linux uno veía el prompt de “LILO:” al reiniciar, básicamente se estaba del otro lado.

Después de un rato me volví bastante experto en las opciones que venían con Lilo, y conforme fui probando otras distribuciones y reinstalando cada vez, siempre puse Lilo; incluso cuando Grub apareció en escena.

Cuando instalé Gentoo, en el Handbook decía que lo “recomendado” era utilizar Grub, aunque (por supuesto) se puede instalar Lilo sin ningún problema. Eso es decir mucho, porque Gentoo no se eligen paquetes para recomandar porque sean fáciles de usar; generalmente se eligen basados únicamente en el mérito técnico. Pero a mí me valió madre e instalé Lilo.

¿Tiene algo de malo Lilo? No, en absoluto. Es un programa probado hasta la ignominia y que hace muy bien su trabajo. Sólo es viejo, y poco flexible. Pero funciona y funciona bien.

Entonces, ¿para qué cambiarse a Grub? Me gustaría decir que son los méritos técnicos, o que es porque no hay que correr ningún comando después de modificar el archivo de configuración, o porque estoy tratando de ser más “moderno”. Pero no: la verdad es que cambié a Grub porque tiene temas más bonitos y además las etiquetas para cada sistema operativo pueden tener espacios (y entonces se lee “Gentoo Linux 2.6.18-2” en lugar del poco llamativo “linux” que hasta ahora siempre había tenido).

Fue trivial cambiar de Lilo a Grub, y la verdad sí está bastante más bonito. Lo voy a poner en mi laptop también dentro de poco (nada más recupere el eliminador de corriente), y es lo que voy a instalar desde ahora cuando le instale a alguien más Linux. Exceptuando si instalo un servidor; ahí sí creo que Lilo es mejor opción.

Lilo es un gran programa que durante años me funcionó sin ningún problema; sólo que era hora de cambiar a la opción más moderna.

Es oficial Sun liberó Java bajo la GPL. Incluso ya hay un sitio para el código GPL: OpenJDK.

Como dije hace unos días, esto es enorme. Lo voy a repetir, para que quede claro:

Esto es ENORME.

No sólo porque (literalmente) millones de líneas de código (buen código, de alta calidad, usado en la industria y academia) se agregan a todo el código libre que corre por ahí: además porque va a revolucionar a Linux y al uso de Java en todo lo que tenga que ver con Software Libre.

Para empezar, todas (y por todas quiero decir todas) las distribuciones de Linux distribuirán Java y decenas de programas escritos en Java, que hasta ahora eran tratados como ciudadanos de segunda clase en Linux porque era un desmadre instalar Java (incluso en Gentoo era más difícil que los paquetes normales).

Pero además, el principal problema que había con Java al momento de querer empezar una aplicación para GNOME (o KDE) desaparece por completo. C# no se va ir a ningún lado, ni tampoco aplicaciones como F-Spot, o Tomboy, o Beagle, o Banshee; pero ahora van a tener seria competencia.

En añadidura, todo el código del JDK va a ser revisado. Por un chingo de gente (para empezar los Classpatheros). Las probabilidades de que mejore sustancialmente el desempeño de Java y de que se corrijan problemas serios que tiene (como que no haya IPC entre distintas instancias de la máquina virtual, o que tarden tanto en iniciar las aplicaciones), son muy altas.

Damn. Hasta a mí me están dando ganas de empezar a escribir aplicaciones para GNOME en Java.

Voy a repetirlo una vez más, porque me encanta la palabra “enorme”: esto es enorme. Creo que es la mejor jugada que ha hecho Sun en años.

Vientos Sun.

Y resulta que me dejaron implementar AES en criptografía.

Me llevó unas cuantas horas implementar el estándar; quiero decir, la función que recibe 128 bits y la llave de 128, 192 ó 256 bits, y los cifra (y las funciones que a su vez necesita… y las inversas para descifrar). La Wikipedia fue de gran ayuda, porque los el maldito FIPS a mí se me hizo ilegible… o mejor dicho tenía hueva y el FIPS es de 51 páginas.

Y después perdí casi dos días implementando el programa que usa esas funciones que cifran y descifran, el que recibe la llave y el archivo de entrada y el archivo de salida etc. De hecho el programa también me llevó unas cuántas horas, pero cuando lo terminé era lentísimo.

Bueno, para archivos normales estaba bien, pero cifré un archivo de 350 MB, y tardó casi media hora. 350 MB es mucho, pero que tardara media hora era ridículo.

Así que pasé este par de días haciendo pruebas y tratando de entender en dónde estaba el cuello de botella, y resultó estar en la función de MixColumns. Inicialmente había copiado tal cual el código de la Wikipedia, pero como ya tenía implementadas las operaciones sobre polinomios de séptimo grado y sobre GF(2⁸), decidí utilizarlas y hacer la multiplicación de matrices. Ciertamente el código era mucho más legible y bonito.

Y lentísimo. Como 20 veces más lento.

Entonces regresé al código de la Wikipedia, pero no tenía el de la función inversa. Así que lo que hice fue que, dado que las matrices sólo utilizaban las constantes 2, 3, 9, 11, 13 y 14, generar las tablas de multiplicar de todos los elementos del campo con esas constantes. Así la multiplicación se realiza de volada (es buscar un elemento en una tabla). También realicé otras optimizaciones obvias, y cambié el programa para que leyera el archivo de entrada en bloques de 2¹⁶ bytes (y escribiera igual el de salida).

Al final, mi programa pasó de tardar 28 minutos en cifrar un archivo de 350 MB, a tardar 2 minutos 22 segundos. Lo cual está bastante chido, si está bien que yo lo diga. Además, utiliza menos de 2KB de memoria; el único otro programa que encontré específicamente para cifrar usando AES se traba estúpidamente porque trata de cargar todo el archivo de entrada en memoria. Pero con archivos más chiquitos es casi cinco veces más rápido que el mío.

Hay todavía una optimización más que podría hacer, que tal vez le permitiría a mi programa alcanzar la velocidad del otro que encontré, pero me gusta mucho cómo quedó el código y no le veo mucho sentido hacerla. No soy ingeniero; lo que realmente me interesaba era que el programa funcionara.

Sólo que media hora por un tercio de gigabyte era ridículo. Con 2 minutos 22 segundos puedo vivir.

Actualización: Por idiota, se me olvidó ponerle optimizaciones a gcc al compilar mi programa, y quitarle los símbolos de depuración. Con optimizaciones y sin símbolos de optimización, mi programa tarda 1 minuto 33 segundos; y en mi Athlon 64 X2 tarda 33 segundos (sin usar los dos cores al mismo tiempo).

Enrique me comentó algo muy cierto respecto a mi decisión de mantener ciertos archivos de mi máquina encriptados usando GnuPG, como comenté en otra entrada. Básicamente me preguntó que qué chingados iba a hacer si se me perdía mi llave secreta.

Si no tengo respaldo, obviamente la respuesta es sencillamente “echarme a llorar”, porque necesitaría cientos (o miles) de computadoras corriendo un algoritmo paralelo para intentar recuperar mi llave si llegara a perderla. Así que tengo que asegurarme de no perderla.

Lo que voy a hacer es quemar dos o tres copias de la llave secreta en CDs chiquitos (de esos que son del tamaño de una tarjeta), y guardar uno en mi cartera, otro en un lugar lejano y seguro (el departamento de mi papá o el de mi hermano), y uno más en un lugar súper secreto… como debajo de mi cama.

Si alguien llegara a obtener una copia de la llave no importa; de cualquier forma está protegida por el passphrase. Si se me olvidara el passphrase entonces sí estaría en problemas graves, pero dudo que eso ocurra.

Espero.

En mi máquina tengo archivos que en verdad me gustaría que nadie (excepto yo) jamás vea. No entrañan nada del otro mundo (nadie iría a la cárcel por sus contenidos), pero sí son cosas con las cuales un alto nivel de discreción es recomendable.

Lo que hace uno con este tipo de archivos es encriptarlos. No en un Zip con sus ridículos passwords, sino con algoritmos de encriptamiento verdaderamente seguros. En Linux eso suele querer decir utilizar GnuPG (GNU Privacy Guard), la implementación de GNU del estándar OpenPGP, que permite encriptar y firmar digitalmente documentos.

La idea básica es sencilla; se tienen dos llaves (A y B), y si uno encripta algo con la llave A, entonces sólo puede descifrarse con la llave B, y si alguien encripta algo con la llave B, entonces sólo puede descifrarse con la llave A. Por supuesto, para que esto tenga algún tipo de sentido, debe ser muy difícil obtener A a partir de B o B a partir de A. Digamos que estas llaves las genera Fulano.

Una de las llaves (digamos la A) se define como la llave privada (Fulano y únicamente Fulano puede verla y usarla), y la otra (digamos la B) se define como la llave pública (todo mundo puede verla). Entonces así es muy fácil enviarle (por ejemplo) un correo súper secreto a Fulano; sólo se toma su llave pública (todo mundo puede verla, entonces no hay problema), encripta el correo con ella y se lo manda a Fulano. No importa quiénes pudieran interceptar el mensaje; como la llave privada de Fulano sólo la tiene él, sólo él puede descifrar el mensaje.

De igual forma, si Fulano quiere mandar un mensaje y que quede claro que fue él el que lo envió, entonces lo que hace es encriptar el mensaje con su llave privada. Todo mundo puede descifrarlo con la llave pública de Fulano (porque es pública), pero cómo sólo Fulano tiene acceso a la llave privada, queda claro que fue él el que encriptó el mensaje. Y eso es una firma digital.

(Claro que si la llave privada es comprometida, absolutamente todo el esquema de seguridad se viene abajo; pero eso es otro problema. En particular, con GnuPG además se proteje la llave privada con una passphrase, para que incluso si alguien puede tener acceso a ella, no quiera decir que ya pueden utilizarla).

El algoritmo usado por GnuPG es ElGamal, que utiliza criptografía de curvas elípticas (que es por cierto lo que estoy viendo en mi clase de criptografía). Es seguro mientras el problema del logaritmo discreto no se pueda resolver “rápidamente” en una computadora. Las computadoras cuánticas en teoría podrían resolverlo de volada; pero mientras no estén aquí y sean usables en la práctica, no hay nada de qué preocuparse.

Yo vengo usando GnuPG desde hace años; desde que comencé a usar mi cuenta de correo en Ciencias como mi cuenta principal, generé mis llaves y publiqué mi llave pública (je) en http://pgp.mit.edu (ahí la pueden consultar si me quieren enviar encriptados sus planes de dominación mundial). Huevón como soy, le puse que nunca expirara; se supone eso está mal, pero realmente no uso mi cuenta en Ciencias para fines subversivos (para eso tengo otras cuentas), y sólo quería tener la posibilidad de firmar mis mensajes y que alguien, si lo quería, me enviara correos encriptados. Lo primero lo vengo haciendo desde hace años; lo segundo hasta ahora no ha ocurrido.

Como sea, también sé que que para encriptar archivos uno sólo tiene que hacer:

gpg -r NAME --output OUTFILE.gpg --encrypt INFILE

y para descifrar uno sólo tiene que hacer:

gpg -r NAME --output OUTFILE --decrypt INFILE.gpg

…pero qué hueva estar haciendo eso cada vez que uno encripta o descifra un archivo. Así que fue muy divertido descubrir cómo funciona Seahorse, el front end de GNOME para GnuPG.

Ya lo había instalado antes, pero lo desinstalé en primer lugar porque no sabía cómo usarlo y me dio hueva investigar, y en segundo lugar (y la razón más superficial del universo) porque su programa de configuración no tenía iconito en los menúes de GNOME; desde hace un rato borro cualquier aplicación que ponga entradas en los menúes y no les ponga iconos.

Pero con GNOME 2.16 viene Alacarte, que es un editor de menúes über cool, que me permitió poner el iconito necesario y así dejar el programa instalado el suficiente tiempo como para aprender a usarlo. Que fueron como 15 minutos, por cierto.

Lo chido de Seahorse es que se integra con Nautilus; entonces si uno tiene un archivo que quiere encriptar

Lo único que hace es hacerle click con el botón derecho del ratón y elegir (duh!) “encriptar”:

Entonces sale una ventana donde uno puede elegir qué llave pública usar para encriptarlo. Otra cosa chida de GnuPG: uno puede tener cuantas llaves quiera, y cada una de ellas tiene su propia passphrase. Para encriptar archivos para mi uso personal, decidí usar una llave distinta a la que uso en mi correo electrónico, y además no la publiqué en pgp.mit.edu:

Y ya; el archivo queda encriptado:

Esto es lo único que no me gustó: Seahorse encripta a un archivo con extensión .pgp, que no es la que Nautilus asocia con Seahorse. Pero eso se soluciona fácilmente cambiándole la extensión a .gpg, y al hacerle doble click, Seahorse pide el passphrase (obviamente no me “pide” la llave privada porque esa la tengo en mi máquina):

Y si la passphrase concuerda, desencripta el documento. Está súper chido; incluso si robaran mi máquina (o más posible, mi laptop), está muy cabrón que puedan descifrar alguno de mis documentos encriptados (a menos que mi passphrase sea terriblemente débil… pero eso es otra historia). Otra cosa bonita es que el programa seahorse-agent corre como demonio todo el tiempo, y guarda las passphrases un rato (50 minutos por omisión, pero se puede configurar y borrar cada vez que uno quiera el cache de passphrases).

Así es muy sencillo estar encriptando y descifrando archivos. Y entonces puedo mantener mis sucios secretos seguros de miradas indiscretas.

Actualicé abulafia (la máquina dónde antes estaba este blog) de Fedora Core 5 a Fedora Core 6. Fue básicamente igual que la actualización de Fedora Core 4 a Fedora Core 5, con algunos problemas de dependencias, una corrupción de la base de datos de RPM (fácilmente reparable), y un reinicio para usar el nuevo kernel.

A pesar de que en general no me quejo, sí le falta mucho para llegar al nivel de Gentoo o Debian a la hora de hacer actualizaciones. Y aunque ahora hubo menos broncas de dependencias, en abulafia usamos básicamente puros paquetes “oficiales” de Fedora; no debería haber ningún problema (en Gentoo no recuerdo la última vez que tuve broncas de dependencias).

Pero bueno; abulafia tiene ya corriendo Fedora Core 6. Y dado que las actualizaciones ahora son automágicas, espero no tener que preocuparme por ella en un ratote.

Actualicé mi overlay de XGL (que aunque se sigue llamando así yo ya no uso XGL, sino AiXGL), y para mi sorpresa todos los ebuilds importantes habían desaparecido. Me quedé como lampareado un segundo, antes de que se me ocurriera buscar en el árbol “oficial” de portage.

Y sí, Beryl, Emerald y todo lo relacionado ya está oficialmente en Gentoo. Desde el 22 de Octubre; hago mis actualizaciones los viernes y sábados, así que la última que había hecho fue el 21.

No sólo ya están en el árbol; además no están hard masked; sólo están marcados como inestables. Lo cual está chido: puedo eliminar el overlay que tenía.

En otra cosa que no tiene nada que ver, estaba quemando unos CDs cuando de repente apreté el botón de expulsión de uno con el CD adentro y montado. En Linux eso significaba nada: el CD permanecía dentro de la unidad hasta que uno lo desmontaba. Pero dije “significaba”, del verbo alguien ya lo cambió: cual sería mi sorpresa cuando el CD automáticamente se desmontó y salió expulsado.

Es muy cagado que el sistema operativo vaya mejorando y uno ni siquiera se de cuenta de inmediato.

Estaba desayunando y leyendo Slashdot (al mismo tiempo; también puedo caminar y mascar chicle a la vez), y vi que Adobe acaba de publicar el primer beta de Falsh 9 para Linux. Me metí a la discusión de inmedato y en los comentarios vi que ya había un ebuild para Gentoo. Me metí a la liga, y vi con sorpresa que ya lo habían integrado al árbol de Portage.

Eso sí es raro, que algo esté tan rápido. Está inestable y mascareado, pero está.

Un --sync y un update después, tengo el nuevo Flash 9 (beta) para Linux. Jala sorprendentemente bien. Utiliza ALSA, así que no hay bronca que utilice al mismo tiempo Rhythmbox, y por primera vez los videos en YouTube están perfectamente sincronizados.

Lo que no entiendo es por qué siguen utilizando Motif (o lo que sea que usan) para los menúes e interfaz gráfica en lugar de Gtk+ 2. Pero eso realmente es lo de menos; lo importante es que por fin tenemos la última versión de Flash para Linux (y ya puedo volver a usar Firefox para consultar la cartelera en Cinépolis, y bajar subtítulos de Forom.com).

Como ahora Java es “libre” (o al menos se puede bajar sin tener que prometerle uno o dos hijos a Sun), decidí compilar Azureus. Hasta ahora venía usando la versión binaria, pero después de poner OOo compilado, decidí mover mi Azureus también a compilado.

Y pues sí jala… la verdad no veo diferencia (bueno, es una versión más nueva), pero no es de extrañar: la versión binaria es también bytecode al fin y al cabo. Pero está chido que ya todo mi sistema esté compilado: excepto por MPlayer (y ahí no tengo de otra; los codecs de Windows no jalan nativamente en 64 bits), y Firefox (tampoco tengo muchas opciones: no hay plugin de Flash nativo para Linux en 64 bits… pero dicen que la versión 9 sí será soportada nativamente en 64 bits).

Actualización: por idiota no puse lo que me hizo escribir esta entrada en primer lugar. El ebuild de SWT (que Azureus necesita) dice lo siguiente al instalarse:

* CAIRO Support is experimental! We are not responsible if
* enabling support for CAIRO corrupts your Gentoo install,
* if it blows up your computer, or if it becomes sentient
* and chases you down the street yelling random binary!

En Gentoo OpenOffice.org 2.0.4 se volvió inestable. No suena como gran noticia, pero llevaba años sin poder ni siquiera compilarse en amd64. Lo cual nos forzaba a los usuarios de amd64 a usar la versión binaria del paquete.

(Lo de “forzar” es ligeramente exagerado; la verdad no uso OpenOffice.org, pero es útil cuando alguien me manda una presentación en PowerPoint.)

Así que compilé la bestia y estoy bastante impresionado con la velocidad de mi máquina:

centurion ~ # genlop -t app-office/openoffice
 * app-office/openoffice

     Tue Oct 17 18:29:21 2006 >>> app-office/openoffice-2.0.4
       merge time: 4 hours, 52 minutes and 50 seconds.

En mi antigua máquina tardaba casi 10 horas. Uno inicialmente podría pensar que no hay mucha ganancia, ya que mi nueva máquina es dual core; pero sí es mucha ganancia: el ebuild de OpenOffice.org no utiliza compilación en paralelo.

Y sí está un poquito más rápido el OOo. Sigue siendo más lento incluso que XEmacs, pero es usable.

Instalé lm_sensors, que había intentado usar hace un par de años pero que me desesperó su interfaz. O mejor dicho la falta de.

Está bonito, porque ahora viene con un cómodo script que automágicamente detecta qué módulos del kernel debe cargar y porque hay un applet de GNOME que muestra iconitos bonitos con termómetros y velocímetros para los ventiladores, además de revisar la temperatura de mi tarjeta NVidia también. Los ventiladores no me interesan tanto como la temperatura (quiero decir; si la temperatura está demasiado elevada, probablemente los ventiladores estén mal), así que dejé sólo la temperatura de mi CPU (que tiene dos cores), de mi placa madre, la ambiental y la de mi GPU (mi NVidia).

Y me llevé un sustote:

La temperatura leía 59°C, pero eso estaba en el rojo vivo, así que inmediatamente pensé “¡O mi dos, estoy hirviendo mi tarjeta NVIDIA!”

Espantado revisé el programa de NVidia Settings, y para mi asombro vi que la temperatura máxima de mi GPU antes de comenzar a bajarle la velocidad para evitar daños es de 125°C:

O sea que tranquilamente puedo estar evaporando agua usando mi NVidia. No que lo vaya a intentar, claro.

El applet de GNOME por suerte pueden definírsele los límites de las temperaturas, así que puse el del GPU a 125°C y ya todo se ve bien:

Voy a poner esto en mi laptop, se ve chido.

Esto tratando de ponerme al día sobre las cosas que quería escribir, que por estar ocupado no había podido, pero ya estoy cansado y esta última entrada será rápida.

La gente que mantenía Compiz-Quinnstorm (la versión de Compiz con plugins locochones) decidió (no tengo idea por qué) que ya no les gustaba el nombre de Compiz y ahora el “bisne” se llama Beryl. Repito: no tengo idea de por qué se dio el cambio, y realmente no me importa, pero el punto es que llegué a mi compu, actualicé mi repositorio de XGL Coffee, y resultó que Compiz (y toda la parafernalia necesaria) había pasado a mejor vida.

La mala noticia: Beryl necesita de forma obligatoria la extensión GLX_EXT_texture_from_pixmap, que los controladores de NVidia que tenía instalados en mi AMD 64 X2 no soportaban. La buena noticia: los controladores “beta” soportan esa extensión, y de corolario hacen innecesario usar XGL, porque también jalan con AIXGL.

Así que primero probé el chisme este en mi laptop, y funcionó de pelos (de hecho recuperé mis imágenes arriba y abajo del cubo; en algún momento había dejado de mostrarlas), y tras unos cuantos golpes de cabeza también jaló en mi escritorio.

Y además ahora mis dos máquinas utilizan AIXGL, que es mucho más limpio que XGL. Y el nuevo decorador de ventanas (Emerald se llama; no, no es error de ortografía; y sí, ahí sí entiendo por qué cambiar el nombre de CGWD) tiene mucho más limpios los temas, así que en general el cambio fue bueno.

Que por cierto, creo que esta revolución (porque no es otra cosa) que empezó con XGL y Compiz y ahora sigue con AIXGL y Beryl va a conseguir algo que creí imposible hace unos cuantos años: que KDE y GNOME compartan el mismo manejador de ventanas.

Recuerdo las guerras en las listas de correo cuando GNOME originalmente dijo que no tendría manejador de ventanas “oficial”, y las mentadas de madre que recibió el proyecto cuando se negaron a usar kwin. Sin embargo, los dos proyectos se esforzaron en soportar los estándares de Freedesktop.org, y como resultado cuando salió Compiz fue trivial ponerle soporte para KDE aún cuando originalmente sólo era para GNOME. Ahora Beryl soporta alegremente los dos proyectos, y dado el éxito que está teniendo el escritorio OpenGL, no me extrañaría que ambos proyectos eventualmente pongan al mismo manejador de ventanas como el oficial.

Ahora sólo espero que dejen de estarle cambiando de nombre al proyecto y se queden con Beryl. Que apesta, pero bueno.

Fui con Citlali a instalarle Ubuntu 6.06 (Dapper Drake).

Originalmente le había instalado Gentoo, porque en verdad creo que es una gran distribución, y porque creí que Citla tenía los requerimientos de geek necesarios.

Después de casi año y medio de soporte técnico remoto (y a veces no tan remoto), llegué a la conclusión de que no. Esto no dice nada de Citlali; sin duda es una computóloga más que capaz. Lo que pasa es que Gentoo es demasiado rudo. A veces es demasiado rudo hasta para mí.

Como Omar y otros cuates tenían Ubuntu en alta estima, decidí instalárselo y ver cómo nos iba.

En general fue más que satisfactorio; la instalación toma literalmente quince minutos, y lo primero que hace después de instalar es actualizar a las últimas versiones. Configurar sonido, video, red, impresora, etc. es ridículamente fácil. No, esperen, tachen eso.

No hay que configurarlo. Uno rebootea y ahí está todo.

Ahora, no todo fue miel sobre hojuelas. Ubuntu es una distribución para usuarios. Gente que quiera navegar, oír MP3s, ver videos y tal vez trabajar en procesadores de palabras y hojas de cálculo. En ese sentido, no es developer friendly.

Es la primera vez en la vida que instalo una distribución Linux, escribo gcc en la terminal, y me escupe Command not found.

Yo estaba escandalizado. Creí que de hecho lo difícil en una distribución normal era quitarle el compilador de C a la máquina; no que uno tuviera que ponérselo de hecho.

Como sea eso fue fácil de resolver: apt-get funciona casi tan bien como emerge (y sin duda es más rápido instalar paquetes), y no tuve broncas instalando cosas a lo bestia.

Lo que nos dio realmente problemas fue Scigraphica, un programa que Citla usa para grafiar cosos. Por lo visto es un programa que deben usar como 2 personas, porque nada más fue imposible hacer que jalara. La versión binaria de Debian truena alegremente en un bug que Ci descubrió hace años, y la nueva no pude compilarla por más que usé todos los trucos de los cuales tengo conocimiento (que no son pocos). Hartos al final, hicimos una marranería, pero que jaló: compilamos el programa en Gentoo en otra máquina, y copiamos el binario sobre la instalación de Scigraphica de Debian.

No jaló perfecto; marca un par de errores, y con gráficas muy grandes el PostScript generado truena a la mitad de los datos. Pero jaló.

La otra bronca fue LIRC. Eso sí me molestó, porque me consta que Scigraphica lo usan pocas personas; pero LIRC es bastante utilizado, y debería haber paquetes binarios (o uno grandote) para todos los controladores para los distintos controles remotos que soporta LIRC. Dado que (¡obvio!) no tenía el código fuente del kernel, no pude ni siquiera compilar yo los módulos del kernel, y eso sí no pudimos resolverlo. Quedará para una sesión futura.

Pero exceptuando esas dos broncas, la verdad sí me impresionó lo pulido y en general amigable que está Ubuntu. Sí consideraría seriamente instalárselo a mi mamá o a mi papá en sus computadoras.

Por fin pusieron Mesa 6.5.1 en Portage, así que ahora se pueden compilar todas las dependencias de Compiz sin utilizar cualquier tipo de overlay. De hecho tambien hay un ebuild de Compiz, sólo que es la versión “simple”, sin ninguno de los plugins locochones de Quinnstorm.

Pero no importa: las últimas versiones de XGL Coffee ya traen los parches necesarios para que funcione sin problemas en AiGLX; así que ahora tengo AiGLX (que es mucho más limpio que XGL), y tengo la última versión de Compiz Quinnstorm y plugins relacionados.

Ahora sólo tengo que ponerme a trabajar en lugar de estar jugando con mi laptop.

Instalé GNOME 2.16 en mi desktop y en mi laptop, y entre las cosas nuevas y chidas que trae se incluye el GNOME Power Manager.

Yo tengo ya casi un par de meses hibernando mi máquina en lugar de apagarla, así que el que el iconito del GPM tuviera una opción “hibernate” no me impresionó en lo más mínimo. Sin embargo, además traía una que decía “suspend”, y de pura curiosidad le piqué.

Dos segundos después, mi máquina parecía estar apagada, sólo el led del encendido de la laptop parpadeaba con un color naranja. Apreté una tecla, y tres segundos después mi escritorio estaba tal cual lo había dejado.

Sin embargo, yo había leído que una máquina suspendida (que no es lo mismo que hibernada), de hecho sí consume electricidad. Lo cual tiene sentido; el suspender es virtualmente instantáneo porque la memoria no se mueve al disco duro: se queda ahí, en la memoria. Después la máquina apaga todo pero sigue alimentando tantito poder a la memoria para que no se borre: exceptuando eso, es como si estuviera apagada. Por eso mismo también es tan rápido reactivar una máquina suspendida: sólo tiene que encender el procesador y los discos duros de nuevo.

(Estoy haciendo una hipersimplificación del proceso, obviamente, pero por ahí va la onda.)

Así que no puedo sencillamente suspender mi laptop y meterla a mi mochila sin preocuparme de nada: aunque sea poquita, la máquina sigue consumiendo energía. Por ello hoy hice un experimento: antes de irme al cine, a las 19:30 exactamente desconecté el cable de poder de mi latop y la suspendí, con la batería al 100% en ese momento. Cinco horas después (a las 00:30), regresé a mi casa y reviví la máquina. ¿Total de batería que me quedaba?

96%.

Eso quiere decir que puedo dejar la laptop suspendida varios días (unos 4) sin tener que preocuparme de nada. Ya nunca voy a hibernar mi máquina; es una pendejada. La única ventaja que tiene el hibernar es que puedo dejar la laptop desconectada por un tiempo indeterminado, y que me permite bootear a Windows (que casi nunca lo hago).

De ahora en adelante voy a suspender mi laptop en lugar de hibernarla. De verdad es increíble, es casi instantáneo.

Dejé XGL y ahora estoy usando AiGLX. AiGLX es un cambio mucho menos radical que XGL; mientras que el segundo es un servidor X básicamente nuevo, el primero es sólo una extensión del servidor X normalito. Sin embargo, en ambos funciona Compiz, y además está la no menor ventaja de que para tarjetas de video Intel (como la de mi laptop), AiGLX es bastante más rápido. Y en añadidura me permite ver videos a pantalla completa y jugar Quake sin ningún tipo de problemas (en XGL era lentísimo con mi laptop; en mi escritorio donde tengo una tarjeta de video estúpidamente rápida eso no importa).

Pondría un screenshot; pero realmente se ve igual mi escritorio. Sólo se siente más rápido, además de las ventajas con videos y aplicaciones 3D. Lo malo fue que me cambié de overlay; antes usaba el de XGL Coffee, y ahora volví al de Hanno Böck, que fue el primero que intenté. Y tuve que aplicar parches a pata. Lo bueno es que parece que ambos overlays están integrándose en uno mismo.

En otras cosas, instalé GNOME 2.16. Y todo parece bien, pero hay algunas aplicaciones (Drivel y Gaim principalmente) que me truenan de manera rarísima. Tengo que investigar eso.

Estaba sintiendo medio lenta a abulafia, y de repente me fallaban las conexiones, así que entré y reinicié Apache y MySQL. Ha ocurrido que por broncas en la red de la Facultad quedan demasiadas conexiones abiertas y un reinicio de esos dos servicios es necesario.

Pero vi que rápidamente volvía a ponerse lenta la cosa, así que me puse a revisar los logs. Un ataque distribuido está siendo efectuado contra abulafia; varios hosts (56 en mi última cuenta) lanzan cientos de pedidos idiotas tratando de engañar a mi sistema de blog para que baje un script de Perl y lo ejecute. Es idiota; tengo mi blog en mi cuenta de usuario normal, y mi grupo del servidor de web no tiene los permisos necesarios, pero bueno. El script está aquí:

http://freewebtown.com/v6rulz/spread.txt

Quien quiera que esté atacando abulafia no es muy bueno; el script ni siquiera es suyo (y no funciona para mi sistema de blog). La bronca es que WordPress crea una página especial para cada código de error 404 (page not found), y supongo que eso es lo que alentaba al sistema. Así que creé la página PHP que el ataque busca, e hice que regrese un punto (.), y con eso parece estar ya dándole la vuelta al ataque. No puedo restringir el acceso al host que realiza el ataque porque son decenas, y probablemente cambien en el futuro.

Ahora, lo interesante es que este ataque parecería estar dirigido exclusivamente a mí; sólo mi blog y mi galería en línea están siendo atacados.

Como sea, ahorita ya parece estar todo funcionando normalmente, si bien algo lento porque el ataque realiza cientos de peticiones a abulafia, y aunque ahora sólo responde un punto de cualquier forma quita recursos. Ya saqué el whois de cada IP en el ataque, y veré que hago después; ahora tengo que terminar un trabajo.

Estaba acomodando mis fotos del fondue en casa de Juan (una entrada de eso más adelante), cuando me percaté de un error bastante idiota de mi parte: en mi organización por directorios de mis fotos, puse las fotos de agosto del 2006 en el directorio 2006/07, cuando debería ser 2006/08.

No es terriblemente grave, pero sí quería corregirlo. La única manera en que podría corregirlo en F-Spot sería borrar las fotos de mi catálogo, moverlas al nuevo directorio e importarlas de nuevo, volviendo a poner los metadatos. Lo cual es idiota, por supuesto.

Por suerte F-Spot guarda toda su información en una base de datos relacional usando SQLite; así que sencillamente abrí la base de datos y con tantita magia de SQL hice que ahora el directorio fuera 2006/08, y (claro) moví las fotos a su nuevo directorio. Y voilá, todo quedó chido.

Esa es una de las múltiples razones por las cuales quería un programa para manejar mis fotos que por debajo estuviera sostenido por SQL.