15 ms·

Windows Subsystem for Linux: The lost potential

362 points by r0sk 6y ago

phendrenad2 6y ago
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.
blueflame7 6y ago
It would be wonderful if sftp was included in windows distributions natively
- Iwan-Zotow 6y ago
  but it is included, as well as scp
  - blueflame7 6y ago
    Even within Explore to mount a remote linux server over ssh?
    - cspotrun79 6y ago
      why would you need that if you have the command line functionality already? Windows has shipped with sftp for a while now. about the only think missing is a stand alone ssh client on the windows side but for that there is putty.
      - blueflame7 6y ago
        It would be nice to be able to mount a remote linux data share as a drive without using SMB due to all the EternalBlue Ransomware issues. Having that convenience in windows file explorer like nautilus would be helpful for people who aren't necessarily power users.
      - uberman 6y ago
        There is a native ssh client in windows 10. https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_overview https://docs.microsoft.com/en-us/windows-server/administrati...
        lostmsu 6y ago
        Now I want screen or tmux. Otherwise you can't really run anything on a remote Windows machine over SSH on spotty connections.
        Iwan-Zotow 6y ago
        well, this thing sometimes works https://docs.microsoft.com/en-us/windows/terminal/panes https://docs.microsoft.com/en-us/windows/terminal/panes
        lostmsu 6y ago
        No, the issue is about SSH sessions. ssh user@windows-pc run long job If you do this, and your connection is interrupted, `run long job` command will be terminated.
        uberman 6y ago
        You can ssh into your remote and start a tmux session then. If you are disconnected you ssh back then tmux attach. :-)
        lostmsu 6y ago
        Remote machine is Windows. tmux is not available on Windows. That's the whole issue. This could be done with WSL, but WSL is too heavy for a task like that.
        uberman 6y ago
        Ah my apologies, I thought you were looking for a native windows client version of tmux to go along with the native client ssh. I see you are looking for a server side implementation though.
      - WorldMaker 6y ago
        OpenSSH both client and server has been a Windows feature for sometime in Windows 10 and the client has been auto-enabled in Dev Mode for slightly less but nearly as much time. (It's the OpenSSH Client provided as a Windows 10 feature that also provides sftp now.)
      - solarkraft 6y ago
        I like my GUIs when they're more efficient. All major Linux file managers and the Mac OS one support sftp mounts graphically.
        redflame7 6y ago
        Exactly, especially when one of the few things Windows does a lot better than linux (at least historically) is the seamless integration of multiple video cards for having many screens which allow for more graphical interactions
      - deleted 6y ago
        [deleted]
      - Iwan-Zotow 6y ago
        ssh, sftp, scp are all there, part of W10 SSH package
    - shawnz 6y ago
      Unfortunately it lacks Explorer integration although the command line client works well. SFTP integration in Explorer is one of the few big weak points remaining for Linux interoperability.
johannes1234321 6y ago
> And the reason I can imagine this is because macOS gives you this model (albeit cheating because macOS is essentially Unix). 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?
- agustif 6y ago
  cheating as in they have much less work to do to implement unix-like linux on the hood because it was already there, and Microsoft actually has to build a port.
  - johannes1234321 6y ago
    Where is MacOS implementing Linux? At it's core it is a Unix system (not sure whether they have any recent certification, but doesn't matter) tltonlarge parts following POSIX with a fancy GUI.
    - rbanffy 6y ago
      I wonder if it would be possible to resurrect MkLinux on top of the MacOS Mach kernel. Would doubtlessly be fun.
    - filmgirlcw 6y ago
      Exactly.
  - Longhanks 6y ago
    Which was not always the case, up until Mac OS 9 there was no Unix. They delivered with Mac OS X. That’s not cheating, it’s pointing out that Microsoft failed in this regard.
    - rbanffy 6y ago
      MacOS X is not a new version of MacOS 9 - it's renamed OPENSTEP with a MacOS X theme and some parts replaced. It's also very different from most Unixes in that it has a Mach microkernel with a BSD coat of paint. It almost has more in common with NT than it has with Linux. Before that, MacOS had (AFAIK - never seen it myself) the MPW environment that had a Unix-like shell. And A/UX.
agustif 6y ago
I've dedicated 2 solid work hours to help a co-worker migrate from wsl1 to wsl2. 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!
- lrae 6y ago
  Wait, I didn't even know that was a thing. I am on WSL2 and don't have that either, nor do I think I ever saw it in Microsoft's docs. Interesting, thanks. Let's see if I get it to work for me. For now I always went with \\wsl$. Edit: Wait, are you on an insider build by chance? https://blogs.windows.com/windows-insider/2020/04/08/announcing-windows-10-insider-preview-build-19603/ https://blogs.windows.com/windows-insider/2020/04/08/announc... Seems like this isn't in yet otherwise.
  - craigaloewen 6y ago
    Yes this feature is only available on Insiders builds for right now!
    - shawnz 6y ago
      Thank you for your work on this project. Although like the author I have some reservations about moving to a virtualization-based approach, nonetheless I am grateful attention is being paid to these kind of technologies at all. WSL has totally changed my development workflow for the better.
      - craigaloewen 6y ago
        I'm so glad you're enjoying it! And yes we totally hear the community's reservations about moving to a virtualization based approach and we take this into account as we plan the next overall steps for WSL :)
  - agustif 6y ago
    Oh yeah, that was it indeed, I'm on insider build. Didn't know it was bc of that! Glad it discovered it for you, it's a great feature wsl$$ not so much clean as this.
oaiey 6y ago
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). 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.
- brainzap 6y ago
  we use bash tho
ralph87 6y ago
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. 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. 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 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. 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.
- sedatk 6y ago
  I agree with the sentiment but, some scenarios have become orders of magnitude more complicated on WSL2 like connecting to a daemon on Windows or vice versa. I understand clear cut security boundaries and separate network interfaces, but it's extremely hard to get them running smoothly now. Everything was on localhost on WSL1. Memory usage has also gone bonkers with the VM approach, causing unnecessary overhead for casual users who don't need performance.
trilinearnz 6y ago
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). 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: > 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. [Edit: My first point is actually incorrect - see child comment about 'pico processes']
- TimTheTinker 6y ago
  That leaves out the fact that the kernel scheduler does in fact issue timed interrupts to all kernel and userspace code running on a given core, except for "critical sections" (where one or more locks are held). That being said, the scheduler is so reliable and so seamless that one need hardly ever worry about it unless a particular block of code must not be interrupted, usually for parts of parallel/multithreaded code that have shared memory or other resources, or sections within the kernel or scheduler itself. More info on the current Linux scheduler here: https://www.kernel.org/doc/html/latest/scheduler/sched-design-CFS.html https://www.kernel.org/doc/html/latest/scheduler/sched-desig... Check out the code here, if you're brave: https://github.com/torvalds/linux/blob/master/kernel/sched/fair.c https://github.com/torvalds/linux/blob/master/kernel/sched/f...
- shawnz 6y ago
  WSL 1 actually doesn't use the NT subsystem architecture like SFU/Interix did (and this article implies). Instead WSL 1 was implemented with a relatively new feature called "pico processes". See: https://docs.microsoft.com/en-us/archive/blogs/wsl/pico-process-overview https://docs.microsoft.com/en-us/archive/blogs/wsl/pico-proc...
- sundvor 6y ago
  Showstopper! was an excellent book. I found a new appreciation for dogfood after that.
rbanffy 6y ago
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.
- lukeh 6y ago
  The OS/2 subsystem existed and shipped up to Windows 2000.
  - rbanffy 6y ago
    Really?! I tried to run a couple OS/2 binaries back then without success. Did you have to do anything special?
    - sedatk 6y ago
      You had to enable the feature and it only supported OS/2 1.x apps (console). No GUI support.
- hapless 6y ago
  The original POSIX subsystem was not very useful -- a minimal set of system calls, plus a Microsoft re-branded MKS Toolkit to provide shells and utilities. Microsoft ended up buying Interix, who offered a much more pleasant UNIX-on-Windows setup. That was supported for many years as "SFU" and later "SUA" SUA was still a pretty weird UNIX though. PE-COFF binaries, and a linker that wasn't 100% GNU compatible, and a lot of other little oddities. Porting software to SUA was never very much fun. I assume that was the motive for WSL -- same idea as SUA, but less weird for software ports.
  - rbanffy 6y ago
    On XP and 7 (and 8, perhaps) I used Cygwin to have a Unix-like environment. Does it still work on Windows 10? I remember I could call Windows programs from it and manipulate Windows files.
rbanffy 6y ago
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.
- nix0n 6y ago
  I can confirm Cygwin works with 10. Its default package manager includes most of the standard POSIX tools. I've used it a lot for on-Windows/for-Windows development, but always as a complement to native Windows tools.
  - rbanffy 6y ago
    This is great news. It offers a lot of what the author wants (except the speed of WSL2). I would expect it to be less-complete than WSL1 (it looks like Linux, until you look it from up close) but faster, because it doesn't try as hard to be a Linux.
    - Gibbon1 6y ago
      I've used MinGW's MSYS which gives you a posix development environment. Was the simplest way to get support for autotools on windows. Useful if you need to cross compile a library on windows.
      - 1996 6y ago
        Check out msys2, a please to use with pacman
- flukus 6y ago
  I tried migrating to wsl (1) but there was just too many little things not working so went back to cygwin. WSL had issues with watching files, mounting some network drives and windows interop that I've never had with cygwin.
withinrafael 6y ago
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!
- deleted 6y ago
  [deleted]
deleted 6y ago
[deleted]
beefcubebrush 6y ago
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.
- bootlooped 6y ago
  I pestered my IT department enough and they let me have it.
ProofByAccident 6y ago
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?
- jabedude 6y ago
  Without making a value judgement, that is pretty much spot on
  - ProofByAccident 6y ago
    Sweet, thanks!
- ChrisSD 6y ago
  More or less. Though I'd rephrase your description of WSL1 as "Linux for the NT kernel". In that sense "Win32" (the API used by Windows programs) could also be described as "Win32 for the NT kernel". They are both subsystems that translate their APIs into NT kernel calls. Windows NT used to have a number of these subsystems but all except Win32 were deprecated and eventually removed.
  - ProofByAccident 6y ago
    I see, that makes sense! This is a really interesting design and seeing it this way gives me more respect for the Windows operating system generally. Is this subsystem concept something that has a parallel on the *nix/BSD side of the fence? Or is it unique to the NT architecture?
    - Macha 6y ago
      The closest example outside Windows I can think of is the idea of "zones" in Solaris/Illumos/SmartOS. You can have a "LX branded zone" where the OS will respond to linux syscalls. I don't know if the native solaris syscall interface is itself a zone, while Win32 is a subsystem on Windows.
baybal2 6y ago
Unpopular opinion: Microsoft was afraid that WSL 1.0 would "Embrace, Extend, Extinguish" the Windows OS.
cbdumas 6y ago
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. 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.
- neurostimulant 6y ago
  Most windows laptop has user-accessible ram slots. You might be able to upgrade your ram and save yourself some trouble.
- 1_player 6y ago
  While still being a VM, WSL2 works much better than a Virtualbox VM: boots in 1 second (!) on my machine, as attested by uptime and dmesg, has dynamic memory reclamation, out of the box file sharing through \\wsl$, VSCode integration. Same technology, yeah, but much more ergonomic.
  - rfoo 6y ago
    My Linux VM in Hyper-V also boots in 1 second (well, 1.5 seconds actually but that includes networking, docker, samba and various other services): $ systemd-analyze Startup finished in 76ms (firmware) + 38ms (loader) + 461ms (kernel) + 967ms (userspace) = 1.544s So 1 second by default is impressive, but not really special for those who can already run a VM. Dynamic memory reclamation is turned on by default for any modern Linux distributions running in Hyper-V. Last I checked the performance of \\wsl$ is terrible (certainly not on par with NFS). I can see it might be slightly more ergonomic for casual users though, but certainly not to the point WSL 1 has already been at.
tjoff 6y ago
WSL 1 (haven't tried 2 if they have some sort of magic for this, guess not) can actually run windows applications. So you can run "ipconfig.exe | cowsay" for instance. 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. 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. But an utility that can list and kill both Linux and windows processes can be done in a short shell-script.
- 1996 6y ago
  The same is possible in msys2, and actually very useful. For example, to find my IP, from my bash prompt on windows 10: /c/Windows/System32/ipconfig.exe | grep "^\s\s\sIPv" | sed -e 's/.*: //g'
- shawnz 6y ago
  WSL 2 actually also supports that integration. It works by transparently sending the stdio over the network to/from the host instead.
eyelidlessness 6y ago
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. 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. 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.
mdip 6y ago
> Can you imagine how cool it would be to manipulate Windows services from the WSL session? This was a little confusing, in some ways, because it came right after "being able to list out processes to kill". A Windows Service is a lot like a `systemd` service. 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. [0] Was it this way in WSL1? I don't remember, it's been too long. [1] Last time I used WSL2, I ran openSuSE Leap; not sure what the default ships with.
- shawnz 6y ago
  In WSL1, you can't see windows processes in 'ps' or '/proc/[pid]' as if they were linux processes, but you could just execute the Windows tasklist.exe/taskkill.exe binary instead and parse the stdout. Actually, you could do the same with WSL2 also.
jagged-chisel 6y ago
I want fish as my shell. Easy peasy. I want to type ‘code <dir>‘ and have it open in VSCode. Can’t.
- Tijdreiziger 6y ago
  That works for me on bash on WSL1, interested to know why that wouldn't work on fish?
  - jagged-chisel 6y ago
    Thought we were talking about WSL2. Apologies for not including that context.
- int_19h 6y ago
  I use fish as my default WSL shell, and I run "code ..." from it all the time. What doesn't work for you?
  - jagged-chisel 6y ago
    Doesn’t work for me in WSL2. Can’t recall the error/behavior at the moment. Was easier just to use a Linux VM at that point.
29athrowaway 6y ago
How would you send SIGSTOP and SIGCONT to a Windows process? Using kill on Windows processes sounds weird.
- deleted 6y ago
  [deleted]
apatheticonion 6y ago
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. 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: - Connections to Windows VPNs wouldn't work well inside the WSL guest - Running browser automation tools like Playwright wouldn't allow you access to the browser in Windows - The WSL2 guest can't connect to services (tcp, ports, whatever) running on the Windows host - Trying to do something like `ssh -D 1337` from inside the WSL guest is confusing - If you run `ssh -L 8080:localhost:8080 remote.com` using powershell, the WSL guest does not have access to port `8080`. 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. 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. 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). 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. 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). If MS deprecates WSL1, I will probably move back to MacOS or Linux.
- ImprobableTruth 6y ago
  >The WSL2 guest can't connect to services (tcp, ports, whatever) running on the Windows host I assume you're talking about how you need to use the hosts ip rather than localhost? Because you definitely can access host ports. I'm even connecting WSL2 to an X server running on windows.
wnevets 6y ago
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. 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. 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.
- baq 6y ago
  re files - you can mount an nfs export in WSL and Windows 10 comes with a opt-in NFS server - or perhaps try samba. re network - if you mean localhost, that's probably impossible due to WSL2 being a vm unless the folks at MS invent some deep black magic. you should be able to use the LAN interface IP address, though.
chx 6y ago
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. > ptrace(PTRACE_TRACEME, 0, 0, 0) = -1 EPERM (Operation not permitted) Issues also exist for PTRACE_O_TRACEEXIT, PTRACE_O_TRACEEXEC, PTRACE_OLDSETOPTIONS, PTRACE_SYSEMU.
- shawnz 6y ago
  It seems like those bugs were fixed some time ago. See: https://github.com/microsoft/WSL/issues/555 https://github.com/microsoft/WSL/issues/555
  - chx 6y ago
    The big one is https://github.com/microsoft/WSL/issues/2028 https://github.com/microsoft/WSL/issues/2028 which is "fixed-in-wsl2" This makes lldb and dlv both just not work in wsl1 and that's just the languages I dabbed in, I think the Swift debugger had issues as well.
    - shawnz 6y ago
      Interesting, you are right I can repro the bug in issue 2028 although 555 claims to be fixed.
deleted 6y ago
[deleted]
mdoms 6y ago
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: https://twitter.com/richturn_ms/status/1245481405947076610 https://twitter.com/richturn_ms/status/1245481405947076610
- spondyl 6y ago
  You can see a similar comment from Rich Turner here on Hacker News too, under the username bitcrazed: https://news.ycombinator.com/item?id=13697918 https://news.ycombinator.com/item?id=13697918 I'd never actually read it with the apostrophe as pointing out in that tweet so the name makes a lot more sense now. Perhaps Windows Subsystem for (running) Linux would be clearer hah Also, according to his profile, Rich is former Product Manager for WSL and currently "Sr. PM for the Windows Command Line, Windows Terminal" The interpretation in the article was still interesting nonetheless
  - dataflow 6y ago
    They could've called it the Windows Linux Subsystem and done away with the confusion.
hossbeast 6y ago
There was once a dream that was WSL, you could only whisper it. Anything more than a whisper and it would vanish, it was so fragile.
electrotype 6y ago
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?
- gizmo385 6y ago
  Ease of use and ease of setup - both of which are important. If I want to setup an Ubuntu VirtualBox, I have to download the VirtualBox software, find the Ubuntu ISO, and run through the setup process. Then I've got to work through any quirks with the setup to get it working seamlessly within the larger windows environment. With WSL? I hit the install button on the windows app store. That simplicity is important and vastly increases the immediate utility of something like WSL, especially if you just want to try it out.
  - electrotype 6y ago
    I'm pretty sure those who would actually use WSL are also able to install a regular VM or Docker.
    - TillE 6y ago
      WSL launches near-instantly, consumes few resources, runs programs very fast, has seamless access to my Windows drive, etc. It's nice and light where a VM is bulky. It does everything I want as a Linux terminal on Windows. I'm completely indifferent to the stuff mentioned in this blog post, as I'm not a Windows sysadmin.
- bootlooped 6y ago
  Better performance, easier to use if you're just using command line stuff, first-party support. Docker's own docs state that it's better to run containers on the WSL2 backend than the old way (a hyper-v vm just for Docker). Flip the question the other way: what does VirtualBox offer me that I'm not getting from WSL2? I just need Linux command line tools for software development. This feels like the best way to get them on Windows. It's easy to imagine use-cases when a full blown VM are better; not my current use-cases though.
snarfy 6y ago
I tried upgrading to wsl2 only to find out USB serial doesn't work. I use wsl1 to program my esp32 boards.
sfblah 6y ago
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. I see others are offering similar comments, so I'll stop there. Try bash; it's ok in many cases.
- strunz 6y ago
  It's cool, but warning that it treats variables differently. For example if you run an EXE command-line tool which looks for Windows environment variables, it won't use the Bash environment variables. Probably not a huge deal, just a gotcha we've hit at my company which caused a lot of wasted debugging time.
ncmncm 6y ago
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 those programs, but that's table stakes. Other than those, it's Linux from here to the bank, and those processes show up in ps output with right numbers even.
- dboreham 6y ago
  Because his job is to ship software that runs on Windows. You can only do that on actual Windows.
  - ncmncm 6y ago
    That is a manifestly false statement. E.g., the whole MSYS system is cross-compiled, and tested on Wine. Of course, programs would still need QA on real windos, and OS bugs they tickled would not be reproduced. But running them in a VM, with the file system exposed via Samba, would tickle the OS-interaction bugs. Those runs wouldn't show up on ps. True, mgmt might look at him funny. But in my experience they do anyway. So, the question remains open.
Ericson2314 6y ago
Conway's law means were going to end up with quasi-microkernels. - 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.) - Imagine vendor lock-in^2 where my app only runs with Linux and Windows via WSL! - NT and XNU are already that way, probably in-part due to Conway's law - Various "serverless" cloud gambits will chop things up in different ways - Maybe the Fuschias of the world will want a WSL too
saagarjha 6y ago
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.
shmerl 6y ago
In reverse, on Linux I'd surely prefer to use Wine to run Windows programs, instead of using a VM. > But keeping WSL 1 running is a monumental effort due to the need to keep up with Linux changes. 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.
meekrohprocess 6y ago
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. 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. 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.
sime2009 6y ago
> Can you imagine how cool it would be to manipulate Windows services from the WSL session? 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.
- TeMPOraL 6y ago
  But there's literally no point in having WSL then, as such users can just keep using VirtualBox as they always did.
  - sime2009 6y ago
    The goals of WSL2 compared to VirtualBox or HyperV are: * Lower memory use * Tighter integration with networking. i.e. it looks like it is running on localhost. * Start/stops on demand, and much faster. * (easier) file system integration. i.e. you can easily get to your Linux files from inside Windows. So there actually are some points to WSL2. For me personally I couldn't get Docker (actually its networking) to work properly via WSL2 so I'm still on a VM. But at least it works. VSCode's remote working feature is fantastic too in this situation.
    - deleted 6y ago
      [deleted]
  - wildpeaks 6y ago
    That's exactly what I ended up concluding as well when I tried switching to WSL 2 because it added too much friction to the DX, whereas Docker Compose and the Docker VSCode extension kept things simple and scoped. I didn't even keep WSL 2 as Docker engine because it doesn't forward filechange events from shared folders (which breaks livereload / watch mode), ended up going back to Hyper-V and it does exactly what I need.
    - sime2009 6y ago
tilolebo 6y ago
No words can describe WSL1 better than those from Gavin Belson talking about Nucleus: https://www.youtube.com/watch?v=hrO9ZZlg32w https://www.youtube.com/watch?v=hrO9ZZlg32w
tkubacki 6y ago
Hmm it could be nice idea to add WSL2 "module" to allow call "exe" from inside WSL2 env. Is this technically currently possible somehow ?
unnouinceput 6y ago
Quote:"...or, god forbid, suffer through the ancient CMD.EXE console". What's wrong with cmd.exe? It's a good tool 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.
- for_xyz 6y ago
  It's possible to interact with native windows tooling from WSL. Example: $ echo "test" > test.txt & notepad.exe test.txt
- ChrisSD 6y ago
  This is the first time in a long time I've heard anyone refer to cmd as a "good tool". It's a legacy from DOS. Not in the literal sense of course but in the sense of the builtins, syntax and the horrendous BAT. Mind you DOS had a lot of fans even in the late 90's/00's so of course it had its advocates. But they are much rarer nowadays.
GekkePrutser 6y ago
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 :( After all, people who wanted to do that could always run Linux in a VM.
0dmethz 6y ago
I don't really understand this point of view. WSL2 is faster and works better in almost every way. As a developer I absolutely love it and it has changed my workflow completely. 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. 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. 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.
xmodem 6y ago
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.
mwilliams0156 6y ago
WSL - Windows Subsystem FOR Linux, meaning It is a subsystem within windows that is setup FOR linux to run. Its a possession thing.
mwilliams0156 6y ago
Windows Subsystem FOR Linux... meaning the Windows OS possesses Linux ... Makes perfect sense if you are familiar with the English language and how possessives work.
kazinator 6y ago
> 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 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. kill works by sending signals. This makes no sense to processes that are not in the Linux domain. Edit: also what ralph87 writes in paragraph 4: https://news.ycombinator.com/item?id=25154556 https://news.ycombinator.com/item?id=25154556

362 points by r0sk 6y ago

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.

blueflame7 6y ago

It would be wonderful if sftp was included in windows distributions natively

Iwan-Zotow 6y ago
but it is included, as well as scp
- blueflame7 6y ago
  Even within Explore to mount a remote linux server over ssh?
  - cspotrun79 6y ago
    why would you need that if you have the command line functionality already? Windows has shipped with sftp for a while now. about the only think missing is a stand alone ssh client on the windows side but for that there is putty.
    - blueflame7 6y ago
      It would be nice to be able to mount a remote linux data share as a drive without using SMB due to all the EternalBlue Ransomware issues. Having that convenience in windows file explorer like nautilus would be helpful for people who aren't necessarily power users.
    - uberman 6y ago
      There is a native ssh client in windows 10. https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_overview https://docs.microsoft.com/en-us/windows-server/administrati...
      - lostmsu 6y ago
        Now I want screen or tmux. Otherwise you can't really run anything on a remote Windows machine over SSH on spotty connections.
        Iwan-Zotow 6y ago
        well, this thing sometimes works https://docs.microsoft.com/en-us/windows/terminal/panes https://docs.microsoft.com/en-us/windows/terminal/panes
        lostmsu 6y ago
        No, the issue is about SSH sessions. ssh user@windows-pc run long job If you do this, and your connection is interrupted, `run long job` command will be terminated.
        uberman 6y ago
        You can ssh into your remote and start a tmux session then. If you are disconnected you ssh back then tmux attach. :-)
        lostmsu 6y ago
        Remote machine is Windows. tmux is not available on Windows. That's the whole issue. This could be done with WSL, but WSL is too heavy for a task like that.
        uberman 6y ago
        Ah my apologies, I thought you were looking for a native windows client version of tmux to go along with the native client ssh. I see you are looking for a server side implementation though.
    - WorldMaker 6y ago
      OpenSSH both client and server has been a Windows feature for sometime in Windows 10 and the client has been auto-enabled in Dev Mode for slightly less but nearly as much time. (It's the OpenSSH Client provided as a Windows 10 feature that also provides sftp now.)
    - solarkraft 6y ago
      I like my GUIs when they're more efficient. All major Linux file managers and the Mac OS one support sftp mounts graphically.
      - redflame7 6y ago
        Exactly, especially when one of the few things Windows does a lot better than linux (at least historically) is the seamless integration of multiple video cards for having many screens which allow for more graphical interactions
    - deleted 6y ago
      [deleted]
    - Iwan-Zotow 6y ago
      ssh, sftp, scp are all there, part of W10 SSH package
  - shawnz 6y ago
    Unfortunately it lacks Explorer integration although the command line client works well. SFTP integration in Explorer is one of the few big weak points remaining for Linux interoperability.

johannes1234321 6y ago

> And the reason I can imagine this is because macOS gives you this model (albeit cheating because macOS is essentially Unix). 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?

agustif 6y ago
cheating as in they have much less work to do to implement unix-like linux on the hood because it was already there, and Microsoft actually has to build a port.
- johannes1234321 6y ago
  Where is MacOS implementing Linux? At it's core it is a Unix system (not sure whether they have any recent certification, but doesn't matter) tltonlarge parts following POSIX with a fancy GUI.
  - rbanffy 6y ago
    I wonder if it would be possible to resurrect MkLinux on top of the MacOS Mach kernel. Would doubtlessly be fun.
  - filmgirlcw 6y ago
    Exactly.
- Longhanks 6y ago
  Which was not always the case, up until Mac OS 9 there was no Unix. They delivered with Mac OS X. That’s not cheating, it’s pointing out that Microsoft failed in this regard.
  - rbanffy 6y ago
    MacOS X is not a new version of MacOS 9 - it's renamed OPENSTEP with a MacOS X theme and some parts replaced. It's also very different from most Unixes in that it has a Mach microkernel with a BSD coat of paint. It almost has more in common with NT than it has with Linux. Before that, MacOS had (AFAIK - never seen it myself) the MPW environment that had a Unix-like shell. And A/UX.

agustif 6y ago

I've dedicated 2 solid work hours to help a co-worker migrate from wsl1 to wsl2. 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!

lrae 6y ago
Wait, I didn't even know that was a thing. I am on WSL2 and don't have that either, nor do I think I ever saw it in Microsoft's docs. Interesting, thanks. Let's see if I get it to work for me. For now I always went with \\wsl$. Edit: Wait, are you on an insider build by chance? https://blogs.windows.com/windows-insider/2020/04/08/announcing-windows-10-insider-preview-build-19603/ https://blogs.windows.com/windows-insider/2020/04/08/announc... Seems like this isn't in yet otherwise.
- craigaloewen 6y ago
  Yes this feature is only available on Insiders builds for right now!
  - shawnz 6y ago
    Thank you for your work on this project. Although like the author I have some reservations about moving to a virtualization-based approach, nonetheless I am grateful attention is being paid to these kind of technologies at all. WSL has totally changed my development workflow for the better.
    - craigaloewen 6y ago
      I'm so glad you're enjoying it! And yes we totally hear the community's reservations about moving to a virtualization based approach and we take this into account as we plan the next overall steps for WSL :)
- agustif 6y ago
  Oh yeah, that was it indeed, I'm on insider build. Didn't know it was bc of that! Glad it discovered it for you, it's a great feature wsl$$ not so much clean as this.

oaiey 6y ago

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

brainzap 6y ago
we use bash tho

ralph87 6y ago

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

sedatk 6y ago
I agree with the sentiment but, some scenarios have become orders of magnitude more complicated on WSL2 like connecting to a daemon on Windows or vice versa. I understand clear cut security boundaries and separate network interfaces, but it's extremely hard to get them running smoothly now. Everything was on localhost on WSL1. Memory usage has also gone bonkers with the VM approach, causing unnecessary overhead for casual users who don't need performance.

trilinearnz 6y ago

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). 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: > 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. [Edit: My first point is actually incorrect - see child comment about 'pico processes']

TimTheTinker 6y ago
That leaves out the fact that the kernel scheduler does in fact issue timed interrupts to all kernel and userspace code running on a given core, except for "critical sections" (where one or more locks are held). That being said, the scheduler is so reliable and so seamless that one need hardly ever worry about it unless a particular block of code must not be interrupted, usually for parts of parallel/multithreaded code that have shared memory or other resources, or sections within the kernel or scheduler itself. More info on the current Linux scheduler here: https://www.kernel.org/doc/html/latest/scheduler/sched-design-CFS.html https://www.kernel.org/doc/html/latest/scheduler/sched-desig... Check out the code here, if you're brave: https://github.com/torvalds/linux/blob/master/kernel/sched/fair.c https://github.com/torvalds/linux/blob/master/kernel/sched/f...
shawnz 6y ago
WSL 1 actually doesn't use the NT subsystem architecture like SFU/Interix did (and this article implies). Instead WSL 1 was implemented with a relatively new feature called "pico processes". See: https://docs.microsoft.com/en-us/archive/blogs/wsl/pico-process-overview https://docs.microsoft.com/en-us/archive/blogs/wsl/pico-proc...
sundvor 6y ago
Showstopper! was an excellent book. I found a new appreciation for dogfood after that.

rbanffy 6y ago

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.

lukeh 6y ago
The OS/2 subsystem existed and shipped up to Windows 2000.
- rbanffy 6y ago
  Really?! I tried to run a couple OS/2 binaries back then without success. Did you have to do anything special?
  - sedatk 6y ago
    You had to enable the feature and it only supported OS/2 1.x apps (console). No GUI support.
hapless 6y ago
The original POSIX subsystem was not very useful -- a minimal set of system calls, plus a Microsoft re-branded MKS Toolkit to provide shells and utilities. Microsoft ended up buying Interix, who offered a much more pleasant UNIX-on-Windows setup. That was supported for many years as "SFU" and later "SUA" SUA was still a pretty weird UNIX though. PE-COFF binaries, and a linker that wasn't 100% GNU compatible, and a lot of other little oddities. Porting software to SUA was never very much fun. I assume that was the motive for WSL -- same idea as SUA, but less weird for software ports.
- rbanffy 6y ago
  On XP and 7 (and 8, perhaps) I used Cygwin to have a Unix-like environment. Does it still work on Windows 10? I remember I could call Windows programs from it and manipulate Windows files.

rbanffy 6y ago

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.

nix0n 6y ago
I can confirm Cygwin works with 10. Its default package manager includes most of the standard POSIX tools. I've used it a lot for on-Windows/for-Windows development, but always as a complement to native Windows tools.
- rbanffy 6y ago
  This is great news. It offers a lot of what the author wants (except the speed of WSL2). I would expect it to be less-complete than WSL1 (it looks like Linux, until you look it from up close) but faster, because it doesn't try as hard to be a Linux.
  - Gibbon1 6y ago
    I've used MinGW's MSYS which gives you a posix development environment. Was the simplest way to get support for autotools on windows. Useful if you need to cross compile a library on windows.
    - 1996 6y ago
      Check out msys2, a please to use with pacman
flukus 6y ago
I tried migrating to wsl (1) but there was just too many little things not working so went back to cygwin. WSL had issues with watching files, mounting some network drives and windows interop that I've never had with cygwin.

withinrafael 6y ago

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!

deleted 6y ago
[deleted]

deleted 6y ago

[deleted]

beefcubebrush 6y ago

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.

bootlooped 6y ago
I pestered my IT department enough and they let me have it.

ProofByAccident 6y ago

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?

jabedude 6y ago
Without making a value judgement, that is pretty much spot on
- ProofByAccident 6y ago
  Sweet, thanks!
ChrisSD 6y ago
More or less. Though I'd rephrase your description of WSL1 as "Linux for the NT kernel". In that sense "Win32" (the API used by Windows programs) could also be described as "Win32 for the NT kernel". They are both subsystems that translate their APIs into NT kernel calls. Windows NT used to have a number of these subsystems but all except Win32 were deprecated and eventually removed.
- ProofByAccident 6y ago
  I see, that makes sense! This is a really interesting design and seeing it this way gives me more respect for the Windows operating system generally. Is this subsystem concept something that has a parallel on the *nix/BSD side of the fence? Or is it unique to the NT architecture?
  - Macha 6y ago
    The closest example outside Windows I can think of is the idea of "zones" in Solaris/Illumos/SmartOS. You can have a "LX branded zone" where the OS will respond to linux syscalls. I don't know if the native solaris syscall interface is itself a zone, while Win32 is a subsystem on Windows.

baybal2 6y ago

Unpopular opinion: Microsoft was afraid that WSL 1.0 would "Embrace, Extend, Extinguish" the Windows OS.

cbdumas 6y ago

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

neurostimulant 6y ago
Most windows laptop has user-accessible ram slots. You might be able to upgrade your ram and save yourself some trouble.
1_player 6y ago
While still being a VM, WSL2 works much better than a Virtualbox VM: boots in 1 second (!) on my machine, as attested by uptime and dmesg, has dynamic memory reclamation, out of the box file sharing through \\wsl$, VSCode integration. Same technology, yeah, but much more ergonomic.
- rfoo 6y ago
  My Linux VM in Hyper-V also boots in 1 second (well, 1.5 seconds actually but that includes networking, docker, samba and various other services): $ systemd-analyze Startup finished in 76ms (firmware) + 38ms (loader) + 461ms (kernel) + 967ms (userspace) = 1.544s So 1 second by default is impressive, but not really special for those who can already run a VM. Dynamic memory reclamation is turned on by default for any modern Linux distributions running in Hyper-V. Last I checked the performance of \\wsl$ is terrible (certainly not on par with NFS). I can see it might be slightly more ergonomic for casual users though, but certainly not to the point WSL 1 has already been at.

tjoff 6y ago

WSL 1 (haven't tried 2 if they have some sort of magic for this, guess not) can actually run windows applications. So you can run "ipconfig.exe | cowsay" for instance. 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. 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. But an utility that can list and kill both Linux and windows processes can be done in a short shell-script.

1996 6y ago
The same is possible in msys2, and actually very useful. For example, to find my IP, from my bash prompt on windows 10: /c/Windows/System32/ipconfig.exe | grep "^\s\s\sIPv" | sed -e 's/.*: //g'
shawnz 6y ago
WSL 2 actually also supports that integration. It works by transparently sending the stdio over the network to/from the host instead.

eyelidlessness 6y ago

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

mdip 6y ago

> Can you imagine how cool it would be to manipulate Windows services from the WSL session? This was a little confusing, in some ways, because it came right after "being able to list out processes to kill". A Windows Service is a lot like a `systemd` service. 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. [0] Was it this way in WSL1? I don't remember, it's been too long. [1] Last time I used WSL2, I ran openSuSE Leap; not sure what the default ships with.

shawnz 6y ago
In WSL1, you can't see windows processes in 'ps' or '/proc/[pid]' as if they were linux processes, but you could just execute the Windows tasklist.exe/taskkill.exe binary instead and parse the stdout. Actually, you could do the same with WSL2 also.

jagged-chisel 6y ago

I want fish as my shell. Easy peasy. I want to type ‘code <dir>‘ and have it open in VSCode. Can’t.

Tijdreiziger 6y ago
That works for me on bash on WSL1, interested to know why that wouldn't work on fish?
- jagged-chisel 6y ago
  Thought we were talking about WSL2. Apologies for not including that context.
int_19h 6y ago
I use fish as my default WSL shell, and I run "code ..." from it all the time. What doesn't work for you?
- jagged-chisel 6y ago
  Doesn’t work for me in WSL2. Can’t recall the error/behavior at the moment. Was easier just to use a Linux VM at that point.

29athrowaway 6y ago

How would you send SIGSTOP and SIGCONT to a Windows process? Using kill on Windows processes sounds weird.

deleted 6y ago
[deleted]

apatheticonion 6y ago

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. 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: - Connections to Windows VPNs wouldn't work well inside the WSL guest - Running browser automation tools like Playwright wouldn't allow you access to the browser in Windows - The WSL2 guest can't connect to services (tcp, ports, whatever) running on the Windows host - Trying to do something like `ssh -D 1337` from inside the WSL guest is confusing - If you run `ssh -L 8080:localhost:8080 remote.com` using powershell, the WSL guest does not have access to port `8080`. 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. 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. 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). 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. 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). If MS deprecates WSL1, I will probably move back to MacOS or Linux.

ImprobableTruth 6y ago
>The WSL2 guest can't connect to services (tcp, ports, whatever) running on the Windows host I assume you're talking about how you need to use the hosts ip rather than localhost? Because you definitely can access host ports. I'm even connecting WSL2 to an X server running on windows.

wnevets 6y ago

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

baq 6y ago
re files - you can mount an nfs export in WSL and Windows 10 comes with a opt-in NFS server - or perhaps try samba. re network - if you mean localhost, that's probably impossible due to WSL2 being a vm unless the folks at MS invent some deep black magic. you should be able to use the LAN interface IP address, though.

chx 6y ago

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. > ptrace(PTRACE_TRACEME, 0, 0, 0) = -1 EPERM (Operation not permitted) Issues also exist for PTRACE_O_TRACEEXIT, PTRACE_O_TRACEEXEC, PTRACE_OLDSETOPTIONS, PTRACE_SYSEMU.

shawnz 6y ago
It seems like those bugs were fixed some time ago. See: https://github.com/microsoft/WSL/issues/555 https://github.com/microsoft/WSL/issues/555
- chx 6y ago
  The big one is https://github.com/microsoft/WSL/issues/2028 https://github.com/microsoft/WSL/issues/2028 which is "fixed-in-wsl2" This makes lldb and dlv both just not work in wsl1 and that's just the languages I dabbed in, I think the Swift debugger had issues as well.
  - shawnz 6y ago
    Interesting, you are right I can repro the bug in issue 2028 although 555 claims to be fixed.

deleted 6y ago

[deleted]

mdoms 6y ago

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: https://twitter.com/richturn_ms/status/1245481405947076610 https://twitter.com/richturn_ms/status/1245481405947076610

spondyl 6y ago
You can see a similar comment from Rich Turner here on Hacker News too, under the username bitcrazed: https://news.ycombinator.com/item?id=13697918 https://news.ycombinator.com/item?id=13697918 I'd never actually read it with the apostrophe as pointing out in that tweet so the name makes a lot more sense now. Perhaps Windows Subsystem for (running) Linux would be clearer hah Also, according to his profile, Rich is former Product Manager for WSL and currently "Sr. PM for the Windows Command Line, Windows Terminal" The interpretation in the article was still interesting nonetheless
- dataflow 6y ago
  They could've called it the Windows Linux Subsystem and done away with the confusion.

hossbeast 6y ago

There was once a dream that was WSL, you could only whisper it. Anything more than a whisper and it would vanish, it was so fragile.

electrotype 6y ago

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?

gizmo385 6y ago
Ease of use and ease of setup - both of which are important. If I want to setup an Ubuntu VirtualBox, I have to download the VirtualBox software, find the Ubuntu ISO, and run through the setup process. Then I've got to work through any quirks with the setup to get it working seamlessly within the larger windows environment. With WSL? I hit the install button on the windows app store. That simplicity is important and vastly increases the immediate utility of something like WSL, especially if you just want to try it out.
- electrotype 6y ago
  I'm pretty sure those who would actually use WSL are also able to install a regular VM or Docker.
  - TillE 6y ago
    WSL launches near-instantly, consumes few resources, runs programs very fast, has seamless access to my Windows drive, etc. It's nice and light where a VM is bulky. It does everything I want as a Linux terminal on Windows. I'm completely indifferent to the stuff mentioned in this blog post, as I'm not a Windows sysadmin.
bootlooped 6y ago
Better performance, easier to use if you're just using command line stuff, first-party support. Docker's own docs state that it's better to run containers on the WSL2 backend than the old way (a hyper-v vm just for Docker). Flip the question the other way: what does VirtualBox offer me that I'm not getting from WSL2? I just need Linux command line tools for software development. This feels like the best way to get them on Windows. It's easy to imagine use-cases when a full blown VM are better; not my current use-cases though.

snarfy 6y ago

I tried upgrading to wsl2 only to find out USB serial doesn't work. I use wsl1 to program my esp32 boards.

sfblah 6y ago

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. I see others are offering similar comments, so I'll stop there. Try bash; it's ok in many cases.

strunz 6y ago
It's cool, but warning that it treats variables differently. For example if you run an EXE command-line tool which looks for Windows environment variables, it won't use the Bash environment variables. Probably not a huge deal, just a gotcha we've hit at my company which caused a lot of wasted debugging time.

ncmncm 6y ago

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 those programs, but that's table stakes. Other than those, it's Linux from here to the bank, and those processes show up in ps output with right numbers even.

dboreham 6y ago
Because his job is to ship software that runs on Windows. You can only do that on actual Windows.
- ncmncm 6y ago
  That is a manifestly false statement. E.g., the whole MSYS system is cross-compiled, and tested on Wine. Of course, programs would still need QA on real windos, and OS bugs they tickled would not be reproduced. But running them in a VM, with the file system exposed via Samba, would tickle the OS-interaction bugs. Those runs wouldn't show up on ps. True, mgmt might look at him funny. But in my experience they do anyway. So, the question remains open.

Ericson2314 6y ago

Conway's law means were going to end up with quasi-microkernels. - 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.) - Imagine vendor lock-in^2 where my app only runs with Linux and Windows via WSL! - NT and XNU are already that way, probably in-part due to Conway's law - Various "serverless" cloud gambits will chop things up in different ways - Maybe the Fuschias of the world will want a WSL too

saagarjha 6y ago

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.

shmerl 6y ago

In reverse, on Linux I'd surely prefer to use Wine to run Windows programs, instead of using a VM. > But keeping WSL 1 running is a monumental effort due to the need to keep up with Linux changes. 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.

meekrohprocess 6y ago

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

sime2009 6y ago

> Can you imagine how cool it would be to manipulate Windows services from the WSL session? 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.

TeMPOraL 6y ago
But there's literally no point in having WSL then, as such users can just keep using VirtualBox as they always did.
- sime2009 6y ago
  The goals of WSL2 compared to VirtualBox or HyperV are: * Lower memory use * Tighter integration with networking. i.e. it looks like it is running on localhost. * Start/stops on demand, and much faster. * (easier) file system integration. i.e. you can easily get to your Linux files from inside Windows. So there actually are some points to WSL2. For me personally I couldn't get Docker (actually its networking) to work properly via WSL2 so I'm still on a VM. But at least it works. VSCode's remote working feature is fantastic too in this situation.
  - deleted 6y ago
    [deleted]
- wildpeaks 6y ago
  That's exactly what I ended up concluding as well when I tried switching to WSL 2 because it added too much friction to the DX, whereas Docker Compose and the Docker VSCode extension kept things simple and scoped. I didn't even keep WSL 2 as Docker engine because it doesn't forward filechange events from shared folders (which breaks livereload / watch mode), ended up going back to Hyper-V and it does exactly what I need.
  - sime2009 6y ago

tilolebo 6y ago

No words can describe WSL1 better than those from Gavin Belson talking about Nucleus: https://www.youtube.com/watch?v=hrO9ZZlg32w https://www.youtube.com/watch?v=hrO9ZZlg32w

tkubacki 6y ago

Hmm it could be nice idea to add WSL2 "module" to allow call "exe" from inside WSL2 env. Is this technically currently possible somehow ?

unnouinceput 6y ago

Quote:"...or, god forbid, suffer through the ancient CMD.EXE console". What's wrong with cmd.exe? It's a good tool 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.

for_xyz 6y ago
It's possible to interact with native windows tooling from WSL. Example: $ echo "test" > test.txt & notepad.exe test.txt
ChrisSD 6y ago
This is the first time in a long time I've heard anyone refer to cmd as a "good tool". It's a legacy from DOS. Not in the literal sense of course but in the sense of the builtins, syntax and the horrendous BAT. Mind you DOS had a lot of fans even in the late 90's/00's so of course it had its advocates. But they are much rarer nowadays.

GekkePrutser 6y ago

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 :( After all, people who wanted to do that could always run Linux in a VM.

0dmethz 6y ago

I don't really understand this point of view. WSL2 is faster and works better in almost every way. As a developer I absolutely love it and it has changed my workflow completely. 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. 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. 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.

xmodem 6y ago

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.

mwilliams0156 6y ago

WSL - Windows Subsystem FOR Linux, meaning It is a subsystem within windows that is setup FOR linux to run. Its a possession thing.

mwilliams0156 6y ago

Windows Subsystem FOR Linux... meaning the Windows OS possesses Linux ... Makes perfect sense if you are familiar with the English language and how possessives work.

kazinator 6y ago

> 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 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. kill works by sending signals. This makes no sense to processes that are not in the Linux domain. Edit: also what ralph87 writes in paragraph 4: https://news.ycombinator.com/item?id=25154556 https://news.ycombinator.com/item?id=25154556