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

Re: LINUX is obsolete

 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
 
 
 
 
 Newsgroups: comp.os.minix