Yes and no. For specific applications vacuum tubes are objectively better, and certainly there are lot of people who feel subjectively that they are.
But there is a LOT of variability in production quality and usable lifetime. One downer is that the high B+ voltages (350v to 500v+) require huge power supply capacitors, which are themselves prone to noise and require periodic replacement. So your TCO for a high-performing tube system is high.
One nice advantage tubes have is that they are highly resistant to radiation. Transistors are not. I'm betting some of those hollowed-out mountains in Colorado have plenty of tube-based equipment, just in case someone drops The Big One.
Guitarists are VERY conservative when it comes to gear. I worked as a vacuum tube tech for a while working on guitar amps. Guitar amps are the only place in electronics where you look at an RCA manual from the 1930's to find out what the specs are for something.
The digital amp-modeling units have had some succesd---I have a POD that I play almost exclusively. But guitars will NOT change. The iconic image of a rock star holding a Gibson or a Fender is embedded in the minds of too many middle-aged guitar players.
They only way this could happen is if the plug looks exactly like the current 1/4" model (another product from the 30's). Oh, and it has to be compatible with existing analog gear.
Wow, that sounds a little bit like--no, EXACTLY like--Verisign! And clearly they are taking over the world of end-user authentication, so you are definitely on to something.
All kidding aside, third-party trust is only as good as the initial validation of identity, and that itself is a commodity. It becomes a chicken-and-egg problem: if you give the Certificate Authority proof of your identity and the CA gives you a cert to present to a third party, why dontcha just give the third party your proof directly? Is it that hard?
This is pretty much the textbook definition of "patronizing." After Sept 11 can we really go on with the assumption that what everyone in the world wants is to live like an American?
We have two problems: a military/security problem and a cultural problem. Use appropriate tools for each. The Marshall plan worked because Western Europe is the source of America's cultural patrimony---for example the French invented many of our political ideals. Asia and the Middle East are not.
Going back a few years, check out Edward Said's literary work on "otherness"---his premise (much simplified) is that Western culture has defined itself in large part as being un-eastern, un-oriental, and in the process elevated the "mystery" of the east to mythical status.
We need to be clear-headed about this. A McDonald's in Kabul is 180 degrees from what we need to do.
Damn straight! Hear hear! Most of the "fun" stuff I see at these companies looks like the common room in a dorm. And I'm not 18 anymore, so I'm not so impressed.
Check out the runway when you fly into Denver. Tons of little lights all over the place. I'm told that all Denver landings are autocontrolled and that the lights correspond with sensors/transceivers embedded in the tarmac.
There's more to this than the legal aspect. I worked on a project attempting to introduce smartcard-based credit cards to the US. Yes, the legal aspect is important, but there are historical and technical reasons too.
* European consumer spending has historically relied on cash, not credit, and particularly not on bank-issued credit.
* The European telecommunications infrastructure is structured differently. First of all, the rates for local service are not artifically low, as they are in the US, where long distance subsidizes it. Plus there can be lots of taxes. This means that a small vendor's POS terminal can't call every transaction in to VISA/MC without impacting the profit on the sale.
* The legislative agenda in Europe empasizes consumer privacy, not consumer protection. This seems to create a bias toward technology and against contractual/business-based approaches to fraud management.
Re:Reminds me of how core memory used to be made
on
Ethernet MP3 Player
·
· Score: 1
Having done this kind of work---garage runs of prototypes---here's what you get:
1. back and neck strain, along with headaches, from bending over
2. wrist and hand cramps from holding the damn iron so long
3. low-grade respiratory problems from the solder fumes
4. A HUGE rush when you get the first one working, you feel like Prometheus....
Frink: Uh, bleah, guh, everyone says that scientists are not good with emotion, bluh huh. My new invention will prove them wrong! It is a computer language for classifying human interaction, with the smiling and the laughing and the turning me down for a date, bluh AAGH!
Actually the check digit system is a well-known algorithm for providing a checksum that people can handle. It is known as a Luhn or mod-10 system and is used on all major credit cards. Try it out, you'll see that the last (right-most) digit of your credit card number is the check digit for the rest.
It reduces errors by something less than 90%, which isn't too bad.
Well, okay, sure...but he's talking about the simple case. And if you qualify his point a little, he's right. Portforwarding only enables a single box to act as the server; fine for a home network but not for a corporate LAN. Proxying requires additional code running somewhere to compensate for the problems introduced by the NAT.
I'm writing an application proxy right now, and guess what---embedding routing info in application packets adds additional routing logic that is separate from your normal routing infrastructure. Can you say security hole?
He is pointing out how NAT is an incomplete solution to the problem of mapping multiple hosts to a single v4 address. And he's right, it's a pain in the ass.
My point was that Newton's was a scientific achievement. That's different than an engineering achievement. Different order of magnitude, different impact.
Linus comparing himself to Newton is like the Edison comparing himself to Einstein (sort of).
You're asking a bunch of geeks a business account management questions.
Here's the deal. Anytime an intangible value (like security) enters into a dollars-and-cents decision process, you have two sides: the geeks and the bean counters. Your people are the geeks.
Now wait---who decided that they should go with an insecure cheaper solution? Chances are the geeks bought into the process, or at least were forced to do due diligence and assent.
When you go to the company and expose the problem, who looks bad? The geeks! The geeks now have a professional investment in the bad solution.
Your best bet is to contact the technical people directly, create good will with them, and ALLOW THEM to take the issue to the bean-counters.
Let's see---on the one hand, we have Newton: creator of the foundation of all physics, whose theories and equations have lasted centuries with little modification.
On the other hand, we have a set of folks, Linus included, who ported an OS---one with a long pedigree and known advantages---to cheap and popular hardware.
I wouldn't disagree if Linus said that open-source drew from the same idealism and desire to experiment that science does. Or that OSS uses the same combination of open distribution of contributions with credit given to the individual authors that is characteristic of academic science journals. Or that devotion to a worthy goal without monetary compensation is (sometimes) laudable.
But guys...software isn't art, and usually there's not much science in it either. It's engineering.
It'd be more honest for Linus to point out that OSS isn't the same model as academic science, but in fact a new model: an ethical approach to engineering. Unfortunately, no zinger there.
Creating a roadblock and then giving out passes to vendors who "play nice" is MS's way of getting leverage over those vendors. And it clearly works....even if this memo is fake, the certification program does indeed have this effect.
And I think there is a devil's argument for this practice. MS has to support the OS as it ships to consumers, not as it is distributed to Dell, COmpaq, etc. And MS's marketing is based on ease of use.
If Dell et al are busy replacing the file manager and UI components and cutting out MS's default app set, the fact that both boxes have a MS OS is not very meaningful.
Put it this way...if someone branched KDE and made it look and act radically different, and added and removed many components, but still called it KDE, wouldn't that cause static in the Linux world?
Once again, agreed that to attain the level of security you are describing, the world of certs and PKIs is not yet providing the perfect solution. Even using finger and a PGP-style key management mechanism opens you up to DNS cache poisoning.
I think the "proof of identity" problem is a little bit of a red herring. Just because I *know* that the author of this RPM is Joe Foo at 123 4th street doesn't make me trust him. However, if Joe Foo's certificate corresponds to a well-known online source for good RPMs, that actually counts for something.
In any case, I believe we can do BETTER than what we have today, which is "hey here's a random RPM and the readme says it's what I want!" That's like soooooo 1975. If it's true we can do better, then what form would "better" take?
I say start with certs and signatures. Add some OSS-specific key revocation ("www.oss-badcerts.com says don't trust the user with DN 'foo-bar-fjdfladjd'") and we're much better off.
Agreed, the only way to reach a very high level of security is to do your own line-by-line source review and then build it yourself.
But signatures provide a high degree of assurance of a few important facts: integrity protection (has the binary been trojaned since it was signed) and authentication (at least back to the cert that signed it). Signatures alone will never get you to the line-by-line level of assurance.
As far as Verisign goes, the world has yet to see the perfect PKI. Doesn't mean nobody should use what is there. Especially in the open-source world, where reputation among peers is paramount, certs or PGP keys are a great mechanism.
Dvorak is just like all defenders of established technology. He treats the arbitrary rules of the game---"programming is paid for by ads"---as gospel.
If you buy any of the basic concepts behind capitalism---and even if you don't, the players in the TV industry do---you know that competition is not a zero-sum game where the pie is sliced up and a bigger piece for me means a smaller piece for you. Instead, new factors like technology enables pieces of the pie to shrink and grow.
There's nothing wrong with Tivo et al. rewriting the rules of the game, and clearly the rewriting is relatively minor. As other posters have pointed out, a lot of TV is watched on a subscription basis anyway. But the rules are going to evolve, and someone will always be behind the curve (and losing money as a result).
One direction we could go is a tiered system where set-top boxes provide commercial-free programming to those who pay a premium for it, and commercials to those who don't.
In any case, consumers have shown an extraordinary willingness to pay for TV. I'm pretty shocked that I'll pay $50 a month for the few shows I watch. But I do. The only changes that really break the rules are forcing consumers to pay when they don't want to.
Have you watched recently? They DO run ads. It went like this:
* In the olden days (70s and 80s) each show was preceded with about 20 seconds of voiceover, often crediting the PBS station that produced the programming ("brought to you by WGBH").
* Then charitable trusts and other corporate charity channels starting getting credit in the voiceover ("the Pugh charitable trust..") About this time they added "...and viewers like you."
* Then actual corporations got a mention. This may have come at the same time as a static display of the corporate logo, or a bit before.
* Now they show 30-second spots, usually "tasteful" in a Volvo kind of way, but very clearly commercials. These show up in a block of about 3 minutes between programs. Product category tie-ins, especially with cooking shows, are more and more prominent.
So with network TV you get 21 minutes of programming with 9 minutes of ads interspersed. PBS gives you a lot less ads, and they are in a block, but they are still ads.
Now PBS is very inconsistent across the country, so my local PBS (KCTS in Seattle, plus the two Canadian versions I can get on cable) may be ahead of the curve.
In case nobody over in Linux/OSS land has noticed, the world of consumer OS and consumer internet software has settled on a solution to this problem: cryptographically signed packages. Microsoft has used it for ActiveX and IE downloads for a long time, and is now using it for system components. Java's security model has reliance on signed components built into the foundation.
Pretty simple guys, go get a code-signing cert and sign all binaries using standards-based signing mechanisms (check OpenSSL). If you are the developer, sign the source tarball. If you are the builder of binaries, sign the binary tarball. Use a codebase that provides a permanent URL for the source of the component, and use a consistent versioning scheme.
Next step is creating auditing tools that step through your path and check for untrusted components.
Once the mechanism is in place, all you need is an enterprising distributer to make a 100% signed system. Now the user has to trust that the distributer has done their homework and actually reviewed the code and/or checked with the original developer.
One last thought: wouldn't it be cool if the kernel dynamically checked the signatures on components as they executed? This could kill performance, so you'd probably want to precheck a select set at startup and then just compare hashes as the components loaded.
OOP gets the rap for bloated code all the time.
But take a look at what goes into OOP:
1. Overloading. Typically this is handled by the compiler through name decoration. No performance impact, no binary bloat.
2. Encapsulation. This is just plain ol' typedef'ed structures with some additional rules for visibility and access. Most of this is handled at compile time, not runtime.
3. Polymorphism. This is usually handled by a virtual table-type mechanism, which results in a jump, offset and another jump, plus the stack correction on the return.
Polymorphism is the key element that can suck your cycles, but just as with any other tool the performance impact can be mitigated by profiling and using language features carefully. Unfortunately many developers do neither, and some dev environments/frameworks (MFC uggghhhh) actively work against efficient use of polymorphism.
Polymorphism and the use of interfaces can so radically improve the structure and quality of code that many shops make the tradeoff knowingly. I've done it both ways myself and there's pain on both sides of the fence.
I've been the tech lead helping put together a quasi-XP environment for the past six months.
First of all, XP is a bag of techniques, not all of which have to be used for the whole thing to work. It is not a monolithic system.
Second of all, the key IMHO to XP is the fact that the customer plays a central role. Every few weeks you demo your working code the customer. You tell them about what more needs to be done, expressed as features that make sense to them (stories).
So here's the problem: what happens when you don't have a direct customer? I can think of only a few examples of software development when the people writing the check are available, educated, and interested in what you are doing to provide you the assistance you need to stay on target. Onsite development of custom code in a corporate IT department is one (a la Chrysler's C3) and that's where XP was invented.
Does open-source software have a customer? Hmmmmm....uhhhh....NO. You cannot be the developer AND the customer at the same time. I'm not sure a loose "sponsorship" by an inner-circle developer on a large project counts really, either.
I hate to agree with what sounds like an arrogant statement, but the "dimwitted slowpoke" thing IS quite annoying. I have done some pair programming and I absolutely believe that if your working style is incompatible with your partner the productivity is almost nil.
It's like Dogbert's matrix of ugly vs. cute crossed with smart vs. stupid. Nobody wants to be paired with a slow stupid partner. But beyond that, the fast and risk-taking coder probably doesn't want to pair with the slow and careful programmer, even though they may both wind up in the same place at the same time.
I hit this exact problem a few months ago. I traced it to one of the eternal C++ problems: lack of standard name mangling/decoration. The CFX interface could easily be an "extern C" type interface, but instead it is a C++ interface. The native Sun compiler and gcc mangle names differently, hence missing symbols at shared object load time.
The other thing I noticed was that the CFX resources out there on the net seemed predominantly for ColdFusion on windows, with hardly anything about CFXs for Solaris. I guess this reflects the installed base of ColdFusion being mostly NT 4 boxes.
Slashdot Mirror
Yes and no. For specific applications vacuum tubes are objectively better, and certainly there are lot of people who feel subjectively that they are.
But there is a LOT of variability in production quality and usable lifetime. One downer is that the high B+ voltages (350v to 500v+) require huge power supply capacitors, which are themselves prone to noise and require periodic replacement. So your TCO for a high-performing tube system is high.
One nice advantage tubes have is that they are highly resistant to radiation. Transistors are not. I'm betting some of those hollowed-out mountains in Colorado have plenty of tube-based equipment, just in case someone drops The Big One.
Guitarists are VERY conservative when it comes to gear. I worked as a vacuum tube tech for a while working on guitar amps. Guitar amps are the only place in electronics where you look at an RCA manual from the 1930's to find out what the specs are for something.
The digital amp-modeling units have had some succesd---I have a POD that I play almost exclusively. But guitars will NOT change. The iconic image of a rock star holding a Gibson or a Fender is embedded in the minds of too many middle-aged guitar players.
They only way this could happen is if the plug looks exactly like the current 1/4" model (another product from the 30's). Oh, and it has to be compatible with existing analog gear.
Wow, that sounds a little bit like--no, EXACTLY like--Verisign! And clearly they are taking over the world of end-user authentication, so you are definitely on to something.
All kidding aside, third-party trust is only as good as the initial validation of identity, and that itself is a commodity. It becomes a chicken-and-egg problem: if you give the Certificate Authority proof of your identity and the CA gives you a cert to present to a third party, why dontcha just give the third party your proof directly? Is it that hard?
This is pretty much the textbook definition of "patronizing." After Sept 11 can we really go on with the assumption that what everyone in the world wants is to live like an American?
We have two problems: a military/security problem and a cultural problem. Use appropriate tools for each. The Marshall plan worked because Western Europe is the source of America's cultural patrimony---for example the French invented many of our political ideals. Asia and the Middle East are not.
Going back a few years, check out Edward Said's literary work on "otherness"---his premise (much simplified) is that Western culture has defined itself in large part as being un-eastern, un-oriental, and in the process elevated the "mystery" of the east to mythical status.
We need to be clear-headed about this. A McDonald's in Kabul is 180 degrees from what we need to do.
Damn straight! Hear hear! Most of the "fun" stuff I see at these companies looks like the common room in a dorm. And I'm not 18 anymore, so I'm not so impressed.
Check out the runway when you fly into Denver. Tons of little lights all over the place. I'm told that all Denver landings are autocontrolled and that the lights correspond with sensors/transceivers embedded in the tarmac.
There's more to this than the legal aspect. I worked on a project attempting to introduce smartcard-based credit cards to the US. Yes, the legal aspect is important, but there are historical and technical reasons too.
* European consumer spending has historically relied on cash, not credit, and particularly not on bank-issued credit.
* The European telecommunications infrastructure is structured differently. First of all, the rates for local service are not artifically low, as they are in the US, where long distance subsidizes it. Plus there can be lots of taxes. This means that a small vendor's POS terminal can't call every transaction in to VISA/MC without impacting the profit on the sale.
* The legislative agenda in Europe empasizes consumer privacy, not consumer protection. This seems to create a bias toward technology and against contractual/business-based approaches to fraud management.
Having done this kind of work---garage runs of prototypes---here's what you get:
1. back and neck strain, along with headaches, from bending over
2. wrist and hand cramps from holding the damn iron so long
3. low-grade respiratory problems from the solder fumes
4. A HUGE rush when you get the first one working, you feel like Prometheus....
Why does this make me think of Professor Frink?
Frink: Uh, bleah, guh, everyone says that scientists are not good with emotion, bluh huh. My new invention will prove them wrong! It is a computer language for classifying human interaction, with the smiling and the laughing and the turning me down for a date, bluh AAGH!
Actually the check digit system is a well-known algorithm for providing a checksum that people can handle. It is known as a Luhn or mod-10 system and is used on all major credit cards. Try it out, you'll see that the last (right-most) digit of your credit card number is the check digit for the rest.
It reduces errors by something less than 90%, which isn't too bad.
Well, okay, sure...but he's talking about the simple case. And if you qualify his point a little, he's right. Portforwarding only enables a single box to act as the server; fine for a home network but not for a corporate LAN. Proxying requires additional code running somewhere to compensate for the problems introduced by the NAT.
I'm writing an application proxy right now, and guess what---embedding routing info in application packets adds additional routing logic that is separate from your normal routing infrastructure. Can you say security hole?
He is pointing out how NAT is an incomplete solution to the problem of mapping multiple hosts to a single v4 address. And he's right, it's a pain in the ass.
My point was that Newton's was a scientific achievement. That's different than an engineering achievement. Different order of magnitude, different impact.
Linus comparing himself to Newton is like the Edison comparing himself to Einstein (sort of).
You're asking a bunch of geeks a business account management questions.
Here's the deal. Anytime an intangible value (like security) enters into a dollars-and-cents decision process, you have two sides: the geeks and the bean counters. Your people are the geeks.
Now wait---who decided that they should go with an insecure cheaper solution? Chances are the geeks bought into the process, or at least were forced to do due diligence and assent.
When you go to the company and expose the problem, who looks bad? The geeks! The geeks now have a professional investment in the bad solution.
Your best bet is to contact the technical people directly, create good will with them, and ALLOW THEM to take the issue to the bean-counters.
Let's see---on the one hand, we have Newton: creator of the foundation of all physics, whose theories and equations have lasted centuries with little modification.
On the other hand, we have a set of folks, Linus included, who ported an OS---one with a long pedigree and known advantages---to cheap and popular hardware.
Ummmm...does typing "cc" constitute scientific discovery?
I wouldn't disagree if Linus said that open-source drew from the same idealism and desire to experiment that science does. Or that OSS uses the same combination of open distribution of contributions with credit given to the individual authors that is characteristic of academic science journals. Or that devotion to a worthy goal without monetary compensation is (sometimes) laudable.
But guys...software isn't art, and usually there's not much science in it either. It's engineering.
It'd be more honest for Linus to point out that OSS isn't the same model as academic science, but in fact a new model: an ethical approach to engineering. Unfortunately, no zinger there.
Creating a roadblock and then giving out passes to vendors who "play nice" is MS's way of getting leverage over those vendors. And it clearly works....even if this memo is fake, the certification program does indeed have this effect.
And I think there is a devil's argument for this practice. MS has to support the OS as it ships to consumers, not as it is distributed to Dell, COmpaq, etc. And MS's marketing is based on ease of use.
If Dell et al are busy replacing the file manager and UI components and cutting out MS's default app set, the fact that both boxes have a MS OS is not very meaningful.
Put it this way...if someone branched KDE and made it look and act radically different, and added and removed many components, but still called it KDE, wouldn't that cause static in the Linux world?
Once again, agreed that to attain the level of security you are describing, the world of certs and PKIs is not yet providing the perfect solution. Even using finger and a PGP-style key management mechanism opens you up to DNS cache poisoning.
I think the "proof of identity" problem is a little bit of a red herring. Just because I *know* that the author of this RPM is Joe Foo at 123 4th street doesn't make me trust him. However, if Joe Foo's certificate corresponds to a well-known online source for good RPMs, that actually counts for something.
In any case, I believe we can do BETTER than what we have today, which is "hey here's a random RPM and the readme says it's what I want!" That's like soooooo 1975. If it's true we can do better, then what form would "better" take?
I say start with certs and signatures. Add some OSS-specific key revocation ("www.oss-badcerts.com says don't trust the user with DN 'foo-bar-fjdfladjd'") and we're much better off.
Agreed, the only way to reach a very high level of security is to do your own line-by-line source review and then build it yourself. But signatures provide a high degree of assurance of a few important facts: integrity protection (has the binary been trojaned since it was signed) and authentication (at least back to the cert that signed it). Signatures alone will never get you to the line-by-line level of assurance. As far as Verisign goes, the world has yet to see the perfect PKI. Doesn't mean nobody should use what is there. Especially in the open-source world, where reputation among peers is paramount, certs or PGP keys are a great mechanism.
Dvorak is just like all defenders of established technology. He treats the arbitrary rules of the game---"programming is paid for by ads"---as gospel.
If you buy any of the basic concepts behind capitalism---and even if you don't, the players in the TV industry do---you know that competition is not a zero-sum game where the pie is sliced up and a bigger piece for me means a smaller piece for you. Instead, new factors like technology enables pieces of the pie to shrink and grow.
There's nothing wrong with Tivo et al. rewriting the rules of the game, and clearly the rewriting is relatively minor. As other posters have pointed out, a lot of TV is watched on a subscription basis anyway. But the rules are going to evolve, and someone will always be behind the curve (and losing money as a result).
One direction we could go is a tiered system where set-top boxes provide commercial-free programming to those who pay a premium for it, and commercials to those who don't.
In any case, consumers have shown an extraordinary willingness to pay for TV. I'm pretty shocked that I'll pay $50 a month for the few shows I watch. But I do. The only changes that really break the rules are forcing consumers to pay when they don't want to.
Have you watched recently? They DO run ads. It went like this:
* In the olden days (70s and 80s) each show was preceded with about 20 seconds of voiceover, often crediting the PBS station that produced the programming ("brought to you by WGBH").
* Then charitable trusts and other corporate charity channels starting getting credit in the voiceover ("the Pugh charitable trust..") About this time they added "...and viewers like you."
* Then actual corporations got a mention. This may have come at the same time as a static display of the corporate logo, or a bit before.
* Now they show 30-second spots, usually "tasteful" in a Volvo kind of way, but very clearly commercials. These show up in a block of about 3 minutes between programs. Product category tie-ins, especially with cooking shows, are more and more prominent.
So with network TV you get 21 minutes of programming with 9 minutes of ads interspersed. PBS gives you a lot less ads, and they are in a block, but they are still ads.
Now PBS is very inconsistent across the country, so my local PBS (KCTS in Seattle, plus the two Canadian versions I can get on cable) may be ahead of the curve.
In case nobody over in Linux/OSS land has noticed, the world of consumer OS and consumer internet software has settled on a solution to this problem: cryptographically signed packages. Microsoft has used it for ActiveX and IE downloads for a long time, and is now using it for system components. Java's security model has reliance on signed components built into the foundation.
Pretty simple guys, go get a code-signing cert and sign all binaries using standards-based signing mechanisms (check OpenSSL). If you are the developer, sign the source tarball. If you are the builder of binaries, sign the binary tarball. Use a codebase that provides a permanent URL for the source of the component, and use a consistent versioning scheme.
Next step is creating auditing tools that step through your path and check for untrusted components.
Once the mechanism is in place, all you need is an enterprising distributer to make a 100% signed system. Now the user has to trust that the distributer has done their homework and actually reviewed the code and/or checked with the original developer.
One last thought: wouldn't it be cool if the kernel dynamically checked the signatures on components as they executed? This could kill performance, so you'd probably want to precheck a select set at startup and then just compare hashes as the components loaded.
That was probably WriteNow, which was an excellent wp package for the Mac. Fast lean and full-featured. Worked great on my Mac Classic!
Just goes to show, build it and they may not come...
OOP gets the rap for bloated code all the time.
But take a look at what goes into OOP:
1. Overloading. Typically this is handled by the compiler through name decoration. No performance impact, no binary bloat.
2. Encapsulation. This is just plain ol' typedef'ed structures with some additional rules for visibility and access. Most of this is handled at compile time, not runtime.
3. Polymorphism. This is usually handled by a virtual table-type mechanism, which results in a jump, offset and another jump, plus the stack correction on the return.
Polymorphism is the key element that can suck your cycles, but just as with any other tool the performance impact can be mitigated by profiling and using language features carefully. Unfortunately many developers do neither, and some dev environments/frameworks (MFC uggghhhh) actively work against efficient use of polymorphism.
Polymorphism and the use of interfaces can so radically improve the structure and quality of code that many shops make the tradeoff knowingly. I've done it both ways myself and there's pain on both sides of the fence.
I've been the tech lead helping put together a quasi-XP environment for the past six months.
First of all, XP is a bag of techniques, not all of which have to be used for the whole thing to work. It is not a monolithic system.
Second of all, the key IMHO to XP is the fact that the customer plays a central role. Every few weeks you demo your working code the customer. You tell them about what more needs to be done, expressed as features that make sense to them (stories).
So here's the problem: what happens when you don't have a direct customer? I can think of only a few examples of software development when the people writing the check are available, educated, and interested in what you are doing to provide you the assistance you need to stay on target. Onsite development of custom code in a corporate IT department is one (a la Chrysler's C3) and that's where XP was invented.
Does open-source software have a customer? Hmmmmm....uhhhh....NO. You cannot be the developer AND the customer at the same time. I'm not sure a loose "sponsorship" by an inner-circle developer on a large project counts really, either.
It's like Dogbert's matrix of ugly vs. cute crossed with smart vs. stupid. Nobody wants to be paired with a slow stupid partner. But beyond that, the fast and risk-taking coder probably doesn't want to pair with the slow and careful programmer, even though they may both wind up in the same place at the same time.
I hit this exact problem a few months ago. I traced it to one of the eternal C++ problems: lack of standard name mangling/decoration. The CFX interface could easily be an "extern C" type interface, but instead it is a C++ interface. The native Sun compiler and gcc mangle names differently, hence missing symbols at shared object load time.
The other thing I noticed was that the CFX resources out there on the net seemed predominantly for ColdFusion on windows, with hardly anything about CFXs for Solaris. I guess this reflects the installed base of ColdFusion being mostly NT 4 boxes.