Re: Minix VS Linux Linux Inside
[Prev][Next][Index][Thread]

Re: Minix VS Linux

 
 kevin@taronga.taronga.com (Kevin Brown) writes:
  
 >It has been brought to my attention that my last posting was exceedingly
 >harsh.  Having reread it, I'm inclined to agree.
  
 Didn't seem so to me - or is everyone else getting much more tactful in
 the 'kinder, gentler' 1990s? 
  
 >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.
 .... lines omitted
 >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).
  
 In fact, Minix has noticeable problems even as a *single-user* system; such
 a user is likely to be developing code in an 'edit - compile - test' cycle,
 and on a multitasking machine compilation can conveniently take place in
 the background using multiple processes.  Given the small amount of memory
 on the early Minix machines, it probably wasn't practical to edit in the
 foreground during a compile; but a low-end XT such as mine can now put the
 ram-disk in expanded memory and have 500KB free after the OS is loaded.
 However, editing during a compile is still totally impractical; the standard
 1.5 scheduler can't cope, and keyboard response time is both long (seconds)
 and variable.  The fix is simple, use Kai-Uwe Bloem's (spelling ?) patch.
 KuB's scheduler algorithm isn't the last word in sophistication, and the code
 change is a small one, yet it is extremely effective.  I don't understand
 why the original scheduler lasted so long.
  
 Broadly speaking, when porting programs to Minix, or writing them from
 scratch, the main problems are not details of kernel implementation but things
 that are simply missing, such as non-blocking reads or SIGHUP.  If a program
 is to be used on the majority of Minix systems, then it must be written for
 the lowest common denominator ie: the standard current release, and this has
 significant limitations.  Only after these are overcome does the lack of
 memory space, or lack of filesystem performance, become important.  (It
 is quite possible that many of these problems will be fixed in 1.6, but
 that still lies in the future.  By the time it arrives, the goalposts will
 have moved again... )
  
 >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.
  
 This may have been drawn from a comment of mine, concerning the recent
 replacement of a dead 286 motherboard with a 386SX; it was part of an
 example of just how fast hardware prices are falling.  The *board* price
 was $140, ie: $90 more than an XT board.  Memory is about the same price
 for both boards, but obviously the system price for the 386 will tend to be
 higher with the use of faster, larger disk drives, more memory, and so on.
  
 In the last year PH has started marketing Minix as a small general-purpose/
 training Unix, but if Minix 2.0 isn't released for another year, I think it
 will become strictly an adjunct to a successful textbook.  It won't run
 enough of the then-available PD code to be useful for anything else, since
 such code will mostly require gcc and megabytes of memory, implying at least
 a 386.  (I'm assuming that the cheapest hardware will still be Intel/ISA bus).
 Linux seems well-placed to pick up on this wave; whether it will also make
 inroads into academe via easy FTP availability (a version of 'OS Design and
 Implementation' without Minix is coincidentally in hand) remains to be seen.
  
  
 Will Rose
 cwr@pnet01.cts.com