May 2006 - Darwin-dev - lists.apple.com

Re: StartupItems
by Dan Shoop 23 May '06

23 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com >reactionary curmudgeonery in, well, a very long time. 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*. 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. And almost none of which have suitable mechanisms for handling this at all. -dhan ------------------------------------------------------------------------ Dan Shoop AIM: iWiring Systems & Networks Architect http://www.ustsvs.com/ shoop(a)iwiring.net http://www.iwiring.net/ 1-714-363-1174 pgp key fingerprint: FAC0 9434 B5A5 24A8 D0AF 12B1 7840 3BE7 3736 DE0B iWiring provides systems and networks support for Mac OS X, unix, and Open Source application technologies at affordable rates. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… At 1:33 AM -0500 5/23/06, Peter Seebach wrote: In message <FDA5D523-209F-4BFC-B95A-253809669F99(a)freebsd.org>, Michael Smith wr ites: Wow. I can't actually say that I've seen such a collection of Not a Usenet reader? :) Mac-dweebs react poorly to curmudgeonery because they're more used to warm-fuzziness of other Mac users and flower children and rarely make it to usenet or lists where Nomex underwear are often needed. >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. I find it surprising that anyone thinks the RA-81 was among time ago. It hasn't been that long, has it? I observer that volumes drop on and off the system all the time. Firewire drives are the prime example. They seem to drop off the system at time when they're really still there (or should have been) and this can result in the system beachballing unrecoverably. Likewise I have an Exabyte tape drive that seems to do this at the most inopportune times (like during the middle of a backup) on a XServe. These are volumes and devices that are expected to be there and either disappear or have other failures and being able to handle such faults will improve the general stability of the OS. Mac OS X has the largest installed base of any Unix-like operating system. Period. Yes. Almost none of which are servers. And if you think that the rc.d mechanism used so commonly today is an improvement or so great try answering the following common question: "what letter/number/name should I make my rc file to start up X? Which rc directory should it go under?" Such mechanisms are a huge step backwards and unbelievably fragile. At 10:45 PM -1000 5/22/06, Jordan K. Hubbard wrote: That VAX 11/780 sitting in its special, air conditioned machine room was up 24/7 and never had any concept of "sleep/wake", nor did it have to care about how much power it used or heat it generated (if you could afford a VAX, you could afford the power costs and the AC infrastructure). Actually the VAX was /very/ affordable, which was why it was so popular. It was the Mac of it's day in that it provided a powerful entry level computer for the masses. And I remember these same sorts of arguments then too. The VAX introduced so many new concepts and mechanisms that today we take for granted but met with huge resistance in the day. RSX users fumed at how the OS made them change the way they did things, yet didn't seem to mind when it meant all the problems they had been having and had to account for disappeared. At 10:45 PM -1000 5/22/06, Jordan K. Hubbard wrote: Its network interfaces, as well as its hard drives and other peripherals, were hard-wired and never changed, at least not without all kinds of administrative warning and declared flag days which involved bringing the machine down completely for reconfiguration. This certainly wasn't true of VMS. I doubt it was true of any OS on the VAX. That VAX-11/780 most likely shipped with an RP-07 or RM-05 and those volumes changed relatively often. In fact I'd say that the volumes in today's Power Mac G5 are far more "fixed" than those. VMS also handled these transitions, when they were unexpected either by the OS, the operators, or the applications, much better than most systems today. Of course it accomplished this by having some mechanisms that seemed heavy handed to the systems dweebs who were accustom to more lazie faire mechanisms. OS X is making some very serious strides in bringing *nix systems some degree of modernity. That this comes at new sets of rules should not be historically surprising. If you want the lazie faire system that you have total control over then use another OS. I doubt OS X is ever going to be an "embeded" OS, nor is it designed to be something stripped down and offering nothing, which traditionally has been the unix minimalist offering. I agree that forward looking system mechanisms can be disruptive to the current order and may not immediately play well with others. However in the case of launchd it's already consolidated a whole bunch of competing technologies. Before launchd explaining to someone the system bootstrap, IPL, initialization of the OS, launching of services, et cetera was like pointing to a bag of screaming cats and calling it a "service". Sure each of those cats could perform a trick, but it was a mess to deal with and even harder to point to one and say that was the one someone needed to take a look at when there was a problem. launchd solves this and fits very nicely with the concepts that mach teaches us. Yes it may be painful today to switch to a new model with new requirements and restrictions, but it's currently a world of pain every time you have to jump into that bag of cats. -- This email sent to site_archiver(a)lists.apple.com

1 0

Dependancies, theory and practice (Was: StartupItems)
by Dave Zarzycki 23 May '06

23 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: StartupItems
by Marc Epard 23 May '06

23 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcZ+bNFRECUjnepgEdqoNQANk21umg== Thread-topic: StartupItems User-agent: Microsoft-Entourage/11.2.3.060209 on 5/23/06 1:33 AM, Peter Seebach wrote: >> 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? If it's not configured in launchd, launchd won't be listening on the socket. If it is configured, launchd will start the service on demand without needing an explicit dependency outside the code. If that service requires other services, launchd will take care of those in the same fashion. I think you're too worried about needing special code. Most things just work without any special code. Just connect to the socket you need or make the API call that results in IPC. Launchd will take care of the dependencies for you. No special code is needed. No configuration file is needed for clients. It seems to me the only solid example you've given that launchd doesn't currently take care of automatically is a specific volume coming on-line. File a bug requesting that. I'm quite happy not to need to mess with startupitems for our products anymore. It is much easier now to be confident our product will work as the system changes. -Marc _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: StartupItems
by Jordan K. Hubbard 23 May '06

23 May '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com On May 22, 2006, at 11:18 PM, Peter Seebach wrote: I disagree. Which, it seems to me, makes the cost of doing dependency checking and ordering fairly low. So why not do it? I don't see why this is so difficult to understand. - Jordan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I don't know about that. Modern servers still have to manage some level of consistency, or *services stop working*. And until we have the time, budget, and inclination to rewrite everything from named to apache, servers are still going to depend on some amount of stability. I'm not sure what this is an argument in favor of, to be honest. It almost sounds like you're saying something to the effect of: "Servers break if you change them, thus forcing you not to change them. Ergo, servers don't have a problem with change!" Even if that sort of logic was a comfort to you, our problem spaces encompasses the desktop as well as the server (and, if you look at the demographics, desktops are in the overwhelming majority) so it's ultimately not very comforting either way. I think we have a lot of software which is doing just fine, with people consistently able to make 3-4 9's of uptime, and some of the more stable systems doing 5+. "Doing just fine" is such a relative judgement that I think we're going to simply have to agree to disagree here. There's no question that there's a lot of dusty deck software out there and, if that whole Y2K thing hadn't happened, one might have even been able to extend the "just fine the way it is" umbrella to cover several million lines of COBOL code too. For that matter, there are still PDP-8 systems doing process control in various woolen mills around the U.S. No need to change them out, they're doing a fine job with more 9's worth of uptime than you've probably ever seen. The term "borrowed time" comes to mind, however, for both the PDP-8s and much of that software you're talking about. Ultimately, some change in the market or technology is going to push that stuff into obsolescence. And yet, Linux and BSD systems are able to do it just by starting services in a specified order, and have been doing so for a decade or more. I think we've already covered the fact that Linux and BSD systems aren't attempting to do all the things that MacOSX is trying to do. If all you want to do is run a web server, you can do that on a CHIP these days, you don't even need a dedicated UNIX server. If you want a small handful of services, fine, build a BSD or Linux box - heck, since it's single purpose, just start your services out of /etc/ rc - why even bother with startup item abstractions? Oh, you want flexibility too? Now you're on the slope that ultimately leads to launchd (I know you'll disagree there, but we can agree to disagree here too). Omitting a feature and blaming the people who provide it for being "slow" is pure propaganda. I think we disagree on it being a feature, otherwise it wouldn't be slated for deprecation. Because it's fundamentally flawed, for many of the reasons John S. spelled out earlier. Some person who thinks they understand the system essentially hard-codes a dependency chain of A, B, C and D. Then, later, C is upgraded to no longer even need D (this kind of thing happens ALL the time) but hey, the people who maintain C don't have anything to do with the "startup items" for system X, so D is now stupidly and unnecessarily started but hey, it still works so nobody notices they're paying a penalty for no reason. Then, later, B develops a dependency on C and, in some cases, F. F, however, didn't even exist when the startup chain was coded up, so now you have B sometimes mysteriously failing to work for reasons that escape the current crop of sysadmins (did I mention that the original guy has long since fled to Bogota?). That's the SIMPLE example, with only 5 items. Multiply it out and you have a problem of quadratically increasing complexity. With launchd, on the other hand, everybody just checks in and says "I provide foo" and anyone, anywhere, who asks for foo gets it. Simple. They can ask for it always, they can ask for it sometimes, they can decide to stop asking for it altogether in a future release and things Just Work as long as everyone plays by the rules (and this is not a constraint imposed uniquely by launchd - all formal systems have rules). This email sent to site_archiver(a)lists.apple.com

1 0

Re: StartupItems
by seebs＠plethora.net 23 May '06

23 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com In message <4472D0D3.8000002(a)teaching.physics.ox.ac.uk>, Graham J Lee writes: >I think the argument would be that system startup is just a specific >example of the general case "something interesting happened and I want >to be run because of it", and that launchd deals with the happening of >interesting things. I'd agree with that, if it were the argument :-) Hmm. Well, that suggests a way to resolve this fairly elegantly; just provide a hook in plists for having services Do Something which causes other services to run. So, say, you add a tag like <key>StartupDone</key> <string>Gzornenplatzen</string> in some plists, and in others, you have <key>StartupAfter</key> <string>Gzornenplatzen</string> Bam. Nice generic way to put the "something happened and I want to be run" *IN LAUNCHD WHERE IT BELONGS* rather than having all the applications sit around inventing new notification methods and writing their own code. That's the thing; in many cases, it's utterly trivial to explain what ordering I want. If I have an ordering tool, I need one or two lines of code somewhere. If I have to do all the arbitration by hand, I can end up doing callbacks and daemon communications in two or three different protocols at once. Which goes against the idea of a unified launcher which hides this complexity. >As a sysadmin, launchd's allowed me to consolidate a mess of crontabs, >inetd/xinetd configurations, watchdog configurations[1], StartupItems >and custom rc.local files into a mess of plists looked at by just two >tools[2]. Still speaking as a sysadmin I tend to think of programs that >aren't launchd-ready as being so last century (what with there probably >being an order of magnitude more Tiger users than any other Unix >distribution, apart from maybe panther) and in need of some updating. Some programs can be trivially updated, although in practice, I'd bet that nearly nothing is completely "launchd-ready" in terms of surviving edge conditions ("I put /Applications on a USB disk that takes a minute to power up"). >Of course, my dev hat reminds me how much work that can involve... Yeah. -s _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: StartupItems
by seebs＠plethora.net 23 May '06

23 May '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com In message <1FA25CCA-C739-4094-8919-1444957D7AC1(a)apple.com>, "Jordan K. Hubbard " writes: >warning and declared flag days which involved bringing the machine >down completely for reconfiguration. These are only a few examples >of the environment that UNIX grew up in, an environment which now >couldn't be more different. I don't know about that. Modern servers still have to manage some level of consistency, or *services stop working*. And until we have the time, budget, and inclination to rewrite everything from named to apache, servers are still going to depend on some amount of stability. >You also insist on knowing just which decade this "transition" >occurred in and when your code should have become more savvy, >ignoring the fact that the question is essentially irrelevant. The >situation we're NOW in is all that matters, and that situation is a >very dynamic one which software either needs to cope with or be >deemed broken, and yeah, we currently have a lot of broken software >in need of fixing. I disagree. I think we have a lot of software which is doing just fine, with people consistently able to make 3-4 9's of uptime, and some of the more stable systems doing 5+. I guess, I don't feel comfortable asserting that it's a flaw in the silverware that it falls on the floor when we yank the tablecloth out from under it. >Launchd is but one arrow in this quiver, as are the various >notification mechanisms (notify(3), configd, et al) which provide >ways of finding out when things like "disk availability" have >occurred WITHOUT "constantly checking" (to use your suggestion) in a >performance-impacting way. I'm also sure that none of these >mechanisms are close to perfect or all-encompassing, which is why we >need people to file radars asking for enhancements. Good point. >You need to launch on the arrival of data on a UNIX domain socket? >I'm sure it could be arranged, and I think Dave is already working on >this, but that's an excellent type of enhancement request to make. Actually, what I want is the opposite; I want a way to determine whether there's anything listening yet. Since I have to do my dependency management myself. >In other cases, software (yours and other people's) >will simply have to become more sophisticated in the way it >interoperates with the rest of the system and responds to >configuration changes. The fact that so much software currently does >NOT do so is a major contributing factor to the dreaded Spinning >Pizza Of Death (SPOD) that we see way way waaaaay too much of in >Tiger. Hmm. And yet, Linux and BSD systems are able to do it just by starting services in a specified order, and have been doing so for a decade or more. >You're also on darwin-dev, a list which is specifically dedicated to >dealing with MacOSX-related issues. We're interested in "general >UNIX problems", to be sure, but a solution which only works on MacOSX >is still a solution. Well, not all of us are here for the same reasons. I'm here because I'm very interested in OS X, but partially because I don't think it's quite ready for prime time as a server. >If other UNIXen are interested in solving some >or all of the sorts of problems I've talked about then we'll be more >than happy to investigate their solutions as well, but please don't >suggest that we're all constrained to run only as fast as the slowest >runner. That's merely an argument for mediocrity and maintaining a >status-quo which frankly sucks. Omitting a feature and blaming the people who provide it for being "slow" is pure propaganda. Right now, one of the reasons I recommend against OS X in a server role is that it requires a lot more work to make a service on OS X than it does on BSD or Linux. Suggesting that it would work okay if only I were willing to put even more time into duplicating work that ought to have been done, once, in a centralized way, does not improve this. >It's 2006 already - enough with the >clinging to 80's technologies and approaches which could not possibly >have anticipated the world we have today. There's more power in this >laptop I'm typing on than probably existed in my entire machine room >back in 1980! Yes. Which, it seems to me, makes the cost of doing dependency checking and ordering fairly low. So why not do it? CPU time is not the big issue; programmer time is. If we're going to have every application do its own dependency checking so the system doesn't have to break a sweat to launch everything, why not go a step further and remove the read/write system calls, suggesting that people go straight to the disk services and do the filesystem work themselves? It's the same thing. It's an operating system. It should provide services and management FOR applications. Not demand that they do the work themselves. -s _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: StartupItems
by Graham J Lee 23 May '06

23 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 1.5.0.2 (Macintosh/20060308) In message <FDA5D523-209F-4BFC-B95A-253809669F99(a)freebsd.org>, Michael Smith wr ites: Of course, my dev hat reminds me how much work that can involve... Cheers, Graham. On 23/5/06 07:33, Peter Seebach wrote: 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". I think the argument would be that system startup is just a specific example of the general case "something interesting happened and I want to be run because of it", and that launchd deals with the happening of interesting things. I'd agree with that, if it were the argument :-) As a sysadmin, launchd's allowed me to consolidate a mess of crontabs, inetd/xinetd configurations, watchdog configurations[1], StartupItems and custom rc.local files into a mess of plists looked at by just two tools[2]. Still speaking as a sysadmin I tend to think of programs that aren't launchd-ready as being so last century (what with there probably being an order of magnitude more Tiger users than any other Unix distribution, apart from maybe panther) and in need of some updating. [1]which joker decided that they wanted *both* types of init? [2]launchd, and an arbiter tool to take care of things like TCP wrappering and so on. -- Graham Lee UNIX Systems Manager, Oxford Physics Practical Course http://users.ox.ac.uk/~wadh1342 _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: StartupItems
by Jordan K. Hubbard 23 May '06

23 May '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com On May 22, 2006, at 10:25 AM, Peter Seebach wrote: - Jordan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I think it's the job of the sysadmin. Having every process constantly check for disk availability doesn't help all that much; it's load- creating, and it doesn't solve the problem. There comes a time when the UNIX philosophy should win; 10% of the coding does 90% of the job. Dealing with disk changes is probably a human task. I think you've somehow managed to entirely miss the point Kevin was trying to make. We live in a far more dynamic world than our "UNIX ancestors" ever anticipated. That VAX 11/780 sitting in its special, air conditioned machine room was up 24/7 and never had any concept of "sleep/wake", nor did it have to care about how much power it used or heat it generated (if you could afford a VAX, you could afford the power costs and the AC infrastructure). Its network interfaces, as well as its hard drives and other peripherals, were hard-wired and never changed, at least not without all kinds of administrative warning and declared flag days which involved bringing the machine down completely for reconfiguration. These are only a few examples of the environment that UNIX grew up in, an environment which now couldn't be more different. You also insist on knowing just which decade this "transition" occurred in and when your code should have become more savvy, ignoring the fact that the question is essentially irrelevant. The situation we're NOW in is all that matters, and that situation is a very dynamic one which software either needs to cope with or be deemed broken, and yeah, we currently have a lot of broken software in need of fixing. I don't know how many of our open radars are "mobility related" or "power/efficiency related" or "sleep/wake related", but you can bet that they number in the hundreds, if not thousands, and since nobody's come up with a good way to reverse time and restore us to the good old days when 640K was enough for anyone and "events" were something you put on your calendar, we've got no choice but to acknowledge the challenge and rise to it. Launchd is but one arrow in this quiver, as are the various notification mechanisms (notify(3), configd, et al) which provide ways of finding out when things like "disk availability" have occurred WITHOUT "constantly checking" (to use your suggestion) in a performance-impacting way. I'm also sure that none of these mechanisms are close to perfect or all-encompassing, which is why we need people to file radars asking for enhancements. You need to launch on the arrival of data on a UNIX domain socket? I'm sure it could be arranged, and I think Dave is already working on this, but that's an excellent type of enhancement request to make. You need a notification when a specific type of non-IPC related service becomes available? Try to clarify your needs a bit more and we'll see if there's some clever solution possible. In some cases, there will be. In other cases, software (yours and other people's) will simply have to become more sophisticated in the way it interoperates with the rest of the system and responds to configuration changes. The fact that so much software currently does NOT do so is a major contributing factor to the dreaded Spinning Pizza Of Death (SPOD) that we see way way waaaaay too much of in Tiger. Services which mutually deadlock (without even realizing it), other services which provide vital types of information and then suddenly stop providing it without so much as a notification that might allow other services to simply stop asking for (and deadlocking on) it, perhaps falling back on cached data, these (and others) are all issues which lead to SPOD and much user unhappiness. You're also on darwin-dev, a list which is specifically dedicated to dealing with MacOSX-related issues. We're interested in "general UNIX problems", to be sure, but a solution which only works on MacOSX is still a solution. If other UNIXen are interested in solving some or all of the sorts of problems I've talked about then we'll be more than happy to investigate their solutions as well, but please don't suggest that we're all constrained to run only as fast as the slowest runner. That's merely an argument for mediocrity and maintaining a status-quo which frankly sucks. It's 2006 already - enough with the clinging to 80's technologies and approaches which could not possibly have anticipated the world we have today. There's more power in this laptop I'm typing on than probably existed in my entire machine room back in 1980! This email sent to site_archiver(a)lists.apple.com

1 0

Re: StartupItems
by seebs＠plethora.net 23 May '06

23 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com In message <FDA5D523-209F-4BFC-B95A-253809669F99(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Ooops, I thought this (ppc/x86 JNI cross compile) was working
by Paul Archibald 23 May '06

23 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I was premature when I said my JNI lib was building on both platforms and running on both platforms. Turns out I can build it on the IntelMini and it will run on both the PPCPowerbook and IntelMini, but the build on the PPC only works on the PPC. Here is the makefile stuff (again): $(TARGET): $(OBJECTS) g++ -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk - o $@ -dynamiclib -install_name $(DESTDIR)/$@ $^ strip -x $@ %.o: %.cpp g++ -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk - c -O2 -o $@ $^ -I /System/Library/Frameworks/JavaVM.framework/Headers Does anyone know if there is some way to dump the default compiler options during the build, so I can see what the compilers on each platform are doing? Like a -verbose option or something? I assume that when you invoke g++ with some options, there are a bunch more options that are used by default. I think I need to put all the options in my option list to force both compilers to produce exactly the same binary. I think some unseen default option is hanging me up. BTW, the failure is a SIGSEGV that happens when I make a call into the JNI. It loads okay, but can't be called into. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0