It's a "huge conflict of interest" for one company to provide both an operating platform and a security platform, Symantec Corp. CEO John Thompson said during a keynote speech at the Cebit trade show in Hanover, Germany. Although Thompson didn't mention Microsoft Corp. by name, that company's introduction of consumer and enterprise security products to complement its operating systems could hurt Symantec, which currently tops the security software industry by market share.... ==== Not to worry, Mr. Thompson! Microsoft's "security products"
...one senior Microsoft manager has admitted that OneCare shouldn't have been released at all in its present state.
"Usually Microsoft doesn't develop products, we buy products. It's not a bad product, but bits and pieces are missing," said Arno Edelmann, Microsoft's European business security manager. "OneCare is a new product-they shouldn't have rolled it out when they did, but they're fixing the problems now."
Your point is what? It's part of a program's life cycle of implementation and then maintenance. You pull the trigger and release it and don't leave it on the shelf nit picking it. You deploy it and deal with the maintenance and improvements of the product as part of the its life cycle.
No, I am a programmer that's been programming since 1980 and I know the drill of a program's/application's life cycle, from analysis, design, coding/development, testing, quality assurance, deployment/implementation and then maintenance/improvements.
It's pretty much a standard that you obviously know nothing about. It's a computer program/application written by fallible Human Beings and no program/application is going to be 100% perfect out the gate.
We as Human Beings are NOT perfect and nothing we create or do is going to be perfect either. That's a fact.
A bug in Microsoft's new security product (Windows Live OneCare) wipes out Outlook ".pst" and Outlook Express ".dbx" files when it finds malicious email. So it replaces one security problem (the malware) with another (denial of service). Leads to some interesting new forms of attack - send emails to a victim that are just bad enough to trip up OneCare and cause it to launch a DoS attack on its users. Affects Outlook 97 & 2000, and Outlook Express on WinXP.
Shouldn't we have a higher standard for security software in the "do no harm" category? Seems ironic, in particular, that it's a Microsoft product damaging another Microsoft product!
Have you ever been part of the software development team of a non-trivial product that couldn't wait indefinitely for release?
If so, and if you were one of the major developers, then unless your team spent a -lot- of time on strong designs, preconditions and postconditions, logical proofs, and other elements of Zero Defect Programming, chances are excellent that you've released your code with known bugs -- possibly with *many* known bugs.
*Every* real development team that I've ever interacted with has prioritized their known issues. Some teams had strong policies about not releasing software containing problems of more than a certain assessed severity; others just did what they could to get the best practical product out by the fixed deadline. But they all had their bug lists, and even in the best companies some of the bugs wouldn't get fixed the same year; some bugs would end up never actually fixed and would just be found to have "gone away" when something else changed.
For example, I worked as the sole active software developer on a scientific package (several years ago.) I kept comprehensive bug lists -- everything I found wrong, I created a report for. Some of the earliest bugs that I found were still there when development was abandoned about 3 years later.
Does that mean that I was a bad software developer who should never have released anything until the bug-list was completely clear? (If so, perhaps I should have been less scrupulous as to what I recorded!). But this was a scientific program: for some of the bugs I recorded, there is (still) no known solution for.
For example, for the particular kind of values we were summing together, there is no known way to find the global minimum of the equation (which was important to the program). There is no known way of finding general global minima even in 3-dimensional space, and this program was working in 32 to 84 dimensions. Indeed, one can prove that
*in general* there *is* no way of finding global minima even just in 2 dimensions. So the task might not have been -possible-, but perhaps if some world-class complex function analysts had worked on it for a couple of hundred years, they might have been able to find the global minima of those -particular- equations. So down it went on the bug list: the program was incomplete and could produce potentially incorrect results; there might in practice be a -better- search method, and there might in theory be a complete search method. Mind you, the hypothetical complete search method, if it existed at all, might have required about 10 the the 85th calculations... But it was there on the to-fix list, with an action item of hiring a bevy of top mathematicians to spend several decades focused narrowly on improving one small portion of the program functionality.
Some day you should look at the mathematics of proving program correctness (even restricting to cases where the "right" answer to each subsection is known ahead of time.) And look at industry standard bug rates. Even just one bug per thousand lines (very very low) applied to a program the size of MS Windows (millions of lines of code) implies thousands of bugs -- and even with the best industry tools, teams that can achieve bug rates that low are extremely rare. Companies can be very cautious and -still- have large numbers of known bugs, if their code base is large enough.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.