This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Jakub Jelinek wrote:
http://www.nongnu.org/lzip/xz_inadequate.html#fragmentedYou keep referencing the marketing pages of one of the formats comparing to other formats, that can be hardly considered unbiased. Most of the compression formats have similar kind of pages, usually biased as well.
The above article is intended to be a serious (and as unbiased as possible) analysis of the xz format. AFAIK, this is the only analysis of the xz format ever written. I can't find anything similar in the xz site[1], the bzip2 site[2], nor in any of the two gzip sites[3][4]. All the formats document their file format and usually offer some kind of benchmark, but that is all. If you know of any such analysis, specially of xz or lzip, please share it.
[1] http://tukaani.org/xz/ [2] http://www.bzip.org/ [3] http://www.gnu.org/software/gzip/ [4] http://www.gzip.org/BTW, writing such an in-dept analysis is a lot of work, and it hurts when someone describes it as "marketing" without verifying it first. If anybody finds any error or inaccuracy in the above article I'll be happy to correct it. Thanks.
The choice of xz is that it is used very widely these days, which is not the case of lzip.
IMHO It is pretty obvious that whatever format is chosen to distribute the code of a major project (GCC, coreutils, linux) will become widely used, and in the meanwhile the users without support for the new format can fall back to the .gz tarball, which is not so much larger than the current bzip2 tarball.
Best regards, Antonio.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |