4 ms·

This piece from Linus on why he doesn't like debuggers resonates with me [1], although I confess I use Python pdb quite often. [1] https://lkml.org/lkml/2000/9

This piece from Linus on why he doesn't like debuggers resonates with me [1], although I confess I use Python pdb quite often. [1] https://lkml.org/lkml/2000/9/6/65 https://lkml.org/lkml/2000/9/6/65

sokoloff 4y ago
I really enjoyed this thought in that mail: “Tough. There are two kinds of reactions to that [time lost from a bug you introduced in kernel dev]: you start being careful, or you start whining about a kernel debugger.”
- matheusmoreira 4y ago
  He also reminds people why everyone pulls from torvalds/linux to this day: > People think I'm a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings or lost hours of work if it just results in what I consider to be a better system.
heinrichhartman 4y ago
Contrasting perspective from John Carmack [1] who drops into a debugger all the time to explore state, understand program behavior, debug things, etc. Looks like there is no universal golden path. Differing environments make different approaches effective. [1] https://www.youtube.com/watch?v=tzr7hRXcwkw https://www.youtube.com/watch?v=tzr7hRXcwkw
jcranmer 4y ago
That sort of argument is somewhat defensible in a context like the kernel, where when things go haywire, you can't really expect there to be enough sanity to have a debugger work. But very little code runs in such a context, and it turns out that a well-written debugger has incredible features. Also, Linus is writing this 22 and a half years ago, where the capabilities of debuggers were... far, far less. Time-travelling debuggers is really a game changer, just having the ability to travel back in time to figure out who set the value that causes the code to crash. Hot reload is also a wonderful thing (unfortunately, the fragmentation of tooling in Linux makes getting this working properly very difficult).
- eschneider 4y ago
  Lots of (most?) real-time and embedded code run in a state where suspending/resuming really doesn't work in any useful fashion, so it's logging, and minimal logging at that to figure out what's going wrong in-situ. That said, much benefit is gained by writing the complicated bits in such a way that they can be tested/debugged/examined independently on a host system.
  - realo 4y ago
    I'm with you there! Be happy if you can flash a led... happier if you have two speeds... and Nirvana if it is a multi-color led. Intense jealousy of your colleagues who have TWO leds on their boards!
  - nuancebydefault 4y ago
    Hmmm I have 20+ years of embedded sw programming experience and can tell you the reason that embedded software is oftentimes not easily debugged using a debugger, is the crappyness of the debugger solution (debug probe, its firmware and its eco system). Also, high end embedded ICs often contain a serious amount if silicon bugs. The fact that it needs to run real-time, is mostly not in the way of the debugging process. In other words, embedded processors and their eco systems tend to be sub-par in terms of developer friendlyness. Addendum SHARC ADSP anomaly list https://www.analog.com/media/en/dsp-documentation/integrated-circuit-anomalies/adsp-21467_21469-sharc-anomaly.pdf https://www.analog.com/media/en/dsp-documentation/integrated...
- deckard1 4y ago
  > Time-travelling debuggers is really a game changer Core dumps have existed forever. They give you a stack trace and register values at the time of crash. Even better, you don't need a debugger running at the time of crash and you can dig into dumps sent from nontechnical users. Sure, Bret Victor's demo was cool. But time travel debugging is so completely oversold at this point that I can't take anyone seriously that mentions it.
  - jcranmer 4y ago

This piece from Linus on why he doesn't like debuggers resonates with me [1], although I confess I use Python pdb quite often. [1] https://lkml.org/lkml/2000/9/6/65 https://lkml.org/lkml/2000/9/6/65

sokoloff 4y ago

I really enjoyed this thought in that mail: “Tough. There are two kinds of reactions to that [time lost from a bug you introduced in kernel dev]: you start being careful, or you start whining about a kernel debugger.”

matheusmoreira 4y ago
He also reminds people why everyone pulls from torvalds/linux to this day: > People think I'm a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings or lost hours of work if it just results in what I consider to be a better system.

heinrichhartman 4y ago

Contrasting perspective from John Carmack [1] who drops into a debugger all the time to explore state, understand program behavior, debug things, etc. Looks like there is no universal golden path. Differing environments make different approaches effective. [1] https://www.youtube.com/watch?v=tzr7hRXcwkw https://www.youtube.com/watch?v=tzr7hRXcwkw

jcranmer 4y ago

That sort of argument is somewhat defensible in a context like the kernel, where when things go haywire, you can't really expect there to be enough sanity to have a debugger work. But very little code runs in such a context, and it turns out that a well-written debugger has incredible features. Also, Linus is writing this 22 and a half years ago, where the capabilities of debuggers were... far, far less. Time-travelling debuggers is really a game changer, just having the ability to travel back in time to figure out who set the value that causes the code to crash. Hot reload is also a wonderful thing (unfortunately, the fragmentation of tooling in Linux makes getting this working properly very difficult).

eschneider 4y ago
Lots of (most?) real-time and embedded code run in a state where suspending/resuming really doesn't work in any useful fashion, so it's logging, and minimal logging at that to figure out what's going wrong in-situ. That said, much benefit is gained by writing the complicated bits in such a way that they can be tested/debugged/examined independently on a host system.
- realo 4y ago
  I'm with you there! Be happy if you can flash a led... happier if you have two speeds... and Nirvana if it is a multi-color led. Intense jealousy of your colleagues who have TWO leds on their boards!
- nuancebydefault 4y ago
  Hmmm I have 20+ years of embedded sw programming experience and can tell you the reason that embedded software is oftentimes not easily debugged using a debugger, is the crappyness of the debugger solution (debug probe, its firmware and its eco system). Also, high end embedded ICs often contain a serious amount if silicon bugs. The fact that it needs to run real-time, is mostly not in the way of the debugging process. In other words, embedded processors and their eco systems tend to be sub-par in terms of developer friendlyness. Addendum SHARC ADSP anomaly list https://www.analog.com/media/en/dsp-documentation/integrated-circuit-anomalies/adsp-21467_21469-sharc-anomaly.pdf https://www.analog.com/media/en/dsp-documentation/integrated...
deckard1 4y ago
> Time-travelling debuggers is really a game changer Core dumps have existed forever. They give you a stack trace and register values at the time of crash. Even better, you don't need a debugger running at the time of crash and you can dig into dumps sent from nontechnical users. Sure, Bret Victor's demo was cool. But time travel debugging is so completely oversold at this point that I can't take anyone seriously that mentions it.
- jcranmer 4y ago