site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com In message <FDA5D523-209F-4BFC-B95A-253809669F99@freebsd.org>, Michael Smith wr ites:

Wow. I can't actually say that I've seen such a collection of reactionary curmudgeonery in, well, a very long time.

Not a Usenet reader? :)

Given that no other system you're going to touch with a ten-foot pole supports this in the first place, what do you expect? Freebies?

Well, ideally, any kind of bone at all tossed to the notion of minimally intrusive designs; otherwise, one of the much vaunted advantages of launchd ("it's less work!!") goes away.

As has been pointed out, on Mac OS and many other systems, disks come and go. If you are going to handle this at all, then you might as well accept that any volume other than the one you were loaded from may come and go at any time, in which case startup is just a special case.

It's been a long time since the RA-81. You can actually pick a disk up and put it in your pocket, and this has changed the way people use them. You can't pretend that adding a new disk to the system must necessitate an electrician and a forklift anymore.

But I can observe that, in practice, servers don't change system-level volumes that services depend on, unless they're doing real maintenance during which the service *can't run anyway*.

...

It may or may not. I just don't find myself convinced that every daemon in the world should acquire all this extra sanity-checking. I like to isolate repetitive tasks; I would rather see ONE program to dependency checking than DOZENS.

Like, say, launchd? I think you've swapped ends here...

Exactly. **I WANT LAUNCHD TO DO THIS CHECKING, RATHER THAN EVERY SEPARATE PROGRAM**. Right now, launchd *requires* that every program it's going to run do its own dependency checking. That's WORSE than what I had before.

Mac OS X has the largest installed base of any Unix-like operating system. Period.

Yes. Almost none of which are servers.

It's the only Unix-like operating system that takes the desktop environment seriously. Period.

Which doesn't have much effect on services.

It's the only Unix-like operating system that is attempting to adapt the way that the system thinks about people, rather than the other way around. Period.

Er, no. Launchd is, right or wrong, an absolutely crystal clear example of a system declaring "no matter what is convenient for you, THIS IS WHAT YOU MUST DO." You are not allowed to have the system do the dependency work for you.

And thus you get portable, standard, lowest-common-denominator behaviour.

Yup. And since that happens to, today, be BETTER for starting many services than what launchd offers, with LESS EFFORT, that seems like a likely continued state. Launchd, if it's going to see real success outside of the enforced conformance of the Mac, is going to have to offer some kind of solution to the very real problem of dependency management. Having the solution be "every one of the hundreds if not thousands of jobs and daemons that will ever be written must have entire modules to handle dependency checking because we don't want to" is not a solution to the problem; it's a bald assertion that there never was any problem.

As has already been pointed out, if you want to act like a piece of code from the 1970s, that facility is available. There are good reasons not to, some of which are consequent on the points I just made above.

But that facility is going away.

...

wrong. Dependency checking is not something that should be duplicated in every program.

I don't see your point; this is exactly what Dave & co. are asserting with the launchd service dependency design.

Huh?

As a service provider, you advertise your services passively.

As a service consumer, you attempt to consume said services.

The latter results in the invocation of the former.

Where is there any sort of "dependency checking" in the consumer, or for that matter in the provider?

In the attempt to consume said services. Once again, the two most common cases I can think of are sockets and filesystem access. Neither offers a way to indicate "this service isn't available now but will be soon, please try again in a bit".

Launchd will happily spoof local sockets, so I don't see a counterexample there.

Okay. So, when I try to talk to my socket-based service, how do I know whether it's permanently unavailable or just a bit slow?

As previously noted, if by "file access" you mean "the presence of a magic file" then it's down to the vector that presents the file. If you're expecting it to arrive via filesystem mount, then DiskArbitration does everything you want and a great deal more.

Uhm. So, instead of starting my program after filesystem mounts, I'm supposed to write a chunk of brand new system-specific code that queries a brand new service to see whether a disk is available? I thought launchd was abstracting away service dependencies. This is a dependency I apparently have to manually encode and check myself, now?

If you are talking about a passive or implicit rendezvous (e.g. waiting for a PID file before attempting to contact a local service by some other means), then you are typically looking at an arrangement that tries to avoid a problem that the launchd model has made obsolete. You can remove code in this case... should make you happier again. 8)

Well, the obvious examples are things like configuration files.

...

Which are, by strange coincidence, 99% of UNIX services.

But by no means 99% of the services available on a Mac OS X system.

True. In part, because Mac OS X, even Server, really isn't going after the traditional server market right now. In part because, without dependancy checking, it's cheaper to buy a UNIX box than to figure out how to get a service running under launchd.

My opening point about reactionary behaviour and obstinacy bears some restatement. As Dave and Kevin and others have pointed out here, the launchd architecture is trying to solve some fundamental, undeniable problems with the way that services are invoked and managed.

Yes. And I think the problem is that it's done an absolutely BRILLIANT job of replacing cron and inetd. I just don't think the system startup tasks are the same category of tasks. Launchd's handling of on-demand service is absolutely delightful. I would like to see launchd added to other systems to replace inetd (bleh), xinetd (pfui!), cron (meh), and the dozens of system-specific one-off "relaunch this when it fails" scripts that every large system develops. But I don't think it can, or should, replace system startup. These are fundamentally different types of tasks, and I think the attempt to coerce that square peg into launchd's brilliantly perfectly round hole is not working.

Change is pain, and you really have just two choices; impede the process and contribute nothing, or align yourself with it and help these folks improve the world a little.

I've suggested the obvious improvement: Stop trying to crowbar system startup into launchd. Use it for on-demand services and other things that can be started "once the system is up". It is without doubt the best implementation I've ever seen of either inetd or cron functionality, and I'd happily take launchd over both of those any day of the week. But no matter how absolutely beautiful this knife is, it's not a spoon. -s _______________________________________________ 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... This email sent to site_archiver@lists.apple.com