So now you have quick tests. That's disrespectful towards me because I got called slow once.

This can go on forever.

This was definitely not obvious to me from their announcement and I wouldn't be surprised if others similarly misinterpret it.

Root cause? I didn't even know commit comments were a thing that GitHub had! I assume it was much clearer to everyone that knew about them.

Me too. It wasn't a term or feature I was familiar with, and (incorrectly) assumed they were talking about commit messages.

I wish forum.dlang.org had a quick way of browsing just the top list of the most commented posts.

https://superuser.com/a/319322/1173126 (be sure to read the comments of that answer too, these days you need to switch a flag in Ff settings to enable this feature)

and still feel most at home there.

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.

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

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.

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

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

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

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.

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.

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.

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.

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