This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Steering committee, please, consider using lzip instead of xz

Matthias Klose wrote:
I'm not commenting on the "inadequateness" of xz, but maybe it would
better help lzip to address some project issues and promoting it as
an alternative rather than appealing to the GCC steering committee.

It is not my intention to "help lzip", but to use lzip as a mean to help others avoid the "inadequateness" of xz. :-)

  - lzip is not a GNU project (afaics), same as for xz.

Lzip is GPL, xz is not.

  - lzip doesn't have a public VCS.

Why is this important?

  - lzip doesn't have a documented API, doesn't build as a library,
    and I can't find language bindings for lzip.

- The lzip library (lzlib) is at
- The lzlib API is documented at - Libarchive is a library that automatically handles lzip archives. - There are language bindings for libarchive and I think that there are also some language bindings for lzip, but I don't have links for them.

BTW, lzip offers a parallel compressor (plzip) that uses lzlib and features multi-threaded decompression since 2010. Xz-utils still does not implement multi-threaded decompression because LZMA2 makes it difficult.

  - lzip isn't (yet) used for software distributions, while xz is (and afaics
    xz is used for GNU projects in addition to gz).

Lzip is used for software distribution of GNU projects, and contrarily to xz, it has never caused problems for excessive memory requirements or wrong type of CRC.

Best regards,

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]