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).

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.

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.

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 find it ironic that you complain about imapd having a fixed configuration. That's about as "uniform and performant" as you can get.

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.

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.

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.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Reply via email to