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