[alerighi]

Correct, but... this is not WSL. This is a VM.

Let's see this from the opposite point of view: WSL1 is to WSL2 what WINE is to a VM running Windows. Two completely different approaches.

The thing that would have allowed the WSL1 to do was to really integrate between Windows and Linux: imagine writing running a Linux command, piping its output in a Windows command to pipe it again in a Linux command. Imagine sending a signal to a Linux process from a Windows process. Or imagine accessing physical hardware from the Linux subsystem. With the WSL2 is impossible to even use a serial port!

WSL1 had performance problems. That thing about the filesystem performance could have been the occasion to optimize NTFS and even to add to the NT kernel the support for other filesystem, natively. Or why not add to the NT kernel other Linux functionality, to make them available both in the Linux and Windows subsystems.

Of course not everything would have been possible to map on the NT kernel. That is fine. But for most application really the WSL1 was usable.

Maybe the real problem with the WSL was only having called it "Widnows subsystem for Linux". They should really have made WSP: Windows Subsystem for POSIX. Drop the binary compatibility with Linux requirement and just make it an environment in which you can compile code that uses the POSIX API and interface with Windows. Not having binary compatibility with Linux is not a big deal, thing about it but is what macOS does and nobody seems to care, and users would have created a package manager just like there is brew in macOS to easily install software.

[jasonkester]

imagine writing running a Linux command, piping its output in a Windows command to pipe it again in a Linux command.

But that's not most of us want to do with WSL. We just want to run the team's React app with its rube goldberg npm monstrosity that falls over when you try to run it on windows.

That use case covers 90% of us. No need to ask for anything more.

[TeMPOraL]

This is how our industry goes to crap. Repeatedly pruning things that 90% of the current userbase doesn't use over time give you a thoroughly useless product. I mean, do it 7 times, and you've already lost 50% of your audience. If you target 80% cutoff, you're down to 20% of the users now.

I personally do want it from WSL. Hell, 90% of my use of WSL is like this - I run Emacs on my work machine under WSL, where it feels at home. I use it to drive Windows-side cmake and Visual Studio compiler, piping output back to Emacs. Because I can, it works, and it's a much nicer working experience than any app could give me.

[userbinator]

Not having binary compatibility with Linux is not a big deal

But it is, because there is actually lots of proprietary software available on Linux as binary-only --- many of it very specialised and expensive --- and Microsoft wants to be able to run that too.

[moron4hire]

Windows Subsystem for POSIX was already tried. It didn't take off.

[johncolanduoni]

It was a hack to get around a US regulation about government procurement requiring POSIX support. So I think tried is a very strong word, it was never intended to be remotely useful.

[josephcsible]

Isn't the only reason that it didn't take off because it was so incomplete?

[sgerenser]

Incomplete and nobody really knew it existed.

[zerkten]

> That thing about the filesystem performance could have been the occasion to optimize NTFS and even to add to the NT kernel the support for other filesystem, natively.

I doubt that would be feasible given how important backwards compatibility is for Microsoft's business. WSL1 seemed like a huge effort on its own, so changing one of the most critical OS features would be a little ambitious.

[utxaa]

> imagine writing running a Linux command, piping its output in a Windows command to pipe it again in a Linux command.

?? we do this all day long on WSL2.

[mook]

> imagine writing running a Linux command, piping its output in a Windows command to pipe it again in a Linux command.

Actually for that special case WSL2 works. I'm currently experimenting with `sshd -i` on WSL2; not sure why it doesn't work on Ubuntu 20.04 but does on OpenSUSE 15.2…