The elevation display on most GPS units sucks badly though unless you give it a lot of time to average out its error. The main reason for this is that they design the units to track the roads so position on the surface is far more important than the actual elevation. Based on this the filters are modified to give the most accurate result possible in that respect, which might negatively affect the other measurements. Because raw GPS data won't help you much, ideally you get the coordinates from the GPS unit and use a database to determine the elevation. Keep in mind this only counts for cheap GPS modules such as you find in phones and low-end car systems.
Bound to happen, Google is still obliged to follow their contracts they have with the content providers. If they say they device can't do that for one reason or another then they don't have much of a choice. And we all know MPAA would NEVER EVER dare to force a content distributor in such a position. *cough*
That's not a bad idea actually, if you add sufficient lead padding that might just work quite well. The question is off-course how much of a temperature difference you'd be looking at. And you'd have to choose the prism and lens materials very well, else you could end up with x-rays slamming into your sensor at an above average frequency which would significantly increase the noise levels. So you'd have to average the data over a considerable time to be certain.
IR sensors are already very noise sensitive as it is... Introducing radiation won't do much good, even at a distance. It'd be worth a try but I don't see it working long either.
The real problem is getting the digital part of it to a reliable point. You'd have to use military grade radiation hardened hardware, and even then you're looking at a lifespan of days when it has to survive in such a tank unless you pad it with heavy metals, which has several practical issues as encasing RF stages in a thick slab of metal generally doesn't improve stability or reliability. The antenna is the least of your worries I think.
Ah, I used a mechanical pencil because the point didn't break off.
Then again, I tend to have a pencil and pen somewhere in some pocket of my jacket at all times. I simply find it convenient.
During a summer job we wore holsters to hold our tools when working on a roof. Dare to walk up to the nearest roof construction worker and call him a nerd?:P
On a different note, how about those of us who actually had to do technical drawings by hand? I also fit in that category:(
Well, I must say it's still somewhat remarkable how Fortran compilers generally manage to beat C/C++ compilers their collective behinds when it comes to processing large quantities of data. Then again, Fortran tends to be aimed at big data and high performance computing these days.
Ah yes, the good old JIT argument. Then again, I did see Java 6 lose to Perl at several tasks in both speed and memory use. The myth that JIT is able to optimize better than a conventional compiler is pure bullshit. If you're doing low latency data handling it generally means you're working on an embedded system (routers, switches, control systems). On these systems resources are well defined, the memory layout is set ahead of time and the architecture was designed specifically to move data around quickly, and on time. On systems like these C and to some degree C++ outshine most conventional programming languages. Though nothing quite beats Ada at it...
But back to the compiler issue, JIT compilers have a major drawback. They have a very short time to run in if you wish to stick to the "just in time" methodology. A compiler like MSVC or GCC can take several minutes (or even hours) to optimize a program. In terms of branch prediction Intel and IBM compilers are a clear example of how to do it right, they will either attempt to make a calculated guess ahead of time of the most likely scenario or they will listen to the programmer (some compilers have special commands for this) for the most likely result. So that advantage is moot. The memory allocation thing is also bogus, in the end your operating system is still in charge of memory management. Managing the memory and CPU time is the main task of the operating system. Additionally your C program is quite capable of allocating the memory for some task and keeping it reserved until it's needed again. So there you lose another claimed advantage. Memory address translation is mainly a task of the CPU, your JIT compiler can't fill in absolute memory addresses either and shouldn't even be aware of it in the first place. The OS can move your application to another address at will if necessary, only the OS and the CPU need to know about this. And the moment you can replace a pointer by a direct address reference it's possible for your C/C++ optimizer to do it as well. Many of the advantages you claim for JIT are purely software based, but negated by hardware in the end. But this is where the conventional compiler is able to get the advantage. It has the time to optimize and analyze solutions to fit a particular CPU architecture. Your JIT compiler doesn't have the time to do this, optimizing a large program is a very complicated task from a mathematical point of view (check graphy theory to know why).
But Java for low latency is a joke, because it's unpredictable. If I write a snippet of C code I'm pretty sure what's going to come out at the assembly end. This isn't the case with Java. Which brings me to a very interesting bombshell to end this one on: usage of interrupts and timers. In C/C++ you can use inline assembly to call up hardware features of your CPU. And lets face it, nothing beats an interrupt at low latency. Combined with timers for periodic checking you got a killer combination when using C/C++ + assembly. And JNI just isn't fast enough to be able to beat that advantage. But in hindsight both of them suck at low latency and pure high performance. Low latency is the domain of Ada, assembly and hardware. If you claim otherwise you're not working on true low latency problems.
Yeah, but the real problem I see with this method is that once you found an entry point and a set of conditions to one specific "tile of the jigsaw" you might be able to build up an entire tree of solutions quite quickly and solve it. It obviously requires some intelligence, hundreds of years is a brute force, but nobody said you can't use a smart attack vector on this one either. And the moment you have a point you can latch onto most obfuscation techniques tend to fail quite quickly. At least if they do not wish to cause a huge performance penalty judging form the things I've encountered. Combine it with hardware probing and I think you could get a pretty good case against this method if no additional obfuscation methods are used; Combining it with random junk and conventional scrambling could lead to a serious headache though.
That's why you use virtualisation software to begin with when doing this sort of stuff. Then you can simply access anything without the software knowing about it. Memory isolation works both ways in terms of security.
You know what's funnier? That Apple's special connectors all go to a USB socket anyway...
And both of those (RS232 and IEEE1284) are still in use in industrial and lab settings, no reason to ditch a system that works reliably. IEEE1284 was called obsolete by the late 90s, yet IEEE bothered to update the standard anyway in 2000 simply because it was still useful. RS232 is still commonly used at hardware level, you're simply not aware of it. A lot of bluetooth devices transmit data to an integrated bluetooth IC as if it were RS232 communications. And so on... In fact a more rampant case of ancient bus usage in modern equipment is IEEE488 (GPIB / HPIB), it simply won't die. Many have tried, even more have failed at replacing it. It ain't going nowhere simply because the T&M industry realises that GPIB has a few advantages. It's a very simple bus architecture, rugged connectors, reliable (even under high EM noise as you might encounter in an electronics lab), and it can chain and stack several devices easily. The only thing that has come somewhat close is Firewire, but that one has several other problems (complicated implementation, bus management issues, etc.). Don't always think newer is better.
Possibly, it's hard to tell based on sight. But it at least smelled like varnish, and the paper layers in between were coated in the same product. Either way it's a sign of crappy quality, especially considering you can buy spools of coil wire for next to nothing these days.
Slashdot Mirror
The elevation display on most GPS units sucks badly though unless you give it a lot of time to average out its error. The main reason for this is that they design the units to track the roads so position on the surface is far more important than the actual elevation. Based on this the filters are modified to give the most accurate result possible in that respect, which might negatively affect the other measurements. Because raw GPS data won't help you much, ideally you get the coordinates from the GPS unit and use a database to determine the elevation. Keep in mind this only counts for cheap GPS modules such as you find in phones and low-end car systems.
Patent infringement on their patent on ad campaigns against patent trolls!
It wasn't a feature, it was a bug...
$35 is plenty to make a profit on these sort of small devices if they're well designed.
Sure, and a massive drop in sales is totally going to help them with that...
Bound to happen, Google is still obliged to follow their contracts they have with the content providers. If they say they device can't do that for one reason or another then they don't have much of a choice. And we all know MPAA would NEVER EVER dare to force a content distributor in such a position. *cough*
That's not a bad idea actually, if you add sufficient lead padding that might just work quite well. The question is off-course how much of a temperature difference you'd be looking at. And you'd have to choose the prism and lens materials very well, else you could end up with x-rays slamming into your sensor at an above average frequency which would significantly increase the noise levels. So you'd have to average the data over a considerable time to be certain.
IR sensors are already very noise sensitive as it is... Introducing radiation won't do much good, even at a distance. It'd be worth a try but I don't see it working long either.
The real problem is getting the digital part of it to a reliable point. You'd have to use military grade radiation hardened hardware, and even then you're looking at a lifespan of days when it has to survive in such a tank unless you pad it with heavy metals, which has several practical issues as encasing RF stages in a thick slab of metal generally doesn't improve stability or reliability. The antenna is the least of your worries I think.
You really don't get it?
Way to take a joke...
Sorry, posting because I moded incorrectly. *Curses at touch screens*
The main difference seems to be fuel usage and the lack of TSA rectal examinations.
Oh gosh, with a bottle of glue, a block of base material and a CNC mill you can make almost any shape...
Ah, I used a mechanical pencil because the point didn't break off.
Then again, I tend to have a pencil and pen somewhere in some pocket of my jacket at all times. I simply find it convenient.
During a summer job we wore holsters to hold our tools when working on a roof. Dare to walk up to the nearest roof construction worker and call him a nerd? :P
:(
On a different note, how about those of us who actually had to do technical drawings by hand? I also fit in that category
I think it's time to go bungee jumping with a phone in your pocket.
It is close enough if you're talking about a Nokia 3310!
Well, I must say it's still somewhat remarkable how Fortran compilers generally manage to beat C/C++ compilers their collective behinds when it comes to processing large quantities of data. Then again, Fortran tends to be aimed at big data and high performance computing these days.
Ah yes, the good old JIT argument. Then again, I did see Java 6 lose to Perl at several tasks in both speed and memory use. The myth that JIT is able to optimize better than a conventional compiler is pure bullshit. If you're doing low latency data handling it generally means you're working on an embedded system (routers, switches, control systems). On these systems resources are well defined, the memory layout is set ahead of time and the architecture was designed specifically to move data around quickly, and on time. On systems like these C and to some degree C++ outshine most conventional programming languages. Though nothing quite beats Ada at it...
But back to the compiler issue, JIT compilers have a major drawback. They have a very short time to run in if you wish to stick to the "just in time" methodology. A compiler like MSVC or GCC can take several minutes (or even hours) to optimize a program. In terms of branch prediction Intel and IBM compilers are a clear example of how to do it right, they will either attempt to make a calculated guess ahead of time of the most likely scenario or they will listen to the programmer (some compilers have special commands for this) for the most likely result. So that advantage is moot. The memory allocation thing is also bogus, in the end your operating system is still in charge of memory management. Managing the memory and CPU time is the main task of the operating system. Additionally your C program is quite capable of allocating the memory for some task and keeping it reserved until it's needed again. So there you lose another claimed advantage. Memory address translation is mainly a task of the CPU, your JIT compiler can't fill in absolute memory addresses either and shouldn't even be aware of it in the first place. The OS can move your application to another address at will if necessary, only the OS and the CPU need to know about this. And the moment you can replace a pointer by a direct address reference it's possible for your C/C++ optimizer to do it as well. Many of the advantages you claim for JIT are purely software based, but negated by hardware in the end. But this is where the conventional compiler is able to get the advantage. It has the time to optimize and analyze solutions to fit a particular CPU architecture. Your JIT compiler doesn't have the time to do this, optimizing a large program is a very complicated task from a mathematical point of view (check graphy theory to know why).
But Java for low latency is a joke, because it's unpredictable. If I write a snippet of C code I'm pretty sure what's going to come out at the assembly end. This isn't the case with Java. Which brings me to a very interesting bombshell to end this one on: usage of interrupts and timers. In C/C++ you can use inline assembly to call up hardware features of your CPU. And lets face it, nothing beats an interrupt at low latency. Combined with timers for periodic checking you got a killer combination when using C/C++ + assembly. And JNI just isn't fast enough to be able to beat that advantage. But in hindsight both of them suck at low latency and pure high performance. Low latency is the domain of Ada, assembly and hardware. If you claim otherwise you're not working on true low latency problems.
Yeah, but the real problem I see with this method is that once you found an entry point and a set of conditions to one specific "tile of the jigsaw" you might be able to build up an entire tree of solutions quite quickly and solve it. It obviously requires some intelligence, hundreds of years is a brute force, but nobody said you can't use a smart attack vector on this one either. And the moment you have a point you can latch onto most obfuscation techniques tend to fail quite quickly. At least if they do not wish to cause a huge performance penalty judging form the things I've encountered. Combine it with hardware probing and I think you could get a pretty good case against this method if no additional obfuscation methods are used; Combining it with random junk and conventional scrambling could lead to a serious headache though.
That's why you use virtualisation software to begin with when doing this sort of stuff. Then you can simply access anything without the software knowing about it. Memory isolation works both ways in terms of security.
Which controls? I can easily multiplex any number of control channels over the USB cable.
You know what's funnier? That Apple's special connectors all go to a USB socket anyway...
And both of those (RS232 and IEEE1284) are still in use in industrial and lab settings, no reason to ditch a system that works reliably. IEEE1284 was called obsolete by the late 90s, yet IEEE bothered to update the standard anyway in 2000 simply because it was still useful. RS232 is still commonly used at hardware level, you're simply not aware of it. A lot of bluetooth devices transmit data to an integrated bluetooth IC as if it were RS232 communications. And so on... In fact a more rampant case of ancient bus usage in modern equipment is IEEE488 (GPIB / HPIB), it simply won't die. Many have tried, even more have failed at replacing it. It ain't going nowhere simply because the T&M industry realises that GPIB has a few advantages. It's a very simple bus architecture, rugged connectors, reliable (even under high EM noise as you might encounter in an electronics lab), and it can chain and stack several devices easily. The only thing that has come somewhat close is Firewire, but that one has several other problems (complicated implementation, bus management issues, etc.). Don't always think newer is better.
Possibly, it's hard to tell based on sight. But it at least smelled like varnish, and the paper layers in between were coated in the same product. Either way it's a sign of crappy quality, especially considering you can buy spools of coil wire for next to nothing these days.