Exactly. As Ballmer once put it, when asked why Microsoft kept adding functions to Windows,
"If we stopped adding functions to Windows, it would become a commodity, like a BIOS. And Microsoft is not in the BIOS business". This is called "strategic complexity". It's a very real, key component of Microsoft's strategy.
That's way too much for a downsized version on a tiny handheld screen. If you get an HD version, sure, but sub-TV resolution movies aren't worth that much.
Cardigan? The one who sent the Charge of the Light Brigade off in the wrong direction through ego and stupidity? Apple used him on a poster?
"splice" - because Microsoft did it?
on
Linux 2.6.17 Released
·
· Score: 4, Interesting
The "splice" system call seems to be an answer to one of Microsoft's bad ideas - serving web pages from the kernel. At one point, Microsoft was claiming that an "enterprise operating system" had to be able to do that. So now Linux has a comparable "zero copy" facility.
"Zero copy" tends to be overrated. It makes some benchmarks look good, but it's only useful if your system is mostly doing very dumb I/O bound stuff. In environments where web pages have to be ground through some engine like PHP before they go out, it won't help much.
The usual effect of adding "zero copy" to something is that the performance goes up a little, the complexity goes up a lot, and the number of crashes increases.
That's actually the slogan of Wikitruth, but they have a point.
As a regular editor of Wikipedia, it's clear to me what the limitations of the approach are. It's really impressive how far Wikipedia has come. But it seems to have peaked in quality.
Articles on significant subjects tend to be edited until they're roughly correct. They then enter the "churn phase", where they're frequently edited with edits of varying quality. Over time, the overall result of the churning is negative, as the article slowly turns to mush. Every once in a while, someone comes along and cleans up some of the mess. The article's quality then fluctuates over time; on any given day, it may be anywhere from excellent to terrible, depending on recent edits. See, for example, Horse.
Most of the articles on important subjects have already been created. By now, most new articles don't add much of value. New articles tend to be spam, promotion of garage bands, entries for long-forgotten politicians, articles about minor schools, and atlas entries for state highways. Plus there's an endless flood of fancruft; Wikipedia is essentially duplicating IMDB and Gracenote, with a lower level of accuracy and less searchability. There's way too much detail on games, comics, and fan stuff; every Pokemon has a full article, and almost everything from Star [Wars|Trek|Gate], however minor, has an entry. That's where the "million articles" really come from.
This stuff only exists under huge pressure; it's not stable under ordinary conditions.
Compare xenon hexafluoride, a compound of an inert element, something once thought to be impossible. It is also created under high pressure, but it remains a crystalline solid at room temperature and pressure.
It's impressive that they're doing this. Moewe has rather low wing area for the slow-speed maneuvering it does in Nausicaa, though. It's certainly possible to make a lively little aerobatic monoplane (the Sukhoi S-26 is one of the best modern ones), but those little wings imply a high stall speed. If you want hang-glider type stall speeds, you need more wing area or less weight. The classic solution for slow flight is the biplane. Take a look at this old Sperry Messenger, which has about the same wingspan as Moewe. The Messenger was a very maneuverable little plane. Sperry himself once landed one in front of the U.S. Capitol.
Moewe's tailless design creates a pitch stability problem from hell, but that's what flight-control computers are for. It's interesting to see what changes they made from the R/C model. The R/C model looks more like Moewe, with straight wings and a huge dihedral angle. The bigger towed model has a bent wing. They're trying for something that wants to fly straight and level.
There's much new interest in light aircraft today. The FAA has created a new category of "light sport planes", heavier than ultralights but lighter than general aviation aircraft, with less restrictive licensing. Take a look at this StingSport, which isn't much bigger than Moewe, even though it's a two-seater.
I expect the Open Sky crowd will build something that looks more or less like Moewe and flies reasonably well. And they'll do it long before Moller gets off the ground.
It's a bulk eraser for hard drives, and it weighs 125 pounds. Put drive in slot, turn crank. That's a very special-purpose product. Especially since it will erase the alignment tracks, too, so it's strictly for destroying a drive, not for prepping one for reuse.
In America's Army, players who violate the rules are sent to an online prison. "You are in the United States Army Disciplinary Barracks at Fort Leavenworth, Kansas..."
As Joel points out in "Joel on Software", the language isn't the big issue any more. It's the libraries. Learning another set of a few thousand things you can call, where a measureable fraction of them are broken or don't meet their specifications, requires time and practice.
And it's so unrewarding, because you're expected to work around the flaws in the libraries.
I miss aerospace, where, when a vendor doesn;t meet specification, the contracts people pound on the vendor until it's fixed.
Los Alamos once had the tradition that the lab director had to have a Nobel Prize. In the 1980s, Ronald Reagan appointed a lawyer. It's been downhill since then.
When CDs first came out, there were some very low cost breadbox-like plastic boxes with slots for jewel cases. I bought about twenty of these boxes, for about $35 or so, and still use them. Then came all those more-expensive ways of storing discs; padded cases, flip racks, and other overpriced dreck. Try to get low-cost boxes for dead storage now.
Unfortunately reference-counting leaks in circularly linked structures.
That's the textbook answer, but in practice it's not a major problem, especially if you have both "strong links" and "weak links", like Perl. Perl and Python can leak circularly linked structures, but in practice, they seldom do. The reason is that leaks due to circular linking are generally due to design errors, and will occur in normal program operation, so they're caught early in debugging. Unreleased blocks and dangling pointers, on the other hand, tend to occur in abnormal situations, so they're not caught early in debugging and persist into production programs.
In a language with destructors, a reference-count approach has the advantage that destructor ordering works out correctly. Trying to call destructors from the garbage collector leads to a horrible mess, as can be seen in Managed C++.
Occam is like that, where all sizes are known in advance.
There's a language you don't hear much about any more.
The other thing to bear in mind is that CPUs are designed around procedural code, NOT functional design and certainly not object-oriented principles. Code written in a non-native paradigm is essentially cross-compiled to the native paradigm and there must surely be some loss of efficiency there. I suspect that if you were to build a CPU where the design and instruction set was modelled after Smalltalk, then compiled C would probably run slower than interpreted Smalltalk, as the interpreter would be a very thin layer over the CPU whereas the compiler would need to add an enormous wedge of compatibility code, adding overhead.
Then again, maybe not. LISP machines turned out to be slower than LISP on conventional CPUs. Hardware Java engines turned out to be a dead end. The programmer-friendly instructions of the VAX line slowed down the CPU, and the Intel 432 was painfully slow. It's not at all clear that building higher language abstractions into the hardware helps. You lose some of the ability to exploit
concurrency that a modern register-oriented superscalar CPU gives you. It's surprising which instruction set architectures can be made to go fast. x86 actually turns out to be pretty good, ugly though it is. RISC features like large numbers of programmer-visible registers and fixed-width instructions turned out not to help. The overhead of saving and restoring registers slowed down calls and interrupts, and the fixed-width instructions caused code bloat and wasted cache space.
There are some interesting things to do in the architectural area, like making the CPU's MMU and interconnects like InfiniBand play well together, so you can have safe inter-CPU communication without operating system intervention for every message pass. That's probably the next area for major performance improvements.
I know about D, I corresponded with Walter Bright about it, and I used his early compilers. But it's just not getting any traction. Today, to introduce a new language, not only do you have to give it away, you have to spend money promoting giving it away. Sun spent $20 million to launch Java as a free product.
One old worry is that someone would develop a way to trigger a fusion bomb without a fission bomb. Serious work went into that problem in the 1950s and 1960s, and the designer of the neutron bomb has been quoted as saying that certain lines of research should be discouraged because they might lead to a solution.
Re:The problem: our native-code languages are bad
on
The End of Native Code?
·
· Score: 2, Insightful
But the _real_ issue is that there are times:
1) when you want arrays and pointers to be the same thing, and
2) when you don't
No, the real issue is that you can't talk about the size of variable-sized data in C.
If C had syntax like
int write(int fd, size_t length, char buf[length]);
instead of
int write(int fd, char* buf, size_t length);
then size information would be carried along with the data, and checking would be possible. In the syntax we have now, you're lying to the compiler; you're saying you have a pointer to a char, but you really have a pointer to an array of char of indeterminate length. That's the problem. Most buffer overflows arise from this language design error.
C++ tries to paper this over with collection classes, but raw pointers keep leaking out, and the hiding thus doesn't quite work.
Windows 2000 has been looked at by many people, and its traffic to the network watched and analyzed. It's well known what it does and doesn't do, and it's known not to "phone home" unless you install some add-on that does so. XP, however, is a completely different story.
You run your Windows 2000 system. Redmond runs your XP system.
The problem: our native-code languages are bad
on
The End of Native Code?
·
· Score: 5, Insightful
The problem isn't native-code vs interpretive code. It's that our native code languages are terribly flawed.
Programming backed itself into a corner with C and C++. They're useful languages, but they're not safe. Now this has nothing to do with performance; you can have safety in a hard-compiled language. Ada, the Modula family, and the Pascal/Delphi family did it. The problem is that, because of some bad design decisions in C (the equivalence of arrays and pointers being the big one), you have to lie to the language to get anything done. This makes safety hopeless.
The basic problem of C is that you have to obsess on "who owns what" for memory allocation purposes, and the language gives you no help with this. The language doesn't even adequately address "how big is this". With those two design defects, we're doomed to have memory safety problems. Which we do.
C++ at first seemed like an improvement, but as it turned out, C++ adds hiding to C without improving safety. Note that this seems to be unique to C++; no prior language did that, and no language since has taken that route. Attempts have been made to work around the problem within the structure of C++, but with limited success. The "auto_ptr" debacle and the endless problems of trying to make sound reference-counted allocation work reliably indicate the fundamental limitations of the language. You just can't fix those problems in C++ without breaking backwards compatibility. (See my postings in comp.std.c++ over the last decade for more details on this.)
Java was invented mostly to get around the memory safety problems of C and C++.
The fact that Java is usually semi-interpretive has nothing to do with the language design; that's a consequence of Sun's original focus on applets. There are native-code compilers for Java; GCC contains one. There are competitive advantages of locking the user into a giant environment (J2EE in the Java world,.NET in the Microsoft world), which is part of why we're seeing so much of that. But it's not a language design issue.
Microsoft came up with C# as their answer to Java, and most of the same issues as with Java apply.
What's so embarassing about all this is that it's quite fixable. The solutions were known twenty years ago. If you have a language where the language knows how big everything is, and the subscript checks are hoisted out of loops at compile time, you get safety with high performance. There were Pascal compilers that got this right in the 1980s.
On the allocation front, you can use either garbage collection or reference counting to automate that process. Java and C# are garbage-collected; Perl and Python are reference-counted, and in practice, programmers in those languages seldom have to think about memory allocation issues. Allocation overhead can also be hoisted out of loops. Java compilers are starting to do this, allocating temporary variables on the stack. Reference count updates can be optimized similarly. There's nothing to prevent using these techniques in a native-code compiler.
And that's how we got to where we are today, with buffer overflows, zombies, and blue screens of death, papered over with a layer of inefficient interpreters. Fortunately the hardware people have held up their end and made it possible to live with this, but we on the software side should have the understanding and grace to be embarassed by it.
Somewhere, a bunch of programmers are busily recompiling x86 code for PowerPC and looking for endian problems. It's a routine headache. Remember, the original Xbox is quite vanilla; it's basically a PC with an NVidia graphics processor running a stripped-down Windows 2000. In fact, most Xbox games can be run on PCs with the development environment (usually VC++), if you have the tools and files to build the game. (No, fanboys, that doesn't mean you can run the retail game on your PC.)
I wonder if the porting job is being done in the US or in some low-wage country.
Right now, we're mostly at 8 bits of data per color channel. This upgrade supports 10, 12, and 16 bits of color per channel, or 24, 30, 36 and 48 bits per pixel.
This will be a big help in reducing banding on smooth gradients and artifacts during fades. Actually, you don't get more colors; you get more luminance range. It would probably work just as well to have 16 bits of luminance and two other color difference channels of 8 bits, but the HDMI people went uncompressed.
Now the compression people have to go to work and deal with the issues of when it's worthwhile to send that much data and when it isn't.
Silicon Valley ceased being an engine of significant economic growth after the dotcom bust. It is unlikely to return to its former glory.
I'm writing this from within walking distance of downtown Palo Alto, and I tend to agree. It's really discouraging. Five years after the dot-com crash, there are still empty industrial parks for lease. The big reseach centers are gone. Xerox PARC is gone. Interval Research is gone. IBM Almaden Research is emptying out. DEC SRL and DEC WRL are gone. HP's real business today is printer ink. Intel is still around, but the new fabs aren't here, and they seem to be out of ideas anyway.
Most growth seems to be in companies that deliver advertising - Google, A9, and their ilk. Startups tend to be "me-too" operations scrabbling for market share in crowded markets.
Yet there's so much to be done. How about producing a personal computer that just doesn't break? Something with hardware and software immune to attack. Satisfaction guaranteed or your money back. Or electric cars with serious range. Or safe nuclear power plants. But that's not what people are working on.
As the head of a DARPA Grand Challenge team last time around, I was seriously worried about this. We had to field test the thing, which
was a worrisome exercise. In the early phases, we operated entirely in a big fenced parking lot totally isolated from anybody. But later we had to take the vehicle into more accessable areas. We had very conservative algorithms on the LIDAR processing (which is why our vehicle tended to stop and rescan too much at the Grand Challenge), a radar system as backup, and an industrial-grade radio emergency stop system. And liability insurance.
The next DARPA Grand Challenge requires operating in congested areas, and that's going to require serious work on robot vehicle safety. The way this is going, those things are going to be rolling through small towns in hostile territory in a few years, and they'd better not be running over little kids.
I'm still running Windows 2000 on the Windows machine. I have the latest version of OpenOffice, the latest Firefox, the latest Blender, etc. and they all run fine, which is what matters. And I don't have to put up with whatever new stupid thing Microsoft does on XP, where your machine is a slave to Redmond.
Letting the vendor have a backdoor into your machine is really risky. If you're in a financial institution, is the vendor bonded? If you're a healthcare provider, is the vendor HIPPA compliant? If you're in a law firm, are any of your clients competitors of Microsoft? You have no contractual guarantee that somebody at Microsoft, or elsewhere, isn't using that backdoor in some interesting way.
Slashdot Mirror
Exactly. As Ballmer once put it, when asked why Microsoft kept adding functions to Windows, "If we stopped adding functions to Windows, it would become a commodity, like a BIOS. And Microsoft is not in the BIOS business". This is called "strategic complexity". It's a very real, key component of Microsoft's strategy.
That's way too much for a downsized version on a tiny handheld screen. If you get an HD version, sure, but sub-TV resolution movies aren't worth that much.
Cardigan? The one who sent the Charge of the Light Brigade off in the wrong direction through ego and stupidity? Apple used him on a poster?
The "splice" system call seems to be an answer to one of Microsoft's bad ideas - serving web pages from the kernel. At one point, Microsoft was claiming that an "enterprise operating system" had to be able to do that. So now Linux has a comparable "zero copy" facility.
"Zero copy" tends to be overrated. It makes some benchmarks look good, but it's only useful if your system is mostly doing very dumb I/O bound stuff. In environments where web pages have to be ground through some engine like PHP before they go out, it won't help much.
The usual effect of adding "zero copy" to something is that the performance goes up a little, the complexity goes up a lot, and the number of crashes increases.
That's actually the slogan of Wikitruth, but they have a point.
As a regular editor of Wikipedia, it's clear to me what the limitations of the approach are. It's really impressive how far Wikipedia has come. But it seems to have peaked in quality.
Articles on significant subjects tend to be edited until they're roughly correct. They then enter the "churn phase", where they're frequently edited with edits of varying quality. Over time, the overall result of the churning is negative, as the article slowly turns to mush. Every once in a while, someone comes along and cleans up some of the mess. The article's quality then fluctuates over time; on any given day, it may be anywhere from excellent to terrible, depending on recent edits. See, for example, Horse.
Most of the articles on important subjects have already been created. By now, most new articles don't add much of value. New articles tend to be spam, promotion of garage bands, entries for long-forgotten politicians, articles about minor schools, and atlas entries for state highways. Plus there's an endless flood of fancruft; Wikipedia is essentially duplicating IMDB and Gracenote, with a lower level of accuracy and less searchability. There's way too much detail on games, comics, and fan stuff; every Pokemon has a full article, and almost everything from Star [Wars|Trek|Gate], however minor, has an entry. That's where the "million articles" really come from.
This stuff only exists under huge pressure; it's not stable under ordinary conditions.
Compare xenon hexafluoride, a compound of an inert element, something once thought to be impossible. It is also created under high pressure, but it remains a crystalline solid at room temperature and pressure.
It's impressive that they're doing this. Moewe has rather low wing area for the slow-speed maneuvering it does in Nausicaa, though. It's certainly possible to make a lively little aerobatic monoplane (the Sukhoi S-26 is one of the best modern ones), but those little wings imply a high stall speed. If you want hang-glider type stall speeds, you need more wing area or less weight. The classic solution for slow flight is the biplane. Take a look at this old Sperry Messenger, which has about the same wingspan as Moewe. The Messenger was a very maneuverable little plane. Sperry himself once landed one in front of the U.S. Capitol.
Moewe's tailless design creates a pitch stability problem from hell, but that's what flight-control computers are for. It's interesting to see what changes they made from the R/C model. The R/C model looks more like Moewe, with straight wings and a huge dihedral angle. The bigger towed model has a bent wing. They're trying for something that wants to fly straight and level.
There's much new interest in light aircraft today. The FAA has created a new category of "light sport planes", heavier than ultralights but lighter than general aviation aircraft, with less restrictive licensing. Take a look at this StingSport, which isn't much bigger than Moewe, even though it's a two-seater.
I expect the Open Sky crowd will build something that looks more or less like Moewe and flies reasonably well. And they'll do it long before Moller gets off the ground.
It's a bulk eraser for hard drives, and it weighs 125 pounds. Put drive in slot, turn crank. That's a very special-purpose product. Especially since it will erase the alignment tracks, too, so it's strictly for destroying a drive, not for prepping one for reuse.
In America's Army, players who violate the rules are sent to an online prison. "You are in the United States Army Disciplinary Barracks at Fort Leavenworth, Kansas..."
And it's so unrewarding, because you're expected to work around the flaws in the libraries. I miss aerospace, where, when a vendor doesn;t meet specification, the contracts people pound on the vendor until it's fixed.
Los Alamos once had the tradition that the lab director had to have a Nobel Prize. In the 1980s, Ronald Reagan appointed a lawyer. It's been downhill since then.
When CDs first came out, there were some very low cost breadbox-like plastic boxes with slots for jewel cases. I bought about twenty of these boxes, for about $35 or so, and still use them. Then came all those more-expensive ways of storing discs; padded cases, flip racks, and other overpriced dreck. Try to get low-cost boxes for dead storage now.
Unfortunately reference-counting leaks in circularly linked structures.
That's the textbook answer, but in practice it's not a major problem, especially if you have both "strong links" and "weak links", like Perl. Perl and Python can leak circularly linked structures, but in practice, they seldom do. The reason is that leaks due to circular linking are generally due to design errors, and will occur in normal program operation, so they're caught early in debugging. Unreleased blocks and dangling pointers, on the other hand, tend to occur in abnormal situations, so they're not caught early in debugging and persist into production programs.
In a language with destructors, a reference-count approach has the advantage that destructor ordering works out correctly. Trying to call destructors from the garbage collector leads to a horrible mess, as can be seen in Managed C++.
Occam is like that, where all sizes are known in advance.
There's a language you don't hear much about any more.
The other thing to bear in mind is that CPUs are designed around procedural code, NOT functional design and certainly not object-oriented principles. Code written in a non-native paradigm is essentially cross-compiled to the native paradigm and there must surely be some loss of efficiency there. I suspect that if you were to build a CPU where the design and instruction set was modelled after Smalltalk, then compiled C would probably run slower than interpreted Smalltalk, as the interpreter would be a very thin layer over the CPU whereas the compiler would need to add an enormous wedge of compatibility code, adding overhead.
Then again, maybe not. LISP machines turned out to be slower than LISP on conventional CPUs. Hardware Java engines turned out to be a dead end. The programmer-friendly instructions of the VAX line slowed down the CPU, and the Intel 432 was painfully slow. It's not at all clear that building higher language abstractions into the hardware helps. You lose some of the ability to exploit concurrency that a modern register-oriented superscalar CPU gives you. It's surprising which instruction set architectures can be made to go fast. x86 actually turns out to be pretty good, ugly though it is. RISC features like large numbers of programmer-visible registers and fixed-width instructions turned out not to help. The overhead of saving and restoring registers slowed down calls and interrupts, and the fixed-width instructions caused code bloat and wasted cache space.
There are some interesting things to do in the architectural area, like making the CPU's MMU and interconnects like InfiniBand play well together, so you can have safe inter-CPU communication without operating system intervention for every message pass. That's probably the next area for major performance improvements.
I know about D, I corresponded with Walter Bright about it, and I used his early compilers. But it's just not getting any traction. Today, to introduce a new language, not only do you have to give it away, you have to spend money promoting giving it away. Sun spent $20 million to launch Java as a free product.
Is Hawking hinting at something here?
One old worry is that someone would develop a way to trigger a fusion bomb without a fission bomb. Serious work went into that problem in the 1950s and 1960s, and the designer of the neutron bomb has been quoted as saying that certain lines of research should be discouraged because they might lead to a solution.
But the _real_ issue is that there are times: 1) when you want arrays and pointers to be the same thing, and 2) when you don't
No, the real issue is that you can't talk about the size of variable-sized data in C.
If C had syntax like
int write(int fd, size_t length, char buf[length]);
instead of
int write(int fd, char* buf, size_t length);
then size information would be carried along with the data, and checking would be possible. In the syntax we have now, you're lying to the compiler; you're saying you have a pointer to a char, but you really have a pointer to an array of char of indeterminate length. That's the problem. Most buffer overflows arise from this language design error.
C++ tries to paper this over with collection classes, but raw pointers keep leaking out, and the hiding thus doesn't quite work.
Windows 2000 has been looked at by many people, and its traffic to the network watched and analyzed. It's well known what it does and doesn't do, and it's known not to "phone home" unless you install some add-on that does so. XP, however, is a completely different story. You run your Windows 2000 system. Redmond runs your XP system.
The problem isn't native-code vs interpretive code. It's that our native code languages are terribly flawed.
Programming backed itself into a corner with C and C++. They're useful languages, but they're not safe. Now this has nothing to do with performance; you can have safety in a hard-compiled language. Ada, the Modula family, and the Pascal/Delphi family did it. The problem is that, because of some bad design decisions in C (the equivalence of arrays and pointers being the big one), you have to lie to the language to get anything done. This makes safety hopeless. The basic problem of C is that you have to obsess on "who owns what" for memory allocation purposes, and the language gives you no help with this. The language doesn't even adequately address "how big is this". With those two design defects, we're doomed to have memory safety problems. Which we do.
C++ at first seemed like an improvement, but as it turned out, C++ adds hiding to C without improving safety. Note that this seems to be unique to C++; no prior language did that, and no language since has taken that route. Attempts have been made to work around the problem within the structure of C++, but with limited success. The "auto_ptr" debacle and the endless problems of trying to make sound reference-counted allocation work reliably indicate the fundamental limitations of the language. You just can't fix those problems in C++ without breaking backwards compatibility. (See my postings in comp.std.c++ over the last decade for more details on this.)
Java was invented mostly to get around the memory safety problems of C and C++. The fact that Java is usually semi-interpretive has nothing to do with the language design; that's a consequence of Sun's original focus on applets. There are native-code compilers for Java; GCC contains one. There are competitive advantages of locking the user into a giant environment (J2EE in the Java world, .NET in the Microsoft world), which is part of why we're seeing so much of that. But it's not a language design issue.
Microsoft came up with C# as their answer to Java, and most of the same issues as with Java apply.
What's so embarassing about all this is that it's quite fixable. The solutions were known twenty years ago. If you have a language where the language knows how big everything is, and the subscript checks are hoisted out of loops at compile time, you get safety with high performance. There were Pascal compilers that got this right in the 1980s.
On the allocation front, you can use either garbage collection or reference counting to automate that process. Java and C# are garbage-collected; Perl and Python are reference-counted, and in practice, programmers in those languages seldom have to think about memory allocation issues. Allocation overhead can also be hoisted out of loops. Java compilers are starting to do this, allocating temporary variables on the stack. Reference count updates can be optimized similarly. There's nothing to prevent using these techniques in a native-code compiler.
And that's how we got to where we are today, with buffer overflows, zombies, and blue screens of death, papered over with a layer of inefficient interpreters. Fortunately the hardware people have held up their end and made it possible to live with this, but we on the software side should have the understanding and grace to be embarassed by it.
Somewhere, a bunch of programmers are busily recompiling x86 code for PowerPC and looking for endian problems. It's a routine headache. Remember, the original Xbox is quite vanilla; it's basically a PC with an NVidia graphics processor running a stripped-down Windows 2000. In fact, most Xbox games can be run on PCs with the development environment (usually VC++), if you have the tools and files to build the game. (No, fanboys, that doesn't mean you can run the retail game on your PC.)
I wonder if the porting job is being done in the US or in some low-wage country.
Right now, we're mostly at 8 bits of data per color channel. This upgrade supports 10, 12, and 16 bits of color per channel, or 24, 30, 36 and 48 bits per pixel.
This will be a big help in reducing banding on smooth gradients and artifacts during fades. Actually, you don't get more colors; you get more luminance range. It would probably work just as well to have 16 bits of luminance and two other color difference channels of 8 bits, but the HDMI people went uncompressed.
Now the compression people have to go to work and deal with the issues of when it's worthwhile to send that much data and when it isn't.
At that price, of course it's ahead of the $400 product.
Silicon Valley ceased being an engine of significant economic growth after the dotcom bust. It is unlikely to return to its former glory.
I'm writing this from within walking distance of downtown Palo Alto, and I tend to agree. It's really discouraging. Five years after the dot-com crash, there are still empty industrial parks for lease. The big reseach centers are gone. Xerox PARC is gone. Interval Research is gone. IBM Almaden Research is emptying out. DEC SRL and DEC WRL are gone. HP's real business today is printer ink. Intel is still around, but the new fabs aren't here, and they seem to be out of ideas anyway.
Most growth seems to be in companies that deliver advertising - Google, A9, and their ilk. Startups tend to be "me-too" operations scrabbling for market share in crowded markets.
Yet there's so much to be done. How about producing a personal computer that just doesn't break? Something with hardware and software immune to attack. Satisfaction guaranteed or your money back. Or electric cars with serious range. Or safe nuclear power plants. But that's not what people are working on.
The next DARPA Grand Challenge requires operating in congested areas, and that's going to require serious work on robot vehicle safety. The way this is going, those things are going to be rolling through small towns in hostile territory in a few years, and they'd better not be running over little kids.
Letting the vendor have a backdoor into your machine is really risky. If you're in a financial institution, is the vendor bonded? If you're a healthcare provider, is the vendor HIPPA compliant? If you're in a law firm, are any of your clients competitors of Microsoft? You have no contractual guarantee that somebody at Microsoft, or elsewhere, isn't using that backdoor in some interesting way.