check now
Linus has long had a dislike for interactive kernel debuggers. His position is that they lead developers to fix symptoms; he would rather they stare at the source and come to an understanding of the real problem.
Yeah, user-space GDB is a real drag also. Too many programmers use debuggers as a crutch, when it is obvious that simply staring at the source code is *so* much more likely to result in true enlightenment.
I always hate it when the hardware guys use logic analyzers, oscilliscopes, and simulators to find bugs in their designs. Obviously the correct way to verify or fix hardware designs is to stare at the Verilog code and schematics until your eyes bleed.
And when my car's engine is making a funny noise, I'm apalled when the mechanic actually looks under the hood and finds the problem immediately, rather than spending a few days thinking about what could cause that sound. It's hard to believe that using methods like that, anyone could develop a true understanding of what's going on in there.
Engineers today rely way too much on fancy-shmancy tools to help with their tasks. Back in the old days, we only had printf(), and WE LIKED IT. So what if it took weeks to fix obscure kernel bugs that with better tools could be found in days; the important thing is the process, not the results. Just like the "new math".
Of course, good engineers don't use time-saving tools like compilers, either. If the program is worth writing, it's worth writing in assembler. Or better yet, toggling in binary via the front-panel switches. (It's not a proper computer unless it has front-panel switches.)
Seriously, though, I don't understand why Linux thinks that debuggers "lead developers to fix symptoms". I've used both kernel- and user-space debuggers to find many hundreds of bugs, and in the vast majority of cases have been able to fix the underlying problem, not just symptoms. It's not at all obvious how having an additional tool and source of information can make it more difficult or less likely to develop an understanding of a problem.
Eric
Back to Eric's home page
Last updated April 27, 2000
Copyright 2000 Eric Smith