Re: StartupItems
Re: StartupItems
- Subject: Re: StartupItems
- From: email@hidden (Peter Seebach)
- Date: Tue, 23 May 2006 04:18:08 -0500
In message <email@hidden>, "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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden