el blog de cHagHi

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.

 

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

 

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.

 

Hacía rato que tenía problemas con Ubuntu en la laptop con el soporte de "Suspend to RAM".

Suspender, suspendía. El problema era al despertar. Pasaban 3 cosas:

• La pantalla no se encendía. 

• Me quedaba sin sonido. El control de volumen maestro quedaba silenciado, y además, se bajaba completamente el volumen PCM.

• Me quedaba sin wifi. Mal. El dispositivo desaparecía, el led de la laptop quedaba apagado y no respondía a la combinación de teclas Fn+F2 para encenderlo, y NetworkManager determinaba que estaba solo en el mundo, sin ningún dispositivo que atender.

Lo de la pantalla tenía un workarround: apretar CTRL-ALT-F1 y luego ALT-F7, o sea, conmutar a modo texto y volver a modo gráfico. Eso terminaba de despertar al video. Feo, pero eran dos golpes de tecla. 

El tema del sonido, también tenía un workarround: Des-silenciar el master, abrir el control de volumen, y volver a subir el volumen PCM. Me hinchaba las pelotas, sí, pero se arreglaba con algunos clics del mouse.

El tema de la red wifi tenía un workarround HORRIBLE: reiniciar :(

Hace unos días me puse a investigar más a fondo. El objetivo primario era hacer que funcione ok (i.e., que al despertar la laptop tuviera red otra vez automáticamente); el premio consuelo que estaba dispuesto a aceptar era encontrar que servicios reiniciar (y en que orden) para que volviera a funcionar, y al menos no caer en reiniciar la máquina (que es la salida típica en Windows, pero NO en Linux). 

Después de googlear bastante, la primera conclusión a la que llegué es que todo "debería" funcionar bien; los problemas que estaba experimentando eran típicos de hace un par de versiones atrás, pero no de Ubuntu 7.10. Si bien no era el único que tenía estos problemas, también era mucha la gente que reportaba que todo le funcionaba perfecto "out of the box".

¿Entonces? Empecé a bucear en decenas de bug reports y threads en foros y demás, probando tocar un archivo u otro (casi siempre, /etc/default/acpi-support), para comentar una línea o descomentar otra, o cambiar cierto parámetro... pero nada. El tema no se arreglabla. Finalmente, terminé encontrando un post en un foro donde un usuario daba la siguiente receta, al iniciar luego de un suspend:

• parar el servicio de networking;
• parar NetworkManager;
• forzar la descarga del módulo del kernel correspondiente a tu placa wifi (en mi caso, ipw3945); 
• volver a cargar el módulo;
• iniciar networking;
• iniciar NetworkManager;

Voilá!. Andaba. Y era suficientemente sencillo como para armar un pequeño script que automatizara eso, cosa que terminé haciendo. Cada vez que la laptop salía de un suspend, corría el script, y volvía a tener red. Además, claro, tenía que seguir despertando "a mano" el video y el sonido. Feo. Pero ya había dado un paso: No reiniciar.

Pero todo esto me dejó pensando... si todo se limitaba a reiniciar servicios, ¿entonces por qué no andaba? ¿Por qué hay N personas a las que no les andaba, y M personas a las que sí? Y entonces empecé a confirmar la sospecha de que al fin y al cabo todo era producto de los upgrades sucesivos de una versión de Ubuntu a la siguiente. Este tema (el power management) hace un año y pico atrás tenía problemas. Ahora estaban resueltos. Pero probablemente algo (vaya uno a saber qué...) no había sido correctamente pisado, reconfigurado o reemplazado en alguno de los upgrades, y por eso me seguía funcionando a medias.

Y decidí probar lo siguiente: La mayoría de las recetas para arreglar estos problemas implicaban modificar el archivo /etc/default/acpi-support. ¿Qué pasaría si eliminara COMPLETAMENTE (incluyendo la configuración) el paquete "dueño" de ese archivo, y lo reinstalara?

Ejecuté un

$ dpkg -S /etc/default/acpi-support

y me enteré que el archivo es parte del paquete acpi-support. Probé desinstalarlo, y APT me dijo "no! no podés desinstalar eso, porque el paquete powermanagement-interface depende de acpi-support". Igual, decidí forzar la desinstalación ignorando las dependencias (total, pretendía reinstalarlo inmediatamente después, con lo cual no iba a quedar nada roto), pero ya que estaba metí en el trámite también a ese otro paquete:

$ sudo dpkg --purge --force-depends acpi-support
$ sudo dpkg --purge --force-depends powermanagement-interface

Listo. Con el --purge me aseguraba de haber eliminado también toooooodos los archivos de configuración, y que por lo tanto al reinstalarlos, se configurara todo de cero. A reinstalar:

$ sudo aptitude install acpi-support powermanagement-interface

Y listo! ¿Adivinen qué? Ahora anda todo 100% Ok. La laptop suspende perfecto, y se despierta perfecto, con video, sonido y wifi.

Algunas moralejas de esta historia:

• Por maravilloso que sea actualizar el sistema operativo "on the fly", de una versión a otra, es muy complicado que el proceso cubra el 100% de los detalles. Y esto se potencia cuando las actualizaciones se acumulan (yo ya voy por el 3er upgrade, y en un par de meses sale Hardy, e iremos por el 4to...)

• Si algo no te anda, y a otras personas sí, y tu instalación no fue hecha desde cero, empezá a sospechar de que algo haya quedado mal por ese lado.

• Si empezás a tocar acá y allá, y no obtenés resultados, y a la larga lo que estás buscando es la configuración "por defecto" en la que todo debería andar, empezá a preguntarte si no es mejor purgar completamente el componente de software en cuestión, y reinstalarlo para que se autoconfigure solito.

• APT (el sistema de paquetes) es una joyita. Es fantástico poder llegar de un archivo a un paquete, poder desinstalarlo COMPLETAMENTE, incluyendo a la configuración, y que la reinstalación se ocupe de auto-configurar todo nuevamente.

• Linux es fantástico por su modularización, y por permitir estas cosas. Ok, en un mundo ideal esto no debería pasar, y tampoco la solución es para cualquiera (no la veo a mi vieja por ejemplo siguiendo estos pasos), pero una vez ante el problema, prefiero mil veces lidiar con algo así en Linux, al que le puedo preguntar donde le duele (¡y me responde y todo!), que en Windows, donde no queda otra que recurrir a la magia negra... o reinstalar TODO, ABSOLUTAMENTE TODO.

 

Y así pasaron las Sextas Conferencias Abiertas de Software Libre y GNU/Linux.

Al igual que el año pasado, Python fue el lenguaje con más presencia en las conferencias, tanto en charlas, como en "comunidad". Esto es un logro de todo PyAr, pero creo que merece ser destacado el esfuerzo de Alecu, Dani, Dave, Lucio y Facu generando contenido, y el de los chicos de Santa Fe y Córdoba, siempre presentes. Como siempre, y a pesar de los reparos que yo en lo personal tengo al respecto, pyWeek vende. Y tener dos OLPC (gracias Educ.ar!) en el stand para mostrar, fue como tener un tarro de miel a un metro de un hormiguero... :)

Otro "debut" de este año fue la cartelera de trabajo, organizada por Alecu: http://python.com.ar/trabajos. Además de su contrapartida web, estuvo "físicamente" en forma de un gran afiche junto a nuestro stand, y todo el tiempo ví gente tomando nota.

Hubo muchas menos charlas que el año pasado, y creo que eso es un plus. Como comentábamos con los chicos de Lanux anoche, eso ayudó a subir el nivel: Hubo mucha menos superposición de contenidos, y más gente en cada charla. No si es esto fue casual o la gente de CaFeLUG específicamente buscó este efecto... pero es para tomar nota.

De las charlas a las que asistí, me quedo en especial con dos:

• "Python más rápido que C", por Lucio Torre y Facundo Batista. Una muy entretenida e ilustrativa charla para mostrar que sí, que a veces Python es (bueno, casi...) más rápido que C, y que otras tantas, C es más rápido pero, ¿vale la pena el esfuerzo? Habían generado mucha espectativa con su charla, el título de entrada fue un gancho de marketing fenomenal. Y salieron muy bien parados de la prueba. Felicitaciones.

• "Caperucita en el Bosque", por Enrique Chaparro, de la Fundación Vía Libre. Excelente. Sumamente ocurrente, en cuanto a usar el cuento de caperucita roja como analogía e hilo conductor de la charla. Muy amena. Y muy ilustrativa. Esta fue la "Key note", la única charla plenaria. Espero que se haya grabado... traten de buscarla, bájenla y véanla. Vale la pena.

El cierre de CaFeConf quedó una vez más a cargo de Leito Monk, y al igual que el año pasado, estuvo absolutamente desopilante. NADIE, absolutamente NADIE se esperaba verlo entrar al escenario disfrazado de pingüino, y gritando "developers! developers! developers!" La organización de todo el evento estuvo muy bien, realmente la muchachada de CaFeLUG labura un montón para esto... y se nota. Gracias!

El único punto "flaco", al igual que el año pasado, fue el lugar: UADE no es el mejor ámbito para estas conferencias. Los cacheos de seguridad, LENTOS y BUROCRATICOS son sumamente molestos. Así y todo, desapareció una laptop. Y algo me dice que UADE va a mirar seguramente para otro lado (ojalá que no... but I'm not holding my breath...). Pero bueno, por ahora, es lo que hay. 

En cuanto al aspecto puramente social y pythonico, la noche del viernes nos fuimos a tomar unas cervezas por San Telmo. La excusa oficial fue festejar los buenos resultados de los grupos argentinos en la última edición de pyWeek... y terminó siendo una pseudo-reunión de PyAr. Luego de pasar un rato en una coqueta parrilla de San Telmo de la cual no recuerdo el nombre (ni lo quiero recordar...), en la que solo tomamos unas cervezas, terminamos en la pizzería Tío Felipe, en Balcarce y San Lorenzo. BUENISIMO. La pasamos genial. Y como siempre, los lugares más tradicionales, más "de barrio", son los mejores. Si alguien de Tío Felipe lee esto: Sigan así. No se dejen aggiornar por la movida "transformemos San Telmo en un lugar solo apto para europeos con euros". Ojo, no tengo NADA en contra del turismo europeo... solo de los comerciantes inescrupulosos argentinos que arman una mentira cara para vender a los turistas, que NO tiene nada que ver con la escencia de uno de los barrios más antiguos y tradicionales de Bs. As., y hacen que solo puedas salir a comer afuera por la zona si a), te creés la mentira y b) estás dispuesto a pagar por un servicio que no lo vale.

La noche del sábado, un pequeñísimo grupo de PyAr (Dave, Alecu y yo) acompañamos a los chicos de Lanux a tomar algo... oooootra vez, una muy buena cervezeada con picada y pizza, en el local de Zapi de Independencia y Perú.

Fotos, fotos y más fotos.

 

¿Notan una mezcla rara en este screenshot?

:)

Es un nuevo chiche de la versión 1.5 de VirtualBox. La llaman "Seamless windows", y lo que hace VB en este modo es ocultar el escritorio del sistema operativo guest (Windows XP Home en este caso), para lograr una mayor integración con el host.

Por ahora, únicamente funciona para Windows como "guest", y no al revés, y requiere que sí o sí el sistema operativo virtualizado tenga instaladas las "guest additions".

Ya había visto (aunque no probado) experimentos similares usando QEMU, y también pruebas sobre VirtualBox, pero en ambos casos usando un feature de Windows Terminal 6 (o superior) que permite que el cliente en lugar de recibir el escritorio completo de Windows pueda recibir solamente la ventana activa. Entonces, el truco era correr Windows virtualizado en background, y luego abrir alguna aplicación mediante el cliente Terminal Server de Linux. Pero esto tiene varios drawbacks:

• Es bastante complejo de configurar / administrar

• Funciona únicamente para Windows, y solamente versiones de windows que tengan implementado el RDP (Remote Desktop Protocol), lo cual te limita a versiones Professional o Enterprise (no Home) de Windows XP o superior.

• Por una limitación de RDP, solo se puede trabajar con una aplicación simultánea (aunque creo que algunas versiones de Windows, o con configuraciones especiales, esta limitación podía salvarse).

El approach que eligió VirtualBox me gusta más. Si bien por ahora funciona solo con Windows, funciona en CUALQUIER Windows en el que sean instalables las Guest Additions. No depende de ninguna configuración de networking entre host y guest. Puedo abrir todas las ventanas y aplicaciones que quiera. Y calculo que a futuro implementarán esto también en las guest additions de Linux y MacOS. Mi impresión personal es que arrancaron con Windows porque hay más usuarios que corren Windows sobre Linux que al revés.

Y lo más lindo: Funciona out of the box. No tuve que hacer nada más que actualizar VirtualBox, arrancar la virtual machine que tiene instalado Windows, actualizar las Guest Additions también a 1.5... y listo. Con CTRL-L conmuto entre el modo seamless y el normal.

 

El anuncio de prensa de hoy de Dell, marca todo un hito en la historia de Linux. Si bien hace mucho tiempo que proveedores de hardware preinstalan alguna versión de Linux en algunos modelos de PCs o laptops, es la primera vez que se combinan dos cosas:

• Estamos hablando de un vendedor main-stream (Dell), con presencia mundial y llegada a muchos (sino todos) paíes.
  
• Se hace oficialmente a través de la empresa detrás de la distro (en este caso, Canonical), con programas de certificaciones y soporte;

Impresionante.

Tal como recapitula el anuncio, todo comenzó en febrero: Dell tuvo la iniciativa de poner en línea un sitio web en el cual sus clientes podían participar proponiendo ideas sobre nuevos productos. Y fue enorme la cantidad de gente que dijo "quiero Linux preinstalado". Y Dell escuchó. A partir de ahí, hubo varios comentarios oficiales de Dell, diciendo "Los escuchamos, y lo estamos evaluando". Y parece que era verdad.

Desde el punto de vista tecnológico, no me sorprende: Mi laptop funciona de maravilla con Ubuntu (y por caso, estoy seguro que funcionaría igual de bien con cualquier otra distribución reciente), y el tema es aún más fácil en desktops. Los puntos ríspidos son los de siempre: nVidia, ATI, Broadcom, los winmodems... pero hoy, si uno no se pone religioso con lo de "free software", y acepta por ejemplo el driver oficial de nVidia (de código cerrado), las cosas funcionan muy bien. Hay workarrounds. Igual, imagino que aunque sea para facilitar el mantenimiento y soporte de los equipos, Dell priorizará aquellos productos en los que tiene un stack de hardware más fácil de soportar, como por ejemplo, un chipset 100% Intel.

Desde el punto de vista comercial, tampoco me sorprende: Hacía rato que estaba esperando que algo así pasara, ya que si bien el mercado de Linux no es enorme (comparado con el de Windows), es obvio que estratégicamente la primera empresa que se vuelque a ofrecerlo en forma masiva, se va a ganar la simpatía de una comunidad de usuarios que suele hacer mucho ruido, y suele ser muy idealista. ¿Adivinan que empresa va a recomendar ahora cualquier "geek" usuario de Linux a sus amigos / familiares no-geeks? Adivinaron. El otro plus, es que en esa comunidad hay muchísimos desarrolladores. Muchos. Y los desarrolladores son muy importantes... (¿se acuerdan de un tal Steve Ballmer a los gritos en un escenario? yo sí). Con este movimiento, Dell se está poniendo a una buena porción de la comunidad Linux en el bolsillo. No me caben dudas. Y Canonical da un enorme paso que lo ayuda a consolidar su nicho de "orientado al usuario" (en contraste con Red Hat / Novell, que apuntan más al mercado enterprise).

¿Entonces? ¿Por qué esto no pasó antes?

Creo que por un lado, Linux no estaba listo. Hace un par de años, o más, hubiera sido comercialmente inviable para una empresa como Dell ofrecer Linux. Aún había muchas aristas que pulir. Ojo, el OS en aquel entonces ya era excelente para desarrolladores, entusiastas, gente que venía del mundo UNIX y usuarios avanzados. Pero NO para doña Rosa.

Además, la fragmentación de Linux, con las decenas (¿centenas?) de distros existentes, nunca ayudó. Hoy, si bien sigue habiendo múltiples opciones, fueron surgiendo "líderes". Y Canonical viene consolidándose en un terreno que Red Hat y Novell nunca pudieron / quisieron. Y Dell, para ofrecer algo así, necesita tener del otro lado a una empresa. No le sirve la "comunidad XXX".

Y por último, esto no hubiera pasado si Microsoft no se hubiera debilitado un poco. En el medio, Dell también creció. Ojo, igual, cuando entren a la página de Dell, verán propaganda de Windows Vista por todos lados... y está ok. Pero la realidad es que Microsoft tardó demasiado tiempo en salir al mercado con Vista, y los vendors (como Dell) y los usuarios están teniendo problemas. Y así como Dell hace propaganda al Vista pero "por atrás" sigue vendiendo equipos nuevos con Windows XP, ahora va a elegir algunos productos de su línea y les va a poner Ubuntu. Hay una realidad, y es que MS ya no tiene la fuerza de antes para imponerle a cualquiera cualquier cosa a cualquier precio. Menos a Dell. Menos cuando MS no puede aplicar su trillada estrategia de "comprar al enemigo" (ya le gustaría a MS poder "comprar" Linux y guardarlo bajo 7 candados... pero no, no está en venta), o copiarlo (¿se imaginan a MS dando su código fuente libremente?)

¿Qué haremos esta noche, Cerebro?

Terminé mi serie de upgrades de Ubuntu 6.10 a 7.04, los cuales son esencialmente 2 :p (mi desktop y mi laptop).

Creo que con este upgrade terminé de aprender, o de convencerme, que una línea de ADSL 256 NO es apta para actualizar un OS completo. Es MUY lento, y el upgrade es un proceso "atómico", en cuanto implica la descarga de centenas de archivos, y cuando la ventana de actualización es de más de 8hs, hay muchas cosas que pueden salir mal. Y el upgrade no es un proceso que sea cancelable/resumible así nomás.

Con el desktop, me pasó que últimamente vengo con problemas de temperatura, y se apaga. La semana pasada cambié la fuente, que estaba andando decididamente mal, y supuse (parecía) arreglado. Bueno, no :( El sábado a la tarde inicié el proceso de upgrade vía internet, y seguí con mis cosas. A la noche, cuando volví a casa, seguía descargando. El domingo a la mañana, la PC estaba apagada. Damn. Y lo que es peor, ya no booteaba. Se apagó en medio de la instalación, no del download, con lo cual, mitad de los paquetes estaban actualizados/instalados, mitad estaban desconfigurados pendientes de instalación, un desastre.

Pero, esto es GNU/Linux, y el upgrade no hace nada de magia negra... tan solo baja los .deb nuevos, y luego, ejecuta una enooooooorme transacción de apt que los instala/configura. Así que lo que hice fue iniciar con el Live CD de Ubuntu 6.04 (Dapper Drake), montar mi partición root de disco, hacer un chroot, y reiniciar la configuración de paquetes pendientes. Eso anduvo... a medias. Es que por desconocimiento, no monté los filesystems /proc y /sys, y la mitad de los scripts de post-instalación fallaban por eso. Después de innumerables intentos, llegué a un entorno chrooteado "sano", y pude terminar.

Si te pasa lo mismo, la secuencia de pasos correcta sería, desde una consola del LiveCD:

$ sudo mkdir /target 
$ sudo mount /dev/mapper/lv_root /target   #reemplazando /dev/mapper... por el dispositivo que contenga el filesystem root 
$ sudo mount /dev/hda2 /target/boot #opcional, solo si tenés /boot en una partición independiente, y (obviamente) reemplazando /dev/hda2 por lo que corresponda en tu caso 
$ sudo mount -t proc proc /target/proc 
$ sudo mount -t sysfs sysfs /target/sys 
$ sudo modprobe dm-mod # opcional, si tenés un array o usás LVM2 
$ sudo chroot /target

y luego, desde el entorno chroot

# dpkg --configure -a # para terminar de configurar los paquetes que estén pendientes
# aptitude update && aptitude upgrade && aptitude dist-upgrade
# aptitude dist-upgrade # por las dudas...
# apt-get -f install # también x las dudas...

y listo.

El otro tema, es que según como tengas la partición/boot, desde el chroot puede verse diferente, con lo cual al instalarse las imágenes del kernel, el menú del gestor de arranque puede quedar mal configurado. En mi caso, quedaba con referencias a /boot/linux-image-... cuando en realidad es /linux-image-...

Antes de reiniciar por primera vez, conviene verificar en /target/boot/grub/menu.lst que todo esté ok.

Finalmente, anduvo todo joya. No perdí datos (obvio), y mejor aún, no perdí configuraciones / customizaciones, y se actualizaron todos los programas ok. Mi PC había quedado actualizada a Fesity Fawn. Se sigue apagando después de 6 a 8 hs de funcionamiento continuo... pero por supuesto eso no es problema de software.

En base a esa experiencia, para la laptop tomé un camino diferente: Bajé la imagen ISO del CD alternativo de instalación, monté el ISO como si fuera un CD (jeje... ni siquiera me tomé el laburo de quemar un CD real), y disparé el Upgrade desde CD. Con eso, TODOS los paquetes base ya los tenía de una, con lo cual, el instalador solo bajó de internet las cosas accesorias (así y todo, fueron más de 250Mb de descarga). Pero fue mucho más rápido / confiable. Y no tuve que embarrarme las manos en una consola (ok, solo un poquitito, para montar el ISO, pero eso es solo un comando... casi que no lo contamos, ¿no?)

Tarea cumplida. Mis dos compus están actualizadas a la última versión de Ubuntu. Todavía no pude apreciar mucho las mejoras, más allá de lo que es puramente look&feel (el artwork está más pulido).

 

Desde que instalé Ubuntu en mi laptop que vengo tratando de hacer que Evolution empiece a filtrar correctamente el correo basura. Como me gusta más bogofilter que spamassassin (porque consume MUCHOS menos recursos), activé el plug-in correspondiente, desactivando el otro (spamassassin es el default). Además, instalé el paquete bogofilter, y le di un curso rápido de spam vs. no spam alimentándolo con varios cientos de mails "buenos" y mails "malos" que tenía guardados. O sea, hice todos los deberes.

Y sin embargo, nada. Todos los días terminaba con el inbox lleno de correo basura. Los primeros días no le dí mayor importancia, porque bogofilter es un filtro estadístico, y necesita aprender. Pero... después empecé a sospechar, porque primero que aprende RAPIDO, y por otro lado, yo le había dado un "curso acelerado" de entrada.

Empecé a escarbar, y encontré que la base de datos que se va alimentando con el correo basura no estaba siendo actualizada. Incluso si yo manualmente marcaba un mail como spam, la base de datos seguía teniendo el mismo tamaño, fecha y hora de modificación con los que había quedado luego de mi importación inicial de mensajes.

Empecé a googlear para tratar de encontrar si a alguien le había pasado lo mismo, y nada. Hay varios problemas con el filtro de spam en Evolution, todos relacionados con que suele ser algo que por un motivo u otro no anda bien de entrada, pero no encontré nada respecto a mi problema específico.

Hasta que se me ocurrió correr a Evolution desde la línea de comandos, para poder ver los mensajes que tiraba, si es que tiraba alguno. ¡Bingo! Cada vez que yo marcaba un mensaje como spam, Evolution decía que no podía ejecutar el filtro de spam porque no encontraba el programa /usr/bin/bogofilter

¿Cuál era el problema? Que yo había instalado bogofilter-sqlite, la versión de bogofilter que usa SQLite como backend para almacenar los mensajes, en lugar de la versión que usa BerkeleyDB. Y el ejecutable de esa versión es... /usr/bin/bogofilter-sqlite 

Fácil de arreglar. Solo tuve que crear un link simbólico y listo. Pero...

No debería haber tenido que correr Evolution desde la línea de comandos para enterarme que algo estaba fallando "por atrás". Si yo activé un plug-in, y al disparar en la GUI un comando se ejecuta el plug-in, y el plug-in falla porque no encuentra un archivo, YO QUIERO VER UN ALERTA EN LA GUI.

El Zen de Python, entre otras cosas dice:

Errors should never pass silently.
Unless explicitly silenced.

Sabias palabras Mr. Tim Peters. Muy sabias palabras.

(Launchpad bug: #81581)