Hacker News Reader

Comment by NelsonMinar | Hacker News Reader

git bash is very cool. It's based on good ol' MSYS2 and MinGW which has always been a nice way to do minimalist Unix-like stuff in Windows.

WSL2 is great these days and can interact fine with Windows files (despite what this article says). But it's a lot more stuff, a full Linux install in a VM.

View on HN

I just had an IDEA nx plugin crash my editor until it was removed because it can't handle WSL directories, so I would not say it can interact fine.

Tip: Install the IDE inside WSL2. Should also run somewhat faster, especially any operation which has to do with many small files, at the expense of a tiny bit of latency in the GUI.

> WSL2 is great these days and can interact fine with Windows files (despite what this article says)

is that true when using Docker with WSL2?

Wsl2 mounts the Windows filesystem via 9p in the Linux VM, so exposing it to your Docker container is just a config issue.

> a full Linux install in a VM

Really? I always thought the subsystem worked translating OS calls back and forth without virtualizing an entire machine. It sure has an entire OS, kernel and all, but not a virtualization layer. Maybe that was the case for WSL but not WSL2?

That was WSL1 and as a result had a bunch of unimplemented syscalls.

Microsoft realized trying to keep up with the ever-growing list of syscalls on Linux is actually not practical hence they opted for the virtualized approach with an actual Linux kernel to achieve 1:1 syscall compatibility.

They released that as WSL2. Technically the name is not accurate anymore as there aren’t any “subsystems” at work anymore.

WSL1 used a concept called a pico process [1] and the pico driver that is associated with the process is forwarded the syscalls to translate to the required NT APIs. WSL2 is a VM running through Hyper-V but integrated in a way that mostly looks like a normal process. It was introduced to improve filesystem performance (on the Linux mounts) and avoid having to translate and maintain the syscalls required by Linux [2]. The tech behind WSL1 is quite fun but WSL2 certainly has better compatibility and aside from FS performance between Linux and Windows is mostly a positive.

[1] https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-pro... [2] https://devblogs.microsoft.com/commandline/announcing-wsl-2/

WSL 1 worked that way. WSL2 is a full Linux vm.

Yep, WSL1 was a translation layer. Extremely awesome but unfortunately dog slow for anything involving npm packages or large(r) PHP environments as all file accesses would go through the translation layer, the Windows filter chain (aka virus scanners) and then finally NTFS. WSL2 in contrast is a VM, which avoids all the slow paths in file accesses - all that Windows sees is a bunch of bulk block I/O to the backing file of the VM disk.

On the other hand, running Python, Go and .NET on it was a dream. Awesome development environment, and much more battery friendly, to the point where I still use it.

WSL2 is "just" Linux running in a Hyper-V VM (with some special sauce on top of it to handle things like interacting with the filesystem or doing Wayland and X11 graphics, plus containerization stuff to allow multiple distributions to be installed and run under one VM and one kernel).

WSL1 was a completely different approach, adding a Linux compatibility layer to Windows itself. There, you never had a Linux kernel running at all-- Linux syscalls would call into WSL, which would talk directly to the NT kernel to do whatever that syscall needed to do.

WSL1 didn't last very long (still present, but not actively being developed)-- turns out that reimplementing one operating system on top of another is a Hard Problem (see also: Wine). WSL2 avoids this entirely, and also avoids most of the impedance mismatches that you get when trying to reimplement POSIX on top of NT. WSL2 solved a whole bunch of compatibility problems essentially overnight that WSL1 never even got around to.

Reply on news.ycombinator.com