Hacker News Reader

Comment by kubanczyk | Hacker News Reader

The ecosystem is already there for devs, except for those interested with directly interacting with their laptop's hardware.

I've migrated from MBP to Win10 WSL three months ago and it's like a breath of fresh air for general $DayJob backend CRUD-like work. I'd still prefer a Linux laptop, but WSL is so much closer to a real Linux box.

I don't think I touched PowerShell or any .BAT stuff even once.

View on HN

WSL had horrendous I/O performance last time I tried it and it couldn't run some pretty basic stuff (e.g. headless chrome).

Virtual box is a better experience if you wanna run Linux on windows IMO.

WSL2 is a simple virtual machine. Nothing you couldn’t do on macOS with e.g. multipass.

But it’s not simple. It’s nothing like a “simple” VM.

It's a headless VM that runs on Hyper-V

Once Microsoft finishes the work on DXGI for Linux, it won't even have to be headless.

It's also very paravirtualized, which is why HyperV enlightenments are required for WSL2 guest.

That's a gross over-generalization: https://www.techrepublic.com/article/wsl-2-where-is-it-and-w....

Sure, it has some nice integrations, but I don't see how this article is in contradiction with what I've said. (To be clear, I didn't mean it as a critique, I like Hyper-V)

Not really. Under HyperV both the Windows and Linux kernel run subsidiary to the HyperV hypervisor, so in that sense Windows itself is "just a virtual machine".

The work in TFA describes patches to make the Linux kernel communicate with the hypervisor (sharing information like used memory pages). In my book that's pretty sophisticated.

EDIT: The work appears to be available on Github https://github.com/microsoft/WSL2-Linux-Kernel/commits/linux...

It doesn't matter how the hypervisor is arranged, but it is still just a virtual machine. Just because it happens to run on a type1 vs type2 hypervisor means not much, or just go ask around whether Xen is any faster than KVM these days.

But the filesystem integration is much better than a VM in macOS, being able to run Window programs from Linux, etc.

Also, Windows has decent X11 servers that work well with retina displays, which can't be said of XQuartz.

"Windows programs for Linux"? It doesn't really have any better filesystem integration. The filesystem is stored on a disk image on WSL2 as on any other VM. You can mount other host filesystems from inside the VM in any hypervisor I know of.

Ack on XQuartz being crap (thought it does have Retina support these days, at least for non-rootless mode), but this is not really a problem of the VM.

"Windows programs for Linux"?

Whoops, typo. Windows programs from Linux, I'll fix that.

You can mount other host filesystems from inside the VM in any hypervisor I know of.

In most hypervisors you can't do a

  notepad.exe foo.txt

  TextEdit.app foo.txt

for that matter in a Linux VM,

With virtio-fs I think this is becoming more doable. Of course, it's not quite as fast as running a guest filesystem on virtio-blk yet, but maybe it'll get there.

WSL can run `notepad.exe foo` from bash. Not only fs integration.

> WSL can run `notepad.exe foo` from bash.

Isn't that just a binary loader, like you can do with wine/qemu on any Linux? Surely it's mostly just proxying the pipes, replicating the working directory, and maybe keeping some of the environment variables. The filesystem integration seems like the trickiest part of that altogether.

It works so crazy well that sometimes it works and then I stop and think: how did that work.

Example: I type code ./somefolder in WSL and it opens VSCode on Windows, editing the folder I specified.

Edit: danieldk replied just before me, but I think my answer adds to that instead of just duplicating danieldks.

Also danieldks answer highlights something important: it doesn't seem to be just magic shell wrappers (or if it is they are truly magic).

VSCode is somewhat special when it comes to editing files, Notepad is not.

The filesystem integration is not without flaws though, it doesn't seem to implement full posix semantics.

Many times in WSL2 I've had a git rebase fail because it couldn't overwrite existing files, and every time it could be fixed by just running git rebase --continue. The actual problem seems to be that WSL2 system calls return before the NTFS operation completes, so quick successions of create-after-unlink or write-after-rename can have unexpected results.

For this reason I still keep a WSL1 environment, it doesn't have the same issues (and doesn't appear to be any slower for filesystem operations).

> For this reason I still keep a WSL1 environment, it doesn't have the same issues (and doesn't appear to be any slower for filesystem operations).

It's definitely a great deal slower for filesystem operations inside the Linux system. Filesystem operations outside the VM's disk image go through 9p, which gives you basically the same performance for both.

Also networking. e.g. you can spin up a Node.js server in Linux then connect to it with Chrome on Windows at http://localhost

WSL2 is a simple VM like Docker is a simple Linux container.

It's really not. With WSL2 the kernel runs in a VM, but user-space programs do not. As a result, CPU-bound programs suffer close to zero overhead compared to running natively on linux.

AFAIK, there's no way to achieve anything like this on macOS.

Do you have any source/documentation for this? I'd really like to read more about it, my understanding has always been that WSL2 was more or less a classic VM on a type-1 hypervisor (Hyper-V)

That is not quite correct, it is in WSL1 that they are NT processes, with Linux syscall emulation.

But in WSL2 the whole thing runs in a Hyper-V VM, with a customised Linux kernel (available via http://linux.microsoft.com) to help with interoperability between WSL and Windows.

You got it completely wrong. WSL1 was a system call translation layer, and everything worked directly on the Windows kernel, like Windows programs do under WINE. WSL2 is an standard Hyper-V virtual machine, no more no less, with a custom Linux kernel build and a ext4 root filesystem stored in a .vhdx image. Every process runs as a native Linux process under the Microsoft's Linux kernel, _inside_ the VM. What makes it more convenient than simply opening the Hyper-V manager and creating a VM is ease of installation, maintenance and integration with Windows (using the 9p protocol to allow file access).

And you got it all wrong :p. It’s not a “standard Hyper-V virtual machine” you can’t make one from scratch.

With "standard Hyper-V virtual machine" I mean that's like every other VM, because it runs under its own instance of vmwp.exe, spawned by vmms.exe, like every other one you may have in the system.

Now I want to take those executables apart and see if it does any special handling.

Reply on news.ycombinator.com