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

1610 lines
69 KiB
Plaintext
Raw Normal View History

Initial commit
2021-04-15 13:31:59 -05:00
F I D O N E W S -- | Vol. 10 No. 7 (15 February 1993)
A newsletter of the |
FidoNet BBS community | Published by:
_ |
/ \ | "FidoNews" BBS
/|oo \ | +1-415-863-2739
(_| /_) | NEW!--> 1:1/23@FidoNet
_`@/_ \ _ | editor@fidonews.fidonet.org
| | \ \\ |
| (*) | \ )) | Editors:
|__U__| / \// | Tom Jennings
_//|| _\ / | Tim Pozar
(_/(_|(____/ |
(jm) | Newspapers should have no friends.
| -- JOSEPH PULITZER
----------------------------+---------------------------------------
/*********************************************************************
* IMPORTANT NOTE: The FidoNet address for FidoNews has been changed. *
* The new address is: *
* *
* FidoNews = 1:1/23 *
* *
* Starting January 1993 email sent to the old address will not be *
* forwarded! You were warned! *
*********************************************************************/
For information, copyrights, article submissions, obtaining copies and
other boring but important details, please refer to the end of this
file.
Table of Contents
1. EDITORIAL ..................................................... 1
And the winner is ............................................. 1
2. ARTICLES ...................................................... 4
Fidonet: Choice of a New Generation(?) ........................ 4
Review of the Zyxel U-1496E modem ............................. 5
Time to Bring Policy 4 into the 1990's ........................ 18
More Insantiy In Fidonet! ..................................... 19
A_THEIST Echo now on Backbone! ................................ 21
The GlobalNet Network (92) .................................... 22
The INTERNET echo is now available! ........................... 23
Online Magazine Standard Proposal ............................. 24
MENSANS_ONLY Echo Notice ...................................... 25
NEW ECHO FOR ANTIQUE RADIO COLLECTORS ......................... 27
SKEPTIC Echo now on the Zone 1 Backbone! ...................... 27
3. FIDONEWS INFORMATION .......................................... 29
FidoNews 10-07 Page 1 15 Feb 1993
======================================================================
EDITORIAL
======================================================================
And the winner is...
by Tom Jennings (1:1/23)
Let's gets some small-time business out of the way. Let's take a look
at what appears to me to be yet another case of bureaucratic
silliness, finger-pointing, name-calling and other useless friction.
OK, the nodelist and nodediff remains broken. A data-format error
causes nodelist processors on many FidoNet nodes/BBSs to break. The
immediate, problem-at-hand is, there's an extraneous control character
embedded in one net's nodelist fragment. It is, in fact, not supposed
to be there. Each of these fragments is maintained by each network's
NC, who passes it up to each ZC, who compiles the complete nodelist
from all the fragments. From this master nodelist is created the
nodediff, which is distributed back to each local network. This is
more-or-less the process, minus lots of details.
MAKENL, written before most of you even know FidoNet existed, checks
for lots of potential errors on these many nodelist fragments. It
however doesn't check for this particular error. It would be nice of
it did, obviously.
So we have a number of possible solutions. A reasonable one (of many)
might be, to edit out the unwanted control character from the nodelist
fragment in question, and then to consider whether it's worth changing
MAKENL to check for Yet One More Error.
But no, instead we piss and moan, complain, point fingers, generate
huge volumes of CC'd rants complete with dozen-level quotes,
pontifications, etc etc ad infinitum.
Hmm... maybe we need... another POLICY document! Another level of
/0's! A new scapegoat!
How about a text editor, and fix the goddamned text file?
A few weeks ago, I casually mentioned that maybe MAKENL has a problem,
and should be looked at. A number of people took this to mean I wanted
to be part of every conversation regarding MAKENL or the nodelist -- I
am not interested, so you may stop now, please.
Looking back on what I wrote, I remain satisfied. In light of the new
information, it looks like yes, MAKENL could be made to check for this
error as well as the ones it already checks for, but in fact MAKENL
works just fine, and the data given it is AFU -- hence GIGO.
FidoNews 10-07 Page 2 15 Feb 1993
Why people have such emotional investments in this stuff is beyond me.
* * * * *
I have finally chosen a new heir-apparent to the FidoNews fortune.
The new victim I mean victims I mean volunteers for life are:
Sylvia Maxwell & Donald Tees, FidoNet 1:221/192
There were actually a number of excellent candidates, really. A
diverse bunch. You can read what they wrote, buried in the file NEW-ED
available from the FidoNews BBS. Here are some of the highlights of my
reasoning: They are from not-the-US. There are two of them; there have
times when having a co-editor has saved me. They seem to be the right
kind of whackos. They are not part of any existing /0 conspiracy, as
far as I can tell. And last but not least, they seem to have a grasp
of FidoNews' peculiar and subtle position within FidoNet, and value
FidoNet's independence highly. I think I trust 'em.
As most of you probably know, there is no set process for picking a
FidoNews editor. It used to matter a whole lot less. It will matter
more and more. The present editor (me) is fairly well known within
FidoNet, ahem. Previous editors were also well known within FidoNet,
especially during their reigns.
I don't know what the process will be for choosing the next editor. I
know that I am personally am not comfortable with mob-rule, aka
"democracy". It ain't a slot to fill, it's a peculiar set of skills
necessary. What those requirements will be will change with the times,
as they have in the past. I think what I did, though hurried, is about
right, for this point in time. It would have been OK years ago, and
maybe years from now, but we won't know until we get there. WE CAN'T
KNOW FOR SURE UNTIL WE GET THERE. Let's not trade off flexibility, and
the fun and satisfaction of banging heads with the future, for the
"security" of bureaucratic rule. We've got enough of that out in the
Big Room*, and no one is going to die if we screw up.
FidoNet has not succeeded by making correct plans in 1984, for 1993,
and certianly won't survive if it makes hard plans for 2001. We got
here, and quite reliably, safely and fun! by being flexible. In spite
of the annual sky-is-falling contests we seem to love, FidoNet remains
incredibly robust and efficient. We splinter off dozens of new
networks all the time; what Randy Bush calls "SourGrapesNet"s he also
recognizes as a healthy thing; communications is supposed to serve
peoples' needs, dammit, not some monolithic one-world-one-network
heirarchic fantasy.
"ONE PLANET -- FIVE BILLION SOVEREIGN STATES!"
FidoNews 10-07 Page 3 15 Feb 1993
Do you really understand what that means? This is how I treat the
world. You can quote me.
-----
* the Big Room is the large place where it's bright during the day
and dark at night with little bright specks. Some of us venture there
occasionally, others rarely.
----------------------------------------------------------------------
FidoNews 10-07 Page 4 15 Feb 1993
======================================================================
ARTICLES
======================================================================
By Isaac Salpeter
The Youth of Fidonet.
In many senses I am your everyday average sysop. I have a v32
modem like 3800 other sysops in the nodelist. I am very individualistic
and fiercely independent, like many other sysops. I have never been an
NC or for that matter any other administrator in Fidonet. My bulletin
board is fairly locally-oriented, like the majority of those out there
who have a limited budget and are running their system as a hobby,
rather than a business. OK, so my file bases set me a little bit apart
because I specialize in sound & graphics, but that's not really very.
I do not carry any national echoes at present. Most of my users only
read and post on message bases local to my system. But these are not
what makes me or my system so different from others.
I am fifteen years old.
Wait! Before you punch the Page Down key, muttering under your
breath "stupid kid", I think I have something valid to say.
I set up this BBS about 5 months ago, but I have been a regular
user of bulletin boards for over 5 years. I have, since I was 4 years
old, used Apple ]['s, a decrepit PS/2 model 30, several Macs, the
local university mainframe, a dumb terminal, and, for the past two
years, my current 386'er to get my "digital fix". Right now, as well
as attending school and running the BBS, I do consulting for the City
of Pensacola as a community service. So, while it was not always true,
I consider myself fairly literate in the world of computers and BBS's.
"So what?", you say.
The reason I bring this up is because of the alarming hostility
towards most minors that I have seen from users and sysops over the
years, including "adult" users of Fidonet. I know, I've heard all the
jokes and anecdotes about so-called "d00dz" (generally minors who act
immature, arrogant, and annoying, and who do so publicly and through
the modem). I know there is a kernel of truth in this (there are a
few in town who run "B-Bordz"). However, I am irked by the notion
perpetuated by quite a large number of "adults" that this stereotype
accurately fits all minors. Here's an example:
In town, there is one other Fido sysop who is a minor. He has
run a BBS for about a year, I believe. He is an extremely intelligent
individual, and the care he puts into his system is apparent to all
his users. I have yet to see him be anything but friendly and fair,
which is more than could be said for a lot of adult sysops. And yet
despite this, he was and is just about completely disregarded by
several local sysops as "just a kid with a modem". Mind you, this
treatment has ebbed slowly, and when I joined Fidonet just before the
new year, this sort of "stoopid kid" talk was not really present, (at
FidoNews 10-07 Page 5 15 Feb 1993
least not in "official" channels). Nevertheless, it is time for the
majority of Fidonet (pun intended) to step back and reevaluate their
positions on minors in Fidonet. I suggest these questions as ones
adult sysops should ask themselves before insulting or dismissing a
minor in the net:
1. Is this kid just cocky or does he/she actually know something?
2. Do or will I dismiss or shout down his/her opinions because of
my own arrogance?
3. Am I being condescending to this person because of his/her age?
4. What has this user/sysop done to me to deserve sub-standard
treatment?
And most importantly:
5. How would I like to be treated the same way, were *I* in his/her
position?
I think that if everyone honestly asks themselves these questions,
many people would come to the realization that not all minors are
arrogant, ignorant, and just putting up a front. I know there are bad
apples among the youth, but I fear that without some sort of change
in behaviour by the adults of our "hobby" (addiction :-)), that the
future of FidoNet, and even the hobby of BBS'ing will wane as more
and more minors feel less and less welcome in the realm of computers.
OK, say what you will. Perhaps you agree with me, perhaps you
think I'm just a fool. But whatever you think on this subject, let me
know, or better yet, let your NC, your net, your local BBS community
know how you feel. If you agree, hey, great! You can make a difference.
Encourage young users and sysops, let them know that they are welcome!
If you don't like what I say, well, write me hate mail, for all I
care. I've gotten it before, and my skin is not thin, so why waste
your time? Now, if you have some serious, logical argument against the
youth of Fidonet, then by all means, I'd be glad to hear from you.
Otherwise, direct replies to the NULL device.
Thanks!
Isaac Salpeter
1:3612/380
----------------------------------------------------------------------
by Tom Jennings
FidoNet 1:125/111
Internet tomj@fido.wps.com
FidoNews 10-07 Page 6 15 Feb 1993
BBS-usable hardware fashions come and go; very few are worth
remembering. I say "BBS-usable" because so little of the hardware we
use was designed for bulletin boards.
I've been using bulletin boards since 1977, and I've run one
continuously since 1983. The only devices worthy of mention in all
those years are: the original Hayes S-100 board modem (ca. 1976?); the
Hayes Smartmodem 1200 (ca. 1982?); the US Robotics Courier 2400 (the
first time a manufacturer sought the BBS community's input); the US
Robotics Courier HST (affordable high-speed); and the National 16550
FIFO'ed UART (how could we live without it). To this short list, I'd
add the Zyxel U-1496 series, which I've had the pleasure to work with
these last few months.
MY INSTALLATION
I have two rather disparate modem installations in my network here;
FidoNet/dialup BBS, and direct-connect Internet. The features and
desirable modem behavior for each is quite different. A modem great at
BBSing is frequently terrible at unattended Internet use, and vice
versa.
While obviously the highest possible speed is always desired, I'll
always trade off reliability for performance; it doesn't matter how
fast it is, if it won't stay running! Reliability and consistency are
the most important "features" of a modem, and the most difficult to
account for. I want my modems to be *boring*. One doesn't need
"excitement" in complex devices that need to run 24 hours a day.
The 1496E has been about perfect: boringly reliable, a drop-in to
install, and no tradeoff on speed; as a matter of fact it's the
fastest all-around modem I've ever used.
My FidoNet BBS, "Fido Software / FidoNews", is a 286-clone running my
Fido/FidoNet program. Like many systems, mine doubles as a
public-access BBS, as well as a FidoNet network interface. What's
important for a BBS is reliability in an environment of many
connects/disconnects/bad connections per day. Just as important is
compatibility with other (BBS callers') modems. Human callers use
every and any sort of modem, from the most popular to the most
obscure, and every imaginable (and then some) terminal program. Few
BBSs today rely on the modem to "auto-answer"; modern software handles
all aspects of BBS incoming-call negotiation to maximize performance
and error handling. A busy BBS modem might handle 100 calls per day,
not including connections failed due to operator error, busy signal,
noisy phone lines, etc.
FidoNet uses the same sophisticated modem handling as BBSs, but does
something that makes FidoNet unique -- dialing out to other FidoNet
systems to automatedly deliver messages and files. A busy FidoNet
system might make many tens of phone calls a day throughout a broad
geographical area.
FidoNews 10-07 Page 7 15 Feb 1993
Performance in BBSing and FidoNet means, besides reliability, BYTES
PER SECOND! We have protocols (ZMODEM, off-line compression such as
ARC, etc) optimized to squeeze every last second of connect times,
since as amateurs (mostly) we're more sensitive to the cost of every
minute we stay online.
My other modem installation connects my 386BSD (freeware Berkeley
unix) computer to the Internet. The inter-net is a large connection of
computers ("hosts") and networks inter-connected via ethernet, modems,
T3, radio, microwave, and any other damned thing humans have managed
to cram 1's and 0's through -- including modems. A "connection to the
internet" simply means a connection to another host connected to...
Most Internet hosts are instantaneously connected to all other hosts,
24 hours/day. In under 1 second, I can find out how long my friend
Alekz's terminal has been idle in the library at Johns Hopkins
University in Maryland, from my little 386 in San Francisco. The
amount of data to determine this is small, but it takes a number of
back and forth queries and responses, each taking a few hundred
milliseconds. Contrast this to the BBS/FidoNet paradigm, of staying
idle and "offline" with intense bursts of activity transferring as
much data as possible in a short period of time.
Many of the two million (last best guess) Internet hosts are connected
with a protocol called, surprise, Internet Protocol (IP). IP knows
nothing about modems or phone lines; it assumes a point-to-point
connection, full-duplex, up and running 24 hours/day. Copper wire (or
functional equivalent) is the perfect IP medium. IP behaves vaguely
like Kermit or XMODEM, in that there are small packets with ACK/NAK
(response) packets for each packet or group of packets. It is most
definitely *not* optimized for maximum-data-throughput alone.
Since us mere mortals can't afford high-speed leased lines ($100/month
and up for short runs plus $1000 CSU/DSU hardware), we resort to using
BBS-style modems and plain old telephone service (POTS). A phone line
and modem goes at my house, a phone line and modem to the nearest
Internet-connected host, then you make exactly one phone call -- and
never disconnect it! Many links require manual intervention when the
line drops (operator tripped over the cord, etc) to bring the link
back up. This is generally adequate for IP use.
Because IP is uncooperative in establishing and maintaining a
connection, unlike FidoNet, features for unattended modem use are most
important, besides the constant of reliability. Performance for IP
also requires something that FidoNet has designed around; turnaround
time; the time it takes a pair of modems to flip direction, back and
forth; SEND RECEIVE SEND RECEIVE ... more on this later.
FidoNews 10-07 Page 8 15 Feb 1993
Contrast the BBS/FidoNet and the Internet/IP requirements, and you'll
see there's more than a bit of difference. BBS/FidoNet likes lots of
interactive command-rich features, and IP wants solid unattended-use
auto-answer reliability.
MY TEST SETUP
For testing I used two 80386 hard-disk clone computers, each with a
Zyxel U-1496E (external model) modem attached. For the DOS-based tests
I ran DOS 5.0, Ray Gwinn's X00 FOSSIL driver, and my homebrew FidoTerm
program. For Internet-based tests I used 386BSD 0.1.
Before all testing, I restored the modems to factory-default settings
with the "AT&F" command to ensure consistency.
In all cases the modem to computer link was locked at 56,700 baud, and
used hardware flow control, which is smartly the Zyxel factory
default. Unlike older, simpler (slower!) modems where you simply set
the baud rate to the maximum and forgot it, high-speed modems' actual
rate is negotiated by the modems at connect time, and varies during a
session; the flow of data to/from the modem must be regulated, and
hardware flow control does this.
When choosing a locked rate, a good rule of thumb is to pick the
lowest speed that is still higher than the maximum data rate you will
actually get. Setting baud rates needlessly high will simply lower
reliability and increase processor-interrupt overhead.
THE MODEM
I tested the Zyxel for performance and operational behavior, rather
than the commands and features. The command set is more than
complete. They smartly chose the basic functions to be compatible with
"most" modems, including most of the "AT&" extended command set of
Hayes and US Robotics.
The Zyxel however has a truly daunting proprietary command set. It
seems there's a command or S-register for possible function, and then
some, and I hear that the PLUS series has even more. Every week it
seems I get yet another list of not-in-the-manual commands from the
huge and growing Zyxel support/user/hacker community.
The 1496E has the usual excessive array of modem result codes given
after a dial (ATD) or answer or originate commands (ATA, ATO). It's
not their fault that there are currently about 25 modem protocols and
variants in use today, but it sure is a pain to configure software
these days. With some of my older software (such as Fido/FidoNet) I
had to suppress most of them (ATX command); with newer programs, or
ones under my control such as FidoTerm dialing scripts, I was able to
use every feature. (The ATX command merely suppresses the extended
connect/status messages; the modem will still communicate at the
FidoNews 10-07 Page 9 15 Feb 1993
highest speed possible.)
I'll ignore the FAX features and commands, which are completely out of
my area of interest and expertise. It seems though that Zyxel has
implemented what looks to be the future FAX standard. I'll leave it
for others to cover.
THROUGHPUT
I'm fairly conservative when testing throughput. Back in 1987 or so
when FidoNet mailer packages started supporting high-speed modems, it
became all the rage to display "bytes per second" for each session. It
was no coincidence that the software displaying the highest number
became most admired, never mind that the other end of the very same
session displayed a lower, more conservative number... My
Fido/FidoNet program, for example, measures "bytes per second" from
start to end of the entire session, which is more realistic but less
exciting. Oh well.
I kept this attitude in my testing of the Zyxel modems. I don't
measure "peak" speeds during some most-optimal part of a test, but
include startup and finish times, disk file open and close, etc. I
feel this approach is more likely to reflect reality.
On to the actual testing. I concentrated on two areas in basic
data-throughput, pure ASCII text and pre-compressed binary, and
tested turnaround latency, ie. modem responsiveness.
PURE ASCII:
These are the numbers that modem manufacturers love to brag about.
Text, using standard ASCII encoding, is very redundant; using nifty
mathematical tricks compression techniques can squash text to a
fraction of it's original size. Presto! instant modem speed increase!
(This is what the V.42 stuff does, amongst other things.)
For testing ASCII text throughput, I used an industry-standard test
called Bit Error Rate Testing, or BERT. It works by having one end
issue a repeating test pattern such as "THE QUICK BROWN FOX JUMPS OVER
THE LAZY DOG" and with the receiving end comparing the incoming bit
stream against the same test pattern; error bits (not bytes) are
counted. BERT has enough hard statistics to give you a pretty good
handle on things.
TEST #1: direct modem-to-modem, unidirectional pure ASCII.
DTE speed locked at 57600 baud.
FidoNews 10-07 Page 10 15 Feb 1993
+MODE: Receive-only
+DURATION: 60:10
+LOG INTERVAL: 5:00
---------- Errors -----------
Time Bits Rec'd Bits Blocks Seconds Resyncs
=13:34:22 0 0 0 0:00 0
=13:39:26 12,369,312 0 0 0:00 0
=13:44:30 24,722,112 0 0 0:00 0
=13:49:36 37,150,616 0 0 0:00 0
...
=14:25:12 123,967,184 0 0 0:00 0
=14:30:16 136,319,880 0 0 0:00 0
-14:34:30 146,231,616 0 0 0:00 0
-END: 14:34:30
-RECEIVE BYTES/SEC: 4051
-BER: 1.00*10E-07
OK, so Zyxel has something to brag about; 4051 bytes/sec is fast! Note
that the "Recv'd Bits" column counts bits, not bytes; there are eight
data bits per byte. Note also the "Errored bits/blocks/seconds"
columns. BERT does not correct errors, it merely counts them. It is
meant to measure the error rate of a communications link. Obviously
with this particular test we should have a very low error rate; as
indicated, it's less than one error out of 10 to the seventh power,
ie. zero.
This is NOT a real-life test; you will probably not get this
downloading even a pure text file; telephone lines were not used. The
modems were connected together with an RJ-11 cord, one was commanded
"ATA" and the other "ATO". This is "flat out downhill with the wind";
you can however use it as a relative measure of telephone line
quality.
TEST #2: Dialup, unidirectional pure ASCII.
DTE speed locked at 57600 baud.
+MODE: Receive-only
+DURATION: 60:10
+LOG INTERVAL: 5:00
---------- Errors -----------
Time Rec'd Bits Blocks Seconds Resyncs
=15:37:04 0 0 0 0:00 0
=15:42:08 11,027,256 0 0 0:00 0
=15:47:12 22,975,176 0 0 0:00 0
=15:52:18 34,932,344 0 0 0:00 0
=15:57:24 46,896,248 0 0 0:00 0
...
=16:27:54 117,567,408 0 0 0:00 0
=16:32:58 129,486,280 0 0 0:00 0
-16:37:12 139,430,784 0 0 0:00 0
-END: 16:37:12
-RECEIVE BYTES/SEC: 3862
-BER: < 1.00*10E-07
FidoNews 10-07 Page 11 15 Feb 1993
Now this test was done with phone lines in a realistic manner. I live
in an old industrial area, the phone lines aren't new, but not
particularly bad either. The central office is about 5 miles away, so
this is probably over 10 miles of copper. No fiber here yet!
Note how the throughput dropped about 5%. This is the direct effect of
pushing data over phone lines vs. about 4 feet of cord. Downloads of
large, uncompressed text files will see this speed; it will also make
BBS bulletins very snappy!
TEST #3: Dialup, bidirectional pure ASCII.
DTE speed locked at 57600 baud.
+MODE: Bidirectional
+LOG INTERVAL: 3:00
---------- Errors -----------
Time Bits Sent Bits Rec'd Bits Blocks Seconds Resyncs
=20:47:54 184 3752 0 0 0:00 0
=20:50:56 6,326,840 5,877,464 0 0 0:00 0
=20:54:00 12,512,552 12,095,040 0 0 0:00 0
=20:57:04 18,850,984 17,760,856 0 0 0:00 0
=21:00:10 25,479,032 22,622,432 0 0 0:00 0
...
=21:21:46 70,366,384 59,473,344 0 0 0:00 0
=21:23:58 OPERATOR INTERRUPTION START
=21:23:58 OPERATOR INTERRUPTION END
=21:25:00 76,999,584 60,747,280 23 1 0:01 1
-21:26:50 80,421,800 60,922,264 23 1 0:01 1
-END: 21:26:50
-REASON: OPERATOR ABORT
-DURATION: 38:56
-SEND BYTES/SEC: 3443
-RECEIVE BYTES/SEC: 2608
-BER: 3.77*10E-07
This was a difficult test to perform, and I failed -- modem
performance exceeded my test setup! My goal was to saturate the modem
in both directions simultaneously, and see how the sum total
throughput compared to the unidirectional tests. I never got there.
My poor processors were overloaded trying to send and receive at these
speeds; as a matter of fact, at one point I had to manually pause it
to keep the computer out of saturation! Hence the relatively-low
receive rate.
Note that this time the error rate is not zero; I can assure you this
is due to the computer dropping bits when I manually broke in, rather
than the modem.
FidoNews 10-07 Page 12 15 Feb 1993
The real problem is not that a 386 can't handle 50,000 bytes per
second; disks are ten times that speed. The problem is we're running
into the fundamental limits of Async ports, and while brute-force
processor-clock speed helps, it's not the ultimate solution. More on
this later.
TEST #4: Dialup, ZMODEM file transfer.
DTE locked at 56700 baud.
+17:52:12 File #001: TESTFILE.1, 641,304 bytes, Zmodem
-17:57:40 File complete (5:34, 1920 bytes/sec)
+17:57:42 File #002: TESTFILE.1, 641,304 bytes, Zmodem
-18:03:12 File complete (11:05, 1928 bytes/sec)
TEST #5: Dialup, ZMODEM file transfer.
DTE locked at 38400 baud.
+18:52:22 File #001: TESTFILE.2, 1,923,912 bytes, Zmodem
-19:08:50 File complete (16:30, 1943 bytes/sec)
OK, some real-life tests finally. The files used for testing was
NODELIST.015, a recent FidoNet nodelist, pre-compressed with LHARC
2.12, to somewhat foil V.42bis compression.
These numbers are very conservative; they are file transfer end-to-end
times, including file open, close, read and write, and do *not* include
file-transfer protocol overhead bytes. These are very pessimum, and
are the numbers real people will get with real files and clocks.
1943 bytes/second is damn fast.
LATENCY
Modem latency is usually ignored, because it's hard to test and the
results are not obvious. Latency, or turnaround time, is the time it
takes the modem to send/receive data in alternating directions; send,
receive, send, receive, ... the lower the latency, the better. Plain
copper wire has zero latency. 2400-baud and below only modems are
usually pretty good, because they are much simpler internally.
Most people who have used high-speed modems, especially older designs,
know what latency is about... the sluggish response to your typing on
a BBS that otherwise does fast downloads. Latency is the thing that
killed XMODEM good and dead as far as high-performance was concerned.
FidoNews 10-07 Page 13 15 Feb 1993
In the BBS and FidoNet world, things are optimized to not rely on
latency wherever possible. ZMODEM's strongest feature is it's
streaming mode that minimizes latency effects.
TEST #6: Latency using IP over dialup.
DTE locked at 38400 baud.
For the first test I used my Internet IP link. My internet router, a
386SX running NOS, is connected to another router at my internet
connect site across town, which is a 386DX running 386BSD unix.
Testing consisted of using "ping"; Ping is a feature built-in to IP to
check a link; a small block of data is sent out to a (specified)
remote host, which immediately returns it back to the sender -- ping!
When you ping across a single, simple modem link, you can measure the
time the packet takes to traverse that link.
There are however complications. First of all, this is serial
communications; each byte is serialized, so that even under ideal
conditions sending and receiving one byte of data takes time. Ideally
one data byte would be sufficient; however the smallest packet my IP
implementation will do is 16 bytes (8 data, 8 overhead). Since the
test is turnaround latency, ie. out and back, the latency times are
for two modems in series. On top of this, the software itself is a
complex real-time multitasking system, and there is non-zero latency
within the software itself. However most of this can be untangled,
with care.
The basic test consisted of 500 or so pings from my router, to the
remote router, and back. My router calculated an average turnaround
time of 180 milliseconds, and I watched to make sure the numbers
stayed sane; the lowest I saw was about 150, the highest about 220.
I then did another 500 pings on my router box to it's own internal
interface; this resulted in an average turnaround time of 9
milliseconds of software overhead alone. I repeated this test on the
remote router and got zero milliseconds. This is probably means
something under 1 millisecond, which is reasonable, given that 386BSD
unix is well-tuned for TCP/IP.
The results of this test depend on how you want to look at what's
left, which appears to be approximately 171 millisecond total loop
time (180 minus 9). For comparison purposes, this is enough. In a
series of messages forwarded to me from some internet mailing lists,
there are many people interested in modem latency. According to
various other informal tests, the Zyxel is better than most, with only
one modem, the Digicom 9624LE+ significantly faster. (Their numbers
were 203 milliseconds for the Zyxel and 163 milliseconds for the
Digicom, using a very different and more complex test environment.)
FidoNews 10-07 Page 14 15 Feb 1993
TEST #7: Benchmark latency, direct modem-to-modem.
DTE locked at 56700 baud.
I did however want to get "real numbers", ie. an actual measurement of
modem turnaround latency. Without a large amount of comparative data,
however, these numbers aren't much use. I believe the method is a good
one however and I'd like to see more testing done in this area.
My test environment in this case was again the two 386 machines
coupled with two 1496E's. The test mechanism was plain old vanilla
XMODEM transmission of a pre-compressed text file, once again
NODELIST.015 compressed with LHARC 2.12.
XMODEM is convenient because it transmits data as a series of blocks,
each containing 128 bytes of data. Each block requires an ASCII 'ACK'
character before the next block is sent; therefore there are two
turnarounds per block (same as a ping). The file was exactly 641,304
bytes long, sent as exactly 5011 blocks (rounded up to the nearest 128
bytes); the entire transfer was 666,464 bytes including the
file-transfer protocol overhead data.
We can use the data from the ZMODEM send of the test file for
comparison; both ZMODEM and XMODEM need to open files, write to disk,
display status info on-screen, etc, minimizing the number of
variables.
+17:38:58 File #001: TESTFILE.1, Xmodem/CRC [641,304 bytes]
-17:58:10 File complete (19:13, 556 bytes/sec)
+17:52:12 File #001: TESTFILE.1, 641,304 bytes, Zmodem
-17:57:40 File complete (5:34, 1920 bytes/sec)
The difference in time between these two is the turnaround latency.
With 5011 blocks sent we can easily calculate the latency per block
(remember two turnarounds per block):
19:13 - 05:34 = 13:39 time difference
5011 / 13:39 = .163 sec/block turnaround time
This jibes pretty well with my less-rigorous ping testing, and that
of others.
UNATTENDED USE
Another major aspect of Internet type use that modems frequently need to
be completely unattended. In the Internet cooperative that I manage,
the San Francisco end has a dozen modems of various types. The Zyxels
are by far the best-behaved and easiest to configure; the
remote-configure feature isn't exactly a luxury when your other modem
is locked in a basement ten miles away. Five of the newest members of
our Internet coop are using them. Some of the other members, not using
Zyxels, have their modems attached to a BSR box, so they can remotely
power them off and on to reset them. Consider what it would take to
drive you to such ends... not a pretty thought.
FidoNews 10-07 Page 15 15 Feb 1993
Because our current router software doesn't manage connects for us, we
have the modems setup for blind auto-answer. The router doesn't even
issue a single "AT" command, usually required to let the modem know
what the locked rate is. We've had no problems getting the Zyxel's to
perform well under the worst possible conditions (dumb software
blazing out IP packets to a modem not even connected...).
Personally I'd recommend that you disable the infamous "+ + +"
sequence that Hayes went and patented on everyone. It hardly matters
any more anyways; decent software uses DTR to get the modems
attention. Zyxel uses some proprietary method that is actually
supposed to work. I see no use for it anymore anyways.
RECOMMENDATIONS AND OTHER FEATURES
I recommend the Zyxel U-1496 series highly. They don't require tons of
fine tuning to get them working. The command set has the most common
subset of all the high-speed modems I've used. They are inexpensive,
bang per buck. Zyxel has a $35 EPROM software upgrade policy -- and
for real cheapskates, you can get the EPROM image and burn your own
for free!
OOPS -- PROBLEMS!
OK, so nothing is perfect. All high-speed modems these days are about
equivelant to a Macintosh Plus in processor power and memory, and as
much software. All modems have bugs; what matters is (1) will I ever
get it fixed and (2) does it still get the job done in the mean time.
Well. I ran into two problems. One looked to be truly horrid at first
glance, but turned out to be not quite so. Some people doing testing
in a purely Internet environment found that their 1496E's would not
output received data under heavily-loaded full-duplex conditions; the
modem was apparently too busy sending to notice the received data, and
programs were timing out waiting for that input. In other words, the
modem wouldn't really do full duplex. (When you stopped sending, all
the queued up recieve data would come spewing out.)
It turns out to be fairly hard to reproduce this bug; you have to
enable hardware handshake (RTS/CTS) and then, apparently, ignore it.
Instead of dropping bytes, the modem tries to keep up. Personally, I
would have called this "operator error"!
What Zyxel did however was fix the bug and mailed a copy to the person
who found the bug -- and as far as I know, this was a mere mortal
customer, not an "official" tester!
FidoNews 10-07 Page 16 15 Feb 1993
In a DOS environment, with a standard PC Async Adapter, especially
with a decent FOSSIL driver, you will never be able to reproduce this;
it requires an improper installation.
This is not the only story like this, where Zyxel takes customer bug
reports and acts on them, producing a fix in the next ROM version.
And makes those ROMs available for $35, or "free" if you can burn your
own EPROMS! (Which most people don't of course do; however it lets
others burn replacement EPROMs and make them available inexpensively.
I can think of a few other modem manufacturers who will simply not
admit that their product could possibly have bugs, or that mere users
could find them. Grrr.
Zyxel seems to be agressively working the sysop world. We're a fussy
and demanding group of people, but I think they've noticed that BBS
callers tend to look to BBS sysops' experience as to what modems are
worth getting. This worked with U.S. Robotics, and it seems to be
working well with Zyxel. Let's see if they can keep up!
FIDONET COMPATIBILITY REARS IT'S UGLY HEAD...
There is one other problem of uncertain effect, that has already
caused not a little bit of trouble. The Zyxel modems will not
auto-answer at 300 baud, ie. Bell 103A. Really.
No one *likes* 300 baud. In this day and age it's a "fall back", when
literally everything else fails, and in some cases, such as calls from
"overseas" (US-centric point of view) the only modem protocol in
common with U.S. modems. (The old European split 1200/75 baud 202A
protocol for example.)
The clincher: the FidoNet technical standards require that a node in
FidoNet always accept incoming mail, simply put. Even if this means
falling back to FSC-001 mode, with XMODEM for files and at 300 baud;
at least a message can get through.
Zyxel claims that the problem is due to some modems' FAX protocols
using 300 baud for protocol signaling, such as the Supra, and because
of this 300 baud is unavailable for modem use. I do not understand FAX
protocol issues, and can only offer that other modems do not have this
problem.
So a Zyxel-equipped FidoNet system cannot accept incoming 300-baud
calls, which is technically in violation of FidoNet technical
requirements. It has already come up as a problem in one net, at
least.
FidoNews 10-07 Page 17 15 Feb 1993
FidoNet is not here to sell modems; it's here for people to
communicate, period, even or maybe especially people with "no money"
systems using junk modems.
But in fact this "300-baud" problem has been around for a while now --
for example, my Tandy 200 laptop (circa 1985) has a built-in 300-baud
modem that hasn't been able to connect to any high-speed modem for
years; it's old design gets fooled by the complex tones required for
the new speeds. Probably this is a common problem.
I truly don't know how much it matters that the very bottom end of the
speed range is going away. Are we cutting off a dozen people? A
hundred? Thousands? It's a marketing decision certainly, and we'll see
what the outcome is. I wish we could have both, such as an option to
dedicate Bell 103A to modem use vs. FAX.
--------------------------
Zyxel contact information, courtesy Zyxel
Retail Price SYSOP Special Price
ZyXEL U-1496B/144 (Internal Card) US $449.00 US $289.00
ZyXEL U-1496B/168 (Internal Card) US $469.00 US $299.00
ZyXEL U-1496E (Ext/16.8kbps) US $469.00 US $299.00
ZyXEL U-1496E+ (Ext/16.8/19.2kbps) US $649.00 US $399.00
ZyXEL U-1496 (Ext/16.8kbps) US $899.00 US $499.00
ZyXEL U-1496+ (Ext/16.8/19.2kbps) US $989.00 US $549.00
ZyXEL U-1496R (Rack Modem16.8/19.2)US $899.00 US $549.00
ZyXEL RS-1600SY (Rack System with one RS-1600 and one U-1496R modem)
US $1349.00
Manufacturers Representative William Gourley 1-800-669-5085
1-800-GOU-RLEY
Support BBSs:
San Diego Rep 1:202/346 8:913/1 1-619-282-0857
Corporate 1-714-693-0762
Fax:
San Diego 1-619-282-2397
Stocking Resellers:
ORG NAME MANAGER VOICE PHONE
Donovan Enterprises - Brenda Donovan - 1-619-560-8317 RTL/VAR
FidoNews 10-07 Page 18 15 Feb 1993
Micro City - Rodger - 1-619-689-0567 RTL
Sole Source Systems - Scott McMillan - 1-619-467-0661 RTL
LaPaz Electronics - Allen - 1-619-586-7610 WHL
Richard Couture - Richard - 1-415-621-1908 RTL/VAR
----------------------------------------------------------------------
by: Phillip Dampier
1:2613/228
While flipping through an overloaded case of floppy diskettes, I was
very much surprised to find the floppy disk that contained the very
first nodelist that listed my node, back in December of 1988.
At the time, our hub consisted of about a baker's dozen of nodes, all
a part of a Net 260 that was about two screen pages full. The entire
nodelist was well under 700k at the time.
What amused me even more was finding a policy document on that diskette
that was almost identical to the Policy 4.07 that is used today in
Fidonet, one that was adopted in 1989.
Today, the nodelist is fast on the way to reaching two megabytes in
length as Fidonet passes 22,000 individual nodes.
With that growth has come change -- change that has not been reflected
in this network's current policy document.
For those visionaries who want to bring Fidonet into the
1990's through representative governing of this network, a new
policy built from the ground up sounds like an excellent idea at
first thought.
Unfortunately, the landscape is littered with policy proposals and
movements that have pledged to produce a new policy built from the
ground up, only to stand little or no passage within the current
Fidonet infrastructure.
The policy proposal recently submitted by a committee working under
the auspices of Richard Wood does not address all of my concerns,
but I have realized that it's a good first step. It represents
the building of a new foundation for Fidonet -- one built on
democratic reform.
It's time for us to recognize that Fidonet needs a new policy
document. It also needs a new system for adopting policy documents,
one that involves each of you who belong to this network.
Let's take the first step by adopting a policy that sets the stage
for future reform through better election procedures and a realistic
policy reform process. Without this basic reform, no major policy
proposal ever has any real chance of discussion and adoption.
FidoNews 10-07 Page 19 15 Feb 1993
I call on all Fidonet Region Coordinators to support taking this
new policy proposal to a full network referendum.
I call on all nodes in this network to take the time and get involved
in Fidonet's administration. Your involvement in this great Fidonet
Co-Op brings new blood and a new vision for the future. Let's start
off with a new policy document that paves the way.
Some of our nodes in Net 2613 who wanted to add their names to this
article follow:
Jerry Seward (Net 2613 NEC) 1:2613/333
Tracy Logan (Hub Coordinator - MetroEast) 1:2613/111
Daniel O'Donnell (Hub Coordinator - MetroWest) 1:2613/369
John Passaniti 1:2613/102 George Vaisey 1:2613/333.5
Raymond DeRoo 1:2613/450 Alex Barbara 1:2613/123
Mark Pedersen 1:2613/211
----------------------------------------------------------------------
Yes, it's possible: More Insanity In fidonet!
By Mike Catchpole of 1:267/113.15
Well, the hot air from my last article seems to have died
down, but it's still winter out and it's getting cold out here :) I'll
attempt to do an entire article without that phrase that has become
quite popular in the fido world today...
... GO POUND SALT ...
The democracy issue in fidonet is getting a good start, and
this is good. Glen Johnson wrote recently on point voting. It
was in fact the most cool-headed article ever written about the topic.
>But, I gotta oppose that one, friends. See, a point system, by
>definition, is an extension of an existing Fidonet Node. Points
>are not subject to policy; they don't have to be up during Zone Mail
I couldn't agree more on the first part. If points were allowed to
vote under a new policy, it would open the door for ballot box
stuffing. Not good.
However, the thing that points do not have to follow policy is a gray
area. Existing policy defines points as users. So we have to follow
policy and be users... Which means exactly what?
A user is PHYSICALLY and TECHNICALLY unable to File Request, for
example. He doesn't have the software to handle it. On the other
hand, a point can physically File Request or crash mail systems other
than his own. But.....
FidoNews 10-07 Page 20 15 Feb 1993
Is this legal under policy 4? Well, friends, it depends on who you
ask! Attempts by points to get some clear cut definition on this
issue in the policy_5 echo have been meet in a very unique and
interesting manner. Keep in mind, the points in question did not want
to set policy... they wanted it to say specifically what was legal and
what was not. Of course, that didn't stop the netmail flame-throwers
from telling them they had no right to set a policy that will affect ME.
(me being the nodelisted flame throwers...)
First off, when points posted in the echo they were told by persons in
the echo that points could not have anything above READ ONLY access.
Some changed. Some came in later and never saw the message.
Then Glen Harvy Posted a message, which he signed "Zone 3 Co
Moderator" in which he stated that points could not receive the echo,
period.
So I looked it up in the elist. And again in elist 302 just in case it
had been changed for some reason... it hadn't.
Here is the entry from elist302, with some of the indentation removed to
make it more fido-news friendly, otherwise unchaned...
Policy 5 assimilation, discussion, and implementation. POLICY_5
This conference is for those persons who are interested in seeing a
new FidoNet policy (Policy 5). It is not a place to bitch about the
downfalls of Policy 4, but a place for constructive discussion which
WILL lead to drafting a policy that is more in tune with the needs
and flavor of todays FidoNet. YOUR INPUT COUNTS!
Moderator: Chip Kukuk 1:3636/3 Last Updated: 12/01/92
No. of Nodes: 25 Volume: 40/week Restr:
Distribution: REQUEST
Gateways: ZONE 3 VIA 1:291/11 Rule File: n/a
Now, first thing is that the Restr: field is blank. Thus, it can go to
anyone, not just these nodelisted sysops.
Secondly, according to nodelist.029, there is no such node as 1:3636/3.
Now, how chip is moderating the echo from a node that does not exist
when the rules suposedly say that you must be the sysop of a listed node
to participate is beyond my comprehension.
As far as I am concerned, it is somewhat ridiculous to establish rules
for a confence that specificly prevent the moderator from receiving
it. Especially when they are created to squash the voice of a so
called minority group.
I also received a netmail from Glen that "Policy 5 will never be
accepted if it is learned it was moduled by points". Well, I don't
think it'll last long if it DOES pass. Since many major points, such as
point file requests and crashmail will probably never be considered, it
will have the same weakness as policy 4- vaugness.
FidoNews 10-07 Page 21 15 Feb 1993
Well, I think I can imagine what policy 5 will probably look like. If it
was based on the recent fido events, there will be no elist, no
nodelist, and no rules....
----------------------------------------------------------------------
Christopher Baker
Rights On! 1:374/14
A_THEIST Echo Available
A_theism means free of religion in the way a_political means
free of politics or a_sexual means free of sex
characteristics or drives.
With that in mind and ever cognizant of the continued
pressure of religion to intrude itself into our government
and its operations, the A_THEIST Echo is provided to inform
and alarm and hopefully wake up the sleeping and too long
silent majority to the peril on our doorstep.
It is now a Zone 1 Backbone Echo Hosted and Moderated
by Rights On! [1:374/14] and Christopher Baker [card
carrying member of American Atheists, Inc.]. Initial links
may be obtained from your local Backbone source connection.
Zone 3 is being fed through 3:800/857 and Zone 2 through
2:241/6001 via a Gate at 1:374/14 until direct links can be
made to those Zones via the international Backbone links.
The Zone 3 Hub sends it into Zone 6.
The Echo is open to anyone who can discuss, without
proselytizing, the extreme desirability of maintaining the
absolute separation of State and church in this country as
provided for in our Constitution.
A sample of the first few messages and the statement of
purpose of the Echo is available as A_THEIST.ZIP from this
system anytime except 0100-0130 ET and Zone 1 ZMH [USR HST
V32 online] if you wish to get an idea of whether to commit
disk space to the Echo. An archive of the past traffic from
the Echo is also available as A_ECHO1.ZIP, A_ECHO2.ZIP, and
A_ECHO3.ZIP, A_ECHO4.ZIP, etc.
It has been on the Backbone for months. Ask your Backbone
connection to get it for you! The complete info is available
in the current ELISTnnn.XXX file available from your NEC or
REC or here. [Request ELIST.]
I hope you will join us or ask your Sysop to request a link
via their regular Backbone connections!
FidoNews 10-07 Page 22 15 Feb 1993
TTFN.
Chris
----------------------------------------------------------------------
By: Howard Sucher 1:167/320
The GlobalNet Network (92)
This article is to let sysops and non-sysops know that their is an
alternative FREE electronic communications network that travels
around the world daily. This network is called the GlobalNet
Network (92).
Now please don't start thinking "Oh no, Not another network, they are
all the same." GlobalNet Network is not like any other network! I'm
sure it is very hard to believe this. But it really is true. A network
can be compared to a computer game. Their are many bad programmed
games and a few good ones. The GlobalNet Network (92) is a network who
is based mainly on adult and professional type people. We do not
support the writings of wasteless messages that always say hello,
hello and hello and have such FALSE B.S in them. Sysops and non-sysops
who are a part of GlobalNet are willing to help each other out. We
have no moderators in our 50+ message areas that travel anywhere from
North America, All over Europe, Asia and Australia. I'm sure you are
wondering how we don't have moderators? The answer is that we have
specialists! These people are knowledgeable in this subject field!
They are not in the echos to complain about people doing this and
that.
GlobalNet is free of cost shareing as this network is founded on the
basis of free amateur communications around the world, where people
can enjoy themselves and not put up with useless words found in many
other networks.
This is how a Good ELECTRONIC amateur network should be! It's a hobby.
In GlobalNet, you decide what you would like to see and then discuss it
with everyone else. Unlike some other networks in which your plight and
suggestions are flushed down the toliet, we in GlobalNet take everything
seriously and even if your a node, yes a node! your very important and
have a say! No one rules you!
If by chance your eyes and head are not overpowered with everyday life
and you really want to believe and see something different, then you
can't lose on trying out this network.
P.S. Also to prove that GlobalNet is not just a network off the floor,
it was mentioned in an article with in PC-TODAY magazine Aug. 92 issue.
FidoNews 10-07 Page 23 15 Feb 1993
For fast and quick information freq: GN_REG at:
Howard Sucher - (514) 487-7086 (19200 ZYX) Fido: 1:167/320
Howard Sucher - (49) 6841-15390 (HST DS 16.8) Fido: 2:247/83
----------------------------------------------------------------------
by Adam Michlin, 1:143/143
The INTERNET echo is now available:
This echo is for novices and other non-experts to discuss the use of
the Internet. Finally, a place where the question "How do I send
netmail from my fidonet address to my friend on the Internet and
vice versa?" is on-topic.
What INTERNET is:
o A place to ask "dumb" questions like:
* How do I get a node-number on the Internet?
* How can I get a full Usenet feed with my 1200 bps modem and
my Fidonet mailer?
o A place to discuss getting access to the Internet, and getting
Usenet feeds.
o A place to discuss the "cool" places to FTP from, how to
FTP/Telnet, and how to be polite about FTP'ing.
o You don't know what FTP'ing is? INTERNET is the echo for you.
o A place to discuss how to address mail from Fidonet to other
non-Fidonet technology networks such as Compuserve.
What INTERNET isn't:
o An overly technical echo. Topics like "Getting the best throughput
with UUCP-G" will be tolerated, but not looked upon favorably =)
o A place to discuss the actual technical issues behind running
your own Usenet/Internet gateway. (For this, you might try the
UFGATE echo).
Why?:
o Why not?
o It's needed. The OTHERNETS echo gets a lot of Internet related
traffic and needs to return back to Fidonet technology related
issues. How many times have you seen someone ask something
about the Internet in an echo that has nothing to do with
the Internet? I see many messages like that consistently in
all sorts of echos.
Who?:
o The moderators are Adam Michlin@143/143 and Software John@143/8.
I (Adam) am the current moderator of the backbone echo OTHERNETS,
and to some extent an Internet novice myself. John runs the
Internet<->Fidonet connection for Net 143 and will be the resident
FidoNews 10-07 Page 24 15 Feb 1993
'expert'.
Where?:
o Currently available from:
Adam Michlin 1:143/143 Al Anderson 1:377/37
Software John 1:143/8 Michael Forrest 1:278/707
Guy Martin 1:143/269 Jim Cannell 1:216/21
Mark Woolworth 1:209/710 Jerry Seward 1:2613/333
Barry Kapke 1:125/125
J. Allen 1:2201/13
John Gillet 1:114/27
Leon Lynch 1:262/3
Roger Smith 1:214/33
Ralph Sims 1:343/94
-Adam Michlin
1:143/143
amichlin@cats.UCSC.EDU
----------------------------------------------------------------------
by Jasen Fici (1:260/445)
Magcom v1.0
Concord Software would like to introduce Magcom v1.0 ...
Magcom is a result of years of on-line experience.
Many, many great publications are transmitted electronically in or as
a single text file. Although many system operators make these
magazines available for users to look at while they are on their
system, and some even make them available for download, until this
time, there has been no easy way for the user to do this (or the sysop
to set it up).
Enter stage left, Magcom ...
Magcom is a full featured, magazine and publication manager, viewer,
and on-line door. It encompasses a rather wide range of functions,
but is extremely easy to use.
Who is Magcom for? In a word, EVERYONE!
For the writers, and people who create publications, Magcom is a GREAT
magazine management facility. It allows the authors to easily manage
individual articles, full magazines, and entire publications (multiple
issues of the same magazine). It creates compressed archives of
magazine and publications on command, and allows for the easy
distribution of such on-line-creations.
FidoNews 10-07 Page 25 15 Feb 1993
For the sysop, almost painlessly, on-line magazines and publications
created by authors who also decide to use Magcom (mentioned above),
can be viewed, captured, or downloaded by their users. Magcom is the
ultimate on-line magazine viewer! (and as far as we know, the only
one).
For the casual BBS users, Magcom can make your life EXTREMELY easier.
No longer are you required to pan through an entire on-line document
to get to the part that you want to read. Anything created with
Magcom will allow you to view things in an orderly and structured
fashion. It even allows you to download individual sections of a
publication with the seven internal protocols supplied!
The number one objection you will hear from authors, is that magazines
distributed in this format would not allow for users of non-based DOS
machines to view it. I say, Magcom does NOT have to be a switch of
the way their magazines are distributed, but simply an addition. With
the thousands of DOS based BBS systems available, distributing
magazines in the Magcom format makes nothing but sense.
How can Magcom become successful? By you, the system operators and
users. If you would like to see your favorite on-line magazines
distributed in the Magcom format, you MUST ask the authors of these
magazines to take a look at Magcom. Don't harass, but make a simple
suggestion. If enough people make the request, eventually they will
see the possibilities of Magcom.
Since this is the first major release of this type of software, Magcom
we may NOT have thought of EVERYTHING that you would like to see
within such a program. If you have any comments, suggestions,
constructive hate mail (if there is such a thing), please send it to
Jasen Fici at the address below.
Magcom is being distributed as shareware. It is available from
1:260/445 24 hours a day, 300-14400 with a file request for the magic
name : MAGCOM (how original?)
You can also obtain it from calling our BBS at (607) 748-5276 also 24
hours. We also have designed a new BBS package known as Harmony BBS
that had been released across the country a few months ago. We are
working on a majpr update to that software also, but please feel free
to call up, take the grand tour, and say hello. (Harmony BBS v1.1a can
be FREQ with the magic name HARMONY)
----------------------------------------------------------------------
Christopher Baker
1:374/14, Titusville_FL_USA
FidoNews 10-07 Page 26 15 Feb 1993
MENSANS_ONLY Echo
MENSANS_ONLY is open to any verified member, past or
present, of any Mensa organization.
MENSANS_ONLY is not connected with American Mensa, Ltd.
[The High IQ Society], or any other Mensa organization
anywhere. MENSANS_ONLY has no opinions. Any opinions
expressed are those of the writer and any replier.
MENSANS_ONLY exists solely to provide a convenient forum
for electronic conversation between accepted members of any
Mensa organization. Any other inference you may glean from
perusing this Echo is all in your head, which is where it
should stay.
It is Hosted and Moderated from Rights On! in
Titusville_FL_USA at 1:374/14. It is intentionally withheld
from the FidoNet Backbone distribution system and is
offered for point-to-point links only. Any Backbone system
discovering this Echo traversing their system should
immediately remove it and notify anyone sending or
receiving it through them to desist unless said Backbone
system is an active and verified participant of
MENSANS_ONLY.
Anyone may read the traffic in this Echo but only verified
members may post in this Echo. Non-members interested in
more information about Mensa are directed to the general
Mensa Echo of the same name [MENSA] available from the
FidoNet Backbone and Moderated by Dave Aronson of
1:109/120.
Sysops who link into MENSANS_ONLY agree to abide by the
access restrictions above. The content of that Echo is not
restricted to any single topic or idea.
The number of systems linked to this Echo and the volume of
traffic in this Echo varies. Traffic is generally light
which is typical of non-Backbone, special interest Echos.
Anyone interested in linking into MENSANS_ONLY, should send
Netmail to: Christopher Baker at 1:374/14 {Rights On!,
Titusville_FL_USA}.
The following is a list of primary links for M_O:
[Zone 1:] 109/120 114/15 114/74 135/71 250/416 374/14 374/98
380/7 387/31. Zone 2 is also connect thru Holland courtesy
of Bob Hirschfeld at 1:114/72. [thanks, Bob!]
The Sysops of the above systems may link others into
MENSANS_ONLY based on the acceptance of the restrictions,
imposed above, by the link requesting Sysop.
FidoNews 10-07 Page 27 15 Feb 1993
Anyone requiring a direct feed or further information
should send Netmail to me at 1:374/14. Rights On! is a 24
hour system currently at 9600+ bps. It is now at 9600+ on a
USR Courier HST dual standard courtesy of their Sysop
Purchase Plan.
TTFN.
Chris
----------------------------------------------------------------------
RADIOS_OLD is an new echo for collectors, traders and restorers of
antique radios and televisions. For systems carrying shortwave, ham,
or electronic for-sale echos, Radios_Old will fit right in. For the
nearest feed, contact Darren Leno at 1:115/747 / (708) 238-1901.
----------------------------------------------------------------------
Christopher Baker
Rights On!, 1:374/14
SKEPTIC Echo is alive and well!
SKEPTIC is now a Backbone Echo that originally sprang forth
from the San Francisco area. It now originates from Zone 3
in Adelaide, Australia under the Moderatorship of Jackson
Harding at 3:800/857 and is Hubbed into Zones 1 and 2 by
1:374/14. It is Hubbed into Zone 6 from 3:800/857. The
Zone 2 Hub is Dieter Hummel at 2:241/6001.
If any of you or your Sysops are interested in obtaining
this Echo, you or they should contact their regular,
Backbone Echo source! SKEPTIC now appears in FIDONET.NA as
of 2 May 92.
SKEPTIC is devoted to examination and report of paranormal
and fringe-science claims. It has NO official or unofficial
connection to CSICOP {Committee for the Scientific
Investigation of Claims of the Paranormal} but has a similar
philosophy. Claims are not rejected on a priori grounds but
rather are investigated by objective and critical inquiry.
The Echo is now fully activated and waiting for those with
an interest in the mission stated above.
Complete information about the Echo may be found in the
current issue of the EList and the ELRules files.
FidoNews 10-07 Page 28 15 Feb 1993
Come and join us in the pursuit of knowledge! [grin]
TTFN.
Chris
Zone 1 Hub for SKEPTIC
----------------------------------------------------------------------
FidoNews 10-07 Page 29 15 Feb 1993
======================================================================
FIDONEWS INFORMATION
======================================================================
------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ----------------
Editors: Tom Jennings, Tim Pozar
Editors Emeritii: Thom Henderson, Dale Lovell, Vince Perriello
IMPORTANT NOTE: The FidoNet address of the FidoNews BBS has been
changed!!! Please make a note of this.
"FidoNews" BBS
FidoNet 1:1/23 <---- NEW ADDRESS!!!!
Internet fidonews@fidosw.fidonet.org
BBS +1-415-863-2739, 300/1200/2400/16800/V.32bis/Zyxel
(Postal Service mailing address) (have extreme patience)
FidoNews
c/o World Power Systems <---- don't forget this
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.
Authors retain copyright on individual works; otherwise FidoNews is
copyright 1992 Tom Jennings. All rights reserved. Duplication and/or
distribution permitted for noncommercial purposes only. For use in
other circumstances, please contact the original authors, or FidoNews
(we're easy).
OBTAINING COPIES: The-most-recent-issue-ONLY of 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 Internet.
PRINTED COPIES may be obtained from Fido Software for $10.00US each
PostPaid First Class within North America, or $13.00US elsewhere,
mailed Air Mail. (US funds drawn upon a US bank only.)
BACK ISSUES: Available from FidoNet nodes 1:102/138, 1:216/21,
1:125/1212, (and probably others), via filerequest or download
(consult a recent nodelist for phone numbers).
A very nice index to the Tables of Contents to all FidoNews volumes
can be filerequested from 1:396/1 or 1:216/21. The name(s) to request
are FNEWSxTC.ZIP, where 'x' is the volume number; 1=1984, 2=1985...
through 8=1991.
FidoNews 10-07 Page 30 15 Feb 1993
INTERNET USERS: FidoNews is available via FTP from ftp.ieee.org, in
directory ~ftp/pub/fidonet/fidonews. If you have questions regarding
FidoNet, please direct them to deitch@gisatl.fidonet.org, not the
FidoNews BBS. (Be kind and patient; David Deitch is generously
volunteering to handle FidoNet/Internet questions.)
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/23 as file "ARTSPEC.DOC". Please read it.
"Fido", "FidoNet" and the dog-with-diskette are U.S. registered
trademarks of Tom Jennings, Box 77731, San Francisco CA 94107, USA and
are used with permission.
Asked what he thought of Western civilization,
M.K. Gandhi said, "I think it would be an excellent idea".
-- END
----------------------------------------------------------------------
Reference in New Issue Copy Permalink