Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Jan 1997 11:08:22 +1100
From:      davidn@unique.usn.blaze.net.au (David Nugent)
To:        terry@lambert.org (Terry Lambert)
Cc:        joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.ORG
Subject:   Re: DEVFS permissions &c.
Message-ID:  <Mutt.19970113110822.davidn@labs.blaze.net.au>
In-Reply-To: <199701121838.LAA25821@phaeton.artisoft.com>; from Terry Lambert on Jan 12, 1997 11:38:03 -0700
References:  <Mutt.19970112003853.davidn@labs.blaze.net.au> <199701121838.LAA25821@phaeton.artisoft.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes:
> > > What are the current ideas of a SysV init? :-)
> > 
> > Shoot first and ask questions later?  :-)
> > 
> > Seriously, I've used sysv for many years, and grew to quickly despise
> > the sysv approach. It does have some good sides, but, for example,
> > Sun's tree of symlinks to init/shutdown scripts is definitely an
> > overkill.
> 
> This really depends on whether you expect to install third party
> commercial software, or not, doesn't it?

No, it is more a question of the implementation.

I can easily imagine a simpler scheme involving a flat file of
scripts to run, in the order in which they run, for each runlevel
or even all runlevels with a flag field to determine which runlevel
each should be run. This is easily handled by a bourne shell script
and doesn't involve the bogosity of symlinks.


> Third party commercial software needs an interface for inserting
> tasks into the startup/shutdown mechanism such that it's possible
> for the tasks to be added/removed without post-processing rc files,
> since if only one vendor out of 200 vendors screws this up, your
> system is screwed entirely.

Sure, I understand the need. But symlinks just obfuscate the entire
process.

There is no *logical* difference between the scheme I've suggested
and what many sysv's use. Only the implementation differs in that
the directory becomes the list - a much more difficult way to
manage it.

A vendor who "screws this up" has no business being a vendor at all.


Regards,

David Nugent - Unique Computing Pty Ltd - Melbourne, Australia
Voice +61-3-9791-9547  Data/BBS +61-3-9792-3507  3:632/348@fidonet
davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19970113110822.davidn>