el blog de cHagHi

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) 

Este es un resumen de la configuración de Ubuntu 6.10 en mi nueva laptop. Hace unos días había dicho que pretendía instalar Feisty Fawn (la versión de desarrollo de Ubuntu 7.04, que está en alfa 2), pero un bug en el actual kernel de esa versión me impidió hacerlo. Probablemente vuelva a intentar con alguno de los próximos alfas (hay previstos 5, creo).

Entonces, volviendo al tópico que nos ocupa, vamos a ver como me fue instalando, en lo que respecta al soporte de hardware. Fue toda una experiencia: Primera laptop, primera vez que instalo un OS en una laptop, y atrás, tenía el historial de haber ido siguiendo (en foros, listas de correo, blogs y demás) la evolución de Linux en este tipo de hardware... que ha hecho montones de progresos, pero tiene en su haber algunos capítulos tortuosos :)

En mi caso en particular, decidí usar el CD de instalación "alternativo", ya que quería absoluto control sobre como particionar el disco, y además, quería configurar LVM.

Preparación del disco

• Defragmenté la unidad C: de Windows
• Inicié un Linux reciente desde CD (en mi caso, usé el LiveCD de Ubuntu 6.04)
• Usando el editor de particiones de Gnome, achiqué la partición de Windows a 20GB, sin tocar nada más. Mi intención era achicarlo más... pero finalmente lo dejé de 20GB por si decido instalar un stack completo de desarrollo de .NET. Así todo es un montón de espacio.
• Reinicié Windows, y dejé que el scandisk chillara e hiciera su trabajo al encontrarse con que le habían tocado su disco por afuera. ¡Maricón! :p
  

Una vez que me aseguré que Windows seguía feliz en su casa achicada, volví a arrancar con Linux, y ahora sí, realicé los otros cambios:

• Eliminé la partición de Dell MediaDirect;
• Eliminé la partición de recuperación de Dell;

¿Por qué hice esto en 2 pasos? Porque ajustar una partición NTFS sigue siendo algo relativamente experimental. Con lo cual, quería tocar lo menos posible la tabla de particiones antes de dejar que Windows pudiera verificar su unidad.

Instalación de Ubuntu 6.10

No voy a cubrir el proceso de instalación (menos el del Alternate CD) acá; solo mencionaré algunos detalles (que no necesariamente son aplicables a todo el mundo, en particular en cuanto al layout de disco).

• Use el modo de particionado manual. Creé una partición extendida ocupando todo el espacio que quedaba. Dentro de esta, creé una partición de 100MB para /boot, y otra de 1GB para swap. En el resto, creé un grupo de volúmenes LVM, con 3 volúmenes lógicos: Uno de un tamaño inicial de 10GB para /root, otro de 4GB para /home, y el último de 20GB para /opt. El resto del disco quedó dentro del volúmen físico, pero sin asignar. Eso me permitirá agrandar o achicar las particiones de Linux dinámicamente en función del espacio que vaya necesitando.
• Cuando llegó el momento de instalar GRUB (el boot manager), elegí instalarlo en la partición /boot, y NO en el MBR. Esto lo hice para no correr el riesgo de perder alguna funcionalidad en el arranque manejado por Dell. Quizás fui demasiado paranoico. La verdad, no lo sé :)

El resto de la instalación... sin novedades.

Configuración del arranque

Si uno instala GRUB en el MBR, listo. Pero si no, se termina con un Linux instalado pero sin poder arrancarlo. Hay que "enseñarle" a NTLDR (el boot manager de Windows) a hacerlo. Esto está explicado en miles de lugares, pero básicamente los pasos son:

• Iniciar con un Linux desde CD;
• Copiar el primer sector de la partición de arranque de Linux en un archivo;
• Arrancar Windows;
• Copiar el archivo que contiene el sector de arranque de Linux en C:, y configurar una entrada en el boot.ini haciendo referencia a ese archivo;

Probando Ubuntu. Ajuste fino

Listo. Solo faltó arrancar Ubuntu, y entrar a probar. Anduvo prácticamente todo "out-of-the-box":

• Touchpad;
• Notificación de estado de la batería;
• Ajuste dinámico del brillo de la pantalla al (des)enchufar la laptop;
• Hibernación;
• Suspend;
• Detección del cierre de la tapa;
• Teclas especiales de la laptop;
• Manejo de la frecuencia de clock de la CPU en función de la demanda;
• Placa de red;
• Lector de tarjetas;
• ... en fin, todo. O casi todo.

¿Entonces...?

¿Qué no anduvo, o no anduvo bien?

Básicamente 3 cosas:

• Resolución correcta del LCD (en formato wide). Tuve que instalar el paquete "915resolution", reiniciar el modo gráfico, y salió andando. Hay reportes de que en las últimas versiones de Xorg, si cambio el driver "i810" (que es el default para la placa integrada Intel 950) por "intel", no hace falta el 915 resolution, pero no lo probé. Primero quiero investigar que otras diferencias tiene un driver respecto del otro.
• Placa de red inalámbrica. Acá el problema es que no se instalaron los módulos restringidos del kernel. Solo tuve que instalar el paquete "linux-restricted-modules-generic", y reiniciar. Y listo. A partir de ahí, anduvo todo, hasta la autenticación WPA (yo tuve que pelearme un rato con eso, pero por ignorancia mía...)
• Ajuste del brillo de la pantalla "a mano", usando el teclado. Aparentemente es un bug del módulo de gestión de energía del kernel que se disparó partir de cierta versión de BIOS de Dell (en laptops con BIOS anteriores funciona ok). Acá es donde tuve que hacer magia negra: agregar el módulo "video" a la lista negra de módulos en /etc/modprobe.d/blacklist. No entiendo muy bien por qué, ni que otro efecto colateral tiene eso (si tiene alguno, no lo he notado), y no deja de ser un workaround feo, pero anda. Ahora puedo apretar Fn+Up o Fn+Down y manejar el brillo de la pantalla sin problemas.

¿Conclusión? Una maravilla. 100% del hardware autodetectado, configurado y funcionando correctamente, con solo 3 ajustes manuales.

Incluso activé AIGLX en la configuración gráfica, e instalé Compiz. Funciona perfecto. Efectitos 3D, transparencia, blah, blah. Todo el eye-candy de moda. Tengo algunos glitches con la hibernación y el suspend (no funcionan 100% ok el 100% de las veces), pero dejando de lado eso, está todo super estable. Ningún cuelgue, ningún error crítico. Nada.

Y estoy absolutamente maravillado con la performance de este bichito, a pesar de que el gestor de energía del kernel me pone los dos cores al 50% de su velocidad la mayor parte del tiempo. Tengo que hacer algo muy muy pesado para que el kernel diga "ok, necesitás más procesador, te voy a dejar usar el 100% de lo que compraste" :p Y en ningún momento tuve problemas de performance. La ventaja de dejar que el kernel haga su laburo a demanda, es que como consecuencia de tener los cores de la CPU laburando al 50%, el equipo trabaja re-silencioso (casi nunca se encienden los ventiladores), y apenas tibio. No calienta prácticamente nada.

Por último, hay algunas cosas que aún no probé (algunas ni siquiera en Windows), y no se si funcionan ok o no:

• Modem
• El slot ExpressCard (no tengo con qué...)
• La salida DVI
• La salida VGA
• La grabación de CDs/DVDs (la reproducción anda perfecto; la grabación de CDs la probé en Windows; la grabación de DVDs no la probé en absoluto)
• La entrada de micrófono
• La salida de auriculares (ups! mientras escribía esto dije "probémoslo ahora". Y me acabo de dar cuenta que el enchufe no es estándar. ¿Eeeehhhh? ¿Acaso hay un mini-plug de audio más mini que el estándar de diskmans y reproductores de MP3? :( Nada. Era cuestión de hacer más fuerza nada más... :p)