Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!think!ames!ptsfa!hoptoad!academ!killer!elg From: elg@killer.UUCP (Eric Green) Newsgroups: news.misc Subject: Re: USENET anarchy ! - (nf) Message-ID: <1144@killer.UUCP> Date: Fri, 17-Jul-87 03:04:44 EDT Article-I.D.: killer.1144 Posted: Fri Jul 17 03:04:44 1987 Date-Received: Sun, 19-Jul-87 07:10:15 EDT References: <53200001@tub.UUCP> Organization: Bayou Telecommunications Lines: 55 in article <53200001@tub.UUCP>, hex@tub.UUCP says: >> [...], the problem of a >> vocal minority making it appear that an action is unpopular when it really >> isn't,[...]. >> >> I think it's time for the Net to graduate from being an anarchy, to being a >> democracy. >> >> [...] > > DON'T GO THE WAY OF LAW AND ORDER. > DON'T GO THE WAY OF CENTRALISED POWER. > > GO THE WAY OF FREEDOM AND RESPONSABILITY. > GO THE WAY OF LOVE AND UNDERSTANDING. > > > Marcus Verwiebe, Western Germany. As I recall, the West German USENET is centrally controlled, from a central "country backbone" machine... I've given up on the concept of a net.democracy. But only because freedom, responsibility, love, and understanding don't seem to be in large supply. The backbone makes occasional goofups, but at least these guys have their eyes on their wallets instead of on ideology and fascism... unlike some of the net.saviors that have arisen in recent times (who scream everything from strident anarchism to belligerent "freedom to say anything I want at your expense"). However, I do believe that there is a place for a volunteer Network Flow Enhancement group, because out here in the boonies, it takes almost two weeks for news to travel from the Backbone to here.... the general problem seems to be that the network is strung out into a long linked list at its far edges, instead of as a tree with (possibly) interconnects. The solution is simple -- instead of "foo" calling "bar", have "foo" call "bar"'s news source. Another problem is local machines overloading the local "rib-bone"... for example, a machine pretty near capacity because of the large number of local systems calling it. So what you end up with is that the local systems get their news in a timely fashion, but network flow as a whole suffers, because of the lack of connectivity. The answer, of course, is for you, the local rib site, to require that each local system getting their news from you in turn feeds other local systems, and then using the freed capacity to improve connectivity (by having sites fed by a LD newsfeed, call you directly, and other such things). Finally, there's a heck of a problem with just getting a newsfeed! Some sort of centralized network flow center could maintain a database of what machine feeds which, and thus be able to help the new machine find its proper place in the heirarchy. Since this would merely be a database project, and would not be mandatory control of any sort, I think that it would be fairly palatable. The other problem would be collecting the data. Perhaps the news system could help out there, in a later revision of the news system.... ERic Green {ihnp4,cbosgd}!killer!elg, elg@usl.CSNET