Slashdot Mirror
Does launchd Beat cron?
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."
Based on what I've read about it, it's more a replacement for xinetd and the sysv init scripts than cron.
B
But can it be piped?
Simply referring to launchd as a cron replacement is a major understatement. launchd runs as the init process and according to TFA was primarily made to replace the /etc/rc.d scripts during startup.
/etc/rc.d scripts (considering the length of pause an fsck would take--users would certainly assume there system hung during boot).
This is somewhat understandable for something like OS X. Doing something simple like displaying a GUI detailing startup is terribly difficult with
I'm not sure launchd is something you'd want in 99% of Linux installs but if you're looking for a end-to-end user-oriented desktop I can see how a technology like this is necessary.
I'm not sure Apple Gets It though. Why in the world would they use XML configs? Gesh.
the machine boots to a desktop (auto log in and all) in less than 15 seconds.
I am the Alpha and the Omega-3
let me know when its in ports and ill try it out
freebsd gets no love around here
I have nothing to contribute to this discussion, except for my opinion on how ambiguous headlines are. For example, "Does launched beat cron?" has the following possible meanings (yes, I see it's launchd, but listen):
1) Does as a verb, launchd as n, beat as v, cron as n. That is, a question whether or not the thing "launchd" beats the thing "cron".
2) Does as a verb, launched as adj, Beat as n, cron as v. That is, a question whether or not thing Beat, which has been launched, crons. (Well, "croon" is a verb, so maybe "cron" is too).
3) Does as a noun, launched as v, beat as adj, cron as n. That is, a statement that female deer have launched "Beat cron" -- cron that has been beaten, perhaps.
Any others?
Launchd provides faster startup through a unified framework for starting, stopping and managing daemons, and incorporates inetd, init, mach_init, System Starter and related services.
Sun came up with (at first glance) a similar thing called Service Management Facility in Solaris 10.
Apple is doing a good thing here is shaking up the administrative and setup side of the UNIX world. Most of their work was actually NeXT's, but their "Application as directory" concept is wonderful in a lot of ways, and their reorganizing of the filesystem so that it makes more sense to users is probably a good move in the long run.
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.
yea, it really seems to clean up a lot of things. Like being able to tell that the service or process shutdown, instead of just sending bigger and badder kill messages.
Looks like a nice clean API that has some nice message passing structure in it. I also kind of like the magic dealing with auto-resolving dependencies and starting programs in parallel if possible.
From the sound of it, it just seems cleaner in the back-end. Much less knowing specific Unix tricks or gotchas, and more of it just working and giving you the proper interfaces.
that the submitter simply couldn't spell or capitalise correctly?
"Does launchd Beat cron?"
What is that? Some new form of AOL speak?
did you RTFA? launchd seems to be a system wide super program launcher. startup, timed, event driven (plug in a usb memory stick and get a pop up window asking what you want to do).
from reading the article, launchd sounds like a viable technology to replace quite a few convoluted system on my linux machines.
More like, "it's a single, consistent format and therefore inherently better than anything else".
Isn't half the attraction to OS X for geeks how its not that much different from Linux or BSD from the console? And that many/most Linux/BSD scripts and apps would work with just a few, if any changes? I don't see how making it more different really helps it. Not trying to be a troll, but I got to assume if all or most the other Unixes work with what launchd replaced just fine, that OS X could as well.
Every time you post an article on Slashdot, I kill a server. Think of the servers!
- really wasteful
- it takes a long time to parse
- inconsistent (like, the sometimes-freeform-sometimes-not issue)
- quite human-unreadable
Sure, it's better thanThe creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Windows .ini files are consistent too, but you don't find fanboys harping that they're the best format since the parting of the red sea. The thing that both XML and .ini files lack is any self-documenting: you still need to know what options are supported and what values are useful for those options. XML for configs solves nothing new, and makes things more bloated by far. You move away from human readability/editability and into the realm where only a machine can fathom the format.
[
Actually, 15 seconds sounds really wrong to me.
To keep things simple, we divide the boot process into two halves: the hardware half and the software half. The hardware half involves power-on self-tests, and the time it takes varies wildly from computer type to computer type, or even from configuration to configuration. It takes longer to test 8 GB of RAM than 512 MB of RAM.
The software half begins with the grey Apple-logo screen turns blue and the progress window appears.
From the time that happens to the time the menu bar appears (via autologin) should be four seconds on a stock Mac OS X install with middle-of-the-road hardware (dual 1 GHz G4).
Nice to see Apple take a page out of Sun's book...
Seems like it's a bit nerdy,
Oh God, no! *exits window*
Uh, the code is licensed under the BSD model. So Apple will get in trouble as well if there is patent trouble. /. will get you modded up automatically, but come on people....
I know making the statement, "boo patents!" on
Monstar L
You move away from human readability/editability and into the realm where only a machine can fathom the format.
.whateverrc start with a hash mark? A semicolon? A double slash? C-style /* ... */ delimiters? XML-style ? Are you even allowed to have comments? Can you use nested parentheses? Are angle brackets a symbol for redirecting i/o or do they delimit XML tags? Does a pipe chain the output of cone command to the input of another, or is it a logical or operator? Replacing that mess with a single standard format will make things *more* human readable IMHO, and it will certainly make it easier to have a single integrated pointy-clicky interface for changing all those configuration options.
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
0 1 - just my two bits
if you want to document your xml config file format, you can give a schema (xsd) or dtd for your document. you can give all the information about al l the supported options for the config file in your schema definition.
xml is more robust than its property file counterpart.
.ini has the serious disadvantage of not allowing for more than two levels of properties.
:p
But don't worry. I've once used a mmapped structure to make sure the config gets preserved over crashed -- but fortunately, someone beat me back into the senses. Try to exceed _this_ level of brain-damage
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
We do need a replacement for our boot process. Boot GNU/Linux systems is slow. We want processes to be able to start concurrently, or in some cases, with specified pauses. If non-essentials (print server, etc.) start a few seconds after the log-in screen appears, I can be functional faster. We don't have a good system in place now.
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.
Speaking of which, back in about 1995, I think it was, I installed my first Linux distro that I actually used on a daily basis. It was an early version of SuSE linux. Anyway, as I scratched deeper and deeper under the surface, I came to the conclusion that the init system was a mess... the entire system's functionality was implemented as piles upon piles of shell scripts, organized neatly into a whole bunch of directories, and activated according to their name and whatnot. This seemed kind of dumb, actually, because it meant that startup, shutdown, and switching runmodes were a lot less efficient than necessary, and also because you'd have to search through a zillion (that's a big number) scripts to find what you need.
A few years later, in 1999 or so, I tried FreeBSD for the first time. (Here it comes, I'm gonna be modded troll for starting another BSD- vs. SYSV-style init script war...) There, the functionality is still implemented in scripts, but there was a much more sane system. There is one script that is the same across all FreeBSD installs of that version. Then, there's the script you get to customize if you want. There's one more file, and that's where you simply give yes or no answers, or provide other data, in the form of environment variables that influence the running of those two scripts. It's so simple, and works quite quickly. Also, since you really only mess with one file, and two if you modify the script, it's much easier to find where things are. It's more efficient, from many standpoints.
So I don't blame Apple for getting rid of that SYSV stuff. It might have been cool back in the day, but it has lost its luster.
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.
This thread, so far, seems to be filled mostly with "Ah! Someone's doing something differently than UNIX has for 30 years! My knee is jerking!" So I feel I should respond.
launchd is neat. It's not simply a different way of doing the same things, it lets you do different things.
Like automatically evaluating dependencies between daemons, starting them in the right order, and running them in parallel if needed. FreeBSD's the only other OSS system I've ever seen do this; Gentoo does the dependencies but not the parallel startup. (Which is annoying while it's, say, trying to get an address from a nonexistent DHCP server.) Long story short, it dramatically reduces boot time, while eliminating dependency hacks like runlevels and numbered scripts. (Not that BSD had them.)
For those of you who posted without reading the manpage (or administering an OSX system), it also lets you do init-style startup tasks on a per-user basis. You can configure it to start daemons and other processes on the behalf of users as the log in, and shut them down -- gracefully, not by TERM; KILL -- when the user logs out.
Anyone who's ever dealt with the myriad of hacks to get ssh-agent in place will understand why this is good.
There's a lot of resentment these days toward anyone who does something that's perceived as "not the UNIX way." Change is the only way to innovation, people; perhaps the UNIX way is broader than you thought?
No, you've covered them all.
Why the hell is the user forced to wait through the RAM test? All that has to be tested is the portion needed for booting, and the rest can proceed in the background, with RAM becoming incrementally available to the system as it finishes testing.
This takes a significant portion of the boot time, and is nothing but piss-poor lazy design. If you add all the minutes wasted over all the people who use the OS over its life, that's a hell of a lot of man-hours.
Two words:
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.
Don't count your messages before they ACK.
Is there a way to make Dashboard widgets sticky on the desktop?
You don't want them to. One of the benefits of the Dashboard layer is the fact that when the Dashboard isn't visible, the widgets are completely suspended, consuming no CPU cycles at all. If you put a widget on the screen outside the Dasboard layer --which of course you can do, if you run Dashboard in debug mode --it'll execute its run loop all the time, sucking up CPU cycles unnecessarily.
XML is just a file format, and besides, everyone does it now. If we have a way of unifying those 1000 different Unix config and script file formats, then I say go for it, if only because today Unix configuration is a totally non-uniform mess. Why not XML? Even Apache uses it (with some limitations, but it's the thought that counts. well, at least they have angle brackets, that's a start I guess)...
/etc/rc.d (or /etc/init.d on most Linux systems) is a huge mess that's hurting startup time and performance. I think it's time for Unix people to realize that the whole application landscape severely suffers from integration problems. Take Monad for example, this is where Microsoft took the "Unix way" and implemented it for modern computing - think about it, friggin' Microsoft got this, and Unix geeks are still debating whether it's time to replace the ancient startup daemon that their fathers used!
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.
There is a method for detaching Dashboard widgets described here.
This lets you keep as many widgets as you want on your desktop, and they don't jump back into the Dashboard every time you display it.
The one remaining annoyance is that they float above all of your other windows. Hopefully there will be a hack for this soon.
daemontools and the free-er clone runit which both give you the advantages of a non-linear system startup process, automatic service restarting, no need to write daemon-ising code in each program etc. Each author also has common tools to use with these service supervision programs to ensure network-based daemons don't need to write network code: ucspi-tcp and ipsvd respectively.
/sbin/runit instead of init from then on; we tend to use it on top of the existing init scripts.
:-)
Brave Deian owners can apt-get install runit-run which will start your system with
And the system that's had such a sensible service supervision system since the year dot? Windows NT and its service control manager. Of course you could argue a centrally-controlled daemon restarter is much more of a priority when you expect your daemons to crash more
Matthew @ Bytemark Hosting
Ye Olde cron is still there and running. My Bashpodder script still runs on Tiger. As for launchd, I am going to have to read up on that. Sounds interesting.
Are there schedulers better then cron? You bet. As a scheduler for home use, cron is fine. We are currently trying to find a ore robust replacement for cron that will attempt to correct things before reattempting a script and with dependency checking. When I used to be a operator on a DOS/VSE based mainframe, our scheduler had a dependcy check that would hold jobs from running at thier assigned time if the previous job did not finish and other things like that. It had very robust logging to. No e-mails to root. I could just run a report. There are schedulers that come close to this on UNIX but cron is a very basic scheduler that is flexible which is a saving grace.
Gorkman
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.
Solaris 10 has something very similar to launchd called SMF: Service Management Framework. It doesn't replace cron but it does replace init.d and inetd. It also provides backwards compatibility so that existing init.d scripts and run and existing inetd entries are migrated to SMF on upgrade.
SMF also does dependancy checks and auto matic restart on failure (or some other conditions). It also uses XML for its configuration but imports that into an SQlite database so that it doesn't need to reparse the XML on every service restart or system boot.
For more information on SMF in Solaris see the links in the main architect/developers blog .
Your reply sounds like it comes from a geek, or perhaps wannabe geek. Well, just check out the source and tell us. http://www.opensource.apple.com/darwinsource/10.4/ launchd-106
There have been several comments along these lines. I don't understand them at all.
The launchd configuration files are property lists, which are serialized Core Foundation data structures. They consist of key-value pairs. They map directly to data structures in memory. The code for parsing them is used all over the place in Mac OS X, and is very old. It dates all the way back to the first development in the late 1990s. It's highly optimized, and it's reused over and over and over and over again.
The second advantage to plists is that they're self-validating. When a program tries to load a plist, if the file doesn't validate against the PropertyList-1.0 DTD, nothing happens. An error is returned, and the program (in this case, launchd) moves on. No chance of a corrupt file producing unexpected results.
The third advantage is that we ship a handy property-list editor with our operating system. This makes it easy for developers to create and modify plists.
Finally, plists are always in UTF-8 format. That's vitally important for us, because our system is fully localized. We have to be able to launch services with names that don't fit into the ASCII/Latin-1 character set. Using plists ensures that we can do that, and gives us that capability for free.
The question here is, why would anybody want to invent their own proprietary ASCII-only, non-validating file format for something as important as system startup control?
MacOSX programs make frequent use of NSDictionary, a Objective C collection class. There's also a C version, known as CFDictionary. It's worth noting that most of the relevant C interfaces, known collectively as "CoreFoundation" are open source
The CoreFoundation interface to MacOSX's built in XML parser is described here.
Upgrading to Tiger moved my cron jobs over to launchd. No problem, but now the scheduled jobs seems to run an hour later than they should. Something scheduled for 3:15 runs at 4:15, for example. Not a huge issue, but my Mac is set to wake up at night to run these jobs - doesn't work so well if they don't fire at the right time.
Has anyone else seen this? Any ideas?
Hmm. So you think that this XML-based solution is bad because XML makes everything slooow. Interesting. Especially considering the fact that launchd reduces boot time from a minute to under 15 seconds. While XML itself might make some things slower, in this case it allows for processes to be launched concurrently on startup, rather than one at a time. The overhead of parsing an XML file is minimal compared to the speed gains launchd allows.
Pack up your anti-XML trolling and bring it elsewhere. It has some good uses. I very much doubt that you'd be happier with it if they used some proprietary, non-readable format instead of XML since it would save them all of 0.025 more seconds on boot.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
I'm not an expert, but from what I read of the XML files, launchd seems more of a wrapper program than a replacement for cron. Translated: ProgramArguments = /usr/sbin/cron;
QueueDirectories = /var/cron/tabs;
ps -wwax|grep cron # shows two cron processes in memory;
So launchd takes the place of init, and starts up cron, with the proper arguments. Cron then takes care of its own.
Basically, cron needs higher resolution, that's my only beef with it. It also seems like to do anything facny with cron you end up writing a program to do it and it's not that uncommon to do that.
The startup scripts need an all together different kind of overhaul. I've been working on Linux appliances for over 6 years now, without exception, it seems like someone ends up writing some kind of "health script" that is kicked off by cron every minute or a few or is a daemon in it's own right that watches for things to crash or not be running and then it restarts them. I've seen it in a production set-top box based on Linux where we essentially wrote our own init and had it treat some processes special and 5 different software appliances. Fact of life is software crashes from time to time. These scripts then do something else, like ping the gateway or something stupid to check if the network went down before they do what it is that they do. To make matters worse, they are always written in Perl by some guy who doesn't know Bourne shell to write a good startup script in the first place; that's the part that chaps me. Rather than contaminate the system with all this extra shit we should just have an easily extensible and configurable system process starter and monitor and it shouldn't require scripting to do anything advanced.
There are probably some things I forgot, it's really not that much, I could see bangin' this out in Python or java in not that much code. My thinking is that instead of checking for a PID file or grepping through ps outout to provide "status" you query a running process and it tells you your proc is up and running. Yeah yeah, I know, shit shouldn't crash and whatever. I've just seen such a shitty job of this stuff being done over and over and even on fairly stock installs of major linux distributions I've seen service
The programmer or administrator is responsible for putting that information in the XML file. That's why they're using XML. It allows for more data to be available. Where it (init) used to basically be a list of programs to launch, it (launchd) is now a system whereby a collection of programs are launched. It is much more flexible, and since it can launch programs concurrently, much faster as well.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
Yeah, no kidding. I must boot at least once every few months or so, so pretty soon that's going to add up to...uh, a couple of minutes.
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.
Dewey, what part of this looks like authorities should be involved?
Apple has open sourced the thing, and is apparently hoping all the unix kids will take a look.
I've been poking around at Apple's Open Source page and fail to see launchd, SystemStartup, or anything else thereabouts. Does anybody have a URL for this, or know of the specifics of getting the source? It looks like promising technology, and I'd love to get my hands on a copy to play with. I would also hate to think that we're being strung along with promises of an Open system that turns out to be only partially open (like the recent KHTML/Safari issue).
As far as I know, the parting of the Red Sea -if it happened at all- wasn't related to fileformats in any way :-)
.ini files. First of all, XML allows you to store information in a more structured way: you can store it a tree, whereas a .ini file allows only one level deep "trees". Obviously, and specifically for large projects, having just one nesting level is very limiting in structuring the configuration information. This is likely one of the reasons Microsoft switched to the registry which allows the information to be stored in a treestructure, similar to XML. And projects such as Apache already use a XML-like format because it makes structuring configuration information a lot easier.
.ini files aren't. XML schemas -such as DTDs- describe what an adhering XML file should look like. So, in an XML based configuration file, you could demand that the user provides a username and petname for example, by creating a DTD demanding this information to be available. Furthermore, self-documenting formats are in generally considered files which describe the field that are contained in them. So, as an example, file "a.dat" would not be self-documenting while file "b.dat" would be self documenting:
o me_user=1: favorite_pet=dog
.ini files can't do. .ini files.
.ini-fanboys shouldn't complain to much about their beloved .ini fileformat, as the main/user and designer of that format replaced the format too.
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
We did open-source launchd. It's part of Darwin 8.
It's part of Darwin. Try this page: http://www.opensource.apple.com/darwinsource/10.4/
In all fairness, it sounds like you're the one who's ignoring the elephant in the room. If it's taking five minutes for your laptop to pass POST, you need to take it in for repair. It's obviously got a hardware problem.
launchd is also capable of automatically checking for dependencies and scheduling services to startup in the correct order. It can even start services in parallel which speeds up the boot process.
If you can't figure out an xml plist config, then you are not smart enough to be in the shell.
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)
Democracy Now! - uncensored, anti-establishment news
Apple's plist stuff is an abuse of XML. All those keys should have been XML elements so that I can actually validate the configuration using a DTD or a schema, not just the key/value structure.
It's also maddening to use XPath on a plist. I once needed to use Apple's iTunes export format to programmatically recover from a disk failure. The plist format made it difficult to get at the information associated with each file that I was missing.
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.
according to googlefight...
no!
Well
The format we're talking about here is what we call a "property list," a serialized data structure that's written out to disk in XML format. Here's an example. This is the launchd config file for KernelEventAgent, an important Mac OS X system service.This files are generated by the serialization functions in Core Foundation. You create a data structure, in this case a CFDictionary. Then you populate it with objects. In this example, that's four key-value pairs. The keys are "Label," "ProgramArguments," "OnDemand" and "ServiceIPC." The values are a CFString, a CFArray of CFStrings (with just one object in this case), and two CFBooleans. Then you issue one function call to serialize that property list to XML and another to write it to disk as a file.
Of course, in this particular case you wouldn't go through that trouble. But the important part is the other part of the process. You make one function call, passing it a path to a file, and you get back a de-serialized Core Foundation data structure, all type-checked and everything. If at any point the property list fails --if it fails in the XML validation or the static type checking --then you get back null and an error. All atomic, no muss, no fuss.
That's what launchd does. All clear now?
And shipping one of those implies there's difficulty in editing or reading the configs manually.
Look at it and you tell me. How daunted are you?
If you're building better solutions, maybe you can architect them to work well for most unixes?
We're releasing launchd, we're releasing Core Foundation, the property list format is both wide-ass open and fully documented in many different places. What else do you want?
You can ensure that the file is a valid property list XML file, but you can't make sure that it contains launchd configuration info
Of course you can. A launchd configuration property list de-serializes to a CFDictionary. If the CFDictionary doesn't include the required key-value pairs, it's not a valid launchd configuration file.
Syntactic and semantic structure happen in two different places. One happens as the file is de-serialized in Core Foundation. The other happens inside the launchd code itself.
DTD/Schema sensitive editors still wont help you out with semantic structure.
Technically this is a valid point, I agree. But property lists are almost always so incredibly simple that this objection is purely academic.
My favorite line from the article: "For Tiger, Apple created launchd: one launch daemon to rule them all."
whoa
Since XML is an abstraction on top of plain text files, there's absolutely no way it could be simpler than a plain text file to begin with!
Not true. By text files, we tend to mean line-oriented files. Often to be useful, it must also be field-delimited files.. colon-delimited in password files, or worse with cron-files a mixture of space-delimiting and position-dependence. (after first sevearl spaces, remaining spaces are no longer delimiters).
With XML you are no longer rectangular in your data-structure; no longer rows and columns (and potentially sub-colums), but instead you can more naturally represent the data however complexly it needs, and not have to worry about escaping arbitrarily complex characters, because all XML files use the same escaping.
-Michael
I know the guy who does the Darwin releases.
You're not him.
I know the guy who has been working on launchd for over two years now.
You're not him.
I know the guys who work on the BSD Technology Team.
You're not any of them.
So what I want to know is, where do you get off using "we" every time you open your mouth about Apple? You didn't write it. You didn't think of it. I doubt you could do either. The credit isn't yours, and I have a feeling that Corporate Security is bearing down upon your desk in the QA department right about now.
If I were you I'd shut my trap and cover my ass.
-- AC
Hmm, I cannot see Sun or IBM, both hardware manufacturers, using code that their right to it would be revoked if they sue apple for anything at all.
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.
The only concern I have is how bloody ugly/unreadable the config files are. There's so much noise from the tags that one's hard pressed to read the entries. I don't care if there's an editor for it, when I have to do it by hand with a text editor the file format's fluff gets in the way.
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?
Wrong, at least on your first point. launchd is APSL-licensed open source. Oh, and these chaps seem quite happy with the APSL, so it'd be churlish to begrudge Apple that choice of license.
From an educational perspective, I'd be interested to know which Unix design ethics it violates, though.
Well, since you mention it.. If you're reading this, ASOTV, please drop me an email. Nobody's going to eat you, but we'd like to have a discrete word... Thanks.
- Jordan Hubbard co-founder, the FreeBSD Project. Director, UNIX Technology. Apple Computer
And I suppose that you like C:\ better?
I forget, was my CDROM drive D: or E:? I'd better call my mom and ask her. She's sure to know.
If you don't want crime to pay, let the government run it.
Amazing. I've just read four or five comments on launchd from people diminishing how boot time has been decreased (by roughly an order of magnitude, it seems) by Apple. How would you like a car that took two minutes to "boot?" Resistance to change seems to be human nature to some. The arrogance is so palpable one could cut it with a knife.
My debian linux firewall/gateway box has been booting with runit as process 1 for years. Most of the "services" on the box are controlled by runit/daemontools. It has worked flawlessly for me. launchd seems to extend this paradigm very elegantly. I welcome launchd with open arms, and I hope a debian package is available at some point. BTW, 10.4 server is using lanchd, too. This is not just for desktops.
Think about all the customers who will boot their new mac and be amazed by the quick startup. Seems like Apple has their priorities straight. It's hard for me to see a downside to faster boot. Perhaps the more anxiety-prone will wonder if something is wrong?
"Mit der Dummheit kaempfen Goetter selbst vergebens." - Schiller