|
|
|
|
|
|
|
|
NetMonth, August 1986
* * * * *
** * ** ** *
* * * * * * * * * * *
* * * *** ***** * * * *** **** ***** ****
* * * * * * * * * * * * * * *
* * * ***** * * * * * * * * * *
* ** * * * * * * * * * * *
* * **** * * * *** * * * * *
* *
* A monthly guide to BITNET servers and services *
*******************************************************
Volume 1 Number 2 - August 1986
Editor: Chris Condon BITLIB@YALEVMX
* Contents *
Bitnotes ............................................ 1
Instant Insanity by Jeff Kell ....................... 3
Relay Growth ........................................ 6
New Mailing Lists ................................... 7
The VAX Toolbox ..................................... 7
/Links .............................................. 8
The NETSERV User Directory Services ................. 8
New List Servers ................................... 10
Spotlight Server: UTCSERVE@UTCVM ................... 12
Feedback ........................................... 13
Policies ........................................... 14
__________________________________________
/ /[
/__________________________________________[/
]
] ___________________________________
] ] ] /[
] ] ]_______________________________[/
] ] /
] ]/__________________________________
] /[
]__________________________________________[/
A complete list of servers and services is available
from any NETSERV file server as the file named BITNET
SERVERS. News, article submissions, additions to the
list of servers and services, subscription requests and
letters to the editor should be sent to BITLIB@YALEVMX.
Subscribers are also sent BITNET SERVERS updates.
Printing this file: VM users can print this magazine
by first copying or renaming it to NETMONTH LISTING and
then printing it with your local file printing command.
-------------------------------------------------------
FuzzyBytes Electronic Publishing "Because We're Here."
1
Page 1
*************************************************************************
* Bitnotes Issue 2 *
***************************************************************************
"Never underestimate the power of human stupiditiy."
- Robert A. Heinlein
Ignorance is bliss, or so they say. That may not be applicable to BITNET,
for here ignorance usually spells Trouble (yes, with a capital 'T').
Ignorance may be as harmless as not knowing how to use a file server or
as harmful as requesting 125 files from a file server within the course
of three minutes. Certainly, this is not bliss. Not for the poor guy who
doesn't know what is going on, or for the person wondering why it is
taking so long for those 125 files to arrive.
Discipline begins at home, or so they say. Likewise, education on how to
use BITNET servers and services begins at the home node. I have gotten
some mail about this, requests for tips and information. And while I am
not a node administrator by any means, I might be able to get away with
listing these suggestions.
1. When in doubt, don't.
Allegedly common sense will tell you it will require a lot more effort
to fix something you have done wrong than it will to do it right in the
first place. If you don't understand how to use a server or service,
ask somebody who does, or refer to the local documentation. Which leads
to:
2. Keep documetation on how to use the servers and services at your node.
Keep it in a really obvious place too, and update it frequently. One
helpfile about CSNEWS on a public disk is a lot safer than ten users
with copies of their own (and a lot more efficient to boot!). Store
some explanations on what each type of server does (i.e What is a file
server? What does it do? How do you use it?) You might even go as far
as printing a local BITNET users guide (although it would have to be
pretty general with the way things change).
3. Have a BITNET user consultant at your node.
There is not much sense in the blind leading the blind, so this is
particularly helpful. You might want to make this person responsible
for keeping the documentation updated.
4. Develop some usage guidelines, and stick to them.
Yes, there may be some bad apples at your node. Have some sort of policy
to deal with these people. On the other hand, some people just don't
know any better, so post some guidelines on what is acceptable and what
isn't. You'd be surprised what some may do unless you tell them they
shouldn't. I think (my opinion only) that a policy that deals with
individual abuses will have a greater affect on those-who-would-be-bad.
1
Page 2
Fine. Those are all wonderful suggestions on how to prevent yourelf and
others from doing something wrong. A more positive approach might be to
list some things you can do RIGHT. From this end of the picture it seems
that one of the rightest things you can do is offer services to the BITNET
community.
This doesn't mean that you have to run a file server or produce an
electronic magazine. Perhaps you don't have the time or resources for that
sort of thing. That doesn't mean you can't do something with a slightly
lower profile. Some suggestions for students and administrators alike:
1. Form a local BITNET user's group. It doesn't have to be large to be
effective (although it probobly helps). Not only can you promote
the responsible use of the network, it makes good resume material, too!
2. Write an article for one of the electronic magazines.
You must have some thoughts about what is happening in BITNET. If ONE
user at each node wrote ONE article in ONE year there would be enough
material to make the monthlies go weekly. Why not be that one and give
it a try?
For those of you who might want to take on the responsibilbity of offering
a full scale service, like a file server or mailing list, here are
some considerations to take into account before you get in too deep. Try to
approach it as if you were running a business, where your service is the
product that you want to sell:
1. Is there a need for this service?
Example: If Joe Dokes is already running a file server for people who
are interested in Chemistry, is there a need for a second one? Or maybe
there is a server like that but you think you could do a better job.
2. Are there enough people interested in what you want to do?
Example: If you want to run a mailing list for people concerned about
the social implications of knitting, make sure there are enough people
interested in that sort of thing.
3. Do you have the resources to produce this service?
Remeber, time is your most valuable resource. Do you have enough of it?
If you want to produce a weekly electronic magazine, do you think you
can really put one out regularly? Or will you slack off after three
weeks? And what will happen to the magazine when you leave the network?
4. Does your SYSTEM have the resources to produce this service?
If your system has a lot of people using mega-cpu maybe running a
file server there isn't such a good idea.
1
Page 3
In this issue we have, to put it lightly, a lot of good stuff. First off,
we have an article written by the author of Relay, Jeff Kell. It sheds
some light on the directions Relay is taking, as well as answering some
prickly and not-so-pricky questions. As a companion to that, I drew up a
chart showing the Relay growth in the past year...
DON'T PANIC! I have included a lot of non-Relay articles, too. There are
plenty of new mailing lists, list servers, and user databases. In addtion,
the Feedback column makes it's first appearance in it's soon-to-be
traditional spot on the last page.
Meanwhile, I have made a few obvious cosmetic changes to NetMonth, as well
as a feeble attempt to insert some page breaks. Who has the time to SCRIPT?
Off we go...
*************************************************************************
* Instant Insanity - by Jeff Kell JEFF@UTCVM *
***************************************************************************
Instant Insanity -or- Why I Should Have Anonymously Written Relay :-)
Several years ago, I discovered 'chat' machines. Ahhh, the old days of
Billy, Missing Link, LateHack and EarlyHack, Castle, WorldNet, etc.
And shortly thereafter, about February 1985 I seem to recall, Henry
Nussbacher's infamous paper concerning the dangers of chat machines to
the network was circulated to contacts, managers, and administrators of
practically every site in the network. And boom, the party was over, or at
least rather well pooped.
There were many valid points to the paper. There are dangers to the old
centralized chats. If you don't understand them, you can read about it
in RELAY INFO (the /info command) or elsewhere, I don't want to repeat
them again here. The bottom line remained: centralized chats were bad
business. Management in general (contacts, administrators, technical
people) developed a bad taste for "chatting", and most of it was put to
a halt. Others went underground, and when discovered and exposed, only
served to increase management distaste for the whole concept.
I began working on Relay around March of 1985, and sometime thereafter a
Relay here at UTCVM (Version 0.03 or so) successfully linked to a Relay
at YALEVM and the distributed Relay system was born. Growth was slow,
as the last thing management wanted to hear about was another "chat",
and it was hard to be granted a brief hearing, let alone get volunteers
for beta testing. Add to this the problems of testing and debugging a
program of this size spread out across three continents, and it was not
a pretty picture; but eventually things began to stabilize.
The biggest "boost" to Relay came when some management switched over to
1
Page 4
our side, although granted with considerable caution. When Relay was
being considered for becoming "official" at Yale, Jim Owen and Phillip
Long sent me a list of their concerns to insure that Relay would not be
recreating the same problems the older chats had. Thus the first set of
statistics, limitations, and restrictions were imposed in an effort to
make Relay "legitimate".
Currently, several members of the Bitnet Executive Committee are directly
involved with Relay. The committee as a whole has discussed Relay more
than once and it is still currently under study; although we have done
a great deal to improve the technical aspects of Relay in terms of the
network load and CPU requirements, there is still a large concern that
Relay serves no "practical" purpose. Admittedly, it is hard to make a
point in my favor when you have management issuing a "/who" to Relay and
finding users like "SuperStud", "NeedSex", and "Cuddles".
Management complains that Relay is not restrictive enough. Users say that
Relay is too restrictive. And guess who *receives* the complaints?
We are currently drafting a "Usage Guidelines" statement for Relay to be
presented to the Executive Committee. It *may* pass, in which case we
will be accepted once and for all. If it does, you *may* not like what
it contains; it is more restrictive than we currently are enforcing.
But it will be a final word, and hopefully final peace.
The new policy calls for such things as:
* Restricting public users (as it is now) to channels 0-9 and still
enforce service areas, quiesced periods, limits, etc.
* Creating a "full access" user class which can only be granted by
the host Relay's master operator. This class of user can use any
channel at any time, but *only* for *practical* purposes, ie., for
real conferencing and not recreation.
I personally think it is a bit harsh; I'm not out to "get" anyone. But
it would be of enormous value to have the Relay program finally reach
a "legitimate" status. Please don't rush off to mail your flames too
early either; remember it is precisely what Relay has shown itself to
be that brought this on in the first place. For example, in answer to
the numerous complaints I have had in various areas:
* "Why can't I use the BLAHBLAH Relay instead of the one I'm supposed
to use if I want to?"
Relay is supposed to REDUCE network traffic. If you use a Relay
that is farther away, you will only INCREASE traffic. Since users
would not do this on their own for whatever reason, Relay enforces
this now.
* "I was warned/banned about scanning channels; what's wrong with that?"
Private channels are just that -- private. You can /msg the user and
ask to b e invited, but you don't just drop in. In addition, it takes
a certain amount of overhead to process the channel change and migrate
that change to the other relays.
1
Page 5
* "Why am I supposed to sign up with my real name?"
If you aren't honest enough to use your real name, or at least use a
name that looks real, what kind of practical/legitimate use are we
supposed to expect from you? Relay does not have to be stone serious
all the time, but that is stretching things a bit.
* "My Relay is quiesced, why can't I use another one?"
Relays are quiesced to reduce network load during prime time. The
original Executive Committee request was to quiesce ALL Relays from
8:00 AM until 6:00 PM; but thus far only the central Relays in high
traffic areas are quiescing at all. Granted, when Bitnic is in its
quiesced state, Europe is cut off from the states, and the CUNYVM
side separated from the PSUVM side; but if you use a Relay on the
other side of the quiesced one, your messages will pass through the
node or link in question, generating precisely the load that the
quiesce was trying to prevent.
The list goes on, but these are the most frequent. I also get them from
the other side of the fence:
* "Why is this
|