> In my experience, WSL1 is also very, very slow
I've commented this in the past, but WSL1 is much faster than WSL2 when interoping with the Windows file system[0]
[0]https://github.com/microsoft/WSL/issues/4197
In Multipass 1.0 – Mini-cloud on Mac or Windows workstationmicrosoft
WSL
C++2016–2026
microsoft / WSL
WSL
Windows Subsystem for Linux
222Distinct people
260Mentions
2Explicit recommenders
34.4KGitHub stars
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
- microsoft/wslg · linked in 2 of the same 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, 12:45:45 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.
* 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
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 23 | 4 | 19 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 33 | 2 | 31 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 13 | 1 | 12 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 23 | 0 | 23 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 40 | 4 | 36 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 37 | 3 | 34 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 18 | 3 | 15 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 27 | 4 | 23 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 13 | 0 | 13 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 22 | 5 | 17 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 11 | 5 | 6 |
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 GitHubWhat Hacker News says
23 sources> WSL 2.0...is very fast
Unless you want to interop with the Windows file system[0]
[0]https://github.com/microsoft/WSL/issues/4197
In Ask HN: Feasible Alternative to the MacBook Pro?>I don't like PowerShell, it is too verbose.
alias
>Intel Graphics drivers has a lot of bugs
They suck everywhere. I've had nothing but problems with HD4600 on Linux. Frequent video player crashes, kernel lockups, glitches, the whole shebang.
>- ClearType has been improved but Linux ... font aliasing is a lot better.
I have the opposite experience. Depends on your display I guess.
>I would like to remove the task bar
You can remove it. I don't use and don't see it on Win10.
>- NTFS is getting old and it is very slow if you have a lot of small files.
It's not NTFS. NTFS by itself is plenty fast.
https://github.com/Microsoft/WSL/issues/873#issuecomment-425...
In Show HN: Cascadia Code, a Font for Windows Terminal and VSCodeWSL 2 is the real game changer.
I'm on an issue for WSL 1 where there's a nasty bug when dealing with a lot of files. The only way you can free up the file system is to restart. https://github.com/microsoft/WSL/issues/2882
WSL 2 alleviates this file issue. There are some issues where daemons like postgres, mongo, etc. aren't started by default and sysctl.conf isn't respected. A manual command has to be ran.
Windows 10 is fast. It has amazing support for high resolution displays and multi-monitor that a light year ahead of anything Linux has unfortunately.
WSL also gives choice of distro. You get to use the stable packages instead of being stuck with a brew package that's broken.
In Microsoft Hosts First Windows Subsystem for Linux Conference> Well for starters WSL implements Linux system calls, so it definitely has its own system calls!
Sure, but not in the NT system call table.
> But even beyond that, I was thinking of one thing they added for performance reasons (see 3rd bullet): https://github.com/Microsoft/WSL/issues/873#issuecomment-425....
> However I'm not entirely sure if it's a concrete "syscall" or if it's implemented as a new option through an existing one. (It's not clear to me how they could reasonably fit this into anything that already exists, but it might.) Though I would be mildly surprised if they didn't implement at least one syscall specifically for WSL...
It's neither, it's an API inside kernel space. They didn't expose it through the NT syscall table, but instead how the linux transtalion layer calls directly into NT kernel functions.
In Windows X86-64 System Call TableWell for starters WSL implements Linux system calls, so it definitely has its own system calls!
But even beyond that, I was thinking of one thing they added for performance reasons (see 3rd bullet): https://github.com/Microsoft/WSL/issues/873#issuecomment-425...
However I'm not entirely sure if it's a concrete "syscall" or if it's implemented as a new option through an existing one. (It's not clear to me how they could reasonably fit this into anything that already exists, but it might.) Though I would be mildly surprised if they didn't implement at least one syscall specifically for WSL...
In Windows X86-64 System Call TableIt's not a problem with NTFS and switching to another filesystem won't help. It's the classic "death from a thousand papercuts". The only way to mitigate performance issues is to bypass most of their I/O stack altogether, like they did with WSL2.
https://github.com/Microsoft/WSL/issues/873#issuecomment-425...
In exFAT in the Linux kernelMost of the performance issues are not NTFS so much as the prevalence of file-system filter drivers. This is why WSL had so many file-system performance issues despite the fact that it was using a custom FS. IIRC this also motivated the move to WSL2 from what I read, since a virtual machine can use a small set of files to store a whole FS.
EDIT: See here - https://github.com/Microsoft/WSL/issues/873#issuecomment-425...
In exFAT in the Linux kernelThe Windows tree is unlike the Linux tree in that the Windows tree is the entirety of Windows, not just the kernel. Not having to check out the entire tree is why GVFS was made.
https://github.com/Microsoft/WSL/issues/873#issuecomment-425... talks about why Windows I/O for multi-file operations is slow in general (as opposed to sustained I/O on a single file).
In Sunsetting Mercurial Support in BitbucketWSL over NTFS does not preserve file attributes, you'll get 777 everywhere. Plus, the I/O is damn slow currenty, and it's something they are unlikely to fix*; the more files you have, the slower it gets.
https://github.com/Microsoft/WSL/issues/873#issuecomment-425...
In The new DropboxPerhaps you are right, but to me this feels more like Microsoft hedging their bets, rather than a genuine interest in having two parallel products doing effectively the same thing (from a user perspective).
I asked the same question on their GitHub issues:
https://github.com/microsoft/WSL/issues/4022
In The New Windows Subsystem for Linux (WSL2) Architecture [video]It's still an issue in 2019: https://github.com/Microsoft/WSL/issues/3292
In ubuntu you have to pass the --disable-inotify flag and the Debian version (without this flag) simply doesn't work.
In Microsoft Launches React Native for WindowsIt is more then just "MFT contention". Lots of time are spend on other parts of the kernel:
https://github.com/Microsoft/WSL/issues/873#issuecomment-425...
In Windows 10 is getting a Microsoft-built Linux kernelShowing the 15 most recent of 23 sources. Enable JavaScript to search and browse every indexed mention.