Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!pacbell.com!tandem!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.society.development Subject: Re: Low-cost Usenet (Re: usenet in Nepal) Message-ID: <1991Jun18.065605.6955@zorch.SF-Bay.ORG> Date: 18 Jun 91 06:56:05 GMT References: <78978@eerie.acsu.Buffalo.EDU> <1991Jun14.100804.4867@iccgcc.decnet.ab.com> <1991Jun15.023819.5589@newshost.anu.edu.au> Organization: SF-Bay Public-Access Unix Lines: 97 Probably be a useful idea to start off by defining some "do and don't do" rules (or "motherhood and apple pie" baselines) for the vaporware plug and play Usenet system under consideration. 1) Not MS-DOS. Why? I spent a mercifully brief nine months working on a ten month MS-DOS project to upgrade an existing commercial software package with much more functionality to "beat the competition"; it's delivery was just announced, three YEARS late. Every problem _I_ saw was due to overstressing an architecture and an operating system already pushed far past its limits. Cheap as the hardware and OS are, building on an MS-DOS base is a recipie for failure or immediate obsolescence. Something like SCO Unix on a fairly cheap 80386 box would probably be fairly effective. AmigaUX is a SYSVr4 Unix, but a bit pricy compared to the Intel boxes, but it might be worth considering too, since the software would all be PD after the initial purchase. 2) Preemptive multitasking -- so the operator can be using the system, while the filing software is working at sorting out news/mail, while at least one user is logged in. 3) Diligient, highly directive error reporting; not just "error ### occurred", but "The last transfer was halted due to lack of spool partition space; your current expire is 3 days, run expire with a two day parameter (do a 'man expire' to see how) to get more room, or look for suspiciously overlarge or over-age files using 'find' (see 'man find')." 4) A complete online glossary and help/manual set: "what's a spool partition" should be an easy question to answer. 5) Brilliant error recovery from all the current problems; dropped user lines, dropped feed lines, overlarge file transfer, file system corruption, power loss, etc. 6) A prioritizing system to transfer files in aged "smallest files first" fashion to encourage brevity. 7) Backing store for files await transmission; this may (probably will) require operator intervention, but we shouldn't be afraid to make the system labor intensive to save costs; we have the example of amateur radio operators to show us how hard hobbiests are willing to work, we just need to make the system not be knowledge intensive, so that those diligent but unskilled can just follow directions to make it work. 8) Robust and commonly available components; we should _expect_ phone line quality problems, power brownouts, lightning storms, etc. Since repairs will be a problem, select stuff that doesn't break often, and where local spares are an affordable option. 9) Redundancy; use two lesser grade $300 systems instead of one $600 system, so that graceful failure modes exist; do this even at the sacrifice of greater overall throughput from the monolithic system. 10) A _very_ simple editor, character and line oriented, that automatically avoids transmitting overlong lines, etc. 11) Lots of optional ways to do things; hooks to use radio instead of phone instead of satellite; swap editors at the user level, locally present news as mail and vice versa, etc. 12) Respect for local character sets; probably best to just start with a 16 bit or variable length character size; this implies that each document transmitted should have a header that identifies language and character set, so that we monolinguals can pick our favorite language out of a wider discussion. While I love English as a standard language for world discussion, and it is probably the most common second language in the world, it is still not reasonable to ask local conversations to occur in English. 13) Probably tons more; someone else take a turn. Kent, the man from xanth.