tneff@dasys1.UUCP (Tom Neff) (10/22/88)
After all the drawn-out discussion on the merits of net.binaries, I frankly never thought I'd see it perverted like this. Merely ARC'ing a bunch of source (text) files does NOT create a "binary" worth sending in this newsgroup via UUENCODE! Recent postings such as GYMAKE are wasteful and rude. The appropriate thing to do with a source collection is to package it as a shell archive and post it to a source newsgroup as clear text. ARC+UUENCODE should be restricted to no-choice binaries like .EXE's and data files. Newsbatch-compress will do a better job of saving net bandwidth on your source files than ARC+UUENCODE can anyway. Text should still have primacy on Netnews whenever technically possible, so that the greatest number of newsreaders can enjoy the benefits of the information they're paying to pass around. -- Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff "None of your toys CIS: 76556,2536 MCI: TNEFF will function..." GEnie: TOMNEFF BIX: t.neff (no kidding)
charette@edsews.EDS.COM (Mark A. Charette) (10/22/88)
In article <7119@dasys1.UUCP>, tneff@dasys1.UUCP (Tom Neff) writes: > After all the drawn-out discussion on the merits of net.binaries, I > frankly never thought I'd see it perverted like this. Merely ARC'ing a > bunch of source (text) files does NOT create a "binary" worth sending > in this newsgroup via UUENCODE! Recent postings such as GYMAKE are > wasteful and rude. > > The appropriate thing to do with a source collection is to package it > as a shell archive and post it to a source newsgroup as clear text. > -- > Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff > "None of your toys CIS: 76556,2536 MCI: TNEFF > will function..." GEnie: TOMNEFF BIX: t.neff (no kidding) I disagree somewhat. For those people accessing this via some connection other than a Unix machine, it requires finding out what *.sources it would be in, downloading it in ascii form (at their expense), and writing (or finding) the unshar script. I like having both the source and binary packaged together. I may not have the {compiler,libraries,version} needed to compile the source immediately, so at least I can try the binary and figure out whether it's worth the conversion effort to make it work with my compiler. Also, I have a (little) more trust in a binary accompanied by source - the chances of the binary being a trojan might be reduced. -- Mark Charette "On a clean disk you can seek forever" - Electronic Data Systems Thomas B. Steel Jr. 750 Tower Drive Voice: (313)265-7006 FAX: (313)265-5770 Troy, MI 48007-7019 charette@edsews.eds.com uunet!edsews!charette
16012_3045@uwovax.uwo.ca (Paul Gomme) (10/23/88)
In article <7119@dasys1.UUCP>, tneff@dasys1.UUCP (Tom Neff) writes: > After all the drawn-out discussion on the merits of net.binaries, I > frankly never thought I'd see it perverted like this. Merely ARC'ing a > bunch of source (text) files does NOT create a "binary" worth sending > in this newsgroup via UUENCODE! Recent postings such as GYMAKE are > wasteful and rude. > > The appropriate thing to do with a source collection is to package it > as a shell archive and post it to a source newsgroup as clear text. > ARC+UUENCODE should be restricted to no-choice binaries like .EXE's and > data files. Newsbatch-compress will do a better job of saving net > bandwidth on your source files than ARC+UUENCODE can anyway. Text > should still have primacy on Netnews whenever technically possible, so > that the greatest number of newsreaders can enjoy the benefits of the > information they're paying to pass around. I disagree with you for two reasons. First, I (for one) don't have access to anything which will un-shell (short of doing it by hand). Consequently, UUENCODEd ARC files are very convenient to me. Second, ARC files save transmission time down to my micro. Don't forget that most of the stuff posted here _is_ for those MS-DOS machines. ------------------------------------------------------------------------- Paul Gomme Bitnet: p.gomme@uwovax.bitnet ARPA: p.gomme@uwo.ca
cjl@ecsvax.uncecs.edu (Charles Lord) (10/23/88)
Tom, I have to disagree. There is a definite advantage from an administration viewpoint for the orderly concatenation of the files, whether source or binaries, into an archive of some *nix/ ms-dos compatable archiver. Shell archivers such as used on net.source.misc are a pain in the butt on programs that have oodles of little include and patch and header files that extract out. I almost always end up making a temp subdirectory, running the shell in that subdirectory, then ARCing everything together for local archive and distribution. Zoo or PKwhatever would work just as well. Your complaint that sources appear on c.b.i.p is noted, but with so many going virus-paranoid it is small bandwidth sacrifice that authors provide either source only or both source and executable. -- * Charles Lord ..!decvax!mcnc!ecsvax!cjl Usenet (old) * * Cary, NC cjl@ecsvax.UUCP Usenet (new) * * #include <std.disclamers> cjl@ecsvax.BITNET Bitnet * * #include <cutsey.quote> cjl@ecsvax.uncecs.edu Internet *
pervect@bsu-cs.UUCP (Barrett Kreiner) (10/23/88)
In article <7119@dasys1.UUCP>, tneff@dasys1.UUCP (Tom Neff) writes: > After all the drawn-out discussion on the merits of net.binaries, I > frankly never thought I'd see it perverted like this. Merely ARC'ing a > bunch of source (text) files does NOT create a "binary" worth sending > in this newsgroup via UUENCODE! Recent postings such as GYMAKE are > wasteful and rude. > [Yum.. stuff deleted] > > Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff > "None of your toys CIS: 76556,2536 MCI: TNEFF > will function..." GEnie: TOMNEFF BIX: t.neff (no kidding) Hello Net.. I'm the IBMPC/MSDOS archiver at bsu-cs. I feel that Mr. Neff's statements are untrue and have a big flaw: Note the following archive listing (our site converts archives to zoo format.. whaddaya expect.. our sysop WROTE it :-] ) : Archive gy_make.zoo: Length CF Size Now Date Time -------- --- -------- --------- -------- 2314 57% 990 22 Oct 88 01:09:06 decl.h 2131 49% 1078 22 Oct 88 01:09:06 default.mk 13483 51% 6559 22 Oct 88 01:09:10 make.1 17712 53% 8304 22 Oct 88 01:09:14 make.c 21907 23% 16811 22 Oct 88 01:09:20 make.exe <--+ 2611 45% 1426 22 Oct 88 01:09:20 make.h | 17004 57% 7297 22 Oct 88 01:09:22 make.man | 1074 36% 687 22 Oct 88 01:09:24 makefile | 15235 54% 6999 22 Oct 88 01:09:26 parse.c | 1435 32% 977 22 Oct 88 01:09:26 readme | 3532 46% 1890 22 Oct 88 01:09:28 tstring.c | 751 37% 473 22 Oct 88 01:09:28 tstring.h | 975 22% 757 22 Oct 88 01:09:04 Message | -------- --- -------- --------- -------- | 100164 46% 54248 13 files | Now.. does everybody see this entry? It says make.EXE (for those of you not TOO familiar with the PC, this is a program for the computer to execute.) Trying to stick this as a "sh" archive would be a good way to kill our posting system. Now, as for the high text vs exe ratio of this particular posting.. as was made well known earlier, if sources ARE available..they WILL go out with the executables. Please find something else to grip about as Mr. Moderator HAS: 1) standardized the postings headers/trailers That allowed ME to develop some simple scripts to automate our archiving process. 2) Controlled the amount of duplicate/nobody wants type postings.. (do any of you remember the PICNIX postings.. Hmmmm?!?) 3) Keeps partial postings/bad archives off the net (i.e. it goes to IBMBIN instead of the whole of Netland) KRAK! Fizz.. *Snap* *Snap* crash --Aaugh!! (for those not psychic.. that was those flamers torching my soapbox) Thank you.. and good day.. |---------------------------------------------------------------------|-----| | Barrett Kreiner UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!pervect | :-] | | Technical Manager, Fine Arts Computer Lab|--------------------------|-----| | Ball State University. Muncie, Indiana |This space left blank on purpose| |------------------------------------------|--------------------------------| | How am I computing? Let my parents know at ddsw1!kreiner (HI ma & dad) | | Disclamer: "I don't know them! I'm a student, nobody listens to ME!" | |---------------------------------------------------------------------------|
dhesi@bsu-cs.UUCP (Rahul Dhesi) (10/23/88)
In article <7119@dasys1.UUCP> tneff@dasys1.UUCP (Tom Neff) writes: >Merely ARC'ing a >bunch of source (text) files does NOT create a "binary" worth sending >in this newsgroup via UUENCODE! Recent postings such as GYMAKE are >wasteful and rude. > >The appropriate thing to do with a source collection is to package it >as a shell archive and post it to a source newsgroup as clear text. A comp.sources.msdos newsgroup would be nice but doesn't exist. Somebody should propose it and volunteer to moderate it. While sources of general interest are posted to comp.sources.misc, posting sources there does have two disadvantages. First, the charter of comp.sources.misc is to get sources postings out quickly. A frequent result is that many source postings are unaccompanied by any information about what they are. Second, comp.sources.misc is a general-interest newsgroup and posting too many MS-DOS specific sources there may cause irritation to those who don't use MS-DOS, or at least to those who don't have any compilers on an MS-DOS system. Here is a summary of the advantages and disadvantages of posting source in archived format versus posting it in clear text format. Advantages of source in clear text format: o Usenet newsfeeds can take full advantage of compression for transmission. The UNIX "compress" program will compress most text to 50% of its size. Compression of a uuencoded archive containing compressed files will yield a net compression of its original contents (allowing for expansion during uuencoding) of perhaps 30 per cent. These numbers are rough guesses. o Users can easily see what has been posted without having to unarchive it first. Disadvantages of source in clear text format: o Clear text takes more disk space for storage. o If the source is stored as a shar archive, then only a very rudimentary error detection (by counting characters) is available. Shar does not maintain any CRC value for error detection. o If the source is stored as a shar archive, not all systems can extract it. On UNIX systems extraction is easy. On other systems extraction may be difficult or nearly impossible, especially if the shar archive uses a prefix character. (A prefix character is needed to avoid losing leading blanks and tabs when the article passes through peculiar network links, and to avoid the string "From" being replaced by the string ">From" at the beginning of a line by helpful mail software. o Some transmission channels will strip out trailing blanks; though not usually detrimental to source, this will often change the character count and lead to users wondering if they received uncorrupted source. Some transmission channels will silently truncate source lines to 80. BITNET is a good example of both of the above. o Most cleartext for MS-DOS contains lines terminated with <CR><LF> pairs; for Usenet posting as clear text these will need to be converted to <LF>-terminated lines, and converted back by the end user when moving to his microcomputer. o Since almost all source posted to comp.binaries.ibm.pc is accompanied by one or more executable files, posting clear text will approximately double the number of articles posted. Each source posting will need to be posted as at least two articles, one containing the source files, the other containing the archived executable(s). -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
heiby@falkor.UUCP (Ron Heiby) (10/24/88)
Mark A. Charette (charette@edsews.EDS.COM) writes: > I disagree somewhat. For those people accessing this via some connection > other than a Unix machine, it requires finding out what *.sources it would > be in, downloading it in ascii form (at their expense), and writing (or > finding) the unshar script. What an incredibly interesting concept! You mean someone might have to actually *PAY* for what they want, rather than just leaching off some other site?????? And, further, that someone might actually have to spend five minutes with a text editor to get something they want????? Wow! I never imagined that Tom could be so insensitive, that he would want someone to actually have to work to get something they wanted, just so people who don't have the good fortune of having the most amazing computer ever made on their desks could possibly get a small amount of benefit from the posting they're paying to transport. How obnoxious! ======== Good grief! Let's all get out our manuals and figure out how our text editors work, shall we? For those who cannot read, the MKS toolkit provides a dandy version of the Korn Shell and other tools that should be able to "unshar" quite nicely. MS-DOS unshar programs have been posted in the past, as well. Again, good grief! -- Ron Heiby, heiby@mcdchg.chi.il.us Moderator: comp.newprod "There is a fine line between stupidity and cleverness." (This is Spinal Tap)
wfp@dasys1.UUCP (William Phillips) (10/25/88)
In article <3271@edsews.EDS.COM> charette@edsews.EDS.COM (Mark A. Charette) writes: [...] >I like having both the source and binary packaged together. I may not have >the {compiler,libraries,version} needed to compile the source immediately, >so at least I can try the binary and figure out whether it's worth the >conversion effort to make it work with my compiler. >Also, I have a (little) more trust in a binary accompanied by source - the >chances of the binary being a trojan might be reduced. I agree entirely with both points. Also, as has been pointed out, the effort involved in unsharing, then zooing (or a*cing, if you prefer) all the bits and pieces together for download can be a pain in the butt. So much simpler just to remove superfluous lines, uudecode, and download. Besides, you get the added benefit of CRC checks -- I've downloaded stuff only to find it corrupted when dea*cing it, but at least then I _know_ it's corrupt and won't try to use it. /bill -- William Phillips {allegra,philabs,cmcl2}!phri\ Acting Co-administrator {bellcore,cmcl2}!cucard!dasys1!wfp BEC Public Excess Unix New York, NY, USA !!! JUST SAY "NO" TO OS/2 !!!
dani@ritcsh.UUCP (Dani Kadoch) (10/25/88)
>In article <7119@dasys1.UUCP>, tneff@dasys1.UUCP (Tom Neff) writes: >> ARC+UUENCODE should be restricted to no-choice binaries like .EXE's and >> data files. Newsbatch-compress will do a better job of saving net >> bandwidth on your source files than ARC+UUENCODE can anyway. > >I disagree with you ... >... ARC files save >transmission time down to my micro. Don't forget that most of the stuff >posted here _is_ for those MS-DOS machines. Some people seem to forget that having the net is a priviledge, not a right. The cost of transmitting long postings is very high, and when we think about how to send files over the net we should be *primarily* concerned with the "hidden" costs involved. I don't know exact figures, but I know that *many* long distance phone calls are made for every posting. We have to remember that if some backbone sites start considering stopping their service because of the costs involved, the net would be seriously hurt. When you download stuff to your micro you're probably making a local phone call which is probably for free. If you let your micro work a little longer downloading a file, it won't affect you as much as it would increase transmission costs of that file world-wide. -- +/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\+ > Dani Kadoch -- R&D director @ Computer Science House < > Rochester Institute of Technology < > UUCP:rochester!ritcv!ritcsh!dani MCIMail:dani BITNET:dnk8842@ritvax <
thaler@speedy.cs.wisc.edu (Maurice Thaler) (10/25/88)
The point about editing the files is superflous. With the newer UUDECODE, if you have multiple files that are numbered properly, it will do ALL THE WORK. For example, save the pieces as blah1.uue,blah2.uue,blah3.uue and blah4.uue. Then run UUDECODE BLAH1. It will automatically attach the files and ignore the lead in gobbledegook. You don't even have to change newline to cr/lf. So just download the files as is, and put them together on your pc. Easy as pie. The version of UU-DECODE that I use is by Richard Marks and is version 2.8 . The UU-Encode is equally excellent.
tneff@dasys1.UUCP (Tom Neff) (10/25/88)
Several people have objected to my assertion that PC source collections should be posted in shell-archive form to a comp.sources.* group rather than bundled into ARC "binaries" and UUENCODED into the c.b.i.p. newsgroup. The primary objection seems to be that PC users either don't have the tools to deal with shar's and wouldn't know where to get them, or that it's too much like hard work to deal with things that way when you could just take the ARC file directly. Unfortunately this is tantamount to saying that since PC users only know how to deal with BBS's, Usenet (specifically Netnews) should accomodate them by behaving like a BBS. But Netnews is not, and *cannot be*, a BBS. We have been all over the reasons for this in the original c.b.i.p. debate. PC users have a responsibility to learn something about Usenet before crowding into it. If they don't, they will both damage the net and reinforce the mainframe/mini crowd's nastiest prejudices. Archive site administrators, in particular, have zero excuse for not having the tools to deal with the primary forms of Net distribution. If you don't have what you need, say so in news.* and people will get in touch with you. C.b.i.p. should carry only binary executables, fonts, control files and such. Source should be shar'd and posted to comp.sources.*. That's not what a BBS does, but this is not a BBS. -- Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff "None of your toys CIS: 76556,2536 MCI: TNEFF will function..." GEnie: TOMNEFF BIX: t.neff (no kidding)
leonard@bucket.UUCP (Leonard Erickson) (10/26/88)
In article <7119@dasys1.UUCP> tneff@dasys1.UUCP (Tom Neff) writes:
<The appropriate thing to do with a source collection is to package it
<as a shell archive and post it to a source newsgroup as clear text.
<ARC+UUENCODE should be restricted to no-choice binaries like .EXE's and
<data files. Newsbatch-compress will do a better job of saving net
<bandwidth on your source files than ARC+UUENCODE can anyway. Text
<should still have primacy on Netnews whenever technically possible, so
<that the greatest number of newsreaders can enjoy the benefits of the
<information they're paying to pass around.
Last time I looked there was not a comp.sources.ibm.pc group. Comp.sources.*
has far to little of use to non-Unix systems to follow.
No as to the matter of packing the files as a "shell archive"...
*DON'T*!! I have tried several versions of programs that would supposedly
unpack shell archives on my MS-DOS system only to have them fail one or
another of the shell archives I've downloaded. This means I have to unpack
them on the unix system and then download a whole bunch of files. And since
they aren't packed, they take a lot of time to download. I could use compress
on them as I have a working 16-bit compress on my MS-DOS system, but then I
have to go and change all the newlines to cr/lf's. The file xfer program can
do that automatically on text files.
I'd much rather download the article and do all the editing, uudecoding
and unarcing on *my* machine, where I don't have to worry about hogging
a limited resource like phone lines.
--
Leonard Erickson ...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I used to be a hacker. Now I'm a 'microcomputer specialist'.
You know... I'd rather be a hacker."cjl@ecsvax.uncecs.edu (Charles Lord) (10/26/88)
OK Tom, next round...
I agree that this is *NOT* a BBS or file service. It is an
education-based medium for the proper support and dessimination (sp?)
of information in the *proper forums*. A binary newsgroup should
*only* have binaries and source newsgroups likewise. A discussion
group such as comp.sys.ibm.pc should be such and not have programs
or WANT ADS (hint, hint folks!), but for every request to do things by
the "rules" there is at least one rulebreaking post. My point is that
a system like this should not be constrained to what is RIGHT, but what
the users will agree to abide by. I really do not feel like the PC
users are lazy or afraid to change, but wish to remain in familiar
territory. Why force them to use Un*x conventions when it really is
not necessary? I predict that the ensuing net.confusion if you got
your way would be chaos! Look at the flurry of "I missed part 6"
responses on postings. Just imagine what would happen if the post
was in two or even three Newsgroups! (.binary.,.source.,.docs.)
Besides, there IS NO comp.sources.ibm.pc
....yet.
Bottom line: your idea has merit but it will never fly.
--
* Charles Lord ..!decvax!mcnc!ecsvax!cjl Usenet (old) *
* Cary, NC cjl@ecsvax.UUCP Usenet (new) *
* #include <std.disclamers> cjl@ecsvax.BITNET Bitnet *
* #include <cutsey.quote> cjl@ecsvax.uncecs.edu Internet *w8sdz@smoke.BRL.MIL (Keith B. Petersen ) (10/26/88)
When the network can transmit newsgroups without errors and truncations
we should consider posting clear text. Until then, ARC files are the
only way to know if the posting arrived intact. The Unix compress
program does not have any checksum or CRC to go with the file. If it
did, we wouldn't see any munged postings because the receiving system
would tell the sender to try again until it got a good copy. It's a
basic flow in the way Usenet operates with no error checking of the file
integrity. True, uucp has error checking, but that doesn't solve the
problem of other system errors such as a system that truncates a posting
simply because there is no more room in the /usr/spool directory. It
should delete the file when that happens and then later ask for a
retransmission when there is disk space available. If Usenet used
Zmodem instead of Uucp for moving the net mail and newsgroups this
wouldn't happen. Zmodem sends the file size info before sending the
file and the receiver can reject it if there is not enough space.
--
Keith Petersen
Maintainer of the CP/M and MSDOS archives at SIMTEL20.ARMY.MIL [26.0.0.74]
Arpa: W8SDZ@SIMTEL20.ARMY.MIL
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!simtel20.army.mil!w8sdzimacbeath@crocus.waterloo.edu (Ian MacBeath, Conrad Grebel College) (10/26/88)
In article <7194@dasys1.UUCP> tneff@dasys1.UUCP (Tom Neff) writes: >Several people have objected to my assertion that PC source collections >should be posted in shell-archive form to a comp.sources.* group rather >than bundled into ARC "binaries" and UUENCODED into the c.b.i.p. >newsgroup. [discussion about USENET and BBS stuff] >C.b.i.p. should carry only binary executables, fonts, control files and >such. Source should be shar'd and posted to comp.sources.*. That's >not what a BBS does, but this is not a BBS. It appears that comp.binaries.ibm.pc is the odd newsgroup out in that there is no corresponding comp.sources.ibm.pc newsgroup. I just had a quick look and there are comp.{binaries,sources}.{atari.st,amiga,mac} newsgroups to which are posted the uuencoded executables in the binaries newsgroup and the shar'ed sources in the sources newsgroup. Doesn't it seem reasonable to follow the procedure that the rest of USENET uses? Why doesn't somebody start and moderate a sources newsgroup? .binaries is for binaries because some of us don't have compilers so we can't use the sources, but if we wanted them then we should be able to get them out of the sources group (if it exists). How about just posting the sources separate from the binaries so that those who can't use them or don't want them can just junk the sources and save the binaries? This way they don't have all this extra source to uudecode, dearchive, and throw away to get the binaries. Those wanting the sources can just save the sources posting. Summary: Create comp.sources.ibm.pc and be like the other USENET groups or post sources and binaries separately until when the sources newsgroup will inevitably get created.
dmt@mtunb.ATT.COM (Dave Tutelman) (10/26/88)
OK, I've sat on the sidelines till now, but Tom really got to me this time.... In article <7194@dasys1.UUCP> tneff@dasys1.UUCP (Tom Neff) writes: >Several people have objected to my assertion that PC source collections >should be posted in shell-archive form to a comp.sources.* group rather >than bundled into ARC "binaries" and UUENCODED into the c.b.i.p. >newsgroup. I, for one, though not publicly until now. >The primary objection seems to be that PC users either >don't have the tools to deal with shar's... Like "sh" ? That's certainly true for the VAST majority of PC users. Do you know where I can get a "sh"-alike for DOS for under $100? Don't tell me about "unshar" programs that deal with the "usual" shar format, unless you're prepared to accept a SPECIFICATION AND STANDARDIZATION of the shar format. Right now, the DEFINITION of a shar is, I believe, anything that can be unpacked by sh and the commonly-available UNIX operating system utilities. I have seen shell archives (and even made one or two) that do just a little more, and would break a special-purpose unshar program. But they unpack as intended under the UNIX operating system. >.... or that it's too much like hard work to deal with things that way >when you could just take the ARC file directly. So you propose a return to the "work ethic" of "do it by hand; who needs tools!" What industry did you say you worked in???? (If you meant something other than this, you didn't say it well.) By the way, you'd be closer to right if this weren't EXPLICITY a newsgroup for PC users. But, facts being facts, it is. >..... >PC users have a responsibility to learn something about Usenet before >crowding into it. If they don't, they will both damage the net and >reinforce the mainframe/mini crowd's nastiest prejudices. This is an ad-hominem argument tinged with paranoia. You're better than that, Tom. I was a usenet reader before I was a PC user, and I continue to be involved in more than the PC newsgroups. But I can disagree with you STRONGLY on the merits of this debate. >.... >C.b.i.p. should carry only binary executables, fonts, control files and >such. Source should be shar'd and posted to comp.sources.*. I have a very practical problem with this. When I post a program, I frequently want to post the source (for those who want to see how it's done) and the binary (for those who don't have the same compiler I do). No flames about writing portable programs only; I go out of my way to, but some things don't quite port and some things have to be tuned for acceptable performance. Anyway, the last time I posted such a combination to a source group, the moderator followed the rules and broke it into a source and a binary posting (in the appropriate DIFFERENT newsgroups). This, of course, (1) broke my file manifest and my announcement, and (2) led readers of one group but not the other to never see half the posting. I had to deal with tons of mail from people wondering where the rest of it was. Thus I maintain THERE IS A NEED for a newsgroup that accepts MIXED SOURCE AND BINARY POSTINGS! Right now, c.b.i.p. fills this need nicely. Any proposal to do away with source on c.b.i.p. MUST DEAL WITH THIS NEED. Tom's scolding doesn't. +---------------------------------------------------------------+ | Dave Tutelman | | Physical - AT&T Bell Labs - Lincroft, NJ | | Logical - ...att!mtunb!dmt | | Audible - (201) 576 2442 | +---------------------------------------------------------------+
Ralf.Brown@B.GP.CS.CMU.EDU (10/26/88)
In article <7194@dasys1.UUCP>, tneff@dasys1.UUCP (Tom Neff) writes: }C.b.i.p. should carry only binary executables, fonts, control files and }such. Source should be shar'd and posted to comp.sources.*. That's }not what a BBS does, but this is not a BBS. Does this mean that you volunteer to moderate comp.sources.msdos? The fact of the matter is that, unlike for the Atari, Mac, or Amiga, there is no sources group for MSDOS machines. Second, many copyrighted-but-free programs require that ALL files be distributed together, i.e. in the original archive. Splitting the binaries and sources into different newgroups probably violates this requirement. I have even seen several programs which prohibit repacking with a different archiver, much less splitting things up. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/31 Disclaimer? I |Ducharm's Axiom: If you view your problem closely enough claimed something?| you will recognize yourself as part of the problem.
nelson@sun.soe.clarkson.edu (Russ Nelson) (10/27/88)
Ok, guys. Let's face it -- Tom is correct in that archives of source files cost more to transmit than just the source files themselves. And everyone else is correct in that archives are more convenient and more usual in the PC domain, which after all, is the intended domain. And they are also correct in that shar files can easily get truncated. I have thought of a solution which will make everyone happy. We need to distribute everything in shar format, including those few files that really are binary (they get uuencoded, of course). Included in the shar file is a verbose listing of the arc file that contained the sources in the first place. We need a pair of programs, arc2shar and shar2arc, that will change an archive file into one or more shar files and back again. These programs can assume that Howard Chu's port of ARC to Unix is available. Each shar file should stand on its own, so that the parts can arrive out of order. Another advantage of this system is that you never get a totally unusable arc file, since it's made up on the spot. arc2shar should automatically detect binaries and uuencode them. They should both be written in C and should not assume the presence of uuencode or sh. In other words, the programs should be portable to MS-LOSS. Tom Neff is going to write these programs, because he is the one who is kvetching about the current situation. If Tom refuses to write them, then he abrogates his right to complain. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) To surrender is to remain in the hands of barbarians for the rest of my life. To fight is to leave my bones exposed in the desert waste.
keithe@tekgvs.GVS.TEK.COM (Keith Ericson) (10/28/88)
OK, first of all, remember that Tom's original complaint/observation
had to do with SOURCE files, wherein everything fit into the 7-bit
ASCII world.
In that case it seems inefficient to do
ascii --> arc(='binary') --> uuencode(='ascii')
followed by
ascii --> uudecode(='binary') --> unarc(='ascii')
especially when good arguments have been put forth that USENET
transmission of ARC'd/UUENCODE'd files is not as efficient as
is the transmission of cleartext ascii.
It seems to me (look out, unsupported opinion follows) that the
efficency for the many, many USENET machines is more important than
the individual USENET host-to-PC. And besides, if you really _want_
to you can ARC it on your USENET host and _then_ download it.
keith
ps - ARC is calimed to be a trademark by SEA and I'm trying to forget
what "S" "E" "A" stands for as fast as I can...burleigh@silver.bacs.indiana.edu (frank burleigh) (10/28/88)
Those who want to send clear text over USENET and who wouldn't gag on a SEA product could use ARC's S suffix to store the text in an archive without compressing it. The archive is still binary, but that would only be file headers. All else seems to be clear text. of course PKPAK hasn't such a suffix... -- Frank Burleigh USENET: ...rutgers!iuvax!silver!burleigh 812/335-4127 Department of Sociology, Indiana University, Bloomington, Indiana 47405
dmt@mtunb.ATT.COM (Dave Tutelman) (10/28/88)
In article <NELSON.88Oct26134617@sun.soe.clarkson.edu>: > >I have thought of a solution which will make everyone happy. We need >to distribute everything in shar format, including those few files that >really are binary (they get uuencoded, of course). Included in the >shar file is a verbose listing of the arc file that contained the sources >in the first place. So far, so good, with reservations.... >We need a pair of programs, arc2shar and shar2arc, that will change an >archive file into one or more shar files and back again. Either you've gone into overkill, or I overstated what I wanted. I don't insist on an ARC file. What I want is: - Combined source/text and binary in a single posting. THIS IS ESSENTIAL; it is NOT met by a moderated comp.sources.ibm.pc with rules that binaries get stripped out and posted elsewhere. - The ability to pack/unpack it on my PC. I'm quite willing to manually enter a command, to ARC (oops, hope I don't get sued :-) and unARC the loose files. My real problem is that I don't have the tools to shar and unshar in DOS. All we need to make me happy is a STANDARD FORMAT for shar files that we all agree to use, and a shar/unshar program[s] that works under DOS. I even agree that the ability to look at the readme file in quasi-clear text is an advantage. Now there will be SOME people who won't be happy with this: - Those who download at low speeds, and need the compression of an ARC. I have a high-speed link, so I'll just let them speak for themselves. - Those who want to move bundles of software between BBSs and usenet without bothering to unpack them. (I guess I don't have sympathy for them.) Ain't I reasonable? :-)> +---------------------------------------------------------------+ | Dave Tutelman | | Physical - AT&T Bell Labs - Lincroft, NJ | | Logical - ...att!mtunb!dmt | | Audible - (201) 576 2442 | +---------------------------------------------------------------+
jpn@teddy.UUCP (John P. Nelson) (10/28/88)
In article <2547@silver.bacs.indiana.edu> burleigh@silver.UUCP (frank burleigh) writes: >Those who want to send clear text over USENET and who wouldn't gag >on a SEA product could use ARC's S suffix to store the text in an >archive without compressing it. The archive is still binary, but >that would only be file headers. All else seems to be clear text. >of course PKPAK hasn't such a suffix... Uh, I think you missed the point. The reason that posting ARC's of text files is a problem is because you must "uuencode" them before posting. ARC (with or without the S suffix) generate a file which must be uuencoded because USENET can only tolerate ASCII files. It is the ASCII -> BINARY (ARC) -> ASCII (uuencode) sequence that is the real problem with ARC's on usenet. It is much more efficient to skip BOTH the ARC and uuencode steps, and post the ASCII text directly. However, it HAS been established that: BINARY -> ARC -> UUENCODE is no worse than BINARY -> UUENCODE in terms of transmission efficiency, and it is more convenient for the end-users as well. -- john nelson UUCP: {decvax,mit-eddie}!genrad!teddy!jpn smail: jpn@teddy.genrad.com
draper@bu-tyng.bu.edu (Sir Dave of Wentworth) (10/29/88)
Hello all, I'm not sure which is the way to go. ARC files will all the files in them make life quite easy. Shar files with the source would make a lot of sense if we had a source group for pcs. I think the average person who has a pc and uses the net should have the ability to handle the information passed over the net no matter what format it is in. There are plenty of pd programs around for unsharing and uudecodeing files. If anybody dosen't have them then send email to me. I have several nice versions of uuencode/decode and shar programs. I have source for all of them also if you're of those persons that dosen't trust binaries. There was quite a discussion about the merits of a newsgroup for msdos sources about 6 months ago. I would like to re-open that discussion. I propose that we discuss the idea of creating a group that would fall along the lines of: comp.sources.dos I think with all the trojans and viruses going around these days we need this group mokre than ever right now. Dave Dave Draper UUCP: decvax!elrond!bu-tyng!draper Internet: draper@bu-tyng.bu.edu Boston University Corporate Education Center 72 Tyng Road Tyngsboro MA 01879 649-9731 x14
tneff@dasys1.UUCP (Tom Neff) (11/01/88)
In article <NELSON.88Oct26134617@sun.soe.clarkson.edu> nelson@clutx.clarkson.edu writes: >... Tom Neff is going to write these programs, because he is the one who is >kvetching about the current situation. If Tom refuses to write them, >then he abrogates his right to complain. Well, at least we've learned how one earns the right to complain on Usenet: agree to code Russ Nelson's solution to every problem. :-) 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. Let me cover a few points. * Yes, some shar variants give MSDOS-based unshar programs headaches. HOWEVER please keep in mind that these are *moderated* newsgroups. It ought to be perfectly straightforward for the moderator to (a) settle on one or two "approved" unshar'ers for use with the material distributed, (b) vet each incoming submission against the approved unshar to make sure it likes it, and either (c) reject or (d) re-shar submissions that cause trouble. * 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 because (that's right, you guessed it) USENET IS NOT A BBS! We cannot possibly carry everything BBS's carry, and we shouldn't try. If something is going to consume Usenet resources for the benefit of PC-owning Usenet members, it can damn well conform to Usenet convention. * Missed sections and repost requests are a fact of life, especially in groups like c.b.i.p. whose connectivity sucks because of the high volume-to-interest ratio. The way you minimize the heartache from missed sections is to POST SMALL STUFF!! Not to point the finger at anyone in particular, but 17-part games or demos are not the way to fly. Rahul has been doing a wonderful job at handling this, by the way -- I just wanted to make the point. The ideal c.b.i.p. posting is a 10k utility everyone with a PC ought to have. Here endeth the polemic. :-)
creps@silver.bacs.indiana.edu (Steve Creps) (11/03/88)
In article <5665@ecsvax.uncecs.edu> cjl@ecsvax.uncecs.edu (Charles Lord) writes: >Besides, there IS NO comp.sources.ibm.pc But there IS a comp.sources.misc. PC sources should go there. That is where I posted PCcurses. As for using arc on these files, PC users can get a copy of arc for Unix, and use it after they've extracted the shar files. That's what I do. Personally I think there is too much of this "BBS mentality" in the PC groups (just in general; I don't mean the person whose article I'm replying to). Those individuals should go elsewhere as far as I'm concerned, like to a BBS. They've already made comp.sys.ibm.pc worthless. - - - - - - - - - - Steve Creps, Indiana University, Bloomington, home of the "Hoosiers" creps@silver.bacs.indiana.edu (129.79.1.6) {inuxc,rutgers,uunet!uiucdcs,pur-ee}!iuvax!silver!creps creps@iubacs.bitnet (forwarded)
bobmon@iuvax.cs.indiana.edu (RAMontante) (11/04/88)
tneff@dasys1.UUCP (Tom Neff) writes: > [lotsa stuff; then...] > > * Missed sections and repost requests are a fact of life, especially > in groups like c.b.i.p. whose connectivity sucks because of the high > volume-to-interest ratio. I see far more repost-requests in the various source groups (or source.d groups) than I do for c.b.i.p; also, the monthly readership analyses consistently put c.b.i.p quite high in terms of distribution, readership, and by implication interest. Let me offer the following quibble w.r.t. the repostings issue: Consider a program containing 80K of source files. If shar'ed, this program will have to be sent as two postings to satisfy the limitations of some of the net's mailers. If yer-favorite-archiver can knock it down by 60%, and uuencode takes that back up by 125%, the result is 60K -- just small enough to go out as one posting. So the chances of needing a repost of a part are worse with the shar'ing, simply because there are more parts running around. >Here endeth the polemic. :-) I think the only way net.discussions end is by being eclipsed by newer & flamier topics :-) -- -- bob,mon (bobmon@iuvax.cs.indiana.edu) -- "Aristotle was not Belgian..." - A Fish Called Wanda
wcf@psuhcx.psu.edu (Bill Fenner) (11/04/88)
In article <4458@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: | |Disadvantages of source in clear text format: | |o Clear text takes more disk space for storage. | Yabut... it's going to be uuencoded arc'd text which is usu. bigger (or close to the same size as) the clear text... if you can tell machines to uudecode it after sending it, then it'll take less space, but it will still take approximately the same space using the current software. Bill -- Bitnet: wcf@psuhcx.bitnet Bill Fenner | "Ain't got no cash, Internet: wcf@hcx.psu.edu | Ain't got no style UUCP: {gatech,rutgers}!psuvax1!psuhcx!wcf | Ain't got no girls Fido: Sysop at 263/42 (814/238 9633) \hogbbs!wcf| To make me smile"
brad@looking.UUCP (Brad Templeton) (11/08/88)
Why not use the "portable archiver" from HP that was posted to the net a while ago. It's freeware, very simple, consists of just a few pages of portable C source, and it's compatible with the 4bsd "ar" program. On top of that, the archives of text files are themselves text files and are human readable. It's silly to ARC text. -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
alexande@drivax.UUCP (Mark Alexander) (11/10/88)
In article <2275@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes: >Why not use the "portable archiver" from HP that was posted to the net >a while ago. It's freeware, very simple, consists of just a few pages >of portable C source, and it's compatible with the 4bsd "ar" program. You could also use the 'f' option of Zoo to create non-compressed archives. The advantage is that Zoo is already in wide use on many machines. (I like to use existing tools.) -- Mark Alexander (UUCP: amdahl!drivax!alexande) "Bob-ism: the Faith that changes to meet YOUR needs." --Bob (as heard on PHC)
greggy@infmx.UUCP (greg yachuk) (11/15/88)
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