
DirectX is coming to the Windows Subsystem for Linux - modeless
https://devblogs.microsoft.com/directx/directx-heart-linux/
======
lalaland1125
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.

~~~
m12k
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.

~~~
NeverFade
> _EEE was hinged entirely on the dominance of Windows and IE for the
> Extinguish phase._

EEE was more effective when Microsoft was completely dominant, but it's
clearly still effective even when that dominance has diminished.

This move, for instance, will cause Linux users to depend on a proprietary,
closed-source API entirely controlled by Microsoft. It's very bad for Linux
and very good for Microsoft. It's a lever of Microsoft control, extended into
the rival Linux system. Very easy to see how it effectively fragments the
Linux ecosystem and allows Microsoft to forcibly pull users who come to depend
on DirectX from Linux to Windows by manipulating this lever - reducing Linux
support in the future, etc.

This is classic EEE, and the only way you can dismiss it is if you believe
their PR, as apparently you do:

> _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._

As the other comment explained, they are still a huge gorilla in spaces that
are absolutely vital to Linux: server, desktop, and laptop.

Linux as we know it lives or dies on the server and desktop / laptop markets.
Yes, Android is technically based on the Linux kernel, but it builds an
entirely different ecosystem on top of it. The Linux ecosystem is only on the
server and PC - exactly where Microsoft is competing.

Finally, the availability of this proprietary API will reduce the incentive
for hardware companies like Nvidia to allow development of direct Linux
support (drivers etc) for their products - which is what Linux really needs in
order to survive, let alone prosper.

~~~
halbritt
> As the other comment explained, they are still a huge gorilla in spaces that
> are absolutely vital to Linux: server, desktop, and laptop.

No reasonable person at Microsoft considers Linux to be a threat on the
desktop/laptop. No reasonable person at Microsoft considers Windows Server to
be a threat to Linux on the server.

~~~
NeverFade
Microsoft holds a large and fast-growing share of the enterprise server market
with products like Office365, Exchange, and Sharepoint.

~~~
AshleyGrant
O365 is SaaS. Customers that are hosting Exchange on-prem are being encouraged
to move to O365 for email. Same for SharePoint. If I had to guess, O365 is
helping to reduce, not grow, the market share of Windows server.

~~~
NeverFade
What's important is that server-side services that Microsoft offers are
replacing Linux servers. Whether it's SaaS like Office365 or more traditional
server software like Exchange and Sharepoint is not crucial.

~~~
5partan
Except that Linux usage on Azure has surpassed that of Windows a long time
ago...

~~~
NeverFade
And I was talking specifically about Microsoft products like Office365,
Exchange, and Sharepoint.

~~~
halbritt
Microsoft's interest in on-premises business with these products is waning,
just as the market share for them is also waning. They most assuredly aren't
trying to win the war against Linux on the server. That war has been won (by
Linux) and MS is off chasing other revenue streams that are growing.

------
mmm_grayons
> This also enables third party APIs, such as the popular NVIDIA Cuda compute
> API, to be hardware accelerated within a WSL environment.

Dollars to donuts this is why Microsoft is implementing this. GPU acceleration
is becoming a critical feature for many users (but especially developers) and
this will continue. If WSL is to be a serious competitor, this is necessary
and I'm glad to see it showing up. This is true of cloud compute, too, and
Microsoft is betting big on cloud as its future growth area.

> Only the rendering/compute aspect of the GPU are projected to the virtual
> machine, no display functionality is exposed.

The Linux gaming folks will be pretty sad about this one. Anyway, this isn't
really a Linux port of DirectX. This is GPU compute via DirectX APIs.

So now, I'm just waiting on monitor mode/AF_PACKET for WSL...

~~~
Mic92
Do ML people actually care about DirectX? I thought everyone is using CUDA?
Anyway in my university building I have not seen anyone that does machine
learning on Windows.

~~~
anaisbetts
They typically don't - the team published both a special build of Tensorflow
that uses DirectX, as well as working with nVidia to get CUDA running against
their DX Linux kernel implementation

~~~
lostmsu
> special build of Tensorflow that uses DirectX

Huh? Are you sure about that? Regular TensorFlow on Windows uses CUDA, not
DirectX-flavored compute.

~~~
raphlinus
I was also surprised, but found this RFC for TensorFlow on top of DirectML:
[https://github.com/tensorflow/community/pull/243](https://github.com/tensorflow/community/pull/243)

~~~
lostmsu
Oh well, I think that will take several years to land.

------
gmanley
I found this reply to be especially interesting:
[https://lkml.org/lkml/2020/5/19/1309](https://lkml.org/lkml/2020/5/19/1309)

> I also have another concern from a legal standpoint I'd rather not review
> the ioctl part of this. I'd probably request other DRI developers abstain as
> well.

> This is a Windows kernel API being smashed into a Linux driver. I don't want
> to be tainted by knowledge of an API that I've no idea of the legal status
> of derived works. (it this all covered patent wise under OIN?)

> I don't want to ever be accused of designing a Linux kernel API with
> illgotten D3DKMT knowledge, I feel tainting myself with knowledge of a
> proprietary API might cause derived work issues.

This is the real scary part about software patents, and more specifically,
patenting APIs. I'm not saying Microsoft is doing this in this case, but it
could be a very real strategy by a bad actor. Attempt to taint open source
software with your patented software and then litigate.

In a dystopian future where patented software API lawsuits have become a
common occurrence, I could imagine "clean room people". Individuals who can be
guaranteed to not have been exposed to certain software designs.

~~~
jfkebwjsbx
On the other hand, if Microsoft themselves are publishing this code as open
source, on the open, on one of the most important projects out there, and are
_actively_ asking other experts _from other companies_ to review it, I would
imagine they are weakening their arguments on the potential litigation.

~~~
codys
Only for copyright claims. Patent claims are not diminished by publishing
items and asking for review. We can see this in the various video codec and
other standards that publish a bunch of info that is covered extensively by
patents.

------
christoph-heiss
FYI:

 _This is the first draft of the Microsoft Virtual GPU (vGPU) driver. The
driver exposes a paravirtualized GPU to user mode applications running in a
virtual machine on a Windows host. This enables hardware acceleration in
environment such as WSL (Windows Subsystem for Linux) where the Linux virtual
machine is able to share the GPU with the Windows host._

So this isn't actual "DirectX on Linux", just a driver for a virtual GPU
exposed to WSL-guests to enable guests to directly use DirectX, more or less.

Probably most useful for Azure-based projects.

~~~
Avamander
This sounds like an attempt to win back ML segment from Linux to Windows.
There are three letters back in my mind that sound like screaming, but too
early to tell unfortunately.

~~~
badRNG
How is it too early to tell?

It is an _extension_ of the capability of WSL, giving you that sweet
convenience of the DirectX API with your existing ML project. Of course, this
extension makes your project incompatible with desktop Linux once adopted.

~~~
dade_
Not necessarily. It is not possible to access the GPU in WSL at all right now,
so I need to dual boot which also means dealing with Linux desktop
compatibility issues with my laptop. As long as I can use the same ML
framework (without DirectX API), then this poses no compatibility issues at
all. It just means I can develop & run my ML code in WSL.

~~~
lostmsu
Just curious, what stops your ML code from running under Windows?

~~~
monocasa
It's way more of a pain, due to a lot of legacy constraints in windows. It's
easy to overflow pathnames and command lines that then get silently truncated.
Doing ML dev work is for sure easier on a Linux env than a pure Windows env.
it's not impossible on Windows, but def much nicer in Linux.

------
wmf
...and extend. I'm sure this architecture was easier for MS but it opens the
door to code that runs on WSL2 that doesn't run on regular Linux.

~~~
Rusky
In the linked thread the Microsoft developers explicitly deny that this is the
intent, if that's worth anything to you.

The goal, rather, is to take all the usual (for the Linux side) GPU stuff and
give it access to the Windows host's GPU, when running on WSL.

That is, they are already working on getting OpenGL/Vulkan/etc. to run on top
of this: [https://www.collabora.com/news-and-blog/news-and-
events/intr...](https://www.collabora.com/news-and-blog/news-and-
events/introducing-opencl-and-opengl-on-directx.html)

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."

~~~
xabotage
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.

~~~
Rusky
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.

~~~
bigbizisverywyz
Embrace phase sounds about right.

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.

------
mappu
There is a new, closed-source Microsoft DirectX 12 library for Linux apps that
speaks WDDM to /dev/dxg.

There is a pre-existing closed-source NVIDIA Vulkan+OpenGL+CUDA library for
Linux apps that speaks EGLStreams to /dev/nvidia0.

There is an announcement that the closed-source NVIDIA library might start
speaking WDDM to /dev/dxg.

There is a pre-existing open-source Mesa DirectX 12 (+Vulkan +OpenGL + ...)
library for Linux apps that speak GBM to /dev/dri (and some support for
speaking EGLStreams to /dev/nvidia0 too).

There is a pull request to implement /dev/dxg in the kernel as a Hyper-V pipe
for WSL2's use.

There are lots of interaction points for alternate implementations of various
pieces of the stack. For example, in the future it might ultimately be
possible for an alternate /dev/dxg implementation to wrap the normal DRM API,
or for NVIDIA's binary driver to reimplement /dev/dxg on real hardware.

------
nly
"There is no intent for anyone in the Linux world to start coding for the DX12
API."

[https://lkml.org/lkml/2020/5/19/1139](https://lkml.org/lkml/2020/5/19/1139)

"This is a driver that connects a binary blob interface in the Windows kernel
drivers to a binary blob that you run inside a Linux guest."

[https://lkml.org/lkml/2020/5/19/1288](https://lkml.org/lkml/2020/5/19/1288)

------
badRNG
The title is misleading.

This isn't DirectX on Linux. This is DirectX API access for WSL exclusively.
It will lock ML projects into Windows/WSL for the price of access to the
DirectX API and at the expense of development of other projects like Vulkan
for native Linux.

~~~
monocasa
Not anymore so than they're already locked into CUDA. It's more a WDDM bridge
than a strict DirectX bridge.

~~~
badRNG
I don't see how being "locked into CUDA" should make one less skeptical of a
change that will functionally lock projects into Windows. I can't help but
think this is going to siphon resources from Linux native graphics
development.

~~~
monocasa
I don't see how it'll be locking projects into windows. There's no user space
DirectX library here.

The whole point looks to take your CUDA code that would run just fine on Linux
without a hypervisor, and run it just as well in WSL2.

ie. this is at worst still the embrace stage, IMO.

~~~
jfkebwjsbx
They are providing libd3d12.so, that is a user space library that apps can
link to.

At the moment, that library only works under WSL, but I guess the DXVK folks
can connect their implementation too.

~~~
monocasa
> 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.

[https://lkml.org/lkml/2020/5/19/1139](https://lkml.org/lkml/2020/5/19/1139)

And backing that up, they ported Mesa to get OpenGL and OpenCL in the Linux
guest and are working on a Vulkan port as well.

------
wtallis
I really wish Microsoft would just tell NVidia (and AMD) to support SR-IOV on
all their GPUs. Then we wouldn't need any major software changes to enable
CUDA acceleration within VMs, just a configuration change to pass through a
virtual function of the GPU to make it available to existing drivers.

~~~
monocasa
SR-IOV doesn't make sense on most GPUs, because they have their own MMUs
already with different semantics. SR-IOV is terrible for dealing with a large
bank of RAM on the target device, because the MMU is in the wrong part of the
architecture. It's all the way on the root complex, so all GPU VRAM reads and
writes would need to take the slow path through PCI-E and back. This is
basically a nonstarter for GPUs that have their own VRAM. They also don't
cover the GPU specific caching information that's normally stored in the GPU
page tables either.

Intel is able to get away with it for integrated GPUs because they can
codesign their system level IO-MMU with the GPU MMU and it doesn't have it's
own VRAM bank. I'd bet dollars to donuts that Intel's new Xe discrete GPU
doesn't support SR-IOV even though the integrated versions of the same core
will.

~~~
wtallis
How does AMD deal with this on their server discrete GPUs that support SR-IOV?

~~~
monocasa
It's not really SR-IOV in the way you'd generally consider it as it only
virtualizes the GPU's access to main memory not VRAM. That still requires that
you setup GPU page tables and manage them on the host side with a bridge
driver in the guest like Microsoft's work here is doing.

The same with Nvidia's A100.

------
jagger27
The linked blog post in TFA has a clearer title: "DirectX is coming to the
Windows Subsystem for Linux"

~~~
dang
We've switched to that post now from
[https://lkml.org/lkml/2020/5/19/742](https://lkml.org/lkml/2020/5/19/742).
Thanks!

------
stefan_
This is the kind of driver that you get when you ignore all existing Linux
code, then try to throw 15k LOC over the wall when its all done. Microsoft
should really know better: _this is not how you get your code upstreamed_.

~~~
rrss
I doubt Microsoft really cares. Microsoft will ship it in the linux kernel in
WSL2, and people will use it, and if the upstream community doesn't want it I
don't see why Microsoft would have a problem with that.

~~~
kelnos
They'd certainly prefer that upstream Linux maintains it for them. The more
code they have to maintain out of tree, the harder it is for them to upgrade
their WSL kernel.

------
4cao
Is it really "DirectX on Linux," or more like "DirectX on Windows Subsystem
for Linux?" Is it going to be useful for Linux in general, outside WSL?

~~~
badRNG
No, this is only an extension of WSL, it will not impact desktop Linux.

~~~
4cao
Thank you. In the meantime I also noticed the following comment from Dave
Airlie on LKML [1]:

> This is a driver that connects a binary blob interface in the Windows kernel
> drivers to a binary blob that you run inside a Linux guest. It's a binary
> transport between two binary pieces. [...] I can see why it might be nice to
> have this upstream, but I don't forsee any other Linux distributor ever
> enabling it or having to ship it, it's purely a WSL2 pipe.

1\.
[https://lkml.org/lkml/2020/5/19/1288](https://lkml.org/lkml/2020/5/19/1288)

~~~
monocasa
He's pretty against it on a number of fronts.

That being said I don't see why distros like Ubuntu that allow non free code
wouldn't ship with it out of the box. They already support Nvidia binary
drivers anyway, so why wouldn't they support a transport bridge that'd let
people use them on WSL too?

Also, he notices that it's intended to be more than a bridge in the future, as
they're already working on integrating it with the presentation layer on
Linux.

~~~
isatty
Because this benefits only WSL. I don’t think that the Linux maintainers
should spend time and effort maintaining a shim that only benefits users on
another operating system. It does not even lead to cross platform code if a
dev uses this on WSL.

Microsoft can ship it however they please though within bounds of licenses.

~~~
monocasa
They've already upstreamed lots of other hyper-v paravirtualization
infrastructure.

And why do you assume it only helps WSL? Doesn't this help all hyper-v setups
get access to GPUs, including azure?

~~~
vopi
Probably because its a shim to use a proprietary (only distributed by MS)
binary blob version of DirectX compiled for Linux. Outside of ML utilizing
DirectX in WSL on Windows, the only group that this helps is MS.

FTR, I'm not arguing whether or not this should be upstreamed. I just see
where the other poster could be coming from. I could be wrong on my take and
if so, someone please correct me.

~~~
monocasa
They also ported OpenCL and OpenGL to it via Mesa. Vulkan is in the works, and
you can use CUDA if the host GPU supports it.

Would y'all be so worked up about VMWare upstreaming their virtual GPU bridge?

~~~
chrsw
Depends. If VMWare had the history Microsoft had one would be naive not to get
"so worked up".

~~~
monocasa
VMWare is probably the company with the worse reputation than Microsoft since
they spent more than a decade shipping large part of Linux linked against
their proprietary hypervisor in a blatant GPL violation.

And yet here's where their paravirtualized GPU driver lives
[https://github.com/torvalds/linux/tree/master/drivers/gpu/dr...](https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/vmwgfx)

~~~
chrsw
Microsoft has a history of anti-competitive practices that crippled the
industry. In either case, serious objections are justified and severe handling
of one case doesn't invalidate the handling of the other.

~~~
monocasa
There's been Microsoft levels of anticompetitive practices from every
proprietary hypervisor vendor. The others are seen as "oh, look! They're
working with Linux! yay!" for a code dump across the wall (like vmware, and
arguably z/VM), whereas here Microsoft appears to be doing everything right
and working with upstream to modify a minimal MVP and are being lambasted for
it.

It feels like they're doing everything right and everything we've asked for,
for decades, and being shunned for it. What's the mechanism here for Linux
winning and Microsoft being allowed into the community and what should they be
doing different?

~~~
chrsw
They're not doing everything right. They're doing something objectionable,
like other people are also doing. Except they're being called out for it
because of their reputation of having one of the most hostile anti-competitive
practices the industry has ever seen. It's the price you pay for having such
bad credit, even if your intentions initially seem benevolent.

~~~
monocasa
> They're not doing everything right. They're doing something objectionable

What exactly? The only performant way to expose GPUs to guests while still
allowing them to be used by the host (or multiple guests) for GPUs that don't
have hardware support for partitioning themselves (ie. pretty much all
discrete GPUs) is to replicate the ioctl layer from the host up into the
guest. Any other solution is a non starter if you care about getting the perf
you'd expect from the paravirtualized GPU.

------
Koshkin
Twenty years ago Microsoft wanted to make Java “the best language for Windows
programming.” Today, apparently, they want to make Windows “the best
environment for running Linux.” (This time around they might even succeed.)

------
Grimm1
Yeah, I don't buy the arguments here that Microsoft can extinguish Linux. Or
would want to. Who's going to run Window's servers just to enable wsl? This is
clearly targeted at developers coming back to windows on the PC, the aim is
even stated as such to "enable IDEs" on wsl. I've ran arch, ubuntu and debian
on my various systems, not because I want to but because they have the
superior development environment in the terminal, outside of that Linux still
feels janky and doesn't have any market share because of that.

Microsoft is making something I've wanted for a while, I can get Linux off my
desktop and laptop do my development and my game playing on Windows and ssh
into my servers for any heavy lifting. This sounds like it will be a great win
for devs.

------
satvikpendem
This is probably a better article directly from Microsoft:
[https://devblogs.microsoft.com/directx/directx-heart-
linux/](https://devblogs.microsoft.com/directx/directx-heart-linux/)

OpenCL, DirectX and CUDA all seem to be available for GPU acceleration on WSL.

One other exciting thing is GPU accelerated GUI Linux apps on Windows. You may
not need an X server anymore. I'm looking forward to using i3 on Windows.

~~~
dang
Changed to that from
[https://lkml.org/lkml/2020/5/19/742](https://lkml.org/lkml/2020/5/19/742).
Thanks!

------
owaislone
As far I understood the article, this does bring the DirectX API to Linux but
in it's current shape it's only usable in WSL as the API implementation uses
the virtual devices under the hood provided by WSL.

Legal/licensing issue aside, how hard would it be to re-purpose this to make
it available under something like Wine or even natively on Linux with real
graphics devices? How much of this is till locked in on the Windows host side?

------
techntoke
Did anyone see the comments?

[https://lkml.org/lkml/2020/5/19/960](https://lkml.org/lkml/2020/5/19/960)
[https://lkml.org/lkml/2020/5/19/1288](https://lkml.org/lkml/2020/5/19/1288)

~~~
jschwartzi
Per the second one it sounds "relatively straightforward" but also "not really
worth maintaining upstream."

------
woadwarrior01
Hopefully, this will enable Windows users will be able to run docker
containers that use GPUs the way Linux users have been able to for years now
with nvidia’s container toolkit[1].

[1]: [https://github.com/NVIDIA/nvidia-
docker](https://github.com/NVIDIA/nvidia-docker)

~~~
mkl
From the linked blog post [1], it sounds like it: "In addition to CUDA
support, we are also bringing support for NVIDIA-docker tools within WSL. The
same containerized GPU workload that executes in the cloud can run as-is
inside of WSL."

[1] [https://devblogs.microsoft.com/directx/directx-heart-
linux/](https://devblogs.microsoft.com/directx/directx-heart-linux/)

------
CobrastanJorji
Am I mistaken, or is this not so much "DirectX on Linux," but only "DirectX on
Linux VMs on Windows?"

------
hiram112
I was a beta user of WSL1. It was interesting, but the very slow file system
performance from Windows to Linux and vice versa was a deal breaker for
development use.

I haven't even bothered to use WSL2 because I hardly use Windows anymore, and
I was forced to use VMWare with Linux on Windows for a few years of
development work. It was always a pain, too, and once I switched to MacBook, I
never looked back.

Since then, I assumed WSL2 wasn't going to be used much by 'real developers'
as it also had many of the same problems that plague VMWare and VirtualBox,
which haven't been adopted by enough developers to pose a threat Linux native
and Mac users.

But I really feel MS is throwing a lot of resources into this. It's not just a
quick fix for those users who need a command line but wouldn't ever consider
Linux or Mac anyway, as I initially thought.

And if this gets 'good enough' then imagine even more trouble for Linux and
especially Mac's grip on engineers and scientists.

Ubuntu, Redhat, and the rest have utterly failed to work with Dell or Lenovo
or HP to concentrate on just one or two _very well_ supported laptops -
everything including suspend, battery life, ACPI, fonts, etc. It's a chicken
and egg problem - workstations aren't profitable because most users won't put
up with the hardware and driver problems. And without paying users, the
distros ignore potential pro users to concentrate on enterprise.

As for Mac, while I'm happy they've finally fixed the keyboard and allowed
32GB+ ram, that configuration looks absurdly expensive at $3500 compared to a
similarly configured $1700 Dell Precision or Thinkpad. And MacOs has gotten
worse over the years, not better. There is nothing really compelling me to
stay except for it's Unix compatibility.

WSL2 may eventually be the final nail in the coffin for a viable Linux
Desktop, and Apple should be worried too, though they appear to have forgotten
about pro users years ago anyway.

~~~
m01
Dell have developer edition laptops that come with Ubuntu preinstalled and I
saw a link on HN not long ago about Fedora coming to Lenovo laptops (I think
it was [https://fedoramagazine.org/coming-soon-fedora-on-lenovo-
lapt...](https://fedoramagazine.org/coming-soon-fedora-on-lenovo-laptops/)).
I've not used them myself but I'd hope the situation isn't as dire as you
describe, at least for those selected models.

~~~
hiram112
Dell has put out Linux laptops (XPS and Precision) with both Redhat and now
Ubuntu for years.

The problem is that they don't keep up with updates, and so you buy an XPS in
2017, and then decide to update to the next non-LTS version of Ubuntu, and
eventually more and more of your hardware no longer 'just works'.

And since moving to Mac, I just can't get used to my Dell Precision anymore
because certain things like fonts and touchpad are just so inferior to a
Macbook from the same year.

And this is probably half the problem: If they concentrate on only one or two
models, then they either have to pick their top-end line (Precision or
Thinkpad) to compete for pro users who'd go with $3000 Macbook Pros, or
instead target the lower end budget users on Inspirons or Lenovo Yogas who'd
otherwise just use Windows.

So instead, it just seems like Linux is mediocrely supported on most of their
laptop lines, but not a single one is 100% supported long term like it would
be with a Mac or any Windows box.

------
swiley
Maybe I'm missing something but how is this an improvement over virgl?
Something that's platform agnostic and works with applications right now being
replaced with something that's very tied to windows.

Not a fan but also not a graphics programmer.

------
arminiusreturns
Why can't we all just agree and use Vulkan!?

~~~
kbumsik
Yes Vulkan is supported as well. They are implementing Mesa driver on top of
it: [https://devblogs.microsoft.com/directx/directx-heart-
linux/](https://devblogs.microsoft.com/directx/directx-heart-linux/)

------
kristopolous
I also found the phrasing of this to be ambiguous.

Windows (subsystem for Linux)

has a Windows host running Linux

Or

(Windows subsystem) for Linux

has Windows running on a Linux host

They've been using this phrasing since the OS/2 and POSIX subsystem days and
it was also confusing then

Quarterdeck did it right with Desqview/X by just renaming their WIN16
subsystem as winx. Then you would see "desqview winx" and know that it's
windows running on desqview and not the other way around.

IBM also got it right: OS/2 Windows VDM. I know it's running on OS/2.

But Microsoft has been running with this phrasing since literally Windows NT
and it's always been confusing.

~~~
kgwxd
Wasn't it originally something like "Linux Subsystem for Windows" and there
was some legal problem with the word "Linux" being first?

~~~
kristopolous
Apparently people _have_ used the words swapped to mean the same thing.

It's bad.

Microsoft releasing something to run windows software on Linux, maybe for some
exorbitant fee and only on say, the commercial versions of RHEL to undercut
Wine progress, not only doesn't seem out of the question but also a reasonable
defensive strategy and something I totally missed the announcement of. It's
not like I'm a tech reporter, I go into my work for a couple weeks missing
everything pretty often

------
dzonga
EEE, slowly the Linux desktop | os environment will be a thing of the past.
something you won't run directly but interact via the windows api. and your
only other choice will be mac os on arm. the biggest mistake the linux
ecosystem did, was being so fragmented. if they had rallied around one desktop
env, then lots of people would've migrated. I personally use a t490 on ubuntu
and a 2013 macbook. but even I I'm attempted to try out WSL even though, I
haven't used windows in over a decade

~~~
rvz
> the biggest mistake the linux ecosystem did, was being so fragmented.

I'm not sure how many times I have pointed this out here, but given the lack
of a standardized desktop environment, that is the reason why most software
companies are reluctant to support Linux users. But in contrast with 'Android'
in the mobile industry has succeeded in doing this with Linux as its kernel.

For a typical or even a complex desktop app, I can support 100% of all Windows
users, 100% of the time. macOS is more or less the same here. Linux distros
however has this fragmentation running so deep that to target the majority of
users there, you must supporting 5+ distros they could be running. That's 5+
CIs to maintain and 5+ troubleshooting guides to update here.

As even Linus Torvalds would say: > 'I still wish we were better at having a
standardize desktop that goes across all the distributions… It’s not a kernel
issue. It’s more of a personal annoyance how the fragmentation of the
different vendors have, I think, held the desktop back a bit. ' This is a
distro ecosystem problem, not a 'kernel' issue.

~~~
_ph_
While he is right that it is not a "kernel" issue in the strict sense, I have
to say it would have been beneficial, if Linus had used his influence to push
more for a better desktop environment.

------
m0zg
If this works, Microsoft will overnight become viable for scientific dev work.
Kudos to MS for taking on what is perceived by many as a "fringe" feature, but
would allow me to use Windows on a laptop, while having a sane (and compute-
rich) Linux dev environment. In all these years, NVIDIA still didn't make it
easy to use laptop GPUs from Linux directly. At least not if you want good
battery life.

------
dvfjsdhgfv
I wish they did away with these heart symbols, professing their love for open
source. Yes, we got that, Linux brings MS tons of money via Azure, but all
this monkey show about love is plain disgusting, I can't imagine someone
falling for that.

------
nihil75
So they WILL port DirectX to Linux, but only when it's running as a VM atop
Windows.

Typical..

------
rietta
I remember starting to use and learn Visual J++ just to find out that if one
wasn't really careful the code you wrote didn't run on other systems. If I was
going to keep making a Windows only program, I preferred to stick with Visual
Basic at the time. The real Java SDK was harder to learn for teenager me so I
dropped it for a couple years until I started at Georgia Tech, which used Java
extensively.

------
modmans2nd
Step 1) Put a Linux Kernel on Windows as a separate subsystem

Step 2) Port all APIs to this Kernel

Step 3) Switch over to Linux as the main kernel and make the windows kernel a
a Linux sub system to support legacy win32 apps.

Step 4) Make all win32 support into a containerized system

Microsoft moves to a Linux based system it offers for free and is only used
for integration and support of it’s services.

------
mikorym
Maybe this question has an obvious answer, but will I still need to start my X
Window System for graphics to display from my WSL terminal?

My guess is that the answer is yes, but the type of applications that can be
run is now extended?

Conversely, I would expect this doesn't change anything with regards to
SSHuttle, which would still not work on WSL.

------
starpilot
Great, now we might get RAPIDS on Windows!
[https://stackoverflow.com/questions/58623169/is-there-a-
way-...](https://stackoverflow.com/questions/58623169/is-there-a-way-to-run-
rapids-on-windows-pc)

~~~
rrss
Looks like yes:
[https://news.ycombinator.com/item?id=23240076](https://news.ycombinator.com/item?id=23240076)

------
owaislone
It seems Microsoft is getting closer to making Windows a fully Linux
compatible OS. I wouldn't be surprised to see them get rid of virtualized
distros running in WSL at some point and Windows natively becoming POSIX
complaint.

------
dang
We changed the url from
[https://lkml.org/lkml/2020/5/19/742](https://lkml.org/lkml/2020/5/19/742),
which points to this.

------
jaimex2
[https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...](https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish)

------
acd
Windows will become an emulation layer in Linux when Microsoft is tired of
maintaining Windows kernel/sees profit in running Windows apps native on
Linux. SQL server is already ported.

------
prirun
Here's the "new" Microsoft:

[https://news.ycombinator.com/item?id=23255591](https://news.ycombinator.com/item?id=23255591)

------
29athrowaway
DirectX on WSL and DirectX on Linux are not the same thing.

------
visarga
The big news is Docker support for GPUs on Windows. You could train on GPU on
Windows but you couldn't serve the model without Docker, as a business.

------
ComodoHacker
>This is the real and full D3D12 API, no imitations, pretender or
reimplementation

But isn't Direct3D a COM API?

------
prometheus76
Nobody: Microsoft: Now you can use DirectX in the Windows Subsystem for Linux!

------
mpfundstein
even though I am quite successfully using pytorch under win (with conda), ...
THIS IS EPIC. because now o can finally go full wsl

and a pretty good excuse to switch to fast lane.

i love wsl(2) and this is the icing on the cake.

------
SXX
I just hope David Airlie not going to merge it.

------
wmichelin
This title is misleading, I saw it and got really excited that someday we may
be able to game on Linux.

~~~
account42
> got really excited that someday we may be able to game on Linux.

Someday? You can already game on Linux.

------
adammunich
How about sockets...

------
floatingatoll
Blog post from Microsoft linked at the top of the LKML email:
[https://devblogs.microsoft.com/directx/directx-heart-
linux/](https://devblogs.microsoft.com/directx/directx-heart-linux/)

~~~
dang
Changed to that from
[https://lkml.org/lkml/2020/5/19/742](https://lkml.org/lkml/2020/5/19/742).
Thanks!

------
kalium-xyz
The Year of the linux desktop has come

~~~
squarefoot
Actually, the year of Linux on the desktop will never come also thanks to
this. Developers will find more comfortable writing Linux software on Windows
(some already do); desktop users will have both worlds at hand without being
forced to dual boot; Linux gamers won't have any reasons to keep using native
Linux. Etc. I foresee in a not so distant future Microsoft integrating Windows
UI elements and events hooks right into WSL, so that Linux developers too will
be able to take advantage of the well standardized Windows UI; no more GTK or
Qt frankenapps on Windows: just pure Linux code written on well known Windows
RADs that access all windows internals while opening standard Windows dialogs
and widgets. That would likely take away a huge part of Linux users.

~~~
bb88
> the year of Linux on the desktop will never come also thanks to this.

I think you're giving MS too much credit here. Apple has one UI, and Windows
has one UI (2 if you count windows in tablet mode). Linux has, what? 30?

Quoth the Torvalds:

"I still wish we were better at having a standardize desktop that goes across
all the distributions… It’s not a kernel issue. It’s more of a personal
annoyance how the fragmentation of the different vendors have, I think, held
the desktop back a bit."

Only recently did Ubuntu stop trying to push Unity and accepted Gnome, thereby
reducing fragmentation by 1.

[https://itsfoss.com/desktop-linux-torvalds/](https://itsfoss.com/desktop-
linux-torvalds/)

~~~
_ph_
I think that both Ubuntu and Red Hat family being based on Gnome is a good
thing for Linux on the desktop, as there is a clear target for Linux GUI
applications. I like the fact, that you still have the freedom to run any kind
of desktop environment of Linux, but a stable default can only help Linux.

~~~
kalium-xyz
Its better if the competing ecosystem offers multiple stable defaults IMHO.
Have you looked at KDE5? its amazing.

------
pojntfx
WTF. Just use Vulkan like a normal person.

------
unnouinceput
Ohhh, such a smart move. If there was any momentum of gaining developers on
Linux for gaming this will crush it.

Microsoft is eating Linux with a "loving" embrace.

~~~
wvenable
I'm curious why you think this would make any difference to Linux gaming? If
you want games to only run on Windows, they can just develop them for Windows.
There's no need to put Linux in the middle.

~~~
unnouinceput
Vulkan means cross-platform independent of OS. This is a move by Microsoft to
lure any undecided/new game developers back to their walled garden. If you
don't see this, let's talk in 10 years again - assuming Microsoft doesn't crap
on it along the way.

~~~
hgoel
Being able to run dx12 in a virtualized environment that's still under Windows
(and thus not actually changing anything vs just developing only for windows)
is going to lure undecided game developers how?

~~~
unnouinceput
Say you're a game developer under Linux, OK? Then this comes along and you
give it a try. This combined with all the great game engines that are pure
Windows these days (see Unreal Engine 5 demo that was launched these days) and
you now can target Linux using that. What do you do - continue with Vulkan or
offer your game using this?

~~~
wvenable
You can't target Linux using that. I think you misunderstand what this is. It
doesn't help nor hurt Vulkan or Linux development -- this only exists to
"optimize" the Linux VM in Windows.

~~~
unnouinceput
ehh, nevermind

------
zakk
I remember when DirectX was a huge obstacle to porting games to Linux. This
feels like a great, great victory for Linux to me!

~~~
badRNG
> This feels like a great, great victory for Linux to me!

Why?

This is not DirectX on the Linux desktop, it is DirectX for WSL. This means
that code written for this will NOT function on desktop Linux.

Additionally, support for DirectX for WSL is support not spent on Vulkan and
OpenGL.

~~~
wvenable
> This means that code written for this will NOT function on desktop Linux.

Like CUDA, I assume that most applications would not be coded to this API
directly. Microsoft already mentioned OpenCL and OpenGL.

This is to hardware accelerate Linux applications and not to create WSL-
specific Linux apps. I can't imagine there's a big market for Linux GUI apps
that would only run on Windows.

------
ngcc_hk
Embrace - wsl 1/2

Extend - features you really open source to have and they fix it (running on
laptop, apple do not do Nvidia) but try their best only run in their linux
versus

Extinguished - may the last one turn the light off, and thanks you for all the
fishes

------
shmerl
Not impressed, especially since it's still a blob.

MS should stop fooling around and should start supporting Vulkan instead of
pushing their DX lock-in and making hypocritical statements how they aren't on
the wrong side of history anymore because they "support open source". The
above feels like typical MS EEE.

