Date: Mon, 25 Sep 1995 23:43:33 -0400 From: Coranth Gryphon <gryphon@healer.com> To: gryphon@healer.com, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com Cc: hackers@FreeBSD.ORG Subject: Re: ports startup scripts Message-ID: <199509260343.XAA14628@healer.com>
next in thread | raw e-mail | index | archive | help
From: patl@asimov.volant.org
> I generally agree that having multiple copies or multiple locations
> can lead to problems; but in this case I believe that the advantages
> far outweigh the possible difficulties.
That's where we differ. I don't see any advantage to it.
> Gack. First, one 'local' isn't enough. Second, the new states may
> not actually fit between any of the existing states. (E.g., another
> contractor I know wants a single-user-with-networking state.)
>
> No, I can easily create my own state using the next available state
> number. Since there's no implied level-ordering of the states, which
> number I choose is purely arbitrary.
It's a question of how much flexibility is going to be commonly used vs.
how much effort it take to implement each increase in flexibility.
But I agree that run-states are worth the effort. It gets us the most
for only a medium increase in difficulty.
> The SVr4/Solaris2/etc. technique is the simplest and most powerful
> mechanism proposed to date. Let's not let a hatred for SysV keep
> us from adopting one of the things they did -very- well.
No it is not the simplest. And that it was done "very well" is entirely
debatable. As I said, it comes down to a religious argument.
I don't like it, you do.
> |> We are not talking about script editing. We are talking about adding
> |> a line to a control file, versus adding a line to a directory.
> How does 'adding a line' differ from 'editing' ? Control file -vs-
> script is a minor point compared to the fact of installation scripts
> editing shared system control files.
Each sub-system has it's own script. A control file determines what
gets run when. Or each sub-system has it's own script, and directory
ordering in a sym-linked tree determines which gets run when.
> |> And one of it's single biggest confusions. I prefer BSD variants
> |> over SysV variants BECAUSE of design decisions like this.
> |> A lot of other people probably do as well.
> If this really confuses you that much, perhaps you aren't well suited
> to systems administration. Personally, I'd far rather have the tiny
> bit of potential confusion than the huge potential for damage.
It's not that SysV confuses me, it's that I think it is a LOUSY DESIGN.
Personal opinion, which is a matter of a lot of experience. I've been
doing unix system and programming admin for about 10 years. And I like
the BSD way over the SysV way.
> Don't say "SysV is doing it so we shouldn't"!
I'm not saying not to do it because someone else is, I'm saying
not to do because I consider it a bad design and most examples
of it bad implementations of that bad design.
> I really think you are letting your hatred for SystemV color your
> judgement here. Sit back and pretend that this mechanism was not
I don't reject SysV style ways of doing things because they come
from SysV. I reject SysV because it does things those ways.
I don't care who invented it. I've looked at it, worked with it,
and don't agree with it. It's really that simple.
> Pretend that we are inventing it here for the
> first time. Would you really be so adamantly against it? (You
> don't have to answer publicly - just think about it for yourself.)
Would I still be against it? Yes. I was against it the first half-dozen
times I had to work with it (and still am after 10 years), and I was
against similar designs I've run into on entirely unrelated projects.
I prefer to keep configuration information explicit, in a file,
not implicit, in a sort order.
I prefer to keep one copy of things, not two - even if they are links.
|> Or, if we want to put a little more work in, we can do both and
|> make everyone happy. We have to define the commonalities (one
> Easily done. 'Inittab' and init.d become the 'required' part of the
> system, with a control file or rc?.d subdirs and rc? scripts as the
> 'optional' parts.
The directory which holds everything ("init.d" or whatever it's called)
and one-script-per-subsystem (stored there) are the 'required parts'.
The two options for ordering determination are the control file ("inittab"
or "init.conf" or whatever it's called) and the "rc?.d" directories with
sym-links and names based on start/stop and numeric ordering.
Details on how to best implement each them become unrelated discussions.
Except that anything in common becomes part of the underlying foundation,
so that only the differences are implemented in parallel.
> |> But we'll end up with something that is simply fantastic,
>
> That's a lot tougher. The biggest problem being to make the package
> installation scripts able to handle the necessary updates for both
Each mechanism will have to have a means to automatically add config
information. These two will become subroutines of some overall tool
(called "pkg_init_setup" or whatever).
All packages/ports will call this commong interface, which will determine
(by some fixed mechanism) which startup type is in use, and call
the correct subroutine.
This "dual-natured" system was mentioned by someone as already having
been done. And working well for those who use it.
Powers that be? Who makes the decision on which (or both) way we go?
At this point, it's pick a direction, unless anyone has any other
completely different paths to head in?
-coranth
------------------------------------------+------------------------+
Coranth Gryphon <gryphon@healer.com> | "Faith Manages." |
| - Satai Delenn |
Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+
USMail: 3 Hansom Drive, Merrimack, NH 03054
Disclaimer: All these words are yours, except Europa...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509260343.XAA14628>