What makes the know-it-alls and bone-heads that work in the news any better than know-it-alls and bone-heads who don't?
Most media people you see day-to-day have the mistaken impression that they actually know WTF they're talking about. Unfortunately, they don't.
That's a ridiculously uninformed comment.
BMW speedometers read high but it's not due to a problem with the electronics. It is intentional and other replies have already stated why it's intentional.
If you go into the car's service menu (you can reach it with a goofy pedal combination, similar to the old Nintendo up-down-up-down-a-b-start) you can find a menu that presents the ACTUAL speed which is clearly separated from the REPORTED speed.
It goes to show that a company like IBM can function using a "minority" office suite.
That depends on how you define "function."
No, it hasn't. The problem is that much of the advances are in areas that aren't immediately obvious to most people. The various biological sciences and materials sciences are prime examples.
People notice the things that fundamentally change their life; the car, the airplane, the TV, etc. They don't notice someone rewriting a virus to perform something useful, nor the work with brain implants that when fed through a computer have controlled robotic limbs, nor someone "growing" nanowires in the lab, nor the fabrics that can stop a bullet while still being light and flexible enough to make comfortable clothing, etc.
IMO, anyone that doesn't see amazing tech popping up nearly every day is either stuck in the past or simply lacks any vision of the future.
True to a degree, though there is definitely money going towards working out the broad details of such a plan.
While many industries don't create plans that span more than a year or two, the business Intel is in all but requires it. It's absolutely a work in progress and is expected to change over the years but you'd be surprised how accurate these things can be. The broader vision of the Nehalem we see today is not that far removed from the vision of Nehalem they were discussing ~6 years ago.
Where did you see a suggestion there should be no software verification? Surely not in the parent. The question of the degree to which software verification is needed is entirely different than the question of whether "formal verification" is as effective as people who haven't worked with it believe.
I'm simply stating that formal verification isn't perfect. Having worked with it personally I have seen the majority of people simply take what it says on faith because they don't understand the process. Simple rules of thumb that people use to attenuate their "normal" verification expectations are often thrown out the window the first time they work with "formal" verification. A frequent reason is because they hear that it uses math - despite the fact that many forms of it use no more math than any other form of verification - and of course "math can't be wrong" when you're an engineer.
Formal is simply another tool in the toolbox. As with the rest of the tools there are certain instances in which it makes a lot of sense and others where there is something better. Having worked with it in the past I see a story claiming that an entire kernel was "formally verified" and the first thing that comes to mind is a question of how many bugs they missed by not using all their tools.
Just because someone did a formal proof doesn't mean it's correct, bug-free, etc. That's obviously the intention but just as people make mistakes when writing the initial code, people also make mistakes when doing the formal proofs.
Formal has been used for various pieces of hardware verification for a while. It's fairly easy to find examples of very real bugs that made it past formal.
The most famous one is probably the old, infamous Intel FDIV bug. Bob Colwell (PPro, P2, P3, P4 Chief-Architect) gave a talk at Stanford back in 2004 and one of the interesting slides brought up the FDIV bug and how it was "formally proven" but the formal proof was wrong.... Oops.
(You can find video of the talk online - great talk - check it out)
Let the machine do the dirty work. -- "Elements of Programming Style", Kernighan and Ritchie