Once upon a time, drago01 <drago01@xxxxxxxxx> said: > Well the change says " multi-threaded operation for both compression > and decompression, with almost linear scalability" linear scalability > means speed ups on the range of 2-8x on current desktop / laptop > systems. > Which I'd call a "significant gain" ;) That depends. If I made an alternate "mv" that ran 10 times faster, would we go through the pain of alternatives to offer two options for it? How much impact on real-world system usage will speeding up the bzip2 command offer? Many of the common users (such as rpm) are linked against the library and don't use the command, so they won't be impacted. We'll end up with more disk space used, because the current /usr/bin/bzip2 and friends are linked against the library (so there's only one copy of bzip2 code). Since lbzip2 doesn't offer a library, I guess each program has to have a copy of the code, and other system tools will still use the bzip2 library. I think the "right" way to move forward is to make a library that is at least API-compatible with the current libbz2.so.1, make all the tools use it, and just replace bzip2 with lbzip2. -- Chris Adams <linux@xxxxxxxxxxx> -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
