Open Code Has Fewer Bugs

Ooh baby by Anonymous Coward · 2003-02-20 02:17 · Score: 4, Funny

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

Re:Ooh baby by Anonymous Coward · 2003-02-20 03:11 · 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.

Maybe, maybe not by Raul654 · 2003-02-20 02:18 · 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

Statistics by Caractacus+Potts · 2003-02-20 02:19 · 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.

Re:Statistics by Xtifr · 2003-02-20 02:42 · 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.
Re:Statistics by dglo · 2003-02-20 03:23 · 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!

In other news by asmithmd1 · 2003-02-20 02:20 · Score: 4, Funny

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

--
Free cell phone tracking

Title of post misleading by jfrumkin · 2003-02-20 02:21 · 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

But aren't TCP/IP stacks mostly BSD? by mccalli · 2003-02-20 02:22 · 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

Re:But aren't TCP/IP stacks mostly BSD? by gurps_npc · 2003-02-20 03:18 · 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

"The Linux" by sczimme · 2003-02-20 02:23 · 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.

Bah. by KefkaFloyd · 2003-02-20 02:25 · 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).

No Suprise There by Greyfox · 2003-02-20 02:26 · 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?

Re:No Suprise There by syle · 2003-02-20 02:39 · 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
Re:No Suprise There by mrpuffypants · 2003-02-20 02:42 · 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 =]
Re:No Suprise There by Rary · 2003-02-20 02:58 · 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
Re:No Suprise There by mccalli · 2003-02-20 03:13 · 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
Re:No Suprise There by Rary · 2003-02-20 04:43 · 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

Something we all knew .. by phuturephunk · 2003-02-20 02:27 · 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..

Claim is too general by Peter_Pork · 2003-02-20 02:27 · 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...

Stating the obvious by seanadams.com · 2003-02-20 02:30 · 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).

Space shuttle code is closed by MondoMor · 2003-02-20 02:35 · 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.

Why that component? by DeadSea · 2003-02-20 02:40 · 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.

any kernel patches come from this? by dido · 2003-02-20 02:40 · 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.

Re:Fewer bugs than what? by LizardKing · 2003-02-20 02:49 · 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

This only makes sense. by SatanicPuppy · 2003-02-20 02:51 · 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.

Yes, but the code has diverged. by Jimithing+DMB · 2003-02-20 02:54 · 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. by Eccles · 2003-02-20 04:23 · 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.
Re:Yes, but the code has diverged. by Bodrius · 2003-02-20 05:04 · 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...
Re:Yes, but the code has diverged. by Abcd1234 · 2003-02-20 05:16 · 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.

Which is the cause and which is the effect? by Skapare · 2003-02-20 02:59 · 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

Comment removed by account_deleted · 2003-02-20 03:07 · Score: 4, Insightful

Comment removed based on user account deletion

Fewer Errors in TCP/IP Stack? by zimmermantech.com · 2003-02-20 03:15 · 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

Is age the key factor? by realnowhereman · 2003-02-20 03:23 · 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

Re:in other news.... by CrayzyJ · 2003-02-20 03:34 · 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!

Already Analyzed by Euphonious+Coward · 2003-02-20 03:49 · 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.

Or... by intermodal · 2003-02-20 04:49 · 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!

Linux IP stack a complete rewrite by maynard · 2003-02-20 05:16 · 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

38 of 330 comments (clear)