3 ms·
All of the arguments here seem to assume corruption (even extensibility is a form of it), and to treat it as a thing that can be fixed by the decompressor. It s
by web007 10y ago
All of the arguments here seem to assume corruption (even extensibility is a form of it), and to treat it as a thing that can be fixed by the decompressor. It seems xz isn't ideal in that case, but none of the others are great either. As mentioned elsewhere in this thread, if integrity is your primary concern you should use PAR or some other error-correction mechanism. If you just need a binary integrity indicator you should have separate hashes published somewhere.
xz wasn't chosen for its archival integrity AFAIK, it was chosen for its size. Package distribution ought to spend as much resource as practical to reduce bytes over the wire. Size is why bzip2 "won" over gz despite being many times slower and requiring much more RAM. lrzip would be my first choice for maximum compression, but its downstream resource requirements are far too high vs any of the others, so from my experience xz would be the answer anyway.
- saurik 10y ago> xz wasn't chosen for its archival integrity AFAIK, it was chosen for its size. No: that's why the LZMA compression algorithm is being used. The switch from the original LZMA container format to the "improved" xz container format had nothing to do with size, as the old container generated slightly smaller files in addition to not having this combination of negative properties.
- amaranth 10y agoI remember the hype around LZMA2 and xz being that, because it uses blocks, you can do the compression and decompression on multiple threads. LZMA was generally considered too slow to use for regular usage (only for archival, basically) and multicore was the new way to scale so this was perfect.