Submitted by Between December 2004 and July 2005, the “defect density” in the Linux kernel has fallen from 0.17 to 0.16 and all serious defects have been corrected, a new report out from code analysis firm Coverity asserts. Defect density declined by 2.2 percent.
This is just another reason why the Open Source philosophy of “many eyes” is superior to Closed Source programming. No matter how many bugs/glitches/errors may lurk in coding, someone will find it, sooner or later. I just wish more companies would follow this route (Novell’s move with OpenSUSE is a good example). 🙂
I just wish more companies would follow this route (Novell’s move with OpenSUSE is a good example). 🙂
Such a interaction can benefit both company and OSS.Development cycles can decrease and most end-users have a better chance of getting newer more advanced features
sooner.
For the ones who still think MS takes security serious and reacts adequately to new threads have a look at this one:A vulnerability in default installations of the affected software that allows malicious code to be executed with minimal user interaction.(remotely)
Affected:win2000,XP,win2003
http://www.eeye.com/html/research/upcoming/20050329.html
MS has been informed in March and is now 68 days overdue.
I would say that’s a genuine advantage (not).I have never experienced such an overdue with any Linux distro and *BSD.
Alright … now let’s analyze the BSD codebases …
Oh, what’s that? Linux just put its foot in its mouth? Pity.
Care to state your sources ?
Sure. Go read about the BSD development model and attitude. Now contrast it to Linux.
Linux: Let’s get something marginally functional/stable out there, then fix the bugs later. (Any software engineer knows that there is nothing more permanent than a temporary stop-gap)
BSD: Let’s work on this until we get it right, then we’ll release it.
A quality quote from Ted T’so, senior Linux kernel dev:
Not all 2.6.x kernels will be good; but if we do releases every 1 or 2 weeks, some of them *will* be good.
That, my friend, is ridiculous. WTF kind of a professional development attitude is that? It doesn’t take a university degree in computer science to realize that the major contrast in attitudes between these two camps results in a much cleaner and stable code base for one camp, and less so for the other.
Take a look at the FreeBSD handbook. Take a look at http://www.over-yonder.net/~fullermd/rants/bsd4linux/bsd4linux1.php — and read all of it. You’ll have a much deeper understanding of the entire BSD dev process and why it is ultimately superior to the Linux mish-mash process.
Um… Yeah, thats why BSD is so much more popular than Linux… On wait, thats right, it isnt… Idiot!!!
Linux popularity can be attributed purely to hype, and not technological superiority.
As for defects counts … yes, they are complete bullshit, but code quality can still be examined and given a “rating”. Defect counts are not that rating. Considering the fact that the Linux kernel itself has about 4x as many lines of code as the entire FreeBSD operating system, which makes use of a lot of GNU code, a slightly higher defect count is acceptable, regardless of who’s count you’re going by.
Either way, Linux is poo, and BSD is gold.
OS X is pretty cool too. Windows is good for games and a few other things. That’s my verdict.
Not too long ago there was a similar article posted here on FreeBSD. Coverity found it had 1 bug in every 4000 lines of code, or a “defect density” of 0.25. Considering this is higher than Linux’s rating of 0.16, tell us again which is superior?
Visors down, pilot lights ignited
1. If they can be so readily correctly counted (easier said than done: “That’s not a bug, that’s a feature!”) then why on earth are they released knowing they exist?
2. Once (hopefully) the past “Defects” are determined and corrected, how can you be 100% certain that new ones aren’t introduced? Most realistic answer: you can’t! You might “fix” many defects, but you may create at least one or perhaps more defects than existed in the first place! It seems most likely, though, that those new and improved bugs won’t be counted amongst the statistics when touting “Look how well we did with the ‘many eyes and many hands’ method!” when it comes to that current release. Because, once again, going back to point #1, first you have to know what defines a defect/bug/etc. before you can count it correctly, and if you can do that in the first place, why on earth is it released that way?
3. What points #1 and #2 are saying is that all these “defect count” metrics indicate is that a certain number of things have aroused the attention of someone/something looking at a code base at some particular point in time and were labeled as defects. By no means does it translate to a 100% correct assessment of that code base, because it is a metric based on perception, and not every tool or developer will fully perceive what is right/wrong compared to the specifications of what the software is supposed to actually do.
4. Certain defects are easier to detect than others. For example, accessing past the end of an array that has a known size by a flaw in a loop that has that information available, but doesn’t use it. However, you can have perfectly “Stable” code in terms of not reading/writing outside of what it is supposed to access and that doesn’t use stale pointers that is still distinctly a bug, because it creates results that are incorrect in some manner. These are the sorts of things that are most likely not going to be properly accounted for in these silly “Defect” metrics that are easily collected.
5. What point #4 is saying is that likely these are simply silly pissing contests because even though people may count things, what they may count may be severely undercounting the number of defects, because the people doing the counting don’t have 100% understanding of #1
…on how YOU define “defect”…
Coverity Prevent is a static checker. It is programmed to look for patterns and make should that they comply with particular rules. For example, a rule could be: “before accessing kernel data structure x, acquire lock v.” This makes it better than more simplistic tools such as Lint, which primarily detect the big three (uninitialized variables, null pointer deferences, and out-of-bounds array accesses) plus slews of stylistic complaints.
The inherent theory behind a checker is that it can only look for what it is programmed to look for. It does not in any way provide assurance that the “defects” it finds are the only problems. This can only be done with a verifier, which uses a system of code annotation to explain to the tool what the code is doing, so that the tool can verify that the code is really doing what is intended. The problem with verification is that it requires a lot of work to annotate the code, and this process can only be done well by a developer who really knows the code.
In the end there is no substitute for human code review, but static analysis can filter quite a bit of problems beforehand, and the use of such tools as a part of the development process has also been shown to improve coding style. If the checker complains about checking for null where you are pretty sure that the pointer in question will never be null, it is easy to just put the check in and have the complaint go away. In the long run, this is good style because later on someone can change some other code that might allow for that pointer to become null.
As far as human code review goes, there are two forms: static code review and runtime functional verification. The BSDs use a more thorough static code review process than does Linux. However, Linux not only has “more eyes on the code,” it has tons more real world testing going on. People are running Linux in all sorts of weird configurations in large numbers. Any problems are usually discovered and reported quickly. Coincidentally, it is usually the types of bugs rooted out by static checkers (particularly uninitialized variables) that are more likely to crop up later in the product lifetime.
A new movement to bring BSD to the desktop seems to be starting, given the relatively recent releases PC-BSD and others. This is good, because it opens up a wider audience for BSD. I hope the hardware support can catch up to Linux, or else the desktop BSD movement might be limited. Also, BSD has no catch up to Linux on low latency process scheduling and other features that make Linux appealing on the desktop.
Finally, Windows sucks for games. It just happens to be that many games are written only for Windows. DirectX sucks for developing games that perform well or have innovative features. Most of the “big titles” for PC gaming are written in OpenGL for this reason. DirectX is really only “good enough” for console gaming. With Linux, game developers can produce Live Game CDs/DVDs that boot to an environment (possibly including a tweaked kernel) specifically tuned for that game. Windows can’t really do that (are there any Windows LiveCDs that can even compare to those widely available for Linux?).
You have proof of DX sucking where, exactly? And I have no idea where you got the idea that most titles are OpenGL … Doom 3 comes to mind. That’s about it.
Half-Life 2
UT 2003/2004 (and the upcoming 2006)
Splinter Cell: Chaos Theory
Far Cry
Age of Empires 3
Band of Brothers
…
Are all DirectX. Say again?
PS: What’s this about Linux Live Game CDs? LOL Until a distro boots to a perfectly-configured, non-bloated desktop with full 3D/sound/networking/input support, that suggestion is a crock of shit. Typical Linux requires at least 2-3 hours of tweaking to get working with all of the hardware in a typical gaming PC. Having to do that every time you boot? No thanks.
Gentoo has a UT2003 GameCD as well as a couple others. The technology is there. The only thing possibly lacking is high-quality graphics drivers, and the latest nVidia drivers for Linux are getting decent. How’s 3D acceleration on *BSD?
“LOL Until a distro boots to a perfectly-configured, non-bloated desktop with full 3D/sound/networking/input support, that suggestion is a crock of shit.”
There are tens of LiveCDs that satisfy these requirements. I don’t know of any Linux LiveCDs that don’t automatically configure sound, networking, and especially input devices. Most newer LiveCDs (2.6.x kernel by default) will configure 3D acceleration if you have an nVidia card. Not sure if FreeSBIE (a FreeBSD LiveCD) does 3D acceleration.
I thought that UT200* was OpenGL. I was wrong. Half Life was OpenGL, not sure about Half Life 2. DirectX sucks because: 1) horrible texture rendering compared to OpenGL, 2) slower than OpenGL, and 3) only 3D toolkit for PC gaming that is not cross platform.
As a newbie to Linux I been wanting to ask, isn’t BSD Linux? If not, what makes it different? I read so much about it’s “better security” but have yet to find out what exactly makes it so much more secure? I’m using Ubuntu now, but PCBSD has sparked my interest. Thanks to anyone that replies.
You should read this: http://www.over-yonder.net/~fullermd/rants/bsd4linux/bsd4linux1.php — It talks about the philosophical/substantial differences in great detail.
Generally, BSD is regarded as the “true”/”professional” UNIX/UNIX-like operating system, whereas Linux is just a kernel with a mish-mash of GNU software, which is in turn called a “distribution”. BSD has been around for longer than Linux, and is a direct descendant of the original UNIX, whereas Linux is a re-written clone.
“As a newbie to Linux I been wanting to ask, isn’t BSD Linux? If not, what makes it different? I read so much about it’s “better security” but have yet to find out what exactly makes it so much more secure?”
First, don’t listen to obvious trolls like “Linux is poo.”
BSD is not Linux, although they share a good deal of GNU software. The key differentiating feature is that none of the BSDs use the Linux kernel. The other main difference is that BSD has “variants”, which should not be confused with Linux “distributions.” OpenBSD, FreeBSD, NetBSD, and Dragonfly BSD all use significantly different kernels that are not interchangeable. For the most part, any Linux distribution can use a kernel from another Linux distribution. The Linux kernel supports a great deal more hardware devices, filesystems, and architectures than the BSDs, although I should note that NetBSD is perhaps the most portable OS on the planet and supports more architectures than Linux ever will.
The BSDs are open source (i.e. you can download the source code, modify it, redistribute it, etc.), but they employ a closed development model. There is a team of developers than work on the kernel and userspace, and for the most part the public is not invited the participate beyond reporting bugs. This is in contrast to the Linux kernel development process, where anyone is free to submit a patch for consideration by a team of trusted “lieutenents” and Linus–and also in contrast to an open or democratic development model employed by several community distributions including Debian, Gentoo, Fedora, and possibly OpenSuSE.
It is hard to compare the relative security of BSD or Linux, because the first line of defense in operating a secure machine is always the user. Security for the majority of users depends highly on the chosen defaults. If you care about security above all else, I wholeheartedly recommend OpenBSD, which has experienced only 1 remotely exploitable vulnerability in over 8 years–in the default install. In other words, don’t expect to have everything you need in the default install. From the perspective of the desktop user, it is fair to say that any security delta between Linux and BSD operating systems is completely insignificant. From the perspective of a server sysadmin, it is more important to know how to properly secure whatever OS you choose than to install one that is touted as more secure, but that you are relatively unfamiliar.
PC-BSD has some very interesting concepts, such as those .pbi binary packages and a nicely configured KDE desktop (if you like KDE, being an Ubuntu user). The era of BSD on the desktop is in its infancy, whereas the era of Linux on the desktop is starting college this fall. The beauty of opensource is that the same desktop technology developed for desktop Linux can be leveraged on BSD, and this is just beginning.
The most fundamental ongoing difference between BSD and commercial OS’s vs. Linux is the differnce between “intelligent design” vs. evolution. The former group of folks just can’t believe that randomness (“trial and error”) will outperform something that a smart bunch of developers have carefully thought out. Yet if you believe in Darwin’s theory of evolution, (as opposed to the religious right who talk of creationism) you know that such randomness of genetics has led to the present diversity of living organisms and no intelligent design was necessary.
No. No LiveCD has satisfied these requirements on my gaming box at home — which has pretty standard hardware (the Audigy 2 ZS with 5.1 speaker system and Radeon X800 XT Platinum Edition are the cause of problems). If I can’t get 3D video or sound, then the “Live Gaming CD” is pretty useless, isn’t it?
1. Explain. Textures look perfect in any D3D game.
2. Depends on the video card. Most ATI cards tend to do better with DX9 games, most NVIDIA cards tend to do better with OpenGL games.
3. Like anyone but Linux users care.
“Generally, BSD is regarded as the “true”/”professional” UNIX/UNIX-like operating system,”
“BSD has been around for longer than Linux, and is a direct descendant of the original UNIX,
Didn’t the BSD community remove all the UNIX code as part of its settlement back in the early nineties? How can it be a direct descendant if it contains none of the original code?
Generally, BSD is regarded as the “true”/”professional” UNIX/UNIX-like operating system, whereas Linux is just a kernel with a mish-mash of GNU software, which is in turn called a “distribution”. BSD has been around for longer than Linux, and is a direct descendant of the original UNIX, whereas Linux is a re-written clone.
BSD is no more UNIX than GNU/Linux is, it may even be less UNIX-like do to less support for the POSIX family of standards than a typical GNU/Linux system. Most of the people who commit changes to Linux are paid to do so, not true for any BSD. None of the Open Source BSD projects predate Linux.
Much appreciated info from the both of you. That was a really long read, but I think I have the gist of it. I may throw a pc together to try it out. I’ve been using Ubuntu for a few months and I like it’s ease of use, however BSD caught my attention due to all the security talk. I consider myself competent enough to secure Windows and Linux machines, but this may just be my next challenge/headache. Thanks again.
You sound upset.. are you jealous that Linux is more popular than BSD or something?
I’m just pleased to have access to both technologies and have a clear understanding of the additional protections that apply to Linux.
Although UNIX was interesting back in the 70s, its a bit old and outdated now. There are many ways to do the same thing, some of them are better than others. If you never go look at the alternatives that exist out there how will you know you chose the right solution for your problem?
That’s the problem I see with BSD/*nix.. its not very diverse, yet it has the same set of compatibilities/dependency problems as everything else. Might as well experiment a lil if you’re writing blind, making drivers through trial and error because you have no documentation for the hardware like everyone else, etc, etc, etc.
Reality is very different than a clean room university environment, where there is a clear and simple solution for every problem. It gets a bit dirty out here and sometimes its more appropriate to provide a temporary solution to a problem than spend months/years engineering the university approved and certified quality of code for a small piece of the system that will end up being replaced by something better anyway..
Creativity, originality and innovation are at least as important as theory and political/academic correctness. How would we have ever learned anything if we stuck with the books? They teach us only what we already knew…
You could rewrite Emacs today, if you wanted, but the time you spent on it would not be very productive for the rest of the community who think that GNU Emacs or any other versions are “good enough”. That’s why we spend our time creating new things, adding features and fixing critical bugs instead of stabilizing and tuning a system that will end up being obsolete in 3 years without those features and innovation. Besides, if we spent all our time fixing bugs we’d run out of bugs to fix and that wouldn’t be very fun, would it?
last comment should have had the Subject @Linux is poo
Ask Dave Jones that from OLS, we’re regressing in 52% in the kernel and its due to kernel drivers!
Sorry, but we’re worse now than before.
Shawn.
Um… Yeah, thats why Linux is so much more popular than Windows… On wait, thats right, it isnt… Idiot!!!
BSD – very tightly coded, very good quality, highly secure, very poor driver support (imho). Coding process is almost pedantic in its method. Very slow development.
Linux – coding isn’t as good (quality wise), and it isn’t as secure. But – it supports a much wider range of hardware and options and features. This is important.
Take your pick.
Dave
as it should be and is…
OSS is better by design and philosophy.
try to get Windows to the level of solid code as OpenBSD.
won’t happen.
I guess its the fact that BSD has always touted their “more secure and cleaner” kernel code. It seems like linux is catching up. Linux already beats out BSD in the density dept. And it might match or even beat out BSD in the overall defects dept.
I guess its nice how the Linux security threads attract the BSD flies like mad. =)
Linux – coding isn’t as good (quality wise)
How will you know,are you a coder?,So lets talk..
, and it isn’t as secure.
You obviously like to generalize.You talk about BSD security with OpenBSD in mind and giving the credits indirectly to FreeBSD.Does FreeBSD have a “hardened” variant?Does FreeBSD have something equivalent to PAX,grsecurity,RSBAC?
Talking about *BSD,which one?
Talking about *linux,which one?
The #1 defect is that at every release all the kernel apis change, breaking all 3rd party stuff. That’s horrible. It makes great stress to companies trying to support Linux with their device drivers.