I would be interested in a book about the lifecycle of the Linux kernel source; that is, how bugs are reported and fixed, distribution approaches, discussion forums, fix approval procedures, debugging procedures, etc. Is there such a book? This one appears to be completely technical in its approach.
That would indeed be a concern, if not for the fact that machines require energy. Gray goo would not only need to replicate itself; it would need to extract energy from the environment. No one knows how it could do that on a large scale, or if. Photosynthesis is a slow way to conquer the world.
Consider that it takes an entire multinational industrial system to provide the power to a single tank and then ask yourself how much we need to worry about gray goo.
In the la-la land of nanotechnology, little concerns like power source and heat dissipation are not interesting enough to consider, compared with fanciful speculations about Fantastic Voyage cell repair robots and smart mists.
Of course, the first reason, is that "free" as applied to so-called "Free Software" has nothing to do with monetary cost, but the freedom to modify and redistribute code.
I was referring to a specific claim made in the article under discussion, which I quoted: "All of the alternatives mentioned above are completely free. If a new version of Debian comes out, you can download it without charge." I am aware of arguments made by RMS and others that the word "free" is not supposed to refer to payment. However, large segments of the free and open source communities are continuing to falsely insist that Linux is free in the commerical sense -- which it is not. A serious, pre-integrated, cross-platform Linux package such as RedHat will cost you the same as Windows or MacOS.
Second, I've been through 3 linux distributions, and not paid a penny for any of them.... On a cable modem, I downloaded the Redhat and Slackware current ISO images in just about 6 hours each. This was not wasted time, though, since I left my computer downloading the images while I attended classes, and came back to find them waiting for me.
Using the RedHat list of mirror sites, it took over two hours to even find a working mirror; the vast majority are broken or require a user account. I have just now tried a random sampling to confirm that this is still the case, and it is. There are a handful of sites on that long list that actually work and are open to the public, but it takes quite a long time to find out which ones they are; and once you do find them, half the connections terminate in the middle and have to be restarted by hand, requiring a babysitting process.
If you actually have a way to reproduce the six-hour hands-off anonymous download, feel free to share it here. I don't believe that you do.
Furthermore, not once have I had to restart a download, and none of the servers have choked.
Then you must be using some very special server, rather than one on the Red Hat mirror site list. It would be good to know what server that might be, but it doesn't change the fact that this arcane knowledge is not something that is accessible to the average end-user.
As far as TCO, a term I'm sure Microsoft has perverted far beyond comprehension, your statements are simply not true. You must consider the TCO when you are running Linux (or some other Free UNIX) in the hands of an experienced administrator. Microsoft, and you, expect to calculate TCO from a vantage point of a skilled Windows administrator. They include training and general "figuring-out-time" in the cost of setting up a Linux system. What about training and "figuring-out-time" for Microsoft systems? If you insist that the Linux admin knows nothing about Linux from the start, you must assume the same about the Microsoft admin. But if you assume your admins are skilled in UNIX, installing Linux is trivial. (I should hope any company would be cautious switching operating systems when their administrators don't know about the new OS.) No matter what UNIX-like operating system an admin comes from, it is trivial to become acquainted with another one.
None of the above has anything to do with reality. You are unaware of the TCO differences between GUI and command-line software, and you are ignoring the flakiness of free software. As Monty Manley wrote:
A quick look at freshmeat.net lists the reams of software being written, most of it for Linux, and damned little of it unit-tested, much less system-tested. Will application x cooperate with application y? Will daemon x coexist peacefully with the MTA? Does application x fail gracefully? Odds are very good that the programmer didn't think about any of this, much less test for it, and expects his hapless users to do his QA for him.
Commerical software is at least tested. Use a free package for anything important and you may literally be taking your life in your hands. Everyone who has ever been a UNIX system administrator knows that Unices of any flavor generate problems on a daily basis and require constant tweaking to even keep running. The same has not been true of Windows systems for the last five years, and it was never true of MacOS systems. UNIX TCO is a disaster -- a disaster that is profitable to those who work as sysadmins.
Furthermore, in the hands of a skilled admin, installing software in Linux is trivial.
Simply not true. Most of the people who say this seem to be unfamiliar with current desktop systems. Guess what -- on MacOS and Windows you almost never have to mix and match versions to make sure your packages will play together, you don't have to hunt down trivial driver settings to make basic hardware like monitors and keyboards work, and you don't have to search all over the web to find the libraries you depend on before you can install. To the UNIX devotee, somehow these costs don't count, but looking at the situation objectively, they are a huge time drain for the administrator. And that time is real money.
Of course, most Free software is also free monetarily, which cuts the initial cost to 0.
If you don't have to pay your system administrator, and your own time means nothing to you, then this is true.
I never need to memorize manuals when installing software under Linux. I don't know why you expect this is necessary.
If you don't RTFM, you can't use the software, because it's not self-documenting. Every UNIX program requires training by self or others, whereas few GUI programs require training. Again, this is one of the TCO losses on UNIX which UNIX devotees think is actually a benefit.
The vast majority of software installation breaks down to little more than "./configure; make; make install", and often, the./configure part is not necessary.
That's assuming you have already spent hours resolving all the dependencies and version conflicts, and reading through README and INSTALL files to figure out which set of options you need to use.
Don't forget about package systems, either. RPMs and debs make software installation trivial, especially with a package management utility like apt. Software installation with apt is no more difficult than "apt-get install ", which automatically downloads packages, satisfies dependencies, sets up a default configuration, and drops you back at a shell.
It says a lot about your set of assumptions that you'd consider a cryptic command-line method of software installation "trivial." Have you ever opened a single book on user interface design? RTFM!
I will admit I have had to hack some makefiles in my day, but any experienced UNIX admin will have no trouble doing that.
You are admitting that just to install free or open software, you are faced with difficulties that would not arise on commercial platforms. Once again, these hidden costs somehow are waved away. To you they don't count, but in any objective TCO investigation they would loom large.
Plus, the advantage of being able to modify code far outweighs any benefit (I consider it a drawback) of a nice, "keep-clicking-next" install interface.
A benefit useful only to the.00001 percent of the human population that is made up of computer programmers.
There is real control in UNIX software installation, and little added difficulty.
Huge added difficulty. Contrast both difficulty and time consumed in changing a configuration file and rebuilding as against clicking a checkbox in a self-documenting preferences dialog.
We haven't even considered support costs. Microsoft Windows, a closed system, often has problems which are unsolvable by anybody but Microsoft. This means you must call them, and wait on the phone, to talk to somebody who probably doesn't know what he's doing anyway. Often times, you must repeatedly call, talking to a differnt person each time. To top it off, Microsoft charges for support calls after you've exceeded a certain number of calls. This gets expensive.
Not as expensive as a huge staff of on-call UNIX sysadmins 24/7, which is what it would take to maintain any significant network of end-user UNIX systems. If UNIX is confined to the back office then the support costs are probably about the same as for a Windows NT server network; but move it out to the end users and I would be surprised if support costs dodn't go up a factor of ten compared to a Windows or MacOS network.
An open system, like Linux, is much cheaper to troubleshoot.
Only if the software is of the same basic quality level, which it isn't, due to the lack of testing in most free or open source software.
Attitudes are important in troubleshooting, too. Linux, being an open system, harbors a community phenomenon that Microsoft Windows just can't sustain. People who use linux feel like part of a tightly-nit, minority group, and are therefore much more willing to help, without expecting something in return.
More of a closed community of obnoxious losers who desperately need to get a life out in the real world, from what I've seen. To quote Manley again, "Linux, more than any other OS, suffers from a surfeit of testosterone-poisoned young men who know little but speak much.... They are, in a word, punks. And Linux has far too many of them."
In pragmatic terms, anyone who wanders into this community of obnoxious young hackers asking for help is likely to be immediately accused of stupidity, have "RTFM" and less polite terms screamed at them, and otherwise face social conditions that the vast majority of the population would find intolerable. Not this closed community, though -- it loves to flame newbies.
You were right about it not being about money, though. Still, Linux can be totally monetarily free, and cheaper in man-hours than any Microsoft or Apple product.
Assuming we simply ignore all the hidden costs, it certainly can.
However, I don't think most LINUX advocates are trying to be deceitful by covering up the costs. Like Windows 3.1 users, they honestly don't realize there's a better way -- they really think it ought to take hours to install a piece of software. It's sad, especially since better ways have been in mass distribution for more than fiteen years now.
(Oh, to respond to one of the flames in your message: Both my download and CD installs of Linux were successful. I learned to kernel hack on BSD on a Sun I at C-MU back in 1984, and have worked as a UNIX administrator.)
Of the many false myths beloved of fans of free and open source software, the most persistent is summed up in this statement from the article in question: "All of the alternatives mentioned above are completely free. If a new version of Debian comes out, you can download it without charge."
This is false. It is virtually impossible to install a Linux distro by downloading. The servers choke and the downloads have to be repeatedly restarted; it takes over ten hours of manual labor on a fast line if you do manage to do it at all; and the installation instructions distributed for free apply only to the CD-based versions. Try going on to #linuxhelp and ask for help installing a downloaded copy -- people will tell you they have never heard of such a thing.
So how much do the CDs for this "free" operating system cost? Not much, just about seventy to eighty dollars for RedHat -- which is, of course, within spitting distance of what you'd be charged for a copy of MacOS or Windows. Somehow, this "completely free" operating system appears to cost just as much as the supposedly expensive proprietary ones.
So far, this is based purely on cash outlay considerations. If you take into account total cost of ownership, the equation is even worse, because free software was explicitly designed for a high support cost business model. As Stallman said in the 1980's, most UNIX people earn their dough as system administrators, and free software (together with its open source descendants) is set up to keep those people in business. It does that by creating costs in TCO, specifically personnel costs in system administration. Just installing a new piece of software on Linux can easily take over a day, between memorizing the manual, reconciling version mismatches, finding the right compile-time options, rebuilding the software, and dealing with configuration issues. The same software on MacOS or Windows might cost a few hundred bucks up front but it would probably be up and running in less than an hour, without needing to memorize a manual. How much do you make an hour? Do the math and tell me which way is cheaper. You only win if someone is paying you to install it for them.
A free operating system is just as expensive up front as a for-pay operating system. So-called "free" software is more expensive than for-pay software from a total cost of ownership perspective due to the high-support-cost assumptions embedded in the way free software is written. It's not about money and it's false to say it is. Hackers like free software because they like hacking on it, not because it's cheap in any real sense.
I don't understand why the point 12.1(c) was retained.
12.1Termination. This License and the rights granted hereunder will terminate:
(c)automatically without notice from Apple if You, at any time during the term of this License, commence an action for patent infringement against Apple.
I can't see why a good attorney would allow an organization which owned patents to become dependent on any APSL software given this clause. Suppose Apple _does_ infringe one of the organization's patents; this clause denies it any recourse. The effect is that if one is dependent on APSL software then one has granted Apple a permanent royalty-free license to all one's patented intellectual property.
Expecting someone to read documentation on how security protocols work before using Amazon does not reflect conditions in the real world. Manuals have been obsolete for the average end user for years now. No one reads documentation except engineers, and they usually only read it for projects they are working on.
I think it's strange that people can't see the basic difference in complexity and transparency between the algorithm of a public key authentication mechanism and turning a key in a lock. Again, there is a basic failure to grasp the difference between how engineers think and how ordinary people think.
I don't mean any offense, but I think your message is a good example of failing to understand the difference between engineers and non-engineers. Do you really imagine that end users can or would read a protocol specification? A non-engineer outside the security community doesn't have the faintest idea what a host key is or how an authentication protocol works. Asking them to do so would be like asking them to understand how a lock works internally in order to use their front door.
This thoughtful piece is appreciated, but I feel it misses the mark. A common error of engineering specialists is to assume that their expertise is accessible to the average user. It is simply not realistic to frame the issue as "user and sysadmin awareness of their responsibility to maintain the SSH known-hosts lists, configure client behavior in accordance with a considered security policy, and think carefully before overriding security warnings about changed or missing host-keys." No non-engineer outside the security community would even be able to understand this issue; it's rather like expecting everyone with a locking front door to perform their own locksmithing. If that is what is required, then in the real world what we have is a radically insecure protocol that only provides security for a small cadre of specialists. In fact, by providing a veneer of protection, it creates a false sense of security which can easily be preyed upon.
I don't know where Henri J. Schlereth got the 2500 figure. I took his word since he identified himself as a member of the RedHat Beta Test Team. The actual outstanding bug count for Red Hat Linux is 1551. The number of fixed bugs is much higher than 2500.
Bug Report for Red Hat Linux
Tue Oct 3 13:24:09 2000
Summary
New Bugs This Week 194
Bugs Marked New 879
Bugs Marked Assigned 606
Bugs Marked Reopened 66
Total Bugs 1551
The Debian number is several times that, which I think probably indicates better reporting on the Debian side rather than a buggier distro or worse bug screening.
The doctrine that open source software is higher quality than proprietary software is a relic from a time before anyone was tracking bugs in most open source software. The community simply decided to inform itself that it was doing a great job, apropos of nothing. The single metric that was cited during those times was the infrequency of kernel crashes -- but there's a lot more to software quality than how often the OS crashes. The open source community's quality standard comes from the UNIX world, which has long been content with finicky systems in need of constant tweaking, and in which most of the members of the community were supported financially by the fact that the quirkiness of the systems kept them employed as system administrators.
Now that some open source projects use bug tracking, it's become clear that the actual defect curve of large open source software shows an ever-increasing number of bugs, not the "shallowness" predicted by Eric Raymond in his religious essay. We can see that, just as with his claim that open source projects manage themselves, he was mistaken.
This is not a judgment call; it's demonstrated empirically by two of the main Linux distros (Red Hat and Debian) and by Mozilla. However, like any religionists, the open source community responds to empirical evidence against its dogma either by ignoring it or by flaming it. If open source is really to enter the mainstream and become more than a set of quirky tools for system administrators, the open source community must come to terms with the facts about its quality problems and its management requirements. However, I am not expecting that to happen before creationists decide to accept Darwin.
The two overarching Raymondian doctrines of the open source movement are these:
- Open source doesn't need project management.
- All bugs are shallow given enough eyeballs.
The first of these was recently disproven, by simply pointing out that all successful open source projects use a strong management model.
The second is disproven by the lingering effects of thousands of bugs in every large open source project, such as Linux and Mozilla. The bug curves merely increase. Mozilla no longer supports their bug chart feature in bugzilla because the almost monotonically increasing curve was too embarassing. Debian and RedHat Linux distributions constantly grow in number of bugs.
And no, the bugs in the new distro are not all or mostly new; as this bug states:
the number of bugs for
7.0 that are new/open are 149. The rest of the other 2.500 bugs are spread out over previous releases and beta
test releases.
Henri J. Schlereth
RedHat Beta Test Team.
That is, nine out of ten of these bugs have already been out in front of the alleged pool of bug-fixing eyeballs for a significant time.
Bug fixing is hard and unrewarding work. Anyone who has led or managed engineers knows that it is often difficult to get them to clean up after themelves. In the open source world, nearly the only bugs that get fixed by people who are not paid to work on the project are the few high-profile status bugs -- the rest simply lie fallow, many for all time.
Slashdot Mirror
Tim
Tim
Consider that it takes an entire multinational industrial system to provide the power to a single tank and then ask yourself how much we need to worry about gray goo. In the la-la land of nanotechnology, little concerns like power source and heat dissipation are not interesting enough to consider, compared with fanciful speculations about Fantastic Voyage cell repair robots and smart mists.
I was referring to a specific claim made in the article under discussion, which I quoted: "All of the alternatives mentioned above are completely free. If a new version of Debian comes out, you can download it without charge." I am aware of arguments made by RMS and others that the word "free" is not supposed to refer to payment. However, large segments of the free and open source communities are continuing to falsely insist that Linux is free in the commerical sense -- which it is not. A serious, pre-integrated, cross-platform Linux package such as RedHat will cost you the same as Windows or MacOS.
Second, I've been through 3 linux distributions, and not paid a penny for any of them.... On a cable modem, I downloaded the Redhat and Slackware current ISO images in just about 6 hours each. This was not wasted time, though, since I left my computer downloading the images while I attended classes, and came back to find them waiting for me.
Using the RedHat list of mirror sites, it took over two hours to even find a working mirror; the vast majority are broken or require a user account. I have just now tried a random sampling to confirm that this is still the case, and it is. There are a handful of sites on that long list that actually work and are open to the public, but it takes quite a long time to find out which ones they are; and once you do find them, half the connections terminate in the middle and have to be restarted by hand, requiring a babysitting process.
If you actually have a way to reproduce the six-hour hands-off anonymous download, feel free to share it here. I don't believe that you do.
Furthermore, not once have I had to restart a download, and none of the servers have choked.
Then you must be using some very special server, rather than one on the Red Hat mirror site list. It would be good to know what server that might be, but it doesn't change the fact that this arcane knowledge is not something that is accessible to the average end-user.
As far as TCO, a term I'm sure Microsoft has perverted far beyond comprehension, your statements are simply not true. You must consider the TCO when you are running Linux (or some other Free UNIX) in the hands of an experienced administrator. Microsoft, and you, expect to calculate TCO from a vantage point of a skilled Windows administrator. They include training and general "figuring-out-time" in the cost of setting up a Linux system. What about training and "figuring-out-time" for Microsoft systems? If you insist that the Linux admin knows nothing about Linux from the start, you must assume the same about the Microsoft admin. But if you assume your admins are skilled in UNIX, installing Linux is trivial. (I should hope any company would be cautious switching operating systems when their administrators don't know about the new OS.) No matter what UNIX-like operating system an admin comes from, it is trivial to become acquainted with another one.
None of the above has anything to do with reality. You are unaware of the TCO differences between GUI and command-line software, and you are ignoring the flakiness of free software. As Monty Manley wrote:
Commerical software is at least tested. Use a free package for anything important and you may literally be taking your life in your hands. Everyone who has ever been a UNIX system administrator knows that Unices of any flavor generate problems on a daily basis and require constant tweaking to even keep running. The same has not been true of Windows systems for the last five years, and it was never true of MacOS systems. UNIX TCO is a disaster -- a disaster that is profitable to those who work as sysadmins.
Furthermore, in the hands of a skilled admin, installing software in Linux is trivial.
Simply not true. Most of the people who say this seem to be unfamiliar with current desktop systems. Guess what -- on MacOS and Windows you almost never have to mix and match versions to make sure your packages will play together, you don't have to hunt down trivial driver settings to make basic hardware like monitors and keyboards work, and you don't have to search all over the web to find the libraries you depend on before you can install. To the UNIX devotee, somehow these costs don't count, but looking at the situation objectively, they are a huge time drain for the administrator. And that time is real money.
Of course, most Free software is also free monetarily, which cuts the initial cost to 0.
If you don't have to pay your system administrator, and your own time means nothing to you, then this is true.
I never need to memorize manuals when installing software under Linux. I don't know why you expect this is necessary.
If you don't RTFM, you can't use the software, because it's not self-documenting. Every UNIX program requires training by self or others, whereas few GUI programs require training. Again, this is one of the TCO losses on UNIX which UNIX devotees think is actually a benefit.
The vast majority of software installation breaks down to little more than "./configure; make; make install", and often, the ./configure part is not necessary.
That's assuming you have already spent hours resolving all the dependencies and version conflicts, and reading through README and INSTALL files to figure out which set of options you need to use.
Don't forget about package systems, either. RPMs and debs make software installation trivial, especially with a package management utility like apt. Software installation with apt is no more difficult than "apt-get install ", which automatically downloads packages, satisfies dependencies, sets up a default configuration, and drops you back at a shell.
It says a lot about your set of assumptions that you'd consider a cryptic command-line method of software installation "trivial." Have you ever opened a single book on user interface design? RTFM!
I will admit I have had to hack some makefiles in my day, but any experienced UNIX admin will have no trouble doing that.
You are admitting that just to install free or open software, you are faced with difficulties that would not arise on commercial platforms. Once again, these hidden costs somehow are waved away. To you they don't count, but in any objective TCO investigation they would loom large.
Plus, the advantage of being able to modify code far outweighs any benefit (I consider it a drawback) of a nice, "keep-clicking-next" install interface.
A benefit useful only to the .00001 percent of the human population that is made up of computer programmers.
There is real control in UNIX software installation, and little added difficulty.
Huge added difficulty. Contrast both difficulty and time consumed in changing a configuration file and rebuilding as against clicking a checkbox in a self-documenting preferences dialog.
We haven't even considered support costs. Microsoft Windows, a closed system, often has problems which are unsolvable by anybody but Microsoft. This means you must call them, and wait on the phone, to talk to somebody who probably doesn't know what he's doing anyway. Often times, you must repeatedly call, talking to a differnt person each time. To top it off, Microsoft charges for support calls after you've exceeded a certain number of calls. This gets expensive.
Not as expensive as a huge staff of on-call UNIX sysadmins 24/7, which is what it would take to maintain any significant network of end-user UNIX systems. If UNIX is confined to the back office then the support costs are probably about the same as for a Windows NT server network; but move it out to the end users and I would be surprised if support costs dodn't go up a factor of ten compared to a Windows or MacOS network.
An open system, like Linux, is much cheaper to troubleshoot.
Only if the software is of the same basic quality level, which it isn't, due to the lack of testing in most free or open source software.
Attitudes are important in troubleshooting, too. Linux, being an open system, harbors a community phenomenon that Microsoft Windows just can't sustain. People who use linux feel like part of a tightly-nit, minority group, and are therefore much more willing to help, without expecting something in return.
More of a closed community of obnoxious losers who desperately need to get a life out in the real world, from what I've seen. To quote Manley again, "Linux, more than any other OS, suffers from a surfeit of testosterone-poisoned young men who know little but speak much.... They are, in a word, punks. And Linux has far too many of them."
In pragmatic terms, anyone who wanders into this community of obnoxious young hackers asking for help is likely to be immediately accused of stupidity, have "RTFM" and less polite terms screamed at them, and otherwise face social conditions that the vast majority of the population would find intolerable. Not this closed community, though -- it loves to flame newbies.
You were right about it not being about money, though. Still, Linux can be totally monetarily free, and cheaper in man-hours than any Microsoft or Apple product.
Assuming we simply ignore all the hidden costs, it certainly can.
However, I don't think most LINUX advocates are trying to be deceitful by covering up the costs. Like Windows 3.1 users, they honestly don't realize there's a better way -- they really think it ought to take hours to install a piece of software. It's sad, especially since better ways have been in mass distribution for more than fiteen years now.
(Oh, to respond to one of the flames in your message: Both my download and CD installs of Linux were successful. I learned to kernel hack on BSD on a Sun I at C-MU back in 1984, and have worked as a UNIX administrator.)
Tim
This is false. It is virtually impossible to install a Linux distro by downloading. The servers choke and the downloads have to be repeatedly restarted; it takes over ten hours of manual labor on a fast line if you do manage to do it at all; and the installation instructions distributed for free apply only to the CD-based versions. Try going on to #linuxhelp and ask for help installing a downloaded copy -- people will tell you they have never heard of such a thing.
So how much do the CDs for this "free" operating system cost? Not much, just about seventy to eighty dollars for RedHat -- which is, of course, within spitting distance of what you'd be charged for a copy of MacOS or Windows. Somehow, this "completely free" operating system appears to cost just as much as the supposedly expensive proprietary ones.
So far, this is based purely on cash outlay considerations. If you take into account total cost of ownership, the equation is even worse, because free software was explicitly designed for a high support cost business model. As Stallman said in the 1980's, most UNIX people earn their dough as system administrators, and free software (together with its open source descendants) is set up to keep those people in business. It does that by creating costs in TCO, specifically personnel costs in system administration. Just installing a new piece of software on Linux can easily take over a day, between memorizing the manual, reconciling version mismatches, finding the right compile-time options, rebuilding the software, and dealing with configuration issues. The same software on MacOS or Windows might cost a few hundred bucks up front but it would probably be up and running in less than an hour, without needing to memorize a manual. How much do you make an hour? Do the math and tell me which way is cheaper. You only win if someone is paying you to install it for them.
A free operating system is just as expensive up front as a for-pay operating system. So-called "free" software is more expensive than for-pay software from a total cost of ownership perspective due to the high-support-cost assumptions embedded in the way free software is written. It's not about money and it's false to say it is. Hackers like free software because they like hacking on it, not because it's cheap in any real sense.
Tim
12.1Termination. This License and the rights granted hereunder will terminate:
(c)automatically without notice from Apple if You, at any time during the term of this License, commence an action for patent infringement against Apple.
I can't see why a good attorney would allow an organization which owned patents to become dependent on any APSL software given this clause. Suppose Apple _does_ infringe one of the organization's patents; this clause denies it any recourse. The effect is that if one is dependent on APSL software then one has granted Apple a permanent royalty-free license to all one's patented intellectual property.
Tim
I think it's strange that people can't see the basic difference in complexity and transparency between the algorithm of a public key authentication mechanism and turning a key in a lock. Again, there is a basic failure to grasp the difference between how engineers think and how ordinary people think.
Tim
Tim
Tim Maroney
tim@maroney.org
Bug Report for Red Hat Linux
Tue Oct 3 13:24:09 2000
Summary
New Bugs This Week 194
Bugs Marked New 879
Bugs Marked Assigned 606
Bugs Marked Reopened 66
Total Bugs 1551
The Debian number is several times that, which I think probably indicates better reporting on the Debian side rather than a buggier distro or worse bug screening.
The doctrine that open source software is higher quality than proprietary software is a relic from a time before anyone was tracking bugs in most open source software. The community simply decided to inform itself that it was doing a great job, apropos of nothing. The single metric that was cited during those times was the infrequency of kernel crashes -- but there's a lot more to software quality than how often the OS crashes. The open source community's quality standard comes from the UNIX world, which has long been content with finicky systems in need of constant tweaking, and in which most of the members of the community were supported financially by the fact that the quirkiness of the systems kept them employed as system administrators.
Now that some open source projects use bug tracking, it's become clear that the actual defect curve of large open source software shows an ever-increasing number of bugs, not the "shallowness" predicted by Eric Raymond in his religious essay. We can see that, just as with his claim that open source projects manage themselves, he was mistaken.
This is not a judgment call; it's demonstrated empirically by two of the main Linux distros (Red Hat and Debian) and by Mozilla. However, like any religionists, the open source community responds to empirical evidence against its dogma either by ignoring it or by flaming it. If open source is really to enter the mainstream and become more than a set of quirky tools for system administrators, the open source community must come to terms with the facts about its quality problems and its management requirements. However, I am not expecting that to happen before creationists decide to accept Darwin.
- Open source doesn't need project management.
- All bugs are shallow given enough eyeballs.
The first of these was recently disproven, by simply pointing out that all successful open source projects use a strong management model.
The second is disproven by the lingering effects of thousands of bugs in every large open source project, such as Linux and Mozilla. The bug curves merely increase. Mozilla no longer supports their bug chart feature in bugzilla because the almost monotonically increasing curve was too embarassing. Debian and RedHat Linux distributions constantly grow in number of bugs.
And no, the bugs in the new distro are not all or mostly new; as this bug states:
That is, nine out of ten of these bugs have already been out in front of the alleged pool of bug-fixing eyeballs for a significant time.
Bug fixing is hard and unrewarding work. Anyone who has led or managed engineers knows that it is often difficult to get them to clean up after themelves. In the open source world, nearly the only bugs that get fixed by people who are not paid to work on the project are the few high-profile status bugs -- the rest simply lie fallow, many for all time.