Xref: utzoo comp.binaries.ibm.pc.d:361 comp.sys.ibm.pc:16190
Path: utzoo!dciem!nrcaer!scs!spl1!laidbak!att!osu-cis!killer!pollux!dalsqnt!rpp386!jfh
From: jfh@rpp386.UUCP (John F. Haugh II)
Newsgroups: comp.binaries.ibm.pc.d,comp.sys.ibm.pc
Subject: Re: Source code newsgroup for MS-DOS
Message-ID: <2277@rpp386.UUCP>
Date: 1 Jun 88 16:58:20 GMT
Article-I.D.: rpp386.2277
References: <1555@bu-tyng.bu.edu> <3186@bsu-cs.UUCP> <11803@ut-sally.UUCP> <7978@brl-smoke.ARPA> <4827@teddy.UUCP> <4298@sphinx.uchicago.ed
1 Jun 88 16:58:20 GMT
Reply-To: jfh@rpp386.UUCP (The Beach Bum)
Organization: Big "D" Home for Wayward Hackers
Lines: 22
Xref: dciem comp.binaries.ibm.pc.d:337 comp.sys.ibm.pc:14548

In article <7985@brl-smoke.ARPA> w8sdz@brl.arpa (Keith Petersen ) writes:
>When Usenet can guarantee error-free and non-truncated transmission of clear
>text files  I will agree to posting clear text files.  Until that day
>arrives (is anyone working on it?) I will continue to post them as ARC
>files in the comp.binaries.ibm.pc newsgroup.

the advantage of arc files is that arc includes crc's, where as shar doesn't.
however, shar does include character and line counts, and if a file is the
victim of a line hit, at least you might be able to figure out what happened.
with arc files, if you take a hit and an INSTRUCTION gets changed, you may
never figure the problem out.

binaries are fundementally worthless because when broken only a person with
source can fix them.  and with the case of certain `shareware' products,
will only provide the fix for a $$ ``donation''.

- john.
-- 
John F. Haugh II                 | "If you aren't part of the solution,
River Parishes Programming       |  you are part of the precipitate."
UUCP:   ihnp4!killer!rpp386!jfh  | 		-- long since forgot who
DOMAIN: jfh@rpp386.uucp          |