On Jun 2, 2006, at 10:17 PM, Peter Seebach wrote: And since 10.4, getting even fairly trivial daemons started at a time when the system provides the services they need is annoying, and following the instructions given in the man page can wedge a system permanently at a blue screen.
I didn't say it was impossible; I said I didn't think it's a "good tool". It's obviously possible to do the bootstrapping that way; I just don't think it's a very good tool for the job.
Maybe this whole conversation would be easier if you (and some of the others in this conversation) could more precisely describe just what it is you want launchd to do, rather than making this an ongoing retro argument where we stick on our grey beards and debate the usefulness of StartupItems, /etc/rc.d, SYSV runlevels and so on.
Clearly, launchd is the direction we're headed. Just as clearly (I hope), launchd has the option of creating helpers which keep its internal design clean yet provide various bits of useful functionality. One example of this in action is the interaction between the well-known tcp_wrappers and existing mechanisms like [x]inetd. Rather than jam a whole access control system into inetd, a bright guy named Wietse wisely decided "hey, I'll just write an interposing mechanism that adds all the access control knobs without having to redesign or change inetd in any way" and, what do you know, it worked great.
Similarly, a lot of useful wrappers could be created for launchd, including but not limited to wrappers which allow arbitrary ordering of services through notifications. I was kind of curious as to how hard it might be to write such a thing with notify(3) and it took all of 20 minutes to write a fairly functional ordered-launch wrapper for launchd, so either I'm badly underestimating your needs (hence the question in the first paragraph) or we've spent far too much time discussing and not enough time doing actual engineering during this thread.
- Jordan
|