Lzip uses the same compression algorithm as xz, but is otherwise a simpler and better-designed format, without any of xz's bizarre countainer-inside-container design decisions.
Absolutely false because Zstandard didn't exist when xz was initially chosen. And the actual ratio difference is not that huge, generally less than 10% for most use cases, while the fastest level of xz is slower than most levels of zstd. (In fact, `dpkg-deb` uses `xz -6` by default because `-9` would be really expensive.) Given that zstd is also faster to decompress than xz as well, the ~10% increase is justifiable.
> Lzip uses the same compression algorithm as xz, but is otherwise a simpler and better-designed format, without any of xz's bizarre countainer-inside-container design decisions.
Lzip is not a better-designed format, it is just needlessly minimal for its use cases, much like xz's needless extensibility. I have detailed my own criticisms in the other comment [1].
tar -xf lzip[version].tar.gz
cd lzip[version] && ./configure && make check
Yeah, this is going to massively improve things. I foresee no plausible way we can gave a repeat if we switch to this lzip thing. Absolutely watertight. We learned from past events. Problem solved.
The backdoor was in the released tar only, the sources were fine, because such a malicious m4 would have been detected. The compressed test bin containing the backdoor was in git, but such unobvious things do get attention.
By the xz maintainer? I very much doubt that.