Xref: utzoo alt.sources.d:1419 alt.flame:27829 Path: utzoo!utgpu!cs.utexas.edu!rice!uw-beaver!milton!hayes.ims.alaska.edu!lll-winken!uunet!munnari.oz.au!uniwa!DIALix!metapro!bernie From: bernie@metapro.DIALix.oz.au (Bernd Felsche) Newsgroups: alt.sources.d,alt.flame Subject: Re: REPOST lharc102A Part 01/04 BSD Unix to Amiga archives Message-ID: <1991Jan31.034127.18393@metapro.DIALix.oz.au> Date: 31 Jan 91 03:41:27 GMT References: <1991Jan19.175350.11910@druid.uucp> <1991Jan20.144049.3404@zorch.SF-Bay.ORG> <7563@sugar.hackercorp.com> <1991Jan23.071609.1401@zorch.SF-Bay.ORG> Organization: MetaPro Systems, Perth, Western Australia Lines: 54 De-flamed deliberately. In <1991Jan23.071609.1401@zorch.SF-Bay.ORG> xanthian@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. > >-- >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 / \ 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@metapro.DIALix.oz.au | bernie@DIALix.oz.au