4 ms·

Extinguish, I have no examples. But Embrace and Extend, here is a possible one. Not saying I think this is a case of the first two E's necessarily but I know ot

Extinguish, I have no examples. But Embrace and Extend, here is a possible one. Not saying I think this is a case of the first two E's necessarily but I know other people have pointed it out. 1. Build WSL2 and incorporate Linux kernel into Windows with great integration. 2. Add DirectX and GPU acceleration support for Linux that works in WSL2 only and not in regular Linux: https://www.phoronix.com/scan.php?page=news_item&px=Linux-GUI-Apps-GPU-WSL2 https://www.phoronix.com/scan.php?page=news_item&px=Linux-GU.... These two steps could certainly be looked at as Embrace and Extend, although I admittedly fail to see how they could take an Extinguish step from here.

zeusk 6y ago
Well, the way directx on wsl works is it redirects dxgkrnl escapes/ioctls to host windows system something not possible on native Linux.
- capableweb 6y ago
  Well, that doesn't matter in the end. Part of extend is to take whatever you embraced, and add things you cannot do. So it's a success in that sense. Seems you're trying to put it as "What can Microsoft do if Linux doesn't support it?" when they can, if they want to, do plenty about it.
  - zeusk 6y ago
    I think you're wrong there, bringing dxgkrnl to Linux would have been a much more involved process instead of just providing a redirect. dxgkrnl is by far the heaviest NT module afaik.
    - capableweb 6y ago
      > bringing dxgkrnl to Linux would have been a much more involved process instead of just providing a redirect Of course, that's how collaboration works. Instead of going the harder but "improving the entire ecosystem" way, Microsoft chose the easiest + the one where they can extend stuff in a non-compatible way.
      - zeusk 6y ago
        The way you look, you'll find malice in every little thing.
phkahler 6y ago
I thought they wanted to bring DX natively to Linux as well but got rejected. That would be an extend that easily leads to extinguish. You get Linux application developers to use the proprietary API to build stuff, then reduce support for everything but "MS Linux". This is why people need to be vigilant about the freedom of the entire stack. Over time we may see MS playing nice, but there really is no value to FLOSS developers in having a closed source graphics API on Linux.
amluto 6y ago
DirectX on Wine on native Linux seems to work okay already. GPU on Linux is a seriously mixed bag, but this is largely nVidia’s fault, not Microsoft’s. GPU on Windows works okay because Microsoft is willing to play the let-nVidia-do-whatever-it-wants game on Windows. GPU on Mac is a bit dicey because Apple seems to be unwilling to play this game. nVidia gets away with this garbage on Linux because (as I understand it) they have strong-armed enough vendors into bending over backwards to support their driver model. The result is that nVidia can tell end users to either put up with constant breakage or to use of several not-really-upstream-kernel-based distros to get something stable enough to support the driver properly. Sadly, nVidia has the market power to pull this off. I would love to see a big enough consortium (e.g. Red Hat, SuSE, Citrix, Oracle AMD Canonical) tell nVidia to buzz off. If all of those vendors dropped support for out-of-tree kernel GPU drivers and instead tracked upstream more closely for improved in-tree support, AMD and Intel would get a boost and nVidia might have to change its tune. And the vendors could stop wasting engineering resources to keep nVidia working. Users get easier-to-work-with systems. Everyone except nVidia wins.
jimnotgym 6y ago
Embracing and extending something, with no possible way to extinguish cannot be seen as steps one and two of an embrace, extend, extinguish strategy. That makes no sense at all
- oblio 6y ago
  Agreed! Embracing is purely positive. Extending can be negative, but it generally isn't frowned upon. Heck, it's one of the reasons for FOSS existing! Extinguish is the only purely negative part, people seem to forget that...
  - CyberDildonics 6y ago
    The extend stage was always some sort of small convenience that would be only in microsoft's version of a standard so that when people used a standard language or tool on windows, switching platforms would eventually get bogged down with changes and problems, keeping people locked in.

zeusk 6y ago

Well, the way directx on wsl works is it redirects dxgkrnl escapes/ioctls to host windows system something not possible on native Linux.

capableweb 6y ago
Well, that doesn't matter in the end. Part of extend is to take whatever you embraced, and add things you cannot do. So it's a success in that sense. Seems you're trying to put it as "What can Microsoft do if Linux doesn't support it?" when they can, if they want to, do plenty about it.
- zeusk 6y ago
  I think you're wrong there, bringing dxgkrnl to Linux would have been a much more involved process instead of just providing a redirect. dxgkrnl is by far the heaviest NT module afaik.
  - capableweb 6y ago
    > bringing dxgkrnl to Linux would have been a much more involved process instead of just providing a redirect Of course, that's how collaboration works. Instead of going the harder but "improving the entire ecosystem" way, Microsoft chose the easiest + the one where they can extend stuff in a non-compatible way.
    - zeusk 6y ago
      The way you look, you'll find malice in every little thing.

phkahler 6y ago

I thought they wanted to bring DX natively to Linux as well but got rejected. That would be an extend that easily leads to extinguish. You get Linux application developers to use the proprietary API to build stuff, then reduce support for everything but "MS Linux". This is why people need to be vigilant about the freedom of the entire stack. Over time we may see MS playing nice, but there really is no value to FLOSS developers in having a closed source graphics API on Linux.

amluto 6y ago

DirectX on Wine on native Linux seems to work okay already. GPU on Linux is a seriously mixed bag, but this is largely nVidia’s fault, not Microsoft’s. GPU on Windows works okay because Microsoft is willing to play the let-nVidia-do-whatever-it-wants game on Windows. GPU on Mac is a bit dicey because Apple seems to be unwilling to play this game. nVidia gets away with this garbage on Linux because (as I understand it) they have strong-armed enough vendors into bending over backwards to support their driver model. The result is that nVidia can tell end users to either put up with constant breakage or to use of several not-really-upstream-kernel-based distros to get something stable enough to support the driver properly. Sadly, nVidia has the market power to pull this off. I would love to see a big enough consortium (e.g. Red Hat, SuSE, Citrix, Oracle AMD Canonical) tell nVidia to buzz off. If all of those vendors dropped support for out-of-tree kernel GPU drivers and instead tracked upstream more closely for improved in-tree support, AMD and Intel would get a boost and nVidia might have to change its tune. And the vendors could stop wasting engineering resources to keep nVidia working. Users get easier-to-work-with systems. Everyone except nVidia wins.

jimnotgym 6y ago

Embracing and extending something, with no possible way to extinguish cannot be seen as steps one and two of an embrace, extend, extinguish strategy. That makes no sense at all

oblio 6y ago
Agreed! Embracing is purely positive. Extending can be negative, but it generally isn't frowned upon. Heck, it's one of the reasons for FOSS existing! Extinguish is the only purely negative part, people seem to forget that...
- CyberDildonics 6y ago
  The extend stage was always some sort of small convenience that would be only in microsoft's version of a standard so that when people used a standard language or tool on windows, switching platforms would eventually get bogged down with changes and problems, keeping people locked in.