el blog de cHagHi

Finalmente, después de bastantes experimentos, creo que logré una configuración de manejo de correo electrónico en la laptop que me satisface. Y no te dejes engañar por el "Evolution" del título: En realidad, bastante de la experiencia aplica a cualquier MUA, o a cualquiera que quiera independizarse del MUA (ver "Bonus track" final), o simplemente a cualquiera que quiera tener un backup del correo de GMail local accesible incluso off-line.

Background

Mi cuenta de correo principal, la que más uso, está en GMail. La aplicación web está excelente, y ahora que me estoy acostumbrando a los "atajos de teclado" (¿por qué tardé literalmente *años* en tratar de aprenderlos e incorporarlos a mis dedos?), aún mejor. Pero así y todo, me gusta sentir que no dependo de una conexión a internet para acceder al correo histórico, y me gusta tener un backup, con lo cual necesito que el correo esté bajado en mi disco, para poder accederelo con algún MUA.

Hasta hace unas semanas, accedía a GMail con Evolution usando POP3. Desde que empecé a usar GMail que hacía esto. Y tenía múltiples filtros de correo entrante y saliente que redistribuían los mensajes en N carpetas de Evolution que, más o menos, equivalen a una etiqueta en GMail. Por otro lado, tenía (tengo) años de historia de correo electrónico que no es de GMail, principalmente, de mi vieja, querida y deprecada cuenta de Sion. Entonces por ejemplo en la carpeta "Amigos", tengo todo el correo de mis amigos, no solo el de los últimos 3 años en GMail, sino también el histórico.

El tema es que a medida que empecé a usar más y más GMail, y especialmente, desde que empecé a usarlo desde distintas computadoras, en distintos ámbitos, y con diferentes clientes, me choqué contra lo obvio: POP3... #noescala (chiste interno para los twitteros... je). Leer una cantidad de correos durante el día, etiquetarlos, acomodarlos, y a la noche prender la laptop y volver a bajarlos como correo "no leído", es una porquería. Muchas veces me pasaba que "leer" correo en la laptop en realidad era ir carpeta por carpeta en Evolution marcando los mensajes como leídos, sin siquiera abrirlos.

Boludo, ¡usá IMAP!

Hace bastante GMail habilitó IMAP. Cualquiera diría que es la solución. Pero... siempre hay un pero (en este caso, varios)

La implementación de IMAP de GMail suckea un poco. Lo de exponer los labels como folders tiene el inconveniente de que los correos que tienen N etiquetas, los bajás N veces (¿tantos recursos le sobran a Google que fue por este camino, en lugar de mapear las etiquetas a IMAP keywords, y dejar que las carpetas las manejes vos?). Por otro, la filosofía de "no borres el correo, archivalo", sumado a lo de las etiquetas, hace que cuando accedés a GMail con IMAP desde un cliente, algunas operaciones no sean obvias, o no hagan lo que vos pensás que deberían hacer. Aún hoy estoy tratando de incorporar algunas de estas cosas de manera definitiva en mi cerebro.

Así y todo, decidí sacrificar mi estructura histórica de carpetas, reemplazarla por la estructura "plana" que me da GMail (sí, ya se, si usara etiquetas con "/" en medio, automáticamente en la interfaz IMAP se traducen en una jerarquía de carpetas, pero no me gusta), y acceder vía IMAP.

Ahora, ¿qué hacía con las carpetas con el correo histórico? Vieron que los MUA en general cuando configuran una cuenta IMAP, como que crean una sub-estructura de carpetas nuevas, con su propia bandeja de entrada, papelera, correo enviado, borradores, más las carpetas de esa cuenta. Así que en cuanto hice el switch, el primer escollo es que en Evolution pasé a tener 2 grandes nodos: Correo viejo bajado por POP3, de GMail, de SION y otras cuentas, y el correo nuevo que iba entrando por IMAP. Y además, había una superposición: Todo el correo de GMail que había bajado durante años via POP3 estaba también accesible vía IMAP (repetido).

Para resolver eso, me tuve que embarrar las manos. Una solución hubiera sido escribir un script que leyera las carpetas en formato mbox de Evo y analizando los headers de los correos los copiara en las carpetas IMAP... pero no tengo experiencia manipulando correo a bajo nivel, y tampoco tengo TANTAS carpetas (ni tanto correo, apenas unos cientos de MBs), así que lo fui haciendo a mano: En cada carpeta de Evo, seteaba un filtro que básicamente era "mostrame el correo que entre los remitentes o destintatarios tenga a mi cuenta de sion o la cuenta de mi ex laburo y no tenga mi cuenta de GMail", y al correo resultante lo arrastraba a la carpeta (label) correspondiente en la cuenta de GMail.

Esto efectivamente "sube" (o importa) el correo en GMail, así que estuve un bueeeen rato haciendo esto. Y después me topé con este bug de GMail: El correo importado desde IMAP queda con la fecha incorrecta (con la fecha del día que lo importaste) en la interfaz web. Así que ahora tengo miles de correos en GMail que si los accedo desde la web, o si los busco, tienen la fecha en que los importé. Como internamente la fecha está bien (desde cualquier otro cliente se ve la fecha correcta, e incluso dentro de la interfaz web de GMail, en la vista de conversaciones se ven bien), supongo que algún día Google lo arreglará (aunque el tema es un known issue desde hace más de un año...)

Bueno, pero entonces, listo, pasaste a IMAP, y fuiste feliz, ¿no?

No

IMAP en Evolution *sucks*

Y por lo que leí, IMAP en Thunderbird también, y hasta IMAP en mutt suckea en algunos aspectos, así que malo por malo, me quedo con el malo que conozco, que encima es el MUA oficial de Gnome, y por lo menos tiene resuelta la integración con el desktop de manera decente.

Evo por default baja solo las cabeceras de los mensajes. Así que navegar por las carpetas se vuelve lentísimo, porque se tiene que conectar al server a bajar el mensaje. Obvio si el mensaje no está completo, no tengo un backup en disco. Y tampoco puedo hacer búsquedas locales, ni acceder al correo viejo si no tengo internet. Se le puede decir a Evo que baje todo el correo. Y lo hice. Lo dejé una noche haciéndolo. Pero resulta que el tipo así y todo ¡¡¡NO baja los attachments!!!. E igual, aunque tenga el correo cacheado en disco, cuando te parás encima del mensaje el tipo "dialoga" con el server IMAP para ver si el mensaje sigue existiendo, si le cambió algún flag, etc., o para bajar el attachment que no bajó. Es *lento*. Navegar por las carpetas de Evo se vuelve una tortura, y eso que no tengo cientos de miles de correos en cada carpeta, ni mucho menos. 

La única manera de leer correo sin que sea leeeeeeeento, es decirle a Evolution que labure "off line". Entonces el tipo se desconecta, no habla más con el server IMAP, y se deja de joder. Pero... no tengo los attachments. Y si entra nuevo correo, no me entero. Y si hago cambios localmente en el correo (los borro, los muevo, etc), no se impactan en el server hasta que no vuelvo a decirle a Evo que labure on line. Sucks. Sucks *big time*.

Después de considerar momentáneamente cambiar de MUA, decidí que ese no era el camino. En múltiples foros me encontré con que Thunderbird tiene issues también. Y no iba a volver a Thunderbird, cuya integración con Gnome es *pésima*, para sufrir más o menos lo mismo. Y no iba a pasarme a un MUA geek de terminal, como mutt o SUP, no gracias. No soy *tan* geek. Encima SUP está escrito en Ruby (yikes!).

Enter OfflineIMAP

Resulta que hay un programita, hecho en Python (¡Python rocks!), llamado OfflineIMAP, que básicamente sirve para sincronizar una cuenta IMAP con un repositorio local en formato Maildir. Puede hacer unas cuantas cosas más, como sincronizar múltiples cuentas, o sincronizar un IMAP con otro, y así, pero en esencia, el tipo es eso: un algo que lee un repositorio remoto (IMAP), y lo sincroniza contra uno local (Maildir u otro IMAP), y en el medio, podés poner reglas (esto sí, esto no, lo de esta carpeta pasalo a esta), y esas reglas muchas veces son expresiones de Python, o invocaciones a funciones de Python que realizan la conversión :)

Y todos sabemos que manejar tu correo con Python gives you a warm and fuzzy feeling :)

Así que hice eso: Configuré OfflineIMAP, y luego apunté a Evo a la carpeta raíz de la estructura Maildir, y voilá. *It flies*. Y encima, el formato Maildir es mucho más robusto que un mbox: tengo un archivo por correo, así que si por puta se corrompe un archivo, se pierde UN correo, no mil.

No voy a exponer acá un tutorial detallado de como configurar OfflineIMAP (hay *mil* recetas en la web), pero si voy a dar algunos tips que me resultaron interesantes, o que descubrí a fuerza de darme algún palo:

Muchos tutoriales te dicen que para configurar OfflineIMAP para GMail y luego accederlo con Evo tenés que mover ciertas carpetas a un nodo "root", porque si no Evo no entiende bien la estructura Maildir. Esto es parcialmente falso. La única carpeta problemática es el INBOX, que tiene que ser la raíz de la estructura Maildir, y GMail la expone como "/INBOX", no como "/". Esto se resuelve así en tu .offlineimaprc:

nametrans = lambda foldername: re.sub('^INBOX', '.', foldername)

Puede que NO quieras bajar la carpeta "Spam" de GMail, ni la carpeta "All Mail". La última es un tema... en mi caso, como soy bastante histérico con el etiquetado de correo en GMail, es raro que un mensaje quede sin etiquetar. Si está etiquetado, lo tengo en por lo menos una carpeta IMAP (y si tiene N etiquetas, en las N carpetas); si no está etiquetado, en general no es importante. Anyway, la forma de exluir una o más carpetas de la sincronización es la siguiente:

folderfilter = lambda foldername: foldername not in ['[Gmail]/Spam', '[Gmail]/All Mail',]

Dejarlas afuera tiene los siguientes caveats:

• No hay forma de reportar un correo como SPAM desde tu estructura Maildir. La forma de decirle a GMail desde IMAP que un correo es Spam es moverlo a dicha carpeta, pero como no la estás sincronizando...
• No hay forma de "desetiquetar" por completo un mensaje. La forma de hacerlo es mover el mensaje a la carpeta "All Mail", pero como no la estás sincronizando...

De nuevo, eso último es personal. A mi, me sirve así.

Ya que hablamos de carpetas, no dejen de leer estos tips de Google. Básicamente:

• No mapeen la carpeta "Correo enviado" de su MUA a la carpeta Sent. Google copia automáticamente los mensajes que salen por su SMTP a la carpeta Sent.
• No mapeen la "Papelera" de su MUA con la carpeta Trash de GMail, a menos que quieran efectivamente *borrar* el mensaje en lugar de archivarlo. Google recomienda lo último (archivar). La manera de borrar sería arrastrar el correo a la carpeta trash. Si atan la papelera de su cliente con el Trash de Gmail, no tienen forma de hacer el equivalente al "Archive" de GMail desde el cliente... a menos que también estén sincronizando la carpeta "All Mail", en cuyo caso, el Archive sería mover el correo a la carpeta All Mail.
• Sí mapeen la carpeta "Borradores" de su MUA con la Draft de GMail, así los tienen sincronizados.

Por último, un detalle: No me gustaba mucho tener la clave de GMail volcada textualmente en un archivo de configuración. Pero resulta que OfflineIMAP puede invocar a una función de Python que le devuelva algunos settings, entre ellos, la password y el usuario de la cuenta IMAP (o de GMail). Así que pensé, ¿no podré tener la password en el keyring de Gnome, hacer un script de Python que lo recupere, y decirle a OfflineIMAP que use eso? Si, puedo. Y alguien ya lo había hecho :) Miren acá.

Bonus track

Lo bueno de tener a OfflineIMAP en el medio volcando tu correo en un Maildir estándar, es que ahora mi copia local del correo es independiente del MUA :)

Si mañana me canso de Evolution, solo tengo que poner el MUA que quiera apuntando a mi repo local, y ya está. Y si quiero probar un MUA nuevo, no necesito hacer NADA. Hasta puedo usar diferentes MUAs simultáneamente.

 

 

Terminé de migrar a Jaunty. Esta vez, fue una experiencia diferente. Tenía intenciones de hacer un clean-install, manteniendo mi $HOME y mi /opt, que están en particiones independientes. Siempre termino usando el CD "alternativo", porque mis particiones están sobre LVM2, y Ubiquity, el instalador de la versión Desktop no lo soporta.

Resulta que anoche iba a quemar el .iso... y me encuentro con que no tenía ni un CD virgen. Últimamente estoy volviendo a micro-blogguear bastante en Twitter, y desde hace poquito también en Identi.ca, y cuando postié "Iba a aprovechar el release de Jaunty para hacer un clean install, y me acabo de dar cuenta que no tengo ni un CD para quemar el .iso", bugabundo, alguien que ni conozco y que no es un follower directo mío en identi.ca me respondió "@chaghi do you have a USB stick? you can use that!".

Eso motivó un par de intercambios en identi.ca con este flaco, con un poco de google en paralelo, y un ratito después había aprendido lo siguiente:

• Hay *algo* en identi.ca que evidentemente permite que pongas en tu "radar" determinadas keywords o tags o algo y eso hace que te enteres de determinados posts aunque no seas suscriptor del usuario. Hay todo un manejo de tags y grupos en identi.ca sobre el que tengo que investigar un toque;

• La herramienta Sistema -> Administración -> Creador de discos de arranque USB que Ubuntu tiene desde hace un par de versiones te automatiza el proceso de hacer booteable un USB, y meterle el contenido de un .iso (normalmente, correspondiente al CD de instalación de Ubuntu) para poder arrancar, instalar, o probar desde ahí. Es automágico, no es destructivo (i.e., no te borra lo que ya tengas en el pendrive), y hasta te sugiere reservar una especie de micro-partición en el USB para hacer persistentes los cambios, onda que luego si arrancás con el pendrive, y guardas un archivo en tu Escritorio, por ejemplo, lo estás persistiendo en el USB, y no en RAM como sucede normalmente con el LiveCD.

• El Desktop CD tiene *algo* de soporte para LVM. En particular, la herramienta de particionado manual de Ubiquity NO puede crear volumenes LVM nuevos, ni te deja tocarlos mucho, pero si está preparada para reconocer a los que existan, y usarlos en la instalación.

Así que por primera vez en la vida, decidí bajar el Desktop CD en lugar del Alternativo, e instalar con Ubiquity. En mi caso, y por este tema de tener LVM en el medio, hay dos detalles a tener en cuenta:

No puedo arrancar el instalador directo desde el menú de arranque. Tengo que bootear la version Live de Ubuntu, instalar lvm2 (¿que les costará meterlo por defecto en el CD?), activar mis volumenes LVM, lanzar Ubiquity, instalar seleccionando particionado manual, y a lo último NO REINICIAR. Antes, debo hacer un chroot a la instalación en disco, e instalar lvm2 también ahí, ya que Ubiquity NO lo instala.

Es un poco tricky, no es algo que le recomendaría a mi madre, pero digamos que si estoy usando LVM2 es porque no soy precisamente un newbie, así que el workarround tampoco es terrible.

Después de todo eso, llegué a las siguientes conclusiones:

• Realmente no tiene sentido hacer el "Upgrade" de una versión a otra. El Upgrade tarda muchísimo más que una instalación limpia, aún tomando los paquetes base desde el CD. Mucho más. Un Upgrade es un proceso de un par de horas, a veces más, mientras que instalar Ubuntu con Ubiquity lleva algo así como 20'/30'. Nada que ver. Ok, parte del tiempo del upgrade es tiempo que con un clean install perdés después bajando soft adicional (más sobre esto luego)... pero igual.

• El Upgrade tiene la ventaja de que preserva los datos, pero teniendo particiones independientes... es lo mismo. Usás la misma partición para tu $HOME, le decís al instalador que no la formatee, y ya. La otra ventaja del Upgrade es que tiene cierta heurística de migración que hace que si algún default cambió, y vos tenés todavía el default anterior (y no un setting custom), te pone el nuevo default. Al hacer un clean-install eso no lo tenés, y a veces tenés que luego jugar un poco con las configuraciones para activar un feature nuevo que de otro modo no ves porque está "tapado" por una configuración legacy, digamos, pre-existente en tu $HOME.

• El Upgrade no solo preserva datos en tu $HOME, sino system-wide, con lo cual cualquier cosa que hayas toqueteado en por ejemplo /etc, también se mantiene. Pero hacer un backup de /etc es trivial, y pisar luego en la instalación nueva los 2, 3 o 4 archivos que al menos en mi caso podés llegar a tener con configuraciones extra, es también trivial. Si fuera un server sería más complejo, obvio, pero al menos en la laptop... hacer rato que me vengo apegando a las configuraciones por defecto, y de última a centralizar cualquier cosa custom dentro de mi $HOME, y no como algo global.

• Por último, el Upgrade preserva todo tu software extra, y te lo actualiza, mientras que si hacés un clean-install, todo lo que no provee el CD y tenías instalado, tenés que volver a bajarlo. Pero no me jode. El tiempo de downloading a la larga es el mismo, y a su vez ayuda a cada 6 meses PENSAR si vale la pena volver a instalar ese programa que habías instalado para probar algo, y lo ejecutaste solo una vez ese día y nunca más...

¿Conclusión? Dudo mucho que vuelva a usar el Update Manager de Ubuntu para hacer una actualización completa de la distribución. Me parece que me acabo de hacer fan de los clean-installs.

Ahora, respecto a Jaunty:

Arranca notablemente más rápido que Intrepid y las versiones anteriores. Parece un sistema operativo del siglo XXI corriendo en hardware medianamente nuevo y todo :) ¡Bien ahí! Parece una boludez, pero una de las cosas que más me estaba hinchando las pelotas de Intrepid es que el arranque se tomaba un minuto o más hasta el login screen, y luego otro tanto para levantar Gnome. Ahora en menos de un minuto ya estoy laburando.

Tengo una relación de amor-odio con el nuevo Notify-OSD. Si, es sleek. Se ve re-lindo. Pero las notificaciones desaparecen rapidísimo, a veces te las perdés, no todo el soft está usando ese esquema.

El OS en general se nota mejor en performance, excepto en la parte de video, por ciertas regresiones en los drivers de Intel. La verdad se notan. Hay algunos workarrounds experimentales para eso (como habilitar UXA), pero dicen que es a costa de estabilidad... así que ni probé.

El look-and-feel de Ubuntu la verdad ya me aburrió. Los community-themes que ahora se incluyen como alternativas (Dust, Dust-Sand, etc) están buenos, pero tienen muchos detalles. Cositas acá y allá que no se ven bien, o aplicaciones a las que no les gusta y cosas así. Y sí, hay BOCHA de themes para Gnome, pero la verdad... todos tienen detalles, y encima, todos tienden a copiar a Vista, o a copiar a OS X. A la larga, el más pulido es el default, así que volví a Human. Pero estoy aburrido de Human. Espero que para Karmic hagan algo piola y DIFERENTE. Realmente espero que Canonical le pague a un grupo de designers profesionales para que hagan algo lindo, usable, pulido, pero que a su vez se vea como Ubuntu, tenga identidad propia, y no parezca un clon barato de Vista u OS X.

Jaunty ya tiene soporte para ext4. Aún no es el filesystem por defecto, pero ya que estaba reformateando la partición root, esta quedó en ext4. Cero problema. Y quizás eso esté contribuyendo en parte a las mejoras en el booteo.

El tiempo de inicialización de Gnome se arregló. No se que tenía mi profile, que tardaba un montón. Y si me logueaba con otro usuario con un $HOME "limpio", era mucho más rápido. Por un lado le sospechaba a la encripción; por otro, a algún software adicional. Pero el tema es que no toqué mi $HOME, reinstalé básicamente el mismo soft que tenía (al menos en cuanto a los que están colgados del inicio de sesión de Gnome), y mantuve exactamente la encripción, y sin embargo los 30"/45" que después del login se perdían con el disco andando a full haciendo vaya uno a saber que cosa que nunca pude identificar, hasta que aparecían los paneles, se fue. ¡Bien!

All in all, so far I'm a happy Jaunty Jackalope user.

 

¿A veces en el laburo tenés la PC, y una laptop al lado?

¿A veces tenés que trabajar con dos o más equipos al mismo tiempo?

¿Esos N equipos están en red?

Enter Synergy. Es un pequeño soft para compartir un teclado y un mouse de manera transparente a través de la red, con varios equipos. Básicamente configuran uno de los equipos como "server" (el que va a compartir su teclado/mouse), y los demás como clientes. Configuran las relaciones entre ellos, diciéndole al soft "la PC tal está a la izquierda de cual, la PC foo está a la derecha de la PC bar", y listo.

Cuando mueven el mouse hacia el extremo de la pantalla, el puntero "pasa" al otro equipo, junto con el control del teclado.

Y lo mejor, está disponible para Linux, OS X y Windows.

Para Windows, tienen un instalador que incluye una GUI para configurar todo (de manera bastante poco amigable, let me tell you...)

Para Linux / OS X, tienen por un lado un paquete que es la librería más los daemons (cliente y servidor), que pueden configurar mediante un par de archivitos de texto, y por otro lado, pueden bajarse QuickSynergy, que los provee de una linda y sencilla GUI (bastante más intuitiva que la de Windows).

Si usan Ubuntu, tienen synergy y quicksynergy en Universe.

No voy a explicar acá como se configura... Google is your friend, y hay bocha de gente que ya se dedicó a eso en sus blogs.

Yo lo estoy usando estos días en el laburo, para manejar la PC (Windows XP) y mi laptop (Ubuntu 8.10), y anda joya!

 

• Si programan sin hacer testing, hay tabla.
• Si no comentan el código, hay tabla.
• Si no respetan los estándares, hay tabla.
• Si se quejan de la performance, hay tabla.
• Si preguntan boludeces, hay tabla.
• Si cuelgan el servidor con un loop infinito, hay tabla.
• Si reportan el mismo error dos veces, hay tabla.
• Si me hacen laburar un fin de semana, hay tabla.
• Si los casos de uso no están bien escritos, hay tabla.
• Si no versionan, hay tabla.
• Y si preguntan por esto, hay tabla.

Gracias Seba por el original!

BTW, habría que hacer una gigantografía, y colgarla en un par de lugares... 

 

En breve me voy por trabajo una temporada a MDQ, y entre todas las cosas que tengo que hacer, tengo que decidir que cosas dejo operativas en el depto, y cuales no. La idea es viajar a Baires regularmente (calculo que cada 20 días), con lo cual no tengo intenciones de hacer un shutdown *full* de mi casa.

¿Qué hago con la PC? Es un tema. Si bien es normal que esté varios días encendida, haciendo de file-server o alguna otra huevada, no me gusta mucho la idea de que esté encendida y desatendida tantos días seguidos. No le tengo confianza a la fuente, ni a los coolers (ya me pasó una vez llegar a casa, encontrar la PC apagada, la fuente quemada, y ese olorcito a "algún aparato se quemó"). Una cosa es que este encendida permanentemente dejándola sola a lo sumo un par de días, y otra dejarla encendida sin saber a ciencia cierta cuantas semanas pasarán hasta que alguien le eche un ojo al depto. La realidad es que hace mucho tiempo tengo pendiente invertir en una PC más nueva, y de paso prestarle atención a la alimentación, la refrigeración, el ruido, y el cablerío infernal que es hoy el escritorio en donde está. Pero eso sigue sin resolverse, y ya no tengo tiempo de resolverlo antes de la partida.

Mi equipo principal de trabajo hoy es la laptop, no la PC, pero la verdad me gustaría saber que estando en MDQ puedo contar con la PC. Por ejemplo, para mantener sincronizados y backupeados regularmente los datos de la laptop. Para tirar algún proceso largo. Para bajarme algún album de mi colección de MP3. Whatever. Entonces, no quiero dejar la PC encendida... pero me gustaría irme a MDQ sabiendo que puedo prenderla en forma remota si la necesito unas horas. 

Así que me propuse volver a la carga para intentar configurar "WOL", o Wake-On-LAN, que no es otra cosa que un feature que tiene que estar soportado por el BIOS, la placa de red, el mother y la fuente, y que permite mandar un "magic packet" por la red para prender el equipo.

Alguna vez había intentado configurar esto, sin éxito, pero tampoco le dediqué tiempo. Ahora tenía un motivo para investigar más a fondo, así que me puse manos a la obra. El desafío tenía 3 partes:

• dejar de usar la placa de red 3com, y pasar a la nVidia
• hacer que WOL funcione desde la LAN, o sea, lograr encender la compu desde otro equipo que es parte de la red local
• hacer que WOL funcione desde la WAN (algunos llaman a esto WOW), o sea, lograr encender la compu desde internet

Cambiando 3com por nVidia

Mi mother tiene 2 placas de red integradas. La primaria es una placa nVidia con chipset Realtek, la secundaria es una placa 3com con un chipset Broadcom. Resulta que había una época, hace muuuuuchos años, cuando compré la PC, en que el driver "forcedeth" de Linux (el que se usa para nVidia) no andaba ni pa'tras. Así que hacía rato que usaba la placa 3com. También había una época en que NetworkManager era bastante choto en cuanto a configurar una IP fija y/o a levantar la conexión ANTES de loguearte, así que medio tenía by-passeado a NetworkManager, con una configuración medio mirame-y-no-me-toques que nunca entendí del todo, y tampoco quería tocar porque... bueno, para que tocar lo que anda, ¿no?

Pero resulta que de las dos placas, la que soporta WOL es la nVidia. Fuck. Así que por eso el primer desafío era cambiar de placa de red. De paso, si quieren investigar que cosas soporta cierta placa, se lo pueden preguntar a ethtool:

$ sudo ethtool eth0
Settings for eth0:
...
Supports Wake-on: g
Wake-on: g
...

ethtool les va a decir varias cosas. En el ejemplo de arriba dejé solo las salidas relevantes. Supports Wake-on:... está seguido de una seriede flags (letras), indicando todas las opciones de wake up soportadas por la placa. En mi caso, solo soporta "g", que es WOL usando un "Magic Packet" (más sobre esto, luego). La línea Wake-on:... nos muestra, dentro de las opciones soportadas, cuales están efectivamente activas.

Bueno, el tema es que hace una semana hice el cambiazo, y empecé a usar la placa nVidia. Hice este cambio con tiempo para poder testear que todo ande bien. La buena noticia es que los años que pasaron desde la última vez no han sido en vano, y aparentemente el driver forcedeth just works. Y NetworkManager sigue teniendo sus no pocas mañas, pero al menos ahora se puede configurar una IP fija y cambiar de una configuración a otra sin tener que encomendarte a ningún espíritu para que funcione.

So far, so good.

Configurando WOL

Además de tener una placa que soporte WOL, esta configuración tiene que estar soportada por el mother y activada en la BIOS. Por defecto, no lo está. El nombre con el que aparece puede ser bastante críptico, en mi caso, la configuración está dentro de Power Management, y la opción que hay que habilitar es "Power Up on PCI Device". Por otro lado, esto tiene que estar soportado por tu fuente... pero a menos que estemos hablando de una XT no debería ser problema, ya que me parece que alcanza con que la fuente sea ATX.

Por último, si la placa de red no está integrada (i.e., no es parte del motherboard, y es una placa PCI aparte), es muy probable que en algún lado tenga un conectorsito específico de WOL en el cual habrá que chantar un cable que en el otro extremo termina en el conectorsito WOL del motherboard. En mi caso todo esto no existe porque la placa está integrada al mother.

Hasta ahí estamos con el hardware y la BIOS... el siguiente paso, es configurar el sistema operativo.

Primer problema: El soporte WOL no está activo por defecto. Si tiráramos el comando que mostraba más arriba, veríamos el soporte para WOL "g", pero no lo veríamos activo. Hay que activarlo, y que yo sepa, no hay otra que hacerlo vía ethtool:

sudo ethtool -s eth0 wol g

(reemplazando eth0 por el dispositivo de red que se desea configurar si fuera otro)

Segundo problema: La activación no es persistente. Cada vez que se reinicia la PC, y el kernel reinicializa el hardware, esa configuración se pierde. Al menos es así con forcedeth. Así que tuve que crearme un pequeño servicio para que active WOL en la placa de red cada vez que se enciende el equipo.

Idealmente, debería haber *algo* en la infraestructura de networking de Linux para configurar esto, y de manera permanente, y los DEs (por ejemplo, Gnome) deberían brindar alguna GUI para hacer la configuración... pero por ahora hay que ensuciarse las manos :(

¿Y ahora? Si los planetas están alineados, y apagamos la PC normalmente, y desde otro equipo dentro de la LAN enviamos un Magic Packet, la PC debería encenderse.

¿Y qué es eso de un "Magic Packet"? Si quieren detalles pueden leer por ejemplo acá, o googlear sobre WOL, pero básicamente un Magic Packet es un datagrama UDP de 102 bytes (pueden ser más si se configura un password), en el que se envía el byte 0xFF 6 veces, seguido de la MAC address de la placa de red de destino repetida 16 veces (seguido opcionalmente de un password). Hay múltiples utilidades para generar ese tipo de paquetes. Yo me bajé un script en Perl que se llama, en un derroche de originalidad, "wakeonlan" :p, porque es lo que tenía más a mano (está en los repos de Ubuntu).

Y este script, en su forma más simple, se usa así:

$ wakeonlan xx:xx:xx:xx:xx:xx

donde xx:xx:xx:xx:xx:xx es la MAC de la placa de red.

Pero resulta que no andaba, no andaba, y no andaba. Después de MUCHO googlear (no quiero ni sacar la cuenta de las horas que perdí en esto...), y gracias a un comentario reciente en este post de hace mil años de un foro de nVidia, descubrí que forcedeth tenía un bug que hacía que la MAC se interprete al reves. Supuestamente lo arreglaron, pero aparentemente en algún punto se rompió otra vez. Así que si tu placa de red es nVidia, usas forcedeth y un kernel reciente, y tu MAC es 01:02:03:04:05:06, tenés que generar el Magic Packet como si fuera para la MAC 06:05:04:03:02:01. ¿No era OBVIO? :(

La buena noticia es que... ANDA!

Configurando WOW

Hasta acá, debería ser fácil. Si tu hardware lo soporta, si tu BIOS está bien configurada, si los drivers de la placa de red del operativo no fueran una mierda, y si tu SO te facilitara la configuración de esto (en Windows, por ejemplo, al configuración está un poco escondida, pero ESTA, y es persistente), deberían ser un par de clics.

Ahora, querer que esto ande desde internet... es otra historia. Porque ahí tenés que pasar por al menos un router (el tuyo), y si el mismo no es más o menos "de verdad" y no tiene soporte nativo para WOL, vas a tener que recurrir a algún "hack" para convencer al router de que cuando reciba el Magic Packet, se lo pase a la PC.

Mi router es un D-Link DI-524, y es bastante pedorro. No tiene soporte para WOL. Así que hay que empezar a probar trucos. ¿Dónde está la complejidad? WOL funciona haciendo un broadcast. Dentro de una LAN eso está bárbaro, pero desde una WAN, obviamente uno no puede hacer un broadcast al universo. Básicamente tenés que mandar el Magic Packet a tu IP pública. A menos que tengas un servicio con IP fija, primero tenés que resolver como saber en un momento dado que IP te asignó tu ISP. Esa es una historia que tengo resuelta desde hace rato con DynDNS, así que hasta ahí, todo OK.

Ahora, el tema es como hacer para que el router retransmita el Magic Packet, y lo haga llegar a la placa de red de destino. Si el mismo no te da ninguna solución nativa entre las opciones de configuración, la solución pasa por configurar un virtual server, y hacer que por ejemplo los paquetes UDP sobre el puerto 9 (que ese el que se suele usar para WOL) los envíe a la IP-tal, donde IP-tal es la IP de tu PC. Y acá es donde las cosas se empiezan a complicar...

Obviamente, el primer paso es que tu PC tenga siempre la misma IP interna. En mi caso, tengo esto configurado así desde hace rato, así que vamos bien, pero el tema es que la PC va a estar apagada. Mandamos el Magic Packet a la IP pública. El router lo recibe. Como está en el puerto 9, y hay un Virtual Server definido para ese puerto, se encuentra con que tiene que mandar el paquete a la IP-tal de la LAN. Entonces manda un request ARP preguntando "¿quién tiene la IP tal?". Y resulta que la PC está apagada para contestarle :(  Normalmente el router cachea esta información, así que si uno apaga la PC e intenta un WOL a los pocos minutos, puede que ande. Pero después de un (normalmente) corto tiempo, ya no.

Si el router fuera más o menos bueno, uno podría cargarle un registro estático en su tabla ARP, diciéndole que a la IP-tal le corresponde la MAC-tal, y listo. El router ya no necesita hacer un request ARP para esa IP. Pero mi router no permite manipular la tabla ARP, así que no es una opción.

En estos casos, lo que uno puede hacer es configurar el Virtual Server para que use como IP privada la IP de broadcast de la LAN, entonces, cuando el router recibe el Magic Packet, lo termina broadcasteando hacia adentro. Pero... no siempre el router te deja definir como IP privada de una regla de virtual server a la IP de broadcast. En mi caso, me dejaba definirla, pero cuando recibía el paquete, se colgaba !!!

A todo esto: Yo no sabía absolutamente NADA de IP broadcasting, tablas ARP y demás conceptos de ruteo, así que fui sorteando cada nuevo obstáculo con la ayuda de google y muchos golpes contra la pared. En particular, este hilo en este foro está BUENISIMO. Fue gracias a ese hilo que aprendí un montón de cosas, y que fui dando con las soluciones. Gracias a la experiencia de otro usuario con mi mismo router, llegué a la conclusión de que tal vez si actualizaba el firmware del router iba a solucionar el tema del cuelgue del mismo al recibir el paquete.

Generalmente no soy NADA amigo de actualizar el firmware de ningún equipo, a menos que tenga un problema que sí o sí necesito resolver, y esté seguro que la nueva versión de firmware lo arregla (y cierta garantía de que no rompe otras cosas en el proceso...). En este caso, si bien dejar funcionando WOL no era de vida o muerte, y la única "evidencia" de que con un firmware más nuevo lo podía arreglar era la experiencia de UN usuario en UN post de UN foro encotrado al azar en internet... decidí tirarme a la pileta. Más que nada, por calentura.

Así que algunos minutos después, estaba rebooteando el router con firmware nuevito. Así y todo... WOL desde internet seguía sin andar. El avance fue que ya el router no se colgaba (bien!), pero la PC, ni se inmutaba. Seguía apagadita apagadita. Lo parió.

Después de un rato más de Google y paseo por diversos foros, y cuando ya casi estaba por mandar todo a la reputamadrequelopario, encontré en Ubuntu Forums un flaco que hablaba de microWOW, un MIDlet para celulares que permite generar paquetes WOW. No le tenía mucha fe, ya que había probado UN MONTON de servicios web para generar paquetes (además del script 'wakeonlan' que me había bajado, y además de varias pruebas armando paquetes "a pedal" con Python), pero perdido por perdido, decidí probarlo.

Y funcionó! Aún no se por qué, pero so far es la única alternativa que me anda fuera de mi LAN.

El por qué es un misterio. Me bajé los fuentes, y constaté que no hace ninguna magia rara. Es más, me armé una pequeña aplicación de consola en Java usando el código ese como base, y no me anduvo. Constaté que lo que hace ese MIDlet aparentemente es lo mismo que hace el script en Perl que había bajado, y lo mismo que hice con diversos experimentos con Python, pero la realidad es que TODOS los intentos por generar un Magic Packet desde internet no me funcionan, excepto si lo genero desde el celular con microWOW (por otro lado, TODOS los experimentos que hice SI funcionan desde adentro de la LAN).

Misterio.

Lo bueno es que tengo una alternativa... lo malo es que con tanto tanto tanto tiempo invertido, me encantaría saber a que le estoy pifiando cuando genero el Magic Packet con otra herramienta, porque TIENE que ser una boludez, tiene que ser algo que evidentemente Java Micro Edition hace por default con los sockets, que es diferente de lo que Java Standard Edition hace, y es diferente de lo que yo hago desde Python, y lo que wakeonlan hace con Perl.

En un momento se me ocurrió que el problema tal vez era que en definitiva con mis experimentos el paquete se estaba generando desde dentro de la LAN, mientras que con microWOW se estaba generando posta desde afuera (con el celular), pero hice la prueba de mandar un paquete conectándome vía SSH con otro server fuera de mi LAN, y tampoco anduvo.

Conclusiones

• mientras tenga mi celular a mano y servicio GPRS, puedo encender la compu de casa en cualquier momento
• configurar WOL no es trivial, hay muchas variables en juego
• el soporte para WOL en Linux al día de hoy es bastante pedorro, y hay que hacer todo a mano y desde una consola
• configurar WOW es muy complejo a menos que tengas un router de verdad, y no uno de los juguetes que uno suele comprarse para la casa
• aprendí bastante sobre enrutamiento y broadcasting de paquetes...
• ... pero no lo suficiente como para entender por que el único generador de paquetes que me anduvo es microWOW

Si este no es a la fecha el post más largo en este blog (a excepción de los relatos de viajes), le pega en el palo...

 

Estuve investigando el supuesto camino de pre-compilar módulos para ver si lograba resolver los problemas de performance que mencioné hace unos días.

Resulta que la punta del iceberg estaba escondida en el pack de ejemplos de IronPython, que se descarga aparte. En ese paquete está, entre otras cosas, el famoso pyc.py, parte de cuyo README nos cuenta:

This sample demonstrates the use of the Python Hosting APIs to compile Python files into .NET executables.  The behavior of the generated files is actually quite similar to that of CPython files with the ".pyc" file extension.

Bueno, ni tanto. El script de ejemplo solo es un programita de consola para compilar en bloque una serie de módulos, y generar un assembly. Básicamente, es una interfaz al nuevo método CompileModules del CLR, y hay una explicación bastante detallada de como funciona todo esto acá.

A menos que me esté perdiendo de algo, sinceramente no entiendo de donde sacan que el funcionamiento de todo esto es "similar al de los archivos CPython de extensión .pyc".

Veamos por que:

• Explícitamente tengo que compilar los módulos. En CPython, esto es transparente.
• Explícitamente tengo que indicar cual es el módulo que actuará como "entry point". En CPython, esto no es necesario.
• Si compilo varios módulos, termino con un único assembly con todo. En CPython, cada .py genera su propio .pyc.
• Pero lo más importante: Para usar el módulo compilado, tengo que cambiar los fuentes que lo consumen (importan). En CPython, el uso de los .pyc por parte del intérprete es completamente transparente.

El último punto es re-importante, y es la diferencia más grave. En CPython, si tengo un módulo foo, en el archivo foo.py, lo importo así:

import foo

... y resulta que si ese módulo está pre-compilado en foo.pyc, es lo mismo. Para mí no cambia nada. El intérprete agarra el .pyc. Y es más: El intérprete se ocupa de determinar si el .py cambió (es decir, si el .pyc ya no es válido).

En IronPython, al usar la compilación de módulos, y asumiendo que ya me haya tomado el trabajo de generar foo.dll (lo que me están vendiendo como "equivalente a un .pyc", para usar el assembly tengo que hacer esto:

clr.AddReference("foo.dll")
import foo

Y eso tiene varios problemas:

• El código dejó de ser compatible con CPython (por el uso de clr)
• Si alguien borra el assembly, el código pincha
• Si foo.py sufre algún cambio, y nadie lo recompila, sigo levantando la foo.dll con el código viejo, y capaz ni me entero

Todo es más o menos workarroundeable: Podría tener un módulo clr "dummy" que no haga nada en CPython, podría meter el AddReference en un try/catch, podría crearme un modulito genérico que generalice toda esta magia, e incluso se ocupe de verificar si el assembly debe ser recompilado... pero no es el punto. Esto NO es lo mismo que un .pyc.

Anyway, estuve jugando con el esquema. Aplicarlo a algo como Cheetah es muy complejo, porque está compuesto por muchísimos módulos. ¿Cuáles compilo? ¿Todos? ¿Algunos? ¿Genero un solo assembly? ¿Genero un assembly por cada módulo? ¿Cuál es la diferencia? La documentación oficial sobre todo lo que tenga que ver con la compilación estática de scripts es sumamente escasa, por no decir inexistente.

Lamentablemente, no llegué a ningún resultado útil. Si compilo Cheetah, igual sigue tardando una bocha en importarse, y lo que es peor: ¡Después no anda! Se importa aparentemente ok (tardando...), pero luego al usarlo empiezan a producirse errores extraños, inesperados.

También noté que si compilo un programa de consola, tengo problemas por ejemplo con sys.argv. En la versión compilada, pierdo los parámetros (sys.argv es siempre ['']).

Conclusión: El esquema de compilación estática no es transparente, no funciona igual que los .pyc de CPython, es más engorroso de usar, obliga a cambiar el código fuente, no acelera la importación, e introduce side-effects y errores inesperados.

Me parece que el equipo de desarrollo de IronPython debería volver a leer el Zen de Python...

Mientras tanto, este esquema a nosotros no nos sirve. No solo no nos resuelve la performance, sino que nos obliga a armar toda una magia para implementarlo, y encima, después funciona a medias, o directamente no funciona.

Hace un tiempo vengo haciendo diversas pruebas con IronPython 2, principalmente por sus mejoras en compatibilidad con CPython, y sus mejores opciones de integración con VS (en particular VS 2008).

A partir de aquel experimento que alguna vez comenté, en el laburo decidimos usar Cheetah e IronPython como núcleo de nuestro generador de código. Hace un tiempo había empezado a experimentar con IronPython 2, y me dí contra la pared cuando descubrí que Cheetah (en su momento el único template engine que encontré que andaba con IronPython) ya no funcionaba del todo bien, y que además, era *lentísimo*. Oportunamente reporté esto en CodePlex, pero básicamente parecía haber quedado en el olvido.

Los problemas de Cheetah en el peor de los casos podían salvarse con un par de workarounds, pero implicaba tocar bastante código de nuestro lado, y además caer en cosas no recomendadas por la doc de Cheetah. Así que no era lindo. Pero además, lo de la performance era... intolerable. Simplemente intolerable.

Así que seguimos usando IPy 1.1.

En los últimos días me hice de algo de tiempo para probar IPy 2.0.1, la última release estable de IronPython. Y me encontré con 2 gratas sorpresas:

• Cheetah funciona otra vez as expected;
• parte de los problemas de performance están resueltos;

Eso último, parcialmente: Lo que encontré es que usando IPy 2.0.1, el generador de código funciona perfecto, y descontando la inicialización de Cheetah, incluso es por lo menos un 30% más rápido que IPy 1.1. ¿Lo malo? La inicialización de Cheetah es PATETICAMENTE lenta.

¿A qué le llamo "inicializar Cheetah"? A un simple

from Cheetah.Template import Template

Eso en CPython es instantáneo. En IPy 1.1 tarda segundos (más de 5", y a veces hasta 10"), y en IPy 2.0.1 tarda el triple que en IPy 1.1

¿Es un problema de Cheetah? No. Es un issue conocido en IronPython que los module imports son lentísimos, y que a veces muchas de las mejoras de performance de IronPython sobre CPython a nivel runtime se pierden porque de pronto en medio de tu código tenés un inocente import que se lleva el 80% del tiempo de ejecución. Una reverenda cagada. Mal.

IPy 1.1 tenía una opción SaveAssemblies que permitía guardar las DLL que generaba el intérprete. Eso ayudaba un poco, aunque no mucho en el caso de los imports. El tema es que esa opción no existe más en IPy 2.x. Supuestamente, para IPy 2.x se estuvo trabajando en una precompilación similar a la de CPython (algo parecido a la generación de .pyc), y por más que el tema está mencionado en las release notes y todo, no logro encontrar como cuerno se activa y/o usa y/o implementa eso. De todos modos no tengo muchas esperanzas, porque leí en varios lugares que de nuevo, en el caso de los imports, esta precompilación no aporta mucho, pero en nuestro caso algo es algo, y me gustaría probarlo.

Dear lazy web, does anybody know how to test the "precompile" feature of IronPython 2.x?

 

¡Bien! La beta4 de IronPython 2.0 va a incluir la librería estándar de Python. En el laburo estamos usando bastante IronPython para algunas herramientas internas. Y siempre me molestó que por un lado hacían un laburo realmente MUY BUENO en brindar un runtime de Python perfectamente integrado con .NET, y por el otro... le sacaban las baterías (para los no iniciados: solemos decir que "Python viene con las baterías incluídas", por lo amplia, útil y poderosa que es la librería estándar que uno obtiene out-of-the-box cuando lo instala).

La realidad es que no van a incluir TODA la stdlib; hay cosas que hoy por hoy ya se sabe que no funcionan (mayormente, módulos que en todo o en parte están implementados en C, y para los cuales no se hizo ningún wrapper "managed" del lado de .NET). Pero es algo.

Otro punto positivo: IronPython 2.0 va a salir con una licencia dual: La licencia MS-PL de Microsoft, que cubre IronPython, y la Python Software Foundation License, cubriendo la stdlib. Esto es todo un hito: MS acepta, y reconoce, la licencia de la PSF. Según comentan en otro blog, hasta hubo abogados de por medio para poder dar este paso. Bien por la PSF, bien por el software libre, y bien MS.

IronPython 2.0 va a ser compatible con Python 2.5, lo cual agregará varios chiches por sobre 1.1, y probablemente habilitará a que funcionen algunos módulos de terceros que hoy por hoy no funcionan.

Aún tengo pendiente probar todo esto; en particular, quiero aprovechar estas últimas betas para verificar que nuestras herramientas funcionen correctamente con el nuevo runtime.

(gracias Facu por pasarme la data)

 

El reproductor de música del Nokia 6131 es bastante pedorro. Básicamente porque no ofrece una buena interfaz para navegar la colección de música. Por practicidad, trato de replicar en la MicroSD del celu la misma estructura de archivos que tengo en la PC y en la laptop, a saber:

/Jukebox
/Jukebox/Artista 1/
/Jukebox/Artista 1/Album 1/
/Jukebox/Artista 1/Album 2/
/Jukebox/Artista 2/
/Jukebox/Artista 2/Album 1/

... etc.

Con ese esquema, si le digo al reproductor que tome como carpeta base a /Jukebox, me "aplana" toda la colección en una lista, ordenada como puede. Donde el como puede depende de la metadata de los mp3, y del orden en que se hayan copiado los archivos en la MicroSD. Particularmente esto último, hace que la lista sea cualquiera, especialmente si uno arrastra N carpetas con archivos de una al teléfono, porque el orden en el que se escriben en el filesystem no está garantizado.

Entonces la opción cuando quiero escuchar el album Foo del artista Bar, es reconfigurar el reproductor para que tome solo esa carpeta. Pero esto tampoco está bueno, ni es óptimo, porque:

• Es lento navegar hasta la carpeta para seleccionarla;
• Es lento el re-escaneo de los temas, particularmente si hay muchos archivos en la MicroSD (y como es de 1GB, normalmente hay muchos...)
• No me soluciona el problema del orden. La lista me queda circunscripta a un artista/album, pero si los archivos que conforman el álbum no están en el orden correcto... alpiste.

¿Entonces? De acuerdo al manual del teléfono, y a las opciones que da el reproductor en los menúes, todo parecía indicar que había *algún* tipo de soporte para playlists. Pero por más que intentaba crearlas, no encontraba como. Googleando un poco, encontré que sí, que hay soporte de playlists, pero que no se pueden crear desde el teléfono. Son las clásicas M3U, así que son fáciles de escribir, pero el teléfono no te deja ponerlas en cualquier lado (bah, dejar te deja, pero el reproductor de música no las reconoce). Tienen que estar en una carpeta especial semi-oculta en la memoria del teléfono... y solo las podés crear con el Nokia PC Suite, que es un software muy bueno y muy completo, pero del cual no hay una versión para Linux. Ufa.

Googleando un poco más, terminé dando con varios posts de gente que había encontrado donde se guardan las playlists, y daba pistas de como copiarlas al teléfono con gnokii o gammu.

Resulta que una vez que juntás todas las piezas, no es tan complicado. Por ejemplo, con gnokii:

• La memoria del teléfono se accede como drive A:
• Las playlists se guardan en A:\predefgallery\predefplaylist\
• La microSD es el drive E: ^[1]
• Además, las playlist (archivos .m3u) tienen que estar en formato DOS (terminación de línea de DOS)

En general, el soporte out-of-the-box de mi Nokia 6131 en Linux es bastante decente. Cosas como conectarse via bluetooth, o con el cable USB en modo "transferencia de datos", enviar y recibir archivos, están perfectamente integradas y soportadas. Subir música al teléfono es conectarlo (vía bluetooth o con el cable), y hacer drag&drop. Pero Nokia con esto de obligar a que la playlist esté en la memoria del teléfono, y siguiendo sus convenciones absurdas me caga, porque para acceder a la memoria del teléfono, hay que caer en cosas como gnokii, que es software hecho por geeks para geeks, y no es muy amigable ni para configurar ni para usar. :(

Pero una vez configurado, y conociendo dónde y cómo hay que guardar las listas, es relativamente sencillo, y hasta no debería ser tan complejo escribir una linda GUI que permita seleccionar archivos en la tarjeta de memoria, crear una .m3u para los mismos, y subir la lista a su cornudo directorio-secreto-oh-nokia-eres-tan-brillante.

Hasta que tenga tiempo de encarar la GUI, por ahora me armé un script en python que a través de gnokii lista un directorio en particular de la MicroSD, y escupe por stdout la lista de temas que encuentra en ese directorio en formato m3u, y ordenada por nombre de archivo.

Ejemplo:

$ nokia_m3u.py  "E:/Jukebox/Mikael Bolyos/A Family Affair" \
> "A Family Affair.m3u"

Y después tengo que subir la playlist a su directorio especial:

$ gnokii --putfile "A Family Affair.m3u" \
"A:/predefgallery/predefplaylist/A Family Affair.m3u"

Es bastante directo, pero si escribiera una GUI para arrastrar los archivos y grabar la .m3u en el teléfono directamente desde ahí, estaría mucho mejor. Veremos si invierto tiempo en eso...

^[1] Jugando un poco más con gnokii descubrí que la microSD también puede accederse como drive B: (parecerían ser sinónimos), pero como Nokia PC Suite crea las .m3u usando E:... decidí respetar eso. Y la memoria del teléfono también es visible como drive C:

 

Terminé la migración de la compu y la laptop a Ubuntu 8.04. Esta es la segunda versión LTS, o Long Time Support. Inicialmente iba a esperar algunos días más para migrar, pero hoy tenía tiempo, estaba aburrido, y venía probando los últimos dos betas y el RC sin mayores problemas, así que me animé.

El mayor miedo era que dejara de andar la placa wi-fi de la laptop, ya que en los últimos kernels de Linux se viene trabajando en un refactoring de código importante de la infraestructura de soporte para los drivers de dispositivos WLAN, que entre otras cosas, obligó a re-escribir el driver de mi placa (una Intel 3945)... que paradójicamente era uno de los más maduros, estables, fáciles de hacer andar. Y su reemplazo tenía un par de bugs que se arreglaron apenas después de la beta6. De hecho en lo que a mi me concierne sigue habiendo un bugsito que finalmente no se arregló, y es que con el nuevo driver no funciona el led que indica si la placa wireless está activada o no.

Volvamos a la actualización: En ambas máquinas el upgrade funcionó sin novedades. Al igual que las últimas veces, realicé el upgrade con el CD de instalación "Alternativo", de manera de tener la mayoría de los paquetes disponibles en CD. Eso acelera mucho el proceso, y lo hace más inmune a mirrors lentos... que estos días estaban que ardían con todo el mundo upgradeando. La PC (que actualicé primero), salió andando de una, sin ningún problema. Supongo que ayuda que hoy se transformó especialmente en un server y máquina de respaldo, y he desinstalado parva de cosas, con lo cual hoy por hoy es una configuración sumamente minimalista y estándar.

Con la laptop tuve un problema complicadito de resolver, culpa de esas cosas que es imposible probar con el LiveCD, y que hasta que no hacés la instalación posta no te das cuenta que no andan. Y culpa también de una configuración bastante particular de mi parte. Resulta que tengo mi HOME encriptado. Esto es más que nada para que si me chorean o pierdo la laptop, estar medianamente tranquilo que no desparramo por ahí un montón de info personal mía, y de amigos y familiares. Pero el approach que usé para configurar la encriptación no es precisamente el más robusto (después de todo, la idea no es proteger la info frente a un técnico de un servicio de inteligencia, sino ante un choro cabeza de mierda de los que abundan últimamente...), sino el más fácil de configurar. Estoy usando EncFS, que es un layer de encripción liviano que corre en user-space por arriba de FUSE. Esto está pensado más que nada para encriptar directorios y/o archivos individuales, pero yo tengo encriptado todo mi HOME. Y tengo instalada una magia que a través de PAM me da acceso a la info encriptada al iniciar cesión, para que sea "transparente", y no tener que estar ingresando múltiples passwords. Y resulta que la versión de libpam-encfs con la que salió Ubuntu 8.04 está compilada mal, y no se puede cargar.

El efecto fue que al reiniciar la máquina por primera vez luego de la actualización, y obviamente sin saber nada de todo esto, me encontré con que ni bien ponía mi nombre de usuario para iniciar cesión, me saltaba un alerta de "Authentication failed" (sin siquiera pedir el password). Y no había forma de entrar. Con ningun usuario. Ni desde el session manager ni desde una consola. Googleando un poco encontré que el bug estaba reportado desde hacía ya un tiempito, que es una boludez (un flag de compilación!), que está detectado, y calculo que en los próximos días saldrá un rebuild oficial del paquete con el fix. Pero mientras tanto... tuve que encontrar todo esto, bajar el source del paquete, el patch que incluyen en el bug report, y rearmar el paquete aplicando ese patch, y reinstalarlo. Todo esto desde una cesión "chrooteada" booteando con el LiveCD. Una vez detectado el problema fue fácil, pero ciertamente son esas cosas que uno resuelve por experiencia en la plataforma, mientras que un usuario final no sabría para donde correr. Aunque también es cierto que un usuario normal no tendría el setup pseudo-complicado que tengo yo (de hecho, el reporte de este bug pasó completamente inadvertido para mí, a pesar de que hacía varias semanas que venía prestando atención a posibles problemas que podrían presentarse en un upgrade, y supongo que fue así porque no es un bug que haya mordido a demasiada gente).

Sorteado ese susto... pude empezar a disfrutar la nueva versión de Ubuntu. No voy a hablar de cosas nuevas en detalle, porque hay miles de reportes y blogs y servicios de noticias publicando posts con las novedades de Ubuntu 8.04 desde hace meses. Pero si quería detenerme un poquito en PulseAudio, el nuevo sound server. Instalando un par de aplicaciones de configuración, pude probar los dos features más interesantes:

• Controlar en forma individual el volumen de cada cosa que está sonando;
• Publicar en la LAN las placas de sonido, de manera de poder hacer cosas como reproducir música en la laptop, pero escucharla por el hometheatre conectado a la PC :)

Y lo más lindo es que todo esto se configura con 2 o 3 clics en las herramientas correspondientes, y Just Works. Y es dinámico. Los servers se "publican" en la red mediante Avahi, y usan Zeroconf, así que se auto-descubren, sin configurar IPs, ni puertos ni nada. Y en cualquier momento, desde el control de volumen, uno puede "transplantar" un stream de audio de un dispositivo a otro. Impresionante. PulseAudio es multiplataforma, así que encima esto funciona en una red mixta con Linux, Solaris, FreeBSD y Windows (sorry Mac... :p)

Otro cambio muy visible, es Firefox 3 (Ubuntu 8.04 instala la beta5). Para los usuarios de Linux, es realmente bienvenido que los developers de Mozilla se hayan puesto finalmente las pilas, y hayan hecho que Gecko use los widgets nativos de la plataforma en los forms, y que Firefox herede los iconos, colores y demás look&feel de la apariencia general configurada a nivel global. Así que ahora Firefox dejó de parecer un alien. Esta fue una de las principales causas de que dejara de usar Firefox con Gnome, y empezara a usar Epiphany. Además Epiphany es mucho más liviano. El tema es que ahora Firefox3 (teóricamente...) también está mejorado en ese aspecto. Pero a su vez Epiphany usa Gecko, y muchas de las mejoras de Firefox3 son en realidad mejoras de Gecko, con las cuales las tiene también Epiphany. Conclusión: Voy a tener que probarlos bastante más codo a codo para determinar si Epiphany continúa siendo una mejor alternativa (para mí, claro está), o si vuelvo a Firefox.