home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / linux / 21018 < prev    next >
Encoding:
Text File  |  1992-12-21  |  6.9 KB  |  144 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!math.fu-berlin.de!news.th-darmstadt.de!adams
  3. From: adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams)
  4. Subject: Re: LINUX, Unix, and opportunity for change
  5. Sender: news@news.th-darmstadt.de (The News System)
  6. Message-ID: <ADAMS.92Dec18224635@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de>
  7. In-Reply-To: mleech@bnr.ca's message of 17 Dec 92 15: 45:05 GMT
  8. Date: Fri, 18 Dec 1992 22:46:35 GMT
  9. References: <1992Dec17.154505.8927@bcars6a8.bnr.ca>
  10. Nntp-Posting-Host: pdv2.fmr.maschinenbau.th-darmstadt.de
  11. Organization: TH-Darmstadt
  12. Lines: 130
  13.  
  14. In article <1992Dec17.154505.8927@bcars6a8.bnr.ca> mleech@bnr.ca (Marcus Leech) writes:
  15.  
  16.    Path: news.th-darmstadt.de!math.fu-berlin.de!ira.uka.de!yale.edu!jvnc.net!rutgers!utcsri!torn!nott!bnrgate!bcars6a8!bnr.ca!mleech
  17.    From: mleech@bnr.ca (Marcus Leech)
  18.    Newsgroups: comp.os.linux
  19.    Date: 17 Dec 92 15:45:05 GMT
  20.    Sender: usenet@bcars6a8.bnr.ca (Use Net)
  21.    Organization: Bell-Northern Research, Information Techology Division
  22.    Lines: 62
  23.    Nntp-Posting-Host: bcarh1ea
  24.  
  25. >   Unix provides an extremely rich programming environment, but it has
  26. >     traditionally been weak in the areas of system management and
  27. >    administration. With LINUX, comes an opportunity to address many of these
  28. >     issues. We have an opportunity to build a robust, manageable system, with
  29. >     true "Industrial Strength".
  30. Industrial strength and at least administration comparable to Minis???
  31. Was that the aim of Linus???
  32.  
  33. If you would like to have such a system, start with Mach,
  34. implement/port/ use all approbriate servers (authentizitation
  35. [spelling???], verification, logging, journaling..)
  36.  
  37. >   Parameterization of system modules, including the kernel and critical
  38. >     system processes.  It is desirable to have a highly parameterized kernel
  39. >     with as many of the system parameters tunable dynamically as possible.
  40. >     There needs to be a consisent mechanism for specifying and tuning
  41. >     system parameters; anyone who's used SYSGEN on VMS knows what I'm
  42. >     talking about. 
  43.  
  44. [AUTO]-SYSGEN is fine,  often it returns useful information. BUT: 
  45. Most of its logs are done in hardware on component side, NOT in software.
  46.  
  47. Think of the burden if you start to record each disk access, required 
  48. time to seek, to read etc, to record each character sent to terminal .....
  49.  
  50. Linux would run under full load, just to log its own behaviour.
  51.  
  52. I think Standard-SYSGEN is not yet necessary, as Linux runs on one
  53. hardware platform, but VMS ran on MicroVaxen up to VAX-9000. Currently
  54. Linux need not support multi processor architectures ;->
  55.  
  56. Perhaps it might be reasonable to derivy an optimal configuration for
  57. a given hardware from a set of rules....
  58. (PROLOG programmers please listen ....)
  59.  
  60. >The ability to dynamically load device drivers [LINUX
  61. >     may already have this--I'm not yet a LINUX system manager].  Along with
  62. >     parameterization, theres a *strong* (IMHO) need for *instrumentation*--
  63. >     a system manager needs to know what's going on in the system, its
  64. >     peripherals, and its user processes. 
  65.  
  66. Again -- PC hardware is neither Mini nor Mainframe. Most of the
  67. hardware tools are simple not available!
  68.  
  69. Instrumentation solemnly on a software level might cut performance up to
  70. 90%....
  71.  
  72. >Too often, writers of device drivers
  73. >ignore instrumentation, even though it's cheap and highly useful. I'd like
  74. > to (for example) be able to do the Unix equivalent of the [VMS] SHO DEV/FILES
  75. > command.  Instrumentation should be considered at least as important as
  76. >functionality and performance.
  77.  
  78. To say the least, you simple can not administrate much on a PC.  It is
  79. easier and will show more success just to put in high performance
  80. components as long as none of the various bottlenecks [bus,
  81. memory,cpu,display] becomes dominant.
  82.  
  83. >   There needs to be a consistent and flexible accounting mechanism. Such a
  84. >     mechanism is crucial to tracking security problems, finding out the
  85. >     gory details of why a cron job failed at 03:00 last Thursday, etc, etc.
  86. >     For those who want to charge for computing services (eeek!), good
  87. >     accounting is vital to business objectives.  The current Unix accounting
  88. >     mechanism is not very flexible, lacks certain details, and lacks good
  89. >     tools for dealing with system accounting records.  It's also rather 
  90. >     more expensive to run than it should be.
  91. Why?
  92. Linux is targeted for PCs, that means below [!] work station class....
  93.  
  94. >   More of the system should use the syslog() mechanisms, and there should be
  95. >     standards for use of this mechanism.  When the system crashes, or a
  96. >     peripheral runs into trouble, I want the details recorded by the
  97. >     system as it's happening.  Look at the VMS OPLOG and ERRORLOG facilities
  98. >     for a flavour of what I mean.  /etc/dmesg simply doesn't cut it.
  99.  
  100. May I remind you, that most of the PC peripherals simple lack the hardware
  101. to make OPLOG/ERRORLOG useful? PC is a PC, neither Mini nor Mainframe.
  102.  
  103. Most VAX components including CPU keep track of their own failures themselves.
  104. (Most have error registers to read from.....).
  105.  
  106. I may detect a bad block on a disk on  a PC, but I would not be informed,
  107. that 5 recalibrations during last 67.69 seconds were necessary due to xyz...
  108.  
  109. >   The notion of allocation of peripheral devices to specific sessions is
  110. >     important when you're running a large timesharing system [with the
  111. >     advent of cheap 486/50MHZ systems, people *will* do this with LINUX and
  112. >     other systems].  When I'm making a load of tapes, I don't want someone
  113. >     else to be able to grab the tape drive between tapes.  On a large
  114. >     system, this is vital.  Unix totally lacks the notion of "allocation"
  115. >     of objects, which I think is a big gap in functionality.  With LINUX,
  116. >     we still have the opportunity to address this issue. A coupla changes to
  117. >     the proc table, and a couple of systems calls, and voila--allocation.
  118.  
  119. A private allocation scheme for tty lines is used by uucp....  Indeed
  120. it it not too hard to write one on your own (we did it here both for
  121. tty lines and mass storage [tape and floppy]...), but it should be
  122. available in the package "Cops"....
  123.  
  124. Access control to mass storage devices was always an issue taken by the
  125. file system under ***IX. There is little reason to change this.
  126.  
  127. Access to mass storage devices should only be granted by kernel, for
  128. example claimed by a "mount" command, which offers a standardized
  129. access to mass storage, and only kernel [process] can ensure the
  130. required level of security.
  131.  
  132. (Yes, I believe it is reasonable to have a tar-archive mounted, before
  133. access is granted to user..., and keep access to raw devices strictly
  134. restricted.)
  135.  
  136. Though you may posses a mass storage (tape, disk pack etc), you need
  137. not be the legal owner of the data... Vaxen solve this conflict in
  138. "backup", you never did just a rawread [some lines assembler and a
  139. $QIO], did you? (There are some fine programs in DECUS which allow to
  140. "restore" broken backups... got me?)
  141.  
  142. doubting, adams
  143.  
  144.