home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11835 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  2.4 KB
  1. Path: sparky!uunet!noc.near.net!hri.com!spool.mu.edu!uwm.edu!zaphod.mps.ohio-state.edu!menudo.uh.edu!sugar!ficc!peter
  2. From: peter@ferranti.com (peter da silva)
  3. Newsgroups: comp.arch
  4. Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
  5. Message-ID: <id.UL0W.D1A@ferranti.com>
  6. Date: 21 Dec 92 21:56:47 GMT
  7. References: <BzGL07.2wK@dscomsa.desy.de> <1992Dec18.150228.8274@cis.uab.edu> <BzIuKw.Buy@dscomsa.desy.de>
  8. Organization: Xenix Support, FICC
  9. Lines: 41
  10.  
  11. In article <BzIuKw.Buy@dscomsa.desy.de> Hallam@zeus02.desy.de writes:
  12. > There is no way of making a UNIX machine look as if it configured in one way
  13. > to one program but in quite a different way to another program.
  14.  
  15. That depends on where the program looks for the configuration, of course.
  16. There are UNIX programs with hard-coded file names, just as there are DOS
  17. programs that write direct to the screen. This has to do with how "virtual"
  18. the execution environment is. UNIX does very well in this department compared
  19. to other 20 year old operating systems, and it's quite easy to fake out an
  20. application in all sorts of *other* ways.
  21.  
  22. But it sounds like what you really want here is Plan 9.
  23.  
  24. > If you have more
  25. > than 20 people on a cluster you will realize why it is impossible to give root
  26. > privs to everybody.
  27.  
  28. Why would you want to? We have about three people with root here, and when
  29. more people want it we arrange things so they don't need it.
  30.  
  31. > Having beds for rent does not mean that a bordello is a hotel.
  32.  
  33. > A multiuser machine should be just that, it should allow multiple users to
  34. > access it without interfering with each other.
  35.  
  36. Gee, I thought we were doing that quite well, apart from CPU speed degradation
  37. and so far as I know only the DoD cares about that.
  38.  
  39. > In addition to this inadequate resource
  40. > monitoring means that the scheduler is practicaly useless, any user can simply
  41. > spawn tasks to increase the proportion of CPU alloted to their needs. 
  42.  
  43. Well, eventually they reach the per-user process limit. And antisocial
  44. behaviour can be addressed outside the OS. Defending against every possible
  45. resource starvation attack is damned hard, and I'd rather spend my personal
  46. on more productive areas. Like the boot/configuration environment, for example.
  47. -- 
  48. Peter da Silva                                            `-_-'
  49. Ferranti International Controls Corporation                'U` 
  50. Sugar Land, TX  77487-5012 USA
  51. +1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
  52.