On Mar 6, 2006, at 2:00 PM, Mark Crispin wrote:
On Mon, 6 Mar 2006, Michael Cashwell wrote:
Oh please! What standards? If there's a uniform and performant
solution that addresses system-init, network daemon listers,
system- and per-user time-scheduled execution and the like, can we
have a link to it? It was precisely this void that prompted Apple
to create launchd.
Other UNIX systems have variants, each being their respective
vendors' own idea of "improved", but along a common theme that
respects the 30+ year UNIX tradition. It is possible to transfer
knowledge of one system to another; and where the changes are
major, it is possible to use man to uncover the answer.
Apple, however, went completely off on their own, just as NeXT did
with NetInfo (creating the system where you couldn't do an ls or
much else because a DNS query didn't respond).
I've been irritated too by delays and hangs when services (especially
DNS) are down or during system bring-up, but I've not see this
recently. And I've found Red Hat systems whose behavior was FAR worse
in this regard. But these issues have more to do with poor initial
configurations than inherent design problems, IMO.
But it's worth noting that Apple doesn't just make these things up
for the fun of it. As an example, they have deprecated OpenSSL in
favor of their SecureFramework in order to support new features. (In
this case the concept of having certificates and keys on smartcards
where OpenSSL forces certificates to be in files.)
And even in doing that they didn't just roll their own code. The
framework is CDSA-based (Intel open-source) and they use the muscle
card code (also open source) for much of the smartcard heavy lifting.
Launchd is unlike anything else. You have to be of the XML
religion to like it. I've noticed that neither Linux, nor BSD, nor
System V, seems to be making any move to adopt it.
I'd argue that being unlike the existing, fractured solutions is a
requirement in order to address them. That the other vendors aren't
adopting it or doing something along the same lines is more of an
indictment against them. Inertia is a powerful thing but that doesn't
necessarily make it good.
But that aside, I really don't understand your aversion to XML
plists. It's a standard way to represent key/value data and is far
more elegant than some of the flat file formats where the ideas of
container data structures or hierarchy were grafted on as an
afterthought. I agree that XML is ugly to edit in raw form but it was
not intended to be handled that way. (No one faults JPEGs for being
hard to manipulate in a text editor!) There are decent tools for
working with plist XML.
I certainly would prefer my daemons to use XML with their own keys
than each rolling their own format from scratch. Regrettably, the
latter seems to be much more common. Plists allow me to concentrate
on the key/values I want to set and not spend time worrying about
which daemon wants commas and which want single quotes, etc.
Much is missing. For example, nowhere in any of the Apple
configuration tools is there any operation to get the modem port to
function as an incoming dialup. "man init", "man getty" and "man
ttys" all tell you things that you already knew from UNIX, but are
totally false on Mac OS X.
I freely admit that I have not done this and that some man pages are
utterly wrong. The latter has improved considerably in the last 2
years, however.
Bits and pieces of the traditional programs, configuration files,
and man pages remain. Some do nothing at all (e.g., ttys, fstab).
Others work, but unpredictably (whether your xinetd configuration
will start properly at system boot time depends completely upon
timing!). Still others actually seem to be current (e.g., /etc/
services).
A web page has a sample launchd XML equivalent of a sample xinetd
file; but it doesn't document the set of values nor does it
document the equivalent for fields that aren't in the sample xinetd
file.
I'm not sure which web page you mean here, but man launchd has "See
Also launchd.plist". That man page seems to document all the various
keys, values and behaviors pretty thoroughly.
I find it ironic that you complain about imapd having a fixed
configuration. That's about as "uniform and performant" as you can
get.
I was talking about a uniform and performant daemon launcher /
listener. Something the loose collection of init, /etc/rc, inetd,
xinetd, and cron can hardly claim to be.
As the launchd docs note, "... processes which are not directly
initiated by users might be launched from at least three different
places, and configured in at least three different ways." And there
are other side effects like having to kill processes or reboot for
changes to take effect. launchd is intended to try to bring some
uniformity to tasks that are largely similar.
My complaint with imapd wasn't that the configuration is fixed but
that it's done in the source and compiled in. Using a config file
read at startup strikes me as a widely used standard practice that
imapd doesn't follow and maintaining my configuration across releases
is made harder for it.
I couldn't help the problems caused by multiple system
configuration databases (/etc files, Yellow Pages/NIS, NetInfo),
multiple network listeners (inetd, xinetd, launchd), multiple
security packages (OpenSSL, SSPI, PAM, SecureWare, SIA, AFS,
Kerberos, POSIX,...), etc. It wasn't so bad when I wrote imapd.
Quite true, I completely agree.
But I could (and did) create a single, sane, default IMAP
configuration. In my experience, most deviations from that
configuration are unnecessary, ill-informed, and generally cause
more problems than they solve.
Indeed this is largely true. I see the frequent posts where people
complain that they cannot log into imapd using a plain-text password
or they want SSL but don't want to mess with certificates. Often they
really don't want to do what they think they want to do and your
defaults are superior.
But there are many settings that are little more than personal
preference. The two I constantly have to set are mailsubdir and
hideDotFiles. This is to counteract the negative effects of the
default settings in situations where users do a lot more in their
home directories than just email. They don't like seeing their
documents cross-pollenating with their email.
Having a sane default configuration is great but if it's implemented
in a manner that makes perfectly legitimate settings hard(er) to
maintain then it does come at some cost.
Many of these deviations are applied by third parties, who then do
not disclose what they did, nor the implications of what they did,
with their customers. Guess who ends up answering the customers'
"why doesn't it work the way it's documented" questions. Most of
the time, the solution is to replace the hacked version with a
completely unmodified one.
Yes, I've certainly seen this too and seen the problems vanish when
they just use the real distribution. Please understand, I very much
appreciate your hard work both on the toolkit and on trying to
educate people that standards are important!
And I'm certainly not in the camp that thinks Apple can do no wrong.
(Don't get me started about their private, special cases relating to
their 802.11 software!) But in my experience, they generally honor
documented standards for data structures and protocols (unlike some
vendors... ahem) but will branch out on their own in implementations
of them when there's good reason.
I do see value in launchd over the discordant mess it seeks to replace.
Cheers!
-Mike Cashwell
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
