Date: Tue, 26 Sep 1995 00:01:05 -0400 From: Coranth Gryphon <gryphon@healer.com> To: gryphon@healer.com, patl@asimov.volant.org, terry@lambert.org Cc: hackers@FreeBSD.ORG, jmb@kryten.atinc.com, peter@taronga.com Subject: Re: ports startup scripts Message-ID: <199509260401.AAA14675@healer.com>
next in thread | raw e-mail | index | archive | help
From: patl@asimov.volant.org
> |> it adds to the end of the file. Or adds to the first (or fourth or ...)
> |> line after its dependancy.
> If it can find the dependancy. And doesn't mistake something else for it.
> Which basicly means it will work fine in the lab and fail miserably in the
>real world. I have yet to see an automatic editing system which was robust
Anything which can figure out the correct number to use for the script
name can figure out where to place itself in a file. If it can't, then
it can't and the argument become moot.
|> > No. Because the number is not the only designator. By definition,
|> > collisions in order designation are "don't care". This is because if
|>
|> Again, you can always append to the file if it is a "don't care",
> It's a matter of how simply the logic can be applied. With the numbered
> file technique, it is generally a simple matter to nail down the sparse
> sequence points that are likely to be significant (NFS started, etc.)
So the numbers also become run levels (being how much we've started running).
Great. Back to argument #1. :-)
> Once that has been done, the install scripts can be written with a priori
> knowlege and hard-coded sequence numbers. In the file editing case, the
> installation script must be able to recognize the proper insertion point
For 99% of cases, just append to the file. You only need to "find the
correct point" if you are inserting into the middle of a process chain.
Which will probably be a very rare condition, unless you are replacing
one startup command with another, in which case the position is
already determined for you.
> by examining the file at run time. (And if that doesn't scare you, think
> about scripts trying to automatically -remove- services from the script.
> If you still aren't scared, you haven't been a sysadmin for long enough.)
Granted. Having things remove from a control file requires good
solid coding.
So does having a script remove a file automatically from the startup
directory set, when the name has been permuted with command prefixes
(S## or K##).
I've worked with both types of systems, and I really have never found
one to be more dangerous or less dependable than the other.
> |> That's the whole point of everything we're doing. Give the average
> |> person on the street a system that they can understand and maintain.
> |> Personally, I'd rather me (the designer/programmer) spend the time to
> |> make their lives easier, since that generates a larger customer/user base.
> Great plan. But in this situation, it suffers badly from diminishing
> returns. You are talking about implementing a complex installation
> and removal system to allow for a run-time system which only appears
If we automate things, we either do it right or we screw up a lot of things.
That holds regardless of the automation procedure, or how the underlying
layers are implemented.
> Actually, I find the SysV/Solaris2 technique -easier- to understand and
> work with.
As I said, it's a matter of personal preference.
|> > +> Yes, this relies upon implicit order (whatever "find" returns), which I
|> > +> really don't like. But I couldn't see any other option, and if you
|>
|> > fairly simple: pick a number after the number of the packages you depend
|> > on, but low enough that other packages may depend on you without
|> > overflowing the lexical name space. I'd suggest 3 digits rather
|> > than 2 as a guard
|>
|> Or use file order, in which case your numbering limit is maximum number
|> of lines in the file. Again, it quickly becomes a religious battle of
|> which people prefer - numbered scripts or a control file.
> No, it isn't a purely religious battle over preferences - it is a very
> real battle over safety-and-simplicity -vs- perceived-simplicity and
> tradition.
No. It's which you see as simpler and safer vs. which I see as simpler
and safer.
I've built systems using my methods. They work. They are dependable.
I've seen and worked with (but not written) systems that use your
(and SysV) method. They work. They are dependable.
Both work. They simply do things in different ways. Both make seperate
assumptions and take divergent risks. Both are dependable if
implemented well. And if they are not implemented well, then we
hit an entirely different argument.
So we pick one path, and some subset of people become unhappy, or we
implement both, and put in extra work (but get good results for it)
or we give up on the entire concept, and stay with what we have.
Think about this:
When the argument comes up, "Which should I use? FreeBSD or Linux?",
the answer I invariable see from the core team is "Try them both
and decide for yourself". So I say let's implement both, do a great
job on both, and see which people like.
If they like both, we keep both. If they don't we drop the one that
noone likes.
-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?199509260401.AAA14675>