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

40 sources
folkrav·Dec 17, 2020
Yeah it's actually pretty damn good. Performance was better than it was with WSL1 for me, at least (especially IO). IIRC they are exploring USB passthrough using Hyper-V sockets, but it's still very early to actually talk about having that included[1] Once they figure that out I might just as well be able to switch over and stop dual booting. I hate dual booting more than I hate Windows, so it would be an improvement. [1] https://github.com/microsoft/WSL/issues/2195#issuecomment-74...
In GWSL: Run graphical Linux apps in WSL
thekyle·Nov 28, 2020
I really wanted to like WSL 2 but it has a lot of bugs that may take years to get ironed out (unusably slow disk IO, memory leaks, virtual disks that grow forever, etc.) I think it would probably work for web development as long as you keep everything inside WSL, but for other development tasks you're going to run into issues real quick. https://github.com/microsoft/WSL/issues/873 https://github.com/microsoft/WSL/issues/4197 https://github.com/microsoft/WSL/issues/4166 https://github.com/microsoft/WSL/issues/4699
In Apple Silicon M1: A Developer's Perspective
wahern·Nov 20, 2020
Your point about the dentry cache seems like a non-sequitur. The cache isn't the bottleneck; the bottleneck is that NTFS is a crappy filesystem. Yes, I've read this comment: https://github.com/microsoft/WSL/issues/873#issuecomment-425... The argument about Windows not having a single, central dentry cache doesn't hold water. For one thing, there's no reason to think that a two-level cache would significantly decrease performance. More importantly, the fact that on Windows most VFS work occurs in the filesystem driver itself only proves that Windows could have implemented an EXT4 driver with better dentry and other semantics and permitted WSL1 environments to keep most of its files on an EXT4 volume, which is what happens with WSL2, anyhow. WSL1 could have been better in every way. It would have required them to track a moving target, but
Read the rest
they already accomplished semantic parity with seemingly minimal resources. Improving performance was certainly possible, and keeping up would have required significantly less work on its own. At the end of the day, I think the reason WSL1 was canned is obvious: the decision to ship WSL1 was probably accidental. Why accidental? Because anyone with the slightest business acumen would realize that a WSL1 environment with feature and performance parity to open source Linux would mean there'd be little reason to target Windows' native environment at all for new software development. And while Microsoft has done relatively well for itself with Azure and other ventures, its revenue still principally derives from Windows and Office, and the last thing Microsoft needs is to accelerate movement away from those products. WSL2 means that Microsoft can keep its Linux environment a second-class citizen without being blamed for it, while still providing all the convenience necessary for doing Linux server application development locally. Integration with the native Windows environment will be handicapped by design and excused as an insurmountable consequence of a VM architecture. For example, with WSL1 and some obvious and straight-forward improvements it would have been trivial to run a Linux-built Electron app with identical performance, responsiveness, and behavior (not to mention look & feel, given the web-like UI). With WSL2 Microsoft will likely only ever provide GUI integration over RDP, which will never have the same responsiveness (not because it's theoretically impossible, but because nobody would ever demand it, and in any event it would require tremendously more effort than the comparable WSL1 approach).
In Windows Subsystem for Linux: The lost potential
hapless·Nov 19, 2020
As I understand it, it's not really possible to "improve" Win32 I/O performance -- both the fundamental I/O APIs and the NTFS on-disk storage format make high performance infeasible. Not without either abandoning all extant FS drivers, or abandoning NTFS compatibility, anyway. Edit: Here are the WSL 1.x's team members original comments on this subject. It sounds like a deeply intractable problem. https://github.com/microsoft/WSL/issues/873#issuecomment-424... https://github.com/microsoft/WSL/issues/873#issuecomment-425... The second link explains why a dentry cache just isn't feasible. The short version is that the NT IO APIs seem to have been very, very ill-considered. It's just not possible to make it fast. Even win32 operations are extremely slow, so win32 applications go out of their way to avoid doing any file I/O. Linux applicat
Read the rest
ions were not written with those constraints in mind.
In Windows Subsystem for Linux: The lost potential
tony·Nov 2, 2020
Also interested in the response to the parent (loeg) > facing many of the same difficulties that prompted the Windows team to just run Linux in a hypervisor If by difficulties, you mean implementing system calls, this is being kept tabs on here: https://wiki.freebsd.org/Linuxulator One that comes to mind is FreeBSD's kqueue, which opens a file descriptor for every file watched [1] So inotify, inotify_add_watch, inotify_rm_watch isn't started. Lots of applications need watching of changes on directories. Even plain old FreeBSD gets messed since a large webpack project is going to chew up way too much. If you're interested in this type of system call across operating systems check out https://github.com/emcrisostomo/fswatch On WSL1/2: Namely in WSL1, there were serious issues with package systems like npm, node_modules/ would have file desc
Read the rest
riptors get clogged, and it took a full system reboot to get WSL working again: https://github.com/microsoft/WSL/issues/1529. WSL2 Fixes it. [1] https://emcrisostomo.github.io/fswatch/doc/1.8.0/fswatch.htm... See Freebsd -> kqueue -> Peculiarities
In Ubuntu Linux Jail on FreeBSD 12.2-Release

Showing the 15 most recent of 40 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.