Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
I'm currently using xz for my own files, but...
On 2015-06-14 05:46:00 +0200, Guillem Jover wrote:
> On Sun, 2015-06-14 at 01:08:29 +0200, Thomas Goirand wrote:
> > On 06/13/2015 10:55 AM, Paul Wise wrote:
> > > On Sat, Jun 13, 2015 at 4:23 PM, Thomas Goirand wrote:
> > >> As a friend puts it:
> > >>
> > >> "This is a fundamental problem/defect with xz. This (and a lot of
> > >> other such defects, e.g. non-robustness of xz archives that easily
> > >> lead to file corruption etc) are the reason that there is lzip (and
> > >> which is why gnu.org has, on a technical basis, decided that lzip is
> > >> official gzip-successor for gnu software releases when they come in
> > >> tarballs).
>
> TBH this smells like FUD. For example I've never heard of corruption in
> .xz files due to non-robustness, I'd expect that corruption to come from
> external forces, and that integrity would help or not detect it.
xz-utils (4.999.9beta-1) experimental; urgency=low
[ Jonathan Nieder ]
* New upstream release.
- Fix a data corruption in the compression code. (Closes: #544872)
[...]
But of course, this is old, and any compression software can have the
same kind of bug (possibly unless proved formally).
However lzip compresses better, sometimes much better:
-rw-r----- 1 vinc17 vinc17 822474 2015-04-26 00:45:51 mail.log.lz
-rw-r----- 1 vinc17 vinc17 915544 2015-04-26 00:45:51 mail.log.xz
(this example is a postfix mail log) and uses much less memory for
compression:
$ sh -c 'ulimit -v 200000; lzip -9 < mail.log > /dev/null'
$ sh -c 'ulimit -v 800000; xz -9 < mail.log > /dev/null'
xz: (stdin): Cannot allocate memory
$ sh -c 'ulimit -v 800000; xz -9 < /dev/null > /dev/null'
xz: (stdin): Cannot allocate memory
Note: see the 200000 for lzip and 800000 for xz.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply to: