Re: Steering committee, please, consider using lzip instead of xz

[R0b0t1 <r030t1 at gmail dot com>]

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 <antonio@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.