Tech Insider					     Technology and Trends


		   Linux Activists Mailing List Archives

From: mleech@bnr.ca (Marcus Leech)
Subject: LINUX, Unix, and opportunity for change
Date: 17 Dec 92 15:45:05 GMT

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".

I've been a Unix system programmer and manager and support person for nearly
  14 years. I'd like to review some of the areas that I think need attention, 
  and solicit comments [no flames, please, let's maintain our objectivity].

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. 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. 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.

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.

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.

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.

So, is anybody *else* interested in this stuff, or am I preaching to an
  empty church?

I'd like to make it clear that I'm as rabid a Unix fanatic as the next guy,
  but I have the wisdom to see where other OSes have done some things
  better. If you flame me because you think I'm a VMS weenie, I'll
  not reply.

-- 
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
ml@ve3mdl.ampr.org             Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs

From: dsc3pzp@nmrdc1.nmrdc.nnmc.navy.mil (Philip Perucci)
Subject: Re: LINUX, Unix, and opportunity for change
Date: 18 Dec 92 17:56:28 GMT

In article <1992Dec17.154505.8927@bcars6a8.bnr.ca> mleech@bnr.ca (Marcus Leech) writes:
>
>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. The ability to dynamically load device drivers [LINUX
>  may already have this--I'm not yet a LINUX system manager].
>

Yes!  Most people can't (or won't) compile the kernel, but the ability
to configure kernel parameters and device drivers is more common-place.

>  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. 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.

Sure would be nice!


Then again, let me say I am quite grateful for what has already been
accomplished.  Thank-you Linus!!!

-- 
===========================================================================
  phil perucci      | "Any opinions expressed are solely my own views and 
  ssb1pzp@digex.com |  do not reflect the position of any organization"
===========================================================================

From: mleech@bnr.ca (Marcus Leech)
Subject: Re: LINUX, Unix, and opportunity for change
Date: Sat, 19 Dec 1992 17:01:43 GMT

In article <BzGv65.KKI@nmrdc1.nmrdc.nnmc.navy.mil>, 
dsc3pzp@nmrdc1.nmrdc.nnmc.navy.mil (Philip Perucci) writes:
|> Then again, let me say I am quite grateful for what has already been
|> accomplished.  Thank-you Linus!!!
|> 

Lest anyone think my post was a shot at Linux and its progenitors--that's
  *not* what I intended.

I see Linux a completely fresh implementation of a Unix-esque system.
  It strikes me as an opportunity to fix many of the long-standing 
  problems with Un*x, and to address those areas that the commercial Un*x
  vendors have been either too timid, or too stupid to address.

I think that what Linus and the assembled multitudes here have done is a
  tremendous testament to the vitality of the free sofware "industry". Let's
  leverage that vitality, and build something truly fresh and exciting.

Were it not for the fact that I have a job where everything I create is
  owned by my employer, I'd be as busy as Linus; contributing, rather
  than just pontificating.  [Though it's certainly not unheard-of around
  here to be able to release freeware, just rather rare].

-- 
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
ml@ve3mdl.ampr.org             Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs

From: pmacdona@sanjuan (Peter MacDonald)
Subject: Re: LINUX, Unix, and opportunity for change
Date: Sat, 19 Dec 92 17:33:16 GMT

In article <1992Dec17.154505.8927@bcars6a8.bnr.ca> 
mleech@bnr.ca (Marcus Leech) writes:
>Unix provides an extremely rich programming environment, but it has
...
>Parameterization of system modules, including the kernel and critical

There are two schools of thought on this.  
Please allow me to...
And please don't make me ...

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.  

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.

>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'd like to make it clear that I'm as rabid a Unix fanatic as the next guy,

Glad to hear it.  But there are probably more differences than similarities
between VMS and Linux (I work supporting products on a 6*6000 VAX cluster).
Some of these differences are more than just philosophy.  VMS is single
sourced, and tightly controlled.  Linux is great :-).

Peter
pmacdona@sanjuan.uvic.ca

From: mleech@bnr.ca (Marcus Leech)
Subject: Re: LINUX, Unix, and opportunity for change
Date: 20 Dec 92 22:14:58 GMT

In article <1992Dec19.173316.7680@sol.UVic.CA> 
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
mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
ml@ve3mdl.ampr.org             Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/