Contra opinion: the VM option reduced the service interface between Windows and Linux to a single kernel implementation and a few drivers, rather than every possible userspace program ever written. It's an amazing and obvious trade off. My inner architecture astronaut appreciates all the ideas in this post, but I've been trying to kill that guy for over a decade now. The bottom line is WSLv1 design SUCKED precisely because it tried to cross-breed 2 extremely complex semantically incompatible systems.<p>Example: Linux local filesystem performance mostly derives from the dentry cache. That cache keeps a parsed representation of whatever the filesystem knows appears on disk. The dentry cache is crucial to pretty much any filesystem system call that does not already involve an open file, and IIRC many that also do. Problem is, that same cache in WSL must be subverted because Linux is not the only thing that can mutate the NTFS filesystem - any Windows program could as well. This one fundamentally unfixable problem alone is probably 80% the reason WSL1 IO perf sucked - because the design absolutely required it.<p>Solutions are rip out a core piece of kernel functionality, and in the process basically taking over ownership and maintenance for ALL code anywhere in the kernel assuming the existence of said cache, engineer something that is somehow better, and support this in perpetuity, including any semantic mismatches that turn up much later that were never designed for<p>The idea of merged ps output where Windows binaries would show up in the Linux /proc. How would you even begin to implement that without confusing EVERY process management tool ever written that interfaced with /proc? What about /proc/.../environ? On UNIX that has no character set. On Windows it is Unicode.<p>A trillion problems like this made WSL1 a beautiful nightmare. Glad it was tried and from watching the tickets, that team bled heroically trying to make it all work, but ultimately, I'm also glad it's gone, because the replacement is infinitely easier to engineer, maintain, and use, and that team earns its quarterly bonus much more easily. Everyone wins, except the astronauts, but as experience teaches us they never do.
I think we all are sometimes guilty of reading too much into things. WSL was announced to support developers. Not Administrators. The Windows/Azure division has a strategy for administration. And that is Powershell (also on Linux). They admin strategy is implement Powershell commandlets for Windows and Linux and execute them via Powershell (and things like DSC).<p>WSL however was always announced as a tool for developers to develop stuff. As long as you can run Linux tools and services and finish your dev tasks with it, they are considering it as goal achieved.
This is a really interesting article, and WSL 1 was a testament to Dave Cutler's vision for the NT architecture re: support for multiple operating environments (read 'Showstopper!' for more background).<p>Also, as someone hacking with a custom OS kernel in their spare time, I found this quote illuminating when it comes to understanding the lower level:<p>> A user-space process is a collection of binary instructions that the processor executes uninterruptedly (leaving interrupts aside). The operating system’s kernel is unaware of what the process is doing until the process issues a system call: at that point, the kernel regains control to perform an operation on behalf of the user, which can be something like reading a file or pausing for a few seconds.<p>[Edit: My first point is actually incorrect - see child comment about 'pico processes']
Starting my development journey on Windows many years ago, discovering Linux and eventually daily driving MacOS for years - WSL1 has enabled me to once again make Windows 10 my daily driver for both work and play for the last year.<p>I spent several months using WSL2 but because the implementation attempts to hide virtualization behind a curtain, it was unclear where the magic successfully blended the guest with the host and where it didn't. I ended up having a lot of trouble with networking, and leaned heavily on my understanding of virtualization to debug those issues:<p>- Connections to Windows VPNs wouldn't work well inside the WSL guest<p>- Running browser automation tools like Playwright wouldn't allow you access to the browser in Windows<p>- The WSL2 guest can't connect to services (tcp, ports, whatever) running on the Windows host<p>- Trying to do something like `ssh -D 1337` from inside the WSL guest is confusing<p>- If you run `ssh -L 8080:localhost:8080 remote.com` using powershell, the WSL guest does not have access to port `8080`.<p>While incredible in that it has dynamic VM memory allocation and such, it still felt like running Linux in VirtualBox, SSHing into it and having a lot of automation to handle port forwarding - a workflow I have used in the past and isn't very revolutionary.<p>WSL1, while a simpler implementation that is more feature constrained, I felt that it matched my behavioural expectations (an API mapping that isn't feature complete) making it more useful. I continue to daily drive it.<p>Windows Terminal also made Windows competitive with other OSes that have quality terminal emulators, such as `iTerm2` or `gnome-terminal` (`hyper` is too memory heavy, though `cmder` is not too bad).<p>It's my understanding that MS wants to focus on Hyper-V to make VMs more like containers, but for my simple use-case/world view, I would rather the "reverse Wine" world of WSL1 to the "enhanced VM" world of Hyper V.<p>I will continue to use WSL1 daily and hope MS chooses to focus on this style of integration over the WSL2 style. I'd love to see features like blending `/etc/hosts`, supporting `tmpfs` and containerization (without virtualization).<p>If MS deprecates WSL1, I will probably move back to MacOS or Linux.
I too was really sad to see WSL 1 be replaced by what seems to be just a built-in VM. One of the great things about WSL 1 is that I can run Linux tools on my laptop without the memory overhead of a VM. My laptop only has 8GB of ram which is not enough for Windows and a Linux VM to comfortably share, but plenty to run the Linux tooling I want under WSL 1.<p>On my desktop with 16GB of ram I can just run Virtualbox. WSL 2 solves nothing for me. Like the author I am very skeptical that WSL 1 will be maintained going forward but I hope it is.
This article is entirely wrong about why it's called the Windows Subsystem for Linux and not the Linux Subsystem for Windows (not surprising, since his argument makes no sense). The real reason is that Microsoft can't name something leading with a trademark owned by someone else. Here it is straight from the horse's mouth, senior PM of WSL Rich Turner:
<a href="https://twitter.com/richturn_ms/status/1245481405947076610" rel="nofollow">https://twitter.com/richturn_ms/status/1245481405947076610</a>
WSL 1 (haven't tried 2 if they have some sort of magic for this, guess not) can actually run windows applications.<p>So you can run "ipconfig.exe | cowsay" for instance.<p>I'm not in front of a windows machine now but you could do stuff like list windows processes with a windows command, filter it with linux command and take the result to kill a process. All in a short line.<p>And honestly, more integrated than that I'm not sure I want. I like isolation and knowing that my linux command won't touch windows processes etc.<p>But an utility that can list and kill both Linux and windows processes can be done in a short shell-script.
Not sure I agree with this write up. Microsoft can and is already plumbing various host bits into the guest virtual machine (e.g. GPU). There's nothing preventing them from exposing processes, per the author's wishes, but it really comes down to -- do folks really need/want that? If so, file an issue in the WSL repository and get the ball rolling!
As someone who has done work on a sort of "Darwin subsystem for Linux", seeing the death of WSL1 has been really sad. Linux is one of the few OSes where this kind of approach really makes sense, since it's open source and has a small, very well-defined, stable ABI that you can implement and everything should "just work". Of course this process can be tedious and complicated, but I mean it is so much easier than what Wine or Darling is doing on a closed-source OS at a very different layer in the stack. It's of course obvious why WSL2 exists but its existence brings a great sadness, like Oracle buying Sun or Google killing off Hangouts and replacing it with whatever they're using these days.
If you want a Linux-like environment on Windows that can see and be seen from the Windows side, there is Cygwin. It's not as deeply integrated as WSL1, nor has binary compatibility (you'll have to get binaries compiled for it or compile them yourself) but last time I checked (Windows 7, IIRC) it did the job.
I don't really understand this point of view.<p>WSL2 is faster and works better in almost every way. As a developer I absolutely love it and it has changed my workflow completely.<p>I haven't run into any limitations that kept me from doing what I wanted to do with it, and some minor adjustments like using wsl2host helps bridge any gaps.<p>What did we sacrifice along the way? Well, apparently we can't change our Windows network config or see Windows processes through Linux tools that weren't designed for it anyway.<p>And we want that sort of thing because, it's, uhh, "cool"? Those priorities don't make sense to me, but maybe I don't fully understand what people want to do with it.
I'm extremely ignorant about OS design, but based on this it sounds like WSL1 could be fairly described as basically Linux for the Windows kernel, whereas WSL2 is more like a really fancy VM. Is that the gist of it?
I remember NT was to have an OS/2 subsystem, probably because it started out as OS/2 3.0, with a New Technology (NT) kernel. I know there was a POSIX system, but I never saw or interacted with it and, legend says, it was only used to check a box in government contracts.
One of the things I really liked about WSL1 was the integration with Windows. This caused some bugs but made other task a lot simpler. For example editing a file that existed in the Windows file system with a Windows application and then actually processing it with a linux binary worked really well most of the time.<p>With WSL2 you are expected to only interact with files in the linux filesystem with linux. I'm sure this made a bunch of easier for the dev team but it kinda ruins WSL for me.<p>I still haven't figured out how to call a binary that exist in the linux vm from Windows or how to interact with the windows network from linux.
I don’t have a dog in this fight, nor any experience with Windows since 7, nor much familiarity with the various low level differences that might make WSL 1 the giant ball of asterisks and footnotes and incompatibilities that I can intuitively imagine based on the conceptual explanation. That said, as a Mac user—a system with a great deal more common heritage with Linux—knowing that such a compatibility approach for (say) Docker hasn’t even been attempted, despite the huge amount of developer goodwill it could generate, because the OSes are so significantly different... I’m impressed that WSL 1 was even tried.<p>Also as such an outsider, I have to wonder if a similar approach in the opposite direction (bring core Windows APIs more in line with *nix, build traditional Windows environment compatibility layers on top for existing software, eventually become a Linux) might have been a more expensive but more successful and future proof approach. Even so, that sounds (even in the abstract) a lot to ask. Even from one of the largest software vendors in existence.<p>I’m sure there’s a ton of details I’m missing or getting confused, but it’s interesting brain food for me as someone fully in the Apple ecosystem but perpetually casually watching the MS ecosystem and its improvements as a backup plan.
Yeah this really resonated with me. I thought WSL1 was a great idea and they gave up on all the great integration aspects just to gain some minor things like docker compatibility :(<p>After all, people who wanted to do that could always run Linux in a VM.
> And the reason I can imagine this is because macOS gives you this model (albeit cheating because macOS is essentially Unix).<p>What is the cheat there? That MacOS X is a single operating system, where both, command line tools the blog author knows and GUI tools, life in the same world, with da process model and same devices on a single kernel, unlike WSL? How is that cheating? Is my Linux desktop cheating as well?
> Can you imagine how cool it would be to manipulate Windows services from the WSL session?<p>It is a cool integration trick and might even be useful for some people like the author and their role with Azure. But it isn't remotely interesting for most WSL users who just want a local Linux to run containers in, or Linux tools, or just do server related stuff.
Looking forward to the next LTS version of windows 10 that can support WSL2. As of right now WSL2 only works on Windows 10 versions 1903 or newer so it's a no go on LTSB/LTSC.
I've dedicated 2 solid work hours to help a co-worker migrate from wsl1 to wsl2.<p>Such a PITA. I couldn't get the linux tab to appear on his explorer.exe like in mine but oh well everything else worked fine!
Quote:"...or, god forbid, suffer through the ancient CMD.EXE console". What's wrong with cmd.exe? It's a good tool<p>Quote: "and the fact that WSL continues to be separate from the native Windows environment shows. Even though I was quite hopeful, I cannot use WSL as my daily driver because I need to interact with “native” Windows tooling."
You do know CygWin exists, yes? Quite good and get this, exists from the moment Win95 came to existence.
Conway's law means were going to end up with quasi-microkernels.<p>- See google doing networking and other stuff in userspace to work around lazy phone manufacturers for Android. (And also for servers for entirely different reasons.)<p>- Imagine vendor lock-in^2 where my app only runs with Linux and Windows via WSL!<p>- NT and XNU are already that way, probably in-part due to Conway's law<p>- Various "serverless" cloud gambits will chop things up in different ways<p>- Maybe the Fuschias of the world will want a WSL too
When working on Windows I often use the verion of bash which comes with git. It's obviously not at all the same as WSL, but it gives you a lot of the feel of using a Unix machine while working in windows. The command-line tools work properly, for example.<p>I see others are offering similar comments, so I'll stop there. Try bash; it's ok in many cases.
WSL1 was nice and idealistic, but WSL2 is a better fit for how people actually want to use WSL (IMHO): Linux as essentially a Windows app. You could get this before with VirtualBox or some other VM, but now it's more tightly integrated, with built-in filesystem sharing, and Linux distros distributed through the Windows Store.
In reverse, on Linux I'd surely prefer to use Wine to run Windows programs, instead of using a VM.<p><i>> But keeping WSL 1 running is a monumental effort due to the need to keep up with Linux changes.</i><p>That's what Wine has been doing for years - keeping with up with Windows changes. And it's indeed a monumental effort for such compatibility layers.
Can somebody explain why he doesn't get the best of all worlds just running Wine on bare-metal Linux? Sure, he's obliged to run <i>those</i> programs, but that's table stakes. Other than <i>those</i>, it's Linux from here to the bank, and <i>those</i> processes show up in ps output with right numbers even.
> Can you imagine how cool it would be to manipulate Windows services from the WSL session?<p>This was a little confusing, in some ways, because it came right after "being able to list out processes to kill". A <i>Windows Service</i> is a lot like a `systemd` service.<p>In the scenario he envisions where you could see windows processes within WSL[0], it'd be possible to write a script that could invoke the windows-equivalent command to stop/start services and print `systemd`[1]/Windows services side-by-side, but you couldn't make Windows services "work" with `systemd` tools. Somewhat obvious, probably, but it caused me to raise an eyebrow for a second so I thought I'd mention it.<p>[0] Was it this way in WSL1? I don't remember, it's been too long.<p>[1] Last time I used WSL2, I ran openSuSE Leap; not sure what the default ships with.
Correct me if I'm wrong, but this article makes it sound like WSL might be taking notes from WINE. It's Not an Emulator, because that would be slow and error-prone. Instead, it finds a way to abstract the appropriate functionality within the existing system.<p>Talk about irony. But I share the author's desire to see WSL share resources transparently between the W and the L. USB serial devices are a good example: it took forever for WSL1 to sort of support them, and it's still spotty with WSL2.<p>This is an area where WSL could be very appealing: many embedded workflows rely on one or two legacy Windows applications, but most of the core tooling works fine in Linux. But if you can't easily pass your USB debugger between OSes, you can't easily split your workflow across OSes.
I have zero insight obviously but I still believe it was ptrace that broke the camels back. And yes, I had so much hope for WSL1.<p>> ptrace(PTRACE_TRACEME, 0, 0, 0) = -1 EPERM (Operation not permitted)<p>Issues also exist for PTRACE_O_TRACEEXIT, PTRACE_O_TRACEEXEC, PTRACE_OLDSETOPTIONS, PTRACE_SYSEMU.
> <i>Can you imagine how cool it would be if you could type ps or top within a WSL session and see Linux and Windows processes side-by-side, able to mutate their state with kill</i><p>No, that could not reasonably have been. The underlying NT kernel seeing all processes, whether Win32 or WSL, is one thing, but the psutils in the Linux world being able to see non-Linux processes doesn't make any amount of sense.<p>kill works by sending signals. This makes no sense to processes that are not in the Linux domain.<p>Edit: also what ralph87 writes in paragraph 4: <a href="https://news.ycombinator.com/item?id=25154556" rel="nofollow">https://news.ycombinator.com/item?id=25154556</a>
No words can describe WSL1 better than those from Gavin Belson talking about Nucleus:<p><a href="https://www.youtube.com/watch?v=hrO9ZZlg32w" rel="nofollow">https://www.youtube.com/watch?v=hrO9ZZlg32w</a>
I tend to agree with the article. What does WLS2 provides that a regular VM (VirtualBox for example) doesn't? Or a Docker container that I run with "C:" mounted as a volume?
Totally agree with this post. I use WSL1 quite a bit, and it brings many of the things I love about working on the mac to Windows. I do hope MS does continue to support it as promised.
Hmm it could be nice idea to add WSL2 "module" to allow call "exe" from inside WSL2 env. Is this technically currently possible somehow ?
Windows Subsystem FOR Linux...<p>meaning the Windows OS <i>possesses</i> Linux ... Makes perfect sense if you are familiar with the English language and how possessives work.