home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / linux / 9301 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  2.2 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!olivea!hal.com!darkstar.UCSC.EDU!keller
  2. From: keller@cse.ucsc.edu (Jeffrey Keller)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: GNU kids on the block?   (sorry... couldn't resist)
  5. Keywords: Linux, Mach, CISC, RISC
  6. Message-ID: <17m6sbINN64o@darkstar.UCSC.EDU>
  7. Date: 28 Aug 92 21:46:51 GMT
  8. References: <1992Aug25.123854.26792@uwm.edu> <1992Aug25.195316.9174@kithrup.COM> <1992Aug27.135703.9312@crd.ge.com>
  9. Organization: University of California, Santa Cruz (CE/CIS Boards)
  10. Lines: 37
  11. NNTP-Posting-Host: oak.ucsc.edu
  12.  
  13. In article <1992Aug27.135703.9312@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
  14. ...
  15. > Multi-server is the CISC
  16. >of software, a sort of hypercube of processes rather than processors.
  17. ...
  18. >
  19. >  I like the Linux RISC-like approach, do only a few things, but very
  20. >well and very fast. Build the complex functions out of sequences of
  21. >simple operations. To me this means simple kernel calls and the library
  22. >providing the complex stuff.
  23. >
  24. >  Don't take this as a rejection of multi-server by me, I'm unconvinced
  25. >rather than convinced against. Sort of a software agnostic.
  26. >
  27. >--
  28. >bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
  29. >    I admit that when I was in school I wrote COBOL. But I didn't compile.
  30.  
  31. You realize that microkernel people would take the opposite position,
  32. right?  That the microkernel is RISC-like, stripped down to the
  33. essentials, with the server processes corresponding to subroutines?
  34. And that a conventional kernel (even Linux) is CISC-like, trying to
  35. anticipate what the user will need and handle it internally?  And, of
  36. course, they'd probably argue that just as it is easier to tweak a
  37. subroutine than microcode, it's easier to tweak a discrete server than
  38. a part of the kernel.  Just an observation.
  39.  
  40. By the way, I also have mixed feelings about microkernels.  On the one
  41. hand, I don't believe they can ever be as efficient as macrokernels;
  42. on the other, (despite what Larry McVoy says) I believe that further 
  43. evolution of OSes is essential and that microkernels can foster that.
  44. I also think that it might be easier to make a microkernel secure,
  45. but I'm not at all sure of it.
  46.  
  47. --
  48. Jeff Keller <keller@cse.ucsc.edu>    CIS Board, UCSC
  49. "If X is the answer, what was the question?" --David Fuller
  50.