I've always thought that doctors should use shots to deliver antibiotics whenever possible. For many of the most common things like ear infections it is 1 shot or 2 weeks of pills. It also applies disincentive for idiots who ask for antibiotics for problems that don't need them(based on the fact that many people that I know hate getting shots).
I once got a friend of mine to believe there was such a thing as blinker fluid. It just so happened that another friend had his car parked outside with a cracked tail light. It had rained heavily earlier that day and water had leaked in and filled the blinker right up to where the lens was cracked. She was calling bullshit until we took her outside and showed her. She bought it hook, line and sinker after seeing it. We caught hell later, but it was a lot of fun.
My company has a pretty rigid set of processes and we find that we catch approximately 25% of our defects in code reviews. This doesn't count minor things like not following the coding conventions or bad comments, those are logged separately. We have reviews where we hand them off to just one other engineer as well as the Fagan style of reviews, depending on what we feel is appropriate for the particular piece of code. In our industry(embedded software), it isn't exactly easy to push out a patch once the code is released so that plays into how/why we do it the way we do. I wouldn't say the review process is cheap, but neither are warranty campaigns. Pay it now or pay it later I guess...
Even the best people occasionally typo, put in a bad/wrong comment or just flat out make a mistake during coding. Personally, I'd love it if we had the resources to review every single line of code I write.
Cosmic rays can cause bit flips, but in my experience it is more likely to happen to electrostatic discharge or other electromagnetic interference of terrestrial origin. The odds of cosmic rays hitting your device is partially dependent on altitude.
There was a study done by IBM that indicated that a semiconductor based device could expect one such event every year. Other studies have shown that as the number of transistors in a device goes up, the chances increase. Just because an event occurs does not mean it will be visible. It could happen in unused memory, not affect a calculation significantly, etc.
The interesting bit is this: "The potential impact on typical memory applications illustrates the importance of considering soft errors. A cell phone with one 4-Mbit, low-power memory with an SER of 1000 FITs per megabit will likely have a soft error every 28 years. A high-end router with 10 Gbits of SRAM and an SER of 600 FITs per megabit can experience an error every 170 hours. For a router farm that uses 100 Gbits of memory, a potential networking error interrupting its proper operation could occur every 17 hours. Finally, consider a person on an airplane over the Atlantic at 35,000 ft working on a laptop with 256 Mbytes (2 Gbits) of memory. At this altitude, the SER of 600 FITs per megabit becomes 100,000 FITs per megabit, resulting in a potential error every five hours. The FIT rate of soft errors is more than 10 times the typical FIT rate for a hard reliability failure. Soft errors are not the same concern for cell phones as they can be for systems using a large amount of memory."
*laugh* What do you suggest replacing C with? For many of the microcontrollers I've worked on my alternative is assembly language. Ada is better in many respects, but is hard to find developers for, if you can even get a compiler for your architecture. Things like Java or C# are too damn big to fit in the microcontrollers I usually see. Auto generated code from a model has potential, but the tools are EXPENSIVE and have a steep learning curve.
> In embedded systems programming, it is common practice to disable interrupts if they are not used. It is certainly possible that this app simply does not need to handle these interrupts, whether they are enabled or not.
There is rarely a good reason to shut off the interrupt for an illegal instruction if it exists on your micro. It is entirely possible for a stray bit of electromagnetic radiation(cosmic ray, electric motors turning on or off, etc) to flip a bit in the micro, causing an illegal instruction. The illegal instruction interrupt exists for situations like this. It should be caught and handled in an appropriate manner, ESPECIALLY in safety critical or (as in this case) legal evidence gathering applications. I've seen it happen at work when we do our electromagnetic interference testing.
I work on embedded system stuff every day. At the end of the day, there are NO lint warnings in my code. First, I tend to avoid coding practices and designs that generate lint warnings. By and large, lint warns for a good reason most of the time. Second, in the limited number of situations where lint flags something incorrectly, there are methods for silencing the warnings via special comments. I'm currently working on a 50000 line project, and there are about 70 places in the entire code base were we had to tell lint to ignore a warning. Each warning suppression is documented as to why lint is incorrect.
Lint isn't a perfect tool by any means but in my opinion, anyone developing C code without it is not acting in a professional manner.
I used to get at least one ear infection a year, usually more. If I took antibiotics, I would be functional again within about 24 hours. If I didn't, I couldn't sleep, was crabby, dizzy and otherwise non-functional for several days. So even though I could possibly recover just fine without them, I'd much rather not miss work and be in pain for several days. I'll take the antibiotics thank you very much.
I take much better care of myself these days and I only get one ever couple of years instead of twice or more a year. I don't know how much I can attribute to better diet, and more to following my doctors suggestion of taking decongestants when I feel my ears getting plugged up. Either way, it is nice to be on antibiotics less.
Your average C++ programmer from the non-embedded world will likely be missing a set of skills that are necessary for a lot of embedded work. For example, do they know how to use a oscilloscope? A logic analyzer? A voltmeter? Arbitrary waveform generator? Emulators? Protocol analyzer? Are they used to working on devices that might only have a few K of RAM or even ROM? They could be a good fit if you need someone working on application level stuff, rather than bringing up the low level hardware. It all depends on exactly what the work involves and if the company is willing to allow someone to learn as they go, or if they need someone to hit the ground running.
We do test them ourselves. We chain the equipment down during testing so it can't tip over. We've still bent/broke things due to going outside mechanical system limits(that were not in the spec by the way). It gets even more interesting when you are 50 feet in the air, in a 30 MPH wind when it is -30 F outside. If the machine doesn't kill you, the cold will.
I use PC-lint religiously for my embedded code. In my opinion it has the most bang for the buck. It is fast, cheap and reliable. I've found probably thousands of issues and potential issues over the years using it.
I've also used Polyspace. In my opinion, it is expensive, slow, can't handle some constructs well and has a *horrible* signal to noise ratio. There is also no mechanism for silencing warnings in future runs of the tool(like the -e flag in lint). On the other hand, it has caught a (very) few issues that PC-Lint missed. Is it worth it? I suppose it depends if you are writing systems that can kill people if something goes wrong.
You cannot always avoid stopping in the intersection. For example:An idiot decides to start jaywalking, forcing you to slam on the brakes. End result - you are stopped in the intersection through no fault of your own and get a ticket. Sounds like a crappy deal to me.
You obviously don't work in the embedded field. For many embedded fields, minimizing unit cost is the utmost priority. A few cents(or several dollars in the case of moving from a 1 megabit to a 32 megabit flash) of difference makes a huge difference when you are talking hundreds of thousands or even millions of units. Spending the money on non-recuring engineering expenses pays off in the long run.
And many embedded systems don't even have much of what most people consider an OS. They can get away with a very simple timed loop type OS or a simple scheduler. For the majority of embedded systems, Linux, and any other real time operating systems is just plain overkill.
A friend of mine, who used to be in the Marines was once out on patrol. They called for a 5 minute break so everyone broke out their MRE packets and began to wolf them down. They had so little time they didn't bother to heat them. He just poured the instant coffee in his mouth took a hit off his canteen and swallowed it. He came across the accessory packet, ripped it open and ate the candy. He saw a little bottle of something(Tabasco sauce) didn't know what it was but figured it was edible. He opened it up and poured it in his mouth. He thought they had put some nasty poisonous shit in his MRE it hurt so bad! Quite the shock.
The really funny part about MRES is they contain a little pack of toilet paper(like 12 squares). I swear if you eat MRES for a couple of days thats all the toilet paper you need.
If anyone thinks your juvenile record is ever destroyed(or even really sealed) you're smoking crack. They hang onto those things forever. And they aren't sealed from everone. If you are applying for government security clearances, they can and do go back and look at your records, all the way back.
I work daily with fingerprint technologies and believe me, there is no such thing as a standard "mark up" method. Every company has their own proprietary way of doing things. Every companies algorithms that I have worked with have said there is no way to reconstruct the actual fingerprint from the data the extract(of course!!). From the amount of data that results from processing a fingerprint I tend to beleive this. There is a puch in the industry right now to come up with a standard but there is alot of opposition because each company wants theirs to be the standard. I'm guessing it will sort out when Microsoft begins to throw its weight around.
Slashdot Mirror
I've always thought that doctors should use shots to deliver antibiotics whenever possible. For many of the most common things like ear infections it is 1 shot or 2 weeks of pills. It also applies disincentive for idiots who ask for antibiotics for problems that don't need them(based on the fact that many people that I know hate getting shots).
My wife has Verizon service. She was able to call and get text messages disabled. No charges. It took her all of five minutes.
I once got a friend of mine to believe there was such a thing as blinker fluid. It just so happened that another friend had his car parked outside with a cracked tail light. It had rained heavily earlier that day and water had leaked in and filled the blinker right up to where the lens was cracked. She was calling bullshit until we took her outside and showed her. She bought it hook, line and sinker after seeing it. We caught hell later, but it was a lot of fun.
Wouldn't lint catch typically catch this sort of problem(possible use of a NULL pointer warning)?
My company has a pretty rigid set of processes and we find that we catch approximately 25% of our defects in code reviews. This doesn't count minor things like not following the coding conventions or bad comments, those are logged separately. We have reviews where we hand them off to just one other engineer as well as the Fagan style of reviews, depending on what we feel is appropriate for the particular piece of code. In our industry(embedded software), it isn't exactly easy to push out a patch once the code is released so that plays into how/why we do it the way we do. I wouldn't say the review process is cheap, but neither are warranty campaigns. Pay it now or pay it later I guess...
Even the best people occasionally typo, put in a bad/wrong comment or just flat out make a mistake during coding. Personally, I'd love it if we had the resources to review every single line of code I write.
Cosmic rays can cause bit flips, but in my experience it is more likely to happen to electrostatic discharge or other electromagnetic interference of terrestrial origin. The odds of cosmic rays hitting your device is partially dependent on altitude.
There was a study done by IBM that indicated that a semiconductor based device could expect one such event every year. Other studies have shown that as the number of transistors in a device goes up, the chances increase. Just because an event occurs does not mean it will be visible. It could happen in unused memory, not affect a calculation significantly, etc.
I dug up an article written by some guys at Cyprus Semiconductor(complete article at http://www.edn.com/article/CA454636.html);
The interesting bit is this: "The potential impact on typical memory applications illustrates the importance of considering soft errors. A cell phone with one 4-Mbit, low-power memory with an SER of 1000 FITs per megabit will likely have a soft error every 28 years. A high-end router with 10 Gbits of SRAM and an SER of 600 FITs per megabit can experience an error every 170 hours. For a router farm that uses 100 Gbits of memory, a potential networking error interrupting its proper operation could occur every 17 hours. Finally, consider a person on an airplane over the Atlantic at 35,000 ft working on a laptop with 256 Mbytes (2 Gbits) of memory. At this altitude, the SER of 600 FITs per megabit becomes 100,000 FITs per megabit, resulting in a potential error every five hours. The FIT rate of soft errors is more than 10 times the typical FIT rate for a hard reliability failure. Soft errors are not the same concern for cell phones as they can be for systems using a large amount of memory."
*laugh* What do you suggest replacing C with? For many of the microcontrollers I've worked on my alternative is assembly language. Ada is better in many respects, but is hard to find developers for, if you can even get a compiler for your architecture. Things like Java or C# are too damn big to fit in the microcontrollers I usually see. Auto generated code from a model has potential, but the tools are EXPENSIVE and have a steep learning curve.
> In embedded systems programming, it is common practice to disable interrupts if they are not used. It is certainly possible that this app simply does not need to handle these interrupts, whether they are enabled or not.
There is rarely a good reason to shut off the interrupt for an illegal instruction if it exists on your micro. It is entirely possible for a stray bit of electromagnetic radiation(cosmic ray, electric motors turning on or off, etc) to flip a bit in the micro, causing an illegal instruction. The illegal instruction interrupt exists for situations like this. It should be caught and handled in an appropriate manner, ESPECIALLY in safety critical or (as in this case) legal evidence gathering applications. I've seen it happen at work when we do our electromagnetic interference testing.
I work on embedded system stuff every day. At the end of the day, there are NO lint warnings in my code. First, I tend to avoid coding practices and designs that generate lint warnings. By and large, lint warns for a good reason most of the time. Second, in the limited number of situations where lint flags something incorrectly, there are methods for silencing the warnings via special comments. I'm currently working on a 50000 line project, and there are about 70 places in the entire code base were we had to tell lint to ignore a warning. Each warning suppression is documented as to why lint is incorrect.
Lint isn't a perfect tool by any means but in my opinion, anyone developing C code without it is not acting in a professional manner.
I used to get at least one ear infection a year, usually more. If I took antibiotics, I would be functional again within about 24 hours. If I didn't, I couldn't sleep, was crabby, dizzy and otherwise non-functional for several days. So even though I could possibly recover just fine without them, I'd much rather not miss work and be in pain for several days. I'll take the antibiotics thank you very much.
I take much better care of myself these days and I only get one ever couple of years instead of twice or more a year. I don't know how much I can attribute to better diet, and more to following my doctors suggestion of taking decongestants when I feel my ears getting plugged up. Either way, it is nice to be on antibiotics less.
Your average C++ programmer from the non-embedded world will likely be missing a set of skills that are necessary for a lot of embedded work. For example, do they know how to use a oscilloscope? A logic analyzer? A voltmeter? Arbitrary waveform generator? Emulators? Protocol analyzer? Are they used to working on devices that might only have a few K of RAM or even ROM? They could be a good fit if you need someone working on application level stuff, rather than bringing up the low level hardware. It all depends on exactly what the work involves and if the company is willing to allow someone to learn as they go, or if they need someone to hit the ground running.
We do test them ourselves. We chain the equipment down during testing so it can't tip over. We've still bent/broke things due to going outside mechanical system limits(that were not in the spec by the way). It gets even more interesting when you are 50 feet in the air, in a 30 MPH wind when it is -30 F outside. If the machine doesn't kill you, the cold will.
I use PC-lint religiously for my embedded code. In my opinion it has the most bang for the buck. It is fast, cheap and reliable. I've found probably thousands of issues and potential issues over the years using it.
I've also used Polyspace. In my opinion, it is expensive, slow, can't handle some constructs well and has a *horrible* signal to noise ratio. There is also no mechanism for silencing warnings in future runs of the tool(like the -e flag in lint). On the other hand, it has caught a (very) few issues that PC-Lint missed. Is it worth it? I suppose it depends if you are writing systems that can kill people if something goes wrong.
There are both gas and electric tankless water heaters.
I would think beer taster and Budweiser would be more like torture. Of course jobs aren't supposed to be fun...
You cannot always avoid stopping in the intersection. For example:An idiot decides to start jaywalking, forcing you to slam on the brakes. End result - you are stopped in the intersection through no fault of your own and get a ticket. Sounds like a crappy deal to me.
You obviously don't work in the embedded field. For many embedded fields, minimizing unit cost is the utmost priority. A few cents(or several dollars in the case of moving from a 1 megabit to a 32 megabit flash) of difference makes a huge difference when you are talking hundreds of thousands or even millions of units. Spending the money on non-recuring engineering expenses pays off in the long run.
And many embedded systems don't even have much of what most people consider an OS. They can get away with a very simple timed loop type OS or a simple scheduler. For the majority of embedded systems, Linux, and any other real time operating systems is just plain overkill.
A friend of mine, who used to be in the Marines was once out on patrol. They called for a 5 minute break so everyone broke out their MRE packets and began to wolf them down. They had so little time they didn't bother to heat them. He just poured the instant coffee in his mouth took a hit off his canteen and swallowed it. He came across the accessory packet, ripped it open and ate the candy. He saw a little bottle of something(Tabasco sauce) didn't know what it was but figured it was edible. He opened it up and poured it in his mouth. He thought they had put some nasty poisonous shit in his MRE it hurt so bad! Quite the shock.
The really funny part about MRES is they contain a little pack of toilet paper(like 12 squares). I swear if you eat MRES for a couple of days thats all the toilet paper you need.
If anyone thinks your juvenile record is ever destroyed(or even really sealed) you're smoking crack. They hang onto those things forever. And they aren't sealed from everone. If you are applying for government security clearances, they can and do go back and look at your records, all the way back.
>>-40 in what? Farenheit or Celsius? Makes a big >> difference, you know... =-p
Actually, -40 is the same temperature in Fahrenheit and Celsius.
I work daily with fingerprint technologies and believe me, there is no such thing as a standard "mark up" method. Every company has their own proprietary way of doing things. Every companies algorithms that I have worked with have said there is no way to reconstruct the actual fingerprint from the data the extract(of course!!). From the amount of data that results from processing a fingerprint I tend to beleive this. There is a puch in the industry right now to come up with a standard but there is alot of opposition because each company wants theirs to be the standard. I'm guessing it will sort out when Microsoft begins to throw its weight around.