All those years, people thought MS was hostile to open source, but their commitment was right there all along, in the GW-Basic code of conduct, with a link to their website too!
You and I both - first time I ever touched an IBM PC XT (in my Dad's office), I immediately fired up BASIC and went to town (had already been programming BASIC for 18 months by that time).
It was the first time I ever saw him just stare in awe at me like I was an alien's child! :)
WSL uses a Hyper-V derived virtual machine that is
* Sparse & light - they only allocate resources from the host when needed, and release them back to the host when freed
* Fast - it can boot a WSL distro from cold in < 2s
* Transitional - these lightweight VMs are designed to run for up to days-weeks at a time
Full Hyper-V VMs aim to (generally) grab all the resources they can and keep hold of those resources as long as possible in case they're needed. Full VMs are designed to run for months-years at a time.
WSL's VMs are MUCH less impactful on the host - FWIW, I run 2-3 WSL distros at a time on my 4 year old 16GB Surface Pro 4 and don't even notice that they're running.
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 < 2s and which aggressively releases resources back to the host when freed.
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 the tools you run within WSL can take advantage of the machine's available GPUs etc. and integrate well with the Windows desktop & tools, then you benefit. As do the many Windows users who want/need to run Linux apps & tools but cannot dual-boot and/or who can't switch to Linux full-time.
This will (and already has) resulted in MANY Windows users getting access to Linux for the first time, or first time in a while, and are now enjoying the best of both worlds.
The question isn't asking whether you, a Windows user who runs Windows, benefit. The question is asking what it does to Linux users who don't run Windows even a little. (And I think you know that.)
That's like asking whether Linux users who don't run ESXi benefit from their paravirtualized drivers being upstreamed. No, they don't, but they were accepted with way less bruhaha. And that's despite VMWare blatantly violating the GPL for more than a decade.
With DirectX on WSL, you can do new things when Linux is running on Windows (via WSL). But these new things aren't possible when Linux is running another way (e.g. on the bare metal).
So people who use it are married to Windows.
I think folks would be absolutely excited if this was an initiative to allow writing DirectX applications on Linux, and available for Linux on bare metal. But as people realize this marries them to Windows, they go meh.
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.
Imagine if you could run AI/ML apps and tools that are coded to take advantage of DirectML on Windows and/or atop DirectML via WSL.
Now you can run the tools you want and need in whichever environment you like ... on any (capable) GPU you like: You don't have to buy a particular vendor's GPU to run your code.
If you're old like me and remember the dark ol' days when games shipped with specific drivers for (early) GPU cards/chips, but failed to run at all if you didn't have one of the supported cards, you'll understand why this is a big deal.
> If you're old like me and remember the dark ol' days when games shipped with specific drivers for (early) GPU cards/chips, but failed to run at all if you didn't have one of the supported cards, you'll understand why this is a big deal.
Maybe I'm not that old, but I'm old enough to remember the days when microsoft was intentionally degrading opengl performance on windows ;).
This. Some games would have a handful of different renderers for different setups, while other games would only support one specific card type (and if you were lucky, a software renderer).
Those days sucked. Bigtime. If we can avoid doing the same mistakes for machine learning then we should.
> Maybe I'm not that old, but I'm old enough to remember the days when microsoft was intentionally degrading opengl performance on windows ;).
Which is still nonsense, since this only affected the OGL driver shipped by Microsoft. In contrast to truly bad actors like Apple, OEM were free to ship their own OGL drivers from day 1.
>Now you can run the tools you want and need in whichever environment you like
Isn't the linked post saying you have to be running on Windows though? It seems like it would make way more sense to either port directX to Linux, or ditch directX and put those resources into supporting Vulcan.
Don't you think the effort to achieve this would be absolutely massive? I don't know what kind of resources are thrown on this project, but I'd estimate minimum to be 3 dev teams for 2 years just to get a few variations of ResNet to work "as is". And that's just for regular models, that don't require quantization or (auto-)mixed precision for training.
Neither pytorch nor tensorflow support WinML, so this is going to be a bit of a stretch still, since CUDA is still the toolkit of choice for mainstream ML frameworks.
WSL 1 and Expo don’t play nice with each other; Expo was causing ephemeral port exhaustion and making both Windows and Linux unusable. WSL 2 should fix, but I don’t want to jump to an insider build quite yet.
Appreciate your feedback, but we solicited and received feedback from many, MANY sources. UserVoice, Stack Overflow, Github Issues, customer interviews, email, Twitter, comments after speaking at events, comments from customers at booths at OSCON, Build, Ignite, JSConf, PyCon, etc. to name just a few.
We received an OVERWHELMING number of asks for unicode text support. Emoji are simply one class of unicode glyph but they're pretty important for those working with tools/scripts that use emoji to indicate the state or outcome of an operation.
Further, many users speak non-Latin languages which require non-ASCII glyphs, some of which can be quite challenging to support in a grid-based display format (e.g. Arabic, Hebrew).
This whole class of asks around "Unicode Support" required not just a brand new renderer that could actually draw the correct glyph in the correct cell, but also a whole new way of storing, iterating, and navigating variable-width code-points qucikly and efficiently.
These asks (and many others like them) vastly outnumbered asks for mouse support.
The Console/Terminal team first took-ownership of the Console & Cmd codebases in late 2014, so it's been ~5.5 years.
Until v. recently, the team averaged ~2.5 devs and 0.5 PM (I had to split my time across Console and WSL).
Since spring 2019 when we began the effort to build Windows Terminal, we've grown the team to 4 devs and 1.25 PM (I am now the .25 since Terminal now has a dedicated PM).
During this time, we have shipped improvements to Console in every release of Win10, including transparent background, VT, 24-bit color, and many perf, stability, etc. fixes. But we can only do so much to the Console before we start to break users' existing systems, apps, and tools.
Since Console & Cmd's key responsibility is backward compat, we're pretty much leaving them alone.
But we're plowing ENORMOUS effort into building Windows Terminal which is shaping-up nicely for its v1.0 release this summer. Please give it a try and if you find problems, find/file issues in the github repo because, yes, Windows Terminal and Console are open-source!
1. You're confusing Cmd (the command-line shell) with Console (the terminal UX you see and interact with on-screen)
2. Development for NT started in Oct 1989 and the first version of NT shipped in 1993
Hey Nick. I'm the PM for Windows Terminal, and formerly, WSL:
Thanks for your thoughts on WSL & the new Terminal.
Re. release mechanisms, etc: Terminal will be delivered via the Store so we can ship out-of-band.
We're aiming to deliver new Terminal preview builds every 2 weeks or so which, since we're delivering via the Store, will auto-upgrade everyone soon after each release.
Re. Insiders: We do NOT gather any personally identifiable information. We only collect anonymized statistics about some of the features you use and/or issues you experience. Why? To ensure that we can find and fix issues as effectively as possible.
For example, with WSL, we collect the number of times an un-implemented syscall is called, or # of times a syscall returns an unexpected error. We couldn't care less WHO experiences these issues, only how OFTEN they occur. This info (esp. combined with bug reports in our repo, etc.) has been essential in helping us prioritize which syscalls are being called, which we've implemented, which are failing, and thus, which we need to pay attention to. Without this info, we wouldn't have been able to make WSL as good as it is.
We understand the community's concern about data collection - heck, EVERYONE should be - but in the general scheme of things, I think it fair to say that Microsoft's telemetry data collection is pretty well contained and is not egregious.
The last time I tried to install insiders it mandated that I sign into Windows with a real Microsoft Live account, which requires an email address sign up.
Where as the stable version of Windows allows you to create an offline account.
If I sign in with a Microsoft Live account, now you can associate my email address to my OS usage stats. Isn't that the definition of personally identifiable data?
It mentions "User ID -- a unique identifier associated with the user's Microsoft Account (if one is used)". It also mentions collecting a bunch of low level network data that look questionable, such as IP addresses flowing through network devices. Isn't that saying "logs every website you visit"?
Then it mentions it logs every app I open and how long it was opened for, and even what I search for in those apps. I didn't go through the whole list in detail but that was what I saw in a 60 second scan of the page.
But on the topic of WSL, are you saying if we run Windows stable we'll be able to get and continuously update WSL v2 from the store? That would be neat.
