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

1619 lines
70 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 -- | Vol. 9 No. 2 (13 January 1992)
The newsletter of the |
FidoNet BBS community | Published by:
_ |
/ \ | "FidoNews" BBS
/|oo \ | (415)-863-2739
(_| /_) | FidoNet 1:1/1
_`@/_ \ _ | Internet:
| | \ \\ | fidonews@fidonews.fidonet.org
| (*) | \ )) |
|__U__| / \// | Editors:
_//|| _\ / | Tom Jennings
(_/(_|(____/ | Tim Pozar
(jm) |
----------------------------+---------------------------------------
Published weekly by and for the Members of the FidoNet international
amateur network. Copyright 1991, Fido Software. All rights reserved.
Duplication and/or distribution permitted for noncommercial purposes
only. For use in other circumstances, please contact FidoNews.
Paper price: . . . . . . . . . . . . . . . . . . . . . . . $5.00US
Electronic Price: . . . . . . . . . . . . . . . . . . . . . free!
For more information about FidoNews refer to the end of this file.
--------------------------------------------------------------------
Table of Contents
1. EDITORIAL ..................................................... 1
Editorial: Revelation! ........................................ 1
2. ARTICLES ...................................................... 3
Cost Recovery (Yes!) .......................................... 3
Geography and Fidonet ......................................... 6
New version of WorldPol released .............................. 9
3. RANTS AND FLAMES .............................................. 23
4. LATEST VERSIONS ............................................... 24
Latest Greatest Software Versions ............................. 24
5. FIDONEWS INFORMATION .......................................... 30
FidoNews 9-02 Page 1 13 Jan 1992
======================================================================
EDITORIAL
======================================================================
Editorial: Revelation!
by Tom Jennings (1:1/1)
Us FidoNet sysops have been outdone at our own game. There's a group
with higher expectations, less willing to put forth effort, regardless
of consequences.
U.S. automakers. Un-be-liev-able.
OK, so Pres. Bush and the big-three CEOs (Ford, GM, Chrysler) visit
Japan to "do something" about the massively declining U.S. auto sales.
Japan is unfair to the U.S., is the assertion.
An article in the S.F. Examiner (8 Jan 92) goes on and on about this
Japanese showroom vs. that, sales figures, etc. Depressing. However a
few glaring details leak out.
Example: a Jeep Cherokee cost twice as much, with half the MPG (at twice
the fuel price!) as an equiv. Nissan product. And the steering wheel is
on the left side! (Japanese cars are righthand drive.) "It's too
expensive to change this for the Japanese market", says Chrysler
spokesman Izumi Kato.
(Many American cars used to be made with provisions for either-hand
drive; my 1963 Rambler has obvious provisions in the sheet metal, and
factory parts catalogs show RH drive parts. (Ramblers were sold in
Australia and Brazil, for instance.))
Oh yes, and they don't seem to advertise their cars on Japanese TV. Kato
said it's too expensive (huh?!). Chrysler's ad budget in '91 was $1M
(less than 1/4th Lee Iacocca's '91 salary!), and 1/10th of Nissan's US
ad budget.
And American car dealers in Japan do there what they do here -- sit in
showrooms waiting for customers to come to them. Except, in Japan, car
salesman go door to door, and have lots of salespeople -- Toyota's
42,000 to Honda's with 12,000. Ford and GM have only a few dozen in
their showrooms!
In another article in the same paper, an unnamed Bush administration
official said, regarding Japanese consessions to what Bush & co. are
asking: "Culturally, they'll never change. We'll have to ram it down
their throats." (Of course we here at FidoNews! also recognize that
there's only one way to do things -- OURS! I assume you all do too.)
Whatever happened to the open market?
FidoNews 9-02 Page 2 13 Jan 1992
In yet another article (which I don't have in front of me for direct
quotes), a United Auto Workers union official was quoted to the effect,
"we build the best cars we can with what we're given". Seems they know
who's fooling whom.
We've been outdone, boys and girls. Can we take the hint?
----------------------------------------------------------------------
FidoNews 9-02 Page 3 13 Jan 1992
======================================================================
ARTICLES
======================================================================
Original Message Date: 08 Jan 92 08:52:16
From: Reinhart Behm on 2:242/38
To: Tom Jennings on 1:1/1
Subj: Fnews
^AINTL 1:1/1 2:242/38
Hello Tom,
as the archiver of embbs and fnews for the nodes of Berlin I'd like to
have the very old fnews issues (below 650).
Could you give me a fido address of someone in germany or at least europe
which (to the best of your knowledge) holds these files? Or, if you don't
know, would you agree to receive a letter from me with diskettes, envelope
and postage and to copy these files for me in a lonely and boring hour?
cu :-) Reinhart
----------------------------------------------------------------------
Cost Recovery (Yes!)
by Jack Winslade (NEC 285)
1:285/666 (DRBBS Technical BBS)
jsw@drbbs.omahug.org
('Net 285, where few people run an IBM-PC, but nobody holds it
against you if you do.')
This is in response to Joe Jared's article in _Fidonews_ 901. For
the past 1 1/2 years, I have coordinated a successful cost-sharing
plan for Net 285 which appears to be well-received by all. I'd like
to respond to some of Joe's remarks, and I have taken the liberty of
including brief quoted sections where appropriate.
Right after Joe's article, 'Cost Recovery (hah)', appeared in
_Fidonews_, another sysop wrote to me in our local sysops' conference
asking '... do you and Larry {our alternate 'gatekeeper'} ever take
any of the flak like that guy {Jared} did?' I replied that no, we do
not, and with rare exception, our Net 285 sysops are appreciative,
helpful, and seldom complain. I've also never heard anyone try to
excuse themself from paying their fair share of the load.
When I was elected NEC of Net 285, we had never had an echomail cost-
sharing plan. Sysops imported echomail on an individual basis, most
often at the lower speeds, and phone bills in the hundreds of dollars
per month were frequent. My goal was to establish a cooperative
echomail 'gateway' which would be funded by all who receive echomail
through it.
FidoNews 9-02 Page 4 13 Jan 1992
When I proposed the gateway to the local network, we agreed on the
following principles under which it should operate:
o It should be voluntary. Each sysop should be free to join or get
echomail elsewhere at his/her own expense. It was my hope that the
cost savings would be the incentive necessary for almost everyone
in the local net to join.
o It should be convenient and reliable. To me this meant that it
should have its own dedicated processor, modem, and phone line.
The processing and delivery of echomail should not have to compete
with regular BBS usage.
o Cost to the member systems should in all cases be less than what it
would cost the sysop to obtain the desired quantity of data using
independent means.
o It should be self-supporting. Nobody should be financially burdened
by it.
o It should pay its own way in the nationwide Fidonet echomail system.
Not only should it pay its own way locally, but it should contribute
to its upstream feeds (the members recently voted a 20% 'tithe') to
help with recovery of their costs.
> I'd like to know how anyone can justify accounting for echomail on a
> echo for echo basis.
I can sum that up in one sentence. It's the only fair way to do it.
In Net 285, the ratio of echomail volume between the system receiving
the most and the system receiving the least is close to 100 to 1. It
is simply unfair to ask the sysop who receives one low-volume echo to
pay the same as the one who receives many medium and high-volume
conferences. (A standing joke at our local users' group meetings is
for two of the low-volume sysops to speculate if their combined bills
for the month are enough to buy me a soda from the machine. ;-)
If all sysops wanted roughly the same volume of data, I could see how
a flat-rate scheme might work, but in our case (as I am sure is the
case in many other networks) the low-volume sysops would be subsidizing
those who had higher volume.
> When it's all averaged out, the cost of accounting would
> significantly outweigh the cost of charging a toll for backbone
> echomail.
The cost of accounting ?? What cost ?? We let the machine do the
grunt work of keeping track of who gets what. It maybe takes a few
extra minutes of machine time per month at most. The accounting
utility is a simple 'c' program driven by a called batch file which
runs every time the message areas are cleaned up and purged.
Something like this can easily be written in less than an hour by
anyone who has had a couple of programming courses. I'm sure that many
teenage hackers with no formal instruction could easily write such a
program. It's almost trivial. It could even be done (although more
slowly) by redirecting each message directory to a text file and
processing the result with an AWK script just prior to cleanup.
FidoNews 9-02 Page 5 13 Jan 1992
> I don't believe for a minute that any single node can pickup
> even 1 echo with the speed and reliability of a backbone net hub
> for less than it costs if everyone contributed.
There are cases where it will not pay for someone to use our system,
and I believe it should be the choice of the individual sysop whether
or not to join a plan such as ours.
We have one node that cannot benefit from our cost-sharing plan. Due
to the oh-so-close-but-yet-so-far extortive in-state telephone rates,
he can call the regional hub directly for less than he can call us.
(We're working on some innovative [and legal] ways around this, but
as of this time we do not have an effective solution to this problem.)
If he were to join the gateway, he would pay twice, once as his share
for getting the data to the gateway, and another to get the data from
the gateway to his node. Certainly this extra burden would far
outweigh the cooperative cost savings.
Some numbers ...
One local system always comes in under a dollar each month. He is
certainly saving. Some systems exceed $20 per month, but those are
the exception and not the rule. Most systems fall somewhere between
the extremes. The cost of a 2-3 minute long distance call each day
easily exceeds what many systems pay for echomail using the gateway.
If we assume a reliable 9600 bps feed, a plan with a major long
distance carrier that charges about $.10 per minute for phone time,
and a 50% compression of echomail using ARC or ZIP, it should cost
right around $0.0089 to import each kilobyte (unpacked) of echomail
into the local network. Now when we take into consideration the
sharing of some of these echoconferences, the actual cost of each
kilobyte typically runs $0.007 or so at most, even considering the
inefficiencies of session startup, orphan portions of minutes, etc.
We can even add a 20% 'tithe' to our upstream feed and come in
lower than the 100% efficient cost.
Toward the future ...
Our network is small, but growing. As more systems join the network,
more echoconferences are shared, and everyone's cost per kilobyte
drops. As sessions grow longer, the overhead of session startup and
unused portions of minutes becomes less and less significant. Since
our gateway system is dedicated, it will be able to meet the echomail
needs of the network as it grows and requires more volume of data.
In conclusion, I will say that there is no such thing as a one-size-
fits-all echomail scheme. What works for one network might not work
for another. However, I think that any cost-sharing plan, in order
to serve the network to its best, must be voluntary, equitable, under
the control of the network sysops as a whole, and should not be a
financial burden to anyone.
FidoNews 9-02 Page 6 13 Jan 1992
Good day JSW
. . . . .
----------------------------------------------------------------------
Geography and Fidonet
by Daniel Tobias, 1:380/7.0
Once again, the question that has led to much political strife within
FidoNet rears its ugly head: the issue of whether nets, regions, and
zones must be strictly constrained by geographical boundaries, or
whether a more "creative" interpretation should be applied to permit
nodes to overlap these boundaries where it suits a need.
The latest volley in this battle is the article by Dennis McClain-
Furmanski (1:275/42.0) in FidoNews 901. In it, he raises a valid
gripe of inconsistency on the part of the FidoNet hierarchy: they
vehemently disallowed the addition of Cuban notes to his U.S. net,
even though due to a geopolitical quirk those nodes (on a U.S.
military base) were actually more directly connected, in telephone
topology, to Net 275 than to the "geographically-correct" Zone 4.
However, in an unrelated squabble later, the same hierarchy "looked
the other way" at some blatant violations of geography on the part of
an adjacent net (which seems to be having a "turf war" with net 275,
from the looks of things). This is blatantly inconsistent, and
results in feelings of unfairness on the part of those affected by
these rulings, whatever the reasons for them might have been.
However, McClain-Furmanski's response hardly seems likely to improve
the Fairness Quotient. Rather than attempting to get the hierarchy to
reach a consistent, impartial resolution of the geographical problems
that affect Net 275, he has (on what authority?) unilaterally declared
these two decisions to both be reversed, to agree with HIS desired
positions. In case no other FidoNews reader has noticed, this mirror-
reversed position is STILL fundamentally inconsistent; it is just
fundamentally inconsistent in the direction of supporting Mr. McClain-
Furmanski's wishes, which presumably is thus regarded as fairer by him
and his friends, but not by anyone on the other side of the issues in
question. It is certainly not a generalized solution to the problem
of geography. While the hierarchy disallowed Cuban nodes for Net 275
but allowed another net to "raid" its territory, the new "solution" is
to arbitrarily ban geographical exceptions for the neighboring net,
but allow them for Cuban nodes.
No lasting solution to FidoNet's political woes will result from
different people unilaterally declaring the geographical exceptions
THEY want to be good, and those that THEY dislike to be bad, and
attempting, successfully or not, to make their wishes binding on
everyone else. To end such squabbles, it is necessary to have a
universal, binding rule that everyone can live with. Two
possibilities:
FidoNews 9-02 Page 7 13 Jan 1992
1) Allow no exceptions whatsoever to geography. All nodes would be
forced to join the zone, region, and net of their location. Somebody
can take a world map and parcel things out so there isn't a square
inch of land anywhere that isn't covered.
ADVANTAGES: If the net/region/zone affiliation of a node is
predetermined, one can hope there would be fewer squabbles about
whether some particular node assignment should be made. Also, the
nodelist would have a very logical structure, making it easier for a
newcomer to locate nearby nodes wherever he might be, or wherever he
might have a friend he'd like to send FidoNet mail to.
DISADVANTAGES: Often, due to the peculiarities of phone systems or
other unusual circumstances, people would be forced into a net or zone
which is inconvenient for mail-routing purposes. Also, to the extent
that the coordinator structure serves as politicians as well as
technical administrators, some people would end up subject to
political "fiefdoms" they dislike, with a monopoly of power over their
areas much like feudal lords.
HOWEVER: This needn't be insuperable, given intelligent management of
the net. Echomail feeds needn't be constrained by zone or region
membership, though some net politicians seem to want to force this.
Intelligent mail-routing software can be made to send mail in
appropriate channels regardless of the actual node numbers involved.
And if the coordinator structure sticks to mere technical coordination
rather than powermonging, it needn't be an intolerable situation to be
compelled to be a member of a particular part of the net.
2) Remove all mandatory geographic restrictions. Assign each zone,
region, and net a geographical area and encourage nodes to follow it,
but don't make it a rule that they must. Somebody wishing to join
elsewhere, and finding a NC who agrees to allow it, should be
permitted to do so, regardless of who else bellyaches about it.
ADVANTAGES: This would also hopefully end the squabbles about whether
some particular exception should be allowed, as they all would be.
Also, such a laissez-faire policy would promote general freedom,
discouraging the "fiefdom" mentality on the part of power-hungry
coordinators at all levels. People finding one ruler intolerable
might change their affiliation to another. This could defuse some
squabbles by providing an exit route.
DISADVANTAGES: The nodelist would acquire a crazy-quilt appearance,
with many nodes in apparently-illogical positions, making it more
difficult for newcomers to figure out, or for people to locate a node
in a particular place. Nodes who were excommunicated for valid reason
might try to pop up elsewhere in the net to cause more trouble. And
some of the power-mongers might simply trade a "feudal lord" mentality
for a "used car salesman" one, and begin making a pest of themselves
running "ad campaigns" to entice nodes to switch their affiliation to
one net instead of another.
FidoNews 9-02 Page 8 13 Jan 1992
HOWEVER: Controls can be put in place to prevent excommunicated nodes
from rejoining the network at any point without permission of the Zone
Coordinator. And most nodes will probably prefer to remain in their
geographical nets, so the nodelist might not be as mixed-up as some
would think. Anyway, Usenet and Internet get along fine with domains
and topologies that have barely any connection to geography. People
looking for nodes in a given area can still do a text search of the
full nodelist with any of a number of different programs.
In closing, I think some sort of consistent policy should be adopted
regarding geography, rather than a patchwork of exceptions in some
places and strict enforcement in others. But, more importantly, a lot
of the problems would be solved if everyone would just lighten up a
bit; this is just a hobby, after all. Is it really the end of the
world if some neighboring net is allowed to "aggrandize" itself by
adding nodes that "by rights" ought to be in your net? On the other
hand, is it catastrophic if you are compelled by the hierarchy to
obtain a node number with a different net or zone at the head of it
than the one you like best? You can still send and receive mail from
anyone else regardless of what arbitrary numbers you are assigned, and
your friends can set their configuration files to send it directly to
you even if the nodelist structure says it should go through a "zone
gate." The whole issue really isn't such a big deal for any sysop or
coordinator who is primarily concerned with the technical aspects of
the network; it only "matters" when people want to turn the network
into a big political playground, populated by coordinators who like to
ego-trip by increasing the number of nodes beneath them and the level
of power they have over them; and sysops who see all actions of
coordinators as a massive, evil conspiracy they must fight. Under
these mindsets, it's a "big deal", but it doesn't particularly matter
to the rest of us who are just trying to run our boards.
----------------------------------------------------------------------
Sara Gordon
1:227/190
VFR Systems AntiVirus BBS
(219) 273-2431
Net 1:227 mourns the loss of Gerald Opperman (1:227/125) who passed away
January 1, 1992. Gerry was a driving force behind Net 227 for a number
of years, having served as NC, sysop, adviser and friend. Gerry did it
all and did it well.
As sysop of River City Network, Gerry brought multi-line BBSing into its
full bloom in Michiana. He was always found on the other local boards
as well, chatting into sun-up; always there to lend a hand, to help in
anyway, with any thing.
FidoNews 9-02 Page 9 13 Jan 1992
Gerry's contribution to sysops and users alike is immeasureable. It is
said that generosity of the spirit is the measure of a man. It was true
in his case; he was a great man and a good friend to all who knew him.
Gerald Opperman
July 8, 1946 -- January 1, 1992
* On a personal note, Gerry always told me he wanted his epitaph to read
"NO CARRIER"
He did perform this ultimate hack, as now all the machines and modems in
the world now pay him daily tribute. He'd be proud of himself.
Warpspeed, old friend. I'll never forget you.
Sara Gordon
----------------------------------------------------------------------
The WorldPol Project
4:4/50@FidoNet
INTRODUCING WORLDPOL VERSION 2C
A new update of the FidoNet Worldwide Policy Document proposal
has been now released. It reflects the changes being discussed in
the WORLDPOL echo.
The WORLDPOL echo is a public echomail conference open to anyone
wishing to participate in it. It is distributed worldwide by the
Independent Distribution System, and currently available at the
following locations:
Zone-1: 1:128/77, 1:133/411, 1:142/928, 1:157/603, 1:250/99,
1:273/909 and 1:367/1. You can request a feed from any of these
systems or from your echomail coordinator if you are in Region 12
(Eastern Canada).
Zone-2: 2:257/102 is the European gateway. Check with Noel
Bradford for your nearest link.
Zone-4: 4:900/130, 4:900/202 and in any system of the Zone-4
backbone.
Zone-6: 6:600/300 in Singapore and 6:720/13 in Taiwan.
W o r l d P o l
The FidoNet Worldwide Policy Document
FidoNews 9-02 Page 10 13 Jan 1992
Version 2c, 11 Jan 1992
This Worldwide Policy document has been released for vote by the
members of FidoNet and is not yet in force.
1 FidoNet
This document establishes an international (inter-zonal) policy
for system operators who are members of the FidoNet network of
FidoNet-compatible electronic mailers. FidoNet is defined by a
list of nodes (NodeList) issued on a weekly basis by each of the
Zone Coordinators, on behalf of the International Coordinator.
1.1 Scope
A node is understood to be a "member system" of FidoNet. The
collection of nodes is classified into Zones, Regions and
Networks.
Each FidoNet Zone is entitled to issue its own policy document
according to its own needs and customs. This International Policy
determines general rules common to FidoNet nodes in all zones.
Regions and Nets may also issue their own policies according to
the provisions in any corresponding Zone Policy, provided that
they do not contradict this policy.
1.2 Overview
FidoNet is an amateur electronic mail system. As such, all of its
participants and operators are unpaid volunteers and/or
hobbyists. From its early beginnings in 1984 as a few friends
swapping messages back and forth mainly in North America, it
consists now of an International community of more than 13,000
nodes worldwide.
FidoNet is not a common carrier or a value-added service network.
FidoNet is a public network only as much as the independent
member nodes may individually provide public access to the
network via their system.
FidoNet exists to provide electronic mail services to its
member nodes. To efficiently provide such services, various
structure and control mechanisms have been established. The
structure and administration of FidoNet is detailed in this
document.
FidoNews 9-02 Page 11 13 Jan 1992
This document outlines procedures at the international level of
FidoNet as well as some general policies common to all levels.
2 Language
Each zone has the right to determine its own official language.
For practical purposes, FidoNet adopts English as its official
language at the international (inter-zonal) level. All the
FidoNet documents issued at the international level must exist in
English. Translation into other languages is encouraged.
3 Admittance to FidoNet
FidoNet membership is open to everyone fulfilling the technical
standards described on a document released by the network's
Technical Standards Committee (FTS-0001 at this writing).
Lower-level policies may issue additional restrictions only if
specifically authorized by the Zone Coordinator Council.
3.1 Anti-discrimination Policy
Discrimination is not permitted within FidoNet.
This means that any type of restriction imposed to a member of
the network that has no technical justification is unacceptable.
No technical requisites will be demanded to any member of the
network than those specifically authorized by this or lower-level
policy documents.
4 Organization
The organizational structure of FidoNet has been developed to
distribute the administration and control of FidoNet to the
lowest possible level, while still allowing for coordinated
action over the entire system.
Effective administration is made viable by operating in a
top-down manner. This means that a person at any given level is
responsible to the level above, and responsible for
administrating the level below.
If a person at any level above sysop is unable to properly
perform their duties, the person at the next level may replace
them temporarily, until new elections are held. For example, if
a Region Coordinator fails to perform, the Zone Coordinator may
cause the Coordinator to be replaced.
FidoNews 9-02 Page 12 13 Jan 1992
Coordinators may also be removed by a majority vote of the level
below. For example, if network Coordinators in a region lose
faith in the ability of a Region Coordinator to effectively
perform, they may vote to have a new Coordinator elected.
4.1 Zone Coordinator Council
The Zone Coordinator Council (ZCC) consists of the Zone
Coordinators and the International Coordinator.
Each Zone Coordinator has one vote at the ZCC. The International
Coordinator may only vote in the event of a ZCC vote tie, but
does not regularly have voting power.
The Zone Coordinator Council is the legislative body of FidoNet,
it represents each of the zones in FidoNet. It is the highest
authority of the network's Top-Down organization.
4.2 International Coordinator
The International Coordinator (IC) is the Executive Officer of
FidoNet and coordinates the joint production of the master
nodelist by the Zone Coordinators. The International Coordinator
is responsible for creating new zones in FidoNet, but can only do
so with the approval of a simple majority of the members of the
Zone Coordinator Council.
The International Coordinator is selected by unanimous vote of
the Zone Coordinators, and removed by a majority vote of the Zone
Coordinators. In the case of absence of the International
Coordinator, the Zone Coordinator Council replaces her/him by
voting on all IC resolutions to be approved by a simple majority.
4.3 Zones and Zone Coordinators
A zone is a grouping of Regions generally consisting of several
countries, whose borders are determined by the Zone Coordinator
Council.
The Zone Coordinator is the Executive Officer of the Zone, and
the zone's representative to the other zones.
The Zone Coordinator compiles the nodelists from all of the
regions in the zone, creates a master nodelist and a difference
file, which is then distributed over FidoNet within the zone. A
Zone Coordinator does not perform message-forwarding services for
any nodes in the zone, whereas the Zone Coordinator is
responsible for the formation and/or administration of one or
more zone-gates to provide inter-zone mail facilities.
FidoNews 9-02 Page 13 13 Jan 1992
The method used for selection of Zone coordinators is left to
the discretion of the relevant Zone Policy. In the absence of a
Zone Policy selection method, Zone Coordinators are elected and
removed by a simple majority vote of the Region Coordinators in
the Zone.
4.4 Regions and Region Coordinators
A Region is a defined geographic area containing nodes which
may or may not be combined into networks. A typical Region will
contain many nodes in networks, and a few independent nodes which
are not part of the Region's other networks.
The Region Coordinator maintains the list of independent nodes in
the region, and accepts nodelists from the Network Coordinators
in the Region. These are compiled to create a regional nodelist,
which is sent to the Zone Coordinator. A Region Coordinator is
encouraged to perform message-forwarding services for nodes
within the region, but is not forced to, unless the appropriate
Zone or Region policy imposes such a requirement.
The method used for selection of Regional coordinators is left to
the discretion of the relevant Zone or Region Policy. In the
absence of such a policy selection method, Region Coordinators
are elected and removed by a simple majority vote of the Ncs in
the Region.
4.5 Networks and Network Coordinators
A network is a group of related nodes. Networks coordinate their
mail activity to decrease cost.
The Network Coordinator is responsible for maintaining the list
of nodes for the network, and for forwarding netmail sent to
members of the network from other FidoNet nodes. The Network
Coordinator may make arrangements to handle outgoing netmail, but
is not required to do so, unless the appropriate Zone, Region or
Net policy imposes such a requirement.
The Network Coordinator is required to assign a valid node number
to each and every qualifying petitioner within 3 weeks from the
request. A petitioner may only be deemed unqualified if she/he
cannot meet current Fidonet Technical Standards. The NC must
inform the petitioner of the grounds for any rejection.
The method used for selection of Network coordinators is left to
the discretion of the relevant Zone/Region/Net Policy. In the
absence of such a policy selection method, Network Coordinators
are elected and removed by a simple majority vote of the Nodes in
the Network.
FidoNews 9-02 Page 14 13 Jan 1992
4.5.1 Network Routing Hubs
Network Routing Hubs exist only in some networks. They may be
appointed by the Network Coordinator, in order to assist the
management (especially routing tasks) of the network.
4.6 Individual systems (Nodes)
The smallest subdivision of FidoNet is the individual system,
corresponding to a single entry in the nodelist. The system
operator (SysOp) formulates a policy for running the board and
dealing with the users. The sysop must mesh with the rest of the
FidoNet system to receive and send mail, and the local policy
must be consistent with other levels of FidoNet.
4.6.1 Users of an individual system
The sysop is responsible for the actions of any user when they
affect the rest of FidoNet (i.e. if the user is annoying, the
sysop is annoying). The users have no rights under this policy
document.
4.6.2 Points
A point is a system that is not in the nodelist, but communicates
with FidoNet through a node defined to as bossnode.
The bossnode operator is responsible for all mail originating at
the point. All mail sent to a point is addressed to the
bossnode's address.
Points are generally regarded as users of an individual system.
4.7 The FidoNet Technical Standards Committee
The FidoNet Technical Standards Committee, abbreviated as the
FTSC, exists for the purpose of establishing minimum requirements
in software and hardware to be able to interface with FidoNet.
These minimum requirements must be obeyed at every level. Nodes
not meeting these requirements are ineligible for a node number
(see section 5.9). These requirements are subject to change at
any time by the FTSC.
5 General Procedures for All Coordinators
FidoNews 9-02 Page 15 13 Jan 1992
5.1 Making Available Difference Files and Nodelist
Each Coordinator is responsible for obtaining and making
available for file request, on a weekly basis, nodelist
difference files and complete nodelists.
5.2 Making Available FidoNews Documents
FidoNews is the Official Newsletter of FidoNet. Each
Coordinator is responsible for obtaining and making available
for file request on a weekly basis, FidoNews Documents.
This requirement may be waived in the event that a majority of
the Sysops served by the Coordinator have no desire to read or
receive FidoNews.
If a Zone Coordinator is not able to get FidoNews into her/his
Zone, he should immediately request help from the FidoNews
Editor. If the Editor can arrange a way to have it delivered to
the Zone Coordinator, FidoNews must be necessarily available to
the rest of the Zone. Otherwise, the Zone Coordinator may
unilaterally waive this requirement.
5.3 Processing Nodelist Changes and Passing Them Upstream
Each Coordinator is responsible for obtaining nodelist
information from the level below, processing it, and passing the
results to the level above. The timing of this process is
determined by the requirements imposed by the level above.
5.4 Ensure the Latest Policy is Available
A Coordinator is responsible for making the current version of
the International Policy available to the level below, and to
encourage familiarity with it.
5.5 Minimize the Number of Hats Worn
Coordinators are persuaded to limit the number of FidoNet-related
Coordinator functions they perform. A Coordinator who holds two
different positions, compromises the appeal process. For example,
is the Network Coordinator is also the Region Coordinator, sysops
in that network are denied one level of appeal.
Multiple hats are also discouraged due to the difficulty of
replacing services when a coordinator leaves the net.
FidoNews 9-02 Page 16 13 Jan 1992
5.6 Be a Member of the Area Administered
A Coordinator must be a member of the area administered. This is,
a Network Coordinator must be a member of the network s/he is to
coordinate. A Region Coordinator must be either a member of a
network in the region, or an independent in a region.
5.7 Encourage New Sysops to Enter FidoNet
A Coordinator is encouraged to operate a public bulletin board
system which is freely available for the purpose of distributing
Policy and Nodelists to potential new sysops. Dissemination of
this information to persons who are potential FidoNet sysops is
important to the growth of FidoNet, and Coordinators should
encourage development of new systems.
5.8 Tradition, Precedent and Technical Management
A Coordinator is not bound by the practices of predecessor.
However, it must be clear that Coordinators are bound by all
requirements of this document, both as FidoNet sysops and as
Coordinators. The holding of a Coordinator title does not grant
license to annoy others or to flaunt policy.
The primary responsibility of any Coordinator is technical
management of network operations. Decisions should normally be
made only on technical grounds. A Coordinator has the
responsibility to act as objectively as possible; objectivity
must be considered an essential factor when making a decision.
5.9 Exclusivity of Zone Mail Hour
Zone Mail Hour is the heart of FidoNet, as this is when network
mail is passed between systems. Any system which wishes to be a
part of FidoNet must be able to receive mail during this time
using the protocol defined in the current FidoNet Technical
Standards Committee publication (FTS-0001 at this writing). It
is permissible to have greater capability (for example, to
support additional protocols or extended mail hours), but the
minimum requirement is FTS-0001 capability during this one hour
of the day.
This time is exclusively reserved for netmail. Many phone
systems charge on a per-call basis, regardless of whether a
connect, no connect, or busy signal is encountered. For this
reason, any activity other than normal network mail processing
that ties up a system during ZMH is considered annoying behavior.
User (BBS) access to a system is prohibited during ZMH.
FidoNews 9-02 Page 17 13 Jan 1992
Zone Mail Hour will be defined by each Zone Policy. In the
absence of a Zone Policy, it will be defined by the Zone
Coordinator.
Zone Mail Hours for all zones should be published every week in
FidoNews, as well as in the nodelist.
6 Election and Referendum Procedures
Any election or referendum at any level of FidoNet must comply
with the standards described in this chapter.
6.1 Democratic Qualities of the Election
All sysops in FidoNet have a vote and must be allowed to
participate in an election or referendum.
All sysops in FidoNet are entitled to be candidates to any
elective position, provided that the requirements for each
position described on this and lower-level policy documents are
satisfied.
6.2 Particular election mechanisms
Each zone will issue its own election procedures, which may
involve direct participation or indirect participation (electoral
college approach).
In any case, all the sysops in the zone must be allowed to vote.
In the case of an indirect elections, the electors must be chosen
by direct vote of the sysops.
6.2.1 Coordinators acting as Electors
Coordinators will automatically be qualified as electors
representing their network or region in an indirect election only
if they have been chosen by direct vote of the sysops in the
administered area.
6.3 Worldwide elections and referendums
In worldwide elections and referendums with the participation of
all zones, the Zone Coordinator Council will determine the
election procedures and whether vote will be direct or indirect.
This will be done in each particular case by form of a ZCC
resolution.
FidoNews 9-02 Page 18 13 Jan 1992
7 Policy Referenda
7.1 International Policy
A referendum on International Policy modification is invoked by
the International Coordinator at the direction of a majority of
the Zone Coordinators, or a majority of the Region Coordinators
of all zones, a majority of the Network Coordinators of all
zones, or by one third of all the sysops in all zones.
All the members of FidoNet are entitled to vote on an
International Policy referendum, which is to be held according to
the procedures described by the Zone Coordinator Council before
the election is called.
7.2 Zone Policy
A referendum on Zone Policy modification is invoked by the Zone
Coordinator, by a majority vote of the Region Coordinators in the
zone, by a majority vote of the Network Coordinators in the
zone, or by one third of all the sysops in the zone.
All the members of the zone are entitled to vote on a Zone
Policy referendum, which is to be held according to the
procedures described on the Zone Policy. If such document does
not exist, the procedures will be determined by the Zone
Coordinator with the approval of the Zone Coordinator Council.
The formulation of Region and Network Policy documents is
encouraged, and must be regulated by the Zone Policy documents in
each zone.
7.3 Transition to a 'Worldwide Policy environment'
After the approval of this Worldwide Policy, the previously
existing policy will still be in effect for the Zone level until
the approval of a new Zone policy, according to the methods
provided in this document.
All the procedures introduced by this Worldwide Policy document
adjourn the procedures existing in the previous policy document.
8 Resolution of Disputes
The FidoNet judicial philosophy can be summed up in two rules:
1) Thou shalt not excessively annoy others.
FidoNews 9-02 Page 19 13 Jan 1992
2) Thou shalt not become excessively annoyed.
The parties involved in a dispute are encouraged to solve their
problems directly, without the intervention of a Coordinator.
8.1 Mediation Requests
Any of the parties involved may request the intervention of the
respective Coordinator: Network Coordinator if a dispute between
members of the same network, Region Coordinator if a dispute
between members of different networks on the same region; Zone
Coordinator if a dispute between members of different regions on
the same zone; International Coordinator if a dispute between
members of different zones.
The Coordinator requested to act as "mediator" will ask each
party to provide all information relevant to the request within
two weeks from the request being made and will make a decision
within forty-five days after s/he received all the information
from the involved parties.
A Coordinator, unable to resolve a dispute, may name a third
party to act as "mediator," provided the parties involved in the
dispute agree.
8.2 Appeals to a Mediator's Decision
A mediator's decision may be appealed to the immediately superior
level if considered unfair: Region Coordinators handle appeals
from decisions made by Network Coordinators; Zone Coordinators
handle appeals from decision made by Region Coordinators; the
International Coordinator handles appeals from decisions made by
the Zone Coordinators; and the Zone Coordinator Council will
handle appeals from decisions made by the International
Coordinator, decisions of the Zone Coordinator Council are not
subject to appeal.
For appeals to a decision made by a third person named by a
Coordinator to act as mediator, it will be as if the Coordinator
made the resolution and the previously enumerated sequence of
appealing will be appropriate.
For appealing to a decision made by a mediator, the same terms
and procedures as for any Mediation Request apply.
8.3 Statute of Limitations
A mediation request may not be filed more than 60 days after the
date of discovery of the source of the infraction, either by
admission or technical discovery of the source of an infraction,
either by admission or technical evidence. Mediation requests may
not be filed more than 120 days after the incident, unless they
involve suspected unlawful behavior, in which the legal statute
FidoNews 9-02 Page 20 13 Jan 1992
of limitations of the country involved shall apply.
8.4 Echomail and File Distribution Networks
Each FidoNet Zone is encouraged to establish in it's Zone
Policy, the manner of handling Echomail and File Distribution,
and the resolution of disputes arising from both distributions.
No sysop may be required to carry an echomail conference or a
File Distribution as a condition of joining or remaining in
FidoNet, with the exception of a single restricted traffic
announcement echo used to pass important information to nodes
within a network.
9 "CCC": Comments, Credits and Copyright!
This section will be automatically removed upon approval of this
document.
9.1 Comments on Implementation
This document is not final. No FidoNet policy is or will ever be.
WorldPol is an open enterprise where every member in FidoNet is
encouraged to participate. It is a unique experience, so far
successful.
If you disagree with any point of this document, you have a real
opportunity of have your voice be heard and contribute to the
future of FidoNet.
All FidoNet sysops are encouraged to make suggestions for
changes, as well as comments, which can be addressed to FidoNet
node 4:4/50 (WorldPol Project). The WORLDPOL echo is also a good
means of doing this; contact 1:102/631 for information on how to
access the independently-distributed WORLDPOL echo.
This World Policy will be adopted according to the mechanisms
provided on the present policy document.
9.2 Credits
WorldPol has received either directly or indirectly, input from
the following individuals (in alphabetical order): Raul Artaza,
Don Benson, Bill Bolton, Steve Bonine, Randy Bush, Billy Coen,
Phillip Dampier, Jack Decker, David Deitch, Daniel Docekal, Ron
Dwight, Luis Garcia-Barrio, Hector Gomez, Tomas Gradin, Jackson
Harding, Rob Hoare, Jesse David Hollington, Alejandro Hopkins,
Tom Jennings, Glen Johnson, Daniel Kalchev, Raymond Lowe, Rick
Moore, George Peace, Vince Perriello, Bob Satti, Jerry Schwartz,
Jan Stozek, Erik Van Riper, Matt Whelan, and Gustavo Zacarias.
FidoNews 9-02 Page 21 13 Jan 1992
Thank you all.
Special thanks are hereby given to Thomas Jefferson whose ideas
were still in the 1990s an important source of inspiration for
this document.
9.3 Temporary Copyright
This document is Copyright (C) 1992 by Pablo Kleinman.
Todos los Derechos Reservados / All Rights Reserved.
This document is protected under international copyright laws.
----------------------------------------------------------------------
* When YOUR the fan, duck! [New Year; Same Shit!]
When YOUR the fan, duck!
By Trevor Merritt (1:161/600)
If you were a fan, and the shit was about to hit, don't you think it
would be a good idea to duck? If only the majority of us could.
This article has quite a bit... Some.... Little (very little) to
do with Fidonet, except that I operate a BBS (okay, I'm a Hub system)
in it.
Since this is the first article I have submitted to FidoNews, let me
start by letting you all know who I am, why I am writting this, and
what I intend you the reader to gain from it.
My name is Trevor Merritt, and I live in Fairfield, California, USA.
For those of you that don't know where it is, don't look for it on
a map. Look for San Francisco and Sacramento California. Fairfield
is in-between. I have operated a BBS for about three and a half
years. Recently, the NC of the Net I was in decided that he didn't
want to BBS any more, and assumed that nobody wanted the Job. To
some extent he was right. So, I immediately re-joined the Net I was
in before. Seems a bunch of the rest of them wanted to remain in
Fidonet as well, so I became a Hub. Other than running a BBS, I also
work (if only I didn't have to). I work for a Credit Union, although
sometimes people think I live there. Hey, what do you expect when
your title is Computer Operations Coordinator.
I am writting this article because... I have better things to do and
just don't feel like doing them right now. Also, I wanted the let
those people out there who had a terrible new years eve/day know
that they aren't the only ones.
Hopefully, the reader will gain something. I don't rightly know
what it will be, and don't care, but you'll probably find it
funny at the least. So, here we go, my New Year [Same Shit].
FidoNews 9-02 Page 22 13 Jan 1992
31Dec91 - Things started going wrong just about the time everyone
was prepareing to leave work, and go out partying. Not me, by my
own choice I would be starting later; I had decided to close and
perform the year end backup of the system myself. The time was
5:18 PM (console logs don't lie). Year end, and everything needs
to be done in exactly the right order. Okay, here we go. I stop
transaction logging. I set the date forward. I backup the system
to tape. I run the year end job file..... Uh oh.... SHIT!!!
I wasn't supposed to set the date forward! The software won't
allow the date to be turned back, because the year end processing
has already started! Okay, don't panic... You can still be outa
here by midnight. We just need to do a reload from last nights
backup. All the transactions are on the logging tape... Except
the batch runs. Those need to be keyed in again. That means that
recieved files (Electronic Funds Transfers, Etc.) will need to be
reloaded for those batch jobs that process them. No problem.
01Jan92, 1:25 AM - Almost done. Just one more file to reload so
that it can be processed. Okay... And the ATM transaction journal
is over $350,000.00 off!!! How can that be! Hmmm.... No, that can't
be right... the date on the file is December 26th. Someone didn't
put the right tape number in the log book!
Well, for the sake of making this article a little shorter, I'll
abreviate the rest. Finally located the RIGHT tape, had to reload
AGAIN. Executed all the Batch jobs, the journals still aren't
correct, but close enough considering that I haven't done the
recovery posting from the transaction logging tape. Revovery posting
completes, and everything balances. Okay, I make another backup, and
run the year end job. Okay, now I can go home! And look, it's only
6:34 AM!!! Let's see, I arrived at work on 31Dec91 at 8:55AM, and
left work 01Jan92 at 6:34 AM. Not counting luch hour, that makes
20.5 hours straight! Now the funny part. I'm salaried, exempt.
No over-time. But, you know the next time I want a comp day, I
better get it!
In parting, I'm sitting here now reading the latest copy of LAN
TIMES (December 30, 1991, Vol.8, issue 24). I just love the
"In The Trenches" article they fill the inside back cover with.
And I quote "Then we sent a message telling everyone [on the LAN]
that it would be down for a few hours for maintenance. (heh, heh,
heh, users can be sooooo naive)". Ain't it the truth! Oh, and
I also loved the statement that Ron Skates of Data General made.
"...We've got a terrible budget deficit. There's no reason we can't
fire 25% of the government tomarrow..."
Thank you for reading the rabblings of a fellow computer warrior.
If you have a direct comment to make on this article please send
NetMail to 1:161/600, Bushido BBS - The [Computer] Warrior's BBS.
----------------------------------------------------------------------
FidoNews 9-02 Page 23 13 Jan 1992
======================================================================
RANTS AND FLAMES
======================================================================
_(*#$_(*@#(* (*^$+)#(%&+| #$)%(&*#_$ @_#( @$
^@#+)(#&%$*+)$%&*+$*%&#@(@#_|)*%|)#%&)#*%&+(@#&*_+(@#*^&@###
*&#_($*&#$_(*#&$_(#*$&$ _(#$*#$+)#($&*+#)$ &#+$*&#
()*&#$_(&^#$_(#*$_#($^&#_$(^&#_$(&^#$_(&#^ damn right _(#^&$_(#^&
$*&#$_+(* #)$&(%($%+)($%*+$)%($* it's ugly _#&%^# &
#($_*#$_ FidoNet (*$&%_@#_(*&@#_(@*#&_ @#_(*&@#_(*
)*&#$ Flames *^$+)#(% (not for the timid) @_#(
(*#$_(*^@#+) and #_|)*% &+(@#&*_+(@#*^&@###
(#$*&#_($*&#$_(*#&$_(#* Rants *&+#$*&#+$*&#
)*&#$_(a regular feature)^&#_$(&^#$_ $^&#$_(#^
(*^#$_*#^&$)*#&$^%)#*$&^_#($*^&#_($ Section #&%^_
_(*#&$_(#* #($*& #$* _(*&@#_(@*# *&@#_(*&
)&*+_)*&+)*&+))&*(*&
(*&_(*&_(*&
----------------------------------------------------------------------
FidoNews 9-02 Page 24 13 Jan 1992
======================================================================
LATEST VERSIONS
======================================================================
Latest Greatest SoftWare Versions
Last Update: 01/02/92 - Happy New Year!!!!
----------------------------------------------------------------------
MS-DOS Systems
--------------
BBS Software NodeList Utilities Compression
Name Version Name Version Utilities
-------------------- -------------------- Name Version
Aurora 1.32b EditNL 4.00 --------------------
DMG 2.93 FDND 1.10 ARC 7.12
DreamBBS 1.05 MakeNL 2.31 ARJ 2.20
Fido/FidoNet 12.21 Parselst 1.33 LHA 2.13
Genesis Deluxe 3.2 Prune 1.40 PAK 2.51
GSBBS 3.02 SysNL 3.14 PKPak 3.61
Kitten 1.01 XlatList 2.90 PKZip 1.10
Lynx 1.30 XlaxNode/Diff 2.53
Maximus-CBCS 2.00
Merlin 1.39n
Opus 1.73a* Other Utilities(A-M) Other Utilities(N-Z)
Oracomm 5.M.6P@ Name Version Name Version
Oracomm Plus 6.E@ -------------------- --------------------
PCBoard 14.5a 2DAPoint 1.50* Netsex 2.00b
Phoenix 1.07* ARCAsim 2.31 OFFLINE 1.32@
ProBoard 1.20* ARCmail 2.07 Oliver 1.0a
QuickBBS 2.75 Areafix 1.20 PKInsert 7.10*
RBBS 17.3b ConfMail 4.00 PolyXarc 2.1a
RemoteAccess 1.10 Crossnet 1.5 QM 1.00a
SimplexBBS 1.05 DOMAIN 1.42 QSort 4.04
SLBBS 2.15C* DEMM 1.06 RAD Plus 2.11
Socrates 1.11 DGMM 1.06 Raid 1.00
SuperBBS 1.12* DOMAIN 1.42 RBBSMail 18.0
SuperComm 0.99 EEngine 0.32 ScanToss 1.28
TAG 2.5g EMM 2.11* ScMail 1.00
TBBS 2.1 EZPoint 2.1 ScEdit 1.12
TComm/TCommNet 3.4 4Dog/4DMatrix 1.18 Sirius 1.0x
Telegard 2.5 FGroup 1.00 SLMail 2.15C
TPBoard 6.1 FNPGate 2.70 SquishMail 1.00
TriTel 2.0* GateWorks 3.06e StarLink 1.01
WildCat! 2.55 GMail 2.05 TagMail 2.41
WWIV 4.20 GMD 3.10 TCOMMail 2.2
XBBS 1.77 GMM 1.21 Telemail 1.27
GoldEd 2.31p TGroup 1.13
GROUP 2.23 TIRES 3.11
Network Mailers GUS 1.40 TMail 1.21
Name Version Harvey's Robot 4.10 TosScan 1.00
-------------------- HeadEdit 1.18 UFGATE 1.03
BinkleyTerm 2.50 HLIST 1.09 VPurge 4.09e
D'Bridge 1.30 IMAIL 1.20 WildMail 2.00
Dreamer 1.06 InterPCB 1.31 XRS 4.99
Dutchie 2.90c Lola 1.01d XST 2.3e
FidoNews 9-02 Page 25 13 Jan 1992
FrontDoor 2.02 Mosaic 1.00b YUPPIE! 2.00
InterMail 2.01 MSG 4.2 ZmailH 1.25
Milqtoast 1.00 MSGED 2.06 ZSX 2.40
PreNM 1.48 MsgLnk 1.0c
SEAdog 4.60 MsgMstr 2.03a
SEAmail 1.01 MsgNum 4.16d
TIMS 1.0(mod8) MSGTOSS 1.3
OS/2 Systems
------------
BBS Software Other Utilities(A-M Other Utilities(N-Z)
Name Version Name Version Name Version
-------------------- -------------------- --------------------
Kitten 1.01 ARC 7.12 oMMM 1.52
Maximus-CBCS 2.00 ARC2 6.01 Omail 3.1
SimplexBBS 1.04.02+ ConfMail 4.00 Parselst 1.33
EchoStat 6.0 PKZip 1.02
EZPoint 2.1 PMSnoop 1.30
Network Mailers FGroup 1.00 PolyXOS2 2.1a
Name Version GROUP 2.23 QSort 2.1
-------------------- LH2 2.11 Raid 1.0
BinkleyTerm 2.50 MSG 4.2 Remapper 1.2
BinkleyTerm(S) 2.50 MsgEd 2.06c SquishMail 1.00
BinkleyTerm/2-MT MsgLink 1.0c Tick 2.0
1.40.02 MsgNum 4.16d VPurge 4.09e
SEAmail 1.01
Xenix/Unix 386
--------------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
BinkleyTerm 2.32b ARC 5.21
C-LHARC 1.00
MsgEd 2.06
|Contact: Jon Hogan-uran 3:711/909, | MSGLINK 1.01
|Willy Paine 1:343/15 or Eddy van Loo| oMMM 1.42
|2:285/406 | Omail 1.00
ParseLst 1.32
Unzip 3.10
VPurge 4.08
Zoo 2.01
QNX
---
FidoNews 9-02 Page 26 13 Jan 1992
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
QTach2 1.09 QMM 0.50s Kermit 2.03
QCP 1.02
NodeList Utilities Archive Utilities QSave 3.6
Name Version Name Version QTTSysop 1.07.1
-------------------- -------------------- SeaLink 1.05
QNode 2.09 Arc 6.02 XModem 1.00
LH 1.00.2 YModem 1.01
Unzip 2.01 ZModem 0.02f
Zoo 2.01
Apple II
--------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
DDBBS + 8.0* Fruity Dog 2.0 deARC2e 2.1
GBBS Pro 2.1 ProSel 8.70*
ShrinkIt 3.30*
|Contact: Dennis McClain-Furmanski 1:275/42| ShrinkIt GS 1.04
Apple CP/M
----------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
Daisy 2j Daisy Mailer 0.38 Filer 2-D
MsgUtil 2.5
Nodecomp 0.37
PackUser 4
UNARC.Com 1.20
Macintosh
---------
BBS Software Network Mailers Other Software
Name Version Name Version Name Version
-------------------- -------------------- --------------------
FBBS 0.91 Copernicus 1.0 ArcMac 1.3
Hermes 1.6.1 Tabby 2.2 AreaFix 1.6
Mansion 7.15 Compact Pro 1.30
Precision Sys. 0.95b EventMeister 1.0
Red Ryder Host 2.1 Export 3.21
Telefinder Host Import 3.2
FidoNews 9-02 Page 27 13 Jan 1992
2.12T10 LHARC 0.41
MacArd 0.04
Mantissa 3.21
Point System Mehitable 2.0
Software OriginatorII 2.0
Name Version PreStamp 3.2
-------------------- StuffIt Classic 1.6
Copernicus 1.00 SunDial 3.2
CounterPoint 1.09 TExport 1.92
MacWoof 1.1 TimeStamp 1.6
TImport 1.92
Tset 1.3
TSort 1.0
UNZIP 1.02c
Zenith 1.5
Zip Extract 0.10
Amiga
-----
BBS Software Network Mailers Other Software
Name Version Name Version Name Version
-------------------- -------------------- --------------------
4D-BBS 1.65@ BinkleyTerm 1.00 Areafix 1.48
DLG Pro. 0.96b TrapDoor 1.80 AReceipt 1.5
Falcon CBCS 1.00 WelMat 0.44 ChameleonEdit 0.11
Paragon 2.082+ ConfMail 1.12
TransAmiga 1.07 ElectricHerald 1.66
XenoLink 1.0 Compression FileMgr 2.08
Utilities GCChost 3.6b
Name Version Login 0.18
NodeList Utilities -------------------- MessageFilter 1.52
Name Version AmigArc 0.23 Message View 1.12
-------------------- booz 1.01 oMMM 1.50
ParseLst 1.66 LHARC 1.30 PolyXAmy 2.02
Skyparse 2.30 LZ 1.92 RMB 1.30
TrapList 1.40 PKAX 1.00 Roof 46.15
UnZip 4.1 RoboWriter 1.02
Zippy (Unzip) 1.25 Rsh 4.07a
Zoo 2.01 Tick 0.75
TrapToss 1.20
|Contact: Maximilian Hantsch 2:310/6| Yuck! 2.02
Atari ST/TT
-----------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
FIDOdoor/ST 2.5.1 BinkleyTerm 2.40n9 ApplyList 1.00@
FiFo 2.1v The Box 1.95* Burep 1.1
LED ST 1.00 ComScan 1.04
MSGED 1.99 ConfMail 4.10
QuickBBS/ST 1.06* NodeList Utilities Echoscan 1.10
FidoNews 9-02 Page 28 13 Jan 1992
Name Version FDrenum 2.5.2
-------------------- FastPack 1.20
Compression ParseList 1.30 Import 1.14
Utilities EchoFix 1.20 oMMM 1.40
Name Version sTICK/Hatch 5.50 Pack 1.00
-------------------- Trenum 0.10
ARC 6.02
LHARC 2.01i*
PackConvert
STZIP
UnJARST 2.00
WhatArc 2.02
Archimedes
----------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
ARCbbs 1.44 BinkleyTerm 2.03 ARC 1.03
BatchPacker 1.00
ParseLst 1.30
!Spark 2.00d
Unzip 2.1TH
Tandy Color Computer 3 (OS-9 Level II)
--------------------------------------
BBS Software Compression Utility Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
RiBBS 2.02 OS9ARC (Arc) 1.0 Ascan 1.2
OS9ARC (Dearc) 1.0 AutoFRL 2.0
DEARC CKARC 1.1
UNZIP 3.10 EchoCheck 1.01
FReq 2.5a
LookNode 2.00
ParseLST
RList 1.03
RTick 2.00
UnSeen 1.1
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Key: + - Netmail Capable (Doesn't Require Additional Mailer Software)
* - Recently Updated Version
@ - New Addition
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
FidoNews 9-02 Page 29 13 Jan 1992
The Complete List is Available For FReq as VERSIONS from 1:103/250
Utility Authors: Please help keep this list up to date by reporting
all new versions to 1:103/250 in this format:
1) Software Name & Version 2) FileName.Ext
3) Support Node Address 4) Support BBS Phone Number
Note: It is not our intent to list all utilities here, only those
which verge on necessity. If you want it updated in the next
FidoNews, get it to me by Thursday evening.
--David French, 1:103/250
----------------------------------------------------------------------
FidoNews 9-02 Page 30 13 Jan 1992
======================================================================
FIDONEWS INFORMATION
======================================================================
------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ----------------
Editors: Tom Jennings, Tim Pozar
Editors Emeritii: Thom Henderson, Dale Lovell, Vince Periello
Special thanks to Ken Kaplan, 1:100/22, aka Fido #22
"FidoNews" BBS
FidoNet 1:1/1
Internet fidonews@fidonews.fidonet.org
BBS (415)-863-2739 (9600 HST/V32)
(Postal Service mailing address)
FidoNews
Box 77731
San Francisco
CA 94107 USA
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.
FidoNews is copyright 1991 Fido Software. All rights reserved.
Duplication and/or distribution permitted for noncommercial purposes
only. For use in other circumstances, please contact FidoNews (we're
easy).
OBTAINING COPIES: FidoNews in electronic form may be obtained from
the FidoNews BBS via manual download or Wazoo FileRequest, or from
various sites in the FidoNet and via uucp. PRINTED COPIES mailed
may be obtained from Fido Software for $5.00US each PostPaid First
Class within North America, or $7.00US elsewhere, mailed Air Mail.
(US funds drawn upon a US bank only.)
Periodic subscriptions are not available at this time; if enough
people request it I will implement it.
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 BBS, or Wazoo filerequestable
from 1:1/1 as file "ARTSPEC.DOC".
FidoNews 9-02 Page 31 13 Jan 1992
"Fido", "FidoNet" and the dog-with-diskette are U.S. registered
trademarks of Tom Jennings of Fido Software, Box 77731, San Francisco
CA 94107, USA and are used with permission.
-- END
----------------------------------------------------------------------
Reference in New Issue View Git Blame Copy Permalink