ADA has nothing to do with software vendor accessibility.
It's about a person's disability(/ies).
Even if you could argue that Safari, FireFox, Opera and what-have-you would be disabled-persons tools, you can't argue against the fact that IE is Section-K compliant (aka, ADA part specific to computer software).
This is purely about incompetence of web site developers.
And MicroSoft being responsible for the levee breakage I suppose (har har).
I think it was always pretty clear that MonkeyBoy is totally a deranged maniac. And I mean this in the most flattering way I can given he's probably worse than what his public figure make him out to be.
This is serious stuff. He basically made a death threat to the Google CEO.
Balmer sometimes acts like a cocaine addict. Snappy, choleric, over-hyped ("developers developers developers!").
He's certainly not a role model of mine.
Gates might have been an evil corporate henchman, but at least he didn't have this deranged personality.
There's no "native PowerPC" or "Native Intel" binary formats. It's all just binary data dumped into a file. How this file is organized means only something to the operating system loading it. Not the CPU. The CPU doesn't care where the data segments is. It doesn't care where the content lies within the file. It's not going to load it and parse the damn file itself.
All it cares is the in-memory address or what's to execute.
PEF (long deprecated) and CFM were formats devised for use the the classic Mac OS system. It's nothing to do with any specific CPU requirements. It's simply a standard way to package your binaries so the OS knows what to do with them and how to access them.
The truth of the matter is, any CFM app runs slower in Mac OS X. Not much slower. Perhaps not noticeably slower. But any system or Mach-O library call will end up requiring two jumps to get to it so either way you look at it, CFM apps WILL be slower than Mach-O. but again, it's got nothing to do with the CPU. It's the managing OS underneath and how everything else is linked as.
As far as GCC's PPC code generation, same goes for Intel. If you want faster generated code, you go either CodeWarrior or IBM's XL for PPC, or go with Intel compiler (icc?) for Intel hardware.
It's got nothing to do with the binary format. Other than not having to doubly-inderect system calls if you're linked as CFM.
The binary format of Carbon application is either CFM or Mach-O.
CFM was the binary format of Mac OS "classic".
Mach-O is the native binary format of Mac OS X.
When the OS loads a CFM application, it does so through a "LaunchCFMApp" process instance wich loads the CFM binary and links up in one huge vector table all the system calls being made to Mach-O libraries (including Core Foundation & Carbon).
A CFM application is therefore double-inderected for all system calls.
Mach-O Carbon applications though are not all that common. Anything that still supports Mac OS Classic will be in CFM. There's not that much advantages at moving your CFM application to Mach-O unless it's to remove the tiny (and I mean tiny) burden of dealing with cross-format boundaries. There's not a performance penalty worth mentioning at being CFM, unless you're dealing with quick load time.
Cocoa applications are invariably in Mach-O format. So are, too, any unix tools underneath.
Off-topic:
Given that all of Apple's tools (and binaries for that matter) are Mach-O, it's easier to debug a Mach-O binary, unless you stick with CodeWorrior (did I misspelled that? Oops!).
Apple did say the transition would take a couple of years.
It's obvious that after the Intel bomb shell they dropped that they now need to secure supplies of current processors until the entire line has moved onto Intel.
This is common sense. (But you don't have to expect this from news sites that report, even, that Apple might be back-tracking on the Intel switch.)
I still preferred it to Windows because of the UI, but I'm very pleased that with OS X I no longer have to make that tradeoff. As seen in an earlier response of mine, I fully agree with this.
But Mac OS in itself was not buggy. it behaved pretty well and probably had fewer bugs than any OS might have today (that's a given due to it's size really, but nonetheless true--the OS itself had very few flaws).
In itself, mac OS was also very stable. Most commercial applications also were very stable. Even sharewares. But Mac OS' vulnerability to other process' failures was due to it's ancient (20 years!) design. Not because it was unstable. Apple recognized that fact too and tried many times to make it evolve (Pink/Taligent, Copland) but failed. In a way, I'm glad they failed because I'm sure we're better off with OpenStep^H^H^H^H Mac OS X than whatever they could have come up with on their own.
The Multi-processing API (thanks for bringing it up) came much later than those I mentioned in my original reply. I've not used that one myself wich is probably why I omitted it in the first place (I was looking for "MPTask" something but I couldn't find it in my head).
I still glad we have OS X anyhow. But I dont like people dissing the older brother because he wasn't as brilliant. He was a fun buddy.
This may be because I keep all my old Macs around.
Miss-behaving applications could bog down other applications because Mac OS used "cooperating" multi-tasking. An application, through it's normal course of operation, would relinquish CPU time through it's event loop(s).
It's a transparent process done simply by polling the system for your next user, system or idle event (aka, "WaitNextEvent()"). This is where Mac OS' multi-tasking defers from preemption modern OSes offer (Linux, Unices including OS X and Windows). In those OSes, the kernel is the one that decides when to switch out the CPU's attention.
Any application not relinquishing CPU time when it didn't need it was immediately considered poorly-programmed and seldomly used.
A developer's poor aptitude was no excuse for the Mac OS locking up. It offered everything you needed to make things to smoothly. It just required a bit more thinking.
Dont get me wrong. I prefer OS X to what we had back then (I've been developing, professionally, Mac applications since 1988 so I know what we had back "then"). But It's important not to skew the facts.
It didn't have (full) memory protection but this somehow made Mac apps more stable in the first place. When developers get called because their app takes down the whole system, they dont make the same mistake twice.
OpenGL support in Windows predates OS X as far as I know. So this decision was a good one for MS.
But now, MS might be seeing Open GL as a double-edged sword. Like any standard it doesn't control, MS now want to lock their incredible user/developer base to their own system by forcing a migration to things they do control.
OpenGL/DirectX isn't the only example of that. Java/C# and the PDF -like thing they're doing (forgot the name) come to mind.
Now that OpenGL is good on Mac OS X, it's time for MS to move away from OpenGL. And some developers are following on this. Look at video card makers. Some already provide DirectX acceleration chips on them.
Problem is that MicroSoft is doing everything it can to move developers off OpenGL and into DirectX. In Vista, OpenGL is actually impaired and emulated from DirectX.
So performance-inclined developers will be tempted to develop for DirectX wich isn't available (or wanted) on Mac OS X.
It's just another MS move in attempt to lock-out gaming from Mac OS X.
And even if the power plant pollutes just as much as a car engine for a given amount of energy, there's another advantage -- the polution is generally produced away from the city, which helps keep the polution around the people who actually use the cars down.
A far worse problem not even looked at by bi-energy car buyers is the actual pollution generated by hybrid cars.
Them batteries are a heck of a problem to manufacture and dispose of. Altogether, hybrid cars may pollute less via their exhaust, but solid hard numbers of their real pollution output have not yet been studied.
Hold-click is still there. Case to point:the Dock. Hold-click and you get the contextual menu. Though, use of that IS marginal in Mac OS X as you imply.
So is drag-hold (pop-up windows in drag and drop).
The shuttle was sold on the promise of routine, cheap, quick flights to space, and we have something that flies so irregularly that it's hard to even say how often it flies (once a year or less?).
Blame it on congress and cost cutting.
The original Shuttle designed called for a reusable pilot-able booster ratter than solid boosters and a foam-covered fuel tank (I've seen this referred to as a dual-stage maned orbiter-launcher).
The model was even shown on Discovery's "Return to flight" special on Daily Planet last week. I couldn't find images on the web though.
For every web site/.-ed, a message eventually appears from the webmaster explaining why their regular visitors were locked-out. This eventually leads to these visitors back to/.
Slashdot Mirror
ADA has nothing to do with software vendor accessibility.
It's about a person's disability(/ies).
Even if you could argue that Safari, FireFox, Opera and what-have-you would be disabled-persons tools, you can't argue against the fact that IE is Section-K compliant (aka, ADA part specific to computer software).
This is purely about incompetence of web site developers.
And MicroSoft being responsible for the levee breakage I suppose (har har).
Don't you dare compare that chick to that chimp again!
I think it was always pretty clear that MonkeyBoy is totally a deranged maniac. And I mean this in the most flattering way I can given he's probably worse than what his public figure make him out to be.
This is serious stuff. He basically made a death threat to the Google CEO.
Balmer sometimes acts like a cocaine addict. Snappy, choleric, over-hyped ("developers developers developers!").
He's certainly not a role model of mine.
Gates might have been an evil corporate henchman, but at least he didn't have this deranged personality.
What the hell you're talking about?
There's no "native PowerPC" or "Native Intel" binary formats. It's all just binary data dumped into a file. How this file is organized means only something to the operating system loading it. Not the CPU. The CPU doesn't care where the data segments is. It doesn't care where the content lies within the file. It's not going to load it and parse the damn file itself.
All it cares is the in-memory address or what's to execute.
PEF (long deprecated) and CFM were formats devised for use the the classic Mac OS system. It's nothing to do with any specific CPU requirements. It's simply a standard way to package your binaries so the OS knows what to do with them and how to access them.
The truth of the matter is, any CFM app runs slower in Mac OS X. Not much slower. Perhaps not noticeably slower. But any system or Mach-O library call will end up requiring two jumps to get to it so either way you look at it, CFM apps WILL be slower than Mach-O. but again, it's got nothing to do with the CPU. It's the managing OS underneath and how everything else is linked as.
As far as GCC's PPC code generation, same goes for Intel. If you want faster generated code, you go either CodeWarrior or IBM's XL for PPC, or go with Intel compiler (icc?) for Intel hardware.
It's got nothing to do with the binary format. Other than not having to doubly-inderect system calls if you're linked as CFM.
Almost.
The binary format of Carbon application is either CFM or Mach-O.
CFM was the binary format of Mac OS "classic".
Mach-O is the native binary format of Mac OS X.
When the OS loads a CFM application, it does so through a "LaunchCFMApp" process instance wich loads the CFM binary and links up in one huge vector table all the system calls being made to Mach-O libraries (including Core Foundation & Carbon).
A CFM application is therefore double-inderected for all system calls.
Mach-O Carbon applications though are not all that common. Anything that still supports Mac OS Classic will be in CFM. There's not that much advantages at moving your CFM application to Mach-O unless it's to remove the tiny (and I mean tiny) burden of dealing with cross-format boundaries. There's not a performance penalty worth mentioning at being CFM, unless you're dealing with quick load time.
Cocoa applications are invariably in Mach-O format. So are, too, any unix tools underneath.
Off-topic:
Given that all of Apple's tools (and binaries for that matter) are Mach-O, it's easier to debug a Mach-O binary, unless you stick with CodeWorrior (did I misspelled that? Oops!).
Apple did say the transition would take a couple of years.
It's obvious that after the Intel bomb shell they dropped that they now need to secure supplies of current processors until the entire line has moved onto Intel.
This is common sense. (But you don't have to expect this from news sites that report, even, that Apple might be back-tracking on the Intel switch.)
It reminds them too much of their own "What you say!" and "Move 'Zig' For Great Justice".
Just to be a smart ass:
:D
The first person waves at 12:02.
The second at 12:04
Unless you have an observer next to every person with a stopwatch. And then you still have to wait a few years for them to return you the results.
(BTW, the third person didn't wave. He was sick of waiting for the signal.)
I still preferred it to Windows because of the UI, but I'm very pleased that with OS X I no longer have to make that tradeoff.
As seen in an earlier response of mine, I fully agree with this.
But Mac OS in itself was not buggy. it behaved pretty well and probably had fewer bugs than any OS might have today (that's a given due to it's size really, but nonetheless true--the OS itself had very few flaws).
In itself, mac OS was also very stable. Most commercial applications also were very stable. Even sharewares. But Mac OS' vulnerability to other process' failures was due to it's ancient (20 years!) design. Not because it was unstable. Apple recognized that fact too and tried many times to make it evolve (Pink/Taligent, Copland) but failed. In a way, I'm glad they failed because I'm sure we're better off with OpenStep^H^H^H^H Mac OS X than whatever they could have come up with on their own.
The Multi-processing API (thanks for bringing it up) came much later than those I mentioned in my original reply. I've not used that one myself wich is probably why I omitted it in the first place (I was looking for "MPTask" something but I couldn't find it in my head).
I still glad we have OS X anyhow. But I dont like people dissing the older brother because he wasn't as brilliant. He was a fun buddy.
This may be because I keep all my old Macs around.
Wrong.
Miss-behaving applications could bog down other applications because Mac OS used "cooperating" multi-tasking. An application, through it's normal course of operation, would relinquish CPU time through it's event loop(s).
It's a transparent process done simply by polling the system for your next user, system or idle event (aka, "WaitNextEvent()"). This is where Mac OS' multi-tasking defers from preemption modern OSes offer (Linux, Unices including OS X and Windows). In those OSes, the kernel is the one that decides when to switch out the CPU's attention.
Any application not relinquishing CPU time when it didn't need it was immediately considered poorly-programmed and seldomly used.
A developer's poor aptitude was no excuse for the Mac OS locking up. It offered everything you needed to make things to smoothly. It just required a bit more thinking.
Dont get me wrong. I prefer OS X to what we had back then (I've been developing, professionally, Mac applications since 1988 so I know what we had back "then"). But It's important not to skew the facts.
I waste my moderation point (-1 troll) to bite...
pre-OSX Mac was buggy and unstable single-threaded OS
Wow. 3 false statements in one sentence only.
Tell us in what way Mac OS {10-n } was a) buggy b) unstable and c) single-threaded?
I'd really wish you'd tell me where Mac OS failed on you? Anything that was OS-related?
I've had better uptimes in Mac OS 8 and 9 than any version of Windows you can throw at it. Right up to XP.
Mac OS was threaded. In various ways. There was the Task Manager, the Vertical retrace manager, and the Time Manager (in 3 iterations over the years).
It didn't have (full) memory protection but this somehow made Mac apps more stable in the first place. When developers get called because their app takes down the whole system, they dont make the same mistake twice.
...dying of AIDs seems an attractive solution compared to milking crocs.
OpenGL support in Windows predates OS X as far as I know. So this decision was a good one for MS.
But now, MS might be seeing Open GL as a double-edged sword. Like any standard it doesn't control, MS now want to lock their incredible user/developer base to their own system by forcing a migration to things they do control.
OpenGL/DirectX isn't the only example of that. Java/C# and the PDF -like thing they're doing (forgot the name) come to mind.
Now that OpenGL is good on Mac OS X, it's time for MS to move away from OpenGL. And some developers are following on this. Look at video card makers. Some already provide DirectX acceleration chips on them.
^^nervous
(sigh)
Problem is that MicroSoft is doing everything it can to move developers off OpenGL and into DirectX. In Vista, OpenGL is actually impaired and emulated from DirectX.
So performance-inclined developers will be tempted to develop for DirectX wich isn't available (or wanted) on Mac OS X.
It's just another MS move in attempt to lock-out gaming from Mac OS X.
I bet they're nerver about mactel too.
4.6%.
(har har)
No MS virus have had any factual effect on Mac sales. Ratter, it's the cumulation of frustration that shifts some users away from MS.
This one virus alone isn't enough on it's own to make massive shifts. People are stupider than that.
And even if the power plant pollutes just as much as a car engine for a given amount of energy, there's another advantage -- the polution is generally produced away from the city, which helps keep the polution around the people who actually use the cars down.
A far worse problem not even looked at by bi-energy car buyers is the actual pollution generated by hybrid cars.
Them batteries are a heck of a problem to manufacture and dispose of. Altogether, hybrid cars may pollute less via their exhaust, but solid hard numbers of their real pollution output have not yet been studied.
Just do a little searching for google's sake:
I've heard and seen lots of tandoori programming recently. They claim they NAN is batter than ours.
[wrong buzzer sound]
Hold-click is still there. Case to point:the Dock. Hold-click and you get the contextual menu. Though, use of that IS marginal in Mac OS X as you imply.
So is drag-hold (pop-up windows in drag and drop).
I hope this finally ends all the lame "Yeah, but it only got a one-button mouse" idiocy
No. They'll go on forever and say "it took Apple 20 years to innovate a second button mouse on there".
The show's web rerun is available here
The shuttle was sold on the promise of routine, cheap, quick flights to space, and we have something that flies so irregularly that it's hard to even say how often it flies (once a year or less?).
Blame it on congress and cost cutting.
The original Shuttle designed called for a reusable pilot-able booster ratter than solid boosters and a foam-covered fuel tank (I've seen this referred to as a dual-stage maned orbiter-launcher).
The model was even shown on Discovery's "Return to flight" special on Daily Planet last week. I couldn't find images on the web though.
It's actually a good publicity vehicle.
/.-ed, a message eventually appears from the webmaster explaining why their regular visitors were locked-out. This eventually leads to these visitors back to /.
For every web site
The term slashdotting HAS become mainstream.
Most importantly:
some horror flic