Although many people seem to be receiving the WSL2 news well, I am one of the few that feels that we will be missing something important with this new direction.
WSL1 was pushing the boundaries of OS research: - a method for having multiple syscall interfaces in a mainstream OS - processes in WSL1 were real NT processes (even if lacking some of the NTOS environment) - direct integration with the rest of the OS without an awkward VM separation layer.
In comparison WSL2 is basically an optimized VM with some fancy guest additions. Color me underwhelmed.
I understand the argument that WSL2 is faster than WSL1 in file system operations. I expect this will only be true for their root file system ("VolFs") and that performance will remain same or suffer for Windows drives ("DrvFs"). I am certain that they could fix "VolFs" performance by moving the file system of NTFS and into a raw disk partition or VHD. (Note: I write file systems both in and out of kernel.)
Finally WSL2 will be distributed with Windows which raises some licensing questions (IANAL) if not in the letter of the GPL license at least in spirit. I write GPL'ed software myself and I would be somewhat miffed if I saw my software used in a similar manner (i.e. "via a VM", but still distributed with non-GPL code).
As described in the Video, they could not keep up with feature parity of syscalls in Linux and some concepts are simply incompatible with the two systems. They reference the concept of open file handles and moving folder structures.
I think they found the boundary of OS research in this case, and a better product is using the actual Linux kernel.
> Finally WSL2 will be distributed with Windows which raises some licensing questions (IANAL) if not in the letter of the GPL license at least in spirit. I write GPL'ed software myself and I would be somewhat miffed if I saw my software used in a similar manner (i.e. "via a VM", but still distributed with non-GPL code).
Mere aggregation of non-GPL code with (“distributed with”) GPL code expressly is consistent with the GPL, it is contrary to neither letter nor spirit of the license.
I was initially very excited for WSL2, but I do worry it will require Hyper-V to be enabled. I use VMWare Workstation and it’s a true pain to switch Hyper-V on and off. Also, I cant help but worry that this will somehow be a downgrade in some way... will it be just as integrated? Windows Firewall worked on WSL Pico processes for example.
I hate the way HyperV messes up networking with its virtual network adapters. It gets complicated with a VPN or LTE connection really quickly. Maybe I’m just doing it wrong, but I’ve never found networking to work properly on a machine with HyperV enabled.
Switching to a virtualization model feels like a step backwards. If I wanted a virtualized Linux on Windows, I’d run a virtual Linux on Windows. WSL is special because it’s a middle ground.
if it needs hyper-v, then what's the point? how is it fundamentally different from just running ubuntu in virtualbox with a shared network drive, then? except where the terminal window is?
> Windows Firewall worked on WSL Pico processes for example.
In WSL1 they share the same IP addresses and TCP/UDP port space, while WSL2 has an separated IP address. I suppose there is some NAT to make the network working in WSL2.
At the end of Q&A part they mentioned that sharing localhost, IP addresses, and port number space (which is a WSL1 feature) may be done in future, but they have no roadmap for it right now.
Switched to Windows from Linux on my work laptop 6 months ago. First-class support for Zoom, Office, screen-sharing, presenting, etc. is good. General terminal-based development is not fantastic, but WSL made it possible at all. I can run all but my most Linux-specific programs (e.g. dependent on procfs).
Aside from not have some Linux pseudo-filesystems the bigger issue has been the speed of file operations. I dread having to run `dep ensure` and `yarn install`.
Why not just Hyper-V? Every few weeks I try to figure out how to set up a static IP but I cannot for the life of me. So it takes 1-2 minutes every time I want to reconnect because not only does it get a dynamic IP by default, it is reset every day or so. Need to go into the VM via Hyper-V, get the current IP address, reset /etc/hosts within WSL, reset /etc/hosts within Windows, SSH into VM within WSL. It drives me nuts.
Really looking forward to WSL2 for faster file operations and being able to run all my programs.
Are there any plans to support graphical guest applications running in a native Windows window, like VMWare Fusion? Their client/server VS Code demo where only the UI runs in Windows seems really bizarre to me. Why not just run X? I suppose you could pipe X over SSH but it would be nice to get built-in support without the hassle or performance penalty.
This is already supported in HyperV VM, and the concept is old: it is called ballooning.
Basically a driver in the Linux guest (hv_balloon for HyperV, but you have the same things for KVM, VMWare etc.) can artificially "inflates" its memory use when detecting too much unused memory and give it back to the host. When the guest needs more memory, the balloon driver will give the memory back. Couple with hotplug memory support and things can be pretty dynamic.
Not sure if they do something more sophisticated for WSL2 though.
I'm pretty sure the Linux side owns it's own FS cache. The whole point of this release is just to run a real Linux kernel in a VM in order to increase FS perf. I'm not sure how you do that and divorce it from the Linux kernel's FS cache.
I'm surprised, is integrating a Linux kernel with Windows not a GPL violation? Is this a "mere aggregation" situation? Are the Linux kernel and other closed source Windows code at no point linked, or exchanging complex internal data structures?
Given that it requires HyperV it’s running in a manner similar to a VM. That doesn’t require linking and any I/O occurs via the normal channels (CPU interrupts, serial console, etc).
This is similar to how running a userland application on Linux doesn’t require the application to be GPL’d because it’s not directly linked to the kernel. While it interacts with the kernel it is not derived from it.
The interpretation around what "linking" means in the context of the GPL is a full-time job. At the least, the literal interpretation I was raised with has never been the official position of the FSF. For example, just because you link a library statically doesn't mean you're GPL-violating. You need to for example, swap complex data structures in some complex control flow to cross the line.
Even then there are still more exceptions for 'runtimes' and suchlike where while in a literal sense, the final assembled program when executing is linked against GPL source the result is not considered to be covered by the GPL.
None of this stuff is actually part of the license text -- it's built on precedence and common understanding. These things are a lawyer's job, we're just engineers
It’s just another app that runs on Windows. They’re moving from a white-box implementation written by Microsoft of Linux kernel with no GPL code, to just shipping the thing in a VM and be done with it. I can’t say I blame them, WSL always had its rough edges and it breaks in unexpected ways.
I was thinking about this issue on binary blob driver like nvidia's.
GPL is a clever hack of copyright law. It grant derivative works a copyright permission under the condition of accepting the same license.
Now, Windows kernel and Nvidia's binary blob driver exist without relying on Linux kernel at all. How could they be considered as a derivative work in terms of copyright law? Since GPLv2 relies on copyright law, it has no effect on situation where copyright law doesn't allow exclusive right.
For Nvidia's driver, Nvidia released a thin shim wrapper code as GPL which interface between Linux API and Nvidia binary blob driver API. But the core Nvidia binary blob driver existed independently from Linux kernel, it can't be a derivative work of Linux kernel.
For WSL2 case, Microsoft may take the same approach. They may release a thin shim wrapper which interface Linux kernel and Windows as GPL. But Windows kernel itself cannot be a derivative work of Linux kernel if it's separated well.
Why would it be? There are specific things you have to do for your code to be considered "integrated" with GPL code and as long as you avoid that there's no issue.
I'd be interested to see a Microsoft backed Wayland implementation to support GUI apps. Basically very similar to how Chrome OS has done it with Crostini. If you're interested too vote here:
I'd really like for this to support accelerated graphics - unfortunately I imagine that would require a comprehensive solution to GPU virtualisation at the DirectX level, which would at least need to be implemented in drivers - if not also supported at the hardware level.
Without that, then the main reason that I'd even be using the subsystem - GPU compute - is unavailable, and I'll need to actually boot into Linux if I want to do anything useful.
Sounds like Docker for Mac for Windows. Might have some of the same shared FS consistency issues from running two full kernels with their own FS caching hierarchies.
Why isn’t windows just built on Linux at this point are there reasons for MS to maintain their own kernel? There must be people inside of MS asking this just like how edge is now built on chromium...
While all my servers are Linux, on the Desktop it is my last choice. Interesting enough I used to love customizing the window manager to death but I'm older now and I just want something that is consistent and works out of the box.
Macs work really well out of the box but with some tweaks WSL makes Windows a quite decent development workstation.
Currently I'm using Windows + WSL and I'm quite satisfied. Looks like with the new version some of the tweaks to use docker are not necessary anymore. Great work, Microsoft, keep the pace.
I've been using Ubuntu on my primary work laptop for years now, and the only real sticking point is video conferencing. Skype for Business and Webex barely work. Google hangouts is n't bad, but often runs into audio trouble with pulse and alsa.
And the real trouble is that you can't just go find the one that works. If your co-workers all use webex then you're stuck.
[+] [-] billziss|6 years ago|reply
WSL1 was pushing the boundaries of OS research: - a method for having multiple syscall interfaces in a mainstream OS - processes in WSL1 were real NT processes (even if lacking some of the NTOS environment) - direct integration with the rest of the OS without an awkward VM separation layer.
In comparison WSL2 is basically an optimized VM with some fancy guest additions. Color me underwhelmed.
I understand the argument that WSL2 is faster than WSL1 in file system operations. I expect this will only be true for their root file system ("VolFs") and that performance will remain same or suffer for Windows drives ("DrvFs"). I am certain that they could fix "VolFs" performance by moving the file system of NTFS and into a raw disk partition or VHD. (Note: I write file systems both in and out of kernel.)
Finally WSL2 will be distributed with Windows which raises some licensing questions (IANAL) if not in the letter of the GPL license at least in spirit. I write GPL'ed software myself and I would be somewhat miffed if I saw my software used in a similar manner (i.e. "via a VM", but still distributed with non-GPL code).
[+] [-] mey|6 years ago|reply
I think they found the boundary of OS research in this case, and a better product is using the actual Linux kernel.
[+] [-] dragonwriter|6 years ago|reply
Mere aggregation of non-GPL code with (“distributed with”) GPL code expressly is consistent with the GPL, it is contrary to neither letter nor spirit of the license.
[+] [-] schwede|6 years ago|reply
[+] [-] rjsw|6 years ago|reply
[+] [-] jchw|6 years ago|reply
[+] [-] OkGoDoIt|6 years ago|reply
Switching to a virtualization model feels like a step backwards. If I wanted a virtualized Linux on Windows, I’d run a virtual Linux on Windows. WSL is special because it’s a middle ground.
[+] [-] skrebbel|6 years ago|reply
[+] [-] sorz|6 years ago|reply
In WSL1 they share the same IP addresses and TCP/UDP port space, while WSL2 has an separated IP address. I suppose there is some NAT to make the network working in WSL2.
At the end of Q&A part they mentioned that sharing localhost, IP addresses, and port number space (which is a WSL1 feature) may be done in future, but they have no roadmap for it right now.
[+] [-] wnevets|6 years ago|reply
[+] [-] eatonphil|6 years ago|reply
Aside from not have some Linux pseudo-filesystems the bigger issue has been the speed of file operations. I dread having to run `dep ensure` and `yarn install`.
Why not just Hyper-V? Every few weeks I try to figure out how to set up a static IP but I cannot for the life of me. So it takes 1-2 minutes every time I want to reconnect because not only does it get a dynamic IP by default, it is reset every day or so. Need to go into the VM via Hyper-V, get the current IP address, reset /etc/hosts within WSL, reset /etc/hosts within Windows, SSH into VM within WSL. It drives me nuts.
Really looking forward to WSL2 for faster file operations and being able to run all my programs.
[+] [-] benou|6 years ago|reply
Regarding the networking issue, I sort of solved it by using VMBus between my VM and Windows. Shameless plug: https://github.com/bganne/hvnc
[+] [-] brianpgordon|6 years ago|reply
[+] [-] Scarbutt|6 years ago|reply
[+] [-] kevin_thibedeau|6 years ago|reply
[+] [-] Tepix|6 years ago|reply
WSL is what makes it somewhat bearable. I look forward to Windows Terminal and WSL2.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] hs86|6 years ago|reply
[+] [-] benou|6 years ago|reply
Basically a driver in the Linux guest (hv_balloon for HyperV, but you have the same things for KVM, VMWare etc.) can artificially "inflates" its memory use when detecting too much unused memory and give it back to the host. When the guest needs more memory, the balloon driver will give the memory back. Couple with hotplug memory support and things can be pretty dynamic.
Not sure if they do something more sophisticated for WSL2 though.
[+] [-] monocasa|6 years ago|reply
[+] [-] 1wd|6 years ago|reply
[+] [-] jahewson|6 years ago|reply
This is similar to how running a userland application on Linux doesn’t require the application to be GPL’d because it’s not directly linked to the kernel. While it interacts with the kernel it is not derived from it.
[+] [-] _wmd|6 years ago|reply
Even then there are still more exceptions for 'runtimes' and suchlike where while in a literal sense, the final assembled program when executing is linked against GPL source the result is not considered to be covered by the GPL.
None of this stuff is actually part of the license text -- it's built on precedence and common understanding. These things are a lawyer's job, we're just engineers
[+] [-] rolleiflex|6 years ago|reply
[+] [-] ezoe|6 years ago|reply
GPL is a clever hack of copyright law. It grant derivative works a copyright permission under the condition of accepting the same license.
Now, Windows kernel and Nvidia's binary blob driver exist without relying on Linux kernel at all. How could they be considered as a derivative work in terms of copyright law? Since GPLv2 relies on copyright law, it has no effect on situation where copyright law doesn't allow exclusive right.
For Nvidia's driver, Nvidia released a thin shim wrapper code as GPL which interface between Linux API and Nvidia binary blob driver API. But the core Nvidia binary blob driver existed independently from Linux kernel, it can't be a derivative work of Linux kernel.
For WSL2 case, Microsoft may take the same approach. They may release a thin shim wrapper which interface Linux kernel and Windows as GPL. But Windows kernel itself cannot be a derivative work of Linux kernel if it's separated well.
At least, that's my conclusion. I'm not a lawyer.
[+] [-] micmil|6 years ago|reply
[+] [-] jpeeler|6 years ago|reply
https://wpdev.uservoice.com/forums/266908-command-prompt-con...
[+] [-] arcboii92|6 years ago|reply
[+] [-] Narishma|6 years ago|reply
[+] [-] adolfojp|6 years ago|reply
"It'll be available on all SKUs that run WSL currently including windows home!"
[+] [-] arcboii92|6 years ago|reply
[+] [-] yarg|6 years ago|reply
Without that, then the main reason that I'd even be using the subsystem - GPU compute - is unavailable, and I'll need to actually boot into Linux if I want to do anything useful.
[+] [-] monocasa|6 years ago|reply
[+] [-] pdonis|6 years ago|reply
[+] [-] xfer|6 years ago|reply
[+] [-] taf2|6 years ago|reply
[+] [-] packet_nerd|6 years ago|reply
[+] [-] apotatopot|6 years ago|reply
[+] [-] scardine|6 years ago|reply
Macs work really well out of the box but with some tweaks WSL makes Windows a quite decent development workstation.
Currently I'm using Windows + WSL and I'm quite satisfied. Looks like with the new version some of the tweaks to use docker are not necessary anymore. Great work, Microsoft, keep the pace.
[+] [-] logicchains|6 years ago|reply
[+] [-] sk0g|6 years ago|reply
I like to record audio, and use DAWs and plugins/ VSTs.
What about artists who use graphic design or video editing programs? Is your use case the only valid one, for whatever reason?
[+] [-] kevingadd|6 years ago|reply
[+] [-] seanc|6 years ago|reply
And the real trouble is that you can't just go find the one that works. If your co-workers all use webex then you're stuck.
[+] [-] sameoldfears|6 years ago|reply