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

[Assaf Gordon]

Hello,

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

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.

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.


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).
It is *his* burden to convince those people.
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.
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).

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).





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

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.

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



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