hckrnws

better format from the devblog[0]:

Added support for new opt-in experimental features

    autoMemoryReclaim – Makes the WSL VM shrink in memory as you use it by reclaiming cached memory
    Sparse VHD – Automatically shrinks the WSL virtual hard disk (VHD) as you use it
    Mirrored mode networking – A new networking mode for WSL that adds new features and improves network compatibility
    dnsTunneling – Changes how WSL resolves DNS requests to improve network compatibility
    firewall – Applies Windows firewall rules to WSL, and allows for advanced firewall controls for the WSL VM
    autoProxy – Makes WSL automatically use the proxy information from Windows to improve network compatibility

Readable version:

autoMemoryReclaim – Makes the WSL VM shrink in memory as you use it by reclaiming cached memory

Sparse VHD – Automatically shrinks the WSL virtual hard disk (VHD) as you use it

Mirrored mode networking – A new networking mode for WSL that adds new features and improves network compatibility

dnsTunneling – Changes how WSL resolves DNS requests to improve network compatibility

firewall – Applies Windows firewall rules to WSL, and allows for advanced firewall controls for the WSL VM

autoProxy – Makes WSL automatically use the proxy information from Windows to improve network compatibility

Also from the same article:

    WSL GUI apps now have Windows snapping with the keyboard

Auto shrinking the disk will be very helpful. Currently, it is necessary to shut wsl down, invoke some power shell commands and hope that it works. I’ve messed it up before.

I love when guides for this recommended I back up my 300 GB VHD before shrinking, which I'm doing because I'm running out of space.

Mirrored network mode sounds quite a lot like what wsl-vpnkit does: https://github.com/sakai135/wsl-vpnkit

It came from Docker Desktop for Windows, where they needed a solution for VPNs like GlobalProtect and AnyConnect that are often configured to drop packets for networks that aren't the main one associated with the VPN.

How it works: https://www.docker.com/blog/how-docker-desktop-networking-wo...

Edit: Reading a bit more, it seems like they are both trying to solve the same problem but in a different way. The mirrored mode seems use the same exact IP in the wsl/linux instance that's used in Windows. Somewhat like docker host networking.

Does anyone else find it totally confusing that they released WSL 2 around Windows 11, and now they call this release 2.0.0? Are they going to release version 2.0.0.0 next year?

When I first started seeing articles this week on hacker news, I thought they were just old.

Anyways, I love WSL! Thanks for the update.

If anyone is curious like me. Apparently the original version wasn't released on the Microsoft Store and WSL2 was version 1.0.0 on the Microsoft Store, so apparently they've switched to using Microsoft Store Versions even although it's super confusing.

Can someone elaborate on what exactly is mirrored network mode, under the hood?

Not sure exactly, but not happy with the non-answers in the thread.

From my understanding, mirrored network mode is essentially duplicating the Windows host network interfaces into the WSL2 VM, so that they have the same IPv4 (and IPv6) addresses. This also allows you to seamless access network services between the Host and VM over localhost, and also expose network services (say SSH) over your LAN without futzing around with firewall and port forwarding (as you would have to do previously).

https://devblogs.microsoft.com/commandline/windows-subsystem...

Scroll down to "New Networking Mode". Still somewhat sparse on info, but does have some detail.

watch the video, it is explained and demo-ed.

One line of text is often so much better than blah blah youtube blah.

TLDR always confused me. I'd rather read 10 paragraphs in a minute, than sit through 10 minutes of "hi, I'm Joe X, and this is my blah blah..."

I agree. I much prefer to read than watch a video, especially for technical content.

Don’t forget to like and subscribe!

This is good news as I'm forced to use the companies hardware with windows 10 and zscaler vpn. I love WSL and VS code, works great together but zscaler has occasionally been a pain.

Hopefully the mirrored network mode will help, looking forward!

Sidenote regarding the website (mobile) of the article, how many annoying and slow loading ads can you fit into a single page holy smokes...

I am in the same situation with having to (or was required to use) Windows 10 on hardware. I just wanted a bash shell with network access via the VPN. On that computer I was able to install MSYS2 with some certificate tweaks to get it to work on the VPN (git bash is fine too). I realized gradually I can do most things on my Linux laptop and a virtual desktop :)

Regardless, I think this is great, particularly for colleagues, so I can have a good story around using something Linux on their Windows laptops (specifically bash, docker, using devops tooling, etc.)

IMHO, if the requirement is just for Linux CLI tools, WSL1 - it still exists - may have been a better experience. It gives access to a complete distro without having to deal with WSL2 hibernation issues.

IMHO, they should have invested more in WSL1 - it actually shares Windows resources and runs under the Windows kernel rather than trying to do clever things with virtual machines.

Yeah WSL1 is underrated - and more elegant IMHO

Elegant but really hard to implement and maintain (at least on top of the NT base (which I mention because illumos and some BSDs implement Linux compat more easily by being unix-like in the first place)); it's much like how WINE is pretty decent but will always have more compatibility problems than just running Windows in a VM.

I think the reason they gave up is because the Linux kernel has a LOT of syscalls, and every single one would have to be implemented flawlessly in order to properly support all of userspace. They'd basically be implementing a second Linux kernel.

Also because filesystem access translation results in very poor performance vs native Linux filesystem, which is basically insurmountable because of Windows design.

Probably, but this is on a corporate computer and I saw that no WSL version would work. I am otherwise not interested in using Windows (and found a way to avoid it :D )

Cygwin64? Im using it all the time on Windows 10. Without it I would be huge pain to use Windows at all. Pretty much everything works fine over cygwin64, I didnt yet find a tool that has problems. And I like that its just cygwin.dll providing basic POSIX layer, everything else its just windows (networking, FS, ...)

Yeah ... the MSYS2 site says: "The unixy tools in MSYS2 are directly based on Cygwin, so there is some overlap there. While Cygwin focuses on building Unix software on Windows as is, MSYS2 focuses on building native software built against the Windows APIs."

I've been using git for windows / msys2 bash for a while on top of WSL2 - you don't find it to be annoyingly slow?

Hmm, I think I am not following. Why using msys2 bash on top of WSL2? You either using WSL or cygwin/msys2.

GIT is slower on cygwin, especially stat() with do hacks to check for +x mode. But once cache is warm, it works fine. Albeit, I didnt used GIT under Win10 from quite some time, im doing most of my stuff on older windows using my very old Cygwin fork thats is more snappier :)

I use msys2 bash sometimes to collaborate with people and projects who are using it. Adoption of WSL2 is still a work-in-progress at secure enterprises.

Ahh ok, this makes sense. Well, I barely use my corpo Win10. I hate it. Cygwin64 helps a lot, but still if I can do work on my desktops Ill do it there. Basic stuff can be done on Win10 in shell (bash).

So, cannot say much about Win10 + msys2 + new GIT performance here. My laptop is slow anyway with all the bloat IT put there :)

One thing I found useful is setting up a VPN docker container and reverse proxying only the things that I need through the VPN.

When you spend a significant amount of time working on Linux servers/terminal/CLIs, being forced Windows with "there's WSL for you" answer is so infuriating. It's not the same for so many reasons (networking, disk sharing/speed, tooling, file system pathing quirks to name few).

I worked at a company where I was being denied a Mac despite them being common in the organisation and other engineers had them. I left due to a numerous reasons, and the next-most-senior teammate was very vocal about getting a Mac.

He was given a Mac very next week after I left.

Will Microsoft make this version of WSL available to Windows 10 users? With slightly two years and a month of support left, Windows 10 has reached the "you should be looking into migrating to Windows 11" phase, and I wouldn't be surprised if this branch only makes it to Win11.

afaik thats already the case for most of the newer features. Not sure if you can nowadays install WSL from the Store (which AFAIK is the version that still gets updates) in Win10, but nearly all new features (including GUI support, systemd support, etc) are only supported in the Win11 version.

Sadly so, I'd like to use more of that on my Win10 work device, but not willing to move to 11 for just that.

> Another notable addition in this version is the "Sparse VHD" feature, which, as previously described, automatically shrinks the size of the WSL virtual hard disk (VHD)

Finally. Previously you had to run a bunch of sketchy diskpart scripts, unless you paid for windows professional, which doesn’t come on Microsoft devices.

> Networking improvements are a consistent top ask for WSL, and this feature aims to improve the networking experience in WSL! This is a complete overhaul on the traditional NAT networking architecture of WSL, to an entirely new networking mode called “Mirrored”. The goal of this mode is to mirror the network interfaces that you have on Windows into Linux, to add new networking features and improve compatibility.

For a brief minute I was hoping that this would be a built-in solution for mirroring host files to the linux VM, but alas...

I think development on windows has come a long, long way over the years, but I still feel like these days you're all but stuck going all-in on WSL -- meaning no more GUIs -- or keeping the GUIs but losing WSL. For example: if I want to use sourcetree for git on the host, but autoreload processes within docker when I change code, I'm basically out of luck: sourcetree can't deal with files on the linux filesystem (or at least, not on my setup, though that could be more than just an issue with sourcetree), so I have to store the files on the host. But things like inotify can't cross the filesystem boundary, so now autoreloading works. Which is why the advice is always just to keep all of your code within the WSL filesystem, but now the GUIs don't work. (I mean, I think in theory you can get GUIs from inside WSL, but I have absolutely no interest setting that up -- now it's like a Matryoshka doll of virtualization. Plus, some of the programs I want to use don't ship a linux version, so it's a moot point).

My workaround is annoying but effective, as long as you have a good enough system for it: I run a watcher process on the host and an rsync server within a dedicated docker container, and it syncs my code for me into a named docker volume. I guess this has the added benefit of allowing me to have my own filter files for whether or not things get copied over (I have multiple git repos, and I'd like each of them to obey their gitignores when copying), but... it's definitely pretty rough around the edges.

But still: any improvements are good!

This is probably a dumb comment, but have you looked into using WSLg? I.e. also run the GUI inside WSL? The integration between Win and WSLg is pretty seamless!

Not dumb at all; WSLg would actually work for linux applications, and in theory seems relatively painless, though I've never actually tried it. I think the guides I was looking at were pre-WSLg, where it was... a mess.

But it's kinda moot, because not all of the applications even have a linux version. Sourcetree is a great example: it's only available on windows and mac.

To complicate things further, because I move frequently between my laptop and my desktop, I have all of my source code in dropbox (including git, and yes, it's a shitshow, though I would like to change the way I have this set up because dropbox has a nasty habit of temporarily breaking git). And to complicate things _even further_, my old laptop is dying, and I'm replacing it with a macbook (and throwing ubuntu on the old one), so I'll have windows 10, mac, and linux all at the same time.

For the most part I make it work, but there are definitely days when I just want to throw them all out the window.

Both intellij/pycharm/… and vscode work with WSL these days. Dev tools have to adapt or die, more people seem to use WSL every day. Where I’m now, one of the blockers is the VPN/network issues mentioned here, so I imagine even more devs moving after that is sorted out

Don't get me wrong -- I'm not complaining! Like I said, improvements are just that: an improvement. And my priorities aren't the same as WSL2 priorities, that's clear too.

But I don't think it's reasonable to expect that all of my tooling work with WSL2. A decent chunk of my tooling isn't even developer-centric -- why would the tools I use for asset creation support WSL2? Should Adobe? Should Inkscape? What about the docker sync that I use for static assets, or for source code when I need to move between laptop and desktop and don't want to make a temporary commit or patch with git? Windows app development is already messy enough, are we going to require that everyone making a windows app jump through yet another hurdle, on the off-chance that the small percentage of windows users who happen to be devs can get it to work with docker containers? That doesn't seem reasonable to me.

There are plenty of people like me that choose to develop on windows (and aren't forced by a company to do so), precisely because they want to be able to use windows as they normally would, but also, yknow, develop code. All I'm saying is, having a native way to mirror a filesystem while providing the expected semantics on both sides of the share seems like an important feature for these kinds of workflows.

I see your point, but only partially. Why can’t you write code on windows today? I can, for some/most projects. Why do you then want WSL?

Whether or not you can develop the code directly on a windows host is highly dependent on what kind of code you're writing, and what environment it's being deployed to. It's the recommended way to do virtualization these days on Windows, and if you develop using docker, you have to use WSL. Even in cross-platform interpreted languages like python, if you have third-party deps, not all of them are available on windows, nor do they always work there. Basically, if you're deploying to a linux server but developing on the windows host machine, it's not a question of "if", but "when" you'll run into a problem, etc etc etc. And this is just the "easy" case, where everything is theoretically cross-platform; when you start getting into things that involve proprietary compiler toolchains or specific hardware targets, you don't always have a choice what platform you work on at all.

Put more directly: I don't think any of my previous employers would have had a problem with me developing on a windows machine, as long as I was running the code in a virtualized environment that matched production. But it wouldn't have been acceptable at any of them to run the code directly on the host.

> Among the benefits of enabling mirrored networking in WSL are [...] the ability to connect to the WSL VM from the local area network (LAN)

This is already possible, I distinctly remember SSHing to my WSL by network.

On the host side you need to port forward from a non-static IP (`wsl hostname -I`) and deal with Windows Firewall. On the guest side you need to get sshd working (I use systemd, which comes with additional problems you need to deal with, e.g. systemd-binfmt config when running a Windows executable). It’s somewhat complicated and very poorly documented.

I always use wsl 1 instead of 2. One of the primary reasons is that you can directly control your network card from 1. So with the mirrored networking mode 2 is starting to look a little bit better.

One downside of that aspect of WSL1 is that you can’t get any network interface statistics at all. For instance I have a program running in WSL and I want to report network upload speed while it’s running, and WSL1 simply doesn’t expose that.

What do you mean by "control the network card"?

not an expert:

I believe WSL2 set up networking almost as a virtual client on a network local to your machine. Windows used NAT to direct traffic from Windows to WSL. The new changes allow more direct access to the network hardware instead of "virtualizing" (probably the wrong word) it

Wonder if it fixes this issue. https://github.com/microsoft/WSL/issues/8725

Or this one that makes WSL's clock fall out of sync after sleep or hibernate. https://github.com/microsoft/WSL/issues/10006

How is autoMemoryReclaim not the prime takeaway from this!?

I know we just use headlines here, but that is my single greatest gripe about using WSL day to day

Because Sparse VHD is (at least for me).

WSLg Window Snapping is without any doubt the biggest takeaway from this pre-release.

So this is WSL2 version 2.0.0?

WSL is pretty great. I wish macOS had something like this.

WSL is a Linux subsystem because Windows doesn't have a built in Unix flavor. On the other hand, macOS is a true Unix™ and has all these things built in.

If you specifically want to run a Linux variant (now if you are a true Unix user, you will likely compile from source or use binaries built for Darwin/macOS), you will resort to a VM which is similar to WSL. There are many ways to do this, including just installing Docker which will bring up a Linux VM for you.

It doesn’t have cgroups. That is the problem. I think if they implemented that it would be the ideal developer platform.

Docker / Podman for Windows is much better than macOS equivalents currently.

Sorry, but that's hogwash. There's nothing holding you back as a developer due to not having cgroups. Develop on the machine you are using - alternatively (not ideal, but some people do it), develop against a Docker instance. I would not recommend the latter though.

I don’t like installing things on the local machine like that as it doesn’t have parity with production and harder to manage. Containerization solves real problems in my world.

I mostly don’t miss wsl on Mac because most software I use works well in both Linux and Mac, just not windows. When I want to test something on linux from my Mac, I use and recommend Canonical’s multipass.

macOS doesn’t have support for cgroups / containers however, so you are stuck running a vm to achieve this. wsl runs a vm as well but requires much less care and attention.

It is odd because it seems that macOS should be able to provide a better Linux development experience but right now, Microsoft seems to care about this immensely more than Apple.

Apple cares about macOS and iOS developers, whereas Microsoft's tech stack is aimed at Web Developers to try to make the development experience with Azure seamless. Apple couldn't care less if your Node backend runs well on their machines

You are absolutely right. Everything flows from the business model which is completely rational.

I'd rather just run a Linux vm inside MacOS if I felt a desperate need to do so in an already Unix OS.

The missing feature is cgroups. If they had that, it would be nirvana. Right now there is no nirvana but Windows has the edge (for me) because they’ve implemented a much smoother vm experience with wsl2.

Does POSIX compliance over two decade count? If so macOS definitely have something like this.

I mean… https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem