State of WSL1 #4022
Replies: 65 suggested answers 15 replies
-
|
You want reddit. |
Beta Was this translation helpful? Give feedback.
-
|
@therealkenc what I want is an honest response from the WSL developers, so I can decide whether it is worth to continue investing on their platform. The constant change of platform/API direction is IMO what contributed to MSFT's developer mindshare decline in the mid-00's. I was an MSFT employee at the time. |
Beta Was this translation helpful? Give feedback.
-
|
The honest response is:
The good sport response is discussion threads are left open for a while until they have run their course, in the off chance some actionable comes of it. n.b. I have never seen anyone at MSFT participate in a discussion thread on this github for the last two years (or maybe three, there were a couple of discussion-ish replies in the early days). Because, see, not a discussion forum. |
Beta Was this translation helpful? Give feedback.
-
|
@therealkenc understood and thanks for your understanding. My hope is that even if nobody from MSFT decides to respond, the relevant people might still take notice and decide to eventually clarify the WSL1 status through some form of public announcement. |
Beta Was this translation helpful? Give feedback.
-
|
Take a look at https://mybuild.techcommunity.microsoft.com/sessions/77003 from about 18:00, the discussion of file system differences with regards to open file descriptors. I get where @benhillis comes from when he says "we can't change this, we'd risk breaking existing Windows applications". As per discussion by @therealkenc in #3451, and a whole host of related issues around how Linux and NT kernel handle file systems, some of these issues may not be fixable in WSL 1 without running into the app compatibility issues in Windows. The behavior is so fundamentally different that files inside WSL that live on a Windows file system cannot behave the way Linux expects them to, in every respect. Edit: Should have watched more of that video - Plan 9 and ext4 is the way WSL2 handles access to Linux files from Windows, and if WSL 1 has to have a chance to fix some of these fundamental differences, it might also need an ext4 - just without the benefit of a Linux kernel to drive that. Whether that kind of heavy lift is warranted for WSL 1 is a good question. |
Beta Was this translation helpful? Give feedback.
-
|
The central arguments of WSL2 vs WSL1 appear to be that:
Regarding 1. Yes, I agree: full system call compatibility is hard to achieve. This is exactly what makes WSL1 an interesting and non-trivial project. But Linux is a finite kernel and they would eventually catch up. This is assuming that the internal funding was there, which is perhaps the real reason behind these changes here. Regarding 2. Which file system performance? That of their root file system ("VolFs") or that of accessing Windows drives ("DrvFs")? They have not been explicit on this. I find it likely that DrvFs (i.e So the performance improvements must be primarily with the root file system (VolFs in WSL1). My contention is that they could have achieved those performance improvements by writing a WSL1 disk file system on top of a raw disk partition or VHD together with a POSIX file system cache. I understand that is a non-trivial undertaking, but again this is what made WSL1 an interesting project and worth attention IMO. Perhaps Microsoft might consider this: Do not sunset WSL1. Open source it. I find it very likely that the community will continue to build it for you. |
Beta Was this translation helpful? Give feedback.
-
|
I believe I've read almost the entire thread (except for 20-something hidden messages in the middle). And for me, THIS is the definitive comment, along with that one and the others that bring initiatives such as CoLinux into the discussion. WSL 2 feels like a joke when compared to the latest state of WSL 1 which is a (simply brilliant) actual subsystem or translation layer that brings Linux into Windows. WSL 2 differs too little from what all of us used to do before the advent of any WSL: run some headless VM on a hypervisor of choice (Hyper-V, VMWare, VirtualBox or whatever) and access it via SSH and/or some other interfaces (Xming/VcXsrv, NFS, Samba, some Host->Guest USB device sharing feature and a virtual network stack with or without NAT). I really hope Microsoft doesn't sunset WSL 1. I ask, I urge them not to. |
Beta Was this translation helpful? Give feedback.
-
In the mean time, the community of NT kernel developers could work on making winfsp or dokany or zfs or ext23fsd or winpcap better. It is unfortunate that after 684 Windows NT kernel devs became available to work for free, those projects (and many others) didn't get more help. [A few hundred devs banging on colinux would go a long way too if you got vm skillz.]
Been meaning ask over in #1529 about that part of the video. |
Beta Was this translation helpful? Give feedback.
-
Just voted for this! Raees Iqbal wrote on UserVoice:
Can Raees Iqbal see into the future? :) |
Beta Was this translation helpful? Give feedback.
-
It's locked and can't be voted on AFAICT (count still 684). You probably voted on it in 2016. n.b. re-opening it wouldn't actually change the number of NT kernel developers (such as yourself! |
Beta Was this translation helpful? Give feedback.
-
I thought the behavior was somewhat weird. Once I clicked on the "Vote" button, it recognized the email address I supplied, but the vote count didn't change. I ascribed this to an aging/faulty brain and sensors attached to it, but turns out the signal was correct ("the vote count did not change") and the interpretation was wrong ("the vote count did change, you just missed it" :) |
Beta Was this translation helpful? Give feedback.
-
|
I would personally say kill WSL1 completely. WSL 2 they are build a Linux kernel. http://www.colinux.org/ Full system call compatibility is hard to achieve. Multi groups have attempted Linux syscall emulation. Reality is you want Linux syscall compatibility that is in fact correct you have to really bite the bullet and use a Linux kernel. |
Beta Was this translation helpful? Give feedback.
-
The earliest that could possibly happen is Jan 9th 2029. No sense fretting about it now. Edit: I just realized I may haven taken your comment too literally. If by "kill off completely" you mean "remove the ability to run WSL 1 in some future version of Windows", not "stop supporting it entirely" then yeah, that could happen much earlier, subject to how well WSL 2 meets enterprise needs and what the uptake of each version is over the next 2-3 years. The amount of resources WSL 1 will receive will be "based on user feedback" as per the presentations we have seen. Ability to run Virtualbox and VMWare Workstation has already been highlighted as important to enterprises. I can see a future where the Hyper-V hypervisor learns to "play nice" with other virtualization tech, and that in turn makes WSL 2 more compelling. Networking has been highlighted as another area that's being looked at. I expect WSL 1 will receive diminishing resources, but not be "killed outright", as long as those big bugbear issues with WSL 2 can be handled, and enterprises adopt WSL 2. And where we are in 2029, well, I wouldn't hazard a guess. Three years ago I didn't think a Linux kernel in Windows would be a thing, never mind any thoughts I might have had ten years ago. |
Beta Was this translation helpful? Give feedback.
-
There's been improvements as of the April 2018 update. I managed to get a nested hyper-v and qemu guest to play nice side-by-side inside Win10 guest/host inside a Linux kvm host. I haven't tested VBox or VMWare, but if they don't work already I am sure they will post haste. I had been (mildly) concerned about the scenario but turns out that's oldthink.
|
Beta Was this translation helpful? Give feedback.
-
|
@therealkenc wrote:
I finally had the chance to review this issue. This is of course an artifact of VolFs being based on NTFS. However I believe VolFs could perhaps have worked around this if instead of using The relevant code in FastFat appears to be this one: link. Oplocks make this code increasingly hard to read, but the crux is that if you have an open handle on a file under a directory and you try to rename it you will get Notice that this is not true for memory mapped files without A file that is memory-mapped like this can have its ancestor directories be renamed just fine. Since the location of the VolFs backend storage was an NTFS directory that Windows applications were not supposed to touch, I do not get the "compatibility" argument. EDIT: I should also add that the memory mapping is a user mode trick for having a |
Beta Was this translation helpful? Give feedback.
-
Yes, they need(ed) an indirection (of one sort or another, implementation detail aside). All academic at this point.
Yep. At least flying at 40,000 feet, an approach would be to forget all the NT reads/writes, map everything, make the WSL1 read/writes memcpies. At least for local filesystems. Maybe. But I suspect there would have to be engineering on the NT side to make it work (or make it work right), and NT changes haven't been real forthcoming over the last three years. Or that is my mostly uninformed impression from the outside, anyway. The big thing we've lost with WSL2 is a shared MM. [We've also lost a shared network, but that's maybe a feature not a bug.] In WSL2 everything has to be marshalled with dmabufs. But you weigh that against having to rewrite Linux, I guess. [edit]
Thank God you said it first, not me. The video implies this is axiomatic. Usually when one says something like (paraphrased) "fixing the rename directory problem would definitely break things" (including the adverb), you might want to finish that sentence with a: "...definitely break things like [insert obvious breakage example]". Even if it did break things (okay), it is nothing a flag wouldn't fix -- making the MSYS2/Cygwin people happy. But I'd settle for the example, and concede "oh, you're right, that" if one were presented. |
Beta Was this translation helpful? Give feedback.
-
|
Personally, those 5% matter and feel like way more than 5%. FS performance is actually decent now, Docker works, anything Berkeley DB works, Swift works, Raku works, basically all the stuff that refused to work before, now just does. Yay having an actual kernel. It feels like a big step in the right direction. For those folk that prefer WSL 1, happily it's still around. |
Beta Was this translation helpful? Give feedback.
-
|
Personally, I really hope WSL1 still gets a bit of TLC and isn't outright dropped, even though I fully understand why WSL2 might end up being the future of the WSL story. For my workload, the benefits of WSL1 are:
So for my workloads and use, WSL2 brings absolutely nothing to the table, and in fact actually has the significant usability drawbacks with networking and startup latency. I totally respect that I could be an outlier as a WSL user, but from the feedback in this issue I suspect that I'm not. Even though WSL1 might be at 90% completion with the last 10% impossibly difficult to implement, I suspect that the current 90% of functionality is actually good enough for many, many developers. |
Beta Was this translation helpful? Give feedback.
-
|
I am very happy when WSL 2 comes and tried it with a so much enthusiasm, however I found it is not good as it is described or as good as what i expected in the end.
I switched back to WSL and i felt better. I am glad that wsl will not in sunset and I hope it will be in development continuously. |
Beta Was this translation helpful? Give feedback.
-
|
Further to my earlier messages about working on FUSE for WSL1: it is almost baked. Public release will follow soon. In the screen cap below you can see unmodified Linux SSHFS running under WSL1 and used to browse the source code of WinFuse (the project that makes FUSE for WSL1 possible). The file system is presented as the Windows drive
|
Beta Was this translation helpful? Give feedback.
-
|
FUSE for WSL1 is now available: https://github.com/billziss-gh/winfuse/releases |
Beta Was this translation helpful? Give feedback.
-
|
I notice you say you use the same model as Cygwin and Services for Unix for permissions. You should actually utilize the metadata options in |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
I am aware that WSL1 uses a different model for permissions than SFU and Cygwin and intend to fix this issue in wslfuse (i.e. the WSL1 portion of the WinFuse project) prior to the final release. |
Beta Was this translation helpful? Give feedback.
-
When I watched the original presentation, the only feeling i got was: We have to try to sell that we pulled the plug and have to replace it with something that is not even innovative. Honestly WSL1 got me excited, WSL2 just brought me back to capitalist reality. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
WSL2 is quite strange. It is basically a headless vm with bridged/host only networking running on top of Hyper-V. It seems like it would have been better to support virtualbox and make that leverage Hyper-V or make Hyper-V much better for devs with a seamless/unity mode if they were really going to abandon WSL1. The amount of workarounds and attempts to get things working in WSL2 is just silly compared to me installing any distro in vbox and it works without much fuss. If anything I think WSL2 has been a disaster from my experience and for MS as it has made me think about building a fully fledged Linux machine in the future to avoid the performance penalty of a VM, the superior window management of i3 for dev work, arguably the inability of MS to release a non-fragile alternative to a normal VM or even container, and their lack of resolving issues that have been around for many months. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
First: There is not NIC Bridge Mode in WSL2. Secondly, have you seen the Phoronix benchmarks? Even with the old LTS kernel being used now, it can actually perform better or be on par with Real Linux. In fact, it can even perform better than Windows in some cases. You are thinking of WSL2 like a traditional VM. It is not. It's a microVM using namespace containment for each distro. That is how they all use the same kernel. The only perf that still needs working on the most is the interop with Finally, all those workarounds you complain about it are a no-op in WSL1. Be grateful you can even use those workarounds. Before WSL2, you would be trying to find even crazier workarounds to finagle with NT magic to get WSL1 to do even more than it does. They have literally announced GUI and GPU compute are coming for WSL2. They just released mounting ext4 drives and possibly others into WSL2. This is huge as USB support as primarily a thing of WSL1, within a limited capacity. Yeah we need systemd still and for the propriety init to turn into a daemon instead but the workarounds for those aren't terribly hard. Many workarounds aren't that hard. People already spent time blogging and creating scripts to make those workarounds get applied quickly. Have faith in the WSL community and don't complain about spending a few minutes to get something running that wouldn't otherwise. It's not a big deal. Once it's set up, just be sure to make a backup of the distro afterwards. Now you never need worry about doing it again. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
I compared WSL2 to essentially using that networking mode in a VM, not that it literally uses that mode. Secondly, benchmarks only matter if your system works and works well. Should I show you the numerous networking doesn't work issues, all the attempts to fix it, and the length of time it has essentially gone unaddressed or the hundreds of other issues listed or my own list that I started to keep to get stuff running OOB compared to a normal distro's OOB experience. Based on https://blog.logrocket.com/working-with-node-js-on-hyper-v-and-wsl2/#:~:text=Comparing%20Hyper%2DV%20to%20WSL2&text=The%20user%20interface%20allows%20you,access%20to%20the%20virtual%20machine. A Hyper-V vm offers supposedly offers ~5% less performance. So the argument isn't ever just WSL2 vs WSL1. It is WSL2 vs WSL1 vs type 1 virtualization vs type 2.
I don't need workarounds in a proper VM as it works with barely any fiddling. Basically your premise is WSL2 is better than WSL1. You assume I think WSL2 is worse than WSL1. On a technical level, yes it is worse to me as they basically threw up their hands and abandoned ship to use a VM. On a practical one, I could careless how it is implemented if WSL2 is better than WSL1. The issue is that WSL2 is arguably worse today than simply using a VM and not having to deal with workarounds. I can remote code on my VM almost as easily as WSL2. If I really need folder access outside of the VM I can set that up too and I already get GUI support. I'm sure WSL2 when it matures will be better, but based on the quality of the WSL2 release today I'm expecting that to take at minimum 6 months if not several years. |
Beta Was this translation helpful? Give feedback.
-
|
I agree that if you're looking for all the stuff that you can expect from a traditional VM, we're got a few years to go. But there's still much you can do on your own now so you don't need to wait. That is the point of the workarounds. It's understood that WSL2 has plenty of room for growth. They are trying to tackle the biggest feature requests that have already been patiently awaited for several years already. Having some issues that can be worked around is much more acceptable than waiting several more years for the top requests for WSL to go ignored. Problem is the WSL code or the WSL2 microvm code isn't OSS (although apparently we might soon see Hyper-V running natively on Linux so it's quite close from that perspective). The other problem is the amount of devs assigned to WSL in general. They are a small team. Just like the Windows Terminal/Console team is small. If you stop to think about it, every single CLI team is small. In some cases, being open-source helps push things faster (Powershell for instance), in other cases like WSL, we are stuck being beholden to waiting for a few devs to get to it. What should happen is MS should step up the amount of devs to support the CLI. Both developers, who are developing for Windows, and system administrators who manage Windows require a good CLI experience. We have that now but it can be better. So send your feedback to a channel that can actually make impact. This isn't the best forum for exercising change within MS. |
Beta Was this translation helpful? Give feedback.
-
@Akkuma spoken my pain as well. The network performance on WSL2 really a trade off compare to WSL1. Never thought virtual switch causing such a big different. There were long discussion on #4901 but no update from MS yet. |
Beta Was this translation helpful? Give feedback.
-
|
@Akkuma Basically nailed it. WSL2 feels like one big workaround. I respect that this isn't exactly where the decision is being made but also Microsoft employees need to respect that as a customer this is a different time. Putting aside the fact that I'd had been using Windows since Windows 3.1 and never had my feedback actually be heard in that entire time why would I go and "give feedback" when I could just go and install Linux and not have to deal with the Windows ecosystem at all? In the past few years when I do a fresh Windows install I've always had to run Debloat tools, then have to jump over hoops to install my dev setup. It's no longer a 100% guarantee that I will even be using Windows. These days it's a very negligible benefit. Office and Photoshop are the only things that don't work if you want the latest and greatest. My entire tool chain these days works out of the box on Linux. And so do my games. With WSL1 I might have actually used Windows as a Linux server without sacrificing any performance. But now that's not possible so there's nothing Windows brings to the table. It's quite the opposite really. I am in this weird position where using Windows is actually a lot more work / maintenance / down time than using Linux. But Windows actually costs money. The reason I was excited for WSL1 was because I thought you might add Linux style system calls to the Windows kernel. But that's clearly not happening. But maybe it should. |
Beta Was this translation helpful? Give feedback.
-
|
WSL1 was such a great concept that worked almost flawlessly for my needs (full stack web development) and worked well with existing ecosystem. The only drawback was a terrible IO performance and lags/crashes associated with intensive IO work. But at least it worked unlike WSL2. With WSL2 as other people said we have lots of unresolvable issues or hacks + a hyper-v vm that nobody asked for. Now I can’t work with vagrant and virtualbox, have lots of problems with wsl2 itself and etc. If WSL1 is not actively supported I guess it’s just simpler to switch to Linux. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
WSL1 is a pain for those who develop it because they have to account for the ever increasing amounts of syscalls that Linux supports to be mapped to Windows syscalls. Correct me if I am wrong @craigloewen-msft |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
The networking issue is a black eye with no explanation. Bridge mode is the easiest thing in the world to support, given that IT'S PART OF HYPERV. Not doing it is some deliberate choice on their part, but it's unclear why. File system performance is a tradeoff either way. I switched to improve performance, and was disappointed at the windows filesystem regression. But at least I can see the tradeoff. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
I have problems with WSL2. In particular, that requires Hyper-V to be enabled, and that is not compatible with other virtualization software, such as VMWare. Even if it should be compatible now, I found many issues especially on Windows 11 and disabled it. Also, reguarding the support of all systems call, it's not necessary. In my experience WSL1 runs fine any software that I did run. Glibc is very roboust in the sense that if it doesn't find a system call it will try another one. So even if the most new system call are not implemented, that doesn't imply you can't use the latest userspace software. Reguarding filesystem performance it's true, but it's also true that on WSL2 working on the Windows filesystem is slower than WSL1 since it will pass trough a network connection. So it depends on what you are doing. A feature that I like of WSL1 is that you can see all the network interfaces on your system (and thus start development server to listen without creating a bridge/NAT port forwarding), and also the fact that serial ports are brought in the WSL (useful feature for embedded developers like me). |
Beta Was this translation helpful? Give feedback.
-
|
Silly question, but has anyone forked this WSL1 ? And indeed, though it's open source, can anyone build it ? |
Beta Was this translation helpful? Give feedback.
-
|
Nobody has forked it because it is not Open-Source. |
Beta Was this translation helpful? Give feedback.
-
|
Cheers, just realised this is only for issues, not WSL itself - which is a little unusual to find on github. |
Beta Was this translation helpful? Give feedback.
-
|
And there are more weird options. For example the Xaml repo has the source code of WinUI 2 but has the issue tracker for WinUI 3 too which is closed source. |
Beta Was this translation helpful? Give feedback.
-
|
The closed source model ends up being weird when bits of code are exposed. As mentioned elsewhere in this thread they should open source WSL1 if they are going to abandon it, though still - I'm not sure it would be picked up, but it would be better than nothing. |
Beta Was this translation helpful? Give feedback.
-
|
WSL1 is much more intricately tied to the Windows NT kernel, and so I suspect it would require open sourcing much of the NT kernel for anyone else to do something with it.
Microsoft owns GitHub and so teams are certainly encouraged to use GitHub even for less open stuff - hence the issue tracker being homed here.
But since this issue was started, it’s fairly clear Microsoft intends to dead-end WSL1 until someone else in Redmond needs it. Much like how PowerPC/RISC usage of the NT kernel was necromanced for the Xbox 360.
… On Sep 13, 2022, at 3:11 PM, Stuart Axon ***@***.***> wrote:
The closed source model ends up being weird when bits of code are exposed. As mentioned elsewhere in this thread they should open source WSL1 if they are going to abandon it, though still - I'm not sure it would be picked up, but it would be better than nothing.
—
Reply to this email directly, view it on GitHub <#4022 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASAJYG3IWP4GTKQTBZ72J3V6D3YDANCNFSM4RGAMDAQ>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
-
|
I wonder if their support for Android is based on WSL1 or WSL2. You could imagine them wanting the tighter integration WSL1 brings. |
Beta Was this translation helpful? Give feedback.
-
|
WS for Android is based on WSL2.
…On Tue, Sep 13, 2022, 5:46 PM Stuart Axon ***@***.***> wrote:
I wonder if their support for Android is based on WSL1 or WSL2.
You could imagine them wanting the tighter integration WSL1 brings.
—
Reply to this email directly, view it on GitHub
<#4022 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AASAJYHW6FSBGA7F7L53DC3V6EN6HANCNFSM4RGAMDAQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I like WSL1 and hope it continues to be updated. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
I am finding it hard to square this up with knowing WSL1 has been broken in Windows Server 2022 ( Issue #7480 ) since RTM. These BSOD's were resolved a year ago for Windows 11 insiders (22H2) but Windows Server 2022 was left twisting in the wind. WSL2 was added into Windows Server 2022 at the last minute, but it's not possible to fix a bug in WSL1? It's not like we're asking for feature enhancements - Please let this be just an oversight and not a sign of WSL1 code going from "maintenance mode" to "outright neglect". |
Beta Was this translation helpful? Give feedback.
-
|
Sadly I agree with you. We are getting bad reviews in Pengwin and Fedora due to distros are getting more and more incompatible with WSL1. And worse regularly the fail is on package management. We will ultimately decide to have stable legacy versions only for WSL1 or redirect everyone to Pengwin Enterprise 8 that still expects a 4.x kernel. |
Beta Was this translation helpful? Give feedback.
and others
{{title}}
-
Your blog posts here and here shed some light on your new direction with WSL2. However there are some questions about the state of WSL1 that I am hoping to get addressed.
I personally find WSL1 a fantastic effort that was pushing the boundaries of OS research. In comparison WSL2 feels like a copout. In your blog posts you suggest that file system performance was an issue and I have seen the same in some GitHub comments. Your blog posts do not specify if the performance improvements in WSL2 are related to what you call VolFs or DrvFs. I expect that WSL2 VolFs performance is better, but I believe that you could have improved VolFs performance in WSL1 by running it as a file system on top of a raw disk partition or a VHD rather than emulate it via NTFS. I expect that WSL2 DrvFs performance is comparable to the WSL1 one, because in both cases you have to go through the Windows file system stack and NTFS.
A well-defined future for WSL is important if you wish for platform developers to engage your product seriously. Recently I became interested and started researching the internals of WSL1 for a dual purpose: (1) to add support for WSL1 to my project WinFsp, and (2) to create a development kit for WSL1 that would let third parties write drivers for WSL1. My ultimate goal was to (possibly and eventually) develop a FUSE driver for WSL1. Obviously your announcement takes the wind out of these sails.
I am also hoping that you open up
PsRegisterPicoProviderto allow third parties to write their own "library" OS'es. Consider this my "formal" request :)Beta Was this translation helpful? Give feedback.
All reactions