Rather than "get people to write code that runs on WSL2 but not regular Linux," the goal is "get code that runs on regular Linux but not WSL to run on WSL2."
The developers' word is irrelevant. Microsoft is a business. Microsoft will pursue its long term business interests. Developers are hired to do what the business directs. So the question is really, "what would best serve Microsoft's business interests?" and not "what do the developers intend?" because in time only one question matters and unfortunately it's not the one with the best interests of non-windows-users in mind.
> Microsoft will pursue its long term business interests.
Just like all positive sum games, open source is in everyone's interests, including Microsoft's. Egoistic alturism: serving your own interests [through] serving everyone else's interests.
All the people here railing on how Microsoft is destroying open source clearly don't understand the very premise of the thing that they think they are defending.
The developers' intent does align with Microsoft's current interests -- as you say, they are hired to do what the business directs.
Perhaps their interests will shift in the future, as they clearly have in the past. But the things they build now are not from the "extend" phase of an EEE arc. At worst they are in the "embrace" phase.
If MS make it as easy to run desktop apps on Windows as it is on Linux, then the question of why even run a dedicated Linux machine if you can do everything on Windows? becomes relevant.
I suppose clipboard integration already works? And drag n' drop?
Once that mindset is heavily entrenched (e.g. in Enterprises), then the extend phase can begin.
I don't think MS are as scared as they were previously when Linux started to dominate the server landscape, and swathes of new developers (especially web backend) moved to a java, ROR and Python (or LAMP), where MS were absolutely nowhere in the stack.
The initial implementation of WSL was not mandated by the business. it was created by the developers that were tasked with exploring how to run Android apps (on the ms phone) and they went bananas and invented and created WSL. First later the business side of Microsoft came in to play on wsl
It doesn't matter where it came from. WSL is owned by MS, and the most rational framework to predict how they will use it is that they will attempt to leverage it to support their business interests.
MS is not in the business of paying developers to give away nice things for free.
This announcement is the evidence. They release some directx stubs that are completely useless outside of windows and of absolutely zero importance to anyone in the Linux Ecosystem and make a huge Microsoft hearts Linux push with it with confetti, unicorns and blushing dev-twitter influencers.
While the actual meat of directx will still be proprietary and windows-exclusive where they call the shots and make the money.
Releasing something exclusive is not evidence of EEE. Yes, it’s embracing, but that’s it.
How do you know they don’t plan to port DirectX to Linux? They’re currently attempting to upstream their changes, so why wouldn’t they port DX itself? They also don’t have to open source it (although I wish they would); they could just release a binary blob that you download and install.
Also, how do you expect Microsoft to kill Linux? To me, it seems that people who willingly choose to use Linux over Windows are generally the kinds of people who won’t be persuaded to move back. Microsoft can’t kill Linux.
Have you ever looked past your preconceived biases and considered that maybe Microsoft has actually had a change in culture over two decades? I don’t think so, because the people who scream “EEE” are the kinds of people who’ll never be swayed in their opinion.
> but it opens the door to code that runs on WSL2 that doesn't run on regular Linux.
Which is exactly what I was expecting since day one when WSL was announced. WSL is going to slowly kill Linux, or to be more accurate, it will kill any Linux (be it on servers or desktops) not Microsoft branded and distributed.
Forks on smaller embedded systems will resist for a while, until one day MS decides to port some killer technology de facto embracing them as well.
Yeah, but right now it solves the problem of not being able to run code on WSL that does run fine in Linux.
What really stops me from using Linux on the Desktop is compatibility issues with my laptop(s), reliable sleep/wake and rendering issues with High DPI display.
Microsoft released an MS Teams client for Linux which astonished me. So, I am giving them the benefit of the doubt for the time being.
The Teams client in Linux sucks, it is missing half the features and you have to pkill it after use, because simply closing it doesn't actually stop the program + it spins your fan like crazy doing God knows what in the background.
Agree. I am also looking for a laptop to mainly run Linux on. This quite widens the choices for me. Also, what keeps me and probably many others from running 100% Linux is the requirement of some commercial applications which are not available for Linux. So far using a Mac with a Linux VM was the best compromise for me, but now Windows becomes an appealing alternative.
Microsoft hasn't given up on Windows but having lost the mobile space I think they've decided to go back to their roots of developing software for many operating systems. It doesn't matter if you run Windows, Mac OS, Android, or iOS if they can sell you an Office 365 subscription.
The Windows protectionism that dominated the 2000's doesn't help Microsoft sell more product anymore.
It's not so much that Microsoft has changed but that the world has changed and Microsoft is changing with it.
I think Windows has been trying to kill linux for what, almost 30 years? Some of that conspiracy mentality may have been valid 15 years ago, but probably not anymore.
This patch adds WDDM (Windows Display Driver Model) as a Linux kernel API. The implementation just forwards to the Windows kernel, but it seems to me like someone could implement it natively in Linux. Then Windows user mode graphics drivers would work natively in Linux without WSL, and DX12 too.
This is exactly what we don't want. There's already plenty of effort wasted on GBM vs. EGLStream so introducing a third API would just lower quality even more.
This "third API" is already well supported by every relevant graphics vendor. Adopting it would actually reduce the number of APIs vendors need to deal with. And the quality of WDDM drivers has always been higher than anything Linux has.
Great, just what I want, vendors to be incentivized to force me to run closed binary blobs on my Linux box because they'll just repackage their Windows driver and still not release its source.
This is actually debatable. How many different GPUs are supported on Windows vs ob Linux? There are really only three vendors left on PC, while Linux supports these as well as a bunch of mobile GPUs...
That's not the point. They are trying to not IBM themselves.
They and the clones won the war with IBM in the 80s and 90s because IBM was worried about things that didn't matter: they wasted time with things like an operating system CP/X86 that ran DOS and 3270 emulators to their mainframes on top of a GUI system called mermaid (3270 PC) while Microsoft was writing Windows 3. Oh yeah did I mention some configurations cost $20,000 each? some configurations cost $20,000 each.
Because IBM wanted to secure its AS/400 minicomputers, mainframe, and microcomputer line and make them interoperable, as if a PC user sitting in their den would be connecting with $500,000 or so of other IBM machines, everyone else ran circles around IBM. They kept up the "whole kitchen sink" system way way past its due date.
This also happened to DEC, which responded way too late in the game to be relevant, SUN, SGI, and Wang. And it may eventually take down Oracle.
So they're intentionally taking an uncommitted, decoupled approach. I'm paying Microsoft as a result. I pay GitHub and Azure bills every month and run exclusively Linux.
They can't sway around as a monopoly like they could in 2000, once Ballmer left things changed rapidly. It's not going back. They have effectively zero cloud software (database/operating system etc), effectively zero mobile presence, and most people don't really like Windows.
In a tightly coupled stack you're only as strong as your weakest link, and MS has a bunch. Their biggest risk now is to HP or GM themselves; basically gobble up a bunch of things, blend it into indifferentiable blandness and collapse while waving a giant sceptre labelled "greatest company of 30 years ago" (HP bought DEC, Cray, Tandem, Apollo, Convex, 3Com, Phoenix, Palm and SGI and did effectively nothing with them beyond slapping an HP logo on their final pre acquisition product line and then just rode it out without any followup. HP knowing only how to fumble the ball every time for 20 years is why big business switched to Linux. HP took all the alternatives behind the barn one by one, cut them a fat check and then shot them. Simply crazy)
DirectX does run on regular Linux, courtesy of Wine/Proton. It's just a matter of reimplementing the userspace .so interface that MS will provide for access to this facility, so that it hooks into that support instead.
If I understand it correctly, it just means that GPU-accelerated code that previously only ran on "proper" Linux now can run on WSL too, being powered by DirectX behind the scenes.
You don't understand it correctly.
Nobody is complaining or even talking about the gpu driver.
> DxCore & D3D12 on Linux
Projecting a WDDM compatible abstraction for the GPU inside of Linux allowed us to recompile and bring our premiere graphics API to Linux when running in WSL.
This is the real and full D3D12 API, no imitations, pretender or reimplementation here… this is the real deal. l
> libd3d12.so and libdxcore.so are closed source, pre-compiled user mode binaries that ship as part of Windows. These binaries are compatible with glibc based distros and are automatically mounted under /usr/lib/wsl/lib and made visible to the loader. In other words, these APIs work right out of the box without the need to install additional packages or tweak the distro’s configuration. Support is currently limited to glibc based distros such as Ubuntu, Debian, Fedora, Centos, SUSE, etc…
So you can use it with MS blessed distros and only when running under WSL2. You can't use it without WSL2.
> The plan is for Microsoft to provide shims to allow the existing Linux userspace interact with DX12; 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.
How? For example code that uses CUDA on Linux, calls the GPU CUDA driver, which passes it on to the Windows part of the interface. How does that require user code that doesn't run on normal Linux to take advantage of this?
