lkml.org 
[lkml]   [2000]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Date
FWIW, although this is an interesting theory, in my experience, having a
good kernel debugger allows me *more* time to think clearly, rather than
less. YMMV.

IMHO, the division of labor between man and computer should be that each
does what they are best at. In the case of debugging, this means letting the
machine do the bookkeeping things that debuggers are good for.

The best course is being able to solve the problem from first principles
from a problem description and the source code. But there are plenty of
time when the problem description is ambiguous, or the source code is
someone else's but I need a fix anyway, or any of a thousand other reasons
why I end up using a debugger.

After all, if there is any science in "computer science", it is empirical
science, and the debugger is a lab tool that allows me to quickly test
hypothesis about the source of the problem.

It has also never been my experience that taking longer to scope out the
problem leads to a better fix. Quiet the contrary, especially when under
time pressures. The sooner I can figure out what *is* broken, the more time
I have to think about how best to fix it.

While it may be true that (some) people spend more time thinking when they
are debugging without a debugger, it is probably also true that most of that
thought amounts to trying to figure out how to get the visibility the
debugger would have given you.

marty

-----Original Message-----
From: David S. Miller [mailto:davem@redhat.com]
Sent: Monday, September 04, 2000 5:04 PM
To: jmerkey@timpanogas.com
Cc: alan@lxorguk.ukuu.org.uk; jes@linuxcare.com;
linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for
Linux

Date: Sat, 02 Sep 2000 15:58:50 -0600
From: "Jeff V. Merkey" <jmerkey@timpanogas.com>

I can only assume the reason for this is one of control, and that
there are no valid technical reasons for it. I have spent more
nights with printk() than I care to.

And I bet the lessons learned and the issues involved in those nights
with printk will never leave your brain, you will remember precisely
in the future next time you see the same types of symptoms what kinds
of things to look for and where.

This is what a debugger does not do for you. The debugger allows you
to be lazy, step around, "oh yeah check for NULL" and never have to
_think_ about what you're doing or the changes you're making or even
if the same bug might be elsewhere.

This is why Linus does not allow a debugging facility like this into
the kernel, so people spend time _thinking_ when they go hunting down
bugs.

It takes longer to nail a bug, yes, but the resulting fix is always
far superior. And the person who discovers the bug leaves with a much
larger amount of knowledge about how that area of the kernel works.

Later,
David S. Miller
davem@redhat.com
-
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/
-
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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.027 / U:0.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site