Antonio Diaz Diaz antonio@gnu.org
Esta charla introduce el formato de compresión lzip, sus características, implementaciones y usos, incluida su combinación con el formato tar para implementar un formato de archivo comprimido anexionable, robusto y paralelizable. También presenta las recientemente mejoradas capacidades de recuperación combinadas de lziprecover y GNU ddrescue.
Esta charla está disponible en http://www.nongnu.org/lzip/lzip_talk_ghm_2019_es.html y http://www.nongnu.org/lzip/lzip_talk_ghm_2019.html (diapositivas)
Existen muchos algoritmos de comprensión, y no dejan de inventarlos. La mayoría de estos algoritmos son simplemente variaciones de algún otro algoritmo hechas para optimizar alguna característica, generalmente en detrimento del resto. Algunos comprimen muy bien a costa de ser insoportablemente lentos, mientras que otros comprimen rápido a costa de comprimir poco. Algunos incluso intentan acelerar la descompresión omitiendo la comprobación de integridad. La compresión de datos es como cualquier otra cosa; se puede hacer bien o se puede hacer deprisa, pero no las dos cosas.
La compresión de datos de propósito general es un campo bien estudiado. Las ideas básicas de los algoritmos de compresión se descubrieron bastante pronto en la historia de la ciencia de la computación. Deflate y LZMA están basados en ideas descubiertas en los 1970s. Así que no es esperable que un algoritmo mucho mejor que LZMA aparezca en el futuro previsible.
Además, los formatos existentes cuando lzip fue diseñado en 2008 (gzip y bzip2) tienen limitaciones que no son fáciles de arreglar.
Por tanto, parecía adecuado poner un buen algoritmo como LZMA dentro de un formato bien diseñado para que pudiera ser usado en todas las tareas que requieran fiabilidad o interoperabilidad. Por ejemplo, archivo a largo plazo o distribución de datos comprimidos para un amplio rango de máquinas, desde dispositivos embebidos a mainframes. Lzip es un intento de desarrollar un formato así.
Quizás os estéis preguntando por qué desarrollé lzip en lugar de añadir compresión LZMA a gzip, por ejemplo. Esto hubiera evitado la necesidad de una nueva extensión de fichero, y la gente podría obtener soporte para el nuevo formato simplemente actualizando su gzip. Después de todo un nuevo formato y herramienta son una molestia, ¿no?
Parece una buena idea, y la gente ha estado proponiéndola desde hace mucho tiempo. Por ejemplo, H. Peter Anvin lo intentó en 2006: http://lkml.org/lkml/2006/9/21/236
"Me he estado resistiendo a implementar LZMA en kernel.org, porque al igual que zip (deflate) no se hizo común en el mundo Unix hasta que un formato de encapsulación que maneje cosas esperadas en el mundo Unix, por ejemplo streaming, fue creado (gzip), no creo que LZMA vaya a ser ampliamente usado hasta que exista un "lzip" que haga lo mismo. Incluso comencé el trabajo de añadir soporte LZMA a gzip, pero entonces me di cuenta de que sería mejor si un nuevo formato de encapsulación con soporte apropiado de 64 bits en todas partes fuera creado."
En este contexto, "soporte de 64 bits" significa "tamaños de fichero de 64 bits" no "procesadores de 64 bits".
La razón por la que esto no funcionó es que el formato gzip fue diseñado hace mucho tiempo, tiene limitaciones, y no puede ser fácilmente extendido sin imponer estas limitaciones al nuevo algoritmo. En el siguiente diagrama simplificado podemos ver que gzip carece de un índice y almacena solamente los 32 bits menos significativos del tamaño descomprimido (ISIZE). (Más adelante veremos por qué estas limitaciones son importantes).
+=============+=====================+-+-+-+-+-+-+-+-+ | gzip header | compressed blocks | CRC32 | ISIZE | <-- no index +=============+=====================+-+-+-+-+-+-+-+-+
Así que desarrollé un nuevo formato de encapsulación con las características requeridas y lo llamé lzip. Si alguna vez es necesario, creo que el formato lzip será capaz de incorporar sin fisuras un nuevo algoritmo de compresión.
Lzip ha sido diseñado, escrito y probado con gran cuidado para reemplazar a gzip y bzip2 como formato estándar de compresión de propósito general para sistemas tipo unix, especialmente para el sistema operativo GNU. En esta charla veremos algunas de las lecciones aprendidas de estos formatos previos, y su aplicación al diseño de lzip.
Lzip utiliza una implementación independiente del "algoritmo" LZMA inventado/descubierto por Igor Pavlov. A pesar de su nombre (Lempel-Ziv-Markov chain-Algorithm), LZMA no es un algoritmo concreto; es más parecido a "cualquier algoritmo que utilice el esquema de codificación LZMA". Por ejemplo, la opción '-0' de lzip utiliza el esquema en casi su forma más simple posible; emitiendo la coincidencia más larga que pueda encontrar, o un byte literal si no encuentra ninguna coincidencia. Utilizando variaciones diferentes (pero compatibles) de LZMA, un amplio rango de ratios y velocidades de compresión se pueden conseguir, desde aproximadamente la velocidad de gzip hasta más allá de la ratio de compresión de bzip2. La velocidad de descompresión secuencial (con una sola hebra de ejecución) es intermedia entre gzip y bzip2.
LZMA tiene dos parámetros principales: tamaño de diccionario y límite de la longitud de coincidencia. LZMA es muy parecido a deflate, el algoritmo de gzip, con dos diferencias principales que dan cuenta de su mayor ratio de compresión. Primero, LZMA puede utilizar un tamaño de diccionario miles de veces más grande que deflate. Segundo, LZMA utiliza un codificador de rango como su última etapa, en lugar de la menos eficiente (pero más rápida) codificación de Huffman utilizada por deflate.
Lzip implementa dos variantes del algoritmo LZMA; rápida (usada por la opción '-0') y normal (usada por todos los demás niveles de compresión).
Un fichero lzip está formado por uno o más "miembros". Cada miembro tiene la siguiente estructura:
+--+--+--+--+----+----+=============+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID string | VN | DS | LZMA stream | CRC32 | Data size | Member size | +--+--+--+--+----+----+=============+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lzip permite una rápida descompresión paralela gracias a su índice distribuido (el campo 'Member size' en el diagrama de arriba).
Lzip limita el tamaño de diccionario a un 1/8 del máximo permitido por LZMA, lo que tiene dos ventajas. Primero, permite la descompresión eficiente en máquinas de 32 bits. Segundo, transforma los tamaños no utilizados en detección distribuida de errores, lo que es la base de algunas de las capacidades de recuperación de lziprecover.
Lzip proporciona una comprobación de integridad de tres factores robusta y segura. La probabilidad estimada de que lzip no detecte un error en un fichero es de aproximadamente 6e-17. Este elevado nivel de seguridad es otra de las bases de las capacidades de recuperación de datos de lziprecover. Resultados preliminares incluso sugieren que el formato lzip es suficientemente seguro como para ser usado en sistemas de aviónica de seguridad crítica.
El formato lzip es tan simple como es posible (pero no más simple). Ofrece todas las características requeridas para la compartición de datos y el archivo a largo plazo seguros y eficientes, pero no más características. Porque para la interoperabilidad y el archivo a largo plazo, lo simple es robusto.
El formato lzip no almacena metadatos del fichero original, excepto su tamaño. Por tanto, los ficheros lzip son reproducibles; lzip produce salidas idénticas a partir de entradas idénticas.
Lzip está preparado para el futuro. Ofrece tamaños comprimidos y descomprimidos de 64 bits, y la implementación de referencia produce automáticamente un fichero multimiembro cuando el tamaño es demasiado grande para un solo miembro, permitiendo un tamaño ilimitado de fichero.
El formato lzip proporciona un índice distribuido (el campo 'Member size' en el diagrama de abajo). Un índice es esencial para la descompresión paralela eficiente, mejora la verificación de la integridad de los datos, ayuda a lziprecover en la recuperación de ficheros dañados, y permite el listado de tamaños de fichero correctos incluso para ficheros multimiembro.
Ni el formato gzip ni el formato bzip2 proporcionan un índice. Gzip y bzip2 fueron diseñados antes de la era de los multiprocesadores, cuando un índice no era tan importante.
(Los diagramas de los formatos gzip y bzip2 están simplificados. La cola de bzip2 no está alineada a un byte, pero eso no es importante aquí).
gzip 32-bit size +=============+=====================+-+-+-+-+-+-+-+-+ | gzip header | compressed blocks | CRC32 | ISIZE | <-- no index +=============+=====================+-+-+-+-+-+-+-+-+ bzip2 +==============+====================+-+-+-+-+ | bzip2 header | compressed blocks | CRC32 | <-- no size, no index +==============+====================+-+-+-+-+ lzip 64-bit sizes index entry +--+--+--+--+----+----+=============+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID string | VN | DS | LZMA stream | CRC32 | Data size | Member size | +--+--+--+--+----+----+=============+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
En el diagrama se puede ver que gzip solamente almacena los 32 bits menos significativos del tamaño descomprimido (ISIZE). Esta es probablemente la limitación más frecuentemente reportada del formato gzip, porque el tamaño de cualquier fichero mayor que 4 GiB se almacena truncado. Bzip2 ni siquiera almacena el tamaño del fichero descomprimido.
La compresión paralela es fácil; uno simplemente divide la entrada en trozos, comprime los trozos en paralelo, y escribe en orden los trozos comprimidos a la salida. Por otra parte, la descompresión paralela eficiente necesita un formato diseñado para la tarea.
Un índice como el proporcionado por el formato lzip es esencial para una descompresión paralela eficiente porque les dice a las hebras dónde comenzar a descomprimir. En estos diagramas de ficheros multimiembro, uno puede ver como las cabeceras de los miembros lzip se pueden localizar comenzando desde el final del fichero y sustrayendo cada 'member size' (MS) hasta que se alcanza el principio del fichero. En el caso de gzip no hay forma de saber donde comienzan los miembros sin descomprimirlos.
gzip +=============+=============+=============+=============+=============+ | member | member | member | member | member | +=============+=============+=============+=============+=============+ __________ __________ __________ __________ __________ | | | | | | | | | | V | V | V | V | V | +=============+=============+=============+=============+=============+ | member | MS | member | MS | member | MS | member | MS | member | MS | +=============+=============+=============+=============+=============+ lzip
Gracias al índice, la implementación multihebra de lzip (plzip) es uno de los descompresores más rápidos que existen. Sin un índice, el fichero tiene que ser analizado secuencialmente para encontrar los puntos de entrada de la descompresión. En el caso de gzip ni siquiera el análisis secuencial es posible en la práctica a causa del pequeño tamaño de la cadena de identificación en la cabecera gzip (16 bits). Por tanto, la descompresión de ficheros gzip no puede ser paralelizada. El resultado es que plzip puede descomprimir ficheros regulares más rápido que pigz (la implementación multihebra de gzip) en máquinas con más de 4 procesadores.
Plzip puede descomprimir también en paralelo flujos de datos de acceso secuencial porque el campo 'Member size' valida la cadena de identificación de la cabecera lzip, encontrando fiablemente los puntos de entrada de descompresión.
Es muy importante para un formato con aspiraciones a convertirse en universal que las herramientas que lo procesan puedan ser portadas a todo tipo de arquitecturas y máquinas. Especialmente a las más antiguas y menos capaces, que es donde normalmente aparecen los problemas.
Estas son las herramientas lzip que yo mantengo. Cada una de ellas ofrece alguna característica única:
Lzip La implementación de referencia (C++).
Clzip Una implementación en C para sistemas sin compilador C++.
Plzip Un compresor paralelo (multihebra) para el formato lzip.
Lzlib Una libreria de compresión para el formato lzip, escrita en C.
Lziprecover Una herramienta de recuperación de datos y descompresor.
Lunzip Un descompresor para ficheros lzip escrito en C.
Pdlzip Una implementación limitada, de "dominio público" en C
destinada a aquellos que no pueden distribuir Software Libre
bajo licencia GPL.
Lzd Un descompresor educacional para el formato lzip.
Tarlz Un archivador con compresión lzip multihebra.
De lziprecover y tarlz hablaremos más adelante.
Otros desarrolladores también mantienen herramientas y librerias para el formato lzip.
Igual que el formato lzip proporciona protección de tres factores contra la corrupción de datos no detectada, la metodología de desarrollo de la familia de compresores lzip proporciona protección de tres factores contra errores de programación no detectados.
Tres implementaciones relacionadas pero independientes, lzip, clzip y minilzip/lzlib, son desarrolladas concurrentemente. Cada versión estable de cualquiera de ellas es sometida a 100 horas de pruebas intensivas para verificar que produce una salida idéntica a la de las otras dos. Esto garantiza que las tres implementan el mismo algoritmo, y hace improbable que cualquiera de ellas pueda contener errores de programación serios no descubiertos. De hecho, no se han descubierto errores en lzip (más allá de problemas de portabilidad) desde 2009.
Adicionalmente las tres implementaciones han sido extensivamente probadas con unzcrash, valgrind y 'american fuzzy lop' sin encontrar una sola vulnerabilidad ni falso negativo.
El formato lzip es adecuado para hardware nuevo y antiguo. De 64 o 32 bits. Desde supercomputadores a dispositivos embebidos. Esto permite a los usuarios de hardware antiguo continuar usándolo, y evita la contaminación causada por su reemplazo.
Por ejemplo, clzip, la versión en lenguaje C de lzip, puede ser compilado en máquinas en las que gzip no puede ni siquiera ser configurado. Y lunzip proporciona un modo de 'bajo uso de memoria' capaz de descomprimir cualquier fichero usando un mínimo de 50 kB de memoria, independientemente del tamaño de diccionario usado para comprimir el fichero. Ambos han sido probados en un portátil con un procesador 486 y 4 MiB de RAM.
Lziprecover proporciona capacidades de recuperación de datos únicas porque el formato lzip ha sido diseñado desde el principio para ser simple y seguro. También ayuda que el flujo de datos LZMA tal y como lo usa lzip es extraordinariamente seguro porque proporciona detección de errores distribuida. Cualquier distancia mayor que el tamaño del diccionario actúa como un símbolo prohibido, permitiendo al descompresor detectar la posición aproximada de los errores, y dejando muy poco trabajo para la secuencia de comprobación (CRC y tamaños de datos) en la detección de errores. Lzip es normalmente capaz de detectar todos las posibles corrupciones de un bit en los datos comprimidos sin necesitar la secuencia de comprobación. Sería difícil escribir una herramienta de recuperación automática como lziprecover para el formato gzip. Y por lo que yo sé, nunca se ha escrito.
El formato lzip no incluye bloques de datos redundantes ni códigos de corrección de errores (ECC). Es simplemente que la comprobación de integridad del formato lzip es suficientemente segura como para permitir a lziprecover reparar pequeños errores y encontrar y combinar las partes buenas de varias copias dañadas prácticamente sin peligro de hacerlo incorrectamente.
Además de descomprimir y comprobar la integridad de ficheros lzip, lziprecover puede:
La versión de desarrollo de lziprecover ha introducido recientemente un nuevo método de recuperación (modo reproducción) que puede ser útil para recuperarse de errores de hardware en series de copias de seguridad o tarballs fuente. El modo reproducción se basa en el hecho de que normalmente sólo una pequeña fracción de los datos cambia de una copia de seguridad o de una tarball fuente a la siguiente. Por tanto, es a veces posible arreglar una tarball corrupta, que ddrescue fue incapaz de leer sin errores, usando datos de referencia de otra tarball correspondiente a una versión cercana. Los datos de referencia son usados por lziprecover para rellenar el sector perdido, arreglando el fichero.
Veamos como funciona.
Imaginemos que el disco duro falla. Intentamos rescatar los datos con ddrescue, pero ddrescue es incapaz de leer los datos correspondientes al sector 9 ('s9' en el diagrama de abajo). Esto deja un "agujero" en el archivo tar.lz que contiene s9. En este caso, los datos comprimidos originalmente en este agujero fueron el resultado de comprimir parte del 'fichero 2, el cual a su vez forma parte de un archivo tar. Ahora, si otra copia del 'fichero 2' se encuentra en alguna parte, o bien sola o dentro de un archivo tar diferente, lziprecover puede utilizar lzip para comprimir de nuevo la parte del 'fichero 2' que falta, y rellenar 's9' con ello. No importa si la copia de referencia del 'fichero 2' usada ha sido modificada, siempre que la modificación no afecte a la parte que tiene que ser comprimida para reproducir los datos perdidos de 's9'.
Nota: en el diagrama siguiente los tamaños de los ficheros parecen iguales, pero los archivos tar mostrados son normalmente mucho mas grandes que los correspondientes archivos tar.lz comprimidos.
disc sectors as read by ddrescue (data from 's9' are missing) +====+====+====+====+====+====+====+====+====+=====+=====+=====+=====+ | s1 | s2 | s3 | s4 | s5 | s6 | s7 | s8 | s9 | s10 | s11 | s12 | s13 | +====+====+====+====+====+====+====+====+====+=====+=====+=====+=====+ tar.lz (stored in s1 to s13) +====================================================================+ | lzip member | +====================================================================+ tar archive corresponding to the tar.lz above +================+================================+============+=====+ | file 1 | file 2 | file 3 | EOF | +================+================================+============+=====+ Some other tar also containing a copy of 'file 2' 's9' is reproduced using data from this copy of 'file 2' +================================+================+============+=====+ | file 2 | file 4 | file 5 | EOF | +================================+================+============+=====+
¿Qué ocurre si el sector perdido es 's4', que contiene datos del 'fichero 1', 'fichero 2' y de la cabecera tar correspondiente al 'fichero 2'? En este caso necesitamos utilizar como referencia un archivo tar que contenga el 'fichero 1' y el 'fichero 2'en el mismo orden que el archivo tar que hay que reproducir. También los metadatos del 'fichero 2' tienen que ser idénticos entre ambos archivos.
Por cierto, probar lziprecover lleva un montón de tiempo porque lziprecover procesa ficheros corruptos, y hay una cantidad casi infinita de formas en que un fichero puede corromperse.
Siguiendo el concepto Unix de "hacer una cosa y hacerla bien", la creación y compresión de archivos han sido mantenidas hasta ahora como dos tareas separadas, normalmente realizadas por tar y gzip respectivamente. El archivo tar entero era normalmente comprimido en un solo miembro gzip (compresión sólida), lo que tiene la ventaja de conseguir una alta ratio de compresión. Por otra parte, un archivo comprimido solidamente no puede ser ni descomprimido ni decodificado en paralelo. Tampoco se pueden añadir ficheros al final del archivo. El archivo entero tiene que ser descomprimido incluso si uno solo quiere extraer un fichero. Por último, en caso de corrupción de datos, la mitad del archivo (en promedio) se pierde junto con la comprobación de integridad de la parte recuperable.
tar +============+============+============+============+=============+========+ | tar member | tar member | tar member | tar member | tar member | EOF | +============+============+============+============+=============+========+ tar.lz (solid compression) +==========================================================================+ | lzip member | +==========================================================================+
El primer intento de paralelizar la descompresión de archivos tar consistió en usar un compresor paralelo, como lbzip2 o plzip. (Como vimos antes, la descompresión de ficheros gzip no se puede paralelizar). La ratio de compresión es ligeramente menor que con la compresión sólida. La descompresión es más rápida porque el archivo se puede descomprimir en paralelo, pero la capa tar funciona igual que antes. Tar tiene que procesar el archivo completo de forma secuencial. La falta de alineación entre los miembros tar y los miembros comprimidos impide que el archivo pueda ser decodificado en paralelo. Tampoco se pueden añadir ficheros al final del archivo. Para extraer un solo fichero, hace falta descomprimir el miembro lzip que contiene el fichero y todos los miembros que lo preceden.
"Alineación" aquí significa que cada miembro comprimido contiene un número entero de miembros tar, cosa que no se puede conseguir comprimiendo un archivo tar con un compresor paralelo. La alineación es importante para una extracción paralela eficiente porque si un miembro tar está partido entre dos miembros comprimidos, no puede ser extraído por ninguna de las dos hebras involucradas.
Por último, en caso de corrupción de datos, la mitad (en promedio) del miembro lzip donde ocurrió la corrupción se pierde, junto con la comprobación de integridad de la parte recuperable. Hace falta un descompresor especial (lziprecover), capaz de ignorar el error y continuar descomprimiendo los miembros lzip restantes, para recuperar la parte del archivo que sigue a la corrupción.
tar +============+============+============+============+=============+========+ | tar member | tar member | tar member | tar member | tar member | EOF | +============+============+============+============+=============+========+ tar.lz (plzip unaligned compression) +======================+========================+==========================+ | lzip member | lzip member | lzip member | +======================+========================+==========================+
Con la generalización de los ordenadores multiprocesador, la definición de lo que cuenta como "una cosa" (en "hacer una cosa y hacerla bien") ha cambiado. Resulta que la creación, extracción y listado eficientes en paralelo de tarballs comprimidas es una tarea, no dos, porque la comunicación requerida entre el archivador y el compresor necesita ir más allá de la comunicación normal a través de un flujo de datos, como en 'tar -c | plzip'. Una sola herramienta que controle el archivo y la compresión es necesaria para garantizar la alineación entre miembros tar y miembros comprimidos. Es también conveniente que el formato comprimido proporcione un índice, lo que hace posible decodificar el archivo tar eficientemente en paralelo.
La ratio de compresión de la compresión alineada es menor que la de la compresión sólida (dependiendo del tamaño del miembro lzip). La extracción es rápida porque el archivo se puede descomprimir y decodificar en paralelo. Se pueden añadir ficheros al final del archivo. Para extraer un fichero, sólo hace falta descomprimir las cabeceras tar para encontrar el fichero. El miembro lzip que contiene el fichero es el único que hace falta descomprimir completo.
En caso de corrupción de datos, sólo se pierde la mitad de un miembro tar (en promedio), junto con la comprobación de integridad de la parte recuperable. Tarlz puede saltarse el miembro dañado y continuar decodificando los miembros restantes, exactamente igual que el tar estándar (no comprimido). La alineación de los miembros minimiza el número de miembros tar afectados, lo que normalmente también minimiza la cantidad de datos perdidos.
El incremento de velocidad puede ser espectacular en algunos casos. Por ejemplo, el listado paralelo de un archivo tar.lz regular que contenga ficheros grandes puede ser cientos de veces más rápido que el listado secuencial, porque además de utilizar varios procesadores, sólo se necesita descomprimir una pequeña parte de cada miembro lzip.
tar +==============+==============+==============+==============+==============+ | tar member | tar member | tar member | tar member | EOF | +==============+==============+==============+==============+==============+ tar.lz (aligned compression) +==============+==============+==============+==============+==============+ | lzip member | lzip member | lzip member | lzip member | lzip member | +==============+==============+==============+==============+==============+
Si los ficheros en el archivo son pequeños, comprimirlos de forma independiente puede resultar en una baja ratio de compresión. Para incrementar la ratio de compresión, varios miembros tar se pueden comprimir juntos en cada miembro comprimido, en tanto que se mantenga la alineación.
La ratio de compresión de la compresión agrupada alineada es aproximadamente tan buena como la de un compresor paralelo como plzip (dependiendo del tamaño del miembro lzip). La extracción es rápida porque el archivo se puede descomprimir y decodificar en paralelo. Se pueden añadir ficheros al final del archivo. Para extraer un fichero, sólo hace falta descomprimir los principios de los miembros lzip hasta la última cabecera tar de cada miembro para encontrar el fichero. El miembro lzip que contiene el fichero es el único que hace falta descomprimir completo (para comprobar la integridad de los datos).
En caso de corrupción de datos, sólo se pierde la mitad de un miembro lzip (en promedio), junto con la comprobación de integridad de la parte recuperable. Tarlz puede saltarse el miembro dañado y continuar decodificando los miembros restantes, exactamente igual que el tar estándar (no comprimido).
tar +==============+==============+==============+==============+==============+ | tar member | tar member | tar member | tar member | EOF | +==============+==============+==============+==============+==============+ tar.lz (grouped aligned compression) +=============================+=============================+==============+ | lzip member | lzip member | lzip member | +=============================+=============================+==============+
En resumen, ¿qué es tarlz?
Tarlz es una implementación combinada masivamente paralela (multihebra) del archivador tar y el compresor lzip.
¿Por qué es necesaria una implementación combinada?
Porque para las herramientas multihebra, la creación y la compresión de un archivo es una tarea, no dos. Por tanto una sola herramienta que controle el archivo y la compresión es necesaria para garantizar la alineación entre miembros tar y miembros comprimidos.
Algunas características de tarlz:
Los archivos tar.lz multimiembro creados por tarlz son plenamente compatibles con herramientas tar estándar como GNU tar, que los tratan como cualquier otro archivo tar.lz.
* La extracción multihebra no está todavía implementada en tarlz, pero tengo planeado empezar a implementarla en cuanto acabe este GHM.
Creo que todos los paquetes GNU donde tiene sentido ya están soportando lzip. Por ejemplo:
Varios proyectos GNU y nongnu ya distribuyen sus tarballs fuente en formato lzip. Guix distribuye sus sustitutos (paquetes) en formato lzip. Dragora GNU/Linux distribuye sus paquetes en formato tar.lz.
Respecto a la distribución de tarballs fuente, una cosa que los desarrolladores normalmente no consideran es que el formato utilizado para distribuir código fuente debería ser elegido cuidadosamente porque las tarballs fuente se supone que deben ser archivadas para siempre como una forma de compilar y correr una versión dada de algún software en el futuro, por ejemplo, para decodificar datos antiguos.
Está bien distribuir paquetes binarios en un formato que descomprima rápido, siempre que el código fuente sea distribuido en un formato adecuado para archivo a largo plazo.
Fuera del proyecto GNU algunos proyectos notables están usando lzip para distribuir sus datos. Por ejemplo:
¡Gracias por vuestra atención!
¿Alguna pregunta?
Copyright © 2019 Antonio Diaz Diaz.
You are free to copy and distribute this article without limitation, but you are not allowed to modify it.
First published: 2019-09-04