5 ms·

To be honest, Linus' rants is making a better point for me. I really feel his pain with overflow_usub, and i feel nothing when reading rewritten version.

by shepik 11y ago

adamc 11y ago
Why on earth do I need to "feel his pain" rather than just understand the issues at hand?
- raverbashing 11y ago
  Because them some people think it's still ok to go with the broken code That's cultural differences 101 As a simple example: in Canada one might say "please do not feed the animals" in a Zoo. In some other places, for the message to have the same effect it must be as such: "It is expressly forbidden to feed the animals! Those being caught doing so will be expelled from the zoo!"
  - tptacek 11y ago
    Wait. "Broken" code?
    - raverbashing 11y ago
      From the original Linus email "And yes, you still could have overflow issues if the whole "hlen + xyz" expression overflows, but quite frankly, the "overflow_usub()" code had that too"
      - tptacek 11y ago
        I'm afraid that doesn't clarify, because if the overflow_usub code is broken in that sense, then so is the code Linus is advocating for. Do you still think "broken" was the right word to use? Why?
        raverbashing 11y ago
        I think there's also the issue of limited compiler support for that feature Maybe broken is too strong a word I agree
        tptacek 11y ago
        overflow_usub is the code that gets called when your compiler doesn't support __builtin_usub_overflow (Linus opposes both the function and the intrinsic, of course).
        raverbashing 11y ago
        True, however how it is used in this case leads to unnecessary opacity (I'm referring to the || mtu <= 7 part), which, once you know how usub_overflow works is obvious what it means, but this might not be evident and unnecessarily complicating that snipped Sometimes 'smart code' is not necessarily better (I'm open to disagreement, though)
        tptacek 11y ago
        Just to be clear: I don't think Linus is wrong (I'm also not qualified to judge that). From what I can tell, he's like, 52.5% right. What's more interesting to me is how low-stakes this issue is. Gizmodo wrote an article about it, but really, if you understand kernel C, do you even give a shit about this code? Linus could have said "we're not using GCC builtin overflow intrinics", just like that, one line no punctuation, and the issue would have been settled. But look at this thread at the number of people who extrapolated from Linus' rant that this code was bad, ruinous, unsafe, "one size fits all" (still scratching my head about that), &c. How many of Linus' defenders actually know what he's ranting about? It looks to me like: not many. What's funny is, you actually do seem like you know what he's talking about, and even you overshot the mark with "broken". :)
        micampe 11y ago
        > Sometimes 'smart code' is not necessarily better I would argue that it's usually not, especially in large and long lived projects. “Everyone knows that debugging is twice as hard as writing a program”.
- shepik 11y ago
  You don't. The man who wrote that code does. And judging by his response, i'd say he did - http://lkml.iu.edu/hypermail/linux/kernel/1510.3/02919.html http://lkml.iu.edu/hypermail/linux/kernel/1510.3/02919.html
- marrs 11y ago
  Because people are emotional and we respond more acutely to emotion.
tptacek 11y ago
I'm surprised to read this, because I feel like I understand what Linus is ranting about, and while he's probably right, he's right about such a minor and easily disposed-with point that I'm surprised to see him invest so much emotion in it. He could have just said "overflow_usub? no, not in 2015." and everyone would have agreed with him.
dkersten 11y ago
I disagree. I read a bit of the rant and didn't feel like reading the rest: its not short, its not to the point, its full of language that, despite not being directed at me, made me feel bad. The "rewritten" version is short and to the point. Its clear and it uses neutral language. I read it and immediately understood what the issue is with the proposed code and why the changed code is better. So for me, the rewritten version was many many times better because I could actually understand it without having to force myself to read something long and horrible.

To be honest, Linus' rants is making a better point for me. I really feel his pain with overflow_usub, and i feel nothing when reading rewritten version.

by shepik 11y ago

To be honest, Linus' rants is making a better point for me. I really feel his pain with overflow_usub, and i feel nothing when reading rewritten version.

adamc 11y ago

Why on earth do I need to "feel his pain" rather than just understand the issues at hand?

raverbashing 11y ago
Because them some people think it's still ok to go with the broken code That's cultural differences 101 As a simple example: in Canada one might say "please do not feed the animals" in a Zoo. In some other places, for the message to have the same effect it must be as such: "It is expressly forbidden to feed the animals! Those being caught doing so will be expelled from the zoo!"
- tptacek 11y ago
  Wait. "Broken" code?
  - raverbashing 11y ago
    From the original Linus email "And yes, you still could have overflow issues if the whole "hlen + xyz" expression overflows, but quite frankly, the "overflow_usub()" code had that too"
    - tptacek 11y ago
      I'm afraid that doesn't clarify, because if the overflow_usub code is broken in that sense, then so is the code Linus is advocating for. Do you still think "broken" was the right word to use? Why?
      - raverbashing 11y ago
        I think there's also the issue of limited compiler support for that feature Maybe broken is too strong a word I agree
        tptacek 11y ago
        overflow_usub is the code that gets called when your compiler doesn't support __builtin_usub_overflow (Linus opposes both the function and the intrinsic, of course).
        raverbashing 11y ago
        True, however how it is used in this case leads to unnecessary opacity (I'm referring to the || mtu <= 7 part), which, once you know how usub_overflow works is obvious what it means, but this might not be evident and unnecessarily complicating that snipped Sometimes 'smart code' is not necessarily better (I'm open to disagreement, though)
        tptacek 11y ago
        Just to be clear: I don't think Linus is wrong (I'm also not qualified to judge that). From what I can tell, he's like, 52.5% right. What's more interesting to me is how low-stakes this issue is. Gizmodo wrote an article about it, but really, if you understand kernel C, do you even give a shit about this code? Linus could have said "we're not using GCC builtin overflow intrinics", just like that, one line no punctuation, and the issue would have been settled. But look at this thread at the number of people who extrapolated from Linus' rant that this code was bad, ruinous, unsafe, "one size fits all" (still scratching my head about that), &c. How many of Linus' defenders actually know what he's ranting about? It looks to me like: not many. What's funny is, you actually do seem like you know what he's talking about, and even you overshot the mark with "broken". :)
        micampe 11y ago
        > Sometimes 'smart code' is not necessarily better I would argue that it's usually not, especially in large and long lived projects. “Everyone knows that debugging is twice as hard as writing a program”.
shepik 11y ago
You don't. The man who wrote that code does. And judging by his response, i'd say he did - http://lkml.iu.edu/hypermail/linux/kernel/1510.3/02919.html http://lkml.iu.edu/hypermail/linux/kernel/1510.3/02919.html
marrs 11y ago
Because people are emotional and we respond more acutely to emotion.

tptacek 11y ago

I'm surprised to read this, because I feel like I understand what Linus is ranting about, and while he's probably right, he's right about such a minor and easily disposed-with point that I'm surprised to see him invest so much emotion in it. He could have just said "overflow_usub? no, not in 2015." and everyone would have agreed with him.

dkersten 11y ago

I disagree. I read a bit of the rant and didn't feel like reading the rest: its not short, its not to the point, its full of language that, despite not being directed at me, made me feel bad. The "rewritten" version is short and to the point. Its clear and it uses neutral language. I read it and immediately understood what the issue is with the proposed code and why the changed code is better. So for me, the rewritten version was many many times better because I could actually understand it without having to force myself to read something long and horrible.