If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Michael, bzip2 NOT Pbzip2.
I think they should stop bitching and just replace the command line tool with lbzip2.
On the other side Mikolaj Izdebski should reassure us he will start writing an ABI compatible library. "if there will be demand" means NEVER considering there is ALREADY demand.

Comment

My first thought was: "Finally, some distro that defaults to parallel (de)compression."

However, while looking in it more closely it seems like a pet project of redhat (lbzip2 creator: Mikolaj Izdebski works for redhat) being pushed in fedora.

The biggest concern that i have is no API at all. bzip2 has an API and applications (or other libraries) use that. Replacing bzip2 with lbzip2 won't help those apps/libs. They will have to keep linking against bzip2 because there is no replacement there.So the result you're going to get if they (or any distribution) is going to include lbzip2 as "default" is:
- command line utility uses lbzip2 (you will notice a big speedup)
- apps/libs keep using bzip2 (you won't notice any changes)
- results in both lbzip2 and bzip2 being installed

I think the idea of replacing bzip2 with a parallel friendly version is nice and needed, however, the replacement should be fully compatible with bzip2 (also in API terms) so that bzip2 can slowly move away and apps link against lbzip2. As long as this is not the case, i see no real point from a desktop perspective to replace it. From a command line perspective it's fine, but then it's just a command line tool.

Comment

Michael, bzip2 NOT Pbzip2.
I think they should stop bitching and just replace the command line tool with lbzip2.
On the other side Mikolaj Izdebski should reassure us he will start writing an ABI compatible library. "if there will be demand" means NEVER considering there is ALREADY demand.

lol, fedora as biggest proponent of gnome/gtk is concerned about ... stable API/ABI in zip library??? don't know why, but something sure is screwed in this message

Comment

lol, fedora as biggest proponent of gnome/gtk is concerned about ... stable API/ABI in zip library??? don't know why, but something sure is screwed in this message

GNOME/GTK has a stable API/ABI for the core platform. Any ABI breakages within a stable release series is considered a bug. Perhaps something is screwed up about your understanding. You might be thinking of theme breakages which aren't part of either API or ABI.

Comment

IMO its time to forget bzip2 at all. If someone needs relatively fast compression, gzip would do (and LZ4 and LZO if gzip is "too slow" for you). If someone needs strong compression, LZMA is their choice. Bzip2 is clearly obsolete these days in terms of speed vs compression ratio. So IMO there is just too much buzz on this outdated algo.

Comment

Not that 100MB → 15kB is bad. From some tests I did on highly repetitive text files I remember LZMA being a lot better than bzip2 (like 1000 times better, albeit on an unusual example). So yeah, why care about bzip2 any more.