Re: StartupItems
Re: StartupItems
- Subject: Re: StartupItems
- From: Dan Shoop <email@hidden>
- Date: Tue, 23 May 2006 14:03:33 -0400
At 1:33 AM -0500 5/23/06, Peter Seebach wrote:
In message <email@hidden>,
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? :)
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?
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*.
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.
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.
And almost none of which have suitable mechanisms for handling this at all.
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.
--
-dhan
------------------------------------------------------------------------
Dan Shoop AIM: iWiring
Systems & Networks Architect http://www.ustsvs.com/
email@hidden 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden