el blog de cHagHi (Publicaciones sobre Software)

Buscando con DuckDuckGo

cHagHi — Thu, 22 Mar 2012 01:58:13 GMT

DuckDuckGo logo

Desde hace una semana estoy usando DuckDuckGo como reemplazo de Google para buscar.

No es un servicio nuevo, pero en su momento no le había dado mucha bola. Pero resulta que Google de a poco fue perdiendo la magia. Se nota cada vez más que lo único que quieren es enrostrarte un anuncio publicitario. Ojo, siempre ese fue su objetivo principal, pero había una época en que lo disimulaban, en que te la ponían sin que te dieras cuenta, casi.

Ahora es más evidente. Cada vez hay más resultados esponsoreados. Los resultados de búsqueda están cada vez más sucios de metadata de otros servicios, todo entreverado. Google cambió sus políticas de privacidad y si bien es cierto que son más simples, es como que ahora tienen piedra libre para usar todo lo que saben de vos para influenciar en como te muestran un resultado de búsqueda. Tal vez lo hicieron siempre, por atrás, pero ahora es explícito.

Google se caracterizaba por una página de resultados limpia, pristina, simple, minimalista. En los últimos tiempos han ido agregando iconitos y previews y colores, y +1's y paneles y barras y... está empezando a suckear.

Así que decidí probar DuckDuckGo, un poco por capricho. El diseño recuerda mucho al de Google de los primeros tiempos. ¿Los resultados son buenos? Mirá, lo vengo usando hace solo una semana, y te diría que para el 99% de las búsquedas, sí. No se si es mejor o peor que Google, pero me sirve, me funciona.

En cuanto a privacidad tiene cosas muy piolas, les recomiendo leer al respecto, pero dos cosas que me parecieron fantásticas son la posibilidad de configurar DuckDuckGo para que no le informe al sitio de destino que lo visitás de parte de él, y la posibilidad de usar su sintaxis "bang" para especificar un proxy directamente en la búsqueda, haciendo que el tipo pase por ese proxy, anonimizando (en parte) lo que estás haciendo.

¿Y que es eso de la sintaxis "bang"? Algo que está más bueno que el dulce de leche, que es re-natural y re-útil. Es básicamente una forma de decirle a DuckDuckGo "buscá acá", o "buscá este tipo de información", etc. Ejemplos:

Buscame The Lord Of The Rings en IMDb:

!imdb the lord of the rings

Buscame un torrent con la imagen de ubuntu 11.10:

!torrent ubuntu 11.10

Buscame posts taggeados "Caminito" en Tumblr:

!tumblr caminito

... y así. Y esa sintaxis también funciona para cosas como !convert, !translate, y otros verbos. Hay cientos de términos "bang" para usar, en las categorías y temas que quieras, ciencia, lenguajes de programación, multimedia, noticias. ¿Y lo mejor? ¡Qué son obvios! O sea, no es que tenés que estudiar la lista. A mi me viene pasando que de pronto digo "¿si le mando !flickr buscará en Flickr?" Y resulta que sí, y tal vez con Flickr es obvio, pero encontré intuitivo, natural, pergarle a cosas más específicas.

Y eso no es todo, la sintaxis !bang es solo uno de los goodies que ofrecen; podés escribir queries con cálculos, con conversiones, con temas relacionados con geografía, fecha y hora, etc., etc.

Una semana es poco tiempo para evaluar algo tan importante como un servicio de búsqueda en internet, pero la verdad que por ahora se queda, y como primera opción. Ya agregué el Search Plugin de DuckDuckGo a Firefox para tenerlo en la barra de búsqueda, y lo puse como opción predeterminada.

Enviar un artículo a Read It Later desde Google Reader

cHagHi — Tue, 22 Nov 2011 22:58:37 GMT

Mi servicio preferido para llevar un registro de "cosas que encontré en la web y que me quiero acordar de leer" es Read It Later. Antes usaba Instapaper, pero más que nada por un tema de soporte oficial en celulares con Android, hace unos meses me cambié a Read It Later.

Hace rato que tengo configurado en la barra de marcadores de Firefox un bookmarklet que me permite enviar a Read It Later la página que estoy leyendo, y en general es lo que uso. El tema es que cuando estoy leyendo un artículo en Google Reader, tengo que abrir el artículo en una solapa/ventana nueva (para ir a la fuente original), y de ahí hacer el envío.

Si bien Google hizo muchas cagadas con el rediseño de Reader de hace unas semanas, hasta que le encuentre un reemplazo, lo sigo usando. Y resulta que han hecho algunas cosas buenas. Por ejemplo: al pie de cada artículo hay una opción de "Send to" que permite enviar la nota a diferentes servicios. Desde la configuración de Google Reader se pueden habilitar y deshabilitar que servicios queremos ver. Están los clásicos: Twitter, Facebook, Tumblr, Digg... hasta está Instapaper, pero no está Read It Later.

Si miran en la configuración al pie de los servicios disponibles, verán que no todo está perdido. Google previó crear "sitios personalizados", con lo cual es posible definir nuevos servicios. Y resulta que la gente de Read It Later ya documentó como hacer para agregar su servicio a la lista.

Hay que crear un enlace personalizado con la siguiente información:

Name: Read It Later

URL: https://readitlaterlist.com/save?url=${url}&title=${title}

Icon Url: http://readitlaterlist.com/favicon.ico

... y listo, con eso aparece Read It Later como "sitio destino" dentro de Google Reader, y se pueden enviar los artículos sin necesidad de abrir la fuente original primero.

Fuente: Add Read It Later to Google Reader’s Send To Dropdown

Sí, ya se: hay una extensión oficial para Firefox que integra Read It Later con el browser, pero, cuestión de gustos, personalmente prefiero el bookmarklet antes que una extensión...

Luchando con la memoria interna del HTC Desire

cHagHi — Tue, 25 Oct 2011 11:30:41 GMT

Hay dos cosas que no me gustan de mi HTC Desire: una es la autonomía de la batería, la otra, el espacio de almacenamiento interno.

Bueno, hay tres cosas: La tercera es el GPS, pero no termino de decidir si lo lento que es el GPS para obtener un lock, y la frecuencia con la que se desengancha es un problema de software, de hardware, o que... y no es tan de vida o muerte. Lo puteo *mucho* cuando salgo a correr, pero para lo demás, zafa.

Volvamos a los dos temas originales:

El tema de la batería más o menos quedó aceptablemente resuelto cuando actualicé a Gingerbread. Estoy usando una ROM custom basada en el build oficial de Gingerbread liberada por HTC para el Desire, específicamente esta, que es del mismo desarrollador de la ROM que usaba de Froyo.

Digamos que con esa ROM obtengo unas 8hs de uso intensivo, o unas 24 a 36hs de uso normal (que en mi caso tiende a ser de moderado a bajo). Si bien está lejos de lo que me gustaría, sirve. Sí, en la práctica implica que lo tengo que cargar todos los días, pero bueno... ahora con Gingerbread puedo obtener esa autonomía estando conectado prácticamente todo el día (con Froyo para lograr eso usaba permanentemente Green Power para solo activar la conexión de datos durante 2' cada 30').

Y todavía podría mejorarlo más, si flasheara el "Powersaving Mod" de esta ROM y/o utilizara alguna aplicación que aprovecha el rooteo del teléfono para hacer under-clocking cuando la CPU o la pantalla están idle. Calculo que con eso mejoraría mucho, pero todavía no me puse a jugar con eso. Y siempre puedo recurrir a Green Power (con Gingerbread casi no lo estoy usando... pero la opción está). Como decía al principio, la autonomía que tengo ahora no me vuela la peluca, pero me alcanza. Es manejable.

Pero queda un tema... y es el espacio de almacenamiento interno. Con esta ROM que estoy usando, instalé también A2SD+, que básicamente usa una partición extendida en la SD card, y mueve ahí las aplicaciones y el caché Dalvik, pero *no* los datos de las apps. Eso mejora *mucho* la cuestión, pero no alcanza. Hay dos cosas que con el correr de los días se van descontrolando:

Cache

El caché de algunas aplicaciones crece mucho. Algunas apps tienen el cache en la memoria interna, otras en la externa, otras en ambas. Depende. Pero hay ciertas apps que tienen una tendencia a entrar a comer megas y megas de cache en la memoria interna: Google Reader, Internet, Facebook, Market, Google Maps.

Para resolver esto, instalé CacheCleaner NG (requiere root para ser realmente útil...) Lo que tiene de bueno esta app es que permite ver el caché usado aplicación por aplicación, interno y externo, y configurar individualmente cual quiero que borre y cual no, también aplicación por aplicación. Cada N días, le pego una mirada, y libero unos cuantos megas (con una semana típica de uso suelo estar con entre 10 y 15MB usados para cache, que obviamente sigue creciendo si lo dejo). CacheCleaner NG puede configurarse para iniciarse automáticamente y limpiar con cierta frecuencia, pero por ahora, lo estoy haciendo manualmente.

ANR_history.txt

Esto es un misterio. Intrigado por saber que otra cosa iba comiendo espacio sin parar, día a día, casi que hora a hora, sin prisa pero sin pausa, empecé a prestarle más atención a la info que da DiskUsage. Lo venía usando hace bastante, pero no me había percatado que, si soy root, puedo usarlo para analizar la carpeta /data/data, que es donde están los datos de las aplicaciones. Y ahí me encontré con este señor archivo:

/data/data/com.android.htcprofile/anr_history.txt

Google no me ayudó mucho, pero aparentemente es una especie de log de errores. De hecho, es un archivo de texto, que tiene stack traces de aplicaciones con problemas. Aparentemente, "anr" es "application not responding". Tiene sentido... historial de aplicaciones que no responden. Lo estuve mirando un poco, y hay errores de java de todo tipo, de prácticamente todas las aplicaciones. No tengo idea que tiene que ver con HTC Profile; tampoco tengo muy claro que es HTC Profile. Lo que si tengo claro, es que si no lo blanqueo cada tanto, crece sin parar, mal. Y también estoy casi seguro que esto empezó a pasar con la ROM basada en Gingerbread. ¿Será un bug de la ROM que liberó HTC? ¿Hay forma de apagar ese log de errores? Como les decía, Google no me fue de ayuda. Sí encontré un par de foros en los que aclaran que no conviene borrarlo directamente, porque luego podría tener algún problema de permisos (¿tal vez alguna aplicación o librería de HTC luego no lo encuentra y falla?). No comprobé lo de los permisos, pero por las dudas, no lo borro, lo trunco. Me abro una consola local con ConnectBot, y hago esto:

$ su

# echo "" > /data/data/com.android.htcprofile/anr_history.txt

... y santo remedio. Por algunos días / semanas.

Odio tener semejante teléfono que me salió unos buenos mangos y tener que estar haciendo este tipo de chanchadas. Ya decidí que mi próximo teléfono (si tiene Android) va a tener que tener espacio de almacenamiento interno de verdad (y no los 140MB que tiene el HTC Desire, que son un chiste de mal gusto).

GMail + OfflineIMAP + Evolution

cHagHi — Sun, 27 Dec 2009 14:22:38 GMT

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

Background

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

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

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

Boludo, ¡usá IMAP!

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

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

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

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

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

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

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

IMAP en Evolution sucks

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

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

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

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

Enter OfflineIMAP

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

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

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

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

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

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

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

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

Dejarlas afuera tiene los siguientes caveats:

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

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

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

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

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

Bonus track

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

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

Ubuntu 9.04 - Jaunty Jackalope

cHagHi — Sat, 25 Apr 2009 18:56:28 GMT

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.

Synergy

cHagHi — Tue, 14 Apr 2009 02:13:51 GMT

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

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

¿Esos N equipos están en red?

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

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

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

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

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

Si usan Ubuntu, tienen synergy y quicksynergy en Universe.

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

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

Hay tabla

cHagHi — Mon, 06 Apr 2009 14:46:30 GMT

Hay tabla

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

Gracias Seba por el original!

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

Configurando Wake on LAN

cHagHi — Sun, 22 Mar 2009 01:50:24 GMT

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

IronPython pyc

cHagHi — Sun, 08 Mar 2009 21:21:47 GMT

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

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

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

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

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

Veamos por que:

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

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

import foo

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

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

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

Y eso tiene varios problemas:

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

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

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

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

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

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

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

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

Probando IronPython 2

cHagHi — Sun, 01 Mar 2009 16:11:08 GMT

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

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

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

Así que seguimos usando IPy 1.1.

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

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

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

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

from Cheetah.Template import Template

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

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

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

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