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

[Matias A. Fonzo]

On Thu, 12 Jan 2017 19:17:02 -0500
Assaf Gordon <address@hidden> wrote:

> 
> > On Jan 12, 2017, at 17:44, Matias A. Fonzo <address@hidden> wrote:
> >   
> >> From Assaf Gordon:  
> >   
> >> History has many examples of technically superior solutions
> >> that lost the race to lesser but more popular options.  
> > 
> > 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.  
> 
> Seems like you're agreeing with me, unless I misunderstood you.
> 
> > The "current state of the tools" sounds like "your tools are in a
> > bad state, how we can adopt it!?".    
> 
> That is exactly what I'm saying.
> To be more specific (and hopefully constructive):
> 
> 1. The distribution situation (of so many travels of different
> version) is bad - should be consolidated and simplified.

Why? It follows the Unix philosophy that do one thing and do it well.
 
> 2. The *public* test suite is severely lacking (as is the code
> coverage). For a project whose claim-to-fame is robustness and
> reliability - this is a red flag. If you have private test suites -
> make them public, automated, and integral part of your distribution.

Maybe Antonio can provide the names of the test suites with the
instructions to reproduce it, or an automatic method.  (I don't know)

> 3. The closed development model is another red flag.
> This is so easily fixed (and not even the first time it's mentioned)
> - the insistence on not working publicly on the code is another red
> flag.
> 

As you said, is a development model, and is about *preference*, the code
is there: available, public.

> 
> I'll try to say it in a different way:
> The lzip author wants people to switch to his program (or use it in
> addition to others).

There's nothing wrong with this.

> It is *his* burden to convince those people.

This is not *his* duty neither a *should*.  A developer is a
*developer*, not an expert in marketing.

> How do you convince people about technical matters?
> IMHO, by publishing good code and not by writing emails or web pages.
> And if there is good code that people find useful,
> then the natural progression is for some community to form.

That's not exactly how the things works.  It's subject to a lot of
(relative) things, also it depends in the point of view (of each one).

> And an active community of means that there's actively on mailing
> lists (or the likes of stack overflow), and some existing peripheral
> projects (for example, binding in programming languages).

You are expecting a community to join in?  Be the community!

> I'm sorry but I don't see a lot of that, and that's another red flag
> for me (considering that the project existed for at least 6 years).
> 

Question, where is the test suite for "xz" -- or the "prerequisites" of
a project for a compression format to be accepted?.

> 
> 
> 
> 
> > 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/  
> 
> And indeed, was quickly abandoned.

IMHO, replacing the old lzma utils with xz does not save the day.

Right now, distributing files in xz-only format means that you
need a specific amount of memory for decompress a file...
(more than gzip -9 / lzip -9).

> So you can surely understand why scrutiny of future programs is a
> Good Thing.
> 
> 
> >>> 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.
> >> 
> >> [...] 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.  
> 
> Because checksums (e.g. shaX) and gpg signatures can be used to
> validate the files way before the xz/gzip/lzip is even started.

*This* as a complement never is less.  However -- you cannot expect that
"They" (everybody, I guess) will do this.

> >> meaning: the code is
> >> high quality, well tested, well documented, easily installed, and
> >> widely available).  
> > 
> > It's not already the case?.  ;-)  
> 
> No, at least not well tested (in a way that others can easily
> reproduce the testing). I'm also not thrilled with the coding style,
> but that's really a minor personal preference issue.
> 

Just because you don't have the facility to reproduce the testing
via test-suites does not mean that the software has not been tested.

> 
> 
> Look,
> I'll repeat my point from my previous email:
> 
> I don't think the problem is technical.
> I could very well be that lzip is technical superior to all other
> solutions.
> 
> To use an analogy from a different domain:
> lzip's problem is marketing and adoption.
> lzip is trying to compete in a crowded market,
> offering a product that the users perceive as having
> only marginal benefits.
>
> Repeating "lzip is the best" without backing it up with actions
> will not yield the desired results (IMHO).
> 
> 
> regards,
>  - assaf
> 
> 
> 
> 
>

pgpAQ3XlEPhuK.pgp
Description: OpenPGP digital signature