Open Code Has Fewer Bugs 337
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."
Ooh baby (Score:4, Funny)
Re:Ooh baby (Score:4, Insightful)
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.
Re:Ooh baby (Score:2)
If you're one of the latter group: RedHat includes an option to individually select which packages are installed. You are fully within your rights to select nearly nothing.
Oooh, wait... Did I just respond to a troll? Doh!
Hmmm... (Score:3, Funny)
Re:Hmmm... (Score:2, Insightful)
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.
Re:Hmmm... (Score:4, Insightful)
Re:Hmmm... (Score:3, Insightful)
Too many cooks spoil the broth!
Re:Hmmm... (Score:4, Funny)
This begets competition, back-porting, and maybe even eventual convergence.
Re:Hmmm... (Score:3, Interesting)
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?
Or... (Score:5, Interesting)
Coding for the end result = quality
Coding for a living = paycheck
Any questions?
Re:Or... (Score:3, Insightful)
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.
Re:Or... (Score:3, Interesting)
Circumstantial half-assing (Score:3, Insightful)
Maybe, maybe not (Score:5, Funny)
After seeing this [ioccc.org], I think that statement is being a bit generous
Re:Maybe, maybe not (Score:2, Funny)
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
Statistics (Score:5, Insightful)
Re:Statistics (Score:5, Interesting)
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.
Re:Statistics (Score:2)
Re:Statistics (Score:3, Informative)
I believe you're referring to the fuzz papers [wisc.edu]. They basically threw a bunch of random garbage at different commands and then watched for core dumps.
Comment removed (Score:5, Informative)
In other news (Score:4, Funny)
Bears are found to sh*t in woods
Title of post misleading (Score:5, Insightful)
I get it (Score:3, Funny)
Bill Gates: bugs are cool.
Ergo, open source is not cool!
Oh boy... (Score:2)
and to them I say...
Someone's boxen is only as secure as their updates go...Not all m$ boxes are as secure as linux boxes and vice versa. End it there.
oh...read the article too...it's not even about m$
Re:Oh boy... (Score:2)
So the conclusion is not OpenSrc/ClosedSrc
Its Linux TCP/IP stack contains less bugs than the FreeBSD one.
A little off topic? (Score:2)
Its also kind of strange that they don't even disclose what they compared Linux (kernel 2.4.19) to. Not really a big selling point for Linux. Oh wait its free
On a side note, I would like to see the
But aren't TCP/IP stacks mostly BSD? (Score:5, Interesting)
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
Yes, but the code has diverged. (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.
Re:Yes, but the code has diverged. (Score:5, Insightful)
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.
Re:Yes, but the code has diverged. (Score:5, Interesting)
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.
Linux IP stack a complete rewrite (Score:4, Informative)
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
Re:Yes, but the code has diverged. (Score:5, Informative)
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.
Re:Yes, but the code has diverged. (Score:3, Interesting)
Re:But aren't TCP/IP stacks mostly BSD? (Score:5, Insightful)
"The Linux" (Score:5, 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.
Re:"The Linux" (Score:2)
The awesome grammar. The MSNBC-CNET.COM.COM is obviously very focused on quality content.
Re:"The Linux" (Score:2)
-sirket
Re:"The Linux" (Score:3, Funny)
Re:"The Linux" (Score:2)
Bah. (Score:5, Interesting)
"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).
State the bleeding obvious. (Score:2, Interesting)
So why should any of this article be a suprise or even particulary note worthy?
Re:State the bleeding obvious. (Score:3, Insightful)
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.
No Suprise There (Score:5, Insightful)
Re:No Suprise There (Score:5, Insightful)
Re:No Suprise There (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.
Re:No Suprise There (Score:5, Insightful)
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 =]
Re:No Suprise There (Score:5, Insightful)
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
Re:No Suprise There (Score:2)
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.
as for that, doh, i was just shoting off my mouth...it's too early in the day and I hate using this crap system. =]
Re:No Suprise There (Score:5, Interesting)
Basically, the business logic goes something like this:
We can build your application in one of two ways.
- $5000 for proprietary products (app servers, IDEs, etc.), and $5000 for our time and effort (total = $10000), or...
- $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.
Re:No Suprise There (Score:5, Interesting)
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.
I disagree. (Score:2)
A) Linux is percieved as being a worthy task of a "hacker" (e.g., elite, low level, etc)--as opposed to, say, a word processing suite or one of the many mundane but important features that may save users millions of hours.
B) It is so popular for users and such an exclusive focus, you can be sure that a significant contribution will be seen by many geeks, again, unlike a word processing suite
C) Because it is relatively small, especially if you throw out all the drivers and the experimental stuff, and leave it to things like the very popular TCP/IP stack (which was reviewed in this article)
Linux and some of its associated code are very good in some respects as a result of their incremental improvements and bug fixes. The trouble with this is that when you significantly expand the scope of Open Source efforts things start to fall apart. In such a relatively unstructured environment as the popular open source method, i.e., little to no centralized development/testing/etc, there is every reason to believe that the overlap is key. In other words, since there is really no official QA or group of individuals that can be told or expected to methodically test, evaluate, or fix areas, the open source community essentially depends on random overlap. When you have a sparse group of competent developers or testers, you will run into trouble, as in the case of word processors. Likewise, when you depart from the relatively well established world of the kernel, when you start having to develop everything, not just the code, but the framework, the UI, the API, etc, from scratch the dependence on overlap becomes more and more of an issue. It's one thing to accept the a small patch for a well established tcp/ip stack, it's another thing entirely to have to coordinate the changing of a whole API, to make multiple pieces fit together seamlessly, without a more concrete organization (which can just barely happen in the manner popular open source development method).
Code review is a good thing, in and of itself, if nothing else, for its ability to make those many incremental enhancements and bug fixes. From a strictly technical perspective "open source" code can work as addititive, i.e., you develop, say, your Word processor with a more traditional software group, and then you allow the public to contribute. THe trouble with that is that for most code there simply isn't a viable business model that can support that sort of development effort, or at least, I don't see one and none of the current methods really compute, and as a result open source fails to deliver. I think that there are areas where open source code can thrive. For instance, I'd love to see IBM and a coalition of other software and hardware companies band together to make Linux (or some other kernel) into a complete OS that is every bit as easy to run as Windows and more stable, flexible, etc. It'd be good for everyone involved (except for MS of course) and it's quite doable. However, except for cases like that, where you have a very definite common good, i.e., a reasonably priced OS/API that allows strong and equal footing for 3rd party developers and manufacturers, there simply isn't a formula to actually pay for development. Consequently, open source will not produce better code by and large.
Something we all knew .. (Score:4, Insightful)
Re:Something we all knew .. (Score:2)
The more points of view you apply to solving a problem, the quicker, and better you'll solve it.
"Better?" Maybe. "Quicker?" Definitely not. If you've even been to a single high level design review, you'd know that not only does everyone have their own opinion, but they all adamently believe theirs is the only right way to do it. And they'll fight with you and argue for hours trying to convince you that their way is better than yours, John's, and Ted's. Meanwhile, Ted can't believe that John would propose something so stupid, and John thinks your idea will be a memory hog.
So where does the "quicker" part come in?
Also, I would like to refute the idea that open source projects have all these eyes scouring them. There are a helluvalotta mothballed projects on SourceForge that looked pretty cool, but there's no interest in them. Sure, there are quite a few people actively working on the latest-and-greatest, bleeding-edge Apache mods, and kernel patches, but does anyone care about the Widget Formatter that *my* company needs? No. But throw a little money behind it, and you can have 2 or 3 developers working on it, full time, who will produce software *exactly* to your specification, not just how some programmer in New Zealand thinks it shoud work, in his opinion.
Claim is too general (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...Re:Claim is too general (Score:2)
Personally I use mostly Microsoft software and have experienced many bugs in it, but have yet to contribute 1 single patch or even file a bug report. Who dares when as soon as you pick up the phone they start talking about how much you want to spend today!?
As for open source I have contributed development and/or patches to
JHotDraw
PMD
Netbeans
Java
And I have made specific bug reports on many more open source projects like
Linux sound drivers
XDoclet
I tried unsuccessfully for about 2 years to get a simple but tremendously annoying bug fixed that really affected the usage of VisualCafe.(switched to JBuilder then Netbeans)
I have done these things only for my own personal benefit in general. Yet the open source products have benefited, while the closed source ones have not.
Re:Claim is too general (Score:3, Insightful)
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.
number doesn't matter (Score:4, Insightful)
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.
Open code is only Linux? (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.
Stating the obvious (Score:5, Informative)
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).
Not sure if I believe this (Score:2)
As for Linux beating one of two "special purpose" networking products, the flip siding of beating one of two is that one of two of the commercial OSes was superior to Linux.
If they found them, I hope they reported them. (Score:2)
What I'd love to see is: If all of the significant defects found were reported, how many *still* exist 1 month later.
Fiar Comaparision? (Score:2)
I am sure those guys are alot smarter than I, but I am a little confused on testing.
Anyone?
Misleading in terms of project selection (Score:3, Insightful)
If they would compare the implementations of something less popular, the numbers MIGHT be different. x.25 or something.
Re:Misleading in terms of project selection (Score:2)
I am skeptical of the results (Score:3, Insightful)
Space shuttle code is closed (Score:5, Insightful)
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.
I'm sure Bill will be pleased to hear (Score:3, Funny)
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
Re:Space shuttle code is closed (Score:2)
I'll believe it when I see it.
yeah right (Score:3, Insightful)
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.
Re:yeah right (Score:3, Informative)
There is also an article about this here [zdnet.co.uk].
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.
Now try the same with CIFS (Score:2, Interesting)
Not about Microsoft! (Score:3, Informative)
Why that component? (Score:5, Insightful)
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.
any kernel patches come from this? (Score:5, 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?
But Bugs are Cool! (Score:3, Funny)
Were they testing code from 7 years ago?
This only makes sense. (Score:5, Insightful)
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
Let's think about this... (Score:4, Insightful)
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.
Which is the cause and which is the effect? (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.
Re:Which is the cause and which is the effect? (Score:3, Funny)
Great news! (Score:4, Interesting)
Comment removed (Score:5, Insightful)
This study can't tell how many bugs there are (Score:5, Insightful)
This looks like a publicity stunt by the Reasoning folks.
Fewer Errors in TCP/IP Stack? (Score:4, Insightful)
Re:Fewer Errors in TCP/IP Stack? (Score:3, Informative)
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.
Is age the key factor? (Score:5, Interesting)
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.
Already Analyzed (Score:5, Informative)
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.
But is Open Source the way to go (Score:2, Insightful)
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.
and... (Score:2, Redundant)
Open Source has no deadlines ... (Score:2, Interesting)
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.
Makes sense... (Score:3)
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...
It is natural . . . (Score:4, Insightful)
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.
upgrade maybe? (Score:2, Informative)
"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. "
Re:Fewer bugs than what? (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
Re:Fewer bugs than what? (Score:2)
Re:in other news.... (Score:3, Interesting)
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.
Re:in other news.... (Score:3, 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!
Re:in other news.... (Score:4, Insightful)
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.
Re:in other news.... (Score:3, Interesting)
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!
Re:in other news.... (Score:3, Insightful)
I agree!
No, I mean it's written by people without experience architecting large projects, so the result is verbose, brittle, and messy. Period.
Re:Big surprise, really. (Score:2, Funny)