home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / next / advocacy / 3941 < prev    next >
Encoding:
Text File  |  1993-01-25  |  4.8 KB  |  98 lines
  1. Newsgroups: comp.sys.next.advocacy
  2. Path: sparky!uunet!spool.mu.edu!uwm.edu!rpi!usenet
  3. From: gad@eclipse.its.rpi.edu (Garance A. Drosehn)
  4. Subject: Re: A CPU on Every Desk?
  5. Message-ID: <b+p38fa@rpi.edu>
  6. Nntp-Posting-Host: eclipse.its.rpi.edu
  7. References: <1993Jan25.192117.2503@trilithon.mpk.ca.us>
  8. Date: Tue, 26 Jan 1993 00:46:20 GMT
  9. Lines: 87
  10.  
  11. henry@trilithon.mpk.ca.us (Henry McGilton) writes:
  12. > As Steve Abell said, ``Oh, how short people's memories are!''.
  13. > 
  14. > Anybody who (like me) suffered through that computer industry mass
  15. > psychosis of the 1970's called ``time sharing'' while trying to
  16. > get software out the door would never want to go back to centralised
  17. > anything.  The biggest liberating factor I had in my career was
  18. > when I quit using a Control Data 7600 timeshared machine and got
  19. > myself a Cromemco Z2 box with a Z80 in it -- mine, all mine!
  20.  
  21. The question you should ask is, "Were my problems the result of time-sharing  
  22. per se, or were they particularly bad because of the OS that I happened to  
  23. be stuck with to do that timesharing?"
  24.  
  25. > Unfortunately, I see the disquieting trend back to time sharing,
  26. > except it's now called ``client server computing'', as if giving
  27. > it a new name changes the result.  In these new bad old days, the
  28. > resource being competed for (competition, you understand, NOT
  29. > sharing) isn't so much CPU cycles as network bandwidth.  The end
  30. > results are the same, though:
  31.  
  32. One of my biggest complaints with "the brave new world of computing" is the  
  33. lies that are involved.  People tout the benefits of standalone systems, but  
  34. what is really sold is "client-server" computing.  I agree with you that  
  35. "client-server" computing isn't all *that* much different than mainframe  
  36. computing, once you peel away the fancy marketting layers.
  37.  
  38. >   o   the decisions as to what's on your desk and how well (or
  39. >     mostly badly) it'll be ``served'' are made by somebody
  40. >     other than you.  The person making the decisions usually
  41. >     has no accountability and usually doesn't have to suffer
  42. >     the same lousy service you're getting.
  43.  
  44. Again, this shows a problem in your particular situation.  System developers  
  45. need to be on the *exact* same system as the users, or the problem you note  
  46. is unavoidable.  This is true whether we're talking mainframes or  
  47. stand-alone PC's.
  48.  
  49. >   o   the administration of the central resource ends up being
  50. >     done by what rapidly becomes an elite priesthood of ``gurus''
  51. >     and their acolytes.  This elite priesthood rapidly develops
  52. >     into a defensive faction with their own agenda which has
  53. >     little or nothing to do with providing adequate service to
  54. >     the users of the resource.
  55.  
  56. That defensive mechanism comes from having too many people asking for too  
  57. many things.  This is unavoidable with any centralized system.  Of course,  
  58. with any completely distributed system, you end up with a similar problem.   
  59. My stand-alone Mac has all kinds of gee-whiz, high brow, fancy productivity  
  60. enhancements.  I'll be willing to bet that most the Macs on campus don't,  
  61. because *I* know where to find these things and the average Mac user doesn't  
  62. have a clue about them.
  63.  
  64. While I do believe there's a difference there, it's hard for me to put into  
  65. words just what (or where) I think the overall advantage is.
  66.  
  67. I'm also all too painfully aware of users who *think* they know what they  
  68. are doing, so they install some new piece of software --- and then call us  
  69. up (us = a central computing service) to figure out why nothing on their  
  70. machine works anymore.  I've lost many a day to such "productivity  
  71. enhancements" as we have moved towards the distributed computing approach.
  72.  
  73. >   o   the decisions as to the level of utilisation of the central
  74. >     resource are made by bean counters, who usually don't have
  75. >     to suffer from their decisions.  The bean counter mentality
  76. >     indicates that the resource must be utilised to and beyond
  77. >     the limit, to the point where the resource becomes useless.
  78.  
  79. The influence of bean counters on all this can be a problem.  But again, it  
  80. can also be a problem for standalone systems.  Why buy a Mac Quadra when you  
  81. only use that Mac Plus 2 hours per day?  The real problem here is that you  
  82. are using other people's money to get resources for your own work (work that  
  83. they do not do).  You have to convince them to spend the bucks.
  84.  
  85. And since I work at a university, I am very familiar with this problem...
  86.  
  87. > One would think that the people in the industry had learned their
  88. > lessons in the so called ``software crises'' of the 60's and 70's
  89. > and would not want to repeat the nonsense.
  90.  
  91. It is not clear that everyone can really get what they need with any of the  
  92. current models of computing, if that one model is followed slavishly.
  93.  
  94. --
  95. Garance Alistair Drosehn     =     gad@eclipse.its.rpi.edu
  96. ITS Systems Programmer            (handles NeXT-type mail)
  97. Rensselaer Polytechnic Institute;           Troy NY    USA
  98.