Linux Has Fewer Bugs Than Rivals

sushant_bhatia_progr writes "Wired has an article stating that according to a four-year analysis of the 5.7 million lines of Linux source code conducted by five Stanford University computer science researchers, the Linux kernel programming code is better and more secure than the programming code of most proprietary software. The report, set to be released on Tuesday, states that the 2.6 Linux production kernel, shipped with software from Red Hat, Novell and other major Linux software vendors, contains 985 bugs in 5.7 million lines of code, well below the industry average for commercial enterprise software. Windows XP, by comparison, contains about 40 million lines of code, with new bugs found on a frequent basis. Commercial software typically has 20 to 30 bugs for every 1,000 lines of code, according to Carnegie Mellon University's CyLab Sustainable Computing Consortium. This would be equivalent to 114,000 to 171,000 bugs in 5.7 million lines of code."

Comments

Make love, not war...

[thrill12]

Proves it:

better love (coding) your software, than making war selling it

:)

Re:Make love, not war...

[jcostantino]

Isn't it "make -install"?

Re:Make love, not war...

[Dysan2k]

Nah.. it's:
make mrproper not distclean

Re:Make love, not war...

[AArnott]

Here here! And its not fair to compare actual Linux kernel bugs to predicted Microsoft bugs and say that Linux is tons better. Who knows? Microsoft is closed source, so you can't compare its bugs per x lines of code.

Re:Make love, not war...

[Zorilla]

I use Gentoo, you insensitive clod!

Disclaimer: Windows user w/SuSE on the side, but looking at Debian and liking it.

Re:Make love, not war...

[Anonymous Coward]

Your right, there may be a lot more of em!

Re:Make love, not war...

[Taladar]

LOC isn't a good measurement IMHO. You should take two parts that provide roughly the same functionality independent from the LOC and compare the number of bugs.

Re:Make love, not war...

[Anonymous Coward]

Make love, not war...

No, no, no, no, no.

Make CAKE!

MMMMMMMMMMMMM!

Re:Make love, not war...

[AArnott]

Very good point. If I were moderating this, I'd give you "insightful".

Mistake

[StevenHenderson]

Windows XP, by comparison, contains about 40 million lines of code

I think they mean "40 million lines of bugs" :)

Re:Mistake

[chrish]

Somehow I doubt that the XP kernel is 40 million lines of code. I know it's not good "news" but they should really compare apples to apples in their study.

This just in! "Hello world" has 0 bugs per three lines of code! Most stable and secure software ever devised!

Re:Mistake

[jacksonj04]

I disagree - some bits of Windows actually work as intended without glaring problems. In fact, the vast majority of Windows (especially in 2000 onwards) does what it's supposed to.

Deleting half the DLLs in sys32 then trying to run applications does not constutute a bug, especially when Windows shouts at you that you really don't want to be deleting them. If the user being able to cause problems was a bug (some would say it is), then Linux is more buggy than anything else. Windows has the decency to complain if you're deleting anything essential, Linux at best goes "Y/N", and even that can be overridden with a switch.

Lots of bugs maybe, but you can't say the entire codebase is badly written.

Re:Mistake

[hashwolf]

I think they mean "40 million lines of bugs"

... or ONE helluva BIG bug.

Re:Mistake

[dosius]

Yeah, and it's called Luna.

That's if you're talking a corporate version without activation.

Moll.

Re:Mistake

[Allen Zadr]

I actually agree here. I'm a big Linux proponent, but the whole text seems fishy to me. And if they are certain there are exactly that number of bugs in the code, then they probably have been addressed. Yet, there are probably more bugs yet to be found.

Then, when speaking of XP, they don't quantify the bugs, but merely say, "more are being found daily". Great... a pear.

Re:Mistake

[Kjella]

This just in! "Hello world" has 0 bugs per three lines of code! Most stable and secure software ever devised!

Actually, hello world has the highest ratio of bugs/program complexity I've seen. Depends on who is doing the implementation, I guess.

Kjella

Re:Mistake

[phats garage]

Don't forget, when sizing up XP's kernel you have to add in IE and media player 10.

Re:Mistake

[wwest4]

Bite your head off, man.

Re:Mistake

[FrYGuY101]

Okay, why?

Those are integrated into the Operating System. They are not part of the kernel.

Re:Mistake

[NardofDoom]

Three lines? You're not trying hard enough. I can do it in one(in PHP):

<?= "Hello World" ?>

Re:Mistake

[Chris L. Mason]

This just in! "Hello world" has 0 bugs per three lines of code! Most stable and secure software ever devised!

The scary thing is, lots of "hello world" code examples, actually do have bugs. A common example is returning (void) instead of (int) in main().

Re:Mistake

[fornaxsw]

This just in! "Hello world" has 0 bugs per three lines of code!

3 lines! That's an outrage...
perl -e 'print "hello, world";'

Re:Mistake

[ThePiMan2003]

Because they run in kernel space?

Re:Mistake

[Anonymous Coward]

Nice, but old fashioned.

Try this:

python -c 'print "hello world"'

Re:Mistake

[clambake]

3 lines! That's an outrage...
perl -e 'print "hello, world";'

One line of code! That's an outrage!

bash%clambake@hello world#

Re:Mistake

[Anonymous Coward]

No, they call the kernel. So do a lot of programs, in fact, otherwise the kernel is a bit useless.

Re:Mistake

[Kludge]

This just in! "Hello world" has 0 bugs per three lines of code! Most stable and secure software ever devised!

This case is not interesting. The code is not useful and no one would expect any bugs:
25/1000*3 = 0.075 1

Re:Mistake

[jedidiah]

OTOH, a missing library is trivial to diagnose under Linux. Just run ldd against the binary. Even retrieving the offending library again is pretty trivial in most distributions.

Excessive information hiding exacerbates any bugs in inherent in the system attempting to do the hiding.

Re:Mistake

[Anonymous Coward]

You can do it in one line in most high level languages.

Re:Mistake

[gowen]

If the user being able to cause problems was a bug (some would say it is), then Linux is more buggy than anything else. Windows has the decency to complain if you're deleting anything essential, Linux at best goes "Y/N", and even that can be overridden with a switch.

If you're giving your users write access to the key library files, then yes, they can screw the system. However, this is not a Linux bug; its pretty clearly a bug in your system administration policy. Write access to /lib and /usr/lib is reserved for people who know what they're doing, or point-and-click administration apps (which won't delete libraries you still need).

Re:Mistake

[jerdenn]

"OTOH, a missing library is trivial to diagnose under Linux. Just run ldd against the binary. Even retrieving the offending library again is pretty trivial in most distributions."

Yes, and it is trivial to troubleshoot on Windows, as well. Just run Depends, Showdep, or any number of available utilities against the binary. However, this shouldn't normally be an issue as Windows doesn't suffer from the same type of dependency issues that most Linux distributions do.

Re:Mistake

[Anonymous Coward]

Your version will not work if the short_open_tag flag is set to false. I'd suggest either for maximum portability or simply note that the literal string "Hello World" is a valid PHP source file (that never enters PHP parsing mode and therefore displays only that string).

Re:Mistake

[Garak]

Under linux you can't delete system files unless your root and there is no reason to be root on a day to day bases. Unlike windows you can install apps and what not in your home directory.

Windows, while it has improved greatly since the days of 95, 98 and ME. Its still full of security flaws and bugs. Their orginal model for windows is generally flawed and now that they are trying to fix the security problems(XP SP2) everything else is breaking.

One problem I've been running into lately is WinXP's poor handling of multiable soundcards and network interfaces. My motherboard has onboard sound and I have a M-Audio Delta 1010lt proconsumer recording soundcard. Both cards install fine but after a little use windows seems to loose track of what one I have set as default and then says there are none installed when I try to set the default(reinstalling fixed it, but its annoying). I'm having a simlar problem with my NIC's, this motherboard has dual onboard lan, everyonce in a while on port just stops working and then the other one won't detect a cable being plugged in. I've had various other strange happings with the network interfaces.

Re:Mistake

[fitten]

If that's the only qualification, every device driver ever written has to be included in the line and bug count. Also, pretty much any program that does anything interesting has to call into kernel space to have something done for it, so it's kind of running in kernel space too, just not all the time. Well... that pretty much pulls in every application ever written. I think that research group has a bit more work to do. If 5.7 million lines of code took them 5 years, they should only have about another 1000 years to go before they can publish :)

Re:Mistake

[Zorilla]

Even if "hello world" is perfect, I imagine you still have stdio.h to take into account.

Re:Mistake

[OrangeTide]

Even if all the lines of code were blank it would be 40Mb of source code (80Mb if you use stupid windows/dos CR-LF lines). That seems like a lot of source code when you consider that Microsoft relies on third parties for drivers. Or does calc.exe and hyperterm count as being part of Windows XP? (Maybe if MS Office counts as being part of XP, then I could understand 40 million lines).

Re:Mistake

[blowdart]

And of course to do a proper comparision they would need to actually have access to the XP source code to analyse in the same way they analysed the linux source. Then, if they're doing a like for like compare you can't, for example, analyse IE if Firefox wasn't in the linux analysis. If X wasn't analysed, well there goes the Windows GUI.

Hardly a fair comparison (just like certain TCO studies) but that's not going to stop Linux vendors using it and slipping down to MS marketing levels.

However it's not clear if the comment

Windows XP, by comparison, contains about 40 million lines of code, with new bugs found on a frequent basis.

comes from Wired, or from the Stanford report.

Re:Mistake

[Anonymous Coward]

Of course, plain old text ate my example code and I didn't catch it on the preview:

Re:Mistake

[DrPizza]

Except, uh, they don't do anything of the sort.

Re:Mistake

[1010011010]

Factor in DirectX and GDI as well, since they are, since NT4, part of the kernels's native API.

Re:Mistake

[Anonymous Coward]

I just don't get it..

echo "hello world"

Re:Mistake

[Shachaf]

Using HQ9+, I can do it with one character!

Re:Mistake

[deadlinegrunt]

"If the user being able to cause problems was a bug..."

So in a way Windows is the VB of the programming world where Linux is C in terms of shooting yourself in the foot, but then proof by analogy is fraud.

You were modded insightful but here is something to think about: Linux was not written for end users with Windows mentality. Everything about it is different from that kind of cultural thinking. It was written by programmers for programmers - Windows was not.

I think people tend to forget this more and more. Sure the codebase for Linux and its design lead the way for it being extensible to suit a variety of problems but that was never its main goal.

Windows on the other hand was.

"Lots of bugs maybe, but you can't say the entire codebase is badly written."

Now that you have been given a very tiny history lesson into how each of the OS's came to be - I find it a little ironic that Linux is doing a better job* than Windows was designed to solve. People are stepping up to improve Linux in the area that Linux was never designed for to begin with - making it usable for non-programmers. Windows response? Instead of improving their codebase they want to lock out competition by any means necessary. Innovation indeed.

*Which runs on more hardware as a simple example? Think "putting in the hands of users"

Re:Mistake

[dbacher]

X.Org, Mesa and your choice of KDE/GNome and the tools necessary to have the same base application set as Windows has have over 5m lines of code, so it's safe to say Apache 2, Samba, etc. weren't included in this count, either, nor the GNU C compiler suite.

There's no central Linux repository for reporting bugs in ancillary packages, while at Microsoft's site, all reported bugs go into a single database that can be queried. Each individual Linux distro and each individual Linux package maintains its own bug lists, which would have to be some how amalgamated.

In order to do the stated comparison, you would need to state what distribution you were using, you would have to state which patches you were using, and you would have to document where the information on bug counts came from for both products.

On top of all this, bugs per 1000 lines of code, while an industry metric, isn't a valid measurement of code quality, either, by the way.

One good code metric is the number of control points per function. The more control points per function, the more likely that you have a bug. It's always possible to take a complicated function and break it up into smaller pieces, and with C/C++ (but not .NET or Java), it's possible to do so with no performance impact at all in all ISO compilers.

Another good metric is the distribution of severity of the reported issues. Draw a bell curve of severity of issues, compare percentage to percentage. You're not concerned with 1000 bugs vs. 100 bugs, you're concerned about how many of those bugs compromise your system or cause a crash.

Another good metric is delta bugs over time. There will always be bugs, everyone knows that there will be bugs. The question is the bug count going up or down.

Another good metric is delta time between open and close. Again, there will always be bugs, but how fast they are getting closed is a measure of whether a product is good or bad.

Another good metric is distribution of the number of days that bugs have been open and reported (by severity).

The reason for this is that the number of lines to implement a given function using a given algorithm varies between programmers and programming styles. Some will use two lines or statements to do what can be done in one, to make code easier to read. The line number is something that a developer can manipulate easily.

However, these other measurements are tied directly into the quality of the code. Nobody cares how big the Linux kernel is compared to the Windows kernel, or vice versa. What they care about is how well the Linux kernel works compared to the Windows kernel.

Any count related to bugs, also, needs to take into account the fact that on Windows, you have billions of users any of whom could find and report a bug. On Linux, bugs are more likely to go undiscovered for a longer period of time, simply because there aren't as many people trying to hit them.

The Windows and Linux kernel tend to be very similar in bug counts. The kernels of both OSes tend not to have bugs, because kernels tend to have simple code that's hard to mess up in any meaningful way.

It's only when you start including all these ancillary subsystems, device drivers, etc. that you start to see significant percentages of the bug.

And it is exceptionally hard to get an accurate count of those on Linux. On vMac, I documented approximately one bug in ten that I fixed, and I think that would be typical of other open source projects (although I can't swear to that).

I think that on these other, valid measurements that aren't dependent on lines of code, that if you could collect the statistics on a package per package basis, and compare them, that Open Source would still come out ahead of Windows.

It's just a matter of using a meaningless metric on widely divergent code bases to prove any point is irresponsible, and by reporting it, the media is doing a disservice to the Open Source community by perpetuating the image of the community as a bunch of college students who don't understand real development practices.

Re:Mistake

[Anonymous Coward]

It was written by programmers for programmers

Remember that statement next time we have a "Is Linux ready for the desktop?" story.

Re:Mistake

[lars_stefan_axelsson]

I'm reminded of Knuth's observation that: "Ninety percent of the programs at my installation are short, fortran and wrong."

Re:Mistake

[Thundersnatch]

But you're wrong, they don't. IE and Media player run in user space in Windows. As do the vast majority of "buggy" programs in Windows.

It would be far more fair to compare XP with the Linux kernel + X + Gnome/KDE + browser + email app + xine + a bunch of other equivalent user-space utilities. But that would be a lot of work, and deciding where to draw the lines would be difficult. The two OS are architected very differently... shouldn't the horrendously buggy third-party video drivers that ship with most linux distros be included, since so many third-party drivers are included with Windows?

I'm not saying Linux would lose such a "fair" comparison, it would probably still be found less buggy than Windows. My point is this referenced article is stupid, useless propaganda generated by someone with an axe to grind.

Re:Mistake

[deadlinegrunt]

Seeing as how I am the one pointing it out - I do not think I am that one that needs to "remember" anything.

Interestingly enough it is for that reason I do not push to install Linux everywhere and on everything that I come into contact with. Now if we are speaking of developement environments - I push Linux for every back-end job I can because it is hands down better than Windows based on my empircal knowledge. Do I try to replace the administrations NT/2000 workstations? No freaking way. Could I? You bet.

As an aside if you set up a Linux desktop (have you by chance?) for some Windows users with zero experience how many times have they utterly dumped it and went back to Windows? I have only done that 19 times* and two of which reverted back. Still though - I do not think that Linux is ready for the desktop -- any more than Windows is ready for the networked world...Notice they both do though?

*for family/friends/co-workers in their homes
and the two that reverted where the self-proclaimed "power users" - but kudos for the attempt I say

Re:Mistake

[MyLongNickName]

Excessive information hiding exacerbates any bugs in inherent in the system attempting to do the hiding.

Excessive verbage inclusion exacerbates recipient misunderstanding of the intended message.

Re:Mistake

[m50d]

Damn right. And just try doing it in java. Ugh.

Re:Mistake

[Theatetus]

This just in! "Hello world" has 0 bugs per three lines of code!

That's exactly the sort of attitude that lets bugs flourish. There's more than just the 3 lines in the "hello world" at stake: it's how those three lines interact with the system library, the kernel, and the environment that matters. Are you *certain* nothing in the platform lets a user launch the program in a way that accesses memory inappropriately? If so, how are you sure?

Re:Mistake

[Anonymous Coward]

A more accurate description would be software defects. That is what the Stanford study is counting. Examples of such defects would be items such as:

• using memory that has already been dealocated.
• unitialized variables
• unitialized pointers
• unreachable code
• fallthough switch cases.
• unused variables.

These kind of errors can be automatically detected with lint-like parsers. Something of the same effect can be achieved by compiling with all GCC warnings enabled, although I suspect the Stanford folks are using something considerably more powerful.

Many times such defects are benign, while others are ticking time bombs. It's best just to fix them all.

Re:Mistake

[Anonymous Coward]

Even if "hello world" is perfect, I imagine you still have stdio.h to take into account.

I don't think so... When I'm programming a certainly wouldn't call a bug in the operating system or standard libraries a bug of my program. If I wrote my program perfectly with zero bugs, it could still screw up because of bugs in the operating system, but I still wouldn't count it as a bug in my program. It's alright to distinguish between operating system and application.

Re:Mistake

[RailGunner]

Thundersnatch is right - IE and WMP do indeed run in userland, but the problem is that typical windows users log in with an Administrator account (aka root) allowing these applications access to everything.

If you were to compare a clean install of Windows XP with Service Pack 2, and were to compare all of the products (IE, WMP, Wordpad, etc. vs. KDE, mplayer, gvim) to a major distro like Mandrake or Fedora Core, I think that not only would you find that the full Linux distro has fewer bugs and exploits, but the damage potential would be much, much less in Linux then under Windows, since Linux does a much better job with memory access permissions.

Even some critical flaws in Linux only affect the user (who can easily be deleted and re-added), whereas most critical flaws in Windows severely damage the entire system.

Re:Mistake

[gtkuhn]

Can we assume the Linux bugs were all fixed. Or at least tagged and reported so that they can be fixed. Does this mean Linux kernal 2.6 will now be completely 100% bug free?!?!

Re:Mistake

[Foolhardy]

The NT kernel supports multiple syscall tables. Any kernel mode component can add its own table. Since NT4, Win32 has its own syscall table because it has less overhead than an out of process LPC port to CSRSS (what was used before), but the kernel's native API is seperate.

You may say that this is a trivial difference; that since the Win32 server runs in kernel mode and has a syscall table, it might as well be in the kernel. It wasn't much different before: the Win32 server ran as SYSTEM, the most priviliged account. Although it didn't have it's own syscall table, any app could send messages to it along the LPC port (\Windows\ApiPort). The same functions exported on the LPC port were simply moved to a syscall table. Most of winsrv.dll's functions were moved to win32k.sys. Nothing else in kernel mode, save video drivers, even care about win32k.

Re:Mistake

[Anonymous Coward]

Since the standard C "Hello World" program requires use of the iostream library, you have to include the library in the line count, and you also have to look through it for bugs.

Re:Mistake

[Anonymous Coward]

Under linux you can't delete system files unless your root and there is no reason to be root on a day to day bases. Unlike windows you can install apps and what not in your home directory.

Under Windows (any NT based) you can't delete system files unless you are an Administrator and there is no reason to be an admin on a day to day basis. Without admin, you can't install apps outside of your profile (home directory).

Re:Mistake

[EvilIdler]

Looks fishy to me, too, even being the Linux nut that I am.
But..are the bugs in Windows mostly kernel-related or other software?
If it's kernel-related, counting the rest pulls the average down, making
Windows look better :)

Re:Mistake

[99BottlesOfBeerInMyF]

While I agree, for the most part, with your conclusions that this study is not meaningful, I take exception to one of your staements.

Any count related to bugs, also, needs to take into account the fact that on Windows, you have billions of users any of whom could find and report a bug. On Linux, bugs are more likely to go undiscovered for a longer period of time, simply because there aren't as many people trying to hit them.

There are a number of factors that you do not mention here. One is that bugs can be found more easily in open source products, since the code can and often is inspected by others. Another is that while there are more users of Windows, the ratio of bug reporters to users is probably much lower. The technically inept rarely report problems and even the technically proficient often do not bother reporting them to MS. I know I never report bugs to MS, since none of the ones I have reported were ever fixed. The same is not true with open source, or even many other closed source vendors. Finally, due to the closed nature of Windows, and their reporting process, there is no way of knowing what bugs are found and fixed internally by MS, but are never made known to developers or users. Basically, I agree that this report is nonsense, but I disagree with your theory that Windows probably has the same number of bugs or fewer bugs than the Linux kernel. I suspect that the Windows source code is a bug ridden mess, that will not be fixed unless it affects the bottom line at MS.

Re:Mistake

[Dread_ed]

Dammit dbacher, stop making sense and being all rational and stuff!

We're trying to bash the dogshit out of MS products here and you are messing it up!

Go to your cubicle!

Re:Mistake

[northcat]

Hello World doesn't (usually) check for return values. That's technically a bug. (Just nit-picking here) As for the rest of your comment, I agree. They should compare a minimal Linux installation (with X) to Windows XP. I'm sure they'll find a LOT of bugs in 'Linux' (although not necessarily security holes or disastrous bugs) with many of them in X or X related apps. I always have many problems with X and X apps. Not big ones - small ones like not remembering some configuration it was supposed to remember or some messed up text and stuff like that. Also a few big bugs (still not security holes). When people talk about the merits of Linux they include everything from Apache to the GNU tools. But when it comes to things like this they just take the literal meaning of 'Linux'.

A part of the Linux kernel's small bug rate can be attributed to the fact that when a newbie geek/hacker starts using Linux and he wants to be a part of the OSS developer community it's highly likely that he will just become a kernel hacker because of the popularity of Linux and the word 'Linux'.

Re:Mistake

[mattyrobinson69]

are you trying to imply that there are bugs in my computer?

Quick, somebody take this mans /. id away from him, he obviously doesn't know what he's doing with it.

Re:Mistake

[mattyrobinson69]

but then you have to factor in bugs in php, and anything running below it (apache, kernel, etc)

Re:Mistake

[jacksonj04]

I admire your common sense - most Linux users on /. would push it for everything. I use Windows for desktop because it's easier to do what I need to, and Linux for serving because it does what it's meant to first time (even if it is taking the system out).

Yes, I have configured Linux desktops. I hate them. If I want a GUI it should be integrated with the kernel (note NOT built into the kernel), since that way there is only one thing to deal with. Gnome, KDE, IceWM, they are all different and most of them grind against me in being almost but not quite entirely unlike Windows. They have tried to steal bits of the Windows UI (Right click, Taskbar etc) whereas those churned out by Apple are actually innovative.

If I was moving people to a new OS I would move them to Macs. Linux can stay in the servers where it belongs until there is truly one which can desktop for Joe Public as well as Windows and Mac.

Re:Mistake

[Anonymous Coward]

a major distro like Mandrake or Fedora Core,

How about LINDOWS, that makes all users uid=0 by default.

STFU, it isn't any harder to create non-root users on Windows than it is on Linux. Idiotic users won't be able to do it in either case, so fuck them.

Re:Mistake

[JamesTRexx]

How about "echo Hello World"?

Re:Mistake

[JamesTRexx]

Ugh. Was already there. Read first, post later, preferably while awake.

Re:Mistake

[bwt]

The rate of bug finding really isn't enough to conclude anything. A bad bug find-and-fix process will lower the number of bugs found, but having better software that actually has fewer bugs also lowers the number of bugs found.

There are two variables here: the rate of bug creation and the rate of bug finding. I suspect that open source is break even or only slightly better at the first factor but much better at the second (many more eyeballs looking).

Re:Mistake

[Thundersnatch]

And that is the most serious issue.... the configuration of Windows is often very insecure.

Actually, Microsoft got the "principle of least privilege" mostly correct for the corporate environment. The default permissions given to users on a workstation that is in a Windows NT/2000/2003 domain are very restrictive. Users cannot install software, modify the system portion of the registry, or modify any system or application files or directories.

However, as you point out, many lazy network admins have given their users local admin rights on their Windows workstations. This lets users install software (including printer drivers) on their own, and lets you run some poorly written apps designed for Windows 95 at the flip of a switch. But it horribly compromises security.

Even more unfortunately, home machines that do not participate in a Windows domain default to having the "installing user" be an administrator. A totaly security disaster. I expect, however, that Windows XP "reloaded" or Longhorn will go the Linux distro route and include a "create two accounts" set of steps by default for home users.

Re:Mistake

[bwt]

Any count related to bugs, also, needs to take into account the fact that on Windows, you have billions of users any of whom could find and report a bug. On Linux, bugs are more likely to go undiscovered for a longer period of time, simply because there aren't as many people trying to hit them.

The claim that "billions of users" can "find and report" bugs is completely absurd. "Find", maybe if you take a very broad definition of that term. But "report"? Huh? Ask your mother if she knows how to "report" a bug to Microsoft, though.

I think it would be interesting to actually compare the number of people who have submitted a bug report to IE say than to Mozilla. I would guess the latter number is larger.

Clearly not all bugs are findable by ordinary users anyway. Ask your mom if she's ever found a buffer overflow bug. Or a race condition bug.

Your assertion that bugs last longer in Linux because more people are trying to find bugs on windows contains two big assumptions. I recall a secruity bug study that found bugs in linux last substantially less long, so I certainly question the conclusion. But I also dispute that there are fewer people looking for bugs in Linux. End users, maybe, but they are dramatically ineffective at producing actionable information than developers looking for bugs, which I assert give Linux a big edge.

I really don't think it matters how many bugs get "found" under a broad definition. If you get the BSOD on windows, you've found the bug, I suppose, but so what. How does that help unless you report it and somebody who can fix it takes action on your report. The conclusion of the article seems to be that Linux has dramatically lower levels of bugs, so your conclusions directly conflict with theirs.

Re:Mistake

[nicke999]

Did you read the article? Some of the points that you bring up are in fact answered in the article (severity of the bugs for example). But most importantly, the study hasnt been released yet so I would say that many of your points are unanswered in the short article at Wired and it is therefore impossible to discuss the metrics and methods used. Personally, I would give these guys the benefit of doubt. I put a high degree of trust in a four year research project carried out a prestigious university. Wired has obviously pulled out the parts of the repot that made for the best headline but this tells us nothing about the quality of the study.

Re:Mistake

[bronaugh]

Heh, your "hello world" example has a bug.

Specifically, you didn't tack a newline onto the end of the string, so it prints at the beginning of the prompt which appears after running it.

A common mistake :P

Proper code (with proper punctuation and capitalization):

perl -e 'print "Hello, world!\n";'

Re:Mistake

[Frizzle Fry]

Ask your mother if she knows how to "report" a bug to Microsoft, though.

She doesn't have to know how. Even if she says that she has no idea what you are asking about, there's a good chance that when the dialog pops up and says "do you want to submit an error report?" she clicks "send". Just accepting what the dialog is asking them to do is what the vast majority of users do with any dialog.

Clearly not all bugs are findable by ordinary users anyway. Ask your mom if she's ever found a buffer overflow bug.

And right there is everything that is wrong with what how you are suggesting things should work. A user shouldn't have to know what a "buffer overflow" is. What they know is that the program crashed and is trying to submit a report. Some people are paranoid or whatever and will click no, but your assertion that with the hundreds of millions of people using IE, the number who will click "send" is less than the amount who submit mozilla error reports is simply absurd.

Re:Mistake

[Anonymous Coward]

In XP, at least, if you have a bug severe enough to cause a crash or hang in a program or in some chunk of what appears to be the system, you are presented with a dialogue that allows you to report the problem to Microsoft, as long as you're on the net at the time.

This tends to catch the most severe bugs, but of course, does not do a lot for misfeatures. There are, for example, a number of dialog popups in MS products which contain misleading or misspelled text. Can't bug them though.

Re:Mistake

[Anonymous Coward]

I completely agree! ;-)

If one is thinking:

10 PRINT "Hello, world!"

Then you are probably fairly safe...however,
if one is thinking:

/* World famous "Hello, World" program
by some K&R guys or something...or
maybe Santa Claus and the Tooth Fairy
or perhaps even in the imagination of
DARYL@SCO.COM (see Smoking Crack Organization)
April Fool's Day, 2002-02-02
*/
#include "stdio.h"
void main(void){
printf("Hello, world\n");
}

Then you start opening cans of worms...and
as for Java, well, let's not even go there,
and if you really want lots of sneaky, horrible bugs to creep into your Hello, World programs, then try assembler - using DEBUG.COM :-)

Re:Mistake

[bwt]

What percent of software bugs do you think can be trapped by a "do you want to submit an error report" dialogue? And without steps to duplicate being submitted, most of those error reports are useless anyway. Error reports can only catch certain crasher type bugs. A quick look in bugzilla showed 200 of the 5712 known firefox bugs involve a crash.

And right there is everything that is wrong with what how you are suggesting things should work. A user shouldn't have to know what a "buffer overflow" is.

I don't expect them to be able to contribute at all to solving such a bug. But like it or not buffer overflows exist and most are **never** found by any ordinary use. Which means no "do you want to..." dialouge ever appears. Who types in 10000 characters to the text box in the diologue buried four levels deep?

Re:Mistake

[Anonymous Coward]

Oh how original... how witty... how intelligent a remark... SOOOOOO funny that I guess I just forgot to laugh. MORON.

Re:Mistake

[Anonymous Coward]

public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World");
}
}

Re:Mistake

[killjoe]

Right, because it's not fair to the poor little corporation to bash it. Now they might have to run that commercial two times to counteract all that bashing.

Poor little MS. Being beat up by those nasty slashdotters.

Thank god people like you are around to strike back!.

Re:Mistake

[barrkel]

It's always possible to take a complicated function and break it up into smaller pieces, and with C/C++ (but not .NET or Java), it's possible to do so with no performance impact at all in all ISO compilers. It is actually easier in .NET . The JIT compiler handles all the inlining automatically. It will probably end up faster than anything C/C++ can produce due to the pointer aliasing issues that those languages have to deal with.

Re:Mistake

[vistaconfig]

how is that a bug?? it looks hideous but works as advertised

Re:Mistake

[bronaugh]

Usually unreadable output is called a bug.

Likewise with unexpected behaviour when you go outside the expected set of inputs -- eg programs that sigsegv when called with no arguments...

Congratulations...

[kjones692]

...but while they were going through all those 5.7 million lines of code, would it really have killed them to debug them while they were at it??

Re:Congratulations...

[MadKeithV]

From TFA

Seth Hallem, CEO of Coverity, a provider of source-code analysis, noted that the majority of the bugs documented in the study have already been fixed by members of the open-source development community.

Re:Congratulations...

[Anonymous Coward]

They used an automatic checker, they didn't go through all the lines by hand.

They did report a lot, if not all, of the bugs to the linux kernel developers

Re:Congratulations...

[aborchers]

would it really have killed them to debug them while they were at it??

You really aren't that familiar with the academic research process, are you?

Joke. Joke. Others have already given the straight answer...

Re:Congratulations...

[lphuberdeau]

I doubt they looked up all the code. They probably only made statistics to compare the amount of bugs based on what has been reported and archives.

As a side note, at 20 bugs per 1000 lines, the 40 millions lines of Windows would contain 800000 bugs. I'm not a M$ fan, but this sounds a little excessive.

Re:Congratulations...

[Enigma_Man]

Something I've always wondered about this. How do they identify a "bug"? A bug can be anything from a typographical error (easy to detect, probably won't even _compile_) to accomplishing a slightly different problem than was intended (very difficult to detect, how do you know exactly what the software was intendd to do). So how are they qualitatively identifying "bugs"?

Also, if they're so good at identifying them, is it much different to fix them?

I'm an EE, not a CS, so I'm not familiar with hardcore programming tools, but I'd love it if I had something that could point out bugs in my code before I try it.

-Jesse

Re:Congratulations...

[eobanb]

The problem with this whole analysis is that it sounds nice on paper, but it doesn't accurately represent a user experience. Think about all the bugs you've ever encountered in Linux. How many of them were actually due to bugs in the kernel? No, virtually all bugs you're going to encounter on a day-to-day basis will be in user space tools, like bundled apps, GUI stuff, and really just everything between you and the kernel. Also, how much of Windows is being looked at, here? Again, many of the bugs in Windows are not in its kernel, but user space...sheesh. It'd probably be more useful to look at the whole system. Unless you're writing a kernel module or a driver or something, when's the last time you directly interacted with any part of the Linux kernel itself?

Re:Congratulations...

[jacksonj04]

Some web applications I write have a feature which bypasses a user auth check if they are moving from a specific high security function into a low security function. Usually it would re-authenticate them against the database every event, but in this case that would cause the database to return bad info (The high-security function is a refresh script for every user's permissions and takes a while to run). Skipping the auth makes sure you don't get bad permissions while the script runs - is that a bug? Some would say so.

Re:Congratulations...

[chialea]

I'm not a programmer-type either, but I'm familiar with some of this research. There are a few techniques that I've seen, but don't consider this to be complete, my research is in crypto, not code.

1. code patterns -- if you see something that looks like a pattern, it is probably a bug... "if(x = 0)", for example. of course, you have to check that it actually IS a bug, but you can catch certain common things that way.

2. type safety -- tools can go through your code (either statically or while it's running) and look for type violations. for example, you might write an int to an unsigned int, or mix up pointers and ints, which could be bad. you can catch a stunning number of bugs this way.

3. pointer analysis -- another annoying bug can be in aliasing, where you have multiple pointers that may or may not be pointing at the same memory. are you really /trying/ to overwrite that data structure pointed to by another pointer? In general, this sort of analysis is hard (undecidable, off of the top of my head), but feasible in limited cases.

I'm not sure what sorts of current tools are released by these researchers, but this is a very basic overview of the techniques I've heard about people using recently. (Repeat disclaimer: I'm a theorist.)

Lea

Re:Congratulations...

[LiquidCoooled]

so, if they're so good at identifying them, is it much different to fix them?


Yes, its VERY easy for somebody to notice a bug or unexpected effect.
it may also be very easy to suggest a possible fix for that bug.
However, in a large system with lots of interconnected parts, you cannot just impliment the fix without being certain that you haven't screwed up other parts.

Take for example the slashdot rendering bug in firefox. Plenty of people have reproduced the bug, plenty of people have suggested work arounds and fixes, however none has been stable enough to go into the proper branch (may have changed since I last looked, 1.0 is still problematic).

Now, another source of bugs and errors is compiler updates. Problems with buffer overflows and other "standardised" bugs can often be removed by changing the compiler switches or obtaining an update to the compiler, this is in effect how MS managed to remove a great many problems with SP2.
The inverse is also true, code which worked as expected on one version of the compiler may begin to fail during recompilation many years down the line leading to new unnoticed bugs.

Re:Congratulations...

[Khazunga]

I've not RTFA, so this may not be true for this particular case. However, the bug figure is usually derived statistically. You assume bug finding follows an inverse exponential (picture a capacitor charging function). After some time, from the found bug data, you can deduct the function limit when time is infinite. That limit is the total bug count.

Re:Congratulations...

[Tony Hoyle]

OSs work like that too... if you're going from Ring 0 to Ring 3 the checks are bypassed (higher->lower) and if you're going from Ring 3 to Ring 0 it either won't let you or make damned sure you can't do anything bad.

I wouldn't consider it a bug unless it's possible to circumvent the system.

Re:Congratulations...

[Enigma_Man]

Aah okay, thanks for the info. When I think "bug" I'm thinking "I meant to add 3, but I added 4 instead" kind of bugs, which you couldn't really detect algorithmically, because how's the algorithm supposed to know your purpose for the program? I suppose I might be using the wrong word for that.

-Jesse

Re:Congratulations...

[Octagon Most]

"I doubt they looked up all the code. They probably only made statistics to compare the amount of bugs based on what has been reported and archives."

Exactly. The article is nearly useless. According to the CNet article covering the same issue:
"Proprietary software, in general, has 1 to 7 flaws per thousand lines of code, according to an April report from the National Cybersecurity Partnership's Working Group on the Software Lifecycle, which cited an analysis of development methods by the Software Engineering Institute at Carnegie Mellon University."

The Wired article says,
"... 20 to 30 bugs for every 1,000 lines of code, according to Carnegie Mellon University's CyLab Sustainable Computing Consortium."

Hmmm, both cite Carnegie Mellon University as the source. So which is it, one to seven, or 20 to 30? That's a big difference. It's either 5,700 to 40,000 flaws or 114,000 to 171,000.

The bottom line is that the Linux source code can be viewed and has 985 visible bugs of various identifiable types. The Windows source code cannot be viewed and may have anywhere between 5,700 and 171,000 flaws based on some questionable extrapolation using two widely divergent methods.

Re:Congratulations...

[Anonymous Coward]

Not to mention that Microsoft has made noise about their own code-checker tools.

It's reasonable that Windows and Linux have a very similar defect rate here, at least for types of bugs that can be caught by these sorts of tools.

Re:Congratulations...

[Lonewolf666]

1. This example would make perfect sense in Pascal. In general, I have never noticed that my bugs tend to stand out by looking like patterns.
2. Many developer tools already have this built in and will provide warnings.
3. Can be difficult, and I am not aware of any tools that are universally usable for this. You will probably end up looking long and hard at the code...

Re:Congratulations...

[Anonymous Coward]

One to 7%, or maybe 20-30%, of Slashdotters are getting ready to flame you for questioning the results of any pro-Linux article :-)

Re:Congratulations...

[blancolioni]

By such an analysis, Ada code has two-thirds less bugs, while Haskell code has none at all!

This fits quite well with my experience of both languages by the way.

Re:Congratulations...

[marcosdumay]

This kind of analisis do exist but searching for bugs like that on the linux kernel will give just bogus result. That's because 1 and 2 are made by gcc for the most common bugs, the compiler gives you warnings and the kernel (at least last time I compiled it) have just a few of them and they look like ordinary pieces of code, not bugs. Techinique 3, while usable in limited cases is very hard in a big hightly optimized piece of code, like the kernel.
So, if they used something like that on the linux kernel, they problably found just some weird code, not bugs.

Re:Congratulations...

[Anonymous Coward]

5700 (best case for Microsoft) is still significantly bigger than 985. If those numbers are defensible, the study would still be significant. The 171,000 number is useful to have something to negotiate away in a debate. I.e. you start with 171,000; they counter with 5700; you point out that 5700 is still bigger than 985.

Personally, I think that the more damaging criticism of this study is that it studies something that you would expect to be a Linux strength: visible bugs. The whole point of open source is that it allows more eyes to see the code, so it should be expected to have fewer bugs that are detectable by inspection. It's nice to know that holds up under study, but it's not exactly ground breaking.

Btw, I would tend to give more credence to SEI's numbers. SEI does general research (including Defense department) for CMU and has associations with CERT. People (including Microsoft) would give information to SEI that they wouldn't give to a Sustainable Computing Consortium. I.e. SEI is a serious research organization. This CyLab thing sounds like a pop technology promoter.

Re:Congratulations...

[picklepuss]

err... maybe not. Although he is questioning the study, he still points out that in an absolute best case for Windows scenario, Windows still has 5x as many bugs.

Re:Congratulations...

[chgros]

A very common bug in the kernel:

p = malloc();
if(!p)return;
q = malloc();
if(!q)return; <= Memory leak if this happens

Re:Congratulations...

[GreyWolf3000]

Assertions help here (even if you don't use the assert macro, you can still put checking in your algorithm).

Re:Congratulations...

[chialea]

This is why researchers are working on it. If it weren't hard, no one would bother touching it! :)

Lea

Re:Congratulations...

[chthon]

I'm an EE, not a CS, so I'm not familiar with hardcore programming tools, but I'd love it if I had something that could point out bugs in my code before I try it

You do not need any hardcore tools. Using code reviews can do a lot of good in finding bugs before production.

Re:Congratulations...

[dolmen.fr]

No, you are using the right word.

But the reporter didn't distinguish those. Which of course means that "985 bugs were found in the Linux kernel code" does not mean that fixing them will fix everything and that Linux will then be perfect.

Coverity can some bugs, but it can not find all bugs.

How can one be sure

[UltimaGuy]

How can one be sure about closed source kernels like Windows XP. Even though I agree that it has to contain more bugs, without the actual source how can any one make any judgement in this matter?

Re:How can one be sure

[jacksonj04]

Simple. Windows kicks up more bugs in use than Linux does.

Re:How can one be sure

[Anonymous Coward]

You can't be sure, which is what the article states. They didn't test Windows.

Of course, thats not important when you can put an "anti-M$" spin on an article to further your agenda.

Re:How can one be sure

[Anonymous Coward]

That could be the same bug manifesting itself over and over.

Re:How can one be sure

[jacksonj04]

That one's called Internet Explorer.

Re:How can one be sure

[Deviate_X]

Actually "Windows XP" isn't a Kernel. The kernel of Windows XP is called the actually called the "NT Executive" - which is composed of the Hal (Hardware abstractiomn..), Microkernel and kernel services ( device drivers,.. ).

Windows XP Architecture

Re:How can one be sure

[Anonymous Coward]

It didn't say in the article if they looked at Windows source code or not. But, if they really wanted to, they could license with Microsoft with its Shared Source Initiative? If they did, then they could compare Linux and Windows line-by-line. They are part of a univeristy, so they could have licence agreement with Microsoft.

Re:How can one be sure

[Burb]

Also, take a close look at the statement Windows XP, by comparison, contains about 40 million lines of code, with new bugs found on a frequent basis

Well, the number of lines of code in the code base isn't strictly relevant, but comparing an unquantified rate of bug discovery against a quantified absolute number of bugs doesn't sound like sound practice to me.

It also makes no statement about the relative severity of the bugs - 100 trivial bugs with simple workarounds would certainly be worth fixing, but how can you compare them against, say, one bug that trashes your principal hard disk?

OK that's my opinion, now to R the FA.

Re:How can one be sure

[sjrstory]

I think the vast uptime of *nix systems over windows* systems speaks for it's self.

Re:How can one be sure

[ViolentGreen]

Yeah, by saying "Windows XP" instead of the NT Kernal used in XP, I'm wondering if there is a spin here. I've always heard that the NT kernal is very efficient and well done and that the problem lies with what's on top of the kernal.

I'm not disputing that the 2.6 kernal has less bugs then the NT Kernal. I have no way of knowing whether or not that is the case. Nobody else really does either unless they have seen the code. The frequent XP vulnerabilities are NOT in the kernal.

Slashdot is to Linux as FOXNews is to

Re:How can one be sure

[maxwell demon]

The kernel of Windows XP [...] which is composed of the Hal [...]

This may explain the Windows crashes. "Sorry Dave, I cannot let you do that."

Re:How can one be sure

[js3]

I think what they meant was, in 40million days, windows will have a bug for every line of code.

Re:How can one be sure

[legirons]

"How can one be sure about closed source kernels like Windows XP"

From what I've read so far, they didn't. They just listed how many lines of code it had.

They're also not making any estimates about the quality of programming. Obviously the errors/line-of-code varies wildly, so assuming that anything fits that average seems quite odd. Linux doesn't, obviously (by several orders of magnitude), and it's similarly unlikely that WindowsXP turns out to have exactly 20 error per 1000 lines.

Re:How can one be sure

[Anonymous Coward]

Oh, come on now, be nice. Those arn't bugs, they are undocumented features.

Re:How can one be sure

[juanillodgn]

Besides, the Article seems to account only the Linux kernel.

I wonder what would be the results of such analysis made over the KDE or Gnome codebase, or any other sofware "closer" to the user.

I wonder...

[Chi-RAV]

I wonder which facts from this study will end up on Steve Balmers Propaganda presentation sheets...

Re:I wonder...

[Anonymous Coward]

"Our findings show that Linux contains an extreme ... defect rate ..." said Hallem. "Many security holes in software are the result of software bugs that can be eliminated with good programming processes."

Re:I wonder...

[Walkiry]

Something along the lines of "a careful audit of the Linux Kernel found nearly 1,000 bugs, whereas Windows XP has only had to release , proving our software is more robust and has less bugs to fix".

Conflict of interest...

[BJZQ8]

The problem is that there is very often little vested interest in fixing bugs in closed software...if it can be covered up, then so be it. In open software, there's always a reason, even if it is just to keep people from pointing at your code and laughing.

Re:Conflict of interest...

[Malc]

If it can be covered up then it's not a very serious bug. Why spend money fixing bugs that aren't a big deal?

Re:Conflict of interest...

[akadruid]

If it can be covered up then it's not a very serious bug. Why spend money fixing bugs that aren't a big deal?

See Also: Diebold

Re:Conflict of interest...

[Mjlner]

The problem is that there is very often little vested interest in fixing bugs in closed software...if it can be covered up, then so be it.

One should also always remember that the difference between a bug and a feature is often in the documentation.

...which reminds me of an IBM thinkpad I had. It had a mysterious bug^H^H^Hfeature that caused the mouse pointer to move a bit on it's own after using the red pointing device. The documentation described this behaviour and stated quite clearly: "This is not a bug!". The documentation did not explain what the "feature" was good for. "Whew!", I thought, "It's a good thing I know it's not a bug!"

Re:Conflict of interest...

[BJZQ8]

Perhaps it's not a serious bug at first examination...but someday an exploit is discovered, and it becomes a VERY serious issue. With open software, there is no burying. If it's there, it at least CAN be found, even if it isn't immediately. Closed software depends on the goodwill of the software manufacturer, where there often is none.

Re:Conflict of interest...

[Anonymous Coward]

...which goes to support my view of business: If a business doens't have to, it won't. If it has to, then maybe.

Re:Conflict of interest...

[Riddlefox]

I had an old Thinkpad (760EL) that did the same thing. IIRC, the cause was thermal drift. It would occur when the Thinkpad started getting too warm. This lead to erroneous results from the little nub, which caused the mouse pointer to drift.

Re:Conflict of interest...

[FireFury03]

If it can be covered up then it's not a very serious bug. Why spend money fixing bugs that aren't a big deal?

Or maybe it's a serious bug that just hasn't been exploited yet?

Re:Conflict of interest...

[Anonymous Coward]

In open software, there's always a reason, even if it is just to keep people from pointing at your code and laughing.

This may seem a little strange, but I have just started working on an open source project myself and I have been feeling this strange NEED to prove myself that I never have working at a typical company.

Re:Conflict of interest...

[Malc]

"Bug" is a very generic term. Some scaremongers like to use it in the worse sense of the word, but it could just be something simple like setting a screen area to the wrong colour or having a spelling mistake in a piece of text displayed to the user. A bug could just be the use of an inefficient algorithm leading to poor performance and making the user stare unnecessarily at a busy cursor.

Why do people always look for the worst in things? Yes, you have to have a certain level of paranoia when coding as it is hard to see some of the ramifications, but I think this goes beyond that. In this case it's a sensationalist story...

Re:Conflict of interest...

[ajs318]

Precisely.

But just you wait, because all the indications are that a real live decompiler is just around the corner. It will turn compiled object code into source code, although probably without the original variable and function names {Some compilers even leave the variable and function names in the code -- almost as though they want you to be able to decompile stuff!} Once all the extension modules are finished, you will even be able to decompile something originally written in C into BASIC.

And it will be the beginning of the end for closed source software -- not something I expect to be pretty by any stretch of the imagination, but something I think historians will later agree was very necessary in the long run.

Re:Conflict of interest...

[bibi-pov]

Why was the parent modded funny? It's at the very least, as much insightful as funny !

Re:Conflict of interest...

[tchuladdiass]

I've got a Dell with that same pointer stick. Apparently this "cursor drift" is part of the auto-calibration system. If you put a bit of pressure to one side of the stick, and hold it there still for about 10 seconds, it will then use that new value as "center". You release it to real center, and your mouse starts to move across the screen. If you let it sit there for another 10 seconds, it will re-calibrate.

Re:Conflict of interest...

[Anonymous Coward]

OT, but I found I could fix this problem by replacing the rubber clit thing.

Re:Conflict of interest...

[fitten]

Wierd. I've worked on both open and closed source projects and I constantly feel that I have to prove myself and better myself. Otherwise, I just stagnate and have no reason to do anything well.

When you treat everything you do as if it must be done to the best of your ability, not only do you get good results but you also get respect from your peers and superiors. It doesn't matter whether the source is open or closed. It YOUR reputation on the line in either case. It's all about work ethic. What matters to me is that the code I write is stable and efficient. If you are one of the folks who always thinks about 'I'm not getting paid enough to do this' and the like, well... You've probably never felt the need (desire) to prove yourself anyway. Most of us who program (closed or open) do it because we'd do it even if we didn't get paid. Getting paid is just icing on the cake. For me, it means that I always have a project to work on (I run out of ideas and/or steam on my own ideas from time to time).

Re:Conflict of interest...

[maxwell demon]

Actually it can even be a bug if the program does correctly perform some sensible operation, which just is not the operation the user expects.
For example, if copy under DOS without being given any option just overwrites a file without asking, it's a bug. If cp under Unix does the same, it's the correct behaviour, asking by default would be the buggy behaviour in that case.

Re:Conflict of interest...

[ch-chuck]

Why spend money fixing bugs that aren't a big deal?

And why fix bugs when they can be left in as an incentive to purchase the next upgrade when it's available?

Basically, "big deal" bugs are the ones that show up during the flashy presentation to corporate purchasing decision makers. The ones "not worth fixing" are the aggravating ones the employees have to live with after the big purchase.

Re:Conflict of interest...

[RpiMatty]

I have a thinkpad and used the red nipple mouse all the time.
after a while it started moving on its own.
i took the nipple off and cleaned under it, and that helped.
after a while tho, i had to replace the nipple, cus it got so dirty and wore out.

my guess was dirt got stuck under it, not letting the mouse return to a home position, and after a while, the nipple got so wore out, dust was always getting under there

Re:Conflict of interest...

[greed]

{Some compilers even leave the variable and function names in the code -- almost as though they want you to be able to decompile stuff!}

There are two things that lead to this; one of them is the obvious, debugging symbol tables are needed to allow a source debugger to show you the variable names. After all, who wants to know that you've got a 3 in gr12... and a 7 stored at 0x002fdc1c. Errr, I guess IA32 people would want to know about EAX and so on. Still.

Traditionally, vendors would run the "strip" command on the finished program. This removes (most of) the symbol tables to reduce the amount of on-disk space used by the program. (The symbol tables are not mapped into memory when the program runs, so it doesn't affect the memory footprint.) But, given the low cost of disk today, people now (should) leave the symbol tables in the program for better in-place debugging. It can also help get more information from a core file when the program crashes; stack traces and other program state information will be more meaningful.

Plus, any symbol that is available for runtime linking or dynamic loading must have a symbol table entry. Library calls aren't generally coded with offsets from a base pointer any more--though that may be how they are implemented. (OS/2 and Amiga both had offset-from-base systems for the dynamic libraries. There's some vestiges of the OS/2 linking system still present in Windows, though new code uses symbolic linking.)

Generally, at least on Linux and Solaris, people just let the compiler make every 'extern' available for runtime linking, so you wind up with many more symbols in the symbol table than you really need. But you don't have to maintain an 'export list', and that makes developers very happy.

Put it all together, and decompilers are going to have a very nice time of it. I'm looking forward to it; I hate trying to figure out what closed-source software is doing wrong relying just on truss (or strace) and similar tools.

Heck, it would be neat to see what your code looks like in source form after the optimizer has had its turn with it.

Re:Conflict of interest...

[Malc]

*chuckle* That's when features become bugs depending upon your perspective.

Re:Conflict of interest...

[Spy Hunter]

Also, more bugs means more support contracts.

Definitions

[grennis]

I'd like to draw conclusions from this, but I don't know what meaning of "bug" they are using here.

Lots of "bugs" aren't really bugs at all, so all these numbers (lies, damn lies, and statistics) don't mean anything to me until I know the assumptions they are using as a basis for the study.

Whoops!

[BigHungryJoe]

Make that 986, they just found another one.

bhj

What about the ones they missed?

[Ironsides]

Not to be a downer but, how do we know they didn't miss anything? 5.7 million lines is a lot of code to go through and analyze. I'm also curious where they came up with the 20-30 bugs per thousand lines of code that proprietary software suffers from since they can't see the code.

Of course, we must remember, "It's not a bug, it's a feature!"

Re:What about the ones they missed?

[Roofus]

I don't think they made any attempt to determine the average number of lines per bug of code, they just took the known industry average.

Re:What about the ones they missed?

[imsabbel]

Yeah, i agree.
If bug-finding were so easy that 5 guys could just check 5 million lines of code, we wouldnt suffer from buggy software.

Re:What about the ones they missed?

[WindBourne]

No, but on windows, it is reported as to how many LOCs they have as well as the public bugs (which is sadly but a fraction of what MS reports i.e. the real bug count is MUCH higher). Simple math gets you the rest. With OSS, everything is in the open. That includes the LOC and the bug reports

Re:What about the ones they missed?

[AccUser]

Not to be a downer but, how do we know they didn't miss anything?

Like the man said...

There are bugs we know we know.
There are bugs we know we don't know.
There are bugs we don't know we know.
There are bugs we don't know we don't know.

Re:What about the ones they missed?

[beaviz]

Of course, we must remember, "It's not a bug, it's a feature!"

You misspelled "future".

Re:What about the ones they missed?

[ynohoo]

if I create 20-30 bugs for every 1000 lines I wrote I would consider a new career...

I think these guys are just pulling stats out of their ass. How did they detect these bugs? How do they come up with their MS figures?

Just because MS starts FUD about Linux doesn't mean we have to sink to their level.

Re:What about the ones they missed?

[jusdisgi]

I'm also curious where they came up with the 20-30 bugs per thousand lines of code that proprietary software suffers from since they can't see the code.

Presumably, at some point in the past someone (these researchers or others) was given access to some proprietary software's code in order to do this kind of analysis on it.

Similarly, the methods used to track down the bugs in the code are expected to be equivalent in both cases for a study like this to be valid. That fixes the other problem you raise, that of the researchers missing bugs. Sure, they probably miss a few....but the same is true for the other studies on enterprise software. When the difference in bugs/line is that huge (1:1000+) you just can't explain it away by conjecturing that they missed some.

That said, I do see one issue; I'm not sure it's correct to hold a kernel to the same standards as generalized "enterprise software." It seems to me that if they compared the bugs/line in the major OS kernels, the numbers would be a lot different. But then, that's just a guess.

Re:What about the ones they missed?

[p3d0]

Yeah I was thinking the same thing. That's utterly pathetic, unless they're including such "bugs" as compile errors (in which case it sounds about right to me).

Re:What about the ones they missed?

[maxwell demon]

Well, 5 guys can just check 5 million lines of code. It will just take them much more than 4 years.

Let's calculate: The average life time of a man is about 80 years. Let's assume you can start proofreading with 20, then you have 60 years, or 21900 days where you can look for bugs. Now 5 persons for 5 million lines of code means 1 million for each. Divided by 21900 days, this gives less than 46 lines of code per day, assuming an 8h work day this makes close to 6 lines per hour. Sounds doable. The problem is, noone will do proofreading every day for his whole life, nor would anyone want to wait that long for the proofread.

So, yes, in theory they can proofread 5 million lines of code, but in practise they won't.

Re:What about the ones they missed?

[rueba]

The main value of this study is that it came from an "objective party."

They didn't give the researchers's names in the article, but I am betting these guys are among the top people in their field(Stanford is pretty strong in this area).

In other words they have an academic reputation to uphold, I doubt they would pull something out of their ass and risk being publically humiliated.

Patch...

[leonmergen]

... so, since they've discovered that many bugs, where's the patch? :)

Power of Open Source

[mordors9]

Hopefully since those bugs in the Linux kernel have been identified, they can be fixed. While whatever bugs there are in Windows have not been identified since the source code is not availalble. For those we will have to wait for the next exploit to be announced.

Re:Power of Open Source

[Dorsai65]

we will have to wait for the next exploit to be announced

That should be exploitS.

sigh...

[banana fiend]

"Windows XP, by comparison, contains about 40 million lines of code, with new bugs found on a frequent basis"

which compares very well to a rate of "very frequently" on "less" lines of code. probably at least 2-3 times better - or "more".

Re:sigh...

[ceeam]

Note how the (/.) article does NOT state the number of bugs in WindowsXP code. It just states the number of lines in XP code (supposedly, courtesy Microsoft Corp.) and some _industry_average_ bugs per line numbers. I would call that "propaganda" if I weren't on their side ;)

Re:sigh...

[Realistic_Dragon]

Note how the (/.) article does NOT state the number of bugs in WindowsXP code.

It overflowed a 32bit INT, they are having to wait for their new 64 bit machines to arrive to finish computing the exact number.

Re:sigh...

[1u3hr]

Note how the (/.) article does NOT state the number of bugs in WindowsXP code. It just states the number of lines in XP code (supposedly, courtesy Microsoft Corp.) and some _industry_average_ bugs per line numbers. I would call that "propaganda" if I weren't on their side ;)

They spent 4 years sieving through the Linux code. That's all they can speak authoritatively about. But if anyone has done similar work for MS, it'd very likely be under NDA. So they just used an "industry average". Meaningless really, who can say whether MS is above or below "average"? (Not just asserting "Winblows is teh sux" but actually measuring it.)

Bug Fixes

[timmyf2371]

Not being a computer scientist or coder by any means, I have a couple of questions.

1. Are these the only bugs to be found in the Linux kernel?

2. Now that these bugs have been identified, should these bugs be fixed would that mean that Linux itsself could truthfully be classified as "bug-free" or am I missing something?

Re:Bug Fixes

[Anonymous Coward]

1. No, these probably are not the only bugs in the linux kernel

2. Testing for bugs only shows the existence of bugs, never the absence of bugs

Re:Bug Fixes

[m50d]

2. Now that these bugs have been identified, should these bugs be fixed would that mean that Linux itsself could truthfully be classified as "bug-free" or am I missing something?

Someone above said that after an audit like this you assume there are 5x as many bugs as you found remaining.

Re:huh :)

[Fig, formerly A.C.]

Yeah, my first thought was "No sh*t!!"

At least a totally freaking obvious story is better than a redundant one. ;-)

Bug Fixed !

[hopbine]

Have they fixed the 985 bugs - if they have how many bugs are left ?

Re:Bug Fixed !

[tritium6]

If there were 985 bugs, and they fixed 985 bugs, then my guess is there would be about 0 bugs left...

although, IANAM(athematician)

Re:Bug Fixed !

[maxwell demon]

Even if the premises were correct (i.e. no undetected bugs, and all found bugs fixed), your conclusion is wrong: You can introduce new bugs when fixing old ones.

Simple example: Say you failed to detect a negative value where there are none allowed:

int foo(int x) /* x must not be negative */
{
code_that_crashes_for_x_lt_0(x);
more_code(x);
return something;
}

Now you find this bug and fix it:

void foo(int x)
{
if (x <= 0)
return errval;
code_that_crashes_for_x_lt_0(x);
more_code(x);
return something;
}

You bug is fixed (no crash for negative values). But you introduced a new one (the function flags an error if x is 0, despite x being allowed).

Apple != Orange

[kin_korn_karn]

Talk about misleading stats...

The Windows XP code base includes all of the extraneous crap that gets bundled with and on top of the kernel.

The "Linux" code base just includes the kernel.

Re:Apple != Orange

[Anonymous Coward]

If only we could actually get just the OS part of Windows I might agree with you, but seeing as you HAVE to have all the extraneous crap "because it's integral" to the product then the windows kernel encapsulates the extraneous crap and hence your argument is invalid. It's also about the %age of bugs per line of code and it doesn't just talk about windows. RTFA

Re:Apple != Orange

[Anonymous Coward]

True. My guess is that the actual kernel portion of Windows XP is as or possibly more solid than the Linux kernel.

Re:Apple != Orange

[Seahawk]

On the other hand, Linux contains lots of code drivers for products, which arent counted in the windows source code?

Still apples to oranges though - But isnt that a requirement on /. ;o)

Re:Apple != Orange

[abb3w]

The Windows XP code base includes all of the extraneous crap that gets bundled with and on top of the kernel.

This is what you get for integrating your web browser into your operating system. Legality aside, there was a low cunning to that business move when M$ did it. Now, however, that decision is coming back to bite them on the tender bits: the browser is part of the OS, ergo bugs in the browser count as bugs in the OS.

Re:Apple != Orange

[Realistic_Dragon]

It's normalised by LoCs. So as long as the average for every part of the code is the same, then it's ok.

Since you can bring down the whole of windows by a crash in one of there 8x lines of code the error rate has the same significance as the error rate in the 1x lines of Linux code. (Ie 1 error in 1000 lines is still 1 potentially critical error in 1000 lines no matter which part of the code base it appears in).

Re:Apple != Orange

[MtViewGuy]

Bingo. I think people forget that Windows XP has a LOT of stuff included with a standard installation of the operating system, especially in terms of tightly-coupled multimedia functionality.

Linux is getting there but it still suffers from the lack of hardware driver support that Windows XP enjoys and the ease of adding driver support for newly-installed hardware.

Re:Apple != Orange

[Anonymous Coward]

You obviously don't know all that much about either Windows or the Linux kernel architecture.

First of all I agree the comparison is a bit like apples and oranges, but it's not so far off if you keep in mind a few things:

First of all, the Linux kernel contains nearly every single driver available for the GNU/Linux operating system. Windows XP does not.

Of course, Windows XP includes a graphical windowing interface, which the Linux kernel does not.

However the Linux Kernel does include most of the things desired in an operating system. Two fully working and implemented sound architectures are there (OSS and ALSA). A networking stack that is infinitely more robust than the Windows one. It includes kernel modules for doing everything you could possibly imagine (and many things you can't).

There's a lot of obscure support for pretty interesting things. HAM / Amateur radio support. Bluetooth, framebuffer consoles, all sorts of interesting input devices (ranging from game pads for consoles to SUN keyboards and various touchscreens).

Basically what I'm saying is, just because Windows XP includes some things in that 40 million lines of code that Linux does not, Linux includes many things in its relatively small code base that Windows does not.

Having said that, the comparison is obviously apples and oranges, but regardless, a bug count of 985 as seen by various academic minds is very very good. It shows Linus' leadership has paid off, and bodes well for the Open Source community as a whole.

One thing I can guarantee is that if those same people went over the XP code base (even just the core kernel stuff) in the same fashion they did with Linux, the bug count would be MUCH higher.

Re:Apple != Orange

[Anonymous Coward]

he, what about Lemon != Orange instead? one gets confused with Apple's OSX.

Re:Apple != Orange

[Anonymous Coward]

But Microsoft says that Windows will be crippled without all of the extraneous crap that gets bundled with and on top of the kernel.

And you know that Microsoft is trustworthy because of the millions of bucks it spent on Trustworthy Computing.

So, I believe that the stats are fair, based on Microsoft's opinion. The study has only been performed on what Microsoft has specified as a requirement to Windows.

Re:Apple != Orange

[KarmaMB84]

Outside of the kernel, drivers and highly critical services, there isn't much that will bring down the whole system. Most services will just restart after dying and leave a message in the error log.

Re:Apple != Orange

[KozmoStevnNaut]

Quite certainly. It's just all the other junk they've tacked on to the otherwise brilliant NT kernel that ruins it.

Obviously not content with breaking compatibility with other people's products, they absolutely had to ruin their own product, too.

Re:Apple != Orange

[hackstraw]

The Windows XP code base includes all of the extraneous crap that gets bundled with and on top of the kernel.

The "Linux" code base just includes the kernel.

MS gets dinged all the time (at least by us UNIX guys) for what crud they put into the kernelspace, and much of that "extraneous crap" has caused a number of security and stability issues over the years.

Windows and Linux are fundamentally different in design and purpose. And I do believe that most of the "extraneous crap" code should be included in the kernel lines of code count if it runs in kernel space.

Re:Apple != Orange

[Jussi K. Kojootti]

One thing I can guarantee is that if those same people went over the XP code base ... the bug count would be MUCH higher.

You can? A guarantee from an anonymous coward... Well, I guess we can trust you, since you're going to lose so much face if the opposite is found to be true...

Re:Apple != Orange

[Anonymous Coward]

A networking stack that is infinitely more robust than the Windows one.
you're saying the BSD network stack is worse than Linux's. you're crazy man, just crazy. (and wrong)

Re:Apple != Orange

[Anonymous Coward]

Well thats Microsoft's fault for including extra crap in their kernel.

Re:Apple != Orange

[Chucky B. Bear]

The Windows XP code base includes all of the extraneous crap that gets bundled with and on top of the kernel.

Well thats the point isn't it. Windows uses a monolithic "kernel" which makes it huge in terms of features but not big on security/modularity. The real question should be that if we could get the windows kernel and only the windows kernel, how many bugs in comparison would that have?

Re:Apple != Orange

[cbiltcliffe]

The BSD network stack is definitely more robust than the Linux one.

The bastardized pseudo-BSD network stack hacked into the Windows collective a la the Borg, however, has obviously been somewhat massacred.
There are wierd bugs with Windows networking that don't show up in any other OS. The code originally came from BSD, but it certainly isn't BSD any more.

Re:Apple != Orange

[Anonymous Coward]

Windows uses a monolithic "kernel"

You seem to have things a bit mixed up. Linux has always been considered a traditional Monolithic Kernel. Windows NT started out as a microkernel and now is probably best described as a Hybrid Kernel

Re:Apple != Orange

[GoofyBoy]

> to that business move when M$ did it. Now, however, that decision is coming back to bite them on the tender bits: the browser is part of the OS, ergo bugs in the browser count as bugs in the OS.

You are suggesting that they should have sacrifice usability for a meaningless statistic. What a typical dumb PHB statement.

Re:Apple != Orange

[gregmac]

The real question should be that if we could get the windows kernel and only the windows kernel, how many bugs in comparison would that have?

The point would still be made. They're doing an average, so roughly you'd expect that the percentage of bugs is about the same even if you were to isolate pieces of code. Now, many people have pointed out that if the 'extraneous crap' is running in kernel space, then it should be counted as the kernel (such as the GUI, IE, etc) which I think is fair.

But anyways, let's assume their actual "kernel" is only 10 million lines of code. If it has a lower percentage of bugs, that means the rest of their proprietary code has an even higher percentage of bugs. Perhaps the kernel itself is higher, which makes things even worse.

Re:Apple != Orange

[iBod]

Agreed.

The bare WINNT kernel is a great piece of software engineering. Kudos to Mr. David Cutler and his team.

As another poster said, it's all the crap that goes around it that makes Windows a bit of a pig.

At least it's a moderately polite pig, with lipstick on, these days.

Re:Apple != Orange

[falsified]

Forgive me, O Moderators, for being blunt:

Do you use only the Linux kernel? No. You run Slackware, or Fedora, or SuSE (my personal choice), or Gentoo, or something. A fresh copy of the latest version of a distribution is what should have been analyzed. All of the other stuff that's piled onto the kernel is what you use, such as the GUI, time-killing games, and all the other shit that a standard XP install disc contains. You don't click on line 11359 of the Linux kernel to open up Konqueror. You click on an icon, which starts a process that you use. The stuff piled onto the kernel is far more buggy than the kernel would be. I'd bet that a distribution of Linux is still far less buggy than Windows is, but it's certainly not 985 vs. 800,000. For example, when I minimize my windows on XP, there isn't hard drive activity for the next five minutes, as can happen with SuSE with not very much open. I'm sure something's misconfigured, but if a distribution, in 2004, is that poorly configured by default, then that's a bug.

Re:Apple != Orange

[DrPizza]

Except it doesn't run in the kernel. Things like IE, Media Player, DCOM, UPnP, the shell, Movie Maker, Index Server, IIS (except for http.sys, which is only a tiny part of IIS), .NET, they're not in the kernel. So why should they be included? A fair comparison is between the NT kernel and its associated drivers (ntoskrnl.exe, hal.dll, *.sys) and some key user mode components (csrss.exe, smss.exe, perhaps lsass.exe, and their associated libraries), and Linux. NT's still probably "bigger" (because it contains things like all the GDI code, which doesn't much overlap with Linux), but not as much as the article makes out.

Re:Apple != Orange

[djmurdoch]

The "Linux" code base just includes the kernel.

No, they included more than the kernel. Only 1% of the bugs they found were in the kernel. You can see a bit of a breakdown of what the bugs were and where they were found here.

Re:Apple != Orange

[Politburo]

They're doing an average, so roughly you'd expect that the percentage of bugs is about the same even if you were to isolate pieces of code.

No. You have absoutely no expectation of distribution with an average. You can assume the distribution if you like, but you know what they say about assumptions.

If it has a lower percentage of bugs, that means the rest of their proprietary code has an even higher percentage of bugs. Perhaps the kernel itself is higher, which makes things even worse.

What you say about relative error % is correct. However, it's much more likely that the kernel has a lower % of bugs simply because a kernel bug is more likely to crash the entire system. As such, it is in MS' best interest to make the kernel stable before moving onto other areas (Explorer, IE, etc.).

Re:Apple != Orange

[Anonymous Coward]

In these days of Mozilla, OpenOffice, and KDE I can't believe some of you shumcks are still harping on the bloat line. The pig nowdays is yer Linux Distro.

Re:Apple != Orange

[Anonymous Coward]

If I understand the graph correctly, they were including only the Linux kernel. (i.e. No GNOME, KDE, bash, tcsh, cmatrix, etc.) However, to separate things on their graph, they chose to distinguish between device drivers (which would only be compiled in/installed as modules if you have that hardware), networking (only if you are using that variety of networking), filesystems (only if you are using filesystems of that type), several other types, and kernel (which should be running no matter what). So, kernel is being used to refer to a subset of the Linux kernel, and the entire Linux kernel is all that was tested.

Re:Apple != Orange

[MojoRilla]

You are suggesting that they should have sacrifice usability for a meaningless statistic. What a typical dumb PHB statement.

Exactly how does making the browser part of the operating system make Windows more usable?

Because they did this, I now can't remove IE if I want to. I have trouble with outlook if I set mozilla as my default browser. I can't upgrade IE without patching the OS (which means other programs that use IE components might break). There is no way for me to downgrade to earlier browser versions. There is no way for me to have multiple versions of IE installed, so it makes it hard to test. Because IE is in the operating system, Microsoft has delayed releasing new features until the next version of the OS is shipped.

I can't think of a single thing that integrating the browser into the OS buys you, except some code reusability. From my engineering perspective, this wasn't done for any legitimate engineering reason, but because of legal and business reasons.

Re:Apple != Orange

[kin_korn_karn]

In these days of Mozilla, OpenOffice, and KDE I can't believe some of you shumcks are still harping on the bloat line. The pig nowdays is yer Linux Distro.

mod this guy up. OSS is not immune to bloat.

Re:Apple != Orange

[bicho]

No, he was saying that the comparison was fair.

Re:Apple != Orange

[iBod]

I wasn't saying Windows itself was bloated.

Some of the most popular Windows software is hugely bloated however (errm... Office, Photoshop, Adobe* - you know).

Re:Apple != Orange

[Perl-Pusher]

With Windows XP having only MS word open minimized, my desktop accesses the disk and the network. So does my Linux Box. Konqueror is integrated into the KDE desktop. It's not a clean running, non-infected system I worry about. It's having to clean all the virus and spy-ware crap off of users windows machines. The users bitch to management when they don't have the rights to install software, and then are not in anyway held responsible for the ton's of crap that mysteriously appears on their hard drive. The mail server scans for viruses, each machine has up to date Norton Anti-Virus, Spy-bot and is patched immediately as patches become available. I'm tired of machines that are plenty powerfull slowing to a crawl, causing managers to whine they need a new computer. I don't have these problems with linux users, Mac users or any of the 20+ linux servers, or the 125 nodes on our cluster. I administer 4 Macs, 14 linux users, the network servers and cluster and only 6 windows machines (4 Win2K, 2 WinXP SP2). I spend approximately 60% of my time on those windows machines.

Re:Apple != Orange

[Anonymous Coward]

Actually you can't guarantee this since *no* one here has seen the kernel code. The kernel team has and always will be separate from the rest of the OS team. That core group actually writes good shit. It's the rest of the morons who give the OS such a bad name.

Re:Apple != Orange

[Anonymous Coward]

And I do believe that most of the "extraneous crap" code should be included in the kernel lines of code count if it runs in kernel space.

But the vast majority of Windows doesn't run in kernel space, same as the average Linux distro. It's an utterly nonsensical comparison. Either you compare the Windows kernel and only the Windows kernel, or you add in GNOME or KDE at the very least to the Linux codebase.

Re:Apple != Orange

[GoofyBoy]

>Exactly how does making the browser part of the operating system make Windows more usable?

Faster performance.
Better support (you know they at least have a browser no matter what they installed).

Now would you rather have that or some number (that has no meaning to the users) someone can put in a report?

Re:Apple != Orange

[happyfrogcow]

You don't click on line 11359 of the Linux kernel to open up Konqueror.

You can now. I've just created an app called Konkernel. It loads the source, and makes line 11359 clickable to start Konqueror.

[nelson]Haa-ha[/nelson]

Re:Apple != Orange

[Anonymous Coward]

M$

Please stop.

Re:Apple != Orange

[truthsearch]

Exactly how does making the browser part of the operating system make Windows more usable?
Faster performance.

Eh... no. Generally the two biggest bottlenecks for browsing are network time and HTML parsing. Network time is (currently) waiting for responses. Execution of the software network interface is a very tiny part. HTML parsing can't be improved with OS integration. Either your processor runs through the parsing code fast or slow. The only affect the OS really would have is in holding up processing, but a kernel can be made to make the browser a higher priority.

Better support (you know they at least have a browser no matter what they installed).

What's the difference? A system can determine which patches need to be installed without user input. Browser integration guarantees that browser patches would need to be installed even if the browser's not used by the user. How's that better? Considering how different each system can be (with or without browser integration) I fail to see how this matters.

Now would you rather have that or some number (that has no meaning to the users) someone can put in a report?

Some number? If the number has any real meaning behind it corporate and government procurement would be directly affected, even if the end users don't care. If I can really show that Linux has less bugs then I'm more likely to choose it for mass distribution. I'm also more likely to hire people who have developed the linux kernel since I know they either code very well, fix most of their bugs, or are humble enough to accept patches from others.

Considering IE integration provides no benefits but significant detriments I would easily choose any random number over integration.

Re:Apple != Orange

[Spoing]

1. Faster performance.

Preload it then.

1. Better support (you know they at least have a browser no matter what they installed).

That isn't an operating system issue, it's a desktop issue.

1. Now would you rather have that or some number (that has no meaning to the users) someone can put in a report?

This is for you.

Re:Apple != Orange

[StormReaver]

"The Windows XP code base includes all of the extraneous crap that gets bundled with and on top of the kernel."

When you put everything into the kernel, don't be surprised when people start including those in their kernel reports.

Re:Apple != Orange

[Foolhardy]

First of all, the Linux kernel contains nearly every single driver available for the GNU/Linux operating system. Windows XP does not. [...] It includes kernel modules for doing everything you could possibly imagine (and many things you can't).

This is an important question: are loadable modules that run in kernel mode actually part of the kernel? I'd say that they are in a somewhat grey area, close to being part of the kernel.

Windows's module system is more powerful than Linux's: NT's driver API is much more stable; you can use a driver from NT3.1 in Server2003.
More components are available as modules, including boot drivers; all the drivers requried to boot must be compiled directly into a Linux kernel (not so with NT) and the HAL which provides a generic interface to interrupt, timer, and memory control (the Linux kernel does this directly, not as a seperate component).
If you count all the drivers included with WinXP, driver.cab expanded is over 344 megabytes. Of that, I only have about 28MB installed. (in system32\drivers) OTOH, the command console, which runs the full kernel and uses the same drivers as normal takes a total of 11MB expanded in 183 files. If you don't count all the keyboard layout and NLS files, the kernel is divided into 110 modules just for the text console, not all of which may be loaded depending on hardware. According to msinfo, I've got 120 seperate kernel modules currently loaded.

However the Linux Kernel does include most of the things desired in an operating system. Two fully working and implemented sound architectures are there (OSS and ALSA). A networking stack that is infinitely more robust than the Windows one.

There are NT kernel modules for Win32 including USER, GDI, DirectDraw, and Direct3d, DirectSound, protocol drivers such as TCP/IP and SMB, huge libraries of input and output devices.

What's so bad about tcpip.sys that makes it inferior to Linux's implementation? I was under the impression that it was based on BSD's stack. Or are you saying is it something fundamentally wrong with the IO architecture? NT's IO arch comes from VMS's asynch design. TCP is just another IO device that uses special IOCTL commands. IRPs are allocated and used just like disk access.

Re:Apple != Orange

[Anonymous Coward]

Of course people who are compentant enough to use a Linux machine, aren't of the same user level of Windows users. I would bet you, if you could take all of the stupid people destroying windows and put them onto a linux machine, the distro would not be functional within a week.

A competant windows user can keep his system operating at almost peak efficiency. I've gotten 1 virus in my life. I'm on a DMZ no firewall. I run a full virus scan once a month just to be sure, and havn't run an update from Windows Update for months. My system runs just as fast as when I bought it. And my applications rarely crash.

Re:Apple != Orange

[GoofyBoy]

>Eh... no. Generally the two biggest bottlenecks for browsing are network time and HTML parsing.

Start up time and rendering speeds are fast for IE.

re: Support
>What's the difference?

Try supporting 5 different applications vs. one. Over the phone. With a user with no training or previous knowledge.

>If the number has any real meaning behind it corporate and government procurement would be directly affected, even if the end users don't care.

I'm questioning the statistic mentioned is valid or not. Can this number even be trusted?

Re:Apple != Orange

[merdark]

Exactly how does making the browser part of the operating system make Windows more usable?

In the same way that the Apple WebKit + safari makes OS X more usable, or KHTML + konqueror makes KDE more usable... or (mozilla html) + epiphany makes GNOME more usable.

I can't think of a single thing that integrating the browser into the OS buys you, except some code reusability. From my engineering perspective, this wasn't done for any legitimate engineering reason, but because of legal and business reasons.


And code reusability is not valuable? Perhaps KHTML should not be part of KDE then, and Gnome should not distribute a browser and HTML engine in the main distribution either.

You must be a very poor engineer if you think that forcing every application developer who needs to embed an HTML renderer into their program to create one from scratch, or distribute some third party engine, is a good idea.

All of the 4 major desktop systems in use today have included a browser and rendering engine.

Re:Apple != Orange

[truthsearch]

Start up time and rendering speeds are fast for IE.

And both can be achieved without OS integration. Rendering for any 3rd party app can be direct to the video driver if the OS allows it. That's not integration.

It's already been proven that startup time for all Office apps is from hidden API calls near the start the executable code. They load the visual interface before the application's actually ready for use. That plus pre-loading of DLLs gives fast startup. Office isn't considered part of the OS, yet IE is. Therefore fast startup times have nothing to do with integration.

Try supporting 5 different applications vs. one. Over the phone. With a user with no training or previous knowledge.

I have. An entire office of old-fashioned accountants who prefer ledgers and pencils. How is blending 2 apps tightly together better than having 2 separate apps? If there's a problem with Firefox I can tell someone to not launch it. If there's a problem with IE parts of it are in memory whether I choose them to be or not. If there was less integration in Windows then it could be trimmed down to a minimal size for each user. Instead everything including the kitchen sink must continually be supported. You're only increasing your headache by using Windows and its tight integration.

I'm questioning the statistic mentioned is valid or not. Can this number even be trusted?

Not as purely fact. Yet someone who reads the study may determine that it's better to have the code open to all who can fix bugs instead of one select group. Or it may give insight to management that security can be better achieved when they can have their own people analyze the code. When read properly I don't see how anything but good can come from a study such as this.

Re:Apple != Orange

[Anonymous Coward]

This post is moronic. You're redifining an OS definition so you can criticize MS. You're just another idiot who has a belief and manipulates facts to fit his belief system. Congratulations, you're on par with G.W. Bush

Re:Apple != Orange

[donnz]

Poorly presented article no doubt. But the kernel stability is critical when one starts considering use of OS for servers and enterprise application. Frankly, I don't want IE as part of my OS on my database servers, firewalls, web servers and the like.

Re:Apple != Orange

[falsified]

Yeah. I know. I didn't say anything about security. To be crude, Microsoft is less secure than a freshman girl's virginity on prom night. A lot of those aren't bugs, though, because people voluntarily installed those programs and they don't have to do with Windows except for that the programs are Windows-compatible.

Re:Apple != Orange

[drsmithy]

Well thats the point isn't it. Windows uses a monolithic "kernel" which makes it huge in terms of features but not big on security/modularity.

What definition of "monolithic" are you using here ? Because in CS/OS design terms, the architecture and design sure as hell aren't "monolithic".

Re:Apple != Orange

[f16c]

"Am I the only slashdot user that thought that Minority Report qualified as a horror movie?"

No

Re:Apple != Orange

[quarkscat]

Microsoft's attempt to leapfrog into the
Internet age by closely integrating IE into
the OS has been an unmitigated security (and
PR) disaster for Microsoft. It did, however,
do two important things for Microsoft:
(1) it destroyed the market leader Netscape,
and
(2) staved off a DoJ split of Microsoft into
bits and pieces.

No doubt that Microsoft considers the "gain"
much greater than the "pain", since most of
that PAIN is borne by their "captive & loyal"
customers. I have yet to see a TCO analysis
that "spanks" Microsoft for the continuous
spate of viruses, worms, trojans, and spyware
that infect their customers' computers.

Real science

[coopseruantalon]

It is nice to see som real documentation from independt institutions that document what we have known for a long time. I took note of thge fact that the test had run for 4 years. That's some testing period. Hope that keep MS quiet for some time.

Re:Real science

[Anonymous Coward]

4 years!?

Gosh, that's even slower than the European decision process!

My thought, too

[Kythe]

Since they've found all 985 bugs in the 2.6 Kernel, did they submit them for fixing, or submit patches to fix the bugs themselves? Seems like a waste to just count the bugs, rather than fix them.

Re:My thought, too

[chialea]

I'm not sure if this is my friend's research (he's a PhD student at Stanford, and works in this area), but he has submitted patches for bugs found in the course of his work to all sorts of open-source projects. He has had a TERRIBLE time getting people to actually use them. This frustrates him, very much.

Moral of the story: if you want people to do research on finding and fixing bugs on your software, take their patches regularly, and think about thanking them for it.

Lea

Re:My thought, too

[chialea]

(Err... just a note. The reason he's had trouble getting people to use them is not code-related, it's more ego-related. This, for me, really reinforces the moral -- be nice to people who patch your code as part of their research.)

Lea

Re:My thought, too

[chgros]

Since they've found all 985 bugs in the 2.6 Kernel, did they submit them for fixing, or submit patches to fix the bugs themselves? Seems like a waste to just count the bugs, rather than fix them.

• We have better things to do (like improving our tool and selling it)
• It's probably better to let the people responsible for the code fix it. We're not familiar with it, we might add more bugs, and also have trouble getting our patches accepted.

Now tell us what the bugs are

[Anonymous Coward]

so we can fix them.

Re:Now tell us what the bugs are

[1u3hr]

RTFA: they were working on the code from 2000; took them four years to analyse it. So the code they were looking at has been patched in current versions: "Seth Hallem, CEO of Coverity, a provider of source-code analysis, noted that the majority of the bugs documented in the study have already been fixed by members of the open-source development community."

Re:Now tell us what the bugs are

[mahdi13]

How could they analyse the 2.6 kernel 4 years ago when 2.6 is less then a year old?
ReadingTFA: "The Linux source-code analysis project started in 2000"...

This is an ongoing study, to find the bugs checkout Bugzilla.kernel.org it's not like they hide them or anything

Desktop OS

[Geoff-with-a-G]

They're calling Windows XP a Linux "rival"?

If you're really itching to do a Windows vs. Linux comparison, you should at least be looking at Windows 2000 or Windows 2003.

Re:Desktop OS

[ceeam]

Is Windows 2003 a rival for a Linux deep inside my DVD player or do you imply something?

Re:Desktop OS

[KarmaMB84]

It most certainly could be since it uses an updated NT/2000/XP kernel. Obviously not the whole thing, but a stripped down version like they did with win2k and xbox.

Re:Desktop OS

[SammyTheSnake]

Remember this study's been going 4 years, I assume (no I haven't RdTFA, but it's hardly difficult to guess) they were analysing a version of linux from four years ago, and similarly a version of windows from four years ago (circa 2000) which would be XP or w2k.

Cheers & God bless
Sam "SammyTheSnake" Penny

I always suspected

[pymerej]

That Linux is more bug free than it's rivals. It's nice to be able to show my clients. "Look! There really are less bugs than Windows server software!" With this, more of them may actually believe me.

Re:I always suspected

[Anonymous Coward]

Hmm, if I was your client, and you showed me this article and expected it to convince me that your unprofessional Linux zealotry has some actual substance behind it, I'd fire you.

SK

Re:I always suspected

[pymerej]

I actually have no unprofessional Linux zealotry. I'm not a Linux zealot at all. I use Linux for a webserver - that's it. I understand that my clients want Microsoft software on their network, and have no problem with that. I have Microsoft software running my network. I don't even bother quoting Linux solutions.

I do try and answer questions when my clients ask me about Linux. The more facts I have, the better answers I can provide. If you wanted to fire me for that, then that would be your perogative. I can't say I would want to work for someone so shortsighted as to evaluate one statement as a total basis of my beliefs and fire me based solely on that.

Very accurate count

[Bas_Wijnen]

985 bugs? That sounds like an exact number. Of course that is possible, it being open source, but I hope they don't believe that they found them all. Debugging is quite a profession on itself, and I don't think anyone has found the ultimate "solution" for it.

Anyway, I sure hope they at least reported the bugs they found. Being the best is no reason not to want better. (And no, I did not imply that Linux is the best existing kernel.)

This headline from the No Screaming S--- Dept.

[HangingChad]

Finally! A study to document the entirely obvious.

Re:This headline from the No Screaming S--- Dept.

[djeddiej]

it may be obvious like a bug in the fog...this article does not prove anything. In other words, it may be said that Linux is less buggier, but it is also smaller, has a smaller user base, and really the comparison did not do a full scale analysis of what typically runs on these OS's in a given session. So think a little more before screaming Linux wins. (or Windows Wins, or Z80 wins)

Not completely scientific

[The-Bus]

First off, what does this statement mean?

"[Linux has] 985 bugs in 5.7 million lines of code, well below the industry average for commercial enterprise software. Windows XP, by comparison, contains about 40 million lines of code, with new bugs found on a frequent basis."

So Linux has 985 bugs. Windows has bugs that appear frequently. Ok that doesn't really tell me anything. I tried to dig a bit deeper and came up with: "Coverity has not analysed the source code to Microsoft Windows because the company does not have access to the source code, Hallem said. Apple Computer's Mac OS X has a great deal of proprietary programming, but the core of the operating system is based on BSD, an open-source operating system similar to Linux."

So everything is based on estimates. Now, you know and I know that the Linux kernel has less bugs... but this is a tentative (at best, shoddy at worst) way of presenting that idea.

Re:Not completely scientific

[chris mazuc]

*ahem*

It's still better than what Microsoft comes up with most of the time. At least we don't quote references that actually prove the opposite of what we're trying to say.

Re:Not completely scientific

[phasm42]

Are you implying that because MS is worse, their shoddy work is OK?

Re:Not completely scientific

[chris mazuc]

I was referring to Ballmer's propoganda campaign. I'd rather point to a shaky source and declare it as such than point to a source that only says what I want it to say because it is taken massively out of context.

Re:Not completely scientific

[danila]

I think, this (at least the reporting in Wired) is even less scientific than you imply. How the hell can the statement Linux contains 985 bugs can be true? I mean, did they just count missing semicolons or something? You can never be sure that the code you are looking at doesn't contain more bugs than you are aware of. A combination of several pieces of perfeclty valid code can produce a bug.

Someone may confidently say that Linux contains at least 985 bugs - here is the list or that Linux contains about 1000 bugs - we check the whole source code, found 100 bugs and from experience we know that we usually miss 90% of them. But to imply that they found each and every bug or that they know the precise number of bugs without actually finding them is baloney.

Re:Not completely scientific

[the_ed_dawg]

So everything is based on estimates.

Slashdot has seen these guys before. Basically, Dawson Engler (professor at Stanford who founded Coverity) has made a career out of detecting software bugs by checking for redundant or dead code. While his work is very impressive, he isn't really detecting every bug anyway. It gives a good idea about the frequency of bugs to estimate the number of errors.

That said, I agree with your statement about Windows. It would have been better to have left rephrased that one.

Re:Not completely scientific

[risinganger]

"So everything is based on estimates. Now, you know and I know that the Linux kernel has less bugs... but this is a tentative (at best, shoddy at worst) way of presenting that idea."

You're right. Absolutely correct but what can you do about it. Most commercial offerings will of course be closed source as is their right and we have all seen what 'independent reviews' from Microsoft are like and who can blame them really? If you owned Microsoft would you really want reports being dispersed that said your software was so flaky a minor breeze would take it out if those reports came from your own company? (I'm not trying to suggest that it is that bad, just saying for examples sake but surely nothing can look worse than saying your own product is crap*).

Quite honestly it is surprising sometimes how unscientific some research is at times (just an observance in general) but every so often I suppose we need it to help balance out the crud from the other side.

and somewhere in between you hope is something approximating the truth...

* With the exception of when you have brought out the new improved model

Re:Not completely scientific

[megarich]

Aren't all statistics that way?

Anyhow how did this become a linux v windows discussion when the article does say other os' too?

And back on your point on estimates, how do we know this is the full windows code they're referring to? Forgive me for my lack of knowledge in the lengh of windows code but could it be possible that that's not the complete code or only the code the refers to the os and now the other stuff included like some other posts?

So whose right and whose wrong? You know what? It doesnt matter because even if one side was more secure and less buggy than the other, I doubt that'll change people's opinion to stop arguing at this stage of the game....

Re:Not completely scientific

[zurab]

So everything is based on estimates. Now, you know and I know that the Linux kernel has less bugs... but this is a tentative (at best, shoddy at worst) way of presenting that idea.

The way I see it is that the research itself compares bug frequency in Linux vs. other commercial closed source projects that they have analyzed in the past. Windows XP, OS X, 40 million lines, "new bugs found on a frequent basis" are garnishings brought to you by CNet and /. for their respective readers' flamebaiting experience.

Re:Not completely scientific

[MikeWin10]

Glad to see that someone out there is not ignorant. No one can even begin to put a number on WinXP bugs per line of code. Besides, I have had fewer problem with things breaking on reboot with winxp then linux. Every time I reboot linux, drivers seem to get hosed, so I spent the next 20 minutes reconfiguring devices...hmmm and this is supposed to be better???? At least WinXP just works.

Re:Not completely scientific

[Sebastopol]

They authors were also overheard asking the questions:

"Do you walk to school, or carry your lunch?"

and

"Is it shorter to New York, or by train?"

Boners.

Re:Not completely scientific

[Anonymous Coward]

>> I was referring to Ballmer's propoganda campaign.

Which has not a damn thing to do with this article.

Re:Not completely scientific

[vrTeach]

So everything is based on estimates. Now, you know and I know that the Linux kernel has less bugs... but this is a tentative (at best, shoddy at worst) way of presenting that idea.

This makes sense to me, trusting IT information that you get from Wired is kind of like trusting information about women that you get from Playboy. Sure, it's the subject matter of the publication, but is there really any effort at understanding? Doesn't look like it.

Re:Not completely scientific

[drsmithy]

Now, you know and I know that the Linux kernel has less bugs...

How ?

Re:Not completely scientific

[Anonymous Coward]

It might not be scientific, but it gets the message across. Linux is good, Microsoft is bad. We all know it, but they put it out for all to see for the point of hammering the point home. Linux is a kernel. The smallest part of whatever Microsoft calls a kernel was also compared. If Microsoft stuck a pile of crap into their kernel, then that's their fault. Integrating browsers, solitaire and whatever into an operating system is a bad idea, primarilly from a code design, maintenance and management point of view. There are no (zero) advantages in terms of speed to shoving everything into one place. Microprocessor program counters can take addresses from anywhere with equal ease, whether they are local or remote. Also, Microsoft has no problems comparing it's "mere kernel with browser and desktop manager" up against a six CD Linux distribution (with compilers, design libraries, graphics programs, dozens of games, video titlers, sound programs, word processors, text editors, accounting programs, screensavers, office suites and everything else, and comparing bug counts. The M$ whores never rant about that one, now do they?

Number of rivals?

[farnerup]

1. Linux Has Fewer Bugs Than Rivals
2. Novell and other major Linux software vendors, contains 985 bugs

Ergo: there are at least 987 operating systems in the world.

Re:Number of rivals?

[Anonymous Coward]

ITYM 986 HTH HAND.

Re:Number of rivals?

[Anonymous Coward]

Duh! There are at least 987 LINUX DISTROS alone!

I'm running Heronzalitix GNU/Linux, which was designed for left handed blonde heterosexual Canadians who prefer Fluxbox, strongly support RMS' position on the evils of proprietary software, and run mainly business apps -- but only from the hours of 10am-2pm, with a strong focus on security and Slashdot as my home page.

I don't know why people complain about Linux; trust me, there's a distro out there that's tailored JUST FOR YOU.

Re:Number of rivals?

[Anonymous Coward]

Man this is disapointing. First, we find that OpenBSD.org run on Solaris, and now we find that Theo is running Linux 4 hours a day. How many left-handed, blonde, straight Candians can there be that support RMS?

Re:Number of rivals?

[Anonymous Coward]

BZZZZTTTT!!! You forget that Theo is sandy blonde; that requires a totally different distro.

Huh?

[PrvtBurrito]

Since they didn't compare it to anything else, maybe their method just had low sensitivity? For example, I could analyze linux, find one bug and then be done. Linux has only one bug. Obviously my method is flawed. It only works appropriately when you actually apply the same protocol on a control, that is actual commercial buggy code. And to make the comparisons they want to windows, they should actually run windows code. (For all I know they could have done this, but the article seems to focus a lot on a comparison between linux and windows, and they didn't even test windows.)

More /. FUD

[m00nun1t]

If the same article were submitted but used windows instead of linux, it would have either been rejected or severely criticised in the abstract.

Re:More /. FUD

[ceeam]

Hmm, maybe because:

1) It would be untrue.

2) _This_ article has about the same chance to appear on microsoft.com as .... well, help me here :)

Re:More /. FUD

[phasm42]

Mod parent up. Although I may believe Linux has fewer bugs, they don't really present any facts to support this other than some vague statement that Windows has "new bugs found on a frequent basis", and some blanket statement with a figure they pulled out of their ass about commercial software, "20 to 30 bugs for every 1,000 lines of code. The reporter for that article did a crappy job in his research. I'll bet that if CyLab is as good an institution as it's made out to be, the people doing the research are probably pissed about how full of it this Wired article is. The reporter probably twisted a couple vague statements he got from someone at CyLab.

Re:More /. FUD

[chialea]

Heh. I'm part of CyLab (though I tend to work with other people); it's a collection of researchers at CMU. I'm not sure whose work this is, though I would guess that the reporter is stating the results of some research. It's an average figure, however, and I'm not sure exactly what they examined to obtain it.

The upshot is that it's a vague statement, and I'm sure it has to do vaguely with some good research. I'm sure the Stanford researchers did a good job, too. Reporting just tends to do somewhat of a gloss-over job, which sometimes makes the statements inaccurate. Notice that you regularly see letters from the researchers correcting last month's stories in any popsci magazine. This is no different.

Lea

Re:More /. FUD

[Anonymous Coward]

Mod parent up.

Anyone who says that should be auto-modded down to "-5 buttmonkey"

Linux Kernel vs Windows XP

[vasqzr]

What about if you throw in KDE or GNOME, Mozilla, etc, everything that you'd have to add to really equal the features of Windows XP....

Re:Linux Kernel vs Windows XP

[Realistic_Dragon]

Crashing KDE won't kill your system. System services will keep on rolling just fine.

Crashing the Windows shell will nuke the whole box, web servers, ftp servers, application servers and all.

Obviously the distinction for a desktop user is minor, since your desktop is gone and your work with it, but if you are running servers the separation is VERY important. A KDE crash (unlike a hard lock from windows shell bringing down the system) doesnt lead to:

Service unavailability for customers.
Possible disk corruption (disk writes not completed).
Potentially having to rebuild a volume from raid or journal.
Loss of state based data (eg from a web app).

And so on. Add to this that users for whom stability is critical won't even be running a desktop on a Linux system and you can see why this is a real world metric for users who aren't relying on all of the extra crap that they cannot disable in the NT kernel.

Re:Linux Kernel vs Windows XP

[beuges]

the windows shell is explorer.exe, microsoft's equivalent to kde. if explorer.exe crashes, web servers, ftp servers, database servers, and anything else running on the box, even user applications that are not tied in to the shell, will continue to run unhindered. so, to respond to your first statement, crashing explorer.exe wont kill your system (do it yourself on windows xp, go to task manager and kill the explorer process). system services will keep on rolling just fine. contrary to /. belief, the windows shell is not "tied in" to the windows kernel any more than kde is tied into bzImage.

Re:Linux Kernel vs Windows XP

[Mr. BS]

I rather not throw in KDE or GNOME, Mozilla, etc, and would still have something that would SURPASS the features of Windows XP!

Re:Linux Kernel vs Windows XP

[cybrthng]

Not true at all.

KDE can "krash" a system just as bad - if not worse than XP/Windows with explorer.exe running.

Windows has been recoverable to a great extend since 2k by ctrl-alt-deleting and killing explorer.exe - if it doesn't restart then ctrl-alt-del - file - new task/run -> type "explorer.exe" and voila your desktop is back..

This is really comparing apples to oranges without even being able to open up the orange to have a peek at anyhow.

Re:Linux Kernel vs Windows XP

[squiggleslash]

Crashing the Windows shell will nuke the whole box, web servers, ftp servers, application servers and all.

Nonsense. That wasn't even true back in the Win9X days. Crash Explorer.exe, and Windows will restart Explorer.exe; in the mean time the rest of your applications - including those that have windows open - are available for you to use.

It's possible that crashing the underlying windowing system would result in a blue screen (unlike, say, X11), but crashing KDE vs crashing Explorer.exe gives pretty much the same results.

Re:Linux Kernel vs Windows XP

[LiquidCoooled]

Our Windows server doesn't need a desktop to run. Things operate as services, not as interactive desktop applications.

I log into the administrator account when I need to do things on the machine, otherwise it sits idle.
If the admin account decides to die, everyone just carries on regardless.
The one time the machine stopped operating as expected was when the DVD writer corrupted itself and stopped the local administrator from logging out, all remote users still carried on regardless.

We have had zero effective downtime since it was installed over 2 years ago, users have never encountered connectivity or access problems.

Maybe it was the case with 98 etc, but windows 2000 has been very stable for our uses.
We have more problems with routers and clients than the server itself.

Re:Linux Kernel vs Windows XP

[LWATCDR]

I have had Explorer crash a few times and have lost nothing and the services keep right on going. The HUGE flaw in XP is that Microsoft moved the video driver down to the kernel level. A bug in the video driver can bring a windows box to it's knees. Very bad for a server.

Re:Linux Kernel vs Windows XP

[Chucky B. Bear]

hehe. Your really thinking of this the wrong way around...

What if we could remove internet explorer, notepad, solitaire etc. etc. etc. from windows xp so that we only have a windows kernel left to test against? There should be no reason to want to turn Linux into a monolithic kernel whereas I can think of quite a few reasons why windows should rather not have one. (A certain GDI jpg bug comes to mind.)

Remember the bugs counted was found in the Linux kernel as oppose to finding it in OSS. They're comparing it against Windows XP for lack of anything else Windows to compare it against. A kernel should not be full of features but rather give your "features" access to your hardware. Just my 2p.

Re:Linux Kernel vs Windows XP

[Mordaximus]

"What about if you throw in KDE or GNOME, Mozilla, etc, everything that you'd have to add to really equal the features of Windows XP...."

Why do you assume that a system even needs a GUI or Browser? Not all systems are desktops. GUIs and Browser are not server "features", heck, they have NO place on a production server at all. Period.

Why don't we throw KDE and Mozilla into the mix... because we don't HAVE to. Microsoft made the ill conceived decision to integrate a poorly designed browser into their operating system. Other's should not have to suffer as a result. Likewise, they decided that the OS should be dependant on the GUI. They made the choice to NOT be able to remove these items. They can lie in that bed now.

So, your comment has shown, that apart from being well coded, Linux (and BSD etc.) also soundly designed. Unlike what our simian friends at MS dish out.

Re:Linux Kernel vs Windows XP

[Anonymous Coward]

Yes and no. Theres different meanings of the word "shell" here. Explorer.exe is *just* a shell - it's basically a file browser, of which the desktop is a special case. Explorer.exe crashing won't even disable your applications - it's just another application.

So yes, the GP was incorrect in saying that the "shell" crashing will crash the machine. However, other parts of Windows that correspond to KDE, like the window manager, can crash the machine when they go down, because they run in the kernel. Not all of them, though, because some of them run as services, like the theme engine.

Basically, the architectures are sufficently different that it's pretty hard to draw an simple comparison between them.

Re:Linux Kernel vs Windows XP

[isorox]

I dont want the features of KDE, Mozilla or Windows XP on a server though. With a linux distro I dont install them, with windows?

Re:Linux Kernel vs Windows XP

[Anonymous Coward]

> Very bad for a server.

Yeah, I've been working with NT4 since it came out and have never seen a server crash due to a video driver. Bad idea in theory, not a problem in practice. (You want to complain about something in Windows, how about the in kernel print architecture used in NT4.)

Actually, XP is better in this regard, if the retarded ATI driver crashes, it usually drops back to SVGA mode.

Re:Linux Kernel vs Windows XP

[kidgenius]

Yeah, and I can hit ctrl-alt-backspace and easily kill any running WM. What's your point? It still didn't bring down the kernel. Whereas in Windows, I have had times where the computer is just plain non-respondent. It's hard-locked.

Re:Linux Kernel vs Windows XP

[Anonymous Coward]

"The report, set to be released on Tuesday, states that the 2.6 Linux production kernel, shipped with software from Red Hat, Novell and other major Linux software vendors,"

Read the bloody story lamer.

Re:Linux Kernel vs Windows XP

[Anonymous Coward]

If it runs in kernel space it is part of the kernel.

Re:Linux Kernel vs Windows XP

[Al Dimond]

Well, right. The architectures are different so they crash and burn in hilariously different ways.

On a Windows machine I used to use at work if I printed to a printer that was down from MS-Word the computer would completely lose it to the point where explorer.exe had to be killed (actually it would pop up the alert saying that explorer.exe is not responding, would I like to end task, so I clicked yes). I've actually never seen a Windows computer that ran smoothly after killing explorer.exe, every time I've done it I've had to do a restart to make it work well (that's probably because there was something else going wrong too). At least you can still save documents, etc., after killing explorer.

On this here Linux box, if I ssh to University Solaris machines and use -X instead of -Y and start a remote X app, my system goes to a grinding halt. To get out of that I have to switch to the console (which takes about 10 seconds) and kill ssh, because X is completely unresponsive (keystrokes in the console are slow as well, but it's at least usable). Although once I kill ssh it runs perfectly well, and I remember to use -Y next time. I've never had my Linux box crash to the point where it had to be restarted, but I don't run KDE or Gnome, so if those can really take a computer down I wouldn't know.

Re:Linux Kernel vs Windows XP

[Twanfox]

Certain problems exist with simply end-tasking explorer.exe with Windows. What happens if explorer.exe has issues when it starts up? Just doing an End Task/End Process on it will cause it to restart, and bounce into the same problem again.

Why does explorer also decide to restart every application that it normally would on startup, yet fails to re-iconify basic system services into the system tray? This leads to increased memory usage and the user having to log out and log back in just to get their volume controls back. To be properly effective during a restart, Explorer must detect and re-iconify any application that resides in the system tray. Those that are not, and exist only in the system tray, will not be retrievable unless those icons reappear.

Those are just two big ones. As someone else said, if Explorer blocks against, say, looking up a network drive and then fails to recover/timeout (simply an example), you may not have sufficient resources remaining to start up the Task manager, dispite the forced real time priority of that manager. The system becomes basically deadlocked, and requires a full restart to regain control.

Re:Linux Kernel vs Windows XP

[been42]

That's a good point, if you're looking at a desktop system. Most people use one of the 2 big desktop environments. However, a Linux server isn't always going to have the desktop environment installed, so we don't have to worry about KDE bugs. Windows doesn't really give you that option so the whole package has to be included.

So if I'm looking at numbers for a server system, then I'm going to want to check the system that's closest to what I'll put in production. If I'm purchasing desktop systems for work, then I will have to go somewhere else to find information on GNOME and KDE bugs. If I'm purchasing a desktop system for my house, I just go to www.apple.com and click "Buy".

Re:Linux Kernel vs Windows XP

[cybrthng]

And whats your point?

For me, on EVERY system i've had over the past 2-3 years KDE/Linux or Gnome/LINUX crashes more than Windows. HARD crashes.

These are systems ofcourse running gimp, or wine, or openoffice and playing games such as UT2k4 and Doom 3 - So they're getting heavy use.

Getting back to the bug discussion my point was that with all the fluff both operating systems have the same crashing habits.. Add in overclocking, hacking, cracked programs and or anything else to the mix (such as a poor admin or newbie end user) and the risk of crashes jumps 1000 times..

Re:Linux Kernel vs Windows XP

[cybrthng]

Certain problems exist with simply end-tasking explorer.exe with Windows. What happens if explorer.exe has issues when it starts up? Just doing an End Task/End Process on it will cause it to restart, and bounce into the same problem again.

True - but this exists under KDE as well.. if kdm is in a loop of crashing because of something crashing it or a bad configuration setting your in the same boat. You can just as easily kill the bad process or startup regedit or run a regcleaner on windows to recover as you could kill kdm and cleanup your confs from a shell prompt on linux/unix.

Why does explorer also decide to restart every application that it normally would on startup, yet fails to re-iconify basic system services into the system tray? This leads to increased memory usage and the user having to log out and log back in just to get their volume controls back. To be properly effective during a restart, Explorer must detect and re-iconify any application that resides in the system tray. Those that are not, and exist only in the system tray, will not be retrievable unless those icons reappear.

Behavior for explorer.exe is different on 2k/xp and xp with sp2. With sp2 i have no issues restarting explorer and everything coming back to life - even the taskbar and startup iconsl.. anything previous to sp2/xp..

I don't generally have a problem with windows crashing unless i'm farting around with it - and this same farting around in linux often casuses the same crashes.

A good admin will keep a windows box running as long as any linux box these days..

Re:Linux Kernel vs Windows XP

[Darren Winsper]

Care to tell us how?

Re:Linux Kernel vs Windows XP

[Zemplar]

"What about if you throw in KDE or GNOME, Mozilla, etc, everything that you'd have to add to really equal the features of Windows XP...."

Then you would have a buffer overflow!

Re:Linux Kernel vs Windows XP

[latroM]

What about if you throw in KDE or GNOME, Mozilla, etc, everything that you'd have to add to really equal the features of Windows XP....

Then it wouldn't be Linux anymore. Linux is actually the only well defined piece of the operating environment.

Re:Linux Kernel vs Windows XP

[Anonymous Coward]

No it doesn't, you don't know what you're talking about.
If you get a hard crash, 99% of the time it's a hardware/driver issue (windows and linux). You need to USE THE RIGHT F'ing DRIVERS MORON. That, or put the screws in on your pci cards, slipping pci cards cause instant lockups too :).

It's pretty tough to hard crash linux based on bad software; it kills programs that ask to allocate more RAM than is left. You can make the machine unusably slow for several minutes to hours though!

Re:Linux Kernel vs Windows XP

[globalar]

"x per lines of code" analysis has further less and less relevance to reality.

We need new metrics, because this was almost a waste of time to prove the obvious: the (somewhat) distributed, open source development process can produce competitive, professional software.

That aside, we need metrics that we can use to not only compare software, but direct improvement. Lowering bugs per lines of code, for example, does not necessary make better, or even more stable, software. It is just not that simple and we're dumbing down analysis when we try to make these figures dance. What kind of metrics judge good code?

Re:Linux Kernel vs Windows XP

[FuzzyBad-Mofo]

Just as unfair as when they compare the number of flaws in a Windows distribution (not much software besides the base OS) to the number of flaws in a complete Linux distribution (with thousands of applications).

Re:Linux Kernel vs Windows XP

[T3kno]

I really have to disagree, even if the system (*nix with X) seems completely unresponsive to the user it's usually still talking on the network. Several times I've had to ssh into my workstation and kill X, KDE or whatever was making it freeze. The only time you're really screwed is when you see Kernel Panic. It is possible to completely freeze a linux machine, it's also fairly hard to do. Just because X froze and your keyboard and mouse don't work doesn't mean the machine is completely dead. Where as a BSOD in Windows is the end of the road.

Re:Linux Kernel vs Windows XP

[HydrusZ]

Just doing an End Task/End Process on it will cause it to restart, and bounce into the same problem again.

Not true in 2000 or XP. Explorer will not automatically restart itself if it was manually shut down.

Why does explorer also decide to restart every application that it normally would on startup, yet fails to re-iconify basic system services into the system tray?

That's the app's programmer's fault for not adding one more line to listen for a TaskbarCreated event. Volume control does come back, Norton Antivirus for one, doesn't.

Re:Linux Kernel vs Windows XP

[drsmithy]

However, other parts of Windows that correspond to KDE, like the window manager, can crash the machine when they go down, because they run in the kernel.

I think you mean the display system (GDI, roughly equivalent to X) not the "window manager". It runs in kernel _space_ (note: different to in the kernel itself).

Food for thought...

[JFMulder]

Maybe there's so many bugs in recent Microsoft OSes because the code base is starting to get so huge that it's harder and harder to modify a known API without breaking something by mistake.

After all, maybe there's 10 times the bugs in Windows because there's 10 times the code. Earlier mistakes were mostly squashed out, but API or workflow defeciencies always come up late in development, no matter how you plan and when you have something as huge as Windows, it might be hard to reverse the direction they have taken and have to make do with what they have now. It's not as if Microsoft OSes are based on any variant of Unix or something.

Maybe the people who work at Microsoft aren't all big nerds who know 40 million of code by heart.

Re:Food for thought...

[risinganger]

"Maybe the people who work at Microsoft aren't all big nerds who know 40 million of code by heart."

True but considering they get paid a damn sight more than I do maybe they could at least try... ;-)

Re:Food for thought...

[LiquidCoooled]

Maybe the people who work at Microsoft aren't all big nerds who know 40 million of code by heart.


Billy knows and cherishes every single line of code.

Retarded report

[0x54524F4C4C]

It's a comparison between oranges and apples. Windows has a GUI and a huge userland with complex applications. Linux is just a silly kernel (yes, silly if compared with the other OSS alternatives -- and definitely buggier than the others). But since it goes into slashdot's agenda, let's give it all the latitude.

I particularly like Morton's comment

[youvegottobekidding]

It stands in stark contrast to some recent comments of the proprietary software spokesmen.

Redundant?

[fuyu-no-neko]

A redundancy score?
Is someone trying to say that the redundancy in XP is in the form of redundant bugs? :oO

"Ha, you may have squashed one bug, but we have 10 more in there doing exactly the same job!"

Kernel is not the problem

[Anonymous Coward]

... the ongoing inability of creating a proper desktop environment is. I want to be able to use commands like cut'n'paste in between all programs, from terminal to OOwriter. Also, the driver version stuff can be done better. When I upgrade a kernel I don't want to recompile my Nvidia driver. It should just _work_. The fact that open source software can be the root of something that does work, is proven beyond doubt by Apple's OS X.

Re:Kernel is not the problem

[jacksonj04]

Amen to that. I have never been a big Apple fan, but one thing I will say in their favour is that it just works.

Even on Windows machines, Apple software just works. iTunes shares music across the network with a single checkbox and everything else just works. I plug my iPod in and it just synchronises, and comes up with a playlist based on what I listen to and what I like.

Doing something similar with a combination of vendors? Not a chance. Doing something similar on Linux based systems? Possible certainly, but I don't want to have to write it.

Linux Kernel is solid. Sadly, once you put useful applications on it (like the ones that make WXP 40 million lines long) it will fall apart.

Re:Kernel is not the problem

[quamaretto]

I appreciate your post generally, but...

Linux Kernel is solid. Sadly, once you put useful applications on it (like the ones that make WXP 40 million lines long) it will fall apart.

..I call bullshit on this assumption. Please provide an example of what Windows XP does that Linux does not do, which would require augmentation of the core software.

Re:Kernel is not the problem

[genjo]

Obviously that depends on your definitions of "useful" and "fall apart".

Re:Kernel is not the problem

[Noryungi]

Linux Kernel is solid. Sadly, once you put useful applications on it (like the ones that make WXP 40 million lines long) it will fall apart.

Riiiiiiiiiiiiight.

Here is a clue for you: my main Linux machine is a laptop, running all the applications that I need. Examples:

• GUI = XFCE, Fluxbox
• Surfing the web = Mozilla, dillo
• Writing a document = Abiword, LyX, vim
• Creating a spreadsheet = GNUmeric
• E-mail = Sylpheed, mutt, pine
• Programming = Python, Perl, C, C++
• Graphics = EyeOfGnome, Gimp, Inkscape, XFig
• Usenet news = Pan
• IRC, IM = irssi, Gaim
• MP3, Ogg Vorbis = xmms

Please note that most of these applications are just as rock-solid as the Linux Kernel, with the possible exception of Mozilla. I can leave dozens of applications opened, lock the screen or use the 'sleep' function of the laptop and -- in a few seconds -- go back to my desktop.

The linux kernel has never crashed on me doing all this. The only time I have to reboot my machine is when I upgrade the kernel itself, which is something done in a matter of a few minutes.

Then again, you don't care about all this, right? You are just here to troll anyway...

Re:Kernel is not the problem

[Anonymous Coward]

Can you copy text by selecting it with the mouse, then dragging it from, let's say, pine to Abiword? Can you debug an C/C++ application properly? (text mode gdb does _not_ do the job for me). Can you create a mail with an attachment by dropping a document on the application's icon? (I can go on you know...)
It's usability, user-friendliness and consistency in the GUI where gnu/linux fails. Yes, it's kernel is rock-solid and never crashes (although I've seen linux boxes completely frozen when running Matlab).
But for it to be the success it is is acclaimed to be, the desktop is the area where it is still lacking with respect to both OSX and XP.

Re:Kernel is not the problem

[tclark]

When I upgrade a kernel I don't want to recompile my Nvidia driver. It should just _work_.

You might want to talk to Nvidia about that. They are able to produce a driver that does this, but they choose not to.

Re:Kernel is not the problem

[romi]

Wrong. The Linux kernel team does *not* maintain the module ABI across kernel versions. Linus has explicitly stated that he is opposed to the constraints that would be imposed if they were to maintain the interface.

Nvidia is as helpless as any other Linux vendor, including my employer, who might want to ship a single binary rather than dealing with trying to distribute compileable source and Makefiles.

Re:Kernel is not the problem

[jacksonj04]

Sorry, meant that Linux as a whole will fall apart. The kernel will still work properly, it's just other bits that may fail.

Apps like IE (OK, not *that* useful but for most people it's great), Windows Picture Viewer etc. are all part of the Kernel. Little things like the 'Common Tasks' in XP. They are nice to use, Linux is lacking unless you install them manually, probably along with a specific library that won't talk to X properly because you've changed the config.

Re:Kernel is not the problem

[tclark]

Helpless my ass. You're right that the kernel team does not maintain a stable ABI, and it has made it very clear why. But Nvidia is welcome to support an open source driver in the main kernel tree. They have chosen not to do so.

Re:Kernel is not the problem

[Anonymous Coward]

Linux Kernel is solid.

No, it's not: http://www.securityfocus.com/bid/11864/.

20-30 bugs per 1000 lines???

[phasm42]

Commercial software typically has 20 to 30 bugs for every 1,000 lines of code, according to Carnegie Mellon University's CyLab Sustainable Computing Consortium.

I'm gonna call bullshit on this figure. This sounds like a number someone pulled out of their ass. A rate of 20-30 bugs per 1000 lines would render most programs unusable.

Re:20-30 bugs per 1000 lines???

[plague3106]

Not necessarly. If the bug only shows up when the code is in state C, and state is a valid but very rare, there's still a bug, but its likely that it wouldn't affect you most of the time.

Re:20-30 bugs per 1000 lines???

[phasm42]

If you're doing this 20-30 times per 1000 lines, it's bound to show up pretty quick. And that's an average -- figuring in highs and lows, maybe it'll hit 100 bugs per 1000 lines every now and then, 1 line out of every 10 is defective. Ridiculous. I understand what you're saying about state C when I made my comment, and I still believe this figure is BS.

Re:20-30 bugs per 1000 lines???

[Bachus9000]

A rate of 20-30 bugs per 1000 lines would render most programs unusable.

Sounds like Windows to me! :-)

It's a joke, laugh. :)

Re:20-30 bugs per 1000 lines???

[Rob Riggs]

I still believe this figure is BS

It's not.

There are bugs that affects applications to a level the user notices, and there are bugs that affect the maintainability of the code, the reusability of the code, and the ease of use of the code. Most bugs are hidden from the user's view.

Does a stack overflow in a piece of code that only occurs when a craftily created exploit is executed constitute a bug? Yes it does -- even when no exploit exists. Under normal operations it does not affect the use of the system -- at least not until an exploit is developed and widely used. The fact that Windows, especially the older versions of the OS, were vulnerable to so many simple exploits illustrates the bugginess of the code. And most of the bugs are not even in close enough to the surface to be so readily exploited.

Does an end user see API bugs? Does anyone outside of Microsoft experience architectural flaws in the Windows OS? No, but that does not mean they do not exist.

What about code that misbehaves when presented with certain data. That may not be a problem for the original application that the code was written for, but any time that code gets reused, the programmer must know about these "hidden features" (read: bugs). Again, the user never sees this sort of bug.

The number they came up with wasn't pulled out their ass. See this article on measuring bugs for a more detailed discussion on the topic.

When reading it, bear in mind that most commercial software is produced for in-house use, receives very little QC, and frequently does not even compile cleanly. It's usuall just "good enough" to get the job done.

Re:20-30 bugs per 1000 lines???

[Iphtashu Fitz]

I'm gonna call bullshit on this figure.

Keep in mind that you need to know the definition of a bug. It's not necessarially what you think it might be, but what the researchers defined. By their definition a condition that could never occur could be considered to be a bug. For example:

int foo ()
{
if (0)
return;

do_something();

return (0);
}

This overly-simple example could be considered to be a bug. If the condition is ever true the function will return an undefined value, but the condition will never be true so you couldn't possibly return an undefined value. It's not at all uncommon to find code with similar logic scattered throughout - improperly defined loops, conditionals, etc. could result in theoretical bugs that no path of execution can actually get to.

Then there are the kinds of bugs that only occur in extremly specific situations. About 13 years ago I had to track down a bug that caused a report package to crash. It took me a while to figure it out but eventually I did. The program would crash only on specific days. It'd only crash on Wednesdays. It'd only crash on certian Wednesdays - Wednesdays in September. Even more specifically, usually only the 3rd or 4th Wednesday in September.

The bug was that whoever wrote the code that printed a header on the reports was extremely anal about memory usage. He calculated exactly how many characters it would take for a buffer to hold the full date. The problem was he miscalculated by 1 character. With "Wednesday" being the longest day spelled out and "September" being the longest month, a 2 digit date (eg. Wednesday September 23) meant that the full date string would overflow the buffer by 1 character. This kind of bug wouldn't show up very often - only a few times a year - but it was a pretty nasty one when it did.

Re:20-30 bugs per 1000 lines???

[Anonymous Coward]

I strongly suspect that this study only covers syntax-type bugs and not style issues like maintainablity or reusability (some older parts of Linux are reportedly very poor in this regard).

It certainly doesn't cover "Linux can't suspend my laptop" type bugs which tend to be the ones that the user notices.

Re:20-30 bugs per 1000 lines???

[Theatetus]

If you're doing this 20-30 times per 1000 lines, it's bound to show up pretty quick.

Well, yes and no. Some vulnerabilities can be found easily by static (and therefore theoretically automatable) code auditing. Some vulnerabilities can be found with difficulty by static code auditing. And some vulnerabilities (here is where Turing bites us) provably cannot be found by any computable process.

For instance, "format" bugs in functions are very easy to find: any time memory that has been touched by the user is processed as a format string, that is a vulnerability. These are easy to check for automatically. There are other times when the allocation and deletion of memory is ultimately determined by user input; this too represents a vulnerability but it is much more difficult to check because it requires instantiating a virtual arena runtime. Finally, there will always be conditions under which the result of any computational process cannot be determined beforehand (or as Rumsfeld would say, the "unknown unkowns"); to find these requires experience and intuition.

It's much more complex than considering the value of every variable you think is in scope. The environment, the OS, and the hardware all can affect a computation in ways that are difficult to predict.

Re:20-30 bugs per 1000 lines???

[phasm42]

Enumerating the various types of bugs does not mean that they are there. Yes there are many types of bugs that can exist in many places, but how many actually exist? How many bugs were missed because they required human intelligence to see, and how many were flagged as bugs because they also required human intelligence to understand that the so-called bug could never happen? Here's an example:
a[b] = 0;
What if b is -1? This bad data could segfault the system. But b can be guaranteed not to be negative through other means other than explicitly checking for it. And I still believe that number was pulled out of their ass -- there was nothing backing it up. Even that article you linked to is just a collection of stories about bugs, nothing concrete relating to how they found "bugs". In-house software is in-house software, not commercial software. If it's commercial software, that implies it's being sold to someone.

Re:20-30 bugs per 1000 lines???

[leblin]

if (0)
return;


This overly-simple example would not even compile. The return value is missing :)

Re:20-30 bugs per 1000 lines???

[plague3106]

I understand your reasoning, but I think its somewhat flawed.

As you stated the 20-30 is only an average, so saying that means that a bug will show up quickly I don't think quite follows.

Since it is an average, 75% of the bugs might only present when the program is in state C, perhaps because state C wasn't well understood by the programmer that coded it, or other's that try to 'fix' issues with it. I don't think the bugs are stattered evenly through the source (if they are, then yes i agree, the bugs should show up quickly)...however its more likely they are concentated in a few (complex) spots, and these spots might be rarely hit.

Re:20-30 bugs per 1000 lines???

[jeremyp]

Bzzzt wrong

jeremyp@dhcp-2-1-56:jeremyp$ cat foo.c
#include <stdio.h>

int main ()
{
if (0)
return ;
printf ("Hello World\n") ;
}
jeremyp@dhcp-2-1-56:jeremyp$ gcc foo.c -o foo
jeremyp@dhcp-2-1-56:jeremyp$ ./foo
Hello World
jeremyp@dhcp-2-1-56:jeremyp$ gcc --version
gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Re:20-30 bugs per 1000 lines???

[Iphtashu Fitz]

This overly-simple example would not even compile. The return value is missing :)

That depends on the compiler you use and how you tell the compiler to handle errors/warnings. gcc compiles this fine without even so much as a warning. Using -Wall with gcc does generate the following warning but it still compiles into an executable that you can run:

foo.c:6: warning: `return' with no value, in function returning non-void

That's precisely why I used this example to demonstrate a bug that's irrelevant. It's technically a bug that a compiler might generate a warning about (but the bug will never be reached) and it does compile successfully.

Only if you compile this with something like "-Wall -Werror" will it treat this as an error and fail to compile.

Re:20-30 bugs per 1000 lines???

[julesh]

Sounds like Windows to me! :-)

It's a joke, laugh. :)

It's a sure sign that the moderators are getting stupid when you have to point out the jokes to them. ;-) <--- NOTE SMILEY. :) :)

Re:20-30 bugs per 1000 lines???

[Waffle Iron]

This overly-simple example would not even compile. The return value is missing :)

You can try it yourself; gcc happily and silently compiles it unless you turn on warnings.

The moral of the story: always turn on all warnings when compiling C code.

Re:20-30 bugs per 1000 lines???

[Dr. Evil]

I was once trying to demonstrate a minimal clump of code to generate a core dump by declaring a pointer, pointing it to some insane value, "0x01" I think, and reading from it.

gcc saw that although I read the value, I never used the variable, so it optimized it out and it ran flawlessly :-)

Now it is a good demonstration of the interesting side effects of compile-time optimization.

Re:20-30 bugs per 1000 lines???

[Trillan]

1 have no problem believing that figure. For every programmer who writes good code there is at least one who scores multiple bugs per line.

Re:20-30 bugs per 1000 lines???

[DunbarTheInept]

False. It's a sign the slashdot population is getting stupid. The reason moderators can't figure out who's kidding is that there is a large enough population of slashdotters now who would say something extremely dumb and actually mean it. Just because it looks entirely silly and nonsensical doesn't mean it's a joke.

Re:20-30 bugs per 1000 lines???

[iabervon]

I'd call that a bug. Either the code is something that can never run, even if someone changes a constant or enables it, in which case it shouldn't be there, or the code is intended to be run in some situation which is presently impossible but would be needed if some other changes were made, in which case it should work correctly.

In fact, the body of an "if (0)" is generally considered reachable, unlike "if (1 > 2)", because people only write the former if they sometimes change the 0. Java, which generally prohibits unreachable code, specifically permits "if (false)" for this reason.

The case where you have to allow this sort of thing is:

int a = 1;
int b;

while (1) {
if (a == 2)
return b;
b = 16;
a = 2;
}

In this case, every line is actually used, but only in safe orders. If there's something more complicated going on in the loop (such as looking for a pair of sequence numbers which don't match the previous set but match each other), this code structure could actually be justified. A good static checker should be able to identify that the only paths that reach the return also set b first.

A good static checker will also catch the bug you found, because it tracks the limits of the possible values of the variables, so having the bug occur rarely doesn't matter. Of course, if the report were to give Thanksgiving instead of Thursday on Thanksgiving, it would then want one byte more memory than is actually needed, because it wouldn't necessarily know that Thanksgiving can never go in the string with the longest month name. Of course, that's probably just as well, because this arrangement isn't going to be immediately obvious to the next programmer, either.

Re:20-30 bugs per 1000 lines???

[Anonymous Coward]

It certainly doesn't cover "Linux can't suspend my laptop" type bugs which tend to be the ones that the user notices.

But technically speaking, that is not a bug, its a lack of a feature/support for that laptop.

Re:20-30 bugs per 1000 lines???

[Macphisto]

jeremyp@dhcp-2-1-56:jeremyp$

Dude, letting dhcpcd set your hostname is extremely lame.

Re:20-30 bugs per 1000 lines???

[mdfst13]

"When reading it, bear in mind that most commercial software is produced for in-house use, receives very little QC, and frequently does not even compile cleanly. It's usuall just "good enough" to get the job done."

However, they are criticizing Microsoft OS software based on that projection. Microsoft OS software (for all its flaws) is for more than in house use, receives extensive (if often insufficient) QC, and probably compiles cleanly (if not, they could always rewrite the compiler).

Yes, I think that Linux has considerably fewer bugs than that shell script I wrote because I was tired of always typing the same set of commands. However, to be honest, I also would expect that Microsoft Windows would have fewer bugs per line than my average shell script. Estimating bugs in an OS based on the bugs in my shell scripts would be silly.

The figure may not be BS in general, but it is certainly BS when applied to Microsoft Windows.

Re:20-30 bugs per 1000 lines???

[Anonymous Coward]

Syntax bugs are picked up by the compiler and we know that both the Linux kernel and Windows compile...

Re:20-30 bugs per 1000 lines???

[veg_all]

Bzzzt. Right.

extremely funny.

Re:20-30 bugs per 1000 lines???

[arth1]

I've seen plenty of examples of "bugs" discovered by wannabe-bugtraq-posters, where there's no bug at all. The typical example is a buffer overflow which can never occur, because the data is controlled internally. In a kernel or other time-sensitive app, it makes sense to not do expensive buffer overflow checks when you control the data completely, and no overflow can occur.

I'd call it a bug to "correct" code like that, as you're adding to the size and runtime of the code without getting anything in return.

Of course, the same code might cause an overflow later on, when another programmer adds to the source, and taints the data, without understanding the bounds. That's not the fault of the original programmer, though.

Regards,
--
*Art

Re:20-30 bugs per 1000 lines???

[jeif1k]

I'm gonna call bullshit on this figure. This sounds like a number someone pulled out of their ass. A rate of 20-30 bugs per 1000 lines would render most programs unusable.

Well, given that the study hasn't been released yet, we don't know what their definition of fact is.

Releasing scientific results as press releases may be questionable, but your response is also not justified.

Wait for the facts.

Re:20-30 bugs per 1000 lines???

[Kehvarl]

You're correct. I vote we begin rectifying this situation immediately. I'll even agree that I should probably be in the first or second group of people to be purged from slashdot memory and possibly hunted down and permanently encouraged to avoid visiting (or atleast posting on) slashdot. Hopefully, this would bring the remaining slashdot population back to something close to what it should be.

Re:20-30 bugs per 1000 lines???

[Hasai]

The ironic thing is, your example contains what I call dead code.

Whenever I come across dead code, I rip it out. The reason is that it eats compilation time, storage space, and RAM, and gives back nothing of value.

Perhaps I'm just being fussy, but I personally call this dead code a BUG in and of itself.

:(

Re:20-30 bugs per 1000 lines???

[Anonymous Coward]

-W -Wall -pedantic -Wbad-function-cast -Wcast-align -Wchar-subscripts -Winline -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings -Wcast-qual

i use that =)

Re:20-30 bugs per 1000 lines???

[Ed Avis]

Really? A lot of C code easily has one bug every fifty lines. For example,

printf("hello world\n");
printf("goodbye\n";

If writing the first string fails, the program doesn't warn about it or abort or do anything; it just carries on and tries to print the next string. This is because the return value of printf() is not being checked. This may or may not be a bug depending on what the program is meant to do.

But IMHO, for most programs, not gracefully handling I/O failures is usually a bug. For example if you run 'my_program >out' and the disk fills up, it's probably a bug for the program to silently throw away output and exit with a code indicating success.

Similarly, do you check every integer operation for overflow? You can easily implement the Unix 'wc' command in C but unless you are careful it will have an overflow bug if you fed it, say, a 3Gbyte file of newline characters. On a 64-bit machine the limit is bigger but in principle the bug is still there.

The kind of bugs I'm mentioning are not ones that matter for many applications. Often it's acceptable to let your program misbehave when the disk fills or malloc() fails, and hope these events don't happen often. For kernel code, though, you need to be more paranoid. Even the most obscure and pedantic bug, such as an integer overflow, could one day become a security hole.

Four Years?

[!the!bad!fish!]

according to a four-year analysis of ...
... the 2.6 Linux production kernel

The 2.6 kernel isn't even a year old yet. How'd they do a 4 year analysis?

No I didn't RTFA.

Oh Gawd please make it stop

[djeddiej]

This Windows survey says Windows is better. This Linux survey says Linux is better. Who knows? Who cares? The only way to do a fair comparison is to have both platforms tested on equal footing, and its never ever going to happen while Windows is a closed system. Just keep coding, folks. How does fodder like this end up on slashdot? It just fuels flamebaiters to post Win Vs Lin vs Commodore Vic 20 OS articles.

Sure, nice analysis, but did they pay???

[bcarl314]

Sure this is nice and show what we already knew, but the burning question is:

Did Stanford pay tthe $699 fee to SCO???

the longer you run a program..

[JCOTTON]

In my IT shop we have code that has been running for up to 30 years. I guess that we have worked out most, if not all, of the "bugs" in these applications.
If Microsoft trys to release new software every 2 to 3 years, then they really have not had time to fully debug. In their race to beat the compitition, they have chosen quantity over quality. So be it. Most of the computer software consuming public have decided that it works "good enough".

Statistics

[amigoro]

• Typical Commercial Software: 20 to 30 bugs for every 1,000 lines of code (Kloc)
• Linux kernel : 0.17 bugs per Kloc
• Windows XP: 40-50 bugs per Kloc Source

Moderate this comment
Negative: Offtopic Flamebait Troll Redundant

Positive:Insightful Interesting Informative Funny

Re:Statistics

[phasm42]

Windows XP: 40-50 bugs per Kloc

I don't see this figure anywhere in the source you linked to.

Apples and oranges...

[SilentChris]

Uh, I'm not sure how this is a correct comparison. Since when is a bug (what they presumably looked at in Linux) a security flaw (what they presumably looked for in Windows, considering they didn't have hands on the code)? According to the article summary, they measured "bugs" in Windows by counting the number of identified security flaws, and compared it to the (estimated) number of lines of code.

I'd assume each flaw in Windows would actually result from multiple bugs (incorrectly defined data structure on this line, misread on this line, etc). This would actually skew the results MORE against Windows.

On the other hands, Windows has a lot more code built-in (for better or for worse) for functionality than the average Linux distro. Were they comparing functionaly the same OSes? They claim they were examining kernels, but does Windows KERNEL have 40 million lines (I always read the entire system did)? There's so many intangibles that the article itself fails to answer. All it does is stir up flames.

with 40 million lines oif code

[JaJ_D]

"[Windows xp has]40 million lines of code..." and if 5.7 million lines of code should have "114,000 to 171,000 bugs" that should be that windows has 800k - 1.2 million bugs!!!!

Wow, from the standard of their bugs thre's got to be some _really_ good ones in the source somewhere:-]

And what about the other open-source rivals?

[systems]

Does linux have fewer bugs than the freebsd, netbsd, openbsd kernels, the hurd and more?

That would also be interesting.

I expect the openbsd kernel to win!
But I'd still choose GNU/Debian for many other different reasons

Re:And what about the other open-source rivals?

[quamaretto]

Does linux have fewer bugs than the freebsd, netbsd, openbsd kernels, the hurd and more?

Hurd? I freaking tried to install Hurd once, for a few weeks straight. "Bug" is the word I would use loosely for the whole installation process. But that's not the kernel, I suppose... Does only supporting 2 GB partitions count as a 'bug'? Oh wait, they fixed that one. :)

Well, the BSD's aren't GPL, and RMS would probably claim that's a bug...

And while not in the kernel, they all run X... Wait, I like X. Nevermind.

Oh, and you left out Darwin. And Plan 9, but you could argue that it isn't quite in the same category :)

How do they find bugs?

[lunar_legacy]

What is the basis of these kinds of studies? Is it based on known bugs and submited patches of Linux Kernel? Or they've found new previously unknown bugs?

windows bugs?

[Major_Small]

it would be interesting to know how many bugs there are in windows XP code...

I find those numbers a little hard to believe.

LOC != codetype

[thrill12]

We're talking about # bugs per # lines of code - it doesn't matter what the code does - it matters that the # bugs per LOC are relatively low.

Re:LOC != codetype

[Anonymous Coward]

#include

main()
{
printf ("Hello World!\n");
return 0;
}

// This code has fewer bugs per line of code than the Linux Kernel!

Re:LOC != codetype

[Paladine97]

it doesn't matter what the code does

It actually does. Would you not agree that a kernel needs to be more stable than userland applications? If a kernel had the same amount of bugs as a typical userland application, I highly doubt anybody would be using that kernel. It may be OK for Winword to crash on occasion but if Windows or Linux goes down and takes my entire system with it, I would not be a happy customer.

Clearly both the XP and Linux kernel will have lower bug counts than all the userland apps that go on top of it. After years of laughter, MS has a really solid kernel these days.

Re:LOC != codetype

[Anonymous Coward]

Well, given there are nine lines of code and one of them (#include) has an obvious bug, I think it's safe to say that the code has more bugs per line than the Linux kernel. And that's ignoring the fact that you've used a C++ comment on what's presumably a C program (otherwise you'd have used cout << "Hello World\n"; rather than the printf. And why use printf anyway? It'd have been infinitely more efficient to use puts. Dude, your code sucks.)

Re:LOC != codetype

[Anonymous Coward]

Ha ha it won't compile though.

Re:LOC != codetype

[T-Ranger]

Indeed.. Id say, except for drivers, that the average call rate (?) of kernel functions is significantly higher then those of apps. If you have the ReiserFS module loaded, you have a reason, and you're calling it all day long. How often is some obscure function in Word called? The most obscure function of the Linux (or XP) kernel is called more often then the most obscure function of, say, Word.

Re:LOC != codetype

[GoofyBoy]

The complexity of the code is the major point.

I could create a million line "Hello world" program and could have less "bugs/lines", but does it really mean anything?

Also, the severity of the bugs would also have to be taken into consideration.

Re:LOC != codetype

[Anonymous Coward]

ignoring the fact that you've used a C++ comment on what's presumably a C program

//Comments of this kind are allowed under C99

Next up on "Things That Every /.er Knew Anyway..."

[TooMuchEspressoGuy]

...a new study confirming that patents do indeed stifle creativity in the software market; an analyst explaining that Microsoft is actually a monopoly; and how the DMCA can be abused to take away fair use rights.

Keeping Things In Perspective

[MankyD]

Just to be sure, doesn't windows include a GUI and Web browser in their kernel/OS - addning several thousand lines of code to the count? (Also great places to find bugs.)

Less Features?

[Apreche]

While I think it is plainly obvious that in terms of stability, performance and security that Linux systems are superior to windows systems I don't think that bugs per line of code is a very good measurement. The designs of the two operating systems are so far off from each other its really not a fair comparison.

A bettery way would be a component by component comparison. For example: look at the memory management code in Linux then in Windows. Compare the code for features as well as bugs. Do this for every component. Then you will get a fair comparison.

Of course, I'm almost sure that the result will be that the components of linux are smaller, less buggy, and more "computer science correct" than the windows counterparts. But I'm also sure you will find the windows code to have more features. Meaning the ability to do so many backwards compatible things that nobody understands. So the features don't necessarily mean beneficial abilities for the end user, but they mean ways in which the code allows for so many possibilities.

Interesting, but the comparisons are flawed..

[pcardno]

Sounds like it was a pretty dull thing to do, but reasonably interesting results. I would question though that the "bugs" they found would seem to be pure programming bugs, since they just analysed the source code. The majority of bugs found in systems are usually found by actually using the software and often come about as a result of either unexpected circumstances, unexpected input or compatability issues. Merely reporting the straight programming errors really isn't the same thing.

Also "Windows XP, by comparison, contains about 40 million lines of code, with new bugs found on a frequent basis" isn't exactly very scientific either. How frequent? How severe? XP has been released for roughly 3 years. According to the poster, it's roughly 8 times the size of the code these guys analysed, in which they found 985 errors. So to be at the same level, that would allow for around 7880 bugs, or about 8-10 bugs being found per day since its release. Is that the frequency that's implied here?

It sounds like a good bit of initial research, but probably only just to Bachelors degree level. They need to apply this research correctly in fair comparisons to other operating systems before the results they came up with are meaningful.

Re:Interesting, but the comparisons are flawed..

[akc]

It looks to me like the actually carefully analysed the code and came up with the 985 errors. What about the ones they missed?

It seems they decided on the Windows XP as the worse end of a generic commercial range.

The only way I know of getting a good handle on how many bugs exist in a body of code is to plot the occurrence of bugs during development and into production against time.

You also plot the fix progress, and try and find out how fixing bugs generates new ones (because you see an increase in new bugs after a release that fixed old ones).

You can then assume that where the number of bugs that exist in code is headed is to a point where statistically fixing one bug creates one.

So I agree this is a flawed comparison.

Not serious?

[Kjella]

Crap code can be made to pass some poor unit tests (it works, as long as the input is exactly what you expect it to be), and slide through poor Q&A (we tested the data the way we expect them to be, and the pieces work together).

It can still make for a helluva mess if there is unexpected data (past a certain range, called by a different function with a wider range, while in a wrong state etc.) Perhaps it'll bring the program down in flames out on the users machine, but tracking it down might be hell. So no, the company couldn't cover it up, but the *programmer* covered it up.

Bugs in crap code tend to also be crappy documented, and near impossible to understand so you can fix it. The result is a bunch of patches and workarounds until you really got no idea what you're doing.

Kjella

Just the kernel

[gilesjuk]

It's good to see that the Linux kernel is well designed and coded.

What really matters is what you run on the thing, many security issues occur outside of the kernel.

985 bugs makes jack a dull boy...

[slungsolow]

985 bugs is enough to give you a new bug every day for the next 3 years. How does that make it better than microsoft? How does that make this article seem any less biased towards linux? Seriously?

Kill my karma all you want, but the jab at windows ruins any objectivity in the article. Its obvious that they didn't research the actual number of bugs in microsofts product, so really this is just a marketing pitch for open source instead of an actual reason to embrace it.

Re:985 bugs makes jack a dull boy...

[4nd3r5]

in defense of XP.

xp has 40 mil lines of code, that would give around 7000 bugs with the same bug frequence as linux. That is 1 bug every hour for a year.

I admit its not perfect but its not that bad..

btw. how arrogant are they.. thet claim to have found EVERY error in the 5.7 mil lines of code.. thats just plain bizare..

and .. IDNRTFA .. im busy...

Re:985 bugs makes jack a dull boy...

[Vo0k]

985 bugs is enough to give you a new bug every day for the next 3 years.

If you looked through the code, what you actually use is maybe 10% of it. The rest is architecture-specific code for other platforms, drivers for devices you don't have, features you never intend to use (WAN router anyone? Gigabit ethernet? >16GB RAM?), drivers for long obsolete ancient devices, filesystems for exotic operating systems, obscure network protocols...
and the bugs appear mostly in that hardly used code - few people are interested in it, few people maintain it, few people find bugs. There's probably 10 times less bugs in malloc.c or kernel.c than in, say, framebuffer_amiga.c.
So come, get 10 bugs that will happen in 3 years. 4 of them will get handled by the system not decreasing the functionality in any way. 3 will happen at a far abstraction layer you won't ever notice and i.e. will decrease random number generator entropy by 1% or cause extra 0.1% packet loss. 2 of them will affect negligible features, say, extra power saving scheduler or PC Speaker driver. And one will affect you directly and noticably, you will report it to LKML and Linus will send you a hotfix ready overnight, and be very grateful that you found that bug.

Re:985 bugs makes jack a dull boy...

[slungsolow]

RTFA:

Of the 985 bugs identified, 627 were in critical parts of the kernel. Another 569 could cause a system crash, 100 were security holes, and 33 of the bugs could result in less-than-optimal system performance.

So I guess that means that your theory about the bugs all being in "hardly used code" doesn't hold.

Re:985 bugs makes jack a dull boy...

[be-fan]

I'm guessing you're not a programmer... As for the "jab" at Microsoft --- I'm not going to defend their methods, but I hope you understand that it's impossible to do a comparative study of bug counts in Linux without comparing it to Microsoft.

Re:985 bugs makes jack a dull boy...

[slungsolow]

No, I am not a programmer. I am not saying that their comparison to MS was wrong. I am saying that they didn't do a full investigation. They just make a blanket statement of microsoft having a new bug every day, and I in turn said that with 985 bugs it gives linux a new bug everyday for 3 years. That is pure logic.

On top of that, I know that no program is error free. I know that no matter how many peer/code reviews you do, you will always find a flaw. The fact that this code review was done by humans shows that it is fallible, just like everything that is man made (including windows!).

Re:985 bugs makes jack a dull boy...

[be-fan]

My point was that if you were a programmer, you'd understand that tools that use automatic source analysis count things as bugs that are bugs from a programmer's standpoint (ie: they'll barf if you reuse the code in a different context, or if the code around it changes), but aren't necessarily things the user will see as a bug. Therefore, the "one bug everyday for 3 years" metric is highly misleading. Take something like using memory after it's freed. In a given release of the software, the user might never hit the bug, because the memory manager hasn't recycled that memory yet. So that's not a user-visible bug. Yet, when the memory manager is changed, the system breaks. Thus, it's a code bug.

Re:985 bugs makes jack a dull boy...

[slungsolow]

I know that their won't literally be a bug everyday for three years. I was just comparing it to the statement that they made about microsoft having a bug every day. Completely innocent.

Faith based kernel programming

[GillBates0]

985 bugs in 5.7 million lines of code, well below the industry average for commercial enterprise software.

It is clear that each line of Linux kernel code has 0.0001728th part of a bug. Obviously, Linux programers are evil...they cruelly chop up bugs (and would think nothing of doing the same to cute little puppies) into little, almost unrecognizable chunks and put them in each line of code.

Microsoft is clearly much more compassionate and Pro-Life (TM)...they're willing to forego a little software quality if it means saving a A Bug's Life (TM).

Re:Faith based kernel programming

[phasm42]

Flamebait? Come on now, the parent was was clearly joking.

That's not just funny - it's TRUE!

[Anonymous Coward]

Why do you think code inspections work so well?

Yes, the extra eyes looking at your code helps. But so does the fact that you know that there will be extra eyes looking at your code.

So you do a better job.

And the correllary is therefore that one of the big reasons some programmers don't like code inspections is that they don't want others to see their code.

Gee, if you worked for me and didn't want others to see your code I'd wonder why.

985 bugs ey?

[odyrithm]

So if they submit the patches would this make Linux perfect?

Wrong: Apple == Orange

[chroot_james]

From the post itself: The report, set to be released on Tuesday, states that the 2.6 Linux production kernel, shipped with software from Red Hat, Novell and other major Linux software vendors, contains 985 bugs in 5.7 million lines of code, well below the industry average for commercial enterprise software See where it says: "shipped with software from Red Hat, Novell and other major Linux software vendors"

Re:Wrong: Apple == Orange

[_|()|\|]

"shipped with software ..." is a parenthetical. 5.7 million lines is the right order of magnitude for the kernel. A useful Linux distribution would be closer to the 40 million lines estimated for Windows.

Comparing an OS to a Kernel?

[EightBits]

That's all nice and dandy, but maybe we should be comparing an entire Linux-based OS to Windows XP. Remember that Windows XP comes with a media player, wordpad, notepad, and many many other tools. So let's take the full Redhat Enterprise WS distro (since it's a pretty popular commercial distro) and track down all it's bugs and see if that average doesn't change. I don't think we should be comparing OS vs Kernel. It takes a lot more than a kernel to make my Linux machine go. Having said that, I would be very interested in a comparison of the Windows XP kernel to the Linux kernel.

Linux features.

[Anonymous Coward]

So, this is another area where Linux is severely lacking.

I have decided to donate some of my code to bring Linux up to the standards set by commercial operating systems with regard to unexpected extra features. I have a great track record with this, and I'm sure that if my memory allocation subroutines are incorporated into the kernel, Linux will no longer languish at the bottom of the list of semi intentional value added programming decisions per thousand lines of code.

Fewer lines of code, fewer bugs AND FEWER FEATURES

[Cycline3]

Fewer lines of code, fewer bugs AND FEWER FEATURES. What does it matter if it's better written software, if it's not easy to use or won't do what you want it to do?

People can argue all they want - but Linux vs. OS X or Win XP for the average joe on the desktop just is NOT a reality yet. Not even close.

Who cares, it's failures that count.

[gelfling]

Counting an unknowable number of bugs in code is meaningless compared to what is exploited, in the case of security, or just plain breaks alot in the case of applications.

I suspect this metric does not take into consideration the fact that most business apps run fairly well on Windows whatever the relative number of bugs otherwise. So given that, you may have fewer bugs and less ultity in the Linux world.

On the other hand bugs are only useful as the ease of exploitation whatever the number of occurences you see. It really doesn't matter that Windows has lots of bugs, what's important is that a relatively small number of them are easy to exploit in disasterous ways. By comparison Linux and company have relatively fewer bugs, it's possible, but what's important is that they are comparatively more complex to exploit and generally wreak less havoc if they are exploited.

Some bugs aren't fixed for a good reason

[gilesjuk]

An API call that is partly broken is often not fixed for a few reasons: kludges and workarounds. A broken call might work in conjunction with some other functions or it might behave differently to how it is documented (it might return TRUE not FALSE as expected.

So if a programmer has foolishly used these calls or had no choice, their code will fail if the call is fixed. Therefore the solution in this instance is to create another function and deprecate the old one at some stage.

Re:Some bugs aren't fixed for a good reason

[Anonymous Coward]

If the API behavior is documented, then it becomes a Feature, not a Bug.

The gray area is when Windows detects you're running program X version Y and behaves differently to keep the program working. Apparently this happens quite a bit.

Hey, IE is part of the operating system

[Anonymous Coward]

Microsoft has made that claim many times, including under oath.

They want to make that claim, they can live with all the results.

slightly OT, but...

[djeddiej]

Slightly OT, just wondering as you are reading this article and its responses, what OS are you using to read it? What apps are running in the background? This helps to add what considers to be a "typical" session that could be used to effectively evaluate the OS's in the future. For example I am (because it is there) running Win XP SP2 and surfing with Mozilla 1.7.x. Outlook running in the BG, with stuff like Google Desktop, gmail notifier, MSN Messenger, etc. running. What would be the equivalent running on *Nix? Mozilla, Thunderbird, GAIM etc.?

Re:Fewer lines of code, fewer bugs AND FEWER FEATU

[BenjyD]

Linux on the desktop would be very dull. Without any userspace, you couldn't do much.

Or are you talking about the operating systems which use Linux as a kernel? In which case, you're offtopic.

next recommandation in commercial programming

[dario_moreno]

that's why it is recommended to put only one instruction per line and a lot of comments ! The number of bugs per line of code tends to go down !

The real question...

[fizban]

Did they file bug reports on those 985 items?

Re:The real question...

[Sits]

I was going to give you a link to where the bug database was but it seems to have turned into a promotional page - Coverity Linux "bug database" page. Normally that link goes to a bugzilla like database showing you a list of bugs, what type of error was found and a highlighted code snippet. All very nifty.

Here's kernel hacker davej talking about coverity bugs. So they do let the kernel folks know about the bugs they have found.

However this hits upon something I don't like about this press release. I wonder whether the headline should be "Tool finds less bugs in Linux than rival OSes when previous bugs found by the tool are fixed in Linux". Assuming fixes for all problems that means only new and changed code gives a chance for these errors to occur (which is a subset of the entire code).

Were all codebases that were compared given coverity bug databases and a chance to fix the reported bugs too and over what time scale? If the Linux kernel code gets 6 monthly reports and say OpenBSD kernel only gets reports one every two years and you test towards the end of those two years is that fair test? What does it say other than our tool finds less bugs in code that is regularly checked by previous versions of our tool? Is that in itself a good justification?

partisan hackery

[jonastullus]

i call bullsh*t to all these partisan studies! "windows better", "linux better", ... why won't this stop at least from the "good guys" and let's all have some objective analysis of the REAL cost/benefit situation instead of each side stubbornly stating how superior and infallible they are!

linux has a severe lack of a stringent development process, does little coordinated code reviews and is a big lump of monolithic code!
yet, the discovery-bugfix time is quite acceptable and with enough background knowledge the stability and performance is quite good. but why trash (implicitely) the quality of the alternatives? *BSD and solaris for example are definitely superior to GNU/linux in some areas and have an excellent track record at security, stability. why do we have to worship linux as the non-plus-ultra when in fact it simply is a respectable alternative to windows on the server?

oh, sure, windows has its problems, but at its core the once-microkernel approach is not all that bad and bad drivers will crash linux just as well as windows!
but apart from shady business practices and horrible reaction times to exploitable holes (patch day, anyone?) microsoft is actually making an effort and has some development practices in place that wouldn't be such a bad idea for the open-source community to adopt like nightly regression tests and driver certification.
i am far from saying how wonderful microsoft is as a software producer, but simply bashing them all the time (even if in self defense) won't make the open-source movement look any better!

come on! give a little respect to the *BSD guys who are actually making an effort of code reviews and an emphasis on security! and even give some credit to microsofts (recent) efforts to work towards security (even if in vain when faced with the horrid IE code base)...
open source has HUGE issues with code quality and developer trust, so we shouldn't mouth off about our superiority until we can make sure that total chaos won't break out with the next kernel release!

doing your cutting-edge development in the current "stable" kernel is just as bad as many things microsoft is doing!

jethr0

Re:partisan hackery

[pjrc]

Vaporware marketing strikes again.

Believe it or not, we're supposed to give Microsoft some credit for their recent good efforts. We're supposed to accept that someday in the future, they will ship secure, high quality software.

That may yet happen, and indeed XP SP2 was a good step, but a soild Microsoft system is still vapor.

Faced with superior products already existing on the market, Microsoft has consistently promised and promised and promised vapor... in the hopes of persuading everyone to keep on using their shoddy wares in hope that they'll someday, at an unknown time in the future, provide improvements. After all, they're "serious" and making a good effort.

We're also supposed to believe that Microsoft's process is somehow superious, despite flawed results, because of a 3 year roadmap. It's all part of the vaporware marketing tactic... don't buy something better NOW, instead wait for us. Never mind their poor track record of slipping their own dates and dropping those ambitious planned features.

Re:partisan hackery

[Anonymous Coward]

"soild Microsoft system is still vapor"

What nonsense. I've been running Windows 2003 Server as a workstation for several months (a few tweaks and it's an ideal desktop), with no crashes, no glitches, no viruses, no slowdowns etc. It's astoundingly reliable.

Meanwhile, every Linux distro I try just takes much longer to boot, is heavier and slower, and full of not-all-that-finished apps.

Go and download Win2k3 (free 6 month evaluation from Microsoft) and learn about about Windows here in 2004, instead of blathering on.

Re:partisan hackery

[Creepy Crawler]

Exactly.. If you use WHQL based certified drivers, you wont have many (or any) problems associated with 'Winderz crashin'.

I had severe problems with Win3.1, win95, winNT4, Win98 because there was either lack of driver support or the driver was soo shoddy, i'd be surprised the cpu didnt immediately barf.

When's the last time the Windows subsystem go down (and I dont mean the GUI component, X goes down just as frequently). I've only seen the network system go down once, and that was due to a trojan adware installing a new network stack.

If you keep your system clean with anti-virus, antispyware, and firewall it with an external device, the Windows box will be safe. Anyone who says different has never had a Linux box rooted and then remotely told to DDoS another network (playing with Linux at school and installed a bad ftpserver.. yep, my fault).

Re:partisan hackery

[Cyno]

Why Linux?

Cuz they haven't been convicted of being a monopoly yet.

Cuz its free.

Cuz its FREE.

And cuz, unlike *BSD, monopolies can't embrace and extend it.

We're all like, "But can't we all just get along? This code is good too. Its free and open source and production quality. Why don't you want to use it?" But in the real world I've learned that some things are more important than money or economic value or even access to source code. Take freedom, for example, how much would you sells yours for?

Mistaking symptoms for bugs

[MoebiusStreet]

In proprietary closed code, it's impossible for an outside party to determine the number of bugs.

The best you can hope to do is to count the number of *symptoms*, but that's not the same thing as bugs. It's possible, even likely, that a single bug in the code manifests itself as 100 apparently different external symptoms.

So this comparison is apples to oranges and completely meaningless.

So in all this code auditing...

[eno2001]

...have they found any SCO bugs? ;P I kid, I kid! Because I love!

new vulnerabilities + exploits

[NoSuchGuy]

Here are some new vulnerabilities:

Linux kernel IGMP vulnerabilities von Paul Starzetz

Linux kernel scm_send local DoS von Paul Starzetz

Must compare like with like...

[AccUser]

Regardless of what I feel about Linux and Microsoft, this comparison is between the code base of Linux 2.6 kernel and Windows XP.

If you were to compare the code base of a complete GNU/Linux distribution with that of Windows XP, what would be the outcome then?

However, the benefits of the open source software development model are proved by the facts pertaining to the number of bugs in the Linux 2.6 kernel - 985 in 5.7 million is still well below industry average.

Re:Must compare like with like...

[Stumbles]

My take is this comparison is at the "OS" level. Since Microsoft insists on integrating everything including the kitchen sink where as Linux does not. IMO it is a far comparison.

Of course the outcome would be different if a complete distro of Linux was compared to XP. Probably (just a guess) to the negative for Linux.

However as I stated this seems to be a comparison of OSes only. It is not Linuxes fault they follow a more sane methodology in operating system design.

Re:Must compare like with like...

[AccUser]

But what is the OS? Back in the day the OS was a simple hardware abstraction level with some I/O and process control. These days it is much, much more.

Surely the OS is that software which enables you to operate the computer with an acceptable level of functionality. Given that, does the Linux kernel cut it?

GNU/Linux is an operating system, and includes far more than just the kernel. It includes glibc and all the other essential libraries for user space, a shell, command line utilities for interacting with the kernel, amongst other things. Try using Linux without the GNU bit, and you will be disappointed.

I agree that there is a lot of chuff bundled with XP that is not part of the OS, and also with RedHat Linux, SuSE Linux, etc.

If you really are going to be pedantic, compare the Linux with the core Windows kernel.

Re:Must compare like with like...

[Stumbles]

I think that was the gist with the study to look at the operating system itself. Since there are a number of things "integrated" into XP that are not normally an "OS", those items have to be included such as IE. Again that is not the fault of linux.

In my mind it is a fair study (so far as it goes). When Microsoft decides to heed the advice they were given years ago not to take the path they have, then perhaps another study would have a different out come.

No it doesn't

[Noksagt]

// This code has fewer bugs per line of code than the Linux Kernel!

#include expects "FILENAME" or . In this case, perhaps stdio.h. Which means you have a very high bugs/LoC rate.

Re:No it doesn't

[jellomizer]

I saw that to but he forgot to use the < for the < symbol and the > for the > symbol thus making slash code erase part of his include statement. His code was right but his html programming for code had a bug in it.

Re:No it doesn't

[maxwell demon]

Since you cannot see what he had between the < and > you don't know if his code had a bug there.

So, if the kernel contains 985 bugs...

[RealBothersome]

>> Linux software vendors, contains 985 bugs in 5.7 million lines of code, well below the industry average for commercial enterprise software. Will they be sending in the bug reports so that it may get fixed? And how do they know they are bugs? Maybe some of those were meant be as such and not a bug at all.

Re:Fewer lines of code, fewer bugs AND FEWER FEATU

[space_jake]

I totally agree. When there are 1,200 media players each of which uses the OS in a slightly different way the fact that the OS is being used so many different sheds more light on bugs. Next to no one uses Linux of course not as many bugs are found. But when some random baby-boomer plugs in their digital camera and wants it to go go go, Linux would have the same problem if it had the user base.

Update

[Tom]

Update: 18 hours after posting the study, the Linux kernel team had eliminated all the bugs documented in the study, forcing the researchers to correct the bug count down to 0 per 10,000 lines.

Re:Update

[Anonymous Coward]

Update: 18 hours after posting the study, the Windows kernel team had found another 47 million bugs, forcing the researchers to correct the bug count up to 10,001 per 10,000 lines.

This just in:

[Anonymous Coward]

After sumitting appropriate patches, the total number of bugs in the 2.6 kernel has now gone down to 0, as per the official four-year count.

Re:This just in:

[Anonymous Coward]

(massive sigh of relief from all the linux zealots)

This doesn't prove shit

[Anonymous Coward]

Come on folks, this article says absolutely nothing about competitors. they didn't also investigate windows code. someone just used estimates based on averages.

3 + X = Y

obviously x and y are only 1 and 4 respectively. yeah.

Where do they get these numbers???

[gUmbi]

Commercial software typically has 20 to 30 bugs for every 1,000 lines of code, according to Carnegie Mellon University's CyLab Sustainable Computing Consortium

I'm going to call bullshit on this. Maybe this number is based on some rule that every variable must be asserted, everything exception checked, etc. (even if these conditions rarely or never happen).

If they're counting bugs like I count bugs - i.e., in a normal operating environment the software loses data, produces incorrect results or limits operability then there is no way that a commericially viable product can have this number of bugs.

Re:Where do they get these numbers???

[p3d0]

I think they must be counting compile-time errors.

Re:Where do they get these numbers???

[Anonymous Coward]

> If they're counting bugs like I count bugs - i.e., in a normal
> operating environment the software loses data, produce
> incorrect results or limits operability then there is no way that
> a commericially viable product can have this number of bugs

Google IEFBR14, a program sold by IBM that had more bugs than instructions :-)

I have also heard that the core of some IBM OS (MVS? VM?) has had more bugs fixed than it has instructions.

Now there are 0 bugs?

[jasoncc]

So, I guess the next release of the kernel will contain zero bugs? If these guys found all 985 of them, then they should all get fixed. Tell me they filled out bug reports!

82, 82, 82

[imploded_monkey]

Charlie: 82 what? Raymond: Bugs in the Linux kernel. Charlie: There's a lot more than 82 bugs, Ray. Raymond: 985 total. Oh wait. I forgot, they didn't have rain man count the bugs. They had 5 grad students running some lame source code analysis software. It's definitely 985 bugs then...definitely...

smells like BS

[OldAndSlow]

This post pisses me off:

How do you analyze 5.7 million lines of code except to run it through a static analyzer? Static analyzers can't detect most errors, which tend to be data dependent. So a company selling an uberlint donates their tool, 5 academics run it and write a paper. *Blech*

Commercial software typically has 20 to 30 bugs for every 1,000 lines of code Bull. Software with 20-30 errors per KSLOC doesn't work. (I know, I just spent a year trying to save a project that had 10 errors per KSLOC. Even at that defect density (found and fixed) it was undeliverable. Notice that the link in TFA doesn't take you to anything that supports this assertion, just to the organization's home page. I could't find anything to support these numbers.

Weasely non-comparisons: 2.6 Linux production kernel, ... contains 985 bugs in 5.7 million lines of code as opposed to Windows XP, by comparison, contains about 40 million lines of code, with new bugs found on a frequent basis.What, bug in Linux are found on an infrequent basis?

This is all hot air.

Re:smells like BS

[DoktorTomoe]

Well, of course it is BS, and we all know it. But managers may not, and they do not care as long as they have some numbers they can point at (think of the 260 something patent violations of linux.)

So, the next time we want to point out that linux is more stable than WinXP (which we know is true), we can point to these (bogus) numbers to make our point. May be evil, but it will help.

Re:smells like BS

[BenjyD]

I thought that as well. A thousand lines of code is about enough for a small module performing one task. They're saying that *production* code (pulling an example from my work) to implement a "Save As" dialog is going to have 20-30 'defects'?
Either their definition of defect is strange, or they're making numbers up.

Re:smells like BS

[TrancePhreak]

Linux is no more stable than Windows XP. Just live with it. As long as you don't run junk code (many OSS products for Windows sadly), your system doesn't go down with Windows XP. The same cannot be said if you run Linux on weird hardware that Windows XP would run fine on. That being said, there are some things you can do to Windows that would not take down a Linux based machine, but it's still easy to take down X and that's annoying enough.

Re:smells like BS

[be-fan]

As someone who runs several WinXP machines at home, I can definitely tell you it's more stable. One of my XP machines decides to boot up to a "no system disk found" error once every four or five boots. Reboot it, and it's fine. The damn thing hard-locks at least half the time when it's going to sleep, and will randomly crash for no good reason.

XP *can* be stable. If have to be careful about what software you install, install virus protection, install a third-party firewall, install spyware blocking tools, keep up with Windows Update --- basically, you have to babysit the damn thing. At least Win2K could take a bit of abuse and still be stable. Linux can be abused pretty heavily and still be stable.

Re:smells like BS

[Anonymous Coward]

Definately hot air, I have written programs with 1000 lines of code that definately did not have 20-30 bugs. That should be all fixed before the product reaches production, during what most people call "testing". For such a small program (1000 lines) it's hard to believe that programmers would statistically release the software with that many bugs.

Re:smells like BS

[Anonymous Coward]

I know, I just spent a year trying to save a project that had 10 errors per KSLOC. Even at that defect density (found and fixed) it was undeliverable.

Just because you can't do it, doesn't mean others couldn't. There's bugs and there's bugs. Some bugs are about "usability is bad, colour should be yellow". This is clearly non-critical but a still a bug. But a bug like "crash when I press z and ctrl" is clearly critical, however it's still a bug.

Windows XP source code is closed, probably their bug metrics as well. Not all bugs are public. How do you compare that, then.

Re:smells like BS

[Anonymous Coward]

Yes Linux is more stable.

It's not that easy to take down X. Of course you can write shit all over as root, but that's damn stupid. As regular user using regular programs it's quite solid. More so than any XP crap ever even will be.

If you've seen the w2k source code.. my God what crap it is. I doubt XP is any better inside.

Re:smells like BS

[kingj02]

The same cannot be said if you run Linux on weird hardware that Windows XP would run fine on.

That's because the company that made the weird hardware also wrote a driver for Windows, otherwise Windows doesn't know what it is. They did not write a driver for Linux, otherwise it would run just fine.

Re:smells like BS

[autechre]

I'm no fan of Microsoft (everything at home is currently Debian), but that sounds like hardware problems to me. Have you tried something like Knoppix on the same system?

And yes, "durable" is not a word that I would generally ascribe to Microsoft operating systems, and I agree that XP (even when disabling as much as possible) isn't as stable as 2k.

Re:smells like BS

[chgros]

How do you analyze 5.7 million lines of code except to run it through a static analyzer? Static analyzers can't detect most errors, which tend to be data dependent. So a company selling an uberlint donates their tool, 5 academics run it and write a paper. *Blech*
Actually they created the tool, and then a company.
But I agree that "Linux has 900 bugs" is VERY misleading, what it shoud say is "Coverity's tool found 900 bugs", which is completely different. But you should know not to trust Wired (or worse, /.'s summaries of Wired articles)

Re:smells like BS

[Blakey Rat]

Uh, your computer has hardware problems. When Windows encounters unstable hardware, it'll stop using that hardware. (Meaning, if your video card overheats and begins acting erratic, the image on screen might freeze... Windows is still running, but it's no longer using your unstable video card and it may look as if the computer is hard-locked.)

But if you're getting BIOS errors (like "no system disk found"... and BTW what the heck makes you think that's Windows' fault? Windows hadn't even booted before it came up), and you're getting hard-locks, then you have hardware problems on that computer.

The reason most Linux users have a better experience than most Windows users is not because the Linux kernel is more inherantly stable, it's because they build their own computers using high quality hardware they picked out themselves. In general, Windows users are using $300 Tiny Computers using a motherboard from China and insufficient cooling... of course their computer is going to be less stable.

Re:smells like BS

[iabervon]

Actually, 5 academics wrote an uberlint, tested it on the kernel (because the kernel has a lot of code and active developers who can tell them if it's generating false positives), reported a lot of real bugs, and are doing a startup with the tool. The tool is a static analyzer that makes pessimal assumptions about the data, so it finds the data-dependant bugs, plus theoretical "bugs" which are fine, but only for non-trivial reasons. For some of these cases, the reasons it works were added to the tool; for others, the code was made more explicit (because someone might change the code such that the reason doesn't work any more).

The bugs they found were entirely the sort of thing that simple static checkers don't find, and normal input doesn't trigger. It wouldn't be too surprising to have a lot of these in a project that basically worked. (I bet the GNU utilities have more than 30/KSLOC, given how easy they are to crash with weird input)

Re:smells like BS

[yarbo]

How did you verify? Many bugs are hard to notice by the creator. You wrote the program with your intended usage patterns in mind.

Then again, going by my personal experience, my programs don't have an even distribution of bugs. If your program was pretty trivial, it would have less bugs.

I wrote a Bomberman clone with a team for one of my classes, and it felt like most of our bugs were in the same part of the networking code.
Right now, I can only think of one known bug out of 4500 lines (also in the network part of the code) but that doesn't mean that if 100 new people try to play the game that they won't find 90-135 bugs.

Re:smells like BS

[kyliaar]

I completely agree and this holes in the statement in the post are immediately obvious to anyone with any sort of critical thinking ability, IMHO.

(That last line should silence the trolls.)

Re:smells like BS

[TrancePhreak]

As an abuser of Linux I would say that is not the case. Incorrect settings often lead to system failure. This is quite easy to do, expecially with older distros as the settings are not always clear.

They counted bugs per lines of code

[Anonymous Coward]

They didn't simply count the number of bugs, but the relationship between lines of code and bugs.

Also, I don't run X, KDE, Gnome, whatever on a server, that you can't use Windows without a gui (they even install a browser and a media player on a server) sure isn't Linux fault.
So perhaps a comparison between the linux kernel + apache and Windows server with this nice media player and browser would be relevant.

Re:They counted bugs per lines of code

[KarmaMB84]

They could compare it with the Xbox version of Win2k :)

OK

[hackstraw]

Linux software ... contains 985 bugs in 5.7 million lines of code

I hope they submitted a patch :)

Re:Fewer lines of code, fewer bugs AND FEWER FEATU

[mgrennan]

NO - Not fewer Features - Less trainning. I use Linux as my Desktop and I have for years. I am a Unix admin. and a Linux Desktop makes me MUCH more productive. I use Open Office and Crossover Office for Lotus Notes as a way to interface with my co-workers. This is not Linux Desktops falt. If the company would standardize on other product the few places where there are problems would go away. And the company would not having problems with viruses and malware.

the Linux kernel has fewer bugs than

[Anonymous Coward]

its rivals' Linux kernels.

Yeah, those reported Microsoft bugs also include..

[AzrealAO]

things like typo's in dialog text, or typos in the help. Simple typos are still listed as Defects by Microsoft, and make up a fairly large portion of the 'bugs' in Windows XP.

How many bugs does this analysis have?

[wlodekf]

So now we know how many bugs does Linux kernel have.
Let's remove them and we will have the first ever
system of that size without bugs.
Don't be silly!

20 to 30 bugs for every 1,000

[dnhughes]

I'd like to know what consistutes a bug.

This just in, Apples =! Oranges

[0racle]

So if Oracle shipped with Windows, you would include Windows bugs in a count against Oracle? Sorry, but a little reading comprehension refresher seems to be in order, this is called an explanation. What is the Linux 2.6 production kernel? Linux is a kernel that shipped with software from Red Hat, Novell and other major Linux software vendors. That statement explains what the linux kernel is, not that they counted all of the bugs in all of the software included in a distro. The bug count would have been much higher if they had. Go and count the number of bugs logged against KDE, Gnome, GCC, and X to get an idea what could have been counted had they tried to make a fair comparison. A Linux distro might still have less, but personally I'd bet that the BSD's have less.

The glass is half full...

[H8X55]

I don't care about the number of bugs in Linux, XP, my iPod, or my Toyota - the severity of the glitches is a bigger concern for me.

Obviously these bugs aren't causing *me* problems - so I'm gonna call 'em easter eggs.

Not sure why, but I'm abnormally happy and positive today - karma be damned.

What would be more useful

[hattig]

It would be more useful to have a list of bugs per OS level, i.e., kernel level, driver level, and so on.

This compared the Linux kernel to something a lot bigger. Perhaps the core of the Windows code tested (i.e., the kernel) is a lot more bugfree than the other stuff around it?

And just because the Linux kernel is relatively bug free, it doesn't mean that anything developed by other people is as well! Maybe it is just a sign of having a high quality control level at the kernel submission stage, and that certainly won't translate to other projects.

Bug This!

[mikers]

Karma to burn, karma to burn...

The report, set to be released on Tuesday, states that the 2.6 Linux production kernel, shipped with software from Red Hat, Novell and other major Linux software vendors, contains 985 bugs in 5.7 million lines of code, well below the industry average for commercial enterprise software.

Commercial software (at this point in time) has its priority on releasing new versions often. Because each release is a salable item. Linux on the other hand gets forked or changes version whenever "Linus feels its ready". BIG DIFFERENCE. Here's why.

Commercial software decide how much value is on each bug, if the bugs are cheap (not show stoppers), but minor things they can't forsee as causing them to lose money... They will ship it. Acceptable known bugs. Project management decision.

Open source has time on their hands. They can look over the code carefully, waste time on bugs that commercial outfits wouldn't even bother... But the problem (like with software project management) is that you can't tell which bugs will be the nasties when you choose to ignore them. Less bugs == more secure software, less nasties.

If commerical software decided to play the careful release, minimize bug game... They would make less money initially, but in the end it would work out. Microsoft and ilk can certainly compete with linux, but they made a choice long ago not to. They made a choice to RELEASE FAST and MAKE MONEY FAST! (hey, that sounds like spam).

m

20-30 bugs for each 1000 lines???

[cazzazullu]

If this is true, how comes that any program works anyway? If I write a simulation it is of the order a few thousand lines, but I cannot afford ONE bug in there. Publishing wrong results is not something I would like to do. This of course takes a lot of time, testing and debugging. But to put 30 bugs in each 1000 lines, have it to compile and run cleanly, and then even produce results that somehow hide the obviousness of these bugs and errors must be quite difficult. Anyone an idea of what sort of "bugs" we are talking about here?

Re:20-30 bugs for each 1000 lines???

[Derleth]

void main...

I found a bug in your code already.

Re:20-30 bugs for each 1000 lines???

[cazzazullu]

main can be void. It is just the shell that expects a program to return an int on exit, but the shell takes a default value for this if the program doesn't return this value. If you run my sig, it will not really return to your shell :) PS anyone stupid enough to actually try what happens if you run the program, don't forget to include unistd.h

Re:20-30 bugs for each 1000 lines???

[be-fan]

The bugs are usually things you hit in corner cases, or you'd hit if the user passed incorrect input data or whatever. Your simulation may have tons of bugs in it, but if you verify your results on small data sets (or known data sets), before doing large-scale tests, you can be pretty safe in assuming that your results are accurate. However, the bugs could still bite you if you decide to simulate more than a certain number of nodes, or specify something in the wrong format or whatever.

Confusing

[Keith Handy]

I mistook the title to mean "Linux has fewer bugs than it has rivals" ...

Amazing

[Clete2]

That's amazing that we have only about 1,000 bugs in the kernel, while most commercial software would have over 100,000 bugs. Interesting to read the report.

Apple :: Orange

[Anonymous Coward]

Both are kernel's as stated by their owners. Both are written in C. Both work on the x86 architecture.

While the posters here do not want to compare apples to oranges I think that would be a wasted opportunity. Don't forget Microsoft themselves have compared Linux to them on a fairly regular basis.

It's a matter of statistics.

[thrill12]

It matters to you (and me) that the bug in a certain application has a more severe impact. The number of bugs / loc is however a pure statistical number that tells nothing about the impact-rating of a bug...

GO figure

[pkcs11]

It also has fewer features.

Bugs ~ N_interactors^2

[4of12]

Quite.

My thought, too, was that some "bugs" are not evident by looking solely at the OS codebase.

That is, some bugs only manifest themselves through interaction between, say, a fuzzy incomplete API that the OS exposes to poorly written applications, or applications expecting to see the practical API from 9 years ago.

From my limited experience, it seems that those kinds of bugs are common.

I would expect Linux to have fewer of those kinds of bugs for a couple of reasons:

1. The exposed API, while it surely has evolved, has not built up so large a legacy of dependent applications and users that want old API behavior as has Windows. The growth curve has been so phenomenal that a small fraction of current Linux users will grumble that their old libc 5 based applications are breaking. Microsoft ramped up to OS saturation about 15 years ago, so they do have lots of users of DOS and Win3.1 developed applications that will grumble about breaks with backward compatibility.
2. Linux programmers won't silently tolerate incomplete API's with weird behavior where 3rd party Windows application developers must accept and learn "whatever Win32 does now". And, with a large installed base, Microsoft's OS developers have to cut bait at some finite stage of development with bugs still inevitably remaining. Linux developers always get to hide behind 3 formidable defenses:
   • you get what you pay for and how much did you pay me again?
   • it's still under active development, always and forever, no matter how good Linux happens to be we'll never claim it's done and good for running life support systems
   • if you don't like it, you're welcome to muck around with the source code all you want for your own purposes.
3. Microsoft has a business incentive to gain new application markets by leaving the exposed APIs for competing applicaiton developers in some disarray or changing them to something New and Better and Different for the future while deprecating support for legacy APIs for old OS versions that don't bring in fresh licensing revenue.

Re:Bugs ~ N_interactors^2

[tetromino]

Linux programmers won't silently tolerate incomplete API's with weird behavior where 3rd party Windows application developers must accept and learn "whatever Win32 does now".

I disagree. First, if you are using anything like Perl or Python, you essentially agree to accept and learn "whatever Larry, Damien, and Guido like at the moment". And their opinion tends to change with minor version numbers... However, at least Perl and Python are documented (and in the case of Python, readably so).
The bad side is that many parts of GNU/Linux not only have API's consisting of "whatever the dev likes at the moment" - the API isn't even documented! Case in point: can you figure out what the current fdo standard is for which applications to launch to open a file of a given mimetype? There are some webpages about the topic, but they are outdated. To figure out what's really going on, you need to read two mailing lists, and glean the API from between the lines. Scary.
But that's nothing compared to the kernel. To figure out the inotify api, you need to read Love's website. (how many kernel devs are there? do you know all their websites? how many of them do you want to check when you have a problem?) To figure out what's going on with scsi support this week, you need to diligently read the lkml and the fedora bugzilla (and the behavior of the scsi subsistem fluctuates a lot over time). Much of the documentation in /usr/src/linux/Documentation is old and obsolete, and the new documentation must be figured out from source, from mailing lists, or by asking the devs themselves.
If there is one thing Microsoft can be proud of, it's good documentation, all organized in one place.

Ammunition for Adbots...

[The Angry Mick]

It would have been really nice to see some more specific numbers for XP. Without the MS specicic numbers to compare against, I can easily see this article being cannibalised by some marketing droid for juicy, anti-Linux quotes. Think about how a movie studio will crib a single, positive sounding word from a horrible movie review to use as an advertising blurb:

About the only thing that can help possibly explain this film's existence is the ingestion of some pretty spectacular drugs.

becomes

"This film... is...Spectacular"

Given to the right marketeer, this article could just as easily be re-titled/re-packaged by Microsoft as:

Studies Show Linux has 985 Vulnerabilities

Re:Ammunition for Adbots...

[Anonymous Coward]

However, since the code is not available to be looked at, how can they produce that number? All they can do is say "It may be around the average for commercial applications we have looked at". That figure is something over 100x the error count for Linux. If Microsoft want to gainsay that, then pass over their code to them to run through the same process.

And in other news....

[Anonymous Coward]

Water is wet.

Fire is hot.

oh really...

[Phil246]

as if this comes as a shock to anyone here. sigh

What is this ?

[Salsaman]

"Obvious Day" on Slashdot again ?

Vaigue...

[Transcendent]

What do they classify as a "bug"??

There was a story a while back about the same exact thing, but unlike this incomplete and vaigue article, it mentioned that a lot of the bugs aren't actually bugs, but "warnings." (Maybe as simple as a dangling pointer... but if you're doing anything useful with pointers, they'll dangle at least for 1 line of code.)

You might have 100% bug free code, but their test might think there are 500 bugs in it, simply because an issue that would appear to be isn't because of a check or such beforehand. (but, I guess that's how buffer overflow exploits happen).

Linux kernel source != complete Linux source

[totallygeek]

What most people talk about Linux, they are referring to the "system", not just the kernel. For an accurate count on the number of lines of source code for Linux, you need to wc -l all the text of the source CDs for your distribution. When Microsoft mentions the number of lines of code XP is, they are referring to the overall system with all its utilities. The Windows kernel is just as small an instruction file as the one for Linux.

Another note: this still does not derive some explanation for bugs. If I have a 20-line program with two bugs, can I extrapolate that software will have one bug per every ten lines? Also, remember that Microsoft has many source licensing and backward compatibility issues. They have bugs that exist simply because they improve beyond the capabilities of older software. I don't mean to come off as a Microsoftee, but this is just a slam Microsoft article, and for once it is unfounded.

Sorry I need a more easy to understand metric

[Anonymous Coward]

How many library of congresses could these bugs fill?

Flawed comparison

[willgott]

The article claims that "...the Linux kernel programming code is better and more secure than the programming code of most proprietary software..."

Of course it is.

Most proprietary software are user-level apps where a bug here or a bug there isn't critical. The economic loss that can be atributed to a bug in MS Word's bullet-point-algorithm isn't as great as a datacenter going down due a Oops in the linux-box running the SQL-database. To put it simply: there are different requirements for different tasks. A comparison between the quality of WinXP's GUI and GNOME for example would have been much more interesting.

I don't understand how this story could make slashdot's frontpage.

Re:Flawed comparison

[Ignignot]

With apologies to Douglas Adams:

You don't understand how the story could possibly make the frontpage. To those that know how slashdot really works, it was inevitable that once this story was written, it would reach the front page.

oh man I messed that up bad.

Redhat's still running 2.4

[bingo_tailspin]

The report, set to be released on Tuesday, states that the 2.6 Linux production kernel, shipped with software from Red Hat, Novell and other major Linux software vendors
I just ran up2date and got the latest... 2.4.21-20.0.1.EL
I guess they were back-porting a bugfix :)

Breaking News!!!

[Class Act Dynamo]

This just in: Microsoft has purchased Stanford University. These rogue researchers have been fired and put in jail on nebulous theft charges. Stanford University announces that Windows is better than Linux according to its research.

of course 900 of those bugs

[Anonymous Coward]

were to get the winmodem drivers working...

IEFBR14

[iBod]

When I walked with dinosaurs (ok, IBM mainframes) as a sysprog, there was a utility program named IEFBR14.

The purpose of IEFBR14 was to do exactly nothing, and pass a zero return code to the caller after doing the 'nothing' (branching on the return address in register 14 - thus BR 14).

This was actually more useful than it sounds and was used frequently in MVS JCL (Job Control Language) to make JCL do its thing without having to run a real program in a JCL 'step'.

Thing is, this program that had to do precisely nothing, had no less than 3 patches issued from IBM. Mostly to do with not clearing R15 (the return code register) correctly.

Go figure!

Re:IEFBR14

[wagemonkey]

It was a bit more than that, IEFBR14 was the easiest way to delete a file - you ALLOC it with the right DISP and poof it's gone. That's what I used it for most, it was handy as a null step that let you do lots of other useful stuff as a by-product.

Re:IEFBR14

[iBod]

Yes, as you say, It allowed the JCL to work its dubious magic with file allocations etc.

Did you ever figure out condition code interpretation in JCL? It always seemed backwards to me COND(0,4) LE and all that???

Re:IEFBR14

[Lovepump]

Condition code processing was invented by the devil, immediately before inventing war, disease, pestilence, famine and plain chocolate. Some say it is his crowning glory.

I've pretty much got it sussed now, but when you come across COND=((1,LT),(0,NE,CUMT1),(0,GT,CUMT2)) you have to wonder what possesed the guys at IBM when they came up with it...

Re:IEFBR14

[Anonymous Coward]

"I've pretty much got it sussed now, but when you come across COND=((1,LT),(0,NE,CUMT1),(0,GT,CUMT2)) you have to wonder what possesed the guys at IBM when they came up with it..."

negative logic designed by a drunken hardware engineer

Re:IEFBR14

[iBod]

>> IEFBR14 is your friend - the 2 byte killer app for MVS

After the patch (adding the XOR 15,15 instruction), it was a huge, bloated 4-byte app.

Re:IEFBR14

[FJ]

A co-worker of mine had the best way to explain it. Say the word "SKIP IF" in front of COND statement & it is much easier.

For example if you see

COND=(0,NE,STEP1)

Say to yourself

"SKIP IF 0 NE STEP1". In other words, skip this step if STEP1 didn't give a return code of zero. It makes simple JCL checking easier.

Of course another option is to simply use the JCL IF / THEN / ELSE / ENDIF statements. It is more like standard programming.

Re:IEFBR14

[Lovepump]

But then you run into problems restarting jobs from mid-stream in the JCL deck. With IF/THEN/ENDIF you often get jobs flushing all remaining steps and ending OK unless specifically coded for.

You're right though - IF/ENDIF makes things a hell of a lot easier to read.

Here's a great example!

[Zorilla]

:(){echo "hello world"|:&};:

The reason why open-source rocks

[scovetta]

Seriously folks, this article sounds at first like "Go Open Source!!", but instead of cheering for it, you guys/girls* point out how it's not really comparing apples to apples. Would Microsoft ever come out and say, "No, actually that study that says that MS is better really doesn't address the real issues"?

I guess the fact that not many open-source developers rely on that development for their livelihood, so they're more likely to go for truth over hype.

It somehow restores my faith in humanity.

*I realize that girls don't use /.

Totally unfair comparison

[winkydink]

Windows XP is an operating system. The 2.6 kernel is a kernel. A more fair comparison would be the RHEL or Suse distro versus XP.

Who was that rival again?

[marcovje]

I thought it was OpenBSD :-)

Is it?

[Kythe]

Microsoft has chosen to include as much stuff in their OS as they have. No one said, for example, that they had to integrate the kernel and the GUI, or the web browser, etc.

That said, the article specifically refers to the number of bugs per lines of code, so this is accounted-for.

FUD... or is it?

[feloneous cat]

Okay, here are some non-facts:

o Well to be sure the "facts" are rather hard to come by. Microsoft is loath to part with any of its software for someone to check into it. So much of this HAS to be guesswork.

o 20-30 bugs per 1000 lines is about right (for what I was taught). My compsci class posed about 1 bug for every 50 lines. Reasoning is that if code goes beyond 1 page (printed page), it breaks up the users thought. I have yet to see anything that sez "no, no, it's not true!!!".

o As for the definition of a bug, that is a tricky question. You know what it is and I know what it is, but much like art, we only define it by seeing it. The argument that "it is behaviour that was not designed as part of the program" is such a weak definition as to be laughable (yup, I've heard that one).

o Reporters main goal is to hit the 12th grade reading level. Anything beyond goes over the readers head.

Now you know why heads of business are such morons.

Re:FUD... or is it?

[mdfst13]

According to these people, Linux only has about one bug per 5700 lines. They show *ZERO* evidence that Microsoft's number is higher. Clearly, lower numbers can be attained (Linux did it!).

A better way of saying it would be: prior to testing, most code contains 20-30 bugs per 1000 lines. Linux catches over 99% of these. There is absolutely zero attempt to quantify how much Microsoft catches. Thus, we can make no comparisons between Linux and Microsoft.

Note: I am an open source fanboy. I would love for these numbers to be true. However, I see no actual evidence that they are. This is FUD in the classic IBM sales sense: set up a straw man; demolish straw man; proclaim victory.

Subject is ludicrous!

[dcigary]

Once a very wise CS prof of mine asked us to examine the phrase "We have no undiscovered bugs in our software". Which, as it's written, is true. Truly, a piece of software has no undiscovered bugs. Take that in mind when you read this article. To say that a piece of software has "less bugs" than some other is a very tricky and bold statement to make, as a bug isn't a bug until it's DISCOVERED.

Re:Subject is ludicrous!

[Anonymous Coward]

"We have no undiscovered bugs in our software".

That reminds me of the "If a tree falls in a forest, and no one hears it, does it still make a sound?" I say yes, and there is science to back it up. If you think there aren't any undiscovered bugs in software then prove it.

I don't think so

[samjam]

I reckon there is an exponential drop off for bug discovery in large code bases; as well as measure of bugs-per-lines-of-code for project types.

I reckon that combining these figures over time will give you an estimated number-of-bugs-yet-to-be-found along with the number of hours it will take to find the first certain-proportion of them.

(And being exponential it will that just as long to find the next certain-proportion of whats left.)

I'm guessing all of this, but it seems reasonable to be able to predict bugs left in a large project.

Sam

Not a true comparison

[OhHellWithIt]

Where did they get the Windows source code to examine? If they didn't get the code, then how do they know they found all the bugs in Windows?

There's also the question of defining a bug. Sometimes, one person's feature is another person's bug. Take allowing scripts in email, like Outlook Express used to do. (May still do, for all I know.)

Classic case for the do-nothing argument

[ClosedSource]

For most proprietary software, the source is not available. So when contemplating this study the authors should have realized that it couldn't possibly be valid and decided to go do something else. The fact that they went ahead anyway, is a strong indication of their lack of dedication to scientific principles.

Re:Classic case for the do-nothing argument

[Anonymous Coward]

The fact that microsoft makes attempts to make operating system kernels (and the results of those attempts) "is a strong indication of their lack of dedication to scientific principles." One of the most powerful methods of design known to man, which has been 'proven' by several thousand years of success is the scientific method. A theory for progressing science is proposed based on previous facts and a bit of speculation. Tests and analysis is done. Conclusions are reached and the whole is published. Others read, critique and improve (or discredit) the findings. The process repeats. Knowledge is extracted rigorously. OSS is designed in this way. It is similar to the engineering equivilent; the self-correcting continuous feedback system. Free market economics works this way too. Closed source proprietary software works more like command economies where design is by fiat, bugs are assigned by fiat (or not at all as they are usually rated as economically fixable or not), and better solutions sit idle because only a few are allowed to examine and correct. With closed systems, creativity is artifically hindered. Best designs sit unused, and the bosses friend dictates stupidity, rather than allowing the best person for the job to be heard. Don't argue, you know it's true. And people wonder why OSS is so good. It's good by design, and it's good by it's very design process/cycle.

Re:Classic case for the do-nothing argument

[ClosedSource]

Well, those are some interesting opinions. Too bad they have nothing whatsoever to do with my post.

Prominent counter-example

[68kmac]

"Hello world" has 0 bugs per three lines of code!

The book "C Traps And Pitfalls" by Andrew Koenig (yes, that Andrew Koenig) starts with his first experiences in C and how he managed to have 2 bugs in his "Hello world" program ...

Measuring unknown numbers

[ites]

There is actually a technique to accurately estimate the number of total bugs in a closed-source product. This uses the "theory of unknown numbers".

It requires accurate tracking of two things: bugs reported by the users, and bugs found and fixed by the development

Scenario 1: for every 10 bugs found and fixed during testing, there are 2 more new bugs reported by the outside world.

Now, after testing a release extensively, we find 1000 bugs. We now now that the total number is approx. 1200.

Scenario 1: for every 2 bugs found and fixed, there are 10 more new bugs reported.

After testing we have 1000 bugs. We now know that the true number is closer to 5000 bugs.

This is an accurate tool and we've used it in several projects to predict future support costs. Your mileage may vary, of course. And you definitely want to be in scenario 1, not 2.

Re:Measuring unknown numbers

[ClosedSource]

Where do these numbers come from? Are they supposed to be universal constants? This sounds a lot like a stock market get rich formula to me.

Some statistics...

[Anonymous Coward]

100% of this article is 100% useless.

Blah blah blah

[YesIAmTheMan]

Great, so the Linux KERNEL is in great shape. That really is good news. However, take one look at Secunia's security bulletins for actual Linux software and you'll see just how secure the Linux platform really is. "Oh, but most open-source stuff is patched!" you'll cry. Well, so are the majority of the most severe security-related commercial software bugs. The whole "Carnegie Mellon predicts this bullshit" is bullshit. No explanation needed because if you can't figure out why this is bullshit, your skull must be filled with bullshit. Congratulations researchers! Yet more bullshit for the sake of rhetoric!

20 to 30 bugs

[PMuse]

Commercial software typically has 20 to 30 bugs for every 1,000 lines of code

What software? When? The average for OS Kernels? Not hardly.

How were they counting?

[DeputySpade]

Did they count everything that was clearly marked with the universal bug notation:

// THIS IS A BUG! -- FIXME FIXME FIXME //

and skip everything that was marked with the universal "this is not a bug" notation:

// THIS IS NOT A BUG! //

Maybe they should go back and count again.

Agree with you.

[nortcele]

FUD is FUD regardless of who is spreading it.

Although a pretty good study of the Linux code can be made since itis readily available, they obviously didn't find ALL the bugs. Lumping all commercial code into the statement of: "Commercial software typically has 20 to 30 bugs for every 1,000 linesof code, according to Carnegie Mellon University's CyLab SustainableComputing Consortium." casts a very wide net.

The key word is 'typically'. Obviously Microsoft's code falls well short of the commercial bug average because of their more stringent and advanced build methods and the personnel they hire. (Outlook/Internet Explorer and Ballmer excepted). They can say that the Linux bug rate is low when compared to the overall average. Okay...fine. To then imply that the Linux bug rate is lower than Microsoft's is nothing short of disingenuous. It might be more accurate to imply that the study of the Linux code lends credence to modular code and programming methods, proper source code control, and that many eyes searching the code are better than few.

Let's wait the report before blaming this work

[herve_masson]

> The report, set to be released on Tuesday,

The result of a four year study by 5 researchers is probably much more dense than a few hazardous assumptions. The result of their work is supposed to come next week, let's see then.

main must return int

[hayne]

No - according to the C and C++ standards, main must return an int.
See the C FAQ

Re:main must return int

[cazzazullu]

Ok, you are correct. Since such programs do compile I thought there was no problem, but this is indeed a bug after all. Thanks for pointing this out, I will change my sig immediately ;)

Re:main must return int

[hayne]

Since such programs do compile I thought there was no problem, but this is indeed a bug after all

The more important bug is in the compiler - it should refuse to compile C++ code that fails to adhere to the standard.

Plus

[Sycraft-fu]

If someone can confidently say Linux has 985 bugs, and ONLY 985 bugs, and point them all out, then one would think in short order Linux would have 0 bugs, since they'd all get fixed.

The whole thing kind of strikes me as people talking out of their ass.

how many bugs is unknown

[DunbarTheInept]

While I'd like this news to be true, I have to be very suspicious because any time someone claims to have successfully tallied all the bugs in a program, that person is lying.

But

[Anonymous Coward]

But I thought IE was easily removed?

When bitching about software bugs, Slashdotters complain that IE is too integrated. When bitching about Microsoft tactics, they complain that IE isn't really integrated and can be easily removed by utility programs, and it was all a lie at the antitrust trial.

Meanwhile, this is one of the silliest, most biased, most one-sided articles Slashdot has posted. Wow, 40 million lines of code has more bugs than 5 million? An entire operating system, desktop environment, shell, and included programs has more bugs than a simple kernel? WOW!

569 bugs in Linux could cause a system crash!!!

[Bryan-10021]

The study also shows that the Linux kernel is not perfect, 100 were security bugs and 569 that could cause a system crash. This is just in the KERNEL not the entire OS. The study identified 0.17 bugs per 1,000 lines of code in the Linux kernel. Of the 985 bugs identified, 627 were in critical parts of the kernel. Another 569 could cause a system crash,

• 100 were security holes,

and 33 of the bugs could result in less-than-optimal system performance.

Clearly Sun's Solaris does better in security and reliability in the kernel and the reason commercial UNIX's are still viable. Linux is good but Solaris 10 is just in another league.

Another obvious biased stance

[Sycraft-fu]

Is comparing the Linux kernel to the Windows OS as a whole. The Linux kernel by itself is essentially worthless as an OS. You at the very least have to add drivers, a shell, and some basic programs and services. In reality to have a workable desktop OS you need X, a good WM, and a ton of programs on top of that.

Now I can see maybe comparing the kernel mode code. Windows throws a lot of stuff in the kernel, much of which UNIX types disagree with. Basically the whole graphics subsystem, including rendering engine, is all kernle mode. Microsoft decided that the speed increase was worth it and it didn't matter since if it goes down, the system halts anyhow since Windows doesn't drop to shell. UNIX is different, if X crashes, big deal, you now have a console and you restart X.

However even with kmode comparisions it gets hairy. I mean what is really necessiary and proper there? Talk to a hard core microkernel fan of soemthing like QNX and they'll say NOTHING excpet the kernel, not even drivers. Linux put a LOT in kernel space as compared to some OSes.

Is anyone else bothered by this?

[rd_syringe]

Is anyone else bothered by the idea that an article entitled "Linux Has Fewer Bugs Than Rivals" is posted that compares 5 million lines of code that make up just a kernel to 40 million lines of code that make up a kernel, an operating system, a desktop, its integrated components, and its included applications? 40 million lines has more bugs than 5 million? Who'd have thunk it?

Why does "Linux is just a kernel" suddenly not apply here? Is it because we're bashing Microsoft? This is kind of lame and makes the community look silly and vitriolic.

Re:Is anyone else bothered by this?

[ColMustard]

This guy has a valid point, and to mod him down as if this argument isn't valid is just silly. Mod points shouldn't be used to kill people who you happen to disagree with.

Re:Is anyone else bothered by this?

[Anonymous Coward]

Read the article again.

According to the author: Linux has fewer lines of code AND fewer bugs per thousand lines of code when compared to typical commercial software.

Currently linux has 985 known bugs in 5.7 million lines of code. If linux is to compete with commercial code it will need about 114,000 to 171,000 bugs in 5.7 million lines of code.

Re:Is anyone else bothered by this?

[JudicatorX]

Why does "Linux is just a kernel" suddenly not apply here?

Linux is a kernel. The problem is that this is comparing the linux kernel to all of windows XP

Re:Is anyone else bothered by this?

[Dayze!Confused]

I think what they were trying to get across was that, in this industry, the average is much higher than what they found in the Linux kernel. If Microsoft went with the industry average on bugs then in a ratio of bugs/line of code, Linux beats them with having only 985 bugs compared to what they /should/ expect to have, around 140,000, for that many lines of code.

Re:Is anyone else bothered by this?

[Master of Transhuman]

Anyone wonder why it takes 40 million lines of code to do what 5.7 million do?

That's the real question.

And no, that doesn't include "all of Microsoft's applications."

What "included applications" were you referring to? Notepad? Gimme a break...

Linux is written by programmers who obviously love programming, since they work on it in their spare time outside their normal programming jobs.

Windows is written by 24-year-old recent college CS graduates who have no fucking clue how to do anything - managed by "product managers" who have even less clue - managed by corporate execs who are KNOWN ASSHOLES!

What part of this picture isn't FUCKING OBVIOUS?!

Mod me troll, mod this flamebait! Is that all you got, huh? Are you nuts? Come at me!

Re:Is anyone else bothered by this?

[elder-geat]

Linux is just a kernel -- that's good. It is modular, with well defined interfaces. Windows XP is not just a kernel. It is seven times larger than the linux kernel. It does not have clean interfaces between the apps that are included in the OS for market domination rather than engineering reasons. Software complexity ==> bugs complexity is proportional to the square of the lines of code. linux lines / xp lines = 7 7 * 7 = 49. 49 times more complex. Do the math.

Re:Is anyone else bothered by this?

[fymidos]

hey, i agree, web browsers and multimedia applications shouldn't have anything to do with the kernel at all...

but it's not the communitys' fault, nor the communitys problem.

Re:Is anyone else bothered by this?

[Anonymous Coward]

Jesus Christ, what's wrong with this thread?

The parent is modded insightful when even the blurb says it's comparing bugs per 1000 lines, not total bugs. The 2 posts I've seen that point this out are both at 0 (one AC that started like that and one logged in user that got modded down). The fucktard saying the Linux kernel does what XP does in far less code is at +2. Yet another guy saying that they're comparing the kernel to all of XP is at +2 informative.

How the hell can this many mods NOT EVEN READ THE BLURB?

From TFA:
Commercial software typically has 20 to 30 bugs for every 1,000 lines of code, according to Carnegie Mellon University's CyLab Sustainable Computing Consortium. This would be equivalent to 114,000 to 171,000 bugs in 5.7 million lines of code.

I swear, much more of this and I'm going to whip out the shot gun and find some of these mods.

Re:Is anyone else bothered by this?

[Anonymous Coward]

40 million lines has more bugs than 5 million? Who'd have thunk it?

RTFA. They compare bugs/LOC not total bugs. If you honestly think it is obvious that 40M lines would have more bugs per line than 5.7M lines then I really wish you would stay away from computers since you are just part of the problem.

In my opinion, they did a fairly decent job of comparing two systems in a situation where comparisons are challenging. Perhaps instead of the rather sensational 114,000 bugs vs 1000 bugs they could have given a more honest comparison, say 7000 bugs vs 1000 bugs (over ~6MLoC).

Re:Is anyone else bothered by this?

[Anonymous Coward]

In my opinion, they did a fairly decent job of comparing two systems in a situation where comparisons are challenging. Perhaps instead of the rather sensational 114,000 bugs vs 1000 bugs they could have given a more honest comparison, say 7000 bugs vs 1000 bugs (over ~6MLoC).

Oops, scratch that last sentence. Unbelievable as it might sound it does actually work out to 114,000 bugs / ~6MLoC! The sensationalist number would be about 800,000 bugs in a basic Windows install (of which maybe 114K are in the actual kernel).

Re:Is anyone else bothered by this?

[zoeith]

Though I think most bugs appear in the upper layers... the gui, desktop environment, etc. In my personal experience if something crashes on my linux desktop it is because KDE, Gnome, or Firefox crashed. Similarly in Windows, IE, explorer, and the windowing system are most likely to crash. Had this been only an analysis of Windows/Proprietary Kernel Vs. Linux Kernel, I think the bug counts would be closer. That is to say bugs are not evenly distributed over the different software components that make up a complete operating system. That said... had I the inclination to do so, were I to discover a reproducible bug I could offer valuable insight to the developers of an open source piece of software. But MS would most likely laugh me off in addition to which I wouldn't be able to mention a specific line of code.

Re:Is anyone else bothered by this?

[zoeith]

Linus was born 1969. Linux was unleashed 1991.... 1991-1969 = 22. And yes -- I have seen notepad crash.

Re:Is anyone else bothered by this?

[Anonymous Coward]

If they are comparing code quality then it doesn't matter whether it's a kernel or not... Ok, ok, we're bashing M$!

AC

Re:Is anyone else bothered by this?

[g0sub]

RTFA. Read the slashdot ingress even.

They are comparing one piece of code with another piece of code. They are not saying that the two pieces of code serve the same purpose. This is common in code quality comparisons.

Also - Where on earth did you see that they compared absolute values? They are looking at numbers of bugs per line.

Re:Is anyone else bothered by this?

[CharlieKotan]

Note: the 900+ bugs are in production. There were LOTS more in dev, which is how the CMU 20+ bugs/KLOC came about. Comparing apples to iguanas.

Re:Is anyone else bothered by this?

[Anonymous Coward]

I thought that was his point...the idea that Linux is just a kernel yet is being compared to all of Windows.

Re:Is anyone else bothered by this?

[SanGrail]

1) The fact that it's the kernel *does* make a damn difference, most bugs are in the gui, graphical shit, and most definately not on the kernal which is actually *smaller* in Windows. Comparing bugs in the kernal to bugs in the desktop manager is like apples & oranges.

2) The article is a fanboy piece of journalism (imho as someone who actually uses & supports linux & open source). They are not even comparing it to the Windows operating system, but to the number of bugs you'd expect in a piece of 'commercial software' of that size. Great.
Well even I'll accept that M$, however we may slag them, has a *much* higher standard of quality than your average 'commercial' operation.

So, surprise, surprise. Something as widely publicised as the linux kernel, using opensource, has many less bugs that your average piece of software. Whoopdee.
Now, if they were to do the same to kde, the various x windows, or open office I'd be a mite more impressed. Since they don't have the prestige value of the linux kernel, they've got much further to go.

Re:Is anyone else bothered by this?

[Dean Edmonds]

This got modded "insightful"?

He was *joking* people.

Sheesh!

Re:Is anyone else bothered by this?

[Anonymous Coward]

Whattsamatter? Couldn't post again as rd_syringe or bonch?

Loser.

Re:Is anyone else bothered by this?

[Anonymous Coward]

The problem you're facing is that rd_syringe has two other accounts (bonch and Overly Critical Guy--and probably more just used to cull mod points) with which he can mod up his three most visible accounts with.

I find it hard to believe that the moderators around here would be as stupid to mod up a known troll like rd_syringe-bonch-Overly Critical Guy.

Re:Is anyone else bothered by this?

[Anonymous Coward]

YHBT. YHL. HAND.

Love,
rd_syringe (aka bonch aka Overly Critical Guy)

Re:Is anyone else bothered by this?

[Anonymous Coward]

YHBT. YHL. HAND.

Love,
rd_syringe (aka bonch aka Overly Critical Guy)

Re:Is anyone else bothered by this?

[Anonymous Coward]

Mod points shouldn't be used to kill people who you happen to disagree with.

You're new here, aren't you.

What PRECISELY is a bug?

[davidwr]

What precisely is a bug, and is the same definition used when comparing the Linux Kernel to MS-Windows?

Unless the treated the Linux kernel as a black box, the answer to the 2nd question is "of course not," rendering the comparison much less useful.

There are many ways to "count" bugs.
You can count symptoms.
You can count symptoms that result in behavior that is worse than some BADBEHAVIORLEVEL (i.e. ignore inconsequential mis-behavior).
You can scour the source code looking for code that LOOKS like it doesn't match the DESIGN (or what you think the design would be if there is no explicit design).
You can scour the source code looking for both implimentation errors AND broken-when-written or ok-when-written-but-broken-in-today's-environment designs. But this begs the question "if it's a broken design, is that one bug, one bug for every affected module, one bug for every affected line, or one bug for every unique symptom?". Microsoft code is full of "arguably-ok-when-written-but- broken-in-today's-malware-environment" code.

When it comes to implimentation bugs, do you count bugs in unreachable code?

I'm sure every programmer can add his own two cents to the "what is a bug, really" discussion.

And yet

[Anonymous Coward]

And yet, Linux has more security advisories than Windows each month.

I'd like to see a serious discussion of the methods and funding sources in this study. You know, the same kind of discussions that appear whenever a Microsoft study is posted. Mysteriously, that critical thinking is absent in articles like this.

40 million lines of code != 5 million lines of code. If Microsoft attempted such a skewed study, I can already picture the kinds of posts people would be writing, asking about methods, funding, and more. Those posts aren't appearing in this article. Why? Well, that's because this isn't about the quest for finding out which operating system actually has less bugs (sorry, I forgot, "Linux is just a kernel!"...funny how that oft-uttered phrase is missing in the article discussion), this is nothing more than a Microsoft-bash article intended to generate Microsoft-bashing replies.

OSTG, the corporation that owns Slashdot, makes money off of OSS products. It's rather convenient that they run a "tech news" site that just so happens to post news stories that are all critical of their competitors, isn't it? Imagine if Microsoft owned a tech news site that posted nothing but anti-Linux articles? You guys would be all over it, but your biases against Microsoft make you have a double-standard. So you ignore that Slashdot is a corporate-owned website with a major bias and an editorial staff that can barely read and write correctly, much less bother to read their own website.

Re:And yet

[Anonymous Coward]

How come flame wars always spring up with the "microsoft is buggy" issue. You've made a pretty big jump from "this isn't a fair comparison" to "slashdot authors are idiots". You can't say that suporting OSS makes a newsite useless, it's a choice they make. Microsoft deal with problems by throwing money at them, OSS make news posts. so what?

And while it isn't a fair comapison, you must admit that having so few bugs in the kernel alone suggest that the general standard of coding is high. nobody could trawl through the 40mill lines of WinXP code, just like no one could go through all the software that makes up the Linux desktop (especially seeing as it's constantly updated) But anyway: Do you run windows update? have you seen the number of patches that appear? do you have to keep an antivirus running 24/7 to watch over your security holes?
I know i do. And yes, despite all the advantages of Linux, i run windows, because at the moment i need more ease of use, no time to learn a new OS.
Bug-proof isn't everything.

Re:And yet

[Anonymous Coward]

While it's true that it might be unfair to compare 5.7 million lines to 40 million, the Linux community should not be blamed for Microsoft bloat, nor should we feel compelled to bloat Linux so that studies like this can be made. The article did do a proportional analysis, which should aleviate your rants (but apparently doesn't). It does mention bugs per thousand lines (which is proportional). It's true that there are hundreds of Linux advisories every month (not made by CERT, but made over at kernel.org, where they get fixed as the kernel is advanced). I find it also interesting that the apparent issue of bugs per line gets Microsoft lovers all in a huff on one hand, yet they don't seem to mind the obfuscation of saying 'if Linux were as popular they would get as many viruses' on the other. Proportionally Linux has about 6% of the home market now. It should get 6% of the virii. But it gets less than 0.0006%. WHY? Surely the Microsoft lovers have some ready made excuse. But in the end it all starts to smell like passed gas at a chilli and cabbage cookout.

Re:And yet

[Anonymous Coward]

why the fuck would 6% of virus writers waste time writing viruses that only affect 6% of computers?

or do you just like the numbers because they're the same?

Re:And yet

[Anonymous Coward]

" And yet, Linux has more security advisories than Windows each month."

And this is exactly why microsoft decided to only release security advisories monthly in the future. What they don't know, won't kill 'm right?

OB

[sc0ttyb]

[sings]
These are the Daves I know, I know. These are the Dave's I know...
[/sings]

Even better

[Anonymous Coward]

In Python it would be :

print "Hello World!"

Which is why...

[Inoshiro]

We NEVER compile code without using -Wall and -pedantic!

dylang@shadowgate:~/.tmp$ gcc -Wall -pedantic -c foo.c
foo.c: In function `main':
foo.c:6: warning: `return' with no value, in function returning non-void
foo.c:8: warning: control reaches end of non-void function

It compiles, but you are TOLD about your mistakes!

Re:Which is why...

[Anonymous Coward]

Although this is slightly off-topic as it is, there are many legacy applications that were never compiled with those options from the beginning because they did not exist, and now that they do, generate hundreds of thousands of lines of warnings. It's not that the code is flawed; it operates correctly. It's just not as strict in its source code form as one would like.

Re:Which is why...

[prockcore]

It's not that the code is flawed; it operates correctly.

Nonsense.. the code is flawed.

Example of why you can't trust "running the program to see if it works".

int main()
{
int x=0;
printf("%d, %d, %d\n",x++,x++,x++);
}

That code compiles cleanly, and gcc on linux/x86 will always print out "2, 1, 0". Always. If I didn't know any better, I'd say that it was perfectly correct code.

However, compile that with gcc on solaris/sparc, and it will print out "0, 1, 2".

Compile it with -Wall and gcc will tell you that there is probably something wrong with that code.

You could run it millions of times and have it run flawlessly.. but one little change could cause your program to operate completely differently.

Re:Which is why...

[Anonymous Coward]

using MSVC6, it prints 0,0,0 =/

Re:Which is why...

[jeremyp]

-pedantic doesn't necessarily do what you think it does.

I came across this the other day while compiling some code that used an ancient C++ library. The compiler errored on a function declaration that looked something like this:

extern foo () ;

The C++ standard doesn't allow you to omit the return type. I was able to work around the problem by adding -pedantic and the compiler threw out a warning but managed to create some code. It seems the default setting for g++ (at least) is -pedantic-errors.

Long time in the making.

[Inoshiro]

While this may seem like some random posting to Slashdot, those folks from Stanford have been active on the LKML plenty of times, asking about conditions their tools have found, and whether they are bugs or not.

They've directly led to many of those bugs or design choices being discussed and changed, for the better in every case. I wouldn't belittle such work easily, because they have (in their way) contributed a lot to everyone's favourite OS ;)

Why Linux ...

[The MESMERIC]

Although not as pure Unix - it is definitely a more stable solution than SCO.
Althought not as stable - it is definitely more powerful than QNX.
Although not as powerful - it is definitely more user-friendly than Solaris.
Although not as user-friendly - it is definitely more secure than Mac OS.
Although not as secure - it is definitely more widely known than FreeBSD.
Althought not as widely known - it is definitely a cheaper choice than Microsoft Servers.

Linux is winning popularity for the same reason Microsoft Windows won 20 years ago
- it is suddenly becoming very accessible to businesses at large.

Coverity == Stanford Checker

[Anthony Liguori]

Coverity is a start-up formed from the group at Stanford who developed the Stanford Checker. The Stanford Checker is a static analysis tool (quite primative actually as far as the state-of-the-art is concerned) who's main claim to fame was the number of bugs it found in the Linux kernel.

What they're probably claiming is that their tool found less bugs in Linux than in most commericial software. I buy this. The tool finds a lot of bugs that aren't necessarily easy to exploit or things that are really just not best practices.

Open source software tends to get highly critiqued (at least, the popular projects). It often becomes a programmer pissing-contest to see who can come up with problems in someone elses code. Commericial software, on the other hand, tends to just be whatever gets the job done.

This doesn't answer the most important question though: Which method is more succeptiable to attack? The question is very hard to answer.

When is a bug a bug

[Blitzenn]

I have to agree on your bug definition question. The install base of Windows is so wide and the hardware so varied, many of the so called bugs are simply hardware and software errors caused by the users themselves.

The other problem, related to above, is that new hardware comes to th market and everyone expects that the previously written software should support it without a flaw.

And, furthermore, many people seem to consider a feature that is not there, i.e. no right click menu on an item, a bug. If that is the case, then Linux is loaded so full of bugs that you can see the software through the mass of bugs. There is so much that is not supported or is simply not there that I can't do half of the things I set out to with my Linux installations. Don't get me wrong, I like Linux and use it where it is suitable. I don't use it where it is not suitable and scream 'bugs!'

Doesn't matter AT ALL

[ltbarcly]

This seems to completely miss the point of why it is smart to use Linux now.

1. Linux is "Good Enough" now. Maybe it is better than windows, maybe it is worse, but unless you are a dope, Linux can do what you want it to.

2. Linux improves every day. Most distro's have a twice a year release cycle, with noticable improvements each release. So long as the improvement is non-trivial this leads to #3,

3. Linux will be the best eventually, and by an ever widening margin. Open source is the future of software. Switching to linux now means that you won't have to 'upgrade' to it later, and you can contribute to it by finding those bugs now.

(4. Stop being an asshat and install Linux.)

Uh, wrong comparison!

[adiposity]

How many bugs are there in the NT micro kernel? Not so many, I'd warrant. Comparing the entire win32 api and the XP GUI to the linux kernel doesn't make any sense at all. Granted, it's not really possible for the average person to separate the two, but in order to get the closest comparison, you'd need to compare Windows XP To Linux + Gnome or Linux + KDE, or something along those lines. I believe the number of bugs in KDE or Gnome easily exceeds the bugs in Windows XP, although I can only prove it anecdotally.

I'm excluding Internet Explorer from this, which I refuse to use, but if I were to include it, I'd have to compare it to Mozilla, which also has a huge number of bugs. Also, are security vulnerabilities considered bugs, or not? I'll admit upfront I haven't RTFA, but the summary seems to indicate a comparison of apples to oranges.

-Dan

Re:Uh, wrong comparison!

[praxis]

I totally agree! Comparing any kernel code--be it Linux, Windows, Mach, BSD, Hurd, or any other--to user-level code is a poor comparison. Kernels are tested more thoroughly, written by more competent individuals, and bugs are discovered sooner and easier due to the critical nature of the algorithms working correctly.

Re:Uh, wrong comparison!

[thegnu]

I agree but with reservations. I haven't RTFA either, so we're even. I did, however search TFA for Windows, and it's not in TFA.

The reason why comparing the Linux kernel to Windows in its entirety is fair is because you can install just the Linux kernel. You can't install just the Windows kernel. Plus, I do think that as far as scope goes, they are reporting bugs per capita.

Also, I've found much more often that Windows in its entirety crashes when one of the parts of Windows that is not Windows according to you crashes. So if the Windows microkernel isn't a platform and the integral parts of Windows without which Windows won't work can easily disrupt the microkernel, then we must compare the platform Windows to the platform Linux.

Also, if Microsoft released their source code, it would be open to scrutiny. But they haven't.

they spent four years to analyze the 2.6 kernel!

[no-karma-no-worries]

give me that time machine, so I can run 2.8 right now !!!!

just hold your horses

[jeif1k]

The study hasn't been released yet. Once it has, we can check for ourselves what their methodology was, what their definition of "bug" was, etc. Then, and only then, can we discuss whether the study has merit or not. Until then, there is no reason to flame either way.

So...more rivals than bugs?

[Anonymous Coward]

yay for ambiguously worded headlines!

Re:they spent four years to analyze the 2.6 kernel

[Jakosa]

Next time it will be 3.0.. ehm.. right Linus?

okay..

[Anonymous Coward]

now please submit all bug reports to bugzilla ;)

FUD!!!

[Anonymous Coward]

I get so tired of the FUD by the linux crowd. Yes, anybody can lie with numbers.

Yes oh great linux people, you must take over the earth and subject us to your rule. Yes, comrade, everything else is inferior and our only allowable choice is Linux. You know what's best for the people, so that's what the people will get.

I don't even have a linux box anymore. I got so tired of the we must conquer the world shit that it's over.

Re:FUD!!!

[The MESMERIC]

good
now lick my boot.

Sorry, but the BS meter reads a 10 on this one...

[QuasiEvil]

Great, that's the obvious bugs they could find. The insidious ones are the logical errors, timing problems, or bizarre interactions of code. Those are the ones that you often spend years scratching your head over infrequent, seemingly random (yet oddly related) failures until one day you happen to be looking through code and find something screwy, or you happen to have the debugger on at the right time. Then there's the ones that hide for years, and suddenly pop up when something innocent changes in a completely different section.

I'm a legacy code maintainer among other things, and that's my personal hell.

Slashdot frontpage

[proton]

It made the front page because its interesting and sparks debate, they didnt dump it in the trash just because you happened to disagree.

Slashdot is not just a blog for the latest software releases, if you only want that kind of news, try freshmeat.

/pro

114,000 bugs?

[cybermint]

Only 114,000 bugs... wonderful.

Microsoft has approximately 10x the in-house QA

[romi]

Microsoft has an insanely high in-house QA to developer ratio (it's over 50% I believe). That alone could account for a large discrepancy in the number of bugs found.

How?

[Anonymous Coward]

Umm... I don't think microsoft gave up their source code to be analyzed... so I'm not exactly sure HOW this study could compare invisible code to public code. What did they do use their powers of intuition to estimate Window's bug count?

Apples and Oranges

[katorga]

They provide specific Linux kernel numbers for the 5.7 million lines of kernel code.

Then they reference 20 million lines of code for Windows. Is that all kernel? Microkernal+HAL? Entire OS? No specific number of bugs listed.

Then they reference "commercial software" bug rates per 100,000 lines of code as if a bug in my rss reader app is as important as a bug in the kernel. They no effort to state which types of code deserve higher qa and which do not.

All in all a non-story.

Interesting bias angle

[Sebastopol]

I'd like to note that although /. is aggressively pro-Linux and anti-M$, and despite this pro-Linux propaganda, the /. community has remained largely objective to this study.

I guess coding discipline trumps O/S bias and politics.

Current Status of the Standford Checker

[watermodem]

What is the current status of the Standford Checker. Last time I talked with them they were going to try it on X but that was before the X-Open split.

Readable version

[Anonymous Coward]

http://shit.slashdot.org/article.pl?sid=04/12/14/1 340237

This is Mathematically Impossible

[Jahz]

I am in the midst of finals week and one of my classes is on computational theory and time complexity.

This post goes againt all that I just learned. Obviously these 5 students did not read over all 5.7 million lines of c code. Doing so would take a copious amount of time. Even if they did go over every single line, what makes you think that *they* found all the bugs that dozens of other developers missed??

Obviously some sort of code analyser was used here. And it is not possible to write a program that analyses other arbitrary programs to determine some non trivial property. So, if you cant tell how a program reacts on every possible input, you cannot find all the bugs.

This is a textbook NP-Complete problem. There are innumerable proofs on it. If these 5 Stanford researchers have found a way to take an arbitrary large code sample and give you a number representing the amount of bugs in it, they would be instant billionaires.

(Not to mention having implicitly solved every other non-polynomial decidable problem!)

Article wrong

[antientropic]

This doesn't mean that the kernel has only 985 bugs, it means that the Stanford guys found 985 bugs using their particular tools (which scan for certain types of bugs). That's a big difference. Remember Dijkstra's law: testing can show the presence of bugs, but never their absence.

985 bugs is an absurdly low figure for a software system of any respectable size (except, maybe, life-critical systems). Hell, just looking at a handful of changelogs for Linux kernel releases gives you more bugs than that.

If they use a unified method across the board...

[thegnu]

then it doesn't matter if they've found all the bugs. It's reasonable to assume that they found roughly the same percentage of bugs as they did in any other code they analyzed. But I agree. Phrasing it that way is misleading.

Correction:

[thegnu]

Windows does appear in TFA:

"Windows XP, by comparison, contains about 40 million lines of code, with new bugs found on a frequent basis."

They don't, however, actually say anything about Windows though. And even though they say "by comparison," it's not an actual relevant comparison.

what about the extras

[SI285]

Sure, the Linux core may have fewer bugs but what about all the additional packages included with each distro?

Linux Security Advisories

[Anonymous Coward]

The advisories are amalgamated at LinuxSecurity.

fewer bugs than rivals

[sporkums]

"fewer bugs than rivals"

I don't know if I agree. Linux has a handful of rivals (NetBSD, Solaris, Windows... ) but the number of bugs in Linux probably numbers in the tens or hundreds. ;)

arithmetic bugs?

[townmouse]

According to the article:

Of the 985 bugs identified, 627 were in critical parts of the kernel. Another 569 could cause a system crash...

627 and another 569 is 1196, which is already more than 985.

Re:arithmetic bugs?

[jrhass]

They state it like it's mutually exclusive, but it makes sense that it's not (i.e. a bug in the critical part of the kernel could most likely cause a system crash).

what about the software?

[themoebius]

Sure the kernel is less buggy than anything else, but I've found that most of my linux applications crash WAY more often than any of my windows software.

Why not FIX the bugs

[Godman]

If these people were smart enough to know where the bugs were, why waste 4 years of time just to prove that "Linux is less buggy than Windows" It seems to me that they could have put these four years to better use FIXING the bugs as well as finding them, or just writing new code, or SOMETHING.

Re:Why not FIX the bugs

[BCW2]

You could say the same thing about MS. Some of the Win bugs have been around since 95. Will they ever get fixed?

Re:Why not FIX the bugs

[tao]

They have been doing that as well. Or at least provided really helpful bug reports to the LKML.

confusing

[sad_]

but if all commercial software contains 30 bugs every 1000 lines, does their analysing tool also contain these amount of bugs? they could have debuged it with their own program, ofcourse that first version checking itself would have had bugs of its own that it would not detect because of the bugs. so how do we know that the result is not bugged? this is too complicated and unreliable!

also, since their software is commercial does that mean that the linux kernel has less bugs then their own software? :P

Linux Has Fewer Bugs Than *One* Rival

[MavEtJu]

That's only compared to WindowsXP.

How about comparing it with MacOS/X, FreeBSD and others?

A shame for today's TWO vulnerabilities

[diegocgteleline.es]

It's a real shame that such new was published the same day than
Isec's Two vulnerabilities that were published today.

It makes one think "It's not that good"

Re:A shame for today's TWO vulnerabilities

[The MESMERIC]

so two vulnerabilities were found and reported.
is that so bad?

how many does Microsoft Windows have that we have no clue about - and because it is closed source we never will.

of course "not that good" will be valid if it takes them a long time to fix/patch this.

In Related News

[TheGorilla]

It was recently discovered that Microsoft attempted to patent software bugs, in an attempt to force all other buggy software off the market.

Ballmer was stated saying, "Microsoft has been the first and lead developer of Operating System Bugs since the early 90s. We feel it's about time."

This reminds of the simpsons episode...

[comrade009]

the one with powersauce. Where they have a powersauce news cast with special updats on power sauce.

"breaking news: power sauce is great!"

compare that with:

"breaking news: linux has fewer bugs!"

Why OSS is better

[Phragmen-Lindelof]

From the ACM paper "bugs as deviant behavior", we find
"We demonstrate that the approach works well on complex, real code by using it to find hundreds of errors in the Linux and OpenBSD operating systems. Many of our bugs have resulted in kernel patches."
This paper appeared in 2001 and represents the work of several researchers, some of whom were PhD students in CS. Some of them went on to form a private company (Coverity ) which plans to offer (for pay, of course) the use of their software to companies. It would be possible for Sun to use this software to look for errors in Solaris. However, the fact that the source codes for Linux and BSD were freely available allowed these researchers to test their prototype code and to submit bug reports years before Sun or MS had the option of using the tools developed by this group. Who knows what other groups of CS students or faculty are doing the same type of exercise right now; they may develop tools which will help private companies someday while using OSS to test their code now. (By the way, you might ask why such a group might help OSS projects. The answer is illustrated in the quote above; this company can already claim credit for finding bugs for which kernel patches have been released. You cannot buy better PR than this.)

Based upon those figures...

[Nybble's Byte]

Commercial software has 115 to 174 times as many bugs as Linux 2.6 on a percentage basis. So that means they have to work that many times as hard spreading FUD that Linux isn't ready for the enterprise.

Why deal with code at all?

[shish]

It'd be much easier to count the bug reports that apply to a given version of each OS, and divide by the published line count...

Wow, how did they determine this number?

[wealthychef]

I am very suspicious of this story, although I'm inclined to qualitatively believe it and I certainly think MS makes crappy software. But, what constitutes a bug, and how were they able to find them? How do they know they didn't miss any? And if they don't know that, then how do they know their numbers are accurate? Sounds like a case of the facts flowing from a theory to me.

Is this really a study?

[Zephiris]

They apparently spent four years on this, but only produced numbers for the very latest version of the Linux kernel?

Why not compare it to older versions, from 2.1 to 2.6-test? Why didn't they even mention if the number of bugs has been falling or rising with that? Presumably it'd be lower in 2.4.21 than the latest 2.6.x considering that 2.6.x has suddenly become more or less a development kernel for the time being, but they don't seem to've substantiated that at all.

But even so, all of that aside, what did they compare it against that wasn't Linux? They seem to've just used guesstimation numbers. They didn't use Windows source code to check against. They didn't check against other Open Source projects. If they spent years of time on this, wouldn't it have been interesting for them to compare against the *BSDs, or even FreeDOS?

If it were really, actually, a study, there should've been a lot of competing and baseline data to compare against. Otherwise, it just seems like a thinly veiled 'PR spin' attempt to get more people on the fence to use Linux.

SecurityFocus doesn't agree

[Anonymous Coward]

http://www.securityfocus.com/bid/11864/info/, along with the other 59 other Linux Kernel security vulnerabilities reported this year seem to indicate otherwise. Check out http://www.securityfocus.com/ and choose Linux as the vendor.

Only because

[Brandybuck]

These results are ONLY because Linux does not have a SQA department. The software is released to an unsuspecting public with the unwritten assumption that THEY will do all the testing. Since most users would rather use than test, fewer bugs get reported than in commercial software where there are entire teams of professionals looking for bugs.

A commercial product I worked on last year required nine months of testing for an UPDATE release. On the other hand, your typical Linux release gets zero hours and zero minutes of non-developer testing before it gets released upon the public. And from what I can tell of the commercial distros, very little additional testing is done before being sent to the end user.

Frankly, it's amazing it isn't a complete pile of festering bits.

Can you say?

[SI285]

Can you say "propaganda"?

Re:If they use a unified method across the board..

[DunbarTheInept]

It matters because it is false to assume that bugs found is a representative percentage of bugs existing. If bugs of type A are more common in one system, and bugs of type B are more common in the other, and your test tends to find a larger percentage of the type A bugs than the type B bugs, then you get an incorrect skewed result when comparing the two.

Let's compare shall we?

[Anonymous Coward]

You are talking about the linux kernel vs the entire code base for windows XP. Gee I wonder why there are so many more lines of code. I don't think we can get just the kernel for windows. Anyway lets compare apples to apples. Take the complete CD set for for linux lets say RH enterprise server vs windows 2003 server.

RH you get 101 security advisories in 1 year. http://secunia.com/product/2535/

With windows 2003 you get 36 in 1 year. http://secunia.com/product/1173/

OK so lets get back to the kernel of linux and security advisories. They have noted in 1 year 27 exploits. http://secunia.com/product/2719/

hmm Honest numbers and it looks like windows is kicking butt.

They do

[Numtek]

Imagine if Microsoft owned a tech news site that posted nothing but anti-Linux articles?

Ever heard of msn.com?

http://security.msn.com/

I said -pedantic gives warnings.

[Inoshiro]

From the manpage:
-pedantic
Issue all the warnings demanded by strict ISO C and ISO C++; reject all programs that use forbidden extensions, and some other programs that do not follow ISO C and ISO C++. For ISO C, follows the version of the ISO C standard specified by any -std option used.

-- That seems to be exactly what I described it as doing.

Now, you choosing to make standards un-conformance into a warning rather than an error is something else. (Old) C defines the default return type to be int, but C++ has it as undefined. Forcing it to a warning is not the way to solve that problem; you should've fixed the code, which is why g++ defaults to making the type checking as errors, instead of warnings.