I have to totally agree with this. There is a definite distinction to be made between 'cowboy coder' and 'hacker'. I consider myself a hacker in the traditional sense of the word (pre media buzzword) and I spend many long days and nights studying other people's work, reading books, discovering the latest trends and methodologies in the field of software development, etc. Constantly trying to improve my skills, correct my mistakes, learning better ways of doing things, and keeping an open mind. A cowboy coder has a closed mind and is more in line with the post-media-buzzword meaning of hacker. Someone who dances in code for fame and performing tricks to impress co-workers, not for the pure joy of learning and understanding. For me, the technology industry is like a landscape and I am always excited to see what is around the next bend in the road or over the next hilltop. It is a journey that I often make alone, occasionally meeting fellow travelers to discuss our experiences.
Hackers don't make hacks. I feel that you don't understand the term 'Hacker'. The 'hack' in hacker is not about hacking something together, it is about hacking your way through an unknown to come out the other side with an understanding of a thing.
And yet, after a lifetime of using this account, you would still have stolen less money from me than my bank already did. So tell you what, give me a good interest rate and I may just take you up on it...
Maybe that is the intention? Just because Schneier *thinks* it is an average, doesn't make it so. Maybe the device becomes more accurate as more samples are taken, and therefore gives more weight to the last (not the first!) sample.
Suppose the machine does become more accurate as more samples are taken (like maybe it needs to warm up first or something?), I find it unrealistic that it would become more accurate at the same rate as the ratio implied by the calculations performed in the code. Further, wouldn't it make sense to drop the initial readings anyway until the machine had reached it's 'harmony' with the rest of the universe and was able to measure accurately?
Who cares if there is loss of precision? In the end, it spits out a value that is essentially binary: drunk or not. You are not less drunk if it says so with 9 extra bits of precision, and in fact the extra accuracy could itself be considered an error as it shows a certainty about the result that may not be warranted by the design of the machine.
As mentioned elsewhere, the important fact is that the loss of precision is done prior to making the final determination. I have a deal for you: I will start a bank that will ignore all fractions of a dollar for all of your deposits. You deposit $12.45 but your bank account only gets the $12. I will keep the $0.45. Sound good? It doesn't matter right? I will provide it as a free service to you.
If the code is tested properly, there is no need to keep the first two interrupts going. As for the "software interrupt", it may sound ominous that it is disabled, but there is absolutely no way to tell if and why it should be enabled, and in fact disabling it is probably correct. There is absolutely nothing in software engineering that says you should always enable all interrupts because otherwise your code would be less reliable.
Besides, a typical result of executing illegal instructions is that the device hangs or reboots. Since alcohol testing devices don't do that (to the best of my knowledge), it appears that disabling those interrupts does not cause any harm.
There IS something in software engineering that says you should take every precaution to avoid introducing errors into your code and that you should validate all inputs into your process. A computer (device) rebooting due to illegal instructions is really some low level validation code that forces a shutdown to avoid nasty things like corrupting your data or reformatting your hard drive. What these people have done is to remove this level of validation. If they left this error-checking in place, the unit would probably 'reboot' every five minutes and they would never gotten through the marketing demo.
That conclusion is entirely unwarranted. It appears to be designed to provide a weighted average, not show undue accuracy, and is sufficiently well-tested that it does not need emergency measures like the illegal instruction interrupt. In other words, even though the software may look messy it is working fine.
The interrupts are not emergency measures. If anything, they are safety measures. They were probably taken so that the device would appear to pass any 'testing' that had been performed. I have another deal for you. It's called a sub-prime mortgage...
I usually use Linux based platforms for server applications. True they are more difficult to work with in the beginning. But once you get them working, they work well. Windows, on the other hand, is more simple with the point-and-click action but try remembering which combination of clicks and which dialogs and tabs led to the success of your efforts. Too much interconnectedness (read incest) with their products and features leads to undocumented and vague dependencies between them.
In addition to the expected high latency, this RFC also depends on a notoriously insecure transport medium. Suggest implementing security measures such as taping over mouth and covering your eyes and ears with your hands. This will have the added benefit of being unable to speak, see, or hear evil.
Slashdot Mirror
Except when you hoard it.
Don't forget the step about sticking the whole mess in the microwave for awhile! Can't wait to try this one at home. :-)
Please stop.
I have to totally agree with this. There is a definite distinction to be made between 'cowboy coder' and 'hacker'. I consider myself a hacker in the traditional sense of the word (pre media buzzword) and I spend many long days and nights studying other people's work, reading books, discovering the latest trends and methodologies in the field of software development, etc. Constantly trying to improve my skills, correct my mistakes, learning better ways of doing things, and keeping an open mind. A cowboy coder has a closed mind and is more in line with the post-media-buzzword meaning of hacker. Someone who dances in code for fame and performing tricks to impress co-workers, not for the pure joy of learning and understanding. For me, the technology industry is like a landscape and I am always excited to see what is around the next bend in the road or over the next hilltop. It is a journey that I often make alone, occasionally meeting fellow travelers to discuss our experiences.
Hackers don't make hacks. I feel that you don't understand the term 'Hacker'. The 'hack' in hacker is not about hacking something together, it is about hacking your way through an unknown to come out the other side with an understanding of a thing.
And yet, after a lifetime of using this account, you would still have stolen less money from me than my bank already did. So tell you what, give me a good interest rate and I may just take you up on it...
LOL - nice one. Thanks for the reply. :-)
Maybe that is the intention? Just because Schneier *thinks* it is an average, doesn't make it so. Maybe the device becomes more accurate as more samples are taken, and therefore gives more weight to the last (not the first!) sample.
Suppose the machine does become more accurate as more samples are taken (like maybe it needs to warm up first or something?), I find it unrealistic that it would become more accurate at the same rate as the ratio implied by the calculations performed in the code. Further, wouldn't it make sense to drop the initial readings anyway until the machine had reached it's 'harmony' with the rest of the universe and was able to measure accurately?
Who cares if there is loss of precision? In the end, it spits out a value that is essentially binary: drunk or not. You are not less drunk if it says so with 9 extra bits of precision, and in fact the extra accuracy could itself be considered an error as it shows a certainty about the result that may not be warranted by the design of the machine.
As mentioned elsewhere, the important fact is that the loss of precision is done prior to making the final determination. I have a deal for you: I will start a bank that will ignore all fractions of a dollar for all of your deposits. You deposit $12.45 but your bank account only gets the $12. I will keep the $0.45. Sound good? It doesn't matter right? I will provide it as a free service to you.
If the code is tested properly, there is no need to keep the first two interrupts going. As for the "software interrupt", it may sound ominous that it is disabled, but there is absolutely no way to tell if and why it should be enabled, and in fact disabling it is probably correct. There is absolutely nothing in software engineering that says you should always enable all interrupts because otherwise your code would be less reliable.
Besides, a typical result of executing illegal instructions is that the device hangs or reboots. Since alcohol testing devices don't do that (to the best of my knowledge), it appears that disabling those interrupts does not cause any harm.
There IS something in software engineering that says you should take every precaution to avoid introducing errors into your code and that you should validate all inputs into your process. A computer (device) rebooting due to illegal instructions is really some low level validation code that forces a shutdown to avoid nasty things like corrupting your data or reformatting your hard drive. What these people have done is to remove this level of validation. If they left this error-checking in place, the unit would probably 'reboot' every five minutes and they would never gotten through the marketing demo.
That conclusion is entirely unwarranted. It appears to be designed to provide a weighted average, not show undue accuracy, and is sufficiently well-tested that it does not need emergency measures like the illegal instruction interrupt. In other words, even though the software may look messy it is working fine.
The interrupts are not emergency measures. If anything, they are safety measures. They were probably taken so that the device would appear to pass any 'testing' that had been performed. I have another deal for you. It's called a sub-prime mortgage ...
I usually use Linux based platforms for server applications. True they are more difficult to work with in the beginning. But once you get them working, they work well. Windows, on the other hand, is more simple with the point-and-click action but try remembering which combination of clicks and which dialogs and tabs led to the success of your efforts. Too much interconnectedness (read incest) with their products and features leads to undocumented and vague dependencies between them.
I also remember the day when Microsoft was the upstart rebel. Now they kinda suck like those before them.
An excellent solution.
In addition to the expected high latency, this RFC also depends on a notoriously insecure transport medium. Suggest implementing security measures such as taping over mouth and covering your eyes and ears with your hands. This will have the added benefit of being unable to speak, see, or hear evil.
1st post? :-)