Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!murtoa.cs.mu.oz.au!gwydir!gara!wtoomey
From: wtoomey@gara.une.oz (Warren Toomey)
Newsgroups: comp.os.minix
Subject: Minix's Direction (was Re: Brucee's opus)
Message-ID: <798@gara.une.oz>
Date: 6 Jun 89 10:53:17 GMT
References: <16497@louie.udel.EDU> <11989@bcsaic.UUCP> <2775@munnari.oz>
Organization: University of New England, Armidale, Australia
Lines: 88

In article <2775@munnari.oz>, muller@munnari.oz (Paul Muller) writes:

	[ about the future design of Minix, and it's direction ]

Minix definitely is split between two camps of users:

	a) Those using it to learn about O/S design
	b) Those wanting a cheap, good, O/S with source code.

For the former group, the source needs to be simple, concise, and well
documented. For the latter, anything that's considered `useful'.

I believe that Minix 1.2 & Minix 1.3 very adequately satisfy the demands
of the academic users. For them, any increase in the size & complexity of
Minix would do more harm than good. The IBM-XT here also helps as it is
simple, and cheap for academic departments to buy.

However, for the latter group, much more can be done with Minix to get it
as (current) Unix-compatible as possible. This really means leaving the
IBM-XT behind, and moving on to more powerful machines, with larger available
memories etc. The port of Minix to the '286, and the Atari ST port are the
first steps in this direction.

Therefore, I propose that Minix be broken into two parts. One, a simple
static version of Minix, such as 1.3, to be used to teach about
operating systems, and based on the XT or ST. The other, a continually
evolving system, to keep everybody else happy. This should be ported to
many machines, like the ST, '286 & '386 etc, and hopefully should mean
that all the machine dependencies will reside in only a few files in the
kernel/mm/fs/etc.

> Minix first and foremost is the poor student's teaching OS. It serves its
> purpose above and beyond the call of duty, and that is the point.
	This is the `academic' Minix.

> POSIX compliance is probably important from the point of view of teaching 
> ideas in a real world sense (we can't always patch the C compiler!).
	POSIX compatibility should apply to both versions.

>     The second is the 'upmarket' Minix that everyone seems to think is so
> important, why? Most people who got into Minix for reasons other than formal
> education just wanted to 'hack around'.
> If people are so into the idea of 'real life' Unix, then checkout AT&T, SCO,
> etc offerings. They produce different BINARIES for each processor  ...

	Not only did I buy Minix to play with, but also to have a version
of Unix with almost full source code, and to be a part of comp.os.minix,
where each of us can add to Minix's source code pool, and also help
with design ideas, bug reports etc. This is difficult (nay, impossible)
with real Unix.
	 At the present point in time, Minix only vaguely resembles current
flavours of Unix, and I would really like to see it become as compatible
with both the ATT and Berkely flavours of Unix. This has already started
with sources such as termcap(3), and the memcpy,bcopy variants. Both
flavours of Unix overlap in many areas, and also have extensions which exists
in only one flavour. If Minix could be a fusion of both flavours, and
keep compatibility with them AND POSIX ( & SVID ?), then we would have
an O/S which would be the best of both worlds AND with source.
	

>     I like what Bruce and others are doing for Minix, but the seminal idea
> of ast's based itself on V7, "because of its simplicity and elegance" and this
> is foremost in my mind when I hear talk about changing the listing that will
> appear in the back of the second revision of The Book.

	I agree. The O/S book and `academic' Minix should be kept exactly as
is to make teaching O/S as easy as possible.
However, a more powerful version of Minix should be allowed to develop too.

> What is
> needed is some form of arbitration committee to decide what goes in the
> upmarket version. This should not just rest on ast's shoulders, I prefer
> he gets more time to write his great books! :-)

	Yes! Andy, 'though, being the founder of Minix, should have the
final say on the future of Minix. But a committee of some sorts would
take a lot of the load from him.

BTW, speaking of Minix design, what about job control and the extra
Berkely signals for Minix. This will allow shells etc, to have better
control over child processes, and won't be incompatible with the
Version 7 & SysV signals - well, perhaps a few! Any ideas, comments?

Warren Toomey
University of New England
Australia.

(wtoomey@gara.une.oz)