Re: /etc/init.d structure [long rant]
On Fri, 15 Aug 1997, Dima wrote:
> >>jghasler@win.bright.net wrote:
> >Manoj Srivastava writes:
> >> *Nothing* has an S* in more than one level. A package is meant to be at a
> >> certain run level and higher. A level 3 package is started at run level
> >> 3, killed in run level 2, and at *no* other level. See how this works?
> >
> >Simple and elegant, but not very flexible. How about a state machine
> >approach?
>
> Assuming "runlevel" is roughly equivalent to "state", the above model is
> a stack of states. A state transition diagram would be a (potentially fully
> connected) graph of states. (Potentially) what a mess. :)
>
Depends on how you do it. A fully connected graph of states doesn't need
to have each possible state transition manually defined. All you need is
definitions of each state, and the state transition actions can be
automaticly determined by comparing the two states.
> Next question is how to define a "state" -- 6 basic states is what we have
> now. If we want more states (finer grain) our graph becomes messier.
>
Why would you want more than 6? Even if you do, you only need to define
the additional states (specify what should be running in each state).
> Also, runlevels _are flexible. Nobody can force me to start networking
> daemons at RL 2 -- I can bloody well start them from ip-up when I ring my
> ISP, at whatever runlevel I happen to be then. (In practice I don't care:
> when I don't need networking daemons, they waste about $0.5 worth of my
> swap partition. Big deal).
>
This is a different thing all together. What you are doing is saying that
runlevels are not flexible enough to handle your networking daemon
requirements, so you'r gonna do it manualy. You are just saying that they
are flexible because you don't have to use them.
> If you let user similarly customize the states, you _will end up with a
> fully connected graph for STD -- definitely a mess.
> (One program implementing a complex state machine is sendmail, BTW.)
>
> Stack is a much simpler structure -- easier to implement, less bugs etc.
> Besides, it's almost there already.
>
Yes, it is simpler, and it is almost there already, but;
1) is it the "standard" way of doing it, or are we inventing yet
another way of doing it?
2) regardless of whether it is a standard, it has limitations, and can we
live with those limitations?
ABO
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: