home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 12029 < prev    next >
Encoding:
Internet Message Format  |  1993-01-02  |  3.4 KB
  1. Path: sparky!uunet!auspex-gw!guy
  2. From: guy@Auspex.COM (Guy Harris)
  3. Newsgroups: comp.arch
  4. Subject: Re: multiuser systems (was Re: IBM AS/400 is the world's slowest..)
  5. Message-ID: <16189@auspex-gw.auspex.com>
  6. Date: 2 Jan 93 04:25:55 GMT
  7. References: <id.TX9W.FC3@ferranti.com> <1993Jan1.102554.28575@metapro.DIALix.oz.au> <C07DK0.E7t@cs.bham.ac.uk>
  8. Sender: news@auspex-gw.auspex.com
  9. Organization: Auspex Systems, Santa Clara
  10. Lines: 55
  11. Nntp-Posting-Host: auspex.auspex.com
  12.  
  13. >People who suffered timeshared systems in the 70's often refuse to
  14. >believe any of this unless they have direct experience of the
  15. >benefits.
  16.  
  17. I suspect the people who suffered timeshared systems back then suffered
  18. from having a timesharing system capable of supporting N people
  19. comfortably, but having M > N (perhaps M >> N) people using it
  20. regularly.
  21.  
  22. Is it that at least some of the resources that were in too scarce supply
  23. back then - CPU and memory - are now in much more plentiful supply, so
  24. that you're less likely to have an overloaded time-sharing system? 
  25.  
  26. (Yes, I remember early-'80s timesharing systems.  I've *no* desire to
  27. use a timeshared system that can't, for example, give quick response to
  28. keystrokes in editors such as Frame Maker, even if other folks are doing
  29. compiles, running their own sessions with Frame or 1-2-3 or whatever.)
  30.  
  31. >The strength of this argument is not undermined by the horrors of X:
  32. >at least it provides graphical interaction over a network.
  33.  
  34. And not all such systems (central compute and file servers, desktop
  35. graphics machines that aren't expected to do all the compute work
  36. themselves) use X; see, for example, Bell Labs's Plan 9.
  37.  
  38. Rob Pike has made many of the same arguments (lower cost for desktop
  39. machines, ability to upgrade the central machine's CPU power instead of
  40. upgrading all the desktop machines) for the Plan 9 system (although,
  41. Rob's tendency, at least at one point, to refer to the desktop machines
  42. as "terminals" nonwithstanding, they're actually diskless workstations,
  43. running essentially the same OS as the compute servers, and capable of
  44. running applications, although they generally have less CPU power and
  45. probably less memory than the compute servers).
  46.  
  47. The Plan 9 model is actually a bit different from the "dumb terminal"
  48. model, even the "dumb X terminal" model, as applications that don't
  49. consume *huge* amounts of CPU, and that are quite interactive - e.g.,
  50. text editors (even ones such as Frame; they probably consume more CPU
  51. than "vi", but probably not as much as Verilog...), spreadsheets, blah
  52. blah blah, can be run on the desktop machine.
  53.  
  54. Applications requiring more CPU or memory, or requiring a tighter
  55. connection to the file server (the compute servers and file servers are
  56. joined by higher-speed links than are the desktop computers and file
  57. servers), but not requiring quick response to keystrokes or mouse
  58. motions are probably run on the compute server.  (Graphical applications
  59. that talk directly to a window, and get keyboard and mouse events
  60. directly, can be run either on the compute server or the desktop
  61. computer; the window system is one that runs over a network.)
  62.  
  63. (If you want to debate the merits of Plan 9, debate them with Rob Pike
  64. or Ken Thompson, not with me.  I've never used it, I've just heard about
  65. it and read some papers on it.  I'm pretty much just reciting its
  66. creator's views, as I understand them; I've not enough information to
  67. agree *or* disagree with them, at this point....)
  68.