Well, although Andi may be wrong, nobody should insult him on a public mailing list.
Linus, you're a genius on linux-related things, but sometimes you're a complete asshole on social ones. Really. Coding isn't everything on this life. And yes, i'm a programmer.
Learn to treat others nicely and REMEMBER that Linux won't be anything WITHOUT the myriad of work of thousands of programmers. Remember this before flaming someone again.
+1
It's a shame, because Andy is a real nice guy.
This Andy bashing on LKML is going on for over a year now.
I thought they (Ingo, Linus, Thomas) would stop this behavior,
after they took the x86_64 maintainership from him. But I was
obviously wrong...
Andi stepped down from x86_64 because more developers wanted a unified x86/x86_64 source tree and Andi wanted it kept separate. The unification happened, and Andi didn't want to be the maintainer if that was the arrangement, so he stopped doing it.
>Linus, you're a genius on linux-related things, but sometimes you're a complete asshole on social ones. Really. Coding isn't everything on this life. And yes, i'm a programmer.
If you were able to make that statement, then you have yet to see Theo de Raadt in action.
IMHO it's quite disheartening to see Linus move into Theo de Raadt direction. He used to be witty and funny, but lately his flames are nothing but offending.
Ironically Mr. Linus (I'm always right) Torvalds was too busy crowing over how clever he was when checking in the fix to GIT to pay attention to what he was doing. So the commit comment has some garbage text after the Signed-off-by lines. See: http://tinyurl.com/69mazb
Linus is great! You can see that even in these situations! Look at the discussion and at the fact that Kleen didn't really even try to understand what Linus had done with his patch. Don't jugde people just because they're not all "please", "pardon" or crap like that!
Hey guys, I read the whole thread to try and understand it better and
although a bit of politeliness is always good, I think Andi deserved this
one. And yes, Linus is great, the quote above is really funny, and, what's
worse, it makes sense! I wouldn't argue as Andi did with Linus without
making really sure I did my homework.
Are you saying that someone deserves to be insulted on a public mailing list due to some **STUPID** technical discussion?. Who the hell is Linus to insult Andi, WHO?.
Great. And now i am sure that some people will keep questioning why there are **great** programmers out there that don't want to know a shit about Viro, 'Linus and Co.', etc speeches and bad-manners on lkml ... well, this is a nice example.
Strange how two people can come away with very different impressions (but perhaps that explains how e-mail flames like this happen).
Here's what I saw (though the sequence as viewed by either Linus or Andi may be slightly different as e-mails were criss-crossing the Atlantic in parallel):
1) Linus added Andi to the thread when he tracked the problem to code that had been written by Andi. Specifically he said: "I actually am starting to think that the bug is in __copy_to_user_inatomic_nocache()." and after a code snippet continued with "it may have done three of the 64-bit loads, and then trap on the fouth". The root cause of the communication problems that follow is that Linus said "to_user" here, when he meant "from_user".
2) Andi read this and was puzzled how a copy to user could trap on a load. The design for the copy to user code makes a fundamental assumption that the source addresses will not cause faults, only the destination (userland) addresses can. So Andi replied with "when you do _to_user you shouldn't fault on the loads and vice versa. If a caller does that it's buggy."
3) Linus' reply doesn't help much ... he hasn't yet noticed the "to_user" typo in his original e-mail to Andi. He starts SHOUTING ... which doesn't help the communication flow.
4) Andi is still stuck on the "to_user" issue. He asks: "How can a load fault legitimately in copy_to_user?" This was Linus's big chance to notice that they were not talking about the same thing, and he blew it. If he had read, understood, and replied to this e-mail then the rest of the flame war would never have happened.
5) Andi also replies to Linus's proposed fix with "The caller is broken because it shouldn't pass a faulting source to copy_to_user()"
6) Linus begins to lose it ... but does at least manage to mention for the first time that the issue is in "copy_from"user": "Andi, I'm sorry I cc'd you. You are the author of that crap, but the bug seems to be that you never even understood what copy_from_user() is supposed to do." But since this use of "from_user" comes immediately after the insulting "you are the author of that crap" and "you never even understood" it is understandable that Andi doesn't notice the switch.
7) Andi has a couple of replies ... still focusing on the "to_user" routine should never fault on the memory load. There's the first sign that he realizes that Linus' original description was wrong when he asks: "Or are you're describing copy_in_user()?"
8) Linus loses it: "Andi, just shut up already." ... "Andi, SHUT THE F*CK UP."
9) Linus realizes that he made a typo: "Oh, and yes, I said "copy_to_user_inatomic()" by mistake." But it is too late now, no useful communication happens between Linus and Andi in the rest of the thread.
So Andi failed to read Linus' mind and got screamed at for it.
Right. One is 17+ year old developer, another is 10+ one. And development is on the state of "millions typing monkeys"... They both "good" here, as well as others "from the top of my head".
Unless at least somebody that mature in kernel will start to put wisdom using new level of automated semantics checking/sematntic documentation (imagine that:), then any "hit by bus/lkml-flame" occasion, will be another cycle of wasted time and yet another huge pile of bugs/typos/thinkos in f**ing basic things.
Order and automation are fundamental things to have intensive development.
Linus tried by `sparse`. But C and any crutch on top of it, especially with a bad choice of license, as time shows, isn't that useful.
Also where's review here? What they all are doing most of the time? x86 unification? BKL? IMHO hardware is much more superior nowadays. Software just bloats.
Thats quite a good summary, the asynchronous communication that is email certainly has it's disadvantages sometimes. I myself have been too busy responding to an email before to realise a new email has arrived that corrects something previously stated.
Linus is Linus, Andi is Andi, and Jeremy is Jeremy. Linus seems to be harsh to people at times. Andi does not say anything and silently accepts the insult (or what most people think is an insult). Jeremy selects this post and tabloid-ize the incident, highlighting the insult. Whatever...
...
Well, although Andi may be wrong, nobody should insult him on a public mailing list.
Linus, you're a genius on linux-related things, but sometimes you're a complete asshole on social ones. Really. Coding isn't everything on this life. And yes, i'm a programmer.
Learn to treat others nicely and REMEMBER that Linux won't be anything WITHOUT the myriad of work of thousands of programmers. Remember this before flaming someone again.
+1 It's a shame, because
+1
It's a shame, because Andy is a real nice guy.
This Andy bashing on LKML is going on for over a year now.
I thought they (Ingo, Linus, Thomas) would stop this behavior,
after they took the x86_64 maintainership from him. But I was
obviously wrong...
Andi stepped down from
Andi stepped down from x86_64 because more developers wanted a unified x86/x86_64 source tree and Andi wanted it kept separate. The unification happened, and Andi didn't want to be the maintainer if that was the arrangement, so he stopped doing it.
Nothing was taken from him.
others
>Linus, you're a genius on linux-related things, but sometimes you're a complete asshole on social ones. Really. Coding isn't everything on this life. And yes, i'm a programmer.
If you were able to make that statement, then you have yet to see Theo de Raadt in action.
IMHO it's quite
IMHO it's quite disheartening to see Linus move into Theo de Raadt direction. He used to be witty and funny, but lately his flames are nothing but offending.
No, he's going in an Ulrich
No, he's going in an Ulrich Drepper direction, there is a subtle difference.
Re: No, he's going in an Ulrich
Theo is more witty for a start.
perfection
Ironically Mr. Linus (I'm always right) Torvalds was too busy crowing over how clever he was when checking in the fix to GIT to pay attention to what he was doing. So the commit comment has some garbage text after the Signed-off-by lines. See: http://tinyurl.com/69mazb
OH NO! There's GARBAGE text
OH NO! There's GARBAGE text after the Signed-off by lines! QUICK, get a GIT doctor.
Linus is great! You can see
Linus is great! You can see that even in these situations! Look at the discussion and at the fact that Kleen didn't really even try to understand what Linus had done with his patch. Don't jugde people just because they're not all "please", "pardon" or crap like that!
Hey guys, I read the whole
Hey guys, I read the whole thread to try and understand it better and
although a bit of politeliness is always good, I think Andi deserved this
one. And yes, Linus is great, the quote above is really funny, and, what's
worse, it makes sense! I wouldn't argue as Andi did with Linus without
making really sure I did my homework.
Are you saying that someone
Are you saying that someone deserves to be insulted on a public mailing list due to some **STUPID** technical discussion?. Who the hell is Linus to insult Andi, WHO?.
Great. And now i am sure that some people will keep questioning why there are **great** programmers out there that don't want to know a shit about Viro, 'Linus and Co.', etc speeches and bad-manners on lkml ... well, this is a nice example.
Funny, I read the thread too ...
Strange how two people can come away with very different impressions (but perhaps that explains how e-mail flames like this happen).
Here's what I saw (though the sequence as viewed by either Linus or Andi may be slightly different as e-mails were criss-crossing the Atlantic in parallel):
1) Linus added Andi to the thread when he tracked the problem to code that had been written by Andi. Specifically he said: "I actually am starting to think that the bug is in __copy_to_user_inatomic_nocache()." and after a code snippet continued with "it may have done three of the 64-bit loads, and then trap on the fouth". The root cause of the communication problems that follow is that Linus said "to_user" here, when he meant "from_user".
2) Andi read this and was puzzled how a copy to user could trap on a load. The design for the copy to user code makes a fundamental assumption that the source addresses will not cause faults, only the destination (userland) addresses can. So Andi replied with "when you do _to_user you shouldn't fault on the loads and vice versa. If a caller does that it's buggy."
3) Linus' reply doesn't help much ... he hasn't yet noticed the "to_user" typo in his original e-mail to Andi. He starts SHOUTING ... which doesn't help the communication flow.
4) Andi is still stuck on the "to_user" issue. He asks: "How can a load fault legitimately in copy_to_user?" This was Linus's big chance to notice that they were not talking about the same thing, and he blew it. If he had read, understood, and replied to this e-mail then the rest of the flame war would never have happened.
5) Andi also replies to Linus's proposed fix with "The caller is broken because it shouldn't pass a faulting source to copy_to_user()"
6) Linus begins to lose it ... but does at least manage to mention for the first time that the issue is in "copy_from"user": "Andi, I'm sorry I cc'd you. You are the author of that crap, but the bug seems to be that you never even understood what copy_from_user() is supposed to do." But since this use of "from_user" comes immediately after the insulting "you are the author of that crap" and "you never even understood" it is understandable that Andi doesn't notice the switch.
7) Andi has a couple of replies ... still focusing on the "to_user" routine should never fault on the memory load. There's the first sign that he realizes that Linus' original description was wrong when he asks: "Or are you're describing copy_in_user()?"
8) Linus loses it: "Andi, just shut up already." ... "Andi, SHUT THE F*CK UP."
9) Linus realizes that he made a typo: "Oh, and yes, I said "copy_to_user_inatomic()" by mistake." But it is too late now, no useful communication happens between Linus and Andi in the rest of the thread.
So Andi failed to read Linus' mind and got screamed at for it.
new level
Right. One is 17+ year old developer, another is 10+ one. And development is on the state of "millions typing monkeys"... They both "good" here, as well as others "from the top of my head".
Unless at least somebody that mature in kernel will start to put wisdom using new level of automated semantics checking/sematntic documentation (imagine that:), then any "hit by bus/lkml-flame" occasion, will be another cycle of wasted time and yet another huge pile of bugs/typos/thinkos in f**ing basic things.
Order and automation are fundamental things to have intensive development.
Linus tried by `sparse`. But C and any crutch on top of it, especially with a bad choice of license, as time shows, isn't that useful.
Also where's review here? What they all are doing most of the time? x86 unification? BKL? IMHO hardware is much more superior nowadays. Software just bloats.
Perhaps you should take your
Perhaps you should take your medication?
:)
Thanks.
Thats quite a good summary,
Thats quite a good summary, the asynchronous communication that is email certainly has it's disadvantages sometimes. I myself have been too busy responding to an email before to realise a new email has arrived that corrects something previously stated.
xkcd, once again right on
xkcd, once again right on the money: Internet Argument
Linus is Linus, Andi is
Linus is Linus, Andi is Andi, and Jeremy is Jeremy. Linus seems to be harsh to people at times. Andi does not say anything and silently accepts the insult (or what most people think is an insult). Jeremy selects this post and tabloid-ize the incident, highlighting the insult. Whatever...
... (or what most people
... (or what most people think is an insult) ...
http://lkml.org/lkml/2008/6/17/250
So tell me why I shouldn't just put you in my "idiots" filter? The aggravation just isn't worth it for me.
http://lkml.org/lkml/2008/6/17/254
Ok, I'm now putting you in my idiots filter. (...) No, it will not break the other case. You're an idiot.
----
Enough?