There are already plenty of ways to put "3D on the Web".
Shockwave. Like Flash, but has a full 3D engine. Some versions even had the Havok physics engine. Never became as popular as Flash, but there are some good casual games in it.
VRML. It works now. In 1997, few PCs had enough graphics hardware to run VRML well. Now they do. Nobody uses it any more, but it wasn't a bad idea. It was just too early.
X3D, or "Web3D". This is simply VRML in XML syntax. The XML crowd took over VRML and tried to turn it into a spinning-logo system. Nobody uses this, and the transition killed VRML.
Java 3D. (Well, Sun screwed that up, but it can still be run.)
SolidWorks Viewer. Like Adobe Acrobat for engineers. Making a model requires expensive SolidWorks, but the 3D viewer is free. Widely used by people who make real stuff.
True "eventually consistent" systems are quite difficult in general. Game designers struggle with this. A typical example is a distributed game in which A shoots at B. A's client knows where B was at the last update, but due to lag, is behind on knowing where the (authoritative) server says B is now. A's client has to decide whether A's shot at B hit B.
A typical trick is that A's client projects B's current position assuming B's user doesn't input a direction change, and computes a hit or miss on that basis in the client. The actions of A are also forwarded to the server, which makes the official decision on whether A's shot hit B, and that information is sent back to the clients of A and B, after transmission delay.
The trick is making the visuals work for this. One way to hide the problem is that when A's client computes that A's shot hit B, B is displayed as hit and staggering, but not falling. This buys time until the server update comes in to A's client. If the server says it was a hit, B is displayed in A's client falling down. If the server says it was a miss, B is displayed as A's client as staggering and recovering. This is an illusion created for user A to hide the lag.
Meanwhile, in B's client, B doesn't stagger at all if there's a miss, because, by the time B's client hears about the shot from the server, the hit/miss decision is known. So user A and user B see different things during the lag period, but come back into sync after the update.
Randy Farmer and Chip Morningstar invented this back in the 1980s for Lucasfilm's "Habitat", and called it "surreal time".
Web-based "eventually consistent" systems are usually much dumber than this. Most are more like "becomes consistent after the user manually reloads the page a few times". Distributed cache consistency can be done efficiently (every shared memory multiprocessor CPU does it), but modern cache interlocking technology never seems to have made it to web caches. There really should be little cache-invalidation messages pushed around between the servers in a big web farm, but there usually aren't.
If this attack is combined with some PC-based worm, it will be much more effective.
Routers that are vulnerable from the WAN side can be attacked by zombie PCs. The router can then be reprogrammed to try to attack anything that attaches on the WAN side, bypassing any firewalls in the router. The attack on the PC, of course, includes the code that attacks routers.
We need more devices that boot from a true read-only medium. Yes, upgrading is a pain, but most devices never get upgraded anyway. At least then they'd be stable.
One of the big reasons high-tech has been so successful in California is the provision in the California Labor Code that prohibits employers from owning what you do on your own time.
No employment contract in California can override that. So you can do a startup while still
employed.
Employers hate this, but it's one of the big reasons for Silicon Valley's success. It also boosts innovation in aerospace and Hollywood, both major California industries.
A utility statement, from Southern California Edison:
Application of Common Criteria was considered but deemed impractical to formally apply due to schedule. Much of SCE's process is borrowed from the Common Criteria. Choosing robustness levels. Graduated sense of robustness. Not requiring vendors to take to someone for certification.
In other words, no outside validation of security, and no compliance with even the minimal Common Criteria standards.
I hadn't been aware that "remote disconnect" was being incorporated into electric meters. Read this industry analysis of remote disconnect" for background. The "risk items" list doesn't even consider the implications of hostile attack.
The purpose of "remote disconnect" is to get more control over customers. Utilities are considering using this to enforce collection, and even for prepaid electric service. It's another way to tighten the screws on poor people, like prepaid cellular and paycheck loans.
There's another feature, current limiting - draw too much current and the power cuts off. The current limit can be set remotely. When someone gets behind on their bill, the power they can use is limited to survival levels until they pay up.
Vulnerabilities in the remote management system could be a serious problem. Will the keys be kept in a Microsoft system? If you thought it was bad when credit card numbers were stolen, what happens when someone steals the meter key database? The meters have to be physically visited, one at a time, to reset the keys. And who would do that? The meter readers get laid off when this goes in.
It's surprising, almost amazing, that the US even tries to run subs through the Straits of Hormuz.
Look at the shipping lane map. That's one of the world's busiest shipping lanes (half the world's supertankers go through there), it's shallow, there are narrow spots and islands, there's a sharp turn at the narrowest spot. and there's no organized traffic control.
The real question is whether the US should be running subs through there at all. It might be worth it in wartime, but unless the sub had a job to do in the Persian Gulf, questions will be asked about the policy of doing this.
The sub driver will lose his command, of course.
This is the boat's second accident; the previous one was a grounding due to a navigational error. The ship's motto, "Damn the torpedoes, full speed ahead", may need changing.
First, the "April 1" date isn't when some attack starts. The worm's authors can do that at any time, since this thing does downloads over its private P2P network. It's just when the scheme for connecting to control hosts is upgraded.
Second, the complexity of the thing, the breadth of technologies employed, and the rate of updates indicates that it's the product of an organization, not an individual. Someone behind this has money.
Third, there's a $250,000 reward, and no claimants, so the people behind this have the sense to shut up. They're not going to be found boasting on some IRC channel.
Fourth, as usual, most of the vulnerabilities are related to Windows' propensity for "autorunning" anything that looks executable.
From the article:
The new actuators, on the other hand, expand by up to 200 percent but generate small forces per unit area, making them less than ideal for many applications, including robotics.
What is it with these crap materials science articles? We keep seeing articles about some new material with interesting properties, but not good enough to be useful, touted as a major breakthrough expected to show up in products Real Soon Now. This crap keeps showing up in MIT Technology Review and in Science, which used to be respected publications. It's fine to publish the materials-science results, but not with the press-release hype.
The "robot muscle" problem is well known, and many attempts have been made to address it.
There's no good equivalent of biological muscles.
There are several materials that are promising in theory, but not useful in practice. Electrorheological fluids have been tried, but none of them work well enough. Shape-memory alloys used to have a fan club, but they don't change shape by much, and the electrical power inputs are high for the mechanical energy out, because the power is used to heat up the material and cause a phase change.
Robots still use pneumatics, hydraulics, and electric motors, with the occasional magnetic-particle clutch.
There's a known solution to this problem. In the 1980s S&L collapse, the Office of Thrift Supervision established the rule that S&Ls taken over by the Government couldn't sue each other or the Government. It just burned up legal fees, since the money came out of the same pocket. Congress needs to enact something like that this time.
Something strange is going on here. Capital One's main site returns a certificate for the correct domain, but the certificate is invalid.
This isn't a wrong-domain issue; the cert is bad. CN="www.capitalone.com", the dates are valid, the issuer is Verisign, but it won't validate in Firefox. Our own system, SiteTruth, which uses OpenSSL, also indicates it's no good. But neither Firefox nor OpenSSL is producing a useful error message. It looks like this certificate is either corrupted or bogus.
The location ("L") in the cert is Glen Allen, VA. Capital One has a facility in
Glen Allen, according to Google, and it looks like a huge warehouse. So that's probably their data center, at 4871 Cox Rd, Glen Allen, VA - (804) 270-4104.
A traceroute ends at "capitalone-gw.customer.alter.net", which doesn't mean much one way or the other.
Their stock has dropped from 55 to 12 since September 2008. If you have any money in there above the FDIC insurance limits, get it out now..
Often enough, the "big secret" is that the hardware is crippled and the CPU is doing the real work.
Yes. And board manufacturers get really angry when someone detects that.
In the QNX community, where "real time" really means something, there's a common test of the operating system's real-time response. The tester wires up a square wave generator to an input that will cause an interrupt, programs the computer to wait for the interrupt and start a real-time user process, and has the user process turn on an output. You run some program in the background to keep the CPU busy. On a serious real-time OS, this shouldn't hurt real time response, and on QNX, it doesn't. There are no long interrupt lockouts in the QNX microkernel. Drivers are interruptable user processes.
Input and output lines are then wired up to a storage oscilloscope, to display the interrupt response.
On most machines, the scope shows a nice, boring, consistent interrupt response time of a few microseconds. But on some CPU boards, there's a spike way out there from the expected delay period. This shows clearly the occasional huge delay (by real time standards) of hundreds of microseconds, maybe even more than a millisecond. That's because something is going on in System Management Mode. QNX programmers have found USB serial emulation, flash disk IDE emulation, and other crap running at SMM level.
When a vendor gets caught doing this, word gets around in the real-time community that their board is unacceptable for real-time use. Vendors selling embedded system boards have been caught this way.
Hard real time is a world in which stuff is expected to actually work every time.
It would be dreadful to suffer this fierceness and wrath of Almighty God one moment; but you must suffer it to all eternity. There will be no end to this exquisite horrible misery. When you look forward, you shall see a long for ever, a boundless duration before you, which will swallow up your thoughts, and amaze your soul; and you will absolutely despair of ever having any deliverance, any end, any mitigation, any rest at all. You will know certainly that you must wear out long ages, millions of millions of ages, in wrestling and conflicting with this almighty merciless vengeance; and then when you have so done, when so many ages have actually been spent by you in this manner, you will know that all is but a point to what remains.
-- "Sinners in the Hands of an Angry God", Jonathan Edwards, 1741.
That particular game programmer happens to have worked on games where perfect execution is possible. In chess, "execution" is moving the pieces; in poker, it's moving the cards. The game engine is expected to perform those operations perfectly. There's no "friction" (in the sense that Clausewitz used the term) in such games.
That's not true of a combat game. Weapons have finite accuracy, as do humans; sometimes there will be a miss even if the shooter, human or AI, did everything right. Weapons can jam (America's Army simulates this.) Running characters don't necessarily follow their planned path; bumps on the ground and slippery spots can interfere. The AI has to face those limitations, too.
Of course, if you make it too real, some kinds of games are unplayable. You can't really drive a car very well with a game pad or joystick. (Watch people driving R/C cars that way. They crash every few minutes.) In most console driving games, the CG of the vehicle is below the ground, to make the thing unreasonable stable.
In my ragdoll-physics days, we'd made enough progress that a two-person martial-arts fighting game with real physics looked feasible. Then we realized it would be unplayable. "Your throw failed because your left foot was out of position. Further to the left. Again!" "Yes, sensi." Real physics in a fighting game would make gaming feel like a bad day at the dojo, although without the bruises. Most of your moves wouldn't work. A game with a learning curve like real martial arts, where you train a few times a week for a few years before you're any good, would never sell.
Microsoft bought TellMe (1-800-555-TELL), which does some of that. (Call it from a cell phone; the behavior on land lines is entirely different. From a cell phone, you can get movie listings, driving directions, etc.; on a land line, all it does is phone directories.)
There were times when they were the only ones who could solve a problem that could have cost the company millions of dollars. Of course, most of those times were the result of code they designed or influenced in the first place.
That's not one of the "great developers". That's a con man. Obnoxiousness when challenged is typical con man behavior. It's a manipulation tool.
In a long career, I've met many of the "great developers"; including many big names that are in the textbooks, and dozens of others at the top of the field. None of them act like assholes. I'm talking about MIT/Stanford/CMU/Apple/Sony/IBM Research people. Some can be difficult to deal with, and a few have real trouble explaining their work because they get too wrapped up in their own theoretical niche. Some of them don't suffer fools gladly. But none of them are jerks.
One problem is the "middle class", according to the Wall Street Journal, now starts at around $250K/yr. Few people will ever make that much money. But most college graduates think they will, or at least did until Q4 2008. There's been an upward creep in expectations during the boom. This happens during booms; it happened in 1922-1929. It's not an age thing; it's a boom thing.
The extreme form of this is seen in MBA students. The major MBA schools had (definitely "had") become feeder teams for consulting firms and Wall Street, which, for a while, really was seen as a path to becoming a multimillionaire before turning 30.. In New York City, finance employs 10% of the people, but pays 40% of the salaries. (Well, it did; those are 2007 numbers.)
Being in the robotics field, I saw the better robotics people going off to finance. But recently, I was over at Stanford, and was chatting with a grad student who'd been at Lehman Bros. and was back in computer science, which now looked more stable than finance. The traffic direction has reversed.
We might even see smart people going into manufacturing again. Which we need.
There have been some attempts at contactless fingerprint readers for access control. The idea is to read from a distance of 1cm or so, rather than with the finger pressed up against the glass. This prevents dirt on the glass from messing up the image. In the 1990s, contactless devices were too expensive or too complicated. Now, they're probably feasible.
It helps to be funded to give it away. "Web browsers" came from CERN and the National Center for Atmospheric Research, both tax-funded organizations. The competition wasn't subsidized.
There was Xanadu from Ted Nelson and Autodesk; that suffered from Nelson's fascination with micropayments. There were proprietary graphical clients, like AOL, but that had to be a closed world to make money. There were some big commercial services, like Nexis, Lexis, Mead Data Central, and Western Union InfoMaster, all closed pay systems.
At least five other "hypertext" systems preceded the Web. Intermedia, in the 1980s, was one of the better ones, but it was tied to Apple's version of UNIX (A/UX), which was a turkey later discontinued by Apple.
The early systems needed expensive hardware; that was the main problem.
Somebody would have done this once the hardware got cheap enough.
Read Singer's Wired for War. That's about military robots, and covers some of the issues that arise as the computers start taking over weapons.
Pilots of remotely piloted vehicles occupy a strange place in the Air Force. Most of them are based in the US, controlling vehicles in Iraq. They're stuck in a fighter-jock culture. The RPV pilots, though, are the ones doing damage to the enemy. They're flying combat missions. The fighter jocks are mostly zooming around, but don't have anything to shoot at.
There's a messy command authority problem with RPV pilots. Do they belong to the base commander where they're physically located? The unit that launches the aircraft, often far from the combat zone? Or the unit that's actually in the combat zone?
Then there's the problem of who flies the things. The USAF used to task fighter pilots to fly RPVs. They hated it. Worse, it turned out enlisted men trained to operate RPVs did at least as well as the fighter jocks. The USAF is facing the possibility that the fighter jocks may become irrelevant.
It's happened before, with aircraft carriers. The U.S. Navy, until early in WWII, was dominated by the "battleship admirals". There was heavy opposition to aircraft carriers. Congress finally stepped in and, over Navy objections, made it law that the captain of an aircraft carrier must be an aviator. Today, the battleships are history, and the Navy is dominated by aircraft carrier types.
Bypassing the layers of blogs, here's the actual paper. But it costs $32 to read more than the abstract.
This is an application of superparamagnetism. Paramagnetism is ordinarily a weak phenomenon, but there are some new materials for which this effect is much stronger.
It's too early to tell if this is useful. Right now, it's in the category of "minor development in materials science overpromoted as a major breakthrough". It might turn out to have some relevance to MRI imaging or disk drives, both of which rely on fine-scale magnetic effects.
All the Microsoft "FAT patents" still in force have to do with the horrible hack used to support both long and DOS-type "short" ("XXXXXXXX.XXX") filenames. Nobody uses "short" filenames any more, and under UNIX/Linux, there's not even an API to talk about short filenames. So make an implementation that's long-filename only. You give up backwards compatability with DOS and Windows 3.1. Big deal.
Slashdot Mirror
There are already plenty of ways to put "3D on the Web".
True "eventually consistent" systems are quite difficult in general. Game designers struggle with this. A typical example is a distributed game in which A shoots at B. A's client knows where B was at the last update, but due to lag, is behind on knowing where the (authoritative) server says B is now. A's client has to decide whether A's shot at B hit B.
A typical trick is that A's client projects B's current position assuming B's user doesn't input a direction change, and computes a hit or miss on that basis in the client. The actions of A are also forwarded to the server, which makes the official decision on whether A's shot hit B, and that information is sent back to the clients of A and B, after transmission delay.
The trick is making the visuals work for this. One way to hide the problem is that when A's client computes that A's shot hit B, B is displayed as hit and staggering, but not falling. This buys time until the server update comes in to A's client. If the server says it was a hit, B is displayed in A's client falling down. If the server says it was a miss, B is displayed as A's client as staggering and recovering. This is an illusion created for user A to hide the lag.
Meanwhile, in B's client, B doesn't stagger at all if there's a miss, because, by the time B's client hears about the shot from the server, the hit/miss decision is known. So user A and user B see different things during the lag period, but come back into sync after the update.
Randy Farmer and Chip Morningstar invented this back in the 1980s for Lucasfilm's "Habitat", and called it "surreal time".
Web-based "eventually consistent" systems are usually much dumber than this. Most are more like "becomes consistent after the user manually reloads the page a few times". Distributed cache consistency can be done efficiently (every shared memory multiprocessor CPU does it), but modern cache interlocking technology never seems to have made it to web caches. There really should be little cache-invalidation messages pushed around between the servers in a big web farm, but there usually aren't.
If this attack is combined with some PC-based worm, it will be much more effective. Routers that are vulnerable from the WAN side can be attacked by zombie PCs. The router can then be reprogrammed to try to attack anything that attaches on the WAN side, bypassing any firewalls in the router. The attack on the PC, of course, includes the code that attacks routers.
We need more devices that boot from a true read-only medium. Yes, upgrading is a pain, but most devices never get upgraded anyway. At least then they'd be stable.
One of the big reasons high-tech has been so successful in California is the provision in the California Labor Code that prohibits employers from owning what you do on your own time. No employment contract in California can override that. So you can do a startup while still employed.
Employers hate this, but it's one of the big reasons for Silicon Valley's success. It also boosts innovation in aerospace and Hollywood, both major California industries.
More on "remote disconnect":
A utility statement, from Southern California Edison: Application of Common Criteria was considered but deemed impractical to formally apply due to schedule. Much of SCE's process is borrowed from the Common Criteria. Choosing robustness levels. Graduated sense of robustness. Not requiring vendors to take to someone for certification.
In other words, no outside validation of security, and no compliance with even the minimal Common Criteria standards.
We just discovered that electric meters now come with not only remote reading, but "remote disconnect".
There will be pressure to put that into humans. Anybody who gets out of line could be "remotely disconnected".
I hadn't been aware that "remote disconnect" was being incorporated into electric meters. Read this industry analysis of remote disconnect" for background. The "risk items" list doesn't even consider the implications of hostile attack.
The purpose of "remote disconnect" is to get more control over customers. Utilities are considering using this to enforce collection, and even for prepaid electric service. It's another way to tighten the screws on poor people, like prepaid cellular and paycheck loans.
There's another feature, current limiting - draw too much current and the power cuts off. The current limit can be set remotely. When someone gets behind on their bill, the power they can use is limited to survival levels until they pay up.
Vulnerabilities in the remote management system could be a serious problem. Will the keys be kept in a Microsoft system? If you thought it was bad when credit card numbers were stolen, what happens when someone steals the meter key database? The meters have to be physically visited, one at a time, to reset the keys. And who would do that? The meter readers get laid off when this goes in.
It's surprising, almost amazing, that the US even tries to run subs through the Straits of Hormuz. Look at the shipping lane map. That's one of the world's busiest shipping lanes (half the world's supertankers go through there), it's shallow, there are narrow spots and islands, there's a sharp turn at the narrowest spot. and there's no organized traffic control.
The real question is whether the US should be running subs through there at all. It might be worth it in wartime, but unless the sub had a job to do in the Persian Gulf, questions will be asked about the policy of doing this.
The sub driver will lose his command, of course.
This is the boat's second accident; the previous one was a grounding due to a navigational error. The ship's motto, "Damn the torpedoes, full speed ahead", may need changing.
The basic problem is that the price point for a computer is now $299. Apple can get away with some brand premium, but not $500 any more.
This won't kill Apple. Their volume products, the iPhone and the various iPods, are down into that price region already.
Also, the era of "bling" is so over. Walk into any jewelry store today. It will be empty of customers. (Or, quite possibly, an empty storefront.)
First, the "April 1" date isn't when some attack starts. The worm's authors can do that at any time, since this thing does downloads over its private P2P network. It's just when the scheme for connecting to control hosts is upgraded.
Second, the complexity of the thing, the breadth of technologies employed, and the rate of updates indicates that it's the product of an organization, not an individual. Someone behind this has money.
Third, there's a $250,000 reward, and no claimants, so the people behind this have the sense to shut up. They're not going to be found boasting on some IRC channel.
Fourth, as usual, most of the vulnerabilities are related to Windows' propensity for "autorunning" anything that looks executable.
From the article: The new actuators, on the other hand, expand by up to 200 percent but generate small forces per unit area, making them less than ideal for many applications, including robotics.
What is it with these crap materials science articles? We keep seeing articles about some new material with interesting properties, but not good enough to be useful, touted as a major breakthrough expected to show up in products Real Soon Now. This crap keeps showing up in MIT Technology Review and in Science, which used to be respected publications. It's fine to publish the materials-science results, but not with the press-release hype.
The "robot muscle" problem is well known, and many attempts have been made to address it. There's no good equivalent of biological muscles. There are several materials that are promising in theory, but not useful in practice. Electrorheological fluids have been tried, but none of them work well enough. Shape-memory alloys used to have a fan club, but they don't change shape by much, and the electrical power inputs are high for the mechanical energy out, because the power is used to heat up the material and cause a phase change.
Robots still use pneumatics, hydraulics, and electric motors, with the occasional magnetic-particle clutch.
There's a known solution to this problem. In the 1980s S&L collapse, the Office of Thrift Supervision established the rule that S&Ls taken over by the Government couldn't sue each other or the Government. It just burned up legal fees, since the money came out of the same pocket. Congress needs to enact something like that this time.
Something strange is going on here. Capital One's main site returns a certificate for the correct domain, but the certificate is invalid. This isn't a wrong-domain issue; the cert is bad. CN="www.capitalone.com", the dates are valid, the issuer is Verisign, but it won't validate in Firefox. Our own system, SiteTruth, which uses OpenSSL, also indicates it's no good. But neither Firefox nor OpenSSL is producing a useful error message. It looks like this certificate is either corrupted or bogus.
The location ("L") in the cert is Glen Allen, VA. Capital One has a facility in Glen Allen, according to Google, and it looks like a huge warehouse. So that's probably their data center, at 4871 Cox Rd, Glen Allen, VA - (804) 270-4104.
A traceroute ends at "capitalone-gw.customer.alter.net", which doesn't mean much one way or the other.
Their stock has dropped from 55 to 12 since September 2008. If you have any money in there above the FDIC insurance limits, get it out now..
Often enough, the "big secret" is that the hardware is crippled and the CPU is doing the real work.
Yes. And board manufacturers get really angry when someone detects that.
In the QNX community, where "real time" really means something, there's a common test of the operating system's real-time response. The tester wires up a square wave generator to an input that will cause an interrupt, programs the computer to wait for the interrupt and start a real-time user process, and has the user process turn on an output. You run some program in the background to keep the CPU busy. On a serious real-time OS, this shouldn't hurt real time response, and on QNX, it doesn't. There are no long interrupt lockouts in the QNX microkernel. Drivers are interruptable user processes.
Input and output lines are then wired up to a storage oscilloscope, to display the interrupt response. On most machines, the scope shows a nice, boring, consistent interrupt response time of a few microseconds. But on some CPU boards, there's a spike way out there from the expected delay period. This shows clearly the occasional huge delay (by real time standards) of hundreds of microseconds, maybe even more than a millisecond. That's because something is going on in System Management Mode. QNX programmers have found USB serial emulation, flash disk IDE emulation, and other crap running at SMM level.
When a vendor gets caught doing this, word gets around in the real-time community that their board is unacceptable for real-time use. Vendors selling embedded system boards have been caught this way.
Hard real time is a world in which stuff is expected to actually work every time.
It would be dreadful to suffer this fierceness and wrath of Almighty God one moment; but you must suffer it to all eternity. There will be no end to this exquisite horrible misery. When you look forward, you shall see a long for ever, a boundless duration before you, which will swallow up your thoughts, and amaze your soul; and you will absolutely despair of ever having any deliverance, any end, any mitigation, any rest at all. You will know certainly that you must wear out long ages, millions of millions of ages, in wrestling and conflicting with this almighty merciless vengeance; and then when you have so done, when so many ages have actually been spent by you in this manner, you will know that all is but a point to what remains. -- "Sinners in the Hands of an Angry God", Jonathan Edwards, 1741.
That particular game programmer happens to have worked on games where perfect execution is possible. In chess, "execution" is moving the pieces; in poker, it's moving the cards. The game engine is expected to perform those operations perfectly. There's no "friction" (in the sense that Clausewitz used the term) in such games.
That's not true of a combat game. Weapons have finite accuracy, as do humans; sometimes there will be a miss even if the shooter, human or AI, did everything right. Weapons can jam (America's Army simulates this.) Running characters don't necessarily follow their planned path; bumps on the ground and slippery spots can interfere. The AI has to face those limitations, too.
Of course, if you make it too real, some kinds of games are unplayable. You can't really drive a car very well with a game pad or joystick. (Watch people driving R/C cars that way. They crash every few minutes.) In most console driving games, the CG of the vehicle is below the ground, to make the thing unreasonable stable.
In my ragdoll-physics days, we'd made enough progress that a two-person martial-arts fighting game with real physics looked feasible. Then we realized it would be unplayable. "Your throw failed because your left foot was out of position. Further to the left. Again!" "Yes, sensi." Real physics in a fighting game would make gaming feel like a bad day at the dojo, although without the bruises. Most of your moves wouldn't work. A game with a learning curve like real martial arts, where you train a few times a week for a few years before you're any good, would never sell.
Microsoft bought TellMe (1-800-555-TELL), which does some of that. (Call it from a cell phone; the behavior on land lines is entirely different. From a cell phone, you can get movie listings, driving directions, etc.; on a land line, all it does is phone directories.)
Mod parent up. That's the big weakness of digital cameras today - not enough dynamic range.
Whatever happened to Fuji's dual-pixel system, with a big cell and a small cell at each pixel location? That was back in 2003.
There were times when they were the only ones who could solve a problem that could have cost the company millions of dollars. Of course, most of those times were the result of code they designed or influenced in the first place.
That's not one of the "great developers". That's a con man. Obnoxiousness when challenged is typical con man behavior. It's a manipulation tool.
In a long career, I've met many of the "great developers"; including many big names that are in the textbooks, and dozens of others at the top of the field. None of them act like assholes. I'm talking about MIT/Stanford/CMU/Apple/Sony/IBM Research people. Some can be difficult to deal with, and a few have real trouble explaining their work because they get too wrapped up in their own theoretical niche. Some of them don't suffer fools gladly. But none of them are jerks.
One problem is the "middle class", according to the Wall Street Journal, now starts at around $250K/yr. Few people will ever make that much money. But most college graduates think they will, or at least did until Q4 2008. There's been an upward creep in expectations during the boom. This happens during booms; it happened in 1922-1929. It's not an age thing; it's a boom thing.
The extreme form of this is seen in MBA students. The major MBA schools had (definitely "had") become feeder teams for consulting firms and Wall Street, which, for a while, really was seen as a path to becoming a multimillionaire before turning 30.. In New York City, finance employs 10% of the people, but pays 40% of the salaries. (Well, it did; those are 2007 numbers.)
Being in the robotics field, I saw the better robotics people going off to finance. But recently, I was over at Stanford, and was chatting with a grad student who'd been at Lehman Bros. and was back in computer science, which now looked more stable than finance. The traffic direction has reversed.
We might even see smart people going into manufacturing again. Which we need.
There have been some attempts at contactless fingerprint readers for access control. The idea is to read from a distance of 1cm or so, rather than with the finger pressed up against the glass. This prevents dirt on the glass from messing up the image. In the 1990s, contactless devices were too expensive or too complicated. Now, they're probably feasible.
It helps to be funded to give it away. "Web browsers" came from CERN and the National Center for Atmospheric Research, both tax-funded organizations. The competition wasn't subsidized. There was Xanadu from Ted Nelson and Autodesk; that suffered from Nelson's fascination with micropayments. There were proprietary graphical clients, like AOL, but that had to be a closed world to make money. There were some big commercial services, like Nexis, Lexis, Mead Data Central, and Western Union InfoMaster, all closed pay systems.
At least five other "hypertext" systems preceded the Web. Intermedia, in the 1980s, was one of the better ones, but it was tied to Apple's version of UNIX (A/UX), which was a turkey later discontinued by Apple.
The early systems needed expensive hardware; that was the main problem. Somebody would have done this once the hardware got cheap enough.
Read Singer's Wired for War. That's about military robots, and covers some of the issues that arise as the computers start taking over weapons.
Pilots of remotely piloted vehicles occupy a strange place in the Air Force. Most of them are based in the US, controlling vehicles in Iraq. They're stuck in a fighter-jock culture. The RPV pilots, though, are the ones doing damage to the enemy. They're flying combat missions. The fighter jocks are mostly zooming around, but don't have anything to shoot at.
There's a messy command authority problem with RPV pilots. Do they belong to the base commander where they're physically located? The unit that launches the aircraft, often far from the combat zone? Or the unit that's actually in the combat zone?
Then there's the problem of who flies the things. The USAF used to task fighter pilots to fly RPVs. They hated it. Worse, it turned out enlisted men trained to operate RPVs did at least as well as the fighter jocks. The USAF is facing the possibility that the fighter jocks may become irrelevant.
It's happened before, with aircraft carriers. The U.S. Navy, until early in WWII, was dominated by the "battleship admirals". There was heavy opposition to aircraft carriers. Congress finally stepped in and, over Navy objections, made it law that the captain of an aircraft carrier must be an aviator. Today, the battleships are history, and the Navy is dominated by aircraft carrier types.
Bypassing the layers of blogs, here's the actual paper. But it costs $32 to read more than the abstract.
This is an application of superparamagnetism. Paramagnetism is ordinarily a weak phenomenon, but there are some new materials for which this effect is much stronger.
It's too early to tell if this is useful. Right now, it's in the category of "minor development in materials science overpromoted as a major breakthrough". It might turn out to have some relevance to MRI imaging or disk drives, both of which rely on fine-scale magnetic effects.
All the Microsoft "FAT patents" still in force have to do with the horrible hack used to support both long and DOS-type "short" ("XXXXXXXX.XXX") filenames. Nobody uses "short" filenames any more, and under UNIX/Linux, there's not even an API to talk about short filenames. So make an implementation that's long-filename only. You give up backwards compatability with DOS and Windows 3.1. Big deal.