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 |