HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
microsoft
WSL
C++2016–2026
microsoft / WSL

WSL

Windows Subsystem for Linux

Systems & InfrastructureMobile & Desktop
Explore on GitHubRead Hacker News discussions
222Distinct people
260Mentions
2Explicit recommenders
34.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Windows Subsystem for Linux

GitHub

Where it is used

  • Docker Desktop — Docker Desktop uses WSL 2 as its engine so docker commands run via the WSL 2 engine on Windows. This is a shipped integration enabled in product settings. Source

What people are saying

My main issue is the lack of support for serial (so, no USB support): https://github.com/microsoft/WSL/issues/2195. Other that this I love Windows 10 + WSL2 as a dev environment.

dgellow used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 5:05:26 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year260 dated mentions

Observed mentions: 2016-04-18 14:55:26 UTC to 2026-10-10 10:32:09 UTC.

0102030402016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 23 mentions; 4 submissions, 19 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 33 mentions; 2 submissions, 31 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 13 mentions; 1 submissions, 12 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 23 mentions; 0 submissions, 23 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 40 mentions; 4 submissions, 36 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 37 mentions; 3 submissions, 34 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 18 mentions; 3 submissions, 15 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 27 mentions; 4 submissions, 23 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 13 mentions; 0 submissions, 13 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 22 mentions; 5 submissions, 17 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 11 mentions; 5 submissions, 6 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC23419
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC33231
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC13112
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC23023
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC40436
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC37334
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC18315
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC27423
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC13013
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC22517
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC1156

From the project README

An excerpt from the repository, fetched Nov 12, 2026.

Read the project’s introduction
Welcome to the Windows Subsystem for Linux (WSL) repository Learn more about WSL | Downloads & Release notes | Contributing to WSL About Windows Subsystem for Linux (WSL) is a powerful way for you to run your Linux command-line tools, utilities and applications, all unmodified and directly on Windows without the overhead of a traditional virtual machine or dual boot setup. You can install WSL right away by running this command inside of your Windows command line: wsl --install You can learn more about best practices for setup, overviews of WSL and more at our WSL documentation page. Related repositories WSL also has related open source repositories: microsoft/WSL2-Linux-Kernel - The Linux kernel shipped with WSL microsoft/WSLg - Support for Linux GUI apps in WSL microsoftdocs/wsl - WSL documentation at aka.ms/wsldocs Contributing This project welcomes contributions of all types, including coding features / bug fixes, documentation fixes, design proposals and more. We ask that before you start working on a contribution, please read our Contributor's Guide. For guidance on developing for WSL, please read the developer docs for instructions on how to build WSL from source and details on its architecture. Code of Conduct This project has adopted the Microsoft Open Source Code of Conduct Trademarks This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft’s Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party’s policies. Privacy and telemetry The application logs basic diagnostic data (telemetry). For more information on privacy and what we collect, see our data and privacy documentation. The software may collect information about you and your use of the software and send it to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may turn off the telemetry as described in the repository. There are also some features in the software that may enable you and Microsoft to collect data from users of your applications. If you use these features, you must comply with applicable law, including providing appropriate notices to users of your applications together with a copy of Microsoft’s privacy statement. Our privacy statement is located at https://go.microsoft.com/fwlink/?LinkID=824704. You can learn more about data collection and use in the help documentation and our privacy statement. Your use of the software operates as your consent to these practices. Note on localization All key CLI texts in WSL are localized, but some detailed error outputs are not fully localized. Specifically in wslc.exe we make use of lower level open source libraries that do not have full localization. We've kept these unlocalized strings in the error output to provide richer failure context so that end users can more easily resolve issues.
Read the full README on GitHub

What Hacker News says

18 sources
chazeon·Nov 16, 2022
Not being able to access WSL from within an SSH session due to "not possible to access wsl from session 0 (which is where the Windows OpenSSH server run)" [1,2] is now a deal breaker for me to upgrade to whatever they called 1.0.0 version or released over Windows Store. The old version (non-Store version) used to work, and now the upgraded / non-Preview version doesn't. I don't know how they dare remove that preview tag. [1]: https://github.com/microsoft/WSL/issues/9059 [2]: https://devblogs.microsoft.com/commandline/a-preview-of-wsl-...
In Windows Subsystem For Linux a.k.a. WSL 1.0.0 released
skissane·Sep 6, 2022
Cool, did not know that. Indeed I see this in shared/afunix.h: #define SIO_AF_UNIX_GETPEERPID _WSAIOR(IOC_VENDOR, 256) // Returns ULONG PID of the connected peer process #define SIO_AF_UNIX_SETBINDPARENTPATH _WSAIOW(IOC_VENDOR, 257) // Set the parent path for bind calls #define SIO_AF_UNIX_SETCONNPARENTPATH _WSAIOW(IOC_VENDOR, 258) // Set the parent path for connect calls // NOTE: setting the parent path is not thread safe. SIO_AF_UNIX_GETPEERPID is something I did not know about either, although apparently a bit buggy – https://github.com/microsoft/WSL/issues/4676 What does the "NOTE: setting the parent path is not thread safe" comment mean? Not thread safe if multiple threads are sharing the same socket? (Which seems like an acceptable limitation.) Or something worse than that?
In Userspace FUSE for macOS
wizwit999·Sep 4, 2022
As a general purpose OS, I actually quite like Windows 11, its nice, clean, and beautiful. But unfortunately, Windows is not there for development. I've used WSL for years and its actually gotten much worse with WSL2, especially with Docker. Specifically, I'd be plagued by this issue (https://github.com/microsoft/WSL/issues/4166), where Docker would eat all the WSL memory and never release it. I finally pulled the plug and use Ubuntu 22 as as a daily OS (on dual boot), the UX is not bad, e.g. I was actually pleasantly surprised by the smoothness of the windowing gestures as a first time user, but there are many warts (e.g. very janky around sleeping/hibernating). I mostly develop and browse the web so its OK overall. MacOS is very good, no real complaints.
In Ask HN: Mac OS vs. Windows in 2022
NavinF·Jul 16, 2022
Indeed it is better for many use cases, but they seemed to have stopped taking feature requests for WSL1 a couple of years ago when I asked for the adjtimex syscall to set system time: https://github.com/microsoft/WSL/issues/6310 > I presume this is wontfix for WSL1? > Yes WSL2 won't help your use-case presently. A feature requestion along the lines of "hardware clock passthrough" could be submitted under a different cover. It’s likely the feature freeze started even earlier and I just never noticed. Also see WSLg (GUI), which only works on WSL 2. I think it’s clear that WSL1 is in maintenance mode.
In Android removes much of Fuchsia-related code as Starnix project progresses
_ugfj·Jul 16, 2022
Mmmmmm a kernel call translator. Microsoft attempted to do it with WSL. Then abandoned the idea and went with a VM called WSL v2. I have no solid proof but I believe at least one of the factors were https://github.com/microsoft/WSL/issues/2028 https://github.com/microsoft/WSL/issues/3031 -- the ptrace() syscall is not a single syscall but more like the infamous rabbit hole which you have no idea the depth of.
In Android removes much of Fuchsia-related code as Starnix project progresses
dataflow·Apr 8, 2022
> Everyone has their favorites, I base mine on experimental data. So do I. If all you care about is raw speed, sure, Linux with ext4 might be "king". But I don't just look at speed. I also look at the design both inside and outside, the capabilities, the resilience & robustness, and a ton of other things besides raw speed. Maybe those aren't relevant to you, and that's fine. They are to other folks though. > I’m yet to be convinced NTFS doesn’t factor in. I'm not saying it doesn't "factor in" (I'm sure you could measure some % difference across any filesystem, and you should actually benchmark against FAT32 and exFAT and whatnot before blaming NTFS), but it's not the dominant factor you can blame it on. You can read more here if you're interested (you'll have to expand the hidden comments): https://github.com/microsoft/WSL/issues/873#issu
Read the rest
ecomment-425... > No, compilation is six times faster in Linux in almost every single language I’ve compiled using the exact same hardware setup. I have no idea what you're doing when compiling, but I'm going to guess you either have lots of tiny files that otherwise compile very quickly (thus the slowness in opening files hits you), or you're running a ton of shell scripts in your "compilation" (process spawning is slow on Windows), or you have antivirus or something turned on, or you have some compiler with quirks like GCC. If you give more details I can help you track down what is going on, but a 6x slowdown is simply not something that you can attribute to NTFS by itself. There's something else going on. I'm going to take a guess that you're using Unix-first tools that have been ported to Windows, rather than designed for tools Windows from the ground-up, and finding that there's an impedance mismatch here. Unix tools are designed around shoving every little thing into a tiny file (whether it's a data, script, or executable file), because that's the religion. Windows just isn't designed with that philosophy (e.g., it assumes you'll access the registry for configuration, load DLLs for external functionality, etc.), and hence Windows-native tools don't deal with nearly as many files as ported Linux-native tools do. There are lots of architectural differences (this is just one example), and they do come with their own advantages and disadvantages. > If SSDs didn’t solve I/O for windows then I’ll concede the I/O is garbage I'm confused... are you saying your "experimental data" is from before the SSD era? So this "6x faster" we've been arguing about your experience from over a decade ago? on hard disks? If so, that's a frustrating way to argue about these. > Simply put: Windows needs a ground-up overhaul and to stop catering to the old win32/NTOS/NTFS model. But I don’t really intend nor expect to convince anyone. It's kind of bizarre to read that given your experience seems to be from a different era (?) and when it is in fact Linux who has been forced to overhaul its I/O design from the ground-up with uring. (Compare Windows's IOCP from > 2 decades ago with Linux's epoll. The epoll model itself literally did not even make sense for disk I/O, never mind its implementation.) I could of course argue about the details all day, but I do agree with you that the case you're trying to make isn't convincing. That is, except if your case is "Linux is better for raw speed if you ignore everything else", in which case, yes I agree.
In Using Windows after 15 years on Linux
jve·Mar 11, 2022
Few days ago, I spent quite a few hours trying to make `apk update` work for alpine on WSL2 on Windows. It didn't want to resolve dl-cdn.alpinelinux.org within alpine. Did resolve on host ubuntu. 1. WFH from VPN, firstly I had to lower mtu from 1500 to 1392 (My VPN specific issue) https://github.com/microsoft/WSL/issues/4698 2. Next, I had to run some powershell script that updates /etc/resolv.conf to use my VPN DNS (WSL specific stuff) https://github.com/microsoft/WSL/issues/1350 3. And I still don't know if apk works properly. Kind of works in Docker build, but I have a feeling something not quite right. See this example. Why does it "hang"? Docker command not exiting docker run -it alpine:3.15 apk update fetch https://dl-cdn.alpinelinux.org/alpine/v3.15/main/x86_64/APKINDEX.tar.gz Now, doing it within container itself, works: do
Read the rest
cker run -it alpine:3.15 sh / # apk update fetch https://dl-cdn.alpinelinux.org/alpine/v3.15/main/x86_64/APKINDEX.tar.gz fetch https://dl- cdn.alpinelinux.org/alpine/v3.15/community/x86_64/APKINDEX.tar.gz v3.15.0-342-g4fee739486 [https://dl-cdn.alpinelinux.org/alpine/v3.15/main] v3.15.0-340-g4ed6115e99 [https://dl-cdn.alpinelinux.org/alpine/v3.15/community] OK: 15859 distinct packages available / # exit Can someone shed some light?
In DNS resolution issue in Alpine Linux (2021)

Showing the 15 most recent of 18 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.