27 ms·

It appears that Microsoft has now initiated the "Extend" phase of their classic Embrace, Extend, Extinguish playbook. The key is that the proprietary Microsoft

It appears that Microsoft has now initiated the "Extend" phase of their classic Embrace, Extend, Extinguish playbook. The key is that the proprietary Microsoft specific API added by this patch is only usable in a WSL environment as it relies on many pieces of proprietary closed source software that Microsoft is unwilling to open source. This patch does nothing but fragment the Linux ecosystem and encourage people to develop software that only works in WSL environments. With the "benefit" of forcing the Linux kernel developers to pay the maintenance costs of course.

quietbritishjim 6y ago
According to the comment by christoph-heiss, this is just a paravirtualisation technique and will appear like a normal Limux GPU driver to applications running on WSL, rather than a special DirectX for Linux API that won't work on Linux itself.
- lalaland1125 6y ago
  I'm not sure where you are getting the idea that this would expose a normal Linux GPU API. The blog post and the thread on the kernel mailing list seem quite clear in that this is explicitly designed with the goal of exposing the Windows driver API and associated client APIs like DirectX. From the email introducing the set of patches: > The projection is accomplished by exposing the WDDM (Windows Display Driver Model) interface as a set of IOCTL. This allows APIs and user mode driver written against the WDDM GPU abstraction on Windows to be ported to run within a Linux environment. This enables the port of the D3D12 and DirectML APIs as well as their associated user mode driver to Linux.
  - monocasa 6y ago
    > I'm not sure where you are getting the idea that this would expose a normal Linux GPU API. The fact that they went through the effort of porting Mesa to get OpenGL and Open CL support, and are working on Vulkan support.
    - codys 6y ago
      The standard for Linux gpu access is the dri/drm kernel interface, not the new wsl specific api they've added. Their porting Mesa to use a proprietary library that interacts with the wsl only kernel interface isn't that same as behaving like a standard Linux gpu
      - monocasa 6y ago
        It's not really a standard though, each GPU has a totally different set of ioctls and device files to the point that you can't write against a generic kernel interface either way. AFAIK, the only DRI/DRM interface with two used clients is amdgpu (of which one of the clients is proprietary). And part of the discussion on the mailing list is how to integrate this with DRI/DRM and dma-buf so it can be used by more Linux clients with less work (although still non zero like you'd have on a DRI scheme as well).
  - zamalek 6y ago
    > The blog post and the thread on the kernel mailing list seem quite clear in that this is explicitly designed with the goal of exposing the Windows driver API and associated client APIs like DirectX. Are we reading the same blog post?[1] [1]: https://devblogs.microsoft.com/directx/wp-content/uploads/sites/42/2020/05/word-image-10.png https://devblogs.microsoft.com/directx/wp-content/uploads/si...
lawik 6y ago
I find this a cynical take as far as EEE goes. But even with Microsofts mostly solid efforts into open source I find myself a bit skeptical as well. Most recently with the Live Share extension for VS Code. From skimming the licensing it is only to be used with the Visual Studio family of products. Which is an incredibly disappointing approach. I think this is simply about ML and GPU compute for WSL. And I think Microsoft is genuine in that it sees business value in doing open source work, integrating well with Linux, etc. But at the end of the day the business interests are there and different parts of the company can be motivated quite differently. Some skepticism remains warranted.
- 0-_-0 6y ago
  The license of Live Share as appears among VScode plugins indeed says "You may use the software only with Microsoft Visual Studio or Visual Studio Code", but the license of the source code of the extension on Github is an MIT license: https://github.com/MicrosoftDocs/live-share/blob/master/LICENSE-CODE https://github.com/MicrosoftDocs/live-share/blob/master/LICE...
  - Voloskaya 6y ago
    This is not the code of the extension, it's just documentation.
- deleted 6y ago
  [deleted]
- leeter 6y ago
  I think it is as well, honestly the DX12 part of this is DOA as far as I'm concerned because it's not open source. So that leaves the better support for other APIs as the key delivered feature. Could MS fix that by setting DX12 up as an open to implement API and open sourcing much of this? Yes. But until they do you're better of using the various translation layers from DX to vulkan when using linux even on WSL.
iforgotpassword 6y ago
While this was my initial thought as well, on a second thought that doesn't make too much sense. Well depending on whether you're wearing your tinfoil hat properly, you could say this is for testing the waters, but who the fsck would target their game at this? Write against naive Linux but use DirectX for the graphics? Just why? Sounds like the most stupid thing ever. The CUDA support thing from other comments below seems the only sane use case so far, and in that case I don't really see the EEE either, but just good old "make shit work".
- skohan 6y ago
  EEE is incremental by nature. This represents a lever they could use to create an ecosystem of Linux software which only works on WSL. > but who the fsck would target their game at this? It doesn't have to be games. Maybe MS releases an ML visualization library for Linux which requires D3D. It's not so far fetched. Given the cumulative pain developers have had to deal with supporting IE6 over the years, I think it's warranted to be wary of this kind of thing.
  - iforgotpassword 6y ago
    Eh, still not convinced. Porting that to OpenGL is half a day of work. Like I said, you might say they're testing the waters, but I'm just not paranoid enough to scream EEE yet.
jillesvangurp 6y ago
This feels more like a reverse takeover to me. MS actually has a legacy problem in the form of the windows ecosystem. Under Ballmer this was a problem that required defensive moves and rhetoric to not lose people to Linux and OS X and it didn't work. Under Nadella, a bait and switch was initiated where the problem (windows legacy) is slowly switched out for Linux. This is not the embrace and extend policy of last century. They don't care about software licenses; they care about SAAS revenue these days. In the process, they are rapidly regaining developer trust by building productive relations with the same developers they were alienating under Ballmer. It's smart. They own Github now. Most stuff that happens there is not windows centric. But increasingly the MS developer ecosystem is being untangled from windows in any case. That's necessary to future proof it. While the windows kernel is nice and the driver ecosystem around it serves MS well, it's actually been a problem for them as well. They've failed in the phone market (repeatedly) because linux was a better fit for OEMs. Also they've had Google and Apple compete with them effectively with the ipad and chrome os in a market where MS was peddling crippled laptops. These are all examples where windows legacy was part of the problem for MS. They weren't able to compete there. Their crippled laptops were too expensive and uncrippling them would kill their high end market. So people bought ipads and chrome os laptops instead. Increasingly desktop software that is not web based is getting more and more of a niche. Even office at this point runs well in a broswer and MS actively supports native applications on platforms of all their competitors (android, IOS, OSX, etc.). At this point that's not optional from a revenue point of view. A windows only office would be a problem at this stage. They support it and they actually do a decent job too. This too is something that happened very quickly under Nadella. A lot of the Azure revenue is in fact office revenue. IMHO this move to support GPU virtualization and ultimately running linux desktop apps, gets them access to a lot of niche OSS applications for Linux, the entirety of the machine learning ecosystem, and the community of professionals using that. Not all of them will switch to a windows laptop of course. But some will and they tend to be the type that spends money on their tools. Additionally, they are doing a clever play with APIs, github, cloud native stuff in Azure, development tooling etc. where they are not blocking using non MS things but merely make the choice to buy into their premium SAAS subscriptions more attractive. All of this stuff is usable without doing that but if you are using VS Code already, have your code on Github, and are doing some AI stuff in the cloud, etc; it's a small step to buy into a well integrated ecosystem provided by MS where you are using a windows laptop with their oss tools, while deploying to Azure, and maybe doing your office stuff using office 365. The value is no longer in selling the OS but up-selling SAAS and making sure the choice to buy into that is logical, easy, and natural no matter what you use. Github codespaces is a great example of that. I bet it will be really easy to setup and come with some nice SAAS subscription. It's all OSS and you are welcome to run it on AWS or your own cloud. But I bet it will be easier to run in Azure. MS tools, MS cloud, MS as the easiest place to run linux developer tools (!!!), etc. They won't force anyone to switch. They don't care about individual developers but they do care about what their bosses sign up for in terms of SAAS services. That's where the money is.
m12k 6y ago
Look, I'm not saying saying we should "trust" Microsoft not to Embrace, Extend, Extinguish if they could - but they can't and they know it, so that's not their strategy. EEE was hinged entirely on the dominance of Windows and IE for the Extinguish phase. They won on desktop, but today most of the action has moved to mobile (where Windows lost completely to iOS and Android) and webservers (where Linux is massively dominant). In those domains, they are no longer the 500 pound gorilla in the room, they're the "hey, fellow kids" oldtimer trying to fit in and get in on a piece of the action. Look at a comp sci class in the last decade, and you'll see 1/2-2/3rds of them with MacBook Pros in their laps, because it compiles iOS apps and it's a *nix so it easily runs most of the same tools as a linux webserver. That's what WSL is about, trying to win back developers. That's why they bought Xamarin and Github. That's why they released VS Code. They're trying to win back developers by meeting them whereever they are, even if they know they are targeting platforms where Microsoft is not dominant and has no hope of becoming so. They're trying to make it feasible to target a linux webserver while developing on Windows. They're trying to make Azure a serious contender for cloud computing outside of the corporate C# world. There's not a realistic scenario where they become dominant enough on those platforms to execute any kind of Extinguish move. And they don't need to - there's still tons of money to be made with just a slice of the cloud pie. I think EEE went out the window along with Balmer and the 'Windows First' doctrine. I'm not saying they wouldn't, but I'm saying they can't and they know it, and they're ok with that. All this is not to say that there's any reason for upstream to accept any bad patches that rely too much on proprietary code. But in this case, I think the analysis of the underlying motivations for that patch was outdated.
- deleted 6y ago
  [deleted]
- bad_user 6y ago
  The impression that "most of the action has moved to mobile" is just an impression. First of all the market share of desktop versus mobile is roughly 43% for the desktop, 57% for mobiles and tablets. More importantly however is that the rise of mobiles has been sharp since 2009, but it's been stagnating since 2017 and this stagnation trend is clear. Mobile devices too are a commodity, their market isn't growing any bigger and people aren't replacing their phones as often. The market for the desktop did not shrink. It just reached saturation. And as it will become increasingly clear, mobiles have reached saturation too. What devices do people use in companies to do their jobs? Laptops. Sometimes tablets, for drawing on them, although a piece of paper would do. Mobile devices have been and remain essential for communications, this meant phone calls in the past, nowadays it means WhatsApp, Slack, email, along with shitposting on Facebook/Instagram/Twitter, but that's about it. > "webservers (where Linux is massively dominant)" Sorry to disappoint you, but the market for web servers is actually small, unless you're Amazon and Microsoft realized at some point that selling Linux boxes on Azure is probably more lucrative than what they were doing. The web servers space was never Microsoft's so they had nothing to lose. But the enterprise space is dominated by Microsoft, with their dominance only increasing. Exchange, Sharepoint, Office 365, Skype, Microsoft Teams, Azure DevOps, freaking Yammer, MS SQL, soon GitHub, their reach in the enterprise and their adoption, once you're familiar with the space, is actually quite scary. I have to hand it to them, they became really good at marketing. Otherwise I can't explain this portrayal of them as being the underdog. Or the constant nagging messages I see about them having changed, due to them releasing VS Code or .NET Core. No they haven't changed much. The tooling they make for developers has always been top notch and while .NET was proprietary, they standardized it and they never attacked Mono. Office has been available on Macs since 1989. And they no longer target Linux with patent threats of course, they target Android instead. Until they'll find some way to sell Android. They adopted Chromium, a master move since now they can cut some development costs and win back some users and sell them on Bing too. We'll probably see them windowfying Android too. --- Note that I do enjoy several Microsoft products. But I'm always skeptical when hearing about their motivation. I don't understand what makes people cheer for these big companies, as if they are sports teams. Use their products for what they are and dump them as soon as you find something better.
dazzawazza 6y ago
As a FreeBSD user I find this kind of comment hilarious given I see Linux specific code littering upstream open source projects with no thought for other platforms on a regular basis. I occasionally see resistance to fixing these issues as well.
- AsyncAwait 6y ago
  As a Linux user I find this kind of comment hilarious given I see FreeBSD specific code littering upstream open source projects with no thought for other platforms on a regular basis. Why for example are Jails not compatible with Linux? Is that not considered upstream because FreeBSD's "integrated"? How convenient. I think what you see is happening because these "upstream" projects are actually primarily for Linux and by Linux devs. They just happen to work on BSD as well, but weren't you guys saying this whole time how the BSD approach of having everything integrated into one system is better and the whole GNU/Linux ecosystem of several upstream components is strictly worse? So what exactly are you complaining about? Us trying to use Linux-specific features to make the Linux ecosystem the best, rather than target the lowest common denominator while you guys take full advantage of FreeBSD's specifics? Seems less than fair to me.
  - adamrt 6y ago
    > I see FreeBSD specific code littering upstream open source projects Any examples? > Why for example are Jails not compatible with Linux? What? Jails originated in FreeBSD over 20 years ago? This question doesn't make sense. The OP was referring to systemd affecting upstream by requiring systemd for things (ie Gnome). Are you saying there are pieces of software you have always used, but no longer can because they directly rely on jails? I don't even use FreeBSD, but this was a weird argument.
    - AsyncAwait 6y ago
      I am saying GNOME is primarily a Linux desktop environment, developed practically exclusively by Linux users and thus it makes sense for it to make use of Linux specific features, just as it makes sense for FreeBSD technologies to take full advantage of FreeBSD-exclusive features. Just because GNOME wasn't using systemd in the 90s when systemd didn't even exist does not mean it should not use it ever, even if it makes sense for GNOME devs to do so now.
foxhill 6y ago
i (and others) called this 3 years ago[1]. people need to stop using windows, entirely. i recently built a gaming machine, pretty high spec, and i've resolved to never install windows on it. there are plenty of games i can't play, a few that i would like to. but i wont give money to developers that wont release linux versions of their games - even when they are utilising engines that have linux ports (PUBG being the most recent example i can think of, but any unreal/unity engine based game). there's no reason to use windows any more (for people like us, at least). [1]: https://news.ycombinator.com/item?id=14320200 https://news.ycombinator.com/item?id=14320200
- golergka 6y ago
  As a game developer, for most mid-tier inside titles releasing Linux version costs more than it makes, so, no. And regarding using Windows: company's behavior is important, but product quality, especially when it's a tool you use every day for work, is more important. Linux is ok for certain types of developers, it's still awful for normal users, abysmal for office work and obviously not a choice if you develop Windows software.
  - franga2000 6y ago
    > As a game developer, for most mid-tier inside titles releasing Linux version costs more than it makes, so, no. What are the main costs of releasing a Linux version of a game when using Unity or Unreal? My limited experience with Unity has been "check the Linux box, click the build button". It even cross-compiles no problem. People I know tell me Unreal is similar. It's not like they have to do a full run of play-testing for Linux. Just check if it starts, play for 10 minutes and release that. We know we're a minority so we're willing to put up with bugs. Even if there's only 100 people who'd buy it only if it ran on Linux, that should pretty much cover the couple hours of dev time.
    - coldpie 6y ago
      I can tell you've never released a popular product on Linux. It's a lottttt more effort than you're implying. To do it well, you need to have Linux as a target from the start of your development, it's not something you can tack on to the end. Linux graphics drivers are very different from Windows (the AMD stack isn't even the same codebase). Linux window managers are... wild. You need to build to an ABI that will be supported across distros, which mostly means the Steam Runtime, which means you need to go learn about and understand that. You can't introduce any platform assumptions ("ehh, I'll just hardcode this path with a backslash... oops"). Once you release, you're talking support for dozens of different distros, different versions of distros, different package managers, different filesystems. I know what you're going to say: "Just support Ubuntu LTS and ignore everyone else". Well, now you've just cut your customer base by at least 75%[1], and your customers on other distros are going to demand support anyway. Do you tell a paying customer to F-off because they're not using a distro with only ~20% of the market? Supporting Linux is hard. So is supporting Windows, but if Windows makes up 98% of your customer base, it's justified. 2%? Ehhhhh. (P.S. I love Linux. See my profile. This is the kind of stuff I deal with every single day.) [1] https://boilingsteam.com/we-dont-game-on-the-same-distros-no-more/ https://boilingsteam.com/we-dont-game-on-the-same-distros-no...
gigatexal 6y ago
How exactly will they extinguish Linux and open source?
billars 6y ago
I even doubt the patch will be accepted upstream. That patch adds nothing for other distros and is not convenient to maintain upstream.
AnIdiotOnTheNet 6y ago
> This patch does nothing but fragment the Linux ecosystem Proof that Microsoft really has embraced Open Source development.
app4soft 6y ago
> It appears that Microsoft has now initiated the "Extend" phase of their classic Embrace, Extend, Extinguish playbook. Or, much worse, M$ now trying to kill Linux as desktop OS, same way as Elop killed Symbian as smartphone OS.
wicket 6y ago
It looks like they are already at the "Extinguish" phase for email. Try reading this: https://lkml.org/lkml/2020/5/19/1527 https://lkml.org/lkml/2020/5/19/1527 :(
- mwcampbell 6y ago
  I think that's a bit hyperbolic. The Outlook team's choice to not do word wrapping in the plain-text version of an email is unfortunate, but defensible IMO, considering that most people use an email client that can display HTML email. And before the defenders of plain-text-only email chime in, HTML email has features that most people actually want. The world has moved on from the time when emails were displayed in fixed-width terminals. So Microsoft has as well. Disclosure: I work at Microsoft (on the Windows accessibility team). At work, I use Outlook. Outside of work, I use Mozilla Thunderbird, but even there I send HTML emails sometimes.
  - wicket 6y ago
    I don't think it's hyperbolic. If someone has sent you an email in plain text with wrapped lines, your mail client will know this and it would be reasonable to assume that perhaps the sender may be using a mail client not capable of rendering HTML emails nor autowrapping long lines. It would be a sensible choice to format the reply in the same format as that of the email received. By stating "HTML email has features that most people actually want. The world has moved on...", you seem to be implying that the primary method of communication of Linux kernel developers is irrelevant and their use-case for email is not important. In fact, the more I think about this, this is a classic example of Embrace, Extend, Extinguish.
    - mwcampbell 6y ago
      I think what we have here isn't a deliberate effort to extinguish a standard, but a clash between two different cultures. LKML follows traditional hacker norms, from the days of actual terminals and slow connections, whereas Outlook is built for the world of GUIs, WYSIWYG, and more or less high-speed connections. The latter is what the vast majority of people have chosen, so it's a sensible business decision for Microsoft to not pay much attention to the old ways. It's just unfortunate when those two worlds collide.
2OEH8eoCRo0 6y ago
I hate how this is constantly brought up. Yes- that was a Microsoft strategy and might still be. With that said, Microsoft has no power to make people switch. If people switch off of desktop Linux in favor of Windows it's because Windows is either a better product or Linux was too much of an issue. Why shouldn't consumers choose the better product for themselves? Why shouldn't Microsoft or Linux compete for business? Why do you care so much if someone wants to use Linux or Windows? >With the "benefit" of forcing the Linux kernel developers to pay the maintenance costs of course. No. Nobody is forced to maintain this. If Microsoft stops maintaining it then Linux is free to kick this to the curb.
Rusky 6y ago
> The key is that the proprietary Microsoft specific API added by this patch is only usable in a WSL environment The other key, which everyone crying "Extend" seems so eager to ignore, is that they don't actually want anyone to use this API: https://lkml.org/lkml/2020/5/19/1139 https://lkml.org/lkml/2020/5/19/1139 "I'll explain below why we had to pipe DX12 all the way into the Linux guest, but this is not to introduce DX12 into the Linux world as competition. There is no intent for anyone in the Linux world to start coding for the DX12 API." They want people to continue to use OpenGL/Vulkan/OpenCL/etc., and this is just their mechanism for getting those APIs GPU access when running under WSL: https://www.collabora.com/news-and-blog/news-and-events/introducing-opencl-and-opengl-on-directx.html https://www.collabora.com/news-and-blog/news-and-events/intr... "We have recently announced work on mapping layers that will bring hardware acceleration for OpenCL and OpenGL on top of DX12. We will be using these layers to provide hardware accelerated OpenGL and OpenCL to WSL through the Mesa library."
- colejohnson66 6y ago
  > There is no intent for anyone in the Linux world to start coding for the DX12 API. I took that to mean that the developers on Linux are the people who won’t switch to DX even if it was ported.
cs702 6y ago
Keep in mind, a ton of people and companies are asking for this, because they genuinely want to use hardware-accelerated PyTorch and TensorFlow "through a Linux-thingy" on Windows. BUT I MUST AGREE WITH YOU that, over time, this is likely to fragment the Linux ecosystem and encourage people to develop software that works only in Windows "with the Linux-thingy installed" environments. That's because sooner or later, people using Windows will publish important AI papers or release must-have software or do something else with code that runs only on Windows "with the Linux-thingy installed." The "Linux-thingy" becomes a dependency that gets installed in the background. It becomes a near-invisible component of Windows, abstracted away by layers of Microsoft APIs, code, standards, etc. The "Linux-thingy" on Windows, in other words, becomes like an init system on Linux, which can eventually be replaced in whole or in part without most people caring or noticing. Most Linux users don't care if their Linux machine uses Systemd, a Sys V Init, or even the dead-ended Upstart. That's the "Extinguish" part.
- smaudet 6y ago
  I do think that's a real concern...however in some ways this is an admission of failure - users like what's in the WSL enough that they want more linux, versus just some subsystem which is consumed by other apps. Also, I think linux users (desktop/servers) who actually write code and provide updates for programs, aren't likely to pause the world for WSL. Its not exactly 'linux' nor the destination for their code, WSL stands a risk of becoming obsolete, if not properly maintained etc. Its also good in some sense, it exposes users to linux capabilities and the like, who might not have had the guts to run a live cd or deal with modern hardware foibles.
modmans2nd 6y ago
No. They are not that company anymore and it’s been clear they have not been that way for over a decade. This is a step towards moving their API over to Linux so they can dump Windows as an OS and provide it as a docker container service service for enterprise.

quietbritishjim 6y ago

According to the comment by christoph-heiss, this is just a paravirtualisation technique and will appear like a normal Limux GPU driver to applications running on WSL, rather than a special DirectX for Linux API that won't work on Linux itself.

lalaland1125 6y ago
I'm not sure where you are getting the idea that this would expose a normal Linux GPU API. The blog post and the thread on the kernel mailing list seem quite clear in that this is explicitly designed with the goal of exposing the Windows driver API and associated client APIs like DirectX. From the email introducing the set of patches: > The projection is accomplished by exposing the WDDM (Windows Display Driver Model) interface as a set of IOCTL. This allows APIs and user mode driver written against the WDDM GPU abstraction on Windows to be ported to run within a Linux environment. This enables the port of the D3D12 and DirectML APIs as well as their associated user mode driver to Linux.
- monocasa 6y ago
  > I'm not sure where you are getting the idea that this would expose a normal Linux GPU API. The fact that they went through the effort of porting Mesa to get OpenGL and Open CL support, and are working on Vulkan support.
  - codys 6y ago
    The standard for Linux gpu access is the dri/drm kernel interface, not the new wsl specific api they've added. Their porting Mesa to use a proprietary library that interacts with the wsl only kernel interface isn't that same as behaving like a standard Linux gpu
    - monocasa 6y ago
      It's not really a standard though, each GPU has a totally different set of ioctls and device files to the point that you can't write against a generic kernel interface either way. AFAIK, the only DRI/DRM interface with two used clients is amdgpu (of which one of the clients is proprietary). And part of the discussion on the mailing list is how to integrate this with DRI/DRM and dma-buf so it can be used by more Linux clients with less work (although still non zero like you'd have on a DRI scheme as well).
- zamalek 6y ago
  > The blog post and the thread on the kernel mailing list seem quite clear in that this is explicitly designed with the goal of exposing the Windows driver API and associated client APIs like DirectX. Are we reading the same blog post?[1] [1]: https://devblogs.microsoft.com/directx/wp-content/uploads/sites/42/2020/05/word-image-10.png https://devblogs.microsoft.com/directx/wp-content/uploads/si...

lawik 6y ago

I find this a cynical take as far as EEE goes. But even with Microsofts mostly solid efforts into open source I find myself a bit skeptical as well. Most recently with the Live Share extension for VS Code. From skimming the licensing it is only to be used with the Visual Studio family of products. Which is an incredibly disappointing approach. I think this is simply about ML and GPU compute for WSL. And I think Microsoft is genuine in that it sees business value in doing open source work, integrating well with Linux, etc. But at the end of the day the business interests are there and different parts of the company can be motivated quite differently. Some skepticism remains warranted.

0-_-0 6y ago
The license of Live Share as appears among VScode plugins indeed says "You may use the software only with Microsoft Visual Studio or Visual Studio Code", but the license of the source code of the extension on Github is an MIT license: https://github.com/MicrosoftDocs/live-share/blob/master/LICENSE-CODE https://github.com/MicrosoftDocs/live-share/blob/master/LICE...
- Voloskaya 6y ago
  This is not the code of the extension, it's just documentation.
deleted 6y ago
[deleted]
leeter 6y ago
I think it is as well, honestly the DX12 part of this is DOA as far as I'm concerned because it's not open source. So that leaves the better support for other APIs as the key delivered feature. Could MS fix that by setting DX12 up as an open to implement API and open sourcing much of this? Yes. But until they do you're better of using the various translation layers from DX to vulkan when using linux even on WSL.

iforgotpassword 6y ago

While this was my initial thought as well, on a second thought that doesn't make too much sense. Well depending on whether you're wearing your tinfoil hat properly, you could say this is for testing the waters, but who the fsck would target their game at this? Write against naive Linux but use DirectX for the graphics? Just why? Sounds like the most stupid thing ever. The CUDA support thing from other comments below seems the only sane use case so far, and in that case I don't really see the EEE either, but just good old "make shit work".

skohan 6y ago
EEE is incremental by nature. This represents a lever they could use to create an ecosystem of Linux software which only works on WSL. > but who the fsck would target their game at this? It doesn't have to be games. Maybe MS releases an ML visualization library for Linux which requires D3D. It's not so far fetched. Given the cumulative pain developers have had to deal with supporting IE6 over the years, I think it's warranted to be wary of this kind of thing.
- iforgotpassword 6y ago
  Eh, still not convinced. Porting that to OpenGL is half a day of work. Like I said, you might say they're testing the waters, but I'm just not paranoid enough to scream EEE yet.

jillesvangurp 6y ago

This feels more like a reverse takeover to me. MS actually has a legacy problem in the form of the windows ecosystem. Under Ballmer this was a problem that required defensive moves and rhetoric to not lose people to Linux and OS X and it didn't work. Under Nadella, a bait and switch was initiated where the problem (windows legacy) is slowly switched out for Linux. This is not the embrace and extend policy of last century. They don't care about software licenses; they care about SAAS revenue these days. In the process, they are rapidly regaining developer trust by building productive relations with the same developers they were alienating under Ballmer. It's smart. They own Github now. Most stuff that happens there is not windows centric. But increasingly the MS developer ecosystem is being untangled from windows in any case. That's necessary to future proof it. While the windows kernel is nice and the driver ecosystem around it serves MS well, it's actually been a problem for them as well. They've failed in the phone market (repeatedly) because linux was a better fit for OEMs. Also they've had Google and Apple compete with them effectively with the ipad and chrome os in a market where MS was peddling crippled laptops. These are all examples where windows legacy was part of the problem for MS. They weren't able to compete there. Their crippled laptops were too expensive and uncrippling them would kill their high end market. So people bought ipads and chrome os laptops instead. Increasingly desktop software that is not web based is getting more and more of a niche. Even office at this point runs well in a broswer and MS actively supports native applications on platforms of all their competitors (android, IOS, OSX, etc.). At this point that's not optional from a revenue point of view. A windows only office would be a problem at this stage. They support it and they actually do a decent job too. This too is something that happened very quickly under Nadella. A lot of the Azure revenue is in fact office revenue. IMHO this move to support GPU virtualization and ultimately running linux desktop apps, gets them access to a lot of niche OSS applications for Linux, the entirety of the machine learning ecosystem, and the community of professionals using that. Not all of them will switch to a windows laptop of course. But some will and they tend to be the type that spends money on their tools. Additionally, they are doing a clever play with APIs, github, cloud native stuff in Azure, development tooling etc. where they are not blocking using non MS things but merely make the choice to buy into their premium SAAS subscriptions more attractive. All of this stuff is usable without doing that but if you are using VS Code already, have your code on Github, and are doing some AI stuff in the cloud, etc; it's a small step to buy into a well integrated ecosystem provided by MS where you are using a windows laptop with their oss tools, while deploying to Azure, and maybe doing your office stuff using office 365. The value is no longer in selling the OS but up-selling SAAS and making sure the choice to buy into that is logical, easy, and natural no matter what you use. Github codespaces is a great example of that. I bet it will be really easy to setup and come with some nice SAAS subscription. It's all OSS and you are welcome to run it on AWS or your own cloud. But I bet it will be easier to run in Azure. MS tools, MS cloud, MS as the easiest place to run linux developer tools (!!!), etc. They won't force anyone to switch. They don't care about individual developers but they do care about what their bosses sign up for in terms of SAAS services. That's where the money is.

m12k 6y ago

Look, I'm not saying saying we should "trust" Microsoft not to Embrace, Extend, Extinguish if they could - but they can't and they know it, so that's not their strategy. EEE was hinged entirely on the dominance of Windows and IE for the Extinguish phase. They won on desktop, but today most of the action has moved to mobile (where Windows lost completely to iOS and Android) and webservers (where Linux is massively dominant). In those domains, they are no longer the 500 pound gorilla in the room, they're the "hey, fellow kids" oldtimer trying to fit in and get in on a piece of the action. Look at a comp sci class in the last decade, and you'll see 1/2-2/3rds of them with MacBook Pros in their laps, because it compiles iOS apps and it's a *nix so it easily runs most of the same tools as a linux webserver. That's what WSL is about, trying to win back developers. That's why they bought Xamarin and Github. That's why they released VS Code. They're trying to win back developers by meeting them whereever they are, even if they know they are targeting platforms where Microsoft is not dominant and has no hope of becoming so. They're trying to make it feasible to target a linux webserver while developing on Windows. They're trying to make Azure a serious contender for cloud computing outside of the corporate C# world. There's not a realistic scenario where they become dominant enough on those platforms to execute any kind of Extinguish move. And they don't need to - there's still tons of money to be made with just a slice of the cloud pie. I think EEE went out the window along with Balmer and the 'Windows First' doctrine. I'm not saying they wouldn't, but I'm saying they can't and they know it, and they're ok with that. All this is not to say that there's any reason for upstream to accept any bad patches that rely too much on proprietary code. But in this case, I think the analysis of the underlying motivations for that patch was outdated.

deleted 6y ago
[deleted]
bad_user 6y ago
The impression that "most of the action has moved to mobile" is just an impression. First of all the market share of desktop versus mobile is roughly 43% for the desktop, 57% for mobiles and tablets. More importantly however is that the rise of mobiles has been sharp since 2009, but it's been stagnating since 2017 and this stagnation trend is clear. Mobile devices too are a commodity, their market isn't growing any bigger and people aren't replacing their phones as often. The market for the desktop did not shrink. It just reached saturation. And as it will become increasingly clear, mobiles have reached saturation too. What devices do people use in companies to do their jobs? Laptops. Sometimes tablets, for drawing on them, although a piece of paper would do. Mobile devices have been and remain essential for communications, this meant phone calls in the past, nowadays it means WhatsApp, Slack, email, along with shitposting on Facebook/Instagram/Twitter, but that's about it. > "webservers (where Linux is massively dominant)" Sorry to disappoint you, but the market for web servers is actually small, unless you're Amazon and Microsoft realized at some point that selling Linux boxes on Azure is probably more lucrative than what they were doing. The web servers space was never Microsoft's so they had nothing to lose. But the enterprise space is dominated by Microsoft, with their dominance only increasing. Exchange, Sharepoint, Office 365, Skype, Microsoft Teams, Azure DevOps, freaking Yammer, MS SQL, soon GitHub, their reach in the enterprise and their adoption, once you're familiar with the space, is actually quite scary. I have to hand it to them, they became really good at marketing. Otherwise I can't explain this portrayal of them as being the underdog. Or the constant nagging messages I see about them having changed, due to them releasing VS Code or .NET Core. No they haven't changed much. The tooling they make for developers has always been top notch and while .NET was proprietary, they standardized it and they never attacked Mono. Office has been available on Macs since 1989. And they no longer target Linux with patent threats of course, they target Android instead. Until they'll find some way to sell Android. They adopted Chromium, a master move since now they can cut some development costs and win back some users and sell them on Bing too. We'll probably see them windowfying Android too. --- Note that I do enjoy several Microsoft products. But I'm always skeptical when hearing about their motivation. I don't understand what makes people cheer for these big companies, as if they are sports teams. Use their products for what they are and dump them as soon as you find something better.

dazzawazza 6y ago

As a FreeBSD user I find this kind of comment hilarious given I see Linux specific code littering upstream open source projects with no thought for other platforms on a regular basis. I occasionally see resistance to fixing these issues as well.

AsyncAwait 6y ago
As a Linux user I find this kind of comment hilarious given I see FreeBSD specific code littering upstream open source projects with no thought for other platforms on a regular basis. Why for example are Jails not compatible with Linux? Is that not considered upstream because FreeBSD's "integrated"? How convenient. I think what you see is happening because these "upstream" projects are actually primarily for Linux and by Linux devs. They just happen to work on BSD as well, but weren't you guys saying this whole time how the BSD approach of having everything integrated into one system is better and the whole GNU/Linux ecosystem of several upstream components is strictly worse? So what exactly are you complaining about? Us trying to use Linux-specific features to make the Linux ecosystem the best, rather than target the lowest common denominator while you guys take full advantage of FreeBSD's specifics? Seems less than fair to me.
- adamrt 6y ago
  > I see FreeBSD specific code littering upstream open source projects Any examples? > Why for example are Jails not compatible with Linux? What? Jails originated in FreeBSD over 20 years ago? This question doesn't make sense. The OP was referring to systemd affecting upstream by requiring systemd for things (ie Gnome). Are you saying there are pieces of software you have always used, but no longer can because they directly rely on jails? I don't even use FreeBSD, but this was a weird argument.
  - AsyncAwait 6y ago
    I am saying GNOME is primarily a Linux desktop environment, developed practically exclusively by Linux users and thus it makes sense for it to make use of Linux specific features, just as it makes sense for FreeBSD technologies to take full advantage of FreeBSD-exclusive features. Just because GNOME wasn't using systemd in the 90s when systemd didn't even exist does not mean it should not use it ever, even if it makes sense for GNOME devs to do so now.

foxhill 6y ago

i (and others) called this 3 years ago[1]. people need to stop using windows, entirely. i recently built a gaming machine, pretty high spec, and i've resolved to never install windows on it. there are plenty of games i can't play, a few that i would like to. but i wont give money to developers that wont release linux versions of their games - even when they are utilising engines that have linux ports (PUBG being the most recent example i can think of, but any unreal/unity engine based game). there's no reason to use windows any more (for people like us, at least). [1]: https://news.ycombinator.com/item?id=14320200 https://news.ycombinator.com/item?id=14320200

golergka 6y ago
As a game developer, for most mid-tier inside titles releasing Linux version costs more than it makes, so, no. And regarding using Windows: company's behavior is important, but product quality, especially when it's a tool you use every day for work, is more important. Linux is ok for certain types of developers, it's still awful for normal users, abysmal for office work and obviously not a choice if you develop Windows software.
- franga2000 6y ago
  > As a game developer, for most mid-tier inside titles releasing Linux version costs more than it makes, so, no. What are the main costs of releasing a Linux version of a game when using Unity or Unreal? My limited experience with Unity has been "check the Linux box, click the build button". It even cross-compiles no problem. People I know tell me Unreal is similar. It's not like they have to do a full run of play-testing for Linux. Just check if it starts, play for 10 minutes and release that. We know we're a minority so we're willing to put up with bugs. Even if there's only 100 people who'd buy it only if it ran on Linux, that should pretty much cover the couple hours of dev time.
  - coldpie 6y ago
    I can tell you've never released a popular product on Linux. It's a lottttt more effort than you're implying. To do it well, you need to have Linux as a target from the start of your development, it's not something you can tack on to the end. Linux graphics drivers are very different from Windows (the AMD stack isn't even the same codebase). Linux window managers are... wild. You need to build to an ABI that will be supported across distros, which mostly means the Steam Runtime, which means you need to go learn about and understand that. You can't introduce any platform assumptions ("ehh, I'll just hardcode this path with a backslash... oops"). Once you release, you're talking support for dozens of different distros, different versions of distros, different package managers, different filesystems. I know what you're going to say: "Just support Ubuntu LTS and ignore everyone else". Well, now you've just cut your customer base by at least 75%[1], and your customers on other distros are going to demand support anyway. Do you tell a paying customer to F-off because they're not using a distro with only ~20% of the market? Supporting Linux is hard. So is supporting Windows, but if Windows makes up 98% of your customer base, it's justified. 2%? Ehhhhh. (P.S. I love Linux. See my profile. This is the kind of stuff I deal with every single day.) [1] https://boilingsteam.com/we-dont-game-on-the-same-distros-no-more/ https://boilingsteam.com/we-dont-game-on-the-same-distros-no...

gigatexal 6y ago

How exactly will they extinguish Linux and open source?

billars 6y ago

I even doubt the patch will be accepted upstream. That patch adds nothing for other distros and is not convenient to maintain upstream.

AnIdiotOnTheNet 6y ago

> This patch does nothing but fragment the Linux ecosystem Proof that Microsoft really has embraced Open Source development.

app4soft 6y ago

> It appears that Microsoft has now initiated the "Extend" phase of their classic Embrace, Extend, Extinguish playbook. Or, much worse, M$ now trying to kill Linux as desktop OS, same way as Elop killed Symbian as smartphone OS.

wicket 6y ago

It looks like they are already at the "Extinguish" phase for email. Try reading this: https://lkml.org/lkml/2020/5/19/1527 https://lkml.org/lkml/2020/5/19/1527 :(

mwcampbell 6y ago
I think that's a bit hyperbolic. The Outlook team's choice to not do word wrapping in the plain-text version of an email is unfortunate, but defensible IMO, considering that most people use an email client that can display HTML email. And before the defenders of plain-text-only email chime in, HTML email has features that most people actually want. The world has moved on from the time when emails were displayed in fixed-width terminals. So Microsoft has as well. Disclosure: I work at Microsoft (on the Windows accessibility team). At work, I use Outlook. Outside of work, I use Mozilla Thunderbird, but even there I send HTML emails sometimes.
- wicket 6y ago
  I don't think it's hyperbolic. If someone has sent you an email in plain text with wrapped lines, your mail client will know this and it would be reasonable to assume that perhaps the sender may be using a mail client not capable of rendering HTML emails nor autowrapping long lines. It would be a sensible choice to format the reply in the same format as that of the email received. By stating "HTML email has features that most people actually want. The world has moved on...", you seem to be implying that the primary method of communication of Linux kernel developers is irrelevant and their use-case for email is not important. In fact, the more I think about this, this is a classic example of Embrace, Extend, Extinguish.
  - mwcampbell 6y ago
    I think what we have here isn't a deliberate effort to extinguish a standard, but a clash between two different cultures. LKML follows traditional hacker norms, from the days of actual terminals and slow connections, whereas Outlook is built for the world of GUIs, WYSIWYG, and more or less high-speed connections. The latter is what the vast majority of people have chosen, so it's a sensible business decision for Microsoft to not pay much attention to the old ways. It's just unfortunate when those two worlds collide.

2OEH8eoCRo0 6y ago

I hate how this is constantly brought up. Yes- that was a Microsoft strategy and might still be. With that said, Microsoft has no power to make people switch. If people switch off of desktop Linux in favor of Windows it's because Windows is either a better product or Linux was too much of an issue. Why shouldn't consumers choose the better product for themselves? Why shouldn't Microsoft or Linux compete for business? Why do you care so much if someone wants to use Linux or Windows? >With the "benefit" of forcing the Linux kernel developers to pay the maintenance costs of course. No. Nobody is forced to maintain this. If Microsoft stops maintaining it then Linux is free to kick this to the curb.

Rusky 6y ago

> The key is that the proprietary Microsoft specific API added by this patch is only usable in a WSL environment The other key, which everyone crying "Extend" seems so eager to ignore, is that they don't actually want anyone to use this API: https://lkml.org/lkml/2020/5/19/1139 https://lkml.org/lkml/2020/5/19/1139 "I'll explain below why we had to pipe DX12 all the way into the Linux guest, but this is not to introduce DX12 into the Linux world as competition. There is no intent for anyone in the Linux world to start coding for the DX12 API." They want people to continue to use OpenGL/Vulkan/OpenCL/etc., and this is just their mechanism for getting those APIs GPU access when running under WSL: https://www.collabora.com/news-and-blog/news-and-events/introducing-opencl-and-opengl-on-directx.html https://www.collabora.com/news-and-blog/news-and-events/intr... "We have recently announced work on mapping layers that will bring hardware acceleration for OpenCL and OpenGL on top of DX12. We will be using these layers to provide hardware accelerated OpenGL and OpenCL to WSL through the Mesa library."

colejohnson66 6y ago
> There is no intent for anyone in the Linux world to start coding for the DX12 API. I took that to mean that the developers on Linux are the people who won’t switch to DX even if it was ported.

cs702 6y ago

Keep in mind, a ton of people and companies are asking for this, because they genuinely want to use hardware-accelerated PyTorch and TensorFlow "through a Linux-thingy" on Windows. BUT I MUST AGREE WITH YOU that, over time, this is likely to fragment the Linux ecosystem and encourage people to develop software that works only in Windows "with the Linux-thingy installed" environments. That's because sooner or later, people using Windows will publish important AI papers or release must-have software or do something else with code that runs only on Windows "with the Linux-thingy installed." The "Linux-thingy" becomes a dependency that gets installed in the background. It becomes a near-invisible component of Windows, abstracted away by layers of Microsoft APIs, code, standards, etc. The "Linux-thingy" on Windows, in other words, becomes like an init system on Linux, which can eventually be replaced in whole or in part without most people caring or noticing. Most Linux users don't care if their Linux machine uses Systemd, a Sys V Init, or even the dead-ended Upstart. That's the "Extinguish" part.

smaudet 6y ago
I do think that's a real concern...however in some ways this is an admission of failure - users like what's in the WSL enough that they want more linux, versus just some subsystem which is consumed by other apps. Also, I think linux users (desktop/servers) who actually write code and provide updates for programs, aren't likely to pause the world for WSL. Its not exactly 'linux' nor the destination for their code, WSL stands a risk of becoming obsolete, if not properly maintained etc. Its also good in some sense, it exposes users to linux capabilities and the like, who might not have had the guts to run a live cd or deal with modern hardware foibles.

modmans2nd 6y ago

No. They are not that company anymore and it’s been clear they have not been that way for over a decade. This is a step towards moving their API over to Linux so they can dump Windows as an OS and provide it as a docker container service service for enterprise.