WSL 1.3.10 Brings Experimental Memory Reclaim, Updated DXCore and Linux Kernel
phoronix.com
phoronix.com
ps.: the new features are nice, I like WSL2 and use it quite a bit sometimes.
WSL1 just runs processes on the NT kernel directly. There's no need for memory reclaim just as there'd be no need while managing Win32 binaries.
I've lost track of what's going on with Java ecosystem, at least on the enterprise side.
As for jdk8 vs jdk11, backward compatibility was broken when J2EE javax.* classes were rightfully removed from the standard lib after Java 8. But Oracle (again) disallowed usage of the javax namespace in external libs and everybody now has to update to the poorly named jakarta replacement.
WSL (option 1) is pretty dead I believe, so this should be WSL2 version 1.3.10...
WSL2 is much faster on files that live inside it. I haven't found the 9P bridge to Windows to be too slow.
honestly, I don't know why they couldn't bypass the FS filter stack or something for WSL1.
(disclaimer: I work at MS, but not on WSL.)
I'm very curious what WSL1 performance sitting on top of Dev Drive will be like. I have no idea yet if that's even an expected to be supported scenario. (In further curiosity with a few quick searches: no direct mention of it in the Dev Home repo, the only WSL-related issues they seem to be currently tracking are installing Repos to WSL paths from Dev Home. I don't see anything on automating installing WSL[1] distros to Dev Drive.)
This is only WSL2 (I know, versioning could have been better)
https://github.com/microsoft/WSL/issues/4699?ref=blog.dan.dr...
Personally, i never had to do this
It’s great that you personally don’t have to do it. Maybe you don’t often delete files from the linux drive. Maybe your hard drive is large. I know other people that have to do it once a month. That is how storage works.
WSL is great but the only use I see for it is if Windows is forced upon you by company policies.
I've ran Windows as the host for my Linux VM for years because it always provided me nicer experience than the other way around. Not to mention games are of course native in that context also (and there's no issues with anticheats).
Windows just is the best desktop for Linux.
Funnily enough, games sometimes run better in the "non-native" context of Proton on Linux (Elden Ring is a notable example, which had the shader compilation stutter on launch on Windows, but much less noticeable on Linux, and no issues with the anti-cheat (EasyAntiCheat) either).
I don't see Apple putting in the same level of effort to create the WSL experience on mac but who knows. Hyperkit could be quite a nice base to build on.
The only issue I've run into is that there are more gotchas with podman & docker when running the ARM macs but that's only because so many images are still x86-only.
Edit: Darwin has BSD roots and FreeBSD offers Linux binary compatibility.. I wonder if it could be brought to macos (would be a huge undertaking though since there are SO many differences between Linux and modern macs).
I know for a fact that Microsoft sees it as a defeat internally that their own developers would rather have a macbook over the company-issued Surfaces or similar windows laptops. So easing the pain of working on *nix machines is a top priority for enterprise Microsoft users.
That's not really a huge issue for Apple, they are neither in the business of selling linux virtual machines nor their ecosystem offers such a huge gap to native linux after all.
That sounds like trying to recreate what Microsoft did with WSL1*, which is an emulation layer for Linux on Windows. They realised that was a mistake (things like cgroups and container support are complex and slightly different implementations led to subtle bugs). Now WSL2 is a whole Linux kernel running in virtualisation.
The "clever" bits are now the glue (file sharing, even if that has performance limitations) and some things like WSLg, which sadly they still keep as their own fork and haven't upstreamed yet.
*: As touched on in other threads, despite the version number of 1.3.10, most of the features they are talking about, such as actually using a real Linux kernel are for "WSL2".
In the meantime, FreeBSD, NetBSD, and illumos have all had Linux ABI compat since long before WSL1 and are doing fine - not perfect compatibility, but quite good. If I were guessing, I would guess that papering over the difference between members of the unix family is easier than between unix OSs and NT.
* As I sort of mentioned, I suspect that the others may actually do a better job of compatibility than WSL1 because they're on unix-likes already so there's less fundamental differences to try and make compatible. For example, fork() is already cheap, and unix-likes already have filesystem performance like Linux.
* A binary compatibility layer is less important to begin with since you're already on a unix-like. For example, sibling comment says postgres didn't work; FreeBSD already has postgres as a fully supported native package, so you're unlikely to care how it runs under the Linux compat layer.
The quote is misrepresenting issues with wsl1.
Wish they didn't just throw in the towel. WSL1 was (is, still using it) something special, WSL2 is only streamlining/first-party-ing the usual workaround of running Ubuntu in a VirtualBox.
The performance was never that bad, depending on your use cases is all. Admittedly a lot of use cases for developers are heavily file I/O bound or deal with dark details and edge cases of syscalls rather than the happy paths (because developers gonna develop), so of course developers felt the performance sting there.
(I'm very curious if WSL1 on the soon-to-come Dev Drive has good performance, because it will bypass a lot of the file I/O filter drivers that caused some of the worst WSL1 performance for developers. That seems like an obvious and interesting win, if the case.)
In my experience, WSL1 was fast enough even on large git repos with lots of files (after tweaking some Git settings), but performance crashed once corporate nuked my Defender exclusion lists, making both the repo and the entire WSL1 filesystem suffer from "real-time checks" on every file write.
The issues with syscalls to me always seemed to be more around obscure compatibility than performance. Apps would crash that shouldn't because they relied on a weird POSIX edge case (that they maybe shouldn't). It always seemed more to me on the general syscall front beyond File I/O that "app just doesn't work at all" rather than "app works slowly".
That said, I've never been a heavy WSL user so my experiences may have been limited in some of the syscalls people were complaining about. WSL1 was "fast enough" for my use cases. I'm very curious if WSL1 on the incoming Dev Drive which takes a different approach to A/V exclusion among other things and file I/O in general would be as good or better than WSL2 performance.
Within those use cases, I hardly had any trouble with anything - the worst things so far was 1) clipboard occasionally breaking, which I'm now 95% convinced is a problem with PowerToys, not WSL, and 2) Emacs leaking memory, which is what you get when you build it from sources at the tip of the main branch. I haven't had anything bad happen I could clearly attribute to WSL1.
RE Windows Defender, this is not a problem on my personal machine - as long as you can set up exclusion rules for real-time scans, it barely registers. Unfortunately, at work, security policies got updated, erasing my exclusions and preventing any changes to it. WSL2 doesn't seem to be affected - I suspect simply because its VFS is opaque to Defender - but it's not without problems. Most annoying of them is that network traffic to/from WSL2 gets blocked by the company VPN, which isn't the case with WSL1. I'm yet to find a workaround for this.
(And yes, the VPN maker has plenty of support issues opened about WSL2 issues, and it's addressing them about as eagerly as Microsoft is addressing WSL2 tickets on Github.)
(In regard to your WSL2 VPN issue, that seems to be expected given it is running in a VM. It's possibly just as simple as enrolling the network interface WSL2 is using like you would any other Hyper-V network interface for your VPN. To my understanding, it should be auto-bridged to your main network interface, but is still its own network interface and some VPN software is too smart for its own good and ignores Windows' bridges to charge more. If so, it may even be likely your tickets are just languishing in the "won't fix" of "please pay us more to upgrade to a SKU that 'better' supports VMs", ie "a SKU that doesn't intentionally ignore VM network interfaces, because we can charge for that".)
With the memory reclaim, that's going to be neat for long uptime Window systems. That said, I wonder if they fixed a memory leak in wsl.exe I reported that Docker Desktop seems very keen on making more and more of. Hundreds of thousands of handles leaked after a week uptime:
https://github.com/microsoft/WSL/issues/9851
DD is a POS, so ah, whatever.