informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/bbs/FIDONET/FIDONEWS/fido1609.nws

1527 lines
65 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

F I D O N E W S Volume 16, Number 09 01 March 1999
+----------------------------+---------------------------------------+
| The newsletter of the | ISSN 1198-4589 Published by: |
| FidoNet community | "FidoNews" |
| _ | +27-41-581-5913 [5:5/23] |
| / \ | |
| /|oo \ | |
| (_| /_) | |
| _`@/_ \ _ | |
| | | \ \\ | Editor: |
| | (*) | \ )) | Henk Wolsink 5:7104/2 |
| |__U__| / \// | |
| _//|| _\ / | |
| (_/(_|(____/ | |
| (jm) | Newspapers should have no friends. |
| | -- JOSEPH PULITZER |
+----------------------------+---------------------------------------+
| Submission address: FidoNews Editor 5:5/23 |
+--------------------------------------------------------------------+
| MORE addresses: |
| |
| submissions=> editor@fidonews.org |
| hwolsink@catpe.alt.za |
+--------------------------------------------------------------------+
| For information, copyrights, article submissions, |
| obtaining copies of FidoNews or the internet gateway FAQ |
| please refer to the end of this file. |
+--------------------------------------------------------------------+
Table of Contents
1. EDITORIAL ................................................ 1
2. GUEST EDITORIAL .......................................... 2
Announcing Candidacy for Z1C... maybe .................... 2
What's Not Happening - Elections ......................... 2
3. LETTERS TO THE EDITOR .................................... 5
SPAM-lite in FidoNews? Ptooie! .......................... 5
4. ARTICLES ................................................. 6
Grunged Echomail Deleted (a Response) .................... 6
Letter from a concerned reader? .......................... 6
The Shrinking Nodelist - What can be done? ............... 7
Zone 1 Backbone Service Level Agreement .................. 8
5. COLUMNS .................................................. 20
ECHO TALK - Monkey Business .............................. 20
6. NOTICES .................................................. 21
7. FIDONET BY INTERNET ...................................... 22
8. FIDONEWS INFORMATION ..................................... 26
FIDONEWS 16-09 Page 1 1 Mar 1999
=================================================================
EDITORIAL
=================================================================
Greetings,
On my question in the 16-07 issue about Z2 and in particular R29,
I received a very interesting e-mail from a SysOp there.
It seems, that the Z2C just wants to show how big or is it small,
he can be. What a great pity. As the saying goes: it takes all
kinds to make the world go round. ;-)
Since I do have the full message and the authors name here on file,
he has given permission to use it.
Some interesting articles this week. From a message I saw, Bob
Satti has decided not stand for another term as Z1C. Thats the
spirit Bob, one should not have two *C positions as far as I'm
concerned. ;-)
Happy reading,
-----------------------------------------------------------------
FIDONEWS 16-09 Page 2 1 Mar 1999
=================================================================
GUEST EDITORIAL
=================================================================
I'm not sure why I'm doing this... you'd think I'd learn. Last year
I announced a candidacy for the Z1EC election, only to find that the
election I'd expected never happened. Things are different this
year, though. In announcing for the Z1C sysop-level election, I'm
not expecting it to be held. In fact, there's been no hint from the
Zone 1 RC's, who are empowered by policy to elect a Zone
Coordinator, that there are any plans afoot, let alone a sysop-level
election. I'm interpreting the silence from the RC's as an
indication that Bob Satti will receive a vote of confidence, as
happened last year, and this will serve as an election for an
additional two-year term.
So why run for an office when I don't expect an open election?
Mostly because I believe that there should be one. There are at
least two good reasons for this:
1. Fidonet sysops have expressed a consistent desire that
representative positions be determined by sysop-level election
rather than by the appointments specified in Policy 4. It's become
fairly common practice at the NC level and a growing number of RC's
are elected... but not the ZC.
2. Bob Satti currently holds the simultaneous positions of Zone
Coordinator for Zone 1 and International Coordinator for all of
Fidonet. One of these positions is more than enough for one man -
it's time to let go.
Whether there is an open election or not, I intend to start acting
like a candidate. Currently I plan to discuss two issues which I
consider core to the ZC position - the shrinking nodelist and the
subject of elections. Following those discussions, I'll try to
follow up on whatever feedback comes from echomail and netmail.
One outcome I'd like to see from this announcement is the
encouragement of other candidates to announce so we can get a real
forum going. Perhaps Bob Satti will even join us. I'd especially
like to see the sysops of Fidonet actually conduct an open election
themselves rather than waiting for the RC's to make a decision.
Such an election would not be binding on the RC's of course, but
would effectively communicate to them the expectations of the
sysops. Hopefully the RC's would realize that this is a healthy
process, and seriously consider it.
-----------------------------------------------------------------
What's Not Happening - Elections
.-- -- -- -- -- -- WHAT'S NOT HAPPENING -- -- -- -- -- --.
| There isn't always something happening on Fidonet, but |
| there's always something which isn't happening. This |
FIDONEWS 16-09 Page 3 1 Mar 1999
| column is dedicated to the lost causes which make Fido |
| what it isn't today. Published semi-occasionally... |
`-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --'
Douglas Myers 1:279/720 doug@mdtnbbs.com
Perennial sport in the Fido echoes is the roasting of non-elected
coordinators. Currently, Martin Belcke (Regional Coordinator of
Region 11) is the recipient of the honors, but he shares the
limelight on a rotating basis with Dallas Hinton (RC17) and Bob
Satti (Zone 1 Coordinator and International Coordinator), with
occasional guest appearances by other notables.
In all fairness, the criticism doesn't center on Martin's
performance as RC. Indications are that he does a good job in that
capacity, and probably enjoys widespread support in his own region.
The criticism centers on a deep-seated conviction on the part of
many that representative positions in Fido should be determined by
regularly-scheduled, public elections. Unfortunately, Fido policy
doesn't actually require elections - all coordinator positions are
appointments by policy. However, it's become customary for a
substantial number of these positions to hold public, sysop-level
elections with the elected candidate then appointed per policy, and
proponents of elections want that practice uniformly applied.
Election advocates make several claims to support their wishes:
1. Elections, if uniformly applied, would revitalize Fidonet.
This seems highly doubtful to me, as the main reason for
Fido's shrinking nodelist seems to be the simple fact that
computer enthusiasts have found the Internet more attractive
than local BBSes.
2. Elections yield better leaders.
This is unsupported, and I doubt that it can be
demonstrated. However, I believe regularly-scheduled
elections encourage some minimum of responsiveness from
representatives, or - at least - provide a means for their
removal at the next election if unsatisfactory.
3. Elections "validate" a coordinator.
This seems to be the strongest argument for elections to
me. No matter how controversial the election, most folks
recognize a voting process as valid.
Martin and his supporters offer several reasons to decline holding
an election:
1. Sysops in the region have indicated that they don't want an
election - to hold one would act against the wishes of the majority.
FIDONEWS 16-09 Page 4 1 Mar 1999
There does seem to be some validity to the claim that sysops
in the region are generally satisfied with their present
representation, or - at least - aren't in open revolt.
Unfortunately, the basis for that claim isn't solid.
Surveys have been conducted by both proponents and opponents
of elections with, supposedly, conflicting results.
I suspect that sysops in the region have no desire to elect
another candidate, but are not necessarily opposed to
holding elections. It's hard for me to see how an actual
election would be any more of an imposition than all the
surveys.
2. Elections are a messy procedure, leading to vocal conflict and
general disharmony.
If they're done right, this is true. However, what's the
alternative? Morphine injections?
3. Elections don't necessarily lead to agreement; those who
supported a candidate before still support him, those who didn't
still don't, and those who didn't care still don't.
It's certain that the arguments still go on after an
election, often with charges of election irregularities.
Still, most folks eventually concede that the fellow who got
the most votes should represent.
My prediction is that sysop-level elections for Regions 11 and 17
and for the Z1C position won't happen in the near future... but they
should. Not because Fido will somehow be revitalized with
elections, not because the unelected coordinators have done a poor
job, but simply because Fido should be in the hands of the sysops
who are members.
-----------------------------------------------------------------
FIDONEWS 16-09 Page 5 1 Mar 1999
=================================================================
LETTERS TO THE EDITOR
=================================================================
SPAM-lite in FidoNews?
Dear Editor:
It was with growing dismay that I read the two-page press release
from Fast Engines, Inc. embedded in FIDO1606.NWS, touting their
new web server utility. What made it worse was that it was the
longest "article" in the Snooze -- although that is not the point.
I'm really very disappointed.
I didn't like the idea when you announced in FIDO1547.NWS that you
would allow ads that related to "BBSs and/or Fidonet", but I assumed
that you meant it would be limited to commerical products applicable
to the majority of FidoNet.
I assumed wrongly, it seems. Since the simple majority of us still
run POTS dial-up BBSi and don't run web servers, Fast Engine's
product has no utility for us. In fact, it amounts to SPAM-lite, if
you will --a little less salty but it still gets piped directly to
an audience that didn't solicit the ad, can't use the product, don't
want it and still must pay to haul and store it.
I note that several to the Snooze Editor on this subject were
published in 1998 (Gary Petersen, Dave Garland in FIDO1523, Doc
Logger in FIDO1547) and that all of them were objections. When
Zorch raised the question FIDO1522, he appeared to have qualms about
the appropriateness of commerical ads. Since the readership has
commented that it doesn't want commerical ads, I ask that you revise
your stand and cease publishing them.
If I'm hungry for highly processed stuff in a brightly colored
package, I'll seek it out on my own.
Lee Ayrton 1:320/455
dayrton@mail.welseyan.edu
ED: The editor has the right to publish what he/she thinks is
appropriate for the newsletter.
I have made it quite clear in the FIDONEWS echo, that I will
allow advertising, provided it relates to computers and/or
communication(s).
No one editor, regardless for which or what publication it might
be, has the same oppinion about what should or not be placed
in the their newsletter, magazine or newspaper.
Your objection has been noted and I appriciate feedback. Thanks.
-----------------------------------------------------------------
FIDONEWS 16-09 Page 6 1 Mar 1999
=================================================================
ARTICLES
=================================================================
Grunged Echomail Deleted (a Response)
by Jerry Schwartz 1:142/928
A couple of weeks ago, Roy Tellason asked about the
appropriateness of suppressing long (30kb) messages from the
echomail distribution system. While I'm no expert in this
matter, I can address his question about whether or not people
are running software which needs to be protected from messages of
this size. Not long ago, I posted a series of messages which
were in the 16k range (approximately). I checked to make sure
they weren't much bigger than that, but I didn't check their size
exactly.
I should have been more careful, I guess: one or another of those
messages prevented my uplink from tossing the entire bundle!
Again, I can't say what the limit is but I was certainly
surprised that an OS/2 system running Squish would have problems
with anything I, running the DOS version of Squish, could
generate.
So the answer is "Yes." Anyone posting messages in the 16kb+
range is creating a technical problem. As a technical solution,
I'd certainly prefer to see messages split, rather than bounced
or deleted, but I'm not in charge around here.
-----------------------------------------------------------------
Letter from a concerned reader?
(Henk, you may use this in FidoNews or not, as you wish. I am
posting it here only because this is the closest thing to an
administrative echo that is available to non-members.)
I have been a Fidonet user since 1995, and have seen a bit of the
discussion (and I use that word loosely) concerning administrative
and policy matters of all sorts. I have observed (and
occasionally taken part in) arguments over everything from the
validity of Policy 4.07 and the need for an Echo Policy to the
multiplicity of backbones and the effectiveness or
ineffectiveness of certain hat-wearers.
Although I wasn't around at the time, I understand all these
counterproductive arguments are due to Fidonet's departure from
the ideals and goals set by its founder, Tom Jennings. in fact,
if what I have read is true, it was this very sort of
in-fighting that led Mr. Jennings to leave Fidonet.
Here is my revolutionary suggestion: Let us beseech Tom Jennings
to return to Fidonet as a sort of one-man "supreme court" with
the authority to arbitrarily overturn any existing policy and any
FIDONEWS 16-09 Page 7 1 Mar 1999
actions (or inactions) taken by officials at any level of Fidonet,
with such authority limited to a period of, say, two years. While
the power of such a position may not appeal to Mr. Jennings,
perhaps the opportunity to put fidonet back on track would be
sufficient to bring him out of his self-imposed retirement.
Just imagine the possibilities. At last we would know if Policy
4.07 actually serves the best interests of Fidonet as seen by its
"founding father". We'd know for certain if ZCs must come from
within the ranks of RCs, or if any sysop is eligible to run for
the post. We'd even have someone with the authority to find out,
once and for all, if Zorch Frezburg and Mark Hernandez are the
same person!
Please consider my suggestion carefully and seriously. Discuss
it among yourselves. Fidonet membes, feel free to kick the idea
around in your admin echoes. No one knows how Fidonet should be
better than Tom Jennings, and it would be nice to have a
"benevolent dictator" whose only interest was the good of Fidonet
itself. Of course, actually getting Mr. Jennings to take such a
job might be difficult, and getting him to stay with it for two
full years without getting disgusted and leaving again may be
well-night impossible; but we'll never know unless we try.
Walter, wluffman@usit.net
ED: Walter, I do not know the reason why Tom has left FidoNet,
but what you are 'saying' has merit. ;-)
-----------------------------------------------------------------
The Shrinking Nodelist - What can be done?
Douglas Myers, 1:270/720, doug@mdtnbbs.com
In this article, I'm discussing one of the issues I feel is
pertinent to the Z1C election. In a separate article, I've
announced my candidacy for this position; please note, however, that
there's been no indication from the RC's that there will be an open
election, so I may simply be talking through a non-existent "hat."
Fidonet is losing nodes, particularly in Zone 1. The evidence is
clear, in that each week I compile a smaller nodelist. This
shrinking nodelist has been blamed on all sorts of things:
excessive fighting in the echoes, lack of democratic elections
throughout Fido, inaction by the Zone Coordinator and Regional
Coordinators...
While I would certainly like to see a friendlier atmosphere in the
echoes... while I support the concept of sysop-level elections...
and while there are some areas I'd like to see the ZC and RC's
address... I don't think any of the above actions would reverse the
trend of the shrinking nodelist. Sysops are simply taking down
their BBSes because computer owners have chosen to connect to the
world through the Internet instead.
FIDONEWS 16-09 Page 8 1 Mar 1999
This is not necessarily bad news - the same internet technology
which has attracted the general public away from Fido has also given
us the means to maintain low-cost connections despite a smaller
number of nodes. We can live with a smaller nodelist, and still
have a viable and quality network.
This doesn't mean we have to be passive and let Fido be swallowed by
the Internet, but it does mean that we need to stop using the size
of the nodelist as the sole indicator of the health of Fido. The
health of Fido is best indicated by how we, the hobbyists, enjoy the
hobby. If we maintain Fido in a state that we, the sysops, enjoy...
then the job of inviting guests to join us will be all that much
easier.
The work has already begun - many individuals and teams have chosen
to do something positive about the changing nature of Fidonet. Mail
has long been transferred over the Internet, reducing costs and
improving availability. The nodelist format has been positively
altered to facilitate the integration of nodes operating strictly
from the Internet. Enterprising sysops have offered QWK packets and
Blue Wave packets to individuals through internet email attachments,
effectively allowing individuals to function as users of their BBS
without the necessity of logging on... and providing a low-cost
alternative to the telenetable BBS. At least one net has
established an information package for internet users, offering
instructions for using the commonly-available windows terminal
program to log onto a local BBS. All these efforts should be
encouraged and expanded where possible.
The shrinking nodelist isn't the death of Fidonet. If we make Fido
the kind of place where we want to be, folks will join us.
-----------------------------------------------------------------
Zone 1 Backbone Service Level Agreement
by The Members of the Zone 1 Backbone
=====================================
== Zone 1 Backbone ==
== Service Level Agreement ==
=====================================
SLA_9903.Z1B - Mar 99
=========================
Table of Contents
===================
1.0 Introduction
1.1 Purpose of this Document
1.2 Definitions
1.3 Service Level Agreement
1.4 Z1B Relationship to FidoNet
FIDONEWS 16-09 Page 9 1 Mar 1999
1.5 Changes to this Document
2.0 Z1B Administration
2.1 Voting
2.2 Selection of Z1B Hubs
2.3 Selection of the Z1BC
2.4 Administrative Areas
3.0 Moderators
3.1 Moderator Identification
3.2 Moderator Responsibilities
3.3 Moderator Tools
3.4 Echo Addition
3.5 Echo Removal
3.6 Echo Name Change
4.0 Standard Operating Procedures
4.1 Technical Standards
4.2 Gateways
4.3 Encrypted Messages
4.4 Encoded Files in Echoes
4.5 Illegal Activities
4.6 Censorship of Messages
4.7 Anonymous Remailers
4.8 Emergency Plans
(Items noted by the "|" are changes from the previous version.)
1.0 Introduction
===================
1.1 Purpose of this Document
-------------------------------
This Service Level Agreement has been assembled as a means to provide
information about the Zone 1 Backbone, how it operates, what it
offers, what it expects in return, and to provide insight as to its
internal administration.
This document is updated as circumstances and practices change.
Please ensure that you are referencing a current edition.
1.2 Definitions
------------------
Zone 1 Backbone - A group of volunteer FidoNet hubs who help
distribute echomail and routed netmail in FidoNet Zone 1
(North America). The structure is customarily recognized as a
set of tiers with the intention of distributing echomail in an
accurate and expeditious manner. Hereafter in this document
the Zone 1 Backbone is referred to simply as the Z1B.
Echo or Conference - An echomail conference is a message base or
forum, distributed under a specified echomail conference name
or tag, dealing with a defined area of interest. Hereafter in
FIDONEWS 16-09 Page 10 1 Mar 1999
this document echomail conferences are referred to simply as
echoes.
Zone 1 Backbone Hub - A hub who helps to distribute mail within the
Zone 1 Backbone. Tier 1 Z1B Hubs, also known as ZHubs or
Stars, distribute mail at the zone level. They are fully
meshed with each other for speed and reliability. Tier 2 Z1B
Hubs, also known as RHubs, distribute mail at the region
level. Tier 3 Z1B Hubs distribute mail at the net level.
Zone 1 Backbone Coordinator (Z1BC) - Person responsible for the
day-to-day operation of the Zone 1 Backbone. He coordinates
routing to ensure reliable and efficient transport of echomail
and Z1B-routed netmail while avoiding creation of duplicate
messages. He also serves as liaison to the ZEC and to other
distribution systems.
Echomail Coordinators (ECs) - Echomail Coordinators have been
recognized by Fidonet since 1987. The Zone Echomail
Coordinator (ZEC) functions at the zone level. Region
Echomail Coordinators (RECs) function at the region level.
Net Echomail Coordinators (NECs) function at the net level.
BACKBONE.Z1B - A text file listing all echoes, and their descriptions,
which are presently distributed by the Zone 1 Backbone. This
text file is formatted in a manner which makes it easily
readable by echomail distribution software to use as a
"forward list". It is published weekly by the Z1BC and
distributed in the BACKBONE file area.
BACKSTAT.Z1B - A text file containing the Zone 1 Backbone status
report which, among other things, itemizes echoes which are in
the process of being added to or dropped from the Zone 1
Backbone, as well as listing the Tier 1 and 2 Z1B Hubs, and
the Z1BC. It is published weekly by the Z1BC and distributed
in the BACKBONE file area. It is advisable that those who
rely on the Zone 1 Backbone get in the habit of reading this
file.
SLA_xxxx.Z1B (xxxx = yymm version) - This document. It is published
monthly by the Z1BC and distributed in the BACKBONE file area.
Moderator - Person(s) responsible for an echo and its liaison with the
Zone 1 Backbone.
EchoList - A database containing a list of echoes, published monthly
by the EchoList Coordinator (1:1/21). It customarily contains
echo names, moderator names and addresses, and descriptions of
the echoes.
Gateways - Echomail Gateways are nodes whose systems are used to
exchange mail with other groups. The term Gateway, as used
here, includes all forms of gating including, but not limited
to, FidoNet zone gating, inter-distribution system gating,
inter-network gating, and domain gating.
FIDONEWS 16-09 Page 11 1 Mar 1999
1.3 Service Level Agreement
------------------------------
The members of the Z1B agree to distribute mail in the most accurate
and expeditious manner possible within their means. Although they
agree to provide the best service possible, they do not have control
over all of the factors thus some problems might occur occasionally.
Netmail messages which are time critical or require sensitive handling
should be sent direct.
The Tier 1 and 2 Z1B Hubs agree to make available all echoes which
are listed in BACKBONE.Z1B. Tier 3 Z1B Hubs are not obligated to
distribute all listed echoes. In no case does any Z1B Hub agree to
distribute any echo which, in their own opinion, could subject them to
consequences which might have a negative effect on their well being.
The Z1B encourages the use of "echo-path routed netmail" (ERN) as a
means of keeping echo volume and off-topic posts at a reasonable
level. Z1B Hubs agree to accept routed netmail from any node who
connects with them. Any netmail message with a deliverable destination
within FidoNet, regardless of its origin, is accepted.
The Z1B Hubs agree to route ERN according to the wishes of the
individual nets. The Z1B Hubs depend on regional routing maps
provided by the RECs to represent these wishes. The Z1B encourages
all nets to list every ERN connection path to the nearest Tier 1 (zone
level) Hub, regardless of distribution system, in their region's
chart. This will allow ERN to follow the best path available. When
these paths are not known or are not available, Z1B Hubs agree to
route ERN along echomail paths or to a ZC, RC, or NC who has agreed to
handle such mail.
The Z1B Hubs agree that ERN is for personal messages. It is not for
commercial messages, echoes, tunneling, mailing lists, news groups,
file-attaches, "encoded" files, pyramid letters, or chain letters.
Thus, the Z1B Hubs do not agree to route such messages.
The Z1B Hubs agree to treat all in-transit netmail as private mail.
The Z1B Hubs agree to not read or disclose routed netmail which passes
through their systems, except as required for technical or legal
reasons.
The Z1B consists of volunteers. It does not agree to handle any echo
which could take the fun out of the hobby. Use of Z1B services should
be viewed as a privilege, not a right. Any or all of these services
may be terminated at any time, without any prior notice.
All Z1B Hubs agree to the terms of this document.
1.4 Z1B Relationship to FidoNet
----------------------------------
The Z1B is indeed part of FidoNet. It's made up of a voluntary group
of FidoNet members. It exists within FidoNet and must abide by
FidoNet Policy, just as any other FidoNet node or group of FidoNet
FIDONEWS 16-09 Page 12 1 Mar 1999
nodes.
However, the Z1B is not an entity or sub-division of FidoNet in the
sense that it is not mandated or defined by FidoNet Policy and is not
operated by FidoNet officials.
There is no requirement for the Z1B to offer services and there is no
requirement for anyone to use the Z1B's services.
This document is not a part of FidoNet Policy. Should any part of
this document conflict with FidoNet Policy, then FidoNet Policy shall
prevail.
1.5 Changes to this Document
-------------------------------
This document is changed only as the result of a two-thirds vote.
Anyone may propose a change by finding a Tier 1 or 2 Z1B Hub who is
willing to sponsor it for them.
2.0 Z1B Administration
=========================
2.1 Voting
-------------
Tier 1 and 2 Z1B Hubs, as listed in BACKSTAT.Z1B, get 1 vote each.
Nobody else may vote. All voting is by public ballot in the Z1B_Coord
echo. The standard voting period is 1 week.
Unless specified otherwise, a majority vote (more than half of those
voting) is the norm. Certain decisions, as noted, require a
two-thirds vote (at least two-thirds of those voting).
A recall vote can not be held until at least 4 months has elapsed
since the prior selection or recall vote for the person holding that
position.
2.2 Selection of Z1B Hubs
----------------------------
Tier 1 Z1B Hubs are selected by a majority vote. They are normally
chosen from amongst the Tier 2 Z1B Hubs. They serve an indefinite
term but are subject to recall by a two-thirds vote.
Tier 2 Z1B Hubs are selected by a majority vote. Anyone may apply by
finding a Tier 1 or 2 Z1B Hub who is willing to nominate them. The
applicant should connect to either a Tier 1 or 2 Z1B Hub and route
netmail and/or echomail for at least a few nets other than their own.
They serve an indefinite term but are subject to recall by a
two-thirds vote.
FIDONEWS 16-09 Page 13 1 Mar 1999
Tier 3 Z1B Hub selection is left up to the individual nets.
2.3 Selection of the Z1BC
----------------------------
The Z1BC is selected by a majority vote. Anyone may apply by finding
a Tier 1 or 2 Z1B Hub who is willing to nominate them. He serves a 1
year term but is subject to recall by a two-thirds vote.
Note: The term of the current Z1BC expires on April 1, 1999.
2.4 Administrative Areas
---------------------------
The Z1B uses two echoes of its own and two shared file areas to
conduct its business.
The Z1BACKBONE echo is open to any node having business with the Z1B.
The moderator for this area is selected by a majority vote. He serves
an indefinite term but is subject to recall by a two-thirds vote.
The Z1B_COORD echo is restricted to Tier 1 and 2 Z1B Hubs, the Z1BC,
and invited guests. Guests are invited by a majority vote. The
moderator for this area is the Z1BC.
The Z1B also makes use of the shared BACKBONE and Z1_REC file areas.
3.0 Moderators
=================
3.1 Moderator Identification
-------------------------------
The Z1B refers to the current EchoList in order to identify an echo's
moderator. As far as the Z1B is concerned, all individuals listed as
moderators or co-moderators of a particular echo are equal. In case
of disagreement, however, the moderator listed first has priority.
Moderators are encouraged to appoint co-moderators to assist them in
their duties and to stand in for them in their absence. This will
ensure that the echo is properly maintained, especially in the case of
a moderator who is frequently absent for long periods of time.
3.2 Moderator Responsibilities
---------------------------------
The responsibilities of a moderator of an echo which the Z1B
distributes are:
1) Seeing that messages in their echo correspond to the echo's
FIDONEWS 16-09 Page 14 1 Mar 1999
theme.
2) Updating their echo's listing in the Echolist at least every
six months.
3) Preventing the distribution of their echo from interfering
with the operation of the Z1B.
4) Must be accessible via netmail through known channels.
5) Seeing that messages in their echo do not violate the
standards set in Section 4.
When moderators place their echoes on the Z1B they must realize that
Z1B Hubs distribute publicly available echoes and that the job of
enforcing any kind of access restrictions remains with the moderator.
These restrictions, as well as the echo's rules, are usually available
in the EchoList so that any Sysop interested in the echo may review
them prior to actually carrying the echo on his or her system.
3.3 Moderator Tools
----------------------
The Z1B provides some "tools" to a moderator in order to help him/her
carry out their responsibilities.
If a moderator believes that a node is violating an echo rule, he/she
may request the feed to that node be severed. This request is made in
written form (netmail), to the Z1B Hub feeding the offending node,
with a copy to the offending node. It is recommended that a copy also
be sent to the node's NEC so that he or she is aware of such problems
in the net and can provide information and assistance.
Some important points to remember regarding feed cut requests:
1) Feed cuts should be initiated with an effort to cause the least
amount of disruption to the echo.
2) In most cases, the main goal of a feed cut is to remove a
REPEAT offender who is likely to cause future echo disruption.
3) Echo rule offenders are, in most cases, PEOPLE - not systems.
4) SYSTEMS should not be cut until efforts to remove the PERSON
have failed. Moderators should attempt to resolve problems as
close to the root of the problem as possible, i.e., user first,
SysOp second, hub third, etc.
5) Feed cuts at the zone level are taken very seriously. Only use
them as a last resort after all other means have failed. Have
proper documentation ready to support a link cut request at the
zone level showing that all other efforts have failed.
6) Feed cut requests are just that - requests. Communications
should be polite and not demanding as you are REQUESTING help
FIDONEWS 16-09 Page 15 1 Mar 1999
from another system.
3.4 Echo Addition
--------------------
The Z1BC adds an echo to Z1B distribution when all of these
requirements are met:
1) The moderator lists the echo in the EchoList. See the
EchoList FAQ for information about how to do this.
2) The moderator requests that the echo be distributed by the
Z1B. The request should be sent from one of the moderator
addresses listed in the EchoList, via one of the following
methods, preferably "A".
A) Echomail: To "Z1B", in the Z1BACKBONE echo
B) Netmail: To "Z1B", at the Z1BC's FidoNet address
C) Email: To the Z1BC's Internet address, subject "Z1B"
The body of the request should consist of a current copy of
the EchoList listing for the echo. This could be taken from a
recent message from the EchoList (netmail, email or echomail)
or be an excerpt from the current EchoList itself.
The echo is then listed in BACKSTAT.Z1B as requesting
addition.
3) Within one month of being initially being listed in
BACKSTAT.Z1B, two Tier 1 or 2 Z1B Hubs and/or RECs request
that the Z1B distribute the echo. The requests should be sent
via one of the following methods, preferably "A".
A) Echomail: To "Z1B", in the Z1BACKBONE echo
B) Netmail: To "Z1B", at the Z1BC's FidoNet address
C) Email: To the Z1BC's Internet address, subject "Z1B"
The requests are noted in BACKSTAT.Z1B.
If two requests are not forthcoming, prior to the one month
expiring the moderator may request a one month extension from
the Z1BC.
The echo is then added to BACKBONE.Z1B and this is noted in
BACKSTAT.Z1B. A welcome message is sent in the echo to help establish
links. At this time any private links to the echo should be switched
to the Z1B.
3.5 Echo Removal
-------------------
The Z1BC removes an echo from Z1B distribution when any of these
situations occur:
FIDONEWS 16-09 Page 16 1 Mar 1999
1) The echo is not listed in the EchoList. The echo is first
listed as "not in EchoList" in BACKSTAT.Z1B for up to 3
months, then it is dropped entirely. During these 3 months,
weekly warning messages are posted in the echo alerting the
moderator and the users as to the echo's status. If at any
time during these 3 months it is re-listed in the EchoList
then it's status is restored.
2) Unconditionally when the moderator sends a direct request to
the Z1BC that the echo be removed. The request should be sent
from one of the moderator addresses listed in the EchoList, to
one of the following:
A) Echomail: To "Z1B", in the Z1BACKBONE echo
B) Netmail: To "Z1B", at the Z1BC's FidoNet address
C) Email: To the Z1BC's Internet address, subject "Z1B"
3) The moderator fails to properly carry out his
responsibilities (see Section 3.2).
4) The traffic level in the echo falls below 2 messages for any
month. The echo is first listed as "low traffic" in
BACKSTAT.Z1B for up to 6 months, then it is dropped entirely.
If at any time during these 6 months the traffic level rises
to or above 5 messages for any month then it's status is
restored.
The Z1B drops echoes when the traffic level falls below a
minimum:
A) To encourage the formation of new echoes, like pruning
dead branches off a tree.
B) To save the SysOps and users from the frustration of
setting up areas only to find that they are dead.
5) When it is decided by a two-thirds vote that the distribution
of an echo is not in the best interest of the Z1B.
All changes in status of echoes are noted in BACKSTAT.Z1B.
3.6 Echo Name Change
-----------------------
In order to change the name of an echo which is currently distributed
by the Z1B, without the necessity of reapproval, you should:
1) EchoList the new echo name.
2) Set a date for the change to occur. This date should give
all concerned plenty of time to prepare. Generally, a 3-4
week notice should suffice. The proposed date for the change
should fall on a Sunday.
3) Spread the word of the impending name change. Do so in the
FIDONEWS 16-09 Page 17 1 Mar 1999
affected echo, the Z1BACKBONE echo, and via netmail or email
to the Z1BC.
4) Item 3 should be repeated at least once per week before the
name change is to occur.
5) On the day before the change is to occur, send a netmail
reminder to the Z1BC.
6) The change occurs. The new echo name is added to BACKBONE.Z1B
and the old echo name is removed.
4.0 Standard Operating Procedures
====================================
4.1 Technical Standards
--------------------------
The Z1B observes FTSC specifications FTS-0001 and FSC-0074. Notes:
1) All Z1B Hubs use the pathline.
2) The Z1B considers the "toUserName", "fromUserName" and
"Origin Line" to be control information lines, thus character
set restrictions apply.
3) The requirement that control information lines shall contain
only ASCII characters, from 32 to 126, is extended to include
hi-bit alphabetic characters, including 128 to 168, 173, and
224 to 240.
4) Echomail messages older than 30 days may considered to be
dupes. This technique has undergone much testing and has
proven its value in preventing dupes due to massive rescans
without interfering with the flow of normal echomail.
5) Due to the limitations of some current software, the Z1B can
not guarantee delivery of messages in excess of 30K bytes.
Z1B Hubs are encouraged to use message processing software
which allows larger messages, preferably up to 64K bytes, to
be handled. Z1B Hubs may split large messages to ensure their
safe passage.
Z1B Hubs may delete messages which do not conform to these technical
standards when such messages might be harmful to the technical
operation of the Z1B. This includes duplicate messages and "grunged"
messages. Such messages are generally not returned.
Z1B Hubs operate in a secure fashion. They automatically process
inbound messages only from those nodes with which prior agreements
have been made. Normally this means that Z1B Hubs use session
passwords and secure ("protected") inbound areas. However, any
reasonable method of ensuring that non-secure messages do not enter
FIDONEWS 16-09 Page 18 1 Mar 1999
the Z1B is acceptable.
A Z1B Hub may choose not to provide services to a node which does not
operate in a secure fashion.
4.2 Gateways
---------------
Gateways must remove foreign distribution identifiers (including
seen-bys) which might adversely affect the distribution of the echo on
the Z1B. Pathlines, however, should be left intact. The origin line
should be that of the Gateway.
Gateways also pass netmail into the other network, unless it is
technically impossible to do so.
4.3 Encrypted Messages
-------------------------
Some Z1B Hubs do not allow encrypted messages to flow through their
systems. Therefore, the Z1B does not agree to handle encrypted
messages in routed netmail or in echoes, excepting digital signatures
and occasional demonstration and/or test messages.
4.4 Encoded Files in Echoes
------------------------------
Echomail is not an efficient method of transporting files. There are
many File Distribution Networks which can be used instead. Thus the
Z1B does not distribute any echo which routinely contains large
(multi-message) encoded files. The use of an echo for small or
occasional encoded files is left up to the discretion of its
moderator.
4.5 Illegal Activities
-------------------------
The Z1B does not distribute any echo which routinely contains
messages which contain illegal information, or promote illegal
activities. As used in this paragraph, "illegal activities" includes
activities which are a violation of civil law as well as activities
which could result in criminal prosecution.
4.6 Censorship of Messages
-----------------------------
Z1B Hubs do not delete or alter messages as they are distributed,
except for technical reasons.
If a Z1B Hub feels that netmail messages may lead to legal action
against him then he may decline to handle such messages, as per
FIDONEWS 16-09 Page 19 1 Mar 1999
FidoNet Policy.
If a Z1B Hub feels that echomail messages may lead to legal action
against him then he may decline to handle that echo in its entirety,
notifying the echo's moderator.
The Z1B does not distribute any echo which routinely contains
counterfeit messages. A counterfeit message is any message entered
using another person's name, handle, or node address with the intent
of deceiving others about the true author of the message.
4.7 Anonymous Remailers
--------------------------
An "Anonymous Remailer" (AR) is software which conceals the identity
of a message's author. Use within an echo is up to the moderator of
that echo.
However, an AR should not be used in an echo until the echo's
moderator has informed the operator of the AR that such messages would
be welcome. The burden of proof that such a request has been granted
is carried by the operator of the AR.
4.8 Emergency Plans
----------------------
The Tier 1 Z1B Hubs maintain emergency backup plans should one of
them experience problems. These plans include:
1) Quick availability of replacement equipment.
2) Adequate backups of necessary control information.
3) Standby nodes capable of assuming the load.
4) Alternate routing to bypass a down Tier 1 Z1B Hub.
================================== End ===============================
-----------------------------------------------------------------
FIDONEWS 16-09 Page 20 1 Mar 1999
=================================================================
COLUMNS
=================================================================
ECHO TALK - Monkey Business
. -- -- -- -- -- ECHO TALK -- -- -- -- -- .
| Food for thought from Fido's echomail. |
| Purloined without permission by D Myers |
` -- -- -- -- -- -- - -- -- -- -- -- -- '
RanD on the structure of Fidonet:
--------------------------------
Fidonet is like a tree full of monkeys, all on different limbs at
different levels.
Some monkeys are climbing up, some down.
The monkeys on top look down and see a tree full of smiling faces.
The monkeys on the bottom look up and see nothing but assholes.
-----------------------------------------------------------------
FIDONEWS 16-09 Page 21 1 Mar 1999
=================================================================
NOTICES
=================================================================
Future History
12 May 1999
12th Anniversary of Fido Operations in Zone 4;
10th Anniversary of the creation of FidoNet Zone 4.
24 Jul 1999
XIII Pan American Games [through 8 Aug 99].
9 Jun 1999
Tenth Anniversary of the adoption of FidoNet Policy 4.07.
10 Sep 1999
10th anniversary of Zone 5 operations.
26 Oct 1999
Thirty years from release Abbey Road album by the Beatles.
31 Dec 1999
Hogmanay, Scotland. The New Year that can't be missed.
1 Jan 2000
The 20th Century, C.E., is still taking place thru 31 Dec.
1 Jun 2000
EXPO 2000 World Exposition in Hannover (Germany) opens.
15 Sep 2000
Sydney (Australia) Summer Olympiad opens.
21 Sep 2000
10 years of FidoNet in +7 (xUSSR)
1 Jan 2001
This is the actual start of the new millennium, C.E.
-- If YOU have something which you would like to see in this
Future History, please send a note to the FidoNews Editor.
-----------------------------------------------------------------
FIDONEWS 16-09 Page 22 1 Mar 1999
=================================================================
FIDONET BY INTERNET
=================================================================
This is a list of all FidoNet-related sites reported to the
FidoNews Editor as of this issue; see the notice at the end.
FidoNet:
Homepage http://www.fidonet.org
FidoNews http://www.fidonews.org [HTML]
http://209.77.228.66/fidonews.html [ASCII]
WWW sources http://travel.to/fidonet/
FTSC page http://www.ftsc.org/
Echomail [pending]
General http://owls.com/~jerrys/fidonet.html
http://www.nrgsys.com/orb/foti
List servers:
http://www.onelist.com/subscribe.cgi/fidonet-discussion
============
Zone 1: http://www.z1.fidonet.org
Region 10: http://www.psnw.com/~net205/region10.html
Region 11: http://oeonline.com/~garyg/region11/
Region 13:
Net 264: http://www.net264.org/r13.htm
Region 14:
Net 282: http://www.rxn.com/~net282/
Region 17: http://www.nwstar.com/~region17/
Region 18: http://techshop.pdn.net/fido/
Region 19: http://www.compconn.net/r19
Zone 1 Elist http://www.baltimoremd.com/elist/
Not sure where the following should be placed:
http://www.angelfire.com/biz/snwvlly/fido.html
============
Zone 2: http://www.z2.fidonet.org
ZEC2:
Zone 2 Elist: http://www.fbone.ch/echolist/
Region 20: http://www.fidonet.pp.se (in Swedish)
FIDONEWS 16-09 Page 23 1 Mar 1999
Region 23: http://www.fido.dk (in Danish)
Region 24: http://www.swb.de/personal/flop/gatebau.html (German)
Fido-IP: http://home.nrh.de/~lbehet/fido (English/German)
Region 25: http://www.bsnet.co.uk/net2502/net/
Region 26: http://www.nemesis.ie
REC 26: http://www.nrgsys.com/orb
Region 27: http://telematique.org/ft/r27.htm
Region 29: http://www.rtfm.be/fidonet/ (French)
Region 30: http://www.fidonet.ch (German)
Region 33: http://www.fidoitalia.net (Italian)
Region 34: http://www.pobox.com/cnb/r34.htm (Spanish)
REC34: http://pobox.com/~chr
Region 36: http://www.geocities.com/SiliconValley/7207/
Region 38: http://public.st.carnet.hr/~blagi/bbs/adriam.html
Region 41: http://www.fidonet.gr (Greek/English)
Region 42: http://www.fido.cz
Region 48: http://www.fidonet.org.pl
Region 50: http://www.fido7.com/ (Russian)
Net 5010: http://fido.tu-chel.ac.ru/ (Russian)
Net 5015: http://www.fido.nnov.ru/ (Russian)
Net 5030: http://kenga.ru/fido/ (Russian & English)
Net 5073: http://people.weekend.ru/soa/ (Russian)
============
Zone 3: http://www.z3.fidonet.org
============
Zone 4:
Region 90: http://visitweb.com/fidonet
Net 903: http://www.playagrande.com/refugio
Net 904: http://members.tripod.com/~net904 (Spanish)
============
Zone 5: http://www.eastcape.co.za/fidonet/index.htm
============
Zone 6: http://www.z6.fidonet.org
FIDONEWS 16-09 Page 24 1 Mar 1999
Region 65: http://www.cfido.com/fidonet/cfidochina.html (Chinese)
============
Pages listed above are as submitted to the FidoNews Editor,
and generally reflect Zone and Regional Web Page sites. If
no Regional site is submitted, the first Network page from
that Region is used in its place. Generally, Regional pages
should list access points to all Networks within the Region.
TCP/IP accessible node access information should be submitted
to the FidoNews Editor for inclusion in their Region or Zone.
-----------oOo-------------
Fidonet Via Internet Hubs
Node# | Operator | Facilities (*) | Speed | Basic Rate
-----------+-------------------+----------------+-------+------------
1:12/12 | Ken Wilson | FTP | T1 | $24mo.
1:13/25 | Jim Balcom | FTP | 56k | $20mo.
1:106/1 | Matt Bedynek | FTP,VMoT,UUE | 64k | $5/$15mo.
1:106/6018 | Lawrence Garvin | FTP,VMoT | 64k | $5/mo.
1:107/451 | Andy Knifel | FTP, VMoT, UUE | 33.6 | n/c
1:140/12 | Bob Seaborn | FTP | T1 | $5/$20
1:270/101 | George Peace | FTP | T1 | $30mo.
1:271/140 | Tom Barstow | UUE | T1 | n/c
1:275/1 | Joshua Ecklund | UUE | 28.8 | $10/yr.
1:280/169 | Brian Greenstreet | FTP | 33.6 | $2mo.
1:2401/305 | Peter Rocca | FTP,UUE | T1 | unkn
1:2424/10 | Alec Grynspan | FTP,UUE | T1 | n/c
1:2604/104 | Jim Mclaughlin | FTP,VMoT,UUE | 33.6 | $1mo.
1:2624/306 | D. Calafrancesco | VMoT | 33.6 | $15yr.
1:345/0 | Todd Cochrane | FTP | T1 | n/c
1:346/250 | Aran Spence | FTP,UUE | T1 | $10mo.
1:396/45 | Marc Lewis | UUE | 33.6 | $26/yr.
1:3651/9 | Jerry Gause | FTP,VMoT | 33.6 | $3/$6
1:396/1 | John Souvestre | FTP,VMoT | T1 | $15mo.
2:335/535 | Mario Mure | VMoT,UUE | 64k | n/c
2:254/175 | Alex Kemp | UUE | 56k | n/c
2:284/800 | Jeroen VanDeLeur | FTP,UUE | 64k | n/c
2:335/610 | Gino Lucrezi | UUE | 33.6 | n/c
2:469/84 | Max Masyutin | VMoT | 256k | n/c
2:2411/413 | Dennis Dittrich | UUE | 64k | n/c
2:2474/275 | Christian Emig | UUE | 64k | unkn
3:633/260 | Malcolm Miles | FTP | 33.6 | n/c
4:905/100 | Fabian Gervan | VMoT, UUE | ??? | n/c
5:7104/2 | Henk Wolsink | FTP | 28.8 | n/c
--
* FTP = Internet File Transfer Protocol
* VMoT = Virtual Mailer over Telnet (various)
* UUE = uuencode<->email type transfers
[I'm only cataloging transfer methods, eg, ftp, email, telnet.
Specific programs using these protocols are no longer being listed.
Contact the system operators for details of which programs they have
available.]
FIDONEWS 16-09 Page 25 1 Mar 1999
Compiled by C. Ingersoll, 1:2623/71, (609)814-1978, fbn@dandy.net
Posted on the 1st of every month in FN_SYSOP, R13SYSOP and Fidonews.
-----------------------------------------------------------------
FIDONEWS 16-09 Page 26 1 Mar 1999
=================================================================
FIDONEWS INFORMATION
=================================================================
------- FIDONEWS MASTHEAD AND CONTACT INFORMATION -------
Editor: Henk Wolsink
Editors Emeriti: Tom Jennings, Thom Henderson, Dale Lovell,
Vince Perriello, Tim Pozar, Sylvia Maxwell,
Donald Tees, Christopher Baker, Zorch Frezberg
"FidoNews Editor"
FidoNet 5:5/23
BBS +27-41-581-5913, 2400/9600/V34
more addresses:
Henk Wolsink -- 5:7104/2, hwolsink@catpe.alt.za
(Postal Service mailing address)
FidoNews Editor
P.O. Box 12325
Port Elizabeth,
6006
South Africa
------------------------------------------------------
FidoNews is published weekly by and for the members of the FIDONET
INTERNATIONAL AMATEUR ELECTRONIC MAIL system. It is a compilation
of individual articles contributed by their authors or their
authorized agents. The contribution of articles to this compilation
does not diminish the rights of the authors. OPINIONS EXPRESSED in
these articles ARE THOSE OF THE AUTHORS and not necessarily those of
FidoNews and/or the Editor.
Authors retain copyright on individual works; otherwise FidoNews is
Copyright (C) 1999 Henk Wolsink. All rights reserved. Duplication
and/or distribution permitted for noncommercial purposes only. For
use in other circumstances, please contact the original authors, or
the Editor.
=*=*=*=*=*=*=*=*=
OBTAINING COPIES: The most recent issue of FidoNews in electronic
form may be obtained from the FidoNews Editor via manual download or
file-request, or from various sites in FidoNet and the Internet.
PRINTED COPIES may be obtained by sending SASE to the above postal
address. File-request FIDONEWS for the current Issue. File-request
FNEWS for the current month in one archive. Or file-request specific
back Issue filenames in distribution format [FNEWSGnn.ZIP] for a
particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP
where mmm = three letter month [JAN - DEC] and y = last digit of the
current year [9], i.e., FNWSJAN9.ZIP for all the Issues from Jan 99.
FIDONEWS 16-09 Page 27 1 Mar 1999
Annual volumes are available as FNEWSn.ZIP where n = the Volume number
1 - 16 for 1984 - 1999, respectively. Annual Volume archives range in
size from 48K to 1.4M.
INTERNET USERS: FidoNews is available via:
http://www.fidonews.org
** http://www.fidonet.org/fidonews.htm
** ftp://ftp.fidonet.org/pub/fidonet/fidonews/
ftp://ftp.irvbbs.com/fidonews/
ftp://ftp.nwstar.com/Fidonet/Fidonews
And in non-English formats via:
** http://www.hvc.ee/pats/fidonews (Estonian)
http://www.fidonet.pp.se/sfnews (Swedish)
** LINK HAS NOT BEEN UPDATED
*=*=*
You may obtain an email subscription to FidoNews by sending email to:
jbarchuk@worldnet.att.net
with a Subject line of: subscribe fnews-edist
and no message in the message body. To remove your name from the
email distribution use a Subject line of: unsubscribe fnews-edist
with no message to the same address above.
*
You may retrieve current and previous Issues of FidoNews via FTPMail
by sending email to:
ftpmail@fidonews.org
with a Subject line of: help
and FTPMail will immediately send a reply containing details and
instructions. When you actually make a file request, FTPMail will
respond in three stages. You find a link for this process on
www.fidonews.org.
*=*=*
You can read the current FidoNews Issue in HTML format at:
http://www.fidonews.org
and in the FIDONEWS echo.
STAR SOURCE for ALL Past Issues via FTP and file-request -
Available for FReq from 1:396/1 or by anonymous FTP from:
FIDONEWS 16-09 Page 28 1 Mar 1999
ftp://ftp.sstar.com/fidonet/fnews/
Each yearly archive also contains a listing of the Table-of-Contents
for that year's issues. The total set is currently about 13 Megs.
=*=*=*=
The current week's FidoNews are now also available almost immediately
after publication on the FidoNews Editor homepage on the World Wide
Web at:
http://209.77.228.66/fidonews.html
There are also links there to jim barchuk's HTML FidoNews source and
to John Souvestre's FTP site for the archives. There is also an
email link for sending in an article as message text. Drop on over.
=*=*=*=*=*=*=*=*=
SUBMISSIONS: You are encouraged to submit articles for publication in
FidoNews. Article submission requirements are contained in the file
ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable
from 5:5/23 [5:7104/2] as file "ARTSPEC.DOC". ALL Zone Coordinators
should have copies of ARTSPEC.DOC. Please read it.
"Fido", "FidoNet" and the dog-with-diskette are U.S. registered
trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141,
and are used with permission.
"Disagreement is actually necessary,
or we'd all have to get in fights
or something to amuse ourselves
and create the requisite chaos."
-Tom Jennings
-----------------------------------------------------------------
Reference in New Issue View Git Blame Copy Permalink