5 ms·

For those not familiar with the Linux kernel contributors, Alan Cox wrote large parts of the networking stack, was the maintainer of the 2.2 branch, and was com

For those not familiar with the Linux kernel contributors, Alan Cox wrote large parts of the networking stack, was the maintainer of the 2.2 branch, and was commonly considered the "second in command" to Linus Torvalds at one point: http://en.wikipedia.org/wiki/Alan_Cox http://en.wikipedia.org/wiki/Alan_Cox

uberdog 12y ago
He released what people considered to be the stable branch of the Linux kernel (the -ac branches). Linus was moving quickly and Alan would package up the releases that everyone would use. I just learned, from reading that wikipedia page, about the falling out he and Linus had.
rodgerd 12y ago
And, interestingly enough, a senior maintainer who quit because he got sick of Linus' behaviour.
- DanBC 12y ago
  https://lkml.org/lkml/2009/7/28/373 https://lkml.org/lkml/2009/7/28/373
  - rodgerd 12y ago
    Yes, I'm familiar with the incident. I was reading LKML when it happened. It's a counterpoint to the usual "Linus's style doesn't cause any problems."
    - vidarh 12y ago
      It may be a counterpoint, but it is also one of the milder rants from Linux: No expletives; no colourful descriptions. Yes, it's critical, but is the criticism unwarranted? He is questioning why one of the most senior maintainers is directly contradicting one of the most central "edicts" from Linus on the kernel development: Don't break user-land. In the message, Linus directly quotes Alan as arguing that breaking userland is ok. Of course Alan was/is free to disagree, but he should have known very well that Linus would never let that fly. Not least because Linus had told him it wouldn't, and he kept pressing for it. What was the alternative? From the outside, it looks like Alan repeatedly avoided doing what Linus told him needed doing. Linus could not have backed off without sacrificing the guarantee of not breaking userland.
      - glass- 12y ago
        If you read the whole thread Linus was wrong. He was constantly confusing two different bugs (despite Alan pointing this out to him multiple times), and the fixes he was yelling at Alan for not applying would have caused other things to break.
        makomk 12y ago
        Ooof. If I'm reading that thread correctly, Linus wanted to leave in a bug that would probably allow a local attacker (or maybe even a remote attacker) to execute arbitrary code in the kernel, just to avoid the risk of breaking userland code that did questionable thing that happened to work before by fixing it.
        IgorPartola 12y ago
        So reading this thread, I keep asking "could Linus have said what he needed to say in nicer terms and gotten better results?" I think so. In every Linus rant I encounter he goes on and on about the problem, then the person causing the problem, and typically attacks the developer. It's one thing to rule with an iron fist, it's another to target individuals and not the behavior.
        Alupis 12y ago
        > It's one thing to rule with an iron fist, it's another to target individuals and not the behavior. Quite honestly, I don't see any of this in the thread in question.
        IgorPartola 12y ago
        Where he's practically yelling "WHY?". Here's how it could be re-written to be a more effective email: "Hey Alan, The problem is that while you make pty.c have the correct behavior, lots of legacy userland code relies on the current implementation. Since as kernel developers, we must avoid breaking userland code at all costs, a better solution is to change the behavior, but implement a compatibility layer. Once enough userland code has been fixed, we can remove the compatibility layer. This has been our standard approach for these types of issues, and I think it would work here. While I understand how frustrating it is to not be able to fix this once and for all, I think we need to address our users' needs first. Thanks, Linus" Shorter, nicer, more to the point, and with much less time wasted on emotional outbursts.
    - leoc 12y ago
      > Yes, I'm familiar with the incident. I was reading LKML when it happened. Probably the link was posted for the benefit of others.
      - DanBC 12y ago
        Yes, thanks. I should have mentioned that.
- Alupis 12y ago
  not being familiar with this case -- but from an outside perspective reading the mailing list now, seems Alan introduced a patch that broke userland code -- which is the biggest No-No in kernel hacking, ie. the number 1 rule is don't break userland. Alan appeared to argue userland code was broken and not his patch, which just made Linus mad (as expected). The kernel strives to never break userland, even when userland is relying on legacy and/or broken pieces of kernel code (the idea is to code around the broken parts and provide compatibility until userland changes/fixes their problem -- ie. no kernel change should ever mass-break userland code).
  - jff 12y ago
    > code around the broken parts and provide compatibility until userland changes/fixes their problem read: provide compatibility indefinitely.
    - Alupis 12y ago
      yes that's the idea. in fact, it was only last year (or maybe 2012) that intel 386 (an almost 30 year old cpu) support was finally dropped. This is how binaries from 20 years ago will still run on today's hardware and kernel with zero modifications. That is a good thing, especially for enterprise. it's not that they leave security vulnerabilities in, it's that they build compatibility for any software that may expect something to work a certain way, while simultaneously fixing the underlying problem. To software, it should not care what kernel it's running on going forward.
- pantalaimon 12y ago
  That's not true at all, Alan Cox stated himself > I'm leaving the Linux world and Intel for a bit for family reasons. I'm aware that "family reasons" is usually management speak for "I think the boss is an asshole" but I'd like to assure everyone that while I frequently think Linus is an asshole (and therefore very good as kernel dictator) I am departing quite genuinely for family reasons and not because I've fallen out with Linus or Intel or anyone else. Far from it I've had great fun working there. https://plus.google.com/u/0/+AlanCoxLinux/posts/KW3TdRYwjr9 https://plus.google.com/u/0/+AlanCoxLinux/posts/KW3TdRYwjr9
  - hamburglar 12y ago
    This is a much more recent incident. The time he abruptly resigned as maintainer of the tty code was clearly a "fuck this, if you don't like the way I'm doing it, fix it yourself" resignation in direct response to some classic (if mild) Linus-in-your-face criticism.
    - Alupis 12y ago
      Aren't they the same incident? His G+ posts talks about resigning from tty duties among other things -- but also states there was no beef between him or any other kernel maintainers.
      - hamburglar 12y ago
        January 2013: "I'm leaving the Linux world and Intel for a bit for family reasons." July 2009: "I've had enough. If you think that problem is easy to fix you fix it. Have fun. I've zapped the tty merge queue so anyone with patches for the tty layer can send them to the new maintainer." No, they're not the same incident.

uberdog 12y ago

He released what people considered to be the stable branch of the Linux kernel (the -ac branches). Linus was moving quickly and Alan would package up the releases that everyone would use. I just learned, from reading that wikipedia page, about the falling out he and Linus had.

rodgerd 12y ago

And, interestingly enough, a senior maintainer who quit because he got sick of Linus' behaviour.

DanBC 12y ago
https://lkml.org/lkml/2009/7/28/373 https://lkml.org/lkml/2009/7/28/373
- rodgerd 12y ago
  Yes, I'm familiar with the incident. I was reading LKML when it happened. It's a counterpoint to the usual "Linus's style doesn't cause any problems."
  - vidarh 12y ago
    It may be a counterpoint, but it is also one of the milder rants from Linux: No expletives; no colourful descriptions. Yes, it's critical, but is the criticism unwarranted? He is questioning why one of the most senior maintainers is directly contradicting one of the most central "edicts" from Linus on the kernel development: Don't break user-land. In the message, Linus directly quotes Alan as arguing that breaking userland is ok. Of course Alan was/is free to disagree, but he should have known very well that Linus would never let that fly. Not least because Linus had told him it wouldn't, and he kept pressing for it. What was the alternative? From the outside, it looks like Alan repeatedly avoided doing what Linus told him needed doing. Linus could not have backed off without sacrificing the guarantee of not breaking userland.
    - glass- 12y ago
      If you read the whole thread Linus was wrong. He was constantly confusing two different bugs (despite Alan pointing this out to him multiple times), and the fixes he was yelling at Alan for not applying would have caused other things to break.
      - makomk 12y ago
        Ooof. If I'm reading that thread correctly, Linus wanted to leave in a bug that would probably allow a local attacker (or maybe even a remote attacker) to execute arbitrary code in the kernel, just to avoid the risk of breaking userland code that did questionable thing that happened to work before by fixing it.
        IgorPartola 12y ago
        So reading this thread, I keep asking "could Linus have said what he needed to say in nicer terms and gotten better results?" I think so. In every Linus rant I encounter he goes on and on about the problem, then the person causing the problem, and typically attacks the developer. It's one thing to rule with an iron fist, it's another to target individuals and not the behavior.
        Alupis 12y ago
        > It's one thing to rule with an iron fist, it's another to target individuals and not the behavior. Quite honestly, I don't see any of this in the thread in question.
        IgorPartola 12y ago
        Where he's practically yelling "WHY?". Here's how it could be re-written to be a more effective email: "Hey Alan, The problem is that while you make pty.c have the correct behavior, lots of legacy userland code relies on the current implementation. Since as kernel developers, we must avoid breaking userland code at all costs, a better solution is to change the behavior, but implement a compatibility layer. Once enough userland code has been fixed, we can remove the compatibility layer. This has been our standard approach for these types of issues, and I think it would work here. While I understand how frustrating it is to not be able to fix this once and for all, I think we need to address our users' needs first. Thanks, Linus" Shorter, nicer, more to the point, and with much less time wasted on emotional outbursts.
  - leoc 12y ago
    > Yes, I'm familiar with the incident. I was reading LKML when it happened. Probably the link was posted for the benefit of others.
    - DanBC 12y ago
      Yes, thanks. I should have mentioned that.
Alupis 12y ago
not being familiar with this case -- but from an outside perspective reading the mailing list now, seems Alan introduced a patch that broke userland code -- which is the biggest No-No in kernel hacking, ie. the number 1 rule is don't break userland. Alan appeared to argue userland code was broken and not his patch, which just made Linus mad (as expected). The kernel strives to never break userland, even when userland is relying on legacy and/or broken pieces of kernel code (the idea is to code around the broken parts and provide compatibility until userland changes/fixes their problem -- ie. no kernel change should ever mass-break userland code).
- jff 12y ago
  > code around the broken parts and provide compatibility until userland changes/fixes their problem read: provide compatibility indefinitely.
  - Alupis 12y ago
    yes that's the idea. in fact, it was only last year (or maybe 2012) that intel 386 (an almost 30 year old cpu) support was finally dropped. This is how binaries from 20 years ago will still run on today's hardware and kernel with zero modifications. That is a good thing, especially for enterprise. it's not that they leave security vulnerabilities in, it's that they build compatibility for any software that may expect something to work a certain way, while simultaneously fixing the underlying problem. To software, it should not care what kernel it's running on going forward.
pantalaimon 12y ago
That's not true at all, Alan Cox stated himself > I'm leaving the Linux world and Intel for a bit for family reasons. I'm aware that "family reasons" is usually management speak for "I think the boss is an asshole" but I'd like to assure everyone that while I frequently think Linus is an asshole (and therefore very good as kernel dictator) I am departing quite genuinely for family reasons and not because I've fallen out with Linus or Intel or anyone else. Far from it I've had great fun working there. https://plus.google.com/u/0/+AlanCoxLinux/posts/KW3TdRYwjr9 https://plus.google.com/u/0/+AlanCoxLinux/posts/KW3TdRYwjr9
- hamburglar 12y ago
  This is a much more recent incident. The time he abruptly resigned as maintainer of the tty code was clearly a "fuck this, if you don't like the way I'm doing it, fix it yourself" resignation in direct response to some classic (if mild) Linus-in-your-face criticism.
  - Alupis 12y ago
    Aren't they the same incident? His G+ posts talks about resigning from tty duties among other things -- but also states there was no beef between him or any other kernel maintainers.
    - hamburglar 12y ago
      January 2013: "I'm leaving the Linux world and Intel for a bit for family reasons." July 2009: "I've had enough. If you think that problem is easy to fix you fix it. Have fun. I've zapped the tty merge queue so anyone with patches for the tty layer can send them to the new maintainer." No, they're not the same incident.