[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Lzip-bug] Source code repository for lzip
From: |
Michał Górny |
Subject: |
Re: [Lzip-bug] Source code repository for lzip |
Date: |
Fri, 28 Feb 2014 23:56:09 +0100 |
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
- [Lzip-bug] Source code repository for lzip, Michał Górny, 2014/02/22
- Re: [Lzip-bug] Source code repository for lzip, Antonio Diaz Diaz, 2014/02/24
- Re: [Lzip-bug] Source code repository for lzip, Michał Górny, 2014/02/25
- Re: [Lzip-bug] Source code repository for lzip, Antonio Diaz Diaz, 2014/02/25
- Re: [Lzip-bug] Source code repository for lzip, Michał Górny, 2014/02/25
- Re: [Lzip-bug] Source code repository for lzip, Antonio Diaz Diaz, 2014/02/26
- Re: [Lzip-bug] Source code repository for lzip, Michał Górny, 2014/02/27
- Re: [Lzip-bug] Source code repository for lzip, Antonio Diaz Diaz, 2014/02/28
- Re: [Lzip-bug] Source code repository for lzip,
Michał Górny <=