site_archiver@lists.apple.com Delivered-To: Darwin-dev@lists.apple.com Thread-index: AcZ9/nS3s443dunxEdqmXQAKlbpFBg== Thread-topic: StartupItems User-agent: Microsoft-Entourage/11.2.3.060209 On 5/22/06, Peter Seebach <seebs@plethora.net> 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 (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