Kontroverse Diskussionen zwischen Windows- und Linux-User:innen wurden oft als „konservativ vs. progressiv“ wahrgenommen. Das bedeutet allerdings nicht, dass zwischen Windows und Linux komplette Featureparität herrscht – manche Sachen kann das komplett Open-Source-Betriebssystem auch im Jahr 2024 noch besser als Windows.
Traditionelle Methoden zur Bekämpfung dieses Problems sind einerseits die virtuelle Maschine und andererseits ein Dual-Boot-System. Insbesondere Zweiteres mag die maximale Performance der zugrunde liegenden Hardware exponieren, leidet in der Praxis aber darunter, dass das Austauschen von Daten alles andere als bequem ist.
Mit dem Windows Subsystem für Linux, oder kurz WSL, versuchte Microsoft diesem Problem seit längerer Zeit mit einem schlagkräftigen Werkzeug entgegenzutreten. Dieser Artikel nutzt eine brandaktuelle Windows-11-Workstation, um eine Analyse der Möglichkeiten und Grenzen und eine Besprechung der verschiedenen Spielarten von WSL zu liefern.
Microsoft bietet WSL zum Zeitpunkt der Drucklegung dieses Artikels in zwei Versionen an: Während der Fokus der Weiterentwicklung auf der zweiten Variante liegt, gilt nach wie vor, dass WSL 1 zumindest weiter unterstützt wird. Zu beachten ist bei der Nutzung von WSL1 allerdings, dass auf Windows 11 basierende Systeme in diesem Fall mitunter zu Bluescreens neigen – die unter [1] bereitstehende Diskussion enthält weitere Informationen zu diesem leidigen Thema.
Im Hintergrund müssen Entwickler:innen dabei mit zwei komplett unterschiedlichen Konzepten vorlieb nehmen. WSL 1 ist eine Art Wrapper, der die diversen APIs und Syscalls der Linux-Applikation auf Windows-Äquivalente umleitet. Aus der Logik folgt, dass die von WSL 1 verwendete Vorgehensweise mit vergleichsweise geringen Systemressourcen auskommt und außerdem die native Hardwarevirtualisierung des Windows-Hosts in keiner Weise tangiert. Das ist beispielsweise für all jene hilfreich, die ihre WSL-Umgebung parallel zu einem modernen Hypervisor wie VirtualBox auszuführen gedenken.
WSL 2 ist stattdessen – im Prinzip – eine virtuelle Maschine, die aber aufgrund der technischen Nähe zum Rest von Microsofts Betriebssystem wesentlich enger in die diversen Betriebssystemdienste integriert ist und Datenaustausch sowie Kommunikation wesentlich erleichtert. Andererseits gilt, dass der Ressourcenbedarf höher ist – außerdem steht WSL 2 in ganz frühen Versionen von Windows 10 nicht zur Verfügung, während es unter Windows 11 als Quasistandard anzusehen ist. Allgemein fasst Microsoft die Unterschiede zwischen den beiden Varianten in Abbildung 1 zusammen.
Abb. 1: WSL vs. WSL2
Ebenda findet sich allerdings auch eine Liste von Ausschlusskriterien, deren Auftreten in einer Einsatzsituation die Verwendung von WSL 1 immer prioritär erscheinen lässt. Erstens ist hier die Interaktion mit seriellen oder USB-Peripheriegeräten anzusprechen: Während mit USBIPD-WIN mittlerweile ein Workaround zur Verfügung steht, lehrt die jahrzehntelange Erfahrung des im Embedded-Bereich tätigen Autors, dass das Durchreichen von USB-Peripherie über VM-Grenzen im Allgemeinen eher schlecht als recht funktioniert und im Interesse eines bequemen Arbeitsalltags nach Möglichkeit zu vermeiden ist.
Neuerung Numero zwei betrifft den Zugriff auf das Dateisystem. Da WSL 1 die Befehle direkt umsetzt, ist der Zugriff auf die Windows-Files wesentlich einfacher – ist beispielsweise eine Cross-Compilation zu bewerkstelligen, führt das zu wesentlich höherer EA-Performance.
Zu guter Letzt ist nach Ansicht des Autors auch noch anzumerken, dass das Hosting von Netzwerkanwendungen in WSL nicht immer leicht ist. Eine WSL-1-Anwendung ist unter Localhost ansprechbar, während eine in WSL 2 lebende Anwendung logischerweise mit den diversen mit VM-Vernetzungen einhergehenden Lustigkeiten zu kämpfen hat.
Obwohl es insbesondere im Bereich der Embedded-Entwicklung einige Argumente pro WSL 1 gibt, wollen wir unsere Experimente in diesem Artikel ausschließlich mit der zweiten Version durchführen.
Auch im Bereich der Installation bietet Microsoft mehrere Spielarten an, die unter dem URL unter [2] im Detail durchdekliniert werden. Wer mit Windows 11 oder aber einer Windows-10-Version größer als Build 19041 arbeitet, kann auch auf eine bequeme Schnellinstallation setzen.
Hierzu müssen Sie im ersten Schritt eine PowerShell mit Administratorrechten öffnen, und danach nach folgendem Schema das Deployment der WSL-Arbeitsumgebung befehligen. Zu beachten ist, dass dieses Kommando eine nicht unerhebliche Menge an Daten aus dem Internet herunterlädt – eine volumenunbegrenzte und hochperformante Internetverbindung ist also auf jeden Fall anzuraten:
PS C:\Windows\system32> wsl --install
Wird installiert: Ubuntu
Ubuntu wurde installiert.
Zu beachten ist, dass der Installer unter Windows 11 von Haus aus WSL 2 zur Ausführung bringt – das zeigt sich unter anderem (Abb. 2) gezeigt, wenn ein an die Einrichtung eines neuen Shell-Accounts erinnernder Anmeldevorgang ersichtlich ist.
Abb. 2: Die Konfiguration von WSL 2 erfolgt Linux-ähnlich
Wer das Kommando wie der Autor hier eins zu eins eingibt, wird danach mit Ubuntu in Version 22.04.3 LTS belohnt. Spezifisch identifiziert sich der Kernel als (GNU/Linux 5.15.153.1-microsoft-standard-WSL2 x86_64). Das ist insofern nützlich, als der Autor auf dem zum Test verwendeten MSI GF65 auch ein natives Ubuntu 22.04 installiert hat.
Der offensichtlichste Unterschied zu einer...