Dnia 2014-02-28, o godz. 21:12:28 Antonio Diaz Diaz <[email protected]> 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 mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lzip-bug
