Henry Spencer:
There are three fundamental problems that have always pretty much scuttled
proposals for article compression.

One is that it saves space at the expense of CPU time, and CPU time is
not always in ample supply on news hosts.

A much more serious problem is:  how *much* space does it save?  Bear in
mind that news articles are small -- they consistently average about
3KB -- and small files do not compress particularly well.  Worse, the
quantum of disk storage on many systems is quite large.  If you compress
the typical article from 3K-1 bytes to 2K+1 bytes, most modern systems
will see *no storage savings at all*, because they allocate disk in
1KB blocks.

The final problem is that an improvement by a factor of (say) 1.5 does
not buy you a lot of time in the news business.  In exchange for a lot
of work and a permanently raised CPU load, you set the growth curve
back a few months.

Geoff Collyer:
A more general solution than hacking all the news software, that also
benefits ftp archives and the like, is to write a user-mode (NFS) file
server for /usr/spool/news (and /usr/spool/ftp, etc.) that compresses
files as they are written (after the close for non-sequential writes) and
decompresses files when they are read (the entire file will have to be
uncompressed temporarily into scratch space for non-sequential reads).
Such a server provides compression transparently and is in a good
position to decide that very small files should not be compressed because
there is little or no benefit to doing so.  Keeping the server in user
mode avoids the horror of embedding compress in kernel code.

© 2008 FAQS.ORG. All rights reserved.