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.

 Imprimir entrada

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.

 Imprimir entrada

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:

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.

Vientos Sun

 Imprimir entrada

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).

 Imprimir entrada