I can't read the original article, It's been Slashdotted to death. But I think I can make a pretty good guess as to what happened.
First off, we host Bugtraq, not NTBugtraq, which is Russ Cooper's list. (Any chance we can get that fixed in the story intro? Anyone know if the same mistake is in the original article?)
Secondly, I'm constantly amazed at how people mis-read our stats page. The Linux aggregate stats are the total of all unique bugs across all the various distributions we track. It's supposed to answer the question "How many Linux-related bugs were there that year." It's based on things like which distro ships a particular package, and when that package is found to have a hole, it also gets attached to the distro. This is so you can look up your distro, and see what bugs you might need to patch.
Take a look at the top of the page, our script hasn't been running since August, when we switched from Roxen to Apache. So, we're missing the whole last quarter of 2001 stats.
Regardless of anything else, using these number to declare that one thing is more secure than another is a mistake. Based on our numbers, why didn't they declare that everyone should run MacOS for security? Or that if you want to be more secure, run Debian instead of Win2K?
Let's see, Win2K was said to have about 60k bugs, right? So if they work every day of Feb, they need to fix roughly 2150 bugs per day.
1) It is a flase assumption that 65K+ records in their bug tracking database where all bugs. These are just reports and have not been independently verified or filtered for feature requests or duplicates. What "are" really bugs can also be a "specification bug", not a technical one. For example, you click the start button it's supposed to "fade in with speckles" but instead it displays with no effect. To the end user it still functions perfectly. To the product development team the feature wasn't implemented correctly.
2) You are assuming that over the past two years (when this ambiguous "65K" number got thrown around) that they have done nothing to resolve the bugs in Win2K. This obviously overlooks the fact that the NT5.0 codebase is much more mature thanks to ongoing development that has resulted in multiple service packs and WinXP.
3) The point of this month is to focus on bug fixing, not "let's fix all the bugs that we created 5 years ago". It's like me saying, "I'm going to take a week and do spring cleaning on my house" and assuming that means that I never cleaned my house on a regular basis.
4) If there really where 65K bugs, each programmer would be responsible for fixing 1.5bugs within the month (appx 40,000 programmers). Of course, this is severely trivializing the issue, but reminds us of the awesome resources MS has at it's disposal.
Also, Win95 is mainly relevant when discussing the GUI and DirectX. Most all of Win2K's technology is based on NT, which is an older codebase. (the first beta was in 1992 I believe)
Lots of other posters have mentioned pieces of the puzzle, so I risk being redundant here. But, it seems the whole equation goes something like this:
1. If each box only handles a part of the web, it is possible that most of the space on it's drive (or drives) are wasted anyway.
2. If disk latency means that cpus spend idle time, eliminating that latency means more throughput per box, hence fewer boxes. More money spent on DRAM, less money spent on CPU, power supplies, etc.
3. Even with same number of boxes, lower power draw, smaller and/or fewer UPS(s) required. With fewer boxes, even more reduction.
4. Which leads, of course, to lower A/C bills during the warm weather.
5. Fewer boxes, fewer pieces, whatever, means fewer things breaking. The impact of a single outage may be greater, but, from the cost standpoint, you need fewer man-hours to manage the outages, fewer spare-parts, etc.
6. Lower medical expenses from sysadmins going insane due to the noise from all those drives and the associated larger power supplies and extra cooling fans.
OK, that last item is a stretch, but how many sysadmins are more than a step from insanity anyway?
I think I now understand why Davies was so hung up on the issue. He had developed a one-node packet switch in the UK before the ARPANET was deployed. Unfortunately, the UK would not provide enough financial support to Davies so that he could expand his one-node switch into an operational network. Had they done so, the Internet might have been born in the UK; instead his work was stalled and could not go forward. This must have been very frustrating for him.
That would have been interesting. Britain as the home of the Internet.
The possibilities of an alternate history are fascinating.
In any case some of it is a matter of research being done in parallel, which means that these sort of debates will take place as a matter of course.
I'll avoid most of my comments about your choice of language because most of it is of a political nature, rather than practical one; however, I really wouldn't suggest trying to make a massively multiplayer game with a language you're unfamiliar with. It's quite an undertaking even with a language you know. I know; i'm working on one.
As for the networking code transparency, this one seems fairly obvious to me.. Just keep a datastructure containing all the changed or "tainted" objects as you go. Make mutator functions of your classes set objects as tainted. Then, just do the networking updates once or twice every time through the main loop (assuming it's in the same thread. Otherwise, you can implement something that might end up being a little more efficient).
As for updating only what the player needs to be updated on, this seems like a question of algorithm efficiency. I don't know the specifics of your game, but with most massively multiplater games, transmitting the entire world state, or even the entire list of changes to every client, every cycle would be insane. So, you have to only update the section of the world that the player can see. How to do this well depends on the internal structure of the world, and what sort of stuff the player can "see". If the game is room-based, then this is easy. If the player can always just see a specific size circle or rectangle around him, this is also easy (each event can check distance to all players in its regeon). If it works like most RTS with arbitrary viewing areas, then you might have to be a little more clever. Whether this is even much of a concern is really a question of the number of people supported, and the expected hardware this'll be running on.
Slashdot Mirror
Sigh...
I can't read the original article, It's been Slashdotted to death. But I think I can make a pretty good guess as to what happened.
First off, we host Bugtraq, not NTBugtraq, which is Russ Cooper's list. (Any chance we can get that fixed in the story intro? Anyone know if the same mistake is in the original article?)
Secondly, I'm constantly amazed at how people mis-read our stats page. The Linux aggregate stats are the total of all unique bugs across all the various distributions we track. It's supposed to answer the question "How many Linux-related bugs were there that year." It's based on things like which distro ships a particular package, and when that package is found to have a hole, it also gets attached to the distro. This is so you can look up your distro, and see what bugs you might need to patch.
Take a look at the top of the page, our script hasn't been running since August, when we switched from Roxen to Apache. So, we're missing the whole last quarter of 2001 stats.
Regardless of anything else, using these number to declare that one thing is more secure than another is a mistake. Based on our numbers, why didn't they declare that everyone should run MacOS for security? Or that if you want to be more secure, run Debian instead of Win2K?
Let's see, Win2K was said to have about 60k bugs, right? So if they work every day of Feb, they need to fix roughly 2150 bugs per day. 1) It is a flase assumption that 65K+ records in their bug tracking database where all bugs. These are just reports and have not been independently verified or filtered for feature requests or duplicates. What "are" really bugs can also be a "specification bug", not a technical one. For example, you click the start button it's supposed to "fade in with speckles" but instead it displays with no effect. To the end user it still functions perfectly. To the product development team the feature wasn't implemented correctly. 2) You are assuming that over the past two years (when this ambiguous "65K" number got thrown around) that they have done nothing to resolve the bugs in Win2K. This obviously overlooks the fact that the NT5.0 codebase is much more mature thanks to ongoing development that has resulted in multiple service packs and WinXP. 3) The point of this month is to focus on bug fixing, not "let's fix all the bugs that we created 5 years ago". It's like me saying, "I'm going to take a week and do spring cleaning on my house" and assuming that means that I never cleaned my house on a regular basis. 4) If there really where 65K bugs, each programmer would be responsible for fixing 1.5bugs within the month (appx 40,000 programmers). Of course, this is severely trivializing the issue, but reminds us of the awesome resources MS has at it's disposal. Also, Win95 is mainly relevant when discussing the GUI and DirectX. Most all of Win2K's technology is based on NT, which is an older codebase. (the first beta was in 1992 I believe)
It doesn't sound like open source intelligence at all.
The sources are still secret - but some of the results are made public faster.
But did anyone really expect open intelligence sources?
Lots of other posters have mentioned pieces of the puzzle, so I risk being redundant here. But, it seems the whole equation goes something like this:
1. If each box only handles a part of the web, it is possible that most of the space on it's drive (or drives) are wasted anyway.
2. If disk latency means that cpus spend idle time, eliminating that latency means more throughput per box, hence fewer boxes. More money spent on DRAM, less money spent on CPU, power supplies, etc.
3. Even with same number of boxes, lower power draw, smaller and/or fewer UPS(s) required. With fewer boxes, even more reduction.
4. Which leads, of course, to lower A/C bills during the warm weather.
5. Fewer boxes, fewer pieces, whatever, means fewer things breaking. The impact of a single outage may be greater, but, from the cost standpoint, you need fewer man-hours to manage the outages, fewer spare-parts, etc.
6. Lower medical expenses from sysadmins going insane due to the noise from all those drives and the associated larger power supplies and extra cooling fans.
OK, that last item is a stretch, but how many sysadmins are more than a step from insanity anyway?
I think I now understand why Davies was so hung up on the issue. He had developed a one-node packet switch in the UK before the ARPANET was deployed. Unfortunately, the UK would not provide enough financial support to Davies so that he could expand his one-node switch into an operational network. Had they done so, the Internet might have been born in the UK; instead his work was stalled and could not go forward. This must have been very frustrating for him.
That would have been interesting. Britain as the home of the Internet.
The possibilities of an alternate history are fascinating.
In any case some of it is a matter of research being done in parallel, which means that these sort of debates will take place as a matter of course.
I'll avoid most of my comments about your choice of language because most of it is of a political nature, rather than practical one; however, I really wouldn't suggest trying to make a massively multiplayer game with a language you're unfamiliar with. It's quite an undertaking even with a language you know. I know; i'm working on one.
As for the networking code transparency, this one seems fairly obvious to me.. Just keep a datastructure containing all the changed or "tainted" objects as you go. Make mutator functions of your classes set objects as tainted. Then, just do the networking updates once or twice every time through the main loop (assuming it's in the same thread. Otherwise, you can implement something that might end up being a little more efficient).
As for updating only what the player needs to be updated on, this seems like a question of algorithm efficiency. I don't know the specifics of your game, but with most massively multiplater games, transmitting the entire world state, or even the entire list of changes to every client, every cycle would be insane. So, you have to only update the section of the world that the player can see. How to do this well depends on the internal structure of the world, and what sort of stuff the player can "see". If the game is room-based, then this is easy. If the player can always just see a specific size circle or rectangle around him, this is also easy (each event can check distance to all players in its regeon). If it works like most RTS with arbitrary viewing areas, then you might have to be a little more clever. Whether this is even much of a concern is really a question of the number of people supported, and the expected hardware this'll be running on.
Hope that helps,
Bob