Re: [Lzip-bug] Source code repository for lzip

[Michał Górny]

Dnia 2014-02-28, o godz. 21:12:28
Antonio Diaz Diaz <address@hidden> napisał(a):

> Michał Górny wrote:
> > I'm afraid you are missing an important point here. xz is incredibly
> > more popular, and has seen more development and re-implementations than
> > lzip has.
> 
> You are missing several important points here:
>    1) This list is not for discussing popularity of other software.
>    2) Popular != better.
>    3) More re-implementations usually means clueless developers.
>    4) You are a rant away from being banned from this list.

You are right, we're getting off track here. Let's look
at the technical reasons alone.

> > Considering that it uses the same algorithm as xz,
>  > [...]
>  > Then, it could actually become competitive in the xz compressor area
>  > as a better implementation of the LZMA2 algorithm.
> 
>    1) LZMA2 is not an algorithm. More like a sub-format.
>    2) Lzip has never implemented LZMA2.
>    3) There is no such thing as a "LZMA algorithm"; it is more like a 
> "LZMA coding scheme". For example, the option '-0' of lzip uses the 
> scheme almost in the simplest way possible; issuing the longest match it 
> can find, or a literal byte if it can't find a match. Conversely, a much 
> more elaborated way of finding coding sequences of minimum price than 
> the one currently used by lzip could be developed, and the resulting 
> sequence could also be coded using the LZMA coding scheme.

So in fact the 'underlying stream' in lzip file format is incompatible
with the 'underlying stream' in xz? Am I understanding this correctly?

> > the same limitations and can't ever have any significant advantages
> > over it. Without these, it has no way of convincing people to switch to
> > a less popular format and in fact gain any real popularity.
> 
> I seek an advance in things like data safety, simplicity of compression 
> code and format, and efficient use of memory. Only fools value 
> popularity over everything else.

I agree with you that xz is unnecessarily complex and therefore you
could say that it moves in that regard, but I guess I don't understand
lzip enough to see what the arguments are in favor of it instead,
and that's what I'm trying to get a grasp on, what the key benefits are.

It occurs to me that if data safety was my top priority, I'd use a tool
dedicated to just that task, like PAR2.  But if I just need a tool
to compress my sources for distribution, I can safely assume that
something else will be responsible for ensuring the integrity of my
data.

Another technical concern I have, is regarding memory. How does lzip
compare in regards to xz? If the peak memory use is determined
by the dictionary size, doesn't this make efficient use of memory
a matter of better implementation rather than the format?

-- 
Best regards,
Michał Górny

signature.asc
Description: PGP signature