Re: LINUX is obsolete Linux Inside

Re: LINUX is obsolete

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 (