This is the famous thread, preserved in all its glory. I can't remember where I picked it up from, but it's not originally mine.
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: LINUX is obsolete
Date: 29 Jan 92 12:12:50 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam
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 (ast@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.
0, unseen,,
*** EOOH ***
From: meggin@epas.utoronto.ca (David Megginson)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 29 Jan 92 14:12:12 GMT
Organization: University of Toronto - EPAS
Nntp-Posting-Host: epas.utoronto.ca
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 meggin@epas.utoronto.ca
Centre for Medieval Studies david@doe.utoronto.ca
University of Toronto 39 Queen's Park Cr. E.
#################################################################
0, unseen,,
*** EOOH ***
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 29 Jan 92 18:03:01 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam
In article <1992Jan29.141212.29636@epas.toronto.edu> meggin@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 (ast@cs.vu.nl)
0, unseen,,
*** EOOH ***
From: gt0178a@prism.gatech.EDU (Jim Burns)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 30 Jan 92 03:39:48 GMT
Organization: Georgia Institute of Technology
in article <12605@star.cs.vu.nl>, ast@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: gt0178a@prism.gatech.edu
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a
0, unseen,,
*** EOOH ***
From: joe@jshark.rn.com
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Summary: Is this for real?
Date: 31 Jan 92 12:55:21 GMT
Organization: a blip in entropy
In article <12605@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>In article <1992Jan29.141212.29636@epas.toronto.edu> meggin@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 (ast@cs.vu.nl)
joe.
--
joe@jshark.rn.com
uunet!nstar!jshark!joe
0, unseen,,
*** EOOH ***
From: drew@anchor.cs.colorado.edu (Drew Eckhardt)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 2 Feb 92 12:17:44 GMT
Organization: University of Colorado, Boulder
Nntp-Posting-Host: anchor.cs.colorado.edu
In article <12605@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>In article <1992Jan29.141212.29636@epas.toronto.edu> meggin@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 (ast@cs.vu.nl)
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.
0, unseen,,
*** EOOH ***
From: jonathan@ukmug.uk.mugnet.org (Jonathan Allen)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 3 Feb 92 07:43:00 GMT
Organization: MUGNET UK Backbone (UKMUG)
In article <12605@star.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) wrote:
> In article <1992Jan29.141212.29636@epas.toronto.edu> meggin@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
0, unseen,,
*** EOOH ***
From: ts@cup.portal.com (Tim W Smith)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 7 Feb 92 01:30:59 GMT
Organization: The Portal System (TM)
Andy Tanenbaum (ast@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
0, unseen,,
*** EOOH ***
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 29 Jan 92 23:14:26 GMT
Organization: University of Helsinki
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 <12595@star.cs.vu.nl> ast@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 :)
0, unseen,,
*** EOOH ***
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 30 Jan 92 13:44:34 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam
In article <1992Jan29.231426.20469@klaava.Helsinki.FI> torvalds@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 (ast@cs.vu.nl)
0, unseen,,
*** EOOH ***
From: feustel@netcom.COM (David Feustel)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 30 Jan 92 18:57:28 GMT
Organization: DAFCO - An OS/2 Oasis
ast@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
feustel@netcom.com
=== NBC News: GE's Advertising And Public Relations Agency ===
0, unseen,,
*** EOOH ***
From: meggin@epas.utoronto.ca (David Megginson)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 30 Jan 92 19:58:50 GMT
Organization: University of Toronto - EPAS
Nntp-Posting-Host: epas.utoronto.ca
In article <1992Jan30.185728.26477feustel@netcom.COM> feustel@netcom.COM (David Feustel) writes:
>ast@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... ;-)
David
#################################################################
David Megginson meggin@epas.utoronto.ca
Centre for Medieval Studies david@doe.utoronto.ca
University of Toronto 39 Queen's Park Cr. E.
#################################################################
0, unseen,,
*** EOOH ***
From: feustel@netcom.COM (David Feustel)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 30 Jan 92 23:15:05 GMT
Organization: DAFCO - An OS/2 Oasis
meggin@epas.utoronto.ca (David Megginson) writes:
>In article <1992Jan30.185728.26477feustel@netcom.COM> feustel@netcom.COM (David Feustel) writes:
>>ast@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.
--
David Feustel N9MYI, 1930 Curdes Ave, Fort Wayne, IN 46805. (219)482-9631
feustel@netcom.com
=== NBC News: GE's Advertising And Public Relations Agency ===
0, unseen,,
*** EOOH ***
From: pete@ohm.york.ac.uk (-Pete French.)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 31 Jan 92 09:49:37 GMT
Organization: Electronics Department, University of York, UK
in article <1992Jan30.195850.7023@epas.toronto.edu>, meggin@epas.utoronto.ca (David Megginson) says:
> Nntp-Posting-Host: epas.utoronto.ca
>
> In article <1992Jan30.185728.26477feustel@netcom.COM> feustel@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 /
0, unseen,,
*** EOOH ***
From: peter@ferranti.com (peter da silva)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 3 Feb 92 16:22:32 GMT
Organization: Xenix Support, FICC
In article <1992Jan31.094937.3726@ohm.york.ac.uk> pete@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?"
0, unseen,,
*** EOOH ***
From: kt4@prism.gatech.EDU (Ken Thompson)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 3 Feb 92 23:07:54 GMT
Organization: Georgia Institute of Technology
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:!kt4@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
0, unseen,,
*** EOOH ***
From: kevin@taronga.taronga.com (Kevin Brown)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 4 Feb 92 08:08:42 GMT
Organization: University of Houston
In article <47607@hydra.gatech.EDU> kt4@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:!kt4@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
0, unseen,,
*** EOOH ***
From: rburns@finess.Corp.Sun.COM (Randy Burns)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 30 Jan 92 20:33:07 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: finess.corp.sun.com
In article <12615@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>In article <1992Jan29.231426.20469@klaava.Helsinki.FI> torvalds@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.
0, unseen,,
*** EOOH ***
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 31 Jan 92 10:33:23 GMT
Organization: University of Helsinki
In article <12615@star.cs.vu.nl> ast@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
0, unseen,,
*** EOOH ***
Newsgroups: comp.os.minix
From: kevin@nuchat.sccsi.com (Kevin Brown)
Subject: Re: LINUX is obsolete
Organization: Where???
Date: Fri, 31 Jan 1992 07:43:47 GMT
Sorry, but I just can't resist this thread...:-)
In article <12615@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>In article <1992Jan29.231426.20469@klaava.Helsinki.FI> torvalds@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 (ast@cs.vu.nl)
Kevin Brown
0, unseen,,
*** EOOH ***
Newsgroups: comp.os.minix
From: kevin@taronga.taronga.com (Kevin Brown)
Subject: Re: LINUX is obsolete
Organization: Sorely lacking.
Date: Mon, 3 Feb 1992 05:12:58 GMT
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).
÷³So 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, þò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. 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
0, unseen,,
*** EOOH ***
From: kaufman@eecs.nwu.edu (Michael L. Kaufman)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 3 Feb 92 22:27:48 GMT
Organization: EECS Department, Northwestern University
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 <12615@star.cs.vu.nl> ast@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
0, unseen,,
*** EOOH ***
From: entropy@wintermute.WPI.EDU (Lawrence C. Foard)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 6 Feb 92 09:22:40 GMT
Organization: Worcester Polytechnic Institute
Nntp-Posting-Host: wintermute.wpi.edu
In article <1992Feb3.051258.4153@menudo.uh.edu> kevin@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. \/
0, unseen,,
*** EOOH ***
From: kevin@taronga.com (Kevin Brown)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 9 Feb 92 09:02:24 GMT
Organization: What's that?
In article <1992Feb6.092240.16377@wpi.WPI.EDU> entropy@wintermute.WPI.EDU (Lawrence C. Foard) writes:
>In article <1992Feb3.051258.4153@menudo.uh.edu> kevin@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?
kevin@taronga.com kevin@nuchat.sccsi.com
0, unseen,,
*** EOOH ***
From: julien@incal.inria.fr (Julien Maisonneuve)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 3 Feb 92 17:10:14 GMT
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.
0, unseen,,
*** EOOH ***
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 4 Feb 92 14:46:49 GMT
Reply-To: richard@aiai.UUCP (Richard Tobin)
Organization: AIAI, University of Edinburgh, Scotland
In article <12615@star.cs.vu.nl> ast@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.Tobin@ed.ac.uk
Edinburgh University.
0, unseen,,
*** EOOH ***
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 5 Feb 92 14:48:48 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam
In article <6121@skye.ed.ac.uk> richard@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 (ast@cs.vul.nl)
0, unseen,,
*** EOOH ***
From: linville@garfield.catt.ncsu.edu (John W. Linville)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Summary: Small model compiler limits Coherent as an alternative
Date: 5 Feb 92 17:56:35 GMT
Organization: NCSU CATT Prog
In article <12696@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>In article <6121@skye.ed.ac.uk> richard@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 (ast@cs.vul.nl)
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
0, unseen,,
*** EOOH ***
From: jerry@connection.prospect.com (Jerry Shekhel)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 6 Feb 92 21:28:05 GMT
Organization: Polygen Corporation, Waltham, MA
linville@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 |
| jerry@polygen.com |
+----------------------------------------------------------------------------+
0, unseen,,
*** EOOH ***
From: meggin@epas.utoronto.ca (David Megginson)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 5 Feb 92 20:50:55 GMT
Organization: University of Toronto - EPAS
Nntp-Posting-Host: epas.utoronto.ca
In article <12696@star.cs.vu.nl> ast@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 meggin@epas.utoronto.ca
Centre for Medieval Studies david@doe.utoronto.ca
University of Toronto 39 Queen's Park Cr. E.
#################################################################
0, unseen,,
*** EOOH ***
From: ajt@doc.ic.ac.uk (Tony Travis)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 6 Feb 92 02:17:13 GMT
Organization: Department of Computing, Imperial College, University of London, UK.
ast@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 | Rowett Research Institute,
| Greenburn Road, Bucksburn, Aberdeen,
| AB2 9SB. UK. tel 0224-712751
0, unseen,,
*** EOOH ***
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 7 Feb 92 14:58:22 GMT
Organization: AIAI, University of Edinburgh, Scotland
In article <12696@star.cs.vu.nl> ast@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).
-- Richard
--
Richard Tobin,
AI Applications Institute, R.Tobin@ed.ac.uk
Edinburgh University.
0, unseen,,
*** EOOH ***
From: comm121@unixg.ubc.ca (Louie)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 30 Jan 92 02:55:22 GMT
Organization: University of British Columbia, Vancouver, B.C., Canada
Nntp-Posting-Host: chilko.ucs.ubc.ca
In <12595@star.cs.vu.nl> ast@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
pwu@unixg.ubc.ca
0, unseen,,
*** EOOH ***
New