Messages in this thread |  | | Date | Wed, 6 Sep 2000 21:21:50 -0400 (EDT) | From | Gregory Maxwell <> | Subject | Re: Availability of kdb |
| |
On Wed, 6 Sep 2000 lamont@icopyright.com wrote:
[snip] > I guarantee you that IT managers and CTOs do not share your enthusiasm for > slow, correct coding when faced with their business being down, their > revenue stream being interrupted and their stock options losing value. [snip]
No company should have to face that sort of problem, any problem that severe should be easily found in preproduction testing. Linux'es low-cruft level usually causes pretty consistent and testable behavior, once it works it tends to keep working. Additionally, any problem so severe and repeatable to cause such problems should be easily fixed with or without a debugger.
I've seen an example of a fast bugfix from a company with a wonderful in-kernel debugger.
When the teardrop became common, Microsoft used their wonderful debugger to find a great point to insert a 'if packet looks like this' filter. They didn't fix the problem in their initial patch. They inserted a fast non-fix, the kind of behavior encouraged by debuggers (fix the symptom, not the problem). Just a few days later, they were being crashed again by a minor variant of the same bug.
Linux on the other hand, had a true fix and were not subject to the revised attack. (Incidentally, Linux's true fix came out before MS's quick patch).
Quick fixes bring about quick cruft. The 'expense' of maintain code grows exponentially with it's cruft level. A 'slower' fix today will likely improve long term sustainablity.
Finally, who says that acceptance by 'IT managers and CTOs' is actually a measure of 'quality' that anyone here finds interesting or acceptable? The very fact that many 'IT managers and CTOs' find NT acceptable speaks volumes to counter the credibility of that as a useful product metric.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |