Top 10 IT myths

2. More CPU power equals more speed
Shaun Nichols: This is a misconception that has spanned two eras. In the 1990s and first half of this decade, the thinking was that higher clock speeds translated to pure performance, that twice as many megahertz meant twice as fast in practice. Then dual-core chips came along and it changed to twice as many cores means twice as fast.

While this is convenient marketing jargon, it's also pretty bad measurement and not at all accurate. The CPU is one of many components of a PC, and as such is also one of many bottlenecks. Things such as memory and hard drive speeds can have just as much or more of an impact on a system's overall speed as a processor.

The multi-core argument only further muddies the water. While two cores are of course faster than one, they're not always twice as fast. Certain instructions, for example, need to be processed in such a way that they simply can't be run in parallel, effectively limiting many operations to single-core functions.

Perhaps the problem is that the CPU is the most macho of all the computer parts. Many of us nerd types have to fight off the urge to let out a big Tim Allen "cave man" grunt when rattling off the specs for our quad-core beasts. The fact is, however, that the CPU isn't the only star of the speed show.

Iain Thomson: Shaun has this spot on. For years the computer industry, both processor manufacturers and system builders, staged a computing arms race in advertising and PR. Each increase in clock speed was hailed as a competitive advantage beyond price.

The prime example of this was the race between Intel and AMD to build the first 1GHz processor. One of my fondest memories is an Intel spokesman coming into the office just after AMD beat them to this mark. Obviously my first question was how he felt about losing. He looked my in the eye and said "Well you know, Iain, speed isn't everything," and managed to keep a straight face - with a little effort. I'm not surprised that he's now running the UK operation - that took balls.

As you rightly point out, however, processor speed is little to do with overall performance. Cache sizes, graphics capability and hard drive access times all play their part. Software too is critical; code has to be written to perform on multi-core systems and older software won't see much of a speed bump.

The shift in emphasis from processor speed is no bad thing. I was a little ashamed reading your description of attitudes towards it. I, and I suspect a fair few readers, have displayed such sad characteristics. Yes, the phrase 'Oh, you're running a 486, how retro!' has crossed my lips.

1. Virus companies write most malware
Iain Thomson: If you want to make a security software specialist spitting mad trot this one out. I've heard it everywhere, even from rational people who understand a little about computers. It's not true and never has been.

There are actually very few proper malware writers. Until recently the vast majority of attacks came from script kiddies, who took someone else's malware code, tweaked it slightly and then released it into the wild. This has changed slightly as malware has become more about profit, but it is still the case.

Anti-virus specialists are adept at spotting the hallmarks of the true virus writers, and if one of them started writing the stuff themselves it is highly likely that they would be spotted fairly quickly. But this ignores the key point about this myth.

The teams of anti-virus researchers in the industry are driven people, in a way that makes the average coding geek look like a stoned slacker. They see themselves as the thin blue line between computers succeeding and failing, and take unusual steps to do so.

It's also one of the few industries where competitors share secrets. Once a signature file for a specific piece of malware has been developed it gets emailed to all competitors who also share information (which is almost all of them - even Microsoft). That means that whichever security software you use you get roughly similar protection.

So what, I hear you say, there are cases of fire-fighters who set fires just so they can be a hero and put them out. Well yes, but if one researcher suddenly started solving all these signature files without a good explanation, then questions would be asked.

Shaun Nichols: This myth is insulting to the good and the bad guys. I think a large part of it comes from a misunderstanding as to the nature of vulnerability disclosures and proof-of-concept code.

What usually happens is that a researcher discovers a vulnerability in a product. The researcher then either directly contacts the company or contacts a third party, such as a TippingPoint, which then passes it on to the company, which then patches it. The researcher usually releases a sample proof-of-concept script to show that he or she actually did find the flaw. Around 99 per cent of the time, this is done before the public even knows about the flaw.

This, to some people, seems unethical. Why would one try and create ways to attack a system? The answer is because the bad guys are really smart people too. The 'white hat' researchers who find and report vulnerabilities for a living are plugging holes that those who create malware and attack kits would otherwise find in time and exploit as 'zero day' attacks for which there are no fixes.

The bottom line is that the bad guys really don't need any help in finding flaws, and getting a vulnerability out in the open is almost always better than sticking your head in the sand and hoping nobody writes an exploit.