Subject: /etc/inittab (was: /etc/default)
To: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
From: Greg A. Woods <woods@kuma.web.net>
List: current-users
Date: 07/25/1995 11:03:32
[ On Tue, July 25, 1995 at 06:27:40 (-0400), der Mouse wrote: ]
> Subject: Re: /etc/default
>
> This too I loathe.  In both cases, not because the underlying idea is
> bad, but because it is invariably implemented with a lot of hidden (and
> undocumented) magic.  The idea seems, in both cases, to be to make it
> easy to do changes that SGI thinks you should maybe want to do, and
> make it extremely hard, borderline impossible, to do anything else.

Though only the folks inside AT&T who requested this feature can say for
sure, it's my guess that the primary goal is to make it easier to
upgrade systems, esp. ones which might have third-party hardware and
software installed on them.

The fact that it also makes some administrative tasks easier and more
reliable is, I think, a side-effect.

I've yet to see how these schemes make it hard to do anything you
desire.  Certainly some things you might do may compromise some
features, such as the ease of upgrading to a new release, but in any
given situation this may or may not be relevant.

> Now, it may be possible to do this while still retaining the full
> generality we have now.  But I'm skeptical; I won't believe it till I
> see it.

Surely you jest.  What do you mean by "full generality"?  I see the AT&T
/etc/inittab and accompanying /etc/rc.d scripts as far more general and
flexible.  Some folks say *too* general!

> In short, if you want commercial-vendor style software...
> ...you know where to find it.

There's a massive difference between what I think you mean by
"commercial-vendor style software", and an OS ready for use in a
commercial environment.  Many of the things like /etc/default and
/etc/inittab were done in order to meet the needs of the latter, and
just because they were done by the former doesn't mean the concepts are
bad.  Perhaps NetBSD could gain such features with a better
implementation.  Let's talk about the issues rather than the existing
commercial implementations.

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>