NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/os/linux/21186

Text File | 1992-12-21 | 3.4 KB | 64 lines

Newsgroups: comp.os.linux
Path: sparky!uunet!utcsri!torn!nott!bnrgate!bcars6a8!mleech
From: [e-mail] (Marcus Leech)
Subject: Re: LINUX, Unix, and opportunity for change
Message-ID: <[e-mail]>
Sender: [e-mail] (Use Net)
Nntp-Posting-Host: bcarh1ea
Organization: Bell-Northern Research, Ottawa, ON CANADA
References: <[e-mail]> <[e-mail]>
Date: Sun, 20 Dec 1992 22:14:58 GMT
Lines: 51

In article <[e-mail]> pmacdona@sanjuan (Peter MacDonald) writes:
>The VMS tunable kernel is necessary because Digital is not giving out
>source.  Linux comes with source so you are free to tune the source
>to your hearts content.  If want to avoid recompiles, you can use
>lilo to pass in parameters.  For run time tuning, you can hook into
>the ioctl calls, to modify kernel parameters.
>
Only partly true.  What if I had to recompile grep(1) every time I wanted
  to use a different option?  Having a dymamically tunable kernel is useful.
  VMS tends to overdo it, and a certain amount of autoconfiguration at
  system startup would probably be more useful than the vast majority of
  many tunable parameters.  The VMS mechanisms for this don't just apply
  to the kernel, however, which is nice. It means you can (for example)
  tune the parameters of system daemons from a single place.
>Having the source is far superiour because it is less indirect, and
>indirection always exacts a price,  in terms of simplicity, flexibility
>and power.
>
>>There needs to be a consistent and flexible accounting mechanism. Such a
>
>Ditto what someone else said (mkj?).  This is overhead few will want.
>If it isn't to extensive, we might consider adding it to the kernel
>as a conditional compile.
>
Put together a 50MHZ 486(586) system, with 16M of memory, a coupla Gs of
  disk space, a coupla tape drives, and 16 or 32 serial ports.  Suddenly,
  this isn't a "desktop, single-user PC", it's a compact timesharing system
  suitable for a variety of business and technical uses. Some people
  need good accounting, either for customer chargebacks, or as part of
  ongoing system administration.  None of the commercial vendors have
  very good tools for this, maybe Linux can address this.

>>More of the system should use the syslog() mechanisms, and there should be
>
>Syslog (which I have started to add to SLS) is not in the kernel.  It
>is supported or not, by the system utilities login, etc.  Note, things
>like xlock, and xdm and ftpd need source modifications, to participate.
>
I realize that syslog() isn't in the kernel.  My point is that there should
  be a consistent, centralized logging mechanism used by ALL parts of the
  system that ever need to log anything.  In Unix, this has been handled
  rather poorly in the past, with every program and subsystem choosing to
  do this in incompatible ways.  Syslog() was introduced to alleviate this,
  and it's a shame that more parts of the system don't use it.  Just like
  more parts of the system (daemons, applications) don't yet use getopt()
  and perror().  Yes, source code modifications will be necessary, but
  somebody with a work-term student with time on their hands..... ;-)
--
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
[e-mail]                  P.O. Box 3511, Stn. C   |are my own, and not
[e-mail]             Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs