Forgot your password?
typodupeerror
Utilities (Apple) Businesses OS X Operating Systems Software Unix Apple

Does launchd Beat cron? 798

Posted by timothy
from the borrowable dept.
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."
This discussion has been archived. No new comments can be posted.

Does launchd Beat cron?

Comments Filter:
  • Probably not. (Score:1, Insightful)

    by chuckfucter (703084) on Sunday May 01, 2005 @03:20PM (#12399886) Journal
    Rather than have one system to rule them all, we will now have one more system to use, complain about, introduce new problems, and work with.
  • by Anonymous Coward on Sunday May 01, 2005 @03:22PM (#12399905)
    If the submitter would have RTFA, he would know that launchd doesn't replace cron, but it replaces the sysv boot procedure (remember /etc/rc.d & friends) with something fancy. That might be a very good thing, since the current method is not really that flexible (for example, services are started one by one, you can't start them concurrently.).
  • by akac (571059) on Sunday May 01, 2005 @03:23PM (#12399916) Homepage
    Because everything in OS X uses XML configs. A dang site better than Windows Registry or the thousands of permutations that Linux uses.
  • by Anonymous Coward on Sunday May 01, 2005 @03:25PM (#12399935)
    No, you don't get it. Why in hell would you want to write yet another config file parser and use your own awkward config format when you could use standard XML and that very same parser that's already loaded to system RAM as a shared lib?
  • by Senjutsu (614542) on Sunday May 01, 2005 @03:27PM (#12399951)
    I'm not sure Apple Gets It though. Why in the world would they use XML configs?

    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?
  • 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.
  • Re:sweetness (Score:1, Insightful)

    by justsomebody (525308) on Sunday May 01, 2005 @03:31PM (#12399991) Journal
    Looks cool? Based on what?

    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)

    by cortana (588495) <{ku.gro.stobor} {ta} {mas}> on Sunday May 01, 2005 @03:31PM (#12400000) Homepage
    More like, "it's a single, consistent format and therefore inherently better than anything else".
  • by JohnsonWax (195390) on Sunday May 01, 2005 @03:32PM (#12400004)
    Why in the world would they use XML configs? Gesh.

    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.
  • by Anonymous Coward on Sunday May 01, 2005 @03:36PM (#12400034)
    The job: To automatically start services. The tool: launchd.

    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)

    by Speare (84249) on Sunday May 01, 2005 @03:38PM (#12400051) Homepage Journal
    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.
  • by Anthony Liguori (820979) on Sunday May 01, 2005 @03:43PM (#12400094) Homepage
    The fundamental problem launchd was created to solve is system startup time. Twenty or thirty seconds to boot a freakin' laptop is just absurd. So we used launchd to get that down to four.

    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.
  • by Anonymous Coward on Sunday May 01, 2005 @03:45PM (#12400106)
    Well, for starters there's the fact that launchd is better than any of the "Look, mom, I wrote my own init!" packages out there.

    You think it's "not invented here?" I think it's "not invented correctly."
  • Re:Ahh yes. (Score:5, Insightful)

    by Cid Highwind (9258) on Sunday May 01, 2005 @03:47PM (#12400123) Homepage
    You move away from human readability/editability and into the realm where only a machine can fathom the format.

    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 .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.
  • by GamblerZG (866389) on Sunday May 01, 2005 @03:48PM (#12400131)
    For once I agree. XML is _ideal_ for configs. In fact, it is more suited for configs than for many other fields in which it's actively used. The key things are it's flexibility and human-editability.
  • XML? (Score:4, Insightful)

    by Anonymous Coward on Sunday May 01, 2005 @03:49PM (#12400142)
    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.
  • by revscat (35618) on Sunday May 01, 2005 @03:50PM (#12400153) Journal

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

  • by jamezilla (609812) on Sunday May 01, 2005 @03:54PM (#12400190) Homepage
    From the launchd.plist man page [apple.com]:
    A daemon or agent launched by launchd SHOULD:
    oo Launch on demand given criteria specified in the XML property list.
    What does cron do? Launch programs! Clearly this means that launchd can be used to replace cron.

    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.

  • by synx (29979) on Sunday May 01, 2005 @04:04PM (#12400249)
    "Design by committee" is not a way towards excellence. Excellence often comes in small doses and grows from there.

    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.
  • by As Seen On TV (857673) <asseen@gmail.com> on Sunday May 01, 2005 @04:11PM (#12400319)
    I think, to the contrary, we've greatly simplified Mac OS X. When it comes to programs that run without being explicitly started by the user, there used to be six or eight ways to skin the cat, many of which overlapped to a greater or lesser extent. Now there's one.
  • Re:XML? (Score:3, Insightful)

    by lewiz (33370) <purple@NOSPAM.lewiz.net> on Sunday May 01, 2005 @04:14PM (#12400348) Homepage
    Not being able to use cut/sed/"etc." is your only reason that launchd is bad?

    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)

    by ip_fired (730445) on Sunday May 01, 2005 @04:15PM (#12400367) Homepage
    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.
  • by gnuman99 (746007) on Sunday May 01, 2005 @04:17PM (#12400384)
    If they replaced many small programs with one large, complex one then their system will NOT be adopted because it defeats the main advantage of Unix methodology over Windows methodology.

    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)

    by thasmudyan (460603) <`moc.liamg' `ta' `reteorhcs.odu'> on Sunday May 01, 2005 @04:20PM (#12400406) Homepage
    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)...

    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 /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!

    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.
  • by As Seen On TV (857673) <asseen@gmail.com> on Sunday May 01, 2005 @04:20PM (#12400407)
    We replaced many small programs that all do the same thing with one small program that all does the same thing. In the process, we eliminated five different cryptic configuration file formats, replacing them with one property list format which has already been in use for five years and consequently is well known.
  • by MalachiConstant (553800) on Sunday May 01, 2005 @04:32PM (#12400495)
    You know, I've read many of your posts and even if you are an actual employee of Apple you say "we" way too often. Unless you're Steve Jobs I find it hard to believe you're personally involved in all the projects you've insinuated yourself into.

    We're all very impressed if you work for Apple, but the chest-thumping is getting a little tiresome.

  • by evvk (247017) on Sunday May 01, 2005 @04:32PM (#12400497)
    XML sucks for anything that humans might want to edit: configuration files and documents. It's only barely usable for protocol that, and for that it is rather bloated too. Configuration files should use a simple human-readable format. The .ini format, for example, is rather robust. Of couse, programs that support scripting probably should use the scripting language for configuration so there wont' be a zillion different ways to do things.
  • 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.

  • by Kent Recal (714863) on Sunday May 01, 2005 @04:45PM (#12400604)
    I agree with parent.
    I've had the misfortune to fiddle with XML config files (tomcat comes to mind). Give me a sane key=value scheme anyday.

  • by Anonymous Coward on Sunday May 01, 2005 @04:47PM (#12400627)
    Over the last 15 years using UNIX on everything from System V on an At&T 3b20, Dec VAX, Sun/dec workstations, HP mainframe class machines, and of course linux/x86 my conclusion is that through inertia we are still stuck with many of the terrible to use UNIX utilities.

    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.

  • by NMerriam (15122) <NMerriam@artboy.org> on Sunday May 01, 2005 @05:10PM (#12400826) Homepage
    Isn't half the attraction to OS X for geeks how its not that much different from Linux or BSD from the console?

    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)

    by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Sunday May 01, 2005 @05:22PM (#12400932) Homepage Journal
    You move away from human readability/editability and into the realm where only a machine can fathom the format.

    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)

    by takis (14451) on Sunday May 01, 2005 @05:29PM (#12400992) Homepage Journal
    As far as I know, the parting of the Red Sea -if it happened at all- wasn't related to fileformats in any way :-)

    Furthermore, you seem to miss the point about XML. There's huge differences between XML and .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.

    Secondly, XML _is_ self-documenting while .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:
    a.dat:
    123:12:adf:0:1:dog

    b.dat:
    userid=123:age=12:name=adf:vi_user=0:gno me_user=1: favorite_pet=dog

    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 .ini files can't do.
    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 .ini files.

    So, the .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.
  • by As Seen On TV (857673) <asseen@gmail.com> on Sunday May 01, 2005 @05:30PM (#12401004)
    What's the difference between damaging /etc/inittab and /sbin/launchd?

    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)

    by jonabbey (2498) * <jonabbey@ganymeta.org> on Sunday May 01, 2005 @05:36PM (#12401061) Homepage

    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.

  • by revscat (35618) on Sunday May 01, 2005 @05:42PM (#12401110) Journal
    Maybe he does work with that team. If he works for Apple, the pronoun "we" is entirely correct.

    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.

  • by Anonymous Coward on Sunday May 01, 2005 @06:02PM (#12401313)
    Argh. I started using my mod points already, so AC for me :-/

    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?
  • by Guido von Guido (548827) on Sunday May 01, 2005 @06:47PM (#12401758)
    Also, in many cases you don't have to directly edit all those files. For instance, you can chkconfig on many distributions to turn on and off services at boot time. (Or whatever it is Sun uses in Solaris 10 now, not that I've had a chance to play with it much yet.)

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

  • by crush (19364) on Sunday May 01, 2005 @06:48PM (#12401768)
    The launchd service isn't a daemon.
    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.
  • by bussdriver (620565) on Sunday May 01, 2005 @07:01PM (#12401878)
    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)
  • by pohl (872) on Sunday May 01, 2005 @08:03PM (#12402465) Homepage
    You see these programs as "NOT doing the same thing" because of the abstractions that you have used in describing the functions of these programs. If you reframe the description using a common abstraction then it is easy to see that launchd is, in fact, consolidating function (and eradicating complexity) in a right proper way: all of those systems are merely handling the startup of processes in response to system events.

    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.

  • by NoMaster (142776) on Sunday May 01, 2005 @08:07PM (#12402493) Homepage Journal
    XML sucks for anything that humans might want to edit
    However, it's pretty damned good for the times where you want a machine to parse your config files and present them in a nice GUI format.

    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 .ini or .cfg file by hand? Your MTA? Apache? Samba? BIND? Crontab? Inetd? Initd? IPFW/PF? If you're like me, you did it by hand-editing the first few times so you knew what was going on; since then you've used Webmin or Gnome/KDE's control-panel-like apps.
  • by cakoose (460295) on Sunday May 01, 2005 @08:25PM (#12402627) Homepage
    If you can't figure out an xml plist config, then you are not smart enough to be in the shell.

    1. It's not about figuring it out. Just because you can figure something out doesn't make it optimal or even non-crap.

    You scared people clearly don't understand plist files and how they represent records and lists.

    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.

    {
    Dogs = (
    . {
    . . Name = "Scooby Doo"
    . . Age = 43
    . . Colors = (Brown, Black)
    . }
    )
    }
    A natural XML equivalent would be a little more verbose:
    <Config>
    <Dogs>
    . <Dog>
    . . <Name>Scooby Doo</Name>
    . . <Age>43</Age>
    . . <Colors>
    . . . <Color>Black</Color>
    . . . <Color>Brown</Color>
    . . </Colors>
    . </Dog>
    </Dogs>
    </Config>
    Using Apple's XML format, you'll get:
    <dict>
    <key>Dogs</key>
    <array>
    . <dict>
    . . <key>Name</key>
    . . <string>Scooby Doo</string>
    . . <key>Age</key>
    . . <integer>43</integer>
    . . <key>Colors</key>
    . . <array>
    . . . <string>Brown</string>
    . . . <string>Black</string>
    . . </array>
    . </dict>
    </array>
    </dict>

    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.

    • You can't validate semantic structure. (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).
    • DTD/Schema sensitive editors still wont help you out with semantic structure. It can auto-complete "key", "dict", etc. but it can't auto complete "Name", "Age", or "Color".
  • by EvilAndrew (581758) on Sunday May 01, 2005 @08:46PM (#12402773) Homepage
    The basic point here is that the plist stuff is XML unfriendly.

    <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)
  • by pberry (2549) <pberry@@@mac...com> on Sunday May 01, 2005 @09:02PM (#12402875) Homepage
    Obviously this is why qmail rules the MTA world.

    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.
  • by Anonymous Coward on Sunday May 01, 2005 @09:38PM (#12403159)

    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.

  • by gnuman99 (746007) on Sunday May 01, 2005 @09:46PM (#12403210)
    It seems to me that the launchd is quite small with a well defined interface. How is it more efficient to have multiple program using up "more" HD space, and more resources? How is it "good thing"?

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

  • XML sucks for anything that humans might want to edit: configuration files and documents.

    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.

  • by drsmithy (35869) <(moc.liamg) (ta) (yhtimsrd)> on Sunday May 01, 2005 @09:50PM (#12403237)
    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.

    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)

    by Anonymous Coward on Sunday May 01, 2005 @10:08PM (#12403368)
    launchd summary:

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

  • by Anonymous Coward on Sunday May 01, 2005 @11:37PM (#12403987)
    God, I couldn't have said it better. Apple's greatness, and a modest but important greatness it is, is that they're willing to look at this massive thing called Unix and say, "This sucks. This sucks. This sucks. Let's replace these things with something that doesn't suck."

    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.
  • by JQuick (411434) on Sunday May 01, 2005 @11:52PM (#12404070)
    However, the question is are we losing simplicity for features?

    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
  • by node 3 (115640) on Monday May 02, 2005 @02:46AM (#12404837)
    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.
  • by EvilAndrew (581758) on Monday May 02, 2005 @02:54AM (#12404864) Homepage
    ..and one of the big advantages of serializing into XML is that it's easier for it to be consumed by other applications.

    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.
  • by As Seen On TV (857673) <asseen@gmail.com> on Monday May 02, 2005 @03:03AM (#12404890)
    Yet another reason Apple is wrong in claiming 'a UNIX core' to their OS.

    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)

    by node 3 (115640) on Monday May 02, 2005 @03:28AM (#12404993)
    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?
  • by geoffspear (692508) * on Monday May 02, 2005 @11:40AM (#12407981) Homepage
    You must hate Linux then. It's totally against what you consider to be the Unix philosophy to replace a microkernel (like the one used by OS X, by the way), with the bloated Linux kernel.

    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.

From Sharp minds come... pointed heads. -- Bryan Sparrowhawk

Working...