The possibility of doing this aside, falling back on the easily-spoofable C/A code when the P(Y) code is recognized as invalid would defeat the entire purpose of having Anti-Spoof technology on the P-code at all. It'd be like having the world's strongest password, but the "I forgot my password" link just asks for your name, and lets you right on in.
P(Y) is still significantly more accurate than C/A, and having access to both L1* and L2P allows the receiver to do ionospheric correction, improving the accuracy even further.
Still, I'm not aware of anyone who has successfully spoofed P-code (though it's been a few years since I worked directly on GPS), so I suspect you're right that this drone was operating only on L1C, which is rather simple to spoof. Especially given that a less-than-perfect spoof of P-code, if even possible, should have been easily detected by an inertial guidance system.
If you notice in the article, that's why there is a whole order-of-magnitude difference between the basic and the parameterized COCOMO estimations.
Using the parameterized models, you're able to describe a lot of the complexities that set kernel-programming apart.
Now, whether or not they're enough is a whole other topic, but the model DOES try to account for such differences. I have a feeling that the real-life-projects they used to generate their parameter coefficients included very few OSes.
It would be interesting to make a ceiling calculation of ACTUAL development time for the Linux kernel (something like, for each month of the kernel's life, the number of developers who submitted patches * 1MM). Would that at all approach the COCOMO number?
The problem is that the left-eye and right-eye imagines need to be separated. Unlike the the clumsy old red & blue method, both eye's images cannot exist in the same source image. Current systems use a *physical* difference between the two perspectives, whether it's polarity (common in theater systems) or timing (common in TV systems).
So the difference between 2D and 3D TVs is that the 3D TV must be able to make a physical difference between the two perspectivesThe most common system for this in 3D TVs now is to double the TV's refresh rate (to 120Hz), and alternate showing left eye then right-eye images. The viewer then has special shutter glasses, which are synchronized with the TV. They work by blocking the right eye when the left-eye image is displayed, and block the left-eye when the right-eye image is displayed.
Other technology, which is more costly on the TV side, but doesn't require such fancy glasses, is for the TV to interleave scan lines with different polarities. Then left-eye images are displayed only on the lines which are polarized one direction, while the right-eye images are displays only on the lines polarized the other direction. Then the viewer just needs the same, simple, polarized glasses as used in the movie theaters. But the image will effectively be half the resolution of the TV.
This is DARPA... It's been a LONG time since they've ever actually paid for development through final production.
Their strategy is to pay for initial technology development and proofs of concept, and then encourage (and probably help) to find a government customer who actually wants a product based on those technologies.
So the timeframe for a real product winds up being much longer. And the final bill to the taxpayers, much higher.
The GPS receiver in both the 3G and 3GS does indeed work stand-alone. The assist servers merely provide faster time-to-fix by providing the data you mention.
Without a cell connection, both models will still eventually locate a satellite and obtain the almanac like any normal GPS device.
The 3G and 3GS HAVE true GPS that maybe be operated standalone or assisted. Its accuracy is equal to most any other handheld GPS unit, and the assisted portion allows faster time-to-fix than standard products.
Which the 3G is missing that makes turn-by-turn difficult is a compass. Most turn-by-turn devices have a digital compass, which allows detecting that you've completed a turn an instaneous result. Without a compass, one has to depend on consecutive positioning calculations to detect that you are indeed moving in a different direction now (accumulating enough readings in the new direction to rule out precision error).
The 3GS DOES have the digital compass.
However, even in the 2G and 3G, one could use the accelerometer to confirm a turn. It requires using more than just CoreLocation in the apple SDK, but it's entirely doable and just as reliable an indicator as a digital compass.
I don't know if TomTom uses this approach in non-3GS devices or not, though. Some other apps do.
The conversion has absolutely nothing to do with cost of energy. They're calculating the amount of energy (measured in energy density units of gallons of gasoline) required to move the vehicle.
Basically, they're claiming the car requires 146Wh/mi for the somewhat arbitrary commute distance selected by the EPA. ((33705Wh/g)/(146Wh/mi)) = 230mpg (equivalent).
Granted, that works out to around 6kWh for a 40 mile commute.
Well, technically... Easily. You can claim the lives themselves are invaluable, but the judgement against the offending company would most definitely have a very specific dollar figure.
The insurance is for that. Not to replace the people themselves.
Oversight? Hardly. It's damned expensive to produce unclassified content from a classified source.
By default, it is assumed ALL data generated by a classified source is classified. To unclassify any of that information requires a highly-tested, bulletproof-design of software that can be shown that in the process of declassifying any part of the data, it is impossible that something classified accidently got in there.
It's much cheaper to just leave everything classified at the same level as the piece of hardware/algorithms that produced it.
Threading only applies to a subset of parallizable cases, on a subset of computing architectures.
You're not going to use threads to decompose a for loop doing simple non-dependent mathematic operations over a large vector. That's why the ugly vector operations were added to C for Alti-Vec/MMX/SSE/etc. It's another type of problem.
As long as software development is stuck in a cycle of having to invent new programming solutions for every new computing architecture, we're not going to see a whole lot of variance/advancement in computer architectures.
What is desperately being sought now is a much more generic way of indicating parralelism in code, that a compiler can then parralelize or no parallelize using any number of techniques, depending on the specific architecture it's compiling to.
People talk about fancy super-intelligent compilers, but that's not really what we're after now. They key is "merely" being able to concisely indicate data relationships (foremost dependency, but other attributes as well), which will open the door for any number of hardware and software innovations.
Having working with the OS in question and directly with the NSA on getting our own OS certified (which we decided was too expensive in the end, and wound up throwing it away to use Integrity-178B)....
NSA does employ a sizeable group of mathemeticians in the area of security now as well. They've invested a lot of time in money in mathematical models for proving security, namely from the vantage point of possible combinations of system states, and how to minimize those into a human-testable number of states.
The importance isn't the image itself. It's how the image changes with time, including the rotation of the earth changes the reflected light and the position of the moon.
There are certain things we can guess, but in trying to build a model of how to observe other Earth-like planets from a distance, an actual observation, even from a much shorter distance, can improve the technology many times over.
In the end, when we look for extra-solar planets, we aren't looking for pretty images, we're looking for funny effects that are observable from a nearly singular point of light: regular variances in intensity, spectrum, polarization, etc..
Likewise, if someday we could do a similar study from one of our probes that's managed to get out of the solar system, that would improve the model another order of magnitude, accounting for other variables in the observation.
But on my PC, I have mozilla as my default browser, but Picasa and Visual Studio still insist on using IE when it needs to do web stuff. I'm sure I could override that, but I haven't bothered.
IE being the system's browsers leaves it easy to be accidently opened, methinks.
But I'm in agreement that if Windows provides a mechanism for marking files as unsafe, it's Safari's fault for not taking advantage of that. Apple can't blame Microsoft of being at fault if they're not using the security mechanisms that Microsoft has put in place.
That seems like a reasonable core requirement, when dealing with traditional type cores.
But, as Moore was saying, you start to evaulate heterogenous microprocessors, with processing units much more specialized than your basic general purpose processor (be it more DSP, GPU, FPGA, or whatever), you're going to have a lot more problems with the fact that the functionality of a single object may not be well-fit to the optimum processing unit. Not to mention, we also need techniques for determining exactly which processing units are optimum for the particular task, based not only on raw functionality, but resource availability, and future resource needs.
Homogenous multi-cores are difficult as it is. The heterogenous nightmare is what particularly frightens researchers in this area. We've seen some amazing performance success with these types of processors, but essentially purely with hand-tuned (or at least heavily hinted) source code. To actually sell microprocessors of these types with success, there's no doubt that we need either more intelligent tools or a miraculous generalized-yet-not-too-high-level parallel programming paradigm. Preferably both.
The problem with existing high-throughput processors are, as you pointed out, power consumption, plus achievable throughput, I/O throughput, and space readiness.
For most front-end type signal processing, the MONARCH design approaches that of an FPGA in terms of utilization efficiency. When it comes to the next-gen sensors for DoD applications, the Cell doesn't have near the I/O capability required (or, more correctly, the I/O options don't match the processing resource requirements, so you lose efficiency), and there's no way on earth (no pun intended) that a Cell will operate error-free in a radiation-rich environment at its current clock rates.
Yes, it's designed for a niche market. Hopefully one bigger than just next-gen satellites, but it was never meant to replace your desktop or your toaster.
I expect it'll be longer than a few years before you see it on your desk, because dataflow processors don't really solve desktop computing problems.
However, you will see them in space, on aircraft, in missiles, GPS units, etc. in the next few years, because they are very attractive solutions to real-time front-end processing problems, especially where size and power consumption is a major concern. Hence why TRIPS is being paid for by DARPA (along with several other dataflow - some more dataflow than others - architectures in the Polymorphous Computing Architectures program).
Slashdot Mirror
The possibility of doing this aside, falling back on the easily-spoofable C/A code when the P(Y) code is recognized as invalid would defeat the entire purpose of having Anti-Spoof technology on the P-code at all. It'd be like having the world's strongest password, but the "I forgot my password" link just asks for your name, and lets you right on in.
P(Y) is still significantly more accurate than C/A, and having access to both L1* and L2P allows the receiver to do ionospheric correction, improving the accuracy even further.
Still, I'm not aware of anyone who has successfully spoofed P-code (though it's been a few years since I worked directly on GPS), so I suspect you're right that this drone was operating only on L1C, which is rather simple to spoof. Especially given that a less-than-perfect spoof of P-code, if even possible, should have been easily detected by an inertial guidance system.
Big screen? More like on a little, choppy, pixelated redtube flash app.
If you notice in the article, that's why there is a whole order-of-magnitude difference between the basic and the parameterized COCOMO estimations.
Using the parameterized models, you're able to describe a lot of the complexities that set kernel-programming apart.
Now, whether or not they're enough is a whole other topic, but the model DOES try to account for such differences. I have a feeling that the real-life-projects they used to generate their parameter coefficients included very few OSes.
It would be interesting to make a ceiling calculation of ACTUAL development time for the Linux kernel (something like, for each month of the kernel's life, the number of developers who submitted patches * 1MM). Would that at all approach the COCOMO number?
The problem is that the left-eye and right-eye imagines need to be separated. Unlike the the clumsy old red & blue method, both eye's images cannot exist in the same source image. Current systems use a *physical* difference between the two perspectives, whether it's polarity (common in theater systems) or timing (common in TV systems).
So the difference between 2D and 3D TVs is that the 3D TV must be able to make a physical difference between the two perspectivesThe most common system for this in 3D TVs now is to double the TV's refresh rate (to 120Hz), and alternate showing left eye then right-eye images. The viewer then has special shutter glasses, which are synchronized with the TV. They work by blocking the right eye when the left-eye image is displayed, and block the left-eye when the right-eye image is displayed.
Other technology, which is more costly on the TV side, but doesn't require such fancy glasses, is for the TV to interleave scan lines with different polarities. Then left-eye images are displayed only on the lines which are polarized one direction, while the right-eye images are displays only on the lines polarized the other direction. Then the viewer just needs the same, simple, polarized glasses as used in the movie theaters. But the image will effectively be half the resolution of the TV.
The Pirate Party's opposed? Gee, Microsoft MUST be shaking in their boots now.
This is DARPA... It's been a LONG time since they've ever actually paid for development through final production.
Their strategy is to pay for initial technology development and proofs of concept, and then encourage (and probably help) to find a government customer who actually wants a product based on those technologies.
So the timeframe for a real product winds up being much longer. And the final bill to the taxpayers, much higher.
The GPS receiver in both the 3G and 3GS does indeed work stand-alone. The assist servers merely provide faster time-to-fix by providing the data you mention.
Without a cell connection, both models will still eventually locate a satellite and obtain the almanac like any normal GPS device.
The A-GPS used by the 2G is subpar to true GPS.
The 3G and 3GS HAVE true GPS that maybe be operated standalone or assisted. Its accuracy is equal to most any other handheld GPS unit, and the assisted portion allows faster time-to-fix than standard products.
Which the 3G is missing that makes turn-by-turn difficult is a compass. Most turn-by-turn devices have a digital compass, which allows detecting that you've completed a turn an instaneous result. Without a compass, one has to depend on consecutive positioning calculations to detect that you are indeed moving in a different direction now (accumulating enough readings in the new direction to rule out precision error).
The 3GS DOES have the digital compass.
However, even in the 2G and 3G, one could use the accelerometer to confirm a turn. It requires using more than just CoreLocation in the apple SDK, but it's entirely doable and just as reliable an indicator as a digital compass.
I don't know if TomTom uses this approach in non-3GS devices or not, though. Some other apps do.
The conversion has absolutely nothing to do with cost of energy. They're calculating the amount of energy (measured in energy density units of gallons of gasoline) required to move the vehicle.
Basically, they're claiming the car requires 146Wh/mi for the somewhat arbitrary commute distance selected by the EPA. ((33705Wh/g)/(146Wh/mi)) = 230mpg (equivalent).
Granted, that works out to around 6kWh for a 40 mile commute.
This is windows. find == grep. Well, find < grep.
Well, technically... Easily. You can claim the lives themselves are invaluable, but the judgement against the offending company would most definitely have a very specific dollar figure.
The insurance is for that. Not to replace the people themselves.
Once touched by a classified process, the non-classified data becomes classified, until you painstakingly prove that it is not.
Oversight? Hardly. It's damned expensive to produce unclassified content from a classified source.
By default, it is assumed ALL data generated by a classified source is classified. To unclassify any of that information requires a highly-tested, bulletproof-design of software that can be shown that in the process of declassifying any part of the data, it is impossible that something classified accidently got in there.
It's much cheaper to just leave everything classified at the same level as the piece of hardware/algorithms that produced it.
In addition to the other commentaries:
Threading only applies to a subset of parallizable cases, on a subset of computing architectures.
You're not going to use threads to decompose a for loop doing simple non-dependent mathematic operations over a large vector. That's why the ugly vector operations were added to C for Alti-Vec/MMX/SSE/etc. It's another type of problem.
As long as software development is stuck in a cycle of having to invent new programming solutions for every new computing architecture, we're not going to see a whole lot of variance/advancement in computer architectures.
What is desperately being sought now is a much more generic way of indicating parralelism in code, that a compiler can then parralelize or no parallelize using any number of techniques, depending on the specific architecture it's compiling to.
People talk about fancy super-intelligent compilers, but that's not really what we're after now. They key is "merely" being able to concisely indicate data relationships (foremost dependency, but other attributes as well), which will open the door for any number of hardware and software innovations.
Having working with the OS in question and directly with the NSA on getting our own OS certified (which we decided was too expensive in the end, and wound up throwing it away to use Integrity-178B)....
NSA does employ a sizeable group of mathemeticians in the area of security now as well. They've invested a lot of time in money in mathematical models for proving security, namely from the vantage point of possible combinations of system states, and how to minimize those into a human-testable number of states.
The importance isn't the image itself. It's how the image changes with time, including the rotation of the earth changes the reflected light and the position of the moon.
There are certain things we can guess, but in trying to build a model of how to observe other Earth-like planets from a distance, an actual observation, even from a much shorter distance, can improve the technology many times over.
In the end, when we look for extra-solar planets, we aren't looking for pretty images, we're looking for funny effects that are observable from a nearly singular point of light: regular variances in intensity, spectrum, polarization, etc..
Likewise, if someday we could do a similar study from one of our probes that's managed to get out of the solar system, that would improve the model another order of magnitude, accounting for other variables in the observation.
Who uses safari for windows, period?
But on my PC, I have mozilla as my default browser, but Picasa and Visual Studio still insist on using IE when it needs to do web stuff. I'm sure I could override that, but I haven't bothered.
IE being the system's browsers leaves it easy to be accidently opened, methinks.
But I'm in agreement that if Windows provides a mechanism for marking files as unsafe, it's Safari's fault for not taking advantage of that. Apple can't blame Microsoft of being at fault if they're not using the security mechanisms that Microsoft has put in place.
We've designed civilian receivers that use the L2 signal for correction, too, using the carrier wave, avoiding having to decrypt P code.
Not something you'll find in your Garmin or iPhone 3G, but not horrible uncommon in high-end survey equipment.
No, I believe that title goes to Toonces.
That seems like a reasonable core requirement, when dealing with traditional type cores.
But, as Moore was saying, you start to evaulate heterogenous microprocessors, with processing units much more specialized than your basic general purpose processor (be it more DSP, GPU, FPGA, or whatever), you're going to have a lot more problems with the fact that the functionality of a single object may not be well-fit to the optimum processing unit. Not to mention, we also need techniques for determining exactly which processing units are optimum for the particular task, based not only on raw functionality, but resource availability, and future resource needs.
Homogenous multi-cores are difficult as it is. The heterogenous nightmare is what particularly frightens researchers in this area. We've seen some amazing performance success with these types of processors, but essentially purely with hand-tuned (or at least heavily hinted) source code. To actually sell microprocessors of these types with success, there's no doubt that we need either more intelligent tools or a miraculous generalized-yet-not-too-high-level parallel programming paradigm. Preferably both.
The problem with existing high-throughput processors are, as you pointed out, power consumption, plus achievable throughput, I/O throughput, and space readiness.
For most front-end type signal processing, the MONARCH design approaches that of an FPGA in terms of utilization efficiency. When it comes to the next-gen sensors for DoD applications, the Cell doesn't have near the I/O capability required (or, more correctly, the I/O options don't match the processing resource requirements, so you lose efficiency), and there's no way on earth (no pun intended) that a Cell will operate error-free in a radiation-rich environment at its current clock rates.
Yes, it's designed for a niche market. Hopefully one bigger than just next-gen satellites, but it was never meant to replace your desktop or your toaster.
Wow. In contrast, I can think of only a small subset of digital logic designs that are practical to implement on a microcontroller.
Thank god they all have computers and internet access.
I expect it'll be longer than a few years before you see it on your desk, because dataflow processors don't really solve desktop computing problems.
However, you will see them in space, on aircraft, in missiles, GPS units, etc. in the next few years, because they are very attractive solutions to real-time front-end processing problems, especially where size and power consumption is a major concern. Hence why TRIPS is being paid for by DARPA (along with several other dataflow - some more dataflow than others - architectures in the Polymorphous Computing Architectures program).