4 ms·

"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 packeti

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".
- digi_owl 12y ago
  Makes one wonder if Sievers should be allowed to touch any more projects...
rektide 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." I dont know what I feel about this particular missive. But I do have some points to add about it- First and foremost, if I interpret this correctly there are two different issues Linus is conveying: 1. Kay has let a subsystem he has (shared-?) responsibility over decay from it's normal functions. 2. Debian does whack bad shit to read kernel logs. So, Kay is not the target of abuse. People who are not kernel devs are indirectly being targetted for insane usages of system facilities. I believe most laymen might mistakenly interpret the email by Linux as being directed at Kay. Only the first two paragraphs have a direct pertinence to Kay. The rest is saying why it's silly that Kay should have to do the work at all. I don't believe Kay is traceable to Debian's almost-certainly longstanding use of dd bs=1 . Second, Kay's level of commitment ranks much beyond a "contributor" "contributing." He has volunteered to maintain subsystems, volunteered to maintain udev. He is running his part of the show, and is responsible for ensuring those realms are working ok. That relationship is far different than that of a contributor in that Kay has directly taken up a distinct responsibility to be on top of things. Third, I think it's funny and hilarious. I thought it was funny and characterful the first time I read it. And I'd misread it too: I thought it was all packaged against Kay, laying the single-byte read WTF usage at his feet. I didn't think, "Oh Kay, what a horrible unabsolvable should-be abortion! I hate him!," I didn't think "GAWDD this guy is so lame, fuck Kay!," I thought "there's probably some really freaky old code from way the hell back when that has some really dumb stupid reason for doing things in a safe 1 at a time way." Engineers are expected to have empathy. That's the core lesson of all of this. And empathy for happenstance, for the weird misconfigurations that have arisen themselves is the chief empathy our ilk endures and battles with. We have great powers but we are still tied to a shamblingly mortal system of seeming immortal and unchanging nature. The conflict of empathy here is not with each other, it is with circumstance and what has already accrued, and people who are actual makers all can relate and understand- Linus's rage is heavy here because the very bad very old reasons are things which dog us still, and all of us who push are healed by hearing the drive and push towards betterment and away from _that,_ (a non-specific, non-direct that-which-haunts-us, even in the case of /proc/kmsg now). Linux capabilities unlike shipping code don't get post mortems- this bad capability will soldier and go on. But Linus and others give us an outlet where we can empathize with the desire to get beyond, to be better, even as Kay stays up puzzling through seven headfuls of concerns to hack a path forwards. Fourth, here's Kay's patch <2 days latter: https://lkml.org/lkml/2012/7/7/118 https://lkml.org/lkml/2012/7/7/118 "Thanks, Kay" I WILL NOT DRAW JUDGEMENT EITHER WAY on Linus's choice of writing here. I think it foolish to have conviction this is or is not acceptable behavior. It's deeply human, it's speaking to his base, it's speaking to his true beliefs and assessments and his feelings and passion all, it's sharing a deep seated completely justified mortal pain. Could he have channeled all that out in another fashion? Perhaps. But the words you wrote sbilstein are hollow, mechanized, shallow productions: they are what a machine would produce. I'll leave it for others to debate the merits and disadvantages of the "professionalism" and "responsibility" and "respectful leadership" that must balance against the more charged and unrestrained tact Linus opted to take, but I would say absolutely that as an engineer I feel better about my own empassioned pitched battles with ugly reality by getting to see Linus try to channel his feelings and assessment out, not packaged for efficient mechanized high-compression high-efficacy conveyance, but as someone giving a shit about decisions and what gets built.

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".

digi_owl 12y ago
Makes one wonder if Sievers should be allowed to touch any more projects...

rektide 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." I dont know what I feel about this particular missive. But I do have some points to add about it- First and foremost, if I interpret this correctly there are two different issues Linus is conveying: 1. Kay has let a subsystem he has (shared-?) responsibility over decay from it's normal functions. 2. Debian does whack bad shit to read kernel logs. So, Kay is not the target of abuse. People who are not kernel devs are indirectly being targetted for insane usages of system facilities. I believe most laymen might mistakenly interpret the email by Linux as being directed at Kay. Only the first two paragraphs have a direct pertinence to Kay. The rest is saying why it's silly that Kay should have to do the work at all. I don't believe Kay is traceable to Debian's almost-certainly longstanding use of dd bs=1 . Second, Kay's level of commitment ranks much beyond a "contributor" "contributing." He has volunteered to maintain subsystems, volunteered to maintain udev. He is running his part of the show, and is responsible for ensuring those realms are working ok. That relationship is far different than that of a contributor in that Kay has directly taken up a distinct responsibility to be on top of things. Third, I think it's funny and hilarious. I thought it was funny and characterful the first time I read it. And I'd misread it too: I thought it was all packaged against Kay, laying the single-byte read WTF usage at his feet. I didn't think, "Oh Kay, what a horrible unabsolvable should-be abortion! I hate him!," I didn't think "GAWDD this guy is so lame, fuck Kay!," I thought "there's probably some really freaky old code from way the hell back when that has some really dumb stupid reason for doing things in a safe 1 at a time way." Engineers are expected to have empathy. That's the core lesson of all of this. And empathy for happenstance, for the weird misconfigurations that have arisen themselves is the chief empathy our ilk endures and battles with. We have great powers but we are still tied to a shamblingly mortal system of seeming immortal and unchanging nature. The conflict of empathy here is not with each other, it is with circumstance and what has already accrued, and people who are actual makers all can relate and understand- Linus's rage is heavy here because the very bad very old reasons are things which dog us still, and all of us who push are healed by hearing the drive and push towards betterment and away from _that,_ (a non-specific, non-direct that-which-haunts-us, even in the case of /proc/kmsg now). Linux capabilities unlike shipping code don't get post mortems- this bad capability will soldier and go on. But Linus and others give us an outlet where we can empathize with the desire to get beyond, to be better, even as Kay stays up puzzling through seven headfuls of concerns to hack a path forwards. Fourth, here's Kay's patch <2 days latter: https://lkml.org/lkml/2012/7/7/118 https://lkml.org/lkml/2012/7/7/118 "Thanks, Kay" I WILL NOT DRAW JUDGEMENT EITHER WAY on Linus's choice of writing here. I think it foolish to have conviction this is or is not acceptable behavior. It's deeply human, it's speaking to his base, it's speaking to his true beliefs and assessments and his feelings and passion all, it's sharing a deep seated completely justified mortal pain. Could he have channeled all that out in another fashion? Perhaps. But the words you wrote sbilstein are hollow, mechanized, shallow productions: they are what a machine would produce. I'll leave it for others to debate the merits and disadvantages of the "professionalism" and "responsibility" and "respectful leadership" that must balance against the more charged and unrestrained tact Linus opted to take, but I would say absolutely that as an engineer I feel better about my own empassioned pitched battles with ugly reality by getting to see Linus try to channel his feelings and assessment out, not packaged for efficient mechanized high-compression high-efficacy conveyance, but as someone giving a shit about decisions and what gets built.