Re: LINUX is obsolete Linux Inside
[Prev][Next][Index][Thread]

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 (ast@cs.vu.nl)