Does launchd Beat cron? 798
Blamemyparents writes "For those who aren't Appleheads, you may not have heard that with Tiger, Apple swapped out old Unix standby cron for their own creation, launchd (Apple mentions it on their OS X page and has the man page for it up as well). Seems like it's a bit nerdy, but this changes a LOT about how *nix systems have done things for many years. Launchd is Apple's replacement for quite a few utilities, including launching and quitting quite a few different things, and getting info from the system and other running processes. This page from Ars Technica talks a bit more in depth about it. Apple has open sourced the thing, and is apparently hoping all the unix kids will take a look."
Probably not. (Score:1, Insightful)
launchd does not replace cron (Score:0, Insightful)
Re:Not a cron replacement, a init replacement (Score:4, Insightful)
Re:Not a cron replacement, a init replacement (Score:5, Insightful)
Re:Not a cron replacement, a init replacement (Score:5, Insightful)
To make it easy to edit the files both by hand and via utilities which can be written very easily by leveraging existing XML parsing libraries?
As long as it doesn't break the fundamentals... (Score:5, Insightful)
What makes UNIX superior for management and power-users is the ability to do everything you need to from command-line tools and options, and the fact that the storage for configuration is in understandable, alterable files. If those are still there...if I can still run my Apple from the shell--I'm a happy man.
The only exception to this would be cases where a vendor deliberately makes a deviation simply to introduce incompatibilities. I don't see that as the case here.
Re:sweetness (Score:1, Insightful)
4 lines on apple page? 20 lines man page? or brief description on Arstechnica (which could be more or less read as "Apple did it, so it is got to be cool")?
I would rather see D/BUS version of system wide launching mechanism. Unfortunatelly, that woulld mean that everything would have to support D/BUS, which would require a lot of rewriting.
D/BUS has very low requirements, it is running on *X and soon on Win too. What it would be nice it would be a possibility to access and work with D/BUS from low scripting level (bash, shell...). If you could register your script with system based D/BUS event?? That would be something.
Re:Ahh yes. (Score:3, Insightful)
Re:Not a cron replacement, a init replacement (Score:4, Insightful)
Well, machine parsable, heaps of validation tools to make sure you haven't shanked it, and user readable text so you can go in there and hack on it if you want.
Given that damn near every scripting tool out there has xml support, it seems like they've kept 90% of the admin-friendliness of unix config files and improved on system parsing by simply hanging off of a well proven structured document format, which standard config files most certainly lack.
Re:Against the UNIX philosophy (Score:1, Insightful)
Does it make sense to have four different tools to start tasks at three different times? (Boot, login, network invocation, periodic.)
Re:Ahh yes. (Score:2, Insightful)
Re:Not a cron replacement, a init replacement (Score:3, Insightful)
You can do parallel startup on most systems these days. Is there any reason why a daemon is necessary to improve startup time? Are shell scripts really that slow?
But beyond that, launchd also takes care of the problem of having six different types of configuration files, none of which are self-documenting or self-validating. A launchd configuration file can be validated and, if invalid (like somebody inserted a typographical error, or the file got truncated or something), discarded without interfering with system startup. That makes the system more resilient.
So it's fair to say that problems in shell scripts (that are based on syntax) are hard to isolate. I'll give you that. But why XML over say something like INI or a much simplier format?
XML is very heavy-weight (especially if you're validating it against a schema). It also quickly becomes unreadable. Startup scripts have always historically been hand-editable and hand-maintainable. While XML can be hand-edited, it's ugly and cumbersome.
I guess the typical Mac user won't care. XML configuration files are probably going to be the biggest thing keeping other Unices from picking launchd up.
Re:Not a cron replacement, a init replacement (Score:1, Insightful)
You think it's "not invented here?" I think it's "not invented correctly."
Re:Ahh yes. (Score:5, Insightful)
You're looking at this from the perspective of someone who understands and remembers the differences in a dozen config file formats. Most people don't.
Do comments in my
Re:Not a cron replacement, a init replacement (Score:4, Insightful)
XML? (Score:4, Insightful)
We need a replacement. launchd isn't it. The problem, fundamentally, is XML. XML is a problem since, fundamentally, it is very flexible formatting, and so doesn't play nice with shell scripts. You can't easily cut/sed/etc. xml files. Until we get a suite of replacement tools that can easily modify XML files from shell scripts, XML won't cut it.
One of the key things to a good system is to make easy, common things fast and easy. The minimal overhead for any program that modifies an XML file is way, way, way to large to want to use it as the standard system format.
Re:Less Compatible? (Score:5, Insightful)
Isn't half the attraction to OS X for geeks how its not that much different from Linux or BSD from the console?
I'm sure some do. But in the aggregate most users will balance something like this against the benefits gained. There are those who are also experimental enough who will try this, and if they find it to be a better implementation will then port it over to other *nix variants, leading to a new "standard".
rc.d, cron, etc. may be the way other unices do things right now, but that in and of itself is not justification enough to be married to such mechanisms in perpetuity. Sometimes it's beneficial to *cough* you know, "think different."
Submitter is NOT confused (Score:4, Insightful)
Not only that but looking at the rest of the plist syntax reveals that this thing is waaay cooler than cron. It allows you to set user, group, chroot, check dependencies, designate where to send input and output, set resource limits and whole crapload of other things. Sure you can do this all from within a script, but this thing gives you all that for free.
Re:Not a cron replacement, a init replacement (Score:5, Insightful)
Let me give you an example from my work. I designed an software monitoring system which read values from our Oracle databases, put the values into RRD files and had a flexible configuration that allowed me to quickly create new sites as copies of other sites. Also I added dependencies and suppression, etc. I designed it to _MY_ specs, what _I_ wanted. But I wrote it in a flexible manner. It's now being used by over 200 people and stands a fair chance at company wide adoption. Not because I asked what people wanted, but because I chose a good solution (not the mythical "best" solution) which worked for me (I had a complex use case fortunately), and made it easily extendable. Now people are feeding data into the system from almost everywhere, and the whole system was rearchitected from a cron job to a continiously running set of daemons. Because of the modular nature of my design it allowed for this redesign easily.
So I think what Apple did rules. They didn't ask requirements from anyone, they had a flash of inspiration, created something awesome that works good for them, and then said 'hey, if you want to use this, go ahead!'
Apple never considered asking other Unices because they wanted something that worked, and also wanted to deliver too.
Re:Submitter is confused (Score:5, Insightful)
Re:XML? (Score:3, Insightful)
Let's put it this way... how long would it take to come up with some simple awk script that will facilitate the use of cut/sed/etc. on XML files? Now, how much longer do you think it would take to address all of issues launchd addresses?
Re:No thanks. (Score:4, Insightful)
Parallel Startup
init/inetd/cron are hardly "simple" tools, they have always seemed quite complex. And, since they all do basically the same thing (start programs) there is alot of duplication of effort, and possible security holes in each app.
One of my biggest irritations when I start up linux is how long it takes to do everything. It runs each service, in the order that is specified by the requirements one at a time. There are a lot of things that can be going on at once to get everything started. For example, while I'm waiting for my clock to sync with ntp (ubuntu does it on every boot) I could also be starting the webserver. Or, while I wait for my network card to be configured with DHCP, hotplug could be starting up, or some other service that doesn't need networking.
There is a lot of waiting that happens during the startup process that could be better spent actually starting something up!
Also, with regards to XML, I think it's a great idea. You don't have to worry about the config file being syntactically invalid because it can check it against the DTD.
Re:Submitter is confused (Score:1, Insightful)
In Unix, there are many, small, specialised system utilities. Each one is thus easy to isolated, debuged, extended, fixed, etc.. (ie. small codebase). Postfix is a MTA, not a mail reader, or a NTP server or ...
Windows methodology is to have one program that does X, Y, Z because they are trivial anyway. For example, what is the point of having lpr, lpd, lpc, lpq, lprm, when all we need is "lpr {print,remove,list}" as one utility?
If Apple is adopting Windows methodology then they should not be suprised their programs will not be adopted by the UNIX world.
Re:No thanks. (Score:4, Insightful)
The problem with "how Unix works" is that there are some tasks that cannot be done by one single, simple tool. Some of those tasks cannot be done by combining existing tools either, because program interaction on a Unix system seldomly goes beyond parsing the other app's text output for some keywords and then acting on it - which is cool in some way, but mainly it's all a big ugly hack.
It's reasonable to re-think the way application startup is done, the current
Though coming from a Unix background myself, I can see why Dave Cutler hated it so much, so he basically took his ideas and created NT. Why hasn't Unix been able to catch up in all this time? We could have done it, but ironically it's the community that makes Unix strong and at the same time kills innovation completely.
Re:Submitter is confused (Score:2, Insightful)
Re:Submitter is confused (Score:4, Insightful)
We're all very impressed if you work for Apple, but the chest-thumping is getting a little tiresome.
Re:Not a cron replacement, a init replacement (Score:3, Insightful)
Re:Against the UNIX philosophy (Score:3, Insightful)
cron, init, et al. were all doing basically the same thing: starting up processes. Quite frankly, I think this system is great; I'm no Apple-head, but I have to confess that *nix boot-up can be nightmarish. On a server that's rebooted maybe once or twice a year, this is acceptable, but on a laptop, something more substantial is needed. launchd seems to provide this, and while it may do separate tasks and violate the "UNIX philosophy" to some extent, there are cases when having a unified tool for separate but similar tasks can make a system run much more cleanly.
Re:Not a cron replacement, a init replacement (Score:3, Insightful)
I've had the misfortune to fiddle with XML config files (tomcat comes to mind). Give me a sane key=value scheme anyday.
grok the improvement (Score:1, Insightful)
With some luck, LSB or equivalent project will figure out that bad directory structure + lack of decent system configuration utilities + bad command line utilities == end user unfriendly systems.
Re:Less Compatible? (Score:4, Insightful)
For a lot of us, the attraction of OS X is that it is -- finally -- a unix that doesn't suck.
Apple has done an amazing job in a few short years of replacing the stupid, archaic, and ridiculously fragmented parts of unix that have festered on it like a cancer for decades.
There are a lot of geeks who are perfectly capable of using unix (and do so on a daily basis) but f*cking hate it because there are 32 separete launch daemons, 47 different configuration file formats, and 376 different GUI permutations, all of which are mutually incompatible except for the token attempts by folks like the LSB, which everyone ignores.
The truth is that Apple is filling the role now that USC Berkeley filled years ago -- stepping back, evaluating what is there, keeping the good and replacing the bad. Unix had been in dire need of a benevolent dictator for years.
Re:Ahh yes. (Score:3, Insightful)
You misspelled "also" as "only". Having a featureful editor than groks every single config file on my system, supports context-sensitive help for each possible option, and shows me what values are legal for all of them sounds like a Good Thing. Wouldn't you like an "etc-mode" for Emacs, or GEtcEditor, or KonfigEditor, or similar?
This should also be eagerly awaited by network administrators who occasionally have to roll out the same config change to hundreds of servers. A command-line XML config file editor should be trivially easy to write, and I image "GNU etcmanager" would be available in a few months' time.
Re:Ahh yes. (Score:3, Insightful)
Furthermore, you seem to miss the point about XML. There's huge differences between XML and
Secondly, XML _is_ self-documenting while
a.dat:
123:12:adf:0:1:dog
b.dat:
userid=123:age=12:name=adf:vi_user=0:gn
And yes, self-documenting formats are indeed less compact. But the "bloat" serves a purpose: Understanding the format is easy.
So, XML does indeed solve several things. Yes, files adhering to the XML specification are a lot less compact then a file containing the pure information would be, but the "bloat" is there for a reason. I'm not a XML "fanboy" at all, and I'm certainly critical in regards to the justifyability of using XML for any and all formats, but for config files, I don't see a real problem. There's projects encoding large datafiles intirely in XML, thereby tripling the size of the datafiles... that's indeed something the phrase "unnecessary bloat" could be applied for. But for configfiles... With the average size of a configfile being what... 1K, 2K, 10K? And disks being many gigabytes large...
Lastly, XML files are both readable and editable by humans as it's a true textformat. It's not a binary file which is truly unreadable and uneditable by userfriendly texteditors, nor is it someting like a BASE64 encoded binary file. So, again I can't agree with that point either.
So, to summarize:
1. XML files are easier to store information consistently, as they allow you to put more structure in your stored information by storing it in a tree structure, which
2. XML files are self-documenting, the DTD files describe the contents the XML file should follow, and shows the user which options are available as well.
3. XML files _are_ readable and editable by humans as they are plain textfiles.
4. XML files are "bloated" because they offer _more_ then plain textfiles or minimally structured files such as
So, the
Re:Submitter is confused (Score:2, Insightful)
Are you kidding? The difference is that launchd is not a script. It's a program. You're not going to be editing it.
At least using "traditional system" you can still boot using init=/bin/bash
Single-user mode, you mean. Command-option-S at system startup. Requires you to have the Open Firmware password, of course, if the machine has one.
Re:XML? (Score:5, Insightful)
Python and Perl have perfectly robust XML i/o libraries these days. I don't think I'd mind very much writing the extra ten lines of Python code required to interface with XML, particularly if the transformation I want to do to the config file is simpler in terms of XML than it would be in terms of sed, etc.
Re:Submitter is confused (Score:3, Insightful)
There is no way to tell for sure, if course, but he seems as knowledgeable about this things as anyone around here. Yes, impostors happen. I just think we'd be better served arguing on what he says rather than on how he phrases it. Making an issue out of his usage of "we" seems a bit pedantic to me.
Re:Not a cron replacement, a init replacement (Score:1, Insightful)
Anyway, the logical extension of your argument is:
depends: network
vs
Depends: network
vs
[depends]
network
vs
depends=network
etc.
The point is that with a very small overhead to the config file, you never have any ambiguity on how that file should be parsed, created or updated. You can also look at the same file in a variety of methods (eg; html, XML, text, etc) by running it through an xslt translation.
Basically, why spend all the time, effort and expense creating code to manipulate free form config files when you can use a standardized XML library to do it?
Re:SYSV.. bah. BSD-style is the way to go. (Score:3, Insightful)
It's also easier to test startup and shutdown scripts. For instance, if I want to test the foo startup script, I just run "/etc/init.d/foo start" (or "service foo start" on some distributions). With the BSD-style startup scripts, I have to add it to another script--which makes testing part of the script more difficult and error-prone. If it's small enough, I can just cut and paste that snippet of the script, but still...
Re:Not a cron replacement, a init replacement (Score:4, Insightful)
Then why give it a confusingly daemonish name by appending a "d" to the end of it?
It's a replacement for init.
Which is a daemon. I can see that a replacement of a daemon might not have to be a daemon, but I'm wondering how that's actually implemented and I'm skeptical of your claim. At the very least you've presented this in a very confusing manner.
Re:XML plist configs are easy (Score:3, Insightful)
I'd rather deal with "hard" stuff like xml tags than "easy" stuff like switching with screen to the man page over and over again...
You scared people clearly don't understand plist files and how they represent records and lists.
plists should be used MORE than just infrequent things like rc/cron... as far as I'm concerned all configs should be plists.
As for xml being slow...a standard parser may beat a custom parser; besides, configs are not read constantly, which is why xml is well suited. (especially for rc/cron...cron: I doubt it parses unchanged files repeatedly)
Re:Submitter is confused (Score:3, Insightful)
The only thing that is different between these systems is that each specializes in certain event types...which is thin justification for a bajillion different configuration formats, if you ask me.
Re:Not a cron replacement, a init replacement (Score:4, Insightful)
Which is exactly what Apple - and the average user - wants. Hell, it's also exactly what you want for your X apps, and what you want for those 90% of times when you're configuring non-graphics apps and services through X, a web interface, or even a command-line configuration app.
The only time it falls down is when editing configuration files manually - and even then, it's still parsable by the human brain.
Now, I'm no XML fanboy. But honestly, when was the last time you edited anything more than the most trivial
Re:XML plist configs are easy (Score:5, Insightful)
1. It's not about figuring it out. Just because you can figure something out doesn't make it optimal or even non-crap.
2. The grandparent post was talking about XML in general and how it's great for configuration data. That is what I was taking issue with. You can build record/list support on top of XML, but it doesn't fit in naturally.
3. I still think the property list XML format is crap. Property lists are decent; they're not perfect, but their extreme simplicity makes them very useful. The ASCII format is great, so why would you want an XML format?
Does having an XML format lets you leverage XML tools? It might have if property list XML worked with XML instead of simply beating it into submission. Apple created a completely opaque layer on top of XML instead of integrating directly.
A natural XML equivalent would be a little more verbose: Using Apple's XML format, you'll get:The result: something that's more verbose and harder to read than even a natural XML format.
What's worse is that you can't leverage DTD/Schema as much as you could with a natural XML format.
Re:Apple's plist Format (was Re:ugh) (Score:3, Insightful)
<dictionary>
<key>item1</key>
<string>somevalue</string>
<key>item2</key>
<string>somevalue2</string>
</dictionary>
is basically useless to any other XML tool. XML format is supposedly for interoperability, so your suggestion to always unserialize into CFDictionary is not really useful.
An alternative could be:
<dictionary>
<item key="item1">
<string>somevalue</string>
</item>
<item key="item2">
<string>somevalue2</string>
</item>
</dictionary>
which would be readily digestible by any other XML parsing tool, XSL, etc.
(the value is the child of the item, rather than being an attribute, as often dictionary values can be other dictionaries, etc)
Re:Submitter is confused (Score:3, Insightful)
Look, launchd may replace more than one program, but before you immediately call it bad or "not the UNIX way" look at the problem that it is trying to solve by doing these tasks. Look at the design. Does it solve a problem? Does it do it well? Those are the questions you should address, not the number of old programs that it is replacing because that is just a silly metric.
Re:Submitter is confused (Score:1, Insightful)
The problem with traditional Unix configuration files is that they're not self-validating. A single typographical error can very easily result in an unbootable system.
This is exactly right. That's why XML is the most bone-headed, inappropriate, stupid choice for critical system configuration.
You've replaced simple line-oriented formats with a complex, unfriendly, free-form, stream-oriented format. For certain things I suppose XML is appropriate. But for simple things like cron, init, etc., it's a mistake.
I would much rather see something like, say, daemontools where files in a directory are used to configure services. That's reliable, scriptable, easy to automate, edit, etc. Either a file is there, or it isn't. If a file is invalid, just *that file* is ignored. I have no idea what happens if I started dropping random bytes into a property list file. I have no idea how to use a sed one-liner to edit an arbitrary XML file. I have no idea if Apple's tools *atomically* replace elements in a property list. For instance it's trivial to script daemontools so that a power failure or reboot at any time will leave everything in a consistent state. If I run an installer with Apple's tools, is this guaranteed? Is it guaranteed because of obvious simplicity or because somebody at apple "thought it through" and is "pretty sure" it will do the right thing?
Who watches the watchdog, by the way?
These questions have to be answered before I'll feel comfortable admin'ing a system with launchd. My bloat detector is pegged at 10 on this one.
Re:Submitter is confused - Parent Insightful? (Score:2, Insightful)
Because the source is easier to understand? If there is a problem with one subsystem you can turn it off without affecting another? I can turn off atd and have cron running. I can turn off inetd if I don't need it. I can modify inetd without worrying about messing init.
What if there is a security hole in their daemon? I can't turn it off (or remove it) because that would kill the system. If there is a security hole in cron or inetd, I can remove those.
Put away your "windoze suxors" fanboy attitude for a moment and take a look at the bloody thing before you judge.
Where did I say "windoze suxors"? I think you need to lay off that acid a bit (or crack!) My post implied I didn't like Windows methodology (which I don't), not that "widoze suxors".
Re:Not a cron replacement, a init replacement (Score:3, Insightful)
Which is why it's excellent for config files. You *shouldn't* be editing config files directly, by hand, with no input validation. You should be using some sort of configuration tool to do it. That XML is human-readable enough to edit it by hand *if you have to*, is a nice bonus.
Re:Less Compatible? (Score:4, Insightful)
Damn straight. I love my work as a sysadmin, but I *hate* having to put up with the crap "unix" requires to do a good job. Which is why I don't run it on my desktop.
launchd summary (Score:1, Insightful)
- Not Free Software.
- Violates Unix Design Ethics.
- Proof that even the best proprietary development teams still don't "get it".
Thanks, Steve, please try again.
Re:Less Compatible? (Score:1, Insightful)
But that's not really Apple, is it? It's Steve Jobs. He started it with Next and just kept going when he came back to Apple.
Re:Submitter is confused (Score:5, Insightful)
Good question.
Let's look at it. When are programs run? The simplest answer is "when they need to."
No, I'm not being snide, merely rhetorical. When do programs need to run?
Programs need to run for a variety of reasons. Some need to to run when the machine is booted. Others need to run at particular times. Some, like certain network server processes are needed only when a user or another program requests service (e.g. accept connections on protocol/port). Others are spool oriented programs where files in a queue directory need to be processed when present but have no work to do when the queue is empty.
So rc scripts run programs at boot time which either do some work and die or act as standalone servers which are intended to live forever (or until they are explicitly told to stop).
init runs programs (like getty processes) which are long lived and are respawned when they die.
inetd/xinetd listens for connection attempts to network ports and spawns server processes on ports.
cron runs programs based on a schedule, the passage across a point in time triggers execution.
launchd provides a superset of the above triggers for spawning programs.
Think of it as
Run Program [ProgramArgs] [ TemporalTrigger | ServiceRequiredTrigger ]
By default, the simplest launchd file says "Run this program now just once.". It is thus a simple rc script which, at boot time, runs something and at shutdown time can be told to stop. Adding a further key/value pair can say "restart on exit," thus replacing inittab/init based functionality. Specifying a family/protocol/port says listen and start me when needed to serve a network request al a inet. Adding a qualifier to this type of socket definition says connect() to an address, instead of the more typical bind()/listen()/accept(). Specifying time based activation covers cron functionality, if you need at functionality specify the environment variable and working directory as well. To enable spool-like behavior or programs tied to arbitrary file system activity watch a file or directory for changes.
Most Unix subsytems only support system level operation. launchd distinguishes whether a process description is system wide or based on user login simply by where the file is found. A launchd plist file found in a LaunchDaemons directory will be loaded on system startup. One found in a LaunchAgents directory will load when a user logs in, and unload on logout. The syntax of the file will be identical in either case.
So, the launchd plist files (short for property lists) contain a set of key/value pairs describing what to run, and when to run it. Beyond this, launchd defines keys which tailor how the program is run, all of which are optional. These include specifying: user and group by either name or uig/gid; working directory, chroot directory, a dictionary of environment variables, CPU niceness, umask. Do you want to limit how much memory or stack it uses, prevent it from wiring system memory? Do you want limit the number of children it can spawn, or treat its IO requests as low priority as urgent? Keys are available for that.
So is this simpler or more complex? In the big picture I believe that this simplifies things tremendously. Launchd defines a tiny language for specifying how and when to run processes. It covers all the traditional triggers of init, rc files, cron, and inetd. It specifies the environmental and security issues of su/sudo, chroot, ulimit, umask, nice and at. It covers both system level startup/shutdown as well as user level login/logout.
Because of well chosen defaults, most launchd input files will be very short and to the point, only specifying the direct functionality they need. Adding just a few more key/value pairs can obviate the need for the majority of moderately complex rc and daemon startup files. Since launchd also obviates the need to daemonize, close files descriptors, fo
Re:Submitter is confused - Mod parent offtopic. (Score:3, Insightful)
That clause only refers to patents, and if Apple first sues you, you can sue back and not violate the APSL.
Although I can't find the details, I believe IBM's grant of patents to the OSS community has a similar requirement. The reasoning is that while most legitimate technology companies realize software patents are fundamentally foolish, they also realize they *must* acquire patents to use as defense against being sued for violating patents. If everyone is in patent violation, any lawsuit opens the doors to MAD. At least, that's the idea.
Back to Apple. The APSL grants the recipient of the code to use any relevant patents. In exchange for that "gift" (same as IBM's patent "gift"), you have to agree not to use patents against Apple. You still can, though, if you decide the infringement is serious enough to stop using ASPL licensed code.
On the whole, this is a good thing. Although it doesn't *eliminate* software patents (Apple can't do that, only Congress can), it does make them even less likely to be abused.
BSD people... I would guess they feel the same as the linux people - but that's just a guess.
The FSF says there's no problem with joining in with an APSL project. They do say you can't copy code between APSL and GPL licensed code, though, but that's pretty much the case with almost every OSS license and the GPL.
The Linux folks (not quite as unified as is being implied, but let's just generalize here for simplicity) have no problem including non-GPL software with their distributions. They also don't tend to take out patents (and especially don't sue over them!), so this clause isn't an issue.
The BSD folks are like the Linux folks, except more unified, and a bit more libertarian WRT the licensing of software.
And if you don't like the license, you can just re-implement launchd as a GPL or BSD licensed program. It duplicates effort, and I don't think the license is so unpalatable as to motivate such an undertaking, but the technology is pretty exciting. The license is a valid OSS license, so let's take advantage of it! (Ubuntu, I'm looking at *you*)
I've used Apple's mDNSResponder and Darwin Streaming Server under Linux, and it doesn't taint the license of any Linux (kernel or distribution) code, and really works *great* for the tasks at hand.
If Apple ever decided to take an adversarial stance with the OSS to any large extent, well, just remember that SCO was pretty cool back in the day.
Re:Apple's plist Format (was Re:ugh) (Score:2, Insightful)
The fact that it's improperly structured, means that nothing useful can be done with the data outside of loading it into a CFDictionary.
The parent poster 6e7a specifically ran into problems when he/she wanted to retrieve information - something that would have been trivial if the xml was formed properly.
What's the point of it being in XML if it can only be effectively loaded/manipulated with a CFDictionary? Pretty much any development tool, scripting or otherwise, already has a decent XML library available - but you think they should all have a CFDictionary interface just in case they want to operate on a property list? Or write a pile of extra code because the data is arranged crappily?
Perhaps you use XML differently than I do. I tend to use lots of XPaths, write quick and dirty reports with XSL, etc. Why do I do that? Because it makes things easier. And I can do this in pretty well any tool that has XPath support.
All of these things aren't possible in this case because Apple's property list XML isn't properly structured.
I have suggested one way that the schema could be fixed to make it compatible with the wider world of XML tools, and your response was that nobody wants to do that anyway - even though the poster who set off this subthread wanted to do exactly that.
Re:Submitter is confused (Score:1, Insightful)
Never happened. All the marketing materials are very careful to say "Unix-based." As in, "evolved from Unix." As in, "started with Unix and then got better."
The Unix philosophy is for there to be many valid and well-characterized ways.
That has never, ever been a part of the Unix philosophy by any interpretation. It's a total side-effect of the fact that everybody seems to want to write his own whatever -- service launcher, Internet superserver, periodic task running, whatever. It's a side-effect, not a design goal.
Re:ugh (Score:4, Insightful)
That sounds like a complaint made up to have something to complain about.
The idea is that you *don't* edit plists by hand, but if you have to, you can.
So, under all normal circumstances, you do things via preference panes, plist editors, the "defaults" command, etc. But if things are hosed and all you have is a boot floppy or CD with vi on it, you *can* recover the system back to a fully operational state. And more to the point, launchd helps minimize the potential for being in such a hosed state.
All this is academic, of course. The question to ask is how often do people find OS X to be in a hosed state, where the system is unrecoverable without resorting to such extreme measures? And how often does this happen in Linux? The answer for OS X is essentially "never", and under Linux it's "every now and then".
So perhaps your trepidation is because you are used to having to fix a hosed Linux system by hand via a boot floppy?
Re:Submitter is confused (Score:3, Insightful)
And I bet you'd never use the Gimp, because it's more Unix-like to have a separate command-line tool to make each modification to an image instead of having one biug program that can do them all.