John Sonnenschein wrote:
> In reply to both John & Garrett,
>
> The only real differences are that you lose the -s/--small flag
> which is probably
> not a problem on any machine capable of running Solaris.
>
> -s --small
> Reduce memory usage, for compression, decompression and
> testing. Files are decompressed and tested using a
> modified algorithm which only requires 2.5 bytes per
> block byte. This means any file can be decompressed in
> 2300k of memory, albeit at about half the normal speed.
> During compression, -s selects a block size of 200k,
> which limits memory use to around the same figure, at
> the expense of your compression ratio. In short, if
> your machine is low on memory (8 megabytes or less),
> use -s for everything. See MEMORY MANAGEMENT below.
>
> Decompression from stdin & pipes is still single threaded on pbzip2 but
> you don't /lose/ anything per se, you just don't gain anything.
>
> We'd appreciate the guidance of the PSARC members here. If you feel
> that we should adjust the case materials to indicate that the
> existing bzip2 utility should be replaced with pbzip2 (via the
> appropriate symbolic links), please let us know.
I'd make that recommendation *if* the -s flag could be added. It
doesn't need to actually do anything -- it could be just a no-op, but
that would allow any customer scripts to "just work".
-- Garrett
>
> Thanks.
>
> -JohnS
> On 20-Apr-09, at 10:47 AM, Garrett D'Amore wrote:
>
>> John Levon wrote:
>>> On Mon, Apr 20, 2009 at 09:25:51AM -0700, Rich Burridge wrote:
>>>
>>>
>>>> bzip2 is a free and open source block sorting lossless
>>>> data compression algorithm with comparatively high
>>>> compression efficiency.
>>>> pbzip2 is a parallel implementation of the bzip2
>>>> algorithm using pthreads written in C++ by Jeff Gilchrist
>>>> that retains file compatibility with the common bzip2(1)
>>>> application included in Solaris and many other operating systems
>>>>
>>>
>>> Is there a reason we're not delivering this version as the real bzip2,
>>> then just providing a symlink? What is the advantage of the
>>> non-parallel
>>> implementation exactly to mean it needs a new name?
>>>
>>
>> And an associated question: are there any command line differences?
>>
>> -- Garrett
>>
>>> regards
>>> john
>>>
>>
>
