Path: utzoo!attcan!uunet!mcvax!hp4nl!botter!star.cs.vu.nl!...@cs.vu.nl
From: a...@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Bruce Evans' opus
Message-ID: <2570@ast.cs.vu.nl>
Date: 22 May 89 06:36:00 GMT
Sender: a...@cs.vu.nl
Reply-To: a...@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 24
Bruce Evans has clearly done a great deal of high quality work in his recent
giant posting and I am sure many people are interested in it. Furthermore,
I hate to be a party pooper, but...
According to P-H's sales figures, the PC version of MINIX is still outselling
the AT version by a wide margin. This means that there are a lot of 8088s
still out there. Consequently, I am going to base V2.x on 1.4a, not on Bruce's
version. I just don't want all that extra complexity on the 8088 (remember,
the goal was a teaching system).
This means that if you convert to Bruce's system now, you may have trouble
converting to 2.x (POSIX-based) later. It is clearly up to you which way you
go, but at least you should be aware that there is a fork in the road here.
The long term plan for MINIX is to wait until not only the 8088, but the 286
has also vanished, and make MINIX 3.x (probably in 4 or 5 years) entirely
a 386/486/585/686/786 based system, assuming these are all architecturally
compatible. The 286's dwarf segments are a real nuisance, and hardly
compatible with the Atari, Amiga, and other versions of MINIX in progress,
whereas on the 386 one can use a single 32-bit segment (Motorola mode) and
implement that fairly cleanly.
Andy Tanenbaum (a...@cs.vu.nl)
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!
cs.utexas.edu!uunet!munnari!muller
From: mul...@munnari.oz (Paul Muller)
Newsgroups: comp.os.minix
Subject: Re: Bruce Evans' opus
Summary: Free-for-all comment on future Minix?
and "Who is this God (AST) person anyway?"
.
Message-ID: <2775@munnari.oz>
Date: 4 Jun 89 11:58:07 GMT
References: <16497@louie.udel.EDU> <11989@bcsaic.UUCP>
Lines: 64
Firstly I apoligise to anyone offended by the summary line....
I think it is rather inconsiderate to talk about Minix as if it was
collectively owned by the netlanders (although much of it would not exist
without them and they all deserve credit), Andrew and PH will differ on
that point no-doubt about it, though as ast so wonderfully put it, there
would appear to be a "fork" in the road after the work of Bruce hit the net.
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. If you
were a student you wouldn't fancy wading through all those #ifdefs for two
days just to find you made a mistake early on in the code and that's why
none of what the lecturer is saying fits together. I am a student and find
nothing more annoying than conditional compilation, it ruins your day and
often clouds the purpose of the code.
I am not going to propose anything radical in regards as to what should be
done, I will just try and put together some ideas that have floated across
the battle table (and try to foresee new ones).
The first idea is to KISS. Sounds nice huh? ;-) Seriously, the first
thing is to get a standard piece of PC code that will form the kernal (in
the larger sense) of the Minix book. Much as it is now. Students can still
boot up on the two floppy PCs they have at home and happily hand in work
for the teacher with the knowledge that comes from looking at the guts of
an OS. 1.4a contains more or less than what is needed to do this. POSIX
compliance is probably important from the point of view of teaching the
ideas in a real world sense (we can't always patch the C compiler!).
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', you were happy with Minix then, why
not now, the old case of "give an inch take a mile" or more "too much of a]
good thing" :-) The idea then is to produce a bunch of either, patches or
modules (FS,MM,xx_wini,etc) that cater for individual tastes and needs.
People can then make up a Minix system to suit them, you could have a file
in /etc that would list all options loaded or have an internal table hard
coded into Minix that would tell applications if they could use certain
features or not at compile (or patch) time.
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 they
support, most proabably different sources as well. Xenix (tm) 286 won't
run 386 code, so why all the hoopla about Minix compatibility? 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! :-)
The whole idea is asking for trouble, but there are sooooo many things that
poeple in the Minix user community want/need/loath/despise in minix that can be
done on paper but fall done trying to fit in with the 'small is beutiful' model
, Virtual memory, windowing, memory model work, swapping and networking just
to name a few.
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.
What do others feel? The ST was a step in another direction, what do users
of ST AND PC (that is people who have used (are using) both) think about
the differences in the code/machine?
paul
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!
uunet!murtoa.cs.mu.oz.au!gwydir!gara!wtoomey
From: wtoo...@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 <2...@munnari.oz>, mul...@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.
(wtoo...@gara.une.oz)