3 ms·
You can easily apply the same argument to xz here, by introducing something rarer with an even better compression ratio (e.g. zpaq6+). Now xz isn't the best at
by mappu 11y ago
You can easily apply the same argument to xz here, by introducing something rarer with an even better compression ratio (e.g. zpaq6+). Now xz isn't the best at anything either.
But despite zpaq being public domain, few people have heard of it and the debian package is ancient, and so the ubiquity argument really does count for something after all.
- voltagex_ 11y ago"This package has been orphaned, but someone intends to maintain it. Please see bug number #777123 for more information" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777123 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777123 - get in touch with the new owner of the package if you're interested. It's probably on their Never Ending Open Source To Do List.
- dchest 11y agoNo, xz (on a particular level setting) is both faster than bzip2 and provides better compression ratio, but zpaq is just slower.
- mappu 11y ago>No, xz (on a particular level setting) is both faster than bzip2 and provides better compression ratio, but zpaq is just slower. Are you implying that xz out-compresses zpaq? Can you supply a benchmark? Here's one from me - http://mattmahoney.net/dc/text.html http://mattmahoney.net/dc/text.html - showing a very significant compression ratio advantage to zpaq.
- dchest 11y agoNo, where did you find this implication in my comment? What I meant is that: * xz is faster than bzip2 and provides better compression ratio [than bzip2] * zpaq is slower [than bzip2 and provides better compression ratio than bzip2] But looks like I'm mistaken? It seems like it can be faster and give better compression ratio than bzip2, can it?