home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / linux / 20832 < prev    next >
Encoding:
Text File  |  1992-12-17  |  4.0 KB  |  74 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!nott!bnrgate!bcars6a8!bnr.ca!mleech
  3. From: mleech@bnr.ca (Marcus Leech)
  4. Subject:  LINUX, Unix, and opportunity for change
  5. Message-ID: <1992Dec17.154505.8927@bcars6a8.bnr.ca>
  6. Sender: usenet@bcars6a8.bnr.ca (Use Net)
  7. Nntp-Posting-Host: bcarh1ea
  8. Organization: Bell-Northern Research, Information Techology Division
  9. Date: Thu, 17 Dec 1992 15:45:05 GMT
  10. Lines: 62
  11.  
  12. Unix provides an extremely rich programming environment, but it has
  13.   traditionally been weak in the areas of system management and
  14.   administration. With LINUX, comes an opportunity to address many of these
  15.   issues. We have an opportunity to build a robust, manageable system, with
  16.   true "Industrial Strength".
  17.  
  18. I've been a Unix system programmer and manager and support person for nearly
  19.   14 years. I'd like to review some of the areas that I think need attention, 
  20.   and solicit comments [no flames, please, let's maintain our objectivity].
  21.  
  22. Parameterization of system modules, including the kernel and critical
  23.   system processes.  It is desirable to have a highly parameterized kernel
  24.   with as many of the system parameters tunable dynamically as possible.
  25.   There needs to be a consisent mechanism for specifying and tuning
  26.   system parameters; anyone who's used SYSGEN on VMS knows what I'm
  27.   talking about. The ability to dynamically load device drivers [LINUX
  28.   may already have this--I'm not yet a LINUX system manager].  Along with
  29.   parameterization, theres a *strong* (IMHO) need for *instrumentation*--
  30.   a system manager needs to know what's going on in the system, its
  31.   peripherals, and its user processes. Too often, writers of device drivers
  32.   ignore instrumentation, even though it's cheap and highly useful. I'd like
  33.   to (for example) be able to do the Unix equivalent of the [VMS] SHO DEV/FILES
  34.   command.  Instrumentation should be considered at least as important as
  35.   functionality and performance.
  36.  
  37. There needs to be a consistent and flexible accounting mechanism. Such a
  38.   mechanism is crucial to tracking security problems, finding out the
  39.   gory details of why a cron job failed at 03:00 last Thursday, etc, etc.
  40.   For those who want to charge for computing services (eeek!), good
  41.   accounting is vital to business objectives.  The current Unix accounting
  42.   mechanism is not very flexible, lacks certain details, and lacks good
  43.   tools for dealing with system accounting records.  It's also rather 
  44.   more expensive to run than it should be.
  45.  
  46. More of the system should use the syslog() mechanisms, and there should be
  47.   standards for use of this mechanism.  When the system crashes, or a
  48.   peripheral runs into trouble, I want the details recorded by the
  49.   system as it's happening.  Look at the VMS OPLOG and ERRORLOG facilities
  50.   for a flavour of what I mean.  /etc/dmesg simply doesn't cut it.
  51.  
  52. The notion of allocation of peripheral devices to specific sessions is
  53.   important when you're running a large timesharing system [with the
  54.   advent of cheap 486/50MHZ systems, people *will* do this with LINUX and
  55.   other systems].  When I'm making a load of tapes, I don't want someone
  56.   else to be able to grab the tape drive between tapes.  On a large
  57.   system, this is vital.  Unix totally lacks the notion of "allocation"
  58.   of objects, which I think is a big gap in functionality.  With LINUX,
  59.   we still have the opportunity to address this issue. A coupla changes to
  60.   the proc table, and a couple of systems calls, and voila--allocation.
  61.  
  62. So, is anybody *else* interested in this stuff, or am I preaching to an
  63.   empty church?
  64.  
  65. I'd like to make it clear that I'm as rabid a Unix fanatic as the next guy,
  66.   but I have the wisdom to see where other OSes have done some things
  67.   better. If you flame me because you think I'm a VMS weenie, I'll
  68.   not reply.
  69.  
  70. -- 
  71. Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
  72. mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
  73. ml@ve3mdl.ampr.org             Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs
  74.