🚀 go-pugleaf

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