home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / linux / 9271 < prev    next >
Encoding:
Text File  |  1992-08-29  |  3.6 KB  |  73 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!mcsun!Germany.EU.net!ira.uka.de!rz.uni-karlsruhe.de!usenet
  3. From: S_TITZ@iravcl.ira.uka.de (Olaf Titz)
  4. Subject: RISC approach to OS - Re: GNU kids on the block?
  5. In-Reply-To: davidsen@ariel.crd.GE.COM's message of 27 Aug 92 13: 57:03 GMT
  6. Message-ID: <1992Aug28.171744.6460@rz.uni-karlsruhe.de>
  7. Sender: usenet@rz.uni-karlsruhe.de (USENET News System)
  8. Organization: Fachschaft Informatik, Uni Karlsruhe
  9. References: <ROLAND.92Aug24194541@churchy.gnu.ai.mit.edu> <1992Aug25.123854.26792@uwm.edu> <1992Aug25.195316.9174@kithrup.COM> <1992Aug27.135703.9312@crd.ge.com>
  10. Date: Fri, 28 Aug 1992 17:17:44 GMT
  11. X-News-Reader: VMS NEWS 1.23
  12. Lines: 59
  13.  
  14. In <1992Aug27.135703.9312@crd.ge.com> davidsen@ariel.crd.GE.COM writes:
  15.  
  16. >    Here comes that idea again... The first o/s I helped write ran about
  17. >  2/3 of the kernel in user mode, with user programs mapped into the
  18. >  addressing space. Multics was using rings to get some of the same
  19. >  things you get with setuid(), namely a limited set of privileges. GCOS
  20. >  used a multi-threaded kernel (sort of) with multiple processors all
  21. >  scampering around inside waving flags at one another. It even had
  22. >  almost lightweight processes to handle i/o interrupts in user space.
  23. >    That was mid 60's and it's interesting that the idea of monolithic
  24. >  kernel is once again drifting out of vogue. Unfortunately I don't think
  25.  
  26. While the Linux kernel does its job well, its being monolithic is a
  27. problem since all of the parts are interdependent, and to comprehend
  28. the work of one of them, you have to know the whole system. This may
  29. work for Linux but is unacceptable for bigger systems.
  30.  
  31. >  the multiserver is right direction, since everything else in computers
  32. >  is headed for less compleity rather than more. Multi-server is the CISC
  33. >  of software, a sort of hypercube of processes rather than processors.
  34. >
  35. >  I'm all in favor of modularity (look at some of my net code), but I am
  36. >  not convinced that this is the best way to get there.
  37.  
  38. Depends on what you want to achieve. A true distributed system could
  39. transparently allocate resources of different machines to a job.
  40. Whether you want this is another question.
  41.  
  42. >    I like the Linux RISC-like approach, do only a few things, but very
  43. >  well and very fast. Build the complex functions out of sequences of
  44. >  simple operations. To me this means simple kernel calls and the library
  45. >  providing the complex stuff.
  46.  
  47. I completely agree, and I wonder why this issue now is raised again by
  48. Linux where this was the design principle of the original UNIX 20
  49. years ago.  And now UNIX is a huge giant with a lot of memory donuts
  50. :-) needed to feed him.
  51.  
  52. But for this approach you need at least shared libraries to avoid a
  53. large-scale memory waste. And it comes down to the Amiga which has NO
  54. real OS kernel, where ALL is shared libraries. Seems to me one of the
  55. most well-designed OSs that ever existed, but been undervalued mostly
  56. because of hardware and marketing problems :-(
  57. (one of them being hardware dependence...)
  58.  
  59. >    Don't take this as a rejection of multi-server by me, I'm unconvinced
  60. >  rather than convinced against. Sort of a software agnostic.
  61.  
  62. Again: Computers are NOT the right place to practice religion. :-)
  63. Better an agnostic than determinedly believing in something that can
  64. possibly be proven wrong. :-)
  65.  
  66. MfG,
  67.         Olaf
  68. -- 
  69. Olaf Titz - comp.sc.student - Univ of Karlsruhe - s_titz@iravcl.ira.uka.de -
  70. uknf@dkauni2.bitnet - praetorius@irc - +49-721-60439 - did i forget something?
  71. Der gr"une Punkt ist halt genauso sinnvoll wie ne T"UV-Plakette
  72.  auf nem Schrotthaufen. - Thomas Volkmar Worm
  73.