>>>>> On 2024-03-30, Guillem Jover wrote: >>>>> On Sat, 2024-03-30 at 00:48:34 +0000, Stephan Verbücheln wrote:
>> Subject: Re: Bug#1068024: Or remove xz altogether? >> Maybe the people who criticized xz back in the day for being an amateur >> project implementing a defective file format were right all along? >> https://www.nongnu.org/lzip/xz_inadequate.html > *Sigh*, the current situation is bad enough, and has nothing to do > with the xz format or design, or the FUD and propaganda from that > link. Please drop it… While I wouldn’t have brought it up myself, nor the arguably provocative Subject: change (reverted), as it’s indeed only tangentially related to the issue at hand (which apparently have resulted from the absense of good faith developers volunteering to maintain this project – and in a word of defense, the design quality of a software project /does/ influence both the amount of maintenance work and, other things being equal, the desire to get involved), the comment above got me curious: which parts of the document linked are ‘FUD and propaganda’? Because I’ve just glanced it over and I don’t find any obvious examples. Granted, I’m not an expert in the field of compression and coding, per se, and can’t readily speak on the validity of most of the arguments given there, those at least appear plausible. Some arguments I find obvious, such as, e. g.: ADD> A well-known property of CRCs is their ability to detect burst ADD> errors up to the size of the CRC itself. Using a CRC larger ADD> than the dataword is an error because a CRC just as large as ADD> the dataword equally detects all errors while it produces ADD> a lower number of false positives. If there’s a reasonable rebuttal to the points raised in that document, I believe that a pointer to it would be appropriate for this discussion. Other than that, I’m not going to go on this tangent any further here. I’ll be monitoring a handful of Internet fora for that, though (news:alt.os.linux.debian, news:comp.misc, irc://irc.efnet.org/%23coders, etc.) -- FSF associate member #7257 np. Moonsong — Shane Jackman
