3 ms·

I like how everyone here is discussing the rhetorical style and ignoring the fact that his rejection of kernel debuggers is batshit insane and idiotic, which is

I like how everyone here is discussing the rhetorical style and ignoring the fact that his rejection of kernel debuggers is batshit insane and idiotic, which is the main topic.

edejong 11y ago
He's acting as a teacher in this email (like in many situations) and trying to explain that, in a deterministic and transparent system, the usage (and necessity) of a debugger is a clear signal of the inadequacy of the design. If you have to use a debugger, you should go back to the drawing board! You've made a fundamental design flaw in your abstractions and following a poor instruction pointer will not help you find that flaw. It's kind of ironic to see that, nowadays, with the increased necessity for concurrent and multi-agent systems, a debugger becomes even more obsolete and cumbersome, since you're often fighting a race-condition or some kind of resource starvation. Personally, I see his rhetoric in this email as highly intelligent community leadership in which Linus is arguing for better systems design (inside, or outside of the Linux kernel).
- vezzy-fnord 11y ago
  And yet, hardened Linux developers like Al Viro will rant all about the awful systems design inside and outside of the Linux kernel constantly (cgroups and udev are frequent targets of his). We can thus extrapolate that a lack of a kernel debugger has not reduced leaky abstractions in any measurable way. At best we can only speculate in counterfactuals. Solaris has a kernel debugger and a more concise architecture.
  - edejong 11y ago
    Linus argument is that use of debuggers may contribute to bad design, but he does not prohibit their use. As Linus was not the core contributor to cgroups (Google was) and kernel debugging certainly was available when cgroups was first implemented, I would say the opposite might actually be true. Personally, I think the UNIX OS design is a poor fit for the requirements of Docker et al. The problems with cgroups should be a signal that it breaks the fundamental design assumptions of Linux (doing fundamental resource separation and multi-ring security in a monolithic kernel).
    - vezzy-fnord 11y ago
      Actually, I agree with most of this. However, Linus letting in the cgroups branch instead of vetoing it proves the opposite, unless the presence of some kernel debugging (nothing close to kmdb, I'd think) depleted Linus' skills somehow.
- VLM 11y ago
  "a debugger becomes even more obsolete and cumbersome" I'm struck by the analogy that I entered the programming game juuuust after front panels went away from minis, a long time ago, and there was much crying about how the programming world really needs front panels to debug code at that time. Nobody demands a front panel to debug code now, of course. Anyway my point is I wonder if something better than a debugger will ever evolve. Much like front panels were replaced by technology or were no longer relevant for the task. A smart AI agent providing advice? Crowd sourced code reviews? Maybe nothing at all, unfortunately.
  - edejong 11y ago
    A debugger shows you only one trace through your code at a time. You want to see most, if not all traces and prohibit any illegal state. Since we humans are quite limited to comprehend this multi-dimensional arena, we need to use some proof system to help us out. For example, static code analysis, type systems (static typing) or even formal proof assistants. All of these are readily available. Another thing to realise is: a debugger works fundamentally on the sequential composition operator (putting instructions or statements after each other). We have to realise that the composition operator is very complex, hard to reason about and difficult to abstract (it's why modern build tools use a dependency graph and no shell scripts). As such, we should prefer other compositions in order to have correctness flow from our design, instead of our debugging cycles.

I like how everyone here is discussing the rhetorical style and ignoring the fact that his rejection of kernel debuggers is batshit insane and idiotic, which is the main topic.

edejong 11y ago

He's acting as a teacher in this email (like in many situations) and trying to explain that, in a deterministic and transparent system, the usage (and necessity) of a debugger is a clear signal of the inadequacy of the design. If you have to use a debugger, you should go back to the drawing board! You've made a fundamental design flaw in your abstractions and following a poor instruction pointer will not help you find that flaw. It's kind of ironic to see that, nowadays, with the increased necessity for concurrent and multi-agent systems, a debugger becomes even more obsolete and cumbersome, since you're often fighting a race-condition or some kind of resource starvation. Personally, I see his rhetoric in this email as highly intelligent community leadership in which Linus is arguing for better systems design (inside, or outside of the Linux kernel).

vezzy-fnord 11y ago
And yet, hardened Linux developers like Al Viro will rant all about the awful systems design inside and outside of the Linux kernel constantly (cgroups and udev are frequent targets of his). We can thus extrapolate that a lack of a kernel debugger has not reduced leaky abstractions in any measurable way. At best we can only speculate in counterfactuals. Solaris has a kernel debugger and a more concise architecture.
- edejong 11y ago
  Linus argument is that use of debuggers may contribute to bad design, but he does not prohibit their use. As Linus was not the core contributor to cgroups (Google was) and kernel debugging certainly was available when cgroups was first implemented, I would say the opposite might actually be true. Personally, I think the UNIX OS design is a poor fit for the requirements of Docker et al. The problems with cgroups should be a signal that it breaks the fundamental design assumptions of Linux (doing fundamental resource separation and multi-ring security in a monolithic kernel).
  - vezzy-fnord 11y ago
    Actually, I agree with most of this. However, Linus letting in the cgroups branch instead of vetoing it proves the opposite, unless the presence of some kernel debugging (nothing close to kmdb, I'd think) depleted Linus' skills somehow.
VLM 11y ago
"a debugger becomes even more obsolete and cumbersome" I'm struck by the analogy that I entered the programming game juuuust after front panels went away from minis, a long time ago, and there was much crying about how the programming world really needs front panels to debug code at that time. Nobody demands a front panel to debug code now, of course. Anyway my point is I wonder if something better than a debugger will ever evolve. Much like front panels were replaced by technology or were no longer relevant for the task. A smart AI agent providing advice? Crowd sourced code reviews? Maybe nothing at all, unfortunately.
- edejong 11y ago
  A debugger shows you only one trace through your code at a time. You want to see most, if not all traces and prohibit any illegal state. Since we humans are quite limited to comprehend this multi-dimensional arena, we need to use some proof system to help us out. For example, static code analysis, type systems (static typing) or even formal proof assistants. All of these are readily available. Another thing to realise is: a debugger works fundamentally on the sequential composition operator (putting instructions or statements after each other). We have to realise that the composition operator is very complex, hard to reason about and difficult to abstract (it's why modern build tools use a dependency graph and no shell scripts). As such, we should prefer other compositions in order to have correctness flow from our design, instead of our debugging cycles.