Did they really do that? MS's official line is that WSL is not deprecated, and can be run alongside WSL2.

Yes they did.

We discussed this here before: I am reasonably certain -- without having any insider info -- it was various ptrace types which broke the camel's back besides the abhorrent file system performance. Both PTRACE_SEIZE and PTRACE_TRACEME was closed as fixed-in-wsl2 https://github.com/microsoft/WSL/issues/2028 https://github.com/microsoft/WSL/issues/3031

Was that incorrect somehow? WSL2 fixed a ton of issues for me.

It's a true statement but it's quite unhelpful to tell people that a problem they have is fixed in a different semi-compatible piece of software.

It probably depends a lot on your specific use patterns, but I expect for most people this was a change that basically fixed a bunch of bugs, introduced negligible new issues, and had an identical interface.

Is WSL really so buggy? I never got that impression myself. All my problems with things getting fussy have been on WSL2.

I tried to build two projects in WSL1, one using the Z3 theorem prover, and one using Chrome for scraping. Both ran into kernel issues. So for me it failed about 100% of the time on anything non-trivial.

Chrome uses almost every single Linux syscall under the sun. So I guess that's not too surprising.

I am a little surprised that Z3 had difficulties. I did not think it used anything exotic.

Z3 had a timer to stop the solve if it takes to long and that used a specific option of clock_gettime that wasn't supported. I hacked around this and it otherwise worked fine.

You can say "fixed in <name>" regardless if the name is numerically sequential.

True, but if MS hadn't presented WSL2 as a variant of WSL, any issues fixed in WSL2 wouldn't count as fixed in the WSL issue tracker. I would prefer it if their issue tracker marked these, more honestly in my opinion, as "This issue is will not be fixed in WSL, you can migrate to HVL instead" (using HVL as a hypothetical name for WSL2) with a separate HVL issue tracker.

Whether they are counted as fixed in the WSL tracker is completely up to them. "Fixed, use HVL" is just as valid way to close a WSL1 issue ticket as "Fixed, use WSL2".

A poor argument IMHO. A naming change for the sake of an issue tracker that appears to be a net negative for users is not a wise choice. Naming and branding doesn't exist to serve the project's management tools.

I guess I don't follow your point. The very reason WSL2 exists is because there were countless issues that COULDN'T be fixed with the way WSL1 was implemented. Why would they leave an issue open they fixed, just because the fix required a complete re-implementation? Furthermore why would they change the name, this is literally how they are carrying forward the functionality of WSL 1. It's still Linux on Windows, there is still a custom subsystem to allow the functionality. It is quite literally still Windows Subsystem for Linux. As documented:

https://i.redd.it/po98dksksjx21.png

Should Mac Office not be called Office because they completely re-wrote it?

They aren't carrying forward the functionality of WSL1. Yes, there are issues that cannot be fixed in WSL1. There are also issues that aren't, and quite likely can't be, fixed in WSL2, that do work in WSL1. The file system corruption that happens here in WSL2 is a nice example, it is something that could not possibly ever happen with WSL1 because of the way it was designed. WSL2 is not and will never be a full replacement for WSL1; WSL1 and WSL2 are two separate products, both with their own advantages and disadvantages, and I wish Microsoft would treat them as such.

> Should Mac Office not be called Office because they completely re-wrote it?

I do not know how different Office for Windows and Office for Mac are, but to go with a different example, yes, I do think Visual Studio for Mac and Visual Studio Code should not have carried the Visual Studio name, it causes unnecessary confusion.