Re: StartupItems
Re: StartupItems
- Subject: Re: StartupItems
- From: "Jordan K. Hubbard" <email@hidden>
- Date: Mon, 22 May 2006 22:45:53 -1000
On May 22, 2006, at 10:25 AM, Peter Seebach wrote:
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!
- Jordan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden