¿Qué formato de compresión deberíamos usar? ¿Deberíamos dejar DEFLATE (.zip) para descansar?

Question

Con la mayoría de las distribuciones Linux descartando gzip y bzip2 a favor de LZMA2 para comprimir sus paquetes, y muchas implementaciones de código abierto para muchas plataformas, me pregunto: ¿No deberíamos poner DEFLATE y el formato .zip (que lamentablemente se bastardizó una y otra vez) para descansar, y pasar a otras formas modernas de distribuir nuestros paquetes (fuente)?

GNU tar apoya el interruptor J, que utiliza xz (otro LZMA2 compresor) como filtro:

$ tar cJf foo.tar.xz foo/ 

Sin embargo, tiendo a utilizar 7z (aplicación p7zip) y es amigo 7za bajo Linux para crear archivos. Todavía utilizo el paradigma "evitar bombas de alquitrán" al crear archivos, lo que significa que hay un directorio en esos archivos, por lo que extraer de la línea de comandos no produce derrames en el directorio actual (esto es modus operandi en Linux con cosas como tar, pero parece ser mucho menos recomendable en Windows).

De todos modos, parece que debido al uso en paquetes (Fedora RPM y Ubuntu DEB, por ejemplo), así como filtros para herramientas como tar, que LZMA2 es la "mejor opción" que viene después de bzip2. Tiene una gran tasa de compresión (supera a bzip2 por mucho en configuraciones estándar) y es muy rápido en eso también (la compresión es un poco más lenta que gzip,

Me hice algunos puntos de referencia, pero me gustaría cambiar el lugar en algunos puntos de referencia más amplios: punto de referencia basado

• Clasificación en compressionratings.com
• punto de referencia basado en la eficiencia maximumcompression.com

Ahora, se dará cuenta, que 7-zip, que es la referencia impl ementación, no aparece en primer lugar. Sin embargo, Freearc usa su propio formato .arc, que no es compatible con plataforma cruzada y no es compatible con el antiguo ARC de los años 80. nanozip no es de código abierto, ¡qué tipo de caída, pero es el algoritmo lo que cuenta, no el archivador!

De todas formas, ahora que el rendimiento con 7-zip y sus implementaciones derivados (xz), no es un problema más, y la relación de compresión es hablar por sí mismo, me siento como la distribución de mis paquetes de código como .7z o .tar.xz archivos. Sin embargo, tengo dos obstáculos en frente de mí, que no parecen capaces de tomar la I:

1. Los defensores de WinRAR. No me malinterpreten, no guardo rencor contra WinRAR o sus usuarios, es solo que realmente no puedo hacer RAR en Linux, y no hay necesidad de hacerlo, ya que tenemos herramientas LZMA2 gratuitas. Y como dije, desde que se convirtió en una parte integral de los paquetes de distribución, está disponible en cualquier Distribución moderna. Dado que toma aproximadamente el mismo tiempo hacer un .7z que un .rar y los archivos LZMA2 son generalmente más pequeños, no veo porqué no usar 7-zip.

2. tar archivos tienen que ser zip o bzip2, sin excepciones. Esto es difícil. ¿Por qué tanta gente está impresionada con gzip? Incluso bzip2 no ve mucho uso la mayor parte del tiempo.Por supuesto, gzip es rápido, un buen punto cuando se trata de la compresión según demanda, como en los servidores web, o cuando se crean copias de seguridad espejo grandes. Pero, ¿qué hay de distribuir el software? LZMA2 es muy asimétrico. Mientras que la compresión toma su tiempo, la descompresión es increíblemente rápida.

OK, ahora aquí viene mi pregunta:

Desde LZMA2 es posiblemente la próxima mejor algoritmo de compresión, por qué la gente no saltar en el tren? ¿Por qué la gente todavía usa WinRAR, que es propietario, tiene una relación de compresión peor, y no está portado a Linux (excepto unrar, pero obviamente no puede crear archivos con eso). ¿Por qué las bolas de alquitrán siguen siendo gziped en su mayoría?

¿No hay forma de convencer a las personas de pasar a un formato de archivo más nuevo y confiable, que no solo sea multiplataforma, sino también gratuito? Cuando le doy a alguien un archivo que termina en .7z, tienden a no saber qué hacer con él, ¿cambiará esto alguna vez?

Ah, y esta es la pequeña referencia que hice yo mismo. He utilizado la configuración por defecto en todas partes:

11837440 GNUtar_TAR.tar 
10657984 Arc_ARC.arc 
9632524 PA2010_TAR_BZip2.tar.bz2 
9536967 PA2010_LHA_Frozen5.lzh 
9510148 PA2010_ZIP_BZip2.zipx 
9490211 GNUtar_TAR.tar.bz2 
9467242 PA2010_LHA_Frozen6.lzh 
9463630 7-zip_ZIP_BZip2.zip 
9437520 7-zip_7-ZIP_BZip2.7z 
9398798 Arj_ARJ.arj 
9373435 GNUtar_TAR.tar.gz 
9370456 PA2010_BlackHole_Deflate.bh 
9369621 Lha_LHA_Frozen6.lzh 
9367712 PA2010_ZIP_Deflate.zip 
9364237 PA2010_TAR_gzip.tar.gz 
9360248 PA2010_Cabinet_MsZip.cab 
9303923 7-zip_ZIP_Deflate.zip 
9215279 7-zip_ZIP_Deflate64.zip 
9189365 PA2010_ZIP_PPMd.zipx 
9060663 PA2010_7-ZIP_PPMd.7z 
8931280 PA2010_Cabinet_LZX.cab 
8847427 7-zip_7-ZIP_PPMd.7z 
8803350 PA2010_ZIP_Optimized.zipx 
8803350 PA2010_ZIP_Wavpack.zipx 
8802850 PA2010_ZIP_LZMA.zipx 
5812491 FreeArc_7-ZIP.arc 
5789853 7-zip_7-ZIP_LZMA.7z 
5789853 PA2010_7-ZIP_LZMA.7z 
5789024 GNUtar_TAR.tar.xz 
5782637 FreeArc_UHARC.arc 
5770969 FreeArc_CCM.arc 
5739697 Fp8_5.fp8 
5718865 Fp8_8.fp8 
5685234 Paq8px_5.paq8px 
5677662 Paq8kx_5.paq8kx 
5644422 Paq8px_8.paq8px 
5609608 Paq8kx_8.paq8kx 

(tamaño en bytes; Nombre del archivo: Archiver_Format_Algorithm.Extension)

El conjunto de filles consiste en imágenes de disco que contienen una instalación de DOS:

1474979 disk01.144 
1474979 disk02.144 
1474979 disk03.144 
1474979 disk04.144 
1474979 disk05.144 
1474979 ldisk01.144 
1474979 ldisk02.144 
1474979 ldisk03.144 
24325 diskcopy.com 

(Tamaño en bytes)

Answer 1

Solía ​​ser ese bz2 wa no es una opción para tarballs. Luego alguien agregó una opción a GNU Tar para crear y leer archivos bz2, y muy pronto el formato comenzó a extenderse. Así que la respuesta es:

Si cree en LZMA, envíe los parches a la Free Software Foundation (con todos los trámites correspondientes) y hará que el mundo sea un lugar mucho mejor.