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. 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.... ---------------------------------------------------------------------- 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 ----------------------------------------------------------------------