Try comparing a VGA signal to a DVI/DisplayPort one some time. The VGA version will be fuzzy and the colours will look a bit wonky compared to the DVI version.
As has been pointed out, if you've got an old monitor that doesn't do digital inputs then just use an adapter.
There's a clear statement here that whilst their court case with Intel are pending Nvidia are postponing investments for Intel DMI CPU chipset development. That's sensible since they could just be throwing such money away.
There's a clear statement that they already have products in the pipeline that are coming out in the next few months.
There is no sign at all in that letter that Nvidia are stopping developing chipsets for AMD, the clear implication is that this work is continuing.
I see no admission at all that Nvidia is leaving the chipset business - quite the opposite.
Neither Sony nor Microsoft have been bundling HDMI cables with their consoles for quite some time, if ever, least not in their mainstream mass-market SKUs. The fact that the latest iterations of their consoles don't include HDMI cables is thus wholly irrelevant.
Blackberry devices do not contain Exchange support themselves. They rely instead on "reflection servers" run by RIM. This therefore adds an additional point of failure - to get email on a Blackberry not only does the Exchange server have to be working, but the reflection server does too. It also exposes your email contents to RIM. There is no option on Blackberry devices to communicate directly with Exchange servers.
Apple's iPhone instead implements direct connection to Exchange servers, including push email, push contacts, and push calendar support, and have had this in place since iPhone 2.0 over a year ago. Oh, and there's remote wipe capabilities too just in case the phone gets lost. Apple refuses to implement "reflection servers" because, well, there's absolutely no need for them - they would increase the complexity of the system, increase the points of failure, and decrease the reliability. And that refusal is a point of criticism?
I'm not seeing any way in which the iPhone is weaker than the Blackberry in this specific area.
Electronic computers use base-2, hence why early computer engineers decided that a kilobyte should be a power of two at 1024 bytes. They probably should not have picked "kilo", but they did and we're stuck with it. They may well have been wrong in this, but this was all decided half a century ago.
This notion to rename a kilobyte to be a "kibibyte" is a relatively new one - I've only been aware of "kibibytes" for at most two years.
The source of this whole discussion is Apple's decision to report disk and file sizes in their Finder using the notion that 1KB = 1000 bytes. The absurd part of this though is that Apple are not consistent. Whilst the Finder reports based on 1KB = 1000 bytes, Mail and iTunes do not, and report their file sizes based on 1KB = 1024 bytes. This means when you copy a file out from iTunes, or save an email attachment, they magically grow in apparent size. System Profiler tells me my Mac has 2GB of RAM, and a 160GB hard disc, although those GB's mean different things...
Standards are based on common use. The argument that a kilobyte should be 1000 bytes should have happened at least 40 years ago. We are only having it now because only one segment of the IT industry, disc manufacturers, has insisted that a kilobyte should be 1000 bytes, whilst the rest insist it's 1024.
I'm not really too fussed about Apple doing this, even though I'm on the kilobyte = 1024 bytes (etc) side... I get the argument, but it's one that should have been had over 40 years ago.
Thing is, Apple are not doing this to be correct, they're only doing it to go along with HD manufacturers marketing departments. My Mac now reports that I have a 160GB hard disc, but it also reports I have 2GB of RAM.
Were they doing this to be technically correct about things, I'd have a 160GB hard disc, and 2 GiB of RAM. Instead they're still using GB for RAM, so the same symbol is being used to represent wildly different numbers of bytes. This is daft, and plain wrong.
Apple should pick one, or pick the other. A KB is either 1000 bytes, or it's 1024 - it's wrong that it should be both.
Personally I never thought that Mostly Harmless was an FU. I enjoyed it immensely. Yes, it's down-beat compared to the other novels in the series, but Adams said that was a reflection of his life at the time. I believe most of it had been written when he was having relationship troubles.
There is more than one possible way of interpreting the ending, and the events surrounding it. Arthur dying is clearly the obvious version, but there are other possibilities.
Back in the mists of time when I used to care about filtering out ads (I was on a dial-up connection) I'd run a Privoxy proxy server. Was very effective at ad blocking. Works with any browser, and runs on almost all OSs too.
Quick google search shows that Privoxy is still going strong.
If Linux had been BSD licensed, then all patches that get accepted to the kernel would also have to be BSD licensed.
On that basis, Linus could accept whatever patches he liked from any party for a BSD licensed kernel, just the same as with a GPL kernel. The license choice he made is largely irrelevant on this score.
I don't see the choice of GPL as being a major driver in the proliferation of the Linux kernel. The Linux kernel just happened to come along at the right time when there were few if any viable open-source alternatives, and gained sufficient mind-share to get a critical mass of development behind it. The choice of license was largely irrelevant for the early developers - they just wanted to hack a unix kernel.
Had Linus chosen the BSD license for Linux I don't see things having turned out much different. Sure, such a license would have allowed for proprietary development and branches to occur, but the main kernel would have remained BSD licensed. Independent developers would still have contributed back to the main BSD licensed kernel. Developers working on proprietary branches would be forever pressuring their management to allow them to contribute back their changes to help ensure they did not diverge too far from the main codebase and thus help them remain current with latest main-line kernel development.
You know what's somewhat ironic about all of this? At this point, the iPhone is probably the easiest phone to unlock EVAR, and is also the poster child for phones chained to tailored calling plans.
Er, no. This is completely inaccurate.
Original EDGE iPhones are easily unlocked. iPhone 3G devices with OS 2.2.0 or older are easily unlocked. iPhone 3G devices running the latest released OS (2.2.1) can currently be "jailbroken", but not unlocked. Jailbreaking means only that you can run applications that have not come from Apple's App Store.
As for the iPhone 3GS, and the forthcoming iPhone OS 3.0, the situation there is not yet clear. It is however certain that there will be no unlock solution for the iPhone 3GS when it is launched, and possibly not for several months after release. As for iPhone OS 3.0 running on existing phones, there may be a jailbreak shortly after release, but it currently seems highly unlikely that there will be an unlock solution.
To be clear, if you go into a store today and buy an iPhone 3G, you will be stuck with a phone that can only be used on AT&T (or whatever your local carrier is). The same will be true with the iPhone 3GS when it is released.
RISC chips have not failed. In fact, the majority of CPUs shipped today are RISC chips. They are just not used on desktop machines.
Intel's x86 design has just three markets: desktops, laptops, and servers. It dominates the first two of these, and leads the third.
In all other markets, RISC chips dominate. The mobile phone CPU market alone dwarfs the desktop/laptop/server market. Mobile phones these days are almost exclusively powered by ARM chips - a RISC design. ARMs also get used in several hand-held consoles, and various embedded applications such as routers. Later this year we'll see several ARM-powered netbooks... MIPS also features fairly heavily in these markets.
x86 relies on Windows being the dominant OS... That is not actually a given.
I believe that you're referring to Graffiti. That was the pseudo-handwriting system that Palm created. It pre-dates all of Palm's PDAs. Graffiti first appeared as an application for the Apple Newton.
The live content on iPlayer is not "implied", it's an actual current feature. All the BBC's main TV channels, with the sole exception of BBC Alba (the BBC's new Scottish language channel), are now available online for live streaming through the BBC iPlayer web site.
The addition of BBC One and BBC Two to live streaming was within the last few weeks, but I believe the other 6 channels (BBC Three, BBC Four, CBBC, CBeebies, BBC News and BBC Parliament) have been streaming for some time now. I'm not sure that local variations of BBC One and BBC Two are available - I only see the London versions and haven't spotted links for others.
I'm in the UK, I'm a fan of Doctor Who and Torchwood, and have set my DVR thingy to record The Sarah Jane Adventures too, although I tend to fall behind with watching that.
I'm really puzzled by your assertion that the three series are inter-linked, and that one needs to watch all three in order to understand Doctor Who.
There have been thematic cross-overs between the series, but generally this has been a flowing out from Doctor Who to the other two. In the case of the Sarah Jane Adventures, this has been the appearance of a couple of particular alien races (and a few specific individuals) that had earlier featured in Doctor Who. These stories may be considered as continuations of the Doctor Who stories, but are essentially still stand-alone, and have had no implications or repercussions in the opposite direction. So, yes, watching Doctor Who can give you a head-start in understanding some Sarah Jane stories, but that's about it.
As for Torchwood, whilst the Doctor Who season preceding the start of that series did have several episodes dealing with the Torchwood Institude. Since then Torchwood itself has been mostly independent of it's parent. About the only reminder of the two being linked has been the presence of Captain Jack. I guess the hand in the jar is about the only other link, but everything one needs to know about that is revealed in Doctor Who itself, not in Torchwood.
I cannot think of a single circumstance in Doctor Who where one has been left in the dark (or even in the shade) if one has not watched Torchwood and/or Sarah Jane. Not one.
Finally the three series generally have not run concurrently here in the UK. As a result, there are usually no story lines happening on the spin-offs whilst Doctor Who is running.
Perl's use of sigils is bizarre and illogical, making it a fantastically ugly language that's incredibly difficult to learn. Perl is what I'd recommend to put a child off programming for life.
I've been programming Perl professionally for 4 years now, out of a 20 year programming career, and I still occasionally get thrown by the bizarre sigils stuff. It took me a couple of months of full time programming with Perl before I'd get to a level where I'd say I was approaching proficiency.
I've used plenty of other languages, but Perl has by far the steepest learning curve of them all.
I agree that it's BS, however the word "of" is not in there in the original, it merely says "top octaves"... which changes the meaning somewhat to something that makes a bit more sense, although still BS.
Had the backing of all 4 major labels, and a bunch of tech companies too. Can't remember what ones exactly.
Load of big-wigs, coming up with a specification, with the promise of devices to follow... 200 companies involved. Never really materialised though. They worked on the spec for a few years and never came up with anything definitive.
Apple turned up with the iTunes Music Store, with their FairPlay DRM system, signed up all 4 majors, and the rest is history.
You do know that silicon is essentially sand, right? It is abundant and very cheap.
Yes, producing pure wafers of silicon has a cost associated with it. New CPUs do indeed cost a lot of money, but once all the sunk costs have been paid (i.e. for design, tooling, and plant) they become incredibly cheap to manufacture. Those sunk costs are immensely expensive.
Solar panels, like CPUs, will not become more cheaper because designs evolve to use less silicon but because the sunk costs (design, tooling, and plant) will get paid off quicker with larger sales.
I agree with you: Javascript is not technically the best solution to write such an application (for now, let's see when JS2 comes out and will be implemented by all major browsers).
Why?
Because JavaScript doesn't (yet) support classes?
If that is the answer, then with all due respect I thoroughly disagree. JavaScript is an OO language, it just uses differential (or prototype-based) inheritance, rather than class-based inheritance. It's quite possible to write fully featured GUI apps using a language that adopts a differential inheritance model. I did that for many years on the Newton, using NewtonScript.
The Newton OS APIs (object prototypes) that went with NewtonScript worked just fine, and provided a GUI that was in a number of ways more advanced than Cocoa. Gave very decent performance on an extremely limited platform.
Personally I have yet to be convinced of the wisdom of including classes in JavaScript2 - it feels unnecessary to me.
I can't help but feed them sometimes.:)
1) The scripting part: mistype a name, and bang, you've got a new variable Welcome to programming.
2) Failed object notation: this.bla, this.foo, this.callMethod(). This is a joke Javascript is not the only language with this notation... I don't consider it to be a joke myself.
3) No inheritance. Javascript is not object oriented. And using dojo.declare is no joy. Now on this you're wrong. Javascript has an inheritance model, and is object oriented. Just because the object model isn't class-based doesn't mean that it isn't there. Javascript uses prototype-based inheritance.
4) Failed arrays and type system. Play with a[1], a["1"] and other variations, loop over them and get different results. Joy and hapinness Well, there's a difference between an array and an "associative array". The first syntax you've used there is array access, second associative array...
5) Failed libraries: new Date( 2000, 1, 1 ): what date is that ? 2000-1-1. Year, Month, Day. Pretty standard way round that. Tis how one expresses dates unambiguously in a world where 1/12/2000 can mean either 1st December 2000 or 12th January 2000.
6) Failed runtime: where are the threads? True...
7) Failed syntax: compare { x:42, y:35 } with { x=42; y=35; }. I thought the comma-as-a-separator was a thing of the past. This is a matter of taste. Personally I'm very familiar with the former syntax, and the latter feels deeply unnatural to me.
I'm not really a Javascript programmer tho - most of the code I write is in other languages.
That being said, it is a very powerful language. But the OP is right saying it doesn't cut it for real web apps (think of apps in the 100K loc scale). It is just the best tool we have, but is in no mean perfect. Well, as I see it the one deficiency you've identified is a lack of threads. A quick google search leads me to believe thread-like behaviour can be simulated...
It seems to me that you just don't like the syntax of Javascript, and are not familiar with it's OO model.
The problem that comes up is that you already have one SMP architecture (the Quadcore Xeon) and one ASMP architecture (the Cell) in the system. How would you resolve this problem? Well, an existing PC that has a Quad-core Xeon as well as a modern GPU is already an SMP architecture processor in an ASMP system.
If one were to architect a system that had both Xeon(s) and Cell(s) that did require shared memory then logically you'd need to design a memory controller that both could talk to and arbitrate their requests.
Probably the easiest way to think about how you'd integrate a Cell processor with a Xeon could be to look on the Cell much like you'd look on a GPU.
Slashdot Mirror
What's wrong with having a VGA output?
Simple. It's crap.
Try comparing a VGA signal to a DVI/DisplayPort one some time. The VGA version will be fuzzy and the colours will look a bit wonky compared to the DVI version.
As has been pointed out, if you've got an old monitor that doesn't do digital inputs then just use an adapter.
Are we reading the same letter here?
There's a clear statement here that whilst their court case with Intel are pending Nvidia are postponing investments for Intel DMI CPU chipset development. That's sensible since they could just be throwing such money away.
There's a clear statement that they already have products in the pipeline that are coming out in the next few months.
There is no sign at all in that letter that Nvidia are stopping developing chipsets for AMD, the clear implication is that this work is continuing.
I see no admission at all that Nvidia is leaving the chipset business - quite the opposite.
Neither Sony nor Microsoft have been bundling HDMI cables with their consoles for quite some time, if ever, least not in their mainstream mass-market SKUs. The fact that the latest iterations of their consoles don't include HDMI cables is thus wholly irrelevant.
So, let me get this straight.
Blackberry devices do not contain Exchange support themselves. They rely instead on "reflection servers" run by RIM. This therefore adds an additional point of failure - to get email on a Blackberry not only does the Exchange server have to be working, but the reflection server does too. It also exposes your email contents to RIM. There is no option on Blackberry devices to communicate directly with Exchange servers.
Apple's iPhone instead implements direct connection to Exchange servers, including push email, push contacts, and push calendar support, and have had this in place since iPhone 2.0 over a year ago. Oh, and there's remote wipe capabilities too just in case the phone gets lost. Apple refuses to implement "reflection servers" because, well, there's absolutely no need for them - they would increase the complexity of the system, increase the points of failure, and decrease the reliability. And that refusal is a point of criticism?
I'm not seeing any way in which the iPhone is weaker than the Blackberry in this specific area.
Electronic computers use base-2, hence why early computer engineers decided that a kilobyte should be a power of two at 1024 bytes. They probably should not have picked "kilo", but they did and we're stuck with it. They may well have been wrong in this, but this was all decided half a century ago.
This notion to rename a kilobyte to be a "kibibyte" is a relatively new one - I've only been aware of "kibibytes" for at most two years.
The source of this whole discussion is Apple's decision to report disk and file sizes in their Finder using the notion that 1KB = 1000 bytes. The absurd part of this though is that Apple are not consistent. Whilst the Finder reports based on 1KB = 1000 bytes, Mail and iTunes do not, and report their file sizes based on 1KB = 1024 bytes. This means when you copy a file out from iTunes, or save an email attachment, they magically grow in apparent size. System Profiler tells me my Mac has 2GB of RAM, and a 160GB hard disc, although those GB's mean different things...
Standards are based on common use. The argument that a kilobyte should be 1000 bytes should have happened at least 40 years ago. We are only having it now because only one segment of the IT industry, disc manufacturers, has insisted that a kilobyte should be 1000 bytes, whilst the rest insist it's 1024.
I'm not really too fussed about Apple doing this, even though I'm on the kilobyte = 1024 bytes (etc) side... I get the argument, but it's one that should have been had over 40 years ago.
Thing is, Apple are not doing this to be correct, they're only doing it to go along with HD manufacturers marketing departments. My Mac now reports that I have a 160GB hard disc, but it also reports I have 2GB of RAM.
Were they doing this to be technically correct about things, I'd have a 160GB hard disc, and 2 GiB of RAM. Instead they're still using GB for RAM, so the same symbol is being used to represent wildly different numbers of bytes. This is daft, and plain wrong.
Apple should pick one, or pick the other. A KB is either 1000 bytes, or it's 1024 - it's wrong that it should be both.
Personally I never thought that Mostly Harmless was an FU. I enjoyed it immensely. Yes, it's down-beat compared to the other novels in the series, but Adams said that was a reflection of his life at the time. I believe most of it had been written when he was having relationship troubles.
There is more than one possible way of interpreting the ending, and the events surrounding it. Arthur dying is clearly the obvious version, but there are other possibilities.
Back in the mists of time when I used to care about filtering out ads (I was on a dial-up connection) I'd run a Privoxy proxy server. Was very effective at ad blocking. Works with any browser, and runs on almost all OSs too.
Quick google search shows that Privoxy is still going strong.
Huh?
If Linux had been BSD licensed, then all patches that get accepted to the kernel would also have to be BSD licensed.
On that basis, Linus could accept whatever patches he liked from any party for a BSD licensed kernel, just the same as with a GPL kernel. The license choice he made is largely irrelevant on this score.
I don't see the choice of GPL as being a major driver in the proliferation of the Linux kernel. The Linux kernel just happened to come along at the right time when there were few if any viable open-source alternatives, and gained sufficient mind-share to get a critical mass of development behind it. The choice of license was largely irrelevant for the early developers - they just wanted to hack a unix kernel.
Had Linus chosen the BSD license for Linux I don't see things having turned out much different. Sure, such a license would have allowed for proprietary development and branches to occur, but the main kernel would have remained BSD licensed. Independent developers would still have contributed back to the main BSD licensed kernel. Developers working on proprietary branches would be forever pressuring their management to allow them to contribute back their changes to help ensure they did not diverge too far from the main codebase and thus help them remain current with latest main-line kernel development.
You might want to pick up a newspaper more than once a year. A female US judge is the #1 news story in just about all of them for the last week.
Not in any of the papers here in the UK....
Is there something wrong with real trees?
You know what's somewhat ironic about all of this? At this point, the iPhone is probably the easiest phone to unlock EVAR, and is also the poster child for phones chained to tailored calling plans.
Er, no. This is completely inaccurate.
Original EDGE iPhones are easily unlocked. iPhone 3G devices with OS 2.2.0 or older are easily unlocked. iPhone 3G devices running the latest released OS (2.2.1) can currently be "jailbroken", but not unlocked. Jailbreaking means only that you can run applications that have not come from Apple's App Store.
As for the iPhone 3GS, and the forthcoming iPhone OS 3.0, the situation there is not yet clear. It is however certain that there will be no unlock solution for the iPhone 3GS when it is launched, and possibly not for several months after release. As for iPhone OS 3.0 running on existing phones, there may be a jailbreak shortly after release, but it currently seems highly unlikely that there will be an unlock solution.
To be clear, if you go into a store today and buy an iPhone 3G, you will be stuck with a phone that can only be used on AT&T (or whatever your local carrier is). The same will be true with the iPhone 3GS when it is released.
Your subject title is patently false.
RISC chips have not failed. In fact, the majority of CPUs shipped today are RISC chips. They are just not used on desktop machines.
Intel's x86 design has just three markets: desktops, laptops, and servers. It dominates the first two of these, and leads the third.
In all other markets, RISC chips dominate. The mobile phone CPU market alone dwarfs the desktop/laptop/server market. Mobile phones these days are almost exclusively powered by ARM chips - a RISC design. ARMs also get used in several hand-held consoles, and various embedded applications such as routers. Later this year we'll see several ARM-powered netbooks... MIPS also features fairly heavily in these markets.
x86 relies on Windows being the dominant OS... That is not actually a given.
I believe that you're referring to Graffiti. That was the pseudo-handwriting system that Palm created. It pre-dates all of Palm's PDAs. Graffiti first appeared as an application for the Apple Newton.
The "open" access point part of a FON router is not actually fully open. If you attempt to use it you get presented with a FON login page.
All owners of FON routers have a FON login. Other people can access providing they pay a fee.
The live content on iPlayer is not "implied", it's an actual current feature. All the BBC's main TV channels, with the sole exception of BBC Alba (the BBC's new Scottish language channel), are now available online for live streaming through the BBC iPlayer web site.
The addition of BBC One and BBC Two to live streaming was within the last few weeks, but I believe the other 6 channels (BBC Three, BBC Four, CBBC, CBeebies, BBC News and BBC Parliament) have been streaming for some time now. I'm not sure that local variations of BBC One and BBC Two are available - I only see the London versions and haven't spotted links for others.
So is/was Doctor Who.
Whilst these days it's produced by BBC Wales, it was originally a production of the BBC children's TV department...
I'm in the UK, I'm a fan of Doctor Who and Torchwood, and have set my DVR thingy to record The Sarah Jane Adventures too, although I tend to fall behind with watching that.
I'm really puzzled by your assertion that the three series are inter-linked, and that one needs to watch all three in order to understand Doctor Who.
There have been thematic cross-overs between the series, but generally this has been a flowing out from Doctor Who to the other two. In the case of the Sarah Jane Adventures, this has been the appearance of a couple of particular alien races (and a few specific individuals) that had earlier featured in Doctor Who. These stories may be considered as continuations of the Doctor Who stories, but are essentially still stand-alone, and have had no implications or repercussions in the opposite direction. So, yes, watching Doctor Who can give you a head-start in understanding some Sarah Jane stories, but that's about it.
As for Torchwood, whilst the Doctor Who season preceding the start of that series did have several episodes dealing with the Torchwood Institude. Since then Torchwood itself has been mostly independent of it's parent. About the only reminder of the two being linked has been the presence of Captain Jack. I guess the hand in the jar is about the only other link, but everything one needs to know about that is revealed in Doctor Who itself, not in Torchwood.
I cannot think of a single circumstance in Doctor Who where one has been left in the dark (or even in the shade) if one has not watched Torchwood and/or Sarah Jane. Not one.
Finally the three series generally have not run concurrently here in the UK. As a result, there are usually no story lines happening on the spin-offs whilst Doctor Who is running.
Are you having a laugh?
Perl's use of sigils is bizarre and illogical, making it a fantastically ugly language that's incredibly difficult to learn. Perl is what I'd recommend to put a child off programming for life.
I've been programming Perl professionally for 4 years now, out of a 20 year programming career, and I still occasionally get thrown by the bizarre sigils stuff. It took me a couple of months of full time programming with Perl before I'd get to a level where I'd say I was approaching proficiency.
I've used plenty of other languages, but Perl has by far the steepest learning curve of them all.
IMHO the only reason why Perl is popular is CPAN.
I agree that it's BS, however the word "of" is not in there in the original, it merely says "top octaves"... which changes the meaning somewhat to something that makes a bit more sense, although still BS.
SDMI.
The Secure Digital Music Initiative.
Had the backing of all 4 major labels, and a bunch of tech companies too. Can't remember what ones exactly.
Load of big-wigs, coming up with a specification, with the promise of devices to follow... 200 companies involved. Never really materialised though. They worked on the spec for a few years and never came up with anything definitive.
Apple turned up with the iTunes Music Store, with their FairPlay DRM system, signed up all 4 majors, and the rest is history.
You do know that silicon is essentially sand, right? It is abundant and very cheap.
Yes, producing pure wafers of silicon has a cost associated with it. New CPUs do indeed cost a lot of money, but once all the sunk costs have been paid (i.e. for design, tooling, and plant) they become incredibly cheap to manufacture. Those sunk costs are immensely expensive.
Solar panels, like CPUs, will not become more cheaper because designs evolve to use less silicon but because the sunk costs (design, tooling, and plant) will get paid off quicker with larger sales.
Silicon is not a factor in the price.
I agree with you: Javascript is not technically the best solution to write such an application (for now, let's see when JS2 comes out and will be implemented by all major browsers).
Why?
Because JavaScript doesn't (yet) support classes?
If that is the answer, then with all due respect I thoroughly disagree. JavaScript is an OO language, it just uses differential (or prototype-based) inheritance, rather than class-based inheritance. It's quite possible to write fully featured GUI apps using a language that adopts a differential inheritance model. I did that for many years on the Newton, using NewtonScript.
The Newton OS APIs (object prototypes) that went with NewtonScript worked just fine, and provided a GUI that was in a number of ways more advanced than Cocoa. Gave very decent performance on an extremely limited platform.
Personally I have yet to be convinced of the wisdom of including classes in JavaScript2 - it feels unnecessary to me.
I can't help but feed them sometimes.
I'm not really a Javascript programmer tho - most of the code I write is in other languages. That being said, it is a very powerful language. But the OP is right saying it doesn't cut it for real web apps (think of apps in the 100K loc scale). It is just the best tool we have, but is in no mean perfect. Well, as I see it the one deficiency you've identified is a lack of threads. A quick google search leads me to believe thread-like behaviour can be simulated...
It seems to me that you just don't like the syntax of Javascript, and are not familiar with it's OO model.
If one were to architect a system that had both Xeon(s) and Cell(s) that did require shared memory then logically you'd need to design a memory controller that both could talk to and arbitrate their requests.
Probably the easiest way to think about how you'd integrate a Cell processor with a Xeon could be to look on the Cell much like you'd look on a GPU.