Während meiner gesamten Zeit bei Microsoft habe ich Tools für Linux-Entwickler erstellt. Ich begann meine Arbeit im August 2016 nach meinem Abschluss an der University of Virginia, wo ich Informatik und Management studierte. Während meines Studiums habe ich hauptsächlich in C ++ programmiert. Mein Hauptbetriebssystem war Linux.
Es mag den Anschein haben, dass meine Erfahrung nicht ganz dem entspricht, was Microsoft möglicherweise benötigt, aber zu dieser Zeit erlebte das Unternehmen einen großen technologischen und kulturellen Wandel. Das Unternehmen bewegte sich in einen neuen Zustand, in dem alle Betriebssysteme, einschließlich Linux, für es wichtig waren.
Meine Arbeit bei Microsoft begann im Linux-Team. Ich habe dort ein SQL Server-Produkt erstellt. Mir wurde angeboten, diesem Team beizutreten, in der Hoffnung, dass ich meine Erfahrungen mit Linux einbringen würde. Ich war sehr beeindruckt von der Tatsache, dass ich, obwohl ich gerade ausgelassen hatte, aufgrund meiner Erfahrung für das Team von Wert sein könnte.
Vor ein paar Jahren war die Idee, eine Variante von SQL Server für Linux zu entwickeln, ein Aprilscherz gewesen, aber 2016 war sie völlig real. Ich bin dem Team kurz nach der Veröffentlichung der ersten Version des Produkts beigetreten. Ich begann das SQL Server-Toolkit zu verbessern, insbesondere für Administratoren. Dieses Toolkit war auf die Verwaltung von Linux-Servern und -Anwendungen ausgerichtet. Für die Verwendung von SQL Server unter Linux mussten die Befehlszeilentools so aussehen, wie es Linux-Benutzer gewohnt waren.
Außerdem hatte ich die Möglichkeit, die erste Version der SQL Server-GUI für Linux zu entwerfen. Ich habe mit einer Abzweigung von Visual Studio-Code begonnen, der heute Azure Data Studio heißt. Dies ist eine elektronenbasierte Anwendung, die unabhängig vom Betriebssystem mit jeder Art von SQL Server arbeiten kann.
Ich habe in meinem ersten Jahr bei Microsoft viel von SQL Server für Linux gelernt. In dieses Wissen kann ich auch die Entwicklung eines Ansatzes zur Verwaltung der Entwicklung und Unterstützung von Projekten einbeziehen, der auf einer Kombination aus Technologie und Geschäftsdenken basiert.
WSL Team, Chocolatey und Boxstarter bei Microsoft Build 2018Im August 2017 trat ich als Projektmanager dem WSL-Team (Windows Subsystem für Linux, Windows Subsystem für Linux) bei. Ich habe zum ersten Mal während der Ankündigung auf der Microsoft Build 2016 von WSL gehört. Zugehöriges Video von Kanal 9, „
Running Bash unter Ubuntu unter Windows! ", Unmittelbar nach der Veröffentlichung wurde viral. Es interessierte das Publikum eindeutig mehr als viele andere Ankündigungen auf der Konferenz. Die WSL-Technologie wurde kurz, buchstäblich innerhalb weniger Minuten, im Rahmen der Bewertung der Hauptpunkte der Konferenz erörtert. Das Publikum davon wurde jedoch direkt verrückt, ganz zu schweigen von den Journalisten. Es gab eine Zeit, in der das Channel9-Supportteam befürchtete, dass das hohe Interesse der Benutzer an diesem Videoclip tatsächlich auf einen DDoS-Angriff zurückzuführen ist! Microsoft-Sprecher startet Bash unter Ubuntu und läuft unter Windows ... Diese Aktion war sofort ein Erfolg.
Das erste Team, das die Benutzeranforderungen für WSL entdeckte, arbeitete an der Windows-Konsole. Während der Entwicklung haben sie immer wieder gehört, dass die Leute so etwas wie Linux's Bash wollen. Infolgedessen kam das Team zu folgendem Gedanken: "Warum etwas Ähnliches wie Bash tun, wenn Sie die Bash-Shell nur unter Windows ausführen können?"
Das soll nicht heißen, dass es einfach war. Die Erstellung der WSL erforderte eine Kombination aus fundierten Windows-Kenntnissen, über die das Entwicklungsteam im Kern des Systems verfügte, und einer bei Microsoft Research entwickelten Technologie namens picoprocess. Interessanterweise sind Picoprozesse außerdem genau die Technologie, mit der SQL Server unter Linux funktioniert.
Der Picoprozess sollte eine unveränderte Linux-Implementierung im Benutzermodus bereitstellen. Das Windows-Kernel-Team hat Shims entwickelt, mit denen Linux-Systemaufrufe mit Windows verbunden werden können. Mit anderen Worten, WSL ermöglichte es, für Linux kompilierten Code auf dem Windows NT-Kernel auszuführen. Es war nicht erforderlich, den Code neu zu kompilieren oder virtuelle Maschinen zu verwenden.
Wir haben damals nicht nur unsere eigene Linux-Distribution erstellt. Tatsache ist, dass es viele solcher Verteilungen gab. Die erste in WSL verfügbare Linux-Version war Ubuntu. Wir haben Canonical-Spezialisten kontaktiert, um herauszufinden, ob sie uns bei der Arbeit an der WSL helfen möchten. Sie waren begeistert von unserer Idee. Dies führte dazu, dass Ubuntu im Microsoft Store erschien. Übrigens klingt der vorige Satz an sich ziemlich ungewöhnlich. Jetzt können Sie im Microsoft Store 6 Distributionen zählen. Ich frage mich, welche anderen auf bestimmten Betriebssystemen verfügbaren Anwendungsspeicher andere Betriebssysteme haben.
Microsoft Store verfügt jetzt über 6 Linux-Distributionen, die in WSL verwendet werden könnenDer Code, den wir damals geschrieben haben, waren Linux-kompatible Kernel-Systemaufrufe, die als Schnittstelle zwischen den Linux-Prozessen und dem Windows-Kernel dienten. Linux hat ungefähr 340 Systemaufrufe. Die Frage war, zu entscheiden, welche Systemaufrufe zuerst implementiert werden sollen. Wie bei jedem Betriebssystem werden unter Linux neue Systemaufrufe hinzugefügt, wenn neue Versionen des Betriebssystems veröffentlicht werden. Alte Aufrufe werden jedoch nie gelöscht, was die Abwärtskompatibilität gewährleistet. Zuerst wurde die Verarbeitung eines bestimmten Satzes von Systemaufrufen implementiert, und alles andere wurde in Ereignisse wie "noch nicht implementiert" eingeschlossen. Auf diese Weise konnte das WSL-Team genau analysieren, welche Systemaufrufe Linux-Benutzer benötigen.
Die Antwort auf die Frage, welche Systemaufrufe überhaupt implementiert werden sollten, bedeutete die Notwendigkeit, eine Kommunikation mit den Personen herzustellen, die WSL verwenden würden. Die Botschaft zu dieser Technologie auf der Build-Konferenz zielte darauf ab, die Benutzer dazu zu bringen, WSL zu verwenden und Feedback zu geben. Um WSL zu erwerben, mussten Sie Mitglied des Windows Insider-Programms sein. Jeder kann sich mit diesem Programm verbinden. Sie könnten denken, dass die Programmteilnehmer nur diejenigen waren, die sich für Windows interessierten, aber dann gab es unter mehr als zehn Millionen Abonnenten Menschen mit einer Vielzahl von Interessen. Sie interessierten sich nicht nur für Windows, sondern beispielsweise auch für Spiele und neue Funktionen von Bluetooth und WSL.
Eine der Benutzergruppen, die daran interessiert waren, die Bash-Shell unter Windows auszuführen, war der Webentwickler, der an der Erstellung von Webanwendungen beteiligt war, die auf Linux-Servern ausgeführt werden. Der gesamte Prozess des Zusammenstellens ihrer Anwendungen bestand häufig aus einer Folge von Bash-Befehlen. Wenn sich jemand entscheidet, bei der Entwicklung von Webanwendungen um Hilfe zu bitten, z. B. bei Stack Overflow, sind die meisten Codebeispiele, die er finden kann, für die Ausführung unter Linux ausgelegt. Dies ist nicht besonders gut für diejenigen, die Windows als Computer für die Webentwicklung verwenden. Für solche Entwickler ist es oft am einfachsten, einfach auf die Mac-Plattform zu wechseln. Unter macOS können ähnliche Codebeispiele problemlos ausgeführt werden.
In den ersten Wochen der Präsenz von WSL unter Windows konnte ein Unternehmensbenutzer XEyes ausführen. Dieses Programm wurde auf einem X11-Fenstersystem ausgeführt, das in WSL ausgeführt wird. XEyes ist ein einfaches Programm. Sie zeigt Comic-Augen an, die dem Mauszeiger folgen. Aber diese Demonstration hat soziale Netzwerke in die Luft gesprengt.
XEyes läuft unter Windows über WSLWir haben viel darüber diskutiert, wie wir genau Bewertungen von Benutzern über WSL sammeln möchten. Das traditionelle Tool zum Sammeln von Feedback war UserVoice. Wir hatten eine UserVoice-Site für die WSL, auf der Hunderte von Ideen und Tausende von Stimmen zu verschiedenen Themen gesammelt wurden. Die eigentliche Frage stellte sich uns, ob wir GitHub verwenden sollten. Da Webentwickler eine der ersten Benutzergruppen waren, die sich für WSL interessierten, war die Frage nach GitHub sehr wichtig. Aber WSL war kein Open Source Projekt. Ein solches Projekt auf GitHub zu platzieren, sieht seltsam aus. Wir haben uns entschlossen, die Anforderungen der Entwickler zu erfüllen, und eine Seite auf GitHub erstellt, auf der Probleme gemeldet, Feedback gegeben und Diskussionen geführt werden können. Seitdem haben wir Tausende von Nachrichten zu vielen Problemen im Zusammenhang mit der Verwendung von Linux unter Windows erhalten.
Tausende von Menschen haben Fehlermeldungen im WSL
GitHub-Repository hinterlassen. Jede dieser Nachrichten wurde vom WSL-Team geprüft und diskutiert, und zu jeder von ihnen wurden Kommentare abgegeben. Danach wurde über weitere Maßnahmen entschieden. Wenn eine bestimmte Gelegenheit erkannt oder ein Fehler behoben werden musste, musste neuer Code geschrieben werden. Dieser Code wurde erstellt und dem WSL-Projekt hinzugefügt. Danach fiel er in alle Windows-Assemblys, die unter dem Windows Insider-Programm verteilt wurden. Der gesamte Zyklus, vom Empfang einer Fehlermeldung bis zur Korrektur, dauerte nicht lange - etwa ein paar Wochen.
Dank der operativen Reaktion des WSL-Teams auf Benutzeranfragen konnte daher festgestellt werden, dass die Community an der Erstellung der WSL beteiligt war. Die Benutzer meldeten Probleme oder ihre Wünsche über UserVoice oder GitHub. Das Team überprüfte dies alles und nahm Änderungen am Projekt vor, die dann in den Builds des Windows Insider-Projekts angezeigt wurden.
Als ich als Projektmanager zum WSL-Team kam, konzentrierte ich mich darauf, die WSL aus der Beta herauszuholen. Benutzerbeschwerden betrafen hauptsächlich Kompatibilität und Leistung. Aber wenn Benutzer sich über solche Dinge Sorgen machen, bedeutet dies meiner Meinung nach, dass sie unsere Entwicklung ernsthaft nutzen. Für die Leistung sorgen nur diejenigen, die mit Hilfe eines bestimmten Softwaresystems einige große Probleme lösen. Obwohl wir noch viel zu tun hatten, haben wir es nicht nur so gemacht, sondern damit die Leute mehr Probleme mit WSL lösen können und damit sie ihre Probleme schneller lösen können.
Als die Funktionen von WSL erweitert wurden, haben wir uns bemüht, WSL den Entwicklern näher zu bringen, und nicht nur den Benutzern, die traditionell mit dem Microsoft-Ökosystem arbeiten. Es war sehr interessant, an Veranstaltungen wie PyCon und OSCON teilzunehmen. Die dort anwesenden Entwickler waren überrascht, dass auch Vertreter von Microsoft an diesen Veranstaltungen teilnahmen. Entwickler waren misstrauisch gegenüber der Idee, Linux in einer Windows-Umgebung auszuführen. Bei diesen Veranstaltungen zeigte ich SQL Server, WSL und Visual Studio Code.
Demonstration der WSL bei verschiedenen VeranstaltungenIch antwortete auf ihre skeptischen Kommentare mit einem Vorschlag, zu versuchen, was ich ihnen zeigte. Wenn Zweifler anfingen, ihre eigenen Befehle, kleinen Skripte und Schnipsel auszuführen, stieß ich immer auf eine heftige Reaktion auf das, was geschah: „Moment mal, und das ist wirklich Linux. Wie hast du das gemacht? Warum wusste ich nichts davon? " Oft kamen sie zu dem Schluss, dass wir etwas geschaffen haben, das ihren Bedürfnissen entspricht, etwas, das sehr interessant aussieht.
Wir haben Beschwerden von Benutzern hinsichtlich der WSL-Kompatibilität und -Leistung berücksichtigt und eine neue Systemarchitektur veröffentlicht -
WSL 2 . Es bietet vollständige Kompatibilität durch die Integration des Linux-Kernels in Windows und eine 20-fache Geschwindigkeitssteigerung. Ich habe eine interessante Erfahrung gemacht, als ich die Grundlage für WSL 2 geschaffen und die Ankündigung dieser Technologie auf der Build-Konferenz im Mai 2019 verfolgt habe. Das WSL-Projekt ist bereits heute aus der Beta-Version herausgewachsen und hat Version 2 erreicht.
Außerdem habe ich bei Microsoft mit anderen Teams zusammengearbeitet, um sicherzustellen, dass WSL mit ihren Produkten verwendet werden kann. Ein wichtiges Beispiel für diese Verwendung von WSL ist Visual Studio Code. Dies ist die beliebteste Codeumgebung, die bei der Entwicklung von JavaScript- und Node.js-Projekten verwendet wird. Ich interessierte mich für Visual Studio Code, als mir klar wurde, dass Entwickler, die diesen Editor verwenden, erhebliche Vorteile aus der WSL ziehen können. Zunächst ging es nicht darum, große Mengen an Code zu schreiben. Das Hauptziel bestand darin, das Debuggen von Node.js-Programmen, die in der WSL-Umgebung ausgeführt werden, zu vereinfachen. Dies würde Entwicklern die Möglichkeit geben, Programme, die für die Linux-Version von Node.js entwickelt wurden, auf einem Windows-Computer unter Verwendung von WSL zu entwickeln. Das Debuggen solcher Programme würde genauso aussehen wie das Debuggen unter Linux.
Nachdem sich herausstellte, dass dies für JavaScript und Node.js möglich war, erhielten wir viele Anfragen nach ähnlichen Aufgaben für andere Sprachen, beispielsweise für C ++ und Python. Ich war fasziniert von diesem Beispiel für die Integration von WSL und VS Code. Ich stellte fest, dass mich alle sehr daran interessiert waren. Dies führte mich zu meiner neuen Rolle beim Erstellen von Tools für Linux-Entwickler. Jetzt konzentriere ich mich auf Tools für C ++ - Entwickler in VS Code. In dieser Arbeit konzentriere ich mich natürlich auf Linux. Es war schön, auf dem PyCon-Event in diesem Jahr eine Demonstration der Remoteentwicklung von Visual Studio Code zu sehen, als die entsprechende WSL-Erweiterung veröffentlicht wurde. Gleichzeitig wurde eine Erweiterung für C ++ eingeführt, die mein Team entwickelte.
Trotz der Tatsache, dass ich nicht so viel Zeit bei Microsoft verbracht habe, bin ich froh, dass ich an der Erstellung vieler Tools für Linux-Entwickler teilnehmen konnte. Diese Datenbank und Unterstützung für Linux unter Windows sowie Tools zum Schreiben und Debuggen von Code. Ich plane, weiterhin an Linux zu arbeiten und Tools zu erstellen, die Entwickler auf der ganzen Welt gerne verwenden werden.
Liebe Leser! Verwenden Sie WSL?
