Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!pyramid!infmx!greggy From: greggy@infmx.UUCP (greg yachuk) Newsgroups: comp.binaries.ibm.pc.d Subject: Re: Source ARCs are inappropriate! Message-ID: <616@infmx.UUCP> Date: 15 Nov 88 08:21:37 GMT References: <7119@dasys1.UUCP> <4457@bsu-cs.UUCP> <7194@dasys1.UUCP> <1314@mtunb.ATT.COM> <8805@spl1.UUCP> Reply-To: greggy@infmx.UUCP (greg yachuk) Organization: Informix, Menlo Park, Ca. U.S.A. Lines: 66 In article <8805@spl1.UUCP> tneff@dasys1.UUCP (Tom Neff) writes: >In fact, if people posted source to a comp.sources.msdos group (I >agree it's a shame none exists, but I am afraid to propose it formally >because I don't have the time to moderate it), and binaries to c.b.i.p., >things would get better not worse. I agree with this split, but likewise have not the time to do it. However, I have some actual honest-to-goodnes hard numbers, which should help to confuse the issues :-) I'd like to preface my posting with the following comment: It is nice to have binaries, but sources are better. Some people don't agree, and/or cannot compile sources, so maybe we *need* both sources and executables. How do we package them up? I've been reading this newsgroup for about eight months and have collected 153 programs, which is most of the ones that went past. Of these, only 64 (42%) have source. Actually, the rest of these figures are biased slightly, since a couple (< 10) of these "programs" were collected from comp.source.misc, or were posted only with source, but these bias the following numbers towards a higher "overhead" for ARC files. I made ARC's containing executables, READMEs and other support files. When possible, I also added the source. I then uuencoded and compressed them. This is what happens when ARCs are transmitted, which is what Tom Neff objected to in the first place. I then made shar files, where files that were not text were uuencoded first. This gave a set of shar's which were a blend of source and uuencoded executables (as had been proposed in this group). This was done only for the programs which had source. The difference was 150,209 bytes. But please put this in perspective. The total size of the compressed shars was 8,858,815 bytes, so the "overhead" of using ARC's is about 1.7%. When weighed against the advantages of ARCs (you know, checksum, not needing a MANIFEST file, easier to manipulate on DOS, etc.) I think that this is low enough an overhead that we should make our postings in ARC format. However, if more sources get posted, this overhead would rise and this argument should be re-thought. > * Yes, some shar variants give MSDOS-based unshar programs headaches. > HOWEVER please keep in mind that these are *moderated* newsgroups. The major headache that I ran into was uuencoding .EXEs which were then too large to fit into a single shar, and so had to be split up into multiple files before shar'ing. This would be a difficult and tedious piece of logic to place into the shar creator (not to mention error prone). The un-shar should be reasonably trivial to do. > * Yes, some packages are floating around out there on BBS's, CompuServe > etcetera that prohibit anyone from breaking up the ARC or otherwise > touching the pristine inner contents in any way. > > WE CAN LIVE WITHOUT THESE PACKAGES Agreed. > * Missed sections and repost requests are a fact of life, especially Also, agreed. >Here endeth the polemic. :-) Just when you thought it was safe to talk about ARC's again... -greg Greg Yachuk Informix Software Inc., Menlo Park, CA (415) 322-4100 {uunet,pyramid}!infmx!greggy why yes, I DID choose that login myself