Funny you should say that on today of all days. I spent a big chunk of the afternoon finalizing some of the documentation for launchd.
The traditional UNIX startup model calls for a lot of tasks to be fired off at boot time, one after the other. Whether you use init scripts or rc scripts or whatever, the model is the same.
In Panther, we created a fairly sophisticated system for firing off these tasks in parallel instead of serially. The net result was a decrease in cold-start times of about 100%.
Now we've got launchd. The idea now is that instead of making the user wait for a bunch of services to start, we let launchd fire them both in parallel and asynchronously.
I don't want to get extremely specific here for reasons I hope are obvious, but on modern (i.e., dual-G5) hardware, the time from the end of power-on tests and the initialization of Open Firmware to the menu bar and dock appearing and the system accepting user input is as little as four seconds.
Four seconds to cold-boot the operating system.
Pretty impressive, no? All it takes is a willingness to look at the traditional way of doing things, recognize massive stupidity, and correct it.
There has never not been a dual-processor Power Mac G5. The first generation of G5s we shipped included a single 1.6 GHz, single 1.8 GHz and dual 2.0 GHz.
In point of fact, a dual-processor machine is always going to be faster than a single-processor dual-core machine, all other things being equal. You've got twice the cache and twice the bandwidth from CPU to memory on a dual-processor system.
Why do you call it a "claim?" I didn't claim anything. I simply stated the facts.
If you don't like them, you're free to ignore me. But I don't understand all this talk of "claims."
Re:I'd be willing to wait until 2007...
on
Longhorn Preview
·
· Score: 2, Informative
Oh, it's far worse than that. Microsoft's #1 selling point for Longhorn is security. "Buy this product because it's more secure than the product we sold you last year." They've been doing that for a while now. They're getting good at it. Ship a product that's known to be flawed, then charge for a product that's known to be flawed slightly less, and advertise it as a big improvement.
Microsoft ought to change their slogan to "We're doing the best we can." Nobody would believe them, but it would at least be slightly closer to the truth.
Reconnaissance satellites are steerable. They can be tasked as little as an hour in advance to be over a specific point at a specific time. And yes, they can transmit high-resolution images to ground stations in real time.
We support Automator actions in AppleScript and Objective-C. We don't offer an entry point for either C or C++, and I can't imagine that we will. Automator depends heavily on the dynamic features of the Objective-C runtime, features that you just can't implement in any other language.
Actions can do anything at all. If you wanted to create an action that does one of two possible things based on whether the input is X or Y, that's your call. But you need to think of Automator workflows like command lines, not like complex programs with branching execution. That's not the idea.
Well... not really. The purpose of the OS is to deliver services to the user to enable him to do what he wants to do. Providing services to developers is really just a means to that end, you know?
The very best example of this is Spotlight. Spotlight is wide open. Anybody who wants to can create an importer (it's just one C function!) and anybody who wants to can run queries from any program. But we're not sitting here waiting for third parties to come aboard. Even if zero third parties touch Spotlight, it's still a killer feature because of the way we've built it right into the desktop and the open/save dialogs and the command line and elsewhere.
Just opening up services to developers and expecting them to lay the last mile to the user is a going-out-of-business plan.
Not at release. Scuttlebutt around the water cooler is that Adobe will be shipping importers for all their formats with CS2, but that's just a rumor right now. Don't hold me to it.
Spotlight comes in two parts, basically. There's the metadata index and the content index. The content index is essentially Search Kit on steroids; it's seriously like twenty times faster now. So we index both metadata and content on every file close operation (for supported file types; the number of supported types will rise as third parties release their own importers).
Automator is really just a nice UI for AppleScript
No, it's not. I'm not sure where this rumor got started. Maybe somebody misunderstood it during the demo.
Automator is the modern equivalent of the venerable UNIX command line. You know what makes the command line cool? Pipelines and loops. You can route the output from one command-line tool to the input of another and create pipelines, and you can loop those pipelines over input. You can type, for example,
for i in *.jpg; do sips "$i" --resampleHeightWidthMax 300 --setProperty format tiff done
(The sips command is the Mac's command-line image processing utility. Other platforms have their equivalents.)
What Automator does it it lets you create the equivalent of UNIX command lines without having to learn a command-line language and without being locked into just what the command-line gives you. In place of UNIX tools like "find" and "sips," you use Automator actions. Instead of building command lines, you build workflows.
For instance, to implement the same basic operation as an Automator workflow, I'd start by dragging the "Get Selected Finder Items" action to the workflow pane, then follow it with a "Scale Images" action, then a "Change Type of Images" action.
Then I can save my workflow as a Finder plug-in, which means it's available from the Action menu in any Finder window. I can select any file (or group of files), choose the workflow from the Automator sub-menu of the Action menu, and off we go.
That's a ridiculously simple example, sure, but in a work environment it can be amazingly useful. For example, say your job is to post news stories and accompanying photographs on the Web. Each photograph has to be scaled and converted from CMYK to RGB, applying the correct ColorSync profile in the process and embedding IPTC copyright metadata. You could do that today with a program like Photoshop using scripting, or you can do it with Automator in much less time and with a much higher degree of desktop integration. Just click an image and run the "Make ready for Web" workflow. Easy.
Automator actions can be either compiled AppleScripts or Objective-C code fragments (strongly recommended). Into any workflow you can insert a "Run AppleScript" action if you absolutely have to call AppleScript; you can even insert a "Run Shell Script" action if you absolutely have to call a shell script. But the actions themselves are little tiny code fragments written in Objective-C that implement runWithInput:fromAction:error.
Think of a UNIX command-line tool that accepts standard input and sends standard output and standard error and you'll have the idea. An Automator action is basically a command-line tool without the nasty command-line interface.
Will most people use Automator? Frankly, probably not. But most people don't create command-line pipelines and scripts either, even the ones who know how. But for those who want to, Automator is there.
Frankly, I never thought I would like it. It just didn't interest me. But then one day I had to do a tedious repetitive task, and ever since I've been a big-time Automator junkie.
Actually, I'm pretty sure we screwed the pooch irrevocably when we went with a BSD user-space environment instead of adopting Linux back in 1997. Having a robust, stable environment that we don't have to sell our souls to the devil in order to distribute commercially was a real cock-up. Apparently.
No, that's what his own lawyer says as well. Ciarelli's position since the beginning has been that YES, he did indeed break the law, but that he should be exempt because California has a (stupidly misguided) "shield law" that gives certain special classes of people certain protections.
I was actually kinda hoping that this case would inspire either the court or the legislature to get rid of that absurdly unconstitutional law, but it doesn't look like that will happen. Instead, the judge just declared that whether the "shield law" is constitutional or not, Ciarelli isn't protected by it.
Three totally non-binding committments to buy a product with imaginary specifications at an impossible price point from anonymous Internet users? Let me get marketing on the phone immediately!
Have you not been following the case? Ciarelli actively solicits Apple employees to break their confidentiality agreements by offering them a promise of anonymity. He then publishes the information they leak to him.
He's breaking the law six ways from Sunday. This has never been in dispute.
Slashdot Mirror
Funny you should say that on today of all days. I spent a big chunk of the afternoon finalizing some of the documentation for launchd.
The traditional UNIX startup model calls for a lot of tasks to be fired off at boot time, one after the other. Whether you use init scripts or rc scripts or whatever, the model is the same.
In Panther, we created a fairly sophisticated system for firing off these tasks in parallel instead of serially. The net result was a decrease in cold-start times of about 100%.
Now we've got launchd. The idea now is that instead of making the user wait for a bunch of services to start, we let launchd fire them both in parallel and asynchronously.
I don't want to get extremely specific here for reasons I hope are obvious, but on modern (i.e., dual-G5) hardware, the time from the end of power-on tests and the initialization of Open Firmware to the menu bar and dock appearing and the system accepting user input is as little as four seconds.
Four seconds to cold-boot the operating system.
Pretty impressive, no? All it takes is a willingness to look at the traditional way of doing things, recognize massive stupidity, and correct it.
There has never not been a dual-processor Power Mac G5. The first generation of G5s we shipped included a single 1.6 GHz, single 1.8 GHz and dual 2.0 GHz.
In point of fact, a dual-processor machine is always going to be faster than a single-processor dual-core machine, all other things being equal. You've got twice the cache and twice the bandwidth from CPU to memory on a dual-processor system.
Are you just being an asshole for fun? I think you understood my comment perfectly well and you're just trying to get a rise out of me.
Pass.
How can a satellite steer its orbit and arrive at a certain point over the earth within an hour?
... which is why we have more than one. See?
Obviously a satellite can't
How many times can it do this before it runs out of fuel?
Well, considering it's done wth gyroscopes powered by solar cells, indefinitely.
Are thinks becoming clear to you now? Or are you still all confuzzled?
Why do you call it a "claim?" I didn't claim anything. I simply stated the facts.
If you don't like them, you're free to ignore me. But I don't understand all this talk of "claims."
Oh, it's far worse than that. Microsoft's #1 selling point for Longhorn is security. "Buy this product because it's more secure than the product we sold you last year." They've been doing that for a while now. They're getting good at it. Ship a product that's known to be flawed, then charge for a product that's known to be flawed slightly less, and advertise it as a big improvement.
Microsoft ought to change their slogan to "We're doing the best we can." Nobody would believe them, but it would at least be slightly closer to the truth.
I don't think you get the idea. Actions are components that are used to build workflows with Automator.
USS Intrepid with an SR-71 on the deck:
9 1&spn=0.008411,0.006824&t=k&hl=en
http://maps.google.com/maps?ll=40.764213,-74.0008
The runway at Edwards is considerably longer. It's 7-1/2 miles from end to end.
And for the record, Groom Lake was publicly acknowledged years ago. No mystery there. It's just an Air Force base.
Reconnaissance satellites are steerable. They can be tasked as little as an hour in advance to be over a specific point at a specific time. And yes, they can transmit high-resolution images to ground stations in real time.
We support Automator actions in AppleScript and Objective-C. We don't offer an entry point for either C or C++, and I can't imagine that we will. Automator depends heavily on the dynamic features of the Objective-C runtime, features that you just can't implement in any other language.
Actions can do anything at all. If you wanted to create an action that does one of two possible things based on whether the input is X or Y, that's your call. But you need to think of Automator workflows like command lines, not like complex programs with branching execution. That's not the idea.
Well ... not really. The purpose of the OS is to deliver services to the user to enable him to do what he wants to do. Providing services to developers is really just a means to that end, you know?
The very best example of this is Spotlight. Spotlight is wide open. Anybody who wants to can create an importer (it's just one C function!) and anybody who wants to can run queries from any program. But we're not sitting here waiting for third parties to come aboard. Even if zero third parties touch Spotlight, it's still a killer feature because of the way we've built it right into the desktop and the open/save dialogs and the command line and elsewhere.
Just opening up services to developers and expecting them to lay the last mile to the user is a going-out-of-business plan.
Not at release. Scuttlebutt around the water cooler is that Adobe will be shipping importers for all their formats with CS2, but that's just a rumor right now. Don't hold me to it.
The V-Twin content index is only half of Spotlight. The other half is the metadata index.
For the record, Spotlight's image importer extracts both IPTC and EXIF metadata. IPTC metadata is used to populate the following Spotlight attributes:
kMDItemHeadline, kMDItemTitle, kMDItemDescription, kMDItemAuthors, kMDItemKeywords, kMDItemInstructions, kMDItemCopyright, kMDItemCity, kMDItemStateOrProvince, kMDItemCountry
We also pull EXIF metadata to populate these items:
kMDItemExposureTimeSeconds, kMDItemFlashOnOff, kMDItemFocalLength, kMDItemAcquisitionMake, kMDItemAcquisitionModel, kMDItemRedEyeOnOff
And so on.
Spotlight comes in two parts, basically. There's the metadata index and the content index. The content index is essentially Search Kit on steroids; it's seriously like twenty times faster now. So we index both metadata and content on every file close operation (for supported file types; the number of supported types will rise as third parties release their own importers).
No, it's not. I'm not sure where this rumor got started. Maybe somebody misunderstood it during the demo.
Automator is the modern equivalent of the venerable UNIX command line. You know what makes the command line cool? Pipelines and loops. You can route the output from one command-line tool to the input of another and create pipelines, and you can loop those pipelines over input. You can type, for example,(The sips command is the Mac's command-line image processing utility. Other platforms have their equivalents.)
What Automator does it it lets you create the equivalent of UNIX command lines without having to learn a command-line language and without being locked into just what the command-line gives you. In place of UNIX tools like "find" and "sips," you use Automator actions. Instead of building command lines, you build workflows.
For instance, to implement the same basic operation as an Automator workflow, I'd start by dragging the "Get Selected Finder Items" action to the workflow pane, then follow it with a "Scale Images" action, then a "Change Type of Images" action.
Then I can save my workflow as a Finder plug-in, which means it's available from the Action menu in any Finder window. I can select any file (or group of files), choose the workflow from the Automator sub-menu of the Action menu, and off we go.
That's a ridiculously simple example, sure, but in a work environment it can be amazingly useful. For example, say your job is to post news stories and accompanying photographs on the Web. Each photograph has to be scaled and converted from CMYK to RGB, applying the correct ColorSync profile in the process and embedding IPTC copyright metadata. You could do that today with a program like Photoshop using scripting, or you can do it with Automator in much less time and with a much higher degree of desktop integration. Just click an image and run the "Make ready for Web" workflow. Easy.
Automator actions can be either compiled AppleScripts or Objective-C code fragments (strongly recommended). Into any workflow you can insert a "Run AppleScript" action if you absolutely have to call AppleScript; you can even insert a "Run Shell Script" action if you absolutely have to call a shell script. But the actions themselves are little tiny code fragments written in Objective-C that implement runWithInput:fromAction:error.
Think of a UNIX command-line tool that accepts standard input and sends standard output and standard error and you'll have the idea. An Automator action is basically a command-line tool without the nasty command-line interface.
Will most people use Automator? Frankly, probably not. But most people don't create command-line pipelines and scripts either, even the ones who know how. But for those who want to, Automator is there.
Frankly, I never thought I would like it. It just didn't interest me. But then one day I had to do a tedious repetitive task, and ever since I've been a big-time Automator junkie.
Fundamentally an OS is the interface between programs and hardware.
Not for decades. Fundamentally an OS is the interface between the programs and their data and the user.
Heh. No offense, but I'm pretty sure I'm right about this one. Delphi 151 is less than half water.
Actually, I'm pretty sure we screwed the pooch irrevocably when we went with a BSD user-space environment instead of adopting Linux back in 1997. Having a robust, stable environment that we don't have to sell our souls to the devil in order to distribute commercially was a real cock-up. Apparently.
No, that's what his own lawyer says as well. Ciarelli's position since the beginning has been that YES, he did indeed break the law, but that he should be exempt because California has a (stupidly misguided) "shield law" that gives certain special classes of people certain protections.
I was actually kinda hoping that this case would inspire either the court or the legislature to get rid of that absurdly unconstitutional law, but it doesn't look like that will happen. Instead, the judge just declared that whether the "shield law" is constitutional or not, Ciarelli isn't protected by it.
So the facts of the case are not in dispute.
Three totally non-binding committments to buy a product with imaginary specifications at an impossible price point from anonymous Internet users? Let me get marketing on the phone immediately!
How well does it run Photoshop and iMovie?
(D'oh.)
Have you not been following the case? Ciarelli actively solicits Apple employees to break their confidentiality agreements by offering them a promise of anonymity. He then publishes the information they leak to him.
He's breaking the law six ways from Sunday. This has never been in dispute.