Hacker News Reader

Comment by raesene9 | Hacker News Reader

From a Microsoft perspective, this feels like damned if you do and damned if you don't.

If they didn't embrance linux style tooling, they get told that they're anti-open source and that Macs will always be a better development environment when you're targeting Linux servers.

If they do embrance Linux style tooling, they get told it's EEE all over again.

I've been following the development of WSL, Terminal and VS Code. It doesn't strike me that this is some corporate EEE style policy, more it's a directive to make Windows as developer friendly as possible.

There's quite possibly an ulterior motive here, but it's more "make deploying onto Azure the happy path" than anything else.

WSL+VS Code+Terminal+Docker for Windows+Github == more business running their workloads on Azure == more money for Microsoft.

View on HN

This is one of the more sane comments on this thread. There is a lot of paranoia about MS wanting to somehow "corrupt" Linux because some web developers are having IE6 flashbacks. Sure if it was still 1999 I'd be scared of that, but now Microsoft's biggest growth business is Azure, so this move is largely about supporting Azure usage, not about creating a weird Linux Windows hybrid to lock developers out of proper Linux distros. The rest all comes from MS being developer friendly, which has always been a part of their culture on the tools side

Not to mention the uptake of proper linux desk top distro's is a rounding error in the big scheme of things. They need to worry more about Apple and Google. And Apple has done more to EEE Linux than Microsoft is going to do.

That's a poor portrayal of EEE. Of course this move is largely about supporting Azure usage, it just supports Azure usage by locking developers out of proper Linux distros.

When you use the proprietary DirectX extension in WSL, you're not developing for Linux anymore, you're developing for WSL, a proprietary package. And now that you're reliant on DirectX/WSL/Windows, what cloud provider are you going to pick? You see, the Azure Advantage (TM) is that only Microsoft knows how to run DirectX on Linux effectively, because only Microsoft can inspect and modify the code. The Azure Advantage (TM) is that only Microsoft has the proprietary rights for Windows, so Microsoft can charge their competitors anything they want while offering it on Azure at a (relatively) affordable price.

If you buy the theory that Microsoft now loves opensource and Linux, I want to ask you why they don't provide full support for things like 'Wine'. May be even develop something like that themselves, that will allow people run Windows programs flawlessly on Linux. (I mean, if they only mostly care about Azure)

Also, they have acquired Github, and they are slowly pushing towards the entire development/discussion to be moved to Github (In the guise of making it easier for people to contribute to Linux), from the current method of using the Emails for discussions and submitting patches.

When you consider everything, and don't just go by localized observations, you might get a better picture of the old EEE in the new bottle.

Supporting Wine would cost Microsoft money and not make them much/any money, why would they do that?

On the other hand, supporting VS Code, Terminal, WSL2 makes them money by helping boost their cloud services, so it makes sense to spend money in those areas.

That doesn't feel nefarious to me, just business.

If they were just embracing Linux, it wouldn't be so nefarious. You're missing that they're already starting the "Extend" phase with proprietary DirectX extensions for WSL, encouraging developers who normally favor the Linux environment to instead target the WSL, which is Windows only.

This isn't just making deploying to Azure the happy path. This is ensuring that a generation of software in the Linux environment only works on Windows' WSL.

If you're going to do Windows specific GUI development, why would you go to the hassle of using DirectX/WSL at all? Why not just do native Windows development?

If you're not doing native development on Windows 'cause you want cross-platform support, you won't use DirectX specific pieces...

The DirectX extensions to WSL aren't intended for GUI development, they're intended for ML workloads.

So if I'm understanding correctly, your theory is that MS will be expecting Windows servers with DirectX and WSL to be the targets for ML production workloads? Instead of Linux servers in Azure...

Wouldn't developers just write native Windows ML apps then?

It's about developing ML applications. Right now ML programming using CUDA is a very Linux centric ecosystem.

The DirectX integration is going to bring over that support to Windows.

https://developer.nvidia.com/blog/announcing-cuda-on-windows...

They also cannot be used from applications directly since they're just implementation detail inside mesa.

This isn't true, you''re supposed to use proprietary DirectX libs that interface with a virtual DirectX device, as shown in this architecture diagram provided by Microsoft:

https://devblogs.microsoft.com/directx/wp-content/uploads/si...

From https://devblogs.microsoft.com/directx/directx-heart-linux/

I'm not even sure where mesa comes in. Can you elaborate where you got your info?

You're supposed to use APIs provided by mesa (OpenGL, OpenCL) or TensorFlow and similar ML Frameworks which then talk to D3D12 or DirectML as seen on linked diagrams.

It makes zero sense to consume D3D12 and DirectML under WSL directly from user applications since that prevents your app from being deployed on the real linux. There also won't be any SDK or headers released by Microsoft so you'll have to manually load functions from .so.

Not everyone will be using the popular ML frameworks that will likely try to smooth out cross platform differences. OpenGL & OpenCL is still available, that doesn't negate the fact that Microsoft's proprietary DirectX extension is exposed directly.

> It makes zero sense to consume D3D12 and DirectML under WSL directly from user applications since that prevents your app from being deployed on the real linux.

That's the whole point, people will do it because it's convenient, and Microsoft is counting on the fact that it prevents your app from being deployed on "real Linux". DirectX is already quite a popular API on a popular OS and actually pretty good on technical merit alone. It may very well be a sensible trade-off for a project or developer to move to DirectX, but it will be a loss for the Linux ecosystem.

> There also won't be any SDK or headers released by Microsoft so you'll have to manually load functions from .so.

The .so files are compiled from the same source code, the article doesn't go into a lot of detail but I suspect existing DirectX tooling will be updated for Linux targets. Either way, normal developers will have access to the same tooling and documentation as the developers for TensorFlow and similar ML frameworks you already claimed will talk to D3D12 or DirectML (unless you're claiming that Microsoft will give special tools to the open source TensorFlow project or something).

I think there a way too many people who are not political and do not give a flying fuck about all those conspiracy theories. They just care about doing the actual work. What we have on sites like this one is a vocal minority that may not represent common situation at all.

Unfortunately it doesn't make it more friendly to developers. If they wanted to make it more friendly to developers, they would release a Microsoft Linux distribution. Maybe port some critical dev tools. There are far too many incompatible quirks with Windows to ever make it a reasonable development platform when targeting Linux.

WSL2 is a virtual machine. It is way more than a reasonable development platform for linux and it is very much friendly to developers, much more so than another distro would be.

As a linux user I'm immensely happy that I can use the same shell-scripts and applications on windows machines as I do on linux. And that I can just SSH into it (and use the same tools, SSHing into powershell doesn't help much if you don't know or use powershell for anything else). It makes coexisting so much more comfortable.

Reply on news.ycombinator.com