REPOST lharc102A Part 01/04 BSD Unix to Amiga archives

[Bernd Felsche]

De-flamed deliberately.

In <1991Jan23.071609.1401 at zorch.SF-Bay.ORG> xanthian at zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>Second, "compress,uuencode,recompress" is not the best use of technology;
>I did a little test with the same files in just one big shar, to simplify
>the reporting of the results:

WHOAH THERE! Shouldn't you be using tar to generate the archive
instead of shar?  Its wrapper information is more compact and
efficient.

Then you compress the tar archive... and uuencode it. Please try this
and publish the results for comparison.

Depending on software versions, you can do all this in a pipe (which
you undoubtedly know) "tar cf - files | compress | uuencode >bugs.tar.Z.uu"

For transmission, it can be compressed again, (it would be smarter to
uudecode) though this _should_ be done by a network layer, even though
it often isn't.  Wouldn't it be nice if modem transfer protocols were
smart enough to compress on the fly?

>So in fact, for the files being sent, there is some modest _gain_ in
>telecommunications efficiency by using the best compression technology
>on text, and then uuencoding it and letting the standard net node to
>node compression have its way with the files.

Agreed.  In fact, the more text, the better the gain.

>I have yet to see a single argument for the present methods that
>comes down, at the last, to anything but sheer laziness on the part
>of those who don't want to change their habits.  Compressed, uuencoded
>transmission methods win on every reasonable criterion.

Although one should be wary of zoo archives, which don't work well if
there are many small text files in it (i.e. typical source code).
Compression can be as little as 10-15%, which uuencoding explodes past
the original size.

>Kent, the man from xanth.
><xanthian at Zorch.SF-Bay.ORG> <xanthian at well.sf.ca.us>
>--
>By the way, it is _not_ a solution to replace compress with a filter
>form of lharc as the typical file compressor for telecommunications;
>lharc is _much_ too slow to use at every step along the way, so it
>needs to be done just once at the originating site to accomplish these
>savings.

TANSTAFL.
-- 
 _--_|\  Bernd Felsche         #include <std/disclaimer.h>
/      \ Metapro Systems, 328 Albany Highway, Victoria Park,  Western Australia
\_.--._/ Fax: +61 9 472 3337   Phone: +61 9 362 9355  TZ=WST-8
      v  E-Mail: bernie at metapro.DIALix.oz.au | bernie at DIALix.oz.au