Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!ll-xn!ames!lll-tis!helios.ee.lbl.gov!nosc!ncr-sd!greg From: greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) Newsgroups: news.admin Subject: Re: Binary groups need their own hierarchy Message-ID: <2237@ncr-sd.SanDiego.NCR.COM> Date: 1 Jun 88 01:50:13 GMT References: <397@pan.UUCP> <5284@sdcrdcf.UUCP> <22773@bu-cs.BU.EDU> Organization: NCR Corporation, Rancho Bernardo Lines: 68 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