If I remember right, the cron daemon is included, but it doesn't run by default. I guess you could take the time to configure it, but you'd be way better off just firing off your tasks as LaunchDaemons instead.
In all fairness, it sounds like you're the one who's ignoring the elephant in the room. If it's taking five minutes for your laptop to pass POST, you need to take it in for repair. It's obviously got a hardware problem.
The reason systems DON'T boot when/etc/intttab get's toasted is they SHOULDN'T boot with out the service it kicks off running.
That's a pretty radical retrograde interpretation of the facts. The reason system don't boot when inittab has an error in it is because init lacks any mechanism for recovering from config-file errors. We fixed that.
When inittab is toasted on one of my AIX servers, I simply boot off of the install CD or a backup tape(yes I can do that). I mount rootvg in maintenance mode, FIX inittab and then reboot. That simple.
So what you're saying here is that you don't like Apple because we're making your job obsolete?;-)
The "get toasted" expression wasn't my choice of words. I was quoting. I would have said, instead, "what happens if, say, you fat-finger inittab while editing it."
The problem with traditional Unix configuration files is that they're not self-validating. A single typographical error can very easily result in an unbootable system. XML-based property lists reduce that possibility. They don't eliminate it entirely, of course; nothing could. But they reduce it.
They also open up the door for us to make the launch system self-repairing. Check out the changes to NSUserDefaults in Tiger to see what I mean there.
Re:Submitter is confused - Mod parent offtopic.
on
Does launchd Beat cron?
·
· Score: 4, Informative
We did open-source launchd. It's part of Darwin 8.
Then launchd posts an error in the log, and that service doesn't run. As opposed to what happens if, say, inittab gets toasted, rendering your computer unbootable. Sounds like an improvement to me.
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?
We replaced many small programs that all do the same thing with one small program that all does the same thing. In the process, we eliminated five different cryptic configuration file formats, replacing them with one property list format which has already been in use for five years and consequently is well known.
Is there a way to make Dashboard widgets sticky on the desktop?
You don't want them to. One of the benefits of the Dashboard layer is the fact that when the Dashboard isn't visible, the widgets are completely suspended, consuming no CPU cycles at all. If you put a widget on the screen outside the Dasboard layer --which of course you can do, if you run Dashboard in debug mode --it'll execute its run loop all the time, sucking up CPU cycles unnecessarily.
Re:Not a cron replacement, a init replacement
on
Does launchd Beat cron?
·
· Score: 5, Informative
Is there any reason why a daemon is necessary to improve startup time?
The launchd service isn't a daemon. It's a replacement for init. And yes, it speeds things up considerably. Previously, every startup script required its own instance of a shell to be fired off. Now that middleman is removed. And it made things considerably faster and simpler.
But why XML over say something like INI or a much simplier format?
Because XML is self-validating, like I said. The contents of the file can be checked for consistency before being used for anything.
It also quickly becomes unreadable.
You don know that we're talking about property lists here, right? It's an XML-based format, but it's not totally free-form XML. You can't just plug in any valid XML and expect launchd to handle it. If the file doesn't validate against the property list schema, launchd will just ignore it.
Besides, we've been using property lists everywhere for five years now. Nobody's complained yet.;-)
I think, to the contrary, we've greatly simplified Mac OS X. When it comes to programs that run without being explicitly started by the user, there used to be six or eight ways to skin the cat, many of which overlapped to a greater or lesser extent. Now there's one.
To keep things simple, we divide the boot process into two halves: the hardware half and the software half. The hardware half involves power-on self-tests, and the time it takes varies wildly from computer type to computer type, or even from configuration to configuration. It takes longer to test 8 GB of RAM than 512 MB of RAM.
The software half begins with the grey Apple-logo screen turns blue and the progress window appears.
From the time that happens to the time the menu bar appears (via autologin) should be four seconds on a stock Mac OS X install with middle-of-the-road hardware (dual 1 GHz G4).
Re:Not a cron replacement, a init replacement
on
Does launchd Beat cron?
·
· Score: 3, Informative
Because XML configuration files are self-validating.
The fundamental problem launchd was created to solve is system startup time. Twenty or thirty seconds to boot a freakin' laptop is just absurd. So we used launchd to get that down to four.
But beyond that, launchd also takes care of the problem of having six different types of configuration files, none of which are self-documenting or self-validating. A launchd configuration file can be validated and, if invalid (like somebody inserted a typographical error, or the file got truncated or something), discarded without interfering with system startup. That makes the system more resilient.
However, when one writes in a particular language, it's customary to spell words in that language. We're speaking English here; it's "Iraq" and not "Irak."
You've been swallowing too much of the Bushie propaganda. Yes, many of the Iraqi troops fell back, but they didn't just give up and go home. They gave up, went home, and became those "foreign fighters" Bushie and Rummy lie to us about.
You don't fight a superior force one-on-one. Even the poor, brown Iraqis know that.
The problem with that idea is that the foreign-fighters idea is a myth concocted by Bushie to distract people from the fact that the Iraqis fought us every step of the way like, well, like a people under occupation by a foreign power.
The people fighting in Iraq NOW are terrorists. They're all car-bombs and beheadings. But the people who were fighting in Iraq up until the end of last year were just average Iraqis like you and me who wanted nothing more than to not be illegally occupied by an imperial power looking to spread its particularly virulent brand of corporatism to their country.
Plus, you know, your idea is inhuman and barbaric. That's a big minus, too.
In other other words, because this information has leaked, the lives of the people, both Coalition and Iraqi, who man highway checkpoints in Iraq have been put in even greater danger.
I know that it's become fashionable to get all conspiratorial and stuff, to think that everything is a cover-up. Hell, I believe that myself most of the time. But sometimes the government classifies things out of a completely legitimate desire to protect people.
I'm about as "fuck the status quo, change the dominant paradigm" as you can get. I think what the US did in Iraq was totally illegal, and that Bushie and his gang of international thugs should be treated just like we treated the Nazis after WWII: a perfunctory trial, then hangings all around. If I had to choose between having Bushie in the White House and Saddam Hussein in the White House, I'd pick Saddam without even thinking twice.
But I'm not enough of an idiot to think that just because some things the government does are corrupt and illegal that everything they do must be corrupt and illegal. Sometimes things are secret for good reason.
Helping terrorists -- real terrorists, this time, not just people who don't happen to subscribe to the corporatist ideal -- kill innocent people isn't going to get us out of Iraq any faster. The best way to get us out of Iraq is to pretend to support the democracy movement, then sit back and cheer when, after the last American solder gets on the boat, the Iraqis reelect themselves a nice, enlightened, Socialist regime and gives corporatism the middle finger. That's how we win.
"You applers?" Horrifying crimes against the English language aside, I'm not really sure I'm buying what you're selling here. In order for that to be true, the average size of each mail message would have to be less than 430 bytes. I don't think that's true.
Here's how it works. The Mac OS Extended filesystem has a minimum allocation block size of four kilobytes. A one-byte file on disk will be given a minimum allocation of four kilobytes. Okay?
Let's say your "mbox" file contains exactly 12,000 messages, and that it totals exactly 11,534,336 bytes. That means each message is an average of about 960 bytes long.
On your Mac, those 960 byte files will be inflated to 4,096-byte files, because of the way Mac OS Extended allocates. That's a ratio of 4.27:1. Your mail store on your Mac will be 4.27 times larger than your mbox file.
That means your mail store on your Mac will be 49,213,167 bytes, or about 47 MB. Even if you double that to account for the property-list metadata embedded with each message, that only comes to 94 MB. Not 105 MB.
So I'm gonna go ahead and say that I don't really buy what you're selling.
Now, setting that aside, your Mac requires considerably more than the 36 MB wasted inside your mail archive just for virtual memory paging. If you're in a situation where 36 MB makes a difference, you're doing something seriously wrong.
How about a real-world example? I have an archive of 22,433 entirely average e-mail messages. On my Panther system disk, that archive occupies 876 MB. On my Tiger system disk, it occupies a grand total of 880 MB. A net loss to me of 4 MB of disk space, for a net gain of all the functionality of Spotlight.
In the real world, e-mail messages are much closer to, or even significantly in excess of, 4 KB than they are in the case you described. And even in the case you described, the net difference is 36 MB, a totally insignificant sum in today's terms.
Completely different, as near as I can tell. Daemontools looks more like watchdog, which launchd obsoletes.
The launchd service is responsible for launching services on demand, be that at boot time, at login time, or upon network connection. It's responsible for automatically detecting dependencies, and for firing off tasks in parallel whenever possible.
The launchd service replaces (hold your breath) init, rc,/etc/rc.d,/etc/init.d, cron, at, SystemStarter and watchdog.
And yes, the configuration files are all property lists.
Slashdot Mirror
I don't think you've wrapped your head around the basic concept here. There are no more scripts. There are XML property list files, one per service.
If I remember right, the cron daemon is included, but it doesn't run by default. I guess you could take the time to configure it, but you'd be way better off just firing off your tasks as LaunchDaemons instead.
In all fairness, it sounds like you're the one who's ignoring the elephant in the room. If it's taking five minutes for your laptop to pass POST, you need to take it in for repair. It's obviously got a hardware problem.
The reason systems DON'T boot when /etc/intttab get's toasted is they SHOULDN'T boot with out the service it kicks off running.
;-)
That's a pretty radical retrograde interpretation of the facts. The reason system don't boot when inittab has an error in it is because init lacks any mechanism for recovering from config-file errors. We fixed that.
When inittab is toasted on one of my AIX servers, I simply boot off of the install CD or a backup tape(yes I can do that). I mount rootvg in maintenance mode, FIX inittab and then reboot. That simple.
So what you're saying here is that you don't like Apple because we're making your job obsolete?
The "get toasted" expression wasn't my choice of words. I was quoting. I would have said, instead, "what happens if, say, you fat-finger inittab while editing it."
The problem with traditional Unix configuration files is that they're not self-validating. A single typographical error can very easily result in an unbootable system. XML-based property lists reduce that possibility. They don't eliminate it entirely, of course; nothing could. But they reduce it.
They also open up the door for us to make the launch system self-repairing. Check out the changes to NSUserDefaults in Tiger to see what I mean there.
We did open-source launchd. It's part of Darwin 8.
What's the difference between damaging /etc/inittab and /sbin/launchd?
Are you kidding? The difference is that launchd is not a script. It's a program. You're not going to be editing it.
At least using "traditional system" you can still boot using init=/bin/bash
Single-user mode, you mean. Command-option-S at system startup. Requires you to have the Open Firmware password, of course, if the machine has one.
What happens if this ONE plist file gets toasted?
Then launchd posts an error in the log, and that service doesn't run. As opposed to what happens if, say, inittab gets toasted, rendering your computer unbootable. Sounds like an improvement to me.
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?
We replaced many small programs that all do the same thing with one small program that all does the same thing. In the process, we eliminated five different cryptic configuration file formats, replacing them with one property list format which has already been in use for five years and consequently is well known.
Is there a way to make Dashboard widgets sticky on the desktop?
You don't want them to. One of the benefits of the Dashboard layer is the fact that when the Dashboard isn't visible, the widgets are completely suspended, consuming no CPU cycles at all. If you put a widget on the screen outside the Dasboard layer --which of course you can do, if you run Dashboard in debug mode --it'll execute its run loop all the time, sucking up CPU cycles unnecessarily.
Is there any reason why a daemon is necessary to improve startup time?
;-)
The launchd service isn't a daemon. It's a replacement for init. And yes, it speeds things up considerably. Previously, every startup script required its own instance of a shell to be fired off. Now that middleman is removed. And it made things considerably faster and simpler.
But why XML over say something like INI or a much simplier format?
Because XML is self-validating, like I said. The contents of the file can be checked for consistency before being used for anything.
It also quickly becomes unreadable.
You don know that we're talking about property lists here, right? It's an XML-based format, but it's not totally free-form XML. You can't just plug in any valid XML and expect launchd to handle it. If the file doesn't validate against the property list schema, launchd will just ignore it.
Besides, we've been using property lists everywhere for five years now. Nobody's complained yet.
I think, to the contrary, we've greatly simplified Mac OS X. When it comes to programs that run without being explicitly started by the user, there used to be six or eight ways to skin the cat, many of which overlapped to a greater or lesser extent. Now there's one.
Actually, 15 seconds sounds really wrong to me.
To keep things simple, we divide the boot process into two halves: the hardware half and the software half. The hardware half involves power-on self-tests, and the time it takes varies wildly from computer type to computer type, or even from configuration to configuration. It takes longer to test 8 GB of RAM than 512 MB of RAM.
The software half begins with the grey Apple-logo screen turns blue and the progress window appears.
From the time that happens to the time the menu bar appears (via autologin) should be four seconds on a stock Mac OS X install with middle-of-the-road hardware (dual 1 GHz G4).
Because XML configuration files are self-validating.
The fundamental problem launchd was created to solve is system startup time. Twenty or thirty seconds to boot a freakin' laptop is just absurd. So we used launchd to get that down to four.
But beyond that, launchd also takes care of the problem of having six different types of configuration files, none of which are self-documenting or self-validating. A launchd configuration file can be validated and, if invalid (like somebody inserted a typographical error, or the file got truncated or something), discarded without interfering with system startup. That makes the system more resilient.
The launchd service replaces (takes a deep breath) init, rc, the init.d and rc.d scripts, SystemStarter, inetd and xinetd, atd, crond, and watchdog.
Basically any task the needs to run on its own, rather than being manually started by a human being, can be handled by launchd.
Oh. Duh. Of course you're right. I'm stupid.
However, when one writes in a particular language, it's customary to spell words in that language. We're speaking English here; it's "Iraq" and not "Irak."
You've been swallowing too much of the Bushie propaganda. Yes, many of the Iraqi troops fell back, but they didn't just give up and go home. They gave up, went home, and became those "foreign fighters" Bushie and Rummy lie to us about.
You don't fight a superior force one-on-one. Even the poor, brown Iraqis know that.
Do your Canadian schools not teach that it's "Iraq" and not "Irak?"
The problem with that idea is that the foreign-fighters idea is a myth concocted by Bushie to distract people from the fact that the Iraqis fought us every step of the way like, well, like a people under occupation by a foreign power.
The people fighting in Iraq NOW are terrorists. They're all car-bombs and beheadings. But the people who were fighting in Iraq up until the end of last year were just average Iraqis like you and me who wanted nothing more than to not be illegally occupied by an imperial power looking to spread its particularly virulent brand of corporatism to their country.
Plus, you know, your idea is inhuman and barbaric. That's a big minus, too.
In other other words, because this information has leaked, the lives of the people, both Coalition and Iraqi, who man highway checkpoints in Iraq have been put in even greater danger.
I know that it's become fashionable to get all conspiratorial and stuff, to think that everything is a cover-up. Hell, I believe that myself most of the time. But sometimes the government classifies things out of a completely legitimate desire to protect people.
I'm about as "fuck the status quo, change the dominant paradigm" as you can get. I think what the US did in Iraq was totally illegal, and that Bushie and his gang of international thugs should be treated just like we treated the Nazis after WWII: a perfunctory trial, then hangings all around. If I had to choose between having Bushie in the White House and Saddam Hussein in the White House, I'd pick Saddam without even thinking twice.
But I'm not enough of an idiot to think that just because some things the government does are corrupt and illegal that everything they do must be corrupt and illegal. Sometimes things are secret for good reason.
Helping terrorists -- real terrorists, this time, not just people who don't happen to subscribe to the corporatist ideal -- kill innocent people isn't going to get us out of Iraq any faster. The best way to get us out of Iraq is to pretend to support the democracy movement, then sit back and cheer when, after the last American solder gets on the boat, the Iraqis reelect themselves a nice, enlightened, Socialist regime and gives corporatism the middle finger. That's how we win.
Unless that's a real new policy, that's not true. Our stores honor educational discounts if you can give them a photo ID.
"You applers?" Horrifying crimes against the English language aside, I'm not really sure I'm buying what you're selling here. In order for that to be true, the average size of each mail message would have to be less than 430 bytes. I don't think that's true.
Here's how it works. The Mac OS Extended filesystem has a minimum allocation block size of four kilobytes. A one-byte file on disk will be given a minimum allocation of four kilobytes. Okay?
Let's say your "mbox" file contains exactly 12,000 messages, and that it totals exactly 11,534,336 bytes. That means each message is an average of about 960 bytes long.
On your Mac, those 960 byte files will be inflated to 4,096-byte files, because of the way Mac OS Extended allocates. That's a ratio of 4.27:1. Your mail store on your Mac will be 4.27 times larger than your mbox file.
That means your mail store on your Mac will be 49,213,167 bytes, or about 47 MB. Even if you double that to account for the property-list metadata embedded with each message, that only comes to 94 MB. Not 105 MB.
So I'm gonna go ahead and say that I don't really buy what you're selling.
Now, setting that aside, your Mac requires considerably more than the 36 MB wasted inside your mail archive just for virtual memory paging. If you're in a situation where 36 MB makes a difference, you're doing something seriously wrong.
How about a real-world example? I have an archive of 22,433 entirely average e-mail messages. On my Panther system disk, that archive occupies 876 MB. On my Tiger system disk, it occupies a grand total of 880 MB. A net loss to me of 4 MB of disk space, for a net gain of all the functionality of Spotlight.
In the real world, e-mail messages are much closer to, or even significantly in excess of, 4 KB than they are in the case you described. And even in the case you described, the net difference is 36 MB, a totally insignificant sum in today's terms.
Completely different, as near as I can tell. Daemontools looks more like watchdog, which launchd obsoletes.
/etc/rc.d, /etc/init.d, cron, at, SystemStarter and watchdog.
The launchd service is responsible for launching services on demand, be that at boot time, at login time, or upon network connection. It's responsible for automatically detecting dependencies, and for firing off tasks in parallel whenever possible.
The launchd service replaces (hold your breath) init, rc,
And yes, the configuration files are all property lists.
Extended attributes are required to implement POSIX ACLs.