Re: StartupItems
Re: StartupItems
- Subject: Re: StartupItems
- From: André-John Mas <email@hidden>
- Date: Mon, 22 May 2006 21:15:39 -0400
Probably a suitable compromise would be come up with GUI based
utility that facilitates the creation of launchd based services. I am
not sure what sort of form it would take on, but sometimes the best
alternative is provide a suitable tool that facilitates the use of
the technology at hand.
Andre
On 22-May-06, at 18:00 , Michael Bartosh wrote:
On May 22, 2006, at 10:40 PM, Kevin Van Vechten wrote:
I'd be surprised if there is not a platform specific line of code
in your program. You can wrap your launchd support in #ifdef
__LAUNCHD__ or something equivalent. It's overstating the problem
to say that you can't have a unified code base. Adding Launchd
support is a relatively small amount of code, I know from
experience. I think your sysadmins (customers) will ultimately be
pleasantly surprised by this investment. Your server can be
automatically kept alive. This and other servers can be uniformly
launched, stopped, and queried via launchctl or programmatically.
That's fine. But what about the poor, dumb sysadmin who -can't
write code-. These guys are not developers. Most sysadmins aren't.
They take code developed by other people and deploy it themselves.
And they need consistent ordering and dependencies that they can
impose on that code.
You (Kevin) seem to acknowledge this when someone brings it up. But
the messaging from Apple seems to be 'use launchd, it's the wave of
the future!'
not
'You might want to use launchd eventually, it has some cool
features, but will create headaches for you in the short run'.
When the latter is far more accurate.
You're right. Launchd is cool. It does some very cool things. 90%
of the time those things are not accessible without dependency
checking various systems require.
I mean, at least add something to launchd.plist that can talk to
configd.. wait for specific configd states, like configd's kicker
does. That alone would make launchd -a lot- more useful.
-mb
_______________________________________________
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
_______________________________________________
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