XZ embedded bug unpacking linux-3.8.tar.xz

[Michael Tokarev]

28.02.2013 04:22, Antonio Diaz Diaz wrote:
[]
> The history in a nutshell: "In 2008, Antonio Diaz released lzip, which uses a proper container format with checksums and magic numbers instead of the raw LZMA data stream, providing a complete Unix-style solution for using LZMA. Nevertheless, LZMA Utils was extended to have similar features and then renamed to XZ Utils"[3].

Oh.  I remember that 2008 year (or a bit before) when kernel folks discussed which
format to use for kernel.org archives and leaned towards lzma, and I pointed out
that it does not have any checksums.  I guess it was a starting point for xz and
lzip.

For some reason I haven't heard of lzip at all until now.  I remember when xz come
out, I looked at it and noticed its complexity and lack of stable format, exactly
as you describe, but that didn't rang any bells for me and eventually it become a
widely known and accepted format.

So, I become curious how lzip behaves.  And I immediately gave it a very quick try.

CPU: AMD AthlonII X2 260, 3.2GHz (2 cores)
file: 1Gb (1073741824 bytes), an image of a small linux virtual machine.

 .lz:  273684804, real 11m53.112s, user 20m30.563s
 .xz:  266670056, real 11m8.190s,  user 10m45.835s

This is the default compression level.

WOW.  So, 2-thread plzip is about TWO TIMES solwer than single-thread xz when
compressing, making parallel plzip on 2 cores to be as fast as xz.  lz produces
slightly larger result.

Are you sure the stream and compression algorithm are the same? :)

Thanks,

/mjt