> Those pain points were solved in WSL 2 by embedding a whole first-party Linux VM inside Windows
Wait so now it's just a regular Linux virtual machine? I thought it was a thin translation layer between the kernels? Kinda not as impressive now.
Wait so now it's just a regular Linux virtual machine? I thought it was a thin translation layer between the kernels? Kinda not as impressive now.
It's only running alongside Windows in the sense that it's running in Hyper-V, which Windows itself effectively does when you have Hyper-V enabled. What is special about this Linux build is that it's specifically made for running alongside Windows since it needs to integrate with the Explorer and other Windows components[0].
0: https://devblogs.microsoft.com/commandline/shipping-a-linux-...
The users who aren't concerned with making the distinction you just brushed aside don't know or care what a VM is so for them Linux is just an app running in Windows. You're making your point the same way they would.
https://docs.microsoft.com/en-us/virtualization/hyper-v-on-w...
WSL1 was like that, but it was severely handicapped by NT filesystem performance, especially for small files or metadata operations. There are a lot of small operations that are more than 2 orders of magnitude slower on Windows than on Linux, and a lot of Linux software just expects them to be fast, so WSL1 is not a great experience for a lot of stuff.
This seems to be a known issue, but nobody knows how to fix it. (It's some UAC thing, apparently.) I imagine this is what WSL 1 used, and it was similarly slow.
From the original NT microkernel design, filesystem access is all asynchronous messaging, and it can be intercepted and modified by drivers at many points. A lot of software takes advantage of that. But it's also why caching isn't as effective as it could be, since you can't rely on all those unknown layers returning the same result each time.
Plus a lot of Windows systems are running an AV which likes to check to see if you should be allowed to read any particular file in case it might be dangerous.
In relation to the above conversation about WSL1 performance characteristics, my impression is that ReFS would be equal or worse to NTFS for what Linux/POSIX file operations expect. (ReFS is still very much on the "SQL Database" side of the analogy, like NTFS as it was of course designed to support much the same transactional semantics, and some additional ones as well at the "virtual storage space" level above the physical pool of drives.)
In danger of getting further aside into tangential spaces, Ubuntu's current experimentation with ZFS by default is probably one to watch to see if the user experience of complicated multi-physical disk file systems like ReFS can be made to fit and is useful to a broader user base than just power users. (Though arguably compared to the broader spectrum of casual Windows users, even some of the more casual Ubuntu users might be considered power users in comparison.)
Also they said "That doesn't mean we've given up either", but you really have to do some mental gymnastics to convince yourself that moving to a VM wasn't "giving up" on solving these problems in WSL1.
And no matter how much MS improves WSL 1 there would always be something missing that enough users want/need. For example I care more about the network related stuff that wasn't implemented (NETLINK_ROUTE\RTM_GETROUTE, AF_PACKET family) because this excluded nmap.
I think Docker on Windows also uses it but I don't use that. Windows Defender has never indicated a requirement for Hyper-V to me.
But in any case, I think the component you want to refer to in that case it the "I/O subsystem".
The RAM issue is a clear setback, and makes it annoying trying to do large compile jobs on the Linux side, though it's been a while since I've tried it. In theory it could be possible to handle coorporation between the Linux and Windows RAM usage patterns since they're running a very heavily modified kernel. I'd be very interrested in knowing if anything is hapenning on that front.
That's possible in theory, I've done it with libvirt/KVM. You have to enable discard on all filesystems and swap on the guest, use a virtual disk interface which can pass the discard requests to the host, and configure the host to release the corresponding blocks on a discard request. I don't know if WSL2 comes configured to do all that, but if not, it shouldn't be too hard for them to add this functionality.
It is technically less impressive, but much easier to maintain and stay compatible for Microsoft.