CoreImage can also look at what you're doing, and sometimes decide that two filters can be applied simultaneously, instead of applying the first to the whole image, then the second to the whole image.
That should be faster, because the pixels of the image will only have to be read, processed, and written once, instead of twice.
This kind of on-the-fly optimization will apply even on G3s without altivec or new graphics cards.
I expect this depends a great deal on the specific filters involved.
The only thing that worried me is that each instance of a widget in Dashboard took 5-10MB of real memory and about 100MB of virtual memory. Any real Mac guru's know what the hell that is about?
I believe all the 100MBs are the exact same 100MBs, shared among the various widgets.
Dashboard uses the WebKit, which means that each widget would have the whole Cocoa framework loaded in, and then some.
But OS X only maps in Cocoa and the rest once. It isn't duplicated in memory for every Cocoa app and Dashboard widget.
Even if Gates wants to hire the best people, at high salaries, it's damn sure that thousands of other companies will be bringing in the cheapest warm bodies they can find.
I don't think the government is capable of evaluating each H1B hire and his or her salary, and the availability of similar US workers. Nor is it desirable to try to get the government to do so.
So the only solution is to keep a cap on hiring.
I think the solution is to auction the existing H1B visas to companies. Companies who want cheap H1B workers will not be willing to bid high for visas, because that'd defeat the purpose. Companies who want foreign workers and intend to pay them high wages - ie, the companies who are truly interested in hiring the world's best - will be willing to make high bids for visas.
So if Microsoft really wants to hire the world's best, they can place high bids on a large block of H1B visas.
The revenue generated this way could then be pissed away by the Bush administration and the GOP-led congress.
No, the idea is that, on a given Mac, performance improves over consecutive versions of OS X.
So when you upgrade from 10.1 to 10.2, you find that your computer runs faster under 10.2 than it did under 10.1.
Likewise from 10.2 to 10.3, performance improves.
In all cases, the comparison is not between older Macs and newer Macs. The comparison is between a given Mac's performance under older and newer versions of OS X.
The expected behavior is for each version to be slower, because of added cruft. Instead, Apple's been tuning and optimizing, so each version has, for the most part, offered some performance benefit.
(Personally, I thought 10.3 made my 500MHz iBook run a bit slower.)
There's a big difference. The ActiveX popup makes it a pain in the ass to surf the web, because the popup will keep coming up whenever a page uses ActiveX.
People aren't going to come across widgets in the same way.
They're going to have to intentionally download them. There won't be surreptitious widgets stuffed into the various websites they visit in the course of a day. If a site offers a widget, it won't be automatically downloaded when you visit the site.
"There are millions of lines of source code in any modern operating system. Exploits don't sprout overnight like mana from heaven. The most useful skill for divining exploits is to notice the existence of edge cases in how various subsystems interact with one another."
Indeed. I think the problem is not that nobody was looking for flaws, but that they were looking in the parts they're familiar with. They'd be looking in the BSD-oriented parts, or the upper levels of the OS.
They probably wouldn't be looking in the Mach parts of the OS, where this bug appears. I doubt many people have spent the time to learn enough about Mach to think of potential exploits.
If it was perfectly ordinary, it would have been discovered long ago.
If it's gone 10 years without being discovered, if Bank of America's NeXTSTEP trading systems never broke because of it in all the years they've been in use, then it's not a significant bug.
iTunes is most likely written in Objective-C against the OpenStep framework, with Quicktime for an audio layer, and Aqua nib files for interface specification and invocation.
No, it's a Carbon app, presumably written in C/C++.
They're the same device on each machine, with the same function. The only problem has been that the data received has been interpreted with the wrong calibration adjustments. Swap the calibration adjustments and rerun the data, and it'll be correct.
It would have been far worse if, say, one had a spectroscope and the other had a *drill*, and they were swapped, and each rover couldn't use the other's tool. And in that kind of a switch, it would be really bad, because the two devices would be visually distinct. But the swapping of two devices that are 99.99% identical, on two rovers that are identical, is no big thing.
Compared to the fact that the rovers are still running long after they were expected to die, this is a tiny, tiny thing.
Does anyone get the impression that there is some subtle but real competition going on between Sun and Apple? Apple seems to be moving in on the server/blade market, and Sun is attempting to do cool GUI tricks.
If this is all Sun's got, then I'd say this is a great opportunity to short their stock.
CGDisplayCapture grabs a screen, and puts a "shielding window" on it, in front of everything else.
You can get the windowLevel of that shielding window. Once you have that, you can create a regular window that is above the shielding window (ie, with a higher windowLevel) and thus visible. Or, you can take an existing window, and set its window level.
Slashdot Mirror
I had two emails from Apple this morning, about 8 am.
The first was a shipping notification.
The second (the very next email) was the apology which you received.
Tiger arrived by FedEx by 11 am this morning.
CoreImage can also look at what you're doing, and sometimes decide that two filters can be applied simultaneously, instead of applying the first to the whole image, then the second to the whole image.
That should be faster, because the pixels of the image will only have to be read, processed, and written once, instead of twice.
This kind of on-the-fly optimization will apply even on G3s without altivec or new graphics cards.
I expect this depends a great deal on the specific filters involved.
The only thing that worried me is that each instance of a widget in Dashboard took 5-10MB of real memory and about 100MB of virtual memory. Any real Mac guru's know what the hell that is about?
I believe all the 100MBs are the exact same 100MBs, shared among the various widgets.
Dashboard uses the WebKit, which means that each widget would have the whole Cocoa framework loaded in, and then some.
But OS X only maps in Cocoa and the rest once. It isn't duplicated in memory for every Cocoa app and Dashboard widget.
Even if Gates wants to hire the best people, at high salaries, it's damn sure that thousands of other companies will be bringing in the cheapest warm bodies they can find.
I don't think the government is capable of evaluating each H1B hire and his or her salary, and the availability of similar US workers. Nor is it desirable to try to get the government to do so.
So the only solution is to keep a cap on hiring.
I think the solution is to auction the existing H1B visas to companies. Companies who want cheap H1B workers will not be willing to bid high for visas, because that'd defeat the purpose. Companies who want foreign workers and intend to pay them high wages - ie, the companies who are truly interested in hiring the world's best - will be willing to make high bids for visas.
So if Microsoft really wants to hire the world's best, they can place high bids on a large block of H1B visas.
The revenue generated this way could then be pissed away by the Bush administration and the GOP-led congress.
I'm sure there's some outfit in Audiophile magazine that will sell you "quantum wire".
I hear it gives you really crisp trebles.
"Be is long gone, so MS has pretty much eliminated their possible saviors."
Maybe Paul Allen needs to come back.
Classic runs my old Mac Infocom games, with no problems.
(Though I prefer running them with a modern zip environment. The old programs insist on a 512x342 window, which is tiny on my 1600x1024 screen.)
That'd work great until your BSOD gets a BSOD.
One way to free up the second core would simply be to run the antivirus on the GPU!
Slap in a second video card, and run anti-spyware on its GPU.
Then, you'd have both cores available for gaming, and you'd get maximum frame rates when playing Zork or Planetfall.
Seems like they should implement it as an OS X input manager.
While simple HTML & CSS widgets work in Safari, I don't think Cocoa-plugin widgets will.
If I'm not mistaken, the more complex widgets require something that is in Dashboard, but is not in Safari or WebKit in general.
No, the idea is that, on a given Mac, performance improves over consecutive versions of OS X.
So when you upgrade from 10.1 to 10.2, you find that your computer runs faster under 10.2 than it did under 10.1.
Likewise from 10.2 to 10.3, performance improves.
In all cases, the comparison is not between older Macs and newer Macs. The comparison is between a given Mac's performance under older and newer versions of OS X.
The expected behavior is for each version to be slower, because of added cruft. Instead, Apple's been tuning and optimizing, so each version has, for the most part, offered some performance benefit.
(Personally, I thought 10.3 made my 500MHz iBook run a bit slower.)
There's a big difference. The ActiveX popup makes it a pain in the ass to surf the web, because the popup will keep coming up whenever a page uses ActiveX.
People aren't going to come across widgets in the same way.
They're going to have to intentionally download them. There won't be surreptitious widgets stuffed into the various websites they visit in the course of a day. If a site offers a widget, it won't be automatically downloaded when you visit the site.
"There are millions of lines of source code in any modern operating system. Exploits don't sprout overnight like mana from heaven. The most useful skill for divining exploits is to notice the existence of edge cases in how various subsystems interact with one another."
Indeed. I think the problem is not that nobody was looking for flaws, but that they were looking in the parts they're familiar with. They'd be looking in the BSD-oriented parts, or the upper levels of the OS.
They probably wouldn't be looking in the Mach parts of the OS, where this bug appears. I doubt many people have spent the time to learn enough about Mach to think of potential exploits.
If it was perfectly ordinary, it would have been discovered long ago.
If it's gone 10 years without being discovered, if Bank of America's NeXTSTEP trading systems never broke because of it in all the years they've been in use, then it's not a significant bug.
"How is a kernel panic not serious? "
If you never, ever encounter it, it's not serious.
You could probably cause a kernel panic by driving an iron spike through the boot drive during some critical OS-level operation.
But it'd be daft to write iron-spike-handling code, to prevent a kernel panic in that rare situation.
IPSS: IP via Smoke Signals.
iTunes is most likely written in Objective-C against the OpenStep framework, with Quicktime for an audio layer, and Aqua nib files for interface specification and invocation.
No, it's a Carbon app, presumably written in C/C++.
Cocoa isn't available on Windows, after all.
"You don't really expect people to burn their songs to CD every time they want to use them outside iSomething"
Um, if you don't have anything that plays MP3s, you pretty much have to burn your songs to CD in order to use them outside your computer.
Even if you aren't using iTunes.
They're the same device on each machine, with the same function. The only problem has been that the data received has been interpreted with the wrong calibration adjustments. Swap the calibration adjustments and rerun the data, and it'll be correct.
It would have been far worse if, say, one had a spectroscope and the other had a *drill*, and they were swapped, and each rover couldn't use the other's tool. And in that kind of a switch, it would be really bad, because the two devices would be visually distinct. But the swapping of two devices that are 99.99% identical, on two rovers that are identical, is no big thing.
Compared to the fact that the rovers are still running long after they were expected to die, this is a tiny, tiny thing.
Does anyone get the impression that there is some subtle but real competition going on between Sun and Apple? Apple seems to be moving in on the server/blade market, and Sun is attempting to do cool GUI tricks.
If this is all Sun's got, then I'd say this is a great opportunity to short their stock.
No, not rotating in 3D. Rotating in 2D.
The point is that the top of the window will always be up, relative to the earth, regardless of what orientation the laptop is in.
The window behaves like a compass needle, only relative to real-up and real-down, instead of north and south.
designed merely to inspire Intel's partners
means Intel was asking it's partners
What the hell is wrong with you people? Why do you insist on producing cheap-looking ugly shite?
Nah, you can do it with a regular Cocoa app.
CGDisplayCapture grabs a screen, and puts a "shielding window" on it, in front of everything else.
You can get the windowLevel of that shielding window. Once you have that, you can create a regular window that is above the shielding window (ie, with a higher windowLevel) and thus visible. Or, you can take an existing window, and set its window level.
There's a simple Cocoa example, at CocoaDevCentral.
Fat Binaries don't solve the QA and Marketing problems. How many major commercial apps shipped on all 4 OpenStep platforms? 1 or 2?
I believe all of Lighthouse Design's apps shipped on all 4.