On 9/14/2010 11:02 AM, Bob Friesenhahn wrote: > On Tue, 14 Sep 2010, Gary V. Vaughan wrote: >> >> No objections. >> >> I'm curious to know what the history of lzma and xz is that makes this >> desirable though. > > I am curious to know if XZ Utils has now achieved a proper stable > release or if it will be perpetually in a prototype like state.
Well, the 4.999.9beta is supposedly the "final" beta. However, it was released 2009-08-27 (e.g. a year ago) -- so, in order to keep that promise (!) the webpage now says: > A snapshot from the git repository is available too, and is generally > recommended over 4.999.9beta. > > xz-4.999.9beta-180-ge23e.tar.gz (1114 KiB) How that differs from a new RC/beta I don't know, but there you go. Anyway, if you check the git logs, you'll see that most of the recent changes have been stabilization and documentation, so I think it is asymptotically converging on an actual release. Of course you know the problem with asymptotes... > Its > code is quite large and quite obtuse. Meh. Most of that is for the alternate compression schemes (e.g. there are schemes tuned specifically for compressing mips binary code, and x86 binary code, etc). The core LZMA compression and XZ file format handling is maybe only 1.5x-2x bzip2. Take a look at the xz-embedded repo; it includes only the XZ and core LZMA stuff: git clone http://git.tukaani.org/xz-embedded.git > Also, I remain curious to know why 'lzip' has never been considered as a > suitable replacement. Lzip accomplishes the same thing with 10 times > less code, and better fits the traditions previously established by gzip > and bzip2. I'm not sure that last clause (...better fits...) is true. Surely, the LZMA SDK code and utilities were...different. But the LZMA Utils and its successor XZ Utils were *specifically* written to follow the gzip/bzip2 traditions. When I added xz support to cygwin's setup.exe via liblzma, the glue code to do so was VERY similar to the corresponding .gz and .bz2 glue code... Ditto when similar glue was added to BSD's libarchive. > Its only limitation is that it requires a C++ compiler. The > claim is made that it is not portable because it does not come with a > megabyte-sized configure script, but it does not need such a huge > configure script because it only uses portable ANSI interfaces, similar > to the way gzip only requires ANSI C. This sort of decision-making > results in people feeling that GNU software is excessively complex > bloatware. Personal politics and status has become more important than > proper technical analysis. Err...I don't think I want to get into a religious war. (I will say this, tho: requiring a 1MB C++ runtime library like libstdc++.so at *runtime* is not _my_ usual approach when trying to create "non-bloated" software, and hardly makes up for the "savings" of not having a 1MB configure script at *build* time. Sure, on "real" unix you'll already have that runtime lib installed, but lzma/xz was pitched on unix as usable on embedded systems and in-kernel too...the same can't be said for lzip) The fact is, whether we @ libtool like it or not, .lzma compression had been adopted by most other GNU projects as "the next great compression scheme" (whether it really WAS or not, is debatable as all such assertions are). When the two primary forces behind lzma-on-unix (Igor Pavlov and Lasse Collin) got together to formulate the xz extension, the early .lzma adopters -- e.g. many GNU projects -- followed along. As one of those GNU projects, automake added support for dist-lzma -- and later dist-xz, not dist-lzip. That's where we are. If you want to start an xz-vs-lzip fight, propose the appropriate support for dist-lzip on automake-patches and fight it there. :-) -- Chuck
