Perl

Mapa de procesos del sistema

Nocturno, nariz quemada de sal marina. Tiro la camiseta sobre una silla, me rasco brevemente un tobillo marcado por líneas paralelas de sangre seca de haber estado cogiendo moras mientras estiro los dedos de los pies descalzos, abro emacs y selecciono el tema Shaman. Las luces de determinados sectores de la pantalla viran a verde grisáceo y gris y, a medida que voy escribiendo, el patrón de la línea anterior se borra para ser redibujado de inmediato cada vez más cerca del borde superior de la pantalla. Los ordenadores hacen todo el tiempo montones de tareas complicadas fingiendo que son sencillas.

Vamos a hablar de esas tareas. Llevo un par de semanas tratando de comprender algunos comportamientos inusuales esporádicos en una máquina. Tras masticar con cuidado los manuales de varios programas que muestran información de ese tipo (ps, top, pstree y lsof fundamentalmente) no he encontrado ninguna opción totalmente satisfactoria que me permitiera estudiar el conjunto en vez de las partes por separado y no he podido dejar de notar lo poco que parecen haber evolucionado estos programas en los últimos años. A pesar de la proliferación de opciones y columnas con todo tipo de información adicional (que a veces estorba más que ayuda) no parece que nadie se haya hecho la pregunta evidente ¿Porqué en estos 15 años no hemos podido ir más allá de la tabla?

No quisiera ser malinterpretado como alguien que protesta por no querer tomarse la molestia de asimilar un manual. No tengo nada en contra de los programas de texto y entiendo que el peso de la tradición a veces obliga a ser conservador y no tomar alegremente determinados caminos, pero cuando un programa tiene que mantener dos sets de opciones distintas para hacer exactamente lo mismo (sólo por compatibilidad) y muchas de esas opciones sirven al final para presentar una tabla de todas las maneras posibles, uno se pregunta si no sería mejor dedicar ese esfuerzo a buscar nuevos enfoques. Algunos de estos programas han sido reescritos desde cero por cuestiones de licencias y podría haberse aprovechado el momento para ser más ambiciosos y distanciarlos del programa al que sustituyeron. En un mundo ideal la información presentada debería hablar por sí misma y ser fácilmente comprensible sin tener que consultar la documentación para poder entender la mayor parte de lo que estamos viendo; con un número creciente de opciones que recordar y lanzar, estamos cada vez más lejos de ese ideal. Probablemente nos hemos centrado tanto en describir detalladamente cada proceso individual que los árboles nos están impidiendo ver el bosque; seguimos insistiendo en representar una estructura de árbol de tareas relacionadas mediante tablas y párrafos de texto y, para empeorar más la cosa, los límites de esta estructura suelen superar a la ventana que la contiene obligándonos a usar un segundo programa para movernos arriba y abajo. Probablemente no el mejor modo de presentar este tipo de información al usuario.

Por eso aquí dejo mi pequeña aportación al problema. Un programa que partiendo de la misma información dada por lsof tiene como objetivo mostrar la estructura subyacente del modo más intuitivo posible y nos va a permitir crear un grafo, limpio y fácil de interpretar y examinar, de las relaciones entre procesos activos en un determinado instante en nuestro sistema.

Biblioteca digital (I)

Un pequeño programa perl para hacer una búsqueda "natural" de archivos PDF

El formato de documento portátil de Adobe cumple este año 20 años desde el lanzamiento de su primera versión. Tras desplazar progresivamente a postscript y rebajar las expectativas de crecimiento de dvi, PDF es en la actualidad El Formato, con mayúsculas, usado para publicar y diseminar libros, revistas, artículos y todo tipo de conocimiento técnico entre ordenadores. Es habitual acabar reuniendo una pequeña biblioteca personal de referencia con cientos de archivos sobre nuestras neuras personales, que habremos descargado, solicitado directamente a sus autores o adquirido on-line y que se van acumulando a buen ritmo en nuestro sistema.

El caso es que como las revistas a menudo usan nombres poco descriptivos cuando queremos revisitar algún documento concreto y ha pasado cierto tiempo puede costar volver a localizarlo en el disco duro, de hecho puede que sea incluso más rápido volver a descargarlo desde la red. En principio sacar un listado de PDFs de un directorio es una tarea trivial (find . -iname '*.pdf') para la que no haría falta molestarse en escribir un post, pero hay un problema: Find es una herramienta de tipo técnico que no nos permite una búsqueda 'natural', simplemente no fue ideado con ese propósito y la mayor parte de sus opciones son inadecuadas en nuestro contexto. Si el articulo "Fernández et al. 1985" reside en un archivo llamado "AD113FE5C-2000.pdf", por ejemplo, no llegaremos muy lejos con find.

Pensemos en cambio en cómo buscaríamos realmente un libro conocido en nuestra biblioteca favorita. En la mayor parte de las veces probablemente ignoraremos los cajones de las fichas y nos desplazamos a la zona por la que debería estar. Una vez allí no iremos leyendo todas las etiquetas de referencias a ver si coinciden, sino que usaremos nuestro conocimiento previo del objeto. Buscaremos, por ejemplo un libro delgado azul con una banda blanca en el lomo, y eso nos permite discriminar más rápidamente porque lo natural para el cerebro es memorizar una imagen de los objetos que conocemos. Del mismo modo, ya que un PDF no es otra cosa que una representación de un objeto real, aunque es muy poco probable que recordemos su -mtime, o cuando lo hemos abierto por última vez, sin duda sabremos sin esfuerzo si el documento que buscamos era un libro gordo, una revista, un artículo, un póster de congreso o una tabla de referencia tamaño tarjeta de crédito con un resumen de comandos básicos.

Y ese es el asunto en el que me quiero centrar hoy. Vamos a ver como resolver problemas del tipo: "Encontrar entre los cientos de archivos en formato PDF diseminados por varios árboles de directorios de nuestro disco duro aquellos que representen a un libro de al menos 18x25 cm de portada y entre 75 y 90 páginas de extensión", o "encontrar el documento de mayor tamaño (físico) de nuestro sistema", y lo vamos a hacer con Perl.

Casos especiales

En la primera parte habíamos visto como crear una tabla en código de latex desde una base de Postgresql y mantenerla permanentemente actualizada de un modo relativamente sencillo. Hoy vamos a usar Perl para enfocar el mismo problema desde un punto de vista mucho más interesante. Normalmente evito hacer las cosas de modo complicado cuando ya tengo una solución simple que sé que funciona, así que podéis confiar en que habrá algún caramelito esperándonos al final.

Aplicando algunos conceptos de ecología al análisis de las comunidades virtuales.

Hoy voy a dejar un poco de lado las cuestiones técnicas y trataré de abordar un problema cada vez más habitual con el creciente número de comunidades virtuales: cómo valorar la madurez y "estado de salud" de un foro de usuarios con respecto al de otros foros similares.

A lo largo de su vida los foros pasan por varias fases fácilmente reconocibles. El esfuerzo de crear un foro exige entusiasmo y cierta habilidad técnica, y al principio suele haber gente muy motivada e implicada. Más tarde, a medida que el foro se va poniendo de moda, aumenta el porcentaje de usuarios novatos que acuden con preguntas básicas o simplemente lo consultan como manual de referencia pero sin atreverse a escribir en él. También aparece un porcentaje de usuarios que directamente tratan de abusar del foro (ignorando las reglas, o esperando que les hagan sus deberes o que el foro sea su pringado/esclavo/servicio técnico gratuito particular) y para empeorar las cosas el foro empieza a atraer a los bots.

En ese momento es fácil morir de éxito, la repetición una y otra vez de preguntas triviales y la lucha contra el spam y los usuarios que incumplen sistemáticamente las normas, sobrecarga e irrita a la moderación. Eso lleva a discusiones que atraen a los trolls, y aumentan más el trabajo de los moderadores para evitar el previsible y típico desenlace: broncas entre grupos de usuarios alineados en diferentes bandos con las consiguientes escisiones, creación de foros paralelos o incluso la total desintegración de la comunidad.

Aparte del aumento de recursos técnicos para mantener el creciente foro en un estado razonablemente ordenado, el proceso suele implicar también la pérdida de recursos humanos cuando los expertos, desgastados por la ausencia de preguntas interesantes, o los moderadores, obligados a recordar una y otra vez las normas, deciden que sería mejor invertir su tiempo en otros asuntos y se trasladan progresivamente a comunidades más pequeñas y elitistas. Todo ello implica la pérdida de calidad en los contenidos del foro.

Lo que nos lleva a una segunda cuestión interesante: ¿cómo valorar la estabilidad de un foro?

Una posible aproximación al problema podría venir, desde mi punto de vista, de la ecología teórica. Un aliado no tan insospechado si pensamos en los foros como ecosistemas complejos en los que no faltan muestras de simbiosis, parasitismo, predación, competencia y territorialismo. Mi idea por tanto será aplicar varios conceptos clásicos de ecología y ver qué ocurre; más concretamente voy a comparar tres comunidades de foreros (esDebian, EsLinux y Ubuntu-hispano) mediante el cálculo de su "biodiversidad".

Buscar e instalar software que no está en los repositorios de Debian, desde Debian

Como todos sabemos, uno de los mayores logros de Debian es su sofisticado y completo sistema gestor de paquetes .deb, que cubre un amplio espectro de soluciones a diferentes necesidades mediante programas como dpkg, dselect, aptitude, synaptic, apt o alien. Ha contribuido tanto al éxito de la distribución que a veces uno olvida que existen alternativas menos conocidas, no basadas en los archivos deb, pero que también permiten instalar software de modo avanzado desde Debian. Su rango de acción empieza allí donde acaba el de los programas citados anteriormente: Las "colecciones temáticas" de software libre fuera de los repositorios en los que se ofrece lo último de lo último antes de que sea empaquetado y entre en Sid.

Éstas semanas el tiempo ha empeorado bastante, los vendavales de noviembre se han intercalado con chaparrones de agua helada en el cogote y éstos a su vez han dado paso a la nieve. La primera víctima fue el mango de la pala; debe de ser la quinta o sexta vez que parto la pala en dos trozos y ya no queda mucho de donde tirar, así que he añadido otra muesca a mi culata y dejado los restos de la batalla en un rincón por ahora. De todos modos no importa mucho porque los rosales tendrán que esperar en cualquier caso a que el tiempo mejore.

El tiempo extra me ha permitido retomar algunos divertimentos e ideas pendientes, como dedicar algo de tiempo a estudiar la estructura interna de Debian. El primer movimiento, crear una base de datos a partir de una instantánea de popularity contest (nov 2010) con información sobre 108300 paquetes, está ya listo y, para los que sientan curiosidad, lo habéis adivinado, ya tenemos las primeras conclusiones: