Re: request for review: lbzip2
Ben Finney wrote:
> ERSEK Laszlo <lacos@caesar.elte.hu> writes:
>> I've been advised under [0] to ask the SRP to review my lbzip2
>> package's description and manual page. If this is the wrong place to
>> ask, I apologize for the noise.
>
> (I don't know what SRP is; perhaps I haven't been paying attention.)
The Smith Review Project, presumably, though this isn't exactly a
candidate for that.
>> Description: parallel bzip2 filter
>
> Thanks for making the synopsis fit the best-practices template of an
> unadorned noun phrase.
>
> What does it mean for the reader that this is a “parallel bzip2 filter”?
> Is it a filter of “parallel bzip2”, or is it a “parallel filter” of
> bzip2 data?
>
> You can assume that the synopsis will be further explained by the long
> description, but I would want “parallel” and “filter” to be less
> ambiguous here. Perhaps “multi-threaded implementation of bzip2 codec”,
> if that actually is an accurate synopsis.
Meanwhile the archives already have pbzip2, "parallel bzip2
implementation". As far as I can see lbzip2 is just another
pthreads-using bzip2 indistinguishable from pbzip2. There's nothing
in either package description that would help me decide which to
install, except that pbzip2 gives me the hint that there's no point
having either on my old uniprocessor desktop.
[...]
> This seems like far too much attention to implementation details. Could
> you try re-phrasing this to address an audience who wants to know
> whether or not they want this package on their system, and who may not
> yet know much of anything about the specific details of what the package
> is trying to do?
Seconded. The users installing the binary don't care *how* it
works; they may never have heard of POSIX threads. Focus more on
what the program is useful for - it's a compression tool, compatible
with normal bzip2, but designed to take advantage of the features of
multi-core CPUs.
Is there any hope of the lbzip2 and pbzip2 projects joining forces?
Or at least synchronising their efforts via mutexes?
Oh; going to the homepage (which I notice redirects me to
http://lacos.hu), I see it's described there as "a multi-threaded
bzip2/bunzip2 filter that doesn't depend on the lseek() system call
and so isn't restricted to regular files." It had never occurred to
me that ordinary bzip couldn't compress block devices (etc); if
that's an important difference between lbzip2 and other
implementations it should probably be emphasised.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: