Respectant les annonces faites depuis la dernière conférence BUILD 2020, Microsoft poursuit son intégration de Linux dans Windows 10 avec notamment WSL. Pour autant, un noyau Linux pour Windows en sera-t-il l’aboutissement ?
Lors de la BUILD 2020, Microsoft a présenté les nouveautés à venir pour sa plateforme, notamment celles dédiées aux développeurs travaillant sous Windows 10. Continuant sur sa lancée depuis 2016, c’est notamment du côté de Linux que la firme américaine a fait des annonces. Windows 10 intègre depuis bientôt quatre ans le Windows Subsystem for Linux (WSL pour les intimes).
La première version, WSL 1, émulait un noyau Linux. Il fallait, après l’avoir installé, télécharger (gratuitement et sans inscription) une des distributions Linux disponibles sur le Store. Cet outil principalement destiné aux développeurs, en particulier les développeurs web et ceux qui travaillent sur des projets open source ou les utilisent, permet d’utiliser Bash, les outils Linux courants tels que sed, awk ou grep et les chaînes d’outils codés en Ruby, Python, C et autres avec Windows. Vous pouvez également accéder au système de fichiers de votre ordinateur local à partir de l’interpréteur de commandes Bash Linux. Vos lecteurs locaux sont montés sous le dossier /mnt. Le lecteur C:, par exemple, est monté sous /mnt/c.
WSL 2 repose désormais sur un vrai noyau Linux, fonctionnant en parallèle de Windows grâce à la plate-forme de machine virtuelle. Il demande moins de ressources (processeur, mémoire et stockage) qu’une machine virtuelle complète. L’intégration des deux systèmes continue avec un gestionnaire de fichiers issu d’une distribution Linux (Canonical pour ne pas la citer) et affichable dans Windows 10. Cette meilleure intégration va permettre à Microsoft d’offrir plusieurs nouveautés. La plus symbolique est la possibilité d’utiliser non plus seulement les outils en ligne de commande issus de l’univers Linux, mais aussi certaines apps graphiques. C’était déjà possible, mais les performances étaient médiocres.
Un noyau Linux pour Windows
Afin d’éclaircir ce point – un futur noyau Linux qui remplacerait le bon vieux kernel Windows – nous avons interviewé Christopher Maneu, Cloud avocate chez Microsoft. Les avocats cloud sont là bien sûr pour promouvoir les choix techniques de Microsoft mais aussi pour aider les ingénieurs et développeurs des équipes produits à «sortir» un peu le nez des 75 km autour de Redmond. Ils sont aussi les yeux et les oreilles des équipes Azur sur le terrain, qui avaient un peu perdu le sens des réalités et ne voyaient plus ce qui se passait dans le monde réel, du moins celui existant ailleurs qu’à Redmond. Christopher Maneu est plus spécialisé sur l’IoT et connaît donc assez bien le monde Linux, mais il cumule aussi plus de 15 ans de développement sur .Net (Desktop) / C#, Python (en Data Science), C /C++ (Desktop et IoT/ développement embarqué) ou encore PHP pour Deezer.
À la question de savoir si, un jour, une nouvelle version de Windows intégrerait un noyau Linux, il a répondu sans ambiguïté : « Changer de kernel ? «Virer» le kernel Windows et le remplacer par un noyau Linux apporterai, sûrement, certains avantages, mais aussi de nombreuses contraintes. C’est très difficile car cela pourrait entraîner de sérieux problèmes de rétrocompatibilité.» Il est vrai que, comme le rappelle Christopher, « la différence entre Microsoft et d’autres OS c’est que des applications Windows 7, XP ou encore plus anciennes peuvent encore fonctionner sous Windows 10 ».
Si l’avocat pense, entre autres, à Mac OS, il est vrai que Windows est un véritable OS d’entreprise qui prend en compte les besoins métier des équipes. Contrairement au choix d’Apple d’obliger à mettre à jour non seulement le système mais souvent aussi le hardware pour utiliser certaines versions récentes de logiciels, de façon totalement artificielle car le soft pourrait très bien tourner sans rien faire, Microsoft, à l’inverse, fait tout pour tenter d’assurer la rétrocompatibilité. L’éditeur de Seattle n’intègre pas de blocages superflus et vicieux comme certains. Il fournit au contraire un assistant de compatibilité, un kit de compatibilité applicative complémentaire, l’ACT (Application Compatibility Toolkit) via son kit gratuit de déploiement et d’évaluation ADK (Assesment and Deployement Kit) et, surtout, il fait en sorte que les API du système soient les plus rétrocompatibles possibles, même si les techniciens systèmes des entreprises doivent réaliser certaines adaptations pour faire tourner leurs vieilles applications métier. Que deviendrait tout cela avec un noyau Linux? Ce serait effectivement problématique pour les clients de Microsoft. « Le changement de Kernel impliquerait de très grands changements dans le développement d’applications pour Windows.» Cela impose certaines limites en termes d’évolution bas niveau du système d’exploitation.
Comme le rappelle aussi Christopher Maneu, « la devise de Microsoft est : Our mission is to empower every person and every organization on the planet to achieve more.» Ce qui peut se traduire approximativement par : « Notre mission est d’aider les individus et les organisations à atteindre leur potentiel maximal.» C’est bien sûr un beau slogan marketing, mais pas seulement. Le big boss, Satya Nadella, en a fait la ligne de conduite de Microsoft et de Windows. Bref, pas de noyau Linux pour Windows, au moins dans un futur proche. En revanche, pour permettre aux développeurs de travailler sur les deux grandes plates-formes (Linux et Windows) depuis Windows 10, il y a WSL qui est sous le feu des projecteurs depuis la dernière BUILD. « WSL est un des exemples de l’application de cette mission !», nous dit Christopher Maneu. « Grâce à WSL, les développeurs peuvent utiliser aisément leurs tools Linux sous Windows, et pas seulement.»
Effectivement, lorsque l’on développe il est assez fréquent d’avoir besoin d’outils Linux tels que vi, grep, bash ou autre. « Il aurait, certes, été possible de porter ces outils sous Windows, mais c’est compliqué à faire et encore plus à maintenir.» Il est bien plus simple d’utiliser directement les « versions originales» depuis un shell Linux (bash le plus souvent, mais vous pouvez charger celui que vous voulez). « Il est possible de faire cela depuis une vm – machine virtuelle – mais cela consomme beaucoup de ressources. Qui plus est, certaines entreprises bloquent l’utilisation des vm sur les postes pour des raisons de sécurité. Mieux qu’une vm, c’est de ne pas utiliser de vm tout en profitant des mêmes avantages. Cela dégrève aussi des problèmes de performances tout en améliorant la productivité des développeurs. Il est ainsi plus facile de brancher un port USB pour le tester avec une application Linux, ce qui n’est pas si simple avec une vm classique, et c’est la même chose avec d’autres ports.» Cela marche très bien en revanche avec WSL qui partage l’adresse IP de Windows. Ainsi vous pouvez accéder à n’importe quel port sur localhost. Si, par exemple, vous avez du contenu web sur le port 1234, vous pouvez utiliser https://localhost:1234 dans votre navigateur Windows. « Pour contourner tout cela, WSL s’exécute sur le noyau Windows avec une couche de conversion des API Posix vers Windows et ne consomme que très peu de ressources.»
Ceci étant, il y a eu pas mal de problèmes de fonctionnement avec WSL 1. Au vu des remontées des développeurs, beaucoup de choses ne fonctionnaient pas. Microsoft a dû revoir sa copie et passer à WSL 2. WSL 2 possède un noyau Linux qui est un fork du noyau classique ; il tourne dans une mini vm avec des temps de démarrage et de fonctionnement optimisés conduisant à une totale compatibilité avec les applis Windows.
En résumé, WSL 2 apporte une bien meilleure compatibilité tout en admettant moins de performances. Il permet par exemple d’accéder à un serveur NodeJS tournant sur WSL – distribution Linux – depuis un localhost sous Windows. La principale faiblesse de WSL tient dans les performances du File System (système de fichiers), notamment quand l’un des File System essaie d’utiliser l’autre. Si, par exemple, vous développez sous le FS de Linux depuis WSL et que vous lancez une compilation sous Windows, les performances seront exécrables. Vous n’aurez pas à faire cela tous les jours, mais si c’est le cas, c’est la catastrophe en termes de rendu. La solution provisoire consisterait à utiliser WSL 1 pour cela, ou bien… d’éviter autant que possible la manipulation d’un FS à partir d’un autre. « Il est possible d’avoir WSL 1 et WSL 2 sur le même poste », nous dit encore Christopher Maneu. Cela demande quelques manipulations – un peu de ligne de commande… – car cette configuration n’est pas directement disponible depuis le Store. « Il faut créer une nouvelle distribution WSL en changeant le nom. Il est même possible de faire cohabiter deux distributions identiques (même distrib et même version) WSL 1 et WSL 2. Il faut juste changer le nom de l’une d’elle en la renommant.»
DirectX
La dernière version de Windows 10 active l’accélération graphique du système pour les apps Linux, permettant ainsi de bénéficier de performances relativement similaires sur les deux systèmes. Cette nouveauté est en fait la conséquence d’un changement plus important. DirectX, l’API 3D de Windows a été modifiée pour apporter l’accélération matérielle à WSL 2 et donc à tous les outils en ligne de commande utilisés par les développeurs. Cela représente un grand avantage pour les applications de Machine Learning et d’autres tâches s’appuyant massivement sur les puces graphiques. Microsoft a aussi beaucoup travaillé pour que OpenGL et OpenCL fonctionnent sur Direct X 12 sous WSL 2. Cela devrait aussi être le cas à terme pour Vulkan, la nouvelle version d’Open GL. CUDA de Nvidia sera aussi disponible dans ce cadre. « L’accès à la GPU pour effectuer des calculs est lui aussi très important. Les Data Scientist et analystes de ML travaillent généralement sous Linux en Python ou R mais commencent et finissent le travail sous Windows. Il faut noter par rapport à cela la virtualisation de la GPU sur WSL 2 et l’arrivée d’une partie de Direct X pour Linux. Beaucoup de travail a été fait par Microsoft sur cette partie graphique.»
Il ne faut pas non plus oublier que dans DirectX il y a Direct ML, la nouvelle couche d’abstraction pour le ML. « L’idée avec Direct ML est d’ajouter une couche d’indirection pour porter plus facilement le code de Machine Learning pour la GPU, de permettre que le code de ML soit plus facilement portable d’une machine à l’autre.» Microsoft travaille aussi sur une API de Mapping entre OpenGL et DirectX. « Le but recherché est bien entendu de ne pas imposer aux dev de recoder leurs applications pour les deux API graphiques.» Finalement, tout cela combiné, Microsoft a fait une grosse partie du travail pour que WSL supporte des applis graphiques.
File System
WSL 1 et 2 ont, pour le moment du moins, vocation à cohabiter, l’utilisation du premier étant parfois plus pertinente. D’après Microsoft et Christopher Maneu, c’est notamment le cas « si vous souhaitez utiliser votre distribution WSL Linux pour accéder aux fichiers de projet dans le système de fichiers Windows.»
De manière générale, le système de fichiers de WSL 1 est plus performant pour le moment si vous utilisez des applications Windows pour accéder à des fichiers Linux. Le système de fichiers de WSL 2 offre, lui, de meilleures performances lorsque vous utilisez des fichiers Linux depuis des applications Linux.
Cela nécessitera une bonne gestion des droits sur les deux systèmes. La conversion des permissions de l’un à l’autre et ses paramètres sont détaillés à cette adresse : https:// docs.microsoft.com/fr-fr/windows/ wsl/file-permissions
Installation et configuration de WSL 2
Pour installer WSL 2, vous devez en premier lieu activer le sous-système Linux et la plate-forme de machine virtuelle dans la liste des fonctionnalités Windows. Vous pouvez pour cela dérouler les menus ou, plus rapidement, lancer OptionalFeatures.exe. Vous pouvez aussi avoir recours à DISM en usant des commandes suivantes dans un shell cmd – en mode Administrateur :
dism.exe /online /enable-feature /featurename:Microsoft-WindowsSubsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
Si vous préférez le faire avec Powershell, ouvrez une fenêtre de commande Powershell – toujours en mode Administrateur – et saisissez cette fois ces deux lignes :
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
Vous devrez ensuite redémarrez votre machine. Si cela ne fonctionnait pas, vérifiez que la fonction de virtualisation et la translation d’adresses de niveau 2 sont bien activées dans votre BIOS ou UEFI. C’est, normalement, le cas par défaut sur des machines récentes, mais on ne sait jamais. Si votre processeur est trop « poussif» (Celeron, par exemple), vous ne pourrez pas le faire. Puisque WSL 1 et 2 coexistent, une distribution peut être installée dans une version ou l’autre, être convertie de l’une à l’autre et même exister sous les deux versions – à condition de renommer manuellement l’une des deux.
Autres avantages et améliorations de WSL
WSL améliore la cross-compilation. La compilation croisée consiste à compiler sur un système d’exploitation pour un autre système, en l’occurrence depuis Windows pour Linux. « Nous sommes très loin de faire fonctionner un binaire Linux directement sous Windows mais… quel intérêt cela aurait-il ? En revanche, avoir un WSL sur son poste qui a la même distribution ou ligne de distribution qu’un serveur de l’entreprise peut s’avérer très pratique pour les IT», nous dit encore Christopher. Le support de l’audio, pour les applis Multimédia, n’a pas été oublié. Il en est de même pour Docker qui propose ainsi un accès de choix à ses outils (https://docs.docker.com/docker-for-windows/wsl/) aux développeurs sous Windows, qui peuvent désormais très facilement les exploiter et les interfacer avec Visual Studio Code. Les dernières versions de Docker for Desktop tournent sur WSL. « Il est possible de faire tourner nativement Docker sous Windows grâce à WSL, alors qu’auparavant il fallait un Mobilinux sous Windows, comme pour MacOS.» Visual Studio Code a lui aussi été spécialement adapté pour profiter du sous-système Linux. Une extension spécifique est ainsi proposée aux utilisateurs : Remote – WSL (https:// marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remotewsl). Nous en parlerons dans un (très) prochain article.
Winget, un nouveau gestionnaire de paquets
Le gestionnaire de paquets en ligne de commande winget vient combler un vide par rapport aux distributions GNU/Linux ou à MacOS. L’idée est de pouvoir installer et mettre à jour très facilement des apps ou des outils en ligne de commande, en gérant notamment les dépendances. Toutes les distributions Linux intègrent leur propre gestionnaire de paquets, et souvent même plusieurs : apt, yum et autres yast. Il en existe aussi plusieurs sur MacOS, le plus connu étant Homebrew. Il était aussi déjà possible d’en installer sous Windows, Chocolatey étant sans doute le plus connu. Néanmoins, le fait que Microsoft crée sa propre version est là encore un message fort en direction de la communauté des développeurs. Comme la majorité de ce qu’elle fait désormais, winget est un projet open-source dans lequel tout le monde peut ajouter ses propres paquets.
Changer de File System et abandonner le NTFS ?
Tout comme pour le noyau, il est difficile voire impossible de changer de File System, de passer par exemple du NTFS à ext4 ou autre btrfs. Là encore, il y aurait un problème de rétrocompatibilité si Microsoft abandonnait NTFS, comme le rappelle Christopher : « Des centaines de partenaires utilisent le NTFS à bas niveau pour faire des logiciels de sauvegarde, de compliance, et il y a les autorisations NTFS, EFS et d’autres technos liées à ce File System. » Windows conservera donc le NTFS, mais en tentant encore de l’améliorer considérablement, de le rendre plus rapide et de mettre au point les Store Space, le futur équivalent de LVM plébiscité par Red Hat et d’autres distributions Linux.