Or in my case, a wife who believes that small cactuses placed next to cathode ray tubes absorb "harmful radiation" because some articles and ads in womens' magazines said so. Protesting that I am a lot bigger than said cactuses and made of similar stuff, so if they did absorb radiation, I'd be absorbing more of it, is futile. Trying to explain the fact that LCD monitor haven't got cathode ray tubes is like having a farting contest with a herd of cows. And so I sit surrounded by little spiky cactuses located just where they will impale me whenever I put a CD in, access a USB / Firewire port, or carelessly move a mouse too far in certain directions because "it's good for you".
IMO the greatest single proof of creationism is the fact that no evolutionary process would have produced so many people who get the first opinion they come across about any given topic immovably lodged in their brains.
In any case, OS X is extremely profitable for Apple:
1) it lets them charge a premium for what is now essentially the same hardware that others have to sell for a lower price, part of which goes to MS.
2) They sell a _lot_ of OS X upgrades to existing Mac users, which gives them a post-sales income stream that would otherwise go into Microsoft's coffers.
3) Apple also sell a lot of Mac software ranging from iLife upgrades to high-priced professional applications. These sales would dwindle if they were forced to compete with entrenched ISVs on Windows.
4) Ditto for high-priced Apple hardware such as Airport. These things sell for a premium because they are part of the "Apple life style", and that would not exist if Apple became yet another Windows box maker (the fact that Apple are associated with a life style is indicative of how strategically important OS X is. One does not for example hear people talk about a "Dell life-style" or a "Gateway life-style").
5) All of the above would also mean a massive diminution of income from AppleCare, because existing Wintel support companies would offer better contracts at more attractive prices.
And if the above financial reasons weren't more than enough for Apple to continue developing OS X, there is also a strategic factor that comes from having the freedom to set their own agenda, a freedom that many consumer-oriented computer manufacturers would love to have. Apple is a company that likes to have complete control, and switching to Windows would mean ceding virtually all of that control to Microsoft. And as many others have found to their cost, letting Microsoft have control over one's destiny can be very dangerous indeed.
Out of general interest, how many people are on that committee? This is being presented as if the very act of MS putting a representitive into the body means that they are exercising some sort of control over it, whereas in my (albeit limited) experience, such groups usually have people from a fair number of commercial entities in them (together with various non-commercial ones), so Microsoft's single member would be unlikely to have any notable influence on anything.
And in a logical world, even those shouldn't have been given any sort of patent, because the concept of using commercial sponsors to subsidise goods or services has been around for centuries. Granting a patent for using an existing and well-known business model to operate a business is not new or innovative, irrespective of what that business happens to be.
The driver situation was a bummer, but then the same could be said for NT of all flavours. As you say, they weren't consumer operating-systems. but they made great development workstations, and were pretty reliable departmental file and print servers _if_ that's all they were used for. Unfortunately, the fact they had GUIs meant that far too many people ended up using said servers as PCs too, which compromised both stability and performance.
The majority ended with Windows-2000, although that was not of course aimed at domestic users. It was however IMO the first really competent operating system from MS.
History teaches that it is the probability of getting caught which acts as a deterrent to crimes, not the potential severity of the punishment. This is why so many criminals try to hide one crime (i.e. reduce their probability of getting caught) by committing a more serious one, e.g. rapists who risk life imprisonment (or the death penalty in the US) by murdering their victim so there will be no witnesses, or somebody who does the same thing while robbing a store or bank.
In Western democracies, draconian punishments for non-violent crimes (i.e. crimes against property rather than people) are thus tantamount to admitting that the chances of getting caught for that particular activity are extremely remote. And those with a predeliction for such things will thus continue as before because risk / benefit ratio is massively slewed towards the benefit side of the equation. People do after all still drive cars and cross busy streets filled with them despite the fact that doing either can result in a fate far worse than spending a _amximum_ of two years in a German prison for offenders who are not a risk to the public.
Dresden was a major rail transport hub (rail was extremely important to German logistics at the time), so it was ostensibly a legitimate strategic target. However, even the low-accuracy bombing techniques of the 1940s did not require levelling an entire city just to take out the rail yards.
"100% false. You must be really confused, because Intel OS X supports the Carbon API just fine"
You are of course correct -- my bad. Apple made a lot of noise just after they'd announced the switch to Intel about "future-proofing" code by rewriting Carbon apps in Cocoa, and cited various companies who were doing just that. I made mental note to the effect of "no Carbon on Intel", and thought no more about it because Carbon is of no interest to me (I've been developing for Mac for about a year, have no legacy code to worry about, and am not porting any of my Windows stuff. This makes Carbon of at best academic interest, because Cocoa has a richer set of APIs and is a lot faster to develop with). I should however have checked up before posting instead of relying on an impression gained before Apple had even shipped the first Intel-based development systems, and apologise for not doing so.
"which is good because that's what vast majority of commercial Mac applciations use"
They do not. While it is true that some of the _most popular_ Mac apps use Carbon (although it is usually mixed with Cocoa code nowadays), "most popular" and "vast majority" are not the same. There are two basic categories of Mac application that use Carbon:
1) Those that have been ported from Windows. Although this is a notably non-trivial process with Carbon, it is still easier than completely rewriting the entire application for Cocoa, assuming of course that the bulk of one's code is written in C or C++ (which is still the case for most commercial Windows stuff despite Microsoft's efforts at moving everyone to.NET). A lot of games ported by Aspyr fall into this group.
2) Native Mac applications with a significant body of legacy code that was written for older versions of Apple operating systems (Photoshop is in this category).
The ones in category (2) are starting to thin out a bit nowadays, though. A lot of the new features that were added to third-party apps subsequent to the OS X transition got written for Cocoa, while the core functions stayed in Carbon. However, Apple have been busily adding new stuff over the years, and using it requires rewriting some of that legacy code. Even if that functionality is available via Carbon (which is by no means always the case), there's little point spending time and money on Carbon-based rewrites when the same thing could be done more easily and quickly with Cocoa. Once the Carbon legacy stuff dwindles below a certain level, it becomes a liability rather than an asset from a maintainability viewpoint.
Most of the stuff that's been written specifically for OS X is Cocoa-based, because Cocoa is quicker and easier to develop for, and supplies some things that simply aren't available in Carbon.
"not having read the first page of Apple's programming manual puts your entire argument in doubt."
The first page of Apple's "programming manual" (or more accurately, programming database) is page 1 of "Getting Started". It says nothing about Carbon beyond having a hyperlink sitting among 26 others under the "Getting Started with Specific Apple Technologies" heading. One could have spent years programming for the Mac without ever encountering Carbon or any documentation about it, because it is not required for those who aren't porting from Windows or working with a body of legacy Mac code that was written before OS X existed.
As to putting my entire argument into doubt, what about the errors you've made such as claiming that multi-tasking solves multi-threading issues? At least I acknowledge my errors and apologise for them.
"I asked which major Windows apps weren't multithreaded."
Where? I've just walked up the thread, and you did not ask for this at all.
"Haven't got an answer yet."
Au contraire. Despìte _not_ being asked, I have already given one pretty major example: the Windows Explorer.
"Finder is a Carbon application, and so is every other major Mac app except maybe one or two"
Bullshit. Well over 90% of current Mac apps are Cocoa based -- if that were not the case, then they couldn't be ported as native apps to new Intel version of OS X, which doesn't have the Carbon compatibility layer, so they would be permanently consigned to running under Rosetta (s-l-o-w), if indeed they work under it, because not all Carbon applications are compatible with Rosetta.
"Fortunately there's an option to run Explorer windows in seperate processes, which solves all the "threading" issues".
1) Running multiple concurrent processes does not solve any threading issues, because multi-tasking (which was around before Microsoft, let alone Windows) and multi-threading _are not the same_.
2) Each of those processes still locks under the circumstamces I described previously because _they are single-threaded_ processes. If you don't kill them via task manager, they will sit there until the next re-boot consuming resources and preventing any other process from using the ports they are occupying. This coukd have been avoided if MS had used their own threading API, which has several facilities for using time-outs in routines that are waiting for completion events. They actually tell programmers to use multi-threading in these circumstances for precisely this reason, and I do not claim to know why they didn't follow their own advice (note that this is not a slam: MS may have had several very good reasons for implementing the Windows explorer in precisely the way they did, and Apple aren't exactly a brilliant example of a company that does things the way they tell the rest of us to either!).
1) MS Office and Photoshop are not "most major Windows apps 10 years ago", which is what you claimed.
2) Finder is a Carbon application (i.e. it uses a portability layer that lets code for old Apple operating systems be compiled to run on OS X). It does not therefore benefit from _Cocoa_ multithreading, which is what the GP was talking about (because he specifically mentioned it by name).
3) In any case, Windows XP suffers from the same problem as Finder, especially when browsing network locations: the cursor turns into an hour-glass, the window client area won't update, and in the case of WebDAV folders, it can lock up completely if it can't open the folder (you get a "Not Responding" message in the window title bar). The only way out of the latter situation involves killing the process, which resets the entire desktop. Obviously, "most major Windows apps 10 years ago" did not include critical XP components released 5 years ago.
"Meanwhile, back in non-fanboy reality, most major Windows programs were multithreaded for backgroaund tasks 10 years ago"
This is total BS. I'm a programming contractor, and have been working on Windows since it was in version 2.1 for companies all over the world, exclusively writing code for commercial applications (i.e. not in-house corporate stuff). In nearly 20 years of Windows programming, I have come across _one_ Windows application that is designed for multi-threaded operation besides those that I've written entirely on my own.
Furthermore, read what the GP actually said: much in the Cocoa library adds multi-threading (and automatic scheduling of said threads to multiple CPUs) "free of charge", i.e. you don't have to specifically write multi-threaded code for applications to take advantage of muliple threads (BeOS did this a lot better than OS X). In Windows on the other hand, you have to craft threaded code by hand, which means dealing with both synchronisation using no less than three different types of synchronisation objects, and possible contention issues. This is hard to do and even harder to debug because getting one thing slightly wrong can result in crashes, resource leaks, locked resources that are only released after a re-boot, "orphaned" threads, and a host of other issues that only manifest themselves when two or more threads are performing a specific set of actions concurrently, which is a rare occurrence in code that by definition operates asynchronously.
Which means that multi-threaded code _which works as intended_ is extremely difficult to write under Windows, so few applications bother with it because it adds a whole bunch of issues that single-threaded apps just don't have to deal with. And in the real non-fanboy world of commercial software, more issues means higher costs in both programming and support.
Note that most of the above is true of nearly all multi-threaded environments if one deliberately writes multi-threaded code. Java simplifies a lot of things by having threading built into the language rather than supplied by library calls, and its GC will automatically remove threads when they've finshed executing, even if this happens after the host application has been closed (thereby reducing the probability of permanently orphaned threads cluttering up the system). It cannot however prevent deadlocks due to contention issues because these are caused by poor program design or coding, usually by people who have little or no idea of how design or write multi-threaded code.
in summary then, you (like many on/.) are spouting a bunch of shite based on some stuff you've read somewhere, hence the fact that you do not realise the massive difference between "supports mulñti-threading" and "implicitly adds multi-threading, irrespective of whether an application is explicitly written to be multi-threaded or not". So you paraphrase you, "Meanwhile, back in Slashdot reality, a Windows fanboy is talking out of his arse."
Because he's a wanker, not a cyborg or a scientist (unless one uses both terms very loosely, e.g. "I am a cyborg because I have a filling", "I am a scientist because I watch National Geographic Channel").
Re:Even if this one isn't real...
on
WinXP on a Mac, Hoax?
·
· Score: 5, Interesting
"Why would you want to run WindowsXP on an Intel based Mac?"
I'm an example of somebody who would want precisely that capability. I have a Mac and various Wintel PCs, and use the Mac for everything except my work (which currently revolves around Windows programming) and some occasional gaming. Being a programming contractor means that I need to travel a fair bit, and my old Windows laptop is showing signs of age, so I'll be in the market for a new one during the next few months. Practicality would appear to dictate another Windows-based machine, but I'd prefer an Apple with OS X otherwise, and could actually justify buying one if I could do my Windows development work on it.
"The reason Intel developed EFI, after all, was to patent it and require AMD to license it from Intel, right?"
Wrong. EFI is firmware that lives on the motherboard, not a part of the CPU, so AMD would not have to license it in any shape or form. It is motherboard or motherboard firmware / chipset manufacturers who would be faced with licensing it from Intel, but this is not restricted to those building systems for AMD CPUs -- third parties manufacturing such systems for Intel processors will also have to pay a license fee to Intel.
IBM are a member of this, and Sun are either joining or are planning to join. IMO trusted computing is much more likely to herald a "digital dark age" than any existing proprietary document format, so the _real_ headline is "IBM and Sun want some of Microsoft's lucrative Office market, and think that pushing Open Document might get it".
"I see this argument on a pretty regular basis, and I think it misses something."
It misses something else as well: source code is a piece of text, and pieces of text are not self-reproducing, so his "counterexample" actually has no more relevance to the topic than hydrogen, soot, or the Crab Nebula.
Slashdot Mirror
Indeed you were. My bad.
Or in my case, a wife who believes that small cactuses placed next to cathode ray tubes absorb "harmful radiation" because some articles and ads in womens' magazines said so. Protesting that I am a lot bigger than said cactuses and made of similar stuff, so if they did absorb radiation, I'd be absorbing more of it, is futile. Trying to explain the fact that LCD monitor haven't got cathode ray tubes is like having a farting contest with a herd of cows. And so I sit surrounded by little spiky cactuses located just where they will impale me whenever I put a CD in, access a USB / Firewire port, or carelessly move a mouse too far in certain directions because "it's good for you".
IMO the greatest single proof of creationism is the fact that no evolutionary process would have produced so many people who get the first opinion they come across about any given topic immovably lodged in their brains.
And (3) Microsoft.
In any case, OS X is extremely profitable for Apple:
1) it lets them charge a premium for what is now essentially the same hardware that others have to sell for a lower price, part of which goes to MS.
2) They sell a _lot_ of OS X upgrades to existing Mac users, which gives them a post-sales income stream that would otherwise go into Microsoft's coffers.
3) Apple also sell a lot of Mac software ranging from iLife upgrades to high-priced professional applications. These sales would dwindle if they were forced to compete with entrenched ISVs on Windows.
4) Ditto for high-priced Apple hardware such as Airport. These things sell for a premium because they are part of the "Apple life style", and that would not exist if Apple became yet another Windows box maker (the fact that Apple are associated with a life style is indicative of how strategically important OS X is. One does not for example hear people talk about a "Dell life-style" or a "Gateway life-style").
5) All of the above would also mean a massive diminution of income from AppleCare, because existing Wintel support companies would offer better contracts at more attractive prices.
And if the above financial reasons weren't more than enough for Apple to continue developing OS X, there is also a strategic factor that comes from having the freedom to set their own agenda, a freedom that many consumer-oriented computer manufacturers would love to have. Apple is a company that likes to have complete control, and switching to Windows would mean ceding virtually all of that control to Microsoft. And as many others have found to their cost, letting Microsoft have control over one's destiny can be very dangerous indeed.
Out of general interest, how many people are on that committee? This is being presented as if the very act of MS putting a representitive into the body means that they are exercising some sort of control over it, whereas in my (albeit limited) experience, such groups usually have people from a fair number of commercial entities in them (together with various non-commercial ones), so Microsoft's single member would be unlikely to have any notable influence on anything.
And in a logical world, even those shouldn't have been given any sort of patent, because the concept of using commercial sponsors to subsidise goods or services has been around for centuries. Granting a patent for using an existing and well-known business model to operate a business is not new or innovative, irrespective of what that business happens to be.
"As for .NET, a C# desktop application performs pretty well"
Not if it uses WinForms or GDI+.
The driver situation was a bummer, but then the same could be said for NT of all flavours. As you say, they weren't consumer operating-systems. but they made great development workstations, and were pretty reliable departmental file and print servers _if_ that's all they were used for. Unfortunately, the fact they had GUIs meant that far too many people ended up using said servers as PCs too, which compromised both stability and performance.
The majority ended with Windows-2000, although that was not of course aimed at domestic users. It was however IMO the first really competent operating system from MS.
The difference being of course that nobody will want to listen to most of what they download from iTunes in 40 years.
"And DOS and CP/M pretty much evolved from Unix system III or so"
CP/M was inspired by DEC TOPS-10 rather than UNIX, and the first version of DOS was very heavily inspired by CP/M.
History teaches that it is the probability of getting caught which acts as a deterrent to crimes, not the potential severity of the punishment. This is why so many criminals try to hide one crime (i.e. reduce their probability of getting caught) by committing a more serious one, e.g. rapists who risk life imprisonment (or the death penalty in the US) by murdering their victim so there will be no witnesses, or somebody who does the same thing while robbing a store or bank.
In Western democracies, draconian punishments for non-violent crimes (i.e. crimes against property rather than people) are thus tantamount to admitting that the chances of getting caught for that particular activity are extremely remote. And those with a predeliction for such things will thus continue as before because risk / benefit ratio is massively slewed towards the benefit side of the equation. People do after all still drive cars and cross busy streets filled with them despite the fact that doing either can result in a fate far worse than spending a _amximum_ of two years in a German prison for offenders who are not a risk to the public.
Dresden was a major rail transport hub (rail was extremely important to German logistics at the time), so it was ostensibly a legitimate strategic target. However, even the low-accuracy bombing techniques of the 1940s did not require levelling an entire city just to take out the rail yards.
"100% false. You must be really confused, because Intel OS X supports the Carbon API just fine"
.NET). A lot of games ported by Aspyr fall into this group.
You are of course correct -- my bad. Apple made a lot of noise just after they'd announced the switch to Intel about "future-proofing" code by rewriting Carbon apps in Cocoa, and cited various companies who were doing just that. I made mental note to the effect of "no Carbon on Intel", and thought no more about it because Carbon is of no interest to me (I've been developing for Mac for about a year, have no legacy code to worry about, and am not porting any of my Windows stuff. This makes Carbon of at best academic interest, because Cocoa has a richer set of APIs and is a lot faster to develop with). I should however have checked up before posting instead of relying on an impression gained before Apple had even shipped the first Intel-based development systems, and apologise for not doing so.
"which is good because that's what vast majority of commercial Mac applciations use"
They do not. While it is true that some of the _most popular_ Mac apps use Carbon (although it is usually mixed with Cocoa code nowadays), "most popular" and "vast majority" are not the same. There are two basic categories of Mac application that use Carbon:
1) Those that have been ported from Windows. Although this is a notably non-trivial process with Carbon, it is still easier than completely rewriting the entire application for Cocoa, assuming of course that the bulk of one's code is written in C or C++ (which is still the case for most commercial Windows stuff despite Microsoft's efforts at moving everyone to
2) Native Mac applications with a significant body of legacy code that was written for older versions of Apple operating systems (Photoshop is in this category).
The ones in category (2) are starting to thin out a bit nowadays, though. A lot of the new features that were added to third-party apps subsequent to the OS X transition got written for Cocoa, while the core functions stayed in Carbon. However, Apple have been busily adding new stuff over the years, and using it requires rewriting some of that legacy code. Even if that functionality is available via Carbon (which is by no means always the case), there's little point spending time and money on Carbon-based rewrites when the same thing could be done more easily and quickly with Cocoa. Once the Carbon legacy stuff dwindles below a certain level, it becomes a liability rather than an asset from a maintainability viewpoint.
Most of the stuff that's been written specifically for OS X is Cocoa-based, because Cocoa is quicker and easier to develop for, and supplies some things that simply aren't available in Carbon.
"not having read the first page of Apple's programming manual puts your entire argument in doubt."
The first page of Apple's "programming manual" (or more accurately, programming database) is page 1 of "Getting Started". It says nothing about Carbon beyond having a hyperlink sitting among 26 others under the "Getting Started with Specific Apple Technologies" heading. One could have spent years programming for the Mac without ever encountering Carbon or any documentation about it, because it is not required for those who aren't porting from Windows or working with a body of legacy Mac code that was written before OS X existed.
As to putting my entire argument into doubt, what about the errors you've made such as claiming that multi-tasking solves multi-threading issues? At least I acknowledge my errors and apologise for them.
"I asked which major Windows apps weren't multithreaded."
Where? I've just walked up the thread, and you did not ask for this at all.
"Haven't got an answer yet."
Au contraire. Despìte _not_ being asked, I have already given one pretty major example: the
Windows Explorer.
"Finder is a Carbon application, and so is every other major Mac app except maybe one or two"
Bullshit. Well over 90% of current Mac apps are Cocoa based -- if that were not the case, then
they couldn't be ported as native apps to new Intel version of OS X, which doesn't have the Carbon
compatibility layer, so they would be permanently consigned to running under Rosetta (s-l-o-w),
if indeed they work under it, because not all Carbon applications are compatible with Rosetta.
"Fortunately there's an option to run Explorer windows in seperate processes, which solves all the
"threading" issues".
1) Running multiple concurrent processes does not solve any threading issues, because
multi-tasking (which was around before Microsoft, let alone Windows) and multi-threading
_are not the same_.
2) Each of those processes still locks under the circumstamces I described previously because
_they are single-threaded_ processes. If you don't kill them via task manager, they will sit there
until the next re-boot consuming resources and preventing any other process from using the ports
they are occupying. This coukd have been avoided if MS had used their own threading API, which
has several facilities for using time-outs in routines that are waiting for completion events. They
actually tell programmers to use multi-threading in these circumstances for precisely this
reason, and I do not claim to know why they didn't follow their own advice (note that this is not
a slam: MS may have had several very good reasons for implementing the Windows explorer
in precisely the way they did, and Apple aren't exactly a brilliant example of a company that
does things the way they tell the rest of us to either!).
1) MS Office and Photoshop are not "most major Windows apps 10 years ago", which is what you claimed.
2) Finder is a Carbon application (i.e. it uses a portability layer that lets code for old Apple operating systems be compiled to run on OS X). It does not therefore benefit from _Cocoa_ multithreading, which is what the GP was talking about (because he specifically mentioned it by name).
3) In any case, Windows XP suffers from the same problem as Finder, especially when browsing network locations: the cursor turns into an hour-glass, the window client area won't update, and in the case of WebDAV folders, it can lock up completely if it can't open the folder (you get a "Not Responding" message in the window title bar). The only way out of the latter situation involves killing the process, which resets the entire desktop. Obviously, "most major Windows apps 10 years ago" did not include critical XP components released 5 years ago.
Banner ads can be run without having to host one's application on a web page.
"Meanwhile, back in non-fanboy reality, most major Windows programs were multithreaded for backgroaund tasks 10 years ago"
/.) are spouting a bunch of shite based on some stuff you've read somewhere, hence the fact that you do not realise the massive difference between "supports mulñti-threading" and "implicitly adds multi-threading, irrespective of whether an application is explicitly written to be multi-threaded or not". So you paraphrase you, "Meanwhile, back in Slashdot reality, a Windows fanboy is talking out of his arse."
This is total BS. I'm a programming contractor, and have been working on Windows since it was in version 2.1 for companies all over the world, exclusively writing code for commercial applications (i.e. not in-house corporate stuff). In nearly 20 years of Windows programming, I have come across _one_ Windows application that is designed for multi-threaded operation besides those that I've written entirely on my own.
Furthermore, read what the GP actually said: much in the Cocoa library adds multi-threading (and automatic scheduling of said threads to multiple CPUs) "free of charge", i.e. you don't have to specifically write multi-threaded code for applications to take advantage of muliple threads (BeOS did this a lot better than OS X). In Windows on the other hand, you have to craft threaded code by hand, which means dealing with both synchronisation using no less than three different types of synchronisation objects, and possible contention issues. This is hard to do and even harder to debug because getting one thing slightly wrong can result in crashes, resource leaks, locked resources that are only released after a re-boot, "orphaned" threads, and a host of other issues that only manifest themselves when two or more threads are performing a specific set of actions concurrently, which is a rare occurrence in code that by definition operates asynchronously.
Which means that multi-threaded code _which works as intended_ is extremely difficult to write under Windows, so few applications bother with it because it adds a whole bunch of issues that single-threaded apps just don't have to deal with. And in the real non-fanboy world of commercial software, more issues means higher costs in both programming and support.
Note that most of the above is true of nearly all multi-threaded environments if one deliberately writes multi-threaded code. Java simplifies a lot of things by having threading built into the language rather than supplied by library calls, and its GC will automatically remove threads when they've finshed executing, even if this happens after the host application has been closed (thereby reducing the probability of permanently orphaned threads cluttering up the system). It cannot however prevent deadlocks due to contention issues because these are caused by poor program design or coding, usually by people who have little or no idea of how design or write multi-threaded code.
in summary then, you (like many on
Because he's a wanker, not a cyborg or a scientist (unless one uses both terms very loosely, e.g. "I am a cyborg because I have a filling", "I am a scientist because I watch National Geographic Channel").
"Why would you want to run WindowsXP on an Intel based Mac?"
I'm an example of somebody who would want precisely that capability. I have a Mac and various Wintel PCs, and use the Mac for everything except my work (which currently revolves around Windows programming) and some occasional gaming. Being a programming contractor means that I need to travel a fair bit, and my old Windows laptop is showing signs of age, so I'll be in the market for a new one during the next few months. Practicality would appear to dictate another Windows-based machine, but I'd prefer an Apple with OS X otherwise, and could actually justify buying one if I could do my Windows development work on it.
"From Wikipedia"
The Internet equivalent of what a guy in a queue outside a cinema says.
"Isn't this good news for AMD?"
It is irrelevant to AMD.
"The reason Intel developed EFI, after all, was to patent it and require AMD to license it from Intel, right?"
Wrong. EFI is firmware that lives on the motherboard, not a part of the CPU, so AMD would not have to license it in any shape or form. It is motherboard or motherboard firmware / chipset manufacturers who would be faced with licensing it from Intel, but this is not restricted to those building systems for AMD CPUs -- third parties manufacturing such systems for Intel processors will also have to pay a license fee to Intel.
IBM are a member of this, and Sun are either joining or are planning to join. IMO trusted computing is much more likely to herald a "digital dark age" than any existing proprietary document format, so the _real_ headline is "IBM and Sun want some of Microsoft's lucrative Office market, and think that pushing Open Document might get it".
"I see this argument on a pretty regular basis, and I think it misses something."
It misses something else as well: source code is a piece of text, and pieces of text are not self-reproducing, so his "counterexample" actually has no more relevance to the topic than hydrogen, soot, or the Crab Nebula.
"This amounts to nothing more than a fictional narrative that conveniently fits the observed facts"
"How this amounts to something more scientifically compelling than what I learned in Sunday School is beyond me."
Because (to use your own terminology) what you learned in Sunday school is a fictional narrative that does _not_ fit the observed facts.
(Narrative that fits the observed facts) = explanation.
(Narrative that does not fit the observed facts) = lie.