3 ms·
There is no reason to assume that. Even if you assume every commit since Jia became a maintainer is malicious, the version from 3 years ago is perfectly fine.
by dralley 3y ago
There is no reason to assume that. Even if you assume every commit since Jia became a maintainer is malicious, the version from 3 years ago is perfectly fine.
Zstd has a number of benefits over Xz that may warrant its use as a replacement of the latter, and this will likely be a motivating factor to do so. But calling it entirely rotten is going way too far IMO
- liendolucas 3y agoWhat keeps ringing in my head is the "." that was found that invalidates compilation. I personally don't buy it (but is my opinion).
- dralley 3y agoWhat do you mean "don't buy it"?
- liendolucas 3y agoMy bad. I thought that the person who made that commit was someone else than JT. Can't delete comment nor self-down-vote it.
- tripflag 3y agoI always use "zstd --long=31 -T0 -19" to compress disk images, since that is a usecase where it generally offers vastly superior compression to xz, deduplicating across bigger distances. XZ offers slightly better compression on average, but decompression is far slower than Zstd.
- dralley 3y agoIIRC memory consumption is generally worse for Zstd at comparable levels of compression. Which, these days, is generally fine, but my point is you can't thoughtlessly substitute the two.
- mmd45 3y agoThere is an interesting argument to be made that pre-JT xz code is probably pretty secure due to the fact that the threat actors would have already audited the code for existing exploits prior to exerting effort to subvert it.