[billziss]

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).

[mey]

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.

[billziss]

> They reference the concept of open file handles and moving folder structures.

I think this comment may have been disingenuous on their part. The reason is that this problem more than likely still exists in WSL2 for the /mnt/c, /mnt/d file systems (i.e. what they used to call "DrvFs" in WSL1).

WSL1 comes with (at least) 2 file systems. "VolFs" which is the file system that they use for the Linux root file system and "DrvFs" which is the file system that they use to access Windows drives (C:, D:, ...).

In WSL1 VolFs was implemented as a layer on top of NTFS, so it comes with all the Windows file system and NTFS baggage. In WSL2 they will replace this file system with a native ext4 formatted partition on a VHD file, thus eliminating the Windows I/O stack (except for READ/WRITE I/O to the VHD file).

My contention is that they could have instead replaced VolFs with a native WSL1 file system that uses a disk partition or VHD as its backend storage, thus eliminating the Windows I/O stack in the same way. They could then have implemented proper Linux file system semantics without any baggage.

> I think they found the boundary of OS research in this case

Unlikely. It would not surprise me if the changes we are seeing are less technical and more political.

[nikbackm]

> My contention is that they could have instead replaced VolFs with a native WSL1 file system that uses a disk partition or VHD as its backend storage, thus eliminating the Windows I/O stack in the same way. They could then have implemented proper Linux file system semantics without any baggage.

But that would require them to implement a new file system from scratch wouldn't it? VolFs in WSL1 relied on NTFS to do the heavy lifting.

Far easier to just let the Linux kernel handle it.

[billziss]

> But that would require them to implement a new file system from scratch wouldn't it? VolFs in WSL1 relied on NTFS to do the heavy lifting.

You are correct.

[dragonwriter]

> 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.

[billziss]

But is it really just "aggregation"?

https://www.gnu.org/licenses/gpl-faq.html#MereAggregation https://www.gnu.org/licenses/gpl-faq.html#AggregateContainer...

I do not know, but I can see arguments on both sides. This is why I would love to hear the opinion of the FSF on this.

[schwede]

I agree that WSL1 was a fascinating project. It’s too bad all that work has gone to waste.

[dragonwriter]

> I agree that WSL1 was a fascinating project. It’s too bad all that work has gone to waste.

Has it? WSL1 and WSL2 seem to be parallel alternatives, the latter isn't replacing the former now, and it's not clear that it is intended to.

[billziss]

Perhaps you are right, but to me this feels more like Microsoft hedging their bets, rather than a genuine interest in having two parallel products doing effectively the same thing (from a user perspective).

I asked the same question on their GitHub issues: https://github.com/microsoft/WSL/issues/4022

[rjsw]

Multiple syscall interfaces is how Linux emulation has been done in the BSD world for many years.

[billziss]

Yes, I am aware of the Linux emulation in FreeBSD and elsewhere.

[rjsw]

How is it pushing the boundaries of OS research then ?

[billziss]

Which systems do you think are more similar: Windows and Linux or FreeBSD and Linux?

Presenting a Linux syscall interface on top of Windows is a hard task. The systems have fundamentally different approaches to many OS functionalities. In general you cannot just 1:1 map syscalls between the two. I am very familiar with the Windows kernel and fairly familiar with the Linux kernel and I am 100% convinced of this.

This is not to minimize the FreeBSD achievement. However I expect that mapping from Linux to FreeBSD and back would be an easier task. I should note here that I only know generalities about the FreeBSD kernel and would be willing to be educated if that is not the case and done in good faith.