Live data from Hacker News

DirectX is coming to the Windows Subsystem for Linux

devblogs.microsoft.com

481–490 of 548 posts

Re: DirectX is coming to the Windows Subsystem for Linux

#481

Earlier quoted context omitted.

what do you mean you wanted to install applications to an external disk? if you have a separate OS on the external drive, you could chroot in and install it. If you just want that one application to be on the other disk, you could mount it to wherever on the filesystem the program would be installed. However you probably don't wanna do that on an application by application basis. you could mount /usr/bin/ on the exte…

> what do you mean you wanted to install applications to an external disk? Kinda illustrates my point about this being a foreign concept to Linux Desktop people. It's pretty simple: I want to put an application on an external disk and run it from there. > if you have a separate OS on the external drive, you could chroot in and install it. No thanks. I'd just like to have the application stored on an external disk, an…

NixOS gets you there I think. They deviate from the standard hierarchy to keep each application in its own directory that could be installed on it's own drive if need be, then with symlinks back to the main tree for legacy purposes. Like /bin/sh would be a symlink to /nix/store/s/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-bash-4.3.43/bash but only because there's enough legacy out there that expects /bin/sh to be runnable verbatim.

Re: DirectX is coming to the Windows Subsystem for Linux

#482
post #236

Earlier quoted context omitted.

But Windows is a painful OS to use for anything other than gaming. Ideally, I'd like to see the exact opposite of this: run Linux with a Windows subsystem just for gaming.

You can do that today with Qemu and PCI-passthrough. You just boot a VM, and pass it a physical grapics card. Check out https://old.reddit.com/r/VFIO/ I guess this will be the standard until we can have nicer graphics drivers for Linux.

That requires two GPUs though, one for the guest and one for the host.

Re: DirectX is coming to the Windows Subsystem for Linux

#483

Earlier quoted context omitted.

It is, of course, decidedly not a Linux distro though. If it was, it wouldn't be an issue. I think there are positives, but it looks a lot like "Extend" to me. I can't even say I wouldn't use it - it might be nice! But I will not use any WSL-only capability, that's for sure.

Hi. Microsoft PM working on WSL, Terminal and Windows. WSL2 literally runs user-mode distros (and their binaries) in containers atop a shared Linux kernel image ( https://github.com/microsoft/WSL2-Linux-Kernel ) inside a lightweight VM that can boot an image from cold in So when you run a binary/distro on WSL2, you are LITERALLY running on Linux in a VM alongside all your favorite Windows apps and tools. If some of t…

I think the concern with this DirectX implementation is that it only works for WSL users, not standard Linux users. So, it's a software API that will only work in your ecosystem, not the overall Linux ecosystem.

If DirectX on Linux could also work on bare metal, the conversation here would likely be different.

Re: DirectX is coming to the Windows Subsystem for Linux

#484

Earlier quoted context omitted.

Because WSL doesn't compete with people who would otherwise run a Linux box, it competes with people who would otherwise shove Ubuntu into a VirtualBox and run it on their Windows box in seamless mode. So the idea that it drives people away from Linux proper is nonsense (BTW., WSL is Linux proper), unless you also believe that installing a Linux in a VM on a proprietary system is also driving people away.

I agree with you completely. I think that the comment I was replying to thinks otherwise.

No, I was just a little more abiguous due to a left out word or two than I intended.

>>> I think if that really matters you should be against

Should be interpreted as (and I meant to write as)

>>> I think if that really matters to you you should be against

The rest of the comment should have made that obvious though, especially the last two paragraphs.

Re: DirectX is coming to the Windows Subsystem for Linux

#485
post #67

Earlier quoted context omitted.

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.

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

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.

Re: DirectX is coming to the Windows Subsystem for Linux

#486
post #364

Earlier quoted context omitted.

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 an…

> 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 di…

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.

Re: DirectX is coming to the Windows Subsystem for Linux

#487

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.

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.

Re: DirectX is coming to the Windows Subsystem for Linux

#488
post #236

Earlier quoted context omitted.

But Windows is a painful OS to use for anything other than gaming. Ideally, I'd like to see the exact opposite of this: run Linux with a Windows subsystem just for gaming.

Wine / Steam's Proton does a decent job, and some older games even work better with Wine than with Windows 10. If you have a spare GPU, a VM with PCI passthrough does an even better job, except for some anti-cheat software that artificially discriminates against this setup. In theory it ought to be possible to switch a single GPU to/from a VM without a reboot. In practice I have no idea how huge a refactoring to the…

> In theory it ought to be possible to switch a single GPU to/from a VM without a reboot. In practice I have no idea how huge a refactoring to the Linux graphics stack that'd require.

I've got this working today. I do it through swapping the nvidia driver for the vfio-pci driver (and back again if required). The slight annoyance is that you may need to restart X11 (for me this is not an issue).

I wrote about this some years ago: https://me.m01.eu/blog/2016/05/pci-passthrough-vm-monitor-se...

Re: DirectX is coming to the Windows Subsystem for Linux

#489
post #329

Earlier quoted context omitted.

> systemd still gets in my way regularly while the sh-based init systems tend to Just Work For me systemd based systems allow me to have declarative, portable unit files where init scripts don't. They allow me to reliably monitor and restart services, they shut things down properly instead of just force killing as many init scripts end up doing. I instantly know how to manage most major distros now that systemd's com…

Arguing that the advantage of systemd is portability is rather bold! And even if portability was the point I'm not sure I see the big deal. Writing an RC script from scratch if the software you use doesn't provide it is generally trivial. The vast majority of the time you wouldn't have to do that anyway as it ships with your OS's packages anyway. Sure, systemd might be "tidier" with its standard APIs and whatnot but…

> Arguing that the advantage of systemd is portability is rather bold!

It's merely a statement of fact, systemd services accept the same set of commands across distros, which is rather unlike SysV.

> It's poor quality, non-consistent and non-deterministic if you write them that way.

That's a bullshit statement, because everything fits it. Of course everything is great if you make it great. And?

The point is that systemd's declarative nature makes it hard to screw up services and even badly written ones will get enough common functionality for free that they'd be usable.

> Systemd has been pushed down everybody's throat for a while now, saying retroactively that people use it because they find it valuable is a bit of a stretch.

Systemd got adopted because people generally found it valuable enough to adopt over what they had before.

> Maybe it's nicer for the people writing the unit files, doesn't mean that it's a good thing for people actually having to use them

Matter of opinion, but I happen to think that having a uniform set of commands working at work and at home is nicer for users too, over the patchwork of scripts that SysV was across the various distros.

Re: DirectX is coming to the Windows Subsystem for Linux

#490
post #392

Earlier quoted context omitted.

I disagree, Windows is very painful for me to use at a basic level compared to Linux. I would be very unlikely to take a job that forced me to develop under Windows.

The same is mostly true for me when trying to use a Linux desktop. However, if I'm using IntelliJ or Emacs and Firefox, I don't really need to care what OS is running underneath too much. Edit: of course, Linux and Mac are available for devs that prefer them. It's still much easier for IT to manage 7000 Windows desktops and a couple hundred Linux ones than it would be to manage 7000 Linux desktops.

> It's still much easier for IT to manage 7000 Windows desktops and a couple hundred Linux ones than it would be to manage 7000 Linux desktops.

Why? I have never seen Windows being managed entirely hands-off whereas Linux just works.

Post reply on HN