174 comments

[ 5.0 ms ] story [ 111 ms ] thread
Despite the container support getting most of the attention, I discovered a measurable performance improvement with WSL3 by accident. Luckily I had another machine to upgrade so I ran an AB test comparing WSL 2 to WSL3 .

If you want a real bump in performance, I have a clever trick . Hardware isn’t cheap these days, so we demand the most of our software.

(comment deleted)
> If you want a real bump in performance, I have a clever trick . Hardware isn’t cheap these days, so we demand the most of our software.

Good trick: get rid of the superfluous Windows layer which stands between that expensive hardware and your target OS. It takes up valuable memory, CPU time and storage space, introduces latency where you don't want it, exfiltrates data to unknown destinations and can decide to "upgrade" itself without warning.

Good tricks need catchy names to succeed so how about NoSL?

"Arch btw" vibes
I get a lot of utility out of windows, the desktop, the browser, Hyper V , MS Excel, RDP, Windows Terminal, Visual Studio + VS Code. A dozen more great apps.

I came here to praise both Windows and Linux.

Great job in benchmarking! I wasn't even aware of the WSLc (WSL3) release. For others, the release info is available here: https://github.com/microsoft/WSL/releases/tag/3.0.1

EDIT: stumbled on the previous HN post here: https://news.ycombinator.com/item?id=49970507

That is quite relevant, and compose ability is on the way, or for some workloads Aspire would be an alternative I guess.

Unfortunately most companies are too cheap to pay for Docker Desktop, and having Windows containers depend on a third party tool has been a problem in such customers.

Because using Rancher Desktop or Podman isn't also a given, due to similar issues.

Is it accurate to call this WSL3? WSL 2 was released in 2019, but WSL 2.0.0 was released in 2023 https://github.com/microsoft/WSL/releases/tag/2.0.0
No I think it's more accurate to call it WSL Containers, or WSLc, but the release is indeed WSL 3.0.*.
It happens to be the major version reported by `wsl --version` on my system.

    NRR-WT1; wsl --version
    WSL version: 3.0.1.0
    Kernel version: 6.18.40.1-1
    WSLg version: 1.0.79
    MSRDC version: 1.2.7214
    Direct3D version: 1.611.1-81528511
    DXCore version: 10.0.26100.1-240331-1435.ge-release
    Windows version: 10.0.26300.9457
    NRR-WT1;
great to hear it thanks. I stumbled upon it on that HN article on containers, and since I’ve run doing other WSL benchmarks lately (testing kernel mitigations , which have a huge performance impact on the guest container), I re-ran those benchmarks on the upgrade.
And yet it's still factors faster without a whole Windows around it.
Unfortunately that acquisition option isn't available in most physical stores, where normies buy their computers, even though there isn't a single OEM not running some distro on their data centers.
You can get a refund for that useless Windows licence but that is a bridge too far for most "normies" whether they buy their computers in brick-and-mortar stores or online. If that process could be streamlined somehow..
Links to benchmarks?
Exactly. That's why there are in maximum benchmarks of current WSL comparing to older WSL releases just like in the announcement.
There’s always going to be a tradeoff with usability. Even on Linux you’ll run containers or VMs to prepare your developer environment (servers aren’t running Arch).

You’d be impressed by how fast WSL runs. I’ve got other optimizations on the blog for even more performance tuning with pretty massive 2x-5x gains.

While every few weeks we read about "some more factors performance improvements" we know how the current state looks like. Let's wait till we are talking about single digit percentage of improvements being worked on and newsworthy like the case in Linux-universe.
can you be more specific about your complaint?
ok great benchmark! I work with herdr/pi for dev work and need to use a windows machine from my company. WSL currently unfortunately lags so much when typing, not sure why when using herdr... Using powershell, some features are missing, so i can't wait to try WSL3 and hope for improvements.
I find that stuff that it offers over a normal Hyper-V VM is stuff that I don't need, leaky abstractions galore.
Well, you can use linux-tools on windows too. I kind of compiled most of LFS/BLFS on it, and it works. So it just gives you more options.
Nowadays I use it mostly for Linux containers.
how about the usability? for me it's 1 step to wsl --import and ~5 steps to setup the disk, networking, instance etc in Hyper V.

auto mounting host disks in the guest is very nice.

Also, I prefer the .wslconfig parameters e.g. for kernel params, networking, memory + cpu caps. It's very convenient.

Lot of the WSL2 lag is not the VM itself, it's the 9P file sharing and interop.

I found that seems like anything under /mnt/c goes through 9P

And yet I had results perfectly within the range of "good enough" having an ai harness muck about in a work folder in a docker mount on a 9P mapped drive under permanent observation by an intelliJ instance on the Windows side before some buggy Windows update made it occasionally lock up under `npm i` sized filesystem loads. Crazy how far we've come.
There is virtio support now, and to be fair 9P was never an issue for me.
9P is very slow for certain operations (such as, for example, git from either direction).

virtio is not enabled by default because its buggy in certain corner cases, and will be enabled by default when it stops doing that. That said, I do have that enabled, it is certainly faster.

Since nowadays I use WSL to run immutable containers, and not really classical Linux Desktop, it isn't something that bothers me.

Agents take more time than building Docker images.

You’re not supposed to work out of the /mnt/c. A lot of people make this mistake and then complain that WSL is slow. On the native linux file system WSL is 100x faster for everything
From the perspective of user empathy, wsl seems to be designed for that use case. but the implementation/defaults can be improved
On my work laptop I made the lazy/naive mistake of mounting my projects from macOS into devcontainers running in Colima.

vscode extensions using ripgrep in parallel in the background (there are many!) are killing the vm.

I now decided to follow Mitchell Hashimoto choice and use VMware Fusion and simply do all my work inside of it.

>You’re not supposed to work out of the /mnt/c.

Source?

Microsoft now launches a pop-up discourging this, so that is my source. Also my own personal experience using WSL for 8 years.
That's the entire appeal of WSL (for me). A single source checkout I can work on from both sides; no inconsistency of forgetting that I need to apply changes twice.

Without it, I can just as well ssh into another box.

Trust me, its not worth the performance cost. Just use git push and pull across the /mnt/c boundry
I do this on wsl1 without issue. wsl2 has an experimental new virtual (or just remote?) fs you can enable but I have not tested it.
I've generally found it better to do it other way around - keep all the stuff in Linux partition and from Windows side access that over the virtual network share \\wsl.localhost\<Distro>\home\me\whatever
I do not really follow how you would avoid this if you are using WSL containers with evdev containers. Wouldn't this be the default?
On top of the performance issue you mentioned, /mnt/c will be case-insensitive and trip up lots of Linux software!
> You’re not supposed to work out of the /mnt/c

That's why i need WSL: to deal with files Windows is not able to.

That feature is faster as well (using virtiofs instead of 9p), but i use the native VHDX IO for my work, which is adequately fast.
WSL2 is a different product from WSL1, not a different version. Is WSL3 now a different version of WSL2 or another separate product?
It's the same thing. Seems like the major version bump is to advertise WSLc, which is like Apple containers - an SDK for launching Linux containers as part of a Windows app.
I guess windows containers where dead on arrival?
Not dead on arrival, just extremely expensive on arrival for commercial/production use-cases, unless you're using Windows Containers on Azure.

They're missing things like winget as well, but that's mostly an inconvenience rather than a blocker.

Not dead, but they are ridiculously buggy. Much like WSL.
Windows Containers, owing to how NT itself is put together, are incredibly awkward to use. Container images have to go all the way down to smss.exe (the NT equivalent to init), which ties you to a particular kernel patch level.

Upgrade the container host? Re-bake your container images. It's a massive pain in the ass.

Yeah, I wasn't familiar with that (being all day working with Linux containers), and past week I found you cannot build images nor run Windows containers unless the host and the image match on the major Windows release. No backwards compatibility either.

So, for example, you cannot run a Windows 2019 container in a Windows 2025 host (nor the other way around). So, upgrading a base image means upgrading all the containers running in that host, and also the host itself.

Exactly, and there isn't really any backwards compatibility possible. Below csrss.exe on the stack, you really are wedded to a particular kernel patch level.

Linus found religion in a stable system call interface somewhere in the 2.4 series, and it's made the Linux container experience rather nice. Windows moves that particular kind of interface stability much, much further into userspace, and it makes the Windows Containers situation untenable.

I jumped ship from Windows a couple of years ago after having used it since the early 90's. One of the primary reasons was how much I had to fight with WSL2 in my day-to-day work. But now it's becoming even more apparent that Microsoft does not care about its operating system. I don't even know what they could do to get me back. Trust continues to be a huge problem in the AI era of Microsoft.
For me Win11 was the final stop.

I still use Win10 for a few things, including testing stuff works there too, via java. I switched to Linux in 2004 or so, though.

Did you work out of /mnt/c?
My problems weren't performance related, aside from the occasional catastrophic memory leak; most of my biggest headaches were related to networking.
They finally fixed the networking thing a while back.

In current WSL2, Windows owns the IP address, the NIC, DHCP, ARP, etc, and it’s shared with the Linux VM.

It’s really kinda magic… Linux sees the same IP address as windows does, and you actually get address-in-use errors if Linux tries to listen on a port Windows is already listening on, and vice-versa. So there’s no NAT going on or any internal 172.x net within the Linux VM, you just run “ip addr show” and you see the same real IP addresses that “ipconfig” shows you in windows.

(I no longer have a windows installation but WSL2 got noticeably better with networking some time before I gave up on windows.)

Not sure if related but you can adjust how WSL releases virtual memory back to windows which will lower your memory usage
I had the opposite experience.

I'm a hardcore Linux user, but it's a fact of life that laptops are not very well supported. There are some that are very compatible, but generally speaking, I need to trade off software (Linux compatibility) for hardware (laptop choice) or viceversa.

WSL allowed me to choose any laptop I want and run the subset of Linux that matters for me. For my use case (that is, not quickly accessing huge amounts of files, performance was ok - as a matter of fact, the author of the article got a very reasonable performance loss on realworld tasks (-4% ~ -16%).

The only thing that I found truly irritating is attaching USB storages, but I ended living with that.

I'm surprised to hear that about laptops. When I first switched to Linux in 2003, laptops were supposedly a somewhat iffy thing. When I got my first laptop in 2007, I had to do a bit of research, but ultimately ended up with a ThinkPad where everything worked fine, modulo the need for proprietary graphics drivers as was common at the time. Since then, I don't think I've ever stressed about whether a laptop would be properly supported. I am easily believe that maybe some things are a little better in Windows (maybe automatic firmware update, or the CPU governor), but which laptops are "not very well supported" by Linux these days?
Does Linux support hibernate or suspend well, 30 years after both technologies have been introduced?
Not even Windows hibernates or suspends reliably. Apple seems to be the only vendor that can get this right.
I've been using hibernate on Windows for the last... 15 years? And I don't remember ever having a problem. Lenovo and HP laptops.
It is easier to verify that there are no problems on Apple hardware. Windows and Linux run the same for me, you need good hardware to run well. Usabiltity and taste is a different question.
Hibernate and Suspend never worked well for me or my coworkers or relatives when we tried it on Windows.
I never understood the point of hibernate/suspend. Just turn off your laptop when you are done.
I don't know what "well" means, but I suspend my laptop whenever I move it around, travel, etc. I used hibernation a lot many years ago, where it worked as perfectly as I would expect.
Yes. The initial problem was ACPI tables in the BIOSes. They were wrong for benign (Windows doesn't care about them much, so the manufacturer was not aware that they are important), or not-so-benign (break them to break Linux compatibility on cheaper devices) reasons. Suspend and Hibernate work pretty flawlessly on higher end devices (i.e. Thinkpads, Pro/Elitebooks, Compaq NX series, etc.) for longer since these machines were designed as OS agnostic and had flawless BIOSes in terms of implementation w.r.t. consumer devices.

Remember, Halloween documents' opening salvo was the idea of extending ACPI so that Linux becomes unbootable on PC hardware.

Hibernation is the same deal. You also need to have a swap file/partition slightly larger than your RAM, since it's dumped to SWAP during hibernation.

So, why don't you come over here? We have cookies.

In the mid to 2000's at IBM, many of us developers and even quite a few regular business people in marketing ran Desktop Linux on Thinkpads, it worked extremely well. I assume they still do.
I never trust people saying "it works well". Heck, even Canonical lies in their certification program, since they may test with custom distros that they may not release (yeah, it's this crazy).

My last machine, according to reviewers, worked "well" on Linux. After I purchased it, I've found that the battery lasts half of what it lasts in Windows. And other stuff.

No doubt that there are 100% compatible machines (Thinkpads, typically), but again, it limits choice.

> I'm a hardcore Linux user, but it's a fact of life that laptops are not very well supported.

No, that isn't a fact at all. I use Dell laptops and have run Desktop Linux on them (Ubuntu past years and more recent switched to Kubuntu) and all of the hardware has worked well, even for gaming, even for my laptop with nVidia built in.

Dell, having one of the most popular engineering laptops of the past decade (xps). It's not surprising that it would have better than average support.
Yeah, WSL was the gateway to daily driving for me. I'd played with Linux as a kid, came back via WSL, and quickly came to the conclusion I'd be best off without Windows.

Haven't regretted it for a second.

I did the same, fighting WSL constantly with some other random conflicting stuff. Moved to Ubuntu and honestly things just work. _Maybe_ 2026/27 will finally be the year of linux desktop.
WSL is one of the few good ideas Microsoft had in the last ... 5000 years or so.
Typescript, vscode, LSP, powershell, kernel subsystems, the HAL, C#, F#, DirectX, side-by-side libraries, a VMM that fucking works. Exchange, SQL Server. Great hardware.

It's a crappy company, like all corporate giants. It has a lot of crappy products. But the case is usually overstated.

Even going back 10 some good ones

* Windows Terminal

* Powershell 7

* Including OpenSSH client + server with windows

* the Visual Studio command line build toolset distribution

* Hyper V and bundling it with Windows Pro

* RDP

* MS Edge (basing on chromium, same extensions, same dev platform)

Amazing they managed to make virtualisation that slow in WSL2
I am not sure about WSL in general right now - no matter if WSL3 is more performant.

For me, Claude bypassed my sudo security by executing `wsl.exe -u root`. The Claude does not need any sudo password :)

You need to start Claude in WSL, not from outside in Windows. Windows user has complete ownership over the WSL it launches
The funny thing is: I launched it from within WSL. But it can call wsl.exe -u root from within WSL.

I was very surprised this works, but that was Claude’s solution to editing a config file that needs sudo access without knowing the password (it edited /etc/fstab)

Isn't this just WSL2 v3?
I’ve never been good at marketing. And that was tongue tying
Not sure what tonym thinks is being tested.

Craig Loewen (MS product manager for WSL) on X stated :

>As a PSA, there is no such thing as WSL 3! I've seen some articles talking about it, and it's not currently a thing. >

>However we did just announce WSL container (Or WSLc for short which might be where the confusion is coming from) and that will be available in just a week or so!

syscall/basic getppid() throughput 1,474,691 ops/s 1,533,399 ops/s +3.98% Entry/exit latency 0.6781 µs/op 0.6521 µs/op -3.83% sched/pipe 100k process ping-pong 48,445 ops/s 54,589 ops/s +12.68% Context switch latency 20.64 µs/op 18.32 µs/op -11.25% sched/messaging Hackbench (20 groups, 800 tasks) 14.507 s 13.047 s -10.06% mem/memcpy glibc default bandwidth (1GB) 7.84 GB/s 12.64 GB/s +61.35%

This is great, this is some good work. But, like an issue I described before with Linux kernel io-uring[1], this fails to test and demonstrate performance with a healthy server load.

This obviously fails to depict a healthy server load because it's just way too specific.

1.https://news.ycombinator.com/item?id=44604793

You're not wrong, it's a synthetic test. I went with this suite to AB test other WSL kernel flag changes, and used it for testing 2.x vs 3.x when I noticed my builds seemed a lot faster with the upgrade.

There are probably better benchmarks.

Microsoft still refuses to fix the most obvious issue here - Windows should be rebuilt on top of a linux kernel.
As someone develops for both systems, I would argue doing the opposite is better from the OS design perspective. NT has a much better paradigm than Linux or any POSIX-system. We should move away from POSIX in the age of AIs. The OS should be more granular in its permission handling to its core. NT can do this. Linux requires a complete rethinking and rewrite to have this in the syscall layer. Current extensions like SELinux are hacks. Something like seL4 should be the basis of future OSes. NT is simply closer to that.
> NT has a much better paradigm than Linux or any POSIX-system.

I am not sure what you are smoking, but that thing must be good.

Regardless whatever I'm smoking, nothing surpasses the highs of the dogma :)
My memory is a bit foggy, but the original WSL promised a much more ambitious integration with Windows, sort of container-like. It had a lot of rough edges when I first tried it, but they promised they'd work on it. That, together with their promise that W10 would be the 'last' Windows and they'd switch to a more OSX-style rolling release model was what pushed me to adopt Windows in ~2016. In the first years of Nadella it really felt like MS would listen to developers. Within less than two years iirc they'd given up on the WSL ambition, with WSL2 being a mere VM with noticeably worse performance for some of my workloads, and completely reneged on their W10 promise, even vowing to make my newly purchased hardware obsolete.

In summary, I really couldn't care less what improvements they make to WSL, and neither should anyone else, imho. If you want Linux, for the love of god just use Linux. Emulation works great the other way round by now.

Do you run your workloads on Windows partitions/filesystem but using WSL2 as the runner? That's how you end up with abysmal performance.

We tested this in the office with equal laptops. CPU workloads have almost no VM overhead and the C++ / Rust compilation workloads on purely WSL2 virtual disk image is only 2% slower.

Yes WSL1 was more ambitious but the fundamental differences in the NT and POSIX makes it quite hard and CPU workloads suffered.

Yes, I don't remember what it was, probably something with file sync, but I remember I kept a WSL1 instance for some stuff for a long time. Rust tooling worked great in WSL2, as long as you stay inside the VM, can confirm.
MS Office is notoriously resistant to running in Wine (haven't tried it myself) and, with all love to LubreOffuce, it's clearly the poor relation.

I've usually been able to get windows software running, but it's not always easy. I borrow my wife's laptop to reprogram my gaming mouse, for example. Couldn't be bothered any longer to dick about with wine.

But this is slightly beside the point: many have to use the allotted machines at work, which will tend to be windows (or maybe mac). That's the audience for WSL. It is an escape hatch for wage slaves.

The original WSL translated syscalls. It was a very tight integration. It was not perfect, and i should think it was a massive ongoing effort. I think it's an elegant approach bit i can see why wsl2 is essentially a vm. I never did any benchmarking, but i suspect that what wsl2 loses in disk performance, it gains in kernel performance. I never found either variant slow, and my corporate laptop was shit. My vagrant stack was diabolically slow, though.

I have no problem with WSL2 being a VM of sorts if thet at least had VirtualBox of 2010 vintage features like properly integrating USB devices, not whatever this usbipd crap is, or a window manager that doesn’t inexplicably die and require a full machine restart.
I'll agree WSL1 was more of a commitment to Windows Kernel. but I've found WSL2 performance to be great unless the plan9 filesystem is used.

and I am using linux. When I execute code, it's executing via the Linux kernel, on the cpu . This is not an emulator . Intel has had hardware virtualization for ~ 25 years or more.

Are majority of the perf gains really from tuning from the kernel's `page_reporting_order` param?
i think the 6.18 kernel scheduler contributes most of the gains, but it's hard to distinguish which improvements led to the biggest gains. also the clock change (no longer context switching to the host to sync the clock)
Interesting, hacker News has truly become the new slashdot :)
I love WSL, but giving this a major upgrade label (2 to 3) seems a bit of a stretch, at least from the viewpoint of an average dev user.

Perhaps it reflects the amount of work and thought that has gone into it, but I really think the optics are better if the selling points are immediately obvious to the user.

Hopefully some light will be shed in further blogs.

Especially given 1 -> 2 was a complete rewrite that changed the entire architecture to the extent that there are still reasons to run WSL 1 in some cases. Talking of which, the one thing I'd be excited about (if I ever expected to do any dev on Windows again, which I don't) would be a way of sharing local storage between Windows and Linux processes without incurring a massive slowdown on one side, which WSL 1 achieves, but it doesn't sound like this has that. (Or does it?)
I think MS is calling it Wsl2 still (3.x series) . Let’s see if they shift the naming like MacOS did with the numbering. (It was 10.x for the longest time then they ditched it)
I moved to Linux from WSL2. It works surprisingly well today as a desktop OS (using it since ~1992 on servers, 20 years of OS Macs before Windows on desktop). And it looks to be perfect for AI - Claude did build and test a noise gate mic pipeline easily because every config is in plain text files.
I love Linux and use it for everything except my desktop for 20+ years now. Too many times even in the past I do an update the distro and then something stops working and then I have to spend a day fixing. Last time (6mo ago) it was my sound card. Small little annoyances that steal hours of productivity. LTS was going good until I wanted to update to the next LTS then the can of worms gets opened. It’s fantastic when it’s fresh and everything works and you can blow it away easily and reinstall. I’ve never found upgrading packages to be reliable long term without eventually having to do some manually recovery or reinstall OS
"my sound card."

Yes, for me today though this is usually fixed in 5min by Claude.

I moved to Linux 8 months ago because of how crappy windows 11 has become. One of the things I loved about windows was developing on it, WSL2 was great and I loved just having VS Code connect to it and it’s my own little dev box.

I’ve really enjoyed the switch so far, having attempted it a few times in the past and ended up going back to windows (once in 2003, another in 2012). It’s encouraging to see MS continue to get the developer experience right with improvements like this, but unless they make significant improvements to the OS itself, I won’t be going back.

After many years of failed switching attempts, I finally made the move to CachyOS 2 months ago. Windows 11 updates constantly force-feeding copilot and not letting me shut down my system without updating is what finally pushed me to give it another honest go.

I want to caution people though because I see posts like this all the time, but nobody mentions just how tough it is to mimic the "polished" look and feel of Windows in Linux. Even getting it installed in a dual-boot setup was an absolute nightmare. If it had not been for Claude, there's no honest way I could have made this transition. It would have ended just like all my other previous attempts: going back to windows.

Here's a list of issues I documented along the way (with many more that I didn't document), some of them resolved with other methods (I game on Windows VM with GPU Passthrough now) and some I live with:

- Not able to choose same display resolution as Windows, especially when mirroring my laptop to my monitor. Most offered resolutions are too slow or too blurry with text also.

- Having to force browsers to use my dedicated nvidia GPU instead of the Intel one, rendering simple web games in browsers is still choppy even with this solution.

- Choppy games (RDRD2, Last of us 1 and 2) when using Proton/Lutris/Wine despite 3080 GPU (these games run smooth in Windows). Kind of expected this...

- Blocky artifacts showing up in most games (tried multiple drivers and Proton flavors)

- Have to disable secure boot in BIOS for some reason otherwise bootloader doesn't work

- Come up with hacky solutions to not get prompted for root password every time I connect a removable drive that is Bitlocker Encrypted

- For some reason when shutting down/rebooting, my CPU fan just stops cold turkey and it makes a "thud" noise. I've found no resolution and it only happens with linux.

- I can't control where applications on my taskbar live. If I place a pin in the middle and click it, the app launches a separate instance at the far end of the taskbar. Tried different sort options, no fix. Some apps work fine, others don't.

- Can't click shutdown/reboot when screen is locked. Need to click "Switch User" first.

If you want a polished OS look thats closeish to Windows I cannot recommend KDE enough.
I setup a new main PC (Nvidia GPU) with Arch and GNOME a couple of years ago and had quite a few problems. I switched to KDE and have had almost 0 problems for day-to-day work and gaming. Every once in a while I’ll run into an issue with running a game that I can usually resolve pretty easily with AI. It seems the work Valve has done with KDE and Proton has really added a lot of polish to the experience; I’ve always preferred Linux over Windows but now the tradeoffs for me are almost non-existent.
This is absolutely true, as was my experience as well, it did take quite a bit of work to get something as functional as windows setup.

I went with Arch and wanted to take a few days to actually go through the Wiki and setup something completely from scratch and learn along the way. I had my laptop next to me and AI was a huge help. I went with Hyprland(Fish for shell, Kitty for terminal, Ashell for my bar, Walker for launcher, Yazi for explorer) and tried installing a bunch of pre-made .config files, but that was a big mistake, just take the time and get everything setup yourself, it's worth it in the long run to learn how all this works under the hood.

I think it's important to point out that my switch was also motivated by a desire to learn about the guts of a linux system and not just go with Ubuntu or a ready made one. I run Ubuntu on a home server and it runs great, but I am a full blown Arch snob now and I could never daily drive it.

Which distro did you switch to?
Arch, I took a few days and just did the full walk through from the Arch Wiki (there is a streamlined install process someone made[1]). I had my laptop next to me and AI was a huge help, but I learned a ton doing it and it was satisfying booting into a graphical interface for the first time!

[1] : https://wiki.archlinux.org/title/Archinstall

What made a significant jump from WSL2 to WSL3?

Unless I'm mistaken, WSL to WSL2 was massive change in complete architecture, with WSL2 now requiring virtualization and making your host-OS run on top of hypervisor, with potential tradeoffs not many users are typically aware of. Basically, WSL and WSL2 were different beasts entirely :)

Was there anything that big or note-worthy from WSL2 to WSL3? Or just a natural evolution/upgrade?

WSL3 is the app version. The underlying mechanism of how Windows runs Linux hasn't changed. The change from WSL to WSL2 was in that mechanism (WSL: run via syscall translation, WSL2: run via VM). This is an app change, so it covers the interfaces of how you can start running Linux code, but underneath the hood, it's still a kernel running within a VM.

The big addition here is the support for containers. The app now provides a simple way to run containers directly. Underneath the hood, there's still a kernel running on a VM, though. There's also some improvements to the filesystem layer, a kernel upgrade, etc.

This article[0] does a nice job explaining it.

[0] https://zenn.dev/yohakucode/articles/wsl3-wsl2-wslc-update

I had to speculate using the changelog, since MS hasn’t released performance tests . Kernel 6.18 has a better scheduler and other refinements. WSL3 improved the clock routines to use a synthetic clock. There are quite a few others.

virtiofs is the biggest change, it was experimental in 2.x. It doesn’t affect my application, but most new users who want to share files between windows + Linux will see a huge bump.

Following some of the comments about switching to linux the big one that enabled it for me is AI. I love to thinker, but sometimes I just want things to work and linux is known for very minor inconveniences that are pain to alter because you have to learn what kind of god forsaken build system the application uses and how it integrates with the desktop environment, but now I can just ask AI and it will be fixed by the time I want to use that feature.

Another big thing is getting lookingglass working. I could not for the life of me figure out what I was doing wrong when I followed the setup guide 1 line at a time, but AI figured out the problem and it it working in 1 hour. And yes it took AI one hour to figure it out so you can assume how long I've sent trying to get this to work.

Now I run a custom kernel with custom KDE and several compiled new packages which would require the effort of a small team, but now it's possible to do with few prompts and it's relatively easy to maintain indefinitely.

Also AI got me off jetbrains onto nvim and I haven't been this happy writing code.

Same experience here. I've dabbled with Linux Desktop in the past but always backed out once I encountered the rough edges. Just because everything is fixable doesn't mean I want to spend a couple of hours on each of the 100 paper cuts. It adds up over time and feels never-ending.

But now, I just open Claude Code and say "this is bothering me" and it runs in the background while I complete other tasks. I get it to document anything it changes and push my custom configs into a private git repo along with my dot files.

In some sense, I'm starting to see Linux almost like a Smalltalk image. Anything permanent is backed up to git and I have documented recipes to go from fresh-install to custom environment in a couple of hours.

There are still a lot of rough edges all over the place but it is a totally workable environment.

Everytime my system updated my flat pack and Nvidia drivers get out of sync. Claude easily fixes it.

A recent update crashed in the middle and left me running an incorrect kernel for my GPU drivers, if I had of rebooted I'd have been hosed. Thankfully Claude caught it before that happened (steam games refused to run) and fixed me up.

In related news - not a fan of flat pack.

In my update notes I have a warning to always do a btrfs snapshot before a system update. And my system update warns me when kernel changes (since that usually requires new drivers for Nvidia). And to wait after flatpak updates for the driver to finish compiling (since apparently the flatpak installer exits as done before the background akmods compilation finishes)

So, yeah, I feel that pain. So far I've been careful and/or lucky.

Maybe Fedora Atomic (or another atomic) would be a good solution for you. I have an old MacBook Air that needs out-of-tree and closed-source WiFi and webcam drivers, and with Fedora Atomic it won’t update the system if it can’t get them compiled in first. Then, if it did and there was still some issue, I could roll the whole system back to the previous working state all at once.