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."
Yeah, this looks really cool (being a unix geek and all). I hope this catches on.
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?
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.
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
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.).
let me know when its in ports and ill try it out
freebsd gets no love around here
One tool, one job.
This replaces cron, init, and all sorts of things. Ugh.
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 doesn't have anything to do with crond. You can even tell just by looking at the name! Launchd - system startup. Crond - periodic program running. Here was me thinking that the Slashdot editors were UNIX nerds. Turns out they're neither UNIX nerds nor editors. Jeez, check your submissions to make sure they're, ya know, factually correct.
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.
Can launchd be covered by some submarine patent ?
-- I'm not closing the paranoia mode publicly so YOUR heads will blow soon... --
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
Change Is Not Good, Leon. This sounds like another reason to delay adopting Tiger until the end of the fiscal year or later, since it seems unlikely that this is the last or only surprise the Man Who Created Lisa will drop on us.
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
To make matters worse, current frontends to cron specifically require an executable. If this executable needs to have some input, matters become kind-of complex, at least for me.
If launchd can save me this misery, that would be a very good thing. The problem though is that I can hardly afford a Mac but I recognize that this is a nother matter altogether.
Sun came up with (at first glance) a similar thing called Service Management Facility in Solaris 10.
Looks like one more PITA for porters...
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.
OS X uses XML configs. A dang site better than Windows Registry or the thousands of permutations that Linux uses.
You're one of those; 'It's XML and therefore inherently better than ANYTHING else.', people eh? XML has its place but, is not the be all and end all of everything. Your kind seems to forget XML's place.
that the submitter simply couldn't spell or capitalise correctly?
"Does launchd Beat cron?"
What is that? Some new form of AOL speak?
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!
It seems pretty well organized, but very osx specific. I wonder how much the directory structure, and the Agent vs Daemon thing can be reconfigured.
I really want to fiddle around with this one!
Is the 15 second boot time a cold boot or is it a resume from hibernation?
Adding XML to to core services like init is beyond stupid, and merging several independant utilities into one monolithic tool is the exact opposite of how unix works. A single, simple tool to do a single simple task. I can't imagine why any other unix system would want this thing.
Doesn't need it? I'd say this is a quite good use of XML.
It's easily read and written by both humans (with only a text editor) and programs. I presume (but I haven't checked) that the XML is in plist format, which maps nicely to CoreFoundation/NS data types. This makes it even simpler for programs to read the format.
Sig Nature
To paraphrase: It's an ambitious program that wants to handle all of your "launching" needs, including rc, cron & at. It's been open-sourced and the open source community would do well to look at it.
That's the article excerpt in a nutshell. It doesn't explain what it does or how it does it. In fact, it reads like it was copied from a press release.
Less sizzle and more steak please.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
WTF do you want to launch an interactive gui mail program in a script for?
Ever hear of the "mail" command?
Only yesterday we had this article about the Apple's patchset not being really useful for KHTML and now this guy says
"Apple has returned the favor by contributing to many of those projects: FreeBSD, gcc, KHTML/KJS, etc."
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
[nt]
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.
How can launchd save you this misery? Launchd is a service startup manager with limited scheduling capabilities. It will not make your desires for automating kmail any simpler. You will still have to have a program or script to perform the steps you desire with kmail. Using DCOP will be the best bet here. Scheduling the script with launchd won't be any easier than scheduling it with cron or AT.
But it's more than cron, it "incorporates inetd, init, mach_init, System Starter and related services" according to apple... I'm not sure I'm that happy with it including everything but it's features sound damn impressive, and I do hope we see something like this for Linux/et-all.
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.
I think I was going for like a book title, where all imporant words are capitalized, but I think I was also trying to stick to the Unix style 'all program names are lowercase' thing (even though OS X, which this is all about, isn't case sensitive). It was all kinda subconcious. Ah well. =3
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.
The two are totally different you prat.
Isn't this a re-post ? I think I read it before somwhere ?? The problem with XML is that it is big and bulky. It will take the system sometime to parse through the whole thing. But maybe they figured a way around it. Maybe there will be a distro that will use launchd or soemthing... We will see, but don't know if the other Unixs will pick up like AIX ?
Are you familiar with init? inittab is extremely simple if you're not braindead; the same goes for SysV rc scripts. There's no compelling reason to use XML here. OK, maybe it was easier---"we'll just drop an XML interpreter into init."
No bloat there.
-rsw
Good thing i did not forget my tin-foil hat!!
I don't understand the guts of launchd, but wouldn't it be possible to recode it to use simple (and in my opinion, superior) text-files?
When a true genius appears, you can know him by this sign: that all the dunces are in a confederacy against him.
Ooh wee. Just look at the syntax errors/typos in that stupidly simple example.
But, since its XML, those typos would be SO easy to find in a three page long config file. Wouldn't they
It all sounds more or less like the servicemanager under windows nt+ (or whatever it is called). That one also(?) keeps asking the 'daemon' (or service as they call it) what it is doing if it has sent it a startup or shutdown message.
I might be wrong though, has been a while since I wrote a service for windows.
www.vanheusden.com - home of Multitail, HTTPing, CoffeeSaint, EntropyBroker, rsstail, bsod, listener, nagcon, nagi
"we'll just drop an XML interpreter into init." No bloat there.
As opposed to what? Do you think the inittab format magically parses itself?
Hmm.... we could have parser for inittab, one for fstab, one for xinetd.conf....*or* one XML parser in a dynamic library that can handle everything.
Bloat? Sorry, not seeing where the "bloat" is here.
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.
It replaces cron too
The article summary wasn't incorrect, it was just incomplete
Oh yeah?? Well...
</paranoia mode>
So there.
This post is a troll for two reasons:
1) Why is adding XML to core services bad? XML is something that is easy to organize, but can be opened/read by pretty much anything. It's also easy to open/read *fast* -- any argument about speed is completely fabricated.
2) Why must all the things launchd does be conceptualized as different tasks? Maybe they're all variations on the same task, in which case instead of "lots of little tools for little tasks" you have "lots of different tools for different aspects of the same task." Which goes from "the UNIX way" to "the confusing way."
Parent is a troll whose definition of "good" is apparently "the way things were done in 1975."
In my opinion, XML is a lousy design for human text editing. Way too unvieldy. Look at e.g. YAML (http://www.yaml.org/) for an example of how to do this more human-friendly (and with less waste for the machines involved.)
Alas, XML became a standard and Apple use it all through OSX, so it's reasonable that they use it here, too.
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
They are just programs. There's no way for it to tell how they relate.
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
What's wrong with crond? It runs things at specified times. And because it's been around for ages, it's probably more secure and stable.
If it's not broke....
Get your own free personal location tracker
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 .
I mean, it's a thing... did everyone get that - it's a cool thing!
A thing I tell you!
James Tiberius Kirk: "Spock, the women on your planet are logical. No other planet in the galaxy can make that claim."
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?
"So, for the next few years, we will now have one more system to use, complain about, introduce new problems, and work with."
This system replaces a *handful* of systems. You're content with having four, five, six systems to deal with, but not with another one that, while obviously not perfect, can *potentially* do a good job in replacing the rest of them, already has proven to increase performance wildly and is open for modifications?
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.
There are a bunch of things in UNIX that are, well, showing their age: cron, init (in its various forms), inetd, etc. It's not hard to improve on them. In fact, there have been lots of improved versions. But, in the end, it doesn't make enough of a difference for people to break compatibility.
Apple should think carefully whether they want to move even further away from UNIX sysadmin standards as they already have.
When I worked the help desk at a company that sold shared hosting, helping people figure out what they'd done wrong with their crontabs was a regular chore.
As I understand it, to replace crond, Apple has introduced Automater; to replace rc.d and the like, Apple has introduced launchd.
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?
SRC's been around for a while (AIX 3?). The Solaris widget looks like Sun thought it was a good idea.
I'm not entirely sure I like it but it's there and it pretty much works. It does mean there are different start/stop widgets on different operating systems and as an administrator that pisses me off.
Deleted
Back on topic, I hope other *nix take a similar approach. Perhaps Apple could Open source it. How about instead of being an annoying and negative ass, try reserving judgement until you see it in action?
Jesus was a compassionate social conservative who called individuals to sin no more.
the code is licensed under the BSD model
No, not really. It's licensed under APSL, which is (as far as I understand the license) very simmilar to the LGPL.
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.
Put away your "windoze suxors" fanboy attitude for a moment and take a look at the bloody thing before you judge.
Jesus was a compassionate social conservative who called individuals to sin no more.
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
a fucker, on slashdork? nevar. fuckwit is more like it.
Having an application as a directory is not really an apple innovation, but has existed before in RISC OS and the related ROX. Look up this page and search for 'application directory'.
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).
We did open-source launchd. It's part of Darwin 8.
Would it be possible to convert a standard linux installation of, say, Slackware, to use launchd instead of rc.d and such? I can't see why not, supposing of course that one is a wise enough unix-fu master to actually do it. I would sure like to learn how you would go about that... I barely understand the init scripts as it is, so it would probably take me a long time to figure out. Yet, that's why I have a linux box in the first place: so I can mess with it.
--The universe will not be altered by forum threads, even those which are very wry. --Tycho Brahe (Penny Arcade)
Cron and init and rc.X work fine, I'm not a hater. However I do think it's time to move forward.
/etc/conf.d on Gentoo.
Fine, I'll bite. Here's why you're just talking out of your ass.
* Use XML for configuration, it's easy to parse, it's here to stay and I think it's a little bit better than the columns of a crontab because it's more verbose.
Ok, everyone, repeat after me, XML is *not* easy to parse. I don't understand why anyone says this. Write an XML parser. No, not some silly thing you did for some crappy college project but a real XML parser that supports namespaces, various encoding types, DTD validation, etc.
The problem with having a standard like XML is that at this point, it's incredibly heavy-weight. Hell, there's even a standard API (Dom) that's a pain in the ass for every language I've ever tried to use it for.
* Have variable restart behavior, restart, restart and restart dependancies, reboot, just let processes die, etc..
Dependencies are hiearchical. Do you mean restart everything that depends on process? That's already in, at least, the Gentoo init scripts.
* Have dependancies (start the database before the shit that inserts data in to it, even though it shouldn't matter, it does) and start them in the right order.
This is supported in a lot of init scripts including Gentoo's.
* Kill dependencies when I kill a process
Again, it's in Gentoo's scripts at least.
* Smart killing, if something doesn't gracefully go down, 9 it down.
kill -9 is never a good idea. You're dancing with the devil if you do this. You risk massive corruption of your system.
* Have some kind of health monitoring call back, at a time I specify, execute a program that will check to see if a process is okay.
This is a feature of launchd. However, I'm not a huge fan. I don't think it will help. Most apps would probably just spawn another thread to respond to these things. If another thread got hung, you would never know.
* Once all this is done, maybe support something like soft cycling, kill everything down to single user mode and then bring it all back.
It's called the 'init' command. You can already do this.
* Variable dependency notification, if I restart my database allow me to do nothing to dependant processes, restart them, or HUP them, or something I define.
You can modify the startup scripts to implement whatever behavior you want.
* Full featured logging.
As opposed to...? Have you not heard of syslog?
* At some configurable interval, sniff out all of the XML configs in this "next gen startup proc" config directory, like every 5 minutes just check for changes and if needed, start something new up.
How do you know whether when you look at the files, they aren't in an inconsistent state? Say you've got vi open on a file (and I bet you use vi) and in the process of editting and haven't closed a tag you're entering but you save because you've made a lot of other changes. What happens when the config is now reread?
* Allow for user to be specified in the config
This is already supported. See
* Allow for end users to have thier own daemons defined by files in their home directories.* Then finally, allow for cron like behavior and run tranient tasks with all the flexibility of cron.
Why even bother combining? What benefit do you get?
* Proc specific ulimits would be nice also...
ulimits on what??
* And some form of runlevel logic still.
So, reinvent what we already have?
* And startup and kill in parallel if allowed by the depends...
Gentoo supports this.
* And it should have a template for common daemon type things I should just provide a startup command, arguments, a user to run it as, and a r
Man, he must have ripped you a +5 Insightful new one.
It's pretty apparent that the guy is a fucking troll, but all of the Apple fanbois who want to believe in this bilge-spewing liar will mod you into oblivion for suggesting such a thing.
Mods: How the hell is pointing out the obvious -Flamebait?
It seems pretty well organized, but very osx specific. I wonder how much the directory structure, and the Agent vs Daemon thing can be reconfigured.
In 10.0 lookupd was launched with flags and fanfares as the way to find anything network or directory related. It had agents and lookup orders, and command line config tools. But it took Apple 4 years (= 4 major OS revisions) to realise that nobody else would use NetInfo, and Open Directory was a safer bet.
launchd has its own lists of agents and daemons each with their xml config (plist). Expect to see launchd shuffling its options for maybe four years before it too settles down.
It's part of Darwin. Try this page: http://www.opensource.apple.com/darwinsource/10.4/
Adding dependancies to core services is always bad. It adds potential bugs, security and reliability issues, etc. Its all just a question of wether or not that new dependancy adds enough benefit to outweigh the downsides. XML does not add anything here, the tools involved are not using all kinds of different config file formats or any other such nonsense, they are simple shell scripts. And just because the XML you make is valid, doesn't mean it will actually do what you think it will, you still have to test your changes just like you do now. Downsides and no upsides add up to a stupid idea.
And no, init and cron do not do the same task, saying "they both start services" shows a complete lack of understanding. Starting a program is just fork(); exec();, this is trivial, done by tons of software, and is the only thing they have in common. The majority of the code of init and cron have nothing to do with this, and are not at all the same.
Your shell does fork(); exec(); all the time, but that doesn't mean its "pretty much the same" as init, cron, sendmail, and apache. Or did you guys want to mash all those together with an XML library too?
And none of this is needed to be able to start services in parallel. Shell scripts can do this just fine, and that's what you init scripts are. Just because current linux distros seem to universally choose hideous sysv style init scripts, doesn't mean they couldn't do it another way. NetBSD's init scripts could easily be changed to add parallel service starting, if it doesn't already support it.
launchd fixed that. rtfa.
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.
Activity Monitor says that's wrong. I decided not to use at least one 3rd-party widget because it was using a few % of CPU in the background. Several of the widgets showed above 0%, actually.
Shouldn't that be "1 0 Just my two bits?"
I did some poking around my laptop and see that for all of the events that were previously, by default, in /etc/crontab now have individual plist files in /System/Library/LaunchDaemons . Makes it kind of difficult to manage your schedule, but now it's less likely for a ham hand to screw up the crontab. I fail to see how having scads of plist files is better then just putting a entry into /etc/crontab for each thing that needs run. One upside is that Apple does provide a plist editor that works pretty well and makes editing the files much easier. At least if you put a entry in your user crontab it still works. In one of my earlier posts I had misunderstood the poster as saying everything was in a single plist file which would be bad, but I am not sure on how this would appear to be better then just the files we have always used.
Gorkman
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
Just be glad I didn't throw a comma in there somewhere. You're like Magneto in a sea of mutants.
WARNING: Smartphones have side effects--most of them undocumented.
It seems some moderators have not read the Moderator guidelines. You should not mod people down, because you disagree with their opinions.
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.
Thanks
I've used sed on XML files before, in a pinch. It works, as long as the XML has decent per-line formatting.
What would be cool is versions of Awk and Sed that XML aware extensions and could do things like identify and work on or replace tagged sections.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
If you are looking for something like launchd, consider using just that - in the Ars Technica article recently posted (a good starting point to read up on what it does) they mention that in a rare move for Apple they are offering it as a standalone open source project for anyone to use. I've not looked into the details yet.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I got Trolled for yes a bit of a rant but not way overbord the other day it's a Mac Snob thing.
Luckly I said enough about Linux in the same rant some one moded me back up as intresting. then back to a new one came back and trolled me again 70% troll 30% intresting.
Who cares what the mod is it was a good question about the article.
Thanks
I'd Tell you all my secrets but I lie about my past
"XML is total crap for config files. At least its complexity is somewhat warranted when dealing with document-type data (like HTML or DocBook)."
What? A concession? I though all you XML haters didn't think XML was good for ANYTHING? Every story that even mentions XML in passing, bring you all out in force. You all should incorperate. At least become a tax-deductiable organization or something.
Parallel startup *will* hang your computer, if you are using a desktop-optimised kernel.
http://bugs.gentoo.org/show_bug.cgi?id=83903
I guess this is exactly why we need something like launchd...
What license? You know the community doesn't like the Apple open source license much.. Not to sound ungrateful if it is under the APSL then I doubt there will be much acceptance from the linux guys.
Replacing the traditional but ill-designed init/cron/at/inetd UNIX mess is IMHO a good idea:
there is indeed a need to modernize/simplify/standardize this across Unixes:
if you check the Unix rosetta stone, you'll see
how big a topic this is.
However, the widespread use of XML in OSX
is a *MAJOR* liability : whatever fanboys
will say about perl and python having easy
to use XML parsing libraries, there is no
way that will ever replace a simples grep | cut
shell command to pump useful info out of the
config files.
Put simply : XML for config files sucks big time.
Go ask any sysadmin managing a large heterogeneous
network of Unix boxes how much they like the
netinfo/automount disaster in OSX, and see how
much they like XML.
XML is a piece of crap when it comes to config
files: it's hard to parse, and whatever some
say, a lot harder to read for human than the
usual Unix config files, and it's been a major
hindrance for OSX to become accepted in production
as a true server side Unix
Ah, excellent. Thanks for the info!
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.
Haha. I didn't know we looked like that. Wasn't it the pro-XML people that were the rabbid ones? I wonder when the tables turned.
In my defence, I was only responding to a very pro-XML comment. The again, the guy who brought XML up in the first place was a member of "our" camp, I suppose.
If you think this was just a coincidence, you're fooling yourself. We're happy to share code with people who don't compete with us.
according to googlefight...
no!
Flamebait!? As far as I know:
Hibernate -> write contents of RAM to disk and power off; restore contents early during boot up and resume
Standby -> put CPU and other peripherals that eat power to sleep, maintain contents of RAM
Why share the code at all if it's license is designed not to be liked by any of the linux people? Who else will use the code?
I can't see the motivation.
Oh, key-value pairs! It was really hard to handle those before XML!
This is retarded... how hard was it to validate text config files before you started using XML? Each line either has a properly delimited key-value pair, or not. The values are either useful to the program, or not. It's not brain surgery.
AWESOME!
Like you needed the XML albatross for that.
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
This is supported in a lot of init scripts including Gentoo's.
I don't know why you think this is an argument -- you are naming another group that agrees with the poster. Or are you suggesting that he's an idiot for not liking Gentoo's implementation?
Unless I want to support long lines (init has a very small argument length limit), or add more information for some entires (say dependencies) that may not exist for all entries.
The value of XML is that I can have a complex configuration file or a simple configuration file at the option of the user rather than at the option of the program designer.
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?
Sorry but I have to agree with the grandparent. XML for configs is a HORRIBLE choice. Here's some reasons why:
Personally I would actually prefer a binary format to XML. If you can't read it or script it you might as well get the speed of a binary format.
Actually what really bugs me about using XML for configuration data is that shows that the designer did not understand that the FORMAT of the data is not the problem. It's the INTERFACE that matters. If they had they would realize that DOM and SAX are horrible generic faceless interfaces. Store it however you like but provide INTELLIGENT APIs for querying and storing the information.
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".
One problem with cron is you can't run something on a specific date if that date is too far out.
For example, let's say you need to run a job in 3 weeks. Easy, right? How about run it in 12 months and 1 day from today. Well hmm, looks like there's no way to specify that, because if you specify it the way you think, it'll run tomorrow. Doh!
That's an irritating limitation that you can get around by using "at". The problem with 'at' is you have no idea what queue number your file is, so if you want to cancel a job you have to run through the at queue, look for a telltale, then use that to figure out the queue number.
Gee, what a PITA.
Why not have the ability to schedule a job at a specific time (returning a token), then be able to manipulate that job using that particular token?
I have no idea if launchd does that, but pratically every other scheduler on earth does. -That's- why it's better to replace all those annoying and limited utils with one that's built-in and supported.
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.
Of course they didn't make it quite as good as I had it laid out.
XML? I considered it and it's a bad idea. Too much work for machines OR humans to parse. They missed the boat on that. It also doesn't look quite as robust as my design either.Then again they're only a multi billion dollar company. What do you expect?
Maybe in another 15 years I'll actually get to see an OS something like what I was building in 2000. : P
This is retarded... how hard was it to validate text config files before you started using XML?
Harder than using an already existing XML parser and validater.
Like you needed the XML albatross for that.
Yeah, it might take a whole 8 milliseconds to parse an XML file when it could parse a flat text file in 4.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
I have been saying that for a while now. I am going to stop reading comments for Apple related stories! Look at his friends list. All a bunch of morons. This guy is probably *the* most successful troll on Slashdot yet. Last week he said: "WE expected to get 5 GHz G5s this summer" and they mod him up. OMG, they'll believe anything. I can't post this logged in because of all the retarded Apple fan boys cruising this site(I am a also Mac user).
Why share the code at all if it's license is designed not to be liked by any of the linux people?
I'm gonna let you figure that one out yourself. The answer is pretty obvious if you ponder it for a sec.
Who else will use the code?
Anyone who wants it.
You've left a whole series of comments with this same basic theme. You're kind of an asshole, aren't you?
Hint for you: Compare the moderations on ASOT's posts to the moderations on yours. Then contemplate what you're doing wrong.
YOUR WORDS WOUND ME.
Yes, receiving positive moderation is the height of achievement. Why didn't that ever occur to me?
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
BSD people? Sun? IBM? Anyone else who doesn't believe in software communism?
On a modern desktop OS, how often do you start the system without cron or inetd?
Oh, that's right: never.
For OS X users, combining the functions into one program that handles failure gracefully is the right call.
Use XML for configuration, it's easy to parse, it's here to stay and I think it's a little bit better than the columns of a crontab because it's more verbose.
Easy to parse?? You mean "there are parsers available for it". It's actually very difficult to parse.
Try this: using only whatever tools can fit in 1MB of disk, write a parser for inittab. Now do the same for XML.
PS: A lot of what you describe is already available in systems like "runit" and "daemontools" (google for 'em). When I deploy a machine to a client, I make sure all daemons are under daemontools. We're pushing 2 years uptime on one system in high-volume production! Daemontools is a real work of art, too bad it doesn't have a license for redistribution.
unified: great
smarter: great
UTF-8: great
self-validating: great
XML: I have concerns.
Does it have to be XML? Is a simpler, yet "self-validating," UTF-8-using format infeasible? Sure you've got the parsing code handy over and over and over and over again in Mac OS X, but will a parser fit nicely on my floppy-based system?
Okay, you ship a plist editor. My unix doesn't. And shipping one of those implies there's difficulty in editing or reading the configs manually. I think you can get all the upshots you listed yet still be able to easily read the configs, easily edit them with ed or shell redirect. Of course, I haven't designed this, but I bet you could have without too much trouble.
If you're building better solutions, maybe you can architect them to work well for most unixes? Maybe that's not your concern.
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.
BSD people... I would guess they feel the same as the linux people - but that's just a guess.
It's part of Darwin (the free, APSL base of OS X.) The source is included in the other source files of Darwin.
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?
FWIW, I use Fefe's Minit, which is based on daemontools. And it was probably the first attempt at speeding up boot times in Linuxland. Good to see things like this going mainstream.
See what happens when you ask people to ponder? :-)
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
I looked over my notes for my MCSE, and I don't get it.
Please, what's so funny?
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
Once upon a time, I worked on a project. It does indeed use a preferences file like the .
The problem is this resulted in a preferences system where it was hard to make changes. Add a preference? You now need to change the schema parsing and the schema. And now you need to grok both the old schema and the new one.
Atop of that, the bottom most systems (The ones actually taking preferences and storing and loading them) have no real need to know what is being stored. All they need to do is hold onto the data and load/store/return it when requested.
The routines on the program side of things? They shouldn't need to care about HOW the preferences are stored. They just want to have the right values returned as asked.
As a side note, Apple's plist files can be edited by hand, with their Property List Editor or with a command line tool on MacOS X called defaults. A number of early MacOS X hacks were simply tweaking hidden defaults that programs had but didn't expose a GUI for. defaults write <domain specifier><property specify> = <new values>
Parent is an anti-apple troll and MS shill.
because you're just that awesome.
sigs are for fools and trolls. no signature is *always* appropriate. you should turn them off in your preferences.
Shhhhhh.
(Except when spreading WHOLLY UNRELIABLE rumors about this that I will OFFICIALLY DENY, please don't call it Linux. It's definitely not Linux. Or wouldn't be, if it existed. Which I have to say that it doesn't.)
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.
Other than that, cheers on making an interesting init replacement. Hopefully someone else will do it better in the future and I can stop complaining.
to use it on a f**%F&%$g mac.
Same old Apple strategy : we're
OpenSource, but you can't actually
do anything with it.
Witness
Did you read the man pages for this? Does Apple have some Tcl stuff now associated with their daemons? What possiblities does this open up?
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
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.
So it can validate syntax, just like cron does, brilliant.
There seems to be two distict camps in this topic. The detractors would probably be less detracting if launchd supported the status quo.
It's definitely not Linux. Or wouldn't be, if it existed. Which I have to say that it doesn't.
Sure it does, it's right here: Download Darwin
I believe you can just download the x86 iso, and install darwinports. That'd pretty much give you a BSD-like distro of Darwin with not quite-so-many available packages, but all the cool unixy features of OS X, including launchd, right?
Of course, this isn't as simple or as organized as installing Debian, but, well, it's there for the downloading.
that XML sucks.
Not for everything.. there are things that XML is good for.
But it sucks.
At this point just plain flat text file is BETTER then XML.
Not because nobody understands that easily parsable and checkable text is wonderfull, but because XML doesn't realy accomplish it. It just makes editing files more confusing.
What Linux needs for it's config files is a application-specific syntax language. Something simple, something stupid. JUST FOR CONFIGURATION FILES. Nothing fancy, something that is designed to be more easily editble by humans then programs.
XML may solve some problems that flat-file applications-specific configuration files introduce, but it doesn't solve them in a way that is enough to make me, and most other people, actually like them.
XML just isn't good enough. That's all. Try again.
It's highly optimized
Apple's idea of highly optimised = Waiting "only" 5 seconds for a window to redraw, then charging you for the "upgrade"
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 detractors would probably be less detracting if launchd supported the status quo.
But launchd has obsoleted and replaced what used to be the status quo. Now it's the status quo.
You do realize that we're not talking about some kind of abstract proposal here, yes? This isn't something somebody might implement someday. It's done, over, released.
I.e. anyone who doesn't make computers or operating systems... /me goes off to wonder who is left that might even be interested.
What else do you want?
I'd like a property list format that was compatible with XPath.
At the moment, I can only retrieve values from a property list either by using the CFDictionary interface, or by processing it with custom code.
If property lists were structured better, then I could do easily retrieve data values with XPaths, easily pretty print them with XSL, etc.
My basic point is that while they are indeed XML, they don't even come close to best practice.
There is one thing that should bug every SysAdmin: in case of a problem, will the programs that are mentioned in this thread be available? I do NOT talk about trying to find a CD with the necessary editors, etc. Every SysAdmin worth his/her paycheck can make sense out of the usual config-files in /etc, try the config of EtherShare to get an idea about the adverse (there is a program to make sense of the config, something every SysAdmins likes to use, don't they?). .NET uses something do not make it viable for *NIX
When the users are breathing into your neck because they need access to their files, messing around in XML using vi/emacs or worse ex, just is not funny.
The fact that
my 2 cents
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?
But it isn't restricted to just software patents. What about hardware patents? Like I've been saying, Apple is mostly a hardware company.
Say IBM rolls out some distro on a large number of machines and the distro they use uses mDNSResponder.
Say now Apple violates one of IBM's hardware patents.
What should IBM do now?
And the BSD folks are more libertarian like you say - exactly why they are even less likely to accept such draconian licencing.
Btw as for reimplementing, yeah it can be done. Both gnome and kde development on zeroconf is pretty much waiting for the reimplementation of mDNSResponder.
First of all, I'm not saying that property lists themselves are bad. I'm just saying that the old format is more readable and property list XML is useless. The rest of my post focused on preempting arguments that might claim that the use of XML gives you additional functionality for free (which may be valid in some situations, but not this one).
I meant to say that you can't leverage the DTD/Schema stuff to perform validation. (The line above the one you quoted was indented to establish that, but I suppose I probably should have ended it with a colon, huh?) And, like you said, you can do all your validation operationally if you want. Or you could create a declarative system just for property lists. But you can't leverage existing DTD/Schema libraries to handle this for you.
Well, if you don't need editor support, that's great. And it just may be the case that nobody will ever want code-completion-like editor support when editing your configuration files, but I doubt it. You can create a custom editor that understands your custom declarative type system for property lists -- and that's perfectly fine -- but the use of XML achieves nothing here (just decreased readability and a slight performance degredation).root@darkstar:/etc/rc.d# ls
rc.0@ rc.M* rc.gpm* rc.inet1.conf
rc.local* rc.sshd* rc.4*
rc.S* rc.hotplug* rc.inet2*
rc.modules* rc.syslog* rc.6*
rc.alsa* rc.httpd rc.inetd
rc.sendmail rc.sysvinit* rc.K*
rc.font.new* rc.inet1* rc.ip_forward
rc.serial* rc.udev*
So to start at boot I have to figure out this whole chmod 755 rc.whatever thing? Yep too difficult, what I really need is some extremely bloated, one size fits all pile of crap that only a machine can edit. BTW cron works just fine. If it doesn't work its usually caused by a malfunction in the script its told to run. Cron is just fine, however many of the people using it are severely b0rked.
UNIX: A set of Linux-like operating systems that grew out of an original version written by some guys at a phone company
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
But it isn't restricted to just software patents.
Right, but what you said is: "their right to it would be revoked if they sue apple for anything at all."
That's a whole different reason.
Say now Apple violates one of IBM's hardware patents.
What should IBM do now?
If the patent is important enough, IBM should sue Apple. They'd lose the license to the APSL code, but if the patent is important enough, and the violation clear enough, Apple can be held liable for the resulting damages, including the damages incurred by the revocation of the APSL licensed code.
Think about it. If it's an important patent, Apple won't want to nick it for their PowerBooks (for example) and risk being forced to stop selling their PowerBooks indefinitely. So, in practice, I don't see this being a problem.
Which is, as I understand it, the same situation any OSS project is in with IBM's patent gift. What if Apple uses an IBM granted patent in Darwin? Apple won't be able to sue IBM either, without the resulting consequences.
Agreed, though, Apple should limit the scope to software patents.
And the BSD folks are more libertarian like you say - exactly why they are even less likely to accept such draconian licencing.
You've got libertarian backwards. They *support* corporate rights, which is why the BSD license lets a corporation use their code in proprietary software.
Btw as for reimplementing, yeah it can be done. Both gnome and kde development on zeroconf is pretty much waiting for the reimplementation of mDNSResponder.
mDNSResponder doesn't have to be compiled into GNOME or KDE (KDE getting huffy about a license?). You run it like you do bind, and nsswitch.conf takes care of redirecting lookups (you get it for free in GNOME, no recompiling required). As for GNOME advertising services, they *should* just tie into the system mDNSResponder daemon, but if they want to compile the code in, yeah, they have to re-implement. That's not a big deal. In that case, the reason isn't because the license states you can't sue over patents, but that it's not GPL compatible, which puts the APSL in the same boat as just about every other OSS license aside from the GPL and the BSD licenses. No big deal, and that's the way it's *supposed* to work in OSS. Different implementations of the same thing for different reasons. Various MTAs, many DNS servers, and yes, many ZeroConf servers. As long as the protocol is open (and it is), then there's no worry that Apple's mDNSResponder will "embrace and extend", breaking GNOME's built-in ZeroConf services.
To me, your schema seems like an ideal location to enumerate and document your preferences. But let's say you don't give a crap about that; you want to add new preferences by updating the config-file-loading code, but the validator isn't letting your new tags through. Turn off the validator. You don't need it. Just let your config-file-loading code look directly at the XML and take the elements it wants. (BTW, what do you mean by "schema parsing"?)
Correct. And so why can't you just give the storage layer arbitrary XML and tell it to store that? Why have the extra layer of indirection ("dict", "array", etc.)?
People (like you and the guys at Apple) are building generic layers on top of XML and building their domain-specific data types on top of that new layer. XML was supposed to be that generic layer, but you guys have implicitly decided that XML sucks too hard to serve that purpose. I totally agree.
What's the world coming to? First we seem to have someone from Apple purposefully rebutting various points and now we have the legendary Ian Hixie of Opera fame posting correct pedantry here too?
/.?
C'mon folks don't you know that serious devs aren't allowed to waste time posting to
And yes, in plaintext view, this is definitely more readable than XML. With syntax highlighting XML does become more readable, but you don't always have that (vim is not as universal as vi!).
"It's better to keep your mouth shut and be thought a fool than to open it and remove all doubt."
How did they resist calling it iLaunch? Must be some new guy working there.
Yes, it includes launchd, but it doesn't, for example, include any GUI whatsoever.
IOW, aside from a different architecture, it will feel like just another open source BSD-style OS.
Hasn't Jordan had his discrete word with you yet? I'll summarize what he's going to tell you... shut up!
While you're being quiet you can try googling for runit, minit, daemontools and smf. This has been done before.
If the XML needs a second processing step in order to be validated there's no advantage whatsoever in maintaining the config file in XML; there are far more readable formats that can do the same job. This is just an example of a company chasing a buzzword.
"Apple can be held liable for the resulting damages, including the damages incurred by the revocation of the APSL licensed code."
:) :)
:)
Really? This would be very interesting
I tried reading the wikipedia article on libertarianism but my eyes just kinda glossed over about half way through, so I'll just cede the point.
About the KDE getting huffy about a license.. well I'm a KDE developer and have done a tiny bit coding with mdnsresponder but we are hoping to see what the gnome guys produce as a replacement.
I realise what you are saying, but can you imagine handing out CD's and saying "Here use this nice new kde live cd! You can use it as long as your company doesn't sue apple!"
So, you'd prefer to have DTDs for every item that you want to manage with launchd? I wouldn't.
mbbac
(about being able to sue Apple for damages) :) :)
:-)
Really? This would be very interesting
In all fairness, I'm not a lawyer. It just seems that if someone violates your patent, you'd be able to recoup all related costs. However, the law hasn't always followed my sense of reason and right-and-wrong!
About the KDE getting huffy about a license.. well I'm a KDE developer and have done a tiny bit coding with mdnsresponder but we are hoping to see what the gnome guys produce as a replacement.
It was meant as a little joke, given KDE's use of Qt, which has caused some issues due to the dual-license nature of Qt, and the fear that Trolltech could revoke the license, or otherwise leave KDE hanging (not entirely unlike what happened with BitKeeper).
I realise what you are saying, but can you imagine handing out CD's and saying "Here use this nice new kde live cd! You can use it as long as your company doesn't sue apple!"
That would make for a humorous CD handout session, but there are plenty of strange license requirements in your standard Linux distro. It's not like your average users are all going around bringing patent suits against Apple.
I would wholeheartedly support a campaign to get Apple to limit the scope of the patent lawsuit exception to apply solely to software patents.
I will admit that I wasn't the clearest. However, if you use XML as you suggested. Then for each version of your program which adds preferences you need a new DTD in order for you to fully validate. Since a program should be able to handle all versions of its preferences. You now need to check against multiple DTDs.
If I turn off the validator... well that seems to go counter to your desire to validate against the DTD.
The application in question is lame. There is no separation of preferences storage and application specific details so it is completely aware of the program domain. Need to add a new preference? You have to add it to the raw code that reads/writes preferences (2 places in that program).
I highly suspect the program doesn't handle new versions of the program reading older preferences or the like.
I admit that if the storage was at least an isolated component, it could spit out arbitrary XML. But it would be a lot harder to find the right DTD.
Side question: Hmm, does an XML DTD itself even state what a value of a field should be, or is it always tags about strings? The property list DTD at least has a description for each value of whether it's a string, array, int, hash (dictionary), or boolean.
I decided to go with an Apple Property List in a cross-platform program, without using Apple's Preferences API, because I wanted better preferences than a memory dump. (what my program had been doing.) Because I wanted them human readable. And because I wanted room for growth without having to flex the DTD for every internal and external release of the program.
Basically, I saw what the other program was doing and desperately wanted to avoid what it had done and I was willing to make an isolated storage layer. Property lists fit what I needed out of my storage layer (application shouldn't care about how preferences are stored, preferences shouldn't care what is stored.) And as an added bonus, because of the ubiquity of property lists on MacOS X, there are already tools to work not just with XML, but explicitly with Property Lists.
I'm no XML God, but just a young programmer. And what Apple was doing with the property lists made a heck of a lot more sense than anything else I had seen. And most likely much more sense than anything I could design as well.
Discrete word?
Hell no! Let's get that dirty laundry out and on slashdot!
Please?
At the moment, I can only retrieve values from a property list either by using the CFDictionary interface
That's exactly how you're supposed to do it. It's not meant to be done in another way. Why would you want to do it any other way?
My basic point is that while they are indeed XML, they don't even come close to best practice.
Your whole concept of "best practice" seems to revolve around some ideas that simply don't apply. You want to "pretty print" your property lists? What?
Do us both a favor: Stop inventing abstract points about which to argue. You obviously don't know anything about property lists or the programmatic interfaces surrounding them. If you did, you wouldn't be making nonsense comments like that one. So do us both a favor and go read the Core Foundation documentation about property lists. Okay? Seriously, that's not too much to ask.
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.
You do realize that you can just use init to do this, right?
/etc/inittab:
For instance, I have a client with a dialup server and several USB modems for his clients to connect to. mgetty is only good for one connection, it doesn't reset itself. So I added these lines to
S0:345:respawn:/sbin/mgetty ttyUSB0
S1:345:respawn:/sbin/mgetty ttyUSB1
S2:345:respawn:/sbin/mgetty ttyUSB2
etc.
Just because you (not you personally, but whoever is duplicating init's functionality in other programs) don't know how to use the existing tools, it's not an excuse to write your own, non-peer-reviewed code with potential security problems.
In post-9/11 America, the CIA interrogates YOU!
Calm down. Tiger still includes cron, so it's perfectly backwards-compatible. You never need to touch launchd, if you don't want to.
Signature.
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
Yes, it is easy to parse, because Apple's plist file is not full blown XML, it is a subset. It only has a few "types": dictionary, array, string, integer, real and boolean.
/usr/bin/plutil, which you can use to check the syntax of a plist file, it weighs in at 30K. My version of libexpat.a is 410K.
Apple has a utility
Then, of course, it's open source, so you can modify the configuration file parser any way you want.
If you want to process plist files, you can use this Perl module:
Mac::PropertyList
I'm sorry you've been put in defense mode. Allow me to attempt to assuage your
pains: You have done a good thing. Really. The thing you have built is quite
keen, there's no doubt about it. There is great, thoughtful, capable
craftmanship evident in it. It well suits your needs and the needs of many.
Doubtlessly you have been suffering quite a bit defending your ideas against a
firestorm of both idiocy and valid concerns. Sorry about that. I hope you come
away from the experience ultimately strengthened and without overly long-lasting
trauma.
I am interested in a startup system improvement for my OS like what you've built
for your OS. Please try to read my message not in a mode where you must defend
your creation, and thus are attempting to discredit my needs and reasons, but in
a mode where you attempt to defend my viewpoint. That may make it easier for
you to understand me. Antagonism, however, is appropriate for most of the crap
you'll have to endure here.
I fully understand that this system works very well for Mac OS X. I also
understand that other OSs could adopt the required infrastructure with hardly
any cost and that the availability of the Core Foundation and launchd code
facilitates this. (Sadly, they're not directly usable by me or many advocates
of free software because of the pro-corporate, pro-IP licensing aspects of the
Public Source license, specifically clause 12.1.c.) I feel, though, that my
real concerns might not have been clearly presented.
I should perhaps state one of my concerns this way: The expat distribution is
larger than my OS.
Another point of mine was the ease of read/edit. I suspect that one could
develop a format that allowed for validation without the obscuring tags of an
XML language. Obviously some markup is required, but how much so for a startup
system? Isn't whitespace a great tool for both markup and visually delimiting?
You ask me how daunted I am at reading/editing the example XML doc as if freedom
from discouragement were enough. Might I suggest that there's much more room
for facility than just getting past dismay? Perhaps you meant "daunting" in
exaggeration. From your perspective XML is far from confusing. Is it possible
to create a markup that lends itself to immediate comprehension instead of
requiring the amount of time you've spent to learn XML?
What you've done suits your needs and the needs of many well. You were not
developing with me in mind, so you have not failed in this regard. I will say,
however, that I believe there is a yet better solution that would satisfy your
requirements of serializing and validation while also satisfying my desires of
of small parser, legibility, editability, and format intuitiveness. It would
not, however, satisfy your desire for cleanly using your existing
infrastructure, which you haven't stated explicitly that I can see.
Why release the code at all if you want to maintain control over it?
The GPL does "limit" those who can make use of the code.
Jesus was a compassionate social conservative who called individuals to sin no more.
Usually more that simple restarting is what is desired.
That is true. But I think it would have been a much better idea to simply transition to UTF-8 (or to specify the encoding at the top).
Not sure what you mean here. If you chose to go the DTD route, youd only have a DTD for every type of launchd config file, not for every program you want to launch.
80-column hard-wrapped text is not a sign of intelligence. if anybody had actually read your comment, they might have found something worthwhile inside it.
well, no, not really. your comment was stupid. but it was stupid and 80-column-hard-wrapped, making it doubly worthless.
please die of ass cancer.
Perhaps. But you know how secretive Apple is about new products, right? I know a guy who's a mid-level manager somewhere in software at Apple, and he claims he knows nothing about new hardware releases until they're unveiled to the public. Seems it's not so far fetched to assume similar "information firewalls" exist in various areas of the software side.
Kinda reminds me of the defense industry, where a lot of classified programs are "need to know." You may have a clearance level high enough to know about a certain project, but if you don't need to know about it for your daily work, then you don't get to know about it. A lot of cool stuff could be going on in the next building, but you'd never know unless you were asked to work on that project!
That is correct. If your preference parsing code needs to be that flexible, then I don't know of any current XML typing system that can handle it (DTD, Schema, Relax NG, etc). Thats why you shouldn't use one.
My desire to use a form of declarative typing only applies if you can use declarative typing. If you feel you need things to be more flexible and are willing to check everything operationally, then check the XML directly. Property list XML creates an entire layer on top of plain XML and then uses a DTD to validate that extra layer. It's a zero-sum setup. All they added was overhead.
I'm not sure what you mean. If you're going to use arbitrary XML, why would you need a DTD?
I don't think DTD allows this, but XML Schema or Relax NG might.
The original format was much simpler to read and parse. In your case, you can claim that you didn't feel like writing a parser for the original format (even though I guarantee you could have done it in less than a day) and wanted to use an off-the-shelf XML parser. Apple, however, already has a working parser. There was no reason for them to create the property list XML format.
Please read my post. I'm not saying property lists suck. I'm saying property list XML is pointless.
The only people making a big deal over his employment is the /. peanut gallery.
Free Mac Mini Yeah, it's
Yes, 'Flamebait' was correct. 'Idiot' would have been more correct, had that option been available. The guy you responded to stated your exact point in a more succinct manner! He was saying that hibernate and sleep are different, and that Macs only have sleep. You fucking moron!
I'm just a troll lurking under the bridge who's read the discussion up to this.
.plist, because .plists are xms, i discovered that they are xml in name only.
.plists.
Essentially, the new xml property list format gets only one thing from being xml, which is UTF-8.
I've tried programming macs before. When I tried editing a
They're
I too would prefer a true xml format, but I guess I'm not a serious mac dev who understoof CF first.
ObTroll:
Mein Führer has a first name, it's A-D-O-L-F!
Mein Führer has a second name, it's H-I-T-L-R!
yeah, you need to define the columns first
--a guy who stores his address book and planner in such a format
A discrete word? Capt. Kirk comes to mind!
In any case, try to keep it discreet - if ASOTV works at Apple, I'm sure the PR guys or The Steve himself would eat him alive if they find out.:-)
"One True Solutions" do not work. XML is not easily piped, and does not play well on the command line. While you might not care about the command line, it is the interface where a lot of us are most productive.
DOM trees are a pain in the ass for cases (and most cases are) where trees are not the ideal data structure to use.
That's exactly how you're supposed to do it. It's not meant to be done in another way. Why would you want to do it any other way?
Because maybe I don't want to learn yet another API for no good reason. What's the point of having it written in XML if the only way to conveniently access it is by using a different API? It's a PITA if I need to track down a module for accessing property lists in every tool I use.
Your whole concept of "best practice" seems to revolve around some ideas that simply don't apply. You want to "pretty print" your property lists? What?Sure, why not. Let's say I want to write a utility that lets me view all of my launchd config files.
Do I want the end-user to see raw XML? No. So I write an XSL template to reformat the data into something more presentable and present it in a web view. Whoops! Can't do it - have to write code instead (the separation of keys and values prevents me from doing any useful reformatting).
Another example: I want to find the launchd items that directly depend on another item - and there isn't a CFDictionary implementation in the tool I'm using, but it has a perfectly good XML implementation.
Because the property list XML isn't structured properly, I have to write a chunk of pointless deserialization code to get to the data I need, while if the data was formatted correctly in the first place, it would be a trivial one liner.
The strength of XML isn't just the data format - it's the wealth of tools that exist for operating on arbitrary XML data. The damage was limited when it was an Apple specific mechanism, but now they are presenting this to the wider community.
My idea of best practice in XML is the ability to leverage the tools that exist for operating on XML. Your argument that validation is the only thing that anybody would ever want is just closed-minded and your assertion that every development tool should include a CFDictionary implementation to deal with the format's deficiency is just silly.
It's not hard to fix the property list format. Just make the values and keys more strongly bound - eg something like: <item key="blah">value xml data here</item>. There is nothing lost by doing this - and everything to gain. CFDictionary is no longer required to easily access property lists, and they are easily transformable.
Say I have a couple of widgets that display continuously updated information from the Net. Say one's a weather app, and another is a news or stock ticker. Now let's say that I'm on a laptop that's on a slow modem connection (or a fast connection accessing a busy, laggy server). When I bring up the Dashboard, I want those widgets to be displayed instantly with up-to-date information. If it's been 30 minutes since I last looked at them, I don't want to wait 5 seconds or however long it takes to update those widgets. I want them to be updated regularly so that when I activate the Dashboard, they are already up-to-date.
This applies for many, many things, like weather apps, stock tickers, news tickers, flight trackers, buddy lists...just about anything that gets info from the Net.
It's a very basic concept. Geez, how much CPU time does it take to download some XML data file, process it, and update a widget off-screen? Run it with a low priority and it will slow nothing down. Write the widget well and it won't waste CPU time in some continuous "do I need to update myself now?" loop.
"Those who consume the bulk of goods are those who make them. We must never forget this secret of our prosperity."
Why is it that people like you can't put two and two together? Why is it you can't face the possibility (the very strong possiblity) that the guy doesn't work for Apple at all and has all of you fooled?
Personally, I think it's because you want so much to believe in this guy that you just blindly accept whatever he says (even if it's plain wrong).
Because maybe I don't want to learn yet another API for no good reason.
You don't have to. We're talking about launchd, remember. No APIs to learn.
What's the point of having it written in XML if the only way to conveniently access it is by using a different API?
We've been over this and over this and over this. The point is that XML files are self-validating.
Let's say I want to write a utility that lets me view all of my launchd config files.
That would be a spectacular waste of time. There's no real-world reason to do that.
Another example: I want to find the launchd items that directly depend on another item
Dependencies are determined automatically at boot time. They're not static.
You continue to try to come up with contrived, artificial examples. Why? Don't you understand that by definition, a contrived, artificial example isn't representative of how people actually use property lists, and therefore isn't going to convince anybody of anything.
Just make the values and keys more strongly bound - eg something like: value xml data here
Impossible. No type checking that way. Remember, property lists are serialized data structures. They have to preserve type data and be compliant with a well-defined and universal DTD.
As a far a whats he's saying? Hell, I don't know enough about unix services to tell. Could be wrong.
Free Mac Mini Yeah, it's
The topic is my ability to write a tool that can read property lists without using a new API.
Your assertion that nobody wants to read from these files is just silly. Is there somehow one magic configuration tool that performs every operation that one would every desire, every reporting capability you would desire?
I propose that somebody might want to write a utility that lets them easily display the current set of tasks that launchd has been tasked with, and your response is why anybody would want to know this? (perhaps to unify with an inhouse system management tool, if you want a specific reason why).
Somebody wants to write a system-wide policy tool that will disable a particular daemon, but only if it isn't depended on by any other service.
I'm writing a configuration tool for a daemon that I've written and I want to edit the property list for my tool to configure the parameters.
The current property list mechanism does not use good XML. It can be improved, and a new DTD written that will validate this improved form.
All I'm saying is that instead of:
<key>someKey</key><string>someValue</string>
you should have something like:
<item key="someKey"><string>someValue</string></item>
All your typing information is still there, it can still be validated - but all of a sudden every other XML tool in existence can be used with it, and no requirement for CFDictionary.
I'm sorry, but your argument that nobody could ever want to check how launchd is currently configured and so it's fine that the configuration data is poorly encoded is just silly.
So what you're saying is, there's no possible way that anyone, anywhere, would ever write the tool that you need, so therefore you need to roll up your sleeves and write your own (something that's typically a case of re-inventing the wheel).
And even though you've made the decision to write your own tool, you don't want to have to bother with actually learning anything, you just want to use the knowledge you have from other projects, so the entire OS needs to change the format of every single property list to conform to your pre-existing knowledgebase.
This is what you're asking. You know how to do it the right way, but you don't want to learn how to do it the right way, and you're whining about how you can't do it the way you've always done it. Hmm. So do you regularly complain to kids who walk onto your lawn? I mean, that's crotchety old man talk.
The topic is my ability to write a tool that can read property lists without using a new API.
You never would. Read on.
Is there somehow one magic configuration tool that performs every operation that one would every desire, every reporting capability you would desire?
I feel that you have lost sight of the ball. We are talking about configuration files here, specifically configuration files for launchd. There are no operations to be performed on them, no reports to be generated that launchctl doesn't do for you already.
I propose that somebody might want to write a utility that lets them easily display the current set of tasks that launchd has been tasked with
You mean "launchctl list?"
Somebody wants to write a system-wide policy tool that will disable a particular daemon, but only if it isn't depended on by any other service.
You mean "launchctl stop (servicename)?"
I'm writing a configuration tool for a daemon that I've written and I want to edit the property list for my tool to configure the parameters.
Groovy. Core Foundation is your friend.
The current property list mechanism does not use good XML.
Sorry, but "Some guy on Slashdot would like it to be different" isn't that convincing. Remember, please, that we've been using XML property lists for six years now. Somehow the Earth has continued to orbit the sun.
I'm sorry, but your argument that nobody could ever want to check how launchd is currently configured and so it's fine that the configuration data is poorly encoded is just silly.
And your authoring a lengthy and multi-part excoriation of the launchd configuration file format without ever stumbling upon awareness of launchctl, which does precisely what you insist can only be done by examining configuration files, is at least as silly.
Does launctl be run as a web service?
Is the output easy to parse so I can get it into the form I want?
Can launctl stop service be run automatically and log something to a postgresql if it couldn't be run for some reason?
Apparently in your world all software is completely perfect and doesn't require custom applications to be written. Apparently I've been wasting my time writing development tools.
I didn't way the propertly list xml was unable to do the job, just that it was badly structured - a concept that you seem to take personally.
My issue here is that while it's previous scope was limited to application manifests, preferences, etc, the issues were limited, but as part of a bold new platform for process launching - something that is far more likely to want some degree of customized reporting within the enterprise, its shortcomings are painfully apparent.
And ultimately my point that it's silly that you should be forced to resort to CFDictionary to do anything with a property list that isn't provided by launchctl can't be countered with "you should use CFDictionary".
If I want to write a web service using PHP that wants to access config data, where's my CFDictionary interface?
If I'm writing something with Java under Linux, where's my CFDictionary interface?
If you want something closer to home, where's my CFDictionary interface in RealBasic?
The fact that you can obviously spend so much time posting to slashdot indicates that you don't do much of importance. I do.
Does launctl be run as a web service?
I think there's a syntax error in there somewhere.
Is the output easy to parse so I can get it into the form I want?
What form do you want? I'm fairly certain, based on your comments so far, that your answer is going to be something ridiculous, so before I even go down that road, what form do you want?
I didn't way the propertly list xml was unable to do the job
Have you been drinking? You shouldn't post while you've been drinking.
My issue here is that while it's previous scope was limited to application manifests, preferences, etc, the issues were limited, but as part of a bold new platform for process launching
"Bold new platform?" You do know that we've been using property lists everywhere since 1999, right? Including as SystemStarter configuration files. Using them in launchd is neither bold or new.
If I want to write a web service using PHP that wants to access config data
On what planet would you ever write a PHP application that gives any random Web user access to your computer's system configuration? No, that's (as I predicted) a ridiculous example.
If I'm writing something with Java under Linux, where's my CFDictionary interface?
In the Core Foundation bindings for Java.
If you want something closer to home, where's my CFDictionary interface in RealBasic?
Because that's a third-party application I can't speak authoritatively, but if it doesn't provide access to Core Foundation, it's not a very useful tool, is it? Seeing as how every Mac OS X application uses Core Foundation and all.
The fact that you can obviously spend so much time posting to slashdot indicates that you don't do much of importance. I do.
Are you also going to tell me that I'm ugly and that my mother wears army boots? Is that the point we've reached?
For example, the ssh-agent daemon (think "keychain for ssh passwords") needs to launch once, and only once for each user login session. Shell startup files are read every time a shell is started. Multiple terminal windows means multiple shells, but still only one login session.
.bashrc or .cshrc; someone tell him about .login or .profile.
Apparently Siracusa hasn't advanced beyond
It's a new twist to old-school Unix hackers, and the initial reaction is predictably cautious.
It's not just a "new twist", it breaks dozens of system management frameworks.
Just keep on repeating your same drivel. Maybe then someone will realize that you actually don't have anything worthwhile to say. launchd is taking a minor parsing hit (something you do, what, once?) for some sizeable gains in flexabiltiy. You idiots would be better off to just say "we like the old way" and be done with it, because your repetitive arguments against making things better with launchd just make you look like technical luddites.
Yes, everything should stay the same, so that we do not have to increase our skillset or allow someone who doesn't know our secret config file rules to admin our systems. Please. Go cry to your mommy if knowing arcane file formatting doesn't make your resume as shiny as it used to be.
>> The fact that you can obviously spend so much time posting to slashdot indicates that you don't do much of importance. I do.
:)
> Are you also going to tell me that I'm ugly and that my mother wears army boots? Is that the point we've reached?
Have you had a word with Jordan yet? Didn't he tell you you might want to see a therapist about your slashdot addiction?
Your assertion that XML is more flexible is baloney.
You are suffering from the 'I only have a hammer' syndrome. Not everything needs a tree structure.
To use text, you have to know the formatting of the text. To use XML you have to know the schema. The reason text may be more 'arcane' to you is because it is written most appropriately for the application at hand.
Might as well ban regular expressions. They look arcane and funny. Why not write those in XML?
I scanned through the man pages but didn't see how to use launchd as a cron replacement. I'm about to upgrade to 10.4 and currently use cron to run my nightly backups. Does 10.4 no longer provide cron? How do I configure launchd to run my nightly script? Can someone point me to the appropriate FM?
Don't underestimate the power of The Source
Knowing the data model for XML in many cases is more complex than knowing the character set/encoding/syntax/data model. Now while it is rarely that much more complicated, it does happen to be more complicated.
You have to parse the entire tree in before you can start to deal with it, unless you wish to write a SAX parser. You have to write a SAX parser with large trees in any case.
The reason I'm not too wild about XML is that its not great for communication between programs that pass lots of data back and forth between them. Often, simple text protocolls ARE great. Where small-medium tree structures are called for, then XML is great in that space.
Do not trust any 'one true solution'
But launchd has obsoleted and replaced what used to be the status quo. Now it's the status quo.
I was refering to the status quo in the wider unix comunity and not specifically tiger.
So, Declaritive typing for relatively straightforward things is good? As in all Launchd things use a standard set of properties, so there should be one DTD for that. And if things change a little bit in the next OS, they get a launchd dtd version 2.0.
In a similar fashion either a dozen different DTDs for different flavors of bundles (apps, frameworks, plugins, widgets, etc...) Or one master DTD that needs to flex with a root element based upon bundle type.. and then have a problem with 3rd party bundle objects. And still more versions of DTDs as time passes.
I'm not sure how Apple could flex the preference system though to both use uniform tools, editors and APIs as they currently do.
Somewhere in the mix, in Apple's transition from NeXT to MacOS X they ended up deciding on one XML format as a flexible data serializer. So for them, their preferences API just taps into the deeper plist API. And their plist API now gets a boost from XML as it can programatically work with the structure while relying on deeper, public and more tested XML libs to deal with common parsing. And from the App's perspective, they just ask for a key value and get their contructed object data.
It seems to me like Apple got what they needed out of the format. And most of the inefficiencies in the format fall into statistical gaps in the modern computer. Bigger file size? It's still under the minimum 4k allocation per file. Longer processing time? my computer still boots into MacOS X faster and does more than my older computers. Human editable/readable. Format was arcane before, and while wordier now, there's more tools in the forms of syntax hilighting and checking text editors that can help cut down mistakes. And I imagine there always was the Property List Editor for either format of the files.
Oddly enough, Project Builder/XCode still seems to use the older plist format for it's build logistics system. Then again it's files are large enough that adding XML to them would make a noticeable change. On the other hand you have Apple's new programs Keynote, Pages using XML. Though I can understand if PB is partly locked to historical restraints. Changing a project file from plist to xml-plist makes it hard to diff to diff across the project conversion line.
I'd not actually encountered the orginal versions of plists by that point in time. Text config files under unixes, bat files on stray, rare occasions under DOS. But Apple ][/MacOS life had never exposed me much to either. xml-plist seemed a natural fit at the time I coded my project. Even if I did need to work on my own code to grok the output of libxml's hooks and APIs since I wasn't using Apple's plist APIs in my program. (I wanted the format, I didn't want to be tied to the OS.) And either way I imagine my code has some holes on it's end due to sheer rawness. :)
Yes, programming declaratively (when you can) has many benefits over programming operationally. But remember that DTD, while declarative, isn't the most powerful declarative type system. Like you said, it can't handle multiple similar versions efficiently.
And remember, I'm not saying that you must use DTD. If it's not convenient, don't use it. I only brought this up to demonstrate that you can't use DTD to validate your plist XML data (in response to someone saying that using plist XML gives you validation for free).
Well, you can either write a declarative specification for every single type, or you can write code to manually validate every single type. Take your pick. Though DTD has its problems, this isn't one of them.
Their plist API gets no benefit, but I think you meant plist implementation. Old-style plists already have a well-tested parser (which, I'm guessing, they still have to support).
Besides, writing a parser is the uncommon case. You essentially only have to do it once. Writing and reading plists is an overwhelmingly more common case. I think the imbalance is high enough to warrant an specialized syntax for plists that is more readable (old-style plists) and efficient (binary plists). XML is neither (and, in fact, worse than old-style plists on both counts).
Also, parsing old-style plists is very easy. Sure, an XML library will let you avoid dealing with the low-level tokenizing details, but it's nothing that a 100-line Lex file couldn't handle for you. Now that I think about it, it might even be less work to parse old-style plists directly than to interface with an XML library and parse plist XML.
Even with the old format, the App's perspective is the exact same. Why do you keep talking about how plists are so great? The question here is whether plist XML is better than the old plist syntax (and answer no :).
The only thing they got was Unicode, which could have been trivially added to the old plist format. I agree that the performance degredation is tiny, but relative to the benefit (zero), it is infinite.
Not only wordier, but less readable. Because of the way Apple designed the format the only thing XML tools can do is try to offset the overhead created by XML in the first place. It's a net loss.
Think about what would happen if C++ was written in XML form. It might look something like this pile of crap. Would you rather edit that stuff in an XML editor or edit C++ in a text editor? It doesn't matter how good your
ASOTV has that part wrong. The blue screen is the start of the WindowServer or loginwindow. Hardware test and OpenFirmware is over the minute the "spinny thing" under the gray Apple logo starts. launchd is the fist thing started by the kernel and starts during the "spinny thing" time.
Man, you really can't take any criticism of your holy cow, can you?
Apparently Siracusa hasn't advanced beyond .bashrc or .cshrc; someone tell him about .login or .profile.
It's been at least 20 years since you could depend on programs that start your first shell of a session to correctly figure out whether they should start a login shell or not. And I've had them fail both ways. The only thing I've found that's at all workable is to have an environment variable that's got the PID of my login shell in it, and use that to figure out which kind of startup I should do.
That's right, any patent-related lawsuit against Apple voids the license.
Well, I'll set aside the "there's other kinds of patent-related lawsuits" bit, and get right to the point. And that is, I'm trying to see the downside to this clause for anyone who is acting ethically.
You're OK with the GPL, I take it. You don't consider the GPL a Trojan Horse or whatever it is you see in the APSL that bothers you, even though the GPL has a key clause that maks it a trjan horse, and the GNU manifesto makes clear that aspect of the GPL is one of the main reasons for it existing. Now, I'm not making a statement about whether the GPL is good or not, the GPL is clearly useful for a lot of people and has been an effective open source license. But it is a clear precedent that just being a trojan horse is not enough to make a license "non-free".
This clause prevents you from filing a patent infringement case against Apple except defensively. This is a problem if there's a good reason for filing a patent infringement case against Apple, other than defensively... IF you're in a business where access to Apple's source code is sufficiently important that this is a deterrent.
The distance between existing practice and the goal of the patent system... particularly in the areas of patent law that Apple is likely to violate... is so huge that while I am open to being convinced that this is a bad thing it'll take some doing. I don't see how this can be used effectively against individual creators, or against companies whose use of Apple's source code is an incidental part of their business, it's only useful against companies for which the software they're getting from Apple is going into their core business.
Now, what kind of patents are they likely to be holding?