
Windows 2000 Has 65,000+ Bugs 596
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?
Re:bugtracking and product release (Score:1)
Actually, I've used Microsoft's internal bug tracking system, and it's basically just a cheezy little database comments type frontend they wrote themselves, much like Bugzilla. Of course, it's windoze software, not a scalable, web based thing like Bugzilla.
Bugzilla actually is somewhat better IMO, though the two are about equivalent in most respects. Actually, they're nearly identical in practice. Bugzilla has far superior bug dependency tracking, with the dependency graphs and such, which puts it on top.
Microsoft's "advanced statistical analysis tools" for their bug database are also pretty much describable as "a cheesy excel spreadsheet with the database link business." Nothing fancy or anything.
Re:come on guys (Score:1)
You are the Sys. admin of a big company, and you decide to install Linux with kernel 2.3.42 in a production server (note: this is a development kernel!). Now go ahead and tell that to the upper management. You'll be fired in 60 seconds...
Unlike your example with Mozilla (or in my example - Linux) - those bugs are NOT being published. MS doesn't tells you "ahh, with IIS 5.0 we got this error and that error" - you'll find that when you have BSOD or your system won't work well..
In Mozilla or Linux - you got a bug list (in the Linux example - check Alan Cox TODO list to see what I mean) - so you know whats right and whats wrong. With MS Win 2k - nada.
And this, my friend, is the difference..
Re:Windows 2000 has over 63,000 bugs (corrected) (Score:1)
From my past experience, I know that MS underestimate bugs, so I really think that "potential issues" are bugs. Maybe not a serious ones, but still - its bugs..
Re:In fairness (Score:2)
There is an extra name given to anything that is actually serious (such as any form of broken functionality, security related or crashes) called showstopper. The stuff that goes into the bug database can refer to anything from , "there is a mispelling in this spec" or "overactive assert in the debug build" to the showstopper class bugs. On shipping, there were no showstopper bugs, which was the criteria.
In the end, I suggest people use the product for a change, and see for themselves that it is quite stable.
Re: bugs in OS not dangerous ???!!! (Score:2)
And still the everything works quite well... I get my salary every month even though my bank is using MS products.
Don't be too sure about it -- banks don't run any of their actual operations on Windows. If they will switch to Windows in some "upgrade", handled by the next generation of managers, we will all start having a lot of questions, where are our money.
Re:Spelling. (Score:2)
I'm a linux user
No, you are not...
- it's great for me as a SysAdmin, wonderful server platform for internet applications, and so on. But desktops? Bullshit. Come back when you've got a productivity suite HALF as good as MS Office, or even WordPerfect.
^^And that was the proof -- WordPerfect runs on Linux, troll.
The appropriate place to run Win 2000... (Score:2)
New XFMail home page [slappy.org]
Re:In fairness (Score:2)
On the "betatest" newsgroups, there are literally thousands of posts with testers posting what they consider "bugs" which, in my opinion, are nothing but "niggly" things that doesn't deserve any attention.
I think this is a really good example of where open source has some advantages. Little "niggly" things get fixed by the person they're "niggling". ;-)
Re:In fairness (Score:2)
--Chris
If you are going to be pedantic (Score:2)
--
I agree but... (Score:2)
--
difference (Score:2)
--
Re:Spelling. (Score:2)
Re:Good poll? (Score:2)
Re:for every bug you find (Score:2)
6,535,000 cockroaces ain't all that bad. They're crunchy, full of protien, and just add milk!
Fool. (Score:2)
(Note: hit the link on the comment ID number and you can see it's moderation history.)
why am I not surprised? (Score:2)
___
Re:Not shocked (Score:2)
windows 2000 hasn't even been released, redhat's bugzilla tracks bugs through about 6 releases.
i know the pundits refer to linux as "new and untested," but a significant percentage of w2k code is completely new and unproven in a production level environment.
What will they say next? (Score:2)
Only three weeks ago, I attended a seminar hosted by a company selling "fireware solution" which runs on NT. The speaker was telling us that their "solutions" will run on W2K.
In the Q & A session, I asked the speaker if the company has any plan to port their wares into Linux, and you know what that guy said to me?
"We have no plan to port any of our product to Linux, and we will never do so, because Linux is too buggy."
Yeah, this is exactly what the guy (supposingly the CEO of the company) said, and his company was supposed to be one of the "biggest NT supporter" in Asia.
With W2K having over 28,000 "features" that may give them "real problems", I truly wonder what the guy will say next.
On the relatively 'bright side' (Score:2)
However, there are an estimated 28,000 Real Problems (TM) still in the software. This, is still quite disheartening. I for one am delaying deployment of Windows 2000 Professional on workstations until it's reported that the final version (give or take 4 service packs) is relatively stable.
And for all you IT managers out there, make sure you develop a stable method of deployment before updating all your NT 4.0 boxen, unless you want to deal with a huge heap of problems. Use common sense.
--
Please note (Score:2)
Also Microsoft has a history of saying that things anyone else would call a bug is not a bug.
Glad I am not planning to use this...
Cheers,
Ben
Re:How many bugs are in Linux? (Score:2)
When you say linux, what do you mean? Is linux just the kernel, the GNU binaries as well, or the entire distrobution?
See it's hard to say what linux IS. Some distrobutions have more bugs than others, and some kernels have more bugs than others. Also add to the fact that linux is being developed and debugged 24/7 worldwide. Look at the developer map on www.debian.org and see what I mean.
I can assure you from working on many projects, some open source some closed source - that linux's development cycle can't be held to the same pattern as MS windows, HP UNIX, etc. Linux is a distributed and large development effort with massive talent and harsh peer review. I wrote a small piece of code that was bug free. ( Very small i.e. near useless code is the only code that can bug free. ) And I still got email about a possible buffer overflow that could happen when the library was used with 'application X'.
Don't try and see releases as linux as a finished product, instead view it as a work of art - always adapting, always changing, always improving...
Re:Debian appears to have 10,000 (Score:2)
The current list of "release-critical" bugs (that is, bugs that must be fixed before release, is available from here [debian.org].
Of course, there is a huge fluff factor here. Debian uses the bug-tracking system to track things that aren't really bugs, there are bugs that weren't really bugs, and so on.
Re:Debian appears to have 10,000 (Score:2)
True, but a very high proportion of the bugs in Debian are with "non-core" parts of the distribution (things that wouldn't be distributed with a Microsoft OS). Many bugs are just users being "niggly" as well. A significant number of "bugs" are in fact proposals for policy changes. Not much difference in fact (except that Debian doesn't hide the problems).
Also, Windows 2000 has some HUGE features that debian doesn't have, like Active Directory.
Debian has some huge features that Win2000 doesn't have, including a complete development environment, full server functionality, lots of powerful applications, etc. etc. etc. The upcoming Debian release will span 4 CD's of binaries. Big as Win2000 is, if you take all the code that Debian distributes, Debian is far bigger.
But these comparisons wouldn't be possible except a memo happened to fall into ZDNet's hands. Wouldn't it be nice if Microsoft made its bug tracking database public?
Re:In fairness (Score:2)
I really really doubt this is actually true in the large sense. First, there are non-programmer users who simply can't fix the bugs (yes, they must be eliminated like the worthless deadweight they are, because knowledge of C is the only skill worth having). Secondly, there are technical users like me who simply don't care about having their own little private code fork that has to be maintained separately (if the original source was kept around at all) who have a very much accurately-formed impression that a diff from Joe Random Luser will be ignored, and generally don't feel like going through the bureacracy of whatever ad hoc QA system, if any, there might have been set up. KDE's bug reporting system is illustrative here: you must send an email that you must hand-format, with a module name that you must guess at, and you get a nastygram if it doesn't fit the formatting criteria. God forbid you get an actual response.
Yes it's possible to fix it yourself. It just hasn't become any less of an irksome chore.
Re:A suggestion to Microsoft-emulate commercial Un (Score:2)
Was NT ever ported to SPARC? I can't imagine anything would ever make Sun happier than a working port of NT to SPARC hardware. Sun considers Solaris as a loss-leader, it just continues to flog it because NT's scalability has always ben too laughable for the big servers Sun wants to sell. That and McNealy's ego.
Re:No thanks. (Score:2)
Microsoft's Bugtracking System... (Score:2)
Re:Microsoft's Bugtracking System... (Score:2)
Re:Oh, stop being so predictable (Score:2)
I hope you are not confusing it with the "Slashdot Community." I would dare say that a large number of real linux hackers have great disdain for slashdot, for a long list of reasons including those you mention.
Make sure you are disgusted with the right people for the right reasons.
Re:Spelling. (Score:2)
I don't want to pick on Linux but I hate being on the receiving end of this sort of thing.
Q: Your software breaks when I do X.
A: We never do X. You are weird. Don't do X. Now go away.
There were many deficiencies in early UNIX kernels, mostly in error checking/recovery and algorithms that scaled poorly. At the time, there were legitimate reasons for it. It was a research operating system that had restricted resources, keeping things simple was important. That was 25 years ago.
Today, I can think of no good reason why a modern operating system should not be able to handle very large numbers of threads/processes/sockets/files without crashing or exhibiting pathological behaviour. Fast and small is nice but not at the expense of reliability and scalability.
Nothing against you... (Score:2)
Hah (Score:2)
That being said, I might argue that some of the recent pressures behind Linux's (and other Open Sourceish products) recent popularity is symptomic of a reversal process (just a hint of it). Though Open Source is not the answer per se (and I doubt it ever will be), it indicates that at least some customers and businesses are growing tired of MS's (et. al) antics, considering alternative solutions, and "Open source" software is, unfortunately, one of the few alternatives that still stands. It has little to do with the fact that Linux is "free"; many have come to realize that software isn't an end unto itself--it is a means to an end, merely a tool to be used. It is a tool that doesn't wear out, and hence doesn't need to be upgraded every year. As a result, software can, and should, become more STABLE and CONSISTENT. This allows companies to cut down in costs in many ways. Not only do they not need to buy new software and licenses, but they don't need to upgrade computers so frequently either. In addition, this kind of stability allows the employee to become more familiar with his OS/Applications, further cutting support costs and improving efficiency. Likewise, a more stable feature set would allow the software the time to develop such that it actually performs as it is supposed to (every tried embedding documents often? mail merge? Connecting to a windows network (netbios) over dialup and TCP/IP...)
Most companies care little about how much MS (et. al) sells their software and licenses for (even though they're overpriced by most any measure). Nor do they care if the software is propietary (not "free"), for its own sake. It is the secondary and tertiary costs (e.g., support, HW upgrade, employee efficiency, etc.), some of which I mentioned earlier, that cost them dearly. Though most companies have not yet reached the point where they refuse to buy MS, there is definetly significant discontent emerging. Maybe not this year....maybe not next year, but Microsoft can't keep pumping out their same shit indefinetly...
Fixing all bugs? (Score:2)
----
Re:Oh, stop being so predictable (Score:2)
Just because it's "beta" doesn't mean it doesn't work. Just because something has "bugs" doesn't mean they affect you and your configuration. Windows 2000 is very stable by any standard.
----
Re:Customer report == real bug until proven otherw (Score:2)
* Customer reports bug.
* Technician/Developer tries to duplicate bug, and fails.
Besides, not all bugs are "debugged" by fixing the software. Some bugs are marked for workarounds, others become warnings (don't use this with that), and so forth. Unless you have unlimited funds and unlimited time, you can never "fix" all bugs.
(By the way, the "infamous" Chevy Nova actually sold just fine in Latin America. The urban legend that it didn't arose later.)
----
Re:No thanks. (Score:2)
Windows 2000 is the most stable "dot zero" Microsoft release I've ever seen. This report of 65,000 bugs is completely divorced from any reality.
Windows 2000 isn't for the home desktop user anyway. Windows 2000 is for corporate networks, and with some exceptions, only makes sense when it's networked together with other Windows 2000 machines.
----
Re:Showstopper is a flexible term... (Score:2)
----
Ok... (Score:2)
Is that an improvement though? (Score:2)
How does it compare to win98? how about to win98SE?
They're all buggy, and we all know that.
So is it getting much worse withW2k, or is it getting a little better, or is it about the same as the others?
--
grappler
Re:Good poll? (Score:2)
Pope
Another nail in thier coffin. (Score:2)
Micro$erf: So, when are you upgrading to Windows 2000?
Me: When you get the 65K or so of bugs out of the code.
Micro$erf: First service pack will take care of that - a month at the outside. Upgrading then?
Me: Um, no. I'd have to get rid of all the Alphas we rolled out for NT4 first.
Micro$erf: Ouch, tough luck. Want me to call Dell for you? $25K gets you the equivelent -
Me: -of a $10K Alpha.
Micro$erf: Heh, um yeah. But Windows 2000 has Active Directory!!! Dynamic DNS!!! We'll reduce your TCO to new lows, especially for your workstations!!!
Me: Even the Macs?
Micro$erf: Macs? Why would you want a dead architecture?
Me: 'cause we're in publishing.
Micro$erf: Oh well, Macs can get files, and they can print, that's all they need.
Me: K. If you say so. I read in the initial stages of Win2K that it would do MacIP - where is it?
Micro$erf: Upcoming feature. It'll probrably only be $49 or so per client, too. Isn't that wonderful!!!
Me: Beautiful. Really. Y'know, lately I've been playing with Linux, and-
Micro$erf: OH GOOOOOD! We've got another add on for unix-type machines, since we're supporting choice these days.
Me: So they get to participate in Active Directory?
Micro$erf: No, but it helps you migrate NIS into AD. You get to use all the familliar Unix utilities, and you can migrate to NT at your leisure from those nasty old legacy systems. For 149$ a server, you can't go wrong.
Me: Sure, what ever you say.
Micro$erf: See we figured it out and you'l only have to spend umm.... $75K to upgrade. Of course, we didn't include all the new Servers, network switches, WAN upgrades and wasted hardware in that price, but why worry about that?
So when can we expect you to order?
Me: (puts on red fadora, picks up stuffed penguin)When you get out of the psyciatric ward.
Re:HAHAHAHA!! (Score:2)
Gee.. where have I heard that before?
Don't be silly (Score:2)
Only 25000 bugs? (Score:2)
Unsurprised (Score:2)
Programming a system, without Engineering it, works well for certain types of evolving systems. Linux, web sites and prototypes change to quickly to Engineer, but trying to "just type in the code" for a major, static system like the autopilot for a aircraft is murder.
So what I'm saying is, as long as we Program a system and then expect to "freeze" it there will always be orders of magnitudes more bugs than we would like. If we keep insisting on not Engineering software there are only two solutions to making Programmed software more robust:
1) Fix it yourself, as in the Open Source model
2) Pay someone else to fix it, which usually means bying the next "upgrade" cleverly disguised as N-3 bug fixes and 3 new features.
Engineered software costs more to build but costs far less in the longer term. Just look as far as the nearest book on software engineering.
So the question is, why do we tolerate 65,000 bugs? Do we feel responsibly for not paying them enough to fix it? Do we feel bad we can't edit the source for them? Or are we just ashamed we keep buying their crap even if it isn't what we, as Consumers, want?
Re:In fairness (Score:2)
Sure, that's fair, and I'm glad to see this post is being moderated up. On the other hand:
As a coder, I'm not going to go liberally sprinkling my code with "BugBug" comments. That's reserved for something somewhat serious and important. Maybe Microsoft policy is different however. Still, 27,000 things Microsoft's coders think is important enough to mark as a bug, yet Microsoft feels the product is ready for release?? Wow!
oh! I see! (Score:2)
Bugs only get fixed if people care enough to fix them, non-critical bugs might not get fixed.
[ c h a d o k e r e ] [dhs.org]
Never mind (Score:2)
[ c h a d o k e r e ] [dhs.org]
wow (Score:2)
[ c h a d o k e r e ] [dhs.org]
Re:Bogus article (Score:2)
I'll name one of them! (Since I entered at least 3 bugs into that database once-upon-a-time... I've been there...)
It goes something like this:
Title: License Plates out of Date.
Description:
Car has out-of-state plates. Get new ones.
Repro: Look at front and rear of car.
Status:
Resolved - won't fix
Reopened
Postponed
Closed as fixed
Reopened - Assigned to new team member from out of state...
Postponed.
...
Etc etc etc... so on and so forth
(As for the other 62999, I have no idea... but a large number of them are most likely bugs that can't be fixed, because fixing them would break existing applications - such as the "Tab control when positioned with tabs running vertically will not return correct dimensions of space remaining" one that I filed about a year ago...
The thing is, it can't be fixed... apparently (though I never got one of the NT team to tell me how the info could be used), the values it returns are deterministic, and as such, someone could have come up with a calculation to work around the problem, and as such, fixing it would break existing apps.
This is the way it goes, folks - a lot of bugs get entered and can't be fixed because they'd break compatibility with some olde Win3.1 app or something.
Shame really.)
Simon
The Tao of Programming (Score:2)
From The Tao of Programming by Geoffrey James [demon.nl]:
Re:In fairness (Score:2)
65000 bugs is nothing compared to public mentality (Score:2)
The way mass merchandised software is produced today, the public just swallows it, because it's NEW!
"Windows 2000, I have to have it"
I remember back several years ago, when this new revolutionary Windows 95 was being released, people were floccking to the stores getting in line so they could have it FIRST.
Do THESE people care how many bugs there are?
I've always had a beef for commercial software. It was ORIGINALLY designed to be a shortcut for those who didn't know how to code the application themselves.
Now it's the norm...
Now, I can sit in a Technical Support Cubicle in the Cubicle Jungles of a not-so-small software organization based in San Diego [intuit.com] and listen to people whine and complain about what this Software [quickbooks.com] can or can't do.
The only think I can think of, but cannot say, is "Well, this is software that you bought, of course it is not going to do what you want, because YOU didn't create it."
(That was probably off-topic, but I digress)
Back to WIN2K. Like some of the above write-ups are stating, the public will not care if there are PUBLISHED bugs, defects, etc.
There will STILL be people lining the malls, shopping centers, and Software Outlets just to get this defective, bug filled Operating System on their machine.
Just because, the computer public is the computer public. They eat this stuff up and complain about it later.
Bill Gates.... he's a genius, he has marketed to the Lowest Common Denominator.
*Carlos: Exit Stage Right*
"Geeks, Where would you be without them?"
Debian appears to have 10,000 (Score:2)
65,000 outstanding items for W2K seems high, but it's not outrageously high - it's two or three times higher than I would have expected, but that could simply indicate very enthusiastic testers.
I'm *far* more concerned by the hints that suggests the bugs are no longer seem to be orthogonal - service packs are introducing as many bugs as they fix. *That* suggests that the code is on the brink of becoming totally unmaintainable, a very real possibility with a large code base that pretends to be tightly integrated.
Re:I was in "QA" too... (Score:2)
Actually, I didn't read it as a bash, nor was I trying to bash Microsoft myself. Mine was comments based on some time I spent working at Microsoft (actually, DreamWorks Interactive, who is 50% owned by Microsoft--but the work was done at the Microsoft campus).
The two don't mix. While you can have a project that has elements of both, you can't call a system that relies heavily on ad-hoc testing a formal system.
That's not what I was trying to describe. What I was trying to describe was a process which has a formal test plan and formal testers who run through a formal script, combined with automation which can perform certain elements of a formal test plan in an automated environment, combined with testers who were also encouraged to "bang on it" within certain parameters. (Read: "Charles, you're in charge of banging on the ODBC Control Panel as well as performing pages 303-306 of the scripted test plan.")
That is, they use a formal test plan written at the start based on the formal specification of the product, but they also encourage their testers to "play with the project" as well as executing the formal test plan.
As to "beta testers", Microsoft calls them "customers." (Okay, I know--cheap shot...)
Integration has nothing to do with it. Complete specifications with the time to execute tests based on them is the whole issue -- it always has been.
Normally I'd agree. However, it seems to me that once a project reaches a certain level of complexity, due to the O(N**2) nature of certain types of interactions inside a "black box", the amount of time required to execute tests based on a complete test specification may grow to be in the dozens or even hundreds of years.
With Microsoft's Windows 2000 product, a number of the "modules" inside the black box are coded as
So integration *does* have something to do with it: it defines how complex the product's possible behaviors will be, and that ultimately defines how complex the test plan will have to be to completely test the product.
Now if they built this thing in a fault-tolerant fashion, in the way firmware is built for an airplane, they'd build it as a collection of independant modules which use well-defined protocols to communicate with each other. Then the testing reduces to an O(N) problem of testing each module and testing to make sure it communicates correctly with the established protocol.
My guess: Most of the formal group gets dragged into ad-hoc testing --or-- they have incomplete tests based on incomplete specifications that they 'sign off' on when marketing, production, upper-management-in-other-areas, decides that there has been enough testing.
Based on my experience, it'll likely be the latter: an incomplete specification (that is incomplete because of the nature of the product), combined with testers who will close bugs more on pressure from management than anything else.
I'm not disagreeing with you about the nature of the ad-hoc element of all of this. I just wanted to clarify my comments, to make sure that folks here understood that I'm not denouncing Microsoft for not having a formal test plan--I'm quite sure they have one.
I just believe that, due to the way Microsoft elected to build the Windows 2000 product, that the specification and test plan is necessarly incomplete due to how huge the entire product is.
Re:In fairness (Score:2)
I have to concur about this. Realize that any company, such as Microsoft, who uses a formal Q/A program which uses a formal bug tracking system is going to eventually fill that bug log with a lot of niggly little things which frankly don't matter.
For example, one project I worked (a children's game) contained about 50 bugs from one tester who didn't like the color of the eyes of one of the characters. (He claimed they were too brown, and should be bluer.) Each bug report corrisponded to each scene in which the character appeared.
Eventually we scanned all of the art to make sure the eye color was the same, and closed out all of the bugs over the tester's protests.
I still have bug reports in my own bug tracking system covering similar non-issues, "helpful" suggestions, and things like "on-line help manual contains run-on sentence in 3rd paragraph." It's quite possible that the large bulk of the bugs relate to similar on-line content.
What's especially frustrating about such Q/A processes such as the one Microsoft uses is often they will report the easy to spot items, such as run-on sentences in on-line help. But at the same time, fatal, hard to detect crashing bugs will go by unnoticed because the Q/A test plan didn't include a situation which would stress the software in unexpected ways. And with the huge complexity of Microsoft's Windows 2000 product, that's the one that worries me the most: not that the product will ship with 65,000 content bugs, but that the crashing fatal bug which wipes out my hard disk wasn't even detected by their test plan.
Re:I was in "QA" too... (Score:2)
If there is one thing that Microsoft does right, by the way, it's this: Microsoft has separate career paths for programmers, testers, management, and content authors. Unlike other companies, which after 5 years of programming, you're expected to be bumped into management and never program again, Microsoft gives you the option to continue up the pay scale as a programmer instead.
What that means is that the head of the testing team for a large and important product such as Win2000 probably has a hell of a lot of Q/A experience.
Microsoft will also use a formal, specifications driven testing plan that included both a bunch of testers who do more "free-form exploration" of the product, and who do a formal testing which is driven by a script. They'll also be using testing automation.
The only problem with the Windows 2000 product is that it's an integrated operating system--that is, unlike Linux development which uses a Unix-like development philosophy of keeping each of the pieces small and managable, Windows 2000 attempts to put a hell of a lot into one large, monolithic black box. This plays hell on any formal testing plan in that you now have to test every possible interaction of every component of that black box. (Linux, on the other hand, can be tested more easily by testing each component separately, and making sure each component interacts with the standard Unix API correctly.)
The monolithic nature of Windows 2000 means that it will be near impossible to create a complete and full test plan, simply because of the huge number of component interactions within the black box. There's probably just too many conditions to test adequately.
Re:Unscientific comparison (Score:2)
So just because there are about 20,000 BUGBUG lines doesn't really mean much.
Except for the stuff in the service pack ... (Score:2)
Re:Windows and non-x86 platforms (Score:2)
NT was proclaimed to be architecture-independent when it first came out, but one by one all the ports to things like MIPS dropped away - leaving only the Alpha port (until now?)
Re:65,000+, huh? (Score:2)
MS Buyers are truly drones (Score:2)
Obviously there is a significant number of people that are compelled to lap up whatever MS spews out. I had thought the failure of MS Bob was an indication that the public was starting to change its thinking, but it's clear this isn't yet complete.
Maybe someone could forward this on to the DoJ Anti-trust division for use in the trial.
Four Bugs in the release that I know about (Score:2)
A couple bugs in the OS/2 console app emulation used to run older Microsoft console Apps and most importantly, to run the Brief editor. The OS/2 --version of Brief supports long filenames, runs great under WinNT.
One, The Ctrl-S and Ctrl-C keys are trapped and don't get through (this works in WinNT, the OS/2 support DLLs are unchanged in Win2000, it's a bug in Win2000).
Two, The file create function does not work on FAT32 volumes, just gives an error. Open works fine. (So for instance you cannot use Brief to edit a file on FAT32).
The most serious bug I know of it IDE driver doesn't work on Micronics 440FX based motherboards (and maybe others). Very popular in Dual Pentium Pro servers.
Bad metrics (Score:2)
One developer, informed of Microsoft's bug estimates, said all new software ships with lots of bugs but few software vendors are willing to acknowledge this reality. "The fact that Microsoft found that many bugs indicates to me just how thorough their testing processes are," said the Windows developer, who requested anonymity.
It could mean that they have done a really good job of finding the bugs, or it could mean that there are a lot of bugs to be found. It depends on a number of factors. What's the arrival rate of new bug reports? How are the known bugs distributed? How does that distribution compare to the distribution of new code in the system since the last release? How does the bug distribution compare to the distribution of testing effort? We don't know enough here other than to say that if this memo really is from within MS, we have no reason to dispute that they know about this many bugs.
How many bugs are in Linux? (Score:2)
Bug Count != Quality (Score:2)
In short, a hypothetical future statement that w2k has 65k "bugs" and w2k-sp1 has only 33k "bugs" would be a completely meaningless comparison, and says absolutely nothing about the quality of either code.
There is no accurate measure of the "bugginess" of the code, particularly one as complex as w2k. For a very simple code, I may measure bugginess by testing all possible inputs (for example, consider a code with two bits of input, bit A and bit B, whose assigned task is to return (A OR B). If the code returns 0 for A=0,B=0 and 1 otherwise, the code is 0% buggy. If the code always returns 0, it got 3 test cases wrong out of four and is 75% buggy).
We often rely on anecdotal evidence to evaluate software ("We have fixed the problem in the PPP script") and compare different pieces of software but should take numerical measurements (such as this bug count) with a grain of salt.
Re:Oh, stop being so predictable (Score:2)
You might have meant something like
if (Liunx_community & (creationism | fundamentalism))
Re:Is that an improvement though? (Score:2)
Yeah, funny you should say that cause bugs like that do get submitted to microsoft and processed.
I think many of the bugs are more like compatability issues to various hardware and software combinations that "could" arise.
Windows 2000 is inherently more stable because of it's underlying WNT/VMS architecture, so apps won't take down the OS as easily as they could on 9x.
Re:My W2K uptime shows no problems yet (Score:2)
Re:Oh, stop being so predictable (Score:2)
Re:Oh, stop being so predictable (Score:2)
if Linux_community is anything but NULL then your if block is evaluated.
Anyway, I was saying that the knee-jerk reactions everyone has is reminicent of creationists.
Re:65,000 defects - BS (Score:2)
I mean, it would make sense, since heaps of applications leave their COM signatures in the registry after the dll is deleted.
Re:Debian appears to have 10,000 (Score:2)
Also, Windows 2000 has some HUGE features that debian doesn't have, like Active Directory.
Re:Oh, stop being so predictable (Score:2)
65K . . . (Score:2)
_________________________
Not shocked (Score:2)
I think not.
_________________________
Re:Win2k not so bad, Site Server not so good (Score:2)
In all seriousness though, I have found NT4 (SP5) to be more reliable than Win2k RTM, at least with Exchange Server. I get no end of bluescreens and Exception Faults on a Win2k testing box. I don't think there is any garuntee that win2k is more stable until enough people use it to prove it.
Re:Not shocked (Score:2)
Re:How many bugs are in Linux? (Score:2)
Just for the sake of argument, I'll use RedHat 6.1. After a little bit of research, I've found that since it's release, no more than 10,000 complaints have been logged. The number is actually more around 9700, and this certainly counts 'non-bugs' as well.
Just a note, since I'm on topic, is that even though RH has SIGNIFICANTLY fewer bugs, it still releases patch after patch after patch, trying to get as close to PERFECT as it can be.
65,000 bugs on the wall, 65,000 bugs.... (Score:2)
Patch it around
65,000... Hey! The keyboard isn't working! What's wrong with this darn....
Re:Windows 2000's slogan (Score:2)
Might be. It can't get much worse.... Right now, my machines running Windows 98 are as unresponsive as if I'd already poured hot grits down the keyboards. And... darn... I have to run it because I support so many poor schlubs who do not have a choice. If I had my druthers, I'd put them all on one of the BSDs. My BSD systems never go down.
--Brett Glass
Re:In fairness (Score:2)
Still 65000 is a huge number...
As a comparison, Red Hat's bugzilla is currently at about 9700 bugs, about 95% of which are resolved, and some of the non-resolved bugs being non-reproducable; and Red Hat's bugzilla contains the whole system (and powertools). I don't think the 65000 bugs in Windows 2000 include bugs in, for example, Visual C++ (Red Hat's include gcc).
Even if only 20% of the bugs are real, that's way more than any bug ever reported in Red Hat Linux.
I think it's pretty much the same situation if you look at the number of bugs in the bug tracking systems for other Linux distributions, or the various BSDs.
Re:Spelling. (Score:2)
Nowhere in my post did I assert that Linux does not have a lot of bugs. I didn't talk about Linux at all. In fact, I said that I accept the fact that bugs are inherrent in computer science, just like the spokesperson for Microsoft said. I further said that it surprises me that people are far more tolerant of defects in computer software than they are in any other type of product. You should probably pay attention to posts before you reply to them.
My post had nothing to do with Windows vs. Linux or any other OS, it was merely an observation about the state of the software market.
talk about being a troll.
Perhaps you should apply that to yourself.
For comparison (Score:2)
Now you might say that Debian is worse at tracking bugs than MS (ie a smaller ratio of Debian's bugs are known than of Windows's bugs) due to the number of full-time MS employees etc, or you might say that the bug tracking system in Debian is at least as good because of its openness to anyone who would submit.. But those are the numbers for anyone interested.
Also important to note is that this does not include kernel bugs. I would have included them, but I don't know where to find those... Someone please reply if you have them.
News Release from Microsoft. (Score:2)
Windows 2004, to be released in Q3 2005, will have a new and improved core. This core has been heavily tested. Our acquisitions department has been looking at the proper target [linuxone.net] and we feel the time is right to change our market focus.
In related news, Microsoft is looking for a new graphic artist who can properly draw a pentagram [linuxone.net].
-----
W2K will soon have zero bugs! (Score:2)
unsigned short bugs_r_us;
the bug counter will soon go from 65535 to 0.
Marketing? Deadlines? Pah... (Score:3)
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?
Irresponsible Slashdot article posters. (Score:3)
>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.
----
bugtracking and product release (Score:3)
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.
Unscientific comparison (Score:3)
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.
Biased poll? (Score:3)
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?
--
A list of few of the bugs: (Score:3)
But on the plus side: Notepad is unbundled from the OS, and now availble for only $99 from local retailers.
Re:A suggestion to Microsoft-emulate commercial Un (Score:3)
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.
A suggestion to Microsoft-emulate commercial Unix! (Score:3)
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.
Re:Spelling. (Score:3)
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?
Re:Not shocked (Score:4)
Consider also RedHat [redhat.com], which has been around for a much shorter period of time. Their Bug reporting system [redhat.com] 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!
65,000+, huh? (Score:4)
(Please don't moderate this if you're not a programmer.
Oh, stop being so predictable (Score:4)
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 (Score:5)
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!