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!