Re: using bzip2 to compress man-pages

Mikhail Teterin wrote:
>> http://www.pkix.net/~chuck/manpage_test/
> 
> Interesting. I did not realize, bzip2 is inferior to gzip on small files. It 
> still wins overall, however -- the wins on large man-pages compensate for 
> losses on the small ones. Your script does not show the total number of 
> sectors in each case (patch attached).

Thanks, your patch has been committed.  If nothing else, we now have lots of 
data on just how bzip2 and gzip compare for tiny files....

[ ... ]
> 	14919 of .gz can be turned into 14738 of .bz2
> That's 181 512-byte sectors or 92672 bytes. Not very much, but this is just 
> the /usr/share/man. Considering the /usr/share/cat (with larger _formatted_ 
> files), plus the ports' man-pages, I still think bzip2 is beneficial.
> 
> Assuming 1024-sized sectors, I get 8170 for .gz vs. 8067 for .bz2, or 105472 
> bytes.

OK.  This seems to be about a 1% difference, which is at least noticable, and 
even going in the right direction.

(It'd be a lot closer without csh.1, ppp.8, and lex.1, which have the honor of 
being the longest manpages present.  If only we had used the Y2K problem as a 
good excuse to remove CSH, that would have been a perfect cover.  :-)

> Reducing reliance on GNU software remains an extra bonus...

Certainly, there exists GNU software which makes me cringe, but gzip isn't part 
of that group.  I suppose there's a preference for BSD-licensed code rather 
than GPL'ed code, but I'd expect gzip and zlib to be a part of FreeBSD for the 
foreseeable future...

> Finally, the PR contains independent patches for both man(1) and the man-page 
> compressing infrastructure. After 5-months wait, I'll settle for partial 
> acceptance.

I don't mind the notion of supporting bzip'ed manpages.  I'll even give a +1 to 
the idea, not that I expect democracy to break out among the powers-that-be.

-- 
-Chuck