Xref: utzoo comp.binaries.ibm.pc.d:337 comp.sys.ibm.pc:16016
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!panda!teddy!jpn
From: jpn@teddy.UUCP (John P. Nelson)
Newsgroups: comp.binaries.ibm.pc.d,comp.sys.ibm.pc
Subject: Re: Source code newsgroup for MS-DOS
Message-ID: <4831@teddy.UUCP>
Date: 30 May 88 17:12:18 GMT
References: <1555@bu-tyng.bu.edu> <3186@bsu-cs.UUCP> <11803@ut-sally.UUCP> <7978@brl-smoke.ARPA> <4827@teddy.UUCP> <2143@rpp386.UUCP>
Reply-To: jpn@teddy.UUCP (John P. Nelson)
Organization: GenRad, Inc., Concord, Mass.
Lines: 32

In article <2143@rpp386.UUCP> jfh@rpp386.UUCP (The Beach Bum) writes:
>In article <4827@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes:
>>As has already been discussed several times, this is a BAD IDEA.  Arc'ing
>>text files (program source files) causes significantly HIGHER transmission
>>costs for most usenet sites!
>
>generally this is true.  it is possible however to suppress
>file compression using the more reasonable arc commands.

Sigh.  It is not the COMPRESSION that causes the problem so much as
it it the UUENCODING!  The REASON that there is a trasmission penalty is
because a .arc file MUST be uuencoded because it is binary, whether it's
component files are compressed or not!

I realize that people like ARC, but all other sources groups live with
the problems and limitations of posting via "shar" archives!  MSDOS
sources are no different!  When the various "sources" newsgroups were
set up, other archiving techniques were considered.  "Shar" is a
lowest common denominator, which is why it is used!  No one to date
has come up with a better archiver that:

    #1 does not generate a BINARY result.
    #2 is as simple to extract files from if you don't have the De-arc
	program.
    #3 has any significant advantages over SHAR.  True, shar doesn't
       have a checksum, but the character count catches 99% of transmission
       errors!
-- 
     john nelson

UUCP:	{decvax,mit-eddie}!genrad!teddy!jpn
smail:	jpn@genrad.com