Re: StartupItems
Re: StartupItems
- Subject: Re: StartupItems
- From: John Siracusa <email@hidden>
- Date: Mon, 22 May 2006 20:18:46 -0400
- Thread-topic: StartupItems
On 5/22/06, Peter Seebach <email@hidden> wrote:
> My objection here is not to the basic idea of the launchd model for many
> things; I think it is hands down the best way I've seen to handle inetd/cron
> jobs or their equivalents. I just think it's doing an awful job of replacing
> rc.d/startupitems. It's good for on-demand launches; it's not doing nearly
> as good a job of startup. [...]
>
> Philosophically, it's wrong about startup. It CREATES the need for daemons
> to do their own dependency checking, and requires everyone to duplicate
> all the code to handle this, add new mechanisms, and so on. It INCREASES
> code duplication.
Try looking at it from another perspective: it moves knowledge out of
your brain and into the code. Sure, maybe you know from experience
(or from R-ing TFM) exactly when each item has to start with respect
to all the others on your system(s) in your environment(s), but that's
among the most fragile systems possible. "Have someone who knows what
they're doing set it up." Or, "Copy this setup created at some point
in the past by someone who knew what they were doing."
IME, this leads to the "cutting the ends off the roast"[1] phenomenon
in the long run--if you're lucky! If you're unlucky, the "smart"
person wasn't actually that smart or just plain made a mistake (or
three). Either way, the point is that the knowledge about when and
how things should start is stored in a person--among the most
unreliable of storage mediums :)
Yes, you have the working system as an end-product, but little can be
extrapolated from it. The only knowledge stored in the system is that
"these services seem to work when launched in this order and in this
particular environment." When it comes time to add a new service, you
need that person again. And, of course, each system or project or
business or whatever needs its own smart person.
The launchd philosophy, OTOH, is to take all that knowledge and put it
in the programs themselves. Then they just get thrown into the stew
and launchd sorts them out. Need to add another service? If it's
"launchd-ready" then you just add it to the pot.
This process of changing code to work well with launchd seems
"decentralized" from the perspective of an experience Unix admin and
coder. But looking at the entire ecosystem, it's actually a
centralizing force, extracting knowledge from experienced people and
condensing it into code form, making it usable by a much wider
audience.
Even better, since all of the experienced people now have one place to
focus their knowledge--the code itself rather than each of their own
individual systems and rc files and what have you--the quality and
robustness of that code will be very good. "Many eyes" and all that
jazz. Then this work is then available to "the masses."
That's the long view, as I see it. Unix has always been way too
conservative in areas like this. Change means risk, but no change
means that nothing will ever get much better. To really improve over
the long term, practices like the careful placement of lines of text
in specially named or numbered files and directories (in one of
several different ways, depending on vendor and distant OS origins in
the 1970s) simply have to give way to more robust systems usable with
less risk by people with less knowledge and experience.[2]
Robust, that is, from the perspective of "the world," not from the
perspective of the fleshy life-form that spent 20 years leaning
exactly where and how to put the ~100 services he's familiar with in
the ~10 different OSes he's familiar with, and who will take that
knowledge to his grave. Put it in the code; it'll live longer and do
more good :)
-John
[1] http://www.snopes.com/weddings/newlywed/secret.asp
[2] "Dumbing-down" you say? Do you know the hex values of all the
instructions supported by your CPU? "Progress," I say.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden