Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!munnari.oz.au!manuel!cmf851 From: cmf851@anu.oz.au (Albert Langer) Newsgroups: comp.society.development Subject: Re: Low-cost Usenet (Re: usenet in Nepal) Message-ID: <1991Jun25.202921.1877@newshost.anu.edu.au> Date: 25 Jun 91 20:29:21 GMT Article-I.D.: newshost.1991Jun25.202921.1877 References: <1991Jun18.065605.6955@zorch.SF-Bay.ORG> <1991Jun21.231902.24754@newshost.anu.edu.au> Sender: news@newshost.anu.edu.au Organization: Computer Services Centre, Australian National University, Canberra, Australia. Lines: 120 In article 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