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
   From: mleech@bnr.ca (Marcus Leech)
   Newsgroups: comp.os.linux
   Date: 17 Dec 92 15:45:05 GMT
   Sender: usenet@bcars6a8.bnr.ca (Use Net)
   Organization: Bell-Northern Research, Information Techology Division
   Lines: 62
   Nntp-Posting-Host: bcarh1ea

>   Unix provides an extremely rich programming environment, but it has
>     traditionally been weak in the areas of system management and
>    administration. With LINUX, comes an opportunity to address many of these
>     issues. We have an opportunity to build a robust, manageable system, with
>     true "Industrial Strength".
Industrial strength and at least administration comparable to Minis???
Was that the aim of Linus???

If you would like to have such a system, start with Mach,
implement/port/ use all approbriate servers (authentizitation
[spelling???], verification, logging, journaling..)

>   Parameterization of system modules, including the kernel and critical
>     system processes.  It is desirable to have a highly parameterized kernel
>     with as many of the system parameters tunable dynamically as possible.
>     There needs to be a consisent mechanism for specifying and tuning
>     system parameters; anyone who's used SYSGEN on VMS knows what I'm
>     talking about. 

[AUTO]-SYSGEN is fine,  often it returns useful information. BUT: 
Most of its logs are done in hardware on component side, NOT in software.

Think of the burden if you start to record each disk access, required 
time to seek, to read etc, to record each character sent to terminal .....

Linux would run under full load, just to log its own behaviour.

I think Standard-SYSGEN is not yet necessary, as Linux runs on one
hardware platform, but VMS ran on MicroVaxen up to VAX-9000. Currently
Linux need not support multi processor architectures ;->

Perhaps it might be reasonable to derivy an optimal configuration for
a given hardware from a set of rules....
(PROLOG programmers please listen ....)

>The ability to dynamically load device drivers [LINUX
>     may already have this--I'm not yet a LINUX system manager].  Along with
>     parameterization, theres a *strong* (IMHO) need for *instrumentation*--
>     a system manager needs to know what's going on in the system, its
>     peripherals, and its user processes. 

Again -- PC hardware is neither Mini nor Mainframe. Most of the
hardware tools are simple not available!

Instrumentation solemnly on a software level might cut performance up to
90%....

>Too often, writers of device drivers
>ignore instrumentation, even though it's cheap and highly useful. I'd like
> to (for example) be able to do the Unix equivalent of the [VMS] SHO DEV/FILES
> command.  Instrumentation should be considered at least as important as
>functionality and performance.

To say the least, you simple can not administrate much on a PC.  It is
easier and will show more success just to put in high performance
components as long as none of the various bottlenecks [bus,
memory,cpu,display] becomes dominant.

>   There needs to be a consistent and flexible accounting mechanism. Such a
>     mechanism is crucial to tracking security problems, finding out the
>     gory details of why a cron job failed at 03:00 last Thursday, etc, etc.
>     For those who want to charge for computing services (eeek!), good
>     accounting is vital to business objectives.  The current Unix accounting
>     mechanism is not very flexible, lacks certain details, and lacks good
>     tools for dealing with system accounting records.  It's also rather 
>     more expensive to run than it should be.
Why?
Linux is targeted for PCs, that means below [!] work station class....

>   More of the system should use the syslog() mechanisms, and there should be
>     standards for use of this mechanism.  When the system crashes, or a
>     peripheral runs into trouble, I want the details recorded by the
>     system as it's happening.  Look at the VMS OPLOG and ERRORLOG facilities
>     for a flavour of what I mean.  /etc/dmesg simply doesn't cut it.

May I remind you, that most of the PC peripherals simple lack the hardware
to make OPLOG/ERRORLOG useful? PC is a PC, neither Mini nor Mainframe.

Most VAX components including CPU keep track of their own failures themselves.
(Most have error registers to read from.....).

I may detect a bad block on a disk on  a PC, but I would not be informed,
that 5 recalibrations during last 67.69 seconds were necessary due to xyz...

>   The notion of allocation of peripheral devices to specific sessions is
>     important when you're running a large timesharing system [with the
>     advent of cheap 486/50MHZ systems, people *will* do this with LINUX and
>     other systems].  When I'm making a load of tapes, I don't want someone
>     else to be able to grab the tape drive between tapes.  On a large
>     system, this is vital.  Unix totally lacks the notion of "allocation"
>     of objects, which I think is a big gap in functionality.  With LINUX,
>     we still have the opportunity to address this issue. A coupla changes to
>     the proc table, and a couple of systems calls, and voila--allocation.

A private allocation scheme for tty lines is used by uucp....  Indeed
it it not too hard to write one on your own (we did it here both for
tty lines and mass storage [tape and floppy]...), but it should be
available in the package "Cops"....

Access control to mass storage devices was always an issue taken by the
file system under ***IX. There is little reason to change this.

Access to mass storage devices should only be granted by kernel, for
example claimed by a "mount" command, which offers a standardized
access to mass storage, and only kernel [process] can ensure the
required level of security.

(Yes, I believe it is reasonable to have a tar-archive mounted, before
access is granted to user..., and keep access to raw devices strictly
restricted.)
 
Though you may posses a mass storage (tape, disk pack etc), you need
not be the legal owner of the data... Vaxen solve this conflict in
"backup", you never did just a rawread [some lines assembler and a
$QIO], did you? (There are some fine programs in DECUS which allow to
"restore" broken backups... got me?)

doubting, adams

Newsgroups: comp.os.linux