Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Sep 1995 17:27:36 -0400
From:      Coranth Gryphon <gryphon@healer.com>
To:        patl@asimov.volant.org, terry@lambert.org
Cc:        gryphon@healer.com, hackers@FreeBSD.ORG, jmb@kryten.atinc.com, peter@taronga.com
Subject:   Re: ports startup scripts
Message-ID:  <199509252127.RAA13404@healer.com>

next in thread | raw e-mail | index | archive | help
From: Terry Lambert <terry@lambert.org>
>>> Ah, but can you guarantee that the install script that inserts a
>>> few new lines is putting them in the right place?
> 
>+> Can you guarantee that the install script is going to get the numbering
>+> right if we go with implicit order based upon script name?

> Yes, actually.  By using a sparse numeric order designator at the front
> of the name to enforce ordering by strict lexical (numeric) order.  Like
> numbering your lines by 10 or 100 in a BASIC program.

Like it adds to the end of the file. Or adds to the first (or fourth or ...)
line after its dependancy.

> +> Or worse, is every install going to check to make sure that no other
> +> scripts exists which use that order number?

> 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",
unless we are allowing additions that MUST come before other things
that already exist in the startup sequence. I can think of it happening,
though I'd like to see ANY automated sequence deal gracefully with it.
And if it does, the same logic can be applied to the file edit.

It really boils down to perference of style, and...

> +> I think these are a LOT more dangerous. File order is explicit and simple.
> +> Anything else is headaches.

> You are not expected to manually edit the data.  If you want to, fine:
> you deserve headaches.  The point is to make it easy for the tools, not

It always comes down to a person trying to figure it out when something
is wrong.  I'd rather spend a little more time making the tools smarter,
so that a person has an easier time of it, than making the tools stupid,
and hoping the person is smart enought to work around that.

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.

Make things so that only long-time sys-admins with a serious understanding
of OS concepts can debug this, and such free OS's will die.

> +> If you want, put it as "mumble.daily" in /etc/bin and it will be run
> +> automatically.

> I have a problem with this.  My problem is that I want finer control
> over the granularity as part of the administrative range granted me

There is no mechanism for doing this now. Either modify the current
one with a few additional granularity levels, or let people do it
by hand (which they have to do now anyway).

I really can't see that there will be that many things that cannot conform
into the "hourly, daily, weekly, monthly" framework we are currently using.

> +> 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.

Personally, I like the control file. I can print it out, and know
exactly what will run in what order.

You like numbered scripts, you can print out a directory listing,
and know exactly what will run in what order.

Functionally, they are the same. Issues for the automation are similar
in most cases (getting the ordering right, dependancies, collisions).

You way requires sym-linked sub-dirs to control the order, mine still
holds to the same master file. The danger of mine is that packages
need to modify the master file, the danger of yours is that packages
need to make sure they put the right files and links in the right places.

> The feature we are considering is the ability to drop in add on components
> as if they were system components and provide a unified administrative
...
> It's possible to write one, but it'd be a kludge, and we all know it.

We're in agreement here. It's just a matter of seeing different ways
to implement similar concepts (gee, programmers never suffer this problem
do they :-)

> valid idea is a valid idea no matter where it comes from (I feel like

Granted. A hundered times over :-)

> The second best concept [SysV] had was run levels/states to allow staged
> "run-up" and "run-down".

I still like linear run-levels, rather than arbitrary states (and think the
former would be a LOT easier to implement).

> If you think you can present a unified view of all system
> components without seperate scripts, fine, I'd like to see a set of
> libraries for dealing with components.

Is this a tangent, or missed interpretation? I have always been in favor
of seperate scripts for each sub-system/component/package. I just want
to put them in one place and have them run from a master file, rather
than sym-links to state-based subdirectories.

And yes, I'd be very happy a combined mechanism that includes startup of
the various levels, plus the regularly scheduled daily/weekly stuff.

> I already have a GUI library that will put out the right thing from the
> same program on DOS, Windows, Mac, UNIX Text, Vanilla X, Motif, and

Great. Given a simple GUI library, I'll even do the GUI's for both parts. 

> I'll give out the termcap/X/Motif libraries.  Though I'd prefer a GUI
> based Drag-N-Drop interface, like the Mac System folder concept, I'm
> willing to throw the (IMO) less powerful paradigm out the door to get

Drag-and-Drop I really think would be frosting. If you have the
libraries for the standard GUI cake, let's go with what we have.

We can always do a different GUI later.

-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?199509252127.RAA13404>