I wouldn't say you're particularly wrong, and as someone who does kernel development I can't say I agree with Linus here (though I may very well have in 2000 wh

I wouldn't say you're particularly wrong, and as someone who does kernel development I can't say I agree with Linus here (though I may very well have in 2000 when he wrote this) - I use GDB to debug my kernel a fair amount, but it's also 2016 and it's rare that GDB helps besides notifying me when a condition happened and killing everything. I think I understand his point though. Kernel debuggers aren't amazing by any means, not at all comparable to standard application debuggers, and a lot of the actual hard problems you run into when dealing with a kernel can't be easily solved by debuggers anyway. Single-stepping through kernel code is filled with bugs and he's right when saying you can't really trust it. Kernel debuggers can be helpful, there's no denying that, but if you're relying on a kernel debugger to solve your problems then you're doing it wrong, and I think that's his point. There's too much that could go wrong that a kernel debugger couldn't easily catch for you - And I'm sure the debuggers in 2000 weren't as good as the ones we have now. Not having a debugger removes the risk of people doing that, and he'd rather have less kernel developers that are more aware of the code they're writing, then more that don't know as much about it.