Announcement

Collapse
No announcement yet.

Bzip2 Is About To See Its First Real Update In Close To A Decade

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Bzip2 Is About To See Its First Real Update In Close To A Decade

    Phoronix: Bzip2 Is About To See Its First Real Update In Close To A Decade

    The Bzip2 open-source compression program is about to see its first real release since September 2010. This new version brings new build systems, security fixes, and much more...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I do wonder what the advantage is in bzip2 versus pbzip2.

    Comment


    • #3
      IMHO the first thing you should not do for the first maintenance release in 9 years is touch the build system. I hope they have good old Makefiles in there, not only for old systems, Irix and such, but also not to introduce random bugs on new systems due to just so slightly miss-compiled / -linked bits and details.

      Comment


      • #4
        Any performance improvements to go with this? I mean, bzip2 is not particularly slow, but you'd think over the timespan, someone must have come up with ideas to speed up some things.

        Comment


        • #5
          Originally posted by rene View Post
          IMHO the first thing you should not do for the first maintenance release in 9 years is touch the build system. I hope they have good old Makefiles in there, not only for old systems, Irix and such, but also not to introduce random bugs on new systems due to just so slightly miss-compiled / -linked bits and details.
          I agree, with the caveat that having worked with the bz2 codebase myself, it is definitely an outlier in its simplicity w/r building. If you have all of the source except the Makefile you can figure out how to compile it with a gcc oneliner in about 30 seconds. This along with the permissive license is part of what makes it so attractive. I worry that by moving to a build-system-of-the-day meant to handle much more complicated codebases, they are losing the simplicity and flexibility they already had. Spend your effort fixing the known issues in the actual code.

          Comment


          • #6
            Originally posted by bug77 View Post
            Any performance improvements to go with this? I mean, bzip2 is not particularly slow, but you'd think over the timespan, someone must have come up with ideas to speed up some things.
            Worth noting that most of those advances in the state of the art have been on the decompression side, given the use cases on the modern web. bzip2 compresses slower than gzip, but MUCH faster than xz and other more modern compression algorithms. For my use case I need fast compression and don't care about the speed of decompression, and bzip2 was, for a time, the best tradeoff.

            Comment


            • #7
              Something not having a single push for years is either dead, or working pretty good. Bzip2 is the latter, the main things to say about the code - C style, almost no folder structure, mixed file types in root folder, very low number of comments, some magic numbers...

              It will benefit from restructuring, having a modern build system. Last release is perfectly useable for makefile fans. Whether Rust port will be viable, remains to be seen, but probably it's not of the charts. The codebase is in thousands LoC, and that's rewritable by any standards. All the best to the maintainer!

              Comment


              • #8
                Originally posted by clavko View Post
                Something not having a single push for years is either dead, or working pretty good. Bzip2 is the latter, the main things to say about the code - C style, almost no folder structure, mixed file types in root folder, very low number of comments, some magic numbers...
                ...Except pretty much all distributions carried patches to make bzip2 compile and to fix security issues. So it did get needed fixes and updates, there was just no upstream to send the fixes to. There wasn't even a code repository, just one source tarball for each release.

                Comment


                • #9
                  Originally posted by Oddsocks View Post
                  I do wonder what the advantage is in bzip2 versus pbzip2.
                  Yes. I've used pbzip2 and pigz for years as drop in replacements. Those work great.

                  Comment


                  • #10
                    Originally posted by bug77 View Post
                    Any performance improvements to go with this? I mean, bzip2 is not particularly slow, but you'd think over the timespan, someone must have come up with ideas to speed up some things.
                    This is effectively just resurrecting an unmaintained project, so at this stage, no - this release is just introducing a more conventional build, and merging some distro patches that have accumulated over the years.

                    Comment

                    Working...
                    X