Results 1 to 10 of 13

Thread: Fedora 21 Aims To Have LBZIP2 Replace BZIP2

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,429

    Default Fedora 21 Aims To Have LBZIP2 Replace BZIP2

    Phoronix: Fedora 21 Aims To Have LBZIP2 Replace PBZIP2

    Fedora developers are eyeing the independent lbzip2 compression implementation to become the default bzip2 on the next release of this Red Hat sponsored Linux distribution...

    http://www.phoronix.com/vr.php?view=MTY1NTc

  2. #2
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    984

    Default

    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.

  3. #3
    Join Date
    Oct 2007
    Posts
    297

    Default

    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.

  4. #4
    Join Date
    Jan 2011
    Posts
    421

    Default

    We shouldn’t worry about that, because systemd will soon include transparent parallel decompression of all files.

  5. #5
    Join Date
    Feb 2010
    Location
    Srpska Republic, Bosnia&Herzegovina
    Posts
    109

    Default

    Quote Originally Posted by stqn View Post
    We shouldn’t worry about that, because systemd will soon include transparent parallel decompression of all files.
    LOL Nicely spotted!

  6. #6
    Join Date
    Jun 2012
    Posts
    328

    Default

    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.

  7. #7
    Join Date
    Oct 2013
    Posts
    422

    Default

    Quote Originally Posted by darkbasic View Post
    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

  8. #8

    Default

    Quote Originally Posted by justmy2cents View Post
    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.

  9. #9
    Join Date
    Oct 2013
    Posts
    422

    Default

    Quote Originally Posted by RahulSundaram View Post
    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.
    i think you misunderstood my sarcasm, but that would probably be my fault on badly expressing it. i wasn't talking about api/abi stability, i was talking about stability of experience during stable version (talking about gnome 3 here). as far as gtk goes, i got other concerns but i won't mention those.

    gtk/gnome can't even decide on how applications behave in 3 era. with each release experience is doing 180. not to mention, they deviate from how other software works in a manner where pure gtk or qt application feels more at home on windows than it does on gnome. any cross platform app can't even start to follow gnome hig and not alienate 99% of the user base.

    off course, your claim will be valid if you say that x is not stable version, but 3.x. that simply begs for question, are daily gnome builds now what 2.x used to be? and... when whole user experience stability doesn't matter, how can small things like api/abi in zip app
    Last edited by justmy2cents; 04-06-2014 at 11:29 AM.

  10. #10

    Default

    Quote Originally Posted by justmy2cents View Post
    i think you misunderstood my sarcasm, but that would probably be my fault on badly expressing it. i wasn't talking about api/abi stability, i was talking about stability of experience during stable version
    Well, that has nothing in common with ABI/API stability in a library which has no UI. If you have feedback on GNOME UI, you should post a new thread or on one of the GNOME mailing lists.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •