Slashdot Mirror
Windows 2000 Has 65,000+ Bugs
According to a story on ZDNET, Sm@rt Reseller got an internal MS memo that says Windows 2000 has 63,000 "defects" (if you read the article the number goes up to 65,000+ bugs), and that's the same Windows that will be out on Feb. 17! Is this what MS suggests putting on people's workstations and installing on production servers? What do you think?
So instead of correcting the problem and pushing back the release date, Microsoft is going to release Windows 2000 upon thousands of unsuspecting retailers, and millions of unsuspecting users JUST to meet the deadline. "That's okay, we'll fix it in service pack 1."
The only problem with that is, Service pack 1 is a good 6 months away. In the meantime, what do the users do?
"Our goal for the next release of Windows 2000 is to have zero bugs."
WHO do these people think they're KIDDING? The next release? Okay, we're at Service pack 6 for NT 4. Several of those service packs actually BROKE more stuff than they fixed, and the goal for Windows 2000 OSR2 is zero bugs? Sure, I'll hand it to them - They have the right idea, but:
A) it's more than likely just marketspeak: "This one may have 63,000 problems, but the NEXT one will have zero, enabling you to have fun, and be more productive than ever! Blah Blah..."
B) How about attainable goals? How many people believe in their hearts that Microsoft will put out a Bug-free operating system? There is no such thing. Also, Microsoft is so concerned about market share that they could care less about present problems. "Fix it later."
Market researchers have repeated warnings to their clients against upgrading immediately to Win2000.
Go back about 5 years, replace "Win2000" with "Windows 95", and we have the SAME EXACT situation all over again. (Those who do not learn from history are doomed to repeat it.)
Several outfits have advised customers to wait until Microsoft issues its first or second service pack before deploying Win2000.
*Ahem* - Replace "Win2000" with NT 4.0. Wash, Rinse, Repeat.
-- Give him Head? Be a Beacon?
-- Give him Head? Be a Beacon? :P)
(If you can't figure out how to E-Mail me, Don't.
>According to a story on ZDNET, Sm@rt Reseller got an internal MS memo that says Windows 2000
... then it becomes a relationship that both parties will be happy with. That is what is meant by a "zero-defect" delivery of product.
>has 63,000 "defects" (if you read the article the number goes up to 65,000+ bugs), and that's the
>same Windows that will be out on Feb. 17! Is this what MS suggests putting on people's workstations
>and installing on production servers? What do you think?
(By the way, when is the Extrans going to work again? Taco? Taco? Bueller?)
This "HeUnique" goombah needs a) a little computer science education, b) to read more carefully, c) to sit down and take a deep breath before posting.
First, the ZDNet article refers to 63,000 "defects", but not all defects are bugs. As reading it makes clear, some defects are simply usability issues, some are shortfalls in meeting intended functionality, others are simply things that cause end-user confusion. To equate all these with software bugs that make the product unusable indicates many things, starting with a lack of real-world experience delivering software to end-users, and obviously including no exposure to the product in question.
Of course Microsoft suggests putting this in a production environment. That's what a piece of software achieving release MEANS. Release does not mean the software works perfectly. It means it meets customer or client expectations, which in a properly managed relationship, are equal to the deliverable. If you've led the client to believe they'll get platinum and you deliver brass, that says more about you than the client. But if you say by X we can deliver brass, or we can wait until Y if you insist on silver, Z for gold
I hope that HeUnique doesn't continue to help Slashdot slide into the abyss of adolescent BBS flammage.
----
lake effect weblog
{Network engineer in Chicago--looking for work!}
O.k. the issue I'd like to highlight is the fact that Microsoft has very thorough configuration management software. I don't know what they use, but you can bet your sweet ass it beats the pants off Bugzilla (which I love, don't get me wrong) -- they can afford it and they need it. That being said, it is certain that they have now and have had for years bug tracking resources in their development teams.
The fact that there are 21,000 or 63,000 "bugs" -- for the sake of some degree of objectivity let's assume there are 20,000 actual "bugs" in Window 2000, as tracked by Microsoft's internal bug tracking systems -- that are being announced now implies that there were (let's say again) very close to 20,000 (or more -- this is assuming they've been busting ass to fix them since they went "gold") bugs that were in the bug tracking system when the product was shipped to manufacturers.
This is in spite off the resources they are claiming they have used to beta test the product! [ I should note that beta testing is rarely testing in a production-load environment, so it is not as useful for finding bugs likely to emerge in Real Use (this is not an indictment of Microsoft, it's just the unfortunate truth) ] I can only imagine how much of a piece of shit Win2k was when it went out for beta testing...
We know why they ship buggy product (two primary reasons -- to meet shipping deadlines, and because a "perfect" product has no need for upgrades :-) ). That they ship buggy product for exhorbitant prices is unforgiveable (ignoring even the marketing that claims otherwise as I'm trying hard to do). That they spend as much as they do on testing and still release shitware is an indictment of their development process -- though what they're doing wrong is open for holy war ("talk amongst yourselves...").
Bottom line: a large number (~20,000) bugs were most likely known, IN THE SOURCE CONTROL SYSTEM, at the time the product was shipped to manufacturers.
Draw your own conclusions.
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
In the Linux kernel source (2.2.12), I found "XXX" 1,561 times out of approximately 2,000,000 lines of code.
Now, Win2k supposedly has 35,000,000 lines of code, or 17.5 times what is in the linux kernel. Therefore, to compare, 1,561 * 17.5 = 27,318.
Looks like the kernel source is right in line with Win2k as far as BugBug or XXX comments go.
In addition, as a coder, I do liberally sprinkle with XXX. Everytime I hit something that I realize I could do better or stub something out for now, I XXX. The code will work and be considered bug free (depending on the stub), but there remain XXX's to remind myself that I wanted to do something better there. In other words, a lot of my XXX's are for rainy days when I have time to improve code instead of just chugging to the next deadline.
Now I'm not supporting Windows here, but I hate biased poll questions, and that's exactly what they had. "Do you plan to buy Windows 2000 - an OS with 65,000 known bugs?" Come on, that sounds like the kind of question Microsoft would ask if it was about their competiton.
Though, Microsoft has spread enough FUD that maybe it's time for some Anti-FUD like this. In that case, could it maybe be a little less obvious?
--
Win dain a lotica, en vai tu ri silota
But on the plus side: Notepad is unbundled from the OS, and now availble for only $99 from local retailers.
1) That's what the windows 2000 beta is. However Microsoft don't get people to try to fix the bugs themselves, that's up to their thousands of debugging and source reading people.
2) Microsoft already has a kick ass debugger - not free though. And the debug symbols for Windows 2000 are readily downloadable my MSDN subscribers or Beta testers. Core dumps (or any crash in windows) again can be debugged. You have many options. One is if you have VC++ installed, it'll bring up a window asking you if you want to debug, then you can do step-step debugging. ALso Dr Watson can collect information like your "core" dump files and store them. BSOD are also documented on MSDN and MS Support, including information for how to connect to a machine during a 'bugcheck/bsod' and debug the BSOD.
Windows 2000's DDK (Driver Development Kit) comes with several 'build' enviroments for creating and testing drivers. Including the 64bit build enviroments for Win64.
3. NT is theorectically hardware independent, very little has to be rewritten because of the HAL. However the market wasn't very good for MIPS, ALPHA, SPARC or PPC and those ports kind of died.
Without being explicitly pro or con Microsoft, a few things Microsoft could do to make its bug-squashing chores easier within the context of a closed-source operation:
1. Run a bugtraq-style mailing list. Even without the source, there are a lot of people with extensive enough knowledge of Windows OS internals to provide at least some outside insight as to why a particular bug might be occurring.
2. Make a really kick-a#! debugger readily and freely available in the tradition of gdb. Make things like core dumps and other Unix diagnostic niceties standard, to allow people the ability to pull something useful out of the rubble for a postmortem. Obviously, within a closed-source paradigm, some method would be needed to ensure that only Microsoft programmers could dissassemble the cores; encryption, maybe? (and yes, I know there's a joke in there somewhere about a user's disk filling up with core dumps within five seconds, but I'm leaving it alone!)
3. Two words: architechture independence. While I have no hard facts to back this up, I would imagine that, because Microsoft is concentrating on a single hardware architechture, quite a bit of assembley code is sneaking its way in. Assembley code is good for speed, but (although there will be doubtlessly much debate about this) the fact remains that the more architechture-independent code is in a product, the more stable it is. For further proof, look at early OSs (such as MSDOS 1.0) that are coded significantly in assembley, and something like BSD Unix, which is about 80% architechture independent - the only assmbley routines are device I/O, memory mapping, and other such things. If Microsoft went to an architechture-independent approach, it could make its debugging job a lot easier.
I know that many people here will probably flame me for giving honest suggestions to Microsoft, but politics aside I think that if Microsoft were to take up the practices I outlined above, along with similar practices common in the Unix world, it would make all our lives a lot easier. After all, Microsoft is going to be here for quite a while, and the less pain that existence inflicts on us, the better.
It's so bad, in fact, that people expect the products they're buying to be defective. I use both Windows and MacOS, and am not at all phased when the box locks up and I have to hit the reset switch. But now that I think about it, shouldn't I be?
Consider also RedHat, which has been around for a much shorter period of time. Their Bug reporting system reports a total of about 1640 new, reopened, and assigned bugs with 140 bugs new this week. If Redhat had the same user base as windows, their bug system would likely report similar numbers.
Time and experience with the new OS will be the true test of its stability. Just think of how the bug counts will grow once it's been released to the rampaging mobs!
And they claim there's no 16-bit code left in Win2000...
:-))
(Please don't moderate this if you're not a programmer.
MSK
If you were to add up the bugs in Linux that Microsoft would consider a bug (eg. would be in their count) I bet it would be the same, if not more.
These bugs aren't show stoppers, gee 65K ooh that is heaps, the damn thing won't even boot! Not.
These bugs are more like, on this system with X hardware when running along side with this hardware and when running X's software package called Y, windows 2000 will have a pixel out of place.
A majority of bugs in the 65K are very much like this. Bugs that cause potential problems with people not having HCL hardware. In fact I wouldn't even call most of them 'bugs' as such, since in the traditional sense they aren't - unless like Microsoft you want to make sure Windows 2000 works on the billions of hardware and software configurations out there.
And this statement "Is this what MS suggests putting on people's workstations and installing on production servers? What do you think?" is just so typical of what everyone's reaction around here would be. So blind, arrogant and ignorant, and very predictable. It's the type of knee jerk reaction which has made me so bitter with the Linux community over the past 3 years.
In many ways the Linux community acts too much like creationists/fundamentalists, no matter what science comes up with there's a knee jerk "oh we're not all monkeys you devil worshipping bastards" reaction.
Windows 2000 is by far the most stable and featured operating system Microsoft has written to date. I have NEVER seen a BSOD on any of our production machines at work.
I admit, on a 3 year old K6200 at home, I have seen around 6 BSOD during the beta testing phase, around the same amount of kernel panics I get on the machine as it seems, so i suspect my hardware is stuffed.
In the last few months of the beta, Microsoft was only paying attention BSOD (bug check) bug reports, even though other bug reports (like cosmetic or hardware compatabilty reports were still being sent in). This isn't incompetance, it's good management.
There's a point in a product's life cycle when it has to ship or never gets shipped. I mean, how many bugs has Redhat 6.1 had since it's releast, heck how many security problems has it had since it's released?
Microsoft at least plan these out, and while they're working on Windows 2000, they also have very good ideas of what the next service pack will do, and even what the next version of Windows 2000 will do. An example of one of these 'feature' bugs is load balancing COM+ services, this was a feature that never got finished in time, but has been moved into the service pack. It's by was by means essential, so it'll get updated later.
Microsoft has tried to do everything they can in Windows 2000, and it's no suprise that they'll be problems and things they don't get done, but that's software! Things that don't get done, get done later in a service pack (or option pack), and bug fixes are the same.
Despite these 65K bugs, Windows 2000 is still stable and will work for most people.
Anyway look at it the other way round, 75% of people _won't_ have compatability problems according to this article. That's not bad for an OS upgrade as HUGE as Windows 2000.
In fairness, keep in mind that "defect", or even "bug" for that matter is a very broad term.
I myself am a QA tester, although not in the Windows group. I've entered many, many bugs that were Postponed or Won't Fixed that, honestly, probably didn't deserve to be fixed. Things like "such and such a static is too long for this control" or "we should notify the user if x, y, or z happens". Little niggly things in other words.
Keep in mind that a "bug" is anything a tester doesn't like, including personal design preferences. It isn't necessarily a flaw that would interfere with use of the product. If a bug is of that kind, then it's smart for a time-starved group to Postpone or Won't Fix the issue.
-matthew Priestley
mpriest@microsoft.com
-konstant
Yes! We are all individuals! I'm not!
-konstant
Yes! We are all individuals! I'm not!