Ubuntu on Windows im Test: Eine neue Hassliebe auf der Kommandozeile
Es wäre wahrscheinlich ein sehr schöner Aprilscherz gewesen zu behaupten, dass der Ubuntu-Userspace künftig ohne Anpassungen auf Windows 10 laufen wird. Doch so abwegig die Idee auch erscheinen mag, Microsoft meint es mit dem auf der Entwicklerkonferenz Build vorgestellten Projekt wohl sehr ernst. Offenbar ist dem Unternehmen inzwischen jedes Mittel recht, um Entwickler auf seiner Plattform zu halten oder von OS X und Linux zurückzugewinnen. Die derzeit verfügbare Vorschau zeigt, dass das Potenzial dafür vorhanden ist. Doch es gibt auch einige deutliche Einschränkungen.
Die Installation ist keine Hürde
Die Mühe, die die Microsoft-Entwickler in das Windows-Subsystem für Linux (WSL), so der offizielle Projektname, gesteckt haben, wird schon bei der Einrichtung erkennbar. Die Installation ist geradezu verblüffend einfach. So reicht es aus, im aktuellen Insider Build 14316 von Windows 10 die Entwickleroptionen zu aktivieren, die Funktion über die Systemsteuerung auszuwählen und dann im Startmenü nach Bash zu suchen. Wird der gefundene Eintrag ausgewählt, öffnet sich ein Terminalfenster, in dem nur eine kurze Lizenzabfrage bestätigt werden muss. Die verlinkten Lizenzbestimmungen sind die der Linux-Distribution Ubuntu. Danach wird das System automatisch heruntergeladen.
Bei dem Download handelt es sich um ein Root-Dateisystem von Ubuntu 14.04. Es enthält viele bekannte Basiswerkzeuge und Bibliotheken. Die Binärpakete sind nicht speziell an die Verwendung mit Windows angepasst, sondern sind exakt jene, die auch in der Linux-Distribution enthalten sind und über die Ubuntu-Server verteilt werden. Für diesen reibungslosen Ablauf hat Microsoft eng mit dem Ubuntu-Sponsor Canonical zusammengearbeitet.
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
Nach dem Abschluss der Installation öffnet sich die Gnu Bash in einem Fenster und die Nutzer sind mit dem Root-Account auf dem Ubuntu angemeldet. Das nutzt allerdings keinen Linux-Kernel als Unterbau, sondern läuft eben nativ auf Windows 10. Dafür übersetzt das WSL die Linux-Systemaufrufe (Syscalls) der einzelnen Anwendungen so, dass diese letztlich vom NT-Kernel ausgeführt werden können. Das Arbeitsverzeichnis ist dabei zuerst /mnt/c/WINDOWS/system32. Bei einem erneuten Start der Umgebung befinden sich Nutzer dann im Ordner /root. Zu finden ist die Anwendung einfach über das Startmenü unter dem Namen Bash on Ubuntu on Windows.
Vertraute Umgebung
Diese Terminalsitzung ist tatsächlich so gut umgesetzt, dass der Windows-Unterbau zunächst ganz schnell vergessen werden kann. Das System meldet sich beim Aufruf von lsb_release -a als Ubuntu 14.04, uname -a gaukelt sogar einen Linux-Kernel 3.4 vor. Darüber hinaus ist das Ubuntu in der üblichen Verzeichnisstruktur aufgebaut, selbst die virtuellen Verzeichnisse /proc und /sys sind vorhanden und in /etc finden sich die von Ubuntu bekannten Konfigurationsdateien.
Viele der GNU-Basiswerkzeuge lassen sich außerdem wie gewohnt direkt einsetzen: Ordner und Dateien erstellen oder wieder löschen, mit sed oder awk verändern und mit grep darin suchen. Which findet die Pfade für Anwendungen und sort -R liefert das gewünschte zufällige Ergebnis. File und stat listen ausführliche Informationen zu einzelnen Dateien.
Mit Curl und Wget lassen sich Dateien einfach herunterladen, und zur Paketverwaltung kann wie angekündigt Apt verwendet werden. Doch schon hierbei zeigen sich erste kleine Probleme ebenso wie fundamentale Schwierigkeiten, die das WSL noch hat. Der positive erste Eindruck wird dementsprechend schnell und nachhaltig getrübt.
Ubuntu als kaputter Fremdkörper
Zwar funktioniert die Installation mit Apt, doch die interaktive Eingabezeile zum Bestätigen der Auswahl zeigt bereits, dass es mit dem Windows-Subsystem für Linux (WSL) massive Darstellungs- und Eingabeprobleme auf dem Terminal gibt. So wird die Eingabe der Backspace-Taste in diesem interaktiven Modus nicht als Löschaufforderung des letzten Zeichens interpretiert, sondern als "normale" Eingabe, weshalb hier beliebige Unicode-Zeichen erscheinen.
Überraschenderweise gar nicht möglich sind die Verwendung von Sonderzeichen sowie Drittbelegungen von Tasten, welche als Tastenkombination per AltGr erzeugt werden. Das Ubuntu nimmt hier keine Eingaben an. In den öffentlichen Bugreports berichten viele Nutzer mit abweichenden Tastaturlayouts von ähnlichen Problemen. Ein bisschen Abhilfe, um wenigstens die Pipe oder das @-Zeichen nutzen zu können, schafft nur der systemweite Wechsel vom deutschen auf das US-Tastaturlayout unter Windows. Das Verändern des Layouts in der Ubuntu-Shell bleibt erfolglos.
Nervig ist auch, dass die Nutzung von Pagern wie etwa Less zu oft dazu führt, dass der anzuzeigende Text in dem Fenster so verrutscht oder überlagert wird, dass die Ausgabe nicht mehr sinnvoll gelesen werden kann. Das Bearbeiten von Textdateien mit dem einfachen Editor Nano ist aus dem gleichen Grund quasi nicht möglich. Dass diese interaktiven Shell-Modi eine Herausforderung für das WSL darstellen, ist nur schwer verständlich. Immerhin ist dies oft Grundvoraussetzung für die Arbeit mit einem Terminal. Doch Microsoft muss seine Interna zur Unterstützung dieser Funktionen wohl erst aufwendig umbauen.
Viele kaputte Grundlagen
Immer wieder verwundern derartige Fehler insbesondere bei kleineren Anwendungen, die völlig unerwartet nur teils oder auch gar nicht funktionieren. So erscheint etwa Midnight Commander zwar in dem nostalgischen Ncurses-Blau, eine Navigation per Pfeiltasten in der Ansicht ist aber nicht möglich und die Software damit vollkommen unbrauchbar.
Eine grundlegende Systemadministration ist ebenfalls kaum möglich. So fehlt zum Beispiel ein Logging-Dienst, und die Verwaltung von Systemdiensten mit den Upstart-Werkzeugen scheitert. Die meisten dieser Anwendungen setzen die Nutzung von Dbus zur Kommunikation voraus, doch der dazugehörige Daemon lässt sich weder automatisch noch manuell starten. Erstaunlicherweise gelingt es aber einigen Anwendungen wie Libreoffice den Dbus-Daemon selbstständig zu starten.
Das Packen und Entpacken von Archiven mit Tar geht außerdem nur so lange gut, bis eines der Archive einen Symlink enthält. Ist dies der Fall, verweigert Tar seinen Dienst. Auch Netzwerkoperationen, die über einfache Grundlagen hinausgehen, stellen das WSL noch vor unlösbare Probleme. So melden etwa Dig und Nslookup Fehler in der Socket-Implementierung. Für Ping fehlt die Unterstützung für ICMP und die eigene IP-Adresse lässt sich über ip a nicht in Erfahrung bringen. Zu allem Überfluss fehlt auch noch /dev/net, was weitere Netzwerkprobleme nach sich zieht. Ein Test von Wine zum Ausführen der nativen Windows-Anwendungen aus dem Ubuntu heraus scheitert an der Speicherverwaltung des Systems.
Seltsame und fehlende Gerätedateien
Die virtuellen Dateisysteme, die unter Linux üblich sind und von Anwendungen deshalb als gegeben vorausgesetzt werden wie eben /dev/net oder andere, bereiten dem WSL wohl die meisten Probleme. So fehlen im Vergleich zu Linux bei dem Ubuntu auf Windows große Teile dieser virtuellen Dateien und Ordner und in /dev /proc oder auch /sys. Die darüber erhältlichen Details zur Hardware und dem System sind eher spärlich und der Zugriff auf Blockgeräte ist zum Beispiel gar nicht möglich. Wenig überraschend lässt sich auch Docker nicht verwenden, da die Cgroup-Schnittstellen und dazugehörige virtuelle Dateien nicht vorhanden sind.
Besonders interessant, aber auch besonders ärgerlich ist das Verhalten der Gerätedatei /dev/null. Zwar verhält sich die Datei beim Hineinschreiben großer Datenmengen wie erwartet: Die Daten werden verworfen und die Datei wird nicht größer. Unter Linux ist das Nulldevice zudem aber ein sogenanntes Character Device, es wird bei der Eingabe von ls -l auch mit einem führenden c als solches ausgewiesen.
In der Umsetzung des WSL ist Letzteres aber nicht der Fall. Das Nulldevice ist zumindest der Ausgabe von ls -l zufolge eine einfache Datei, was bei vielen Anwendungen zu Fehlfunktionen führt. Als prominentestes Beispiel ist hier der OpenSSH-Server zu nennen, der deswegen nicht genutzt werden kann. Microsoft hat bereits zur Ankündigung des WSL und auf der Build-Konferenz mehrfach darauf hingewiesen, dass solche Funktionseinschränkungen zu erwarten seien, da die Entwicklungen einen sehr engen Fokus hatten.
Für Entwickler und Experimentierfreudige
Das Projekt, mit dem Windows-Subsystem für Linux den Ubuntu-Userspace auf Windows zu bringen, zielt eindeutig auf Entwickler, die ihre Projekte auf Linux-Servern einsetzen oder anderweitig mit diesen arbeiten. Sie waren bisher darauf angewiesen, Mac OS X oder Linux zu nutzen, da Windows den Einsatz einiger Open-Source-Anwendungen teilweise erschwert oder dies gar nicht möglich ist.
So verfügt Windows noch nicht über einen eigenen SSH-Client für das Terminal, Git für Windows ist auf eine Emulationsschicht zur Verwendung angewiesen und typische Werkzeuge zur Webentwicklung wie Ruby oder auch Node sind anfangs gar nicht für den Einsatz auf Windows vorgesehen gewesen, was immer noch einige Probleme macht. Das Kompilieren von Linux-Anwendungen unter Windows ermöglicht Visual Studio erst seit kurzem durch eine Verbindung zu einem Linux-Rechner, auf dem dann der Code übersetzt wird.
Da nun aber Ubuntu mit all seinen Anwendungen quasi nativ auf Windows läuft, fallen eventuelle Inkompatibilitäten nicht mehr ins Gewicht und auf umständliche Emulationen oder Portierung kann in einigen Fällen verzichtet werden. Falls nötig kann einfach schnell auf das Ubuntu gewechselt werden, um die gewünschten Arbeiten auszuführen.
Entwickleralltag auf der Konsole
So lässt sich der SSH-Client in dem Ubuntu ohne Hindernisse verwenden, Gleiches gilt für Git. Bei der Nutzung fällt lediglich auf, dass die Übertragung insbesondere größere Dateien sowohl mit Git über HTTP als auch per Scp im WSL teils spürbar langsamer ist als in einer nativen Linux-Distribution. Ebenso können sowohl die Gnu Compiler Collection (GCC) als auch die LLVM-Compiler wie etwa Clang im WSL genutzt werden.
Erste Benchmarks des US-Magazins Phoronix deuten auf eine gute Leistung der so genutzten Compiler hin. Allerdings zeigen diese Tests wohl auch, dass hier noch Probleme bei häufigen Ein- und Ausgabeoperationen (I/O) auftreten. Außerdem listet der Befehl free nur 1 GByte Arbeitsspeicher für das WSL auf, was beim Kompilieren großer Projekte klare Einschränkungen mit sich bringt. Das OpenJDK zur Verwendung von Java aus den Ubuntu-Repositories lässt sich nicht fehlerfrei installieren.
Webserver schnell aufgesetzt
Für Webentwickler kann das Testen der eigenen Projekte je nach Anwendungsfall jedoch schwierig werden. So lassen sich etwa die Webserver Apache oder Lighttp überhaupt nicht starten. An Fehlern im Netzwerk-Stack liegt das aber nicht, denn der in Python integrierte Webserver lässt sich wie gewohnt nutzen. Ebenso einsetzbar ist der Server Webrick von Ruby; so lassen sich etwa schnell mit Jekyll Webseiten aufsetzen. Die so verbreiteten Seiten lassen sich im Browser über Localhost aufrufen, wobei einige Ports nicht genutzt werden können, weil sie bereits von Windows reserviert sind.
Redis startet mit der Angabe eines Ports zum Zugriff auf die In-Memory-Datenbank, MySQL kann dagegen nicht sinnvoll eingesetzt werden. Nodejs übersteht einfache Tests auf der Kommandozeile, die Nutzung großer Projekte für den Javascript-Server ist oft aber nur schwer möglich, wobei schon die Installation verschiedener Node-Module oft fehlschlägt. Letztlich muss wohl aber noch häufig ausprobiert werden, welche Bestandteile eines eigenen Projekts im WSL genutzt werden können und welche nicht.
Grafische Anwendungen sind verwendbar
Obwohl Microsoft von vornherein ausschließt, dass mit dem WSL je die Verwendung grafischer Anwendungen offiziell unterstützt wird, ist dies dennoch schon jetzt möglich. Da die Webserver eine problemlose Kommunikation über Localhost ermöglichen, überrascht es wenig, dass dies auch für das X11-Protokoll genutzt werden kann.
Um X11-Anwendungen zu starten, ist zunächst ein X-Server für Windows notwendig wie etwa Xming oder der X-Server aus Cygwin. Läuft dieser, reicht es aus, in dem WSL die Display-Umgebungsvariable zu setzen, also etwa export DISPLAY=:0 aufzurufen, und schon lassen sich grafische Anwendungen starten. Auch komplexe Software wie Libreoffice steht so zum Testen bereit. Diese Experimente sind aber auch sehr fehleranfällig und es treten viele spontane Abstürze auf.
Technische Details, Ausblick und Fazit
Wie bereits zu Anfang erwähnt, dient das Windows-Subsystem für Linux (WSL) vor allem dazu, Linux-Syscalls der Binärdateien von Ubuntu so umzuwandeln, dass diese von Windows verarbeitet werden können, was über spezielle Treiber geschieht. Seit Ende Januar finden sich hierzu in den Insider-Builds von Windows 10 die Dateien lxcore.sys sowie lxss.sys. Möglicherweise ist das gesamte WSL von dem Project Astoria abgeleitet, das Android-Apps auf Windows bringen sollte.
Einen guten Überblick über den technischen Aufbau liefert zudem ein Blick in den Process Explorer, der wesentlich mehr Informationen zeigt als etwa der Taskmanager. Dort finden sich eine bash.exe, das eigentliche Startprogramm für das WSL als eine Art Wrapper sowie der Console Window Host (conhost.exe), der zum Darstellen der Shell benötigt wird. Außerdem gibt es noch einen Shell Infrastructure Host (sihost.exe). Dem Letztgenannten ordnen sich dann im Prozessbaum die Ubuntu-Prozesse unter: also init, die Bash selbst sowie die vom Nutzer gestarteten Anwendungen. Der Befehl ps in dem Ubuntu stellt konsequenterweise auch nur die Prozesse der Ubuntu-Sitzung dar.
Die Dateien zu dem Ubuntu sind im jeweiligen Nutzerverzeichnis in Windows unter Appdata\Local\Lxss gespeichert. Darin befinden sich das Root-Dateisystem (rootfs) des Ubuntu sowie die Verzeichnisse home, root und cache. Die Windows-Festplatte C: ist zudem in dem Ubuntu als /mnt/c eingebunden, so dass ein Dateiaustausch in beide Richtungen möglich ist.
Offizielle Ausbaupläne
Der Microsoft-Angestellte Scott Hanselmann hat in seinem Blog bereits erklärt(öffnet im neuen Fenster) , wie Nutzer die Bash durch eine andere Shell ersetzen können. Selbst der Austausch des gesamten Ubuntu-Rootfs gegen das einer anderen Distribution scheint machbar. Beides wird Microsoft wohl langfristig nicht offiziell unterstützen. Aber auch sonst bleibt das Unternehmen noch sehr vage in seinen Aussagen dazu, was das WSL künftig alles leisten können soll.
Geplant ist derzeit schon die Unterstützung für Terminalmultiplexer Screen und Tmux. Auch das Programm Top soll zuverlässig arbeiten - bisher zeigt es keinerlei Ausgaben. Anwender sollen künftig auch nicht mehr standardmäßig als Root angemeldet sein, sondern über einen einfachen Nutzeraccount. Damit einhergehend soll auch die Rechteverwaltung angepasst werden.
Fazit
Die Idee, den Ubuntu-Userspace auf Windows laufenzulassen und dabei auf eine Virtualisierung zu verzichten, ist ebenso genial wie fast schon wahnsinnig. Doch verrückt ist daran nicht unbedingt die technische Machbarkeit, deren Zustand die aktuelle Beta des Windows-Subsystem für Linux (WSL) aufzeigt, sondern die enorme Größe der Aufgabe. Denn schon vermeintlich kleine und einfache Anwendungen wie Ping oder Nano funktionieren derzeit noch nicht.
Da ist es wenig verwunderlich, dass die Summe der vielen kleinen Probleme zu einer recht großen Menge an Software führt, die noch nicht genutzt werden kann. Zwar wäre es interessant gewesen, einen SSH-Server zu testen oder gar mit Apache, MySQL und PHP übliche Webanwendungen wie etwa Wordpress oder auch Owncloud aufzusetzen. Doch dass das WSL noch nicht so weit gereift ist, ist wenig überraschend.
Unerwartet gut an dem WSL ist aber, dass viele Basiswerkzeuge vom Editor über die Quellcodeverwaltung bis hin zum Compiler fehlerfrei genutzt werden können. Auch verschiedene Programmiersprachen, die zur Webentwicklung genutzt werden, wie Ruby, und deren integrierte Webserver lassen sich ohne Anpassungen aus den Ubuntu-Repositories beziehen und dann auf einem Windows-System ausführen.
Unter der Voraussetzung, dass das eigene Projekt mit dem WSL läuft, sollte das System deshalb in einigen Nutzungsszenarien große Vorteile bieten. Das gilt vor allem in Umgebungen, in denen sowohl Linux- als auch Windows-Anwendungen entwickelt werden sowie Unternehmen, die ihren Angestellten keine anderen Betriebssysteme als Windows zur Nutzung erlauben oder zur Verfügung stellen.
Der Betastatus des WSL ist derzeit aber noch sehr deutlich zu spüren. Insbesondere Fehler, deren Ursache nicht klar ersichtlich ist, nerven noch und können bei Ungeduldigen zum programmierten Wutausbruch führen. Die Entwickler von Microsoft gehen seit der ersten Veröffentlichung aber aktiv auf die Interessen der Nutzer ein. So werden Fehlerberichte bei Github gesammelt(öffnet im neuen Fenster) und über bereits behobene Probleme wird informiert. Zudem können über das Portal Uservoice(öffnet im neuen Fenster) Wünsche zu WSL geäußert werden.
Das Windows-Subsystem für Linux mit einem darauf laufenden Ubuntu-Userspace wird mit dem für diesen Sommer geplanten Update von Windows 10 für alle Nutzer veröffentlicht. Wie viel die Entwickler bis dahin an dem Projekt verbessern, bleibt abzuwarten. Sollte es Microsoft aber gelingen, Programme wie Apache, den OpenSSH-Server oder gar Docker starten zu können, ist das WSL ein riesiger Coup, mit dem das Unternehmen es wohl tatsächlich schaffen könnte, dass wieder mehr Entwickler Windows nutzen.