/jump to repo

Repos Recent Bookmarks Watched Notes Tags Discover Compare Stats GitHub

Repository brief

microsoft/WSL

Read the upstream summary on the left, browse the cached forks below it, and load each fork comparison into the right-hand panel.

Cached analysis

cached 2026-03-30T16:01:52.477Z

1mo ago

microsoft/WSL

microsoft/WSL is the upstream Windows Subsystem for Linux repository: a large, active Microsoft-managed project for running unmodified Linux command-line tools and applications on Windows. It has broad adoption and fork activity, and the repo is current as of March 30, 2026. Forks are most interesting if you want to work near the core WSL implementation, packaging, diagnostics, testing, localization, or Windows integration rather than a small standalone app.

Loading tags...

Stars31,617

Forks1,669

Default branchmaster

Last pushed2026-03-30T15:55:34Z

Recommended shortcuts

Jump straight into Discofork's strongest cached fork picks, or open a compare view in one click.

Forks

Choose a fork to inspect

10 of 10 fork briefs

Maintenance:

Magnitude:

Sort:

Selected

Choose this fork if you need a customizable WSL base with significant changes to runtime, installer, diagnostics, localization, and tests. Avoid it if you want a low-maintenance, upstream-close WSL build, because the fork is materially behind and already diverging in core areas.

Prefer this fork only if you specifically need Arch Linux downstream automation or maintenance plumbing. If you want current, full-featured WSL development or a stable base for feature work, upstream is a better fit.

Prefer this fork only if you need its CI/release or distro-maintenance customizations. If you want current WSL behavior and low maintenance burden, upstream is the better choice because this fork is significantly behind and likely missing recent fixes.

Prefer upstream unless you specifically need this older snapshot; this fork currently offers no visible enhancements and is materially behind on recent WSL fixes and maintenance.

Choose this fork if you want a WSL codebase with substantial local changes around installation, localization, diagnostics, tests, and distro management, and you are willing to manage a meaningful rebase gap. If your goal is lowest-maintenance adoption, upstream is the safer default.

Choose upstream unless you specifically need this exact older snapshot for private work. This fork does not add features, and it lags upstream by 47 commits, so it is a poor choice for adopters who want current WSL behavior.

Adopt this only if you want an essentially unmodified WSL copy and are prepared to catch up with upstream yourself. For most users, upstream is the better choice because this fork adds no visible functionality and is materially behind.

Prefer this fork only if you specifically want its localized, CI-oriented, and test-heavy modifications and are willing to absorb upstream drift. For most users, upstream is the better default because this fork is materially behind and does not show a clearly differentiated product advantage.

Choose this fork only if you want a customized, divergence-tolerant WSL branch with its own CI/localization/test workflow. If you want current upstream WSL behavior and easy upgrades, upstream is the safer choice.

Prefer upstream unless you specifically need this older WSL snapshot or one of its install/networking tweaks. The fork is materially stale and appears to have lost substantial test coverage, so it is a poor default for adopters who want current WSL behavior.

Fork comparison

harshrajdubey/WSL

54/100

slowing

significant_divergence

Choose this fork if you need a customizable WSL base with significant changes to runtime, installer, diagnostics, localization, and tests. Avoid it if you want a low-maintenance, upstream-close WSL build, because the fork is materially behind and already diverging in core areas.

Likely purpose

A customized WSL variant for users who want to change core runtime behavior, packaging/install flows, localization, and test coverage while staying close to the upstream platform.

Best for

Developers hacking on WSL internals.; Teams that need a customized WSL build for a specific Windows integration or enterprise workflow.; Maintainers comfortable carrying a long-lived fork and resolving upstream drift.; Users who care more about modified runtime behavior than staying on the exact upstream release train.

Additional features

Expanded localization work across multiple languages, suggesting a more internationalized build and release path.
Heavier test coverage and test reshaping in Windows network and unit tests, which is useful for validating changed runtime behavior.
Changes in `src/linux/init/init.cpp` and `src/windows/service/exe/WslCoreVm.cpp`, indicating customization of startup, init, or VM lifecycle behavior.
Updates in diagnostics and packaging-related areas, implying more customized troubleshooting or build/distribution workflows.
Repository-level cleanup in docs, notices, and pipeline references, which suggests an attempt to maintain a forked release process alongside code changes.
Introduces more operational workflow surface such as server-side handling, auth, session control, or admin tooling.

Missing features

The fork is 200 commits behind upstream, so it likely misses recent upstream fixes, including late-March 2026 work around localization, DNS behavior, devicehost tracing, uninstall handling, and test maintenance.
`src/windows/common/install.cpp` shows large deletions, which suggests installer-related behavior may be reduced, altered, or harder to rely on compared with upstream.
Upstream’s current cadence around cloud testing, packaging, and diagnostics is not reflected at the same freshness level, so adopters may lose some of the newest upstream reliability work.
Because the fork diverges across core runtime and tests, upstream compatibility and straightforward upgrade/merge paths are likely harder than on a lightly patched fork.
Some upstream behavior appears to be removed, disabled, or intentionally stripped down in this fork.
Some upstream operational features such as auth, admin, or session handling may be reduced or absent.

Strengths

Broad access to core WSL source, packaging, diagnostics, and test infrastructure.
Meaningful customization surface across runtime, startup, networking, localization, and installer-adjacent code.
Potentially useful for validating nonstandard WSL behavior with substantial test changes.
Still recent enough to reflect a working branch rather than an abandoned snapshot.

Risks

Large divergence makes rebasing onto upstream expensive.
Being behind upstream increases the chance of missing security fixes and stability patches.
Installer and runtime edits may change user-facing behavior in ways that are hard to predict without testing.
Localization and test churn can hide functional regressions if adopters assume upstream defaults still hold.