That's a routine sale of unregistered securities case. If he'd sold them for dollars or yen, the SEC would have done the same thing. Bitcoin is irrelevant here.
C is that way because it had to interface to HARDWARE that doesn't know anything about size limitations.
That's what programming languages are for - to allow better abstractions than the hardware provides. That's what higher level languages are for. At the assembly code level, few assemblers know about array size, but C is not an assembly language. C knows about loops, and scope, which the hardware does not. This allows optimization of checks, which can often be hoisted out of a loop. (For non-compiler people, "hoisting" means moving a computation upwards in code, so that it's done earlier, preferably once per loop instead of once per iteration. Most optimizing compilers do some hoisting.)
And EVERY language you use has to interface at some point where "size" limitations are unknown.
To what? Even when you go to an I/O device, you're usually telling a DMA controller what the size of the buffer is.
And if the hardware (ie, the CPU) has such instructions (like the VAX did) you then bump into the problem of lack of portability... And the CPU is then so constrained that it can't evolve either... (also a VAX problem - it had so many things bound to a 32 bit address that it couldn't go to 64 bits, and remain a VAX).
The VAX had integer overflow checking, which wasn't used much. I once rebuilt the UNIX command line tools on a VAX with the entry masks for functions set to raise a hardware exception on overflow. About half of the tools broke. The VAX machines were heavily microcoded, with explicitly sequential semantics within instructions. As a result, some of the fancier instructions were unreasonably slow. DEC had a terrible problem making VAX machines go faster. Then they went in the other direction with the Alpha, which was a very basic RISC machine. That went fast, but never caught on. All of this is irrelevant to modern computing.
No, it's a backwards compatibility issue. There's all that C code out there, sort of working. It's not an overhead issue. Most subscript checks in inner loops can be hoisted to the top of the loop and optimized out. For FOR loops, this is almost a no-brainer inside a compiler. The Go compiler, which checks subscripts, does that.
There are three big memory issues in C: "How big is it","Who deletes it", and "Who locks it?". The language helps with none of those. "How big is it" problems lead to buffer overflows and security holes. "Who deletes it" leads to memory leaks, and occasionally use after deletion. "Who locks it" leads to race conditions. Of these problems, "How big is it" cause the most security trouble.
C is especially bad because the language doesn't even have a way to talk about the size of an array. When you pass an array to a function, all size info is lost. This sucks.
C is this way because the compiler had to be crammed in a machine with an address space of 128KB, the PDP-11. We have more memory now.
I first wrote C in 1978. We should be past this mess by now.
This is C code, the only major language that doesn't know how big its arrays are. After 30 years of buffer overflow bugs, you'd thing we'd have something better now for low-level programming. The higher level stuff, where you can use garbage collection, is in good shape, with Java, C#, Python, etc. resistant to buffer overflow problems. C and C++, though, are still broken. C++ tries to paper over the problem with templates, but the mold (raw pointers) keeps seeping through the wallpaper.
If you mean [some generic security risk] then perhaps you should read up about what C was designed to do - and it wasn't to hand hold novice coders. It was for people who had a clue who needed to write to-the-metal code and drivers for operating systems and it still excels at that task.
Here's today's buffer overflow story. C strikes out again. The "I'm so good I don't need subscript checking" crowd of programmers is the problem, not the solution. Low level languages don't have to be as bad as C. (It's sad that Modula died with DEC. We were, briefly, on a path to reliable code.)
This is just someone who wants attention. Guns with plastic barrels are junk, worse even than low-end Saturday Night Specials. You can get a cheap gun for under $100 in the US. (Yes, the Raven is a crappy gun, but it's still better than anything made on an extruder-type 3D printer.)
This is not the cutting edge of weapons design. Guns with aimbots. are the cutting edge. Right now, they're expensive, around $10K, but they will get cheaper.
Swift uses string interpolation to include the name of a constant or variable as a placeholder in a longer string, and to prompt Swift to replace it with the current value of that constant or variable. Wrap the name in parentheses and escape it with a backslash before the opening parenthesis:
println("The current value of friendlyWelcome is \(friendlyWelcome)") // prints "The current value of friendlyWelcome is Bonjour!"
I hope they locked that feature down to constant strings.
What could possibly go wrong with a language feature which lets you access arbitrary variables by name at run time by string interpolation?
(Hey, let's use an email address of "\(SitePrivateEncryptionKey)" and see what happens!)
Kind of a "meh" series of announcements. The Mac interface will look more like the phone interface. (How'd that work out for Microsoft?) FTP that goes through Apple's servers. A new GUI theme. Some other routine GUI churn. A medical interface app with sensors. That's it?
Last week, Apple execs were promising big announcements, the biggest since the Jobs era. This is all they've got? From the hype, you'd expect a competitor for Google Glass, or a VR system, or a rugged phone with no connectors and inductive charging, or an AI system that runs your life, or NSA-proof security, or something really new, like a direct brain interface or displays in contact lenses.
Iridum turned out to be a huge success, but not for the expected reason. The U.S. Government bought into it, buying half the capacity, just in time for the wars in Iraq and Afghanistan. DoD and the State Department have lots of people in the middle of nowhere who need to communicate, and Iridium does the job for them. Most ships of any size have an Iridium phone or two on board.
Iridium airtime is now around $1/minute. U.S. Government usage is now under 25% of use, and the number of users is slowly increasing. There's an SMS message capability, and lots of devices in remote areas report in using it. Messages cost about $1/KB, which, considering some US carriers were charging $0.20 per SMS message, isn't bad.
Lots of little shared-use autonomous pod cars running around? That's a PRT, a Personal Rapid Transit system. The idea has been around for decades, and a few prototype vehicles have been built. Older designs were rail based. Later designs used guideways, but the vehicle had some steering smarts. The latest designs steer themselves, but still use dedicated roads. Nothing much has been deployed, except for a few small systems at airports and fairs.
Mortgages are public records. State and local governments already have all that data. Anyone can look it up. Data companies have already collected it for most parts of the US and use it for marketing.
The Consumer Financial Protection Bureau is only going to have a 1 in 20 sample of the data. That's enough to look for improper activity by lenders. There's a lot of funny stuff going on in the foreclosure area, but nobody has been analysing that as a "big data" problem.
"HD Verified" sounds suspiciously like a way to extract more money out of someone.
NicoNico, the big Japanese video sharing site, already does that. "Premium Members get access to speedy video playback, priority seating for live broadcasts, and more! Seamless video playback even during heavy usage! 540 JPY/month!"
It's a bit late to be charging people extra for 720p, but charging extra for 2160p ("4K video") may be something the industry tries.
This is yet another form of forward error correction. The claim is that it doesn't take any extra data to add forward error correction. That seems doubful, since it would violate Shannon's coding theorem.
This was tested against 3% random packet loss. If you have statistically well behaved packet loss due to noise, FEC works great. If you have bursty packet loss due to congestion, not so great.
Thatâ(TM)s the scenario laid out some 35 years ago by a team of academics and NASA engineers meeting at the University of Santa Clara, in California.
There were still AI people talking this up when I was at Stanford CS in the 1980s. They wanted to have self-replicating robots on the Moon or Mars by 2000. I asked "how soon could you have it working in Arizona?" Some people didn't like that.
It's embarrassing how bad robot manipulation is in unstructured situations. DARPA is trying to fix that by throwing money at the DARPA Humanoid Challenge. But so far, the machines in that are mostly teleoperated. (Ignore the edited videos for popular consumption; look at the split-screen videos that show three views of the machine and one of the operators, who often are using game controllers.)
I'd like to see a robotic system able to do simple parts changes on a car - air filter, fuel filter, spark plugs, etc., removing and replacing any covers and cables needed to do the job.
This article seems to be a reaction to
Elliot Roger's autobiography and rant. The autobiography is not that of a "nerd". This guy had no tech skills. He played World of Warcraft too much; that's about it.
What seems to have driven him nuts is growing up in Malibu and UCSB, two of the greatest concentrations of hot women on the planet, and not getting any.
This is a fascinating result. The previous assumption was that neural nets generated stable "generalizations", or settled into a state where the correctly classified cases were not near the "edge" of a transition to a different result. That appears to be incorrect. The training process apparently settles near edges, making it vulnerable to small differences. As the author points out, in high-dimensional spaces, most of the volume is near edges.
This probably isn't an overfitting problem. The researchers say they sized their nets appropriately. (If you make an oversized neural net, one big enough to hold all the cases in its state, and train it, you just get a lookup table. There's no generalization. Same problem as curve-fitting with a curve with as many parameters as data points.)
Neural nets are such a black box. Theory of what's going on in there is currently unsatisfactory. The more statistics-based forms of machine learning are on firmer theoretical ground.
Agreed. Making an CNC positioner work is a solved problem. There are botched positioner designs in the 3D printer world that fail, but that's because of bad engineering. It's an easy positioner problem - the load doesn't vary much. If a stepper is missing steps, you probably did something very wrong. Like using the crap Arduino stepper board from Adafruit, which uses a chip intended for LED dimming.
When I saw the article title, I thought that perhaps someone had closed loop thermal control of the extrusion process. No such luck. The real problems with extrusion-type 3D printers are where the extruded material is welded to the previously deposited material. This is welding a hot thing to a cold thing, which usually fails. On top of that, standard ABS has a high coefficient of expansion, and shrinks when it cools. This is why many 3D printer jobs crack about 1-2 inches from the heated build platform.
Extruder type 3D printers need temperature control over not just the extruder, but chamber air temperature and the temperature of the spot being welded to. There are commercial plastic welders which aim a hot air jet at the spot about to be welded, in addition to heating and extruding the plastic welding rod. 3D printers need something like that. Maybe a laser (a 10W diode should do it) aimed at the join point.
3D printer designers should quit futzing with the positioner design and focus on exactly what's happening at the weld point.
Mod parent up. This is from a group of osteopaths. Here's what Wikpedia has to say about osteopathy:
(Osteopaths) believe that their treatments, which primarily consist of moving, stretching and massaging a personâ(TM)s muscles and joints, help allow the body to heal itself.
As with all forms of complementary and alternative medicine, the practice of osteopathy does not always adhere to evidence-based medicine (EBM). There are few high-quality research studies demonstrating that osteopathy is effective in treating any medical condition other than lower back pain.[2][3] In the UK, the National Institute for Health and Care Excellence recommends osteopathy for the treatment of persistent lower back pain.[4] However, analysis of peer-reviewed research yields little evidence that osteopathy is effective for non-musculoskeletal conditions, and limited evidence that osteopathy is an effective treatment for some types of neck pain, shoulder pain, or limb pain.
No wonder they're unhappy with Wikipedia.
Now if Cell or JAMA or The New England Journal of Medicine complained about Wikipedia, that would be worthy of note.
You know your iPad/Android devices are already capable of doing that. It's just nobody wants to do that.
Right. There's a long history of "docking stations". They work fine, but nobody wants them. There's also a huge compatibility problem - docking stations are usually very device-specific.
Hacker Dojo in Mountain View (formerly a hacker space, now a co-working space) has tables with LCD monitors, but no computers. People bring in laptops, plug in, and camp. That's about as far as "docking" goes.
Lame article, which points to a blog, which points to another blog, which points to the wrong place on a Russian site, which copied the article from The Daily Mail. The Daily Mail, even though a tabloid, has a halfway decent article.
Laser "gyros", which work by interferometery and have no moving parts, have been around for decades. The best laser gyros still have more drift, by about 2 orders of magnitude, than the best mechanical gyros. Laser gyro technology has hit the limits of what you can do with photons.
The idea here is to do interferometry with coupled atoms, rather than photons. That technology has been slowly improving for a decade or so, and it looks like it's getting close to deployment for high-end applcations.
One of the more interesting possibilities here is chip-scale gyros of moderate precision. Here's a Honewell patent from 2006 for one.
Right. A good example is that in the Android "ice cream sandwich" release, Google deliberately brokeon-phone voice dialing. Now, to get hands-free dialing, you have to use Google's voice search service, which logs everything you do for ad purposes. It also won't work if you have poor data connectivity but good voice connectivity, which is common when driving. Google's voice search service assumes the user is looking at the screen, which defeats the whole point of Bluetooth headsets.
Right. There are wheel-driven land speed records,
currently 470.444 MPH with a turboshaft engine, 462 MPH with a piston engine, 307.666 with an electric motor, and 139.843 MPH with a steam turbine.
The 139.843 MPH steam speed record was set in 2009, by a British team. This is embarassingly low for a custom-built steam turbine powered land speed record car that looks like an aircraft. They brought the car out to the salt flats at Edwards for this.
Yes, Disney issued such a press release in 2009. They're not "sequels" now, they're "spin-offs". Since Catmull and Lasseter took over, they've released
"The Little Mermaid: Ariel's Beginning" (a prequel, not a sequel!)
"Tinker Bell", "Tinker Bell and the Lost Treasure", and "Tinker Bell and the Great Fairy Rescue" ( a spin-off with two sequels) and are working on "Planes: Fire & Rescue" (too early to tell if it's a spin-off or a sequel).
Slashdot Mirror
That's a routine sale of unregistered securities case. If he'd sold them for dollars or yen, the SEC would have done the same thing. Bitcoin is irrelevant here.
C is that way because it had to interface to HARDWARE that doesn't know anything about size limitations.
That's what programming languages are for - to allow better abstractions than the hardware provides. That's what higher level languages are for. At the assembly code level, few assemblers know about array size, but C is not an assembly language. C knows about loops, and scope, which the hardware does not. This allows optimization of checks, which can often be hoisted out of a loop. (For non-compiler people, "hoisting" means moving a computation upwards in code, so that it's done earlier, preferably once per loop instead of once per iteration. Most optimizing compilers do some hoisting.)
And EVERY language you use has to interface at some point where "size" limitations are unknown.
To what? Even when you go to an I/O device, you're usually telling a DMA controller what the size of the buffer is.
And if the hardware (ie, the CPU) has such instructions (like the VAX did) you then bump into the problem of lack of portability... And the CPU is then so constrained that it can't evolve either... (also a VAX problem - it had so many things bound to a 32 bit address that it couldn't go to 64 bits, and remain a VAX).
The VAX had integer overflow checking, which wasn't used much. I once rebuilt the UNIX command line tools on a VAX with the entry masks for functions set to raise a hardware exception on overflow. About half of the tools broke. The VAX machines were heavily microcoded, with explicitly sequential semantics within instructions. As a result, some of the fancier instructions were unreasonably slow. DEC had a terrible problem making VAX machines go faster. Then they went in the other direction with the Alpha, which was a very basic RISC machine. That went fast, but never caught on. All of this is irrelevant to modern computing.
No, it's a backwards compatibility issue. There's all that C code out there, sort of working. It's not an overhead issue. Most subscript checks in inner loops can be hoisted to the top of the loop and optimized out. For FOR loops, this is almost a no-brainer inside a compiler. The Go compiler, which checks subscripts, does that.
There are three big memory issues in C: "How big is it","Who deletes it", and "Who locks it?". The language helps with none of those. "How big is it" problems lead to buffer overflows and security holes. "Who deletes it" leads to memory leaks, and occasionally use after deletion. "Who locks it" leads to race conditions. Of these problems, "How big is it" cause the most security trouble.
C is especially bad because the language doesn't even have a way to talk about the size of an array. When you pass an array to a function, all size info is lost. This sucks.
C is this way because the compiler had to be crammed in a machine with an address space of 128KB, the PDP-11. We have more memory now. I first wrote C in 1978. We should be past this mess by now.
This is C code, the only major language that doesn't know how big its arrays are. After 30 years of buffer overflow bugs, you'd thing we'd have something better now for low-level programming. The higher level stuff, where you can use garbage collection, is in good shape, with Java, C#, Python, etc. resistant to buffer overflow problems. C and C++, though, are still broken. C++ tries to paper over the problem with templates, but the mold (raw pointers) keeps seeping through the wallpaper.
I've tried. Here's my paper on a stricter version of C that's object-compatible with existing C code. It's techncally possible to fix this problem. The political problems are huge.
If you mean [some generic security risk] then perhaps you should read up about what C was designed to do - and it wasn't to hand hold novice coders. It was for people who had a clue who needed to write to-the-metal code and drivers for operating systems and it still excels at that task.
Here's today's buffer overflow story. C strikes out again. The "I'm so good I don't need subscript checking" crowd of programmers is the problem, not the solution. Low level languages don't have to be as bad as C. (It's sad that Modula died with DEC. We were, briefly, on a path to reliable code.)
This is just someone who wants attention. Guns with plastic barrels are junk, worse even than low-end Saturday Night Specials. You can get a cheap gun for under $100 in the US. (Yes, the Raven is a crappy gun, but it's still better than anything made on an extruder-type 3D printer.)
This is not the cutting edge of weapons design. Guns with aimbots. are the cutting edge. Right now, they're expensive, around $10K, but they will get cheaper.
This looks bad:
Swift uses string interpolation to include the name of a constant or variable as a placeholder in a longer string, and to prompt Swift to replace it with the current value of that constant or variable. Wrap the name in parentheses and escape it with a backslash before the opening parenthesis:
// prints "The current value of friendlyWelcome is Bonjour!"
println("The current value of friendlyWelcome is \(friendlyWelcome)")
I hope they locked that feature down to constant strings. What could possibly go wrong with a language feature which lets you access arbitrary variables by name at run time by string interpolation?
(Hey, let's use an email address of "\(SitePrivateEncryptionKey)" and see what happens!)
Kind of a "meh" series of announcements. The Mac interface will look more like the phone interface. (How'd that work out for Microsoft?) FTP that goes through Apple's servers. A new GUI theme. Some other routine GUI churn. A medical interface app with sensors. That's it?
Last week, Apple execs were promising big announcements, the biggest since the Jobs era. This is all they've got? From the hype, you'd expect a competitor for Google Glass, or a VR system, or a rugged phone with no connectors and inductive charging, or an AI system that runs your life, or NSA-proof security, or something really new, like a direct brain interface or displays in contact lenses.
Iridum turned out to be a huge success, but not for the expected reason. The U.S. Government bought into it, buying half the capacity, just in time for the wars in Iraq and Afghanistan. DoD and the State Department have lots of people in the middle of nowhere who need to communicate, and Iridium does the job for them. Most ships of any size have an Iridium phone or two on board.
Iridium airtime is now around $1/minute. U.S. Government usage is now under 25% of use, and the number of users is slowly increasing. There's an SMS message capability, and lots of devices in remote areas report in using it. Messages cost about $1/KB, which, considering some US carriers were charging $0.20 per SMS message, isn't bad.
OK, a 14" phone. Just what we needed.
Lots of little shared-use autonomous pod cars running around? That's a PRT, a Personal Rapid Transit system. The idea has been around for decades, and a few prototype vehicles have been built. Older designs were rail based. Later designs used guideways, but the vehicle had some steering smarts. The latest designs steer themselves, but still use dedicated roads. Nothing much has been deployed, except for a few small systems at airports and fairs.
Mortgages are public records. State and local governments already have all that data. Anyone can look it up. Data companies have already collected it for most parts of the US and use it for marketing.
The Consumer Financial Protection Bureau is only going to have a 1 in 20 sample of the data. That's enough to look for improper activity by lenders. There's a lot of funny stuff going on in the foreclosure area, but nobody has been analysing that as a "big data" problem.
"HD Verified" sounds suspiciously like a way to extract more money out of someone.
NicoNico, the big Japanese video sharing site, already does that. "Premium Members get access to speedy video playback, priority seating for live broadcasts, and more! Seamless video playback even during heavy usage! 540 JPY/month!"
It's a bit late to be charging people extra for 720p, but charging extra for 2160p ("4K video") may be something the industry tries.
This is yet another form of forward error correction. The claim is that it doesn't take any extra data to add forward error correction. That seems doubful, since it would violate Shannon's coding theorem.
This was tested against 3% random packet loss. If you have statistically well behaved packet loss due to noise, FEC works great. If you have bursty packet loss due to congestion, not so great.
From the article:
Thatâ(TM)s the scenario laid out some 35 years ago by a team of academics and NASA engineers meeting at the University of Santa Clara, in California.
There were still AI people talking this up when I was at Stanford CS in the 1980s. They wanted to have self-replicating robots on the Moon or Mars by 2000. I asked "how soon could you have it working in Arizona?" Some people didn't like that.
It's embarrassing how bad robot manipulation is in unstructured situations. DARPA is trying to fix that by throwing money at the DARPA Humanoid Challenge. But so far, the machines in that are mostly teleoperated. (Ignore the edited videos for popular consumption; look at the split-screen videos that show three views of the machine and one of the operators, who often are using game controllers.)
I'd like to see a robotic system able to do simple parts changes on a car - air filter, fuel filter, spark plugs, etc., removing and replacing any covers and cables needed to do the job.
This article seems to be a reaction to Elliot Roger's autobiography and rant. The autobiography is not that of a "nerd". This guy had no tech skills. He played World of Warcraft too much; that's about it.
What seems to have driven him nuts is growing up in Malibu and UCSB, two of the greatest concentrations of hot women on the planet, and not getting any.
DARPA Grand Challenge vehicles did that ten years ago. (I ran one of the teams.)
This is a fascinating result. The previous assumption was that neural nets generated stable "generalizations", or settled into a state where the correctly classified cases were not near the "edge" of a transition to a different result. That appears to be incorrect. The training process apparently settles near edges, making it vulnerable to small differences. As the author points out, in high-dimensional spaces, most of the volume is near edges.
This probably isn't an overfitting problem. The researchers say they sized their nets appropriately. (If you make an oversized neural net, one big enough to hold all the cases in its state, and train it, you just get a lookup table. There's no generalization. Same problem as curve-fitting with a curve with as many parameters as data points.)
Neural nets are such a black box. Theory of what's going on in there is currently unsatisfactory. The more statistics-based forms of machine learning are on firmer theoretical ground.
Pretty much all lies from the start.
Agreed. Making an CNC positioner work is a solved problem. There are botched positioner designs in the 3D printer world that fail, but that's because of bad engineering. It's an easy positioner problem - the load doesn't vary much. If a stepper is missing steps, you probably did something very wrong. Like using the crap Arduino stepper board from Adafruit, which uses a chip intended for LED dimming.
When I saw the article title, I thought that perhaps someone had closed loop thermal control of the extrusion process. No such luck. The real problems with extrusion-type 3D printers are where the extruded material is welded to the previously deposited material. This is welding a hot thing to a cold thing, which usually fails. On top of that, standard ABS has a high coefficient of expansion, and shrinks when it cools. This is why many 3D printer jobs crack about 1-2 inches from the heated build platform.
Extruder type 3D printers need temperature control over not just the extruder, but chamber air temperature and the temperature of the spot being welded to. There are commercial plastic welders which aim a hot air jet at the spot about to be welded, in addition to heating and extruding the plastic welding rod. 3D printers need something like that. Maybe a laser (a 10W diode should do it) aimed at the join point.
3D printer designers should quit futzing with the positioner design and focus on exactly what's happening at the weld point.
Mod parent up. This is from a group of osteopaths. Here's what Wikpedia has to say about osteopathy:
(Osteopaths) believe that their treatments, which primarily consist of moving, stretching and massaging a personâ(TM)s muscles and joints, help allow the body to heal itself.
As with all forms of complementary and alternative medicine, the practice of osteopathy does not always adhere to evidence-based medicine (EBM). There are few high-quality research studies demonstrating that osteopathy is effective in treating any medical condition other than lower back pain.[2][3] In the UK, the National Institute for Health and Care Excellence recommends osteopathy for the treatment of persistent lower back pain.[4] However, analysis of peer-reviewed research yields little evidence that osteopathy is effective for non-musculoskeletal conditions, and limited evidence that osteopathy is an effective treatment for some types of neck pain, shoulder pain, or limb pain.
No wonder they're unhappy with Wikipedia.
Now if Cell or JAMA or The New England Journal of Medicine complained about Wikipedia, that would be worthy of note.
You know your iPad/Android devices are already capable of doing that. It's just nobody wants to do that.
Right. There's a long history of "docking stations". They work fine, but nobody wants them. There's also a huge compatibility problem - docking stations are usually very device-specific.
Hacker Dojo in Mountain View (formerly a hacker space, now a co-working space) has tables with LCD monitors, but no computers. People bring in laptops, plug in, and camp. That's about as far as "docking" goes.
Lame article, which points to a blog, which points to another blog, which points to the wrong place on a Russian site, which copied the article from The Daily Mail. The Daily Mail, even though a tabloid, has a halfway decent article.
I'm not going to explain inertial guidance; that's what Wikipedia is for. This is better inertial guidance. Here's a popular article which describes this new class of "gyros" and accelerometers. If you really want to know what's going on here, read Advances in Atomic Gyroscopes: A View from Inertial Navigation Applications
Laser "gyros", which work by interferometery and have no moving parts, have been around for decades. The best laser gyros still have more drift, by about 2 orders of magnitude, than the best mechanical gyros. Laser gyro technology has hit the limits of what you can do with photons. The idea here is to do interferometry with coupled atoms, rather than photons. That technology has been slowly improving for a decade or so, and it looks like it's getting close to deployment for high-end applcations.
One of the more interesting possibilities here is chip-scale gyros of moderate precision. Here's a Honewell patent from 2006 for one.
Right. A good example is that in the Android "ice cream sandwich" release, Google deliberately broke on-phone voice dialing. Now, to get hands-free dialing, you have to use Google's voice search service, which logs everything you do for ad purposes. It also won't work if you have poor data connectivity but good voice connectivity, which is common when driving. Google's voice search service assumes the user is looking at the screen, which defeats the whole point of Bluetooth headsets.
So there's Google, pulling an LG.
Right. There are wheel-driven land speed records, currently 470.444 MPH with a turboshaft engine, 462 MPH with a piston engine, 307.666 with an electric motor, and 139.843 MPH with a steam turbine.
The 139.843 MPH steam speed record was set in 2009, by a British team. This is embarassingly low for a custom-built steam turbine powered land speed record car that looks like an aircraft. They brought the car out to the salt flats at Edwards for this.
will instead focus on spin-offs
Yes, Disney issued such a press release in 2009. They're not "sequels" now, they're "spin-offs". Since Catmull and Lasseter took over, they've released "The Little Mermaid: Ariel's Beginning" (a prequel, not a sequel!) "Tinker Bell", "Tinker Bell and the Lost Treasure", and "Tinker Bell and the Great Fairy Rescue" ( a spin-off with two sequels) and are working on "Planes: Fire & Rescue" (too early to tell if it's a spin-off or a sequel).