For a long time macos was close enough to *nix that it was far better than Windows for developers that need a Linux-like terminal. WSL might be seen as Microsoft's attempt to catchup and in many respects they leap frogged macos for this set of users.
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 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).
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".
> 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).
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.
Microsoft's lesson suggests that actual user needs have evolved passed the point where FreeBSD-style emulation compatibility is good enough. Users are no longer content with "good enough" Linux compatibility, they want perfect Linux compatibility.
Last time I tried WSL1 it couldn’t run Postgres, which was immediate disqualification for my backend work, if you could live with the slow git. WSL2 runs Postgres, docker and basically anything, and git is as fast as native if you stick to WSL2 file system.
* 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.
> 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.*
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.
Except it didn't work and had awful performance as soon as you did any syscall (this is especially apparent for filesystem access). It's a neat idea, but Linux has over 300 syscalls with varying levels of complexity in their behavior.
It worked fine, a lot of people are still using WSL1 and the Windows Android Subsystem is still closer to WSL1 than WSL2, and in that case in Windows 11 Microsoft is even selling that to ordinary users in the Microsoft Store.
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.)
I wonder how much of the WSL1 I/O performance had to do with the syscalls, and how much with them being visible to Widnows Defender and other anti-malware software, which all like to hook into every single file I/O operation userspace programs do. WSL2 I believe, being a full-fledged VM, gets to hide from those checks.
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.
Anecdotally, I never felt like syscall performance was an issue, it was always File I/O (and yes "real-time" A/V is always a massive issue for File I/O on Windows).
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.
I never experienced those syscall issues, despite being a heavy WSL1 user, but that's probably because my uses are pretty narrow - I use it to run Emacs, and do all the usual stuff stuff you do with Emacs, which mostly involve reading and writing text files, and occasionally shelling out or running git. Well that, and a C++ language server, which mostly involves file I/O and some in-memory data reshaping.
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.)
Yeah, most of my use cases involve Ruby in some way or another, with a little bit of C/C++ testing (comparing/contrasting the MSVC and more open source compilers). Ruby is the only language I can never get to work properly "raw" on Windows, it makes far too many Linux-based assumptions and lacks a lot of cross-platform niceties that for instance Python and Node more regularly provide out of the box. It's mostly been random Ruby tools I've seen crash to syscall oddities. (It manages to keep my expectations low for results from Ruby tools in general.)
(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".)
Darwin's FreeBSD roots are not very large (basically some of the userland terminal programs). It was never based on the FreeBSD kernel and that's where FreeBSD's Linux compatibility really resides.
That’s not true: xnu has significant parts originally copied from the FreeBSD kernel, alongside the Mach parts and the IOKit parts. However, considering not just the changes made in the process but also the ~20 years of independent evolution since then, I wouldn’t count on anything from the modern FreeBSD kernel being easy to port. Probably easier to start from scratch.
One key difference between Apple and Microsoft on this regard is that Microsoft needed such a tool internally: after all given the importance of Azure in Microsoft's ecosystem Microsoft developers need machines able to handle Linux workloads.
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.
So is this WSL 1.3.10 or WSL2 1.3.10? The Microsoft custom to confusingly name stuff goes on, in accordance the spirit of the Yoda-speak Windows subsystem for Linux...
ps.: the new features are nice, I like WSL2 and use it quite a bit sometimes.
I still don't understand Java versioning. Apparently the latest JRE is still 8u371? Is that Java 8? How does that relate to the SDK I use which is 17 or 20?
I don't know if upstream ships it but I think JRE still exists as a build target. Debian stable at least has packages like openjdk-17-jre, and unstable has newer.
Oracle no longer releases JRE post Java 8. Users are not supposed to install it as Applets and WebStart are no longer supported. Post 8 only JDK is released which has bundled runtime environment.
Bonus questions: why do I seemingly need to have both Java 8 and Java 11 installed on my work machine? But specifically some $RandomCompanyName Java, because Oracle Java and OpenJDK seem to be disallowed by corporate policies, and there are scanning tools running like hunter-killer drones, ready to snuff out any traces of openjdk and nuke it from orbit? And all I need it for is to run some PKI software that looks like it was written in the 90s?
I've lost track of what's going on with Java ecosystem, at least on the enterprise side.
Your corporate security crew are keenly aware that Oracle's licensing is just a wedge to help an army of lawyers invade your office. OpenJDK must be seen as guilty by association. There is no good reason to play around the legal nuclear pit that is maintained by Larry's minions.
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.
Oh my... Just checked my WSL2 version and it says WSL version: 1.2.5.0. Always thought it was version 2, but now I guess it's more about option 1 and 2...
WSL (option 1) is pretty dead I believe, so this should be WSL2 version 1.3.10...
but filesystem perf on WSL1 is horrible in general. Windows is much, much slower at touching a bunch of files than Linux, due to the filesystem filter driver architecture and NT's deep understanding of paths, the way NT does file locking, etc. it's night and day if you ever have to deal with something like a giant npm project or a huge git repo.
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.
They said Dev Drive supports bypassing most of the FS filter stack, and it somewhat makes sense that it is easier to bypass the stack at the drive level than the folder level (WSL1 was using folders deep in %LocalAppData%).
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.)
I did try WSL2 on a new machine, and it does indeed seem pretty fast even on this dinky laptop, but then working on those files with JetBrains tools (PhpStorm) is a bit of an issue. It looks like they've added some support for it now, but I think it's running the IDE under Linux and then forwarding the GUI or I don't know what, but it adds a bit of latency on the IDE side instead. So I lose one way or the other.
On a fresh install I first setup WSL1, duplicated it and then converted the other one to WSL2. I don't really use the WSL1 one much, but it's nice whenever I need touch files "in Windows".
Yes yes, just like ".NET Framework is a mature application platform" or any other vague terms they like to speak out just not to explicitly say "We will only do security fixes because we're obliged by the Windows Support cycle but really don't like to work on this anymore".
WSL2 is basically the VM solution (the distro and unix files are installed into a VHD just like a VM; the "real" Linux kernel runs directly on top of Hyper-V, the Windows hypervisor, as opposed to WS1 having the NT Kernel acting like Linux), so it may be a "best of both worlds" for you if you were to try "upgrading" your WSL to it.
I tried, it didn't work. The upgrade hangs and then never completes. Known issue apparently. Plus git on WSL2 has had a lot of issues in the past to make me not want to upgrade. Also worth mentioning that using portable VM disks is easier with other softwares than it is with WSL.
I used WSL2 for a long time and it was okay, but one day out of the blue CIFS (SMB) slowed to a crawl, like 10Mbps or something on a 1Gbps LAN connection. Downgraded to WSL1 and the problem went away, have been on 1 since. At least they made it easy to downgrade.
Was about to ask you how do you know the installed version, but wow, just updated WSL, and this new version also brought the support for the `--version` command line switch, so finally I can also check which version I have installed!
I'm waiting for https://github.com/microsoft/WSL/issues/10006 to be resolved without using the work around mentioned in that issue and all the duplicate issues closed before it, before I can reliably recommend the less technical folks on my team to use wsl.
I'd have to double check if there is a difference in behavior between manually setting the computer to sleep vs the computer sleeping on its own after inactivity. I think the former may reduce the skewing, but if I walk away from the computer for a tad too long and wake the computer back up, it'll take me a bit to realize why my 2fa to my local server running in wsl keeps expiring.
WSL daily is great, and generally better for the software development than MacOS, but every six months you have to stop WSL and run a scary command line tool to get your hard drive space back.
Reaching >100GB of host disk usage for <10GB of guest disk usage is clearly very significant. I'm glad you've got enough spare hard disk space or little enough file churn that you've not noticed it.
My Microsoft Surface device does not include Windows 11 Pro so it costs 120 GBP, about 155 USD, for me upgrade to Pro to get that tool.
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.
1) Docker works much better within wsl than outside of it. 2) You still deploy to Linux so makes more sense to develop on Linux, too. 3) performance is basically native.
Because Windows UI is better than anything MacOS or Linux provides. And because everything just works (tm) when it comes to drivers. And hibernate, sleep etc are always there since I don't need to dual boot. And I don't have to deal with buggy Cinnamon scaling experience that just occasionally decides "maybe I won't render things correctly today or just crash the UI when Firefox is launched".
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).
Are there any specific games you require Windows for? I've been pretty much fulltime on Linux at home now (still have Windows on a partition but boot into that a few times per year maybe), and play games more or less daily and have only experienced issues with Kingdom Hearts (cutscenes are broken).
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).
Funny how hibernate and hidpi scaling are two of the things always broken on my windows machine, there is always that corporate software that fails to restore its state after resume and forces you to reboot or that other corporate software that either looks blurry or tiny on 4k displays.
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:
78 comments
[ 3.4 ms ] story [ 161 ms ] threadI 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).
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.
The quote is misrepresenting issues with wsl1.
* 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.
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".)
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.
https://en.m.wikipedia.org/wiki/Unix_philosophy
ps.: the new features are nice, I like WSL2 and use it quite a bit sometimes.
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.)
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.
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).
https://github.com/microsoft/WSL/releases/tag/1.3.10
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.