Tout le temps que je travaille chez Microsoft, j'ai créé des outils pour les développeurs Linux. J'ai commencé à travailler en août 2016, après avoir obtenu mon diplôme à l'Université de Virginie, où j'ai étudié l'informatique et la gestion. Pendant mes études, j'ai programmé principalement en C ++. Mon système d'exploitation principal était Linux.
Il peut sembler que mon expérience ne correspond pas tout à fait à ce dont Microsoft pourrait avoir besoin, mais à cette époque, l'entreprise subissait un changement majeur, à la fois en termes de technologie et de culture. L'entreprise entrait dans un nouvel état dans lequel tous les systèmes d'exploitation, y compris Linux, étaient importants pour elle.
Mon travail chez Microsoft a commencé au sein de l'équipe Linux. Je faisais le produit SQL Server là-bas. On m'a proposé de rejoindre cette équipe, dans l'espoir d'y apporter mon expérience sous Linux. J'ai été très impressionné par le fait que, même si je venais de m'absenter, je pouvais être utile à l'équipe en raison de mon expérience.
Il y a quelques années, l'idée de développer une variante de SQL Server pour Linux aurait été une blague d'avril, mais en 2016, elle était tout à fait réelle. J'ai rejoint l'équipe peu de temps après la sortie de la première version du produit. J'ai commencé à améliorer la boîte à outils SQL Server, en particulier pour les administrateurs. Cette boîte à outils visait à gérer les serveurs et les applications Linux. L'utilisation de SQL Server sur Linux nécessitait d'apporter les outils de ligne de commande à l'apparence habituelle des utilisateurs Linux.
De plus, j'ai eu l'occasion de concevoir la première version de l'interface graphique SQL Server pour Linux. J'ai commencé avec un fork de Visual Studio Code, qui s'appelle aujourd'hui Azure Data Studio. Il s'agit d'une application basée sur Electron qui, quel que soit le système d'exploitation, peut fonctionner avec tout type de serveur SQL.
J'ai beaucoup appris de SQL Server pour Linux lors de ma première année chez Microsoft. Dans cette connaissance, je peux également inclure le développement d'une approche de gestion du développement et du support de projets basée sur une combinaison de technologie et de pensée commerciale.
Équipe WSL, Chocolatey et Boxstarter à Microsoft Build 2018En août 2017, j'ai rejoint l'équipe WSL (Windows Subsystem for Linux, Windows Subsystem for Linux) en tant que chef de projet. J'ai entendu parler de WSL pour la première fois lors de l'annonce de Microsoft Build 2016. Vidéo connexe de Channel 9, «
Running Bash on Ubuntu on Windows! ", Immédiatement après la libération est devenue virale. Cela a clairement intéressé le public plus que de nombreuses autres annonces faites lors de la conférence. La technologie WSL a été brièvement, littéralement en quelques minutes, discutée dans le cadre de la notation des principaux points de la conférence. Cependant, le public de cela est devenu fou, sans parler des journalistes. Il fut un temps où l'équipe de support de Channel9 craignait que le haut niveau d'intérêt des utilisateurs pour ce clip vidéo soit dû à une attaque DDoS! Porte-parole de Microsoft lançant Bash sur Ubuntu, fonctionnant sous Windows ... Cette action a été un succès instantané.
La première équipe à découvrir les besoins des utilisateurs pour WSL a été celle qui a travaillé sur la console Windows. Pendant le développement, ils ont entendu à maintes reprises que les gens voulaient quelque chose comme Linux's Bash. En conséquence, l'équipe est arrivée à la pensée suivante: "Pourquoi faire quelque chose qui ressemble à Bash, si vous pouvez simplement faire fonctionner le shell Bash directement sur Windows?"
Cela ne veut pas dire que c'était facile à faire. La création de WSL a nécessité une combinaison de connaissances approfondies de Windows, que l'équipe au cœur du système possédait, et d'une technologie développée par Microsoft Research appelée picoprocess. Il est intéressant de noter que les picoprocédés sont en outre la technologie même qui fait fonctionner SQL Server sous Linux.
Le picoprocess était censé fournir une implémentation Linux non modifiée en mode utilisateur. L'équipe du noyau Windows a développé des shims conçus pour connecter les appels système Linux à Windows. En d'autres termes, WSL a permis d'exécuter du code compilé pour Linux sur le noyau Windows NT. Il n'était pas nécessaire de recompiler le code ou d'utiliser des machines virtuelles.
Nous n'avons alors pas créé uniquement notre propre distribution Linux. Le fait est qu'il y avait beaucoup de telles distributions. Ubuntu était la première version Linux disponible en WSL. Nous avons contacté des spécialistes canoniques pour savoir s'ils souhaitaient nous aider à travailler sur le WSL. Ils étaient enthousiasmés par notre idée. Cela a conduit au fait qu'Ubuntu est apparu dans le Microsoft Store. Soit dit en passant, la phrase précédente, en soi, semble assez inhabituelle. Maintenant, dans le Microsoft Store, vous pouvez compter 6 distributions. Je me demande quels autres magasins d'applications disponibles sur certains systèmes d'exploitation ont d'autres systèmes d'exploitation?
Le Microsoft Store dispose désormais de 6 distributions Linux pouvant être utilisées dans WSLLe code que nous écrivions alors était des appels système compatibles avec le noyau Linux, qui servaient d'interface entre les processus Linux et le noyau Windows. Linux a environ 340 appels système. La question était de décider quel système appelait à mettre en œuvre en premier. Comme avec tout système d'exploitation, sous Linux, de nouveaux appels système sont ajoutés à mesure que de nouvelles versions du système d'exploitation sont publiées, mais les anciens appels ne sont jamais supprimés, ce qui garantit une compatibilité descendante. Au début, le traitement d'un certain ensemble d'appels système a été implémenté, et tout le reste a été encapsulé dans des événements comme «pas encore implémenté». Cela a permis à l'équipe WSL de commencer à analyser exactement de quel système les utilisateurs Linux ont besoin.
La réponse à la question de savoir quels appels système devraient être mis en œuvre en premier lieu signifiait la nécessité d'établir une communication avec les personnes qui utiliseraient WSL. Le message sur cette technologie lors de la conférence Build visait à inciter les gens à commencer à utiliser WSL et à donner leur avis. Pour acquérir WSL, vous deviez être membre du programme Windows Insider. Tout le monde peut se connecter à ce programme. Vous pourriez penser que les participants au programme n'étaient que ceux qui étaient intéressés par Windows, mais ensuite, parmi plus de dix millions d'abonnés, il y avait des gens avec une grande variété d'intérêts. Ils s'intéressaient non seulement à Windows, mais aussi, par exemple, aux jeux et aux nouvelles fonctionnalités de Bluetooth et WSL.
L'un des groupes d'utilisateurs intéressés à faire fonctionner le shell Bash sur Windows était le développeur Web impliqué dans la création d'applications Web qui s'exécutent sur des serveurs Linux. L'ensemble du processus d'assemblage de leurs applications était souvent une séquence de commandes Bash. De plus, si quelqu'un décide de demander de l'aide pour le développement d'applications Web, par exemple sur Stack Overflow, la plupart des exemples de code qu'il peut trouver seront conçus pour fonctionner sous Linux. Ce n'est pas particulièrement bon pour ceux qui utilisent Windows comme ordinateur pour le développement Web. Souvent, il est plus facile pour ces développeurs de passer simplement à la plate-forme Mac. Sur macOS, des exemples de code similaires s'exécutent sans aucun problème.
Au cours des deux premières semaines de présence de WSL sur Windows, un utilisateur d'entreprise
a pu exécuter XEyes. Ce programme était exécuté sur un système de fenêtrage X11 fonctionnant en WSL. XEyes est un programme simple. Elle affiche des yeux de dessin animé qui suivent le curseur de la souris. Mais cette démonstration a fait exploser les réseaux sociaux.
XEyes s'exécute sur Windows via WSLNous avons beaucoup discuté de la manière exacte dont nous souhaitons recueillir les avis des utilisateurs sur WSL. L'outil traditionnel utilisé pour recueillir les commentaires était UserVoice. Nous avions un site UserVoice conçu pour WSL, qui a recueilli des centaines d'idées et des milliers de votes sur diverses questions. La vraie question nous est venue quand il s'agissait de savoir si nous devions utiliser GitHub. Les développeurs Web étant l'un des premiers groupes d'utilisateurs intéressés par WSL, la question de GitHub était très importante. Mais WSL n'était pas un projet open source. Placer un tel projet sur GitHub semble étrange. Nous avons décidé de répondre aux exigences des développeurs et avons créé une page sur GitHub pour signaler les problèmes, pour les commentaires et les discussions. Depuis lors, nous avons reçu des milliers de messages concernant de nombreux problèmes liés à l'utilisation de Linux sur Windows.
Des milliers de personnes ont laissé des messages d'erreur dans
le référentiel WSL
GitHub . Chacun de ces messages a été examiné et discuté par l'équipe du WSL, et des commentaires ont été donnés sur chacun d'eux. Après cela, une décision a été prise sur d'autres actions. Si pour réaliser une certaine opportunité ou corriger une sorte d'erreur, il était nécessaire d'écrire un nouveau code - ce code a été créé et ajouté au projet WSL, après quoi il est tombé dans tous les assemblys Windows distribués sous le programme Windows Insider. Le cycle entier, de la réception d'un message d'erreur à sa correction, n'a pas pris beaucoup de temps - environ deux semaines.
En conséquence, grâce à la réponse opérationnelle de l'équipe WSL aux demandes des utilisateurs, il a été possible de dire que la communauté était impliquée dans le processus de création de WSL. Les gens ont signalé des problèmes ou leurs souhaits via UserVoice ou GitHub, l'équipe a examiné tout cela et apporté des modifications au projet, qui est ensuite apparu dans les versions du projet Windows Insider.
Lorsque j'ai rejoint l'équipe WSL en tant que chef de projet, je me suis concentré sur la sortie de la version bêta de WSL. Plaintes des utilisateurs principalement liées à la compatibilité et aux performances. Mais, à mon avis, si les utilisateurs s'inquiètent de telles choses, cela signifie qu'ils utilisent sérieusement notre développement. Les performances ne sont prises en charge que par ceux qui résolvent de gros problèmes à l'aide d'un certain système logiciel. En conséquence, bien que nous ayons encore beaucoup à faire, nous l'avons fait non seulement comme ça, mais pour que les gens puissent résoudre plus de problèmes en utilisant WSL, et pour qu'ils puissent résoudre leurs problèmes plus rapidement.
Alors que les capacités de WSL commençaient à s'étendre, nous avons fait des efforts pour rapprocher WSL des développeurs, et pas seulement des utilisateurs qui utilisent traditionnellement l'écosystème Microsoft. C'était très intéressant d'assister à des événements comme PyCon et OSCON. Les développeurs qui y étaient présents ont été surpris que des représentants de Microsoft aient également participé à ces événements. Les développeurs se méfiaient de l'idée d'exécuter Linux dans un environnement Windows. Lors de ces événements, j'ai montré SQL Server, WSL et Visual Studio Code.
Démonstration de WSL lors de divers événementsJ'ai répondu à leurs commentaires sceptiques par une suggestion d'essayer ce que je leur ai montré. Lorsque les sceptiques ont commencé à exécuter leurs propres commandes, petits scripts et extraits, j'ai toujours rencontré une réaction violente à ce qui se passait: «Attendez une minute, et c'est vraiment Linux. Comment as-tu fait ça? Pourquoi je n'en savais rien? " Souvent, ils sont arrivés à la conclusion que nous avons créé quelque chose qui répond à leurs besoins, quelque chose qui semble très intéressant.
Nous avons pris en compte les plaintes des utilisateurs concernant la compatibilité et les performances WSL, et avons publié une nouvelle architecture système -
WSL 2 . Il offre une compatibilité totale grâce à l'inclusion du noyau Linux dans Windows et offre une multiplication par 20 de la vitesse. J'ai eu une expérience intéressante en créant les fondations de WSL 2 et en regardant l'annonce de cette technologie lors de la conférence Build, qui s'est tenue en mai 2019. Aujourd'hui, le projet WSL a déjà dépassé la version bêta et est passé à la version 2.
De plus, j'ai travaillé chez Microsoft avec d'autres équipes, essayant de garantir que WSL pouvait être utilisé avec leurs produits. Visual Studio Code est un exemple significatif de cette utilisation de WSL. Il s'agit de l'environnement de code le plus utilisé dans le développement de projets JavaScript et Node.js. Je me suis intéressé au code Visual Studio lorsque j'ai réalisé que les développeurs utilisant cet éditeur pouvaient tirer des avantages significatifs de WSL. Au début, il ne s'agissait pas de la nécessité d'écrire d'énormes quantités de code. L'objectif principal était de simplifier le débogage des programmes Node.js s'exécutant dans l'environnement WSL. Cela donnerait aux développeurs la possibilité de développer des programmes conçus pour la version Linux de Node.js sur un ordinateur Windows utilisant WSL. Le débogage de tels programmes ressemblerait exactement à leur débogage sous Linux.
Première tentative d' intégration de Visual Studio Code avec WSL et Node.jsAprès que cela se soit avéré possible pour JavaScript et Node.js, nous avons commencé à recevoir beaucoup de demandes pour que quelque chose de similaire soit fait pour d'autres langages, par exemple, pour C ++ et Python. J'étais fasciné par cet exemple de l'intégration de WSL et VS Code, j'ai trouvé que j'étais très intéressé par cela. Cela m'a conduit à mon nouveau rôle dans la création d'outils pour les développeurs Linux. Maintenant, je me concentre sur les outils pour les développeurs C ++ dans VS Code. Dans ce travail, bien sûr, je me concentre sur Linux. C'était agréable de voir une démonstration du développement à distance du code Visual Studio lors de l'événement PyCon cette année lorsque l'extension WSL correspondante a été publiée. Dans le même temps, une extension pour C ++ a été introduite, que mon équipe développait.
Malgré le fait que je n'ai pas passé autant de temps chez Microsoft, je suis heureux d'avoir pu participer à la création de nombreux outils pour les développeurs Linux. Cette base de données et la prise en charge de Linux sur Windows, et des outils pour écrire et déboguer du code. Je prévois de continuer à travailler sur Linux et à créer des outils que les développeurs du monde entier apprécieront d'utiliser.
Chers lecteurs! Utilisez-vous WSL?
