home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / linux / 9277 < prev    next >
Encoding:
Text File  |  1992-08-29  |  2.7 KB  |  63 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!boulder!ophelia!drew
  3. From: drew@ophelia.cs.colorado.edu (Drew Eckhardt)
  4. Subject: Re: RISC approach to OS - Re: GNU kids on the block?
  5. Message-ID: <1992Aug28.174743.8140@colorado.edu>
  6. Sender: news@colorado.edu (The Daily Planet)
  7. Nntp-Posting-Host: ophelia.cs.colorado.edu
  8. Organization: University of Colorado at Boulder
  9. References: <1992Aug25.195316.9174@kithrup.COM> <1992Aug27.135703.9312@crd.ge.com> <1992Aug28.171744.6460@rz.uni-karlsruhe.de>
  10. Date: Fri, 28 Aug 1992 17:47:43 GMT
  11. Lines: 50
  12.  
  13. In article <1992Aug28.171744.6460@rz.uni-karlsruhe.de> S_TITZ@iravcl.ira.uka.de (Olaf Titz) writes:
  14. >
  15. >While the Linux kernel does its job well, its being monolithic is a
  16. >problem since all of the parts are interdependent, and to comprehend
  17. >the work of one of them, you have to know the whole system. This may
  18. >work for Linux but is unacceptable for bigger systems.
  19.  
  20. This isn't true - although the kernel is one big chunk of 
  21. code, it is subdivided into smaller modules, such as the VM 
  22. code, each one of the file systems, each device driver, etc.  Some of these
  23. modules have incestous relationships with eachother due to various
  24. kludges and hacks, but this isn't necessary.
  25.  
  26. You do have to understand some basic "common" things used in the 
  27. kernel - ie, how the fs register points into user space, how 
  28. sleep/wakeup work, etc, but to say you have to understand the 
  29. whole kernel to write a device driver is a gross overstatement.
  30.  
  31.     <deleted>
  32.  
  33. >>    I like the Linux RISC-like approach, do only a few things, but very
  34. >>  well and very fast. Build the complex functions out of sequences of
  35. >>  simple operations. To me this means simple kernel calls and the library
  36. >>  providing the complex stuff.
  37. >
  38. >I completely agree, and I wonder why this issue now is raised again by
  39. >Linux where this was the design principle of the original UNIX 20
  40. >years ago.  And now UNIX is a huge giant with a lot of memory donuts
  41. >:-) needed to feed him.
  42.  
  43. I agree too - 1.5 - 3M for a typical vendor's kernel is outrageous, 
  44. when it doesn't do anything that a generic 500K BSD or Linux kernel
  45. can't do.
  46.  
  47. >
  48. >>    Don't take this as a rejection of multi-server by me, I'm unconvinced
  49. >>  rather than convinced against. Sort of a software agnostic.
  50. >
  51. >Again: Computers are NOT the right place to practice religion. :-)
  52. >Better an agnostic than determinedly believing in something that can
  53. >possibly be proven wrong. :-)
  54. >
  55.  
  56. Blasphemy! There is nothing but the one true EMACS! :-)
  57.  
  58. -- 
  59. Microsoft is responsible for propogating the evils it calls DOS and Windows, 
  60. IBM for AIX (appropriately called Aches by those having to administer it), but 
  61. marketing's sins don't come close to those of legal departments.
  62. Boycott AT&T for their absurd anti-BSDI lawsuit.
  63.