Slashdot Mirror

← Back to Stories (view on slashdot.org)

MySQL & Open Source Code Quality

Posted by CmdrTaco on from the krow-can't-take-kredit dept.

dozek writes "Perhaps another rung for the Open Source model of software development, eWeek reports that an independent study of the MySQL source code found it to be "in fact six times better than that of comparable commercial, proprietary code." You can read the eWeek write-up or the actual research paper (reg. required)."

12 of 446 comments (clear)

  1. Lines of Code? by ksa122 · · Score: 3, Interesting
    Reasoning performed its independent analysis using defect density as a prime quality indicator. Defined as the number of defects found per thousand lines of code, MySQL's defect density registered as 0.09 defects per thousand lines of source code.
    Can any measurement that uses lines of code to compare code that could be written in different languages or for different types of applications be very accurate?
  2. All that's missing ... by JSkills · · Score: 4, Interesting
    All that's missing - to go along with the defects per lines of code comparision - is a comparison of features and performance benchmarking to other commercially built database products. Now that would be the complete comparison.

    As strong proponent of MySQL, I'd be very curious to see how it stacks up in those regards.

  3. Stanford Checker by eddy · · Score: 4, Interesting

    Anyone know how this one is faring? Will it ever be released? It's based on GCC, right? How many students can it pass between until it's "distribution"?

    The reason I'm asking is because I saw that one member of the team has jumped over to a company called Coverity where one can read:

    Originally developed by a team of researchers in the Computer Systems Lab at Stanford University, Coverity's patent-pending source code analysis technology successfully detected over 2000 bugs in Linux including hundreds of security holes.

    I just think it'd be horrible if they used the GPL'ed GCC to develop their methods (having access to a full portable compiler onto which to do research and development is hardly a "small thing"), and then lock these same methods away from the community.

    I'm grateful for their work on checking linux, but really... this smells bad, IMHO.

    (If you don't know what I'm taking about, don't assume it's off-topic, okay? The Standford Checker is a related topic to the Reasoning analysis of MySQL, and I'm not sure we'll ever have a _better_ fitting topic to discuss this)

    --
    Belief is the currency of delusion.
    1. Re:Stanford Checker by Error27 · · Score: 4, Interesting

      I wrote a similar tool to the Stanford Checker called smatch.

      I post the bugs and stuff that it finds on kbugs.org. The most recent kernel that I've posted is 2.6.0-test11.

      One thing that I was working on a couple weeks ago was invalid uses of spinlocks. Here are my results from that. I found quite a few places that don't unlock their spinlocks on error paths etc.

  4. As John Carmack put it... by rafael_es_son · · Score: 5, Interesting

    The main difference between open and *MOST* closed code is the fact that the early release of closed code means mucho mas money to corporate pigs and dogs, thus, proper requirements analysis, design, coding and testing are usually pummeled in the name of happy-go-lucky capitalism. "It will be ready when it is ready." -Carmack "I love America!" -Murphy

    --
    HAD
  5. Re:Duh! by I8TheWorm · · Score: 5, Interesting

    I've used mySQL, Oracle, MS SQL, DB2, and MSDE. I'm not sure I get your comment about MS SQL server. Like any other RDBMS, a little performance tuning goes a long way. As a matter of fact, until Oracle's release of 10g, MS SQL beat all commercial offerings in the TPC benchmarks.

    MS has a buggy os and an awful model for business practice, but I think MS SQL server is a fairly nice offering. It's too bad it only runs on Windows servers though.

    --
    Saying Android is a family of phones is akin to saying Linux is a family of PCs.
  6. Must have been baaad commercial code then.. by jordan · · Score: 4, Interesting

    Because there are portions of the MySQL code that are just painful to look at.

    Take for instance the part that takes as input the key index size and calculates internal buffer sizes. The option's size is an unsigned long long, but they cast it to an unsigned long all over the place, do in-place bitshifting on the cast (and cause it to wrap -- try specifying 4G for your key index sometime and you'll get 0), and the quality of code in that case is just painfully horrible to look at or even figure out what it's doing.

    I could only shudder to think what the quality of the commercial product looked like, in comparison. Hell, I'll have nightmares if I consider the quality of MySQL++ as a comparison..

    --jordan

  7. Re:Debatable scale by Zathrus · · Score: 4, Interesting

    Faults per 1000 lines of code may seem like a valid scale, but I think it is indicatory at best, not proof.

    It's actually a really miserable scale because of your 3rd point. If they ran the code bases through something like cindent and standardized the code formatting and removed all comments and whitespace then it's a somewhat more valid comparison. I didn't look at the actual research paper -- maybe they did. Odds are, your other two points are valid though.

    Additionally, they only say that the commercial code is "comparable". What does that mean (again, maybe answered in the paper)? Do they have roughly the same features? Are the query optimizers of roughly the same quality? Do they support the same platforms? I can't think of a major commercial database that doesn't exceed MySQL in all of these areas (ok, excepting SQL Server which fails on the 3rd only). Maybe it was a minor player in commercial databases. Dunno.

    These are the kinds of points that are raised when someone bashes OSS. There's no reason that they shouldn't be raised when the inverse is true as well. MySQL has progressed nicely and is worthy of consideration for light to moderate database loads now, I don't question that. All I'm saying is don't take things at face value.

    So, small victory, but the race goes on.

    The nice thing is that this is small and succinct -- it's suitable for showing to upper level management. That's a big win IMHO -- because normally the text bites they read are biased against free/open software.

  8. Re:Now apply to IE patches.... by thebatlab · · Score: 3, Interesting

    That open source patch was quite shoddily and hastily written. It wasn't even a patch really. Using it as representative of open source is not fair in any way whatsoever to other successful open source products.

    "Now apply the 'Rule of 6 times' to Microsoft's closed source IE patches..."

    There is no 'Rule of 6 times'. An analysis concluded that MySQL had a very limited number of defects in their code base. Kudos to them. This doesn't define a rule to be used in the open source vs. closed source holy war.

  9. MySQL and Commercial Licenses by Anonymous Coward · · Score: 3, Interesting

    I'm a little confused. I thought I understood how to make profit with the GPL, but now I'm not sure.

    MySQL GPL'ed all their products. (presumably so they could get developers and bug-fixes to their product for no charge.) However, they offer "commercial" licenses for people who want to integrate MySQL into their software, but don't want to GPL it. How can they do that? Presumably, any improvements/bugfixes/modifications that came from the community would be GPL, and therefore cannot be re-integrated under a more restricted license. I'm a little confused here. How can they take code that has been released under the GPL and turn around and release it under a more restrictive license?

  10. Re:If you would RTFA... by Dun+Malg · · Score: 5, Interesting
    they quantified it by dividing verified defects by lines of code.

    Problem with that is that it assumes the same "code density". Granted, it's probably not going to differ by a factor of six, but remember the old question about programmer productivity:
    who's more productive: the coder who solves a given problem with 100 lines of code written in one hour, or the coder who solves it with 10 lines in two hours?

    I mean, simple stuff like doing this:

    bool function(int i);
    main(void)
    {
    int i;
    if(function(++i))
    //blah blah blah
    }
    ...instead of:
    bool function(int i);
    main(void)
    {
    int i;
    bool foo;
    foo = false;
    i++;
    foo = function(i);
    if(foo)
    //blah blah blah

    }

    ...will give you a threefold difference in line count (specifically counting lines in the main() function). Throw in an identical line using malloc in each, both forgetting to free it later, and you've got a "bug density" of .33 for the former, and .14 for the latter. Heck, you could have two un-freed malloc's in the latter an it'd still only be at .25! I'm not saying the study is wrong-- I'd rather have the code out where I can see it, no matter WHAT the "bug density"-- I'm just saying that I wouldn't take any statistic that is derived using "lines of code" as a variable as a serious, hard number.
    --
    If a job's not worth doing, it's not worth doing right.
  11. Re:If you would RTFA... by neelm · · Score: 3, Interesting

    So what you are saying is you would rather have your DB crash over not supporting some feature in a way which is only applicable in select situations?

    As a real world programmer (versus someone living in an academic world of theory) I prefer the what-I-have-works-and-I'm-Working-on-the-rest approach. In the real world, stability and performance are paramount to feature set. Also, when you consider the domain of creating web driven applications, some features of a DB become less important because the stateless nature of a http connection. Server-side cursors don't do well in a cookie.

    > MySQL may be well-written, but it's still a piece of crap by the standards of any professional DBA.

    Which is why I give little attention to certifications.