Today we’re unveiling the newest architecture for the Windows Subsystem for Linux: WSL 2! Changes in this new architecture will allow for: dramatic file system performance increases, and full system call compatibility, meaning you can run more Linux apps in WSL 2 such as Docker.
This is a massive new release of WSL, and for the first time for consumer-facing Windows, Microsoft will be shipping a full Linux kernel with its operating system.
Beginning with Windows Insiders builds this Summer, we will include an in-house custom-built Linux kernel to underpin the newest version of the Windows Subsystem for Linux (WSL). This marks the first time that the Linux kernel will be included as a component in Windows. This is an exciting day for all of us on the Linux team at Microsoft and we are thrilled to be able to tell you a little bit about it.
All changes will go upstream, and the kernel itself will be updated through Windows Update. Of course, this Linux kernel, which contains patches to optimise it for WSL 2, will be fully GPL compliant, so anyone will be able to build to their own custom kernel using these patches.
So now that it’s a VM instance, local file system access must be through a network mount? Our have they done NTFS drivers with cluster locking against the windows system? Does Linux get to use all of the CPU cores? The press was going on about 20-times filesystem throughout improvement, but if that is just to a closed-off VM ext4 image that’s a bit less interesting, no?
It loos like it’ll be the same experience as WSL1, with the same level of integration (That’s what they’re claiming anyways). This would mean accessing the host filesystem under /dev/ as it currently is.
Only, now launching a shell fires up a custom Linux kernel in a special lightweight virtual machine. The demo shows it launching in two seconds.
Presumably it also requires Hyper-V to be enabled, so if you depend on another hypervisor, you won’t be able to use it. However, you’ll be able to switch whatever distribution you pick between WSL1 and WSL2 and back at any time, seamlessly.
Here is what they’ll do:
1) put more and more Linux into Windows,
2) get rid of more and more Windows,
3) port all their valuable software (Minesweeper, Visio and… ?) to Linux,
4) get rid of the Windows kernel and use Linux with a proprietary UI just like macOS does with FreeBSD.
It’s all very clear to me now.
Isn’t the lack of a stable ABI for Linux a stumbling block? Besides, the NT kernel never seemed to me to be a source of problems for Windows.
The lack of ABI is only at the kernel driver level… The userland ABI is stable and has been for a long time…
The NT kernel isn’t too bad, most of the stability and security problems associated with windows have been due to the cruft loaded on top (eg win32 which has its roots on dos).
However, WSL2 is promising massive performance gains over WSL1, yet one of the key differences is that WSL2 runs a full kernel in a hypervisor whereas WSL1 was a reimplementation of the linux syscalls under the NT kernel… I would have expected the VM approach to be slower as it carrier more overhead, so the previous approach must have had some serious inefficiencies.
MacOS uses a great deal of FreeBSD, mostly for userland stuff, kernel services, and whatnot – the one thing they do not use though is the kernel – Xen is not FreeBSD or even distantly related to it (it is a derivative of the Carnegie Mellon Mach kernel)…
Regardless, I completely disagree. I personally think Microsoft is quite happy with the NT kernel, which to be honest is about the best piece of software they ever developed. There problems are all way higher in the stack (although its much less of a problem now than it has been historically imo).
Microsoft wants users to buy Windows. A lot of developers prefer Linux or even MacOS because they both have a bash shell and are Unix work alikes – there is a lot of programmers out there that don’t live in Microsoft’s ecosystem that need bash/ssh/node/docker/ruby/python/etc. and want things to work like it does on Unix. While most of those things can be done on Windows now, the level of pain required is often higher than most programmers would like. This is meant to make at least some of those users happy, and that is why it exists – because it will make Windows viable for them when it wasn’t before.
Its the same reason they are trying to get traction with .NET on Linux – because they want mind share from some of those same programmers. Being a closed ecosystem does not benefit Microsoft the same way it does Apple, because Microsoft still makes most of their money through software and services, not selling hardware.
Microsofts historic success was built on its OS and tooling was the one developers Wanted to work on. It then became self-fulfilling as more apps were developed, more users needed those apps so used windows.
This later became perverted into a lock-in. The strategy is now (again) make Microsoft products the go-to development system(s) and the apps and users will follow.
Windows/Visual Studio/.Net/Github/Azure all viable toolchain options to build and run linux native apps.
Edit: I typed Xen for some reason… I meant Xnu
https://en.wikipedia.org/wiki/XNU
XNU is has more FreeBSD than you realize – The Virtual File System layer, the Unix process model, unix-stye UID and GID and permissions, network stack, SysV IPC, Mandatory Access Control, HFS/HFS+ support, NFS support, and the crypto framework – all part of XNU, all came from FreeBSD.
That is the stuff I meant by kernel services… I’m not at all minimizing the importance of the FreeBSD bits to MacOS – it is arguably more important than the kernel itself in many ways, but it still isn’t a FreeBSD **kernel**.
I know Xen isn’t FreeBSD, but saying it isn’t distantly related is just wrong.
Take it from the the OSX System internals book:
Emphasis mine.
Also,
Nearly half the kernel is FreeBSD based. XNU isn’t a microkernel with FreeBSD kernel services running as Mach tasks – it’s a monolithic kernel, of which FreeBSD is a significant part – using Mach technology to isolate kernel components from each other, but all running together in kernel space as a largely singular unit.
No, they certainly will not. It cannot be understated how important backwards compatibility is to Windows’ success.
Switching to a Linux kernel would break that, and porting Win32 and all the other stuff to Linux would be a monumental task with literally zero benefit.
They aren’t doing this in preparation for moving to Linux. This is solely to convince developers to use Microsoft tech, no matter what they’re development target is.
They like to make a big song and dance about backwards compatibility, but it’s hype. They break things and drop support for old things all the time (just like nearly everyone else). And a good thing too, as lots of the old APIs and designs were severely limited. The world changes. Software that operates in the world needs to keep up.
areilly,
Yes they do break things sometimes, but by and large one of the main things that keeps windows afloat is legacy applications. It takes work and money for developers and corporations to migrate applications. Right now microsoft windows enjoys defacto-support. But if microsoft were to drop the old win32s APIs, without backwards compatibility the new platform would instantly loose marketshare. On the linux side it’s APIs are just as old as windows’. Backwards compatibility with POSIX was one of the big reasons linux was widely adopted for servers: linux avoided changing things even where the engineering could have been better. Alternative operating systems try new APIs all the time, but all too often these go absolutely nowhere because the market insists on POSIX compatibility.
On the languages side, we’ve learned a lot in the past several decades, but we’re so invested in C that we will continue to do what we’ve always done because legacy is still a huge driver.
I don’t disagree with you that old APIs can hold us back, they have made mistakes and we sometimes suffer for it, but I think you’re being optimistic about change in the software world, backwards compatibility remains a crucial requirement for uptake.
Drumhellar,
I’m not actually sure that nnnnic’s post was meant to be taken literally, it may be sarcastic. But yeah microsoft has no intention of ditching the windows kernel for linux. Their intention with linux interoperability is to bring developers back to microsoft’s stack even when they’re developing for linux. My guess is that they don’t exactly like supporting linux, but it’s foolish not to acknowledge linux’s success in the datacenter. Microsoft would rather have linux developers on windows than to loose them outright.
There is some irony hidden in that earlier posts given Apple recently announced forced migration to 64-bit.
Hopefully this fixes the issue where using Windows apps to modify files in the WSL file area makes them lose all their file permissions (literally file mode 000). I like using Sublime Text and don’t want the overhead of installing X and whatnot in WSL.
Yes, I realize this is a self-inflicted problem. 🙂
They have! As of 1903, accessing WSL files fro Win32 apps doesn’t break things.
That’s cool enough, but it’s even cooler: They use Plan9’s 9P protocol to facilitate such changes. A launching 9P server is part of the init process for WSL.
Drumellar
Linux added plan9’s 9p protocol several years back to allow file system access in virtual machine guests to pass through to the host.
https://www.linux-kvm.org/page/9p_virtio
I took a look at this setup years ago for hosting services, but I decided to use a virtual disks instead as these were much better optimized. Consider the overhead of having every single file operation pass through to the host versus flushing entire spans cached on a virtual disk. Also, 9p requires changes to guest distros.
Anyways, while it wasn’t applicable for my use cases where each virtual machine is used by different users, it is a cool feature to be able to share the file system for single user oriented virtual machines. Many of us already use network shares, so it doen’t make much difference, but it eliminates the need to copy files to and fro since they’re all in the same file system.
Well. I, for one, think that WSL is the coolest thing that Microsoft has done in years. It also took me completely by surprise.
I’ve been a Linux guy for 20 years. For about 10 of that I would also use Mac laptops, as it gave me the best end-user experience with a proper Unix back-end. That Microsoft has swung this with Windows at the same time that Apple seems to have turned their backs on that market is good timing for me. I’m typing this in a Surface with WSL running full-screen on a virtual desktop. This has become my norm and is working just great. I look forward to both their new Terminal and continued development of WSL.