4 ms·

Bruce's write-ups are just great, sheer joy of reading.

by wmu 8y ago

drudru11 8y ago
True - and also remind me why I will stay away from windows
- NicoJuicy 8y ago
  Lol, because of bugs? I sense more bias and it's not bug related.
- rincebrain 8y ago
  I regret to inform you that, while I think the current Windows development methodology could use better testing (to put it mildly), things like [1][2] still crop up in other platforms. [1] - https://bugzilla.kernel.org/show_bug.cgi?id=201685 https://bugzilla.kernel.org/show_bug.cgi?id=201685 [2] - http://lkml.iu.edu/hypermail/linux/kernel/1811.2/01328.html http://lkml.iu.edu/hypermail/linux/kernel/1811.2/01328.html
  - NullPrefix 8y ago
    Don't see anything wrong with [2]. Security by default, if you want to disable protection to get some performance on defective hardware, that should be an active choice
    - rincebrain 8y ago
      The problem(s) with it were that it was underspecified _how_ negative the workload impacts were for some cases, and that it ended up in stable branches default-on before getting reverted for the impact. As Linus remarked in the thread, the people who were paranoid about the security implications already went the BSD route and disabled SMT, while the people who don't worry about it that much suddenly get a nasty perf impact by default. To quote an Intel rep in the thread: "Using these tools much more surgically is fine, if a paranoid task wants it for example, or when you know you are doing a hard core security transition. But always on? Yikes." Yes, your system should default to being secure. But there's a sliding scale when deciding on security flaw mitigations of user disruption versus level of security given. In this case, the user disruption was medium-high, and the benefits did not outweigh that, so the intersection of the two factors was refined. If this were something every skiddy toolkit were leveraging to exfiltrate astonishing amounts of data, this might fall the other way. But right now, that's not where we are.
  - Valmar 8y ago
    [2] was resolved quickly. A much revised version has landed recently. [1] is a strange bug, because the devs have consistently been unable to reproduce it, despite constantly looking over the issue. Users of ZFS have hit problems, also, suggesting that it is not an EXT4 bug, but a very subtle problem elsewhere in the block subsystem.
    - rincebrain 8y ago
      [2] was resolved after it landed in stable release branches, which is a bit late for how much impact it had. [1] was, in fact, root-caused to a blk-mq bug. https://patchwork.kernel.org/patch/10712695/ https://patchwork.kernel.org/patch/10712695/
- PhasmaFelis 8y ago
  You're only hearing about this issue because they fixed it. And you know very well that every OS has had problems that are just as dumb from time to time.
  - fit2rule 8y ago
    That may well be, but DLL's on Windows have been dumb for a long, long time. And they're still dumb.
    - PhasmaFelis 8y ago
      Honest question, how does this particular problem differ from classic dependency hell? It sounds like exactly the same sort of issue I see on Linux blogs when e.g. a broken PNG display library causes crashes in a program that doesn't display PNGs (but uses a library that uses a library that does).
      - fit2rule 8y ago
        Its correct that there are similarities, but the difference in this case is that its a system-wide policy enforcing the use of a system-provided DLL that is causing the issue (everywhere) as opposed to your scenario being more of a userspace issue that, an admittedly skilled, user can get themselves out of .. In your case, I'd fix it with some hot LD_PRELOAD action - I'm not sure how I'd endeavour to address this on a production Windows system, however.
KIFulgore 8y ago
I was lucky enough to have a class with him at DigiPen. He's an optimization genius.

Bruce's write-ups are just great, sheer joy of reading.

by wmu 8y ago

Bruce's write-ups are just great, sheer joy of reading.

drudru11 8y ago

True - and also remind me why I will stay away from windows

NicoJuicy 8y ago
Lol, because of bugs? I sense more bias and it's not bug related.
rincebrain 8y ago
I regret to inform you that, while I think the current Windows development methodology could use better testing (to put it mildly), things like [1][2] still crop up in other platforms. [1] - https://bugzilla.kernel.org/show_bug.cgi?id=201685 https://bugzilla.kernel.org/show_bug.cgi?id=201685 [2] - http://lkml.iu.edu/hypermail/linux/kernel/1811.2/01328.html http://lkml.iu.edu/hypermail/linux/kernel/1811.2/01328.html
- NullPrefix 8y ago
  Don't see anything wrong with [2]. Security by default, if you want to disable protection to get some performance on defective hardware, that should be an active choice
  - rincebrain 8y ago
    The problem(s) with it were that it was underspecified _how_ negative the workload impacts were for some cases, and that it ended up in stable branches default-on before getting reverted for the impact. As Linus remarked in the thread, the people who were paranoid about the security implications already went the BSD route and disabled SMT, while the people who don't worry about it that much suddenly get a nasty perf impact by default. To quote an Intel rep in the thread: "Using these tools much more surgically is fine, if a paranoid task wants it for example, or when you know you are doing a hard core security transition. But always on? Yikes." Yes, your system should default to being secure. But there's a sliding scale when deciding on security flaw mitigations of user disruption versus level of security given. In this case, the user disruption was medium-high, and the benefits did not outweigh that, so the intersection of the two factors was refined. If this were something every skiddy toolkit were leveraging to exfiltrate astonishing amounts of data, this might fall the other way. But right now, that's not where we are.
- Valmar 8y ago
  [2] was resolved quickly. A much revised version has landed recently. [1] is a strange bug, because the devs have consistently been unable to reproduce it, despite constantly looking over the issue. Users of ZFS have hit problems, also, suggesting that it is not an EXT4 bug, but a very subtle problem elsewhere in the block subsystem.
  - rincebrain 8y ago
    [2] was resolved after it landed in stable release branches, which is a bit late for how much impact it had. [1] was, in fact, root-caused to a blk-mq bug. https://patchwork.kernel.org/patch/10712695/ https://patchwork.kernel.org/patch/10712695/
PhasmaFelis 8y ago
You're only hearing about this issue because they fixed it. And you know very well that every OS has had problems that are just as dumb from time to time.
- fit2rule 8y ago
  That may well be, but DLL's on Windows have been dumb for a long, long time. And they're still dumb.
  - PhasmaFelis 8y ago
    Honest question, how does this particular problem differ from classic dependency hell? It sounds like exactly the same sort of issue I see on Linux blogs when e.g. a broken PNG display library causes crashes in a program that doesn't display PNGs (but uses a library that uses a library that does).
    - fit2rule 8y ago
      Its correct that there are similarities, but the difference in this case is that its a system-wide policy enforcing the use of a system-provided DLL that is causing the issue (everywhere) as opposed to your scenario being more of a userspace issue that, an admittedly skilled, user can get themselves out of .. In your case, I'd fix it with some hot LD_PRELOAD action - I'm not sure how I'd endeavour to address this on a production Windows system, however.

KIFulgore 8y ago

I was lucky enough to have a class with him at DigiPen. He's an optimization genius.