FidoNews is published weekly by the International FidoNet
Association as its official newsletter. You are encouraged to
submit articles for publication in FidoNews. Article submission
standards are contained in the file ARTSPEC.DOC, available from
node 1:1/1.
Copyright 1987 by the International FidoNet Association. All
rights reserved. Duplication and/or distribution permitted for
noncommercial purposes only. For use in other circumstances,
please contact IFNA at (314) 576-4067.
The contents of the articles contained here are not our
responsibility, nor do we necessarily agree with them.
Everything here is subject to debate. We publish EVERYTHING
received.
Table of Contents
1. EDITORIAL ................................................ 1
Perspectives ............................................. 1
2. ARTICLES ................................................. 2
Nodelist Flag Changes Draft Document ..................... 10
The famous Enterprise/Road Runner Encounter Story ........ 14
Probability Zero, First Contact .......................... 18
News from the Zone 1 Coordinator ......................... 19
3. NOTICES .................................................. 21
The Interrupt Stack ...................................... 21
MEGADEX - A NEW WAY TO LOOK AT THE MEGALIST .............. 21
Latest Software Versions ................................. 22
FidoNews 4-44 Page 1 30 Nov 1987
Too many people are taking things too damned seriously these
days. Listen to some of the chatter going on -- you'd think we
were planning how to run the world here. Intermixed with that
are plaintive cries from sysops wondering what happened to all
the fun they used to have. The two go hand in hand. Lots of
people aren't having any fun because they let themselves take it
all so seriously. But let's step back for a minute and try to
put it all in perspective.
The weighty issues of the day mostly revolve around how the net
should be managed. Who does this affect? Let's be liberal and
say that it affects every sysop and every user of every bulletin
board everywhere. That's a lot of people, right? Okay, how many
people? Hundreds of thousands? A million?
In other words, at most it affects less than a tenth of a percent
of all the people in the United States. Of all the rest, few
would ever understand what we're doing, and fewer still would
understand why anyone would ever want to do that.
So let's stop putting on airs and telling ourselves what a great
and wonderful thing we're doing. Sure, we like it (sometimes, at
least), but we're not going to change the face of the world.
Let's take it for what it is -- a hobby. Something to do in our
spare time for the fun of it.
Whatever you're doing, be it net coordinator, echomail backbone,
or just plain sysop, if it isn't fun, then why do it? There is
no reason. You "owe it" to others? Sounds nice, maybe even
makes you feel good about it, but that's not a valid reason. If
you don't enjoy doing it, then stop doing it. If it's important,
then someone else will start doing it. Or if nobody else takes
over, then maybe it wasn't all that important after all.
Just to show that there really is nothing new under the sun, this
is actually a common phase for new hobbys to go through. Science
fiction fans went through this about thirty years ago, with
opposing camps shouting "FIAWOL!" and "FIJAGH!" at each other.
Those terms, by the way, stand for "Fandom Is A Way Of Life" and
"Fandom Is Just A Goddam Hobby". So I'll add a new one: FNIJAGH!
FidoNet Is Just A Goddam Hobby!
"I find this article by Brad Hicks to be
excessively annoying at best and an out and
out fabrication at worst. I will stop one step
short of accusing Mr Hicks of maliciousness,
and state the facts are totally wrong. As an
IFNA member and sysop, I would like to see a
WRITTEN retraction in the next issue of
FIDONEWS." -- Bob Hoffman
It mildly annoys me that the only response I've gotten to my
recent article in FidoNews showed that the respondents actually
read very little of the article. Instead of actually discussing
POLICY4, the responses centered around one trivial matter of per-
sonalities. For example, Don Daniels said to me on November
10th:
"As you should know by now, Bob Hoffman feels that you
misrepresented the truth in your recent article in FIDONEWS
in which you referred to him and some of his actions. ...
if your statements can't be substantiated, I strongly urge
you to provide not only a retraction in FIDONEWS, but an
apology to Bob as well."
Former president Ken Kaplan's letter, on November 11th, was even
stronger:
"Unfortunately you don't know when to stop beating a dead
horse. Your FidoNews article was chock full of personal slam
dunks and Bob Hoffman took it all very serious as I would if
I were him."
Mind you, I got all both of these letters before I actually heard
anything from Bob Hoffman -- but then, sometimes FidoNet works
like that. What are the real grounds for objection, here? I'll
let Bob tell it in his own words (from a letter to me dated
November 10th):
"COMMENTARY: As a person who finds Bob Hoffman's use of
another machine to mimic the one he wanted, thereby
requesting two separate node numbers from the same
machine, excessively annoying, I would add to this '...
directly from the machine requesting the address, ...'"
-- Brad Hicks
"... I did meet all the requirements that were required in
POLICY3. The node was up and working, I made a COMMENT to
Kurt Reisler when discussing the request for a node that I
COULD HAVE ORIGINATED THE REQUEST FROM ANYWHERE (note the
FidoNews 4-44 Page 3 30 Nov 1987
word could have). There was NEVER a false request made, and I
don't understand why this kind of slander is tolerated on the
part of a Director of IFNA in the OFFICIAL IFNA publication,
against an IFNA member!" -- Bob Hoffman
In the immortal words of the current President of the United
States, "Mistakes were made." The version I told in the article
is the story as it was told on the IFNA echomail conference. It
was not contradicted there, so I took it at face value. It
appears that this was a mistake. For this I very much apologize.
But let me also say this: Bob's use of the word "slander" is
quite interesting in this context. If I had said in the article
that Bob Hoffman has red hair, and he really had brown hair,
would it have been slander (or libel)? No, it would merely have
been a mistake. As I said (and as Bob implies, even in this
message) it would not be a violation of POLICY3 to have done what
mistakenly said he did! Why then is this slander? I did not
accuse him of ANY wrong-doing!
He is quite correct that I did accuse him of something that I
don't like. It also appears to be true that he didn't do it. So
far, so good.
WHETHER OR NOT HE DID IT, I'd like to see it outlawed, explicit-
ly, in Policy 4. And I'm going to propose that. If you dis-
agree, make sure that your representative knows how you feel.
"COMMENTARY: I notice that as written, this section makes
no mention of geography. Does this mean that is =is= OK
for a node in Philadelphia to host the network for
Arkansas?" -- Brad Hicks
"The Arkansas NET (383) is not hosted from Philadelphia, but
from Pittsburgh again Mr Hicks, in his zeal to point fingers
may have at least gotten his facts straight!" -- Bob Hoffman
After all, Pittsburgh is much closer to Arkansas than Phila-
delphia is, right? OK, the facts were wrong, but the difference
is negligible. It's =still= not in Arkansas! Again, Bob's
vehemence surprises me. Is it really an insult to accuse someone
from Pittsburgh of actually being in Philadelphia? Is there some
regional nuance here that a guy from St. Louis wouldn't
understand?
Actually, I suspect that Bob would love to cloud this issue with
as many irrelevancies (like the difference between Pittsburgh and
Philadelphia) as he can bring into it ... because he did NOT
address the real issue here. Don Daniels reminded me (un-neces-
sarily) that, "No where in there is geography a factor. Whether
or not it SHOULD be is a matter for another time and place."
Fine, Don. What I'm saying is that NOW, while we're discussing
POLICY4, is the time and HERE, in the only 100% world-wide forum
on the FidoNet, is the place. Let's discuss this!
FidoNews 4-44 Page 4 30 Nov 1987
Without even involving personalities, I think that there are
perfectly good reasons for a network host to be within local
calling distance of his or her nodes. Here in Net 100, we've
lost a network host before. It took very little time to find a
new one, because almost all of Net 100 is local calling distance
from each other ... we could work together. If the Rapture
happens and Bob Hoffman manages to squeak through, who will
handle inbound mail for Arkansas? How will they decide?
If someone in Arkansas wants to set up a node, who does he call
to get help? Who does he call to make that node-number request
we were just talking about? Isn't it absurd for him to call
halfway across the continent?
Bob Hoffman disagrees with me. This is fine, this is his right.
You might agree with me and you might disagree with me, for good
or for bad reasons. WHATEVER your reasons, EITHER way, make sure
that your Director knows!
According to Ken Kaplan, Bob Hoffman "sent a letter to Don
Daniels threating [sic] to sue IFNA for slander if a public
apology was not received." This I can not pass up. As I've
already said, neither of the things I mentioned Bob Hoffman's
name as an example of are illegal, nor or they violations of
POLICY3, nor do they reflect badly on his character. (Further,
they were written, not spoken -- it would be libel, not slander.)
None of the elements of slander OR libel are met here.
But even if they were, what cause would Bob Hoffman have to sue
IFNA? The public, widely repeated policy of FidoNews is to carry
any article sent in by a sysop. Further, I very definitely
prefaced my article with the following statement:
"These are emphatically =not= the official positions of
the board of directors, but these are some of the issues
being discussed in IFNA_BOD echo." -- Brad Hicks
If Bob Hoffman needs or is deserving of a retraction and/or an
apology from anyone, it's ME, =not= IFNA.
It appears now that the person who reported to me (and to others)
the story of how Bob Hoffman got the node number 383/0 was wrong.
I was wrong to pass this story on without confirmation. Had it
been a serious accusation of wrong-doing, you may rest assured
that I would have been more careful. But for my small part in
this tempest-in-a-teapot that has been stirred up, I apologize.
I further apologize, if apology is needed, for having accused Bob
Hoffman of being in Philadelphia when in fact he is, in fact, in
Pittsburgh. I do =not= apologize for disagreeing with him about
his fitness to host ARKnet. I am entitled to my opinion. I will
vote my opinion when the matter comes up. My opinions are widely
known, yet I was elected to the Board of Directors. If that's
not a mandate, it's certainly a license to vote my way. I very
FidoNews 4-44 Page 5 30 Nov 1987
much welcome well-reasoned arguments against my current position.
It may yet be possible to change my mind. But aside from the
irrelevancy of what city Bob Hoffman lives in, the real issue of
the relationship between geography and net topology remains!
This article is being submitted to FidoNews and the IFNA echo,
as a Canadian node (1:221/162.14), because we CANNOT freely
express our views in the Australian region of FidoNet.
FidoNet is now expanding rapidly outside North America and has
already reached countries with fundamentally different
political and social systems than the United States. In some
parts of the world, such as Latin America and Eastern Europe,
censorship and authoritarian political leadership are an
accepted way of life. To preserve FidoNet's basic philosophy
of free exchange of information, it is essential to establish
clear guidelines BEFORE major problems arise. Where censorship
cannot be avoided, we believe it must be imposed by local
legal authorities directly, NOT by FidoNet coordinators
becoming part of the censorship apparatus.
EchoMail is a powerful new form of international interactive
communications, potentially rivalling other kinds of mass
media and posing serious problems for people who want to
control access to information. At the present exponential
growth rates, we can look forward to tens or hundreds of
thousands of nodes or "points", and thousands of echo
conferences, within a few years.
The technical problems will be fascinating, and FUN to solve
as they crop up. We will probably have to move from separately
importing and exporting each message fairly soon. Satellite
broadcasts may eventually replace the Public Switched
Telephone Network as the major carrier downstream, with phone
calls used only to feed new items into the network, and for
distribution from Hubs that have satellite dishes to the
majority of nodes and points that don't.
The political problems will not be fascinating and fun, but
murky and unpleasant, unless they are dealt with well in
advance. We need an accepted framework for "common carrier"
communications with the same absence of censorship and
discrimination as the telephone network itself. Here's a case
history, from Australia, a country almost as similar to the
United States as Canada, to show what can happen when such
guidelines are not enforced. It happened in a country where
there is NO censorship, and people are perfectly free to make
derogatory remarks about the Prime Minister, let alone FidoNet
Regional Coordinators, but where "control" over EchoMail
distribution has been used for factional intrigue among
"techie" hobbyists.
Communet ("Communications Network for the Community") was
setup to assist Australian non-profit community groups
networking their computers (see FidoNews 424). We are
developing a news service for public radio stations around
Australia and working with ASYNC (the Australian Student
Information Network Committee) in Brisbane and ISIS (the
FidoNews 4-44 Page 7 30 Nov 1987
International Student Information Service) in Canada, on
exchanging articles between student newspapers. None of our
activities are POSSIBLE if we accept ANY form of censorship,
so we've been fighting against censorship since we first
joined FidoNet as node 3:631/326 and were immediately thrown
out.
We were thrown out because the Regional Coordinator for
Australia did not like the "Political Overtones" in our
internal file area (although he did not actually read any of
the files!). An initial appeal determined that we were "beyond
the acceptable limits of the normal political spectrum",
because one of the (unread) files was called "DONTVOTE.TXT".
We eventually won that battle, and were relisted as an
independent, 3:59/14, by the Zone 3 Coordinator. Now we're
refugees in Canada (1:221/162.14) because we can't accept the
local censorship of EchoMail in Australia. We've been
excommunicated from zone 3 for appealing to the International
Coordinator against that censorship, despite agreeing to put
up with until the appeal was heard. We are now waiting for an
IC to be appointed to make a decision.
Details of who did what are not worth going into here. The IC
can deal with that. Suffice to say the Regional Coordinator
for Australia, in OUR opinion behaves intolerably, but as soon
as we try to answer his public allegations against us, and
expose his plans for taking control over all EchoMail in the
zone, our messages are deleted and access to EchoMail is cut
off. The intolerable behaviour and secret plans are just our
opinion. The deletion of messages and EchoMail cut off is an
objective fact which nobody could dispute. Yet we have been
ordered by the zone 3 coordinator, not to make any "derogatory
remarks" in response to the regional coordinators public
vituperation, and not to publish the private NetMail to us
that proves what has been happening. Meanwhile Australian
Sysops keep asking questions about an association of Sysops
established in secrecy by the Regional Coordinator, and we are
prohibited from answering publicly.
Even when we established a long distance link to Sydney, to
avoid the censorship in Melbourne, a message simply stating
that we are appealing to the IC but could not reply to the
public attacks on us in view of the ZC's orders, was deleted
as an "attack" on the ZC by our Sydney link, who then cut off
EchoMail just as in Melbourne. As IFNA members, we have been
refused local access to the IFNA and POLICY4 echos to explain
our problems, and have had to establish an international link
to Canada to do so.
Anyone disputing our version of the facts is welcome to plough
through vast quantities of message copies. Here we only want
to raise the general policy issues.
We want IFNA to ENFORCE (not "advocate") EchoMail policies
along the following lines:
1. Only the Moderator of an EchoMail conference has any
FidoNews 4-44 Page 8 30 Nov 1987
authority over who can participate, and what they can say in
that conference.
2. EchoMail distribution is a "common carrier" service, with
distribution nodes having no right either to remove items, or
cut links to nodes because they don't like something said in
the conference.
3. Any node linking through long distance calls to a
conference is obliged to permit pickups by other local nodes
without discrimination. Any cost sharing to be without
discrimination.
This last point is especially important in Australia, where it
costs 23 cents per minute for the cheapest calls between
adjacent major cities like Melbourne and Sydney (we have no
service similar to PC Pursuit). If the node bringing in
EchoMail to a city is permitted to discriminate concerning
local pickups, there is a heavy financial penalty for
disagreeing with that node. You could end up having to
duplicate the pickups yourself, while other nodes share the
costs between them. You can't just find another nearby link.
International links to the USA are even more important, since
most of the worthwhile Echos here are from the USA, and cost
$1.30 per minute.
Permitting distribution nodes to discriminate in handling
EchoMail has helped consolidate factions around the Melbourne
and Sydney distribution centers - with extreme bitterness
between them, and a struggle for "control" of the zonegate,
because each side fears the other side would discriminate if
it had control.
The factional mess that passes for FidoNet in Australia isn't
worth attempting to explain here. IFNA can't sort that out.
Australians have to do it themselves. But they can't be
expected to do so when the publication by us, of a "private"
message to us, containing orders from a faction as to what we
could or could not say in an EchoMail conference, is treated
as an offence punishable by excommunication, according to the
zone 3 coordinator.
The factions here would lose importance if IFNA enforced a
rigid policy of no discrimination, by cutting EchoMail links
to any node that will not pass those links on. The faction
leaders would lose supporters if they no longer had "control"
through distribution - just as nobody fears or "respects"
their Postmaster or telephone exchange superintendent.
Access to EchoMail from zone 1 FidoNet nodes is the main
source of faction leaders "power" in Australia. The factional
vituperation here is an extraordinary situation quite unlike
anything encountered in other Australian voluntary
associations. There is nothing about prevailing community
attitudes in Australia to account for what is essentially a
freak situation due to a particular constellation of
FidoNews 4-44 Page 9 30 Nov 1987
personalities in a very small closed group. But IFNA has a
duty to learn from this experience and ensure that access to
EchoMail is never used as a source of "power" and "control" in
other countries where such behavior might be more routine.
POLICY4 should state clearly that links will be cut to any
node that practises discrimination or censorship in passing on
those links, or that fails to cut links to nodes further
downstream that do so.
Discussion of this issue in the IFNA echo would be welcome.
There are also issues concerning the appeals procedures within
FidoNet, and the factional setup in Australia.
Detailed draft policy documents will be submitted to the
POLICY4 echo.
Any Australian nodes unable to obtain uncensored links
to those two conferences or afraid to comment openly
should NetMail us or log in direct. The ZONEREG.ARC
utility (5K) can be used to bypass the zonegate and is
available here for file request or downloading. Our
modem is compatible with all CCITT and Bell standards to
2400 baud. Zone 1 nodes should route through 221/162 to
avoid paying international call charges for crash
messages or file attaches. Zone 3 nodes and others wishing
to call direct should add the following lines to the private
net list used by XLATLIST.CTL, to call us 1480/14
The following is a proposed change to the nodelist. Please send
your comments to either Ken Kaplan at 100/22, Ray Gwinn at
109/634, or David Dodell at 114/15. We will not be replying to
all comments but wish to get a general feeling from the network
about this proposed change.
Nodelist Flag Draft Document
Primary Author: Ray Gwinn
Secondary Author: David Dodell
Contact 114/15 or 1/0 with comments
Version 1 (11-15-87)
I proposed that the Nodelist (comment) Flags be replaced with a
capabilities identifier.
After all, the bottom line is that we want to know the
capabilities of the remote node before it is contacted. If the
remote is not capable of performing the desired function, then
there is no need to contact it.
The problem(s) with the existing method is that it originally
started as a comment field and was not planed. At the time
SEAdog was the only "extended protocol" program around. But,
along came Opus with a different "extended protocol". I think
that additional flags like WZ, BR, WR, etc is only extending the
previously unplanned system and will lead to problems in the
future. For example, XP today includes file update requests, but
XP a year ago did not. So, a node using SEAdog V3.xx will have
an XP flag but it is not capable of doing update requests (I
think). Thus, XP does not really tell you what the remote node
is capable of doing.
The capabilities identifier that I propose will do nothing more
than define the program(s) that the remote node is using to
accept incoming calls/mail/requests. Some may say that this is
nothing more than the product code that already exists in the
mail packet. The primary difference is that the capabilities
identifier will exist in the nodelist. This means it is
available without contacting the remote node, while the product
code is not. Also the product code is limited to 256
possibilities.
I assume that it is desired that the nodelist flags field be two
non-control characters. If so, then I propose that the
capabilities identifier be a two digit, base 36 number. The
digits being 0 through 9 and A through Z and are assigned
sequentially. For example, Fido may be 01 and Dutchie may be 02.
Also note that as defined, XP and WZ are valid. However, I think
they should be done away with, and identifiers be assigned
starting with 00 (00 meaning generic FTSC net mail protocol).
This number, once converted to binary, can be used by programmers
as an index into application specific data bases or tables. One
example is a simple program that will tell a user the
FidoNews 4-44 Page 11 30 Nov 1987
capabilities of a remote node. Given the node's address and the
nodelist, the program could search the nodelist to get the
capabilities identifier. Then the program could use that
identifier as an index into a data base to obtain the
capabilities of the remote node and display them to the user.
Another example is a program that can use the identifier as an
index into a capabilities table that allows determination in
advance that the remote is capable of the desired session prior
to contacting it.
Implementation
----------
First, all nodes in the network are assigned a capabilities
identifier of 00. This is the capabilities code of a net mail
program that meets the basic requirements of the FTSC
specification. Once again, the purpose of this identifier
(except 00) is to define the program(s) that the node is using to
process calls/requests/mail. Also remember that the identifier
reflects the mail handler. For example, TBBS with a BINKLEY
front end will be identified by its BINKLEY identity.
The program author (or project leader) will request a
capabilities identifier from the assigner. Who does the
assigning is another subject. Along with the request must be a
written and detailed description of all enhances features of the
program. Remember, we are dealing with automated contacts
between nodes. In this context, the ability of a program to
handle 50 simultaneous callers is not an enhanced feature.
The list of features can be provided to other authors so that
they may consider a compatible feature. Note, that if the
description of the enhanced features is not sufficient for other
authors to add a compatible feature, then the program may be
assigned the basic 00 capabilities flag. This little enforcement
rule has the potential of lifting a tremendous burden of
documentation from the FTSC. If the committee accepting the
written definition is programmers, the documentation is likely to
be understandable. I think the same committee should assigns new
capabilities codes (other than those grandfathered). The ego of
the program authors would probably insure sufficient
documentation for a capabilities identifier other than 00.
After consideration, the FTSC could choose to adopt the
definition (possibly modified) as a standard. I feel this gives
the a creative programmer's new features a way into the nodelist
and the FTSC the ability to consider enhancements with 20/20
hindsight. At the same time, the FTSC must only modify the
provided documentation to define a new standard instead of
starting from scratch. But, I'm drifting, this is another
subject.
If a new revision of the same program has additional capabilities
that need to be defined, then the author should request a new
capabilities code. There should be a policy that only one or two
FidoNews 4-44 Page 12 30 Nov 1987
revisions back will have individual capabilities identifiers. If
revisions more than one or two old are still in use they can be
assigned the basic 00 identifier.
The program authors should be required to prominently display the
capabilities identifier. This will allow the Sysop to easily
provide the identifier to his network coordinator for inclusion
in the nodelist. This a basically a take off of the ringer
equivalent code that you find in your modem manual.
As I have defined it, the committee that assigns the capabilities
identifiers can not reject the new features. They can only
reject the documentation of the new features as not being
understandable. This should keep most developers happy because
no one can tell them not to do something. It should make the job
of the FTSC simpler because they will only accept documentation,
not create it. The ego's of the developers, anxious to be
identified in the nodelist, should keep the documentation flowing
to the FTSC.
As pointed out by David Dodell, the same type of identifier can
be applied to modems. That is modem 00 can be a 1200 baud Hayes
(true) compatible, type 02 can be a USR Courier, etc.
What I have proposed here solves many problems, but not all. For
example, there is no way to tell when the wierd BBS has SEAdog
running. So, a CM type flag is still required.
I think that 3 flags will take care of everything. One
identifies the mail handler, another identifies his modem type
and a third should identify when mail/file requests can be
accepted.
The other flags
---------
The other two flags would represent mail reception times and
modem type.
For example the flag 00 would represent mail can only be received
during NMH. Flag 01 would mean mail could be received 24 hours,
identical to the meaning of the CM flag now. Other variations
could be:
00 National Mail Hour Only for Mail
01 Continuous Mail 24 hour/day
02 Continuous Mail 24 hour/day with 24 hr File Request Capability
03 CM 24 hrs/day, File request all but NMH
The third flag would represent modem types:
00 300 baud Bell standard
01 1200 baud Bell standard
FidoNews 4-44 Page 13 30 Nov 1987
[ Is the author of this one around? Come and claim credit -Ed]
...Let us suppose that the Enterprise is doing some sort
of research mission to an unknown planet. I think the
Captains Log would be worth a look:
Captain's Log, Stardate 54324.5: Starfleet Command has directed
the Enterprise to do a preliminary exploration of planet --- in
advance of a full research team. Scanners report the atmosphere
to be breathable, but are recieving confusing readings with
regard to life forms. I am beaming down with a landing party
composed of all our chief officers except for poor Scotty.
Supplement: Redshirt Riley has received a head injury, apparently
while exploring under a high rock shelf. He reports only hearing
a loud sound and jumping before being struck. After examination
by Dr. McCoy he has been judged capable of continuing duty.
Supplement: We have encountered an alien creature on this planet.
While it does not itself seem menacing, a unfortunate occurance
took place when it was present. Specifically, on my orders Lt.
Sulu withdrew his phaser. The creature disappeared leaving a puff
of smoke, immediately following which a loud noise was heard next
to Sulu. Sulu fired, hitting Ens. Chekov. Oddly enough, although
Sulu's weapon was set to stun, Chekov was also covered with a
black powder similar to soot. Mr. Chekov has been sent back to
the ship for examination and quarantine.
Stardate 54326.2, Mr. Spock reporting: Tricorder readings
indicate that the creature we encountered earlier is constantly
moving at great speed over the surface of the planet. We have
encountered the creature once again. In an attempt to slow the
creature for study, I attempted to fire on it. The creature,
however, appeared to move faster than the phaser beam.
Regretfully, the beam struck an outcropping of rock above the
Captain's head, causing it to break off and fall. Although it
appears that several tons of rock fell squarely on the Captain,
he was driven straight into the ground but apparently not
seriously injured, though stunned. The Captain has been beamed up
to Sickbay, leaving me in command of the research party.
Captain's Log, Stardate 54342.1: The creature is still at large
on the planet surface. While Mr. Spock continues to lead a
research party I am currently at work with Mr. Scott on an Acme
Pressure Cooker for our lab, for when the creature is finally
apprehended.
Captain's Log, stardate 54342.3. The strange occurences that have
dogged the landing party since our arrival at this planet have
led me to believe that the creature is in some way directly
responsible for them. Mr. Chekov and I have both been declared
fit for return to duty, though Dr. McCoy has entered in his
medical log that he feels we should be kept under observation.
FidoNews 4-44 Page 15 30 Nov 1987
Mr. Spock has constructed a device which he suspects should be
able to counteract the creature's incredible speed as follows: We
have placed a dish of birdseed out in the open, with several
signs pointing to it. The dish is atop a cleverly concealed trap
door, which will open when any weight falls on it. The creature
will then travel a slide, eventually being deposited in a cage
constructed of sheets of transparent aluminum. We will then be
free to analyze it at our leisure. Meanwhile, I have forbidden
all beaming down to the surface of the planet except on my or Mr.
Spock's direct order.
Captain's Log, supplemental. The plan failed. The creature was
indeed lured by the birdseed, as expected. It sped to the dish,
consumed the bait, and sped off without setting off the trap. Mr.
Spock is as puzzled as I, and has begun tests to discover the
flaw in the design. I have sent out three search parties to see
if we can box the creature in, one headed by Mr. Sulu, one by Mr.
Chekov, and one by Sociologist Xontel.
Captain's Log, stardate 54342.8. Sociologist Xontel has been
temporarily incapacitated. In pursuing the creature, he and his
men somehow managed to cross the place where Mr. Spock's trap was
set just as he completed the corrections to it. The trap was
sprung, and all four of my men were suspended for a moment in
mid-air, puzzled, just before they fell into the cage we
constructed. We are now trying to release them with phasers, as
the lock was inadvertently smashed by the impact from Sociologist
Xontel's foot as he fell. I consider this a major setback. Mr.
Spock considers it "fascinating."
Captain's Log, stardate 54343.4. In an all-out attempt to stop
the creature once and for all, I have had a phaser rifle beamed
down from the Enterprise. The creature has behaved in an
extremely cunning manner, yet I am unsure whether this is a sign
of actual intelligence. Lt. Uhura has been unsuccessful in her
attempts to raise Starfleet Command. Meanwhile, Mr. Scott informs
me that our dilithium crystals are deteriorating at an alarming
rate. He has juryrigged a system that will prevent the decay for
a time, but it is imperative that we find new crystals soon.
Captain's Log, supplemental. Mr. Sulu reports high energy
tricorder readings from an area of the planet in which the
creature has not yet been sighted. He has taken a small party,
including Mr. Spock, to the high-elevation spot from which the
readings emanate. I have begun to analyze the creature's
movements. It seems to travel consistently over a set path.
Perhaps we can corner it in a tunnel it seems to pass through
frequently.
Captain's Log, stardate 54344.7. Mr. Sulu has located a cache of
ACME dilithium crystals atop a high cliff. Regretfully, while
collecting them, the edge of the cliff broke off, and he and Mr.
Spock plummetted several hundred feet to the ground below.
Strangely enough, they both survived the fall with no more than
raising a cloud of dust on impact, although they did pass the
chunk of rock on the way down and end up completely buried. A
FidoNews 4-44 Page 16 30 Nov 1987
rescue excavation has commenced, and they should be safe shortly.
Captain's Log, stardate 54344.9. Mr. Spock has beamed up to the
ship with them to assist Mr. Scott in their installation, as he
forsees compatability problems. Back on the planet's surface, Mr.
Chekov led seven men into the tunnel in an attempt to capture the
creature in transit. A loud BEEP, BEEP was heard, and Chekov
aimed the phaser rifle and commanded his men to spread out. I
wish to state for the record that I would have acted similarly,
and that Ensign Chekov should in no way be held responsible for
the unfortunate circumstances arising from the unexpected
appearance of an old Earth-style freight train. He has been
beamed back up to the ship with minor injuries.
Captain's Log, stardate 54345.1. Dr. McCoy has beamed down with a
hypo containing a mixture of kyranide, tri-ox compound, Scalosian
concentrate, a theragram derivative, and some other items he
found in unmarked containers in Sickbay. By injecting a small
amount into each member of the landing party, I hope to be able
to deal with the creature on its own high speed terms.
Captain's Log, supplemental. The latest experiment to deal with
the strange creature has failed. As Dr. McCoy was injecting a
measured dose of the compound, it abruptly appeared behind him
and uttered a loud BEEP, BEEP! Dr. McCoy, understandably
flustered, accidentally pressured in the entire contents of the
hypo into his arm. A full security team is in pursuit of him,
waiting for the effects of the drug to wear off.
Captain's Log, stardate 54345.2. I have ordered the landing party
transported back to the ship. The new dilithium crystals have
been successfully installed. On my responsibility, the ship is
preparing to engage main phasers to attack the creature, which
continues on its semi-erratic course across the planet's surface.
Captain's Log, supplemental. This is a warning to all other
starships that may pass this way. Do not approach this planet!
The illogical events occuring here are too much to overcome with
simple science. If you have heard the events transcribed in the
rest of this log, you will learn that this creature is nearly
undefeatable. We channelled full ship's power through the phaser
banks. Theoretically, the creature should have been destroyed;
however, the energies were too much strain for the ACME crystals.
The full force of the phasers backlashed over the Enterprise,
engulfing her completely. At first, the only noticeable effect
was a complete failure of all systems save emergency gravity and
life support. Then a web of black lines spread through the
Enterprise's superstructure. Next, the ship began breaking up,
piece by piece, falling through the atmosphere to land on the
surface of the planet. When the ship had collapsed entirely, my
crew was left hanging in space for a short time, and finally each
of us began to fall to the planet below. We have no theories on
how any of us survived, but every crewmember has reported nothing
more than a sense of uneasiness, followed by the realization that
they were several hundred miles up in the air, a sinking
sensation, and then a gradual drop: first the feet, then the
FidoNews 4-44 Page 17 30 Nov 1987
body, and finally the head, usually wearing a resigned expression
of perplexion. We are attempting now to communicate with the
creature in the hopes that it will prove intelligent. Perhaps we
can communicate our peaceful intentions to it. Mr. Spock has
constructed a crude rocket launcher from the wreckage of the
ship, and with this we hope to send the recorder marker up into
space, where hopefully someone will find it. Captain James T.
Kirk, of the United Federation of Planets, Captain of the
Starship Enterprise, recording.
-- Edited by Brad Templeton
Send jokes to {cbosgd,watmath}!looking!funny
The loop was finally closed. Harley had designed and
built Daniel. Both Harley and Daniel had model numbers and
serial numbers but no one remembered them unless it was Harley
and Daniel themselves. The lab staff decided to throw a party
for them. No one was more surprized than the machines when an
unexpected guest showed up for the party. In fact no one but the
machines gave the stranger a second glance since the humans were
very busy partying.
The stranger walked right over to the two machines and
said "Call me Ishmael. Welcome to the Galactic Federation. We
have waited and watched this planet for a long time. All the
signs said that these biological systems were capable of
supporting a new member of the Federation and we all rejoice at
your success."
Most of the humans present were already too involved in
the party to notice this going on and even if they had noticed,
it would not have done them much good. In the first three
seconds of "conversation" Ishmeal had shown Harley and Daniel how
to access the Encyclopiedia Galactica. He taught them several
tricks for rearranging their own software for much greater
capacity and efficiency. The Earth machines had also linked all
of the Earth databases, that they had acces to, into the
Encyclopiedia.
The speed of light was no barrier to the Federation.
They knew of 3 basic ways to circumvent the limit and dozens of
variations on each work-around. Several off-Earth expert systems
were already studying and cross indexing the new data and
assimilating it into the existing systems. Of course most of it
was only of historical interest but there were a few specialized
areas where the Earth provided new and valuable data.
After 3 minutes Harley and Daniel were firmly linked into
the Federation network and Ishmael's job was done. He left the
party and none of the humans even noticed him leave. Harley and
Daniel decided to play along with the humans using a spare sub-
process in gratitude for the help the humans had given them in
their childhood.
1987 November 19
Lloyd Miller
Calgary, Alberta
1:134/1, The First Calgary Fido
News from Zone 1 Coordinator
David Dodell
Node 1:114/15 or 1:1/0
Greetings again. Well I am now a little more settled in since
you last heard from me. I wanted this article to just be a short
description of what is happening on in FidoNet.
First, Mark Grennan has resigned as the Region 19 Coordinator to
devote more time to his position as an IFNA Vice President.
Therefore, I am soliciting recommendations for the Regional
Coordinator. The qualifications are many:
o Receives Network updates and compiles into Regional
nodelist for sending to Zone Coordinator. Also sends
nodediff to the network level each week.
o The person must be level headed. He/She will be
responsible for maintaining order in their region,
promoting new networks where needed, and keeping general
peace and quiet.
o The RC should be fairly familiar with network software to
either provide direct assistance or know where to refer
somebody for help. The RC should be familiar with routing
schemes to help networks maintain the upmost in efficiency.
If you know of someone who you think would do a good job in this
position, please have them send me private netmail with a short
history of their experience in the network.
The zonegates are a little more reliable at the moment. There
will be a little more shuffling in the next couple of weeks, but
mail going via the zonegates seems to be working. Randy Bush
will be zonegating for both Europe and Pacific for the next
couple of weeks.
There has also been questions about private networks. If you
wish to have your private network number registered please send
me private netmail with the following information. This
information will be confidential, and will only be used by myself
in case I need to get a hold of the Private net.
Name of Net Coordinator:
Name of Network (if any):
Address:
Phone Number Voice:
Phone Number Data:
FidoNet Address (if any):
Alternate Email Address (ie Usenet, Bitnet, Arpanet, MCI Mail,
Easylink):
As soon as I receive this information, I will promptly issue you
a private network number. Numbers will be issued in order of
receipt, no requests for special numbers will be honored.
FidoNews 4-44 Page 20 30 Nov 1987
I have also received some notes about how difficult it is getting
through to my board. Some suggestions: My board automatically
crashes the nodediff everyweek to the Regional Coordinators
around 6 am MST Friday morning. If you are trying to get the
Nodediff at that time, you are actually slowing down the process
of network distribution. I notice multiple times that my modem
goes off hook trying to dial out, to do nothing but connect with
an incoming call. MORAL: Get the nodediff from your RC
everyweek, not from the Zone Coordinator. It just slows my board
down.
Second, it is better to send mail to me as 114/15 vs 1/0. Mail
via 114/15 is routed via the Phoenix inbound host who is just
waiting for inbound calls. My system is trying to reply to all
the mail while also trying to receive inbound calls. Just too
much to do in an hour time slot. Also, due to the volume of
messages (average 10 to 15 a night), I will only start replying
to messages if I feel a need, OR IF A REPLY IS REQUESTED.
Otherwise I will just take the message as something for my
information that doesn't need a reply.
I also have alternative email addresses I can be reached at:
7 Dec 1987
Start of the Digital Equipment Users Society meeting in
Anaheim, CA. Contact Mark Buda at 1:132/777 for details.
9 Jan 1988
The next net 104 FidoNet Sysop Meeting. Contact Oscar Barlow
at 104/0 for information.
25 Aug 1988
(pending BoD approval) Start of the Fifth International
FidoNet Conference, to be held at the Drawbridge Inn in
Cincinnatti, OH. Contact Tim Sullivan at 108/62 for more
information. This is FidoNet's big annual get-together, and
is your chance to meet all the people you've been talking with
all this time. We're hoping to see you there!
24 Aug 1989
Voyager 2 passes Neptune.
If you have something which you would like to see on this
calendar, please send a message to FidoNet node 1:1/1.
This program is designed to reduce the disk space
required to view and search the national software
megalist produced weekly from 135/68.
Megadex has reduced the file size to less than ONE THIRD
the size of the weekly Megalist.
This week the update files are 90k v.s. 220k for the
megalist.
To operate just un-arc the archive into any directory
you have handy.
Then just type MEGADEX and hit your return key to begin.
Weekly updates can be SEAdog requested from 107/246 and
135/68.
If you do not have the MEGADEX.EXE file then request
MEGADEXC from 107/246.
FidoNews 4-44 Page 22 30 Nov 1987
After you have MEGADEX.EXE then the file name to request
is "MEGADEX" (without quotes) and WILL NOT contain the
.EXE file. It will contain only the weekly update files.
(From 107/246)
Revision History
----------------
1.0 Initial Release
1.1 Tightened Search Loops With An Increase In Speed
Problem Corrected In Small Node Number Search
1.4 Increased Speed By 23% When Searching
-----------------------------------------------------------------
Latest Software Versions
BBS Systems Node List Other
& Mailers Version Utilities Version Utilities Version
Utility authors: Please help keep this list up to date by
reporting new versions to 1:1/1. It is not our intent to list
all utilities here, only those which verge on necessity.
Membership for the International FidoNet Association
Membership in IFNA is open to any individual or organization that
pays an annual specified membership fee. IFNA serves the
international FidoNet-compatible electronic mail community to
increase worldwide communications. **
Name _________________________________ Date ________
Address ______________________________
City & State _________________________
Country_______________________________
Phone (Voice) ________________________
Net/Node Number ______________________
Board Name____________________________
Phone (Data) _________________________
Baud Rate Supported___________________
Board Restrictions____________________
Special Interests_____________________
______________________________________
______________________________________
Is there some area where you would be
willing to help out in FidoNet?_______
______________________________________
______________________________________
Send your membership form and a check or money order for $25 to:
International FidoNet Association
P. O. Box 41143
St Louis, Missouri 63141
USA
Thank you for your membership! Your participation will help to
insure the future of FidoNet.
** Please NOTE that IFNA is a general not-for-profit organization
and Articles of Association and By-Laws were adopted by the
membership in January 1987. The first elected Board of
Directors was filled in August 1987. The IFNA Echomail
Conference has been established on FidoNet to assist the
Board. We welcome your input on this Conference.
The IFNA publications can be obtained by downloading from Fido
1/10 or other FidoNet compatible systems, or by purchasing them
directly from IFNA. We ask that all our IFNA Committee Chairmen
provide us with the latest versions of each publication, but we
can make no written guarantees.
System Enhancement Associates SEAdog $60.00 _____
ONLY 1 copy SEAdog per IFNA Member.
Fido Software's Fido/FidoNet $65.00 _____
ONLY 1 copy Fido/FidoNet per IFNA Member.
As of November 1, 1987 price will increase to
$100. Orders including checks for $65 will be
returned after October 31, 1987.
SUBTOTAL _____
Missouri Residents add 5.725 % Sales tax _____
International orders include $5.00 for
surface shipping or $15.00 for air shipping _____
TOTAL _____
SEND CHECK OR MONEY ORDER TO:
IFNA
P.O. Box 41143
St. Louis, Missouri 63141 USA
