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

1850 lines
86 KiB
Plaintext
Raw Permalink Normal View History

Initial commit
2021-04-15 13:31:59 -05:00
F I D O N E W S -- | Vol. 8 No. 43 (28 October 1991)
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: Sleeping dogs and such ............................. 1
2. FIDONET NEWS .................................................. 2
(No FidoNetNews this week) .................................... 2
3. ARTICLES ...................................................... 3
Credibility and the FTSC ...................................... 3
PRODIGY STUMBLES AS A FORUM ... AGAIN ......................... 5
FCC allows rate hike for dialup network access ................ 6
A Coherent Look At Gateways ................................... 8
Too Many Standards! ........................................... 12
The Electronic Eyes of Argus or Atomic Energy and Computers ... 13
NEW ECHOs from LOG-on-the-TYNE ................................ 18
Terminally Ill Relatives Conference * ......................... 19
The Fort Worth Nodelist v3.2.4 ................................ 20
A New Call to Arms - Event Horizons vs. Joe Sysop? ............ 24
4. RANTS AND FLAMES .............................................. 26
5. CLASSIFIEDS ................................................... 27
6. NOTICES ....................................................... 28
The Interrupt Stack ........................................... 28
7. LATEST VERSIONS ............................................... 29
Latest Greatest Software Versions ............................. 29
FidoNews 8-43 Page 1 28 Oct 1991
======================================================================
EDITORIAL
======================================================================
Editorial: Sleeping dogs and such
by Tom Jennings
Ask and ye shall receive (I heard that somewhere else) ... Lo and
hehold, articles from outside the U.S. So there *are* people outside the
"01" country prefix! (That's a poke at us Yankees, dontcha know.)
I'll shut up soon and let this issue speak for itself (curious thought).
It's looking pretty good. I'm glad to see people quoting me stuff, even
if it's not in "proper" format.
Turns out, I do accept articles received via FidoNet message, not only
via file-attach. It is difficult for non-US systems to deliver files
across zone boundaries, and there are reliable established ways for
sending messages.
Thom Henderson (or maybe Vince?) gave me a program that does it
automatically, but when I started doing the editor thing I decided to do
everything manually, and get a feel for what is going on. I try to look
at everything received, and frequently tweak files (I wish I didn't have
to do that, and at some point I may do it less... hint hint ...)
For now, here's a suggestion for sending me articles via FidoNet
message: have the body of the message simply be the article, with the
format described in ARTSPEC.DOC. *'ed title line, by-line, etc followed
by the article text. The message header itself can be anything, but do
me the favor of indicating that it's an article in the subject maybe?
I will write this up and make it all public before I make anything
concrete.
And now on to tonite's shooooooooeee ...
----------------------------------------------------------------------
FidoNews 8-43 Page 2 28 Oct 1991
======================================================================
FIDONET NEWS
======================================================================
################################################################
FidoNetNews -- a weekly section devoted to technical and factual
issues within the FidoNet -- FidoNet Technical Standards Committee
reports, *C reports, information on FidoNet standards documents
and the like.
################################################################
----------------------------------------------------------------------
There were no FidoNetNews submissions this week. Tune again in
next week!
----------------------------------------------------------------------
FidoNews 8-43 Page 3 28 Oct 1991
======================================================================
ARTICLES
======================================================================
Thom Henderson
Credibility
and the
Fidonet Technical Standards Committee
It's amazing how much stew some people can make from a single oyster.
Ever since the conference in Denver I've been hearing rumors about the
big fight at the developer's roundtable. Someone really ought to come
out and say what really happened. Nobody else seems to want to, so I
guess I will. And besides, it makes a nice lead-in to something I
want to talk about.
What actually happened can be summed up very easily, since it was all
over in a few seconds anyway. Simply put, at the developer's
roundtable someone in the audience was taking advantage of the
question and answer session to make a speach when I threw in a
flippant remark that made him fly off the handle.
The speach had to do with how the FTSC had been asked to test a given
piece of software for compliance with the various standards, and my
remark was this: "They came back with a definite maybe."
Judge for yourself. It was found that the software in question COULD
comply with all relevant standards, but ONLY if the sysop using it
knew how to set a few obscure configuration options to make it so; by
default it isn't. So is the software compliant? Maybe. We're very
definite about that. We tested it extensively and we know for sure
that it's a "maybe".
Somehow, one or two people seem determined to take that as some kind
of criticism of the FTSC. Even our esteemed editor is mumbling about
damage to the newly-won credibility of the FTSC -- which brings us to
what I wanted to talk about in the first place.
Does the FTSC lack credibility? I don't think so, overall. Certainly
with a few people, but I think they are in the minority. Generally
speaking, I'd say that most of those who have a problem with the FTSC
fall into either of two categories, those who have a personal axe to
grind, and those who don't understand what a standards organization is
supposed to do (I'm guessing that our esteemed Editor falls into the
latter category).
They don't handle enforcement, and they don't usually handle testing.
Sometimes they try to develope new standards for new things, but when
they do it's often a mistake. What they do best is codify and
document existing practice.
FidoNews 8-43 Page 4 28 Oct 1991
Rick Moore (the Chairman of the FTSC) understands that, and he's done
an outstandingly good job of leading the FTSC in that direction. To
my mind his leadership has given far more credibility to the FTSC than
any paper assignment of dubious licenses ever could.
In case you don't know how it works, it's very simple. Anybody who
wants to can write up a "proposed standard" and submit it to the FTSC.
Rick then publishes it as part of the "FSC" series so that the various
developers can have a chance to look at it and discuss it. Any
proposed standard that gets picked up by the developers and put into
widespread practice is then eligible to become a "real standard" and
published as part of the "FTS" series.
So proposed standards can come from anyone, anywhere and be about
anything (and are). Those that are proven in practice as both
workable and worthwhile become accepted standards. This strikes me as
an admirable system, and exactly what we want the FTSC to be.
But a few people feel for some reason that the FTSC can't be credible
if it doesn't also certify products for compliance. I'm not so sure
that's a good idea, and I can't help but notice that few (if any)
other standards bodies do that. For example, the Data Encryption
Standard is published by the American National Standards Institute,
but compliance testing is handled by the National Institute of
Standards and Technology.
I can't help but think that there's a good reason for that. Maybe it
would cloud the mission of the FTSC, or maybe it would just make it
even harder to get all of the various personalities to keep working
together. More than that, in most cases it just plain isn't
necessary. Most of the things that I've heard people talk about
"turning over to the FTSC for a technical decision" don't take any
great brains to figure out. One example that comes to mind is some
program that creates packets with the wrong length for the date/time
field, thus screwing up the subject line for some other software down
the line. There's no real doubt in anyone's mind about what's going
on, so does this require the combined technical wizardry of the FTSC
to resolve, or are the *C's just passing the buck so that THEY don't
have to take the heat?
/* First off, I think the "proposed standards" thing is more or less
fine in FTSC. Unless something has happened in the FTSC chats that I've
missed, the FTSC is not considering "enforcement" of standards.
What has been discussed is FTSC testing whether programs are
"compatible" (definition under discussion as well!), mainly because many
of the combined expertise available there. What was discussed was what
to do with this information, how to convey it without appearing to be
some sort of "authority" or good/bad judgement; simply to be able to
untangle out complaints of "my program X won't talk to their program Y"
type things. Maybe it is not classical "standards committee" behavior,
but we're not like that much anyways.
FidoNews 8-43 Page 5 28 Oct 1991
As to the "developers roundtable" -- it wasn't a round table, it was
quite linear. The thing was a setup, and if Randy was out of line, so
was I, and so were you. Let's drop it. It was early in the AM when my
and presumably other peoples' blood-sugar was low, and there was
literally no notice, agenda or purpose given out before it started, and
others seemed to share my puzzlement. Let's let sleeping dogs lie.
Besides, we should all know better than to eat seafood in Colorado.
-- tomj */
----------------------------------------------------------------------
PRODIGY STUMBLES AS A FORUM ... AGAIN
By Mike Godwin/EFF
On some days, Prodigy representatives tell us they're running "the Disney
Channel of online services." On other days the service is touted as a
forum for "the free expression of ideas." But management has missed the
conflict between these two missions. And it is just this unperceived
conflict that has led the B'nai B'rith's Anti-Defamation League to launch
a protest against the online service..
On one level, the controversy stems from Prodigy's decision to censor
messages responding to claims that, among other things, the Holocaust
never took place. These messages--which included such statements as
"Hitler had some valid points" and that "wherever Jews exercise influence
and power, misery, warfare and economic exploitation ... follow"--were the
sort likely to stir up indignant responses among Jews and non-Jews alike.
But some Prodigy members have complained to the ADL that when they tried
to respond to both the overt content of these messages and their implicit
anti-Semitism, their responses were rejected by Prodigy's staff of
censors.
The rationale for the censorship? Prodigy has a policy of barring messages
directed at other members, but allows messages that condemn a group. The
result of this policy, mechanically applied, is that one member can post a
message saying that "pogroms, 'persecutions,' and the mythical holocaust"
are things that Jews "so very richly deserve" (this was an actual
message). But another member might be barred from posting some like
"Member A's comments are viciously anti-Semitic." It is no wonder that the
Anti-Defamation League is upset at what looks very much like unequal
treatment.
But the problem exposed by this controversy is broader than simply a badly
crafted policy. The problem is that Prodigy, while insisting on its Disney
Channel metaphor, also gives lip service to the notion of a public forum.
Henry Heilbrunn, a senior vice president of Prodigy, refers in the Wall
Street Journal to the service's "policy of free expression," while Bruce
Thurlby, Prodigy's manager of editorial business and operations, invokes
in a letter to ADL "the right of individuals to express opinions that are
contrary to personal standards or individual beliefs."
FidoNews 8-43 Page 6 28 Oct 1991
Yet it is impossible for any free-expression policy to explain both the
allowing of those anti-Semitic postings and the barring of responses to
those postings from outraged and offended members. Historically, this
country has embraced the principle that best cure for offensive or
disturbing speech is more speech. No regime of censorship--even of the
most neutral and well-meaning kind--can avoid the kind of result that
appears in this case: some people get to speak while others get no chance
to reply. So long as a board of censors is in place, Prodigy is no public
forum.
Thus, the service is left in a double bind. If Prodigy really means to be
taken as a computer-network version of "the Disney Channel"--with all the
content control that this metaphor implies--then it's taking
responsibility for (and, to some members, even seeming to endorse) the
anti-Semitic messages that were posted. On the other hand, if Prodigy
really regards itself as a forum for free expression, it has no business
refusing to allow members to respond to what they saw as lies,
distortions, and hate. A true free-speech forum would allow not only the
original messages but also the responses to them.
So, what's the fix for Prodigy? The answer may lie in replacing the
service's censors with a system of "conference hosts" of the sort one sees
on CompuServe or on the WELL. As WELL manager Cliff Figallo conceives of
his service, the management is like an apartment manager who normally
allows tenants to do what they want, but who steps in if they do something
outrageously disruptive. Hosts on the WELL normally steer discussions
rather than censoring them, and merely offensive speech is almost never
censored.
But even if Prodigy doesn't adopt a "conference host" system, it
ultimately will satisfy its members better if it does allow a true forum
for free expression. And the service may be moving in that direction
already: Heilbrunn is quoted in the Wall Street Journal as saying that
Prodigy has been loosening its content restrictions over the past month.
Good news, but not good enough--merely easing some content restrictions is
likely to be no more successful at solving Prodigy's problems than
Gorbachev's easing market restrictions was at solving the Soviet Union's
problems. The best solution is to allow what Oliver Wendell Holmes called
"the marketplace of ideas" to flourish--to get out of the censorship
business.
----------------------------------------------------------------------
FCC allows rate hike for dialup network access
Captured from GEnie<c> on 10/24/91.
The Federal Communications Commission ("FCC") has adopted rules that
will increase by up to five-fold the price of local telephone lines that
use new network features to provide access to information services. The
new rules could have as serious an impact as the FCC's 1987 access
charge proposal, which was successfully defeated through a massive
letter-writing campaign.
FidoNews 8-43 Page 7 28 Oct 1991
Any information service provider that wishes to take advantage of new
network features -- which are to be made available as part of the FCC's
Open Network Architecture ("ONA") -- must start paying the higher
charges. Although the FCC would allow information service providers to
continue using their existing lines at current rates, providers choosing
this option would be denied the use of much existing and future network
functionality. Many state regulators are compounding this problem by
following the FCC's lead.
These pricing rules will needlessly inflate the costs of providing
information services. Information service providers will have no option
but to pass these added costs on to their subscribers in increased
prices. This is bad for the information service providers, bad for
subscribers, and bad for the United States. At a time when the FCC
should be encouraging the widest possible use and availability of
information services, the FCC has adopted rules that will have precisely
the opposite effect.
It's not too late to stop the FCC from implementing its new ONA pricing
rules. GEnie (through its trade associations ADAPSO and IIA),
CompuServe, Prodigy, BTNA (formerly Tymnet) and others have petitioned
the FCC to reconsider its rules, and the FCC is now considering whether
it should grant those petitions. You can help by writing to Al Sikes,
Chairman of the FCC, and sending copies of your letter to his fellow
Commissioners. You should also write to Congressman Ed Markey and
Senator Daniel Inouye, the Chairmen of the House and Senate
Subcommittees that have jurisdiction over the FCC. (You may also wish
to send copies of your letters to your own U.S. Senators and
Representative).
Tell them that:
- You use information services and how you use them.
- You will curtail your use of these services if prices increase
as a result of the FCC's new ONA pricing rules.
- The FCC's new ONA pricing rules will create the wrong incentives
by discouraging information service providers from taking advantage
of new network features.
- The FCC should reconsider the rules it adopted in Docket 89-79 and
allow information service providers to use new network features
without being required to pay usage-sensitive access charges that
are three to five times higher than existing rates.
Write to:
Honorable Alfred C. Sikes
Chairman
FidoNews 8-43 Page 8 28 Oct 1991
Federal Communications Commission
1919 M Street, N.W., Room 814
Washington, D.C. 20554
Honorable Sherrie P. Marshall
Commissioner
Federal Communications Commission
1919 M Street, N.W., Room 826
Washington, D.C. 20554
Honorable Andrew C. Barrett
Commissioner
Federal Communications Commission
1919 M Street, N.W., Room 844
Washington, D.C. 20554
Honorable James H. Quello
Commissioner
Federal Communications Commission
1919 M Street, N.W., Room 802
Washington, D.C. 20554
Honorable Ervin S. Duggan
Commissioner
Federal Communications Commission
1919 M Street, N.W., Room 832
Washington, D.C. 20554
Honorable Edward J. Markey
Chairman, Subcommittee on
Telecommunications and Finance
U.S. House of Representatives
2133 Rayburn House Office Building
Washington, D.C. 20515-2107
Honorable Daniel K. Inouye
Chairman, Subcommittee on
Communications
United States Senate
722 Hart Senate Office Building
Washington, D.C. 20510-1102
----------------------------------------------------------------------
By: Jason Steck
1:104/424@FidoNet
Over the past two or three years, many networks have
sprung up based, to varying extents, on the FidoNet technical
standards for session protocol and, more problematically,
addressing. With the establishment of built-in support for
zones in popular software, the so-called "OtherNets"
experienced a population explosion both in number of nets and
number of sysops belonging to them.
FidoNews 8-43 Page 9 28 Oct 1991
The primary device used to create an OtherNet was, and is,
the use of a unique zone number. FidoNet was already using
zones 1-3 (and is now up to 5 with rumors of a 6), therefore
OtherNets began utilizing zone numbers ranging from 7
(AlterNet) to the upper limit of the existing nodelist
processors (99 -- EggNet). This upper limit now stands at 255
(internal QuickBBS limit) and is poised to move upward to
Binkley's inherent limit of 4096.
While there is obviously little danger of running out of
zone numbers or even, with a modicum of coordination, the
duplication of a zone among two networks, the "pseudo-zone"
scheme of network creation fails badly when internetwork
communication is desired. The purpose of this article is to
address the previously proposed schemes in comparison to the
gateway concept as introduced by FidoNet Gateway Policy and as
in operation at UFGates around the world.
Under a pseudo-zone scheme, a sysop in one network is
often unable to respond to messages originating in another
network. For example, let's say a sysop in the current zone
1-5 FidoNet receives a message from a node in zone 98. Chances
are, the FidoNet sysop has no idea even what network zone 98
is, let alone how to respond. The sysop simply does not have,
and could not get without significant and unnecessary
investigation and effort, the zone 98 nodelist information.
This problem is especially significant in the netmail response
to echomail in which case both parties are likely to be unknown
to each other and separated by large (and expensive) geographic
distances.
As the OtherNets have grown, a number of suggested
solutions have been put forward. To wit:
1) Set up zonegates between FidoNet and the OtherNets.
Rationale: With this system, no node number is truly
unknwon so long at that network's number is unique and is
listed in the FidoNet nodelist as a zonegate. For example,
zone 98 mail could be sent to 1:1/98 for forwarding into
Mil-Net (that's who it is, by the way). The zonegate, by being
"known" to both networks, would function as the interface
point.
Disadvantages: First, there is a serious problem with
cost. Why should a FidoNet sysop (me) in Denver wishing to
contact an AlterNet node in Denver (say, Larry Kayser) be
required to route through a zonegate in, say, New York (the
likely site of such a zonegate)? Such a system is too limited
in scope and rigid for internetwork operation. Zonegates are
designed, and function quite well, as ocean-spanning cost
savers. However, they are NOT designed to handle internetwork
connectivity in cases where the two networks exist in the same
broad geographic area.
FidoNews 8-43 Page 10 28 Oct 1991
Secondly, a zonegate arrangement FORCES OtherNets to be
dependant and parasitical on FidoNet. True independance is not
possible when a network's communication depends entirely on the
goodwill of ANOTHER network's nodelist prodcution and on the
development of another network's technology base. A zonegate
system, by its design, is OWNED by the administrators of the
network where it is listed. A superior system would allow for
internetwork implementations on a diversified, local sysop
level rather than at the network administrative level.
2) Destroy OtherNets or cut them off from FidoNet
Rationale: The rationale for this "solution" is based on
two basic assumptions: First, that FidoNet is the "one true
network" and that OtherNets are inherently parasitical.
Historically, at least, this assumption has some basis in fact.
FidoNet did exist FIRST in the amateur networking field and the
OtherNets were dependant on FidoNet for maintainence of the
technology base and, later, for echomail. The second
assumption is that OtherNets are totally political "SchismNets"
established solely as a reaction to personal or political
problems in FidoNet. If both assumptions are accepted, then
the "solution" becomes natural.
Disadvantages: Obviously, both assumptions are not always
true. However, the larger problem with this "solution" is the
judgementalism inherent in it. The entire object of networking
in the first place was to enhance communication. The above
"solution" to the internetwork problem is somewhat
understandable at times, but is ultimately counter to the
entire spirit of FidoNet and networking in general as it seeks
to LIMIT communications on the basis of some vague and subjective
political or social judgement which is passed. With such a
"Final Solution" to OtherNets, the debate leaves the technical
realm of HOW to communicate and enters an unpleseant political
realm where whole networks are condemned as criminals of a sort
or are required to pass personal, social, or political muster
with individual network administrators.
Furthermore, in recent times, various OtherNets have begun
to disprove the assumptions inherent in the above "solution".
OtherNets have developed unique personalities and atmospheres
in their own right, totally distinct from FidoNet. They have
extended old technology and occasionally developed new
standards and many have specifically endeavored to maintain
friendly, rather than schismatic relations with FidoNet and its
administrators.
3) Gateway Operations
Advantages: Although often confused with zonegates,
gateways operate quite differently and, ultimately, more
powerfully than zonegates while allowing for internal
sociopolitical independance not allowed by the "nuke 'em
solution". Zonegates are limited by design to a single system
at a single location. Gateways, on the other hand, can exist
in many locations simultaneously, each serving a smaller, more
FidoNews 8-43 Page 11 28 Oct 1991
managable area and providing local-call gateway access in more
cases. This leads to a couple of major advantages over the
zonegate solution: First, gateways are more reliable. If a
zonegate system goes down, the link is cut. If a gateway
system goes down, links only need to be switched to another,
already operating, gateway to the same network. 2) Gateways
are cheaper. A zonegate would only be a local call to the
immediate area of its physical location. However, since
gateway systems can be numerous and physically diversified,
gateways would be local calls to every area they existed in.
Where there is a need, there could be a gateway. People who
would be long (expensive) distance to a zonegate would be able
to call the gateway just down the road.
A further advantage is technical. With a zonegate
arrangement, the OtherNet is dependant on FidoNet technology.
Under a gateway system, ONLY the gateway(s) need "speak the
FidoNet language". In this way, the OtherNets are freed to
pursue extensions to FTSC technology or to even abandon it
altogether in favor of a totally different system while, at the
same time, utilizing gateways as "translators" to ensure
continued connectivity with the venerable FidoNet.
While it may not idealize each individual set of
preferences, prejudices, and opinions, the gateway option has
clear technical and sociopolitical advantages over the more
expensive and draconian "solutions" previously proposed.
Additionally, it is a supremely valid compromise to a seemingly
endless quagmire of internetwork political warfare over the
"ownership" of communications mediums and over the viability or
status of various networks or their internal administrative
techniques. Instead of arguing over "who's show is better" in
a futile attempt to hash out a uniform set of internal "rules"
for all networks, the gateway solution allows each network to
develop and maintain a unique identity without having to
undergo judgement from another network and without having to
reduce or eliminate connectivity options. The simple maxim of
the gateway is: "When in Rome, speak Latin". Quite simply,
messages in FidoNet have FidoNet addressability and obey
FidoNet technical standards. Similarly, messages in another
network follow THAT network's technical and addressing
standards.
A properly implemented gateway system will act as a
bridge, not a barrier, between networks. And, as such,
organizations (such as the FreeNet Project -- you didn't think
you'd get away without a plug, did you?) and individuals
interested in expanding network communications should at least
welcome the gateway concept and work towards its successful
establishment in FidoNet and elsewhere.
(For more information on the FreeNet Project, feel free to
contact me by netmail at 1:104/424@FidoNet. A future FidoNews
article will introduce the FNP and cover some gateway
procedures.)
FidoNews 8-43 Page 12 28 Oct 1991
----------------------------------------------------------------------
Too Many Standards!
Steve Townsley 2:256/117
When I started my first BBS with a couple of friends the only software
around for the PC was Fido if I wanted netmail. Like many SYSOPs before
the advent of Crashmail I remember waiting up to 2:30am (GMT) to see the
first transfer. Most of us, who are not BBS authors, cannot believe it
will really work and I for one marvelled at the first transfer of email.
I have never lost that first feeling of wonder. Even today I quickly check
the night's incoming netmail before going to work. My strongest suspicion
is that Thom Henderson wrote the TWIX message printing program for SEAdog
just to read his email over breakfast. (Relax Thom I have no way of
proving this!)
This jumble of thoughts is nostalgia sure but it illustrates the world of
SYSOPing I come from. It was uncomplicated by net politics and long
debates over standards.
It's curious to think how vacuous standards used to be. A new release of
Fido or a later version of SEAdog jumped us along one more notch in the
technological ladder. Then we had Opus, BinkleyTerm, Dutchie and others
all joining the bandwagon. Versions of software spread to all kinds of
machines.
The negative side of this is compatibility. Instead of new versions moving
netmail on in radically new directions now we have "standards". NET_DEV
gets filled with debates about the position of a null character in a
string. By now I expected authors to be moving on to type 3 packets, reply
threading in echomail, integrated SDS support in BBS software and lots
more.
There are plenty of new standards being proposed but few being officially
ratified by the FTSC. The last great debate was EMSI and JoHo's rather
unique method of session negotiation. It seems to make sense - why not go
for it ?
The real point here is that more than a touch of conservatism is growing
in the net. Combine this with the fact that there is too much discussion
and not enough implementation and you get stagnation.
I feel we are desparately in need of a big jump in technology. Maybe a
move beyond Zmodem for transfers, maybe a general acceptance of EMSI,
maybe type 3 packets. Being strictly a sunday afternoon programmer in
QuickBasic it has occured to me that perhaps the limit of amateur
networking has been reached. What I mean by this is not that existing
programmers are not talented enough to implement new ideas but that the
technology of networking is now so expensive to develop it can only be
done in a commercial environment.
FidoNews 8-43 Page 13 28 Oct 1991
It strikes me that if I read some of the older FidoNews I would find a
certain dynamic in the innovation of the developers would wrote to the
'snooze - what has happened ? Are we turning into a network with mid-life
crisis ?
Could someone write an article and tell me what is special about SEAmail ?
Why doesn't anyone write an informative piece about the current proposals
on the table for true message threading in Echomail ? What is the state of
play with regard to versions of BinkleyTerm - my host has version 2.50 and
the 'snooze hasn't even made mention of what's new in the program!
On reflection maybe a network driven by one or two innovative developers
was better than a multitude of programmers being indecisive. Things
certainly have slowed to crawl recently and one cannot help draw the
conclusion that just maybe someone should write a type 3 packet into a
mailer and just see what happens instead of waiting for a standard. After
all when the net started the only standard was the last most popular BBS.
----------------------------------------------------------------------
Published by The Argus Environmental Trust (UK).
@ ARGUS_II_OPUS (+44-91-490-0327) 2:256/18@FidoNet.org
The Electronic Eyes of Argus
or
Atomic Energy and Computers
by Nane Jurgensen (in German) translated by Zephyros
updated english text by John S. Bone (c) 25th-Oct-1991
The Soviet Union would have much preferred, of course, to
keep quiet about the Chernobyl catastrophe, so as to be able to
go on believing - at least themselves - in the superiority of
their Communist system to our world of Coca-Cola and Hamburgers.
But the radioactive particles swirling through the earths
atmosphere and contaminating great stretches of the European
countryside just couldn't be denied.
Owing to the many nuclear tests and accidents, so-called
low-level radiation is somewhat higher than that provided by
Mother Nature.
Research is showing with ever greater clarity - and contrary
to all official mollifications - that this radiation represents,
when seen over the long term, a not-to-be-underestimated health
risk to all of us.
Ever more citizens, and not only in our own Federal Republic,
are feeling themselves to be inadequately informed by officialdom
on actual levels of radioactivity in general, and on the emission
of nuclear materials in 'incidents' in particular.
FidoNews 8-43 Page 14 28 Oct 1991
Not a few even think it possible that peak levels of
radiation brought about through accidents are simply covered up
by officials for reasons of state.
It was demonstrated in the first weekend supplements of the
(German) newspapers in 1988 that such attitudes towards their own
electors are to be found in politicians.
On 1st January 1988 Government files kept secret for 30 years
were released to show that at the instigation of the then Prime
Minister Harold Macmillan the British government had covered up a
near-meltdown at the nuclear power station at Windscale in 1957.
The UK Government records showed that large quantities of
radioactivity had been released then during a fire at the Atomic
reactor.
The report of the second biggest nuclear accident in the
world, prepared by the nuclear scientist Sir William Penny, was
simply put away in a drawer, on the instructions of the then
English Prime Minister (Macmillan) and in its place was published
a sanitised report which naturally made light of it all.
Instead of decently informing the home population, and that
of Europe, everything was hushed up.
Since then, using the "30 year rule" for releasing old UK
government papers, it has been officially admitted in England
that 33 deaths have been caused by the accident.
But even in the face of increased mortality from leukemia
in the area of the installations on the Irish Sea right up to the
present day, no British government has been obliged to lay its
cards on the table.
Until today, All heads of government after Macmillan have
agreed with his assessment of the near-meltdown: better to hush
it all up than have to deal with "public trust in nuclear energy
being seriously shaken".
The nuclear reactor still has to be sealed off today.
Seventeen tonnes of molten and partially burnt radioactive fuel
are still producing such concentrations of radiation that the
reactor cannot be approached except in protective clothing for
short periods of time.
Alarmed by the way in which information was handled by
politicians and official sources after the Chernobyl catastrophe,
and by the behaviour of the British government in the matter of
the near-meltdown of 1957, some specialists in computers and
communications have got together with active environmentalists to
carry out measurements of background radiation in future on a
wide front, without relying on government and official sources.
FidoNews 8-43 Page 15 28 Oct 1991
With its manifold possibilities as an effective instrument
for democratising our society and for strengthening a public and
decentralised flow of information and communication, the computer
is coming into its own.
The word democracy leads one to think of the ancient
Greeks; even though they managed it without the computer....
So let's take a quick leap back a few thousand years.
Old Zeus had found himself desiring Io, the daughter of
Inachos. In order to protect his beloved from the jealousy of his
wife, Hera, he turned the poor woman into a cow. (Incidentally,
she fled to Egypt and was there given back her human form by
Zeus) Before things had got this far, back in Greece Hera had
had the cow guarded by Argus, the hundred-eyed watchman.
Ever since then the phrase 'argus eyes' has been used to
mean 'vigilantly observing eyes'. Hermes was to release Io by
killing Argus, and Hera was to commemorate the foul murder by
setting the hundred eyes of Argus into the peacock's tail.
Borrowing from this ancient Greek fable, the English group
of computer specialists and environmentalists have called
themselves 'the Argus project'.
They are building small, local monitoring stations across
the whole country. The equipment installed by their volunteers
measures background radiation automatically every ten minutes.
The idea is that wherever in the world, there are plug-in
telephone connections it will be possible to install such Gamma
monitors, building up a comprehensive records based on private
initiative of checking radiation levels against official
measurements.
The motto is: Government information is all well and good,
but measuring it yourself is better.
Each single monitor outstation sends its results through
ordinary telephone lines to a central (host) computer with the
help of a modem and an appropriate communications programme.
The owner of a local monitor can print out measured data
whenever wanted - or transfer them onto disc on a PC so as to be
able to correlate them with tabular or database programmes.
By these means he has an up-to-date overview of the actual
radiation level of the immediate vicinity, and is contributing to
the overall picture of radiation constructed as a mosaic out of
all the local measurements.
FidoNews 8-43 Page 16 28 Oct 1991
The countrywide assessment of radioactivity is only made
possible by collating all the data acquired in a "central" or
"host" computer. The transferred data are received and assembled
in this host computer.
It wouldn't be necessary to bother with computers if this
weren't fully automatic: the local outstation sends its readings
once a day to the host computer, where appropriate programmes
receive the data, collate them, and prepare them for the most
varied uses.
The "Argus" host computer can be reached via normal
telephone lines from anywhere in the world by anyone with a
computer and a modem. (Call it on +44-91-490-0327)
So anyone in, say, Manchester wanting to find out the
current levels of radiation in the area, or countrywide, could
make a telephone call to the Argus project host computer to
elicit the up-to-date readings quickly and easily.
Not only current readings can be sought like this; the
longer the project runs, carrying out measurements over longer
periods of time, the more it will be possible to call up and
display the development of radiation over the last few years.
Really interesting eventualities might result.
The extension of the Argus project will make it even
harder for the authorities to issue doctored readings of
radiation levels, or simply to cover up incidents involving the
emission of radioactive particles.
If this project gets even half way to realising the ideas
of its initiators we will be able to rely on this private network
of monitors keeping tighter and more effective tabs on radiation
than any of the current official sources.
The Argus Project is open to anyone prepared to pay the
basic costs of the equipment (circa $1000 [DM2000]) and the small
telephone usage charges, involved in data transmission, to the Host
computer (about $30-50 [60-100DM] per year).
First of all you need a (ARGUS_Project designed and
built) gamma monitor. As standard a Mullard ZP 1220/01 Geiger-
Muller tube is used, installed by Argus specialists outside the
house 1 metre above ground level to ensure that Beta particles
won't be counted. Arrangements to protect the monitor from
weather, wildlife, or vandals will be made as appropriate to the
local conditions.
The distance from monitor to house, where the computer
data-logging control unit (based on the tried and tested Motarola
6809 microprocessor) is installed, may be hundreds of metres.
FidoNews 8-43 Page 17 28 Oct 1991
A standard printer port is provided with the data logging
control unit. A standard "hayes" modem is attached via a (RS232)
communication port , so that the recorded data may be carried
forward to the Argus host computer.
Once a night, at the most favourable time for minimum
tarif call-charges, the readings which have been recorded every
ten minutes are transmitted via telephone line to the host
computer. To inhibit abuse, data exchange between host computer
and outstations is protected by passwords, and a unique data-format.
The Argus specialists have designed the outstations to
operate reliably for about ten years.
The Argus project's two host computers have also linked into
the International FIDO Network so as to be able to communicate and
thus exchange data with computer users over telephone lines world-wide.
This, the largest independent information network, was
brought to electronic life by the American Tom Jennings in 1984.
It includes at the present moment (at least in the free world)
more than 10,000 computers and bulletin boards. The opportunities
opened up there can be imagined.
For any politician not at home with effective democracy,
such hard-to-control networks are enough to make the hair stand
on end.
Nane Jurgensen
Ysenburgstr. 10
8000 MeNCHEN 19
Telephone (089) 16 79 644
Mailbox (089) 16 79 745
(c) 1988 Nane Jurgensen All rights reserved
Further information is available directly from:
The ARGUS Environmental Trust.
The Argus Gamma Project.
19 St. Marys Terrace,Ryton,
Tyne and Wear,
NE40 3AL
UK
Contact: Graham Denman.
Telephone: +44-91-490-6272 ARGUS_OPUS 2:256/18@FidoNet.org
The Argus Project Computer (ARGUS_TWO) is accessible 24 hours
a day (300 to 2400 baud) on + 44 91 490 0327.
FidoNews 8-43 Page 18 28 Oct 1991
Its Co-Sysops: Graham Deman. (2:253/94) and John Bone (2:256/17)
----------------------------------------------------------------
UPDATE on Current details of the ARGUS Project. 20th AUGUST 1991
The ARGUS Project now has 16 remote Gamma Monitor stations,
reporting their daily Gamma readings each night to one of their
two "host" computers. Each "Host" being a OPUS node in the
FidoNet network.
Gamma Monitor Stations are at the following positions:-
O.S. Map grid references location (Owner of Station)
NZ14640 - Ryton - Tyne & Wear - England (ARGUS_1_HQ)
NZ25600 - Gateshead - Tyne & Wear (Low Fell) (ARGUS site)
TQ32820 - London - England (FoE site)
SU71700 - Reading (Borough) - Berks (Local Council)
NS15800 - Dunoon - Scotland (Cowal)
NZ69040 - Botton - N.Yorks (Wand)
NS33200 - Ayr - Scotland (ARM)
NZ2560A - Gateshead - T&W - (Low fell TEST SITE) (ARGUS)
SH64160 - Mawddach - Wales (CYMRU)
TQ05830 - Uxbridge Civic Centre (Hillingdon)
SP49080 - Oxford City Council (Oxford City)
SU64000 - Portsmouth City Council (Portsmouth City)
SU40100 - Southampton(1)@ Chilworth (Southampton City)
SU42150 - Southampton(2)@ University (Southampton City)
SY92870 - Wareham(1) - Dorset (Local Council)
SZ11920 - Bournemouth (Cemetary) - Dorset (Local Council)
and others coming online soon
:::New for 1992:::
Remote equipement for Acid Rain monitoring is also being
currently developed, by the Argus trust.
Gamma Data has been collected now for over 3 (three) years, and
it is published daily. (some stations are new for 1991)
By JOHN BONE 2:256/18@FidoNet 20th August 1991
---------------------------------------------------------------
----------------------------------------------------------------------
NEW ECHOs from LOG-on-the-TYNE
FidoNews 8-43 Page 19 28 Oct 1991
by JOHN S. BONE AMIAS AMWOBO sysop LOTT 2:256/17 3 Claremont Place,
Gateshead, Tyne and Wear, England, UK. NE8 1TL
I am hoping you will add into your list, the following three (3) echos,
which I am promoting via a postal (snail-mail) drop to over 35
organisations, around the world.
I am a Building Control Surveyor , employed to enforce Builders and
architects and their clients, to observe the Laws of the UK (england) as
to buildings.
These are termed Building Codes in the USA and elsewere.. I am also a
associate member of the WORLD ORGANISATION of BUILDING OFFICIALS, whose
jobs are similar around the world.
Several Canadian and USA based groups also have associate members of WOBO,
and I am proposing that we run a number of echos for these people.
I have set-up at my own BBS (LOG-on-the-TYNE) 2:256/17 the following:-
WOBOVIEW - news and views from/to WOBO membership
BUILDCODE - News and views on building standards etc.
EURONORM - News and views on the European Community's new laws, namely
its Construction Products Directive (CPD!) and thats very
own CE! approval mark.
There are also several Workplace Directives which have
effects upon buildings design matters and materials.
I hope that these will bring into fidonet more folk who will like you and
I carry the banner of open governement, and public information flow.
My net host, LOG-on-In-TYNEDALE is also carrying these echos, he has a
9600 (hst) modem. (2:256/97 / 2:256/0
Cheers
----------------------------------------------------------------------
FidoNews 8-43 Page 20 28 Oct 1991
+-------------------------------------------------------------------+
| * Terminally Ill Relatives Conference * |
| |
| A conference for the relatives of the Terminally Ill. It provides |
| an area for discussion and loving support. |
| |
| Topics include: |
| - what to say, what not to say, when to say it |
| - dealing with guilt, anger, and other emotions |
| - dealing with other relatives |
| - preparing for the loss to come |
| - the days after |
| |
| Questions and sharing about the above topics, and other related |
| topics from time to time, is encouraged. Anyone with a terminally |
| ill close relative is invited to join in. |
| |
| Currently, the conference is available as GroupMail from |
| 1:101/863, area "TERM_ILL". The conference is also available as |
| echo mail, contact your NEC or 1:101/863 for a connection. |
+-------------------------------------------------------------------+
/* This is exactly how *not* to format a FidoNew article. I generously
added the title in the proper format. --tomj */
----------------------------------------------------------------------
Aaron Goldblatt Will Schlichtman
1:130/32.1 FidoNet 1:350/59.0 FidoNet
50:5817/150 EchoNet
The Distribution Nodelist
The Fort Worth Format Version 3.2
-=* Part IV *=-
by Aaron Goldblatt (1:130/32.1@fidonet)
Development Manager: Will Schlichtman (1:350/59.0@fidonet)
Last time we concluded the nodelist specifications with the CITYLIST
format and ????DIFF format.
This week, Aaron makes some comments on things he learned during
development, and gives the short! credits list.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Well, folks, it's done. The Fort Worth Format Nodelist has grown
considerably since its first release last June. In that time I've
gotten hundreds of netmail messages with suggestions, questions, request
for clarification on certain aspects, comments, and a few flames.
Everyone who sent a message got a response, if I received their message.
If you didn't get a response it's likely that you sent your message
after the second release. Well, three days after the release of
FidoNews that week I went on vacation, turned off all of my echomail
feeds, and didn't do any mail for six weeks. In that time it's likely
that my bossnode deleted my mail, for whatever reason.
FidoNews 8-43 Page 21 28 Oct 1991
I got many comments of encouragement. Lots of people said they think
the nodelist is too large and that it's time for a revision.
Some people asked for a set of numbers seeing just how much space could
be saved with the Fort Worth Nodelist. Will Schlichtman wrote a
conversion program for me, and the results it produced, in less time
than it takes me to compile my nodelist for FrontDoor, were printed two
weeks ago.
A few of the messages I got said that the Fort Worth Format will never
work because nodelist compilers will have to be rewritten to take
advantage of the new format. Yes, guys, it will. I suppose that's
something we're going to have to deal with.
I got some mail from folks who identified themselves as NCs. This is
great, because the *C structure will have to implement the changes. But
of the about four hundred netmail messages I got, I saw none (count 'em,
ZERO) from anyone who identified themselves as an RC or higher (George?
You have anything to say?). This was somewhat disturbing to me, and I
don't know why it happened. If you're an RC and DID respond, thank you
for taking the time. It's just that I didn't go through my nodelist
looking for names - my computer is too slow, and there were too many
folks to look for.
There were a lot of folks who said that I should drop Pvt nodes
altogether, even from some Pvt nodes. I only gave a very good reason
for not doing so to about two of them, so here it is for everybody.
There are three reasons for allowing Pvt addresses into the Fort Worth
Nodelist.
o They exist already. Because they exist I need to support them -
you will find Down and Hold listings also. My personal feelings
on the matter are not important. They are there so they stay.
o Deletion of Pvts is a matter of FidoNet policy, not FidoNet
standards. I believe that policy should drive the standards,
not the other way around. If the capability to have a Pvt
listing exists, but FidoNet policy dictates that they not be
allowed in the nodelist, the space is saved anyway, so what
difference does it make?
o Many OtherNets use FidoNet technology, and rely on FidoNet's
nodelist format for their own. Because this is the case, any
change made in FidoNet standards would be felt in all OtherNets
using FidoNet-compatable software. It is impractical to ask
sysops to run two different sets of software to get mail.
In addition, some OtherNets (such as EchoNet) allow Pvt nodes in
their nodelists. This is dictated (or not dictated, as the case
may be) by their own policy documents. If FidoNet were to
delete Pvt nodes from the format, all OtherNets would have to do
the same, for reasons of practicality. This would then infringe
FidoNews 8-43 Page 22 28 Oct 1991
on the policies of OtherNets who allow Pvt addresses. Because
standards are policy-driven, the standards must take into
account policies that already exist in such networks as EchoNet
and MailNet. FidoNet has no right to change its standards in
such a way as to delete nodes from OtherNet's nodelists when
OtherNet's policy documents include these nodes.
FidoNet may delete Pvt addresses from its own nodelist, but not
from OtherNets' nodelists.
Some suggested the use of a binary file and/or hex coding of nodelist
flags. I elected to go with a straight seven-bit ASCII file the way I
did for reasons of simplicity. If I were to develop a binary file I
would have to take into account the file storage schemes for all systems
that might ever be used on FidoNet, from the IBM and Macintosh systems
to DEC Rainbows and Apple ][s. I'm not going to do that. As for hex
encoding, not all NCs are programmers and/or want to deal with the
problems that hex can present. Not only was an important issue size,
but also ease of use on the part of the *C structure. If it's too tough
to use they won't do it, and that would be pointless.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are a couple more comments to make. First, there was a seeming
lack of coordination with respect to the printing of the portions of
this article...here's why.
About a month ago I submitted NODELIS5.ART, Version 3.2.1, to Tom at
1:1/1. It was printed.
Shortly after I got that FidoNews I submitted 3.2.2, NODELIS6.ART. THAT
got printed, too. But . . .
I missed the issue it was printed in - 839. I didn't get my copy of
839 until after I got 840.
The article in 839 contains an error in the bps rate
section...observant readers can find it if they look. What happened
was I resent the fixed article to Tom and asked that it be
substituted for the original - but I didn't realize that the
original had already been published. So, Tom, according to his own
policy, published the fixed version in 840.
I picked up 840 and saw what had happened, and then noted that I got
no netmail about it (more on that later). And then it happened
again.
I seem to have missed 841 . . . so, when I started requesting 841
from my NC I got no response. A human call to 1:1/1 confirmed what
I feared - I'd missed another issue. I downloaded 842, and then
picked up 841 from a node in Pembroke Pines, Florida, and noticed
FidoNews 8-43 Page 23 28 Oct 1991
that I said I would publish a fourth segment "next week."
Well, "next week" was 842, but since I missed a week I didn't ever
get around to finishing writing it, and so it didn't go in until 843
- which SHOULD BE this issue.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
As I went on with this project I got a lot of encouragement, at least at
first. Most of it came from people as I've never heard of, and never
heard from again. Some people made useful suggestions, but many simply
griped that they didn't like the way things were done.
Okay - maybe I'm feeling a little like Felix right now. I've been
working at this for almost five months and have gotten very little
actual help. Yes, there are those of you who sent netmail and make a
contribution by giving an idea that later went in. But I got a lot of
griping about how it will require rewriting all the mailers out there,
about how we should go binary, about how we should delete privates.
Well, guys, the only person who has made a CONCRETE contribution to my
effort - something that we can all see - is Will Schlichtman, which is
why his name appears at the top of this article, and has since the
beginning of the release of Version 3.x.
I'm burnt out. When I asked how sysops in my area feel about my
proposal, the silence was amazing. I got a whopping two responses, one
of which said that the sysop was intentionally ignoring my proposal.
Out of about 200 sysops in my area, 1% isn't bad, I suppose.
As I said above, I got no mail from anyone at RC-level or above. I got
no mail from any mailer software author. I got no mail from an FTSC
member. I got one piece of mail from a FrontDoor Help node saying that
the idea wouldn't work because software would have to be rewritten.
Duuuh...
And so I'll go on my way. I'll leave you folks to figure it out for
yourselves, while those of us who run with the entire nodelist (but
without the disk space to support it) suffer in silence, having tried to
make a contribution but failed due to the inertia of the network (an
object at rest will stay at rest unless acted upon by an outside
force...well, I'm the outside force but I don't carry enough weight to
move 10,000 people). Have fun, folks. I've given my money to the phone
company.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Oh, yeah, the credits.
Aaron Goldblatt - Aaron created the nodelist design and wrote it
out, submitting it to FidoNews and himself to netmail flames for
FidoNews 8-43 Page 24 28 Oct 1991
his efforts.
Weldon Lotspeich - Mr. Lotspeich allowed Aaron to write the specs for
the nodelist during his second period Chemistry class.
Will Schlichtman - Will wrote the conversion program, SL2FW, used in
the development of this nodelist format. It converted the St.
Louis format, described in FTS-0005, into the Fort Worth format.
Will wrote it in C, too, so that everybody could use it, not just
IBM PCs.
Ben Baker and Rick Moore - Ben and Rick wrote and amended FTS-0005,
and they did an excellent job of it. Together they produced a
document that was clear, easy to read, and easy to use. Much of
their work found its way into this document because it was so
good.
Tom Jennings - Tom, as Editor of FidoNews, allowed publication of the
specs for the Fort Worth Nodelist as they were developed. In
addition, it should be noted that Tom is the one who got us all
into this mess.
-=*( Thanks, Tom. )*=-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
For a copy of the full FSC-style document, including all text that was
deleted from the FidoNews article, FREQ magic name FWNLSPEC from
1:130/28, USR HST/V.32/V.42bis. It is archived in SEA ARC v6.00.
For a copy of the conversion program used in the development of the Fort
Worth Format Nodelist, FREQ magic name SL2FW from 1:350/59.0, USR HST.
It is archived in PKWare ZIP v1.10.
As of now, development on the Fort Worth Format Nodelist ceases.
----------------------------------------------------------------------
by Eddie Rowe @ 1:19/124
A New Call to Arms - Event Horizons vs. Joe Sysop?
I don't know if this is old news or new news, but I thought worth
mentioning to my fellow Fight-O-Net "friends".
Until recently I've only know one thing about Event Horizons - they
do some mighty fine .GIFs. But did you know they have this rule
that says you are only allowed to have .GIFs of theirs that say
"Freely Distribute"? Did you also know that a BBS is only allowed
to have 20 of these things?
I'd heard of a so called limit, but my response was always "Yeah,
right." The reason wby I blew them off was the fact that they
put this "Freely Distribute" on almost everyone I've seen. But
my friend Patty Pickett over at Net 380 in Shreveport, LA mentioned
that she was purging ALL her Event Horizons since she had come
across a threatening text file detailing the saga of one such sysop
who had the same thoughts, only to have a user relay them to the
smuck at Event Horizon's personally. I dug out a disk that they
once sent me and LO AND BEHOLD it is there in yellow and white
small print! Jeez!
FidoNews 8-43 Page 25 28 Oct 1991
So what to do? I am not a huge BBS like many of you out there, and
I still have better things to do than count up to 20 gifs done by
the "Ding Dongs R Us" at Event Horizons. So I have joined Patty
in purging my system of ALL scans done by Event Horizons. It really
pisses me off that a company who gets free advertising has such a
"rule"....So you will find no GIFs on my system and it would be a
great pleasure to see everyone in Fidonet stick it to these fools!
Join me in purging your system of these cancers....or who knows...
it could be you against Event Horizons in court.
The text file containing notes back and forth between the sysop
and EH is well over a year old, but on my system as GIFWARN.ZIP
in the event you would like to see it. It is a BIG 6k. 8-)
----------------------------------------------------------------------
FidoNews 8-43 Page 26 28 Oct 1991
======================================================================
RANTS AND FLAMES
======================================================================
_(*#$_(*@#(* (*^$+)#(%&+| #$)%(&*#_$ @_#( @$
^@#+)(#&%$*+)$%&*+$*%&#@(@#_|)*%|)#%&)#*%&+(@#&*_+(@#*^&@###
*&#_($*&#$_(*#&$_(#*$&$ _(#$*#$+)#($&*+#)$ &#+$*&#
()*&#$_(&^#$_(#*$_#($^&#_$(^&#_$(&^#$_(&#^ damn right _(#^&$_(#^&
$*&#$_+(* #)$&(%($%+)($%*+$)%($* it's ugly _#&%^# &
#($_*#$_ FidoNet (*$&%_@#_(*&@#_(@*#&_ @#_(*&@#_(*
)*&#$ Flames *^$+)#(% (not for the timid) @_#(
(*#$_(*^@#+) and #_|)*% &+(@#&*_+(@#*^&@###
(#$*&#_($*&#$_(*#&$_(#* Rants *&+#$*&#+$*&#
)*&#$_(a regular feature)^&#_$(&^#$_ $^&#$_(#^
(*^#$_*#^&$)*#&$^%)#*$&^_#($*^&#_($ Section #&%^_
_(*#&$_(#* #($*& #$* _(*&@#_(@*# *&@#_(*&
)&*+_)*&+)*&+))&*(*&
(*&_(*&_(*&
----------------------------------------------------------------------
FidoNews 8-43 Page 27 28 Oct 1991
======================================================================
CLASSIFIEDS
======================================================================
ADVERTISEMENT POLICY: Submissions must be 20 lines or less each,
maximum two ads per advertiser, 70 characters per line maximum. No
control codes except CR and LF. (Refer to contact info at the end of
this newsletter for details.)
Please notify us if you have any trouble with an advertiser. FidoNews
does not endorse any products or services advertised here.
----------------------------------------------------------------------
FidoNews 8-43 Page 28 28 Oct 1991
======================================================================
NOTICES
======================================================================
The Interrupt Stack
1 Nov 1991
Area code 301 will split. Area code 410 will consist of the
northeastern part of Maryland, as well as the eastern shore. This will
include Baltimore and the surrounding area. Area 301 will include
southern and western parts of the state, including the areas around
Washington DC. Area 410 phones will answer to calls to area 301 until
November, 1992.
2 Nov 1991
Area code 213 fragments. Western, coastal, southern and eastern
portions of Los Angeles County will begin using area code 310. This
includes Los Angeles International Airport, West Los Angeles, San
Pedro and Whittier. Downtown Los Angeles and surrounding communities
(such as Hollywood and Montebello) will retain area code 213.
3 May 1992
The areacode for northern and central Georgia will change from 404 to
702. The Atlanta metro area will remain area code 404. Area code 912 in
southern Georgia will remain the same. Affected areas will share both
the 404 and the 702 area code from May 3, 1992 until August 3, 1992 when
the change will become permanent.
1 Dec 1993
Tenth anniversary of Fido Version 1 release.
5 Jun 1997
David Dodell's 40th Birthday
If you have something which you would like to see on this calendar,
please send a message to FidoNet node 1:1/1.
----------------------------------------------------------------------
FidoNews 8-43 Page 29 28 Oct 1991
======================================================================
LATEST VERSIONS
======================================================================
Latest Greatest SoftWare Versions
Last Update: 10/27/91
----------------------------------------------------------------------
SOFTWARE AUTHORS, AND/OR SUPPORT PERSONNEL, BE ADVISED...
Your current listing in the version list will be dropped it I do not
hear from you by October 31, 1991.
I need the following from those who have their software listed:
1. Software Name & Version
2. FileName.Ext
3. Support Board Network Address
4. Support Board Phone Number
Send your update notices to David French,
1:103/950
45:512/105
65:571/2
69:11/108
93:9702/2
----------------------------------------------------------------------
MS-DOS Systems
--------------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
Aurora 1.32b* BinkleyTerm 2.40 2DAPoint 1.41*
DMG 2.93 D'Bridge 1.30 ARCAsim 2.31
DreamBBS 1.05@ Dutchie 2.90c ARCmail 2.07
Fido/FidoNet 12.21+ Dreamer 1.06 Areafix 1.20@
Genesis Deluxe 3.1 FrontDoor 2.02* ConfMail 4.00
GSBBS 3.02 InterMail 2.01 Crossnet 1.5
Kitten 1.01 Milqtoast 1.00 DEMM 1.06@
Lynx 1.30 PreNM 1.48* DGMM 1.06@
Maximus 1.02 SEAdog 4.60 DOMAIN 1.42
Merlin 1.39n@ SEAmail 1.01@ EEngine 0.32*
Opus 1.71 TIMS 1.0(Mod8) EMM 2.10*
PCBoard 14.5a EZPoint 2.1@
Phoenix 1.3 4Dog/4DMatrix 1.18
ProBoard 1.16 NodeList Utilities FGroup 1.00
QuickBBS 2.75* Name Version FNPGate 2.70
RBBS 17.3b -------------------- GateWorks 3.06e*
RBBSmail 17.3b EditNL 4.00 Gmail 2.05
RemoteAccess 1.01 FDND 1.10 GMD 3.00*
SimplexBBS 1.04.02+ MakeNL 2.31 GMM 1.21@
SLBBS 2.15b Parselst 1.33* GoldEd 2.31p
FidoNews 8-43 Page 30 28 Oct 1991
Socrates 1.11 Prune 1.40 GROUP 2.23
SuperBBS 1.10 SysNL 3.14 GUS 1.40*
TAG 2.5g XlatList 2.90 HeadEdit 1.18
TBBS 2.1 XlaxNode/Diff 2.52 IMAIL 1.20
TComm/TCommNet 3.4 InterPCB 1.31
Telegard 2.5 Lola 1.01d
TPBoard 6.1 Compression MSG 4.2*
TriTel 1.11 Utilities MSGED 2.06
Wildcat! 2.55 Name Version MsgLnk 1.0c@
WWIV 4.20 -------------------- MsgMstr 2.02*
XBBS 1.17 ARC 7.12* MsgNum 4.16d@
ARJ 2.20 MSGTOSS 1.3
HYPER 2.50 Netsex 2.00b*@
LHA 2.13 Oliver 1.0a
PAK 2.51 PolyXarc 2.1a
PKPak 3.61 QM 1.00a*
PKZip 1.10 QSort 4.04
Raid 1.00@
ScanToss 1.28
Sirius 1.0x
SLMAIL 1.36
StarLink 1.01
TagMail 2.41
TCOMMail 2.2
Telemail 1.27
TGroup 1.13
TMail 1.21
TPBNetEd 3.2
Tosscan 1.00
UFGATE 1.03
VPurge 4.09e*@
WildMail 1.01b*
XRS 4.51*
XST 2.3e
ZmailH 1.25*
OS/2 Systems
------------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
Kitten 1.01@ BinkleyTerm 2.50* ARC 7.12
Maximus-CBCS 1.02 BinkleyTerm(S) 2.50*@ ARC2 6.01*
SimplexBBS 1.04.02*+ BinkleyTerm/2-MT ConfMail 4.00
1.40.02*@ EchoStat 6.0
SEAmail 1.01@ EZPoint 2.1@
FGroup 1.00@
GROUP 2.23@
LH2 2.11*
FidoNews 8-43 Page 31 28 Oct 1991
MSG 4.2*
MsgEd 2.06c*
MsgLink 1.0c
MsgNum 4.16d*
oMMM 1.52
Omail 3.1
Parselst 1.33*
PKZip 1.02
PMSnoop 1.30*@
PolyXOS2 2.1a
QSort 2.1
Raid 1.0
Remapper 1.2
Tick 2.0
VPurge 4.09e*
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, | MSGLNK 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
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
FidoNews 8-43 Page 32 28 Oct 1991
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 Import 3.2
Host 2.12T10 LHARC 0.41
MacArc 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.0 SunDial 3.2
CounterPoint 1.09 TExport 1.92
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
-------------------- -------------------- --------------------
DLG Pro. 0.96b BinkleyTerm 1.00 Areafix 1.48
Falcon CBCS 1.00 TrapDoor 1.80* AReceipt 1.5
Paragon 2.082+ WelMat 0.44 booz 1.01
TransAmiga 1.07 ChameleonEdit 0.10
XenoLink 1.0@ Compression ConfMail 1.12
Utilities ElectricHerald 1.66
NodeList Utilities Name Version GCChost 3.6b@
Name Version -------------------- Login 0.18
-------------------- AmigArc 0.23 MessageFilter 1.52
ParseLst 1.64 booz 1.01 Message View 1.12@
Skyparse 2.30 LHARC 1.30 oMMM 1.49b
TrapList 1.40 LZ 1.92 PkAX 1.00
FidoNews 8-43 Page 33 28 Oct 1991
PkAX 1.00 PolyxAmy 2.02
UnZip 4.1 RMB 1.30
Zippy (Unzip) 1.25 Roof 44.03
Zoo 2.01 RoboWriter 1.02
Rsh 4.06
|Contact Maximilian Hantsch, 2:310/6| Tick 0.75
TrapToss 1.20*
Yuck! 2.02*
Atari ST/TT
-----------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
FIDOdoor/ST 2.5.1* BinkleyTerm 22.40n9* Burep 1.1@
FiFo 2.1v The BOX 1.20 ComScan 1.04
LED ST 1.00 ConfMail 4.10
MSGED 1.99* EchoFix 1.20
QuickBBS/ST 1.04*@ Echoscan 1.10
FastPack 1.20
FDrenum 2.5.2*
Compression Import 1.14
Utilities oMMM 1.40
Name Version Pack 1.00
-------------------- Parselist 1.30
ARC 6.02 sTICK/Hatch 5.50
LHARC 2.01e* Trenum 0.10
PackConvert 1.10
STZIP 0.90*
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)
--------------------------------------
FidoNews 8-43 Page 34 28 Oct 1991
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
# - Commercial SoftWare(Not In Use Yet)
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Utility Authors: Please help keep this list up to date by reporting
all new versions to 1:103/950 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/950
----------------------------------------------------------------------
FidoNews 8-43 Page 35 28 Oct 1991
------- 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 8-43 Page 36 28 Oct 1991
"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 Copy Permalink