Weekly Edition
Return to the Development page
| |||||||||||||
Why Linux Is a Model Citizen of Quality Code (Linux.com)
Linux.com reports
on the latest defect statistics from Coverity. "With 6,849,378 lines
of Linux 2.6 code scanned, 4,261 outstanding defects were detected and
1,283 were fixed in 2011. The defect density of Linux 2.6 is .62, compared
to .20 for PHP 5.3 and .21 for PostgreSQL 9.1. Keep in mind that the
codebase for PHP 5.3 — 537,871 lines of code — is a fraction of that of
Linux 2.6, and PostgreSQL 9.1 has 1,105,634 lines of code."
(Log in to post comments)
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 0:01 UTC (Sat) by mgedmin (subscriber, #34497) [Link] I was surprised to learn that PHP code is higher quality than the Linux kernel and read the article to make sure I wasn't misinterpreting the meaning of defect density. Apparently it means more or less exactly what I thought it meant:"The analysis measures defect density, which is the number of defects per thousand lines of code. Code with an average defect density of equal to or less than 1.0 is considered high-quality, and the average for open source in the 2011 Scan was .45.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 0:18 UTC (Sat) by zlynx (subscriber, #2285) [Link]
PHP itself is rarely broken. It is the programs people write with it.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 2:00 UTC (Sat) by robert_s (subscriber, #42402) [Link]
Believe me, if you want to go blind, read the php source. My favourite example (that I can't find now) I saw was a function that purported to provide some thread safety routines but was totally broken.
This result doesn't do much for my confidence in Coverity's tools.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 2:36 UTC (Sat) by zlynx (subscriber, #2285) [Link]
I suppose I never, ever considered writing a multithreaded program with PHP.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 3:29 UTC (Sat) by imgx64 (guest, #78590) [Link] To be fair, lots of developers can't do multi-threaded programming. But the PHP developers get confused even on trivial things like end of line and indentation. Check this gem:
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 26, 2012 3:32 UTC (Sun) by k8to (subscriber, #15413) [Link]
As a bonus, the choice of newline for os x is wrong.
LOL Posted Feb 27, 2012 11:42 UTC (Mon) by cortana (subscriber, #24596) [Link]
I guess no one noticed because __MacOSX__ is not defined by any compiler. You're supposed to test for __APPLE__ & __MACH__ to detect Mac OS X.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 7:26 UTC (Sat) by k8to (subscriber, #15413) [Link]
Coverity helps almost not at all for concurrency problems.
It can help identify cases where you don't lock when you should (by showing that all the other users of a thing acquire a lock). It can show you when you seem to be holding a lock when others release it. It can't do much for any more complex concurrency errors at all. It really doesn't even try.
You can *write* checkers for coverity that try to do things that are more sophisticated, but typically they have to be somewhat heuristic for your own local set of problems. And the going is rough, because the documentation is rather thin on the ground. Really, having the source would probably be more helpful than the documentation which currently exists.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 12:03 UTC (Sat) by robert_s (subscriber, #42402) [Link]
I wasn't specifically talking about concurrency - it was just a great example which showed php developers not quite getting the point.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 10:15 UTC (Sat) by job (guest, #670) [Link]
That's a bold statement to make no more than three weeks after the latest remote execution vulnerability in PHP itself.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 14:51 UTC (Sat) by jmspeex (subscriber, #51639) [Link]
Keep in mind that a piece of software like PHP is almost entirely "exposed" to malicious input, i.e. you have to protect everything. For Linux OTOH, only a very small fraction of the code can lead to remote exploits if buggy. That's also why we see more local exploits than remote exploits. There's just more code that a local process can trigger compared to a remote attacker.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 27, 2012 21:59 UTC (Mon) by philh (subscriber, #14797) [Link]
Which for some reason still doesn't provoke the geniuses that write this stuff to think that taint mode might be a good idea.
Blaming the majority of (worthless) programmers that use PHP for the excrement they produce rather misses the point that the authors of PHP provide a machine shotgun with no safety catch, and are upset if you ask them to deactivate the laser guided foot detecting targeting system.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 0:29 UTC (Sat) by kugel (subscriber, #70540) [Link]
Doesn't that actually mean linux is not only worse than PHP, it's also below average? Doesn't sound too compelling to me.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 0:44 UTC (Sat) by elanthis (guest, #6227) [Link]
One has to keep in mind that "Linux" also has more parts and is written for more use cases.
Every user of PHP is going to make use of a very large amount of the code in PHP. Those parts are designed by idiots who should never have been allowed to design a language, but they do work and do what is advertised (even if what is advertised are idiotic features like identifiers being treated as strings, a complete lack of UTF support, no type tagging despite that being such a ridiculously huge boon to security in apps that deal with so much hostile user input, etc.).
Every user of Linux uses a tiny fraction of the amount of code in Linux. A ton of the less frequently used drivers are complete and utter trash. Even some of the mildly frequently used drivers only barely function adequately (the xbox gamepad driver is my current least favorite driver in Linux, for instance; total garbage).
It is likely that the core frequently-used code paths in Linux are of very high quality. The umpteen billion random drivers that are (foolishly, IMO) shipped in-tree bloat Linux's code and its defect density, all for no really good reason (easier for devs to fail to design a sane API which every other OS has proved is more than feasible to do, hostile to users who need to upgrade or use hardware without wanting to install a whole new OS every six months, and the Linux guys claim those are "features").
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 3:30 UTC (Sat) by tialaramex (subscriber, #21167) [Link]
“fail to design a sane API which every other OS has proved is more than feasible to do”
There are basically three ways this can go, and "every other OS" has provided us with examples of all three between them.
1. Everything is possible, but nothing performs well. So you can use this OS and its lovely sane API, but sadly you will spend a ridiculous amount of money on hardware to overcome the miserable price-performance ratio.
2. The things people did 5 years ago perform well, nothing more recent is supported by the API. Assuming your hardware isn't five years old, this means every driver you run replaces most of the core OS features in a desperate attempt to kludge support for things less than five years old. And just to make things worse, instead of being able to /see/ the mess publicly it's now all in C:\temp\My First Driver\ on one guy's hard disk in Taiwan.
3. Same cause as (2) but instead of nasty hacks in drivers, you put the nasty hacks in the hardware. Now anyone who runs Linux has to put up with the fact that your foozle inputs go through the bazinga controller, or your high resolution mimbler appears as sixteen different mimblers all named "0000" rather than a single mimbler to work around a deficiency in that "sane" API on the other OS..
Have you actually worked with these "sane" APIs, or just admired them from afar?
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 5:46 UTC (Sat) by cwillu (subscriber, #67268) [Link]
The backwards compatibility of the linux kernel is legendary. It's not at all unusual to install the very latest kernel on against a 5 year old userspace and have everything just work (including the new drivers).
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 12:26 UTC (Sat) by gerdesj (subscriber, #5446) [Link]
Agreed - I've done it. Also you can dust down some pretty ancient peripherals and expect them to work when plugged in when other OSs "deprecate" them on a whim.
I gained a new printer when Vista came out and rendered it unusable for the owner. ... and a scanner from someone else.
Cheers
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 28, 2012 17:06 UTC (Tue) by Cato (subscriber, #7643) [Link]
Unfortunately the userland support for printing in Linux is not so backward compatible.
Linux Mint 11 (based on Ubuntu Natty 11.04) has broken printing to an HP G85 - the same PC ran an older CUPS version on Ubuntu 8.04 and 10.04 without problems. I did compile the latest CUPS version on Mint 11, but that still doesn't work with this printer, which is rather old but very reliable.
So I'm planning to install Ubuntu 8.04 in a chroot under Linux Mint, just to run the CUPS daemon that works... Painful but probably easier than installing an older CUPS version, and it should continue to work with the same chroot on a newer Linux Mint version.
Suggestions for a more sane fix welcome of course.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 12:56 UTC (Sat) by khim (subscriber, #9252) [Link] Easier for devs to fail to design a sane API which every other OS has proved is more than feasible to do, hostile to users who need to upgrade or use hardware without wanting to install a whole new OS every six months, and the Linux guys claim those are "features". Bullshit. "Every other OS" proved that what Linux developers are doing is the right thing. Sure, "every other OS" promises stable driver API - yet this promise is rarely fulfilled. I've seen enough cases where drivers are broken not just by switch to other version of OS, but by installation of service pack. I don't know why it's so hard to invent stable driver API, but the fact that "every other OS" fails to do that in practice justifies Linux's approach. Contrast it with userspace API where backward compatibility is not just desired, but actually delivered on most OSes (including Linux kernel - but, sadly, not Linux Desktop). And no, I don't know just why drivers API is so different. I just know that it is different - there are enough experiments to consider this well-established fact. Windows, MacOS, Solaris, etc - they all fail at that quite spectacularly. After each "revolution" their developers say "well, this is the last time we've broken driver's model and forced users to abandon theirs hardware" - and few years later invariably "last time" becomes "next to last time".
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 26, 2012 4:30 UTC (Sun) by elanthis (guest, #6227) [Link]
> Bullshit. "Every other OS" proved that what Linux developers are doing is the right thing. Sure, "every other OS" promises stable driver API - yet this promise is rarely fulfilled.
Sigh. That is not true.
The "promise" is fulfilled just fine. I don't need to install a Windows 7 build from 2012-02-25 just to get hardware I bought a year after Win7 RTM to install and work.
> I've seen enough cases where drivers are broken not just by switch to other version of OS, but by installation of service pack.
And we've seen Linux break after an upgrade in the GCC version, or various apps breaks on glibc updates. When you write buggy code, even small "compatible" changes will break that code, because it depends on undefined or unspecified behavior that the API/specification/rules never promised to maintain.
The presence of a stable API doesn't stop Linux from preferring in-kernel drivers or even banning out-of-tree drivers legally. What the lack of a stable API stops, however, is the ability to take a driver that was written for Linux 2.6.30 and installing that on a distro that only ships Linux 2.6.18. In many cases there are no fundamental problems to compatibility between what the two APIs' design but rather just a large amount of s/foo/bar/g kinds of changes.
Again, this is not a "100% compatible in every conceivable way even for broken code that only worked in the first place by pure chance." As an engineer I would never advocate that.
What I do advocate is that code which follows the rules should not be broken because the rules are being changed every week. Give me a manual, and if I follow the rules in that manual, my code should keep on working until the next major scheduled well-advertised sufficiently-infrequent deprecation point.
> After each "revolution" their developers say "well, this is the last time we've broken driver's model and forced users to abandon theirs hardware" - and few years later invariably "last time" becomes "next to last time".
Breaking the API every major release (separated by multiple years) is one thing. Breaking it every other week is completely different.
I have absolutely no desire to ask Linux to load drivers that are 12 years old. There are clearly going to be deprecations, transition periods, and major API revisions.
I do have a desire to make sure that I can use CentOS 6 (or some other "LTS" distro, your choice) with a piece of hardware which requires a driver that only exists on the very latest kernel version. Even if the age difference in kernel versions is not that large it's still likely broken.
There is nothing preventing a stable API at all, aside from some of the kernel's core developers being silly.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 26, 2012 7:39 UTC (Sun) by slashdot (guest, #22014) [Link]
Uh?
A stable API will either prevent improving the kernel, or result in a large amount of performance-destroying and maintenance-nightmare compatibility layers to convert between the old and new APIs.
A stable ABI is even more problematic, and will also kill performance, since among others it prevents function inlining.
On other OSes, performance and maintainability of the kernel is severely impaired by the inability to include cutting-edge techniques due to API stability, having to use bloated ABIs, and performance-killing translation layers.
If you compare the Linux kernel and Windows interfaces, you'll readily notice that Linux is far more elegant and efficient.
In general, this is a non-issue because you can just upgrade to the latest kernel package as easily as installing a driver.
For CentOS on mission-critical hardware, RedHat backports drivers.
For random junk hardware, just upgrade to the latest Fedora kernel or use Fedora in the first place instead of CentOS.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 26, 2012 10:22 UTC (Sun) by khim (subscriber, #9252) [Link] The "promise" is fulfilled just fine. I don't need to install a Windows 7 build from 2012-02-25 just to get hardware I bought a year after Win7 RTM to install and work. Of course not! Windows 7 build from 2012-02-25 closes analogue is RHEL's kernel with bunch of backported stuff. This is usually backward compatible. Analogue of regular Linux build will be Windows 8 beta - and that beast requires new drivers just like in Linux case. And we've seen Linux break after an upgrade in the GCC version, or various apps breaks on glibc updates. When you write buggy code, even small "compatible" changes will break that code, because it depends on undefined or unspecified behavior that the API/specification/rules never promised to maintain. Sure, but if you can not fix the problem without source then what's the point? You can't use hardware - and that's it. What I do advocate is that code which follows the rules should not be broken because the rules are being changed every week. Give me a manual, and if I follow the rules in that manual, my code should keep on working until the next major scheduled well-advertised sufficiently-infrequent deprecation point. Why? WHat will it buy us? This is how RHEL is doing things - may be you should use that kernel, not upstream one? Breaking the API every major release (separated by multiple years) is one thing. Breaking it every other week is completely different. It's absolutely the same thing. Just one [minor] difference: Windows between-releases kernels are not available for general public. Linux between-releases kernels are. What you seek is produced by RedHat and included in RHEL. Just like in Windows world you need to pay money to get long-term support. There is nothing preventing a stable API at all, aside from some of the kernel's core developers being silly. Nope. Linux developer's model prevents this. Linux does not do releases spaced apart at years. It does releases spaced apart at months. Nothing prevents you from picking some releases and supporting them. Indeed, this is what RHEL is doing. Any other model will be a disaster because it'll require synchronisation beween kernel releases and LTS releases (and there are quite a few of them from different distributors). Will not work, sorry.
API/ABI Churn Considered Helpful Posted Feb 27, 2012 20:05 UTC (Mon) by dmarti (subscriber, #11625) [Link] If there were no technical reason for driver interface instability, somebody would have to invent one. One of my favorite pages about stable drivers is the about page for save-solaris.org. Relevant excerpt: "Currently Save-Solaris-x86.ORG is running Solaris 7 x86 while AMI (now LSI Logic) corrects problems with their driver under Solaris 8." A stable API/ABI would tempt more vendors into offering "stable" out of tree drivers. As long as a driver is like a squirrel (get into the tree or die) we can keep having hardware support that outlasts vendors' attention spans.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 27, 2012 23:48 UTC (Mon) by Karellen (subscriber, #67644) [Link] See dmarti's "technical reason" link below. From the linked documentation: You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree.
Stable userland API Posted Feb 28, 2012 17:12 UTC (Tue) by Cato (subscriber, #7643) [Link]
Having a stable user space API for Linux would be incredibly useful of course - I can run really old casual games on Windows XP and 7, or new top-end 3D games on XP or 7 (mostly), but installing even simple indie games from the Humble Bundle on Linux is a pain compared to just running them on Linux.
I know the answer is 'just use the package manager' but there are many out of distro applications that are not open source, such as games. Even the ones that are already ported to Linux (and showing real revenue for the developers) through the Humble Bundle are too hard to install... I have been using Linux for over a decade but when I want to play a game, I don't want to spend more time tinkering with the install than playing the game.
The 'tinkering to usage' ratio is also why I gave up playing Windows games via WINE - it's possible for some Steam games, but not the majority and requires a lot of tinkering (and I never got anti-aliasing to work) compared to simply rebooting into Windows XP and installing the latest patched games. I chose the hardware to have good stable 3D drivers etc for Linux, but it's still too hard.
Stable userland API Posted Feb 28, 2012 18:00 UTC (Tue) by dark (subscriber, #8483) [Link] Would it make sense to make a distribution that has this as an explicit goal? For example:
Stable userland API Posted Feb 28, 2012 19:01 UTC (Tue) by jedidiah (guest, #20319) [Link]
I run old Loki games with my current (but aged) version of Ubuntu. I also run anything else I can get my hands on like the Humble Stuff and Oil Rush.
Stable userland API Posted Feb 28, 2012 19:20 UTC (Tue) by dark (subscriber, #8483) [Link] Hmm I had trouble with the audio when I tried that. Stuttering followed by sudden death. I guess it might have been a driver bug, maybe I should try again.
Stable userland API Posted Feb 28, 2012 21:17 UTC (Tue) by Cato (subscriber, #7643) [Link]
Interesting idea - it might be good to do a gaming focused distro with a live DVD that includes some good free games. SuperGamer is a live Linux DVD that does something like this but it would be good to have a fork of a mainstream distro that's hard disk installable.
Stable userland API Posted Feb 28, 2012 18:14 UTC (Tue) by khim (subscriber, #9252) [Link] Linux has extremely stable user space API. I think you are talking about troubles with desktop GNU/Linux distributions but these are completely different beasts. I've already discussed it both years ago and recently. This is sad, really: there are people who create and support extremely robust foundation and there are people who are supposedly are trying to "win the battle for desktop", but somehow they refuse to even thing what's the goal of the desktop. Hint: it's not to drag pretty semi-transparent windows around. I don't want to spend more time tinkering with the install than playing the game. Yup, that's the problem #1 for Linux desktop. But it has nothing to do with Linux the kernel.
Stable userland API Posted Feb 28, 2012 18:59 UTC (Tue) by jedidiah (guest, #20319) [Link]
I have found exactly the opposite to be true. Running old games in Windows is problematic at best. Running older code in general is much more likely to work under Linux (or Unix in general). There's simply been less "churn" with regard to the guts of the system.
I'm better off running and older Windows game in a VM regardless of the host platform.
Stable userland API Posted Feb 28, 2012 20:37 UTC (Tue) by khim (subscriber, #9252) [Link] I have found exactly the opposite to be true. Running old games in Windows is problematic at best. Running older code in general is much more likely to work under Linux (or Unix in general). There's simply been less "churn" with regard to the guts of the system. This is also true and, surprisingly, there are no contradiction. On Windows you usually can run older games using few simple tricks, but if you are out of luck then often you really are out of luck. This is because guts are changing significantly but there are good compatibility layer. Situation with Linux is totally different: compatibility layer is not as needed because kernel has excellent compatibility, but because distributors usually ignore such problems completely almost nothing works out of the box, you need to tweak something practically for any old program.
Stable userland API Posted Feb 28, 2012 19:58 UTC (Tue) by mathstuf (subscriber, #69389) [Link]
I didn't find the HIB games too hard to install. I just set the install path to /mnt/games/root/$game and then launch them with HOME=/mnt/games/home so that everything is bundled up nicely. If the game ran right out of the directory it extracted to, I just dumped that into a /mnt/games/root subdirectory. I've managed to get all but a run (or are temperamental within a tiling window manager). The tarball and .run games seem to be much better behaved than anything else.
Stable userland API Posted Feb 28, 2012 21:13 UTC (Tue) by Cato (subscriber, #7643) [Link]
Perhaps the problem is that I was trying to run the HIB games on Ubuntu 8.04, but that's 7 years more recent than Windows XP which runs all the games fine. This illustrates the point that the "Desktop Linux distro" API changes more frequently than the Windows API (including DirectX etc which most games install themselves).
I have only had a few problems with really quite old games on Windows XP SP3 - Half Life from 1998 worked fine, as did Max Payne from 2001, with the only issue being that the latter broke Alt-Tab. Generally I can't think of a game (from about 30 major ones) that didn't install and run OK.
Stable userland API Posted Feb 28, 2012 21:26 UTC (Tue) by mathstuf (subscriber, #69389) [Link]
I remember trying to run my friend's copy of Magic Carpet on my Windows 98 SE machine (he had Windows 95) where it was unplayable because my machine was too fast :) .
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 26, 2012 10:02 UTC (Sun) by petegn (guest, #847) [Link]
Check the line count makes Linux far better than PHP .
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 26, 2012 14:34 UTC (Sun) by darktjm (guest, #19598) [Link]
Does this statement really mean what you think it means? What this statement does not provide is a definition of a defect. My understanding is that a "defect" is a hit from the Coverity static code analysis tool. In other words, it is a style check, only marginally more useful than verifying that indentation is correct. If it is more than that, these bugs should be reported instead of just counted, so that the number is zero (yes, I know they have reported in the past, and bugs were found/fixed, but again, just because something could be a bug doesn't mean it is a bug, and more importantly, just because it doesn't look like a bug doesn't make it correct).
It says nothing about whether or not the program actually does what it is supposed to (i.e., whether or not a bug actually exists). If there were a program which could do that, no more bugs would exist. Where is the comparison between the program's function and its specification? Where is its specification, for that matter, and where is the proof that the specification has no bugs? Even automated proof systems fail with anything but trivial specifications, mainly because non-trivial specifications are just as difficult to create and verify as the programs. This is especially true when dealing with the physical environment, as many real non-trivial programs must. Even programs and specifications with "no bugs" may have misfeatures or missing features which some would call a bug (for example, I consider the lack of adequate documentation to be a bug, and there's no way an automated checker could come up with a useful metric for that).
At least bug comparisons from public bug reporting systems are slightly more useful indicators, as they may show an actual disconnect between design and function. Of course even that is not an absolute metric, as bug reports are often private, wrong, duplicated, undiscovered, unreported, understated, overstated, or filed against unreleased or user-modified code.
In short, you should not be surprised that Coverity's statements of code quality seem inaccurate.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 26, 2012 17:46 UTC (Sun) by dps (subscriber, #5725) [Link]
In my (limited) experience of coverity's tool s a *lot* more than a simple style check. There are false positives and things it misses, some which are due to its inability to solve the halting problem. Soemthing bad happnenning may involve a flow path that is genuinely impossible but coverity's flow analysis engine cant prove that.
Unless I sm very much mistaken coverity is some academic research made commercial.
Let is suffice to say there were, and probably still are, some impressive tools from acaedmia based on similar techniques, which are not completely unrelated to formal methods. If you want an absolutely unambiguous specification and absolute proof then formal methods provide that, but be warned that trivial 5 line programs can take 10 pages of monograph.
The missing number is how well a typical commercial program does. The windows 7 number would be especially interesting.
Static Analysis vs Style Checkers Posted Feb 27, 2012 15:04 UTC (Mon) by gmatht (guest, #58961) [Link]
The fundamental difference between Static Analysis and a Style Checker is that static analysis actually understands the code and need not complain about violations of style that are actually safe. For example, a style checker may nag you about every use of an array on the stack when a static analysis tool would tell you about the one time you actually do read unbounded input into a fixed sized array on the stack.
Even though the CLang Static Analyzer is not nearly as mature as Coverity, it may give you an idea about what can be done with static analysis. They even have screenshots: http://clang-analyzer.llvm.org/
Static Analysis tools like Coverity and CLang SA generally don't check that the program does what it is meant to, but rather looks for obvious defects such as storing 61 bytes in a 60 byte array. So a low defect count doesn't mean that the program is correct (though it may suggest that it is well written and hence relatively reliable), while a non-zero defect count means that there are known and unfixed defects. In some sense the precise defect count is less interesting than the question "Why isn't the defect count zero?". I understand that the Coverity authors do frequently give the kernel authors the defect reports.
I think the answer has something to do with the kernel authors being unhappy with the number reports that they consider to be false positives. It is not like the vast majority of defects are in the staging drivers. (The defect per LOC in the staging drivers is less than double that in other areas of the kernel).
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 4:39 UTC (Sat) by slashdot (guest, #22014) [Link]
Maybe Linux source code is simply more dense?
They should probably use AST, IR or compiled .text (with -Os -fno-inline) size instead of lines of code.
Also, if they have ad-hoc checks for Linux, that's going to skew results too.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 7:36 UTC (Sat) by RogerOdle (subscriber, #60791) [Link]
An OS is not a purpose designed thing like an application. A programming language is orders of magnitude less complex. An OS can be as "high quality" as an application only in an embedded environment where is has a specific purpose and everything that is not essential can be eliminated. But then you are talking about and OS that is thousands of lines long and not millions of lines.
A general purpose OS is developed to meet the needs of many agendas. It invariably get designed by commitee which results in increased complexity size and bugs. It is amazing that the bug rates for Linux are as low as they are. You will never know what the actual bug rates for Windows or OSX are.
It isn't really fair to compare the bug rates for an OS to those of applications that are a fraction of the size. Bug rates do not scale linearly. Complexity does up unbelievably fast with size. Without computer based analysis, Linux would never achieve the low rates of bugs that it has. Humans could not achieve this without tools like coverity.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 8:19 UTC (Sat) by Pawlerson (guest, #74136) [Link]
There's older comparison available and Linux looks much better than NetBSD:
http://scan.coverity.com/rung1.html
Defects/KLOC: 0.127 vs 0.335
PHP result:
http://scan.coverity.com/rung2.html
Defects/KLOC: 0.004
Such low PHP result and Linux and NetBSD with much higher ones just prove what you said. There are also staging drivers in Linux that probably have big impact on the final numbers. Nothing to worry about.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 11:01 UTC (Sat) by mstefani (subscriber, #31644) [Link]
"older comparison"? I would rather call it "antediluvian"; the numbers for e.g. Wine didn't change in 5 years even though each biweekly developer version gets loaded into Coverity.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 25, 2012 13:31 UTC (Sat) by Pawlerson (guest, #74136) [Link]
It doesn't matter, because the point remains the same.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 26, 2012 21:16 UTC (Sun) by dmitrij.ledkov (subscriber, #63320) [Link]
http://www.coverity.com/library/pdf/coverity-scan-2011-op...
The linux kernel is sound, literary:
Php:
Postgres:
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 26, 2012 23:00 UTC (Sun) by fdr (subscriber, #57064) [Link]
I find the defects level in PG.Port interesting, and it would seem likely to me that there is something being not quite correctly analyzed there. libpgport are the system portability shims for Postgres, filling in missing operators for systems that do not support them, for example, a gettimeofday implementation for Windows. It also means that these functions are used all the time (incorrectness is likely to be noticed), and are not really an area of active development.
It's only 6000 lines of physical source lines, so just a few false positives would be enough.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 26, 2012 23:21 UTC (Sun) by RogerOdle (subscriber, #60791) [Link]
It is not unheard of for code that has to interface with Windows to raise alarms with code quality checking software. This has more to do with Microsoft's NIH problem with not complying with any standards (even their own). We all want our code to compile cleanly with all warnings and error checking turned on. This is not always possible so some times you just have to grin and bear it.
Microsoft is not alone in creating non-standard extensions to the programming language. Apple has done the same thing for years.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 27, 2012 6:05 UTC (Mon) by b7j0c (subscriber, #27559) [Link]
php has two unique and damning bugs it does not share with the kernel which cannot be discovered by coverity:
1. it exists
2. people use it
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 27, 2012 18:47 UTC (Mon) by flewellyn (subscriber, #5047) [Link]
I hardly see how that's a productive comment. PHP is useful for many people for many things.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 27, 2012 21:29 UTC (Mon) by ThinkRob (subscriber, #64513) [Link]
$LANGUAGE_THAT_THE_HIP_KIDS_HATE has two unique and damning bugs it does not share with the kernel which cannot be discovered by coverity:
1. it exists
2. people use it
--
See I can play that game with anything. There are a number of fairly accurate technical and organizational criticisms one could make of the PHP project. Saying that its flaws are that "it exists and people use it" might win "upvotes" on reddit or a similar self-congratulatory "social media" site, but is a fairly worthless comment to make on a technical site like LWN.
Personally my biggest gripe with PHP is *also* something that Coverity wouldn't cover: the core developers seem to take a "shoot first, ask questions later" approach when it comes to security and bug fixes. They have added (and later removed/patched/hacked around) a number of convenience features that later turned out to be such security nightmares that one can't help but think that they didn't consider the implications of them (register_globals is a prime example of this.) They have added serious regressions in point releases in the past (rasmus breaking crypt() is a popular example of this). That seems a little strange, since they *do* have a test suite and since you would expect regression tests to pick that sort of thing up... but it makes sense when you realize that each release ships with many, many failing unit tests. Finally, and perhaps most irritatingly, the standard libraries are poorly-organized with inconsistent parameter ordering, screwy naming conventions, and scores of "quirks" which make proper use quite a challenge.
So yes, there are plenty of reasons to criticize PHP. But you know what? There are also plenty of reasons to use it (I myself write a large amount of PHP on a regular basis.)
Still, I'll concede both of your points and acknowledge that PHP is "garbage" just as soon as someone provide a link to a bug-free language which is perfect for every type of application, has an all-encompassing standard library, and has flawless performance and support on every platform. Until then, PHP will remain just another tool: well-suited to some tasks and ill-suited to others.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 28, 2012 10:11 UTC (Tue) by dgm (subscriber, #49227) [Link] > a link to a bug-free language which is perfect for every type of application, has an all-encompassing standard library, and has flawless performance and support on every platform.Sorry, couldn't resist... I know, I know... I will be wearing the chicken all day.
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 28, 2012 15:00 UTC (Tue) by sorpigal (subscriber, #36106) [Link]
> well-suited to some tasks and ill-suited to others.
...and sadly misused so often it makes me want to weep.
To me the funny thing is that the OP implied that the Linux kernel doesn't exist and/or nobody uses it. He should have said something like "The two bugs in PHP that make it less secure than the Linux kernel are: (1) It exists, (2) people use it."
So now it's a hyperbolic security criticism of PHP and not a general attack. That's better, right?
Why Linux Is a Model Citizen of Quality Code (Linux.com) Posted Feb 27, 2012 15:47 UTC (Mon) by fuhchee (subscriber, #40059) [Link]
So if Linux doesn't win on the defect-density metric, invent a new one, defect-per-mass-squared where it does.
Nit with the article title Posted Feb 28, 2012 16:57 UTC (Tue) by thyrsus (subscriber, #21004) [Link]
I think the article is "Evidence of Linux Quality Code" and is worthwhile under that heading. An article about "Why" Linux has quality code would talk about the methods and culture that create that quality, which wasn't approached there.
|
|||||||||||||