17 Punkte von GN⁺ 2025-05-20 | 6 Kommentare | Auf WhatsApp teilen
  • Microsoft hat angekündigt, WSL vollständig als Open Source freizugeben – zugleich eine Antwort auf das allererste Issue im Repository Microsoft/WSL: „Wird es Open Source?“
  • Auf GitHub unter Microsoft/WSL kann der Quellcode heruntergeladen, direkt gebaut sowie um Funktionen erweitert und von Bugs bereinigt werden
  • Der veröffentlichte Code umfasst Kommandozeilen-Tools, Services, Daemons für Linux und sogar einen auf Plan9 basierenden Dateifreigabe-Server
  • WSL besteht aus mehreren Komponenten, die im Windows-Ausführungsteil und innerhalb der Linux-virtuellen Maschine (VM) laufen
    • CLI-Tools: wsl.exe, wslconfig.exe, wslg.exe
    • WSL-Service: wslservice.exe, zuständig für VM-Start, Ausführung von Distributionen, Dateifreigabe usw.
    • Linux-Daemons: init, gns, localhost usw., die Netzwerk- und Port-Forwarding-Funktionen übernehmen
    • Plan9-Server: übernimmt die Dateifreigabe zwischen Windows und Linux
  • Bereits zuvor als Open Source veröffentlichte Komponenten
    • WSLg: Komponenten rund um die grafische Umgebung mit Unterstützung für Wayland- und X-Server
    • WSL2-Linux-Kernel: Linux-Kernel-Quellcode
  • Komponenten, die noch nicht offengelegt wurden
    • Lxcore.sys: der Kerntreiber von WSL1
    • P9rdr.sys, p9np.dll: das Datei-Umleitungssystem, das unter Windows den Pfad \\wsl.localhost unterstützt

Hintergrund der Open-Source-Umstellung und die Geschichte von WSL

  • WSL wurde erstmals auf der BUILD 2016 angekündigt und in das Windows 10 Anniversary Update aufgenommen
  • WSL1 basierte auf lxcore.sys, einer Architektur, die Linux-Syscalls innerhalb des Windows-Kernels verarbeitet
  • WSL2 wurde 2019 erstmals vorgestellt und verbessert mit einem echten Linux-Kernel Kompatibilität und Funktionsumfang
  • Danach wurde WSL mit Funktionen wie GPU-Unterstützung, Ausführung von GUI-Apps (wslg) und systemd-Support weiter ausgebaut
  • Seit 2021 wird WSL als eigenständiges, von Windows getrenntes Paket über den Microsoft Store bereitgestellt
    • Die erste Veröffentlichung war 0.47.1 (Preview), danach wurde mit 1.0.0 im Jahr 2022 die Unterstützung bis Windows 10 erweitert
  • Ab Windows 11 24H2 erfolgt der Wechsel vom bisher integrierten WSL auf das neue paketbasierte WSL
    • wsl.exe bleibt unverändert erhalten, um den Umstieg der Nutzer zu unterstützen

Aktuelle Version und Funktionen

  • Die neueste Veröffentlichung ist WSL 2.5.7; über vier Jahre hinweg wurde es durch GitHub-Releases im Umfang von rund neun Seiten kontinuierlich verbessert
  • Zu den wichtigsten Verbesserungen gehören gespiegeltes Networking, DNS-Tunneling, Session 0 sowie Proxy-/Firewall-Unterstützung

Beiträge der Community

  • Über Jahre hinweg hat die Community durch Bug-Reports, Funktionsvorschläge und inoffizielle Analysen zur Verbesserung von WSL beigetragen
  • Schon vor der Offenlegung des Quellcodes gab es substanzielle Beiträge, nun sind auch direkte Code-Beiträge möglich
  • Microsoft bedankt sich für die Unterstützung dieser Community und erwartet künftig noch stärkere Synergien bei der Weiterentwicklung von WSL

Wie man beitragen kann

  • Wer mehr über die Struktur des Quellcodes oder die Implementierung von Funktionen erfahren oder Verbesserungen beitragen möchte
    • kann sich im Repository microsoft/WSL beteiligen
    • etwa durch eigene Builds, das Einreichen von PRs oder das Melden von Issues

6 Kommentare

 
ing03201 2025-05-27

Aus der Sicht von jemandem, der Endeavour +lustre / Windows 11 + WSL + WSA verwendet,
ist Letzteres in Sachen Komfort besser.
Die Performance ist allerdings bei Ersterem besser.

 
iolothebard 2025-05-21

Anscheinend wurde diesmal auch im WSL-Team stark gekürzt …

 
forgotdonkey456 2025-05-21

Wenn kein Personal da ist, wird es heutzutage bei MS einfach unter dem Vorwand „community-driven“ Open Source gemacht, lol..

 
zihado 2025-05-21

Das wirkt wie Resteverwertung.

 
ksb9770 2025-05-20

WSL1 ist die beste Maschine für eine plattformübergreifende Entwicklungsumgebung. Auch die I/O ist schnell, und Linux-basierte Befehle lassen sich unmittelbar ausführen. WSL2 ist beim Cross-Compiling langsamer als WSL1.

 
GN⁺ 2025-05-20
Hacker-News-Kommentare
  • Ich habe immer das Gefühl, bei Hacker News eine Art Karma-Steuer zu zahlen, wenn ich einen lobenden Kommentar über WSL schreibe. Auf einem einzelnen Rechner mehrere Linux-Versionen gleichzeitig so einfach ausführen zu können, lässt WSL auf mich sogar mächtiger als Linux selbst wirken. Die Unterstützung für Dinge wie Docker, lokaler Speicher und Netzwerk-Mapping ohne spezielle Skripte sowie die sofortige Nutzbarkeit auf Desktop oder Laptop ohne zusätzliche Einrichtung finde ich besonders attraktiv. Wenn zum Beispiel ein Projekt Ubuntu 22 und ein anderes Ubuntu 24 braucht, ist es einfach großartig, sich nicht ständig um OS-Updates sorgen zu müssen.

    • Die Aussage „mächtiger als Linux“ ist übertrieben; WSL ist letztlich eine virtuelle Maschine. Die größte Stärke von WSL liegt in der Automatisierung vieler Komfortfunktionen. Aber wirklich bequemer ist meiner Meinung nach eine Umgebung, die gar keine VM braucht. Tools wie Distrobox und toolbx bieten Ähnliches, und auch unter NixOS lassen sich normale Linux-Umgebungen leicht testen. Dazu kommen Hardwarebeschleunigung, direkt funktionierende Grafik-Apps, keine langsame 9p-Bridge und keine Probleme wie Memory Ballooning in VMs. Für Windows-Nutzer ist WSL revolutionär, aber Linux-Nutzer brauchen so eine VM eben gar nicht.

    • Unter Linux kann man mit Distrobox etwas Ähnliches umsetzen, aber die Kombination aus Windows + WSL hat definitiv ihren Reiz. Wenn Microsoft eine Dev-Edition mit weniger Bloatware, Werbung, Copilot und übertriebener Telemetrie herausbringen und dazu Hardware auf MacBook-Niveau liefern würde, könnten sie durchaus Entwickler zurückholen, die zu Apple gewechselt sind. Ich wechsle selbst zwischen Mac- und Linux-Umgebungen hin und her und finde in Sachen Bedienbarkeit manches an Windows + WSL sogar angenehmer. PowerToys, WSL, PowerShell und die Automatisierung der PC-Einrichtung mit PowerShell + Winget DSC sind wirklich stark, aber die Nutzerfeindlichkeit von Windows und die absurd langen Update-Zeiten sind kaum auszuhalten. Noch besser wäre eine unveränderliche Basis mit imagebasierten Updates wie bei macOS. Dass es auf der Windows-Seite nichts mit der Leistung eines M4-Pro-Laptops gibt, ist ebenfalls ein Nachteil.

    • Die Behauptung, „WSL sei mächtiger als Linux“, ist meiner Meinung nach eine Aussage, für die man zu Recht Karma verliert. WSL ist gut, und ich nutze es täglich, aber auf unterstützter Hardware ist die Erfahrung mit nativem Linux einfach besser. So wie eine VM nie so gut wie nativ sein kann, läuft umgekehrt Windows-Software auch unter Windows besser. Im Vergleich ist WSL bei Ein-/Ausgabe langsamer, die Grafik hat Latenzen und Fehler, gelegentlich gibt es Abstürze, ineffizientes Speichermanagement und Netzwerkprobleme. Auf einem sehr leistungsstarken Rechner und mit Fokus auf CLI-Workloads kann WSL bequem sein, aber am Ende hängt es von den Anforderungen der jeweiligen Person ab.

    • WSL ist in Wahrheit Linux. Besonders seit WSL2 ist es ohnehin eine VM-Struktur, während WSL1 noch direkt auf dem Windows-Kernel lief, was ich ziemlich cool fand. Mein größtes Problem ist aber das langsame NTFS-Dateisystem und dass man sich überhaupt mit Windows herumschlagen muss. Karma-Zahlen sind für mich sowieso nur Zahlen, also ist mir das egal.

    • Für mich ist WSL ziemlich instabil, und jedes Mal wenn der Rechner aus dem Sleep zurückkommt, muss ich wegen Netzwerkproblemen zwischen VM und Host neu starten. Wenn man im Windows-Benutzerverzeichnis arbeitet, dauern git-Befehle wegen des langsamen Dateisystemtreibers mehrere Sekunden, sodass man am Ende zwei Home-Verzeichnisse verwalten muss. Auch beim Setup gab es viele obskure Probleme zu lösen: kompliziertes DNS, VPN, Fehler in der Netzwerkpriorität, Zeit-Synchronisationsprobleme und mehr. Am Ende läuft es darauf hinaus, Windows ständig neu zu booten. Ich brauche keine mehreren Betriebssysteme, und in meiner Firma laufen die meisten Tools ohnehin in einer Linux-VM; das ist die einzig vernünftige Lösung. Das Host-Betriebssystem schafft eher zusätzliche Probleme, und die Interaktion zwischen zwei Betriebssystemen macht alles unnötig kompliziert.

  • Ich habe mich sehr gefreut, als WSL zum ersten Mal veröffentlicht wurde. Es fühlte sich an, als würde der Traum wahr, Gaming und Entwicklung auf einem einzigen Windows-PC zu vereinen. Aber mit der Zeit häuften sich kleine Probleme wie Paketinstallationen und Reibungen an den Grenzen zwischen den Betriebssystemen, und alles wurde zunehmend mühsam. Mit Proton von Valve und der verbesserten Linux-Unterstützung für moderne Spiele bin ich schließlich komplett auf Ubuntu und NixOS umgestiegen. Beim Gaming ist es jetzt etwas unbequemer, aber die Entwicklungsumgebung ist dafür deutlich angenehmer. Abgesehen davon, dass einige AAA-Spiele nicht laufen, ist es für mich eine bessere Erfahrung als Windows + WSL.

    • Ich hatte eine ähnliche Erfahrung, und inzwischen ist Linux zu installieren für mich sogar einfacher. Durch die Spyware-Funktionen von Windows gibt es immer weniger Gründe, es überhaupt zu verwenden.

    • Außer natürlich, man verwendet eine Nvidia-Grafikkarte.

    • Bei welchen Spielen gab es Probleme?

    • Ich denke, die meisten haben so etwas schon erlebt. Wenn Windows heute nicht für Gaming (GPU) relevant wäre, hätte es wohl kaum noch Bedeutung. Ich erinnere mich auch an frühere Projekte, bei denen man zwischen msvc, cygwin, msys2 und anderen Build-Umgebungen hin- und herwechselte und dabei im Chaos versank. Heute lässt sich manches mit WSL einfacher bauen, aber selbst das Ändern einer einzigen Umgebungsvariable fühlt sich ermüdend an, und ich möchte so etwas nie wieder durchmachen.

  • Ich würde eher empfehlen, Windows unter Linux in einer VM zu betreiben. Wenn man unter Windows irgendwann Linux nutzen möchte, sollte man gleich ganz zu Linux wechseln und nie zurückblicken. Ich bin seit 15 Jahren nicht mehr zu Windows zurückgekehrt. Wenn man den aktuellen Zustand von Windows betrachtet, zögere ich inzwischen sogar, es überhaupt noch in einer VM zu nutzen.

    • Bei GPU-bezogener Arbeit wie Gaming oder der Adobe Suite muss man für Windows in einer VM eine eigene GPU an die VM durchreichen; wer das nicht kann, muss auf Beschleunigung verzichten. Deshalb ist die VM-Variante nicht so einfach. Photoshop mit dem QEMU-QXL-Treiber zu betreiben liefert eine miserable Performance, und VirGL unterstützt Windows-Gäste überhaupt nicht. VMWare und VirtualBox sind etwas besser, reichen aber trotzdem nicht an nativ heran.

    • Ich glaube, in den meisten Windows-bezogenen Threads sieht man klar die Trennung zwischen Leuten, die wegen Produktivitäts-Apps unbedingt Windows brauchen, und denen, die das nicht tun. Wenn man wie ich GPU-lastige Produktivitäts-Apps nutzt, ist eine VM keine Option, und man muss Windows nativ verwenden. Für leichte Apps reicht eine VM aus, aber für ernsthafte Arbeit wie CAD oder Gaming ist sie ungeeignet.

    • Ich habe jahrelang nur Linux verwendet, bin dann zu Windows und später wieder zu Mac zurückgekehrt. Probleme mit der Wine-Kompatibilität, unfertige Software-Alternativen wie GIMP als kein vollwertiger Photoshop-Ersatz und die optische Zerrüttung des Desktops durch die Mischung aus Qt- und GTK-Apps zeigen, dass Linux kein Allheilmittel ist.

    • Dagegen würde ich aus eigener Erfahrung einwenden, dass ein VR-Gerät wie die Valve Index in so einer Umgebung, also Linux mit einer Windows-VM, überhaupt nicht richtig funktioniert. Ich war seit meiner Kindheit ein Hardcore-Linux-Nutzer, aber solche Spezialfälle gibt es eben, weshalb pauschale Verallgemeinerungen schwierig sind.

    • Als zusätzliche Info gibt es einen offiziellen Link zu Windows-Test-VM-Images. Wenn die Testphase endet, wird der Desktop schwarz, und der PC fährt stündlich herunter. Die neuesten Test-Images wurden seit mehr als sechs Monaten nicht aktualisiert, aber nach Registrierung bekommt man ein ISO.

  • Der Name Windows Subsystem for Linux verwirrt mich jedes Mal. Auf den ersten Blick wirkt es fast wie eine offizielle Version von Wine, dabei ist es eigentlich ein Windows-Subsystem für Linux. Es klingt, als würde Microsoft Linux etwas geben, und das gefällt mir nicht.

    • Microsoft konnte dem Projekt offenbar keinen Namen geben, der mit „Linux“ beginnt, deshalb wurde es am Ende WSL.

    • Die Benennung stammt von einem früheren Projekt namens Windows Subsystem for Unix. Der Name hat also schon immer Erwartungen geweckt, die nicht ganz zum tatsächlichen Verhalten passten.

    • Ein scherzhafter Verbesserungsvorschlag wäre: das Linux-Subsystem von Windows.

    • Es ist ein Subsystem, um Linux auf Windows auszuführen, aber ich stimme zu, dass die Benennung verwirrend ist.

  • Ich habe in den letzten Jahren immer mal wieder mit WSL entwickelt. Wenn es funktioniert, ist es großartig; wenn etwas kaputtgeht, ist es ein echter Albtraum. Ständig gab es Probleme mit Netzwerk, VPN, XServer, Windows-Skalierung und hardwarebeschleunigter Grafik. Gefühlt habe ich mehr Zeit mit Fehlersuche als mit tatsächlicher Entwicklung verbracht, und ich habe nie den Eindruck gehabt, dass sich das verbessert hätte. WSL ist schnell und leistungsfähig, aber für den täglichen Einsatz ist es für mich zu anstrengend. Stattdessen nutze ich hauptsächlich MSYS2; es ist langsamer, aber zumindest stabil, und das ist der größte Vorteil.

    • Ich benutze immer noch die WSL-Beta und kann nicht einmal upgraden, weil ich fürchte, dass ein Update meine aktuell funktionierende Umgebung zerstört.
  • Letzte Woche gab es trotz Rekordergebnissen massive Entlassungen bei Microsoft; ich frage mich, ob dieses Phänomen eine Nebenwirkung davon ist.

    • Ich denke, Entlassungen im Umfang von 3 % haben in einem Großkonzern praktisch keine Auswirkungen, solange nicht die ganze Firma oder ein komplettes Projekt eingestellt wird. In großen Unternehmen gibt es ohnehin oft Überbesetzung, daher ist so etwas im Grunde nichts Besonderes.

    • Entscheidungen, Vorbereitung und Umsetzung einer Open-Source-Freigabe in so einem Großkonzern sind auf jeden Fall ein riesiges Projekt, das unmöglich in ein oder zwei Wochen abgewickelt werden kann.

    • Angesichts der aktuellen Gesamtstimmung rund um die Build-Konferenz und die zugehörigen Nachrichten fällt es mir schwer, das nur positiv zu sehen.

    • Wenn die Ankündigung stimmt, wurde das über lange Zeit vorbereitet und hat nichts mit den jüngsten Entlassungen zu tun.

  • Es wird darauf hingewiesen, dass lxcore.sys, der kernelseitige Treiber hinter WSL 1, nicht Teil dieser Open-Source-Freigabe ist. Außerdem überrascht es mich, dass WSL 1 überhaupt noch unterstützt wird; ich hätte erwartet, dass es nur noch im Wartungsmodus ist.

    • Der einzige Teil, der mich wirklich interessiert, ist lxcore.sys. Ich nutze immer noch ausschließlich WSL1 und habe sogar schon ungewöhnliche Hacks ausprobiert, bei denen ich ABI-Grenzen überschritten oder Windows in einen Linux-Userspace getunnelt habe. Ich hoffe, dass sich das als Open Source leichter handhaben ließe.

    • Tatsächlich habe ich gehört, dass sowohl WSL1 als auch WSL2 vollständig unterstützt werden. Es ist nicht nur ein Unterschied in der Versionsnummer.

  • Man muss sich Lizenz und Details genauer ansehen. Das könnte positiv sein, aber ich vermute auch, dass Microsoft nach den Entlassungen von Entwicklern nun kostenlose Hilfe will.

    • Die Lizenz ist MIT.
  • Ich bin kein Windows-Nutzer, halte WSL aber für hervorragend. Viele Windows-Nutzer kritisieren Linux vor allem deshalb, weil es „nicht wie Windows aussieht“, während Linux-Nutzer gerade mögen, dass Linux nicht wie Windows aussieht. Ich hoffe nur, dass Windows-Nutzer Linux nicht im Wunsch nach einem kostenlosen, werbefreien Windows in eine Art Windows verwandeln. Wenn WSL Windows-Nutzer auf Windows hält, begrüße ich das eher.

    • Ich bin ebenfalls kein Windows-Nutzer, aber ich mag WSL selbst nicht. Es wirkt auf mich wie Microsofts Strategie, keine Entwicklergeneration an Linux zu verlieren, indem man Linux einfach direkt ins eigene OS integriert. Schade finde ich, dass dadurch das Erlebnis verloren geht, den Kernel selbst neu zu kompilieren und solche Dinge direkt kennenzulernen.
  • Ich hoffe, dass die Bugs beim Arbeiten mit dem Windows-Dateisystem innerhalb von WSL jetzt endlich schnell behoben werden.

    • Ich glaube, Microsoft hofft das auch.