jw@pan.UUCP (Jamie Watson) (05/17/88)
In reading the recent discussions about binary groups and binary postings, it
seems that there has too often been an assumption that anyone who objects to
binary postings is a "unix elitist" or is "anti-pc". I think that this is
missing the point. I object to binary postings because of what they are, not
because virtually all of them (at this time) are for pc's of some sort. If
I undersand John Gilmore's recent postings, he feels the same way. I would
not, under any circumstances, allow a binary from the net to be run on any
computer under my control. This means that if the proposed "ABI" standard
ever becomes reality, and unix binaries start appearing on the net, I will
be every bit as opposed to them as I am to {pc,mac,atari,cbm,...} binaries.
If anything, the tendency toward binary postings seems to be increasing. In
recent weeks there have been suggestions and/or proposals for new groups for
posting hypercard stacks (I think that was it), and gif image files. While
these probably have less destructive potential than unknown executables, it
is likely that they are objectionable to a large portion of the net for many
of the other reasons associated with binary postings (size, limited interest,
etc.).
The solution offered to all those who object has consistently been to just
block comp.binaries at your news feed. This, however, at this time requires
some specific action to be taken by a neighbor site, adding !comp.binaries
to the news/sys file entry. I think the situation should be reversed. By
putting binaries in their own hierarchy, bin.*, it would require specific
action to *receive* them, rather than to block them. Given the occasionally
very large volume of postings in these groups, the rather limited interest
in them on a net-wide basis, and the tremendous volume of complaints, flames,
and counter-flames generated every time a large binary is posted, it seems a
good idea to try something to alleviate the problem, instead of just yelling
at each other about it.
jwjwp@chem.ucsd.edu (John Pierce) (05/19/88)
In article <397@pan.UUCP> jw@pan.UUCP (Jamie Watson) writes: > > .... putting binaries in their own hierarchy, bin.*, would require specific > action to *receive* them, rather than to block them.... That's an excellent suggestion. -- John Pierce Chemistry, B-032, UCSD, La Jolla, CA 92093 jwp@chem.ucsd.edu jwpierce@ucsd +1 619 534 0203
faigin@sdcrdcf.UUCP (Daniel P Faigin) (05/19/88)
In article <397@pan.UUCP> jw@pan.UUCP (Jamie Watson) writes: >By putting binaries in their own hierarchy, bin.*, it would require specific >action to *receive* them, rather than to block them. I have also been thinking carefully about the binary problem, and have come to the same conclusion. If we were to put binaries in their own top level heirarchy, we would: 1) Eliminate a lot of the clutter in the comp. heirarchy 2) Allow easier segregation of binaries to those sites that wish to carry them. 3) Quite possibly, simplify archival and expiration. Think back as to why the net. heirarchy was originally split into comp., news., sci., misc., soc., and talk.. I think it may be time to split comp. into comp. for technical ascii discussions, and bin. for binaries. Daniel -- W: UNiSYS/Defense Systems/System Development Group (nee SDC) 2400 Colorado Ave;Santa Monica CA 90406;213/829-7511x5162 (or 213/453-5162) H: 8333 Columbus Avenue #17; Sepulveda CA 91343 Email: (uucp) faigin@sdcrdcf.UUCP (arpa) faigin@SM.UNISYS.COM
cranor@udel.EDU (Chuck Cranor) (05/19/88)
In article <215@chem.ucsd.EDU> jwp@chem.ucsd.edu (John Pierce) writes: >In article <397@pan.UUCP> jw@pan.UUCP (Jamie Watson) writes: > > > > .... putting binaries in their own hierarchy, bin.*, would require specific > > action to *receive* them, rather than to block them.... >That's an excellent suggestion. I agree! Then we'd see who *really* wants to tote around all those huge binary postings. I wonder what kind of propagation the biniary groups would get then?? Chuck [UDel News Admin] -- Chuck Cranor University of Delaware PHONE: (302)-451-6660 (UDel), (302)-737-5852 (home) ARPA: cranor@udel.EDU, UUCP: ...!<your_favorite_arpa_gateway>!udel.edu!cranor "I'd like to see John the Baptist's impersonation of Graham Hill." - R.J. Gumby
sullivan@vsi.UUCP (Michael T Sullivan) (05/20/88)
In article <397@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: > By > putting binaries in their own hierarchy, bin.*, it would require specific > action to *receive* them, rather than to block them. I second this motion, vigorously! -- Michael Sullivan {uunet|attmail}!vsi!sullivan sullivan@vsi.com HE V MTL Anybody out there remember Max Webster?
haugj@pigs.UUCP (John F. Haugh II) (05/21/88)
In article <678@vsi.UUCP>, sullivan@vsi.UUCP (Michael T Sullivan) writes: > In article <397@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: > > By > > putting binaries in their own hierarchy, bin.*, it would require specific > > action to *receive* them, rather than to block them. > > I second this motion, vigorously! > -- > Michael Sullivan {uunet|attmail}!vsi!sullivan a motion having been made and seconded for the creation of a separate hierarchy for binary groups, i move for a two week discussion period prior to the (hopefully) collection of votes. and as someone else said, once these have been spun off, let's see what kind of propagation they receive then! - john. -- The Beach Bum Big "D" Home for Wayward Hackers UUCP: ...!killer!rpp386!jfh jfh@rpp386.uucp :SMAILERS "You are in a twisty little maze of UUCP connections, all alike" -- fortune
tower@bu-cs.UUCP (05/21/88)
In article <5284@sdcrdcf.UUCP> faigin@sdcrdcf.UUCP (Daniel P Faigin) writes: |In article <397@pan.UUCP> jw@pan.UUCP (Jamie Watson) writes: |>By putting binaries in their own hierarchy, bin.*, it would require specific |>action to *receive* them, rather than to block them. | |I have also been thinking carefully about the binary problem, and |have come to the same conclusion. If we were to put binaries in |their own top level heirarchy, we would: | |1) Eliminate a lot of the clutter in the comp. heirarchy |2) Allow easier segregation of binaries to those sites that wish | to carry them. |3) Quite possibly, simplify archival and expiration. | |Think back as to why the net. heirarchy was originally split into |comp., news., sci., misc., soc., and talk.. I think it may be |time to split comp. into comp. for technical ascii discussions, |and bin. for binaries. | |Daniel |-- |W: UNiSYS/Defense Systems/System Development Group (nee SDC) | 2400 Colorado Ave;Santa Monica CA 90406;213/829-7511x5162 (or 213/453-5162) |H: 8333 Columbus Avenue #17; Sepulveda CA 91343 |Email: (uucp) faigin@sdcrdcf.UUCP (arpa) faigin@SM.UNISYS.COM Binaries are only half the problem. If USENET really decides to go through another renaming spasm, we should let comp be devoted only to issues of general technical interest. newsgroups devoted to specific classes of machines should have their own top-level newsclasses. All PC's should be included. I'm not sure about mini-/main/super-computers. This will allow those sites who care about the immense amount of traffic about PC's to pay for it. And more importantly, the sites who don't want to carry it, can save some $$. unix-pc.all has successfully showed the benefits of doing things this way. Yes, there will be the stray postings to comp.sys.misc. But the comp.all volume will still drop a lot. Yes, it isn't unfair if your USENET administrators decides they can't foot the bill. Go get a USENET feed for your PC or join the pay as you go services like Compuserve, BIX, Delphi, or the Source. I suggest for starters, the following top level classes with their own backbones: ibm-pc.all mac.all apple2.all amiga.all atari.all enjoy -len
ncoverby@ndsuvax.UUCP (Glen Overby) (05/22/88)
In article <22773@bu-cs.BU.EDU> tower@bu-it.bu.edu (Leonard H. Tower Jr.) writes: >newsgroups devoted to specific classes of machines should have their >own top-level newsclasses. All PC's should be included. I'm not sure >about mini-/main/super-computers. Rather than muddling the current comp. soc. sci. etc. naming scheme, why not bring in a new DISTRIBUTION. We've even got that mechanism in place. >I suggest for starters, the following top level classes with their own >backbones: >ibm-pc.all >mac.all >apple2.all >amiga.all >atari.all Distribution codes could be the same (minus the ".all"). *BUT* if a separate distribution hierarchy is set up (or even if it's not..) why not create a mechanism to transport binaries AS binaries, rather than doing hokey ASCIIfication of them? Then sites which compress news can compress directly off of the binary itself. Obviously, many changes would have to be made to our current news readers and such; I haven't thought out exactly HOW to do this. [the Bitnet line eater is implimented incorrectly and 'eats' the LAST line] -- Glen Overby Bitnet: ncoverby@ndsuvax UUCP: {uunet, ihnp4!umn-cs}!ndsuvax!ncoverby
henry@utzoo.uucp (Henry Spencer) (05/22/88)
> newsgroups devoted to specific classes of machines should have their > own top-level newsclasses... While I agree that there is some merit to this idea, I really loathe the idea of YET MORE top-level names. The length of sys-file lines is already getting ridiculous. It is starting to be more of a nuisance to *get everything* than to be selective -- surely an undesirable state of affairs. Note that it is not necessary for a set of groups to have a common name AT THE TOP LEVEL to selectively include or exclude them in a convenient way; it suffices that they have a common name at some level. Saying, for example, "!comp.binaries" is not much harder than "!bin". Arranging alternate distribution paths, backbones, etc. likewise is not much harder.
wisner@fenchurch.MIT.EDU (Bill Wisner) (05/22/88)
In article <908@ndsuvax.UUCP> ncoverby@ndsuvax.UUCP (Glen Overby) writes: >Rather than muddling the current comp. soc. sci. etc. naming scheme, why >not bring in a new DISTRIBUTION. We've even got that mechanism in place. It's a bit late for such concerns, what with alt, unix-pc, bionet, usrgroup, gnu... >*BUT* if a separate distribution hierarchy is set up (or even if it's not..) >why not create a mechanism to transport binaries AS binaries, rather than >doing hokey ASCIIfication of them? Then sites which compress news can >compress directly off of the binary itself. Obviously, many changes would >have to be made to our current news readers and such; I haven't thought >out exactly HOW to do this. Well then, go to it. Develop an entirely news system that will handle binaries. And then convince ten thousand sites still running 2.10 or 2.11.8 to upgrade. ..b
cranor@udel.EDU (Chuck Cranor) (05/23/88)
In article <1988May22.031701.18412@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >> newsgroups devoted to specific classes of machines should have their >> own top-level newsclasses... > >While I agree that there is some merit to this idea, I really loathe >the idea of YET MORE top-level names. The length of sys-file lines is >already getting ridiculous. >for example, "!comp.binaries" is not much harder than "!bin". Arranging Henry- I think you've missed the point. By putting binaries in thier own top level it requires action to *receive* binary news groups rather than block them. [It also makes them a nice open target to nuke!!] It's a great idea. Also, I think the sys file takes the old "\" trick. (It was added in an update?) Chuck UDel News Admin -- Chuck Cranor University of Delaware PHONE: (302)-451-6660 (UDel), (302)-737-5852 (home) ARPA: cranor@udel.EDU, UUCP: ...!<your_favorite_arpa_gateway>!udel.edu!cranor "I'd like to see John the Baptist's impersonation of Graham Hill." - R.J. Gumby
olsen@XN.LL.MIT.EDU (Jim Olsen) (05/24/88)
In article <2676@louie.udel.EDU> cranor@udel.EDU (Chuck Cranor) writes: >By putting binaries in thier own top level it requires action to >*receive* binary news groups rather than block them. It's a great idea. It's a terrible idea. We should not tinker with the newsgroup hierarchy without good reason. This proposed change will create no new capability, and will not clarify the hierarchy, which is already quite clear. This proposal would benefit only one class of sites: those who don't want binaries, and want comp.*, but don't want to bother excluding comp.binaries. Balanced against this, we have all the sites which *do* want binaries, who will be required to perform otherwise unnecessary changes to their sys files. If this suggestion had come up during the Great Newsgroup Reorganization, it might have been worth considering, since people had to change their sys files anyway. Now that the hierarchy is stable, it is silly to impose a piece of useless make-work on news administrators who are already satisfied with their news configuration.
cranor@udel.EDU (Chuck Cranor) (05/24/88)
In article <1008@xn.LL.MIT.EDU> olsen@ll-xn.UUCP (Jim Olsen) writes: >In article <2676@louie.udel.EDU> cranor@udel.EDU (Chuck Cranor) writes: >>By putting binaries in thier own top level it requires action to >>*receive* binary news groups rather than block them. It's a great idea. >It's a terrible idea. We should not tinker with the newsgroup hierarchy >without good reason. This proposed change will create no new capability, >If this suggestion had come up during the Great Newsgroup Reorganization, >it might have been worth considering, since people had to change their >sys files anyway. Now that the hierarchy is stable, it is silly to >impose a piece of useless make-work on news administrators who are >already satisfied with their news configuration. Ah, but it easy to see [from the number of messages on the net] that a lot of news admins are not real happy about binary newsgroups. I personally think that binary newsgroups should be left to local BBS's and Compuserve type operations. The only reason I carry the groups is because they are part of the "standard" USENET newsgroup structure [and an awkward part of that structure too!]. The proposed change's "new capability" [which you seemed to have missed?] will be moving the binary newsgroups from the "standard" USENET newsgroup structure to an alternate one. That makes them an easy target for removal. People don't end up wasting time, money, and disk space by the default configuration. I don't think that the binary newsgroups would get too far if they were to try and make it on their own. Right now they are just abusing both the regular USENET backbone and the NNTP backbone with their multi-megabytes of binary garbage! [Well, at least the groups are moderated....] I also suggest you consider Rich Salz's comments on the computer virus in a binary newsgroup (message <758@fig.bbn.com>), and also the analysis that Chuq's did a while back on binary groups.... Chuck UDel News Admin -- Chuck Cranor University of Delaware PHONE: (302)-451-6660 (UDel), (302)-737-5852 (home) ARPA: cranor@udel.EDU, UUCP: ...!<your_favorite_arpa_gateway>!udel.edu!cranor "I'd like to see John the Baptist's impersonation of Graham Hill." - R.J. Gumby
matt@oddjob.UChicago.EDU (Not the kind you have to wind up on Sunday) (05/25/88)
In article <1008@xn.LL.MIT.EDU> olsen@ll-xn.UUCP (Jim Olsen) writes:
) This proposal would benefit only one class of sites: those who don't want
) binaries, and want comp.*, but don't want to bother excluding
) comp.binaries.
Not necessarily so. Suppose a significant fraction of the sites that
don't want binaries decide to cease accepting or passing binaries.
How is the rest of the net to know whether the set of sites that does
receive binaries is still connected or not?
Matthenry@utzoo.uucp (Henry Spencer) (05/25/88)
> I think you've missed the point. By putting binaries in thier > own top level it requires action to *receive* binary news groups rather > than block them... I agree. My point is that it has a cost, too. Frankly, the proliferation of top-level names is out of control, and is starting to be a major pain. Every time somebody creates a new newsgroup these days it's got to have its own top-level group, it seems. The converse of the above is that people who *want* to get it have to go out of their way to do so, and often have to start with a complex fishing expedition to try to find a nearby site that carries what they want. > It's a great idea. For those who want to get rid of the binary groups, yes. For those who want to continue carrying them, it's a pain. > Also, I think the sys file takes the old "\" trick. This only addresses the mechanics of sys-file editing; it does nothing for the administrative headaches of 57 top-level groups all coming in by different paths. -- NASA is to spaceflight as | Henry Spencer @ U of Toronto Zoology the Post Office is to mail. | {ihnp4,decvax,uunet!mnetor}!utzoo!henry
skea@cad.jmrc.eecs.unsw.oz (Alan Skea) (05/25/88)
Most complaints about binary groups seem to be based on the fact that sites feel morally obliged to carry them because they are part of USENET and USENET is one big network, there is no alternative (well, there is alt but the binaries arn't in alt). What would solve all the complaints is if each top level group had its own backbone and was a logically seperate network. Then there could be a bin hierarchy or any number of specialised hierarchies and only the people interested in them would have any obligation to carry them. I guess this would need a bit of support in the software though.
david@ms.uky.edu (David Herron -- One of the vertebrae) (05/26/88)
In article <1008@xn.LL.MIT.EDU> olsen@ll-xn.UUCP (Jim Olsen) writes: >In article <2676@louie.udel.EDU> cranor@udel.EDU (Chuck Cranor) writes: >>By putting binaries in thier own top level it requires action to >>*receive* binary news groups rather than block them. It's a great idea. > >It's a terrible idea. We should not tinker with the newsgroup hierarchy >without good reason. This proposed change will create no new capability, >and will not clarify the hierarchy, which is already quite clear. > >This proposal would benefit only one class of sites: those who don't want >binaries, and want comp.*, but don't want to bother excluding >comp.binaries. Balanced against this, we have all the sites which *do* >want binaries, who will be required to perform otherwise unnecessary >changes to their sys files. Agreed that splitting off *only* binaries would be silly. The suggestion for splitting out the comp.sys groups in the same way that unix-pc.all exists is interesting. However it might not work as well as unix-pc did. It was trivial to set up the unix-pc net because they already ran unix and no software had to be developed. It wouldn't be so trivial to put onto peoples' individual machines, but would have to be as it is now on machines at school/work. But then, this is just me talking. Just because I think it wouldn't work as well doesn't mean it won't work... There is probably one good reason for going through a renaming of the comp groups. That is the depths some of them have sunk to ... comp.sys.ibm.pc.d is rather deep -- however well organized it might be. -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- SKA: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- <---- Goodbye RAH.
kevin@perle.UUCP (Kevin Pickard) (05/26/88)
In article <215@chem.ucsd.EDU> jwp@chem.ucsd.edu (John Pierce) writes: >In article <397@pan.UUCP> jw@pan.UUCP (Jamie Watson) writes: > > > > .... putting binaries in their own hierarchy, bin.*, would require specific > > action to *receive* them, rather than to block them.... > >That's an excellent suggestion. I agree, it is an excellent suggestion. It has my vote. Kevin Pickard ...!uunet!mnetor!perle!kevin
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (06/01/88)
In article <3803@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >BTW, does anybody else think it's about time to shake the naming tree >again and create top level binary and source groups with their own >distributions? One could even comtemplate a "data" group for all those >images and whatnot that don't fit into the source/binary dichotomy. In article <22773@bu-cs.BU.EDU> tower@bu-it.bu.edu (Leonard H. Tower Jr.) makes an argument to the effect that all the comp.sys groups should be forced up into their own top-level news group. >If USENET really decides to go through another renaming spasm, we >should let comp be devoted only to issues of general technical >interest. Although I concur with the point that more top-level news hierachies should be created, I don't go as far as Len does, suggesting that they each need their own group. I do agree with his point that comp should be focused more on general technical issues. My fuel for the fire is an observation: There are seven news categories, and yet more than 50% of the articles (considered either by count or by volume) are in a single category, the comp hierarchy. This argues that the current division is not as good as could be hoped. A second observation is that the comp category divides naturally into three approximately-equal subsets: comp.sys groups, comp.{source,binary} groups, and everything else. By this division, comp.{source,binary} has fewer articles but more volume; the other two are about equal. This argues that the logical thing to do is divide comp into three top- level categories. For the sake of discussion, I suggest we call them "comm" for the comp.sys news groups (suggested by someone else; I didn't keep the reference) to suggest commercial systems, "data" for the groups under comp.{source,binaries}, and "newcomp" for the rest. My feeling is that the comm groups should indeed be separated out into their own top-level category; I'm not enamored of the name "comm" but nothing else springs to my mind. I'd be pleased if this category would allow allow news groups where a particular corporate entity was well represented -- the Amiga news group is an example of this. I think it's safe to say that NCR would be interested in something like this. I would be happy either with third-party moderation or first-party moderation with specific constraints to prevent abuse. As for the data groups, I think the best alternative would be for the backbone sites to co-ordinate an archive where the sources/objects/data could be retrieved. I don't mean to imply that each backbone needs to be an archive site itself, but if the San Diego area is a good example of how the rest of the net works, the various "data" groups are already archived at sites within the region; all that the backbone would have to do would be to determine where the file was archived and relay the request to the server who could handle it with the cheapest (by some metric) cost. Then machinery would have to be put in place so that the archives stay current. This should minimize the cost of making source/object(/image/stack/...) files available, as they wouldn't have to be transfered to every site and yet would be quickly (and cheaply) available upon demand. As other people have expounded upon the advantages of archiving, I won't go into that. I recognize that the second proposal is controversial (well, both are, but the second is more so), and it's not reasonable to try to do something that complicated all at once. However, it might be reasonable to try it out on a smaller scale; I would like to see that tried. The existance and popularity of the current archive servers show that it is possible to do (for example, NCR will be experimenting internally with a similar scheme to make tools available to its developers); the problems seem to be ones of scale and co-ordination. -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd