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.
You wouldn't want to use 1080/24p cameras for sports. The frame rate is too low. A 60 Hz frame rate is optimal for sports, which means either 1080i or 720p. Opinions differ, but 1080i looks better to me.
And the film issue isn't as simple as you think. Let's come up with a very simple example.
You have four frames of film, ABCD. Okay? You need to stretch that out to five video frames, or ten video fields. So you scan each film frame into two fields, 1 and 2. So you have A1A2, B1B2, C1C2, D1D2. With me so far?
You recombine these to create five video frames: A1A2, B1B2, B1C2, C1C2, D1D2.
It's trivially easy to pull out these repeated fields as long as you've identified your A1A2 frame. It's just iteration after that.
The problem comes when there's a cut, as there always is in TV programming. The network decides to cut away, but they do it on the B1B2 frame instead of the A1A2 frame. Suddenly your TV or set-top device freaks out because it's dropping the wrong fields. The picture looks crummy.
Removal of 3:2 pulldown is trickier than you might think.
it will combine the 1080i field pair into a single 1080p signal
This will, of course, suck.
There are two different ways to get 1080i material. You can either shoot some other format at 24 frames per second and convert it to 1080i, or you can shoot 1080i.
If you shoot film or 1080/24 at 24 frames per second and convert to 1080i, there are a set of well-defined tricks you can use. These tricks are collectively referred to as "pulldown." It's possible to remove pulldown, which is great... except these automatic schemes usually break on cuts, which means they introduce more artifacts than they remove.
If you shoot at 1080i, like for a sporting even or live broadcast, then combining the two fields into a single 1080p frame is going to make it look like ass. Because when you shoot 1080i, you're capturing the upper field 16 milliseconds before you capture the lower field, which means your subject moves between capturing field A and capturing field B. If you then just shove these two fields together, you're going to get a blurry picture.
It's a widely repeated fallacy that 1080p is inherently superior to 1080i. The two formats are equivalent in most respects, and going from one to the other is not a "up-conversion." If done wrong, it can be a down-conversion.
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.
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?
Must be a Linux idiom. In every other system with which I'm familiar, the practice of launching a statically-linked shell as PID 1 is called booting in single-user mode.
How is that not precisely the behavior your want? System services are atomic; you either want them to launch or you don't. You don't want a service to launch but under the wrong UID, for instance. That could screw all kinds of things up.
With launchd, if the service's config file is invalid for any reason, that service is simply ignored.
Yet another reason Apple is wrong in claiming 'a UNIX core' to their OS.
Never happened. All the marketing materials are very careful to say "Unix-based." As in, "evolved from Unix." As in, "started with Unix and then got better."
The Unix philosophy is for there to be many valid and well-characterized ways.
That has never, ever been a part of the Unix philosophy by any interpretation. It's a total side-effect of the fact that everybody seems to want to write his own whatever -- service launcher, Internet superserver, periodic task running, whatever. It's a side-effect, not a design goal.
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.
Nice display of... um... situational unawareness. Nobody was talking about NTFS. We weren't even talking about Windows. We were talking about the Entourage database format.
(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.)
Everything you said is true, but possibly misleading. Nobody needs Core Foundation's XML parser to use property list files. Property list files are created through serialization and "parsed" through de-serialization. You don't need to hand it to an XML parser or run Xpath on it or any of that poop. You just pass the file to CFURLCreateDataAndPropertiesFromResource, then pass the resulting data to CFPropertyListCreateFromXMLData. What you get back is a CFPropertyListRef which can be cast to a CFDictionaryRef.
Like you said, all that's open source.
Re:Not a cron replacement, a init replacement
on
Does launchd Beat cron?
·
· Score: 2, Interesting
Okay, touché. If you use the word "daemon" to refer to any non-interactive program, the sure, init and everything else that isn't an application or a tool is a daemon.
I'm more accustomed to the definition that a daemon is a server, like ftpd or named. It's just the terminology that I learned years ago, and it's stuck with me ever since.
But if you want to throw that out, I'm cool. Yes, launchd is a daemon, in that it's not a user-interactive program.
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.
Well... to put it bluntly... yeah. Look, you and many other commenters here act like we just made up a whole new XML document type just for launchd. I have no problem with people who want to raise valid concerns, but would it kill you to learn thing one about Mac OS X first?
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?
Re:Not a cron replacement, a init replacement
on
Does launchd Beat cron?
·
· Score: 5, Informative
There is no access layer that surrounds a plain text file.
In fact, there is. With Core Foundation, the process of unserializing a property list is atomic. The bytes are read from disk and validated. If and only if the file validates, the data structure is populated and returned by reference, all in one function call.
So yeah, property lists are self-validating.
You have to be DAMN sure that the file is easy to understand and edit by an admin, even if he only has "ed" over a serial connection available.
You mean like the universal, thoroughly documented and self-validating property list format, for example?
I'd much rather work with: TAG:VALUE
Great... right up to the point where "TAG" has a colon in it, or whatever your delimiter. Or where "TAG" or "VALUE" needs to be in Japanese. Or where "VALUE" needs to be a container like a CFArray or a CFDictionary.
Or, for that matter, where "VALUE" needs to be of a specific type. If you're stuck with "TAG:VALUE" then you're kinda screwed when it comes to explicit type-checking, aren't you?
I can confidently write a program to validate and parse inittabs, but I don't know how to that with XML
You aren't expected to. Core Foundation does it for you. There's one function call to serialize a data structure and one function call to un-serialize it.
XML files, are difficult to read, difficult to edit, difficult to edit with programs, and poorly-defined.
Come on, now. Isn't that kind of a stupid statement? XML files are spectacularly easy to read, especially compared to the random mish-mash of configuration-file formats available on Unix. Editing is trivial, of course, because it's just text. More importantly, editing is trivial wherever you are, because the files are UTF-8 and not just ASCII. And calling a document that includes a machine-readable DTD for automatic validation inside it "poorly defined" borders on the farcical.
Some of us have been complaining since the NeXT days.:\
That's funny. Because there were no XML property lists in NEXTSTEP. They were added for Mac OS X.
Maybe a better one would be, say, something corrupting the line that says some program shouldn't run as root (if such a property exists -- if not, use your imagination).
You mean the UserName key? Sure, I suppose it's possible that some mechanical process could alter the bits on the disk so that the value for the UserName key becomes "root" instead of "littlebilly." But it's not very likely, is it?
Basically the gist is, if there's an error isn't it more secure to abort entirely rather than possibly run something the wrong way?
There's a difference between refusing to fire off a given task defined by a (truncated, whatever) config file and leaving the computer in an unbootable state. If inittab were to be truncated, your computer would fail to book. With launchd, you never have to worry about that.
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.
Re:Not a cron replacement, a init replacement
on
Does launchd Beat cron?
·
· Score: 3, Informative
1. There are not "more versions of XML" than there are of anything. There's exactly one version of XML.
1a. It doesn't matter, because we're not using whatever valid XML you decide to poop out. We're using Property List 1.0, which is a specific XML document type.
2. We're not forcing anybody to do anything. We're offering third parties a chance to use our innovation. If they don't want it, they don't have to take it.
2a. Nobody would ever use an XML parser to read a plist anyway. You just use the serialization/unserialization routines we've written into Core Foundation, which is also part of Darwin and therefore also open source. You turn a plist into a CFDictionary in about three lines of standard C code, counting error-checking.
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.
Re:Not a cron replacement, a init replacement
on
Does launchd Beat cron?
·
· Score: 0, Flamebait
Did you copy-and-paste this or something? Because it's not relevant to the comment to which you replied.
For the record, SystemStarter is deprecated in Tiger. All third parties are encouraged to stop using SystemStarter packages and move to launchd. The launchd service replaces SystemStarter.
Slashdot Mirror
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.
You wouldn't want to use 1080/24p cameras for sports. The frame rate is too low. A 60 Hz frame rate is optimal for sports, which means either 1080i or 720p. Opinions differ, but 1080i looks better to me.
And the film issue isn't as simple as you think. Let's come up with a very simple example.
You have four frames of film, ABCD. Okay? You need to stretch that out to five video frames, or ten video fields. So you scan each film frame into two fields, 1 and 2. So you have A1A2, B1B2, C1C2, D1D2. With me so far?
You recombine these to create five video frames: A1A2, B1B2, B1C2, C1C2, D1D2.
It's trivially easy to pull out these repeated fields as long as you've identified your A1A2 frame. It's just iteration after that.
The problem comes when there's a cut, as there always is in TV programming. The network decides to cut away, but they do it on the B1B2 frame instead of the A1A2 frame. Suddenly your TV or set-top device freaks out because it's dropping the wrong fields. The picture looks crummy.
Removal of 3:2 pulldown is trickier than you might think.
it will combine the 1080i field pair into a single 1080p signal
... except these automatic schemes usually break on cuts, which means they introduce more artifacts than they remove.
This will, of course, suck.
There are two different ways to get 1080i material. You can either shoot some other format at 24 frames per second and convert it to 1080i, or you can shoot 1080i.
If you shoot film or 1080/24 at 24 frames per second and convert to 1080i, there are a set of well-defined tricks you can use. These tricks are collectively referred to as "pulldown." It's possible to remove pulldown, which is great
If you shoot at 1080i, like for a sporting even or live broadcast, then combining the two fields into a single 1080p frame is going to make it look like ass. Because when you shoot 1080i, you're capturing the upper field 16 milliseconds before you capture the lower field, which means your subject moves between capturing field A and capturing field B. If you then just shove these two fields together, you're going to get a blurry picture.
It's a widely repeated fallacy that 1080p is inherently superior to 1080i. The two formats are equivalent in most respects, and going from one to the other is not a "up-conversion." If done wrong, it can be a down-conversion.
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.
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?
Must be a Linux idiom. In every other system with which I'm familiar, the practice of launching a statically-linked shell as PID 1 is called booting in single-user mode.
How is that not precisely the behavior your want? System services are atomic; you either want them to launch or you don't. You don't want a service to launch but under the wrong UID, for instance. That could screw all kinds of things up.
With launchd, if the service's config file is invalid for any reason, that service is simply ignored.
Yet another reason Apple is wrong in claiming 'a UNIX core' to their OS.
Never happened. All the marketing materials are very careful to say "Unix-based." As in, "evolved from Unix." As in, "started with Unix and then got better."
The Unix philosophy is for there to be many valid and well-characterized ways.
That has never, ever been a part of the Unix philosophy by any interpretation. It's a total side-effect of the fact that everybody seems to want to write his own whatever -- service launcher, Internet superserver, periodic task running, whatever. It's a side-effect, not a design goal.
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.
However, the need for both SystemStarter and launchd seems clear.
Think again. The roadmap leads to the complete phase-out of SystemStarter. It's been completely deprecated.
I see no means within the launchd subsystem of cleanly specifying dependancies among different daemon plists
That's 'cause launchd auto-detects dependencies. There's no need to specify them.
Nice display of ... um ... situational unawareness. Nobody was talking about NTFS. We weren't even talking about Windows. We were talking about the Entourage database format.
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.)
What self-respecting OpenSource developer would even care to link with the NS junk?
"You can lead a horse to water, but you can't make him drink."
Everything you said is true, but possibly misleading. Nobody needs Core Foundation's XML parser to use property list files. Property list files are created through serialization and "parsed" through de-serialization. You don't need to hand it to an XML parser or run Xpath on it or any of that poop. You just pass the file to CFURLCreateDataAndPropertiesFromResource, then pass the resulting data to CFPropertyListCreateFromXMLData. What you get back is a CFPropertyListRef which can be cast to a CFDictionaryRef.
Like you said, all that's open source.
Okay, touché. If you use the word "daemon" to refer to any non-interactive program, the sure, init and everything else that isn't an application or a tool is a daemon.
I'm more accustomed to the definition that a daemon is a server, like ftpd or named. It's just the terminology that I learned years ago, and it's stuck with me ever since.
But if you want to throw that out, I'm cool. Yes, launchd is a daemon, in that it's not a user-interactive program.
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.
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?
There is no access layer that surrounds a plain text file.
... right up to the point where "TAG" has a colon in it, or whatever your delimiter. Or where "TAG" or "VALUE" needs to be in Japanese. Or where "VALUE" needs to be a container like a CFArray or a CFDictionary.
:\
In fact, there is. With Core Foundation, the process of unserializing a property list is atomic. The bytes are read from disk and validated. If and only if the file validates, the data structure is populated and returned by reference, all in one function call.
So yeah, property lists are self-validating.
You have to be DAMN sure that the file is easy to understand and edit by an admin, even if he only has "ed" over a serial connection available.
You mean like the universal, thoroughly documented and self-validating property list format, for example?
I'd much rather work with: TAG:VALUE
Great
Or, for that matter, where "VALUE" needs to be of a specific type. If you're stuck with "TAG:VALUE" then you're kinda screwed when it comes to explicit type-checking, aren't you?
I can confidently write a program to validate and parse inittabs, but I don't know how to that with XML
You aren't expected to. Core Foundation does it for you. There's one function call to serialize a data structure and one function call to un-serialize it.
XML files, are difficult to read, difficult to edit, difficult to edit with programs, and poorly-defined.
Come on, now. Isn't that kind of a stupid statement? XML files are spectacularly easy to read, especially compared to the random mish-mash of configuration-file formats available on Unix. Editing is trivial, of course, because it's just text. More importantly, editing is trivial wherever you are, because the files are UTF-8 and not just ASCII. And calling a document that includes a machine-readable DTD for automatic validation inside it "poorly defined" borders on the farcical.
Some of us have been complaining since the NeXT days.
That's funny. Because there were no XML property lists in NEXTSTEP. They were added for Mac OS X.
Maybe a better one would be, say, something corrupting the line that says some program shouldn't run as root (if such a property exists -- if not, use your imagination).
You mean the UserName key? Sure, I suppose it's possible that some mechanical process could alter the bits on the disk so that the value for the UserName key becomes "root" instead of "littlebilly." But it's not very likely, is it?
Basically the gist is, if there's an error isn't it more secure to abort entirely rather than possibly run something the wrong way?
There's a difference between refusing to fire off a given task defined by a (truncated, whatever) config file and leaving the computer in an unbootable state. If inittab were to be truncated, your computer would fail to book. With launchd, you never have to worry about that.
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.
1. There are not "more versions of XML" than there are of anything. There's exactly one version of XML.
1a. It doesn't matter, because we're not using whatever valid XML you decide to poop out. We're using Property List 1.0, which is a specific XML document type.
2. We're not forcing anybody to do anything. We're offering third parties a chance to use our innovation. If they don't want it, they don't have to take it.
2a. Nobody would ever use an XML parser to read a plist anyway. You just use the serialization/unserialization routines we've written into Core Foundation, which is also part of Darwin and therefore also open source. You turn a plist into a CFDictionary in about three lines of standard C code, counting error-checking.
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.
Did you copy-and-paste this or something? Because it's not relevant to the comment to which you replied.
For the record, SystemStarter is deprecated in Tiger. All third parties are encouraged to stop using SystemStarter packages and move to launchd. The launchd service replaces SystemStarter.
Any chance of this showing up in AIX anytime soon?
That's entirely up to IBM. Our whole operating system is open-source, available for anybody to use.
It's part of Darwin 8. If we haven't posted that yet, we will soon.