Si j'ai bien suivi, il semble que l'auteur de xz a aussi amélioré le format au passage.
Voila les specs du nouveau format xz : http://tukaani.org/xz/xz-file-format.txt ; elles indiquent noir sur blanc que ce nouveau format diffère de l'ancien LZMA, entre autres ici :
« This document describes the .xz file format (filename suffix
.xz, MIME type application/x-xz). It is intended that this
this format replace the old .lzma format used by LZMA SDK and
LZMA Utils.
[...]
LZMA2 is an extensions on top of the original LZMA. LZMA2 uses
LZMA internally, but adds support for flushing the encoder,
uncompressed chunks, eases stateful decoder implementations,
and improves support for multithreading. Thus, the plain LZMA
will not be supported in this file format. ».
« The .lzma format is too primitive. It doesn't have an integrity check like CRC32 and it has no magic bytes to make it easy to detect the file type. The .xz format doesn't have these problems. There are some additional features like support for multiple filters (algorithms), filter chaining (like piping on the command line), and limited random-access reading. The .xz format also makes it easier to write multithreaded encoder and decoder. ».
Est-ce que l'un d'entre vous saurait si la parallélisation (le support du « multithread ») de l'encodeur/décodeur est déjà implémentée ?
J'imagine que cette fonctionnalité sera de plus en plus pertinente, dès lors que les CPU x86 vendues de nos jours sont pour la plupart multi-cœurs ou multithreads (avec un nombre de cœurs/threads plutôt en augmentation).
[^] # Re: tar
Posté par herodiade . En réponse à la dépêche Slackware abandonne les tgz. Évalué à 10.
Voila les specs du nouveau format xz : http://tukaani.org/xz/xz-file-format.txt ; elles indiquent noir sur blanc que ce nouveau format diffère de l'ancien LZMA, entre autres ici :
« This document describes the .xz file format (filename suffix
.xz, MIME type application/x-xz). It is intended that this
this format replace the old .lzma format used by LZMA SDK and
LZMA Utils.
[...]
LZMA2 is an extensions on top of the original LZMA. LZMA2 uses
LZMA internally, but adds support for flushing the encoder,
uncompressed chunks, eases stateful decoder implementations,
and improves support for multithreading. Thus, the plain LZMA
will not be supported in this file format. ».
Concernant la justification de ces divergences/améliorations du format, je cite l'auteur ( source : http://sourceforge.net/forum/forum.php?thread_id=2918394&(...) ):
« The .lzma format is too primitive. It doesn't have an integrity check like CRC32 and it has no magic bytes to make it easy to detect the file type. The .xz format doesn't have these problems. There are some additional features like support for multiple filters (algorithms), filter chaining (like piping on the command line), and limited random-access reading. The .xz format also makes it easier to write multithreaded encoder and decoder. ».
Est-ce que l'un d'entre vous saurait si la parallélisation (le support du « multithread ») de l'encodeur/décodeur est déjà implémentée ?
J'imagine que cette fonctionnalité sera de plus en plus pertinente, dès lors que les CPU x86 vendues de nos jours sont pour la plupart multi-cœurs ou multithreads (avec un nombre de cœurs/threads plutôt en augmentation).