https://groups.google.com/g/comp.os.minix/c/wlhw16QWltI

[logo_group]Groups
Conversations
All groups and messages
[Search conversations][                    ]
Send feedback to Google
Help
Training
#
Sign in
Groups

comp.os.minix

 
Conversations
 
About
Privacy * Terms
info
Google Groups no longer supports new Usenet posts or subscriptions.
Historical content remains viewable.
Dismiss
 
Learn more
Groups keyboard shortcuts have been updated
Dismiss
See shortcuts





LINUX is obsolete

122,364 views
Skip to first unread message

Andy Tanenbaum's profile photo

Andy Tanenbaum

unread,
Jan 29, 1992, 7:12:50 AM1/29/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to

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.

David Megginson's profile photo

David Megginson

unread,
Jan 29, 1992, 9:12:12 AM1/29/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to

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

Andy Tanenbaum's profile photo

Andy Tanenbaum

unread,
Jan 29, 1992, 1:03:01 PM1/29/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <1992Jan29.1...@epas.toronto.edu> meg...@epas.utoronto.ca
(David Megginson) writes:
>
>Why does the
>Intel architecture _not_ allow drivers to be independent programs?

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)

Kevin Brown's profile photo

Kevin Brown

unread,
Jan 29, 1992, 8:36:43 PM1/29/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to


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

Linus Benedict Torvalds's profile photo

Linus Benedict Torvalds

unread,
Jan 29, 1992, 6:14:26 PM1/29/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
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!

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

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

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.

>1. MICROKERNEL VS MONOLITHIC SYSTEM

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.

> MINIX is a microkernel-based system. [deleted, but not so that you
> miss the point ] LINUX is a monolithic style system.

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 ]

>2. PORTABILITY

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

Louie's profile photo

Louie

unread,
Jan 29, 1992, 9:55:22 PM1/29/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum) writes:

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

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

Jim Burns's profile photo

Jim Burns

unread,
Jan 29, 1992, 10:39:48 PM1/29/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
in article <12...@star.cs.vu.nl>, a...@cs.vu.nl (Andy Tanenbaum)
says:

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

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: gt0...@prism.gatech.edu
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a

Andy Tanenbaum's profile photo

Andy Tanenbaum

unread,
Jan 30, 1992, 8:44:34 AM1/30/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <1992Jan29.2...@klaava.Helsinki.FI> 
torv...@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>You use this [being a professor] as an excuse for the limitations of
minix?
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.

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

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


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

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


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

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)

David Feustel's profile photo

David Feustel

unread,
Jan 30, 1992, 1:57:28 PM1/30/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
a...@cs.vu.nl (Andy Tanenbaum) writes:


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

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

David Megginson's profile photo

David Megginson

unread,
Jan 30, 1992, 2:58:50 PM1/30/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <1992Jan30.1857...@netcom.COM> feu...@netcom.COM (David
Feustel) writes:
>a...@cs.vu.nl (Andy Tanenbaum) writes:
>
>
>>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 :-)
>
>That's ok. Einstein got lousy grades in math and physics.

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


Randy Burns's profile photo

Randy Burns

unread,
Jan 30, 1992, 3:33:07 PM1/30/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum)
writes:
>In article <1992Jan29.2...@klaava.Helsinki.FI> 
torv...@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:

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

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

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

........


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

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.

> An OS itself should be easily portable to new hardware
>platforms.

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.

Linus Benedict Torvalds's profile photo

Linus Benedict Torvalds

unread,
Jan 30, 1992, 10:38:16 AM1/30/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <1992Jan29.2...@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
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

David Feustel's profile photo

David Feustel

unread,
Jan 30, 1992, 6:15:05 PM1/30/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
meg...@epas.utoronto.ca (David Megginson) writes:

>In article <1992Jan30.1857...@netcom.COM> feu...@netcom.COM (David
Feustel) writes:
>>a...@cs.vu.nl (Andy Tanenbaum) writes:
>>
>>
>>>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 :-)
>>
>>That's ok. Einstein got lousy grades in math and physics.

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

But the Existence of Linux suggests that we may have more of an
Einstein than a Quail here.


Geoff Collyer's profile photo

Geoff Collyer

unread,
Jan 30, 1992, 8:13:00 PM1/30/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
Andy Tanenbaum:

>MINIX was designed before POSIX, and is now being (slowly) POSIXized
as
>everyone who follows this newsgroup knows.

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

Kevin Brown's profile photo

Kevin Brown

unread,
Jan 31, 1992, 2:43:47 AM1/31/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
Sorry, but I just can't resist this thread...:-)

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

>In article <1992Jan29.2...@klaava.Helsinki.FI> 
torv...@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>>You use this [being a professor] as an excuse for the limitations
of minix?
>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.

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.

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

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.

>Making software free, but only for folks with enough money
>to buy first class hardware is an interesting concept.

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.

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

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?

>>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.
>Amoeba was not designed to run on an 8088 with no hard disk.

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.

>>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.
>A multithreaded file system is only a performance hack.

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.

>When there is only one job active, the normal case on a small PC, it
buys
>you nothing and adds complexity to the code.

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

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

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.

>It is only a win when there are multiple processes actually doing
real disk
>I/O.

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.

>Whether it is worth making the system more complicated for this case
is
>at least debatable.

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.

>I still maintain the point that designing a monolithic kernel in
1991 is
>a fundamental error.

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

>Be thankful you are not my student. You would not
>get a high grade for such a design :-)

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?

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

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

>An OS itself should be easily portable to new hardware
>platforms.

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.

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

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.


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

He made his code freely redistributable. *You* didn't even do that.
Just
for that move alone, he scores points in my book. Of course, the
distribution technology available to him is much better than what was
available when you did Minix, so it's hard to fault you for that...

But I must admit, Minix is still one hell of a bargain, and I would
never
hesitate to recommend it to anyone who wants to learn something about
Unix
and operating systems in general. As a working operating system
(i.e.,
one intended for a multi-user environment), however, I'd hesitate to
recommend it, except that there really aren't any good alternatives
(except Linux, of course, at least tentatively. I can't say for sure,
since I haven't checked out Linux yet), since it doesn't have the
performance
capabilities that a working operating system needs.

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


Kevin Brown

Linus Benedict Torvalds's profile photo

Linus Benedict Torvalds

unread,
Jan 31, 1992, 5:33:23 AM1/31/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum)
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.

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.

>A multithreaded file system is only a performance hack.

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

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

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

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

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

-Pete French.'s profile photo

-Pete French.

unread,
Jan 31, 1992, 4:49:37 AM1/31/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
in article <1992Jan30....@epas.toronto.edu>, meg...@epas.utoronto.ca
(David Megginson) says:
> Nntp-Posting-Host: epas.utoronto.ca

>
> In article <1992Jan30.1857...@netcom.COM> feu...@netcom.COM (David
Feustel) writes:
>>
>>That's ok. Einstein got lousy grades in math and physics.
>
> And Dan Quayle got low grades in political science. I think that
there
> are more Dan Quayles than Einsteins out there... ;-)

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 /

Jyrki Kuoppala's profile photo

Jyrki Kuoppala

unread,
Jan 31, 1992, 7:07:46 AM1/31/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <12...@star.cs.vu.nl>, ast@cs (Andy Tanenbaum) writes:
>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.

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.

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

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

Ari Lemmke's profile photo

Ari Lemmke

unread,
Jan 31, 1992, 6:38:50 PM1/31/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to

In article <1992Jan30....@klaava.Helsinki.FI> 
torv...@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
In article <1992Jan29.2...@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.

Douglas Graham's profile photo

Douglas Graham

unread,
Jan 31, 1992, 7:26:30 PM1/31/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum)
writes:

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

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.

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

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.

> MINIX is a microkernel-based system.

Is there a consensus on this?

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

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.

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

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 dgr...@bnr.ca My opinions are my own.

Charles Hedrick's profile photo

Charles Hedrick

unread,
Jan 31, 1992, 7:27:04 PM1/31/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
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.

Theodore Y. Ts'o's profile photo

Theodore Y. Ts'o

unread,
Jan 31, 1992, 4:40:23 PM1/31/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
>From: a...@cs.vu.nl (Andy Tanenbaum)

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

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.

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

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!

j...@jshark.rn.com's profile photo

j...@jshark.rn.com

unread,
Jan 31, 1992, 7:55:21 AM1/31/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum)
writes:
>In article <1992Jan29.1...@epas.toronto.edu> meg...@epas.utoronto.ca
(David Megginson) writes:
>>
>>Why does the
>>Intel architecture _not_ allow drivers to be independent programs?
>
>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,

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

> all the I/O tasks could have
>been user programs, like FS and MM.

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!

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

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

j...@jshark.rn.com's profile photo

j...@jshark.rn.com

unread,
Jan 31, 1992, 8:21:44 AM1/31/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum)
writes:
>
> 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.

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.


Will Rose's profile photo

Will Rose

unread,
Feb 1, 1992, 7:16:12 AM2/1/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to

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

n.h.chandler's profile photo

n.h.chandler

unread,
Feb 1, 1992, 8:38:51 PM2/1/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
I have been following the Minix/Linux discussion. How
can I get a copy of Linux?

Neville H. Chandler
cbnewsj!n...@att.com

Drew Eckhardt's profile photo

Drew Eckhardt

unread,
Feb 2, 1992, 7:17:44 AM2/2/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum)
writes:


Every 386 TSS has an iopermission bitmap. If the CPL is of a lower
priveledge
level than IOPL, the io permissions bitmap is consulted, allowing
protection
on a port by port basis.


Allan Duncan's profile photo

Allan Duncan

unread,
Feb 2, 1992, 5:06:26 PM2/2/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
From article <1992Jan30....@menudo.uh.edu>, by ke...@nuchat.sccsi.com
(Kevin Brown):


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

Allan Duncan ACSnet adu...@trl.oz
(+613) 541 6708 Internet adu...@trl.oz.au
UUCP {uunet,hplabs,ukc}!munnari!trl.oz.au!aduncan
Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168,
Australia.

j...@jshark.rn.com's profile photo

j...@jshark.rn.com

unread,
Feb 2, 1992, 6:59:12 PM2/2/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum)
writes:
>
>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.

Maybe keepng quiet would have been best.

>1. MICROKERNEL VS MONOLITHIC SYSTEM
>

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

No, MS-DOS won. Sad, but there you are. 60 million: Next

It would be churlish to point out that MS-DOS has loadable device
drivers
and that VMS is now (basically)a set of loadable service modules and
drivers.

"Microkernel" was the buzz-word of last year, so Minix is a
microkernel.
"Object-oriented" is this years, so Minix is object-oriented - right?


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

I'm a mutated .sig virus, I got this from Henry Spencer's:
"As a user, I'll take speed over features anyday" - A Tanenbaum

Kevin Brown's profile photo

Kevin Brown

unread,
Feb 3, 1992, 12:12:58 AM2/3/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
It has been brought to my attention that my last posting was
exceedingly
harsh. Having reread it, I'm inclined to agree.

Dr. Tanenbaum claims that the microkernel architecture is the way to
go.
He has a great deal more experience with operating systems than I
have.
It's an understatement that it's likely that there's some substance
to
his statement. :-)

Many of the things I said in my previous posting were more a result
of my
philosophical viewpoint on operating systems and programming in
general
than experience. And the particular viewpoint I hold that's relevent
to
the discussion says that the method of implementation chosen depends
on
the design goals, and that there is no "wrong" or "right" way to do
things
that is independent of such goals. Thus, my statement that a
monolithic
kernel follows from some design goals, e.g. ease of implementation of
the
semantics of the Unix API. In particular, the ease of implementing
things
like signal handling, premature system call termination, etc. At
least,
that's the conclusion I come to when I think about the problem.

My experience with Minix says that there are a number of things that
should
not go in a user process, things that are better left in the kernel.
Things
like memory allocation (which requires global knowledge of the
hardware,
something that a user process should, IMHO, not have) and signal
handling
(which requires building stack frames).

chiSo from my point of view, the architecture of Minix is not ideal.
While
it may win in that it's a "microkernel" architecture, the division of
functionality is not entirely to my liking. As is undoubtedly plainly
obvious by now. :-)

Despite that, Minix is quite usable in many ways as a personal
operating
system, i.e. one where there is usually only one person logged into
the
system. If I gave the impression that I thought it was unusable in
general,
then I apologize for that.

However, as a *multiuser* operating system, iuti.e. an operating
system designed
to efficiently meet the needs of multiple users simultaneously while
also
performing batch operations, Minix is lacking, as far as I'm
concerned.
The main reason, of course, is the single-threaded file system
(hereafter,
STFS). Now, Dr. Tanenbaum may feel that a multi-threaded file system
(hereafter, MTFS) is merely a performance hack. Perhaps he's right.
Perhaps the architecture of a MTFS is sufficiently similar to that of
a
STFS that his assessment is correct. My vision of a MTFS may differ
significantly from his, and this would explain why he and I seem to
have
a difference of opinion on this matter. Regardless of whether or not
a
MTFS is a "performance hack", for a *multiuser* operating system, I
think
there are a lot of good arguments that say that a MTFS is a
*necessary*
"performance hack". Provided, of course, that one does not have
infinite
buffer cache resources. :-)

There are other things I feel Minix lacks as well. The ability to
allocate
memory in the kernel is one (such an ability would allow any user
process,
e.g. device drivers and the file system, to allocate memory
dynamically.
This is useful for doing things like resizing the buffer cache on the
fly,
etc. The ability to pass arbitrarily sized messages, optionally via
shared
memory, is another (such an ability might be limited by constraints
like
page size and such).


However much Minix may be lacking from my standpoint, it is
nevertheless
a very useful and welcome enhancement to my system. In spite of the
impression that I may have given everyone in my last posting, there
will
always be a soft spot in my heart for it, if only because it's the
first
decent operating system I've had on my system that I've had source
to.
I don't have to tell you people how incredibly useful it is to have
source.
You already know.

It is very important to me to have source code to the things I run.
It
bothers me a great deal to run things that I don't have source to.
Even
the C compiler. And the less expensive the source is, the better.
This
is why Dr. Tanenbaum's statements about Linux touched a raw nerve
with me:
Linux comes with source *and* it's free. And it's available right
now.

Someone, either here on this newsgroup or over on alt.os.linux, made
a
very valid observation: the cost of a 16 MHz 386SX system is about
$140
more than a comparably equipped (in terms of RAM size, display
technology,
hard drive space, etc.) 8088 system. Minix is $169. In economic
terms,
Linux wins if you have to buy Minix.

Where Minix wins (or is at least even :-) is when you can get it for
free
via the educational distribution clause of the license agreement.
However,
Minix will run even better on a 16 MHz 386SX than on an 8088. If I
were
a student, I'd get the 386SX unless I simply didn't have a choice.
Then
I'd get whichever operating system I could get for the least cost. If
I
could get both for free, then I'd get both. :-)


Given the reasons Linus wrote Linux, I think it's hard for anyone to
fault
him for writing it the way he did. And he was extremely nice in
making
his code freely available to the rest of the world. It's not
something he
had to do. In my book, that makes him almost beyond reproach.


Dr. Tanenbaum didn't make Minix free. His goals were different. Minix
is a teaching aid above all else (unless Dr. Tanenbaum has changed
his
views about Minix :-). That means that he must be concerned with the
most efficient way to get Minix to the student population. At the
time
Minix was released, Prentice-Hall was a good solution, and has been
for
some time. However, I must wonder whether or not this is still the
case.
Dr. Tanenbaum: do you still feel that free distribution of Minix via
the
net is not the best way to distribute Minix?


Which wins? Minix or Linux? Depends on how you measure them...


Kevin Brown

peter da silva's profile photo

peter da silva

unread,
Feb 3, 1992, 11:22:32 AM2/3/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <1992Jan31....@ohm.york.ac.uk> pe...@ohm.york.ac.uk (-Pete
French.) writes:
> But on the points about microkernel v monolithic, isnt this partly
an
> artifact of the language being used ?

I doubt it.

[isn't MINIX]


> written as separate programs simply because C does not support the
idea
> of multiple processes within a single piece of monolithic code.

C doesn't support formatted I/O either, but it can be implemented
quite
effectively in C. So can concurrent processes. I've done it, in fact.
The resulting code is 90% portable (the 10% being the code that
handles
the context switch).
--
-- Peter da Silva, Ferranti International Controls Corporation
-- Sugar Land, TX 77487-5012; +1 713 274 5180
-- "Have you hugged your wolf today?"

peter da silva's profile photo

peter da silva

unread,
Feb 3, 1992, 11:37:24 AM2/3/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
Will you quit flaming each other?

I mean, linux is designed to provide a reasonably high performance
environment
on a hardware platform crippled by years of backwards-compatible
kludges. Minix
is designed as a teaching tool. Neither is that good at doing the
other's job,
and why should they? The fact that Minix runs out of steam quickly
(and it
does) isn't a problem in its chosen mileau. It's sure better than the
TOY
operating system. The fact that Linux isn't transportable beyond the
386/AT
platform isn't a problem when there are millions of them out there
(and quite
cheap: you can get a 386/SX for well under $1000).

A monolithic kernel is easy enough to build that it's worth doing it
if it gets
a system out the door early. Think of it as a performance hack for
programmer
time. The API is portable. You can replace the kernel with a
microkernel
design (and MINIX isn't the be-all and end-all of microkernel designs
either:
even for low end PCs... look at AmigaOS) without disturbing the
applications.
That's the whole point of a portable API in the first place.

Microkernels are definitely a better design for many tasks. I takes
more
work to make them efficient, so a simpler design that doesn't take
advantage
of the microkernel in any real way is worth doing for pedagogical
reasons.
Think of it as a performance hack for student time. The design is
still good
and when you can get an API to the microkernel interface you can get
VERY
impressive performance (thousands of context switches per second on
an 8
MHz 68000).


peter da silva's profile photo

peter da silva

unread,
Feb 3, 1992, 12:40:06 PM2/3/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <1992Feb01.0...@bmerh2.bnr.ca> dgr...@bmers30.bnr.ca
(Douglas Graham) writes:
> 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.

Definitely. Minix shows you how a microkernel works, but it sure
doesn't show
you why you would use one.

A couple of years ago I brought this up with Andy, and his response
indicated
that he was himself not convinced of the superiority of the
microkernel design
at the time. He said (as near as I can recall... this is a
paraphrase) that a
message passing design was inherently slower than a monolithic one...
which was
news to me: I had (and still have) a PC that was MUCH more responsive
than any
UNIX box I ever touched using a message-passing design.

> > MINIX is a microkernel-based system.

> Is there a consensus on this?

Yes, it's not a well-factored one, and there's no API to the
microkernel
interface, but it's a microkernel design.


Richard Tobin's profile photo

Richard Tobin

unread,
Feb 4, 1992, 9:46:49 AM2/4/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum)
writes:
>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

I find the single-threaded file system a serious pain when using
Minix. I often want to do something else while reading files from the
(excruciatingly slow) floppy disk. I rather like to play rogue while
waiting for large C or Lisp compilations. I look to look at files in
one editor buffer while compiling in another.

(The problem would be somewhat less if the file system stuck to
serving files and didn't interact with terminal i/o.)

Of course, in basic Minix with no virtual consoles and no chance of
running emacs, this isn't much of a problem. But to most people
that's a failure, not an advantage. It just isn't the case that on
single-user machines there's no use for more than one active process;
the idea only has any plausibility because so many people are used to
poor machines with poor operating systems.

As to portability, Minix only wins because of its limited ambitions.
If you wanted a full-featured Unix with paging, job-control, a window
system and so on, would it be quicker to start from basic Minix and
add the features, or to start from Linux and fix the 386-specific
bits? I don't think it's fair to criticise Linux when its aims are so
different from Minix's. If you want a system for pedagogical use,
Minix is the answer. But if what you want is an environment as much
like (say) a Sun as possible on your home computer, it has some
deficiencies.

-- Richard
--
Richard Tobin,
AI Applications Institute, R.T...@ed.ac.uk
Edinburgh University.

Ken Thompson's profile photo

Ken Thompson

unread,
Feb 3, 1992, 6:07:54 PM2/3/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
viewpoint may be largely unrelated to its usefulness. Many if not
most of the software we use is probably obsolete according to the
latest design criteria. Most users could probably care less if the
internals of the operating system they use is obsolete. They are
rightly more interested in its performance and capabilities at the
user level.

I would generally agree that microkernels are probably the wave of
the future. However, it is in my opinion easier to implement a
monolithic kernel. It is also easier for it to turn into a mess in
a hurry as it is modified.

Regards,
Ken

--
Ken Thompson GTRI, Ga. Tech, Atlanta Ga. 30332 Internet:!
k...@prism.gatech.edu
uucp:...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!kt4
"Rowe's Rule: The odds are five to six that the light at the end of
the
tunnel is the headlight of an oncoming train." -- Paul Dickson

Kevin Brown's profile photo

Kevin Brown

unread,
Feb 4, 1992, 3:08:42 AM2/4/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <47...@hydra.gatech.EDU> k...@prism.gatech.EDU (Ken
Thompson) writes:
>viewpoint may be largely unrelated to its usefulness. Many if not
>most of the software we use is probably obsolete according to the
>latest design criteria. Most users could probably care less if the
>internals of the operating system they use is obsolete. They are
>rightly more interested in its performance and capabilities at the
>user level.
>
>I would generally agree that microkernels are probably the wave of
>the future. However, it is in my opinion easier to implement a
>monolithic kernel. It is also easier for it to turn into a mess in
>a hurry as it is modified.

How difficult is it to structure the source tree of a monolithic
kernel
such that most modifications don't have a large negative impact on
the
source? What sorts of pitfalls do you run into in this sort of
endeavor,
and what suggestions do you have for dealing with them?

I guess what I'm asking is: how difficult is it to organize the
source
such that most changes to the kernel remain localized in scope, even
though the kernel itself is monolithic?

I figure you've got years of experience with monolithic kernels :-),
so I'd think you'd have the best shot at answering questions like
these.

>Ken Thompson GTRI, Ga. Tech, Atlanta Ga. 30332 Internet:!
k...@prism.gatech.edu
>uucp:...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!kt4
>"Rowe's Rule: The odds are five to six that the light at the end of
the
>tunnel is the headlight of an oncoming train." -- Paul Dickson

Kevin Brown

peter da silva's profile photo

peter da silva

unread,
Feb 3, 1992, 12:32:54 PM2/3/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <TYTSO.92J...@SOS.mit.edu> ty...@athena.mit.edu (Theodore
Y. Ts'o) writes:
> 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.

What does "a mature enough abstraction" mean, here? Things don't move
into the kernel simply because they're now considered safe and stable
enough, but because they're too inefficient when they're outside it
or
they lose functionality by being outside it, and there's no easy fix.

The Amiga operating system certainly benefits from having a file
system
outside the kernel. There are dozens of file systems, many of them
written
by hobbyists, available. Ideas like "assigned paths" can be played
with
in the file system without breaking stuff. All these file systems
have a
common interface and so look to the application as part of the
operating
system, but just because something is on the other side of the API
doesn't
mean it is, or belongs, in the kernel.

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

If this is because the networking was moved out of the kernel, I
consider
it a price well worth paying. Having networking code in the kernel is
the
source of many subtle bugs in networks. Just for something that bit
us,
what happens if you need to get to the upper level driver before you
can
acknowledge a packet, but the process that you need to run is hung up
in
the tty driver waiting for a ^Q?

Something *I* would have expected to find in the kernel before now,
yet
isn't, is windowing systems. With a microkernel (and the associated
lower
*cost* of a context switch) you can get much of the advantages of a
kernel
window system without paying the cost in complexity.


Kevin Brown's profile photo

Kevin Brown

unread,
Feb 4, 1992, 3:28:08 AM2/4/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <1992Feb2.2...@trl.oz.au> adu...@rhea.trl.OZ.AU (Allan
Duncan) writes:
>From article <1992Jan30....@menudo.uh.edu>, by 
ke...@nuchat.sccsi.com (Kevin Brown):
>
>> 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 :-)

There's no question that many of my ideas spring from the
architecture
of the Amiga's operating system. It's pretty impressive to see a
message-passing, multitasking operating system that operates as fast
as the Amiga's OS does on hardware that slow. They did a lot of
things
right.

There are some ideas that, I think, are my own. Or, at least, that
I've
developed independently. For example, if you have a message-passing
system that includes the option to transfer message memory ownership
to the
target process, then it naturally follows that you can globally
optimize the
use of your block cache by making your block cache global with
respect
to *all* filesystems. The filesystem code requests blocks from the
block cache manager and tells the block cache manager what device
driver
to call and what parameters to send it when flushing the block. The
block
cache manager replies with a message that is the size of a block (or,
if
you wish to allocate several at a time, several blocks). Since
ownership is transferred as a result of passing the message, the
block
cache manager can allocate the memory itself, optionally flushing as
many blocks as it needs in order to free up enough to send to the
caller.
The block cache manager is, of course, a user process. If the
filesystem
code is written right, you can kill the block cache manager in order
to
disable the block cache. The filesystem will simply do its thing
unbuffered. Makes for a slow system, but at least you can do it. You
can also change the behavior of the buffer cache by sending control
messages to the cache manager. Can you say "tunable parameters"? :-)

You could also accomplish this with some sort of shared memory, but
this
would require semaphore control of the allocation list. You'd also
have
to figure out a way to flush bits of the cache when needed (easy to
do
if you're a monolithic kernel, but I'm referring to a microkernel)
without
colliding with another process writing into the block. Semaphore
control
of the individual blocks as well?

>Allan Duncan ACSnet adu...@trl.oz
>(+613) 541 6708 Internet adu...@trl.oz.au
> UUCP {uunet,hplabs,ukc}!munnari!trl.oz.au!aduncan
>Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168,
Australia.

Kevin Brown

Julien Maisonneuve's profile photo

Julien Maisonneuve

unread,
Feb 3, 1992, 12:10:14 PM2/3/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
I would like to second Kevin brown in most of his remarks.
I'll add a few user points :
- When ast states that FS multithreading is useless, it reminds me of
the many
times I tried to let a job run in the background (like when reading
an archive on
a floppy), it is just unusable, the & shell operator could even have
been left
out.
- Most interesting utilities are not even compilable under Minix
because of the
ATK compiler's incredible limits. Those were hardly understandable on
a basic PC,
but become absurd on a 386. Every stupid DOS compiler has a large
model (more
expensive, OK). I hate the 13 bit compress !
- The lack of Virtual Memory support prevents people studying this
area to
experiment, and prevents users to use large programs. The strange
design of the
MM also makes it hard to modify.

The problem is that even doing exploratory work under minix is
painful.
If you want to get any work done (or even fun), even DOS is becoming
a better
alternative (with things like DJ GPP).
In its basic form, it is really no more than OS course example, a
good
toy, but a toy. Obtaining and applying patches is a pain, and
precludes further
upgrades.

Too bad when not so much is missing to make it really good.
Thanks for the work andy, but Linux didn't deserve your answer.
For the common people, it does many things better than Minix.

Julien Maisonneuve.

This is not a flame, just my experience.

Michael L. Kaufman's profile photo

Michael L. Kaufman

unread,
Feb 3, 1992, 5:27:48 PM2/3/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
I tried to send these two posts from work, but I think they got
eaten. If you
have seen them already, sorry.

-------------------------------------------------------------------------------

Andy Tanenbaum writes an interesting article (also interesting was
finding out
that he actually reads this group) but I think he is missing an
important
point.

He Wrote:
>As most of you know, for me MINIX is a hobby, ...

Which is also probably true of most, if not all, of the people who
are involved
in Linux. We are not developing a system to take over the OS market,
we are
just having a good time.

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

Well when this happens, if I still want to play with Linux, I can
just run it
on my 386 simulator.

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

That's fine for the people who have those machines, but it wasn't a
free
lunch. That portibility was gained at the cost of some performance
and some
features on the 386. Before you decide that LINUX is not the way to
go, you
should think about what it is going to be used for. I am going to use
it for
running memory and computation intensive graphics programs on my 486.
For me,
speed and memory were more important then future state-of-the-artness
and
portability.

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

I don't know of any free microkernel-based, portable OSes. GNU is
still
vaporware, and likely to remain that way for the forseeable future.
Do
you actually have one to recomend, or are you just toying with me? ;
-)

------------------------------------------------------------------------------

In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum)
writes:
>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.

I think I see where I disagree with you now. You are looking at OS
design
as an end in itself. Minix is good because it is portable/
Micro-Kernal/etc.
Linux is not good because it is monolithic/tightly tied to Intel/etc.
That
is not a strange attitude for someone in the acedemic world, but it
is not
something you should expect to be universally shared. Linux is not
being written
as a teaching tool, or as an abstract exercise. It is being written
to allow
people to run GNU-type software _today_. The fact that it may not be
in use
in five years is less important then the fact that today (well, by
April
probably) I can run all sorts of software on it that I want to run.
You keep
saying that Minix is better, but if it will not run the software that
I want
to run, it really isn't that good (for me) at all.

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

Same point. MSoft did not come out with Dos to "explore the frontiers
of os
research". They did it to make a buck. And considering the fact that
MS-DOS
probably still outsells everyone else put together, I don't think
that you
say that they have failed _in their goals_. Not that MS-Dos is the
best OS
in terms of anything else, only that it has served their needs.

Michael


--
Michael Kaufman | I've seen things you people wouldn't believe.
Attack ships on
kaufman | fire off the shoulder of Orion. I watched C-beams glitter
in
@eecs.nwu.edu | the dark near the Tannhauser gate. All those moments
will be
| lost in time - like tears in rain. Time to die. Roy Batty

Jonathan Allen's profile photo

Jonathan Allen

unread,
Feb 3, 1992, 2:43:00 AM2/3/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <12...@star.cs.vu.nl>, a...@cs.vu.nl (Andy Tanenbaum)
wrote:
> In article <1992Jan29.1...@epas.toronto.edu> 
meg...@epas.utoronto.ca (David Megginson) writes:
>>
>>Why does the
>>Intel architecture _not_ allow drivers to be independent programs?
>
> 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.

Surely this could have been done by a minute task just to read/write
a
given port address in one message ? The security could have been
checked
like everything else using the process table ...

Sure it would not have been at all efficient, but would have given
the independance at a price.

Jonathan

Andy Tanenbaum's profile photo

Andy Tanenbaum

unread,
Feb 5, 1992, 9:48:48 AM2/5/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <61...@skye.ed.ac.uk> ric...@aiai.UUCP (Richard Tobin)
writes:
>If you wanted a full-featured Unix with paging, job-control, a
window
>system and so on, would it be quicker to start from basic Minix and
>add the features, or to start from Linux and fix the 386-specific
>bits?

Another option that seems to be totally forgotten here is buy UNIX or
a
clone. If you just want to USE the system, instead of hacking on its
internals, you don't need source code. Coherent is only $99, and
there
are various true UNIX systems with more features for more money. For
the
true hacker, not having source code is fatal, but for people who just
want a UNIX system, there are many alternatives (albeit not free).

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

Richard Tobin's profile photo

Richard Tobin

unread,
Feb 5, 1992, 11:18:16 AM2/5/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <1992Feb2.1...@colorado.edu> dr...@anchor.cs.colorado.edu
(Drew Eckhardt) writes:
>Every 386 TSS has an iopermission bitmap. If the CPL is of a lower
priveledge
>level than IOPL, the io permissions bitmap is consulted, allowing
protection
>on a port by port basis.

I was looking into using this recently under Minix 386, and to check
I
was doing the right thing, I wrote a user program to access the video
registers. The idea was to have it fail, and then change the kernel
to make it work. To my surprise, it worked anyway...

I'll take a closer look sometime, but does anyone (Bruce?) happen to
already know the explanation?


John W. Linville's profile photo

John W. Linville

unread,
Feb 5, 1992, 12:56:35 PM2/5/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum)
writes:


Coherent is limited by a compiler that only supports the small memory
model,
making it just as difficult (perhaps more in some instances) to port
'standard'
Unix programs to Coherent as it can be under Minix. Also, Coherent is
not
portable (or at least, to the best of my knowledge, has not been
ported), so
this advocacy contradicts one of your arguments against Linux.

Since a true Unix system often costs as much as the machine it runs
on (even
more since many Unix providers un-bundle networking and development
packages),
buying a true Unix system is more than beyond the budget of many
people.

John W. Linville

Lawrence C. Foard's profile photo

Lawrence C. Foard

unread,
Feb 5, 1992, 9:56:30 AM2/5/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum)
writes:
>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.

I believe you have some valid points, although I am not sure that a
microkernel is necessarily better. It might make more sense to allow
some
combination of the two. As part of the IPC code I'm writting for
Linux I am
going to include code that will allow device drivers and file systems
to run
as user processes. These will be significantly slower though, and I
believe it
would be a mistake to move everything outside the kernel (TCP/IP will
be
internal).

Actually my main problem with OS theorists is that they have never
tested
there ideas! None of these ideas (with a partial exception for MACH)
has ever
seen the light of day. 32 bit home computers have been available for
almost a
decade and Linus was the first person to ever write a working OS for
them
that can be used without paying AT&T $100,000. A piece of software in
hand is
worth ten pieces of vaporware, OS theorists are quick to jump all
over an OS
but they are unwilling to ever provide an alternative.

The general consensus that Micro kernels is the way to go means
nothing when
a real application has never even run on one.

The release of Linux is allowing me to try some ideas I've been
wanting to
experment with for years, but I have never had the opportunity to
work with
source code for a functioning OS.
--
Disclaimer: Opinions are based on logic rather than biblical "fact".
------
Hackers do it for fun. | First they came for the drug users, I said \
/
"Profesionals" do it for money. | nothing, then they came for
hackers, \ /
Managers have others do it for them. | I said nothing... STOP W.O.D.
\/

David Megginson's profile photo

David Megginson

unread,
Feb 5, 1992, 3:50:55 PM2/5/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum)
writes:

>Another option that seems to be totally forgotten here is buy UNIX
or a
>clone. If you just want to USE the system, instead of hacking on its
>internals, you don't need source code. Coherent is only $99, and
there
>are various true UNIX systems with more features for more money. For
the
>true hacker, not having source code is fatal, but for people who
just
>want a UNIX system, there are many alternatives (albeit not free).

What Unix's _are_ available for a simple, M68000-based ST, with _or_
without source? These are the only options I know of:

1) OS 9.
2) The Beckmeyer MT C-Shell.
3) MiNT.
4) Minix.

I have used all of these except for OS 9, and Minix is clearly the
closest thing to Unix that I can run (though it is easier to port BSD
programs to MiNT using the MiNT gcc library). I could shell out CAN
$3000 for a TT, but then I may as well buy a 386 box anyway. Besides,
I _like_ having the source. The extra advantage of Minix is that the
user base is a lot wider than the ST market, so I can get decent
system enhancements from Amiga, Mac, Sparc, XT, AT, '386 and '486
users as well as from fellow ST owners.


David

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

Andy Tanenbaum's profile photo

Andy Tanenbaum

unread,
Feb 5, 1992, 6:33:23 PM2/5/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <1992Feb5....@wpi.WPI.EDU> ent...@wintermute.WPI.EDU
(Lawrence C. Foard) writes:
>Actually my main problem with OS theorists is that they have never
tested
>there ideas!
I'm mortally insulted. I AM NOT A THEORIST. Ask anybody who was at
our
department meeting yesterday (in joke).

Actually, these ideas have been very well tested in practice. OSF is
betting
its whole business on a microkernel (Mach 3.0). USL is betting its
business
on another one (Chorus). Both of these run lots of software, and both
have
been extensively compared to monolithic systems. Amoeba has been
fully
implemented and tested for a number of applications. QNX is a
microkernel
based system, and someone just told me the installed base is 200,000
systems.
Microkernels are not a pipe dream. They represent proven technology.

The Mach guys wrote a paper called "UNIX as an application program."
It was by Golub et al., in the Summer 1990 USENIX conference. The
Chorus
people also have a technical report on microkernel performance, and I
coauthored another paper on the subject, which I mentioned yesterday
(Dec. 1991 Computing Systems). Check them out.

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

Lawrence C. Foard's profile photo

Lawrence C. Foard

unread,
Feb 6, 1992, 4:22:40 AM2/6/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <1992Feb3.0...@menudo.uh.edu> ke...@taronga.taronga.com
(Kevin Brown) writes:
>Dr. Tanenbaum claims that the microkernel architecture is the way to
go.
>He has a great deal more experience with operating systems than I
have.
>It's an understatement that it's likely that there's some substance
to
>his statement. :-)

I tend to prefer seeing for myself rather than accepting "expert"
opinion.
Microkernels are nice asthetically, but there are times when
practical issues
must also be considered :)

>w3So from my point of view, the architecture of Minix is not ideal.
While


>it may win in that it's a "microkernel" architecture, the division
of
>functionality is not entirely to my liking. As is undoubtedly
plainly
>obvious by now. :-)

I've been told by people who have used both that Linux is
significantly
faster. There are certainly several factors involved (certainly using
32 bits
helps alot), but the multithreading also makes for much lower
overhead.

>However, as a *multiuser* operating system, ~ri.e. an operating
system designed


>to efficiently meet the needs of multiple users simultaneously while
also
>performing batch operations, Minix is lacking, as far as I'm
concerned.
>The main reason, of course, is the single-threaded file system
(hereafter,
>STFS). Now, Dr. Tanenbaum may feel that a multi-threaded file system
>(hereafter, MTFS) is merely a performance hack.

I think this is a very valid problem. There are two ways a single
threaded FS
could work and both have substantial problems. If the FS blocks while
waiting
for I/O it would be completely unusable for "real" work. Imagine
several users
accessing a database, if the FS blocks for I/O they will have to wait
eventhough the data they are looking for is already in the cache. If
it is
designed to be non blocking then it is even more complicated than a
multithreaded FS and will have more overhead. I hope it is atleast
the second

>However much Minix may be lacking from my standpoint, it is
nevertheless
>a very useful and welcome enhancement to my system. In spite of the
>impression that I may have given everyone in my last posting, there
will
>always be a soft spot in my heart for it, if only because it's the
first
>decent operating system I've had on my system that I've had source
to.
>I don't have to tell you people how incredibly useful it is to have
source.
>You already know.

I will agree here, Minix is infinitly better than Messy-Loss :)

>Given the reasons Linus wrote Linux, I think it's hard for anyone to
fault
>him for writing it the way he did. And he was extremely nice in
making
>his code freely available to the rest of the world. It's not
something he
>had to do. In my book, that makes him almost beyond reproach.

I think more effort has been put into making practical use of Linux
possible.
An educational OS is nice, but there is a world outside of colleges
that
is suffering from the lack of cheap and useful OS's, I've been stuck
doing
most consulting work in Messy Loss because customers don't want to
fork out
$1000 for UNIX.

>Dr. Tanenbaum didn't make Minix free. His goals were different.
Minix
>is a teaching aid above all else (unless Dr. Tanenbaum has changed
his
>views about Minix :-). That means that he must be concerned with the
>most efficient way to get Minix to the student population. At the
time
>Minix was released, Prentice-Hall was a good solution, and has been
for
>some time. However, I must wonder whether or not this is still the
case.
>Dr. Tanenbaum: do you still feel that free distribution of Minix via
the
>net is not the best way to distribute Minix?

I would guess that Prentice-Hall would have some objections :)


--
Disclaimer: Opinions are based on logic rather than biblical "fact".
------

This is your friendly | First they came for the drug users, I said \
/
neighborhood signature virus | nothing, then they came for hackers, \
/
please add me to your signature! | I said nothing... STOP W.O.D. \/

Timothy Murphy's profile photo

Timothy Murphy

unread,
Feb 6, 1992, 6:14:59 AM2/6/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In <1992Feb5....@wpi.WPI.EDU> ent...@wintermute.WPI.EDU (Lawrence C.
Foard) writes:

>32 bit home computers have been available for almost a
>decade and Linus was the first person to ever write a working OS for
them
>that can be used without paying AT&T $100,000. A piece of software
in hand is
>worth ten pieces of vaporware, OS theorists are quick to jump all
over an OS
>but they are unwilling to ever provide an alternative.

Surely Bruce Evans' 386-Minix preceded Linux?

(Diffs for PC-Minix -> 386-Minix
available from archive...@plains.nodak.edu
in the directory Minix/oz)

--
Timothy Murphy
e-mail: t...@maths.tcd.ie
tel: +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland

Tony Travis's profile photo

Tony Travis

unread,
Feb 5, 1992, 9:17:13 PM2/5/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
a...@cs.vu.nl (Andy Tanenbaum) writes:
> Another option that seems to be totally forgotten here is buy UNIX
or a
> clone. If you just want to USE the system, instead of hacking on
its
> internals, you don't need source code. Coherent is only $99, and
there
> are various true UNIX systems with more features for more money.
For the
> true hacker, not having source code is fatal, but for people who
just
> want a UNIX system, there are many alternatives (albeit not free).

Andy, I have followed the development of Minix since the first
messages
were posted to this group and I am now running 1.5.10 with Bruce
Evans's patches for the 386.

I 'just' want a Unix on my PC and I am not interested in hacking on
its
internals, but I *do* want the source code!

An important principle underlying the success and popularity of Unix
is
the philosophy of building on the work of others.

This philosophy relies upon the availability of the source code in
order that it can be examined, modified and re-used in new software.

Many years ago, I was in the happy position of being an AT&T Seventh
Edition Unix source licencee but, even then, I saw your decision to
make the source of Minix available as liberation from the shackles of
AT&T copyright!!

I think you may sometimes forget that your 'hobby' has had a profound
effect on the availability of 'personal' Unix (ie. affordable Unix)
and
that the 8086 PC I ran Minix 1.2 on actually cost me considerably
more
than my present 386/SX clone.

Clearly, Minix _cannot_ be all things to all men, but I see the
progress to 386 versions in much the same way that I see 68000 or
other
linear address space architectures: it is a good thing for people
like
me who use Minix and feel constrained by the segmented architecture
of
the PC version for applications.

NOTHING you can say would convince me that I should use Coherent ...

Tony

--
-------------------------------------------------------------------------------
Dr. A.J.Travis <a...@uk.ac.sari.rri> | Rowett Research Institute,
| Greenburn Road, Bucksburn, Aberdeen,
| AB2 9SB. UK. tel 0224-712751

Jerry Shekhel's profile photo

Jerry Shekhel

unread,
Feb 6, 1992, 4:28:05 PM2/6/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
linv...@garfield.catt.ncsu.edu (John W. Linville) writes:
>
>Since a true Unix system often costs as much as the machine it runs
on (even
>more since many Unix providers un-bundle networking and development
packages),
>buying a true Unix system is more than beyond the budget of many
people.
>

For those who may be interested, MST sells System V Release 4.0.3 for
the
386/486 for $399 including development system, $499 if you need
networking.
X11R5 binaries may be obtained via FTP (networking is not required
for X11R5).
I have just such a setup, and it works great. MST's version of UNIX
doesn't
have too much in the way of bug fixes relative to the AT&T code, but
the
only thing I've really had problems with was a couple of bugs in csh.
Now
that I have tcsh working (built without so much as a warning!) I'll
never go
back :-)

Micro Station Technology
1140 Kentwood Avenue
Cupertine, CA 95014
Tel: 408-253-3898
Fax: 408-253-7853

I am not affiliated with MST except as a customer.

>
>John W. Linville
>
--
+-------------------+----------------------+---------------------------------+
| JERRY J. SHEKHEL | POLYGEN CORPORATION | When I was young, I had to
walk |
| Drummers do it... | Waltham, MA USA | to school and back every day
-- |
| ... In rhythm! | (617) 890-2175 | 20 miles, uphill both ways. |
+-------------------+----------------------+---------------------------------+
| ...! [ princeton mit-eddie bu sunne ] !polygen!jerry |
| je...@polygen.com |
+----------------------------------------------------------------------------+

peter da silva's profile photo

peter da silva

unread,
Feb 6, 1992, 11:02:47 AM2/6/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum)
writes:
> QNX is a microkernel
> based system, and someone just told me the installed base is
200,000 systems.

Oh yes, while I'm on the subject... there are over 3 million Amigas
out there,
which means that there are more of them than any UNIX vendor has
shipped, and
probably more than all UNIX systems combined.


peter da silva's profile photo

peter da silva

unread,
Feb 6, 1992, 11:00:22 AM2/6/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <1992Feb5....@wpi.WPI.EDU> ent...@wintermute.WPI.EDU
(Lawrence C. Foard) writes:
> Actually my main problem with OS theorists is that they have never
tested
> there ideas!

I beg to differ... there are many microkernel operating systems out
there
for everything from an 8088 (QNX) up to large research systems.

> None of these ideas (with a partial exception for MACH) has ever
> seen the light of day. 32 bit home computers have been available
for almost a
> decade and Linus was the first person to ever write a working OS
for them
> that can be used without paying AT&T $100,000.

I must have been imagining AmigaOS, then. I've been using a figment
of my
imagination for the past 6 years.

AmigaOS is a microkernel message-passing design, with better response
time
and performance than any other readily available PC operating system:
including
MINIX, OS/2, Windows, MacOS, Linux, UNIX, and *certainly* MS-DOS.

The microkernel design has proven invaluable. Things like new file
systems
that are normally available only from the vendor are hobbyist
products on
the Amiga. Device drivers are simply shared libraries and tasks with
specific
entry points and message ports. So are file systems, the window
system, and
so on. It's a WONDERFUL design, and validates everything that people
have
been saying about microkernels. Yes, it takes more work to get them
off the
ground than a coroutine based macrokernel like UNIX, but the
versatility
pays you back many times over.

I really wish Andy would do a new MINIX based on what has been
learned since
the first release. The factoring of responsibilities in MINIX is
fairly poor,
but the basic concept is good.

> The general consensus that Micro kernels is the way to go means
nothing when
> a real application has never even run on one.

I'm dreaming again. I sure throught Deluxe Paint, Sculpt 3d, Photon
Paint,
Manx C, Manx SDB, Perfect Sound, Videoscape 3d, and the other
programs I
bought for my Amiga were "real". I'll have to send the damn things
back now,
I guess.

The availability of Linux is great. I'm delighted it exists. I'm sure
that
the macrokernel design is one reason it has been implemented so fast,
and this
is a valid reason to use macrokernels. BUT... this doesn't mean that
microkernels are inherently slow, or simply research toys.


Tim W Smith's profile photo

Tim W Smith

unread,
Feb 6, 1992, 8:30:59 PM2/6/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
Andy Tanenbaum (a...@cs.vu.nl) writes:
> 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.

On the 386, you could run the drivers in V86 mode, which sort of
counts
as user mode and allows access to I/O registers if the kernel sets
things
up to allow this.

Tim Smith

Tim W Smith's profile photo

Tim W Smith

unread,
Feb 6, 1992, 9:09:23 PM2/6/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
> Actually my main problem with OS theorists is that they have never
tested
> there ideas! None of these ideas (with a partial exception for
MACH) has ever
> seen the light of day. 32 bit home computers have been available
for almost a
> decade and Linus was the first person to ever write a working OS
for them
> that can be used without paying AT&T $100,000. A piece of software
in hand is

How about Netware 386 from Novell? It seems to work.

Tim Smith

Richard Tobin's profile photo

Richard Tobin

unread,
Feb 7, 1992, 9:58:22 AM2/7/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum)
writes:
>If you just want to USE the system, instead of hacking on its
>internals, you don't need source code.

Unfortunately hacking on the internals is just what many of us want
the system for... You'll be rid of most of us when BSD-detox or GNU
comes out, which should happen in the next few months (yeah, right).


bert thompson's profile photo

bert thompson

unread,
Feb 8, 1992, 2:43:54 AM2/8/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
feu...@netcom.COM (David Feustel) writes:

>That's ok. Einstein got lousy grades in math and physics.

no he didn't.

bert.

Rogier Wolff's profile photo

Rogier Wolff

unread,
Feb 8, 1992, 4:13:39 AM2/8/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
a...@cs.vu.nl (Andy Tanenbaum) writes:

>In article <1992Feb5....@wpi.WPI.EDU> ent...@wintermute.WPI.EDU
(Lawrence C. Foard) writes:
>>Actually my main problem with OS theorists is that they have never
tested
>>there ideas!
>I'm mortally insulted. I AM NOT A THEORIST. Ask anybody who was at
our
>department meeting yesterday (in joke).

>Actually, these ideas have been very well tested in practice.

The problem is that to really do an unbiased test you would need two
*identical* teams, and ask them to make two OS's, for the same
destination machine, one using a microkernel architecture, and the
other
using the monolithic approach. This is in practice not feasable and
the
publications on the subject can only shout: "look: I've got a good
performance using a microkernel", "we've got very good performance
using
a monolithic aproach" or "it only took us X months to implement this
OS"

If people did benchmark their OS's they wrote the OS for one
architecture,
and adapted it to test the other. This adaptation will naturally
degrade
performance, and show that the designers were right in the first
place.

Anyway, anybody have an opinion about the fact that code for printf
is included three times in the Minix OS when it runs (once in the
kernel, MM and FS)

Roger

--
If the opposite of "pro" is "con", what is the opposite of
"progress"?
(stolen from kadokev@iitvax ==? tech...@iitmax.iit.edu)
EMail: wo...@duteca.et.tudelft.nl ** Tel +31-15-783644 or
+31-15-142371

David Megginson's profile photo

David Megginson

unread,
Feb 8, 1992, 10:04:31 AM2/8/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <1992Feb08.0...@donau.et.tudelft.nl> 
wo...@neuron.et.tudelft.nl (Rogier Wolff) writes:

>Anyway, anybody have an opinion about the fact that code for printf
>is included three times in the Minix OS when it runs (once in the
>kernel, MM and FS)

Back in the yore days, this might have been a problem. I remember
when
every program, even wordprocessors, had to be written in assembler to
squeeze them down to the smallest size possible for a 64K system. One
of the reasons WordPerfect is such a mess today is that it was
written
in assembler instead of C.

Now, even the small systems which Minix runs have at least 640K, so a
few wasted bytes are not so much of a problem.

Why not write Linux in 80386 assembler? It would be smaller and even
faster. And don't forget to code inline as much as possible, to avoid
the crippling overhead of function calls. And leave out comments,
because they waste disk space.


Kevin Brown's profile photo

Kevin Brown

unread,
Feb 9, 1992, 4:02:24 AM2/9/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <1992Feb6.0...@wpi.WPI.EDU> ent...@wintermute.WPI.EDU
(Lawrence C. Foard) writes:
>In article <1992Feb3.0...@menudo.uh.edu> ke...@taronga.taronga.com
(Kevin Brown) writes:
>>Dr. Tanenbaum claims that the microkernel architecture is the way
to go.
>>He has a great deal more experience with operating systems than I
have.
>>It's an understatement that it's likely that there's some substance
to
>>his statement. :-)
>
>I tend to prefer seeing for myself rather than accepting "expert"
opinion.
>Microkernels are nice asthetically, but there are times when
practical issues
>must also be considered :)

I agree. This is why I qualified my statement the way I did. :-)

Having seen both monolithic and microkernel architectures running,
though,
I tend to agree that microkernels are generally the way to go, all
other
things being equal.

But as you say, all things are not always equal. That's when it
becomes
a judgement call. Which is better? Depends on what you're trying to
do.

>I've been told by people who have used both that Linux is
significantly
>faster. There are certainly several factors involved (certainly
using 32 bits
>helps alot), but the multithreading also makes for much lower
overhead.

Yup. I think that if Minix were arranged so that it had message
queueing
and a true multithreaded filesystem, it might be comparable to a
monolithic
kernel in terms of speed. It's hard for me to say, though. I haven't
played around much with multithreaded filesystems, so I don't know
how
hard it is to make them work efficiently. I'd think, though, that it
would
depend enormously on how efficient your device drivers were, and how
much
data copying you'd have to do (ideally, you'd pass references to the
data
buffers around and do your actual data transfers directly to the
user's
buffer).

>>However, as a *multiuser* operating system, i.e. an operating
system designed


>>to efficiently meet the needs of multiple users simultaneously
while also
>>performing batch operations, Minix is lacking, as far as I'm
concerned.
>>The main reason, of course, is the single-threaded file system
(hereafter,
>>STFS). Now, Dr. Tanenbaum may feel that a multi-threaded file
system
>>(hereafter, MTFS) is merely a performance hack.
>
>I think this is a very valid problem. There are two ways a single
threaded FS
>could work and both have substantial problems. If the FS blocks
while waiting
>for I/O it would be completely unusable for "real" work. Imagine
several users
>accessing a database, if the FS blocks for I/O they will have to
wait
>eventhough the data they are looking for is already in the cache. If
it is
>designed to be non blocking then it is even more complicated than a
>multithreaded FS and will have more overhead. I hope it is atleast
the second

I haven't gone deeply into the source code of the Minix file system,
but
the impression I get from my perusing of it is that it blocks on disk
I/O
but not on terminal I/O, the idea being that disk I/O requests will
almost
always be satisfied relatively soon after they are made, whereas
terminal
I/O requests can take an indefinite amount of time to satisfy.

But it seems to me that if you're going to implement the mechanism to
handle
I/O where the file system doesn't block waiting for it, why not use
that
mechanism universally???

>>However much Minix may be lacking from my standpoint, it is
nevertheless
>>a very useful and welcome enhancement to my system. In spite of the
>>impression that I may have given everyone in my last posting, there
will
>>always be a soft spot in my heart for it, if only because it's the
first
>>decent operating system I've had on my system that I've had source
to.
>>I don't have to tell you people how incredibly useful it is to have
source.
>>You already know.
>
>I will agree here, Minix is infinitly better than Messy-Loss :)

Which is why I try to avoid using MS-DOS whenever possible. I'll bet
a
lot of us Minixers do the same. :-)

>>Given the reasons Linus wrote Linux, I think it's hard for anyone
to fault
>>him for writing it the way he did. And he was extremely nice in
making
>>his code freely available to the rest of the world. It's not
something he
>>had to do. In my book, that makes him almost beyond reproach.
>
>I think more effort has been put into making practical use of Linux
possible.
>An educational OS is nice, but there is a world outside of colleges
that
>is suffering from the lack of cheap and useful OS's, I've been stuck
doing
>most consulting work in Messy Loss because customers don't want to
fork out
>$1000 for UNIX.

Even students can make good use of something like Linux. I have 8
megabytes
of RAM on my machine, and 410 meg of harddrive space. Yet I can
barely
run SBProlog on my system, even though my system is considerably more
macho
than most. If I had demand paging on my system, this wouldn't be a
problem,
but the only patches I have for demand paging seem not to work very
well.
Once Linux becomes more stable (and gets support for Seagate ST-02
SCSI),
I'll snag the sources and check it out. Since I already own Minix, I
can
legally transport *everything* over to it, and since both share the
same
filesystem layout, I can do the transporting with a minimum of
hassle.

>>Dr. Tanenbaum didn't make Minix free. His goals were different.
Minix
>>is a teaching aid above all else (unless Dr. Tanenbaum has changed
his
>>views about Minix :-). That means that he must be concerned with
the
>>most efficient way to get Minix to the student population. At the
time
>>Minix was released, Prentice-Hall was a good solution, and has been
for
>>some time. However, I must wonder whether or not this is still the
case.
>>Dr. Tanenbaum: do you still feel that free distribution of Minix
via the
>>net is not the best way to distribute Minix?
>
>I would guess that Prentice-Hall would have some objections :)

No doubt. :-(


--
Kevin Brown Disclaimer: huh?
ke...@taronga.com ke...@nuchat.sccsi.com

peter da silva's profile photo

peter da silva

unread,
Feb 9, 1992, 10:10:00 PM2/9/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <1992Feb08.0...@donau.et.tudelft.nl> 
wo...@neuron.et.tudelft.nl (Rogier Wolff) writes:
> The problem is that to really do an unbiased test you would need
two
> *identical* teams, and ask them to make two OS's [...]

No, you don't. I don't think there's any question that a macrokernel
is
very easy to get decent performance out of. Where the microkernel
design
has a major advantage is in flexibility. Adding stuff to a
macrokernel
is fairly complex and quickly becomes pretty gross. Look at BSD or
System V
for examples. Adding stuff to a well designed microkernel is VERY
easy.

Sometimes you don't want to compare oranges and oranges. Sometimes
you want
to compare concentrated orange juice with fresh-squeezed.
Fresh-squeezed
takes longer, but it's worth it.

Plus, with a microkernel you can get much better context switching
between
microtasks than macro processes. So you can do stuff in separate
processes
that would be out of the question in a macrokernel, and avoid
nonsense like
the myriad inconsistencies in NFS.

> anyone have an opinion about why the code for printf


> is included three times in the Minix OS when it runs (once in the
> kernel, MM and FS)

Anyone have an opinion why the code for printf is included only once
in
AmigaOS (even though the AmigaOS 2.04 "kernel" is actually a dozen or
more separate processes)?

Minix is a poor technology demonstrator for microkernels. Which is
OK, since
it wasn't supposed to be one.


Dave Smythe's profile photo

Dave Smythe

unread,
Feb 10, 1992, 2:08:22 AM2/10/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <1992Feb5....@wpi.WPI.EDU> ent...@wintermute.WPI.EDU
(Lawrence C. Foard) writes:
>Actually my main problem with OS theorists is that they have never
tested
>there ideas! None of these ideas (with a partial exception for MACH)
has ever
>seen the light of day.

David Cheriton (Prof. at Stanford, and author of the V system) said
something
similar to this in a class in distributed systems. Paraphrased:

"There are two kinds of researchers: those that have implemented
something and those that have not. The latter will tell you that
there are 142 ways of doing things and that there isn't consensus
on which is best. The former will simply tell you that 141 of
them don't work."

He really rips on the OSI-philes as well, for a similar reason. The
Internet
protocols are adapted only after having been in use for a period of
time,
preventing things from getting standardized that will never be
implementable
in a reasonable fashion. OSI adherents, on the other hand, seem
intent on
standardizing everything possible, including "escapes" from the
standard,
before a reasonable reference implementation exists. Consequently,
you see
obsolete ideas immortalized, such as sub-byte-level data field
packing,
which makes good performance difficult when your computer is drinking
from
a 10+ Gbs fire-hose :-).

Just my $.02

D

--
=====================================================================
===
Dave Smythe N6XLP dsm...@netcom.com (also dsm...@cs.stanford.edu)

Bill Mitchell's profile photo

Bill Mitchell

unread,
Feb 10, 1992, 10:03:51 AM2/10/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
in comp.os.minix, dsm...@netcom.COM (Dave Smythe) said:


>In article <1992Feb5....@wpi.WPI.EDU> ent...@wintermute.WPI.EDU
(Lawrence C. Foard) writes:
>
>David Cheriton (Prof. at Stanford, and author of the V system) said
something
>similar to this in a class in distributed systems. Paraphrased:
>
> "There are two kinds of researchers: those that have implemented
> something and those that have not. The latter will tell you that
> there are 142 ways of doing things and that there isn't consensus
> on which is best. The former will simply tell you that 141 of
> them don't work."
>

Yeah, but what's the odds on two who have implemented something
differently
agreeing on which 141 don't work?

--
mitc...@mdd.comm.mot.com (Bill Mitchell)

Christopher Stuart's profile photo

Christopher Stuart

unread,
Feb 11, 1992, 8:52:57 AM2/11/92


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
Article 18297 of comp.os.minix:
Path: icdoc!uknet!mcsun!uunet!cis.ohio-state.edu!rutgers!
news-server.csri.toronto.edu!utgpu!news-server.ecf!epas!meggin
From: meg...@epas.utoronto.ca (David Megginson)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Message-ID: <1992Feb8.1...@epas.toronto.edu>
Date: 8 Feb 92 15:04:31 GMT
References: <1992Feb5....@wpi.WPI.EDU> <12...@star.cs.vu.nl> <
1992Feb08.0...@donau.et.tudelft.nl>
Sender: ne...@epas.toronto.edu (USENET)
Organization: University of Toronto - EPAS
Lines: 28
Nntp-Posting-Host: epas.utoronto.ca








David




--
/
*----------------------------------------------------------------------------*
/
/* Christopher Stuart: c...@doc.ic.ac.uk */
/* Dept. Computing, Imperial College, London. */
/
*----------------------------------------------------------------------------*
/

Omniscientist's profile photo

Omniscientist

unread,
Jan 10, 2005, 9:02:10 AM1/10/05


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
Well, sorry Ken...but it looks like microkernels didn't last as long
as
you thought. I'm on Linux right now...and minix isn't anywhere in
sight..

the...@gmail.com's profile photo

the...@gmail.com

unread,
Jan 11, 2005, 4:34:47 AM1/11/05


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
i'm glad I read this.

Kevin Brown wrote:
> In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum)
writes:
> >
> >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 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

Gary's profile photo

Gary

unread,
Jan 12, 2005, 9:04:45 PM1/12/05


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to

On 10 Jan 2005, Omniscientist frothed:

> Well, sorry Ken...but it looks like microkernels didn't last as
long as
> you thought.

Is there a particular reason that you're trolling this group by
answering
13 year old posts by Ken Thompson?

By the way, have you taken a look at Mac OS X lately?
http://developer.apple.com/darwin/history.html
http://developer.apple.com/documentation/Porting/Conceptual/
PortingUnix/additionalfeatures/chapter_10_section_8.html

> I'm on Linux right now...and minix isn't anywhere in sight..

No, you won't see Oracle 10 ported to Minix any time soon, and for
good
reason; see quote below.

-Gary

http://www.prenhall.com/bookbind/pubbooks/tanenbaum/chapter0/custom4/
deluxe-content.html

How would you compare MINIX and Linux?

From the very beginning, MINIX has been designed as a system for
teaching
students and others about operating systems. An overriding concern
has
always been to keep it simple enough for people to understand. In
particular, it is still simple enough that the complete core of the
source
code is listed in the book and can be understood by a student in a
one
semester course. Linux was designed as a production system and is
correspondingly much less suited to learning about operating systems.

chandan's profile photo

chandan

unread,
Jan 14, 2005, 6:11:02 AM1/14/05


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
hi,
im new to this forum. but i can say that there is not a single
operating system which had been designed for students except minix.
ofcourse linux is great in its own terms. but doesn't u think that
minix is well suited for distributed operating system concept.i liked
microkernel concept. i certainly say that minix is student's os.
linux, too, was not great initially but the modification provided by
different groups and organization changed it into a major force. i
know that minix is older than linux but former is not popular. reason
is itself cited in one of A. Tanen. article. (want to leave this os
for
students).

Adrien Plisson's profile photo

Adrien Plisson

unread,
Jan 16, 2005, 4:43:24 AM1/16/05


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
Gary wrote:
> Is there a particular reason that you're trolling this group by
answering
> 13 year old posts by Ken Thompson?

i do have a question: why do i see a lot of greetings post for
thorvald
on this newsgroup lately ? are these "10 years old posts revived by
some
kind of bug" ? do people confuse minix and linux ?

thanks

--
rien

Adrien Plisson's profile photo

Adrien Plisson

unread,
Jan 16, 2005, 4:49:47 AM1/16/05


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to


well, i didn't read the post by Michael Black when i posted this. Now
i
understand, sorry for disturbing...

--
rien

Tux Wonder-Dog's profile photo

Tux Wonder-Dog

unread,
Jan 20, 2005, 6:50:12 AM1/20/05


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
chandan wrote:



Actually, there's Switzer's Tunix, a more rigorously
microkernel-based
teaching operating system than Minix - because practically
everything's a
server in Tunix, versus not that many in Minix. Switzer wrote his
book and
OS for students.

And there is Wirth's Oberon, just to stir the pot a bit. Wirth wrote
his
experimental OS plus language for students.

And Per Brinch Hansen's Solo and associated Concurrent Pascal OSes,
largely
written for students as well.

It seems to be quite wide-spread.

One of the OSes that _wasn't_ written for students, surprise,
surprise, was
Unix. It was a production system that got studied - read the Lions
Book/s.

Having said that, if it hadn't been for the work of Andy Tanenbaum in
writing his book and Minix, the world would've missed out on Linux,
since
it inspired Linus Torvalds to go one better; and I for one wouldn't
have
learned as much about Operating Systems as I've managed to.

So, thanks to Andy Tanenbaum; and also thanks to Linus Torvalds. And,
did I
forget to mention, thank you to the entire BSD team through the
years, etc?

Wesley Parish
--
"Good, late in to more rewarding
well."  "Well, you tonight.  And I was
lookintelligent woman of Ming
home.  I trust you with a tender silence."  I
get a word into my hands, a different and unbelike, probably - 'she
fortunate fat woman', wrong word.  I think to me, I justupid.
Let not emacs meta-X dissociate-press write your romantic
dialogs...!!!

chandan's profile photo

chandan

unread,
Jan 24, 2005, 3:04:47 AM1/24/05


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
thanks tux. i hadn't any idea about these OSes. thanks again

burt's profile photo

burt

unread,
Jan 25, 2005, 1:36:49 PM1/25/05


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
Me too!

Moses's profile photo

Moses

unread,
May 29, 2011, 11:38:31 PM5/29/11


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
What a great thread!

Moses's profile photo

Moses

unread,
May 29, 2011, 11:42:16 PM5/29/11


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
me 3 :DDD
Message has been deleted
derrick....@gmail.com's profile photo

derrick....@gmail.com

unread,
Mar 13, 2012, 8:59:27 AM3/13/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
This thread is impressive. The idea that I can read old USENET posts
is absolutely amazing. The idea I can reply to them is even cooler.
First of all, Yes, Tanenbaum was wrong, but the discussion here will
last far longer than LINUX will.

Second of all, for the first internet "flame war", this was likely
the most mild flame war I've ever seen. If people were "Flaming",
they were certainly more cordial!

As an aside, I wonder what happens when I post here. Does it only
update to Google Groups, or am I actually posting on the USENET? (I'm
pretty sure it's the latter, because Groups should allow me to post
to the USENET proper, but I'm not sure).


max...@googlemail.com's profile photo

max...@googlemail.com

unread,
Mar 15, 2012, 7:19:33 AM3/15/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
Yes this is a legendary thread!
Tonton Th's profile photo

Tonton Th

unread,
Mar 20, 2012, 6:41:32 AM3/20/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
On 03/13/2012 01:59 PM, derrick....@gmail.com wrote:

>
> As an aside, I wonder what happens when I post here.
> Does it only update to Google Groups, or am I actually
> posting on the USENET? (I'm pretty sure it's the latter,
> because Groups should allow me to post to the USENET proper,
> but I'm not sure).

Welcome in the good old real Usenet.

--

Nous vivons dans un monde etrange/
http://foo.bar.quux.over-blog.com/
Srinivas Nayak's profile photo

Srinivas Nayak

unread,
Jun 16, 2012, 7:28:29 AM6/16/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
One thing I heard is, linux 2.6 kernel doesn't support many old
hardwares.
What is that exactly?
Is it because some device drivers removed because of bulkiness of
2.6?
tth...@panvistamedia.com's profile photo

tth...@panvistamedia.com

unread,
Jun 29, 2012, 5:57:33 PM6/29/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
On Tuesday, March 20, 2012 6:41:32 AM UTC-4, Tonton Th wrote:
> On 03/13/2012 01:59 PM, derrick....@gxxxx.com wrote:
>
> >
> > As an aside, I wonder what happens when I post here.
> > Does it only update to Google Groups, or am I actually
> > posting on the USENET? (I'm pretty sure it's the latter,
> > because Groups should allow me to post to the USENET proper,
> > but I'm not sure).
>
> Welcome in the good old real Usenet.

I thought Google Groups quickly fixed this mis-feature?

But with respect to the topic of the thread:
"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."

How things change. As far as Minix v3 is concerned, "all the world's
an x86"; downloads don't even bother naming the single supported
platform: http://www.minix3.org/download/index.html

Maybe it will eventually be ported to ARM. But portability in general
is, sadly, no longer a goal for the project.

mr.fi...@gmail.com's profile photo

mr.fi...@gmail.com

unread,
Sep 20, 2012, 9:07:18 PM9/20/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
Em quarta-feira, 29 de janeiro de 1992 11h23min33s UTC-2, ast
escreveu:
> 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.
>

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

Yeah, this is the famous and epic discussion between Linus Torvalds
and Andrew S. Tanembaum about Linux kernel architecture and how
Tanembaum thinks that monolithic kernels are inferior to
microkernels.
mkam...@tvz.hr's profile photo

mkam...@tvz.hr

unread,
Sep 28, 2012, 9:45:52 AM9/28/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
Dana srijeda, 29. sijecnja 1992. 14:23:33 UTC+1, korisnik ast napisao
je:

Wow,wish that either Linus or Tannenbaum would be my teachers...If
any of you two ever start to work for the Technical Polytechnic of
Zagreb I will be very happy.
nimeto...@gmail.com's profile photo

nimeto...@gmail.com

unread,
Oct 9, 2012, 2:57:07 PM10/9/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
This shoulda been locked.
Martijn van Buul's profile photo

Martijn van Buul

unread,
Oct 10, 2012, 8:07:26 AM10/10/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
* nimeto...@gmail.com:
> This shoulda been locked.

This isn't a forum.

--
Martijn van Buul - pi...@dohd.org
delro...@gmail.com's profile photo

delro...@gmail.com

unread,
Oct 22, 2012, 8:35:08 PM10/22/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to Martijn van Buul
Maybe it is a forum. If you read the URL, it has the word forum in
it:
https://groups.google.com/forum/#!topic/xxxxxxxxx

Martijn van Buul's profile photo

Martijn van Buul

unread,
Oct 23, 2012, 2:51:48 AM10/23/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
* delro...@gmail.com:
> Maybe it is a forum.

Maybe I'm a zebra. That, or maybe you have no clue what you're
talking about.

> If you read the URL, it has the word forum in it:
> https://groups.google.com/forum/#!topic/xxxxxxxxx

I see it's obviously the latter explanation.

Edward A. Falk's profile photo

Edward A. Falk

unread,
Oct 23, 2012, 8:37:48 PM10/23/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
In article <65c6b71f-9ed9-49d9...@googlegroups.com>,
<delro...@gmail.com> wrote:
>Maybe it is a forum. If you read the URL, it has the word forum in
it:
>https://groups.google.com/forum/#!topic/xxxxxxxxx

It's not. It's a Usenet newsgroup. Google chooses to present it
to you as if it were a forum, but it's not.

--
-Ed Falk, fa...@despams.r.us.com
http://thespamdiaries.blogspot.com/
Asad Dhamani's profile photo

Asad Dhamani

unread,
Nov 18, 2012, 3:33:29 PM11/18/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to

Welcome to 2012! 20 years, I have my own Linux distro! :D The future
is now a thing of the past! Feels so great seeing so old threads!
amyas...@gmail.com's profile photo

amyas...@gmail.com

unread,
Nov 25, 2012, 6:30:50 AM11/25/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
So I can post a reply right now for this historical flame war?? And
Google will actually index my name along with ast and Linus? Wow :D
luke...@gmail.com's profile photo

luke...@gmail.com

unread,
Nov 26, 2012, 2:34:02 PM11/26/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to

El miercoles, 29 de enero de 1992 09:20:50 UTC-5, David Megginson
escribio:
> 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.
> #################################################################



El miercoles, 29 de enero de 1992 09:20:50 UTC-5, David Megginson
escribio:
> 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.
> #################################################################

ast, time proved you were wrong, yet, you are the best dinosaur I
ever know,
greetings from cuba.

Skywalker.
Martijn van Buul's profile photo

Martijn van Buul

unread,
Nov 27, 2012, 5:33:38 AM11/27/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
* luke...@gmail.com:
> ast, time proved you were right

There, I fixed that for you

caront...@hotmail.com's profile photo

caront...@hotmail.com

unread,
Dec 30, 2012, 5:32:31 PM12/30/12


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
El miercoles, 29 de enero de 1992 06:23:33 UTC-7, ast escribio:

sk...@ns.sympatico.ca's profile photo

sk...@ns.sympatico.ca

unread,
Feb 1, 2013, 6:14:26 AM2/1/13


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to Martijn van Buul
On Wednesday, October 10, 2012 9:07:26 AM UTC-3, Martijn van Buul
wrote:

> > This shoulda been locked.
>
>
>
> This isn't a forum.
>

it's usenet, afaik a non-moderated newsgroup can't really have locked
threads, violates the rules.
Martijn van Buul's profile photo

Martijn van Buul

unread,
Feb 1, 2013, 6:53:06 AM2/1/13


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
* sk...@ns.sympatico.ca:
> it's usenet, afaik a non-moderated newsgroup can't really have
locked
> threads, violates the rules.

It's not a question of "rules", it's a question of not being capable
of.

The rules, if any, state you shouldn't post articles with a line
length of
more than 80 characters ;)

derrick....@gmail.com's profile photo

derrick....@gmail.com

unread,
Apr 17, 2013, 12:31:22 PM4/17/13


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
I feel like I'm a part of history.
I wasn't even born when this thread opened...
syn4...@gmail.com's profile photo

syn4...@gmail.com

unread,
Apr 25, 2013, 1:18:37 PM4/25/13


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
Me too. :D
usama...@gmail.com's profile photo

usama...@gmail.com

unread,
Apr 28, 2013, 4:57:13 AM4/28/13


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
I am very surprised to read this thread.
Was there Google and Google groups in 1992.....?
Antoine Leca's profile photo

Antoine Leca

unread,
Apr 29, 2013, 6:58:44 AM4/29/13


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to
usama...@gmail.com wrote:
> I am very surprised to read this thread.
> Was there Google and Google groups in 1992.....?

Not exactly; there was known as Usenet then; and Google Groups just
bought the Usenet archives (through DejaNews) in 2001 IIRC.
http://www.google.com/googlegroups/archive_announce_20.html

And since Usenet does allow threads to last and last, and since Pr
Tanenbaum did not put an "Expire" header on his post, Google Groups
offer you the opportunity to post to that thread. Even posts
completely
off-topic to that thread (or to this group comp.os.minix as well.)


Antoine
Michael Black's profile photo

Michael Black

unread,
Apr 30, 2013, 3:35:44 PM4/30/13


Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the
view member email addresses permission to view the original message
to

No.

Google moved to a new interface, and allowed replies to messages
older
than 30 days. 30 days wsa the way from the beginning, and really is
proper for old messages. They had it that way from when they took
over
the dejanews archive. A previous time they changed the interface, and
put
the bug in, but after complaints it was fixed. I have no idea if they
removed the vandalism to old threads, but that time back some years
did
cause stupid responses just like now, the idiots attracted to a
thread
that google itself has pointed out as "historic", at one point they
put up
a timeline of usenet and pointed to specific posts, including this
one.

I'm tired of fighting with google, so I've never bothered complaining
this
recent tiem. Their current interface may be fine for a web-based
newsgroup, but it's not right at all for Usenet. It doesn't even show
dates, or even where the message is posted to (so nobody knows about
cross-posting.

There is no reason to reply to old messages. The conversation has
moved
on, if someone saved the message at the time and gets around to it
later,
that's different from someone replhing through google years later.
The
posters just drop the thread into the newsgroup, they are oblivious
to
where it's going. They often don't even quote. Suddenly a mystery
message appears in the newsgroup without context, people reply
without
even wondering where the rest of the thread is.

The replies usually offer nothing new, they ignore that the thread
back 20
years ago had plenty of answers, likely sufficient. The replies
ignore
the fact that whoever posted back when may no longer be reading the
newsgroup. Indeed, when some idiot replies to an old message that was
offereing something for sale, the original poster may not have been
there
except to post his ad.

All of these replies are from idiots who think it's "cool" to reply
to an
old thread, like they were actually around 20 years ago. They haven't
even added anything useful, just a bunch of "me toos".

The only reason I've not bothered replying to condemn these idiots is
because this is a historical thread, and I didn't want to add my
vandalism. But since you've just given approval to it, I had to speak
out. Don't ecnourage the idiots.

As an aside, deajnews only started in 1995 or 96. Their archive is
what
google bought. But then google tracked down older archives of a more
limited nature, putting them together, which is why there is now an
incomplete archive going back to the start of Usenet, 1979. It's
those
other archives that kept this thread, and the vandalism is because of
google, and because of the idiots who reply.

Michael

It is loading more messages.

0 new messages

Search
Clear search
Close search
Google apps
Main menu