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

1535 lines
68 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. 8 No. 41 (14 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: Less is more ....................................... 1
2. FIDONET NEWS .................................................. 2
(No FidoNetNews this week) .................................... 2
3. ARTICLES ...................................................... 3
Path Transmission in WaZOO Sessions ........................... 3
APPLE MICROSOFT Wars .......................................... 5
A Different Perspective ....................................... 7
VList Submission DEADLINE! .................................... 8
The Fort Worth Nodelist v3.2.3 ................................ 9
Nodelists, and Other Comments on Recent Articles .............. 13
PHILATELY echo ................................................ 16
MENSANS_ONLY Echo Notice ...................................... 17
SIERRAN Echo Anyone? .......................................... 18
A_THEIST Echo now on Backbone! ................................ 19
4. RANTS AND FLAMES .............................................. 21
5. CLASSIFIEDS ................................................... 22
6. NOTICES ....................................................... 23
The Interrupt Stack ........................................... 23
7. LATEST VERSIONS ............................................... 24
Latest Greatest Software Versions ............................. 24
FidoNews 8-41 Page 1 14 Oct 1991
======================================================================
EDITORIAL
======================================================================
Editorial: Less is more
by Tom Jennings (1:1/1)
Amazing. An entire week and I wasn't flamed at. Whew. (Or maybe I'm just
getting numb to them, and what was a flame a year ago is now merely a
disagreement.)
There are actually a couple of technical articles in this weeks
FidoNews! Thank you thank you!!! A suggestion to FidoNet-compatible
authors: copy the behavior of tech trade rags (ELECTRONICS, EDN,
COMPUTER DESIGN, etc) and write a short article describing the features
and functions of your program that makes it unique.
Instead of foolishly insisting that authors be "objective", they simply
give a short bio on the author ("Mary Monster is head of engineering
Acme Rocket Modem Co. and is in charge of design of their 8008-based
1024-line BBS program"), so you simply are aware of the bias, and
further request that the author stick to more or less technical issues,
though in FidoNews! info on obtaining a copy, flaming at competitors,
etc should be acceptable.
As a matter of fact, it would be nice to know just what makes program X
more desirable that program Y. I wrote one a few years ago about
Fido/FidoNet's router design, and I will consider dusting it off for
republishing.
----------------------------------------------------------------------
FidoNews 8-41 Page 2 14 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-41 Page 3 14 Oct 1991
======================================================================
ARTICLES
======================================================================
Path Transmission In WaZOO Sessions
Greylock Software 1:321/202
[What follows is a fragment from the MilqueToast 1.10 release
notes, documenting a feature we find useful. It has impact on
the net at large, so we are trying to disseminate this
information as widely as possible. There is an early gamma of
Milq available on JonesNose that implements this feature,
although we make no commitment to support it exactly as
currently implemented. To get this version, freq MILQGAMM. We
would appreciate any feedback you may have to offer. There's
at least one large problem we've encountered since this was
written; it's left as an exersize to the reader to point it out
to us!]
Milq will send, receive, and use path information in ZedZap and
Janus sessions.
This feature is a powerful one, with great potential for system
abuse. We do not recommend you enable it until you think you
thoroughly understand it.
I program for myself, figuring what I find useful, someone else
might as well. We do all our backups using FidoNet technology.
We LHA our work into a set of archives every day, and exchange
them between a few systems. At 9600, this can take an hour, but
who cares? It's a local call, and this way the backups are done,
period.
Way back when, we used EMCL (TICK) technology to handle this, but
we ran into problems doing this. We needed finer control of
where the mail agent put the files. We needed access to ZSkip.
Initially, we put some code in Bink that allowed for node
specific individual inbound directories, if they existed. Still,
even this caused problems. While it isolated my files from the
"general inbound", it made difficult the task of discriminating
between files sent for backup, and files sent for other reasons.
We have abandoned these changes, although I believe there's still
something to be said for them, they may be restored in
conditionally compiled code. We needed still finer control of
where the mail agent put the files. We need to be able to
transfer and map path information, in effect, providing full
access to any path on the system.
Three config file verbs are added: PathMap, KnownPathMap, and
ProtPathMap. These each take a filename as an argument, pointing
to a file of lines of the following format:
FidoNews 8-41 Page 4 14 Oct 1991
\SrcPath D:\DstPath
Slashes are not "directional sensitive"!
We plan on allowing the nesting of these files, using
@filename.ext. We also plan to allow prefix only substitution
(for now, an exact match is required.) And we plan to allow (in
a controlled manner) for some systems to be able to create paths
that do not exist in the substitution table.
Currently, this only is used on the receive side. We will
probably implement it on the send side as well, which would allow
you to "hide" your directory structure while still taking
advantage of the feature.
Three other verbs control the SENDING of paths (SendPaths,
KnownSendPaths, and ProtSendPaths).
There are restrictions on this feature. It will only work when
you are communicating with a Bink, Igor, or Milque which also
supports this feature, something determined by examining the
product code information transmitted in the YooHoo handshake.
Currently, only beta level software supports this. (Milq 1.01+
and Bink 2.51/GS handle it.)
Why these restrictions? Well, first the easy one. So far as we
can tell, only ZModem based protocols have provisions to transfer
path information. This doesn't completely explain the product
restrictions, since many products support the appropriate
protocols. When we first enabled this feature, we discovered
that at least one mailer does not properly implement ZModem, and
is quite unhappy if you send it a path. Rather than code in the
"bad" mailers, we coded in the "good" ones. In addition, even
the Janus code within earlier versions of Bink (Igor and Milq)
exhibits this weakness.
WARNING! As of this writing, ONLY the 2.51-YYMMDDHHMM version of
Bink (the one we produce) will properly handle this, and there
could be problems with Janus sessions if Bink proper does not
nuke paths on the receive side with betas at or above 2.51!
At the current time, these restrictions are contained in a hard
coded table. We will probably move this table to either the
resource or language file, to allow the enabling of this feature
with other products as possible without recompiling.
In addition, we are still considering mechanisms to regulate this
feature on a node by node basis, in addition to the "node class"
basis initially implemented. We are trying to accomplish this
with a minimum of node specific files.
FidoNews 8-41 Page 5 14 Oct 1991
Let's briefly outline some of the inherent "gotcha's" in this
little ditty. If you allow someone mapped access to your the
directory the running MT.Exe is in, very odd things could happen
if someone uploaded a new MT.Exe. I don't even want to think
about this one.
If you happen to map his "outbound" information to somewhere
other than your inbound, mail might not get unpacked properly.
If you allow mapped access to configuration directories, backup
directories, or program directories, obvious security breaches
are possible.
----------------------------------------------------------------------
APPLE MICROSOFT Wars
Press release from Techno Junk and Grey Matter, Christchurch, New
Zealand, 2:41am Oct 01,1991. Copyright reserved. Publication by
electronic media is hereby granted.
APPLE/MICROSOFT Decision reversed
_________________________________
Recently reported in the ZNPC Magazine distributed in the Public BBS
networks was an interesting article. This was notable for its
contradiction of an earlier press release that discussed this ruling.
In the prior news, we read of the possible outcomes as draconian as
complete withdrawal of the MicroSoft WINDOWS Graphical User Interface
from the market. The article is quoted :
AN APPLE-MICROSOFT 'LOOK AND FEEL' SUIT RULING IN FAVOR OF
APPLE HAS BEEN REVERSED. Judge Vaughn Walker now says that
Microsoft and Hewlett-Packard DO have the right to challenge
Apple's visual interface copyrights and patents, rather than
confining the case to the validity of Apple and Microsoft's
1985 GUI agreement. Previously, Judge Walker refused to hear
such motions. The judge did warn the two defendant companies,
however, that (it) will need to prove that Apple directly and
knowingly copied earlier designs for use on the Lisa and
Macintosh.
28/08/91
The beginnings of this story begin in Palo Alto, the home of PARC, Rank
Xerox's research and development centre. It is here that the GUI was
born, manifesting itself in a product that looked and felt remarkably
like an APPLE Lisa. PARC was a centre player in the SILICON VALLEY
techno-revolution. The computer was known to the author as a XEROX Star,
and was a quantum leap in ease of use computing.
FidoNews 8-41 Page 6 14 Oct 1991
To anybody who has been to PALO ALTO, and knows the EL Camino Real area,
they will have seen the Palo Alto Square Building. This where the High
Tech Law firms operate from. In Palo Alto alone, there is over 900
lawyers (1984), up from 150 in 1964. In one day, one law firm signed 20
million dollars in deals for start up companies alone... another company
was signing up new startup companies at a rate of one per day.
Anybody quess as to what the figures are today, when you add in the
litigation cases and revenue contribution.
We, the consuming public, as software/hardware users are indirectly
paying for this.
The big issue at stake here is one that concerns all technology based
business houses, irrespective of size. This is an issue in which the
outcomes of the APPLE/MICROSOFT case is likely to have far reaching
ramifications.
What is at stake is a determination and precedent for the issues
relating to technology transfer by way of employee/employer transition.
The difficulty in this determination is finding some one who has the
Bachalor of Electrical Engineering, Computer Science qualification, and
Commercial Law expertise in Copyright, and Intellectual Property, to
make correct and appropriate decisions.
Required are the skills to determine if an entrepeneur is taking (or
aquiring benefit from) trade secrets from his former employees, or from
the former employees of personel under his/her control.
In a more global perspective, all this defacto technology transfer, has
had some spin off. Consider the following...
"the unique strength of the US. Semiconductor industry
derives from its firms rapid copying of each others'
innovative chips."
US Federal Trade Commission.
To a large extent this applies to the software industry as well.
Quite apart from the job mobility problems, are the issues of corporate
assimilations, the impact of the network of who knows who, and who owns
what, liquidations, share markets, reputations, sucesses, and new
products, thru to downright rumours, and corporate espionage. Add to
that the close proximity of the player companies, with the increased
opportunity for co-incedental liason, then, distinguishing facts, from
fallacy is a vertible minefeild.
Even the time to take on board the required information to make an
informed decision has an impact, a month is a long time in SILICON
VALLEY.
FidoNews 8-41 Page 7 14 Oct 1991
It is for all these reasons that the process of litigation, as a medium
of dispute resolution, is imperilled over time by the advent of new
process, new market expectations, new corporate structures and
objectives and/or technology. The consequence of a decision in favour of
one or other parties becomes almost irrelevant in the time frame that it
takes to resolve litigated cases.
The only two things that we get from this are rich lawyers, and media
copy.
If the 10% of the annual budget on litigation, was directed towards
increased customer support, then we would find an industry with greater
investment confidence, and a more stable employment force.
If precedent were to prevail, the case of SEA vs ARC, over the look and
feel of a DOS command line, and its punative decision, might well become
more significant.....
Especially notable in this senario is the quiet partnership between IBM
and Apple, and the competative strugle for control of the GUI standards.
We already have seen the pendulum swing to and fro with WINDOWS vs OS/2.
( whoever wanted 1/2 an operating system anyway ).
In a profession as incestous as the computer industry, the bodies
corporate can ill afford to argue.
In respect of the APPLE/MICROSOFT case, I predict an out of court
settlement just at the point somebody's self interest will be about to
spill the beans over who really copied what.
Lets hope its sooner rather than later....
Cheers, Blair Anderson.
Christchurch, New Zealand.
----------------------------------------------------------------------
by Eddie Rowe @ 1:19/124.0
A Different Perspective
In my not so humble opinion, FidoNews should maintain its previous
and longstanding tradition of printing everything it receives which
conforms to tech standards. Yes, I too EXTREMELY DISLIKE this
religious material that has creeped into the Snooze on a regular
basis, but I know where the page down key is in List. Have we all
given thought to the guy out there operating at a blazing 1200 baud
(or less???) who calls long distance to pick up the Nodediff and
Fidonews weekly? Do you recall what it is like to get 115 cps if you
are lucky? I know of one such person who did that religiously a year
ago. Why? Because he lived in BFE and Fidonews was his only way of
reading about tech stuff to learn how to better run his system. What
of the off-topic articles? Well, they provide relief when the tech
stuff taxes the mind (which often it does). So why are the guys who
have the HST's bitching and complaining about it costing them money
FidoNews 8-41 Page 8 14 Oct 1991
to handle the Snooze when they are talking well over 1100 cps for such
a small file? I really don't know except that they can. <grin>
Now I can see the potential need for a publication for the distribution
of just official type FidoNet stuff, but can't we have the best of both
worlds? I truly enjoyed the Church of Elvis issue, particularly since
it originated from Louisiana and the land of Jimmy Swaggart! If we
must change Fidonews to publish only Fidonet related stuff (which I do
not want to see happen), why couldn't we start another publication for
the other articles received?
----------------------------------------------------------------------
By David French
Version List Submission Standards
WARNING WARNING WARNING WARNING WARNING WARNING WARNING
WARNING 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.
Get a copy of VLIST###.LZH(### Current FidoNews number). If you're
listing is not complete, it will de deleted on Oct 31, 1991.
--------------------------------------------------------------------
--*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*--
...FidoNews Version List Submission Guidelines...
--*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*--
All submissions to the FidoNews Version List MUST have the following:
1. Software Name & Version
2. FileName.Ext (If Commercial, Info FileName)
3. Support Board Network Address
4. Support Board Phone Number
If your software is commercial(Not Shareware, etc...) Please so state.
Submissions not meeting these standards will be ignored.
The Complete Current Listing is available from 1:103/950 under the magic
name VERSIONS, or the filename VLIST###.LZH (### is the current fidonews
volume number)
This file contains the complete Version list along with file names, node
addresses and phone numbers.
Here's a couple of examples:
FidoNews 8-41 Page 9 14 Oct 1991
InterMail v2.01 (Commercial)
IM-INFO.ZIP (Info File)
1:1/133
(305)436-1085
------------------------
RemoteAccess v1.01
RA_101.ZIP
1:1/120
(918)254-6618
Send your update notices to David French
1:103/950@fidonet
45:512/105@vnet
65:571/2@ournet
69:11/108@a_links
93:9702/2@podnet
PS: a copy of your software dropped into my inbound would be nice too,
but not necessary...hint...hint...<g>.
----------------------------------------------------------------------
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 III *=-
by Aaron Goldblatt (1:130/32.1@fidonet)
Development Manager: Will Schlichtman (1:350/59.0@fidonet)
Last week we continued the release of Version 3.2 of the Fort Worth
Nodelist format. The first section covered an overview of the format,
including general line entry definitions. Last week specific field
definitions were covered, as well as the dreaded "dialing translation"
section. A sample nodelist entry was provided.
This week we cover the format of the optional file, CITYLIST.nnn.
We also look at ????DIFF format. We do a numerical analysis of the
Fort Worth Nodelist versus the St. Louis Nodelist, both in raw format
and in several archive formats.
As in the first article, some information has been deleted because
formats from the St. Louis Nodelist remain unchanged. These portions
are indicated by text explaining what was deleted in [brackets.]
FidoNews 8-41 Page 10 14 Oct 1991
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
3.0 CITYLIST.nnn
----------------
Some sysops like to know _where_ they are calling, not just who. Some
sysops, on the other hand, have no interest in where they call, so long
as the mail gets through. In order to satisfy both sysops, the former
by giving them the location of the called system, and the latter by not
taking up precious disk space with useless information, the location
information resides in a separate, optional file.
As stated at the beginning of this document, there are two types of
lines in CITYLIST.nnn, data lines and comment lines. As in
NODELIST.nnn, comment lines are preceeded by a semicolon (;). The CRC
value for CITYLIST.nnn is calculated and noted in the same manner as
NODELIST.nnn.
For any non-comment line only one field exists: city_st
Locations are matched on a line-by-line basis with nodes in
NODELIST.nnn, so that the 335th node listed in NODELIST.001 has its
location noted on non-comment line 335 of CITYLIST.001.
Any alphanumeric character is valid except the space ( ) and comma (,).
Maximum field length is 40 characters. A valid example is:
Fort_Worth_TX
Lines end a CR/LF pair, as in NODELIST.nnn.
There are some instances where two or more lines may have the same
information, such as:
Fort_Worth_TX
Fort_Worth_TX
Fort_Worth_TX
In order to conserve space, instead of repeating the information three
times, it is noted only once and a ditto string is used. The ditto
string is two quote characters: "" If this is spotted in CITYLIST.nnn
it means that the previous location applies. So, the above three lines
would be listed as:
Fort_Worth_TX
""
""
4.0 NODEDIFF.nnn and CITYDIFF.nnn
---------------------------------
With more than ten thousand nodes as of this date, the nodelist, even
in archive form, is a substantial document (or file). Since distribution
is via electronic file transfer, this file is NOT routinely distributed.
Instead, when a new nodelist is prepared, it is compared with the
previous week's nodelist, and a file containing only the differences is
created and distributed.
FidoNews 8-41 Page 11 14 Oct 1991
The distribution files, called NODEDIFF.nnn and CITYDIFF.nnn, where nnn
is the day-of-year of publication, is actually an editing script which
will transform the previous week's list into the current list. A
definition of its format follows:
The first line of xxxxDIFF.nnn is an exact copy of the first line of
LAST WEEK'S list. This is used as a first-level confidence check to
insure that the right file is being edited. The second and subsequent
lines are editing commands and editing data.
[More material delted. Information covered:
o DIFF editing commands, same as St. Louis format
o CRC calculation for LIST/DIFF accuracy
o Archiving and naming of LIST/DIFF files in SEA ARC format, same
as St. Louis format
o "Official" Section 5.0, credits]
[end of document]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-=* Size Comparisons *=-
In a marathon session of processing, I converted NODELIST.256 into a
Fort Worth format nodelist, with CITYLIST file, and then archived the
files up in the five different formats, for size comparison. I set this
up as a batch file, and ran the thing at 01:00 one morning. I got up
six hours later and it wasn't finished.
The archive formats were:
System Enhancement Associates' ARC v6.00 ARC
NoGate Consulting's PAK v2.51 PAK
Haruyasu Yoshizaki's LHA v2.13 LHA
PKWare's PKZIP v1.1 ZIP
Robert K. Jung's ARJ v2.20 ARJ
ZOO v2.01 - the EXE didn't identify the author ZOO
In all cases I used default compression, that is, no special command
line switches. I chose the six formats I did because I have seen
nodelists distributed in all of these formats, and because these are the
ones I have on hand. I would have done DWC, too, but I don't have a
copy of that engine. Politics was not involved.
Three numerical fields are listed. They are:
o Size
o Bytes Saved
o Bytes Saved Over Raw
o Size is a file's length expressed in bytes.
o Bytes Saved is a a file's uncompressed size minus it's compressed size.
FidoNews 8-41 Page 12 14 Oct 1991
It is valid for archived files only. The formula is:
rawfile - compressed_file = bytes_saved
o Bytes Saved Over Raw is the length of NODELIST.256 minus the file's
length in bytes, regardless of compression technique. The formula
is:
NODELIST.256 - compressed_file = bytes_saved_over_raw
Bytes Saved Over Raw for CITYLIST.* has been calculated in a slightly
different manner. Instead of doing a straight comparison, the equation
is:
NODELIST.256 - (NODELIST.FW + CITYLIST.256) = bytes_saved_over_raw
When CITYLIST.* is archived, the equation is:
NODELIST.256 - (NODELIST.?FW + CITYLIST.???) = bytes_saved_over_raw
where ??? represents the same archive format - ARC and ARC, ZIP and
ZIP, etc.
Bytes Saved Arch
Filename Size Saved Raw Fmt.
------------ | ------- | ------ | ------ | --- |
NODELIST.256 | 1045043 | 0 | 0 | raw |
NODELIST.A56 | 562092 | 482951 | 482951 | ARC |
NODELIST.P56 | 404474 | 640569 | 640569 | PAK |
NODELIST.L56 | 393358 | 651685 | 651685 | LZH |
NODELIST.Z56 | 405987 | 639056 | 639056 | ZIP |
NODELIST.J56 | 384136 | 660907 | 660907 | ARJ |
NODELIST.O56 | 521217 | 523826 | 523826 | ZOO |
| | | | |
NODELIST.FW | 503474 | 0 | 541569 | raw |
NODELIST.AFW | 271993 | 231481 | 773050 | ARC |
NODELIST.PFW | 213716 | 289758 | 831327 | PAK |
NODELIST.LFW | 206882 | 296592 | 838161 | LZH |
NODELIST.ZFW | 216517 | 286957 | 828526 | ZIP |
NODELIST.JFW | 202611 | 300863 | 842432 | ARJ |
NODELIST.OFW | 253345 | 250129 | 791698 | ZOO |
| | | | |
CITYLIST. | 137900 | - | 403669 | raw |
CITYLIST.ARC | 61999 | 75901 | 711051 | ARC |
CITYLIST.PAK | 40452 | 97448 | 790875 | PAK |
CITYLIST.LZH | 38904 | 98996 | 799257 | LZH |
CITYLIST.ZIP | 40299 | 97601 | 788277 | ZIP |
CITYLIST.ARJ | 38828 | 99072 | 803604 | ARJ |
CITYLIST.ZOO | 57830 | 80070 | 733868 | ZOO |
This shows that, with the Fort Worth Format nodelist, without CITYLIST,
transmission time can be cut by almost 360k, and even with CITYLIST, the
savings is still be as high as 320k, depending on archive format used.
For the average 2400 bps system, that's about a half-hour. Thirty more
minutes in which you could be polling for mail instead.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FidoNews 8-41 Page 13 14 Oct 1991
Next week there will be a few concluding comments from Aaron Goldblatt.
If you read the first article you know that at first only three were
planned, but developments warranted a fourth.
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.
----------------------------------------------------------------------
Nodelists, and Other Comments on Recent Articles
Jack Decker
FidoNet 1:154/8
NODELISTS, AND OTHER COMMENTS ON RECENT ARTICLES
Fidonews 8-40 contained a couple of articles that merit a brief
response. First, Bill Jones of 1:231/370 wrote an article
defending the Saint Louis Nodelist Format. His prime objection
to a new format is that (and I quote verbatim from his
article:) "Converting to a new format would certainly alienate
a large portion of the non-MSDos systems out there (me
included) while they patiently wait for someone to write a new
NodeList processor for their environment." He then goes on to
suggest that unpublished systems should be removed from the
nodelist, along with certain modem flags. What bothers me
about this is that one could just as easily suggest that all
non-MSDOS systems be removed from the nodelist (and there would
certainly be some advantages to MS-DOS people to not have to
deal with other platforms!) and then Mr. Jones would be the one
left out in the cold. How dare he suggest that a certain
segment of Fidonet nodes be dropped?
This is really an old argument, but there are many reasons that
nodes are private, unlisted. If we allow that there are at
least SOME valid reasons for a node to be unlisted, then we get
to the question of who decides which reasons are valid and
which aren't? Some coordinators would say there are no valid
reasons for having a private node, others would let anyone have
one, still others would give them freely to those they happen
to like and withhold them from those they don't like. There
would be Policy Complaints flying fast and furious.
The reason we have this problem is because the software authors
and the political types in Fidonet haven't been thinking along
the same track. The political types have long been saying that
the nodelist is getting too large, but so much of the software
used in Fidonet depends on the idea of a "fully-coupled"
nodelist, where every possible reachable node is listed. There
are BBS's that won't let you enter a message to an unlisted
node, message trackers that will bounce messages destined for
unlisted nodes, and mailers that won't accept file requests
from unlisted nodes.
FidoNews 8-41 Page 14 14 Oct 1991
These considerations are among the big reasons that sysops of
private nodes don't want to become points. Mr. Jones wants us
to stay with the current nodelist processing software because
he's afraid he might not be able to upgrade to a new format,
yet he totally overlooks the fact that there is still BBS
software out there that can't properly handle sending a message
to a point. If you want to retain compatibility with all older
software, Mr. Jones, then you don't want to force people to
become points!
As for the file-request problem... many mailers allow sysops to
deny file requests to unlisted nodes, and when you give sysops
a capability, some are bound and determined to use it, and
never mind that any technically-capable user of a mailer
program can easily set up his system to impersonate a listed
node. So when you use this feature, you deny file requests
only to scrupulously honest sysops, and force others to
impersonate another (listed) node, with the result that you
don't know who REALLY freq'ed that file and you also run the
risk that if they pick the right node number to impersonate
(and you don't password-protect all your regular links), they
could pick up any mail that you have on hold for the node
they're impersonating. Still, some sysops would prefer to be
able to make file requests the honest way, using their own node
number, and unless they enjoy dealing with rejection they can't
do that with just a point number.
(Oh, you say the BossNode could make the request for the point?
Why should the BossNode have to go through that hassle, and
either bear the expense of the request himself or have to
collect from the point?)
Point-ops have always been considered "second-class citizens"
in Fidonet, so my response to Mr. Jones is that the day you are
willing to allow all non-MS-DOS systems to be dropped from the
nodelist and forced to become points (which, by the way, would
end your need to use ANY nodelist processor!) will be the day
I'll agree that some of the current private, unlisted nodes
should be forced to become points. As someone once said, it
all depends on whose ox is being gored, and I just can't
believe that people are really so selfish as to suggest that
OTHERS should be kicked out of the nodelist so THEY don't have
to deal with the relatively small amount of additional entries
(by the way, folks, run the numbers... private nodes really
make up only a very small percentage of the total nodelist,
probably less than one percent. If you think that chopping
less than one percent of the nodes out of the nodelist is going
to resolve ANY problem in Fidonet for longer than two or three
weeks, I feel VERY sorry for you (and how did you get out
without your keeper, anyway!?)).
FidoNews 8-41 Page 15 14 Oct 1991
In contrast we have Pablo Kleinman's article. Pablo is
much-maligned (mostly by the existing power structure in
Fidonet) but is one of the few people who is really trying to
do anything positive in Fidonet. Pablo unfortunately hits the
nail right on the head when he states:
"Those that submitted proposals to reduce the nodelist's size:
do you think you are even paid attention to? Ask me, I know
you're just talking to walls. What about us working in having
the ridiculous and truly nauseating Policy4 replaced? I doubt
under current circumstances we'll arrive to good port. There is
an echomail conference adequately called NET_DEV. Yet the head
of the FTSC refuses to read it... bienvenido progreso!"
I've been accused of launching unwarranted attacks on the FTSC
chairman in the past. It's no secret that he and I don't seem
to like each other very much, but I would just ask you to
consider the question of whether we really need the FTSC (for
that matter, why is it called the Fidonet Technical Standards
COMMITTEE when the word "committee" implies that there is more
than one person actively involved?). What does the FTSC
actually DO, other than act as a library of documents? It
certainly doesn't seem to be very effective in enforcing
standards or promulgating new standards. Well, I'm not going
to beat THAT horse again just now.
The problem is that anyone who really wants to do anything
positive in Fidonet seems to get shot down fairly quickly. In
the meantime, I have noticed that echomail traffic in some
conferences has dropped to something like one-third of what it
was even five or six months ago. Is this a sign that Fidonet
is beginning to die from stagnation (at least here in Zone 1),
or am I just reading the wrong conferences? My SUSPICION is
that some folks have discovered the higher quality of UseNet
conferences and are beginning to migrate over to those, while
curtailing their participation in echomail. Not only are those
conferences of higher quality, but the political structure in
Fidonet can't really control their distribution (with only a
few exceptions, the *EC's generally don't handle converted
UseNet newsgroups, so they can't impose geographic or other
restrictions on their distribution). Besides that, UseNet
offers truly moderated conferences, which can seem like a real
blessing after you've seen the damage that just one "loose
cannon" can cause in an unmoderated echomail conference.
Of course, Fidonet COULD support newsgroups... we could have a
newsgroup processor that would handle UseNet newsgroups in
their native format (not shoehorned into echomail format, at
least not until the destination system is reached). I've even
been trying to program such a thing but it's very slow going
because I'm not much of a programmer to start with, and I'm
using QuickBASIC (which is GREAT for handling strings, but has
other limitations that have to be worked around).
FidoNews 8-41 Page 16 14 Oct 1991
(Yes, I have looked at 'C'... and it's just too confusing, I
just prefer to use what I know best to get the job done, and I
already know how to get around some of the most galling
limitations of QuickBASIC).
To expand on this thought just a bit, what currently happens
when a newsgroup is brought into Fidonet is that it is
converted to echomail format at the gateway system, then
distributed as echomail within Fidonet. This causes a lot of
problems... header and control information present in UseNet
messages is often lost, long messages are lost or truncated,
replies are lost or not properly identified as replies, and to
put it simply, the conversion is imperfect, to say the least.
My theory is that UseNet newsgroups should be carried within
Fidonet in their native format, as defined by RFC-822 (and
other RFC-*) specs, and only converted to a Fidonet-type format
(such as the *.msg format) at the local level, so that they can
be read on BBS systems. In other words, rather than sending
around Fidonet-type mail packets (with all the SEENBY's and
assorted other garbage) we could handle the RFC-822 style
transport mechanism, which (by the way) is MUCH simpler to work
with, although NOT necessarily more efficient in terms of space
used (we have extraneous SEENBY's, they put lots of extraneous
information in message headers).
Now, I recall a year or two ago when folks were seriously
suggesting that we consider a "Type 3" message packet format
that was text-based and therefore much more compatible with the
UseNet formats. These got about as much positive response as
the current proposals to shorten the nodelist. Everyone seems
to say "Ho hum, why bother, let the status quo alone as long as
I'm getting my echomail!" Well, folks, if the bright folks all
leave for other nets, you may just find that whatever echomail
you're still getting really isn't worth the time you spend
reading it!
I know some of you will dismiss this as "a typical Jack Decker
message" but my whole point is not to predict "doom and gloom"
so I can gloat and say that I was right at some point down the
road, but rather to ask you to ask your coordinators to
ENCOURAGE innovation, experimentation and new ideas in Fidonet,
and to not just be satisfied with things as they are. Any
organization either changes or it dies. Let's see some
positive changes that will revitalize this hobby!
----------------------------------------------------------------------
PHILATELY: Philatelic Discussion Conference
FidoNews 8-41 Page 17 14 Oct 1991
In ELIST110, a new echo was listed of the tagname PHILATELY.
However, since the average SysOp doesn't have the time to stroll
through the 470K ELIST on a monthly basis, I thought I'd mention it
here, as well. :-)
PHILATELY is a conference for anything and everything relating
to the hobby of stamp collecting. Used, unused, U.S., foreign, and
First Day Cover collectors, as well as collectors or potential
collectors of any other stamp-related items, are welcome!
PHILATELY is not on the FidoNet backbone at this time, and as
a new conference is small. I'm very hopeful, however, that it will
grow when given a little time. If you're interested in establishing
a link to PHILATELY, please contact me here at 1:260/205.
Best regards!
- Jason DeCaro, 1:260/205
ethyl@rochgte.fidonet.org
PHILATELY moderator
----------------------------------------------------------------------
Christopher Baker
1:374/14, Titusville_FL_USA
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.
FidoNews 8-41 Page 18 14 Oct 1991
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 109/446 109/508 114/18 114/70 114/72
114/74 114/800 135/71 250/416 266/71 374/14 374/98 380/7.
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.
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
----------------------------------------------------------------------
by Eddie Rowe @ 1:19/124.0
SIERRAN Echo Anyone?
The SIERRAN Echo is dedicated to the thousands of Sierra Club members
and friends throughout the United States and world. Just about any
subject that relates to the environment is welcome - especially Sierra
Club events and happenings.
The SIERRAN Echo is currently available at v.32 speeds (or less) from
Eddie Rowe @ 1:19/124.
FidoNews 8-41 Page 19 14 Oct 1991
----------------------------------------------------------------------
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:681/857 and Zone 2 through
2:243/11 via a Gate at 1:102/901 until direct links can be
made to those Zones via the international Backbone links.
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
ds 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.
Backbone status has been approved. 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!
TTFN.
Chris
FidoNews 8-41 Page 20 14 Oct 1991
----------------------------------------------------------------------
FidoNews 8-41 Page 21 14 Oct 1991
======================================================================
RANTS AND FLAMES
======================================================================
_(*#$_(*@#(* (*^$+)#(%&+| #$)%(&*#_$ @_#( @$
^@#+)(#&%$*+)$%&*+$*%&#@(@#_|)*%|)#%&)#*%&+(@#&*_+(@#*^&@###
*&#_($*&#$_(*#&$_(#*$&$ _(#$*#$+)#($&*+#)$ &#+$*&#
()*&#$_(&^#$_(#*$_#($^&#_$(^&#_$(&^#$_(&#^ damn right _(#^&$_(#^&
$*&#$_+(* #)$&(%($%+)($%*+$)%($* it's ugly _#&%^# &
#($_*#$_ FidoNet (*$&%_@#_(*&@#_(@*#&_ @#_(*&@#_(*
)*&#$ Flames *^$+)#(% (not for the timid) @_#(
(*#$_(*^@#+) and #_|)*% &+(@#&*_+(@#*^&@###
(#$*&#_($*&#$_(*#&$_(#* Rants *&+#$*&#+$*&#
)*&#$_(a regular feature)^&#_$(&^#$_ $^&#$_(#^
(*^#$_*#^&$)*#&$^%)#*$&^_#($*^&#_($ Section #&%^_
_(*#&$_(#* #($*& #$* _(*&@#_(@*# *&@#_(*&
)&*+_)*&+)*&+))&*(*&
(*&_(*&_(*&
----------------------------------------------------------------------
FidoNews 8-41 Page 22 14 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-41 Page 23 14 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-41 Page 24 14 Oct 1991
======================================================================
LATEST VERSIONS
======================================================================
Latest Greatest SoftWare Versions
Last Update: 10/10/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.32a*@ BinkleyTerm 2.40 2DAPoint 1.40*
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@ ARC+Plus 7.12
Genesis Deluxe 3.1 FrontDoor 2.02* Areafix 1.20@
GSBBS 3.02 InterMail 2.01 ConfMail 4.00
Kitten 1.01 Milqtoast 1.00* Crossnet 1.5
Lynx 1.30 PreNM 1.48* DEMM 1.06@
Maximus 1.02 SEAdog 4.60 DGMM 1.06@
Opus 1.71* TIMS 1.0(Mod8) DOMAIN 1.42
PCBoard 14.5a EEngine 0.30*
Phoenix 1.3 EMM 2.10*
ProBoard 1.16*@ NodeList Utilities 4Dog/4DMatrix 1.18
QuickBBS 2.66 Name Version FileGroup 2.23
RBBS 17.3b -------------------- FNPGate 2.70
RBBSmail 17.3b EditNL 4.00 GateWorks 3.06e*
RemoteAccess 1.01 FDND 1.10 Gmail 2.05
SimplexBBS 1.04.02*+ MakeNL 2.31 GMD 3.00*
SLBBS 2.15b* Parselst 1.33* GMM 1.21@
Socrates 1.11* Prune 1.40 GoldEd 2.31p*
FidoNews 8-41 Page 25 14 Oct 1991
SuperBBS 1.10 SysNL 3.14 GROUP 2.23
TAG 2.5g XlatList 2.90 GUS 1.40*
TBBS 2.1 XlaxNode/Diff 2.52 HeadEdit 1.18
TComm/TCommNet 3.4 IMAIL 1.20*
Telegard 2.5 InterPCB 1.31
TPBoard 6.1 Lola 1.01d*
TriTel 1.11* Compression MSG 4.1
Wildcat! 2.55 Utilities MSGED 2.06
WWIV 4.20* Name Version MsgLnk 1.0c@
XBBS 1.17 -------------------- MsgMstr 2.02*
ARC 7.00 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
SeaMail 1.01
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
-------------------- -------------------- --------------------
Maximus-CBCS 1.02 BinkleyTerm 2.50* ARC2 6.01*
SimplexBBS 1.04.02*+ BinkleyTerm(S) 2.50*@ ConfMail 4.00
BinkleyTerm/2-MT EchoStat 6.0
1.40.02*@ LH2 2.11*
MsgEd 2.06c*
MsgLink 1.0c
MsgNum 4.16d*
FidoNews 8-41 Page 26 14 Oct 1991
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
MsgUtil 2.5
FidoNews 8-41 Page 27 14 Oct 1991
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
-------------------- -------------------- --------------------
Falcon CBBS 0.45 BinkleyTerm 1.00 AmigArc 0.23
Paragon 2.082+ TrapDoor 1.80* AReceipt 1.5
TransAmiga 1.07 WelMat 0.44 booz 1.01
ChameleonEdit 0.10
ConfMail 1.12
ElectricHerald 1.66
LHARC 1.30
Login 0.18
MessageFilter 1.52
oMMM 1.49b
FidoNews 8-41 Page 28 14 Oct 1991
ParseLst 1.64
PkAX 1.00
PolyxAmy 2.02
RMB 1.30
Roof 44.03
RoboWriter 1.02
Rsh 4.06
Skyparse 2.30
Tick 0.75
TrapList 1.40*
TrapToss 1.20*@
UNZIP 1.31
Yuck! 2.01*
Zippy (Unzip) 1.25
Zoo 2.01
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
FidoNews 8-41 Page 29 14 Oct 1991
!Spark 2.00d
Unzip 2.1TH
Tandy Color Computer 3 (OS-9 Level II)
--------------------------------------
BBS Software Compression Utility Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
RiBBS 2.02@ OS9ARC (Arc) 1.0@ Ascan 1.2@
OS9ARC (Dearc) 1.0@ AutoFRL 2.0@
DEARC @ CKARC 1.1@
UNZIP 3.10@ EchoCheck 1.01@
FReq 2.5a@
LookNode 2.00@
ParseLST @
RList 1.03@
RTick 2.00@
UnSeen 1.1@
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Key: + - Netmail Capable (Doesn't Require Additional Mailer Software)
* - Recently Updated Version
@ - New Addition
# - 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-41 Page 30 14 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-41 Page 31 14 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