Slashdot Mirror
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."
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.
/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.
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
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
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.
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
"Some things have to be believed to be seen." - Ralph Hodgson
Linux is a kernel. The problem is that this is comparing the linux kernel to all of windows XP
"It is a good divine that follows his own instructions" - Portia, The Merchant of Venice
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.
Developers: We can use your help.