gerard@tscs.UUCP (Stephen M. Gerard) (03/08/88)
In article <1424@polyslo.UUCP> mdella@polyslo.UUCP (Marcos Della) writes: >Its been awhile since people have hashed out who is or is not going to >be a moderator here and if there is a real need... Looks like there might >be a need, but the questions is there a want? > >Anyway, I'm still up on helping out with it if people want moderation... > There is a very definite need for moderation here! I would very much like to see comp.binaries.ibm.pc moderated. It would be extremely nice not to have to go through and weed out the chit chat (Including this article :-) ). I do very much appreciate the quality postings that may be found here and I hope that it can continue. I know of sites that do not wish to receive comp.binaries.ibm.pc because of the difficulty in weeding out the misplaced material. If there are any serious potential moderators out there, here are a few features that I would like to see: * A standardized header for postings including: 1. Program Name 2. Version Number of Revision Date 3. Author Name and Address 4. Program Clasification (System Utility, Communications, Business, Text Processing, etc.) 5. A Source Code Included Flag 6. A four to six line description of the program that is not burried in a README file and especially NOT UUENCODED 7. Hardware Requirements 8. Software Compatibility (DOS, UNIX SV, UNIX BSD, etc) * A cataloging program that can read through headers with the afore mentioned information that can print out a cross reference list. * A standardized multi-system compatible archiving format such as ARC. I hope that someone can find time to moderate this group. I feel that it is a shame that the IBM PC is the most popular personal computer system and we do not have moderated binary and source newsgroups. Sincerely, Steve ------------------------------------------------------------------------------ Stephen Gerard - Total Support Computer Systems - Tampa - (813) 876-5990 UUCP: ...{codas, gatech}!usfvax2!tscs!gerard US-MAIL: Post Office Box 15395 - Tampa, Florida 33684-5395
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/10/88)
In article <149@tscs.UUCP> gerard@tscs.UUCP (Stephen M. Gerard) writes: >There is a very definite need for moderation here! I volunteer to moderate again. I'm sending a message to the backbones to tell them so. There really seems to be no documented procedure for this. The specific action that needs to be taken is for the backbones to add a moderator's address in their mailpaths file and to set up a mail alias "comp-binaries-ibm-pc". How one convinces them to do this I don't know. I'll tell you if/when I get a response. I'll check with our UUCP neighbors too at the same time and see if they vehemently object. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
tr@wind.bellcore.com (tom reingold) (03/10/88)
Would you folks please take "comp.binaries.ibm.pc" out of the newsgroups line if you are going to write some text, just as I have just done? It sure looks stupid when I read about how it's annoying to have text in the binaries group in the binaries group. Tom Reingold INTERNET: tr@bellcore.bellcore.com Bell Communications Research UUCP: rutgers!bellcore!tr 435 South St room 2L350 SOUNDNET: (201) 829-4622 [work] Morristown, NJ 07960 (201) 287-2345 [home]
richard@aeras.UUCP (Richard Karasik) (03/11/88)
[STUFF DELETED] .If there are any serious potential moderators out there, here are a few .features that I would like to see: . . * A standardized header for postings including: . 1. Program Name . 2. Version Number of Revision Date . 3. Author Name and Address . 4. Program Clasification (System Utility, Communications, . Business, Text Processing, etc.) . 5. A Source Code Included Flag . 6. A four to six line description of the program that is . not burried in a README file and especially NOT UUENCODED . 7. Hardware Requirements . 8. Software Compatibility (DOS, UNIX SV, UNIX BSD, etc) . . * A cataloging program that can read through headers with the . afore mentioned information that can print out a cross reference . list. . . * A standardized multi-system compatible archiving format such as . ARC. . In addition - the standard header should have VOLUME: etc so that standard archiving programs that grab stuff out of various places like comp.sources can be "slightly" modified (I emphasize slightly) to grab stuff out of here and archive it automatically. Whoever moderates might want to contact the moderator of comp.sources to see why the headers were set up that way. Sorry for the extra chit chat -but no x.x.x.d group yet.
gerry@syntron.UUCP (G. Roderick Singleton) (03/14/88)
In article <125@aeras.UUCP>, richard@aeras.UUCP (Richard Karasik) writes: > [STUFF DELETED] > .If there are any serious potential moderators out there, here are a few > .features that I would like to see: > . {MORE STUFF DELETED} > > In addition - the standard header should have VOLUME: etc so that > standard archiving programs that grab stuff out of various places > like comp.sources can be "slightly" modified (I emphasize slightly) > to grab stuff out of here and archive it automatically. > This is an exceptionally good idea. ... MORE STUFF DELETED > > Sorry for the extra chit chat -but no x.x.x.d group yet. About this last line, I think that comp.sys.ibm.pc provides a more than adequate forum for our discussion. While I agree that there may periods of excessive noise in this group, for the most part ours fits right in and aren't we attempting to encourage postings of binaries to our binaries group? Of course we are. I propose that we move our moderation discussion to the group that will benefit most by its moderation, comp.sys.ibm.pc. We will gain two ways reduction of the noise in our binaries group and increasing the number of interested readers. My hope would be that reaching a broad scope of ibm-pc users would, in the end, increase the volume of good software and reduce the amount of sources, et cetera in the sys group. Before anyone says that the group is too noisy, I read the whole thing faithfully every day and I have yet to find more than 10-13% in the garbage category. This is in constrast to the cr-er-junk in new.groups where I "catchup" more often than not. Further, some of the naive questions pertain directly to use an transfer of the very binaries we are attempting to moderate. Good idea? I hope so. -- G. Roderick Singleton, Technical Services Manager { syntron | geac | eclectic }!gerry "ALL animals are created equal, BUT some animals are MORE equal than others." George Orwell
johnson@c10sd1.StPaul.NCR.COM (Wayne D. T. Johnson) (03/18/88)
Would it not make more sense to find 1 (or more) nodes that are willing to archive the binaries and have the authors (or their representatives) just distribute a synopsis of the program for all to see. These archive nodes could then distribute the software only to those users who have requested (ordered?) it. This process would be automated of course. This would greatly cut down on network traffic because only requested software would be transmitted. Not everyone wishes a copy of every program sent out. In my case I think I only keep 2-3% of the binaries that pass by. The amount of time spent re-transmitting portions of a program (and the requests to retransmit it) could also be eliminated. I have seen references to various archives around the network, since I am new here, some of what I have suggested may be already in place. But the basic idea of only brodcasting small descriptions of a program and allowing those interested to order it instead of mass distribution makes sense to me.
adam@gpu.utcs.toronto.edu (Adam R. Iles) (03/22/88)
In article <345@c10sd1.StPaul.NCR.COM> johnson@ncrcce.StPaul.NCR.COM (Wayne D. T. Johnson) writes: >Would it not make more sense to find 1 (or more) nodes that are willing >to archive the binaries and have the authors (or their representatives) >just distribute a synopsis of the program for all to see. These archive <stuff about a server> >This would greatly cut down on network traffic because only requested >software would be transmitted. NO NO NO !!!!!! This would GREATLY INCREASE the trafic on the net. The present method only involves sending a file between any two nodes once for everyone on the net. Your scheme would see it being transmitted for everyone who requests a copy (almost everyone :-) And don't forget that this includes EVERYONE who is downstream from the server. In the worst case (assuming all subscribers request all the files only once) this would MULTIPLY the load on the system by about 1/2 (assuming an even distribution between all nodes) of the number of subscribers! > Not everyone wishes a copy of every >program sent out. In my case I think I only keep 2-3% of the binaries >that pass by. The load isn't caused by someone keeping the file it's caused by someone requesting the file. > The amount of time spent re-transmitting portions of a >program (and the requests to retransmit it) could also be eliminated. What would be eliminated is the transfering from a node to a PC. This could be done by being careful about what you download. >I have seen references to various archives around the network, since I >am new here, some of what I have suggested may be already in place. But >the basic idea of only brodcasting small descriptions of a program and >allowing those interested to order it instead of mass distribution makes >sense to me. Not to me! It's VERY easy to listen to see smaller numbers and think that it means that it's cheaper, but this plan wouldn't work. The idea of including a synopsis of the program along with it has been around for a long time, but that's ut to the person posting/moderating. I really would like to thank Wayne for posting his article to to Comp.sys.ibm.pc rather than the binaries group. Thank-you for reading this. I'll just put away my soap box now. -- Any opinions stated above may, or may not, refect those of any sane person living, dead, or just sleeping. Adam R. Iles: adam@utgpu