DOUG@ysub.ysu.edu (Doug Sewell) (06/05/91)
In article <1991Jun4.170923.1@cc.helsinki.fi>, harmo@cc.helsinki.fi says: > >Upon further reflection I came upon quite a bad mistake in the scheme. >I believe that there are very few unix-machines (not to speak of mainframes >that could run newsreader) in Nepal, so there probably would not be much >demand, unless NTC set up a modem-based newsreading service. That would >require >quite a lot more than a simple feeding system (many incoming modems, >complicated billing, customer support, ....... a new computer culture, in a >word). Is there really no newsreaders for ms-dos -machines? If you have a 8088 MSDOS machine with 640K and an adequate hard disk, you can run Waffle to read e-mail and Usenet news. Waffle talks UUCP to Unix, and other Waffle systems as well. Waffle can be used for local news-reading or as a dial-in BBS system. It's limited to one user at a time, although I've heard rumors of run- ning two waffle sessions under Desqview. Each user has their own signon. DOS Waffle is shareware - $35/copy registration - source is available. There's also a Unix version of Waffle. By making Waffle the login shell, users have the same interface for news and mail reading as DOS Waffle. Multiple users are supported, and the host system's facilities are used for uucp, news and mail transport. Some public-access Unix systems use Waffle now. This is a commercial product, provided in source, and quite reasonable (about $120 or so). Coming back to the original point, these are some inexpensive, easy to use (from user's point of view, not necessarily the sysop's) ways to make news and e-mail access more widely available. soc.culture.nepal dropped in followups to this article, since we're getting far afield. For more information about either waffle, see alt.bbs.waffle. Doug
elkordy@acsu.buffalo.edu (Mohamed Elkordy) (06/06/91)
DOUG@ysub.ysu.edu (Doug Sewell) writes: >If you have a 8088 MSDOS machine with 640K and an adequate hard disk, >you can run Waffle to read e-mail and Usenet news. Waffle talks UUCP >to Unix, and other Waffle systems as well. Sorry, but I think I do not understand what is going on ! Is this "Waffle" a hardware or just software, and if it is only software you will definitly need modem ? and if u use modem what is the telephone number that you are going to dial from Nipal (or in my case, Egypt). It is not an 800 #, is it? thanks for your anticipated explaination. elkordy@acsu.buffalo.edu
DOUG@ysub.ysu.edu (Doug Sewell) (06/06/91)
In article <78978@eerie.acsu.Buffalo.EDU>, elkordy@acsu.buffalo.edu (Mohamed Elkordy) says: > > Sorry, but I think I do not understand what is going on ! > Is this "Waffle" a hardware or just software, and if it is only software > you will definitly need modem ? and if u use modem what is the telephone > number that you are going to dial from Nipal (or in my case, Egypt). It > is not an 800 #, is it? > Waffle is a software-only program. Yes, you need a modem, that's how you connect to another site by UUCP. I can't answer where you would hook your site to - in Egypt, there may be a university that has usenet access. In Nepal, it was suggested that since the internal phone connections are good, you would need an infor- mation/connection vendor - perhaps the phone company, or a UUNET-like organization. They would have to decide on billing arrangements. Doug -- Doug Sewell, Tech Support, Computer Center, doug@ysub.bitnet Youngstown State University, Youngstown, OH 44555 doug@ysub.ysu.edu There's smoke in the computer room! Get the gasoline!
herrickd@iccgcc.decnet.ab.com (06/14/91)
In article <78978@eerie.acsu.Buffalo.EDU>, elkordy@acsu.buffalo.edu (Mohamed Elkordy) writes: > DOUG@ysub.ysu.edu (Doug Sewell) writes: > > > > >>If you have a 8088 MSDOS machine with 640K and an adequate hard disk, >>you can run Waffle to read e-mail and Usenet news. Waffle talks UUCP >>to Unix, and other Waffle systems as well. > > Sorry, but I think I do not understand what is going on ! > Is this "Waffle" a hardware or just software, and if it is only software > you will definitly need modem ? and if u use modem what is the telephone > number that you are going to dial from Nipal (or in my case, Egypt). It > is not an 800 #, is it? > Waffle is software. To get a news system running with DOS Waffle, you need 1) a MSDOS computer with 640K and hard disk 2) Waffle 3) a modem 4) a feed - this is another news site that you can call on the phone to get news from and feed your local postings back to. 5) a copy of the Nutshell book about uucp Item 1 can be satisfied by an IBM XT or clone, 8088 with 20MBytes of disk. You will always want more disk. Item 2 can be picked up on the network. Item 3 should be at least 2400 baud. You should probably talk to the system administrator of your feed site before buying it. Speeds higher than 2400 have compatibility problems - you want to be able to use all the speed you pay for. Item 4 can be found here. You describe your location and ask for willing neighbors to let you know. For the first USENET site in Nepal, they are going to be a long distance phone call away. You might find a local feed in some places in Egypt. Either way, somebody is paying for long distance phone calls and it is good citizenship to help pay. Item 5 will help, but is still not enough. The documentation is all written in a strange dialect of English, including the Nutshell book. You will need a great deal of patience and determination and the help of the system administrator at your feed site and, probably, also help from people here on USENET. This only begins to point the way. Keep asking questions. Ask for help understanding the things above that don't make sense to you. dan herrick herrickd@iccgcc.decnet.ab.com
cmf851@anu.oz.au (Albert Langer) (06/15/91)
In article <1991Jun14.100804.4867@iccgcc.decnet.ab.com> herrickd@iccgcc.decnet.ab.com writes: >Waffle is software. To get a news system running with DOS Waffle, >you need > > 1) a MSDOS computer with 640K and hard disk > 2) Waffle > 3) a modem > 4) a feed - this is another news site that you can call on > the phone to get news from and feed your local postings > back to. > 5) a copy of the Nutshell book about uucp > >Item 1 can be satisfied by an IBM XT or clone, 8088 with 20MBytes of >disk. You will always want more disk. Technically correct. But for a high speed news feed it would be safer to get a 286 or 386, both of which will also be more useful for other software (especially 386 for possible future upgrade to unix). If you have an 8088 then use it, but don't buy one unless it is DRAMATICALLY cheaper. >Item 3 should be at least 2400 baud. You should probably talk to the >system administrator of your feed site before buying it. Speeds higher >than 2400 have compatibility problems - you want to be able to use >all the speed you pay for. It will be cheaper to buy your feed site a high speed modem as well as buying your own than to use 2400 baud for international news feeds to Egypt or Nepal etc. Trailblazer PEP has the best reputation for difficult international circuits. V32.bis is next choice, HST third choice (but of course you must have the same as your feed). Also get 16550AN USART to replace the 16440 USART on serial card and use a FOSSIL that takes advantage of it. Both Waffle and FOSSILs are available from simtel. 2400 baud may be economically ok if you have a local call feed but would still be a nuisance. Any long distance feed should be higher speed even if not international. (Perhaps a file of "consensus" advice could be built up from discussions in this group - including EXACTLY where and how to get software and hardware and explanations of conflicting opinions. Include within a FAQ or point to it from one. Better still, prepare a "kit" with simplified installation and tutorial manuals etc.) BTW, I think fido software would be better for the actual file transfers than uucico, especially on difficult international links (mainly because of resuming after a lost connection, but also slightly more efficient and easier to configure schedules etc). How about combining a BinkleyTerm mailer with Waffle for the "kit" (needs a similar feed of course)? -- Opinions disclaimed (Authoritative answer from opinion server) Header reply address wrong. Use cmf851@csc2.anu.edu.au
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (06/18/91)
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. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
trifid@agora.rain.com (Roadster Racewerks) (06/19/91)
Oh, you've sure pushed on of *my* favorite buttons! A really GOOD editor....what I wouldn't give for an online editor similar to "QuickEd" by the Dirosh brothers (used on my favorite local systems running QuickBBS software)! Cursor in all directions, insert and delete single character if need be, quote only one line at a time, as chosen by you with a single keystroke. Runs a lot like a good wordprocessor except no spellcheck... All single keystroke or slightly shifted single character commands. Comes online automatically as soon as you hit "r", and waits to be commanded. Lovely! Quick, easy, uncomplicated, handy...no leaving the reading function to do serious editting. (And, thusly, no one quoting entire articles when they only wanted 2 sentences....except for a few regular unix users who can't seem to break the "quote it all" syndrome... ;-) (Hi Shad...! :-) Suze Hammond, who has NO connection to Quick-anything except as a very satisfied user... trifid@agora.rain.com
cirby@vaxb.acs.unt.edu (06/20/91)
In article <1991Jun18.065605.6955@zorch.SF-Bay.ORG>, xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > 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. > 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. Read the July 1991 issue of _Byte_. There's a good article about the new expanded character sets, including Unicode (which is being pushed by most of the big American computer companies. Two byte codes, giving 64K characters. That's enough for the complete alphabets of *all* of the major languages (including the complete ideographic set for Chinese/Japanese/Korean), and space left for local dialects and/or special agreed-upon cases. It's certainly needed, and as long as the ISO is sitting on its' collective thumbs, Unicode has a shot... -- | C Irby cirby@vaxb.acs.unt.edu cirby@untvax | | Between the politicians, the lawyers, the bureaucrats, the insurance | | salesmen, and the TV commentators- not to mention the fools, lovers, | | and idiots- we may be the only two honest people left in the world. | | And I can see that card you have up your sleeve... |
cmf851@anu.oz.au (Albert Langer) (06/22/91)
In article <1991Jun18.211613.22150@agora.rain.com> trifid@agora.rain.com (Roadster Racewerks) writes: >A really GOOD editor....what I wouldn't give for an online editor similar to >"QuickEd" by the Dirosh brothers (used on my favorite local systems running >QuickBBS software)! >Cursor in all directions, insert and delete single character >if need be, quote only one line at a time, as chosen by you with a single >keystroke. Runs a lot like a good wordprocessor except no spellcheck... All >single keystroke or slightly shifted single character commands. Comes online >automatically as soon as you hit "r", and waits to be commanded. Lovely! Expressed as a "requirement" that would be asking for a message editor that functions like any normal PC editor instead of some emulation of a brain-damaged teletype machine. Seems reasonable. But why "online"? And why no spellcheck? If we just state the requirement, it may turn out the best way to meet it is NOT online but offline, with protocols for delivering articles to the users PC like any other network node (e.g. NNTP and POP3 or else X.400 Message Store or FidoNet "point" software) and similar protocols for submitting articles from the user's PC to the Message Transfer Agent (which may well be just another user's PC). >Quick, easy, uncomplicated, handy...no leaving the reading function to do >serious editting. (And, thusly, no one quoting entire articles when they only >wanted 2 sentences....except for a few regular unix users who can't seem to >break the "quote it all" syndrome... ;-) Not leaving the reading function for editing could still be implemented with an ordinary wordprocessor as long as the integration is seamless and uses a single keystroke. I think the requirement for less quoting is not really connected with the quality of the editor. People would quote less if the reader software had keys for jumping back to the message that is being quoted from and then returning to the reply message. (As is partly implemented on many FidoNet readers, where extensive quoting is indeed less common). Requirement: Ability to jump easily between messages that quote text from other messages and the original message the quote was taken from. (Related to cheaper and ease of use requirements as well as being an enhancement of functionality). -- Opinions disclaimed (Authoritative answer from opinion server) Header reply address wrong. Use cmf851@csc2.anu.edu.au
cmf851@anu.oz.au (Albert Langer) (06/22/91)
In article <1991Jun18.065605.6955@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >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. Kent, thanks for kicking this along. I'm going to go through your points with a fine tooth comb, mainly raising objections, but thanks for providing something to comb. My main point is that we should start from requirements and carefully distinguish those from design decisions (although some requirements may be policies or rules to follow in making design decisions). >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. Depends what we are building. If the implied architecture is based on multi-user systems providing a service to a number of simultaneous dial-up online users then MSDOS may be inappropriate (though a number of BBSes do in fact use it). But with phone lines the dominant cost, and a requirement for cheap connection and use, surely an architecture for developing countries should focus even more than in the developed world on making full use of the users own PCs. I have in mind (for use by community groups in developed countries as well) an architecture where each user has a complete MTA and some users provide relay services for other users. e.g. An organization in some town can simply leave their office computer on all night and local users can automatically deliver mail to it before the network schedule for forwarding to the next relay and can then call back again later to pickup mail from it after the network schedule for picking up mail from the next relay. That is the model FidoNet uses for overnight mail exchange among about 10,000 BBSes and it is extended to individual "point" users that run essentially the same network software but have no dial-up dumb terminal callers. FidoNet BBS sysops put as much time into operations as unix sysadmins but on average have less skills and the extension already occurring to "point" operators suggest the sysop functions can be eliminated. (With a GREAT deal of design effort). Such an architecture would greatly reduce costs (if it is feasible to overcome reliability problems through redundancy etc and to design the needed network management). It should not be eliminated from consideration in favour of multiple dial-up users without careful analysis. It would certainly require software to be running on MSDOS boxes and also (less urgently in developing countries) on Macs. The problems with MSDOS may just HAVE to be overcome to meet other requirements. >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. If we do need a unix-like system then Xenix, Coherent and Minix should also be considered. One model might be to switch operating systems at night for network operations. Very likely unix will be desirable at gateways and for additional functions like real-time chat and database lookup. Also unix may be the PC operating system of the future and certainly unix is the best development platform even if the development is for DOS. So unix should be kept in mind. Possible Design Rule: All software developed should be as generic and POSIX compliant as possible with clear separation of platform specific modules from generic modules. >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. Desirable, but not a requirement if the user logged in is at the console. For developing countries, overnight mail may be quite acceptable with no need to do any sorting out or other network activities during times when the user needs the computer. Also it may be possible to do background network transfers with only very minimal multi-tasking that is oriented towards a fancy comms driver like XPC or Mirror rather than providing a complete multi-tasking operating system. (After all PCs on LANs do their networking in the background while still running what looks to the user like plain ordinary DOS). Certainly pre-emptive multi-tasking does not mandate a shift from the DOS world to unix (though it is easier under unix). Many BBSes use Desqview and Windows 3 might also be a possibility. >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')." Again implies a local "operator" but just less skilled (or less tolerant of brain damaged software) than at present. I'm not sure the REAL requirements can be met without eliminating "operator" functions ENTIRELY - which means sending error messages to network management instead of expecting anybody trying to USE the computer to deal with them (which of course implies having a lot less error messages to deal with). >4) A complete online glossary and help/manual set: >"what's a spool partition" should be an easy >question to answer. Nope. Why should a doctor or librarian who wants to use their word processor to communicate with others want to know what a "spool partition" is? The sort of stuff they should see would be along the lines of: "The disk is filling up too quickly. Select 1, 2 or 3. 1. Reduce the period for which old messages are kept. Or, to postpone the problem without solving it. 2. Select some messages to delete now. 3. Move some messages to archive diskettes." Requirement: Error messages should be reported only to network management. System messages visible to the user should walk the user through the procedure required, including insertion and removal of diskettes etc, and should be expressed in terms of concepts the user is necessarily familiar with. >5) Brilliant error recovery from all the current >problems; dropped user lines, dropped feed lines, >overlarge file transfer, file system corruption, >power loss, etc. DEFINATELY. (But I wouldn't call it "brilliant". Having operators deal with these things is simply ridiculous.) >6) A prioritizing system to transfer files in aged >"smallest files first" fashion to encourage brevity. That is a policy statement for brevity which may have less impact than providing for reader selection and prioritizing of articles to read with length as a criteria. That could be added as a requirement though it seems low priority to me. The X400 prioritizing of urgent normal and non-urgent items seems adequate for all transfer purposes. It would allow normal mail to go through while "files" are delayed by lack of disk space at intermediate relays and would allow system messages and other priority traffic to get through while capacity is strained beyond normal limits. This eliminates a substantial part of the need for sysadmins. >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. I can see the point that unskilled labor may be cheaply available for taking diskettes in and out even though operator labor is unavailable, but I doubt that there is much scope for making use of this and certainly can't see it helping with a queue of files waiting for transmission. (The files should just stay on the machine they were produced on or that they have been relayed to until there is room to send them further. With priority queues etc that just results in users being told they can't send the file, not in anything clogging up. Users told they can't send a file can copy it off their hard disks if they really want to, but they are more likely to get bigger disks if it happens regularly, and network capacity has to be increased if it is a problem significant enough to be worth designing a manual backing system store for.) Possible uses for cheap labor might be archiving old messages to diskette (though I suspect tape will soon work out cheaper because of the media costs anyway and tape is not labor intensive). Another one is carrying news and files by diskette or tape instead of phone. >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. Yep. Implies a strong preference for commodity PC hardware used locally for ordinary wordprocessing etc. Another reason to try adding ONLY the modem to what users already have. >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. Yep. But only sites with a critical need for continuous access to the network need duplicate their own equipment (and they would be likely to have multiple PCs anyway). The network itself should simply be designed to assume that a certain percentage, perhaps even quite a HIGH percentage of nodes will be down at any given time and re-route the traffic automatically to provide the lowest cost with the nodes that ARE available (AND to ensure nodes that are down will get their traffic when they come back up, which may be harder). Basically this just means extra disk space apart from the software design. No other extra hardware at all. (Well, maybe ensure there is more than 1 or 2 sites with high speed modems at each end of an expensive and important international link - though even there it is just a trade off with the increased traffic costs from using other nodes with lower speed modems). Our requirements are not the same as corporate networks. >10) A _very_ simple editor, character and line >oriented, that automatically avoids transmitting >overlong lines, etc. See my reply to Sue. >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. Careful. Some things just have to be optional, but providing the network management will require a lot of standardization - at least to the extent that any option must include the remote logging and remote configuration needed to manage it without a local operator. >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. X400 has given thorough consideration to character set and language issues and has for very good reasons standardized on ISO 6937 (T61) for normal text in latin alphabet languages and ISO 2022 escapes to multi- byte character sets for languages like Chinese etc. It also provides for language labels. This is the best solution for permitting use of multiple languages and character sets in the same discussions among users with different equipment each suited to their own language. (Details of why would be a diversion best left to a detailed design stage. Let's not get diverted into re-inventing sheels that international standards organizations have already invented.) Internal character sets on the user's own equipment are a separate issue for which Unicode etc may be relevant. The basic requirement is that network character sets should allow the full expression of each user's own language with maximum possible interchange with users that have equipment designed for other languages. This permits multi-lingual conferences and the emergence of new pidgin and creole languages through networking between people that do not understand each other's language fluently. >13) Probably tons more; someone else take a turn. Thanks for the opportunity. There is indeed tons more to come, but let's try to keep it primarily at a "requirements" level before taking design decisions. -- Opinions disclaimed (Authoritative answer from opinion server) Header reply address wrong. Use cmf851@csc2.anu.edu.au
peter@ficc.ferranti.com (Peter da Silva) (06/25/91)
In article <1991Jun21.231902.24754@newshost.anu.edu.au> cmf851@anu.oz.au (Albert Langer) writes: > >1) Not MS-DOS. > >building on an MS-DOS base is a recipie for > >failure or immediate obsolescence. > But with phone lines the dominant cost, and a requirement for > cheap connection and use, surely an architecture for developing > countries should focus even more than in the developed world > on making full use of the users own PCs. That doesn't imply MS-DOS, except as a way to boot a better system. Look at it this way, DOS users are used to running one program at a time. The Nusenet operating system can just be seen as such a program. What should it be? POSIX compatible, for sure! Why not MINIX? Even better would be a new baby UNIX clone. The mechanisms UNIX V7 uses to handle multitasking, drivers and the like are unsexy, but they're well known. And they're pretty efficient on small systems: V7 on the PC was faster for some stuff than MS-DOS... MINIX, with its elegant structure, is slower. But I have to back Kent's comments on MS-DOS. Depending on it as a platform will just give use another Fidonet. If you're going to do that, why the hell not just start with Fido? It works, it's installed worldwide, and it's certainly cheap! > X400 [...] Let's not get diverted into > re-inventing sheels that international standards > organizations have already invented.) But X400 is an overly complex system. What's wrong with 16-bit clean RFC822? -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
jhess@orion.oac.uci.edu (James Hess) (06/25/91)
In article <1991Jun21.220326.24387@newshost.anu.edu.au> cmf851@anu.oz.au (Albert Langer) writes: >But why "online"? > >If we just state the requirement, it may turn out the best way to meet >it is NOT online but offline, with protocols for delivering articles >to the users PC like any other network node.... I second the offline suggestion. Remember that we are dealing with limited economies. I am working with Dr. Duane Metzger, who is working with the BESTR network out of SDSU. The intent is to link up Spanish and English speakers on both sides of the U.S.-Mexican border. A problem for many is the cost of the telephone line. We hope to combine available software to enable people to log on, automatically download any new messages in the conferences they follow, then log off and hang up. The messages could then be edited, replies written, followed by a log on and automated up-load. Wish us luck! -Jim Hess-
cmf851@anu.oz.au (Albert Langer) (06/26/91)
In article <28669966.27747@orion.oac.uci.edu> jhess@orion.oac.uci.edu (James Hess) writes: >of the U.S.-Mexican border. A problem for many is the cost of the telephone >line. We hope to combine available software to enable people to log on, >automatically download any new messages in the conferences they follow, then >log off and hang up. The messages could then be edited, replies written, >followed by a log on and automated up-load. > >Wish us luck! "Good luck!" BTW, don't even think about writing your own software until you have checked out FidoNet "point" software (many different packages) and "Waffle" (similar concept for Usenet). They integrate the whole process so you don't think in terms of logging in and automatically uploading and downloading. You think in terms of either just leaving your computer on all night so something mysterious happens or occasionally telling it to "do it's stuff". Then you are just writing and reading messages on your own computer. No visible "logging in" or "uploading" or "downloading". -- Opinions disclaimed (Authoritative answer from opinion server) Header reply address wrong. Use cmf851@csc2.anu.edu.au
cmf851@anu.oz.au (Albert Langer) (06/26/91)
In article <U05CKB2@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >That doesn't imply MS-DOS, except as a way to boot a better system. Look >at it this way, DOS users are used to running one program at a time. The >Nusenet operating system can just be seen as such a program. What should it >be? POSIX compatible, for sure! Why not MINIX? > >Even better would be a new baby UNIX clone. The mechanisms UNIX V7 uses to >handle multitasking, drivers and the like are unsexy, but they're well known. >And they're pretty efficient on small systems: V7 on the PC was faster for >some stuff than MS-DOS... MINIX, with its elegant structure, is slower. I'd go along with that since one can make the process of booting from one to the other OS look just like running any other program, and the mtools package is available to access MSDOS files from a unix like system. The only disadvantage I can see is that MSDOS users do in fact do multitasking with Windows etc and it would be nice to be able to cut and paste to other programs. Also it would be nice to let the users run their normal DOS wordprocesser for message editing (though perhaps even that could be kludged by a brilliant hack which switches OSes like saving RAM during a power failure and then resuming). Anyway, those things could be provided later, along with access for Macs and just kept in mind by making the code even more modular than one might otherwise, so that later DOS/Windows and Mac ports could share a lot of modules. As long as the basic functionality can be implemented quicker on a unix lookalike I would say go for it. But can it? My understanding is that Coherent and Minix aren't going to come down in price dramatically in the near future and adding USD $100 to $150 to the cost of what users already have just isn't on. If there was a freely available unix lookalike project with a firm schedule to have something available in time for the "email engine" project I'd be in favour of developing now on Coherent or Minix with the intention of switching later. Or perhaps there could be some special deal with Minix for a "binary only" licence to use on the "email engine" only rather than as a full OS. (I'm not familiar with Minix - care to check out that possibility?) I get the impression from the traffic in Coherent and Minix groups that developing such a project would be quite non-trivial and I'm not aware of anything that looks promising on the horizon. So I come back towards DOS as the initial platform but with modularization etc planned towards future migration to a POSIX environment. Would be DELIGHTED to change my mind if anybody can point to something freely available now or soon with certainty. BTW, another worry is just how difficult it would be to port available unix code to the unix lookalike - seems to be quite a lot of work going on with Minix and Coherent whereas I would prefer it to be dead easy. Are 64K segments a major limitation? Anyway, this isn't critical since no matter how awkward it is it can't be as bad as DOS! >But I have to back Kent's comments on MS-DOS. Depending on it as a platform >will just give use another Fidonet. If you're going to do that, why the >hell not just start with Fido? It works, it's installed worldwide, and it's >certainly cheap! I think FidoNet software is an excellent solution for getting something functioning immediately. But I'm not convinced it will scale up to really large numbers of users with really small numbers of sysops. I'd go for BinkleyTerm as a "Reliable Transfer Server" entirely replacing UUCP or all the lower layers of OSI - especially as it is available in source code and is ported to various non-MSDOS environments and is nicely tuned for efficiency and world-wide use etc. That is a MAJOR contribution from FidoNet. I would be inclined to port it even if we did have a POSIX environment. But the actual message editors and readers (and news transport and mail routing software and expiry and utilities etc) strike me as rather kludgy. Apart from wanting to add features like longer messages and cross-posting and multiple destinations etc my main concern is that you simply get stuck at some point as to the amount of work a "sysop" has to do to keep things working. Most of the better stuff isn't available with source code either. >But X400 is an overly complex system. What's wrong with 16-bit clean RFC822? Similar problem. RFC822 is designed for an environment in which there are unix sysadmins available to fix problems. As well as providing some nice extra features (which is relatively unimportant), the beauty of X.400 is that it specifies EVERYTHING. That of course makes it look "overly complex" (plus the specifications can be unnecessarily pedantic and formal even when necessary). While the pedantry is just a nuisance, the complexity is NECESSARY in order to not have sysadmins who solve routing problems, clean out disk space etc etc. If we start step by step from FidoNet or RFC822 to achieve the level of automatic operation I believe is necessary then we would be re-ionventing X.400 anyway. It IS complex to provide RELIABLE mail and news, with guaranteed delivery or non-delivery notices, no black holes, no disk space filling up etc etc. Another aspect is that this is a big project which isn't going to happen overnight and will require cooperation from a number of egotistical software developers. It would be a nightmare trying to sort out conflicts about what the specs should be, and how to reconcile differences between independently developed modules and ports - just look at arguments that go on within Usenet and FidoNet. Using X.400 specs takes advantage of an immense amount of work that has been done to produce specs that are unambiguous. (While still leaving plenty of work to do both specifying what to implement at each stage, and porting existing code or writing new code). There is a steep learning curve, but it is worth it, and learning X400 stuff will not be a waste of time for anybody's resume. Perhaps this issue can be clarified in the course of examining further requirements specs. e.g. Do we want GUARANTEED delivery or non-delivery notification and if so, how can that be achieved? What are the jobs a sysadmin spends time on as regards mail and news, and how can they be eliminated? -- Opinions disclaimed (Authoritative answer from opinion server) Header reply address wrong. Use cmf851@csc2.anu.edu.au
jet@karazm.math.uh.edu (J Eric Townsend) (06/26/91)
In article <28669966.27747@orion.oac.uci.edu> jhess@orion.oac.uci.edu (James Hess) writes: >of the U.S.-Mexican border. A problem for many is the cost of the telephone >line. We hope to combine available software to enable people to log on, >automatically download any new messages in the conferences they follow, then >log off and hang up. The messages could then be edited, replies written, >followed by a log on and automated up-load. Do what I used to do: Get an AT&T 3b1. It's a 68010 based machine. Not fast, but it's UNIX and will run B news. It'll hold up to 3.5Mb of ram and talk on 3 serial ports. It can be easily hacked to use a large drive (check with the .3b1 newsgroups). You should be able to get a basic unit for $1000 or so. It may be slow, but it's solid, and it's UNIX. -- J. Eric Townsend - jet@uh.edu - bitnet: jet@UHOU - vox: (713) 749-2126 Skate UNIX! (curb fault: skater dumped) PowerGlove mailing list: glove-list-request@karazm.math.uh.edu