Slashdot Mirror


Open Code Has Fewer Bugs

ganns.com writes "Reasoning, which sells automated software inspection services, scrutinized part of the code of Linux and five other operating systems, comparing the number and rate of programming defects. Specifically, Reasoning examined the TCP/IP stack and found fewer errors in Linux. 'The open-source implementation of TCP/IP in the Linux kernel clearly exhibits a higher code quality than commercial implementations in general-purpose operating systems,' the company said in a report released last week. Reasoning also compared the code with that used in two special-purpose networking products and found it superior to one of them."

86 of 330 comments (clear)

  1. Ooh baby by Anonymous Coward · · Score: 4, Funny

    But bugs are cool..does that make me a geek for using Redhat?

    1. Re:Ooh baby by Anonymous Coward · · Score: 4, Insightful

      Mmm, troll! Just what I always wanted.

      Let me tell you -why- I wouldn't choose any of the below that you've mentioned:

      1) Gentoo. Well, on principle I like the idea, but in practice it's a pain in the ass. Having to wait around for hours on end just to have the latest version of KDE compile isn't for everybody. On top of that, there's very little hardware detection, if any. The elitist response to this complaint, I suppose, would be that it's more "configurable" that way..well why not offer two installation modes, the configurable one and the sane, easy-to-use one? Seems like the despised Windows, MacOSX, and yes, even Redhat seem to have that working pretty well for the most part.

      2) Debian. I like the packaging system, but other than that there's no reason for me to use it. Redhat 8.0 installed in 20 minutes, and at that point I had a fully usable system. Sound worked, graphics worked, I didn't have to touch any configuration files. The last time I installed Debian I had to recompile the kernel for support for a number of pieces of hardware I had, and I never did get 3D acceleration working properly. If I wanted to use packages made in the last 1-2 years, I would have had to use the "unstable" packages. I wasn't really keen on that, when RedHat provided everything that I needed.

      3) FreeBSD. I have no problems with FreeBSD..my first webserver ran on it. I wouldn't use it for a desktop, however, which is my primary usage for a system, simply because it barely supports any of the hardware I have. If FreeBSD supported the same amount of hardware that Linux did, perhaps even with auto-detection similar to RedHat or Knoppix, I'd probably use it..and I bet a lot of other people would too.

      The wonderful thing about Linux distributions is that there are many of them. There's ones for people who want to spend their time messing with text files to get their hardware set up properly, there's distributions for people who just want a stable, fast operating system that they can get to work with quickly. Perhaps that does make me a "User," if by definition a "User" expects a certain amount of the work to be done by the operating system, and not themselves. In that case I'm proud I am a "User," as the prospect of being a "Real Geek" sounds monotonous and time-consuming.

    2. Re:Ooh baby by jiminim · · Score: 2, Informative

      >RedHat includes an option to individually select which packages are installed.

      Once upon a time I installed RedHat 7.3 with absolutely NOTHING selected. It still wanted to install 400MB of random stuff...

      So I did switch to Gentoo because I know pretty much everything that is installed.

  2. Hmmm... by Craig+Maloney · · Score: 3, Funny

    I guess it stands to Reasoning that more developers hammering on code leads to fewer bugs. :)

    1. Re:Hmmm... by Anonymous Coward · · Score: 2, Insightful

      i think the enjoyment is also important.

      take 2 people that have the same skills, one enjoys a complicated task, the other does not. more than likely the result will be better by the person enjoys it, because they will show more care.

    2. Re:Hmmm... by cyb97 · · Score: 2, Insightful

      Depends on how the source-tree is managed...
      Too many cooks spoil the broth!

    3. Re:Hmmm... by Tony-A · · Score: 3, Funny

      No, too many cooks fork the broth.
      This begets competition, back-porting, and maybe even eventual convergence.

    4. Re:Hmmm... by scott1853 · · Score: 3, Insightful

      Not just that, but anybody will tend to produce a higher quality product when they aren't being badgered to meet deadlines and being dragged into meetings every other day.

    5. Re:Hmmm... by Ooblek · · Score: 2, Interesting
      I suppose you don't find it odd that a consulting company, who has some of the biggest names in commercial software development as clients, finds that the very threat to the people that pay them is of a higher quality? While I don't doubt there are cases where open source software is of better quality, I also believe the converse that there are cases where commercial software is of higher quality. So one little scan on a sub-system of Linux vs. "commercial software" means that open source is the best hands down? I doubt it.

      Also, why is it that they won't name the commercial software they scanned on their home page? Why is it that I have to provide contact information to view their report? Since everyone here is so critical of BS moves MS makes, why are they not asking the same questions of this for-profit entity?

  3. Maybe, maybe not by Raul654 · · Score: 5, Funny

    Companies such as Oracle and Microsoft typically sell binaries incomprehensible to humans rather than the comparatively understandable source code.

    After seeing this, I think that statement is being a bit generous

    --


    To make laws that man cannot, and will not obey, serves to bring all law into contempt.
    --E.C. Stanton
    1. Re:Maybe, maybe not by Anonymous Coward · · Score: 2, Funny

      .. Also opening those binaries in Notepad resulted in a message, file too large, please use wordpad, which resulted in a message, file too large, please use Office XP which resulted in a message, file unreadable please open in .NET.

      On other hand opening a open source file resulted in a quick readable file, which was in simple comprehensible english. the first word was some bin or bash , a proper dictionary word.

      AK

  4. Statistics by Caractacus+Potts · · Score: 5, Insightful

    How about using a larger sample of code before making such bold statements. It's probably true that the code has fewer bugs, but when you abuse statistics it just makes things look dishonest.

    1. Re:Statistics by Xtifr · · Score: 5, Interesting

      This is not the first such study, there was a paper published in the early nineties which tested various standard unix command-line tools from a variety of vendors. They subjected the tools to horrendous stress and abuse, and found (to their suprise) that the GNU tools were the most reliable, with approximately a 1% failure rate in their bank of tests. The second best was HP, with about 8% failure rate, and everyone else was between 12-20%.

      I don't have a link, but the paper was pretty widely publicised at the time, and should be fairly easy to track down. It was the first major study to really show an emperical link between openness and reliability, but it was far from the last. This latest one is merely one more in a long list.

    2. Re:Statistics by Erasmus+Darwin · · Score: 2, Informative
      "there was a paper published in the early nineties which tested various standard unix command-line tools from a variety of vendors."

      I believe you're referring to the fuzz papers. They basically threw a bunch of random garbage at different commands and then watched for core dumps.

    3. Re:Statistics by dglo · · Score: 5, Informative

      there was a paper published in the early nineties which tested various standard unix command-line tools from a variety of vendors. They subjected the tools to horrendous stress and abuse, and found (to their suprise) that the GNU tools were the most reliable, with approximately a 1% failure rate in their bank of tests. The second best was HP, with about 8% failure rate, and everyone else was between 12-20%.

      I'm guessing you're probably referring to Bart Miller's Fuzz Testing software. They did a survey in 1990 and a followup in 1995. They've even got the software available if you want to do the 2003 version!

  5. In other news by asmithmd1 · · Score: 4, Funny

    Pope is catholic
    Bears are found to sh*t in woods

  6. Title of post misleading by jfrumkin · · Score: 5, Insightful

    Over time, successfull open source projects which address a particular issue will most likely have fewer bugs; just being open source doesn't mean fewer bugs (or better software). It just means that it has a better chance, if it survives, of being better software.

    --

    "What we have here, is a failure to communicate." - Cool Hand Luke
  7. I get it by undertoad · · Score: 3, Funny

    Open source has fewer bugs.
    Bill Gates: bugs are cool.
    Ergo, open source is not cool!

  8. But aren't TCP/IP stacks mostly BSD? by mccalli · · Score: 5, Interesting
    'The open-source implementation of TCP/IP in the Linux kernel clearly exhibits a higher code quality than commercial implementations in general-purpose operating systems,'

    Really? But I thought most commercial OSes derived their TCP/IP stacks from BSD code in the first place. And since BSD is open-source, shouldn't these commercial OSes show roughly the same level of quality then? Or are they arguing that the Linux TCP/IP stack is superior to the BSD one?

    Cheers,
    Ian

    1. Re:But aren't TCP/IP stacks mostly BSD? by gurps_npc · · Score: 5, Insightful

      While the commercial OSes derive from BSD code, it is not the same thing. Related to that, there are three sources of bugs that Closed OS's will have but Open OS's will not. 1) Errors in the derivation of the BSD code - that is they generally have to make minor changes in the BSD code to get it to work with their product. 2) Bugs in the Non-BSD code that is wrapped around the BSD code. 3) Errors found in the BSD code after the Closed code was written. Usually the closed Os will NOT upgrade the BSD code for a bug found in it because either 1) they are lazy, 2) they are ignorant of the bug, or 3) doing so would require a re-write of the Non-BSD code.

      --
      excitingthingstodo.blogspot.com
  9. "The Linux" by sczimme · · Score: 4, Funny


    Reasoning, which sells automated software inspection services, scrutinized part of the code of the Linux and five operating systems,

    Including the Solaris, the Windows, the AIX, and the HP/UX.

    --
    I want to drag this out as long as possible. Bring me my protractor.
    1. Re:"The Linux" by Spunk · · Score: 3, Funny

      Reading that article gave me "the AIX"

  10. Bah. by KefkaFloyd · · Score: 5, Interesting

    I find the fact that they did not say what OSes they compared to be very... suspect. What about Mac OS X, FreeBSD, and other open source OSes that have Open Source TCP/IP implementations in their kernels? Since they did not say what OSes are being used...

    "Reasoning declined to disclose which operating systems it compared with Linux, but said two of the three general-purpose operating systems were versions of Unix."

    How lame. For all we know, they could have tested the Amiga OS, Mac OS 9, Windows 3.1, A/UX, and NeXTStep! Other than this, the article is pretty vague and does not seem to give me much meat on the subject, nor a link to the study (you have to go through some forms and give up personal info to get it at www.reasoning.com).

    --

    Conglom-O: We Own You (TM).
  11. State the bleeding obvious. by Arimus · · Score: 2, Interesting

    Most cryptographic algorithims do not gain acceptance without being open to peer review to spot flaws and potential weaknesses...

    So why should any of this article be a suprise or even particulary note worthy?

    --
    --- Users are like bacteria -> Each one causing a thousand tiny crises until the host finally gives up and dies.
    1. Re:State the bleeding obvious. by blackbear · · Score: 3, Insightful

      So why should any of this article be a suprise or even particulary note worthy?

      perhaps because when large numbers of people are uneducated about something they use and make daily decisions about, it is shocking to them to learn that their assumptions (probably brought about by marketing) are erroneous.

      Other notable, and obvious "surprises" in research:

      -Two parents are better than one.
      -More concealed carry = less violent crime.
      -You are more likely to get sick at a hospital than at home.
      -Breast milk is better for babies than formula.

      A lot of money and time have been spent researching these topics, only to find what many of us already knew to be true and obvious.

      Not everyone is educated and experienced in everything, and it can be painfully difficult to dissuade people of their delusions. Especially when they've been formed out of ignorance.

  12. No Suprise There by Greyfox · · Score: 5, Insightful

    The attitude I've seen in the corporate world is that open source products are made by amateurs and is therefore in some way not blessed by the magical corporate coding fairy which makes all the shit churned out by corporate code shops stink less. This attitude is arrogant and does not take into account the simple fact that all those people who got into programming just for the money tend not to work on open source products. When you've got code that is both written and reviewed by legions of people who love to code and who find good computer programs to be beautiful, you're going to get better code.

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

    1. Re:No Suprise There by syle · · Score: 4, Insightful
      This attitude is arrogant and does not take into account the simple fact that all those people who got into programming just for the money tend not to work on open source products.
      It also doesn't take into account that many people working on open source ARE professional programmers during the day.
      --

      /syle

    2. Re:No Suprise There by sir_cello · · Score: 3, Insightful


      "get better code"

      Better code is not the only thing in the world. What about better design, better architecture, better dedicated talent, better testing resources, better hardware and tools support, etc. It's hard to take something about code defect ratios and turn that into a wide-sweeping statement. I can show you plenty of low defect code that is part of a bad design.

    3. Re:No Suprise There by mrpuffypants · · Score: 5, Insightful

      I'm encountering this in my new job that I recently took. I walked into a company that was using an antiquated MS Exchange system for most of their communication, old networking hardware(which is another issue entirely), and software packages that hadn't been updated in about 5 years because the company that originally wrote them has gone under in recent years (.bomb)

      After looking at everything I suggested a lot of open-source alternatives to all the current software. The prices to buy it all was zilch, and upgrading all the hardware can be done in-house, without the help of "contractors" that charge out the ass just to support their own software. The system would work great, a lot better than the currently antiquated crap we are using.

      After presenting my ideas to management they shot it down totally. They, with their mind for the bottom line, couldn't understand how people would release software totally for free. They kept asking me when they would pull the bait and switch on us. It's two whole different schools of thought, and the only way that I can implement it now is to do it slowly behind their backs until they don't even know what hit them when they don't have to reboot the server daily anymore =]

    4. Re:No Suprise There by Rary · · Score: 4, Interesting
      I'm quite happy to report that this is not entirely the case everywhere in the industry. I happen to work for a consulting company that has become quite fascinated in recent times with the magic that is open source. And we love selling open source-based solutions to our customers, who in turn, love buying them.

      Basically, the business logic goes something like this:

      We can build your application in one of two ways.

      1. $5000 for proprietary products (app servers, IDEs, etc.), and $5000 for our time and effort (total = $10000), or...
      2. $1000 for proprietary products (the rest are all open source), and $7000 for our time and effort (total = $8000)
      Needless to say, this goes over well for the client ($8000 expense is better than $10000 expense), and also for us ($7000 revenue is better than $5000 revenue ).

      Obviously, I'm just picking numbers at random, but I think you get my point.

      Not every client is eager to jump on open source tools, but more and more they're finding that it's a really good idea. Especially when a major consulting company with an excellent reputation (ie. us) comes along and tells them that this is a good idea. People tend to listen to us, because we tend (historically speaking) to be right a lot of the time.

      PHBs might tend to be stuck in the mindset that "if it's free, it must suck, if it's expensive, it must be worth it". But when they pay a high-priced consultant to come in and give them advice, and that consultant says "you know, you can buy IBM's WebSphere Portal Server for $140,000 per CPU, or you can use the open source Jetspeed, which is practically the same thing, in fact, WebSphere Portal is basically just Jetspeed repackaged with some extra tools that you probably don't even need," even PHBs can understand that kind of logic.

      --

      "You cannot simultaneously prevent and prepare for war." -- Albert Einstein

    5. Re:No Suprise There by mccalli · · Score: 4, Insightful
      After looking at everything I suggested a lot of open-source alternatives to all the current software....After presenting my ideas to management they shot it down totally.

      What would be their motivation to replace the software? Does the current set-up work? Is there a burning need to replace?

      Often "it would be a better system" isn't enough. If the old system works well enough and takes few resources, then it's doing its job fine and doesn't need a potentially risky replacement. And it sounds like what you proposed was a large change.

      the only way that I can implement it now is to do it slowly behind their backs

      Careful, young grasshopper. These aren't your private machines. If you've presented your ideas and they've been rejected, then do not sneak in those changes anyway. To do so could have serious ramifications for your job. Stick by what you've been told, and do things openly.

      Cheers,
      Ian

    6. Re:No Suprise There by Rary · · Score: 4, Interesting
      >> "The client can't just pull in any run-of-the-mill certified MSCE to maintain the OS system."

      Well, judging by your reference to MCSEs, I'm forced to assume that you are assuming that my reference to open source products necessarily equates to choosing Linux over Windows. Which it does not.

      Regardless, this "vendor lock-in" is really not an issue. Basically, because we are not the creators of the open source software in question, we actually have little advantage over our clients in terms of knowledge and resources for support. We have to pour through the same newsgroups that their own IT departments would have to pour through in order to diagnose a problem. So there's really little advantage for them to insist on continually hiring us to support the system, when all we would do is precisely the same thing their own IT people would do. Granted, we wouldn't recommend a specific open source solution if we didn't have some experience with it, but over time their own IT staff will acquire that experience as well.

      On the other hand, if we were to sell them a proprietary solution, we have the benefit of partnerships and certifications which we can use to "lock them in", or at least give them the illusion of being "locked in".

      To put this in perspective, let's look at a real example. We do a lot of J2EE development. We could sell a client a complete proprietary IBM package, including WebSphere for the application server and WSAD for the IDE. This means they will primarily rely on IBM for the bulk of their support, or else turn to us, as we have lots of WebSphere certified people (myself included). Or, we can sell them an open source solution that includes JBoss for the application server and Eclipse for the IDE. Eclipse is open source, but it's primarily backed by IBM, so they would still have IBM available for support, as well as us, as well as the Internet community (it's all too easy to assume that "open source" equals "some virgin hacker in a basement", but that's not always the case). JBoss comes with plenty of readily available support -- lots of books on the subject, newsgroups, etc.

      As far as application servers go, JBoss is no more complicated than WebSphere (WebSphere requires a certain amount of "command-line configuration" and "regular updates"). Eclipse and WSAD are actually pretty much the same tool (WSAD is built out of Eclipse). I don't see how using tools such as these locks our customers into relying on us to support them.

      Which is not to say that "locking them in" is a bad thing, from a business perspective. I just don't think it's an accurate assessment in this case.

      Your response makes me sad. How are we to get PHBs past the perception of open source as sloppy unsupported crap slapped together by idiots in basements, if we can't even get geeks past this perception. Yes, some of it is. The same is true of some of the crappy closed source software that is for sale these days. We don't recommend crappy unsupported software to our clients, whether it's open source or proprietary.

      --

      "You cannot simultaneously prevent and prepare for war." -- Albert Einstein

    7. Re:No Suprise There by gbjbaanb · · Score: 2, Interesting
      Possibly the reason open source is looked down on is the lack of professional documentation. Sure, quite a lot of packaged products come with huge sets of docco that have little content besides "click on the 'install' button to install our wonderful product", and less than perfect technical documentation, but O/S products generally have nothing more than a readme.txt that tells the user to visit the product web page and read some generated docs, or a user-supported forum. (which quite often has too much noise that a PHB will accept).


      If a company could package O/S software with nice manuals and guaranteed 'support' then it'd gain much more acceptance, however, I suppose it would stop being 'free' software then.

  13. Something we all knew .. by phuturephunk · · Score: 4, Insightful

    The more points of view you apply to solving a problem, the quicker, and better you'll solve it. The beauty of human reasoning isthat no two people will view the world in *exactly* the same way, therefore each one of their respective paths to the solution will be different...Travelling that path to one solution can, as we know, lead to other SOLUTIONS to other PROBLEMS.. The more heads that work, the more solutions discovered . . and so on..

  14. Claim is too general by Peter_Pork · · Score: 5, Insightful

    Open Code Has Fewer Bugs

    The study looked at a single part of an operating systems (TCP/IP stack) and then the posting made a very general claim about open source software. This is cheap engineering (a.k.a. bad science). Period. You need a much larger sample to make such a claim. A single data point is meaningless. In fact, I believe that code bugs are much more a function of programmer performance and code complexity than open vs. close source development model. Opening the code may have a positive impact, but it is not the major factor to consider. The last thing Open Source needs is this kind of marketing strategies...
    1. Re:Claim is too general by ArthurDent · · Score: 2, Insightful

      You're right. This study alone does not prove anything. However, trying to draw out trends that would lead to that conclusion that could be verified through further study is valuable. Taking your arguement to an extreme no one would ever study anything because a single data point on anything would be useless.

      Perhaps it would be better to say that there is preliminary evidence that seems to show that open code has fewer bugs.

      I believe that code bugs are much more a function of programmer performance and code complexity than open vs. close source development model

      Open Source projects have access to many more developers which leads to there being a much larger body of knowledge and skill to bring to bear on a project. The more eyes that look at the code the better the code will become.

  15. number doesn't matter by Apreche · · Score: 3, Insightful

    Severity of bugs is more important that number of bugs. I could have a program with one bug, doesn't work. And you can have two bugs, feature broken and memory leak, but it works. Who is better?

    I also like the assumption in the title that because linux was found to have fewer bugs than some other OS's that open software in general has fewer bugs. Take a look at some of the bug lists on sourceforge projects and tell me that again. Number of bugs varies by project, not by open-ness.

    --
    The GeekNights podcast is going strong. Listen!
  16. Open code is only Linux? by GammaTau · · Score: 2, Insightful

    Why did they test only one free software kernel while testing four proprietary ones? I'm not saying that if, say, a *BSD kernel was used, the results would necessarily be something else, but making general statements of open code by examining only one open project is certainly not very accurate. Although I suspect that these inaccurate conclusions are more in the Slashdot side than in the study.

  17. Stating the obvious by seanadams.com · · Score: 5, Informative

    'The open-source implementation of TCP/IP in the Linux kernel clearly exhibits a higher code quality than commercial implementations in general-purpose operating systems,

    Well of course it does! The Linux and BSD IP stacks are benchmarks. This is where practically all protocol research happens - how would anyone be able to verify your results otherwise? Furthermore, only the free stacks are useful for compatibility testing because they are so configurable.

    So obviously it stands to reason that this code is much more complete and bug-free than any commercial implementation. THOUSANDS of people are studying every single line of this code on an ongoing basis.

    I've worked on a number of commercial IP stacks - some from scratch, and some based on Linux. Any IP stack written from scratch is understandably simpler, but it's not that hard to implement the essential RFC requirements (i.e. the "MUST"s) and make it stable. Now, making it FAST and making it use all of the bleeding-edge TCP stuff... that's another story. Only Linux/BSD are there (and of course any other OSes which use their stacks).

  18. upgrade maybe? by fiiz · · Score: 2, Informative

    Well ya know you can either go on cursing or upgrade...

    "Mozilla 1.2.1 was released to correct a DHTML bug in Mozilla 1.2. The only difference between the two releases is the fix for this bug (Bug 182500). If you have already installed Mozilla 1.2, you should upgrade to Mozilla 1.2.1. "

    --

    yours ever, fz.
  19. Misleading in terms of project selection by Jeppe+Salvesen · · Score: 2, Insightful

    They chose the TCP/IP stack. That is almost certainly the best tested of all the components in Linux. It is used by everyone, so the eyeball count is particularily enormous.

    If they would compare the implementations of something less popular, the numbers MIGHT be different. x.25 or something.

    --

    Stop the brainwash

  20. I am skeptical of the results by BigBir3d · · Score: 2, Insightful
    For this reason:
    Reasoning declined to disclose which operating systems it compared with Linux, but said two of the three general-purpose operating systems were versions of Unix. The comparison was done with version 2.4.19 of the Linux kernel. For the comparison products, the company had access to the source code that for proprietary software is usually a closely guarded secret.
  21. Space shuttle code is closed by MondoMor · · Score: 5, Insightful

    The code for the shuttle's GPCs is closed, and it's regarded by many as probably the most bug-free code around with any degree of complexity. It's been upgraded several times since the '70s, and rarely have errors been found.

    It probably had one of the longest development times for its size, too. Which helps a lot.

    Quality has nothing to do with whether code is open or closed source. It's got everything to do with the environment in which it was written. Code written under extreme management pressure from a profit-hungry megacorp is just as bad as code written by an ignorant or uneducated dork in his basement.

  22. yeah right by nomadic · · Score: 2, Insightful

    Specifically, Reasoning examined the TCP/IP stack and found fewer errors in Linux.

    So they just looked at the code and found all the bugs. They must have the best programmers in history working for them if they could just look and find all those bugs that it usually takes years for mortal programmers to find.

  23. Now try the same with CIFS by solcity · · Score: 2, Interesting

    Much more interesting would be a code comparison between open source samba and the micro$oft CIFS code..

  24. Not about Microsoft! by Daengbo · · Score: 3, Informative

    Before we begin the bashing, let's note that two flavors of 2.4.19 were compared to two closed source Unix operating systems. Let's try to keep the evil empire out of this one!

  25. Why that component? by DeadSea · · Score: 4, Insightful
    The Linux TCP/IP is an area of code that is known to be robust. It has been analysed again and again. Windows TCP/IP stack is widely regarded to be inferior on many counts. If you choose TCP/IP as your area of study I don't doubt that you will come out with these results. If you chose another area such as USB protocol, you would find very different results.

    TCP/IP is better on linux because many very talented people have worked on it. This is an area in which open source software development has worked well. However, it does not mean that open source developement always works better.

  26. any kernel patches come from this? by dido · · Score: 4, Interesting

    If they found 0.1 errors per 1000 lines of code, did they approach Linus and Co. to point them out? Has Reasoning submitted any kernel patches to address the errors they say they found?

    --
    Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
  27. But Bugs are Cool! by tbmaddux · · Score: 2, Funny
    Right?

    Were they testing code from 7 years ago?

    --
    Can't you see that everyone is buying station wagons?
  28. Re:Fewer bugs than what? by LizardKing · · Score: 5, Informative

    Microsoft pinched their TCP/IP stack from *BSD

    Not exactly true. I can't find the link off hand, but I read an explanation of the background to this myth quite recently. If you Google around you should be able to find it.

    Back when MicroSoft were keen to add TCP/IP support to Windows, they contracted another firm to to do the work. That firm took the BSD licensed stack (from 4.3BSD as I recall), and did tyhe necessary porting work. This they then delivered to MS, meeting the original deadline. Since then, NT has gained a new TCP/IP stack written from scratch by MS engineers.

    As a result, the TCP/IP stack currently used in Windows owes little or nothing to the BSD implementation.

    Chris

  29. Re:in other news.... by Junks+Jerzey · · Score: 2, Interesting

    in other news....duh

    Yup. Note that this doesn't tell you anything about the overall quality of the software, though. So much open source software tends to be writter by students with little experience ("this was my first large project") and it shows. Just because other people find and fix the bugs doesn't change this.

  30. This only makes sense. by SatanicPuppy · · Score: 5, Insightful

    The code I write for myself is the cleanest stuff in the universe. I get freaky about extra lines or lines that look "ugly" or inelegant.

    Now when I'm at work I toss out functional, ugly code. Doesn't work quite as well, but 90% of the users will never know that. I'll write catch statements for the most obvious errors, but I don't sit and brood about what some hypothetical idiot might want to do with the code. If there are enough people who hit an error there, I patch it, and move on with my life.

    By and large, high production commercial code is sloppy. There isn't any profit to be made in making it pretty or elegant, and we all know how (for a random example) MICROSOFT feels about profit.

    Open source is just the opposite; if you're not making any money on it, you're doing it for your own personal satisfaction, and I think most people find it more satisfying to have clean baddass code, rather than sloppy junk code. Heh. Especially when your NAME is on it, and the SOURCE is available.

    Just my .024 euros.

    --
    ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
  31. Let's think about this... by Anixamander · · Score: 3, Insightful

    Reasoning "sells automated software inspection services."

    The key word here is "sells." They would have a tought time selling this to open sourcers, what with everything wanting to be free and all. Instead, they show the big closed source companies that their code isn't nearly as bug free as the open stuff, therefore they really need to buy this.

    I'm not denying that open source is less buggy, but always question the motivation of the company making the claims. Just because Reasoning's assertions fit your own neat world views doesn't mean that they are without bias or secondary motivation.

    --
    Do not taunt Happy Fun Ball(TM)
  32. Yes, but the code has diverged. by Jimithing+DMB · · Score: 5, Insightful

    Actually, you've inadvertantly stumbled upon an excellent point.

    No code is perfect to begin with. The BSD stack is still improved from time to time. The BSD stack that companies folded into their code years ago has since had some major changes and the companies haven't bothered to take many of those changes into account.

    Had they been required by license (GPL) to keep the code open, then it could be fixed by other people. Instead, the implementation has languished. This in fact is one of Stallman's great resons for keeping all code free.

    However, the reality of it is that our current environment still favors closed source software. With any luck, people will slowly start to wake up and realize that source code needs to be open for all software projects. Think about it. If it was normal to receive source with binaries, nobody would really think twice about it. It's only seen as a bad thing because it's not what Microsoft does. But the reality is that Microsoft has a business model that works well for them, a giant monopoly. The reason their competitors fall on their asses is because they are trying to play as if they were MS, which they are not. It's not impossible to compete with Microsoft, it's just impossible to compete head-on.

    1. Re:Yes, but the code has diverged. by Eccles · · Score: 5, Insightful

      However, the reality of it is that our current environment still favors closed source software.

      I'd say it's not environment, it's economics. Apache has flourished because the people who develop it are also people who use it. But what percent of graphic designers are really using the Gimp vs. Photoshop? Maybe Photoshop has more bugs, but it has more usable features (performance also?), and that's what its users want. Unless you can come up with a scheme to fund development of open source in the same way that software purchases fund closed source, closed source is going to be the only way to develop software where the users generally aren't also the developers.

      I develop commercial closed-source software. I'd absolutely love it if some sugar daddy came up to me and said, keep doing what you're doing and I'll keep paying you what you're getting paid, except we're making the code open source. But it isn't going to happen.

      --
      Ooh, a sarcasm detector. Oh, that's a real useful invention.
    2. Re:Yes, but the code has diverged. by Bodrius · · Score: 5, Interesting

      Aye. It could be that the TCP/IP stack that the article mentioned has "flourished" (become better software) because the people who develop it are VERY MUCH using it.

      Linux geeks grok TCP/IP networking, and Linux users DEPEND on TCP/IP (not 'it would be nice to have web access and surf porn while I type this memo') for practically all of its market share. Like gcc, TCP/IP is part of the Linux deal.

      It would be biased to regard this as conclusive evidence of the superiority of open-source unless other, less sexy areas of Linux development are compared to their commercial counterparts in the same way.

      As evidence that certain commercial companies have not put priority on the TCP/IP stack of their OS, this could very well be good evidence.

      But this doesn't necessarily mean the commercial companies are inferior; they may very well be right in having different priorities.

      For example, for a Windows user it's more important that the Media Player works perfectly than having an efficient TCP/IP stack. Even on the server side it's not a big issue on their market. It's under so many layers of software, appearances and priorities that their clients would never notice if they made it better anyway.

      --
      Freedom is the freedom to say 2+2=4, everything else follows...
    3. Re:Yes, but the code has diverged. by Abcd1234 · · Score: 4, Informative

      However, the reality of it is that our current environment still favors closed source software. With any luck, people will slowly start to wake up and realize that source code needs to be open for all software projects. Think about it. If it was normal to receive source with binaries, nobody would really think twice about it. It's only seen as a bad thing because it's not what Microsoft does.

      Please! I'm no MS apologist, but this is getting plain stupid. This isn't just about MS, believe it or not. The fact is, open source as a business model is seen as a bad thing because it's not what a huge number of companies making billions of dollars a year do. Have you heard of Oracle? IBM? Sun? Apple (our latest hero)? I could go on... the fact is, there are a TON of companies out there making big bucks selling closed source software. And more power to them!

      In the real world, closed source is, apparently, a viable business model. And thus far, open source isn't. Honestly, how many companies are actually making some real money making products which they also release the source to? Until this starts happening, closed source is going to be predominant... and there's nothing wrong with that!

      Personally, yes, I agree that open source is a good thing. But assuming that all software should be open based purely on some moralistic view is ridiculous. The world is far more complicated than that. Statements like "source code needs to be open for all software projects" is just plain naive, IMHO.

    4. Re:Yes, but the code has diverged. by tupps · · Score: 2, Interesting

      The thing is that open source products aren't necessarily made by a company whose primary purpose is selling software. Alot of open source is worked on by people who make companies work. Eg, Company X makes widgets, they need a widget inventory control. Company Y makes car parts, and have written an inventory control program. They release this as open source, Company X uses it, and there internal guys find & fix a bunch of bugs. Because it is open source both companies are gaining the added benefit. I think you will find that for most open source projects (especially those that are not high profile) this is how they are being financed. Remember 95% of code written these days is for internal systems that are not released onto the market.

      --
      Go out and get sailing!
  33. Which is the cause and which is the effect? by Skapare · · Score: 5, Funny

    What I am wondering is which is the cause and which is the effect:

    Microsoft source code is defective because it is closed.

    Microsoft source code is closed because it is defective.

    --
    now we need to go OSS in diesel cars
    1. Re:Which is the cause and which is the effect? by jo42 · · Score: 2, Funny

      All of the above.

  34. Re:yeah right by gmuslera · · Score: 2, Informative

    There is also an article about this here.

    They not searched for any kind of possible bug, the article says specifically what they were looking for:

    Reasoning looked for programming problems such as memory that was marked as free when it was in fact still in use, memory that was being used without being properly initialised, and attempts to store data that exceeded the space reserved for it. This last problem is often associated with buffer overruns, a major weakness that under some circumstances can let an attacker take over a computer.

  35. Re:in other news.... by JohnFluxx · · Score: 2, Insightful

    >So much open source software tends to be writter by students with little experience and it shows.

    You mean it's been written with the latest design and coding ideas, to a high quality, tested, documentated and above all written by someone who cares about the program, without the bother of office politcs?

    I agree!

  36. Great news! by indecision · · Score: 3, Interesting

    Now if they could please point out the filenames and line numbers in question, perhaps we could eliminate the bugs altogether...

  37. Comment removed by account_deleted · · Score: 4, Insightful

    Comment removed based on user account deletion

  38. Fewer Errors in TCP/IP Stack? by zimmermantech.com · · Score: 4, Insightful

    "Reasoning examined the TCP/IP stack and found fewer errors in Linux" The TCP/IP stack in Linux (and for that matter, most operating systems) was borrowed from BSD. Shouldn't this comparison be a testament to quality BSD instead of Linux? Paul Zimmerman http://zimmermantech.com/webcam.htm "Comments should be like skirts - Short enough to keep your attention, but long enough to cover the subject"

    --

    Listen to Live FM Radio
    1. Re:Fewer Errors in TCP/IP Stack? by (startx) · · Score: 2, Informative

      (-1) Misinformed

      The linux TCP/IP stack was not pulled from BSD, it was written from scratch, or at least most of it was anyway. That's why when you see bug fixes for the BSD stack you don't see them in Linux, and vise-versa.

  39. Is age the key factor? by realnowhereman · · Score: 5, Interesting

    This is still an argument for the open source method, but I think that the code quality should be attributed to a different source. Perhaps it is not about an inherently good or inherently bad method. What if age is the key factor?

    The Linux networking code has been in for a long time. Not in it's present form, obviously, but each change builds on the last; as it must in open source - it would be foolish to start afresh when you have something that works. So a cylcle develops and at each stage the code gets better. Compare this with proprietary; can they look at a competitors code? No. They must start afresh and so their code is effectively younger.

    Further, if we measure software age not in units of time but in units of updates, open source has the advantage that there are many updates, there is always someone new to look at the code. No company can compete with the sheer quantity of viewings and therefore updates that occur in open source developments.

    --
    Carpe Daemon
  40. Re:in other news.... by CrayzyJ · · Score: 4, Insightful

    "You mean it's been written with the latest design and coding ideas, to a high quality, tested, documentated..."

    I have to respectfully disagree with you that this is a good thing. All too often students will learn a new design or coding idea and want to apply it even when it is not neccessary or the best tool for the job. Furthermore, students, in my experience, are way too ambitious to test much. The just want to code, code, and then code.

    Finally, have you read much of the kernel? Documentation is sparse (though getting a little better in 2.5.x).

    Office politics no. Dorm politics - e.g. my stack is better than yours? Maybe.

    --
    Holy s-, it's Jesus!
  41. I'm sure Bill will be pleased to hear by kfg · · Score: 2, Funny

    that MS code is just as good as code written by an ignorant or uneducated dork in his basement.

    He'll probably have his mom sticth it into a sampler he can hang on his office wall.

    (Of course, personally, I don't think it's true. Bill has the resources to throw at code to make it much worse than any single dork can, but that's just my opinion)

    KFG

  42. Re:in other news.... by JohnFluxx · · Score: 2, Interesting

    Hmm..

    Say you have a load of CS students, and some of them code OS programs for a hobby. Now intuitively the ones who code for a hobby are more likely to be better coders than the average CS student.

    When the hobbiest-student-coder has to do his 6 month computing project (I assume that most uni's have similiar projects - or at least some coding projects) then you have to produce plans and documentation etc for it. They are also far more likely to make their said software open source.

    When in the work place, then you have all the coders together producing code - resulting in a lower average quality of code.

    I'm obviously making some assumptions here, but you get my point..

    Btw, as for kernel, it's not quite so clear cut. I do not dispute that there isn't enough documentation, but sometimes people take up issues in the wrong places.
    For one example, when AA wrote his memory manager, and non-coders complained and booed because it wasn't documentated. One big reason for this was that the algorithm used was a standard well documentated algorithm, and anyone that understood the algorithm well, would be able to easily understand the code.

    Anyway, I have a quantum computing lecture to attend.. bye!

  43. Already Analyzed by Euphonious+Coward · · Score: 4, Informative
    The Linux Weekly News already has an analysis of this report up at http://lwn.net/Articles/22623/

    Two key points are that (1) most of the bugs Reasoning found are false alarms (which is an occupational hazard for this kind of analysis), and (2) one reason Linux does so well is that those lunatics at Stanford have been doing just this kind of analysis for quite some time, so most of the easily-found bugs were found long ago.

    This doesn't invalidate any of their conclusions, of course: the Stanford lunatics haven't been analyzing NT, they've been analyzing Linux, and for sound academic reasons.

  44. But is Open Source the way to go by MhzJnky · · Score: 2, Insightful

    begin troll

    This may be another feather in the Open Source cap, but I wonder if Open Sources is a good thing in the first place. Think about it for a second. Linux replaces Unix in the server world (which is happening). Companies that make closed source Unix OS's lose money, then they fire people. Company's get used to not paying for software so they start using Open Sources more. More closed source companies lose money, more fire people. Just something to think about when your hacking away at your latest kernal patch. You are writing software so companies can spend less money, executives can give them selves big bonuses for saving money, and vendors can fire people. I'm a consultant for big companies, I've seen it, it happens.

    --


    "Failure is not an option, it's part of the standard package"
    1. Re:But is Open Source the way to go by Anonymous Coward · · Score: 2

      Sorry for the rambling but:

      If you go the Open Source way, you end up like Richard Stallman, who has never had a wife, no kids, no car, and no house (as far as I can tell). He's now trying to get a date on his Web page at www.stallman.org.

      The guy is so obnoxious that, when he approached Minix creator Andrew Tanenbaum about using Minix as the kernel of the GNU OS (rather than the Hurd), Tanenbaum realized he couldn't stand Stallman and decided not to participate. Stallman stubbornly chose to go it alone, and the result is an unfinished kernel that most people have forgotten about. (Read the book "Rebel Code"). Meanwhile, Minix begat Linux, and Linux begat so much publicity for Linus Torvalds that Stallman started getting jealous and began railing at everybody to call it "GNU/Linux" to give it "proper credit." Ironically, Stallman had written a paper against this kind of crediting; his target was the BSD license, which you can read at "http://www.gnu.org/philosophy/bsd.html".

      He hasn't programmed now for many years -- his excuse is carpel tunnel syndrome. It's either that, or maybe he just ran out of good ideas. Not many Web shops use Emacs to layout their Web pages.

      I have respect for his programming intellect, but his economics sucks and is actually condescending to other programmers. It's funny how nobody talks about The Software Tax of the GNU manifesto http://www.gnu.org/gnu/manifesto.html. Of course, Richard Stallman graduated from Harvard and has a MacArthur Foundation Genius grant of about a quarter of a million dollars, but that isn't exactly a sustainable business model for everybody else.

      As far as the "study" from this company is concerned:

      1) They don't release the names of the other closed source OS's. Kind of ironic -- they're being "close" mouthed in their praise of Open Source.
      2) If you look at the Web site, and at their service, it seems that all they do is check for array bounds checking, use of unitialized variables, and so forth. Just get a copy of BoundsChecker or Purify, fer cryin' out loud.
      3) This company doesn't seem to produce software, so they have a good reason not to support closed software -- doesn't hurt their bottom line, and gives them more business.

      Man, whatever happened to ShareWare?

  45. Re:in other news.... by Junks+Jerzey · · Score: 2, Insightful

    You mean it's been written with the latest design and coding ideas, to a high quality, tested, documentated and above all written by someone who cares about the program, without the bother of office politcs?

    I agree!


    No, I mean it's written by people without experience architecting large projects, so the result is verbose, brittle, and messy. Period.

  46. Open Source has no deadlines ... by fygment · · Score: 2, Interesting

    ... so with the luxury of time, it _should_ be less buggy.

    I don't think releasing the source is necessarily a good thing for a commericial app. How would you control updates and mods? Where would the configuration control come from? I just had my first encounter with CVS at Sourceforge. _NOT_ straightforward. I don't think you could scale that up to a million purhcasers.

    --
    "Consensus" in science is _always_ a political construct.
  47. Re:Big surprise, really. by Anonymous Coward · · Score: 2, Funny

    By the same token, the more managers you haven the better is your work ?

  48. Or... by intermodal · · Score: 5, Interesting

    People coding something because they want to (and because they need it for something for themself) leads to better code. I know when I do something for myself, I don't half-ass it.

    Coding for the end result = quality

    Coding for a living = paycheck

    Any questions?

    --
    In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
    1. Re:Or... by Anonvmous+Coward · · Score: 2, Insightful

      "Coding for the end result = quality"

      Too bad that quality doesn't always bubble itself up to the UI. That's probably my biggest complaint about open source software is that few ppl actually put serious thought into the UI design. It starts off as a utility written to solve their own problem and eventually it becomes useful enough to share with ppl. VirtualDub comes to mind. Kick ass prog, hardly intuitive in terms of UI.

    2. Re:Or... by intermodal · · Score: 2, Interesting

      This is true, though I am sure it suits the guy who made it just fine...that's one of the great things about having the source. You can do it yourself if you are so inclined. While not everyone has to pay to use it, somebody has to donate their time to create it, usually to their own ends. Then they choose to share that improvement or creation with others. Not trying to use something overly noted here on /., but thats what Linus did with Linux...

      --
      In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
  49. Makes sense... by Junta · · Score: 2

    Open Source is still largely deveolped as a hobby of enthusiasts. Some companies have their hands in the pie too, but even the resultant effort seems to be more in the style of the hobbiest than of the typical company effort.

    Two factors. When I develop closed source apps for work, especially if it is something I have no real passion about, I tend to have messier code. No one is going to see it anyway. If I ever change jobs, a potential employer isn't going to ever see that code to review my style. If no user or the community in general will not see it, I'm more likely to take riskier shortcuts and settle for inelegant hacks. As long as no obvious runtime problems occur, then it is enough. When I submit patches for open source applications, I take more pride in the work. I want it to be clean, easy to read and follow, and free from amateurish looking code.

    Secondly, even when I would like to re-evaluate approaches I use in a commercial environment, the business end of things will push deadlines. Time that I would have normally taken to go back, clean up, and rework the bits that work, but are too inelegant is denied. There is a significant amount of care with respect to market trends, customer demands, and marketing promises that interfere with quality code. With open source, you do it as you feel like it. Take as much time as you want. Sure, there are frequently deadlines in large projects (feature freeze, etc), but the penalty for not being able to meet those deadlines just means your work will be delayed to the next release cycle. There is no danger of losing your job, and even if consistantly missing feature freezes means you lose cvs write access, or are not taken as seriously, it really is no skin off your back, and you can almost always get back in through picking up the pace again...

    --
    XML is like violence. If it doesn't solve the problem, use more.
  50. Linux IP stack a complete rewrite by maynard · · Score: 4, Informative

    The Linux IP stack is a complete rewrite and doesn't derive from the traditional BSD sockets code at all. In particular IP packet formation between Linux and BSD is completely different. The header and tail portion of an IP packet is handled in a single pass through called an "sk_buff". In BSD header and tail formation of the packet is handled in two passes, one for the header the next for the tail, in an "nbuf". The BSD protocol implementation is traditional and the one described in TCP/IP Illustrated, while the Linux implementation is completely new. I believe that one positive feature of the Linux implementation is that it has allowed for zero copy networking, though that's a limited benefit which is only of use to a very small subset of servers connected to very fast network links. A big positive of the BSD stack is that it's old, rigorously tested, and very well documented. Note that the System V Streams implementation is completely different as well, so Solaris and other SysV derived kernels follow their own method for packet formation. I make no claims that any of these protocol implementations are better than the others, only that the code base and history are completely different.

    I've attended a few USENIX kernel internals courses but that's the extent of my competence (have poked through the source out of curiosity though). Please feel free to post additional information or correct any mistakes I may have made.

    Cheers,
    --Maynard

  51. Circumstantial half-assing by intermodal · · Score: 2, Insightful

    The answer is simple. They often do force you to half ass, cut corners, or even write to a horrible design created by someone with no idea what he is doing. So often I have seen commercial software that I myself have worked on go out in deplorable states due to deadlines, budget reasons, or just plain bad managerial decisions, forcing the coding to be horrible, sleep deprived, and poorly debugged. Last time I checked, I don't have a deadline on my personal projects, therefore I can spend all the time I wish to obsessive-compulsively making sure everything works exactly how it should. It's not a matter of willful half-assing, it's a matter of circumstantial half-assing. Excuse or not, the fact is that quality comes from having both the time and the freedom to do it right.

    --
    In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
  52. Re:in other news.... by rusty+spoon · · Score: 2, Funny

    There is a reason for this, which has nothing to do with PHB's attitude, but more wth the Grad's attitude that he thinks he knows it all.

    As they say; Hire a student while they still know everything!

  53. How to measure how good a program is? by snipercat · · Score: 2, Interesting

    This post reminded me of a question I was pondering last week. What makes one software program better than another software program? Is there a way to quantitatively measure how good a piece of software is? Would we measure the "goodness" of software by, the number of bugs it has (or rather the lack there of), the number of lines it took to write it, how long it took to develop, the type of license (open vs proprietary), the efficiency (how long to takes to run), the language it was written in, ease of use, etc, etc, etc? My guess is we would have to come up with a convoluted mathematical formula to measure the goodness of a program. Anyone care to take a stab at it?

  54. It is natural . . . by Eric+Damron · · Score: 3, Insightful

    It is natural for open source projects that survive to become very high quality. Look at it this way: If you buy proprietary software from a corporation, you can be sure that they are motivated by the bottom line.

    Corporations are there for one reason only: profit. This in itself does not mean that the products that they put out will be inferior. However, being motivated by profit means that:

    1. They will push their employees to put out a product quickly.
    2. If a product has flaws, it is the bottom line that dictates the priority given to fixing that flaw.

    Open source on the other hand is completely different. Although it can be motivated by profit usually it is not as much. A lot of people do it because they just want to do it. This in itself does not make open source less buggy. I would say that most young projects have as many or more bugs in them than proprietary projects.

    However, if the projects live for a long time it is because dedicated coders have decided to spend their time improving the product. This dedication over a period of time without the pressure by management to quickly push the product to market is the reason that open source becomes better than proprietary software.

    --
    The race isn't always to the swift... but that's the way to bet!
  55. Collective Ownership vs Individual Ownership by Ardias · · Score: 2, Insightful

    The old saying about "many eyes makes all bugs shallow" is true even for propeietary code. I have been working on proprietary software for most of my career. My own opinion is that software made by companies with collective ownership policies is of better quality than software made by companies which allow for individual ownership.

    At some places where I worked, some people just "owned" some of the source code and for whatever reason, nobody else was allowed to touch it (or sometimes even see it if the boss owned the code). Anybody else who wrote anything dependent upon that often found a lot of bugs in that code, and just had to wait until so-and-so got around to fixing it. Some of eventually wrote a replacement for that whole component, and obsoleted the original.

    At some places where I worked, and at where I am now, the rule is that we all own the code collectively. Sure, there are some people that better understand some parts of the code than others, but nobody tells anybody that some code is off limits. It is easy to just go in to some section of code, fix the bug, and move on.