F I D O N E W S -- | Vol. 9 No. 2 (13 January 1992) 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: Revelation! ........................................ 1 2. ARTICLES ...................................................... 3 Cost Recovery (Yes!) .......................................... 3 Geography and Fidonet ......................................... 6 New version of WorldPol released .............................. 9 3. RANTS AND FLAMES .............................................. 23 4. LATEST VERSIONS ............................................... 24 Latest Greatest Software Versions ............................. 24 5. FIDONEWS INFORMATION .......................................... 30 FidoNews 9-02 Page 1 13 Jan 1992 ====================================================================== EDITORIAL ====================================================================== Editorial: Revelation! by Tom Jennings (1:1/1) Us FidoNet sysops have been outdone at our own game. There's a group with higher expectations, less willing to put forth effort, regardless of consequences. U.S. automakers. Un-be-liev-able. OK, so Pres. Bush and the big-three CEOs (Ford, GM, Chrysler) visit Japan to "do something" about the massively declining U.S. auto sales. Japan is unfair to the U.S., is the assertion. An article in the S.F. Examiner (8 Jan 92) goes on and on about this Japanese showroom vs. that, sales figures, etc. Depressing. However a few glaring details leak out. Example: a Jeep Cherokee cost twice as much, with half the MPG (at twice the fuel price!) as an equiv. Nissan product. And the steering wheel is on the left side! (Japanese cars are righthand drive.) "It's too expensive to change this for the Japanese market", says Chrysler spokesman Izumi Kato. (Many American cars used to be made with provisions for either-hand drive; my 1963 Rambler has obvious provisions in the sheet metal, and factory parts catalogs show RH drive parts. (Ramblers were sold in Australia and Brazil, for instance.)) Oh yes, and they don't seem to advertise their cars on Japanese TV. Kato said it's too expensive (huh?!). Chrysler's ad budget in '91 was $1M (less than 1/4th Lee Iacocca's '91 salary!), and 1/10th of Nissan's US ad budget. And American car dealers in Japan do there what they do here -- sit in showrooms waiting for customers to come to them. Except, in Japan, car salesman go door to door, and have lots of salespeople -- Toyota's 42,000 to Honda's with 12,000. Ford and GM have only a few dozen in their showrooms! In another article in the same paper, an unnamed Bush administration official said, regarding Japanese consessions to what Bush & co. are asking: "Culturally, they'll never change. We'll have to ram it down their throats." (Of course we here at FidoNews! also recognize that there's only one way to do things -- OURS! I assume you all do too.) Whatever happened to the open market? FidoNews 9-02 Page 2 13 Jan 1992 In yet another article (which I don't have in front of me for direct quotes), a United Auto Workers union official was quoted to the effect, "we build the best cars we can with what we're given". Seems they know who's fooling whom. We've been outdone, boys and girls. Can we take the hint? ---------------------------------------------------------------------- FidoNews 9-02 Page 3 13 Jan 1992 ====================================================================== ARTICLES ====================================================================== Original Message Date: 08 Jan 92 08:52:16 From: Reinhart Behm on 2:242/38 To: Tom Jennings on 1:1/1 Subj: Fnews ^AINTL 1:1/1 2:242/38 Hello Tom, as the archiver of embbs and fnews for the nodes of Berlin I'd like to have the very old fnews issues (below 650). Could you give me a fido address of someone in germany or at least europe which (to the best of your knowledge) holds these files? Or, if you don't know, would you agree to receive a letter from me with diskettes, envelope and postage and to copy these files for me in a lonely and boring hour? cu :-) Reinhart ---------------------------------------------------------------------- Cost Recovery (Yes!) by Jack Winslade (NEC 285) 1:285/666 (DRBBS Technical BBS) jsw@drbbs.omahug.org ('Net 285, where few people run an IBM-PC, but nobody holds it against you if you do.') This is in response to Joe Jared's article in _Fidonews_ 901. For the past 1 1/2 years, I have coordinated a successful cost-sharing plan for Net 285 which appears to be well-received by all. I'd like to respond to some of Joe's remarks, and I have taken the liberty of including brief quoted sections where appropriate. Right after Joe's article, 'Cost Recovery (hah)', appeared in _Fidonews_, another sysop wrote to me in our local sysops' conference asking '... do you and Larry {our alternate 'gatekeeper'} ever take any of the flak like that guy {Jared} did?' I replied that no, we do not, and with rare exception, our Net 285 sysops are appreciative, helpful, and seldom complain. I've also never heard anyone try to excuse themself from paying their fair share of the load. When I was elected NEC of Net 285, we had never had an echomail cost- sharing plan. Sysops imported echomail on an individual basis, most often at the lower speeds, and phone bills in the hundreds of dollars per month were frequent. My goal was to establish a cooperative echomail 'gateway' which would be funded by all who receive echomail through it. FidoNews 9-02 Page 4 13 Jan 1992 When I proposed the gateway to the local network, we agreed on the following principles under which it should operate: o It should be voluntary. Each sysop should be free to join or get echomail elsewhere at his/her own expense. It was my hope that the cost savings would be the incentive necessary for almost everyone in the local net to join. o It should be convenient and reliable. To me this meant that it should have its own dedicated processor, modem, and phone line. The processing and delivery of echomail should not have to compete with regular BBS usage. o Cost to the member systems should in all cases be less than what it would cost the sysop to obtain the desired quantity of data using independent means. o It should be self-supporting. Nobody should be financially burdened by it. o It should pay its own way in the nationwide Fidonet echomail system. Not only should it pay its own way locally, but it should contribute to its upstream feeds (the members recently voted a 20% 'tithe') to help with recovery of their costs. > I'd like to know how anyone can justify accounting for echomail on a > echo for echo basis. I can sum that up in one sentence. It's the only fair way to do it. In Net 285, the ratio of echomail volume between the system receiving the most and the system receiving the least is close to 100 to 1. It is simply unfair to ask the sysop who receives one low-volume echo to pay the same as the one who receives many medium and high-volume conferences. (A standing joke at our local users' group meetings is for two of the low-volume sysops to speculate if their combined bills for the month are enough to buy me a soda from the machine. ;-) If all sysops wanted roughly the same volume of data, I could see how a flat-rate scheme might work, but in our case (as I am sure is the case in many other networks) the low-volume sysops would be subsidizing those who had higher volume. > When it's all averaged out, the cost of accounting would > significantly outweigh the cost of charging a toll for backbone > echomail. The cost of accounting ?? What cost ?? We let the machine do the grunt work of keeping track of who gets what. It maybe takes a few extra minutes of machine time per month at most. The accounting utility is a simple 'c' program driven by a called batch file which runs every time the message areas are cleaned up and purged. Something like this can easily be written in less than an hour by anyone who has had a couple of programming courses. I'm sure that many teenage hackers with no formal instruction could easily write such a program. It's almost trivial. It could even be done (although more slowly) by redirecting each message directory to a text file and processing the result with an AWK script just prior to cleanup. FidoNews 9-02 Page 5 13 Jan 1992 > I don't believe for a minute that any single node can pickup > even 1 echo with the speed and reliability of a backbone net hub > for less than it costs if everyone contributed. There are cases where it will not pay for someone to use our system, and I believe it should be the choice of the individual sysop whether or not to join a plan such as ours. We have one node that cannot benefit from our cost-sharing plan. Due to the oh-so-close-but-yet-so-far extortive in-state telephone rates, he can call the regional hub directly for less than he can call us. (We're working on some innovative [and legal] ways around this, but as of this time we do not have an effective solution to this problem.) If he were to join the gateway, he would pay twice, once as his share for getting the data to the gateway, and another to get the data from the gateway to his node. Certainly this extra burden would far outweigh the cooperative cost savings. Some numbers ... One local system always comes in under a dollar each month. He is certainly saving. Some systems exceed $20 per month, but those are the exception and not the rule. Most systems fall somewhere between the extremes. The cost of a 2-3 minute long distance call each day easily exceeds what many systems pay for echomail using the gateway. If we assume a reliable 9600 bps feed, a plan with a major long distance carrier that charges about $.10 per minute for phone time, and a 50% compression of echomail using ARC or ZIP, it should cost right around $0.0089 to import each kilobyte (unpacked) of echomail into the local network. Now when we take into consideration the sharing of some of these echoconferences, the actual cost of each kilobyte typically runs $0.007 or so at most, even considering the inefficiencies of session startup, orphan portions of minutes, etc. We can even add a 20% 'tithe' to our upstream feed and come in lower than the 100% efficient cost. Toward the future ... Our network is small, but growing. As more systems join the network, more echoconferences are shared, and everyone's cost per kilobyte drops. As sessions grow longer, the overhead of session startup and unused portions of minutes becomes less and less significant. Since our gateway system is dedicated, it will be able to meet the echomail needs of the network as it grows and requires more volume of data. In conclusion, I will say that there is no such thing as a one-size- fits-all echomail scheme. What works for one network might not work for another. However, I think that any cost-sharing plan, in order to serve the network to its best, must be voluntary, equitable, under the control of the network sysops as a whole, and should not be a financial burden to anyone. FidoNews 9-02 Page 6 13 Jan 1992 Good day JSW . . . . . ---------------------------------------------------------------------- Geography and Fidonet by Daniel Tobias, 1:380/7.0 Once again, the question that has led to much political strife within FidoNet rears its ugly head: the issue of whether nets, regions, and zones must be strictly constrained by geographical boundaries, or whether a more "creative" interpretation should be applied to permit nodes to overlap these boundaries where it suits a need. The latest volley in this battle is the article by Dennis McClain- Furmanski (1:275/42.0) in FidoNews 901. In it, he raises a valid gripe of inconsistency on the part of the FidoNet hierarchy: they vehemently disallowed the addition of Cuban notes to his U.S. net, even though due to a geopolitical quirk those nodes (on a U.S. military base) were actually more directly connected, in telephone topology, to Net 275 than to the "geographically-correct" Zone 4. However, in an unrelated squabble later, the same hierarchy "looked the other way" at some blatant violations of geography on the part of an adjacent net (which seems to be having a "turf war" with net 275, from the looks of things). This is blatantly inconsistent, and results in feelings of unfairness on the part of those affected by these rulings, whatever the reasons for them might have been. However, McClain-Furmanski's response hardly seems likely to improve the Fairness Quotient. Rather than attempting to get the hierarchy to reach a consistent, impartial resolution of the geographical problems that affect Net 275, he has (on what authority?) unilaterally declared these two decisions to both be reversed, to agree with HIS desired positions. In case no other FidoNews reader has noticed, this mirror- reversed position is STILL fundamentally inconsistent; it is just fundamentally inconsistent in the direction of supporting Mr. McClain- Furmanski's wishes, which presumably is thus regarded as fairer by him and his friends, but not by anyone on the other side of the issues in question. It is certainly not a generalized solution to the problem of geography. While the hierarchy disallowed Cuban nodes for Net 275 but allowed another net to "raid" its territory, the new "solution" is to arbitrarily ban geographical exceptions for the neighboring net, but allow them for Cuban nodes. No lasting solution to FidoNet's political woes will result from different people unilaterally declaring the geographical exceptions THEY want to be good, and those that THEY dislike to be bad, and attempting, successfully or not, to make their wishes binding on everyone else. To end such squabbles, it is necessary to have a universal, binding rule that everyone can live with. Two possibilities: FidoNews 9-02 Page 7 13 Jan 1992 1) Allow no exceptions whatsoever to geography. All nodes would be forced to join the zone, region, and net of their location. Somebody can take a world map and parcel things out so there isn't a square inch of land anywhere that isn't covered. ADVANTAGES: If the net/region/zone affiliation of a node is predetermined, one can hope there would be fewer squabbles about whether some particular node assignment should be made. Also, the nodelist would have a very logical structure, making it easier for a newcomer to locate nearby nodes wherever he might be, or wherever he might have a friend he'd like to send FidoNet mail to. DISADVANTAGES: Often, due to the peculiarities of phone systems or other unusual circumstances, people would be forced into a net or zone which is inconvenient for mail-routing purposes. Also, to the extent that the coordinator structure serves as politicians as well as technical administrators, some people would end up subject to political "fiefdoms" they dislike, with a monopoly of power over their areas much like feudal lords. HOWEVER: This needn't be insuperable, given intelligent management of the net. Echomail feeds needn't be constrained by zone or region membership, though some net politicians seem to want to force this. Intelligent mail-routing software can be made to send mail in appropriate channels regardless of the actual node numbers involved. And if the coordinator structure sticks to mere technical coordination rather than powermonging, it needn't be an intolerable situation to be compelled to be a member of a particular part of the net. 2) Remove all mandatory geographic restrictions. Assign each zone, region, and net a geographical area and encourage nodes to follow it, but don't make it a rule that they must. Somebody wishing to join elsewhere, and finding a NC who agrees to allow it, should be permitted to do so, regardless of who else bellyaches about it. ADVANTAGES: This would also hopefully end the squabbles about whether some particular exception should be allowed, as they all would be. Also, such a laissez-faire policy would promote general freedom, discouraging the "fiefdom" mentality on the part of power-hungry coordinators at all levels. People finding one ruler intolerable might change their affiliation to another. This could defuse some squabbles by providing an exit route. DISADVANTAGES: The nodelist would acquire a crazy-quilt appearance, with many nodes in apparently-illogical positions, making it more difficult for newcomers to figure out, or for people to locate a node in a particular place. Nodes who were excommunicated for valid reason might try to pop up elsewhere in the net to cause more trouble. And some of the power-mongers might simply trade a "feudal lord" mentality for a "used car salesman" one, and begin making a pest of themselves running "ad campaigns" to entice nodes to switch their affiliation to one net instead of another. FidoNews 9-02 Page 8 13 Jan 1992 HOWEVER: Controls can be put in place to prevent excommunicated nodes from rejoining the network at any point without permission of the Zone Coordinator. And most nodes will probably prefer to remain in their geographical nets, so the nodelist might not be as mixed-up as some would think. Anyway, Usenet and Internet get along fine with domains and topologies that have barely any connection to geography. People looking for nodes in a given area can still do a text search of the full nodelist with any of a number of different programs. In closing, I think some sort of consistent policy should be adopted regarding geography, rather than a patchwork of exceptions in some places and strict enforcement in others. But, more importantly, a lot of the problems would be solved if everyone would just lighten up a bit; this is just a hobby, after all. Is it really the end of the world if some neighboring net is allowed to "aggrandize" itself by adding nodes that "by rights" ought to be in your net? On the other hand, is it catastrophic if you are compelled by the hierarchy to obtain a node number with a different net or zone at the head of it than the one you like best? You can still send and receive mail from anyone else regardless of what arbitrary numbers you are assigned, and your friends can set their configuration files to send it directly to you even if the nodelist structure says it should go through a "zone gate." The whole issue really isn't such a big deal for any sysop or coordinator who is primarily concerned with the technical aspects of the network; it only "matters" when people want to turn the network into a big political playground, populated by coordinators who like to ego-trip by increasing the number of nodes beneath them and the level of power they have over them; and sysops who see all actions of coordinators as a massive, evil conspiracy they must fight. Under these mindsets, it's a "big deal", but it doesn't particularly matter to the rest of us who are just trying to run our boards. ---------------------------------------------------------------------- Sara Gordon 1:227/190 VFR Systems AntiVirus BBS (219) 273-2431 Net 1:227 mourns the loss of Gerald Opperman (1:227/125) who passed away January 1, 1992. Gerry was a driving force behind Net 227 for a number of years, having served as NC, sysop, adviser and friend. Gerry did it all and did it well. As sysop of River City Network, Gerry brought multi-line BBSing into its full bloom in Michiana. He was always found on the other local boards as well, chatting into sun-up; always there to lend a hand, to help in anyway, with any thing. FidoNews 9-02 Page 9 13 Jan 1992 Gerry's contribution to sysops and users alike is immeasureable. It is said that generosity of the spirit is the measure of a man. It was true in his case; he was a great man and a good friend to all who knew him. Gerald Opperman July 8, 1946 -- January 1, 1992 * On a personal note, Gerry always told me he wanted his epitaph to read "NO CARRIER" He did perform this ultimate hack, as now all the machines and modems in the world now pay him daily tribute. He'd be proud of himself. Warpspeed, old friend. I'll never forget you. Sara Gordon ---------------------------------------------------------------------- The WorldPol Project 4:4/50@FidoNet INTRODUCING WORLDPOL VERSION 2C A new update of the FidoNet Worldwide Policy Document proposal has been now released. It reflects the changes being discussed in the WORLDPOL echo. The WORLDPOL echo is a public echomail conference open to anyone wishing to participate in it. It is distributed worldwide by the Independent Distribution System, and currently available at the following locations: Zone-1: 1:128/77, 1:133/411, 1:142/928, 1:157/603, 1:250/99, 1:273/909 and 1:367/1. You can request a feed from any of these systems or from your echomail coordinator if you are in Region 12 (Eastern Canada). Zone-2: 2:257/102 is the European gateway. Check with Noel Bradford for your nearest link. Zone-4: 4:900/130, 4:900/202 and in any system of the Zone-4 backbone. Zone-6: 6:600/300 in Singapore and 6:720/13 in Taiwan. W o r l d P o l The FidoNet Worldwide Policy Document FidoNews 9-02 Page 10 13 Jan 1992 Version 2c, 11 Jan 1992 This Worldwide Policy document has been released for vote by the members of FidoNet and is not yet in force. 1 FidoNet This document establishes an international (inter-zonal) policy for system operators who are members of the FidoNet network of FidoNet-compatible electronic mailers. FidoNet is defined by a list of nodes (NodeList) issued on a weekly basis by each of the Zone Coordinators, on behalf of the International Coordinator. 1.1 Scope A node is understood to be a "member system" of FidoNet. The collection of nodes is classified into Zones, Regions and Networks. Each FidoNet Zone is entitled to issue its own policy document according to its own needs and customs. This International Policy determines general rules common to FidoNet nodes in all zones. Regions and Nets may also issue their own policies according to the provisions in any corresponding Zone Policy, provided that they do not contradict this policy. 1.2 Overview FidoNet is an amateur electronic mail system. As such, all of its participants and operators are unpaid volunteers and/or hobbyists. From its early beginnings in 1984 as a few friends swapping messages back and forth mainly in North America, it consists now of an International community of more than 13,000 nodes worldwide. FidoNet is not a common carrier or a value-added service network. FidoNet is a public network only as much as the independent member nodes may individually provide public access to the network via their system. FidoNet exists to provide electronic mail services to its member nodes. To efficiently provide such services, various structure and control mechanisms have been established. The structure and administration of FidoNet is detailed in this document. FidoNews 9-02 Page 11 13 Jan 1992 This document outlines procedures at the international level of FidoNet as well as some general policies common to all levels. 2 Language Each zone has the right to determine its own official language. For practical purposes, FidoNet adopts English as its official language at the international (inter-zonal) level. All the FidoNet documents issued at the international level must exist in English. Translation into other languages is encouraged. 3 Admittance to FidoNet FidoNet membership is open to everyone fulfilling the technical standards described on a document released by the network's Technical Standards Committee (FTS-0001 at this writing). Lower-level policies may issue additional restrictions only if specifically authorized by the Zone Coordinator Council. 3.1 Anti-discrimination Policy Discrimination is not permitted within FidoNet. This means that any type of restriction imposed to a member of the network that has no technical justification is unacceptable. No technical requisites will be demanded to any member of the network than those specifically authorized by this or lower-level policy documents. 4 Organization The organizational structure of FidoNet has been developed to distribute the administration and control of FidoNet to the lowest possible level, while still allowing for coordinated action over the entire system. Effective administration is made viable by operating in a top-down manner. This means that a person at any given level is responsible to the level above, and responsible for administrating the level below. If a person at any level above sysop is unable to properly perform their duties, the person at the next level may replace them temporarily, until new elections are held. For example, if a Region Coordinator fails to perform, the Zone Coordinator may cause the Coordinator to be replaced. FidoNews 9-02 Page 12 13 Jan 1992 Coordinators may also be removed by a majority vote of the level below. For example, if network Coordinators in a region lose faith in the ability of a Region Coordinator to effectively perform, they may vote to have a new Coordinator elected. 4.1 Zone Coordinator Council The Zone Coordinator Council (ZCC) consists of the Zone Coordinators and the International Coordinator. Each Zone Coordinator has one vote at the ZCC. The International Coordinator may only vote in the event of a ZCC vote tie, but does not regularly have voting power. The Zone Coordinator Council is the legislative body of FidoNet, it represents each of the zones in FidoNet. It is the highest authority of the network's Top-Down organization. 4.2 International Coordinator The International Coordinator (IC) is the Executive Officer of FidoNet and coordinates the joint production of the master nodelist by the Zone Coordinators. The International Coordinator is responsible for creating new zones in FidoNet, but can only do so with the approval of a simple majority of the members of the Zone Coordinator Council. The International Coordinator is selected by unanimous vote of the Zone Coordinators, and removed by a majority vote of the Zone Coordinators. In the case of absence of the International Coordinator, the Zone Coordinator Council replaces her/him by voting on all IC resolutions to be approved by a simple majority. 4.3 Zones and Zone Coordinators A zone is a grouping of Regions generally consisting of several countries, whose borders are determined by the Zone Coordinator Council. The Zone Coordinator is the Executive Officer of the Zone, and the zone's representative to the other zones. The Zone Coordinator compiles the nodelists from all of the regions in the zone, creates a master nodelist and a difference file, which is then distributed over FidoNet within the zone. A Zone Coordinator does not perform message-forwarding services for any nodes in the zone, whereas the Zone Coordinator is responsible for the formation and/or administration of one or more zone-gates to provide inter-zone mail facilities. FidoNews 9-02 Page 13 13 Jan 1992 The method used for selection of Zone coordinators is left to the discretion of the relevant Zone Policy. In the absence of a Zone Policy selection method, Zone Coordinators are elected and removed by a simple majority vote of the Region Coordinators in the Zone. 4.4 Regions and Region Coordinators A Region is a defined geographic area containing nodes which may or may not be combined into networks. A typical Region will contain many nodes in networks, and a few independent nodes which are not part of the Region's other networks. The Region Coordinator maintains the list of independent nodes in the region, and accepts nodelists from the Network Coordinators in the Region. These are compiled to create a regional nodelist, which is sent to the Zone Coordinator. A Region Coordinator is encouraged to perform message-forwarding services for nodes within the region, but is not forced to, unless the appropriate Zone or Region policy imposes such a requirement. The method used for selection of Regional coordinators is left to the discretion of the relevant Zone or Region Policy. In the absence of such a policy selection method, Region Coordinators are elected and removed by a simple majority vote of the Ncs in the Region. 4.5 Networks and Network Coordinators A network is a group of related nodes. Networks coordinate their mail activity to decrease cost. The Network Coordinator is responsible for maintaining the list of nodes for the network, and for forwarding netmail sent to members of the network from other FidoNet nodes. The Network Coordinator may make arrangements to handle outgoing netmail, but is not required to do so, unless the appropriate Zone, Region or Net policy imposes such a requirement. The Network Coordinator is required to assign a valid node number to each and every qualifying petitioner within 3 weeks from the request. A petitioner may only be deemed unqualified if she/he cannot meet current Fidonet Technical Standards. The NC must inform the petitioner of the grounds for any rejection. The method used for selection of Network coordinators is left to the discretion of the relevant Zone/Region/Net Policy. In the absence of such a policy selection method, Network Coordinators are elected and removed by a simple majority vote of the Nodes in the Network. FidoNews 9-02 Page 14 13 Jan 1992 4.5.1 Network Routing Hubs Network Routing Hubs exist only in some networks. They may be appointed by the Network Coordinator, in order to assist the management (especially routing tasks) of the network. 4.6 Individual systems (Nodes) The smallest subdivision of FidoNet is the individual system, corresponding to a single entry in the nodelist. The system operator (SysOp) formulates a policy for running the board and dealing with the users. The sysop must mesh with the rest of the FidoNet system to receive and send mail, and the local policy must be consistent with other levels of FidoNet. 4.6.1 Users of an individual system The sysop is responsible for the actions of any user when they affect the rest of FidoNet (i.e. if the user is annoying, the sysop is annoying). The users have no rights under this policy document. 4.6.2 Points A point is a system that is not in the nodelist, but communicates with FidoNet through a node defined to as bossnode. The bossnode operator is responsible for all mail originating at the point. All mail sent to a point is addressed to the bossnode's address. Points are generally regarded as users of an individual system. 4.7 The FidoNet Technical Standards Committee The FidoNet Technical Standards Committee, abbreviated as the FTSC, exists for the purpose of establishing minimum requirements in software and hardware to be able to interface with FidoNet. These minimum requirements must be obeyed at every level. Nodes not meeting these requirements are ineligible for a node number (see section 5.9). These requirements are subject to change at any time by the FTSC. 5 General Procedures for All Coordinators FidoNews 9-02 Page 15 13 Jan 1992 5.1 Making Available Difference Files and Nodelist Each Coordinator is responsible for obtaining and making available for file request, on a weekly basis, nodelist difference files and complete nodelists. 5.2 Making Available FidoNews Documents FidoNews is the Official Newsletter of FidoNet. Each Coordinator is responsible for obtaining and making available for file request on a weekly basis, FidoNews Documents. This requirement may be waived in the event that a majority of the Sysops served by the Coordinator have no desire to read or receive FidoNews. If a Zone Coordinator is not able to get FidoNews into her/his Zone, he should immediately request help from the FidoNews Editor. If the Editor can arrange a way to have it delivered to the Zone Coordinator, FidoNews must be necessarily available to the rest of the Zone. Otherwise, the Zone Coordinator may unilaterally waive this requirement. 5.3 Processing Nodelist Changes and Passing Them Upstream Each Coordinator is responsible for obtaining nodelist information from the level below, processing it, and passing the results to the level above. The timing of this process is determined by the requirements imposed by the level above. 5.4 Ensure the Latest Policy is Available A Coordinator is responsible for making the current version of the International Policy available to the level below, and to encourage familiarity with it. 5.5 Minimize the Number of Hats Worn Coordinators are persuaded to limit the number of FidoNet-related Coordinator functions they perform. A Coordinator who holds two different positions, compromises the appeal process. For example, is the Network Coordinator is also the Region Coordinator, sysops in that network are denied one level of appeal. Multiple hats are also discouraged due to the difficulty of replacing services when a coordinator leaves the net. FidoNews 9-02 Page 16 13 Jan 1992 5.6 Be a Member of the Area Administered A Coordinator must be a member of the area administered. This is, a Network Coordinator must be a member of the network s/he is to coordinate. A Region Coordinator must be either a member of a network in the region, or an independent in a region. 5.7 Encourage New Sysops to Enter FidoNet A Coordinator is encouraged to operate a public bulletin board system which is freely available for the purpose of distributing Policy and Nodelists to potential new sysops. Dissemination of this information to persons who are potential FidoNet sysops is important to the growth of FidoNet, and Coordinators should encourage development of new systems. 5.8 Tradition, Precedent and Technical Management A Coordinator is not bound by the practices of predecessor. However, it must be clear that Coordinators are bound by all requirements of this document, both as FidoNet sysops and as Coordinators. The holding of a Coordinator title does not grant license to annoy others or to flaunt policy. The primary responsibility of any Coordinator is technical management of network operations. Decisions should normally be made only on technical grounds. A Coordinator has the responsibility to act as objectively as possible; objectivity must be considered an essential factor when making a decision. 5.9 Exclusivity of Zone Mail Hour Zone Mail Hour is the heart of FidoNet, as this is when network mail is passed between systems. Any system which wishes to be a part of FidoNet must be able to receive mail during this time using the protocol defined in the current FidoNet Technical Standards Committee publication (FTS-0001 at this writing). It is permissible to have greater capability (for example, to support additional protocols or extended mail hours), but the minimum requirement is FTS-0001 capability during this one hour of the day. This time is exclusively reserved for netmail. Many phone systems charge on a per-call basis, regardless of whether a connect, no connect, or busy signal is encountered. For this reason, any activity other than normal network mail processing that ties up a system during ZMH is considered annoying behavior. User (BBS) access to a system is prohibited during ZMH. FidoNews 9-02 Page 17 13 Jan 1992 Zone Mail Hour will be defined by each Zone Policy. In the absence of a Zone Policy, it will be defined by the Zone Coordinator. Zone Mail Hours for all zones should be published every week in FidoNews, as well as in the nodelist. 6 Election and Referendum Procedures Any election or referendum at any level of FidoNet must comply with the standards described in this chapter. 6.1 Democratic Qualities of the Election All sysops in FidoNet have a vote and must be allowed to participate in an election or referendum. All sysops in FidoNet are entitled to be candidates to any elective position, provided that the requirements for each position described on this and lower-level policy documents are satisfied. 6.2 Particular election mechanisms Each zone will issue its own election procedures, which may involve direct participation or indirect participation (electoral college approach). In any case, all the sysops in the zone must be allowed to vote. In the case of an indirect elections, the electors must be chosen by direct vote of the sysops. 6.2.1 Coordinators acting as Electors Coordinators will automatically be qualified as electors representing their network or region in an indirect election only if they have been chosen by direct vote of the sysops in the administered area. 6.3 Worldwide elections and referendums In worldwide elections and referendums with the participation of all zones, the Zone Coordinator Council will determine the election procedures and whether vote will be direct or indirect. This will be done in each particular case by form of a ZCC resolution. FidoNews 9-02 Page 18 13 Jan 1992 7 Policy Referenda 7.1 International Policy A referendum on International Policy modification is invoked by the International Coordinator at the direction of a majority of the Zone Coordinators, or a majority of the Region Coordinators of all zones, a majority of the Network Coordinators of all zones, or by one third of all the sysops in all zones. All the members of FidoNet are entitled to vote on an International Policy referendum, which is to be held according to the procedures described by the Zone Coordinator Council before the election is called. 7.2 Zone Policy A referendum on Zone Policy modification is invoked by the Zone Coordinator, by a majority vote of the Region Coordinators in the zone, by a majority vote of the Network Coordinators in the zone, or by one third of all the sysops in the zone. All the members of the zone are entitled to vote on a Zone Policy referendum, which is to be held according to the procedures described on the Zone Policy. If such document does not exist, the procedures will be determined by the Zone Coordinator with the approval of the Zone Coordinator Council. The formulation of Region and Network Policy documents is encouraged, and must be regulated by the Zone Policy documents in each zone. 7.3 Transition to a 'Worldwide Policy environment' After the approval of this Worldwide Policy, the previously existing policy will still be in effect for the Zone level until the approval of a new Zone policy, according to the methods provided in this document. All the procedures introduced by this Worldwide Policy document adjourn the procedures existing in the previous policy document. 8 Resolution of Disputes The FidoNet judicial philosophy can be summed up in two rules: 1) Thou shalt not excessively annoy others. FidoNews 9-02 Page 19 13 Jan 1992 2) Thou shalt not become excessively annoyed. The parties involved in a dispute are encouraged to solve their problems directly, without the intervention of a Coordinator. 8.1 Mediation Requests Any of the parties involved may request the intervention of the respective Coordinator: Network Coordinator if a dispute between members of the same network, Region Coordinator if a dispute between members of different networks on the same region; Zone Coordinator if a dispute between members of different regions on the same zone; International Coordinator if a dispute between members of different zones. The Coordinator requested to act as "mediator" will ask each party to provide all information relevant to the request within two weeks from the request being made and will make a decision within forty-five days after s/he received all the information from the involved parties. A Coordinator, unable to resolve a dispute, may name a third party to act as "mediator," provided the parties involved in the dispute agree. 8.2 Appeals to a Mediator's Decision A mediator's decision may be appealed to the immediately superior level if considered unfair: Region Coordinators handle appeals from decisions made by Network Coordinators; Zone Coordinators handle appeals from decision made by Region Coordinators; the International Coordinator handles appeals from decisions made by the Zone Coordinators; and the Zone Coordinator Council will handle appeals from decisions made by the International Coordinator, decisions of the Zone Coordinator Council are not subject to appeal. For appeals to a decision made by a third person named by a Coordinator to act as mediator, it will be as if the Coordinator made the resolution and the previously enumerated sequence of appealing will be appropriate. For appealing to a decision made by a mediator, the same terms and procedures as for any Mediation Request apply. 8.3 Statute of Limitations A mediation request may not be filed more than 60 days after the date of discovery of the source of the infraction, either by admission or technical discovery of the source of an infraction, either by admission or technical evidence. Mediation requests may not be filed more than 120 days after the incident, unless they involve suspected unlawful behavior, in which the legal statute FidoNews 9-02 Page 20 13 Jan 1992 of limitations of the country involved shall apply. 8.4 Echomail and File Distribution Networks Each FidoNet Zone is encouraged to establish in it's Zone Policy, the manner of handling Echomail and File Distribution, and the resolution of disputes arising from both distributions. No sysop may be required to carry an echomail conference or a File Distribution as a condition of joining or remaining in FidoNet, with the exception of a single restricted traffic announcement echo used to pass important information to nodes within a network. 9 "CCC": Comments, Credits and Copyright! This section will be automatically removed upon approval of this document. 9.1 Comments on Implementation This document is not final. No FidoNet policy is or will ever be. WorldPol is an open enterprise where every member in FidoNet is encouraged to participate. It is a unique experience, so far successful. If you disagree with any point of this document, you have a real opportunity of have your voice be heard and contribute to the future of FidoNet. All FidoNet sysops are encouraged to make suggestions for changes, as well as comments, which can be addressed to FidoNet node 4:4/50 (WorldPol Project). The WORLDPOL echo is also a good means of doing this; contact 1:102/631 for information on how to access the independently-distributed WORLDPOL echo. This World Policy will be adopted according to the mechanisms provided on the present policy document. 9.2 Credits WorldPol has received either directly or indirectly, input from the following individuals (in alphabetical order): Raul Artaza, Don Benson, Bill Bolton, Steve Bonine, Randy Bush, Billy Coen, Phillip Dampier, Jack Decker, David Deitch, Daniel Docekal, Ron Dwight, Luis Garcia-Barrio, Hector Gomez, Tomas Gradin, Jackson Harding, Rob Hoare, Jesse David Hollington, Alejandro Hopkins, Tom Jennings, Glen Johnson, Daniel Kalchev, Raymond Lowe, Rick Moore, George Peace, Vince Perriello, Bob Satti, Jerry Schwartz, Jan Stozek, Erik Van Riper, Matt Whelan, and Gustavo Zacarias. FidoNews 9-02 Page 21 13 Jan 1992 Thank you all. Special thanks are hereby given to Thomas Jefferson whose ideas were still in the 1990s an important source of inspiration for this document. 9.3 Temporary Copyright This document is Copyright (C) 1992 by Pablo Kleinman. Todos los Derechos Reservados / All Rights Reserved. This document is protected under international copyright laws. ---------------------------------------------------------------------- * When YOUR the fan, duck! [New Year; Same Shit!] When YOUR the fan, duck! By Trevor Merritt (1:161/600) If you were a fan, and the shit was about to hit, don't you think it would be a good idea to duck? If only the majority of us could. This article has quite a bit... Some.... Little (very little) to do with Fidonet, except that I operate a BBS (okay, I'm a Hub system) in it. Since this is the first article I have submitted to FidoNews, let me start by letting you all know who I am, why I am writting this, and what I intend you the reader to gain from it. My name is Trevor Merritt, and I live in Fairfield, California, USA. For those of you that don't know where it is, don't look for it on a map. Look for San Francisco and Sacramento California. Fairfield is in-between. I have operated a BBS for about three and a half years. Recently, the NC of the Net I was in decided that he didn't want to BBS any more, and assumed that nobody wanted the Job. To some extent he was right. So, I immediately re-joined the Net I was in before. Seems a bunch of the rest of them wanted to remain in Fidonet as well, so I became a Hub. Other than running a BBS, I also work (if only I didn't have to). I work for a Credit Union, although sometimes people think I live there. Hey, what do you expect when your title is Computer Operations Coordinator. I am writting this article because... I have better things to do and just don't feel like doing them right now. Also, I wanted the let those people out there who had a terrible new years eve/day know that they aren't the only ones. Hopefully, the reader will gain something. I don't rightly know what it will be, and don't care, but you'll probably find it funny at the least. So, here we go, my New Year [Same Shit]. FidoNews 9-02 Page 22 13 Jan 1992 31Dec91 - Things started going wrong just about the time everyone was prepareing to leave work, and go out partying. Not me, by my own choice I would be starting later; I had decided to close and perform the year end backup of the system myself. The time was 5:18 PM (console logs don't lie). Year end, and everything needs to be done in exactly the right order. Okay, here we go. I stop transaction logging. I set the date forward. I backup the system to tape. I run the year end job file..... Uh oh.... SHIT!!! I wasn't supposed to set the date forward! The software won't allow the date to be turned back, because the year end processing has already started! Okay, don't panic... You can still be outa here by midnight. We just need to do a reload from last nights backup. All the transactions are on the logging tape... Except the batch runs. Those need to be keyed in again. That means that recieved files (Electronic Funds Transfers, Etc.) will need to be reloaded for those batch jobs that process them. No problem. 01Jan92, 1:25 AM - Almost done. Just one more file to reload so that it can be processed. Okay... And the ATM transaction journal is over $350,000.00 off!!! How can that be! Hmmm.... No, that can't be right... the date on the file is December 26th. Someone didn't put the right tape number in the log book! Well, for the sake of making this article a little shorter, I'll abreviate the rest. Finally located the RIGHT tape, had to reload AGAIN. Executed all the Batch jobs, the journals still aren't correct, but close enough considering that I haven't done the recovery posting from the transaction logging tape. Revovery posting completes, and everything balances. Okay, I make another backup, and run the year end job. Okay, now I can go home! And look, it's only 6:34 AM!!! Let's see, I arrived at work on 31Dec91 at 8:55AM, and left work 01Jan92 at 6:34 AM. Not counting luch hour, that makes 20.5 hours straight! Now the funny part. I'm salaried, exempt. No over-time. But, you know the next time I want a comp day, I better get it! In parting, I'm sitting here now reading the latest copy of LAN TIMES (December 30, 1991, Vol.8, issue 24). I just love the "In The Trenches" article they fill the inside back cover with. And I quote "Then we sent a message telling everyone [on the LAN] that it would be down for a few hours for maintenance. (heh, heh, heh, users can be sooooo naive)". Ain't it the truth! Oh, and I also loved the statement that Ron Skates of Data General made. "...We've got a terrible budget deficit. There's no reason we can't fire 25% of the government tomarrow..." Thank you for reading the rabblings of a fellow computer warrior. If you have a direct comment to make on this article please send NetMail to 1:161/600, Bushido BBS - The [Computer] Warrior's BBS. ---------------------------------------------------------------------- FidoNews 9-02 Page 23 13 Jan 1992 ====================================================================== RANTS AND FLAMES ====================================================================== _(*#$_(*@#(* (*^$+)#(%&+| #$)%(&*#_$ @_#( @$ ^@#+)(#&%$*+)$%&*+$*%&#@(@#_|)*%|)#%&)#*%&+(@#&*_+(@#*^&@### *&#_($*&#$_(*#&$_(#*$&$ _(#$*#$+)#($&*+#)$ &#+$*&# ()*&#$_(&^#$_(#*$_#($^&#_$(^&#_$(&^#$_(&#^ damn right _(#^&$_(#^& $*&#$_+(* #)$&(%($%+)($%*+$)%($* it's ugly _#&%^# & #($_*#$_ FidoNet (*$&%_@#_(*&@#_(@*#&_ @#_(*&@#_(* )*&#$ Flames *^$+)#(% (not for the timid) @_#( (*#$_(*^@#+) and #_|)*% &+(@#&*_+(@#*^&@### (#$*&#_($*&#$_(*#&$_(#* Rants *&+#$*&#+$*&# )*&#$_(a regular feature)^&#_$(&^#$_ $^&#$_(#^ (*^#$_*#^&$)*#&$^%)#*$&^_#($*^&#_($ Section #&%^_ _(*#&$_(#* #($*& #$* _(*&@#_(@*# *&@#_(*& )&*+_)*&+)*&+))&*(*& (*&_(*&_(*& ---------------------------------------------------------------------- FidoNews 9-02 Page 24 13 Jan 1992 ====================================================================== LATEST VERSIONS ====================================================================== Latest Greatest SoftWare Versions Last Update: 01/02/92 - Happy New Year!!!! ---------------------------------------------------------------------- MS-DOS Systems -------------- BBS Software NodeList Utilities Compression Name Version Name Version Utilities -------------------- -------------------- Name Version Aurora 1.32b EditNL 4.00 -------------------- DMG 2.93 FDND 1.10 ARC 7.12 DreamBBS 1.05 MakeNL 2.31 ARJ 2.20 Fido/FidoNet 12.21 Parselst 1.33 LHA 2.13 Genesis Deluxe 3.2 Prune 1.40 PAK 2.51 GSBBS 3.02 SysNL 3.14 PKPak 3.61 Kitten 1.01 XlatList 2.90 PKZip 1.10 Lynx 1.30 XlaxNode/Diff 2.53 Maximus-CBCS 2.00 Merlin 1.39n Opus 1.73a* Other Utilities(A-M) Other Utilities(N-Z) Oracomm 5.M.6P@ Name Version Name Version Oracomm Plus 6.E@ -------------------- -------------------- PCBoard 14.5a 2DAPoint 1.50* Netsex 2.00b Phoenix 1.07* ARCAsim 2.31 OFFLINE 1.32@ ProBoard 1.20* ARCmail 2.07 Oliver 1.0a QuickBBS 2.75 Areafix 1.20 PKInsert 7.10* RBBS 17.3b ConfMail 4.00 PolyXarc 2.1a RemoteAccess 1.10 Crossnet 1.5 QM 1.00a SimplexBBS 1.05 DOMAIN 1.42 QSort 4.04 SLBBS 2.15C* DEMM 1.06 RAD Plus 2.11 Socrates 1.11 DGMM 1.06 Raid 1.00 SuperBBS 1.12* DOMAIN 1.42 RBBSMail 18.0 SuperComm 0.99 EEngine 0.32 ScanToss 1.28 TAG 2.5g EMM 2.11* ScMail 1.00 TBBS 2.1 EZPoint 2.1 ScEdit 1.12 TComm/TCommNet 3.4 4Dog/4DMatrix 1.18 Sirius 1.0x Telegard 2.5 FGroup 1.00 SLMail 2.15C TPBoard 6.1 FNPGate 2.70 SquishMail 1.00 TriTel 2.0* GateWorks 3.06e StarLink 1.01 WildCat! 2.55 GMail 2.05 TagMail 2.41 WWIV 4.20 GMD 3.10 TCOMMail 2.2 XBBS 1.77 GMM 1.21 Telemail 1.27 GoldEd 2.31p TGroup 1.13 GROUP 2.23 TIRES 3.11 Network Mailers GUS 1.40 TMail 1.21 Name Version Harvey's Robot 4.10 TosScan 1.00 -------------------- HeadEdit 1.18 UFGATE 1.03 BinkleyTerm 2.50 HLIST 1.09 VPurge 4.09e D'Bridge 1.30 IMAIL 1.20 WildMail 2.00 Dreamer 1.06 InterPCB 1.31 XRS 4.99 Dutchie 2.90c Lola 1.01d XST 2.3e FidoNews 9-02 Page 25 13 Jan 1992 FrontDoor 2.02 Mosaic 1.00b YUPPIE! 2.00 InterMail 2.01 MSG 4.2 ZmailH 1.25 Milqtoast 1.00 MSGED 2.06 ZSX 2.40 PreNM 1.48 MsgLnk 1.0c SEAdog 4.60 MsgMstr 2.03a SEAmail 1.01 MsgNum 4.16d TIMS 1.0(mod8) MSGTOSS 1.3 OS/2 Systems ------------ BBS Software Other Utilities(A-M Other Utilities(N-Z) Name Version Name Version Name Version -------------------- -------------------- -------------------- Kitten 1.01 ARC 7.12 oMMM 1.52 Maximus-CBCS 2.00 ARC2 6.01 Omail 3.1 SimplexBBS 1.04.02+ ConfMail 4.00 Parselst 1.33 EchoStat 6.0 PKZip 1.02 EZPoint 2.1 PMSnoop 1.30 Network Mailers FGroup 1.00 PolyXOS2 2.1a Name Version GROUP 2.23 QSort 2.1 -------------------- LH2 2.11 Raid 1.0 BinkleyTerm 2.50 MSG 4.2 Remapper 1.2 BinkleyTerm(S) 2.50 MsgEd 2.06c SquishMail 1.00 BinkleyTerm/2-MT MsgLink 1.0c Tick 2.0 1.40.02 MsgNum 4.16d VPurge 4.09e SEAmail 1.01 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, | MSGLINK 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 QNX --- FidoNews 9-02 Page 26 13 Jan 1992 BBS Software Network Mailers Other Utilities Name Version Name Version Name Version -------------------- -------------------- -------------------- QTach2 1.09 QMM 0.50s Kermit 2.03 QCP 1.02 NodeList Utilities Archive Utilities QSave 3.6 Name Version Name Version QTTSysop 1.07.1 -------------------- -------------------- SeaLink 1.05 QNode 2.09 Arc 6.02 XModem 1.00 LH 1.00.2 YModem 1.01 Unzip 2.01 ZModem 0.02f 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 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 Host Import 3.2 FidoNews 9-02 Page 27 13 Jan 1992 2.12T10 LHARC 0.41 MacArd 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.00 SunDial 3.2 CounterPoint 1.09 TExport 1.92 MacWoof 1.1 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 -------------------- -------------------- -------------------- 4D-BBS 1.65@ BinkleyTerm 1.00 Areafix 1.48 DLG Pro. 0.96b TrapDoor 1.80 AReceipt 1.5 Falcon CBCS 1.00 WelMat 0.44 ChameleonEdit 0.11 Paragon 2.082+ ConfMail 1.12 TransAmiga 1.07 ElectricHerald 1.66 XenoLink 1.0 Compression FileMgr 2.08 Utilities GCChost 3.6b Name Version Login 0.18 NodeList Utilities -------------------- MessageFilter 1.52 Name Version AmigArc 0.23 Message View 1.12 -------------------- booz 1.01 oMMM 1.50 ParseLst 1.66 LHARC 1.30 PolyXAmy 2.02 Skyparse 2.30 LZ 1.92 RMB 1.30 TrapList 1.40 PKAX 1.00 Roof 46.15 UnZip 4.1 RoboWriter 1.02 Zippy (Unzip) 1.25 Rsh 4.07a Zoo 2.01 Tick 0.75 TrapToss 1.20 |Contact: Maximilian Hantsch 2:310/6| Yuck! 2.02 Atari ST/TT ----------- BBS Software Network Mailers Other Utilities Name Version Name Version Name Version -------------------- -------------------- -------------------- FIDOdoor/ST 2.5.1 BinkleyTerm 2.40n9 ApplyList 1.00@ FiFo 2.1v The Box 1.95* Burep 1.1 LED ST 1.00 ComScan 1.04 MSGED 1.99 ConfMail 4.10 QuickBBS/ST 1.06* NodeList Utilities Echoscan 1.10 FidoNews 9-02 Page 28 13 Jan 1992 Name Version FDrenum 2.5.2 -------------------- FastPack 1.20 Compression ParseList 1.30 Import 1.14 Utilities EchoFix 1.20 oMMM 1.40 Name Version sTICK/Hatch 5.50 Pack 1.00 -------------------- Trenum 0.10 ARC 6.02 LHARC 2.01i* PackConvert STZIP 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) -------------------------------------- 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 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- FidoNews 9-02 Page 29 13 Jan 1992 The Complete List is Available For FReq as VERSIONS from 1:103/250 Utility Authors: Please help keep this list up to date by reporting all new versions to 1:103/250 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/250 ---------------------------------------------------------------------- FidoNews 9-02 Page 30 13 Jan 1992 ====================================================================== FIDONEWS INFORMATION ====================================================================== ------- 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 9-02 Page 31 13 Jan 1992 "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 ----------------------------------------------------------------------