Date: Sun, 27 Apr 1997 12:32:06 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: ccsanady@nyx.pr.mcs.net (Chris Csanady) Cc: patl@Phoenix.volant.org, davidn@unique.usn.blaze.net.au, mrcpu@cdsnet.net, jkh@time.cdrom.com, hackers@freebsd.org Subject: Re: /etc/netstart bogons.. Message-ID: <199704271932.MAA09051@phaeton.artisoft.com> In-Reply-To: <199704270245.VAA08465@nyx.pr.mcs.net> from "Chris Csanady" at Apr 26, 97 09:45:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I think it is more a case of functionality, rather than personal
> preference. With the rc.d/init.d approach you have more modularity,
> and the ability to start/stop random packages in a consistent way.
> There is also a single standard place that a vendor can throw a
> startup script in--this is a good thing.
Yes. The modularity and the provision for vendor startup scripts
(which already exist for many IBCS2/SVR4/Solaris commercial software
distributions) are my main reason for supporting the model. It is
an IBCS2/interface compliance issue.
That you can start and stop components is a bonus, as is the ability
to support multiple running confiurations for a laptop that may be
disconnected from the net, intermittently IR/Wavelan/etc. connected,
modem/cellular-modem connected, and/or docked. Each is a different
run state (*not* run level).
> What does the rc?.d buy us again? And the two-digit prefix? These
> are no more than a hack aimed at solving the dependancy problem--and
> they only solve the ordering part too. I think multiple
> configurations could be better served than dirs full of symlinks as
> well.
Yes. This is a kludge that has to do with implementation of *levels*
rather than implementation of *states*. I think the numeric designators
are somewhat flawed. I would like to see "rc.xxx" directories, where
"xxx" is the name of a state. I'd also like to see the ability to
transition states based on PnP events ("Hey! I'm docked! Start the
directly connected network!").
> Personally, for the ability to seperate and start/stop services, I
> think I could live with it the way it is. However, I would like
> to see a mechanism to cleanly handle dependancies, and this does
> not cut it.
Yes. The "make" suggestions have been a bit overboard in this regard;
I liked the "tsort" suggestion better. But I'd rather not have state
transition dependencies (implied by "run levels"), though you definitely
need order of operation dependencies internally to setting up a state.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704271932.MAA09051>