My apologies if this issue is closed, I don't meant to drive the discussion much farther if it is. (And my additional apologies if this message is routed improperly, this GNU list seems to do something different than others I am on - default respondee is not the list.)
On Thu, Jun 8, 2017 at 2:29 PM, Antonio Diaz Diaz <anto...@gnu.org> wrote: > Jakub Jelinek wrote: >>> >>> http://www.nongnu.org/lzip/xz_inadequate.html#fragmented >> >> >> You 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. > Mr. Diaz, I think people are reading the document you've provided, but as I tried to point out earlier it is rather hard to understand. A summary of the points you've discussed has been covered. Most of the points in your articles are repetitive and appear to be poorly sourced and unless you can elaborate on them there does not seem to be more to discuss. In the future you may wish to edit your document for brevity. > >> 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. (This is targetted at most of the correspondents and to the steering committee.) If the steering committee would approve of the use of lzip I think it would be beneficial. So far it looks like there is only one major distribution which does not support it in its repository, and that would be an easy fix for that distribution. I do not have much expertise to offer but as someone who has spent time trying to understand the various compression utilities, the codebase of xz verges on incomprehensible. Whereas the source of most coreutils programs can be perused without issue, xz is almost a black box. I get much the same feeling from using it as I imagine an open source developer gets from using Microsoft's Visual Studio and associated utilities. At some point I believe the decision to support superior software needs to be made regardless of its adoption amongst other projects, and that one of the factors to consider is the readability and maintainability of that software as viewed from outside of its project. If it does not seem wise to adopt a new compression format now, I would recommend reconsidering the issue after some time, perhaps a year or two. R0b0t1.
