Re: [PATCH] maint: RFC: add lzip tarballs

[Matias A. Fonzo]

Hi there,

I maintain one of the free distros recommended by the GNU project,
"Dragora".  We've been using lzip since 2009, and we never experiment a
single problem.

I subscribed to the list recently.  I talked to Eric (before) in
private -- in my frustation seeing .xz as the only distribution format
(lately).  I'm glad the discussion has been (re)open to the public now.

> From Assaf Gordon:

>> On 01/12/2017 10:44 AM, Antonio Diaz Diaz wrote:
>> All your objections seem aimed at the tools and the license.

> Indeed. I do not have the expertise nor the time to examine the file
> format. I can (and did) looked at the code (and the mailing list).

>> IMHO, the important issue here is the data format itself. If the
>> lzip data format is good, then any bug in the tools can be fixed.

> We'll have to agree to disagree here.

> History has many examples of technically superior solutions
> that lost the race to lesser but more popular options.
>
> I don't think you'll gain wide spread adoption with the current state
> of the tools.

I have seen things like this before, "popular", "widely", "adoption"
are not always synonymous with *quality*.  Even if the tendency in the
world is to adopt "popular" creations.

Just because "xz is more popular than lzip" this does not mean that
lzip is going to die.  Compared to xz, Antonio has published more
versions than xz during all these years, improving lzip in all of its
aspects: a good sign of health.

The "current state of the tools" sounds like "your tools are in a bad
state, how we can adopt it!?".  Back to 2008[1], it is not the coreutils
project who has been distributing coreutils using the old lzma utils?.
The old lzma utils was really really bad...

[1] http://ftp.gnu.org/gnu/coreutils/

>> The goal is to increase the chances of
>> people being able to access coreutils' source code in 50 years time
>> by choosing a better format.
>
> I think it's a non-issue in this context.
>
> gzip has been around for at least 24 years, and won't go away.
> ftp.gnu.org hosts gzip files going as far back as 1993, and savannah's
> CVS has code commits going back as far as 1986.
>
> This effectively means that existing tools has proven to be 'good
> enough' when combined with other means (like proper backups, checksums
> and gpg signatures).
>
> I'm not saying data corruption doesn't happen.
> I'm saying that when it does (in the context of coreutils tarballs or
> ftp.gnu.org files) - it will more likely be handled by restoring from
> backup then by resorting to archive recovery program.
>
> Which is why IMHO the argument for this specific use case is not
> strong (i.e. "increase the changes of people being able to access the
> code 50 years from now"). They will be able to do so even with gzip
> and xz.

How?  If xz cannot verify the integrity of .xz files in busybox, check
http://www.nongnu.org/lzip/lzip_benchmark.html for a use case.

> It could still be the case that lzip's format is superior than all of
> these existing tools, and can offer good advantages.
> But if you want to convince users to switch to lzip - you need to
> convince them the entire package is worth it (meaning: the code is
> high quality, well tested, well documented, easily installed, and
> widely available).

It's not already the case?.  ;-)

> Perhaps a better use-case for lzip is personal backups and archiving.
> But then if you're talking about "50 years" from now - I want to get
> the feeling that 'lzip' will have a community backing 50 years from
> now and won't become a stale project.
>
> So far I'm not convinced.
>
> regards,
> - assaf

pgpAN7kap2ju7.pgp
Description: OpenPGP digital signature