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

Re: LINUX is obsolete

 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