4 ms·

Linus is one of the few brilliant jerks out there who is truly brilliant. Unfortunately his antics have made it OK for lots of less talented individuals to thin

Linus is one of the few brilliant jerks out there who is truly brilliant. Unfortunately his antics have made it OK for lots of less talented individuals to think they have the right to treat people like dirt in order to write good code. He's exceptional in my opinion but I often wonder what the OSS community would be like without behavior like his. I recall not wanting to major in CS when I entered school because the only programmers I knew when I was young were from newsgroups, forum, and OSS communities that I perused as kid...and they all seemed like assholes. I'm glad I changed by mind cause I was so interested but thick skin shouldn't be the bar for contributing to tech. edit: I'm certainly not defending Linus. His talent makes him a net positive but he definitely should not treat people the way he does.

jdonaldson 12y ago
It always seems like jerks are better at handling other jerks than non-jerks. A jerk-led project may be more sustainable for that reason in the long run. I can think of numerous situations where contributing jerks (in the minority) did more to harm a project than the person leading the project.
rektide 12y ago
Flipping off a bad hardware company, writing some scathing roasts of patches... he's obviously not checking himself into staid polite behavior, absolutely. The extent to which this makes him a jerk, or makes him bossy is a connection that I've always felt is tenuous at best. Even his meanest patch roasts are things that I'd hope people realize can be taken in stride; technical work will have to go in but work can progress, and Linus is not forebearing, he's not enhancing the difficulty of doing that technical work by being directly scathing to the existing work, and generally (what I think most people regards as) humorous and spirited to the rest of the readership. What I haven't seen is any real attempt to find citeable referencable direct impacts of Linus being flamboyant as he produces his technical outlook. Which contributors have taken serious injury, and how has it impacted them? Certainly contributing is hard and finding out the work needs to be redone is hard: what measures can we assign to how much harder those necessary acts are when it's a "jerk"-y delivery (which as I said is not a term I'm not confident is appropriate or applicable). Rather than focus on Linus's behavior as problematic and the emphasis of it being a deeply stemmed root cause, I'd like to see some hard impact-analysis with good data behind it that gives a better idea of why we should adopt strict tone-policing of the necessary harsh and brutal technical review process.
- sbilstein 12y ago
  "Kay, this needs to be fixed. Suggested fix: just use the 'seq_printf()' interfaces, which do the proper buffering, and allow any size reads of various packetized data. Of course, I'd also suggest that whoever was the genius who thought it was a good idea to read things ONE FCKING BYTE AT A TIME with system calls for each byte should be retroactively aborted. Who the fck does idiotic things like that? How did they noty die as babies, considering that they were likely too stupid to find a tit to suck on?" - linus https://lkml.org/lkml/2012/7/6/495 https://lkml.org/lkml/2012/7/6/495 do you want some data on the people who don't even bother dealing with sort of talk? he could easily replace the second paragraph with something like "This is an extremely bad way of doing things; reading one byte of a time is terrible. Please research the system calls you are using before submitting another patch, it's unacceptable to submit code that hasn't been thought through thoroughly."
  - Torgo 12y ago
    "Key, I'm fcking tired of the fact that you don't fix problems in the code you* write, so that the kernel then has to work around the problems you cause[...]I will not be merging any code from Kay into the kernel until this constant pattern is fixed.[...]This has been going on for years, and doesn't seem to be getting any better." That name sounds familiar. https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://plus.google.com/+gregkroahhartman/posts/Kd57G8s1cTD https://plus.google.com/+gregkroahhartman/posts/Kd57G8s1cTD "What I mind is people closing bugs and not admitting mistakes. If Kay had even said "sorry, the excessive output was a bug in systemd, it's already fixed in current -git", that would have been a valid reason to close the bug. And for the people thinking this is a storm in a teacup: this is not the first time Kay has done this, which is why I personally get so frustrated. Kay has done the exact same thing with major bugs that were not fixed anywhere else, and that caused machines to fail at boot time, and Kay happily pointed the finger elsewhere for months at a time and closed bugzilla entries. [...] people are (I think) understandably upset that systemd not only screwed up, but then the people involved weren't even willing to say "sorry" about it but instead go "uh, it wasn't our bug, deal with it".

jdonaldson 12y ago

It always seems like jerks are better at handling other jerks than non-jerks. A jerk-led project may be more sustainable for that reason in the long run. I can think of numerous situations where contributing jerks (in the minority) did more to harm a project than the person leading the project.

rektide 12y ago

Flipping off a bad hardware company, writing some scathing roasts of patches... he's obviously not checking himself into staid polite behavior, absolutely. The extent to which this makes him a jerk, or makes him bossy is a connection that I've always felt is tenuous at best. Even his meanest patch roasts are things that I'd hope people realize can be taken in stride; technical work will have to go in but work can progress, and Linus is not forebearing, he's not enhancing the difficulty of doing that technical work by being directly scathing to the existing work, and generally (what I think most people regards as) humorous and spirited to the rest of the readership. What I haven't seen is any real attempt to find citeable referencable direct impacts of Linus being flamboyant as he produces his technical outlook. Which contributors have taken serious injury, and how has it impacted them? Certainly contributing is hard and finding out the work needs to be redone is hard: what measures can we assign to how much harder those necessary acts are when it's a "jerk"-y delivery (which as I said is not a term I'm not confident is appropriate or applicable). Rather than focus on Linus's behavior as problematic and the emphasis of it being a deeply stemmed root cause, I'd like to see some hard impact-analysis with good data behind it that gives a better idea of why we should adopt strict tone-policing of the necessary harsh and brutal technical review process.

sbilstein 12y ago
"Kay, this needs to be fixed. Suggested fix: just use the 'seq_printf()' interfaces, which do the proper buffering, and allow any size reads of various packetized data. Of course, I'd also suggest that whoever was the genius who thought it was a good idea to read things ONE FCKING BYTE AT A TIME with system calls for each byte should be retroactively aborted. Who the fck does idiotic things like that? How did they noty die as babies, considering that they were likely too stupid to find a tit to suck on?" - linus https://lkml.org/lkml/2012/7/6/495 https://lkml.org/lkml/2012/7/6/495 do you want some data on the people who don't even bother dealing with sort of talk? he could easily replace the second paragraph with something like "This is an extremely bad way of doing things; reading one byte of a time is terrible. Please research the system calls you are using before submitting another patch, it's unacceptable to submit code that hasn't been thought through thoroughly."
- Torgo 12y ago
  "Key, I'm fcking tired of the fact that you don't fix problems in the code you* write, so that the kernel then has to work around the problems you cause[...]I will not be merging any code from Kay into the kernel until this constant pattern is fixed.[...]This has been going on for years, and doesn't seem to be getting any better." That name sounds familiar. https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://plus.google.com/+gregkroahhartman/posts/Kd57G8s1cTD https://plus.google.com/+gregkroahhartman/posts/Kd57G8s1cTD "What I mind is people closing bugs and not admitting mistakes. If Kay had even said "sorry, the excessive output was a bug in systemd, it's already fixed in current -git", that would have been a valid reason to close the bug. And for the people thinking this is a storm in a teacup: this is not the first time Kay has done this, which is why I personally get so frustrated. Kay has done the exact same thing with major bugs that were not fixed anywhere else, and that caused machines to fail at boot time, and Kay happily pointed the finger elsewhere for months at a time and closed bugzilla entries. [...] people are (I think) understandably upset that systemd not only screwed up, but then the people involved weren't even willing to say "sorry" about it but instead go "uh, it wasn't our bug, deal with it".