site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Summary: the rc architecture is designed to support a "start once" model, with any dynamic restarting being done manually and in a controlled manner by a sysadmin. As soon as you create an environment where it's allowed and even expected that the goalpost can move at any time and the system should chase them then the rc system quickly shows its flaws. Since you have to support this dynamic system anyway, why not make startup work the same way, rather than special-case it? UNIX philosophy at work, mostly; 10% of the code solves 90% of the problem. For a huge variety of common cases, dependency ordering is simpler; that means it requires less code, and that means it's less likely to be buggy. I can see encouraging better support for dynamic code; what mystifies me is simply declaring, by fiat, that the majority of existing programs that depend on dependency ordering are definitionally not worth running, and it's not worth providing the hooks to run them. -pmb _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... At 3:42 AM -0500 6/1/06, Peter Seebach wrote: In message <447E9356.6060600@nicta.com.au>, Andrew White writes: You are mischaracterizing our response. Launchd does indeed provide the hooks needed to create static dependency ordering based on strings. For example, you could configure items to trigger off files in /var/run. But none of Apple's "startup items" plan to publish any such strings. You're free to use that mechanism for your own things; it's just not adequate for the stuff the system ships with. System services will publish their "provides" tokens as actual IPC channels instead of strings representing those channels. What mystifies me is why you can't see that launchd is capable of doing what you're asking for, even though we don't choose to use it that way. This email sent to site_archiver@lists.apple.com