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