>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`.

> 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.

>> 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.

>It gets to sound more and more like Tripos and the Amiga :-)

> >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`.

> 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-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).

> 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.

> >   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.

> 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.

> >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.

> 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... :-).

> >   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.

> All in all, I tend to agree.

> >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.

> 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...

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

> Minix is an excellent piece of work.  A good starting point for
anyone who
> wants to learn about operating systems.  But

> > >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`.

> > 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-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).

> > 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.

> > >   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.

> > 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.

> > >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.

> > 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... :-).

> > >   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.

> > All in all, I tend to agree.

> > >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.

> > 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???

>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.