Comparando utilidades de compresión

Hoy ha tocado colocar un poco el disco duro, y en estas que me da por mirar cuánto ocupa el directorio

.thunderbird/

donde guardo todo el correo que recibo (desde hace años, incluído spam). 1.8G suman todos los correos. Casi nada, teniendo en cuenta que es texto plano.

Buceando en ese directorio llego al fichero

Inbox

de una de mis cuentas de correo. Todo lo que almacena está en formato mbox, que es lo que habitualmente usan los lectores de correo (o MUAs, Mail User Agent). Los MTAs (Mail Transport Agent) suelen usar el formato Maildir ya que evita el cuello de botella que impone mbox ante la concurrencia.

El caso es que me da por mirar a ver qué tal comprimen los diferentes algoritmos de compresión que tengo en Linux, que son básicamente cuatro: bzip2, LZMA (7zip y versiones nuevas del tar), el tradicional Zip (herramientas zip y gzip) y RAR.

Me he centrado sólo en el ratio de compresión de cada programa, no me he preocupado por cuánto tardan en comprimir, ni cuánto se tarda en listar el contenido de un fichero, o en descomprimir un sólo fichero. De hecho es que no he diferenciado entre formatos que comprimen y archivan a la vez, y los que sólo comprimen (p.ej.

bzip2

). He comprimido un sólo fichero, y era un fichero de texto (en formato

mbox

).

Los resultados para un solo fichero

mbox

de 118M:

Programa Algoritmo Tamaño ¿Libre?
gzip -9 LZ77 modificado 65M
zip -v9 LZ77 modificado 65M
bzip2 Burrous-Wheeler/Huffman 63M
rar LZSS 56M No
7-zip LZMA 54M
tar –lzma LZMA 54M

Con ¿Libre? me refiero a si yo conozco implementaciones libres del algoritmo tanto para comprimir como para descomprimir.

El LZ77 modificado también se conoce como DEFLATE.

Se concluye lo que más o menos ya habíamos observado a base bajarnos discos:

LZMA

es el que más comprime (y es libre),

RAR

no se queda muy lejos (pero no es libre, aunque es bastante multiplataforma),

bzip2

mejora un poco lo del tradicional

Zip

, pero éstos dos ya van teniendo que jubilarse.

Las únicas ventajas que tienen

zip/gzip/bzip2

son a) que aparentemente tardan menos en comprimir (lógico) y b) que están mucho más difundidos: es difícil encontrar un sistema que no tenga alguno de los tres.

LZMA

en cambio, es más difícil de encontrar.

Update (2009-02-17): Hoy en barrapunto.com han publicado Comparación entre diferentes algoritmos de compresión en Linux . Una noticia que enlaza a tres sitios donde han hecho comparativas similares, pero mucho más extensas:

Algoritmia
Estructuras de datos
Linux
Shell scripting

Comments (0)

Permalink

DBDesigner en Linux (Debian)

DBDesigner es una herramienta CASE para el modelado de bases de datos relacionales.
Funciona sobre Windows y Linux, que yo haya probado, y dice estar preparada para trabajar mano a mano con MySQL.

Desde luego, en el entorno donde hemos tenido que utilizarlo se ha portado mucho mejor que otras herramientas que probamos –MS Visio, y Dia, aunque Dia tampoco estaba mal, y al tener otro enfoque no es muy comparable.

En Debian no hay paquete de esta aplicación, pero se pueden descargar los binarios o el fuente. Se descomprimen los binarios y se ejecutan, sin más.

La aplicación requiere las Kylixlibs (unas librerías de Borland), que tampoco vienen en Debian,

se pueden descargar,

pablo@golgi:~/DBDesigner$
wget http://prdownloads.sourceforge.net/kylixlibs/kylixlibs3-borqt-3.0-2.tar.gz\?download

descomprimir,

pablo@golgi:~/DBDesigner$
tar -xvzf kylixlibs3-borqt-3.0-2.tar.gz

instalar,

pablo@golgi:~/DBDesigner$
cd kylixlibs3-borqt/
pablo@golgi:~/DBDesigner$
sudo ./install.sh

y copiar a /usr/lib/ para que las use DBDesigner

pablo@golgi:~/DBDesigner$
sudo
cp /usr/lib/kylix3/* /usr/lib/

Una vez ahí tan sólo queda ejecutar el DBDesigner,

pablo@golgi:~/DBDesigner$ ./DBDesigner &

Fuentes:

Bases de datos
Herramientas CASE

Comments (0)

Permalink

Sociedades Científicas

Cito de Viva la Ciencia, por Antonio Mingote y José Manuel Sánchez Ron (Editorial Crítica):

Además de sus contribuciones científicas. la Revolución Científica nos dejó una serie de innovaciones, no sólo de ideas, teorías y boservaciones, sino también de comportamientos y mecanismos que resultaron esenciales para el avance científico. Nos estamos refiriendo a las asociaciones profesionales.

Las ideas científicas pueden surgir en ocasiones en escenarios solitarios. [...] Pero, tomada en su conjunto, la actividad científica requiere de instituciones en las que los científicos reciban educación especializada, realicen sus experimentos, intercambien ideas y publiquen sus trabajos. Y fue durante la Revolución Científica cuando se crearon instituciones que sirvieron a estos fines: las primeras sociedades científicas realmente significativas y estables.

En la Europa del siglo XVI proliferaron las universidades. Podemos hablar de ellas, y con razón, como centros de saber. Pero es ésta una denominación un tanto equívoca eran, sobre y por encima de todo, centros de enseñanza, y, de hecho, sus planes de estudios y división en facultades se mantuvieron estáticas durante siglos. Se necesitaba otro tipo de centros para que la ciencia pudiese desarrollarse verdaderamente: las academias y sociedades científicas.

El texto acerca de las Sociedades Científicas sigue, pero creo que es suficiente. Por alguna razón me ha recordado a los hacklabs y medialabs: a los laboratorios de andar por casa donde se pueden desarrollar ideas en colectividad.

Ciencia
Cultura
Libros

Comments (0)

Permalink

Charles Simonyi

Hace un par de semanas leía un artículo traducido al español de Joel Spolsky. Trataba sobre la notación Húngara, un estilo de codificación muy útil si es bien entendida y bien utilizada, cosa que no suele ocurrir (por eso a nivel popular se le tiene tanto rechazo).

Para saber más acerca de la notación húngara recomiendo leer el artículo de Spolsky: Haciendo que el código defectuoso se vea defectuoso.

En ese mismo artículo se menciona que Simonyi era un programador húngaro que inicialmente trabajaba en Xerox Parc en un procesador de textos llamado Bravo, y se acabó pasando a Microsoft para trabajar en el equipo del Word, que es donde inventó la notación húngara con la finalidad de saber de qué clase es cada variable (no del tipo).

Ahora estaba leyendo que el notas va a viajar por segunda vez a la Estación Espacial Internacional en primavera, así que pareceser que con el Word, pese a Clippo, no le fue nada mal.

Lenguajes de Programación
Personajes

Comments (4)

Permalink

Stop the numbers game (II)

En el artículo anterior hablé sobre un paper de David Parnas acerca de cómo evaluar la calidad de un investigador.

Ese artículo iba orientado a explicar su opinión. Ahora pretendo dar mi visión del asunto, muy limitada por mi condición de estudiante.

Precondiciones

Parto de la base de que la investigación científica forma parte del progreso social. No es un pasatiempos, al menos en lo que al nivel institucional respecta. No considero que el Estado deba invertir una pasta en que una serie de personas maten el tiempo encerrados en un laboratorio. Probablemente las empresas con su capital privado tampoco lo consideren.

Sí considero que se debe de invertir el suficiente dinero en investigaciones que a medio o largo plazo vayan a originar (o puedan hacerlo) un progreso para la sociedad (¿qué se entiende por progreso?).

Por esta finalidad eminentemente social de la investigación considero que la transmisión de conocimiento es crucial. De nada sirve invertir tiempo, esfuerzo y dinero (público o privado, me es igual) en investigar, si luego el conocimiento generado no se transmite apropiadamente. Si se investiga no es ni para matar el tiempo, ni para que el producto(s) de esa investigación se quede cogiendo polvo en una estantería.

Por ello veo necesario asegurarse de que las publicaciones científicas presentan un buen volumen de información, pero también de información valiosa. Es decir, calidad y cantidad.

Hasta ahí creo que habíamos llegado todos. El problema se presenta cuando tenemos que optar por más cantidad que calidad, o supuestamente lo contrario, publicar un poco menos, pero de mejor calidad.

¿Publicar mucho y barato o poco y caro?

Como persona relacionada con el software libre estoy bastante influenciado por la mentalidad que reina dentro de lo relacionado con el conocimiento abierto, por ejemplo, con esa idea de Release Early, Release Often.

Publicar a menudo, aunque las ideas estén poco cocinadas, a mi modo de ver, puede tener la ventaja de que se recibe realimentación mucho antes. Si en alguna parte del proceso hemos cometido un error, cuanto antes lo detectemos menor. Si en alguna parte del proceso hemos optado por una aproximación, y (digamos que) nos hemos bifurcado, tener un gran número de papers facilita volver a ese punto de bifurcación para replantearse algunas ideas que hemos estado dando por sentadas los últimos meses.

Creo correcta la idea de David Parnas de que no se puede atender sólo a la cantidad, sino también a la calidad de las publicaciones. Pero para mí, eso no significa que sólo se deban publicar papers bien maduros.

Creo útil publicar pronto y a menudo, pero eso sí, con la marca de paper verde (inmaduro). Creo que no se pueden meter en el mismo saco, ni ponderar por igual los papers verdes (casí a la altura de los apuntes de uso interno en un grupo de investigación) que los papers maduros. Publicar lo inmaduro puede arrojar bastante luz tanto a las investigaciones propias como ajenas, para llegar a evolucionar, a madurar y producir papers bien maduros. A mi modo de ver, y haciendo una analogía con la ingeniería del software: los prototipos sí deben publicarse, no sólo el producto final, pero por supuesto, alertando de su condición de prototipo.

Por mi experiencia, me parece además que ese publicar poco, pero bueno, no es tan frecuente. Más bien se acaba convirtiendo –salvo casos excepcionales– en publicar poco, y no tan bueno como se esperaba, así que no compensa.

Maquillaje

Tampoco me parece que sea hacer trampa coger un paper, darle un poco de maquillaje y volver a publicarlo en otra revista. La trampa es que para evaluar a un investigador nos guiamos exclusivamente por la cantidad de papers sin pararnos a leerlos.

Un mayor número de papers es una mayor transmisión del conocimiento, que es al fin y al cabo para lo que se desarrolla la investigación. Y eso implica más realimentación. Con cambiar las normas de los tribunales y comités para que sea obligatorio leerse los papers creo que valdría, y sería la mejor solución. El problema son los tribunales que no saben (o no quieren) distinguir entre el grano y la paja, no el exceso de paja (con algún grano).

Publicar el mínimo incremento publicable no me parece malo, ni organizar más talleres y conferencias que ponentes, siempre y cuando diferenciemos el nivel de cada ponencia.

Más que arremeter contra el conteo de papers, yo apostaría por centrarnos en diferenciar lo que es un paper serio, de lo que es un esbozo de una serie de ideas poco maduras.

¿Es correcto sólo-firmar frente a firmar-y-pulir?

Es frecuente en las universidades encontrarse profesores que apenas dedican tiempo a un trabajo de unos alumnos pero que sí firman (sólo-firman). Éstos dan a basto con grandes cantidades de alumnos. Por contra, los que pulen junto con sus alumnos el trabajo, atienden menos alumnos, pero obtienen mejor calidad.

Los primeros surgen por la falta de profesorado dispuesto a trabajar con los alumnos. Si hubiera suficiente profesorado los alumnos no dependerían de quien parasita su trabajo, pero ante la falta de profesores hay que apañarse con lo que haya, y siempre será mejor publicar algo malo, que no publicar, siempre que no vaya en el mismo saco lo bueno y lo malo (volvemos a los comités, y a su capacidad para discernir). Obviamente lo óptimo es el profesor que se lo curra y pule además de firmar.

Frente a Parnas

Comparto la opinión de Parnas de que sólo contar los papers no es buena idea, y corrompe el progreso científico. Sin embargo, discrepo con la concepción que me da la impresión que tiene de que realizar el progreso científico debe ser algo elitista, reservado a una minoría muy buena. No creo que deba de estar reservada, pero sí creo que se debe diferenciar entre los del montón, los que son buenos y los que son excelentes. Al fin y al cabo todos cooperan en el progreso, en mayor o menor medida.

Revistas investigación

Comments (0)

Permalink