Live data from Hacker News

Windows Subsystem for Linux 2 Moving into General Availability

infoq.com

131–140 of 420 posts

Re: Windows Subsystem for Linux 2 Moving into General Availability

#131
post #56
post #50

Earlier quoted context omitted.

WSL (1) was what the BSD people call a "kernel personality", which allows one kernel to emulate another at the syscall and ABI level.

So WSL1 on Windows is similar to Wine on Linux?

There is a big difference in that WSL1 only needed to implement Linux syscalls, they could use glibc and all other libraries from the Linux distribution that you are running, whereas Wine needs to reimplement all Windows APIs to work with most applications.

Also, Wine is really a program on top of Linux, while personalities are a core feature Windows. At a low level, the Windows kernel is agnostic wrt. the system ABI. Win32 is just one personality of the Windows kernel, just as NT used to have an OS/2 personality to run 16-bit OS/2 programs.

Re: Windows Subsystem for Linux 2 Moving into General Availability

#133
post #105

Earlier quoted context omitted.

Windows with git and its bash installed works surprisingly well for node development. Docker doesn't work on either MacOS nor Windows, right?

Docker runs just fine on macOS. eg. https://download.docker.com/mac/stable/Docker.dmg

Docker runs in a VM on macOS, with significant penalties to filesystem speed. I haven't used it for a few years, but booting the large Rails app I work on was several times slower under Docker.

Re: Windows Subsystem for Linux 2 Moving into General Availability

#135
post #27

Earlier quoted context omitted.

> Presumably, this also means you have to have Hyper-V enabled, crippling all other VM software How does hyper-V cripple other VM software? I just had to enable it to use a prebuilt VM I need, now I’m a little worried

Last time I checked (months ago) VirtualBox just couldn't run under Hyper-V. If you Google around you'll see lots of threads, e.g. https://superuser.com/q/1208850 Apparently they claim that as of February 19, 2020, they've "Restored the ability to run VMs through Hyper-V, at the expense of performance". https://www.virtualbox.org/wiki/Changelog-6.1

I’m using hyper-v and virtualbox together, seems to be fine performance-wise. Only reason we’re using vbox is that we already have vagrant scripts set up for it and hyper-v didn’t seem to work as well as a target for vagrant.

Re: Windows Subsystem for Linux 2 Moving into General Availability

#136
post #83

Earlier quoted context omitted.

The usecase was Apple has Terminal.app, Windows has MS-DOS. Tell me which you would rather use for node and or docker development.

Windows has Windows Terminal and PowerShell, too. Apple and Linux also have PowerShell.

Presumably the draw is UNIX, not the Terminal app itself.

Re: Windows Subsystem for Linux 2 Moving into General Availability

#137
post #53

Earlier quoted context omitted.

Stop blaming Hyper-V for "crippling other VM software". You ever tried to run VBox and KVM together? It's a limitation of the processor's virtualization extension.

Problem is once Hyper-V is installed and enabled, no other VM can even be started regardless of no Hyper-V VMs actually running. This limitation does not exist on linux afaik. I have run libvirt based VMs and VirtualBox VMs at the same time on linux just fine in the past.

That’s not what’s happening. Hyper-v is a type-1 hypervisor. When it’s running, even your Windows instance is running within hyper-v. Windows 10 has the hypervisor platform that lets other vm developers hook into the hyper-v host architecture, that’s how you can get android emulators and virtualbox running under hyper-v. It all works fine but is a little unintuitive to set up.

Re: Windows Subsystem for Linux 2 Moving into General Availability

#138
post #129

Earlier quoted context omitted.

> Question -- from what I understand, WSL2 is closer to Linux running in a VM, whereas WSL1 was like a Windows kernel level version of Cygwin. Is that mostly correct? Yes, that's essentially correct. You could also think of it as WINE in reverse; one big difference from cygwin is that it runs unmodified binaries rather than needing to recompile. > prior to VMs there was a patch set for the Linux kernel porting it to…

Did WSL1 not use the same binaries as a regular distro? IIRC it will download regular x86-64 .deb packages straight from e.g. Ubuntu’s APT repositories.

I think you read it backwards. It's cygwin that doesn't. WSL1 did.

Re: Windows Subsystem for Linux 2 Moving into General Availability

#139
post #67
post #59

I am giving up. WSL1 was a great invention but Microsoft gave up on it, either because of the filesystem performance problems or because of the debuggers. https://github.com/microsoft/WSL/issues/2028 (lldb, rr, delve all affected). This looks like a dreaded case of the first 90% is easy, it's the second 90% that is hard. Imagine implementing a translator for a vast majority of Linux syscalls just to find certain flav…

WSL was very cool from a pure tech standpoint, but I've never been clear what the actual use case for it was. WSL2 seems to be more along the lines of coLinux, which I felt the same way about when it was new.

Main use case for WSL was to provide better user experience for developers working on Windows. Many modern tools are more geared towards Linux/MacOS.

Maybe there was also some long term goals, like making Windows better platform for Linux software in general (server use).

Re: Windows Subsystem for Linux 2 Moving into General Availability

#140
In WSL1, running "wsl git status" on a moderately sized repo on an NTFS (Windows side) drive or SMB file share is nearly instantaneous.

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.

Post reply on HN