Bitácora de Vuelo

En el lugar en donde estoy actualmente trabajando (Senior Software Developer, en Canonical, programando Python), hacemos en general algún software que es propietario, y algún software que será liberado a la comunidad.

Este post es sin embargo acerca de otra faceta del laburo, faceta en la que incursioné durante estos días a raiz de un problema que tenía al hacer unos tests. Esta faceta es la de trabajar en un paquete que nosotros usamos pero que no es nuestro, e invertir tiempo del laburo (horas, días) en solucionar algo... en definitiva, devolver algo a la comunidad del software libre del que tanto uno toma.

Durante dichos tests, necesité levantar los atributos extras de un archivo. Como obviamente las pruebas las hago desde Python, lo primero que probé usar es la biblioteca xattr, pero me tiraba un error extraño y feo.

Al principio dudé de la biblioteca en sí, y me puse a excavar desde la misma, hasta las llamadas del sistema directamente, con lo cual aprendí bastante de estos atributos extendidos. Pero vi que estaba todo bien.

Luego empecé a subir desde la llamada del kernel a la biblioteca FUSE (que es la que te permite codear vos mismo un sistema de archivos y usarlo sin tener que integrarlo al kernel). Acá es donde encontré un problema. Entendí cómo debería funcionar, vi que estaba mal, busqué el código fuente del proyecto, y verifiqué que incluso en lo más actualizado de ese código (en trunk) también estaba mal.

Así que me traje el código, lo compilé y empecé a probar nuestro sistema con la versión que iba corrigiendo, hasta que solucioné el problema. Una vez que verifiqué todo, generé el parche correspondiente y lo subí a Launchpad, en un bug que abrí por este problema, para que sea considerado su inclusión en futuras versiones y que esto esté resuelto para todos.

Por otro lado, en el laburo, para algunas cosas en desarrollo armamos Paquetes Privados de software, de manera que los desarrolladores nos suscribimos a ello y si hay actualizaciones estas son ofrecidas a nosotros a través del mismísimo Administrador de Actualizaciones del Ubuntu (este es una funcionalidad pública del Launchpad llamada Personal Package Archives (PPA)).

Entonces, como nosotros para desarrollo necesitamos esto corregido, me puse a agregar a nuestro PPA una nueva versión de este paquete. Paso a comentarles cómo es este proceso.

Bajé las fuentes limpias del paquete (apt-get source python-fuse). Hice esto en un directorio vacío y ví que aparte del directorio con las fuentes, aparecieron unos archivos de control, los cuales borré prestamente porque no los iba a necesitar. Copié el parche que había creado al directorio correspondiente de las fuentes (debian/patches), agregando el nombre de ese parche en el archivo debian/patches/00list. Finalmente anoté una entrada en el changelog de las fuentes (esto se hace con un programita auxiliar, ya que deben tener un formato específico; en mi caso hice dch -D <distro> -v <versión_del_paquete> "mensaje para el changelog").

Ya con las fuentes modificadas, armé los archivos de control y paquete como para subir, lo que se hace con la orden debuild --no-tgz-check -S. Para saber que está todo bien, y que todo lo que armé se va a instalar bien, fui al directorio superior (donde antes tenía las fuentes, y ahora dejados por la orden anterior, nuevos archivos de control), y usamos un programita que arma un root falso e instala todo lo que tiene que instalar para ver que nuestro paquete se acopla bien al resto del sistema: sudo pbuilder --build *.dsc.

Finalmente, para subir el paquete al Launchpad: dput -f <host> *.changes.

Luego, lo dejé reposar algunas horas a fuego lento, y al rato Ubuntu nos indica que hay una actualización disponible, y es efectivamente este paquete, :)

Por favor, lean el artículo "Gieco y Filmus quieren tu dinero, lo merezcan o no", y si se sienten tan mal como yo, sepan que pueden al menos apoyar a gente que está trabajando activamente contra esto.

La siguiente es una carta de la Fundación Vía Libre a Daniel Filmus para pedir entrevista y explicarle todo lo malo de lo que está impulsando. Léanla, y manden su adhesión a [email protected] (en caso de personas, poner Nombre, Ciudad, DNI, y a qué se dedica (ej: docente, programador, artista plástico, etc); en caso de organizaciones, recuerden que la adhesión debe ser formalmente consensuada dentro de las mismas).

Estimado Senador Daniel Filmus

Honorable Cámara de Senadores de la Nación

A través de un artículo en su blog personal, hemos tomado conocimiento de su compromiso con las gestoras colectivas de derechos de autor para presentar un proyecto de ley que impondrá un "canon digital" sobre todos los dispositivos que permitan el almacenamiento y transmisión de obras en formato digital. El objetivo de la presente es solicitarle una audiencia para aportar al debate el punto de vista de quienes debemos soportar esa carga, a diferencia de aquellos que se benefician de ella: usuarios de nuevas tecnologías, productores y usuarios de software y cultura libre, bloggers, músicos y escritores independientes, diseñadores, artistas digitales, profesionales y usuarios de las comunicaciones y la informática.

Un gravámen de este tipo, tal como se ha implementado en países como España, es seriamente regresivo para nuestras actividades y genera costos elevados para políticas públicas de educación en nuevas tecnologías, aspecto que sabemos le preocupa de manera prioritaria tras su paso por el Ministerio de Educación de la Nación.

El canon digital es fuertemente resistido por asociaciones de defensa del consumidor, asociaciones de internautas, asociaciones y grupos de usuarios de software libre en los lugares donde se implementa. Compartimos con ellos la preocupación, más aún, sabiendo que los marcos jurídicos vigentes en la Unión Europea son diferentes a los que imperan en nuestro país.

Un gravamen de esta naturaleza aumenta los costos de:

• la educación

• el acceso a conocimiento

• el desarrollo científico técnico

• el desarrollo de cultura accesible a todos los sectores sociales, independientemente de que puedan pagar por ella.

• toda actividad que utilice tecnologías de información en forma intensiva (es decir, cada vez más actividades, prácticamente todo).

A las elocuentes desventajas por el aumento de los costos de todo dispositivo informático y digital, sin importar su destino y usos, se suman datos corroborados sobre esta práctica en otros países, como por ejemplo el costo del canon para los propios autores. En España, la misma Sociedad General de Autores y Editores (SGAE, entidad encargada de administrar los fondos provenientes del canon) admite que sólo 200 de sus afiliados reciben más de lo que pagan por este concepto, en lo que constituye una injustificable transferencia de recursos del conjunto en beneficio de una estricta minoría.

Así, un gravamen regresivo que afecta a todos los usuarios de dispositivos informáticos sin importar si copian o no materiales de los pocos autores beneficiados, no debería ser impulsado sin evaluar sus costos reales sobre el total de la sociedad argentina que se verá afectada. Antes de avanzar en un proyecto de esta naturaleza, es fundamental evaluar cuáles serán las consecuencias de un gravamen que se cobrará de manera generalizada pero que será administrado por entidades privadas sin el debido contralor ciudadano.

Por estos y otros motivos que deseamos exponerle en mayor detalle y con más documentación, solicitamos a Ud. tenga a bien otorgarnos una audiencia en la que podamos conversar sobre este tema en particular antes de que el proyecto ingrese a los canales legislativos en el Senado. A los fines de esta solicitud, fijamos como medio de contacto nuestro correo electrónico en [email protected].

Sin más, y en espera de una respuesta positiva a esta solicitud, saludan atentamente...

...y acá irían todos los que adherimos... yo ya mandé el mail, ¿y vos?

[Actualización] Bea, en una lista de correo explicó que este canon no es un impuesto, sino un gravamen... está tan bien explicado, que lo copio acá:

Esto es un gravamen, no es específicamente un impuesto. En ninguno de los países donde se aplica lo cobra el estado, sino que lo cobran y administran las gestoras colectivas de derecho de autor. Es decir, No es un impuesto que cobra el Estado y redistribuye a todo el conjunto de la sociedad. Es un gravamen que cobra un privado al conjunto de la sociedad para mantener su negocio obsoleto porque la tecnología está haciendo que las cosas no le vayan tan bien como desearía (cosa que es discutible). Hood Robin que le dicen.... le cobrás a todos para mantener el negocio de algunos. Y encima lo administra un privado, por lo tanto ni siquiera es un impuesto. Si es un impuesto, como ciudadanos tenemos derechos a saber qué se hace con nuestro dinero y exigir que tenga destinos justos o socialmente útiles. Como esto es un gravamen que va a manos privadas, no tenemos ningún control sobre qué hacen y a quién retribuyen.

Dos frases buenísimas que leí en los últimos días:

Resulta sorprendente que el modo de encarar la crisis de los países occidentales contradiga tan manifiestamente el modelo que ellos mismos predican para el Tercer Mundo. Cuando hay crisis en Indonesia, o en Argentina, o en cualquier otro sitio, se les exige que suban mucho las tasas de interés y que privaticen la economía y recorten el gasto público. Este tipo de medidas. En Occidente, en cambio, es exactamente lo contrario: bajar los tipos de interés a cero, nacionalizar; si es necesario, inyectar dinero público en la economía, contraer enormes deudas. Exactamente lo contrario del modo por el que se supone que el Tercer Mundo tiene que satisfacer sus deudas. Me parece notabilísimo que se deje pasar eso sin mayores comentarios.

`Noam Chomsky <http://es.wikipedia.org/wiki/Chomsky>`_, entrevista para Press TV

Yo sigo sin entender por qué hablan de propiedad intelectual cuando en realidad quieren decir derechos de explotación comercial. Las redes p2p no ponen en peligro la propiedad intelectual, o ¿acaso alguien ha intentado apropiarse la autoría de una obra por haberla descargado del emule?"

Un tal "toptnc", en un comentario (EDITADO: `la url no existe más <http://www.publico.es/ciencias/195706/bloqueo/mocion/eurodiputado/espanol/p/p?orden=VALORACION&asc=&aleatorio=0.3241225619403919#comentarios>`__) sobre políticos y `P2P <http://es.wikipedia.org/wiki/Caracteristicas_p2p>`_

Encontrar lo que el usuario necesita pero no sabe bien como expresarlo es un bardo... es más... diría que si lo resolvés bien, te llenás de guita (preguntale a Google).

Por el otro lado, entregarte un montón de información pero no dejarte buscar en ese montón, es inútil. De ahí la famosa frase "darte la Wikipedia en un CD, pero sin buscador, es darte un CD cuya mayor utilidad es ponerlo atrás de la patente para evadir fotomultas".

La solución es fácil: agregarle búsquedas a la CDPedia. Hoy por hoy ya la tienen, con un índice no demasiado elaborado sobre los títulos, pero que nos permite buscar por palabras exactas con mucha rapidez (una búsqueda por diccionario), aunque también implementé una búsqueda por palabra incompleta (aunque esto, en el modelo simple actual, con todos los datos, creo que tardaría demasiado, aunque todavía no lo probamos).

Hoy por hoy, también, la búsqueda es utilizando Unicode sin ningún tratamiento. Y aunque esto tiene la ventaja de que soportamos eñes, tildes, y letras raras (o sea, letras a las que no estamos acostumbrados los hispanoparlantes), tiene la desventaja que tenés que poder escribir esas letras (o incluso recordarlas).

Por ejemplo, si quieren buscar ... no sirve que pongan ...

Camión - Camion
Muñiz - Muniz
Çanakkale - Canakkale
Ⅱ - II

La pregunta es... ¿cómo podemos "normalizar" los términos con eñes, tildes, y letras raras, de manera que la búsqueda siga siendo por coincidencia del diccionario?

Estuve leyendo algo de Desnormalización de Unicode (acá está todo, pero también ver esto), pero no me llegaba a convencer que lo que había que hacer era eso, porque las reglas de las distintas normalizaciones no me permitían inferir un único procedimiento para lograr lo que quería hacer.

Buscando y buscando, me di cuenta que si puedo acceder a cierta info de la Tabla de Unicode sin entrar en una Normalización formal, podía tener lo que quería. El acceso a esta información desde Python es con la función decomposition(), y la regla es la siguiente: si la decomposición indica que es por compatibilidad, incluir los caracteres devueltos, pero si solamente nos está separando el grafo principal de los accesorios, quedarnos con el principal.

Lo siguiente es el código, con las pruebas para los ejemplos anteriores:

# -*- coding: utf8 -*-

import unicodedata

def _norm_car(car):
    # si es una letra simple, no hace falta normalización, nos fijamos
    # primero porque es más rápido
    if ord(car) < 128:
        return car

    # descomponemos y vemos en qué caso estamos
    decomp = unicodedata.decomposition(car)
    if decomp == "":
        # no tiene
        res = car
    elif decomp.startswith("<compat>"):
        # compatibilidad
        utiles = [x for x in decomp.split()][1:]
        res = u"".join(unichr(int(x, 16)) for x in utiles)
    else:
        # nos quedamos con el primero
        prim = decomp.split()[0]
        res = unichr(int(prim, 16))

    # guardamos en el caché y volvemos
    return res

def normalizar(palabra):
    return u"".join(_norm_car(c) for c in palabra)

assert normalizar(u"Camión") == u"Camion"
assert normalizar(u"Muñiz") == u"Muniz"
assert normalizar(u"Çanakkale") == u"Canakkale"
assert normalizar(u"Ⅱ") == u"II"

El costo de usar esto en el índice, en la búsqueda real, es primero al construirlo, y luego en cada búsqueda. En ambos casos el extra de procesamiento es agarrar las palabras e ir reemplazando cada caracter por lo que devuelva la función anterior. Creo que al armar el índice esto va a tardar un poco (pero se hace una sola vez), y que en cada búsqueda ni se va a notar (que es lo importante de cara al usuario final).

El resultado final sería que tenemos esta funcionalidad requerida, con un costo que podemos pagar.

Por otro lado, hay otra funcionalidad que querría tener, pero no voy a atacar ahora (posiblemente nunca, pero se los dejo por si les interesa), que es la de búsquedas aproximadas. La idea es que (por ejemplo) si busco almoada o cavra, me encuentre almohada o cabra, respectivamente. Obviamente, en estos casos lo que se hace es listar las palabras que más se parecen, ordenadas de mayor a menor similitud.

Hay formas piolas de lograr esto (creo que la mejor es usando la distancia de Levensthein, que fue sugerida por gente que sabe en la lista de PyAr). El problema que encuentro con este tipo de procesamiento, es que se pierde la coincidencia por diccionario, y hay que calcular esta distancia entre la palabra buscada y las guardadas en el momento de la búsqueda en sí.

Lo bueno de este tipo de procesamiento, sin embargo, es que nos ahorra el anterior (ya que encontraría una palabra con 'Ç' aunque escribamos 'C', sólo porque son parecidas). Anyway... se los dejo como tarea para el hogar (o para el PyCamp de este año <guiño>).

Si les interesó el tema de Hielo Rojo, no dejen de leer este artículo de Página 12. Un extracto:

"En la atmósfera marciana este gas es rápidamente destruido de distintas formas –dice Mumma– así que nuestro descubrimiento de plumas de metano en el Hemisferio Norte de Marte nos indica que existe algún proceso activo que lo está produciendo y liberando." Algún proceso activo... ¿pero cuál? Hay dos maneras de producir metano: una geológica... y otra biológica.