That meant that people doing disk-intensive workloads on the Linux side noticed a big slowdown compared to a native Linux system - certainly e.g. running a big test suite, or a git checkout felt really incredibly slow.
The switch to a VM flipped this relationship round - so now the formerly native / NTFS side is the second-class citizen, but you get the expected performance when putting your files on the "Linux side". For me (doing fs-intensive Rails development), this was a big win.
WSL2 will also quite happily gobble so much memory that Windows slows to a crawl (especially filling Linux's disk buffers on file copies) - that seemed like an odd default, - you just have to pop a .wslconfig in to restrict its usage.
I agree with the other posters here that the WSL1 approach seemed far more elegant, and probably the only way to "not see the joins"- with WSL2 we're worrying about filesystem boundaries _and_ memory now, probably forever. So I hope someone still working that nice seamless syscall layer for a future WSL3.
It probably won't happen anytime soon, but to me it looks pretty inevitable in the long run : because of Azure they already spend tons of engineering time on the Linux kernel nowadays, and maintaining their own proprietary kernel won't make much economic sense for long, exactly like maintaining their own browser engine.
That was not my experience with WSL1; I was regularly running into unimplemented features. Some examples: the Z3 solver used clock_gettime for timeouts, and their specific usage was broken in WSL1 so you'd get random failures depending on how long the solve took. And don't get me started on running Chromium.
It felt like WSL1 would be running into the long tail of compatibility issues for years.
But I'll admit that I don't try to use it the way you do, I run WSL precisely so I'll never have to launch cmd.exe.
(This is mostly a joke, but the performance of NTFS for certain operations has always been abysmal, and having a virus scanner injecting itself into all the operations only makes it worse.)
You might be able to model that stuff as xattr, but then it could be problematic to mount that ext4 partition into Linux because applications might be copying files without respecting the xattrs.
Well, since Microsoft has been borrowing more and more ideas from the Linux ecosystem, it would not surprise me that a Windows 10 successor would include some kind of compatibility layers for different file systems.
We can dream...
I wonder about the bigger part of this question.
What are the higher-ups saying?
I wonder if this is like the IBM PC, which was a GOOD THING invented by a sort of an offshoot of IBM culture. Then IBM higher-ups stepped in and tried to control the platform (PS/2, OS/2, microchannel, etc)
WSL is attracting people to windows. But the endgame isn't to lose them to linux. So they have to tie it into windows more. But if they make it too slow and bloated they might lose.
an interesting situation.
Shame, it was really good.
Do it, free yourself (and your kernel)
Even just letters like WSL-A and WSL-B might have given a better impression.
The supposed speed boosts of WSL2 requires having your files living directly inside of WSL2's file system.
I haven't tried WSL2 yet since I'm waiting for it to hit stable.
Given the fact that Git is used for Windows development with monster monorepository, I think that something's wrong with your setup rather than Git on Windows in general.
Also, remember to disable the antivirus for your Git folder!
For example I use intellij on Windows but want to compile and test on the Linux machine. If it takes 30 seconds longer than wsl 1, why would I bother changing?
What is the actual point of wsl if not for the cross compatible filesystems
There is a Reddit sub for WSL (/r/bashonubuntuonwindows) and it's apparent that MS has PR people on it pimping each new release. Reminding these mostly new developers that Cygwin has been around (with all its problems) for years, brings on a flood of downvotes.
And now it's exactly the same with WSL2; when someone has an issue with some esoteric networking feature that is still not supported on WSL2 beta versions, I'll often remind them that VMWare Player and VirtualBox have been around for a decade and will solve their problem, while also including all sorts of nice features like shared folders, drag & drop, copy and paste integration, etc. But they don't want to hear it. They've been fed so much marketing that WSL and WSL2 are really something incredible...
Maybe wait for an IDE update that handles properly WSL 2?
Then there is no WSL 2 handling in your editor. VSCode remote extension works in the same way for either WSL 2, or a full-fledged Linux VM, or even a remote Linux server.
As someone who run a Linux VM side by side all times, I really don't get WSL 2.
It's the same as saying: " As a person who runs containers all the time, I really don't get Docker".
The point is VS Code handles my code hosted in WSL 2 out of the box. I don't care that I could use a VM or a remote server instead.
I just suggested that the parent commenter waits for is IDE to implement a similar integration...
VSCode made some unique design choices which enable them to support connecting to any Linux server, VM or not. In contrast, these design choices may not be possible for other IDEs. So, because WSL 2 is, effectively, a Linux VM, supporting it in editor is harder than supporting WSL 1.
As for "I really don't get" part, I wanted to say that WSL 2 sounds like a regression to me, WSL 1 makes it possible to achieve something (namely, local-ish cross-"os" net/process/file-system integration) that is entirely impossible otherwise, while WSL 2 is a nice packaged-up solution but functionally does not do more than people already get (Hyper-V).
The software engineer in me agrees with you, WSL 1 was architecturally more ambitious than version 2.
As a user, I couldn't care less. I just hope Microsoft manages to create a good ecosystem around WSL.
Then you could as well run your stuff in a regular docker container, WSL becomes redundant.
https://docs.microsoft.com/en-us/windows/wsl/wsl2-faq#what-w...
Also, it seems the Intellij team is working on supporting WSL2 in some ways. Check their issue tracker.
As long as your processes and files are from the wsl vm, it is extremely fast. I rather use the wsl shell, so all of my files are in the vm.
[1] https://youtrack.jetbrains.com/issue/IDEA-197573?p=IDEABKL-7...
Personally I don't like VS Code, I too use IntelliJ IDEA, which will probably end up having support, but it didn't last time I tried.
On my Macbook I also use Emacs and GUI versus terminal shouldn't be an issue. I'd want Emacs from inside a WSL bash, I'd want it from the Windows GUI too. So that's going to be a headache.
It's not the appdata folder right?
https://devblogs.microsoft.com/commandline/whats-new-for-wsl...
https://www.theverge.com/2020/4/8/21213783/microsoft-windows...
(Also, hints are that Microsoft is exploring adding shortcuts to \\wsl$ directly to the File Explorer left hand tree.)
I've used Linux VMs on Windows before - VMWare Workstation has been around for over a decade and has a lot of bells and whistles that make the experience tolerable, but again, the IO is too slow to share Windows and Linux apps between filesystems, so you're basically forced to develop 100% in the VM, IDE included. If you're locked to a Windows laptop because of your employee's IT rules, it's better than nothing, but not optimal, and I wonder why people are so excited for WSL2 when VMs that have more features have been around for over a decade.
I've been trying to find a non-Apple solution for a decade, and it just doesn't exist. And as Apple has been ignoring developers and MacOS itself for the last 5 years, and Linux is still riddled with the same problems it has had for 20 years, the options for developers are becoming less and less.
Virtualbox, HyperV, etc will all allow you to access your Windows files on the guest OS. If that doesn't work, just set up an SMB share and map it. Why all the complication? Does clicking one button to install a distro really serve anybody? Why do you want to use the fucking awful Windows Update mechanism to update your kernel? Updating the kernel in Linux is so fast and easy...
You learn so much more about Linux by running Linux. Why are we trying to abstract that away? I think it's Microsoft's desperation to keep devs from continuing to jump to MacOS and Linux.
But with that caveat in mind, Cygwin turns Windows into an acceptable Unix for command-line purposes.
I don't think it's quite as good as a development environment when you're targeting Linux though. That's where WSL (in either form) makes a lot more sense.
Also, IO performance of WSL1 wasn't exactly great either compared to native linux filesystems.
I mean, not hating it, but that doesn't feel all too straightforward, definitely less sonthab wsl1 :/
Though it is powering that pseudo-device by a 9p-based file server under the hood, it's not a network accessible path, it's only available to the local system.
The trade-off between WSL1 and WSL2 (and you can have both on the same system and migrate distros both directions between the two) is mostly how often and where do you expect to need to deal with the 9p file server between your operations. In both versions Windows needs to use the 9p server to access Linux files, in WSL2 Linux also needs the 9p server to access Windows files.
It's a network path listening only on "localhost".
Also, yes the current implementation backing that namespace/path is a Plan 9-based network file server, but that's an implementation detail that could change, seems to handled under the covers of the Namespace a little more directly than usual network access (including avoiding a localhost "loopback"), and probably something subject to change as WSL's needs change.
[1] https://docs.microsoft.com/en-us/windows/win32/fileio/naming...
WSL1 was not great in local or cross-os i/o. WSL2 is at least great in local i/o.
My guess is they people who put it together were under the assumption that Linux should be as simple as to implement as the old Windows Subsystem for Unix and POSIX API.
WSL1 was unusable as there was no way to run IntelliJ or Eclipse on Windows, and have it work on large projects sitting in the WSL filesystem - the file IO was way too slow, and the instantaneous feedback you expect from Jetbrains products just wouldn't work.
VMs on Windows would work, but again only if you were developing 100% in the Linux VM, IDE included, and just used Windows for Office and whatever else was required. But at that point, you still had to deal with all the Linux issues like ugly fonts and broken plugins, with all the problems of slow VM file IO.
Cygwin also similar to WSL1 - just wouldn't work for anything that required real Linux underneath.
Linux direct on the laptop works, but with all the same problems that have been around for 20 years and never seem to get fixed - broken multi-monitors, ACPI issues, driver support for Nvidia, video conferencing being too slow or unsupported, no MS Office, etc. I just don't have the time or motivation to spend hours every week babysitting a Linux laptop.
Macbooks are definitely the way to go, I'm just worried that my employer will balk at the cost of the new $3K 16" MBPs next upgrade cycle.
In WSL2, running the same command takes over 30 seconds. WSL2 is a massive hit to the seemless experience between the two operating systems with filesystem performance from Linux to Windows files orders of magnitude worse. Yes, unzipping tarballs or manipulating and stat syscalls are cheaper now on the Linux side. The downside performance loss is, however, staggering for the files I had in C:\
Don't even get me started on how long an npm install took.
One of the truly wonderous things about WSL1 was the ability to do something like this in a PowerShell window:
C:\some-code-dir\> wsl grep -R "something" | Some-PowerShell | ForEach-Item { }
Now performance across the OS boundary is so bad, I wouldn't even think of using "wsl grep" in my C drive. Or "wsl npm install" or "wsl npm run test" or any of that.
It's very depressing because WSL1 is so, so promising and is so close to feature parity. WSL2 should definitely stick around and has use cases, for Docker it's unparalleled. But for daily driver mixed OS use, WSL2 has made me very unhappy. I think I'll be deconverting my various WSL distributions because the performance hit was too much, it just was absolutely unbearable to even run simple commands in my Windows side.