Initial Impressions of WSL 2 | Hacker News Reader

Initial Impressions of WSL 2

daverupert.com

154 pointslelf230 comments

No free lunch, of course. Faster file access with WSL2 (vs WSL1), if you stay in the Linux world. But if you point it at Windows files (/mnt/c, etc), it's pretty slow.

WSL2 just moved the slowness from one side to the other. Accessing the Linux FS from Windows (\\wsl$\) is also slow.

That said, I am a fan, and get a lot of use out of WSL1. Since I don't use the Windows interop much, WSL2 should be a performance win for me.

Yep.

With WSL I can seamlessly access files from both Linux and Windows. I use the Terminal (Windows) and various Unix tools for a lot of stuff (compiling & testing on Posix, objdump, debugging). And I use Windows GUI tools for editing (Sublime), diffing (BeyondCompare), and so on. I get the best of both worlds.

But WSL2 file access in `/mnt/c/` is now unbearably slow. So I just stick with WSL1.

From what I've read, Microsoft intends to support both WSL1 and WSL2 for the foreseeable future. So that's good.

"Microsoft intends to support both WSL1 and WSL2"

I'm not sure I believe them. Maintaining a whole tricky "fake" kernel/translation shim must be a lot of work.

You never know but as has been pointed out in different parts of this post, they have two different use cases in a sense. Windows developers who were using WSL1 aren't going to like the changes and i've heard a lot of complaints. However, people using primarily linux with windows as a nice shell with good hardware support and games are going to prefer WSL2. I think if they want to win over the biggest group of devs, and I feel pretty good about that since they were losing traction with them for years, they will maintain both, at least for a good while.

FreeBSD has a similar syscall translation layer (and has had it for over 20 years). They do it with a team of part-time volunteers. This is enough to maintain basic support, but FreeBSD still lack support for newer Linux syscalls which prevent things like the Linux binary version of Chrome from running on FreeBSD.

Yes, but translating syscalls across two Unix like systems is likely much easier. Big parts of it even just straight mapping one number to another.

This is somewhat true, but not entirely. You have to remember that FreeBSD and Linux share no common ancestors, and FreeBSD defines its ABI at the libc level, whereas Linux defines it at the syscall level. There are also subtle differences in how various internal kernel mechanisms work (such as flag definitions for calls). See linux_common_open() for an example of an "easy" straight mapping. https://github.com/freebsd/freebsd/blob/68a4c41e983228d54619...

This is true even between OSes that share a common ancestor. I was the maintainer of FreeBSD/alpha, and did the compat layer for OSF/1 / DEC UNIX / Tru64 starting with NetBSD's version and adding new calls, etc. The very easiest calls were the simple ones that both inherited from 4.3BSD or earlier (read, write). Medium were things that had diverged in different ways (stat, mmap), and for me the harder things were ABI handlers for the OSF/1 executable format (ecoff).

The hardest stuff was things at almost worked, except for maybe one flag was different, and it was hard to notice because an OSF/1 program would run for 5 minutes, and then coredump.

That's a great rundown. I didn't mean to oversimplify the effort. Just to say that mapping Linux to Windows is likely much harder.

The lseek() call in your link is closer to what I meant by simple.

> FreeBSD defines its ABI at the libc level, whereas Linux defines it at the syscall level

Actually, this really does make it more impressive than I'd realized, especially since FreeBSD didn't just shim libc in - I've run an Alpine Linux (musl-based) chroot on FreeBSD and that worked, which it wouldn't have if they just made a glibc-like wrapper. (I think.)

> I'm not sure I believe them.

I'm not sure why anyone should. They literally say "We currently have no plans to deprecate WSL 1" while simultaneously claiming "We are committed to making WSL 2 feel the same as WSL 1". There's no way their goal is to reach a steady state where they feel the same and yet both have to be maintained. Making them feel the same is literally what you do when your goal is to stop support for one of them. They probably just haven't "planned" it yet, unless they don't expect they will actually ever get them to feel the same.

I watched Aaron Patterson's keynote from RailsConf 2020 (these talks all just came out this week, Couch Edition) and I'm struck when reading your comment that it's absolutely possible to do this, and ultimately you may or may not reach a state where it's possible to "end-of-life" one or the other alternative without making anyone cry about it.

He spends most of the second half of the talk explaining (with a profiler) how two query implementations on ActiveRecord which should be doing pretty much about the same thing, actually perform wildly differently, and narrowing it down with data to understand why.

The talk is really interesting and I think it's a parallel to the current discussion in a way because, in Aaron's talk there were two implementations and one was obviously better performing (but unfortunately it was the one that is harder to write.) He argued mostly that, unless there is a reason for these two implementations to behave and perform differently, the one that is slower (but easier to write) should become more like the one that is "enhanced with a performance pro-tip" that arguably the ActiveRecord user shouldn't really need to know about. In other words, that the bad performance was actually a bug.

(tl;dr: the pro-tip is, to build your own pre-sanitized SQL WHERE clause strings, because you may save something like 38% performance in a pathological case, recovered time that the SQL engine was going to spend traversing AST and compiling.)

My point is that, exactly. If there is bad performance over here, it is a bug. Bad performance over there, bug. But bad performance over here, that can only be solved by swapping for bad performance over there?

This does not sound like a bug anymore, it starts to sound more decidedly like a trade-off. But given enough time, perhaps they will fix the bugs, and the two can be made to perform similarly, fixing bugs on either side, and the need for two alternatives will go away. So why would that be bad?

(And if it can't be done, or can't be done yet, why wouldn't we expect to see both implementations maintained as long as needed to find a solution that pareto-dominates them both?)

> But given enough time, perhaps they will fix the bugs, and the two can be made to perform similarly, fixing bugs on either side, and the need for two alternatives will go away. So why would that be bad?

Because (possibly unlike with your Rails example?) the suggestion that this is possible to do by improving the VM side is, to be blunt, a lie. A VM is a fundamentally leaky abstraction, in far more ways than just the timing behavior (i.e. performance), and the need for both won't go away by just "fixing" the VM side. It's literally impossible for them to ever make a VM "feel the same" as WSL1. To give you a taste: My "feel" was that I wouldn't have to deal with all the VHD/disk/partition/volume management I was so happy to finally get away from. My "feel" for WSL1 was that I could compress its files with the WoF LZX compression in Windows 10 to save a ton of disk space and yet still read them with native Windows tools as if nothing was different about them. My "feel" for WSL1 was that I could actually read and even move Linux files around directly from inside Windows as long as WSL1 wasn't running, treating a WSL folder just like a regular folder. My "feel" was that I could even use Windows tools to alter these files as long as I maintained the Linux attributes correctly.

And my "feel" was that using WSL would have zero impact on any VM technologies that I may or may not want to use, but that's another can of worms.

I could go on, but hopefully you get the point. Either you have to dismiss my "feel" for being somehow "invalid" to your liking, or you have to realize you'll never get the same feel.

> My point is that, exactly. If there is bad performance over here, it is a bug. Bad performance over there, bug. But bad performance over here, that can only be solved by swapping for bad performance over there? This does not sound like a bug anymore, it starts to sound more decidedly like a trade-off.

Only if you assume "only solve X via Y" is correct. I don't believe that's true. I believe they just haven't put in the required work yet, and that if they did put in the work, they could still improve WSL1 substantially. The real reason for why they haven't done so is anyone's guess, but to me, there are multiple signs (not just I/O-performance-related) that suggest the WSL team has to do most of their work independently and can't necessarily get sufficient cooperation from the teams working on different subsystems, and hence this is why they've been unable to improve things. Or maybe the folks who can work on the required parts are no longer available. Regardless of the reason though, I don't believe they've reached the limits of the technology yet.

> Because (possibly unlike with your Rails example?) the suggestion that this is possible to do by improving the VM side is, to be blunt, a lie. A VM is a fundamentally leaky abstraction, in far more ways than just the timing behavior (i.e. performance), and they need for both won't go away by just "fixing" the VM side.

The fun part about my example is actually that he saw a 60% performance difference, but only recovered 38% of that by fixing the one bug that was exposed in the talk.

It was decidedly a bug. Refusing to cop out and say "it's a necessary evil, and can't be fixed" got him that 38% boost in one shot. The remaining ~22% is still a problem that has yet to be explained completely, but now it's not as big (or soon won't be, when they resolve the issues created by fixing the bug, which AIUI it couldn't be merged yet...)

I do get your point, and I grok that parts of this problem simply can't be fixed outright. But from my perspective, the bug isn't that WSL2 is missing features of WSL1, it's that WSL1 performs 60% slower for my use cases (*not an actual measurement) while doing what appears to be, at least from my perspective, basically what is meant to be the same task. I don't really know why, except by what some greater experts have shared, some of that which I have acquired by osmosis.

Your use cases are valid, and we mostly agree, when you say the limits of the technology have not been reached, it seems like we're both arguing that there are simply more bugs yet.

Sure. But I don't completely see the point. "bugs" you don't own are the worst bugs because you have no say on when or if they are getting fixed. I deal with such things on a fairly regular basis - our RDBMS (SQL Server) acting in pathological ways and when I look into it, people have been complaining about this stuff for a decade.

Ultimately, the software creator determines what is and isn't a bug - formally through what they label them as, but effectively through how they act upon the behavior. As an end user of a system, things like the above are less like bugs, and more like features.

Why not just store files in WSL home directory? It's faster than accessing from mnt/c

Well it depends on your use case. If you're using WSL to develop web apps then storing it all in WSL is fine, but if you want to use Linux tools to process a load of files in your Windows drive then it's not quite as smooth sailing...

Check out VS Code. It can now read and edit files inside of WSL remotely [1]. I've been using it on a new project and it works almost seamlessly * . I don't know if other editors will get this functionality, but there's really no need now for me to save files in /mnt/c.

[1] https://code.visualstudio.com/docs/remote/wsl

* One curious effect is you can't move folders from VS Code due to permissions. So I have to close it and use Windows Terminal for that, but moving folders doesn't happen too often.

Couldn't you do the reverse now with WSL 2?

The files would live in WSL 2 directly, but then you access them over Windows through the WSL network path?

I don't have insiders installed so I don't know how slow that would be. Like if you CTRL+p'd in Sublime Text, would it have to grab a list of files from over the network on every call, or does it cache these files locally on a per ST session basis, etc..

There's also maybe the option of running ST natively in WSL 2 and expose its GUI over an X-server. I know latency there is very good (near native) because I've done it in the past. This also gives you the added advantage of ST being able to know about your Linux environment which could be nice for linting and other things that require having your programming runtime installed in the same place as your editor.

You can still have shortcuts too in Windows, for pinning stuff to your taskbar or having right click menus. I do this with Vim now with WSL 1, where I have a custom "open with Vim" right click menu in explorer that opens terminal / native Linux Vim that's installed in WSL.

I'm sure I'm missing something but I don't get this problem with filesystem access performance. It seems the obvious way to do this was to have SMB mounts on either side and optimize the hell out of the already existing SMB implementations on both OSes to get the performance close enough to disk. Maybe have a dedicated virtual network interface exposed only to the VMs and not to the LAN to avoid security issues.

It probably wouldn't get exactly up to native high-end SSD performance but I'd wager you can get it close enough that people wouldn't care.

Meanwhile, try to do a "git status" right now in Linux in WSL2 on a sizable repo in your /mnt/c and feel yourself slowly die inside.

It seems like a bunch of people thought it would be a great science project to write custom kernel drivers for Linux and Windows and learn some stuff along the way. So now they're stuck supporting two complicated software implementations for god knows how long, because neither of them does the job on its own.

Like I said, I'm probably missing something. I'm a network guy, so maybe to me everything can be solved by the network stack.

(edited last line)

Great question. They do have an in-depth blog post of how it works for WSL1: https://docs.microsoft.com/en-us/archive/blogs/wsl/wsl-file-...

Though it doesn't mention why they didn't try what you suggested.

The actual I/O doesn't seem so bad...like writing to a single file. It's things you mention, that create or modify lots of files (git clone, for example) that are really slow.

Edit: Apparently, the Windows side \\wsl$\ access does do what you're suggesting, sort of: https://devblogs.microsoft.com/commandline/a-deep-dive-into-...

It's using a 9P network file server, derived from plan9.

I'm not really using wsl in anger (work laptop runs Linux, with a win 10 vm in virtualbox for the occasional nearly windows program; mostly the odd proprietary vpn; Citrix and occasionally rdp - although remmina on Ubuntu 18.04 mostly works fine) - but I've toyed with the idea of testing smb/cifs and nfs both ways - to see if it isn't good enough for a git checkout the size of the Linux kernel (Ditto a build/compile of same - although I'd normally mount a ramdisk for that, if I really wanted to speed things along).

Both windows and Linux should be fine with home on cifs.

SMB to/from a linux VM is pretty slow, I've spent time trying to optimize it. The performance hits bottlenecks in a few places including (if enabled) transport encryption. You'll have similar problems if you try to shuffle a few gigs across an ssh tunnel locally too (if you're sufficiently clever and willing to wield a compiler in anger, you can disable transport encryption entirely for a nice speed boost).

For reference I had a situation where I needed to pull/push 1-2gb blobs across the VM boundary on a regular basis, so it ended up mattering a lot - sub-1-minute times vs 5-10 minute copies.

I really don’t understand why they disable the NULL cipher. If I want to take the risk and transfer data cleartext over my LAN I don’t see why I need to custom compile ssh/scp to do so (and miss out on security updates since its no longer a tracked package).

I still want my auth credentials encrypted so no telnet and other older tools are not a replacement.

> It seems the obvious way to do this was to have SMB mounts on either side and optimize the hell out of the already existing SMB implementations on both OSes to get the performance close enough to disk.

That's basically what they're doing, only that it's not SMB but 9p protocol servers.

Here is a video where they discuss the WSL2 architecture. The link is time-stamped to go to an overview picture of the architecture.

https://www.youtube.com/watch?v=lwhMThePdIo&t=2435

exactly this is the problem.

As the article says

>To get the full benefit of WSL 2, you’ll also want to move your project files from /mnt/c/Users/<username>/ over to your new ~/ Linux home directory on your new VHD. You can see the contents of this drive on the Network by going to \\wsl$\<distro name>\<username>\home or typing the command explorer.exe . from your bash prompt.

>This is your Linux filesystem and it acts and behaves as you’d expect. I made a folder called ~/projects that has all my project repos and then I open those projects in VS Code using the code . command.

i have accidentally wiped my home directory on Ubuntu VM reinstall. I cant even backup it up easily.

WSL engineers need to figure out a way to make the Linux home directory to be persistent. If we are living in the docker world, this is a solved problem - docker volumes live separately to the docker VM itself.

WSL2 needs to do something like that.

Git? All of my work is backed up to git, even my dot files and config is there. For me, I try to keep my WSL "stateless" and never store anything there unless it's a copy of something.

im running a postgresql database, building docker containers, etc etc.

this is a problem that needs a "docker volume" solution. git is just not enough.

think in terms of people moving to Windows from Linux.

> i have accidentally wiped my home directory on Ubuntu VM reinstall. I cant even backup it up easily.

Normally, it'd live on an nfs mount, or a cifs share.

If you're stuck with VMs for some reason, setting up a dedicated storage appliance would probably be the way to go.

Or it will live inside my linux dual boot...where it should.

If WSL wants me to migrate to Windows...they should fix this.

You could alway try your luck with shared windows/Linux home on zfs...

I must say WSL2 has genuinely been huge for me, to the point where I've finally been able to ditch macOS for a desktop with a Ryzen CPU.

Honestly it's mindblowing how far Windows has come - if I were Apple I'd genuinely be scared of losing a large proportion of power-users as Windows becomes an increasingly viable platform for development.

How does it compare to real Linux distributions? Does it have a package manager? Is it like Debian? What are the limitations?

It is a real Debian (or, by default, Ubuntu). Original packages from Debian's servers are used. You're using apt, as usual.

WSL2 is a full blown emulator / virtualization solution, so it runs a real linux kernel / distribution. The largest downside to me is no gpu passthrough from the host.

You can even compile your own custom kernel for it. I've had to do so in order to run some modules that the WSL 2 kernel currently doesn't have.

They say GPU passthrough is on the backlog in their post build FAQ. https://devblogs.microsoft.com/commandline/wsl-2-post-build-...

I've been tracking that. Almost certainly AMD exclusive since, AFAIK, NVIDIA prohibits GPU passthrough on their consumer cards so VPNs are forced into purchasing 'professional' grade GPUs.

It is an actual linux distribution. The default is Ubuntu but there are others (Suse, Alpine...)

WSL gives you a full Linux distro. You can use Debian, Fedora, Ubuntu, from the top of my head. These are default options. There are others available. Additionally, you can bootstrap to other distros. I know Arch was an early target.

WSL1 replaced the init process. For Ubuntu, at least, snaps were not enabled, at least out of the box. There were occasional issues early on where the syscall translation was not perfect. For me, at least, these were all ironed out after a few revisions. Unsure if there were still edges I didn't hit.

WSL2 takes advantage of virtualization technology, so should be an even better Linux experience.

There were 4 "standard" distros in the Microsoft store IIRC

Just double checked in a Windows VM. These are available when searching WSL in the Microsoft Store. Some of these are for a fee. There are also a few results for terminal emulators and an X server.

- Ubuntu (18.04 and 20.04)

- Kali

- Debian

- Fedora (remix for WSL)

- openSUSE-Leap-15

- SUSE Linux Enterprise

- Alpine

- Pengwin (Debian-based and apparently optimized for WSL, and an enterprise version)

- Centos (7 and 8.1)

You can run various Debian distros. It works like it should. You can run an x server and get a GUI as well.

It sounds fancy but it's just a VM with a bit more polished Windows integration.

Hm, okay. That doesn't sound impressive anymore.

No, but the good news is you can literally run Arch, Debian and Fedora on the same machine with shared files.

That sounds good.

How does it handle case-sensitivity?

You could already do that with WSL1.

Source: I have Arch and Ubuntu on WSL1.

Those didn't change. Other things did.

They didn't say that something changed.

But I'm intrigued, what did change?

I/O performance characteristics changed, your ability to share the same filesystem for both OSes changed, etc.

WSL2 uses a VM while WSL1 uses a Linux like interface over a system-call DLL.

WSL2 sounds like a step back.

Their other choice was to make Windows file IO actually fast.

That just wasn't going to happen.

WSL1 managed to corrupt SQLite dbs. Which is really annoying, and does not happen with WSL2.

My (casual, not work) use relies heavily on Nix, which is built around a centralized SQLite file. I did not enjoy that experience.

Wow, that's amazing/terrible. Would you have a link to a repro?

I think this is the relevant bug: https://github.com/Microsoft/WSL/issues/2395

WSL2 has been great so far (I’ve been using it for a few months now with no serious issues).

Thanks!

Thanks, this perfectly explains a weird error I have been seeing!

Thanks for that, I have hit this bug once with WSL1 in the past and didn't think much of it at the time. Good to know what caused the issue.

Systemd is not working.

I'm using full ubuntu in it. The only real pain is anything that relies on systemd (which comes up unsurprisingly often).

I've also switched from Mac to a Ryzen desktop. So far the experience has been extremely good and performance is amazing. Been working with clojure and react native on WSL2 several months now.

I didn't want it to be this way though. Apple has been continuously pushing out laptops that are not what I want. My Mac is also notifying me nonstop about 2FA authentication and iCloud storage, and I can't seem to turn those off. I used to eagerly await their keynote events to see what cutting edge innovations they will announce. There have been none I care about since Steve passed.

The lack of a decent modern laptop (I just want a proper keyboard without touchbar, some ports, with a decent cooling system) and MacOS becoming more buggy and annoying has pushed me to find an alternative.

WSL1 did not cut it for me, but WSL2 has taken Apple out of my mind entirely with regards to my development environment.

Why do you guys even use WSL? React does not work on Windows proper? If a few command line tools is all you need - there is MSYS and Git Bash. Genuinely curious: I use it mostly for testing, as some of the software we make supports Linux.

I switched to Windows full time a few years back. I started with WSL1, but ran into some serious bugs (that have since been fixed) and made the full jump fairly quickly.

I think a lot of folks take this path because it's just easier. The fact that I know I can do most of the stuff the same way I always have makes it an easier decision to make. I think there's also, for some people, an ideological component, that is, they're still using UNIX, it just happens to be in a Windows host, and that's easier to accept than come to terms with Windows just being a decent OS on its own merits. (I am not saying anyone in particular in this thread is that kind of person, of course.)

I develop multi-platform C and C++ code (intermingled with some python for testing and automation), and my experience has been that while MSYS + Git Bash works, I run into 'rough edges' on that side much more frequently than on the WSL side.

If you deploy / admin linux on production side it just seems to be a lot easier to also basically develop in a linux like environment.

With WSL2 you can go from - I wonder if this would work, do a quick no git checkin no vm no docker quick script, then looks good, let's drop this into git, get a dockerfile going, test on docker then test deploy or start going to production.

And it's all pretty fictionless and you can use your Windows machine still for whatever other desktop stuff you have (which many find easier than getting a linux desktop going especially if you need to interop with a word / excel / microsoft business).

I think Microsoft is finally paying a bit of attention to what developers are looking for. The vagrant / docker on windows solutions were in part providing for this need (windows desktop / linux development). This is also what made MacOS so great (unix/bsd under the hood with a nice gui). Why not bake it in? Linux is open source - you don't even have to license it from someone.

I really like WSL. And Windows 10, well, it's not awful. I don't hate it anymore than I hate Mac OS's GUI. I find things especially nice with the new Windows Terminal.

But the piece missing is still first class support for X (or Wayland) Linux applications. Without GUI Emacs, for example, or some way of integrating the Windows Emacs well, I find the WSL experience not as productive as booting into my actual Linux partition. But it's like... 90% there.

One thing I really like is that the Windows version of CLion will use SSH to connect into your WSL installation and use the Linux toolchain. So you can develop both Linux and Windows applications using the CLion GUI IDE on Windows, it's quite seamless.

Have you tried using Emacs with an X server for Windows?

Yes... it's not as well integrated as I'd like.

You can run emacs on WSL and just pass the X output to windows using an X server like VcXsrv. This works pretty seamless for me, no noticeable lag or anything.

This works very well. Another thing I do that works well, and I don't really see it brought up anywhere, is to use nomachine to connect to localhost. It's not seamless in the sense that you have linux apps side-by-side with native windows, but it gives you a full linux desktop experience (you need to install a linux desktop and wm in wsl for this to work well). Combining this with windows virtual desktop i can flip back and forth between windows and linux instantly without any vm.

> One thing I really like is that the Windows version of CLion will use SSH to connect into your WSL installation and use the Linux toolchain. So you can develop both Linux and Windows applications using the CLion GUI IDE on Windows, it's quite seamless.

Tramp[1] does this for Emacs. You can run Windows GUI Emacs and use SSH or another protocol to edit files and run commands within the WSL installation. It's pretty seamless.

[1] https://www.gnu.org/software/emacs/manual/html_node/tramp/in...

that's awesome! thanks

The one (big) caveat is that some Emacs commands that start subprocesses will incorrectly try to start the process in your local environment (in this case, on the Windows side), rather than the remote environment (within the WSL VM). This mainly occurs when elisp functions are implemented using call-process or make-process when they should use process-file[1] or start-file-process[2].

This isn't an issue for most code within Emacs itself, but it pops up occasionally when using packages from ELPA or MELPA.

[1] https://www.gnu.org/software/emacs/manual/html_mono/elisp.ht...

[2] https://www.gnu.org/software/emacs/manual/html_mono/elisp.ht...

The Mac is 10% of Apple’s revenue. How much of that 10% do you really think are developers that would switch just because Microsoft supports Linux? Especially considering that macOS is a real certified Unix not just tacked on.

How many developers care about "certified Unix", or can even say exactly what that means? Is anyone buying Macintosh computers in order to run their certified Unix software?

Linux isn't certified, and none of developers using that seem to mind. If Microsoft got WSL "certified", would any Linux user consider it a better Linux than Linux?

None.

The point is how many people care about running Linux in a VM (which is all WSL2 is) on Windows instead of running a native Unix operating system? Out of those that do care about running Linux, what is the practical difference between running Linux in a VM on Windows and Linux on a VM on Macs?

Apple doesn’t put time and effort into making Linux on a VM feel at home on macOS.

It doesn’t have to. How does WSL feel “more at home” than the third party VM solutions available for Macs?

Actually there are Linux distributions that are UNIX certified, namely Inspur K-UX and EulerOS 2.0.

https://www.opengroup.org/openbrand/register/brand3617.htm

https://www.opengroup.org/openbrand/register/brand3622.htm

There are tail wagging the dog incentives here.

Part (not all) of the Mac resurgence was that you needed a Mac to develop iPhone apps.

Part (not all) of the new Windows resurgence is that if you even really want to play around with ML or VR dev you need a Windows machine.

I feel like it's about the possibilities - with WSL, Windows Terminal I get what's essentially the mac experience but can suddenly do so much more.

The Mac’s “resurgence” started around 1999 with the introduction of the iMac - 9 years before the App Store opened. Apple currently sells around 16-20 million Macs a year.

No matter how good WSL is, if you want to develop iOS apps, you still have to buy a Mac.

There are around 200 million consumer PCs sold a year. Do you really think any significant number or sold to develop VR apps - that market is minis use.

They resurged because windows laptops was straight trash and wireless worked like shit. Apple only needed to do a few things better back then.

What makes windows better than osx for VR?

Most of the VR platforms just aren't supporting Mac b/c of the smaller playerbase, lack of higher end video card support and games support.

Well, one of the biggest platforms for VR gaming has dropped support for Mac OS.

https://www.theverge.com/2020/5/1/21244468/steam-mac-support...

Coupled with a history of GPU driver support usually being best on Windows and having good GPU support is usually pretty important for VR, its pretty clear why Windows is probably the best platform for VR development at the moment.

To put this in perspective, less than 2% of Steam users have a VR headset. It isn’t exactly a huge market.

https://www.engadget.com/half-life-alyx-adds-1-million-vr-us...

> Part (not all) of the new Windows resurgence is that if you even really want to play around with ML...

Do you mean machine learning? If so, then that doesn't match my experience at all.

Those of us who have been using Linux around the the year 2000 will remember the April fool joke on Slashdot about running Linux alongside Windows. The often repeated mantra, first they ignore you, then they laugh at you, then they fight you and then you win. The main reason of this seamless integration happening between Linux and Windows is most probably the fact that developers or the "cool kids" going to MacOS by the droves. Like what people normally say, the enemy of your enemy is your friend. Only time will tell how many of the "developers" will come to Windows via the unthinkable Linux route, but correctly done Windows and Linux integration is a potent OS combination.

Here we are: https://linux.slashdot.org/story/05/04/01/1453253/gentoo---g... (perhaps there were others)

Back in those days, if Microsoft had seriously invested in the POSIX subsystem, I would never bothered again with Linux.

We were deploying into production with Windows, Aix, HP-UX and Solaris.

The Red-Hat Linux server that we had around was only for test purposes.

Why use WSL2 instead of just running linux directly? Why do you need Windows in there?

drivers.

to play windows games or run windows applications that don't work in wine or in a windows virtual machine.

to comply with company policy that only supports windows on desktops.

Video games. Though I've finally got a second GPU and am working on passthrough from Linux to a Windows VM.

I've solved this problem to myself by having a dedicated Wintendo.

A lot of software (drivers, engineering suites, Visual Studio, games...) requires Windows or is better supported there or easier to work with.

Others prefer the Windows desktop, in particular for multi-screen.

A huge number of things are terribly supported on Linux. Just as much better linux generally is for software dev, it's that same amount worse for most else. When I last tried going full linux (admittedly over five years ago), I remember wifi being a nightmare. Netflix had issues I can't remember specifically. Even ubiquitous formats like pdfs and word docs wouldn't always work correctly. More recently, I remember spotify being a pain and youtube not working as well. Maybe it's better now, but support for new mainstream products always lags in linux.

It's why so many of us try to get the best of both worlds. Dual booting with mainstream OS and linux, or ssh'ing from a mainstream OS to a machine on linux, using OSX + unix terminal, or windows + unix terminal, both options together always seems better than either option alone.

Kinda like how you could do anything in C++ that you can in Python, and vice versa. But the ecosystem is often what determines the best choice. Sticking with one and only one limits you.

Better experience you will have using native linux, insterd of a glorified VM.

Apple lost the development train a few years ago.

Windows + Linux VM has been a better platform for a long time, even before WSL!

Microsoft recognized this and wanted to boost this workflow by providing it themselves.

Windows can be controlled entirely by the keyboard, out of the box (Start+ArrowKey).

MacOS always required extra setup with Karabiner and other tools to mostly accomplish the same thing.

The BSD derived base in MacOS made a great developer OS but the windowing system often felt lacking.

macOS has full keyboard access and you don’t need Karabiner to enable it.

It's my understanding that MacOS requires extra setup for those shortcuts regardless of Karabiner.

If you feel that extra setup is acceptable then any almost modern OS will fit your needs. There's something to be said for standardized shortcuts that work on every MS Windows instance.

All you need to do is enable full keyboard access in System Preferences -> Accessibility and it'll work.

Which keyboard combination moves windows around, the same as WIN+ArrowKey, after enabling "keyboard access" in MacOS?

I'm not sure about that. I've been running Linux as my daily driver for a good 20 years now (minus a few years on macOS when I foolishly bought some Mac hardware too poorly-supported by Linux to be usable). I finally gave up on Mac hardware last year and bought a Dell XPS 13. I went through the Win10 setup so I could easily shrink the Windows partition and install Debian in the remaining space.

It frankly disturbed the hell out of me. Windows asked for consent (default to yes, of course) for a lot of invasive things, to the point that I wondered what it was going to do without asking. And even after I said no to them, I saw what I can only describe as ads all over Windows itself. Windows pushing me to use Edge, Windows pimping Cortana even when I said I didn't want to use it, etc. In the hour or so that I used it, I never wanted to use it ever again (and, indeed, I haven't).

Apple and macOS certainly have issues of their own, but I never felt like Apple was trying to advertise to me or violate my privacy. Microsoft made it very clear that they ravenously wanted to do both to me immediately. I'll stick with Debian, thanks.

> 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.

Yeah don't get too excited, it's just a VM. The disk usage doesn't automatically shrink with usage, and I'm not sure if RAM does either (interested in knowing if they've done anything related to that), which were what I found most useful about WSL1. I wish they'd instead put all their effort from this into legitimately fixing the issues in WSL1 instead.

The disk issue was probably going to be difficult to solve even with the WSL1 model if they wanted good IO performance. Using a proper Linux filesystem underneath is a decent compromise IMO.

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.

Isn't Linux already capable of handing unused memory back to an underlying hypervisor? I vaguely remember that MS contributed code to support that kind of interaction with HyperV. Am I wrong?

They do adjust memory reservation dynamically if I'm correct. It's very nice overall.

I think hyper-v does dynamically scale ram usage of vms, so it’s at least plausible that wsl2 does as well

> it's just a VM. The disk usage doesn't automatically shrink with usage

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.

I imagine that could cause some awful fragmentation?

It's not quite a regular VM, like what users themselves can create, but deeply integrated. But it's based upon Hyper-V, that's correct.

It is technically less impressive, but much easier to maintain and stay compatible for Microsoft.

Here's the diagram - https://i.redd.it/po98dksksjx21.png

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-...

"Alongside" is such marketing nonsense that as a user it almost gets me angry to keep reading it at this point. If it was really running "alongside" Windows then I'd be able to switch to Linux, shut down Windows, and now work in Linux while it's still running. And back. That's what it means to a user when you say they run "alongside" each other. But it's obviously not that. Not even on the same planet as that. It's just a damn VM running inside Windows as far as it concerns a user. Nobody cares if it's running in ring 0 or -1 or NaN, or under a hypervisor or over a supervisor, or whatever terms get thrown around. If it's still going to quack to the user like every other duck, it's a duck.

So how many users are in the set of people that care about running Linux using the WSL, don’t understand the technical underpinning, and that care?

> as far as it concerns a user

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...

The parent and grandparent posts appear to have nothing to do with a casual user's point of view.

Calm down bro no need to be angry over small things. Technicaly it really running Linux and Windows alongside using Hyper-V and I dare you to find a better word for the technology being implemented.

Yup it’s not as impressive technically, but it’s a huge improvement for what developers have actually been using it for.

> I thought it was a thin translation layer between the kernels?

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.

Note that the performance didn't really have anything to do with NTFS. This is trivial to prove if you just try a different filesystem.

WSL 1 and WSL 2 can coexist and be used according to what needs one's scenarios present. I imagine MS collected enough requirements to also justify a full Linux VM. There will be some slowness somewhere, the 2 versions now let you choose on which side of the boundary to place it.

https://docs.microsoft.com/en-us/windows/wsl/wsl2-faq

They could've instead worked on speeding up the I/O subsystem and sped up Windows altogether. I refuse to believe it's impossible. The more plausible reasons to me seem to be (a) they have to work independently from the I/O subsystem team(s) for whatever reason (maybe they didn't care enough to cooperate), or (b) it's too tricky to get right and prone to bugs, so they preferred not to have to deal with it and risk breaking I/O.

I/O subsystem performance is just one aspect. WSL 1 is missing a lot of other stuff probably because the effort to implement it all was to great. MS would have to duplicate a lot of the effort already put in by Linux developers. So they went the route of a full Linux VM.

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.

WSL 2 can't coexist with other virtual machine software though (unless it leverages Hyper-V)

Good chance that your other VM software can't co-exist anyway. Many other technologies, Windows Defender among others, leverage virtualization through Hyper-V.

Hyper-V is not installed by default on Windows and I have not been required to install it for anything except WSL 2 (and Hyper-V itself).

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.

I think by Windows Defender they might've been thinking of the Sandbox?

It is not anywhere in the Windows features dialog mentioned explicitly but many features install an hypervisor under the covers. Not Hyper-V itself but a hypervisor which inhibits other VM hypervisors from functioning.

If you are talking about "Windows Hypervisor Platform", that indeed has Hyper-V as a dependency.

CredentialGuard uses Hyper-V, so it could be that.

Latest version of VirtualBox and VMWare support Hyper-V and Docker latest/beta supports WSL2. That should solve most use cases.

I have had a number of problems trying to use the Hyper-V backend with VirtualBox. In my experience it has caused frequent crashing in my VMs which remains even after disabling Hyper-V.

Yes, this long issue comment explains how the true cause is the design of the Windows IO subsystem: https://github.com/microsoft/WSL/issues/873#issuecomment-425...

Yeah, and I'm not sure I really buy everything they say there either. For example, "unfortunately that means sending more operations down to the file system" seems a little tough to swallow. There's no reason it has to be that way for file systems they control, which I dare say is the case for almost all their users. They could just implement separate APIs that optimize the cases where all sides of the equation are well-known, and only fall back (as they mention) when there's an unknown somewhere. (Not that I'm suggesting these are easy. Just commenting on the technical premises they're providing.)

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.

To be fair, I read that as "NT (kernel) filesystem performance" and didn't assume it meant NT File System as in NTFS.

I also specifically worded it as "note that" to preempt this comment about the slight ambiguity, but I guess that didn't really help...

But in any case, I think the component you want to refer to in that case it the "I/O subsystem".

Personally I never had a problem with filesystem performance on WSL 1. I certainly don't think it was so bad that the whole thing needed to be scrapped in favor of a virtual machine.

Try doing git filter-branch. ;)

Windows does something weird with the filesystem that I have never figured out. In a msys2 shell, git is incredibly incredibly slow. I actually don't even bother running git in msys2 anymore; I just use the native git in that directory. (I use msys2 to cross-compile AVR 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.

As far as I know it's a fundamental kernel architecture decision that Microsoft can't just "fix."

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.

Also, NTFS has very different (multi-file) ACID guarantees and transaction semantics compared to most POSIX file systems. A lot of performance differences between Windows and POSIX file APIs make some sense in a NoSQL versus SQL database analogy: they make very different guarantees about what the "atomic commit" level is, what is stored and how it is stored, what is locked and how and when it is locked. They both have great uses and there are trade-offs to both approaches, you can't always rely on the performance of an application built for one running performatively on top of the other.

I thought ReFS was suppose to give Windows different atomics and I'm surprised they haven't push it further into their client OS.

The impression Microsoft gives to me is that ReFS is meaningfully only beneficial over NTFS in RAID configurations with multiple physical drives (otherwise NTFS and ReFS have very similar semantics on a single physical drive), so pushing it any further than "Windows Storage Spaces" sounds unlikely, and few consumer machines have more than one physical drive in any configuration much less a software RAID configuration.

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.)

Yep, Windows FS is very slow. If you have an antivirus it is extremely slow, but even if you don't, it is still very slow. This is not really an issue of msys2 or WSL, this is an issue of Windows itself.

MSYS2 git has its own overhead; what you're seeing there isn't the Windows or native git overheads (though those also exist).

Really? I found it slow enough to basically not be able to use any of my regular build systems (Maven, NPM, Cargo, etc.).

Try running Node on Windows. Even without WSL the poor NTFS performance is a serious drag.

I've been compiling fuchsia in it, and yes, the file performance is really bad - Normally "gn" does not take that much time to generate ninja files, but under WSL1 it takes significantly more. Later building these files, the impact is taken by the CPU mostly, but still there is lots of I/O so much slower.

Just a reminder that enabling Hyper-V (needed for WSL2) will make your computer boot your current Windows install inside a VM too. This might makes a slight performance impact.

And you might also encounter issues with Type 2 virtualization software such as VirtualBox or VMWare Workstation.

(I will still stick to WSL 1 because of that).

This is a very important detail, yeah.

For ML, 3D, games and what not is probably better to keep Linux in another kind of VM.

that seems odd; what is the performance impact of turning on Hyper-V for the root/host windows instance?

Basically no impact. At least for me. Some people seem to get terrible performance, but I don't know why. Their drivers? Or is it trying to run without Virtualization enabled in BIOS? AMD-V, VT-x, VT-d?

I don't consider it odd. It is the way a Type 1 hypervisor works. Windows puts in some effort to hide most of that from the user.

Unfortunately I have no number to give you. I did a search on the subject a while ago and all that I could find is numerous post on multiple forums with people indicating slowness, lower fps in games, shuttering. Weirdly, this is something that could be tested pretty easily with a benchmark.

In my understanding on how a Hypervisor works, the only thing that I'm almost confident to say is that there is an impact but it's probably not noticeable or highly related to your workload (maybe on I/O?).

People will probably not care about that impact in fact (considering that Hyper-V is enabled by default and there are multiple security features of Windows now relying on Hyper-V).

Any benchmarks on this? For laptops I'd be mostly interested in seeing battery tests - otherwise I guess a compiler benchmark, and some gaming numbers.

I'd be a little surprised if it really is measurable - just win10 with/without hyper-v? I seem to recall xen (which should be comparable) having a pretty low impact?

You may be right but:

1.) The Hyper-V component isn't installed on my Windows 20H1 install. WSL 2 may use Hyper-V technology, but the full thing does not appear to be installed.

2.) So far, VirtualBox is working just fine. I haven't noticed any issues yet while using several virtual machines. Nothing seems amiss at all.

Is "Hyper-V" or "Windows Hypervisor Platform" enabled in Windows Features screen?

The Hyper-V hypervisor is obviously running. I don't remember the corresponding name in the optional components.

The complete Hyper-V suit you use to manually create and run VM does not need to be installed by default, but that's irrelevant. Windows provides more and more features that relies on the hypervisor, e.g. Windows Sandbox, Edge Protected Mode, Credential Guard, etc.

Those features (and WSL2) are not available when you are not running under the hypervisor.

MS also provides an API so that third party VM tools can run, and Virtual Box can use it, but still recently it had tons of issues. Maybe the situation is somehow better now, I don't know. I don't think this is an option with VMWare though.

Indeed, until very recently, Virtual Box could not be run with Hyper-V enabled. One the recent release, fixed that but the price was some performance optimization was disabled. So it's not optimal [1].

VMWare has a tech preview of the next version of Workstation which should work with the new Windows 2004 [2]

[1] https://forums.virtualbox.org/viewtopic.php?p=470529#p470529

[2] https://blogs.vmware.com/workstation/2020/01/vmware-workstat...

Just a reminder that enabling Hyper-V (needed for WSL2) will make your computer boot your current Windows install inside a VM too. This might makes a slight performance impact.

That doesn't sound right. Hyper-V is a Type-1 hypervisor, so by definition the Windows installation would not be running in its own VM (for some definition of VM).

And its pretty much exactly the same for Qemu/KVM on Linux, where Intel VT-x or AMD SVM hardware extensions are used to implement Type-1 virtualisation.

Unless I'm terribly wrong, when Hyper-V is enabled, it converts the current host Windows to a "Parent partition". This is what it's described here: https://superuser.com/questions/836116/hyper-v-appears-to-ru...

The thing about Type 2 virtualization not working is true, but if you hyper-v enabled you already have type-1 virtualization so type 2 is kinda irrelevant.

I've been using Hyper-V for about 5 years and never noticed any performance impact worth mentioning. Type 1 hypervisor VMs are still technically running on the metal.

VMWare has beta Workstation that integrates with Hyper-V.

As a long time free software and linux supporter I am a little bit afraid of this.

It seems like a very smart move from Microsoft. They get rid of the abysmal performance of windows's file system and spawning new processes by using... linux! Provide also an excellent terminal so that developers have the best experience with command line tools, all this without leaving the convenience of Windows!

Not surprising since they dominate the desktop market since forever being smart at strategy.

The only weak point of WSL 2 to my point of view is that you say goodbye to development of native Windows application because you are effectively on Linux. It means you either setup cross-compilation which can be annoying either you go with Visual Studio, the old MS way.

For the moment I will stay with MSYS2 plus Mingw64, they are both excellent and provide a good experience to develop native applications on Windows. At home I will keep using Ubuntu, of course.

For the introduction of WSL 2, I think many of the people using Mac OS X may switch to Windows. They never fully embraced the free-software philosophy and chose Mac OS X because of the high-quality hardware and software and the good terminal experience with unix-like environment. They will easily switch to Windows now.

The small group of people using Linux will probably stay on Linux because of dislike for Microsoft practices and the fondness for free software.

Bad news for free software, good news for Microsoft shareholders!

Good news for end users like me. This was a pain point of Windows, now it's fixed.

I think that people who really embrace the free software philosophy will continue to use Linux. I used Linux for years and I really enjoyed it on several levels.

In my opinion, WSL2 is leveling out the playing field between Windows and MacOS. If you were doing web development (and many people are) it had always been so much easier to get up and running on a Mac. MacOS had native versions of all the stuff web developers use (Python, Ruby, PHP, etc.), on Windows things were always surrounded with a haze of "unsupported" and "non-standard". WSL2 doesn't entirely resolve this issue but it goes a long way towards getting it done.

For myself, I have to do a lot more native Windows development and have had to switch from using Linux at work to Windows (running Visual Studio in a VM under Linux all day just wasn't cutting it). Having all the familiar tools available in WSL2 has made the transition much, much easier.

My view is that WSL2 will help developers who are stuck on Windows (many enterprises force Windows on users).

I don't think Linux will be affected as much. Moreover, Linux is better than ever:

- you can buy laptop with Linux from two companies: Dell and System76, soon from Lenovo

- performance can't be beat (especially for development, with native docker and kvm for virtualization)

- amazing package managers, with fwupd you can even update firmware

- graphics stack is really good and getting better, firefox on wayland with video decoding support, wayland with great hidpi support

- work on chromium on wayland in progress (beta already available), we will have electron apps with hidpi support

- no bloatware (candy crush, 100s of processes...)

- gaming with Proton is miles better than gaming on macOS, still behind Windows for known reasons

Obviously if you need Adobe/Office, Linux loses many points :)

In reality enterprise users on have zero chances seeing WSL2 on their PCs in foreseeable future. Last two banks I worked for ran windows builds 1703 and 1803 respectively, more progressive of the two announced plans to update to 1903 not too long ago (yes, two first digits is year).

Oh, and WSL1 was banned, of course, on the grounds of being "too expensive and uncertain to support". You could have a Linux VM though, with approved distro, same as what prod machines run.

So really WSL is still confined to a small domain of switchers tired of MBP keyboards, Linux is safe for now :)

You are right that enterprises are lagging 1-2 years behind current windows build, but in many of them WSL is seen as major improvement for developers. Fortunately I am allowed to run Linux, so I don't care :)

I'm a Linux user, and to me WSL2 sounds like it actually makes Windows pleasant to use. Now, I haven't used Windows 10 at all. The last time I used Windows was Win7 on a work project in 2016, and it was a typical experience for me - lots of annoyance due to lacking tools. MSYS is really lacking, I used Cygwin to do most of my work in a Linux-like environment with good versions of Linux tools, but it's annoying nonetheless. Occasional problems with Windows interop, occasional annoyance due to Cygwin packages not quite acting like the real ones, and so on.

Seems like with WSL2, one could run Windows but do all the work using native Linux tools while enjoying quality integration with Windows. It's not a setup I would actually prefer over Linux but it should make any work where Windows is required much more pleasant.

On a personal level it's interesting that Windows is getting WSL right around the time when I stoppped booting my Windows install for games. Proton has been amazing, changed Linux gaming completely almost overnight. It's still not the same experience as on Windows, but between Proton and even the occasional native Linux port of a big-budget game - no longer an extreme rarity - I've been able to play games on Linux like never before.

What I haven't seen mentioned is that WSL 1 nor 2 work with the modern Machine Learning GPU acceleration.

From what I understand, WSL 1 doesn't have proper access to GPU, and for WSL 2 / Hyper-V, GPU pass-through isn't a thing for cards such as the 1080TI.

On Windows, Conda / Anaconda is quite buggy, and dealing with a regular python install through the CMD command line isn't too pleasant either.

Looks like the modern macbooks don't have any CUDA-capable GPUs. What do folks use for their ML projects? AWS?

+1 For graphics acceleration work it is also a problem.

I'd suggest avoiding MacBooks if you are in the ML field, or having a dedicated desktop machine somewhere that you connect to.

> When you compile the whole gotdanged planet on every file save, you do a lot of disk writes and stat calls on tens of thousands of files.

What kind of bizarre twisted hellscape do we live in where we just accept this as normal -- for a web page.

For the past couple years I've developed on macOS, and the few years before that in a different role, on windows. On both machines I ended up resorting to a Linux VM to avoid frustrating differences between my dev environment and my prod environment.

Windows was totally off, macOS nearly just worked but every now and then an update would kill my dev environment and I would have to spend a day fixing it.

WSL1 was totally insufficient, and a few months ago I would say that I strongly prefer macOS to windows. Having toyed with WSL2, however, the speed and seamlessness has impressed me. I haven't tried it for full time work, but I'm getting the impression that it's superior to my current workflows with Parallels on macOS.

That said I'd just prefer a high quality full-Linux-dev environment. Going to just lobby for a Thinkpad instead of a MacBook on my coming machine refresh.

I recent switched to a Linux desktop after doing the VM dance on MacOS for a few years and I can't believe I didn't do it sooner.

I am now doing the opposite: When I need to dev for Windows or something (usually for a contract), I spin a Win10 VM on QEMU-KVM.

If you guys have been virtualizing on VMWare or Virtualbox, try KVM. It's blistering fast and the whole SPICE protocol is amazing. You can actually get a usable, snappy 2+ desktop with dynamic resizing, audio redirection and USB redirection (which is SO good i was able to test using a USB soundcard and I got sound to play without underruns! quite a feat)

Do it!

> there was a glimmer of hope that Web Development on Windows would be viable.

I wonder if the success of WSL this will risk making some tooling that is already less-than-stellar on windows (Git, for example) even worse when the group that actually has to work on windows proper shrinks.

Microsoft has been putting a lot of resources on Git for a while, improving and contributing back to the original project.

I expect the Windows Git will keep improving if they keep this Windows+Linux trend.

Plus, the Windows team itself uses git day-to-day now and it would be silly for Windows developers to spin up Linux VMs to git commit on the Windows Kernel. (Windows being source controlled in git has contributed directly and indirectly to a lot of git performance upgrades/tweaks in the last couple of years, including and especially to git running well natively on Windows.)

Jekyll is the only thing I don't run in Docker and it's nice to see he went from 8s to half a second.

Full builds for my site (almost 300 posts) takes like 20 full seconds, but incremental builds when actively writing to see changes takes about 3 seconds.

So if that 3 seconds ends up being half a second or less that would be a pretty big quality of life improvement.

For Docker related projects (Flask, Rails, Phoenix, Webpack, whatever), WSL 1 is quite speedy already since the mount is happening in the Linux VM running Docker Desktop, not the WSL mount. I wonder if this will end up being any faster with a WSL 2 back-end for Docker Desktop. I'll have to wait until WSL 2 hits Windows stable to try it out.

> get a proper, functioning, fast Linux environment up and running on my beefy gaming computer

Since I didn't see it mentioned in this thread - if all one needs is Ubuntu VMs, i.e., for common web development setup, Multipass is a simple and easy tool:

https://multipass.run/

Made by Canonical, runs on Hyper-V (or equivalent), cross-platform support. I have not compared it with WSL 1 or 2, but it's been a smooth user experience.

> you do a lot of disk writes and stat calls on tens of thousands of files.

Found the root problem right there. What the fuck is going on in modern web dev.

WSL2 is great but there are still some very annoying bugs, like when the host sleeps/hibernates and the clock drifts [1], or windows detach from the x server and can't be brought back.

[1] https://github.com/microsoft/WSL/issues/4114

Big fan of WSL, get power of Windows and the full power of Linux combined. Can easily switch between gaming and development.

One caveat is that WSL2 needs Hyper-V, and many anti-cheats won't work with it (many CS:GO anticheats, I think it will be true for many multiplayer shooters).

Really? I've been playing for years now with Hyper-V enabled and hasn't been an issue.

I think you can't play inside a VM (like Hyper-V), which is a different story.

There have been games whose anti-cheat software incorrectly flagged Hyper-V hosts as being Hyper-V guests and would refuse to launch the game, but I believe they are all fixed.

All my Blizzard games seem perfectly happy to run on a machine that has Hyper-V.

I've been using Steam on (Debian) Linux for quite a while and haven't really run into issues. I mostly play Dota 2 and Stellaris, which come Linux native, but also a bunch of other stuff including quite a few Windows native / Proton-"translated" games.

All this on AMD graphics with standard open source drivers btw, did not install either proprietary drivers or "special" open source versions.

(Card is this in case anyone cares:)

  0c:00.0 VGA … [AMD/ATI] Baffin [Radeon RX 550 640SP / RX 560/560X] (rev cf)
  OpenGL renderer string: Radeon RX 560 Series (POLARIS11, DRM 3.36.0, 5.6.2+, LLVM 9.0.1)
  OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.0.2

Then again for lack of a Windows installation I wouldn't know if I'm losing performance. It is however what I expect of the card's age and price segment (mediocre in both I'd say.)

For several years, I too have used just Linux + Steam for gaming. But lately I have some misgivings.

Recently I've noticed that some games running under Proton don't reliably save: "X-Com 2" and "Strike Suit Zero". And I can't rule out that happening with other games running under Proton.

The frustration of lost saves makes gaming less enjoyable for me. So now I'm considering running Windows 10 in a guest VM.

(I'm not interested in Win10 + WSL, because I'm not open to Win10's unavoidable-updates and forced-telemetry.)

I think I tried Imperator: Rome on Fedora and it didn't work. But I don't recall. Everything else from Steam has worked for me.

With Lutris I've been able to get every other game working that I've wanted to play - including Blizzard games, other MMOs like FFXIV, and Path of Exile. But there definitely are some quirks and other things you might need to deal with.

Like to play FFXIV, the first play worked. The second didn't - it failed with some network error. Eventually I figured out that if I deleted a folder the first run created (some web cache/settings folder) it would usually work. That included settings for storing my login information, so I wasn't able to have the game remember that. This workaround also didn't always work. So sometimes I would have to delete the folder, start the application. Close it down, delete the folder, restart the application. It usually worked the first try.

Another annoyance I eventually found out: the error I was getting was the same as what you would get when their servers were down.

You can also do this by running a Windows VM on Linux if you have 2 GPUs.

What are some use cases that would cause a person to choose Windows as their primary OS, but require WSL? At what point do you just move to a *nix OS and virtualize Windows on the rare occasion that it’s truly needed?

I need Windows for Unity dev and VR.

It seems that gaming/graphics/VR is one of the last vestiges of Windows outside of the enterprise and consumers who don't really care what OS they run.

Developing linux software on windows is actually pretty painful.

Actually, running any linux software in general such as middleman or Jekyll is pretty painful on Windows- I recently had a horrible time trying to get git-crypt working for a colleague of mine who was using Windows..

There's a lot of value in being able to just run "linux" (with bash, grep, sed, awk, gcc, python) while being able to access your normal files on a Windows desktop.

You _can_ do this with VirtualBox but it's janky, slow, buggy and generally awkward.

Why not just move to Linux?

The GUI isn't as great as Windows and it's often buggy. Let's face it.

Do you find the microsoft gui great? Honest question, because I have a desktop with windows and I find its gui a clusterfuck of randomness, especially since it seems two or three different ui "languages" are constantly fighting each other since w8.

I'm not talking about the desktop UI/UX philosophy but the system itself. It is much more stable than Linux, especially where there's ongoing chaos regarding Wayland.

I work in game dev. Good luck getting people to switch. Retraining thousands of developers, retraining all our IT staff on how to deploy Linux machines reliably. Retooling all our built up support tools.

It’s not feasible, as much as I wish it was.

Everyone on my team uses a Mac, except me. (I had one for three years, the hardware was nothing but problems, and didn't grow too fond of the OS either). My day-to-day development in Windows works fine, but lots of small stuff is done in a way that's not compatible with Windows. WSL solves that fine, without me having to be an edge-case, or everything having to be written so general as to work on every OS.

Of course I could just run some Linux distro, but that again would be limiting for non-work-stuff and I prefer not switching between OSs daily. And last time I tried I had big issues with HDPI scaling between screens, hibernation etc. And really, I just don't care that much about what OS I run. Windows works.

Well I guess the main two would be:

1. You like windows

2. You want to use software or hardware that works best with windows

Personally I like windows and I want to run Lightroom and various other software that doesn't work on linux. I also want to have a full *nix OS available and windows with wsl gives me exactly that.

I need Windows to continue to work on these lame old .Net Framework applications that I have to maintain. I'm working on migrating them to .Net Core but that's not a priority for the company, it's something I do as time and budget allows. Running Visual Studio under a VM in Linux is fine here and there but unpleasant all day long.

I also still need to maintain several Java projects and some tools that leverage Ruby. Using Java on Windows isn't a big deal, but the Ruby tools are aimed at Unix-ish platforms and I find it a lot easier to work with Ruby under WSL instead of messing around with native Ruby on Windows.

Up until recently, I've primarily been a C#/.NET developer and Visual Studio (2017/2019/Community/etc), IIS, T-SQL... all largely work best on Windows.

Blizzard games (addicted to StarCraft for life, also enjoy Diablo 3). Steam games (some are supported under Linux but I know I can run all modern games with full video card driver support).

WebEx - need this for work and it seems to really lack support under Linux. Couldn't figure out how to get this working on my Ubuntu 20.04 laptop. Also use RSA and Horizon VMWare and haven't dug into how well those apps work in Linux.

I don't need WSL but I really like it. I get to dip my toes into Linux, and enjoy using bash, running MySQL under Linux, generally find the npm/yarn experience is better.

If at this point you wonder why I don't go Mac it's mostly because I could never justify the price premium to get the hardware I want. In theory Hackintosh could fit the bill but I haven't tried it, and everything "just works" under Windows so I haven't felt the need.

- Games, many games are only available on Windows and drivers are best supported on Windows. - Work & business, many companies just require you to use Windows, so you have to. - Market share, if you are a developer and you want to reach as many people as possible you need to support Windows first.

In theory you can develop for Windows being on a Linux PC using a VM or cross-compiler but this isn't always practical or possible. Just have a Windows PC is more simple.

My simple answer: the IT department will let me have a Thinkpad or a Macbook Pro. You are not allowed to install the OS of your choice on the Thinkpad.

X410 is an X server that works so far very well with my WSL (1).

Ive been using Docker Desktop with WSL2 and vscode for the past couple of weeks and its been pretty seamless so far. The performance has been great (on a ryzen 3600x PC and on my surface laptop 3), and was really easy to set up. I'm forced to use a Mac at work, and have generally dual booted to linux at home, but havent needed to so far.

I have been using a VM on a Windows 10 and I have to say, it's been great! On a dual monitor setup, I have the VM on one screen and have a windows browser on the other, and the performance is very much close to 1:1. I don't think I would ever need to install a dual boot system now.

That's great news, thinking about replacing my Ubuntu Linux install for Windows and having WSL2 if these changes and performance improvements are accurate. Windows Terminal looks pretty cool too, reminds me of Terminal.app on macOS with blurred backgrounds and theming too.

Very cool blog post!

I've done exactly that. I had some issues with WSL but WSL2 does what I need it to do. Specifically what I need it to do is cross-compile the linux kernel (among other things) for embedded devices. This works flawlessly.

Almost all my work has moved to WSL - the remaining bit (like UART and JTAG access) could be done with better USB support. So I'm definitely hoping for that!

The Windows Terminal app is very snazzy. I have only run into one problem with it, relating to using tmux.

https://github.com/microsoft/terminal/issues/176

This is not a showstopper for me though, and I have been using it as my primary terminal application for many months.

> It’s still weird to say it, but Windows Terminal is hands-down the best terminal on Windows.

Windows terminal is pretty good, but no, it's not yet the best terminal on windows.

cmder is.

It has panel split, quake mode, git integration...

Now the read map of Windows Terminal is pretty convincing, so let's see how it plays out.

Surely the git integration is in the shell, not the terminal?

Technically yes, but practically, cmder configures each shell it embeds (windows cmd, powershell, cygwing bash) to work with git automatically. So for the end user, ~=.

Eh, YMMV. I tried cmder/conemu for a while, and gave up after I fighting with one strange behavior after another for a few days.

IMO, the best terminal on windows is a linux terminal running in WSL displaying to a windows x server. I use terminator and vcxsrv, and have not had any of the weird vim, ssh, tmux, etc rendering problems I had with cmder.

Windows Terminal has picked up panel split since v0.7: https://devblogs.microsoft.com/commandline/windows-terminal-...

Wow, per the block chart of how this works https://i.redd.it/po98dksksjx21.png

It's using the 9P Filesystem to sync the two between systems... that's interesting.

> It's using the 9P Filesystem to sync the two between systems... that's interesting.

Not rare; qemu/libvirt does the same thing (well, as one option; qemu also supports smb).

Since this is based on Hyper-V, I guess it is a Windows 10 Professional-only feature ? Or did they enable a trim down version of Hyper-V which can be used on Home licenses ?

The latter

Have they gotten networking transparency working to the degree that it was on WSL1 yet? I tried an earlier preview of WSL2 and ran into a bunch of issues here.

It's still an issue afaik. But, might be because my install is old and it doesn't update that by itself.

> Smoother web development

Last I heard networking/sharing ports didn't work, has that been fixed or is there now a solution?

Yup - all works now. If I start rails server I can access localhost:3000 from Firefox on windows, for example.

Support for accessing exposed ports on docker containers using localhost:PORT is still spotty, though.

I've set up a scheduled task to get WSL IP address and update an entry in hosts file then access using http://wsl:PORT.

I would keep using native linux.

Bonus is that now Docker will work on Windows Home.

Reply on news.ycombinator.com