3 ms·

None of this addresses the criticism levied in the article, nor does it defend xz's inconsistent design decisions that are all over the place. Why shouldn't we

None of this addresses the criticism levied in the article, nor does it defend xz's inconsistent design decisions that are all over the place. Why shouldn't we try to squeeze the highest rate of data recovery out of the unlikely event that we're left with the only remaining copy if it costs nothing extra (just the choice of one archiver over another)? Should you choose xz for future archival purposes? No. Should Debian make an active effort to switch away from xz now? Probably not, as their primary concern is distribution, not archival, and xz is good enough.

jmillikin 4y ago
> None of this addresses the criticism levied in the article The article's criticism isn't worth addressing (or reading). Nothing it complains about is important. > nor does it defend xz's inconsistent design decisions that are all > over the place. The level of inconsistency that the article complains about doesn't matter. Pretty much every popular format looks like that. Try writing a Matroska or PDF decoder some time. > Why shouldn't we try to squeeze the highest rate of data recovery > out of the unlikely event that we're left with the only remaining > copy if it costs nothing extra Because it isn't important. For cases where recovery of data from a corrupt compressed stream is important, you'd wrap the compressed data in a container with built-in error correction. Then you'd use that format's error correction to recover the correct compressed data stream, and feed that to your decompressor. > Should you choose xz for future archival purposes? No. Yes you should. XZ is fine, despite the article's silliness. It's better than gzip or bzip2 and nearly as widely supported. If there's a replacement for XZ as a general-purpose compression format for archived data then it'll be selected on the quality of its compression, not whether the bitstream format can produce valid output from invalid input.
- mike_hock 4y ago
  > The level of inconsistency that the article complains about doesn't matter. Pretty much every popular format looks like that. Try writing a Matroska or PDF decoder some time. So a format should be designed wrong because other formats are also designed wrong. > Because it isn't important. So? You don't have to go out of your way to micro-optimize, others like TFA's author are already doing it for you. You just have to pick the micro-optimized product off the shelf. "It isn't important" is a complete non-argument when the bad choices are made for no reason and no benefit at all and especially not even making the design process quicker and easier. > If there's a replacement for XZ as a general-purpose compression format for archived data then it'll be selected on the quality of its compression, not whether the bitstream format can produce valid output from invalid input. The article also addresses design problems that harm the compression ratio.

jmillikin 4y ago

> None of this addresses the criticism levied in the article The article's criticism isn't worth addressing (or reading). Nothing it complains about is important. > nor does it defend xz's inconsistent design decisions that are all > over the place. The level of inconsistency that the article complains about doesn't matter. Pretty much every popular format looks like that. Try writing a Matroska or PDF decoder some time. > Why shouldn't we try to squeeze the highest rate of data recovery > out of the unlikely event that we're left with the only remaining > copy if it costs nothing extra Because it isn't important. For cases where recovery of data from a corrupt compressed stream is important, you'd wrap the compressed data in a container with built-in error correction. Then you'd use that format's error correction to recover the correct compressed data stream, and feed that to your decompressor. > Should you choose xz for future archival purposes? No. Yes you should. XZ is fine, despite the article's silliness. It's better than gzip or bzip2 and nearly as widely supported. If there's a replacement for XZ as a general-purpose compression format for archived data then it'll be selected on the quality of its compression, not whether the bitstream format can produce valid output from invalid input.

mike_hock 4y ago
> The level of inconsistency that the article complains about doesn't matter. Pretty much every popular format looks like that. Try writing a Matroska or PDF decoder some time. So a format should be designed wrong because other formats are also designed wrong. > Because it isn't important. So? You don't have to go out of your way to micro-optimize, others like TFA's author are already doing it for you. You just have to pick the micro-optimized product off the shelf. "It isn't important" is a complete non-argument when the bad choices are made for no reason and no benefit at all and especially not even making the design process quicker and easier. > If there's a replacement for XZ as a general-purpose compression format for archived data then it'll be selected on the quality of its compression, not whether the bitstream format can produce valid output from invalid input. The article also addresses design problems that harm the compression ratio.