Pay Microsoft to fix Windows Viruses

[gore]

Originally posted here by Ghost_25inf
Very good points, but I dont think that Micorsoft is overlooking the issue that they need to come up with new patches. Yes if the Engine (OS) falls out of the car then yes they need to fix it, but if you have kids throwing nails on the road (Crackers, Hackers) then I dont see how the company is responsiable to come up with a New tire resistant to nails.

You've given me quite a bit of thought. I'm going to open a hardware store. If you ever come in I'm going to tell you the hammer I have costs more because it's better and easier to use.

When you come in 20 minutes later because it has broken I'm just going to tell you, "You used a nail that was incompatible with my comanies hammer" and when you get mad, I can say you you can buy MS (MegaStore) nails for just over the price of retail.

Not my fault you went to another vendor for nails, I thought you wanted an integrated solution right? Your fault, not mine, now pay for your **** and get the hell out of my store.

[MURACU]

Here is an interesting look into the developpement of the new windows os. It is from the point of view of the developpement teams and so much from the marketing or public relation teams. It makes interesting reading.
source windows itpro

The parts that I found the most interesting are
1: the number of lines of code involved in windows is over 50 million. I think the space shuttle uses about 500,000 lines of code for its computer systems. Given the basic rule of 1 bug in 1000 lines of code, (i am being overly optimistic), that makes about 50000 bugs before testing.
What should be remebered as far as this discussion is concerned is that when the OS is released all the bugs and expliots are there from day one. They are not the result of everyday wear and tear.
Lets retake the car example again. GM brings out a car where when you are driving along at 55 MPH and turn on the airconditioning the air-bags no longer worked. Which would you expect, that GM recall that series of car or that they would say "Well there is a security problem with this series of car but for a small subscription we will fix it for you"? I know what i would look for.

2: how the bugs are treated in the developpement section. I can understand how

During the mad dash towards RTM, the heartbeat of the project is the War Room, where the War Team meets two to three times daily, five days a week--six days a week now that Windows Server is in its final days of development. "The War Team goes over reports and metrics to see where the project is at every day," Thompson told us, an understated explanation that did little to prepare us for the horrors of the War Room. "Everything is automated now, but back then we came in and passed around paper reports that showed us how we were doing. There were, maybe, 15 to 20 people in the room. Now it's very different."

It sure is.
For Windows Server 2003, the War Room is run by Todd Wanke, who we eventually found to be an amazingly likeable guy. However, in the hour-long War Room sessions, Wanke rules with an iron fist, asking trusted lieutenants for advice here and there, but moving the process inexorably forward with little patience for excuses or, God forbid, product team members who don't show up for the meeting .
Here's how it works. Every morning at 9:30 a.m., representatives from various Windows Server 2003 feature teams meet to triage bugs. They file into conference room 3243--whose exterior sign has been covered up by a handwritten note that reads "argument clinic"--in building 26. There's a large conference table in the center of the room, but most of the participants have to stand, and the room is always overflowing with people. On the day we attended a War Team meeting--the first time any outsiders were allowed to view the inner sanctum for Windows Server, and only the second time overall during the entire development of NT and Windows--the team progressed through about 50 bugs, most of which were simple branding problems, though I've agreed not to discuss the specifics of any bugs discussed that day. (Because we attended War Room very late in the development of the product, and the biggest outstanding issue was the last minute name-change from Windows .NET Server 2003 to Windows Server 2003.)

Every bug is logged in an incredible bug tracking system, each accompanied by a dizzying array of information about how the bug was found, which customers, if any, were affected, and a complete history of the efforts made to date to eradicate the problem. Wanke moved quickly through the bugs, calling out to members of specific feature teams to explain how the fixes were progressing. If there are one or more bugs in IIS, for example, a representative of the IIS team needs to be present to not only explain the merits of the bug, but whether customers are affected, how the fix might affect other parts of the system, and how soon it will be fixed. This late in the development process, bugs are often passed along, or "punted," to the next Windows release--Longhorn--if they're not sufficiently problematic.

The atmosphere in War Room is intimidating, and I spent most of my time in the room, silent and almost cowering, praying that Wanke wouldn't turn his attention to me or my group. Heated argument and cursing are a given in War Room, and the penalty for not being on top of your bugs is swift and cruel ridicule from the other team members. The most virulent treatment, naturally, is saved for those foolish enough to blow off a War Room meeting. On the day I attended, one feature group had four of its bugs punted to Longhorn because they had failed to shown up for War Room. When someone argued that they should be given another day, Wanke simply said, "F#$% 'em. If it was that important, they would have been here. It's in Longhorn. Next bug."