I was in the U.S. for a couple of weeks, so I haven't commented much on
LINUX (not that I would have said much had I been around), but for what
it is worth, I have a couple of comments now.

As most of you know, for me MINIX is a hobby, something that I do in the
evening when I get bored writing books and there are no major wars,
revolutions, or senate hearings being televised live on CNN.  My real
job is a professor and researcher in the area of operating systems.

As a result of my occupation, I think I know a bit about where operating
are going in the next decade or so.  Two aspects stand out:

1. MICROKERNEL VS MONOLITHIC SYSTEM
   Most older operating systems are monolithic, that is, the whole operating
   system is a single a.out file that runs in 'kernel mode.'  This binary
   contains the process management, memory management, file system and the
   rest. Examples of such systems are UNIX, MS-DOS, VMS, MVS, OS/360,
   MULTICS, and many more.

   The alternative is a microkernel-based system, in which most of the OS
   runs as separate processes, mostly outside the kernel.  They communicate
   by message passing.  The kernel's job is to handle the message passing,
   interrupt handling, low-level process management, and possibly the I/O.
   Examples of this design are the RC4000, Amoeba, Chorus, Mach, and the
   not-yet-released Windows/NT.

   While I could go into a long story here about the relative merits of the
   two designs, suffice it to say that among the people who actually design
   operating systems, the debate is essentially over.  Microkernels have won.
   The only real argument for monolithic systems was performance, and there
   is now enough evidence showing that microkernel systems can be just as
   fast as monolithic systems (e.g., Rick Rashid has published papers comparing
   Mach 3.0 to monolithic systems) that it is now all over but the shoutin`.

   MINIX is a microkernel-based system.  The file system and memory management
   are separate processes, running outside the kernel.  The I/O drivers are
   also separate processes (in the kernel, but only because the brain-dead
   nature of the Intel CPUs makes that difficult to do otherwise).  LINUX is
   a monolithic style system.  This is a giant step back into the 1970s.
   That is like taking an existing, working C program and rewriting it in
   BASIC.  To me, writing a monolithic system in 1991 is a truly poor idea.

2. PORTABILITY
   Once upon a time there was the 4004 CPU.  When it grew up it became an
   8008.  Then it underwent plastic surgery and became the 8080.  It begat
   the 8086, which begat the 8088, which begat the 80286, which begat the
   80386, which begat the 80486, and so on unto the N-th generation.  In
   the meantime, RISC chips happened, and some of them are running at over
   100 MIPS.  Speeds of 200 MIPS and more are likely in the coming years.
   These things are not going to suddenly vanish.  What is going to happen
   is that they will gradually take over from the 80x86 line.  They will
   run old MS-DOS programs by interpreting the 80386 in software.  (I even
   wrote my own IBM PC simulator in C, which you can get by FTP from
   ftp.cs.vu.nl =  192.31.231.42 in dir minix/simulator.)  I think it is a
   gross error to design an OS for any specific architecture, since that is
   not going to be around all that long.

   MINIX was designed to be reasonably portable, and has been ported from the
   Intel line to the 680x0 (Atari, Amiga, Macintosh), SPARC, and NS32016.
   LINUX is tied fairly closely to the 80x86.  Not the way to go.

Don`t get me wrong, I am not unhappy with LINUX.  It will get all the people
who want to turn MINIX in BSD UNIX off my back.  But in all honesty, I would
suggest that people who want a **MODERN** "free" OS look around for a
microkernel-based, portable OS, like maybe GNU or something like that.

Andy Tanenbaum (a...@cs.vu.nl)

P.S. Just as a random aside, Amoeba has a UNIX emulator (running in user
space), but it is far from complete.  If there are any people who would
like to work on that, please let me know.  To run Amoeba you need a few 386s,
one of which needs 16M, and all of which need the WD Ethernet card.

I would like to at least look at LINUX, but I cannot, since I run
a 68000-based machine. In any case, it is nice having the kernel
independent, since patches like the multi-threaded FS patch don't
have to exist in a different version for each CPU.

I second everything AST said, except that I would like to see
the kernel _more_ independent from everything else. Why does the
Intel architecture _not_ allow drivers to be independent programs?

I also don't like the fact that the kernel, mm and fs share the
same configuration files. Since they _are_ independent, they should
have more of a sense of independence.

David

#################################################################
David Megginson                  meg...@epas.utoronto.ca
Centre for Medieval Studies      da...@doe.utoronto.ca
University of Toronto            39 Queen's Park Cr. E.
#################################################################

The drivers have to read and write the device registers in I/O space, and
this cannot be done in user mode on the 286 and 386. If it were possible
to do I/O in a protected way in user space, all the I/O tasks could have
been user programs, like FS and MM.

Andy Tanenbaum (a...@cs.vu.nl)

Of course, there are some things that are best left to the kernel, be it
micro or monolithic.  Like things that require playing with the process'
stack, e.g. signal handling.  Like memory allocation.  Things like that.

The microkernel design is probably a win, all in all, over a monolithic
design, but it depends on what you put in the kernel and what you leave
out.

Minix is a microkernel design, of sorts.  The problem is that it gives special
priveleges to mm and fs, when there shouldn't be any (at least for fs).  It
also fails to integrate most of the functionality of mm in the kernel itself,
and this makes things like signal handling and memory allocation *really*
ugly.  If you did these things in the kernel itself, then signal handling
would be as simple as setting a virtual interrupt vector and causing the
signalled process to receive that interrupt (with the complication that
system calls might have to be terminated.  Which means that a message would
have to be sent to every process that is servicing the process' system call,
if any.  It's considerations like these that make the monolithic kernel
design appealing).

The *entire* system call interface in Minix needs to be rethought.  As it
stands right now, the file system is not just a file system, it's also a
system-call server.  That functionality needs to be separated out in order
to facilitate a multiple file system architecture.  Message passing is
probably the right way to go about making the call and waiting for it, but
the message should go to a system call server, not the file system itself.

In order to handle all the special caveats of the Unix API, you end up writing
a monolithic "kernel" even if you're using a microkernel base.  You end up
with something called a "server", and an example is the BSD server that runs
under Mach.

And, in any case, the message-passing in Minix needs to be completely redone.
As it is, it's a kludge.  I've been giving this some thought, but I haven't
had time to do anything with what I've thought of so far.  Suffice it to say
that the proper way to do message-passing is probably with message ports
(both public and private), with the various visible parts of the operating
system having public message ports.  Chances are, that ends up being the
system call server only, though this will, of course, depend on the goals
of the design.

Depends on the design criteria, as you should know.  If your goal is to
design a Unix workalike that is relatively simple and relatively small,
then a monolithic design is probably the right approach for the job, because
unless you're designing for really backwards hardware, the problems of
things like interrupted system calls, memory allocation within the kernel
(so you don't have to statically allocate *everything* in your OS), signal
handling, etc. all go away (or are at least minimized) if you use a
monolithic design.  If you want the ability to bring up and take down
file systems, add and remove device drivers, etc., all at runtime, then
a microkernel approach is the right solution.

Frankly, I happen to like the idea of removable device drivers and such,
so I tend to favor the microkernel approach as a general rule.

Again, look at the design criteria.  If portability isn't an issue, then
why worry about it?  While LINUX suffers from lack of portability, portability
was obviously never much of a consideration for its author, who explicitly
stated that it was written as an exercise in learning about the 386
architecture.

And, in any case, while MINIX is portable in the sense that most of the code
can be ported to other platforms, it *still* suffers from the limitations of
the original target machine that drove the walk down the design decision tree.
The message passing is a kludge because the 8088 is slow.  The kernel doesn't
do memory allocation (thus not allowing FS and the drivers to get away with
using a malloc library or some such, and thus causing everyone to have to
statically allocate everything), probably due to some other limitation of
the 8088.  The very idea of using "clicks" is obviously the result of the
segmented architecture of the 8088.  The file system size is too limited
(theoretically fixed in 1.6, but now you have *two* file system formats to
contend with.  If having the file system as a separate process is such a
big win, then why don't we have two file system servers, eh?  Why simply
extend the existing Minix file system instead of implementing BSD's FFS
or some other high-performance file system?  It's not that I'm greedy
or anything... :-).

All in all, I tend to agree.

Yeah, right.  Point me someplace where I can get a free "modern" OS and I'll
gladly investigate.  But the GNU OS is currently vaporware, and as far as I'm
concerned it will be for a LOOOOONG time to come.

Any other players?  BSD 4.4 is a monolithic architecture, so by your
definition it's out.  Mach is free, but the BSD server isn't (AT&T code,
you know), and in any case, isn't the BSD server something you'd consider
to be a monolithic design???

Really.  Why do you think LINUX is as popular as it is?  The answer is
simple, of course: because it's the *only* free Unix workalike OS in
existence.  BSD doesn't qualify (yet).  Minix doesn't qualify.  XINU
isn't even in the running.  GNU's OS is vaporware, and probably will
be for a long time, so *by definition* it's not in the running.  Any
other players?  I haven't heard of any...

Minix is an excellent piece of work.  A good starting point for anyone who
wants to learn about operating systems.  But it needs rewriting to make it
truly elegant and functional.  As it is, there are too many kludges and
hacks (e.g., the message passing).

                                Kevin Brown

Well, with a subject like this, I'm afraid I'll have to reply.
Apologies to minix-users who have heard enough about linux anyway.  I'd
like to be able to just "ignore the bait", but ...  Time for some
serious flamefesting!

You use this as an excuse for the limitations of minix? Sorry, but you
loose: I've got more excuses than you have, and linux still beats the
pants of minix in almost all areas.  Not to mention the fact that most
of the good code for PC minix seems to have been written by Bruce Evans.

Re 1: you doing minix as a hobby - look at who makes money off minix,
and who gives linux out for free.  Then talk about hobbies.  Make minix
freely available, and one of my biggest gripes with it will disappear.
Linux has very much been a hobby (but a serious one: the best type) for
me: I get no money for it, and it's not even part of any of my studies
in the university.  I've done it all on my own time, and on my own
machine.

Re 2: your job is being a professor and researcher: That's one hell of a
good excuse for some of the brain-damages of minix. I can only hope (and
assume) that Amoeba doesn't suck like minix does.

True, linux is monolithic, and I agree that microkernels are nicer. With
a less argumentative subject, I'd probably have agreed with most of what
you said. From a theoretical (and aesthetical) standpoint linux looses.
If the GNU kernel had been ready last spring, I'd not have bothered to
even start my project: the fact is that it wasn't and still isn't. Linux
wins heavily on points of being available now.

If this was the only criterion for the "goodness" of a kernel, you'd be
right.  What you don't mention is that minix doesn't do the micro-kernel
thing very well, and has problems with real multitasking (in the
kernel).  If I had made an OS that had problems with a multithreading
filesystem, I wouldn't be so fast to condemn others: in fact, I'd do my
damndest to make others forget about the fiasco.

[ yes, I know there are multithreading hacks for minix, but they are
hacks, and bruce evans tells me there are lots of race conditions ]

"Portability is for people who cannot write new programs"
                -me, right now (with tongue in cheek)

The fact is that linux is more portable than minix.  What? I hear you
say.  It's true - but not in the sense that ast means: I made linux as
conformant to standards as I knew how (without having any POSIX standard
in front of me).  Porting things to linux is generally /much/ easier
than porting them to minix.

I agree that portability is a good thing: but only where it actually has
some meaning.  There is no idea in trying to make an operating system
overly portable: adhering to a portable API is good enough.  The very
/idea/ of an operating system is to use the hardware features, and hide
them behind a layer of high-level calls.  That is exactly what linux
does: it just uses a bigger subset of the 386 features than other
kernels seem to do.  Of course this makes the kernel proper unportable,
but it also makes for a /much/ simpler design.  An acceptable trade-off,
and one that made linux possible in the first place.

I also agree that linux takes the non-portability to an extreme: I got
my 386 last January, and linux was partly a project to teach me about
it.  Many things should have been done more portably if it would have
been a real project.  I'm not making overly many excuses about it
though: it was a design decision, and last april when I started the
thing, I didn't think anybody would actually want to use it.  I'm happy
to report I was wrong, and as my source is freely available, anybody is
free to try to port it, even though it won't be easy.

                Linus

PS. I apologise for sometimes sounding too harsh: minix is nice enough
if you have nothing else. Amoeba might be nice if you have 5-10 spare
386's lying around, but I certainly don't. I don't usually get into
flames, but I'm touchy when it comes to linux :)

In <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum) writes:

There are really no other alternatives other than Linux for people like
me who want a "free" OS.  Considering that the majority of people who
would use a "free" OS use the 386, portability is really not all that
big of a concern.  If I had a Sparc I would use Solaris.  

As it stands, I installed Linux with gcc, emacs 18.57, kermit and all of the
GNU utilities without any trouble at all.  No need to apply patches. I
just followed the installation instructions.  I can't get an OS like
this *anywhere* for the price to do my Computer Science homework. And
it seems like network support and then X-Windows will be ported to Linux
well before Minix.  This is something that would be really useful. In my
opinion, portability of standard Unix software is important also.

I know that the design using a monolithic system is not as good as the
microkernel.  But for the short term future (And I know I won't/can't
be uprading from my 386), Linux suits me perfectly.

Philip Wu
p...@unixg.ubc.ca

in article <12...@star.cs.vu.nl>, a...@cs.vu.nl (Andy Tanenbaum) says:

The standard way of doing that is to trap on i/o space protection
violations, and emulate the i/o for the user.
--
BURNS,JIM (returned student)
Georgia Institute of Technology, 30178 Georgia Tech Station,
Atlanta Georgia, 30332            | Internet: gt01...@prism.gatech.edu
uucp:     ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a

In article <1992Jan29.231426.20...@klaava.Helsinki.FI> torva...@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
The limitations of MINIX relate at least partly to my being a professor:
An explicit design goal was to make it run on cheap hardware so students
could afford it.  In particular, for years it ran on a regular 4.77 MHZ PC
with no hard disk.  You could do everything here including modify and recompile
the system.  Just for the record, as of about 1 year ago, there were two
versions, one for the PC (360K diskettes) and one for the 286/386 (1.2M).
The PC version was outselling the 286/386 version by 2 to 1.  I don't have
figures, but my guess is that the fraction of the 60 million existing PCs that
are 386/486 machines as opposed to 8088/286/680x0 etc is small.  Among students
it is even smaller. Making software free, but only for folks with enough money
to buy first class hardware is an interesting concept.
Of course 5 years from now that will be different, but 5 years from now
everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5.

Amoeba was not designed to run on an 8088 with no hard disk.

A multithreaded file system is only a performance hack.  When there is only
one job active, the normal case on a small PC, it buys you nothing and adds
complexity to the code.  On machines fast enough to support multiple users,
you probably have enough buffer cache to insure a hit cache hit rate, in
which case multithreading also buys you nothing.  It is only a win when there
are multiple processes actually doing real disk I/O.  Whether it is worth
making the system more complicated for this case is at least debatable.

I still maintain the point that designing a monolithic kernel in 1991 is
a fundamental error.  Be thankful you are not my student.  You would not
get a high grade for such a design :-)

MINIX was designed before POSIX, and is now being (slowly) POSIXized as
everyone who follows this newsgroup knows.  Everyone agrees that user-level
standards are a good idea.  As an aside, I congratulate you for being able
to write a POSIX-conformant system without having the POSIX standard in front
of you. I find it difficult enough after studying the standard at great length.

My point is that writing a new operating system that is closely tied to any
particular piece of hardware, especially a weird one like the Intel line,
is basically wrong.  An OS itself should be easily portable to new hardware
platforms.  When OS/360 was written in assembler for the IBM 360
25 years ago, they probably could be excused.  When MS-DOS was written
specifically for the 8088 ten years ago, this was less than brilliant, as
IBM and Microsoft now only too painfully realize. Writing a new OS only for the
386 in 1991 gets you your second 'F' for this term.  But if you do real well
on the final exam, you can still pass the course.

Prof. Andrew S. Tanenbaum (a...@cs.vu.nl)

That's ok. Einstein got lousy grades in math and physics.
--
David Feustel N9MYI, 1930 Curdes Ave, Fort Wayne, IN 46805. (219)482-9631
feus...@netcom.com
=== NBC News: GE's Advertising And Public Relations Agency ===

And Dan Quayle got low grades in political science. I think that there
are more Dan Quayles than Einsteins out there... ;-)

David

#################################################################
David Megginson                  meg...@epas.utoronto.ca
Centre for Medieval Studies      da...@doe.utoronto.ca
University of Toronto            39 Queen's Park Cr. E.
#################################################################

Well, I for one would _love_ to see this happen.

First off, the parts of Linux tuned most finely to the 80x86 are the Kernel
and the devices. My own sense is that even if Linux is simply a stopgap
measure to let us all run GNU software, it is still worthwhile to have a
a finely tuned kernel for the most numerous architecture presently in
existance.

Well, the only part of Linux that isn't portable is the kernel and drivers.
Compare to the compilers, utilities, windowing system etc. this is really
a small part of the effort. Since Linux has a large degree of call
compatibility with portable OS's I wouldn't complain. I'm personally
very grateful to have an OS that makes it more likely that some of us will
be able to take advantage of the software that has come out of Berkeley,
FSF, CMU etc. It may well be that in 2-3 years when ultra cheap BSD
variants and Hurd proliferate, that Linux will be obsolete. Still, right
now Linux greatly reduces the cost of using tools like gcc, bison, bash
which are useful in the development of  such an OS.

And reply I did, with complete abandon, and no thought for good taste
and netiquette.  Apologies to ast, and thanks to John Nall for a friendy
"that's not how it's done"-letter.  I over-reacted, and am now composing
a (much less acerbic) personal letter to ast.  Hope nobody was turned
away from linux due to it being (a) possibly obsolete (I still think
that's not the case, although some of the criticisms are valid) and (b)
written by a hothead :-)

                Linus "my first, and hopefully last flamefest" Torvalds

But the Existence of Linux suggests that we may have more of an
Einstein than a Quail here.
--
David Feustel N9MYI, 1930 Curdes Ave, Fort Wayne, IN 46805. (219)482-9631
feus...@netcom.com
=== NBC News: GE's Advertising And Public Relations Agency ===

Andy Tanenbaum:

May I recommend the use of the verb "posixiate" (by analogy with
asphyxiate) instead of "posixize"?  Similarly, I prefer "ansitise"
(converse and anagram of "sanitise") to "ansify".
--
Geoff Collyer           world.std.com!geoff, uunet.uu.net!geoff

Sorry, but I just can't resist this thread...:-)

And an explicit design goal of Linux was to take advantage of the special
features of the 386 architecture.  So what exactly is your point?  Different
design goals get you different designs.  You ought to know that.

I find it very interesting that you claim here that Minix was designed
primarily for cheap hardware (in particular, the IBM PC/XT with no hard
disk) and yet elsewhere have also mentioned the virtues of being portable
across hardware platforms.  Well, if you insist on designing the thing
with the lowest common denominator as your basis, that's fine, but of
course the end result will be less than pretty unless designed *very*
carefully.

Except that Linux was designed more for the purposes of the designer than
anything else.  If I were writing an OS, I'd design it to suit myself, too.
It's just that Linus was nice enough to share his code with the rest of us.

Maybe.  But by then, the 386/486 will probably be where the PC is now:
everyone will have one and they'll be dirt cheap.  The timing will be
about right.  In which case Linux will fit right in, wouldn't you say?

Here's a question for you: as a general rule, when you go to design an
operating system, do you design it for specific capabilities and then run
it on whatever hardware will do the job, or do you design it with the
hardware as a target and fit the capabilities to the hardware?  With respect
to Minix, it seems you did the latter, but I don't know whether or not you
did that with Amoeba.

Bull.  A multithreaded file system has a completely different design than
a single-threaded file system and has different design criteria than a
single-threaded file system.

If there is only going to be one job active anyway then *why bother with
multitasking at all*????

If you're going to implement multitasking, then don't do a halfway job
of it.  On the other hand, if you're going to assume that there will be
only one job active anyway, then don't bother with multitasking (after
all, it *does* complicate things :-).

Maybe.  Multiple users means multiple things being done simultaneously.  I
wouldn't bet on the buffer cache buying you so much that multithreading
makes no difference.  It's one thing if the users are doing something
simple, like editing a file.  It's another thing if they're compiling,
reading news, or other things that touch lots of different files.

Which happens a *lot* when you're running multiple users.  Or when you're
a machine hooked up to the net and handling news traffic.

Oh, come on.  How tough is it to implement a multi-threaded file system?
All you need is a decent *buffered* (preferably infinitely so)
message-passing system and a way to save your current state when you send
out a request to the device driver(s) to perform some work (and obviously
some way to restore that state).  Minix has the second via the setjmp()/
longjmp() mechanism, but lacks the former in a serious way.

Not if you're trying to implement the system call semantics of Unix in a
reasonably simple and elegant way.

Why not?  What's this big thing against monolithic kernels?  There are
certain classes of problems for which a monolithic kernel is a more
appropriate design than a microkernel architecture.  I think implementing
Unix semantics with a minimum of fuss is one such problem.

Unless you can suggest an elegant way to terminate a system call upon
receipt of a signal from within a microkernel OS?

Weird as the Intel line may be, it's *the* most popular line, by several
times.  So it's not like it's *that* big a loss.  And Intel hardware is
at least relatively cheap to come by, regardless of what your students
might tell you (why do you think they all own PCs?)...

As long as you don't sacrifice too much in the way of performance or
architectural elegance in order to gain this.  Unfortunately, that's
*exactly* what happened with Minix: in attempting to implement it on
hardware of the lowest caliber, you ended up having to make design
decisions with respect to the architecture and implementation that have
made vintage Minix unusable as anything more than a personal toy operating
system.  For example: why didn't you implement a system call server as
a layer between the file system and user programs?  My guess: you didn't
have enough memory on the target machine to do it.

Put another way: you hit your original goal right on target, and are to
be applauded for that.  But in doing so, you missed a lot of other
targets that wouldn't have been hard to hit as well, with some
consideration of them.  I think.  But I wasn't there when you were making
the decisions, so it's real hard for me to say for sure.  I'm speaking
from hindsight, but you had the tough problem of figuring out what to do
without such benefit.

Now, *modified* Minix is usable.  Add a bigger buffer cache.  Modify it
so that it can take advantage of 386 protected mode.  Fix the tty driver
so that it will give you multiple consoles.  Fix the rs232 driver to deal
with DCD/DTR and do the right thing when carrier goes away.  Fix the pipes
so that read and write requests don't fail just because they happen to be
bigger than the size of a physical pipe.  Add shared text segments so you
maximize the use of your RAM.  Fix the scheduler so that it deals with
character I/O bound processes in a reasonable way.

Yeah, right.  Just what hardware do you think they'd like to port DOS to,
anyway?  I can't think of any.  I don't think IBM or Microsoft are
regretting *that* particular aspect of DOS.  Rather, they're probably
regretting the fact that it was written for the address space provided
by the 8088.

MS-DOS isn't less than brilliant because it was written for one machine
architecture.  It's less than brilliant because it doesn't do anything
well, *regardless* of its portability or lack thereof.

He made his code freely redistributable.  *You* didn't even do that.  Just
for that move ...

read more »

All right: a real technical point, and one that made some of my comments
inexcusable.  But at the same time you shoot yourself in the foot a bit:
now you admit that some of the errors of minix were that it was too
portable: including machines that weren't really designed to run unix.
That assumption lead to the fact that minix now cannot easily be
extended to have things like paging, even for machines that would
support it.  Yes, minix is portable, but you can rewrite that as
"doesn't use any features", and still be right.

Not true.  It's a performance hack /on a microkernel/, but it's an
automatic feature when you write a monolithic kernel - one area where
microkernels don't work too well (as I pointed out in my personal mail
to ast).  When writing a unix the "obsolete" way, you automatically get
a multithreaded kernel: every process does it's own job, and you don't
have to make ugly things like message queues to make it work
efficiently.

Besides, there are people who would consider "only a performance hack"
vital: unless you have a cray-3, I'd guess everybody gets tired of
waiting on the computer all the time. I know I did with minix (and yes,
I do with linux too, but it's /much/ better).

Well, I probably won't get too good grades even without you: I had an
argument (completely unrelated - not even pertaining to OS's) with the
person here at the university that teaches OS design.  I wonder when
I'll learn :)

But /my/ point is that the operating system /isn't/ tied to any
processor line: UNIX runs on most real processors in existence.  Yes,
the /implementation/ is hardware-specific, but there's a HUGE
difference.  You mention OS/360 and MS-DOG as examples of bad designs
as they were hardware-dependent, and I agree.  But there's a big
difference between these and linux: linux API is portable (not due to my
clever design, but due to the fact that I decided to go for a fairly-
well-thought-out and tested OS: unix.)

If you write programs for linux today, you shouldn't have too many
surprises when you just recompile them for Hurd in the 21st century.  As
has been noted (not only by me), the linux kernel is a miniscule part of
a complete system: Full sources for linux currently runs to about 200kB
compressed - full sources to a somewhat complete developement system is
at least 10MB compressed (and easily much, much more). And all of that
source is portable, except for this tiny kernel that you can (provably:
I did it) re-write totally from scratch in less than a year without
having /any/ prior knowledge.

In fact the /whole/ linux kernel is much smaller than the 386-dependent
things in mach: i386.tar.Z for the current version of mach is well over
800kB compressed (823391 bytes according to nic.funet.fi).  Admittedly,
mach is "somewhat" bigger and has more features, but that should still
tell you something.

                Linus

in article <1992Jan30.195850.7...@epas.toronto.edu>, meg...@epas.utoronto.ca (David Megginson) says:

What a horrible thought !

But on the points about microkernel v monolithic, isnt this partly an
artifact of the language being used ? MINIX may well be designed as a
microkernel system, but in the end you still end up with a large
monolithic chunk of binary data that gets loaded in as "the OS". Isnt it
written as separate programs simply because C does not support the idea
of multiple processes within a single piece of monolithic code. Is there
any real difference between a microkernel written as several pieces of C
and a monolithic kernel written in something like OCCAM ? I would have
thought that in this case the monolithic design would be a better one
than the micorkernel style since with the advantage of inbuilt
language concurrency the kernel could be made even more modular than the
MINIX one is.

Anyone for MINOX :-)

-bat.
--
-Pete French. (the -bat. )         /
Adaptive Systems Engineering      /  

I hear bsd 4.4 might also become free and appear in the near future
for the 386, also someone's supposed to be working on bsd 4.4 on top
of the Mach microkernel, and then there's of course GNU.  Currently of
course for many people Linux is the OS to use because it's here now,
is free and works.

A note here, the sources I've seen seem to imply that Amoeba will not
be free as in you won't be able to use it, copy it, enhance it, share
it etc. without paying $$ and/or asking permission from someone.

//Jyrki

In article <1992Jan30.153816.1...@klaava.Helsinki.FI> torva...@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
   In article <1992Jan29.231426.20...@klaava.Helsinki.FI> I wrote:
:  :Well, with a subject like this, I'm afraid I'll have to reply.

:   And reply I did, with complete abandon, and no thought for good taste
:   and netiquette.  Apologies to ast, and thanks to John Nall for a friendy
:   "that's not how it's done"-letter.  I over-reacted, and am now composing

        I didn't and still don't see anything wrong to FOLLOUP, if
        I'm getting *bashed* on the net. Linus' article was clear
        and not against 'good taste' (what ever that is).

        Linus doesn't have anything to apologise, not even on
        comp.os.minix.

:                  Linus "my first, and hopefully last flamefest" Torvalds

        arl             // has nothing to do what I'm thinking about
                        // Minix or Linux.

Can you recommend any (unbiased) literature that points out the strengths
and weaknesses of the two approaches?  I'm sure that there is something
to be said for the microkernel approach, but I wonder how closely
Minix resembles the other systems that use it.  Sure, Minix uses lots
of tasks and messages, but there must be more to a microkernel architecture
than that.  I suspect that the Minix code is not split optimally into tasks.

My main complaint with Minix is not it's performance.  It is that adding
features is a royal pain -- something that I presume a microkernel
architecure is supposed to alleviate.

Is there a consensus on this?

This is a fine assertion, but I've yet to see any rationale for it.
Linux is only about 12000 lines of code I think.  I don't see how
splitting that into tasks and blasting messages around would improve it.

Well, there are no other choices that I'm aware of at the moment.  But
when GNU OS comes out, I'll very likely jump ship again.  I sense that
you *are* somewhat unhappy about Linux (and that surprises me somewhat).
I would guess that the reason so many people embraced it, is because it
offers more features.  Your approach to people requesting features in
Minix, has generally been to tell them that they didn't really want that
feature anyway.  I submit that the exodus in the direction of Linux
proves you wrong.

Disclaimer:  I had nothing to do with Linux development.  I just find
             it an easier system to understand than Minix.
--
Doug Graham         dgra...@bnr.ca         My opinions are my own.

The history of software shows that availability wins out over
technical quality every time.  That's Linux' major advantage.  It's a
small 386-based system that's fairly compatible with generic Unix, and
is freely available.  I dropped out of the Minix community a couple of
years ago when it became clear that (1) Minix was not going to take
advantage of anything beyond the 8086 anytime in the near future, and
(2) the licensing -- while amazingly friendly -- still made it hard
for people who were interested in producing a 386 version.  Several
people apparently did nice work for the 386.  But all they could
distribute were diffs.  This made bringing up a 386 system a job that
isn't practical for a new user, and in fact I wasn't sure I wanted to
do it.  

I apologize if things have changed in the last couple of years.  If
it's now possible to get a 386 version in a form that's ready to run,
the community has developed a way to share Minix source, and bringing
up normal Unix programs has become easier in the interim, then I'm
willing to reconsider Minix.  I do like its design.

It's possible that Linux will be overtaken by Gnu or a free BSD.
However, if the Gnu OS follows the example of all other Gnu software,
it will require a system with 128MB of memory and a 1GB disk to use.
There will still be room for a small system.  My ideal OS would be 4.4
BSD.  But 4.4's release date has a history of extreme slippage.  With
most of their staff moving to BSDI, it's hard to believe that this
situation is going to be improved.  For my own personal use, the BSDI
system will probably be great.  But even their very attractive pricing
is likely to be too much for most of our students, and even though
users can get source from them, the fact that some of it is
proprietary will again mean that you can't just put altered code out
for public FTP.  At any rate, Linux exists, and the rest of these
alternatives are vapor.

It's not your fault for believing that Linux is tied to the 80386
architecture, since many Linux supporters (including Linus himself) have
made the this statement.  However, the amount of 80386-specific code is
probably not much more than what is in a Minix implementation, and there
is certainly a lot less 80386 specific code in Linux than here is
Vax-specific code in BSD 4.3.

Granted, the port to other architectures hasn't been done yet.  But if I
were going to bring up a Unix-like system on a new architecture, I'd
probably start with Linux rather than Minix, simply because I want to
have some control over what I can do with the resulting system when I'm
done with it.  Yes, I'd have to rewrite large portions of the VM and
device driver layers --- but I'd have to do that with any other OS.
Maybe it would be a little bit harder than it would to port Minix to the
new architecture; but this would probably be only true for the first
architecture that we ported Linux to.

This is not necessarily the case; I think you're painting a much more
black and white view of the universe than necessarily exists.  I refer
you to such papers as Brent Welsh's (we...@parc.xerox.com) "The
Filsystem Belongs in the Kernel" paper, where in he argues that the
filesystem is a mature enough abstraction that it should live in the
kernel, not outside of it as it would in a strict microkernel design.

There also several people who have been concerned about the speed of
OSF/1 Mach when compared with monolithic systems; in particular, the
nubmer of context switches required to handle network traffic, and
networked filesystems in particular.

I am aware of the benefits of a micro kernel approach.  However, the
fact remains that Linux is here, and GNU isn't --- and people have been
working on Hurd for a lot longer than Linus has been working on Linux.
Minix doesn't count because it's not free.  :-)  

I suspect that the balance of micro kernels versus monolithic kernels
depend on what you're doing.  If you're interested in doing research, it
is obviously much easier to rip out and replace modules in a micro
kernel, and since only researchers write papers about operating systems,
ipso facto micro kernels must be the right approach.  However, I do know
a lot of people who are not researchers, but who are rather practical
kernel programmers, who have a lot of concerns over the cost of copying
and the cost of context switches which are incurred in a micro kernel.

By the way, I don't buy your arguments that you don't need a
multi-threaded filesystem on a single user system.  Once you bring up a
windowing system, and have a compile going in one window, a news reader
in another window, and UUCP/C News going in the background, you want
good filesystem performance, even on a single-user system.  Maybe to a
theorist it's an unnecessary optimization and a (to use your words)
"performance hack", but I'm interested in a Real operating system ---
not a research toy.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Theodore Ts'o                           bloom-beacon!mit-athena!tytso
308 High St., Medford, MA 02155         ty...@athena.mit.edu
   Everybody's playing the game, but nobody's rules are the same!

[[We must be talking about protected mode]] *THIS IS UNTRUE*

The Intel architecture supports independent tasks, each of which can be
given a "i/o privilege level". The convenient approach, used by iRMX(?), is
to "build" a load image ("root" device driver, kernel, MM and FS). Once
booted, these could be replaced by loadable tasks from disc (or network...)
and given a suitable privilege level.

The '386 additionally allows each task to have an "i/o permissions bitmap"
which specifies exactly which ports can be used.
(See "80386 Programmers Reference Manual", chapter 8)

Do you really mean "user programs" and not "separate tasks" ??

Separate tasks, possibly privileged, I'll agree with.

User level programs may be ok for teaching operating system principles, or on
toy computers :-)  But a "production" system?  Not on my machines!

joe.
--
j...@jshark.rn.com
uunet!nstar!jshark!joe

If you looked at the source instead of believing the author, you'd realise
this is not true!

He's replaced 'fubyte' by a routine which explicitly uses a segment register
- but that could be easily changed. Similarly, apart from a couple of places
which assume the '386 MMU, a couple of macros to hide the exact page sizes
etc would make porting trivial. Using '386 TSS's makes the code simpler,
but the VAX and WE32000 have similar structures.

As he's already admitted, a bit of planning would have the the system
neater, but merely putting '386 assembler around isn't a crime!

And with all due respect:
  - the Book didn't make an issue of portability (apart from a few
    "#ifdef M8088"s)
  - by the time it was released, Minix had come to depend on several
    8086 "features" that caused uproar from the 68000 users.

joe.
--
j...@jshark.rn.com

I've used Minix quite a bit on a PC XT, from version 1.2 onwards, and
a couple of points seem worth making.  Firstly that I ordered version
1.1 from Prentice Hall, and am devoutly thankful that they delayed my
order until 1.2 was available.  The first version of something as
complicated as an OS is only for the dedicated, and that goes for Linux
too I should think.

Secondly Minix has evolved to a reliable OS on its original PC platform,
but is still getting there on eg. the Mac; these things do take time.

Thirdly even (standard) PC 1.5 Minix won't run a lot of current Unix
software.  Partly this is a matter of the hardware being too limited,
and partly a matter of Minix being too limited in eg: the tty driver.
(And even this tty driver took a lot of sorting out in the early days).

Fourthly, I bought my XT four years ago - the motherboard was $110,
and memory (falling in price) was $7.00 per 256KB chip.  Last autumn
I bought my wife an XT to replace her CP/M word-processor - the m/b
was $50, and memory was $1.50 a chip.  This week I replaced a dead
286 board for a friend - the drop-in 16MHz 386SX was $140, and memory
was $40 for 9 x 1MB...  If I actually wanted an OS to use today, I
think I'd go with Linux; but if I wanted to learn about OS's, I think
I'd use Minix.  It looks as if they both do what they were designed
to do.

Will
c...@pnet01.cts.com