Linked by Thom Holwerda on Tue 19th Jul 2005 19:23 UTC, submitted by Just_A_User
FreeBSD On Tuesday, code-analysis software maker Coverity announced that its automated bug finding tool had analyzed the community-built operating system FreeBSD and flagged 306 potential software flaws, or about one issue for every 4,000 lines of code. The low number of flaws found by the system underscores that FreeBSD's manual auditing by project members has reduced the vulnerabilities in the operating system, said Seth Hallem, CEO of Coverity.
Thread beginning with comment 6631
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: FreeBSD beat Linux 2.6.9
by renox on Wed 20th Jul 2005 05:20 UTC in reply to "RE[2]: FreeBSD beat Linux 2.6.9"
Member since:

>An example of code bloat in Linux (which is just a kernel, compared to the full operating system that is FreeBSD)?

Or an effect of the higher number of drivers available in the Linux kernel?

If this is the case, it really show the power of Linux..

Reply Parent Score: 1

RE[4]: FreeBSD beat Linux 2.6.9
by on Wed 20th Jul 2005 06:42 in reply to "RE[3]: FreeBSD beat Linux 2.6.9"
Member since:


Ok, so AIX has a higher number of statically checked possible bugs than the reported number for BSD and the Linux kernel. How in the hell can you state that AIX or anything else that IBM does is representative of all proprietary software?

AIX and what IBM produces and the very few places you've worked STILL aren't enough of a dataset to be meaningful except to compare what AIX and IBM's work is compared to the stuff cited with these checks on the BSD and Linux kernel. As hard as it is to believe, there are actually proprietary software solutions that will be at a higher level of perfection than what you've measured, even though what you're using as a measuring stick is from IBM. And I mention once again, there's a hell of a lot of open source stuff that has simply not been measured, because it is so limited and/or crappy that nobody gives a crap that it exists, and thus, the statistics mean nothing, except for comparing AIX and that bit of stuff to BSD or Linux kernels and what they've measured. Your attempt at proving your point fails the test of logic, still, to put forth a "proof" of which is higher quality: OSS or proprietary code, because you're working with an incredibly limited set of data, compared to what exists in the wild.

Reply Parent Score: 0

butters Member since:

The basis of my comparison is that both codebases (FreeBSD and AIX) are UNIX-like kernel/userland systems. I could not possibly provide evidence to suggest that proprietary software is in general buggier than open source software if you are holding me to this standard of proof. What I can say is that there are only so many major proprietary UNIX systems in active development today. I would go so far as to say that the only remaining ones are AIX and HPUX, since Solaris has already been extensively prepared for open sourcing. Therefore, comparing FreeBSD to AIX is a fair and representative comparison of open source and proprietary UNIX-like operating systems. I would imagine that HPUX would be on par with AIX at best, especially given HP's commitment to their enterprise UNIX business.

The impact of static analysis on open source software is huge, and the simple reason is: these projects cannot afford to execute large-scale runtime integration, functional verification, and stress testing. Static analysis is extremely cheap in comparison. For proprietary purposes, static anaylsis is just one more item in the QA toolbox. I'm aware of two customer-reported failures in the past 5 years that could have been avoided if IBM had used static anaylsis on those releases of AIX (both resulting from an uninitialized variable). IBM finds nearly every conceivable problem in runtime testing regardless of static analysis. Without access to powerful parallel testing labs, open source projects must embrace static analysis, which is why they eliminate so many of these kinds of errors (and why proprietary development teams can often afford not to care).

Reply Parent Score: 1