Microsoft vient d’annoncer une étape majeure pour Windows Subsystem for Linux (WSL) : son passage en open source. Cette décision, qui intervient peu avant le dixième anniversaire de l’outil, promet de nouvelles perspectives pour la communauté des développeurs. Mais au-delà de l’effet d’annonce, quelles sont les implications concrètes ?
Vu que c’est déjà une plaie à utiliser … m’est avis que ça ne va pas se bousculer pour regarder comment c’est fait et encore moins pour proposer des améliorations.
2 « J'aime »
Faut quand même féliciter le geste
1 « J'aime »
Moi c’est l’inverse que j’aimerais.
A quand un LSW ?
Quand Microsoft fera de windows une distribution GNU/Linux open source, je féliciterai le geste 
2 « J'aime »
C’est pas ce qu’on appelle depuis plus de 30 ans « Wine », forké récemment en « Proton » par Valve ?
1 « J'aime »
Non. Wine est une réimplémentation relativement complète des API Windows par dessus l’API POSIX.
WSL, c’est aujourd’hui un vrai Linux (il n’y a pas de réimplémentation de l’API du noyau Linux, c’est le noyau Linux), qui tourne dans une VM sur un hôte Windows, avec une couche dans la gestion de la VM pour mieux l’intégrer dans l’écosystème Windows, et notamment permettre de « sortir » de la VM dans certains cas (par exemple, tu peux lancer un .exe depuis Bash) et de partager le système de fichier sans passer par du réseau virtuel.
Pour un équivalent dans l’autre sens, c’est plutôt côté Qemu et libvirt qu’il faudrait travailler, mais en l’état l’intégration reste plus limitée que ce qui est possible avec WSL.
1 « J'aime »
Pour rigoler, peux tu nous donner le résultat de la commande suivante dans la « VM Linux » de ton WSL : ls -al /boot
Mais l’objectif est plus ou moins le même non ? Pouvoir faire tourner du soft sur un système qui n’est pas natif ?
Car pour faire du développement, autant prendre le système natif et travailler dessus plutôt que passer par des VM ou des couches de compatibilité ?
C’est vide, ce qui n’empêche pas qu’il y ait un vrai noyau Linux. Simplement il est ailleurs (normalement dans C:\Windows\System32\lxss\tools\kernel)…
Les sources sont là : GitHub - microsoft/WSL2-Linux-Kernel: The source for the Linux kernel used in Windows Subsystem for Linux 2 (WSL2)
De loin, oui, c’est le même objectif. Dans les détails, l’intégration est plus poussée avec WSL, et c’est aussi plus « fiable », puisque tu élimines une couche de réimplémentation (donc avec des bugs possibles) des API système.
Quand tu développes pour plusieurs plateformes, c’est quand même pratique de pas avoir à rebooter.
Et WSL permet aujourd’hui d’avoir un résultat assez fiable pour compiler et tester sous Linux un truc que tu as développé, surtout si ça n’est pas une appli graphique, je suis pas sûr qu’on puisse en dire autant de Wine dans l’autre sens.
1 « J'aime »
La commande donne une réponse vide et c’est normal : dans WSL, le noyau est fourni par Windows et non par la distro, donc /boot n’a pas à contenir d’image noyau ni de bootloader. Ce choix s’explique par l’architecture : c’est l’hyperviseur Windows qui gère le cycle de vie du noyau et de la VM. Centraliser le noyau permet de garantir cohérence, sécurité, et compatibilité entre toutes les distros WSL, tout en gardant un contrôle bas niveau sur l’environnement d’exécution.
P’tet … mais dans ce cas, ce n’est pas une VM. Cela reste une émulation utilisant des mécanismes d’hyperviseur.
Ok, mais même s’il y a une « centralisation pour la cohérence etc … », on parle d’un truc en mode bricolage haut de gamme qui n’a rien à voir avec une machine virtuelle.
Par contre, je ne suis pas du tout d’accord avec ta vision du sujet. Du point de vue basic user, tu peux avoir raison car ton raisonnement est logique. Mais c’est tout. Une fois que tu auras manipulé un OS complet avec toute la panoplie, tu verras que l’approche de MS leur est propre et à leur sauce (CàD en dehors de ce que font les autres) comme tout ce qu’ils font.
Ben non. Les appels système faits par les applications Linux sont directement traités par le code du noyau Linux, tournant nativement sur le CPU dans une VM, et sans exécuter de code Windows (l’interfaçage avec Windows se fait plus bas niveau, via la couche de matériel virtuel). C’est bien de la virtualisation, pas de l’émulation. Sinon ça n’aurait pas besoin de passer par un hyperviseur hein…
Ce n’est pas parce que c’est une VM n’ayant pas tous les attributs classique d’une VM VirtualBox ou VMWare que ce n’est pas une VM. Ce qui fait que c’est une VM, c’est bien le fait qu’un a un noyau isolé, qui tourne nativement sur le CPU via ses fonctions de virtualisation, et auquel on expose du matériel virtualisé.
En comparaison, quand tu exécutes une application Windows avec Wine, lors d’un appel système là ça va passer par une couche d’émulation gérée par Wine, qui réimplémente cet appel système et derrière va faire des appels système sur le noyau Linux. Aucune isolation, pas de matériel virtuel.
1 « J'aime »
Oui tes arguments se tiennent.
Mais quand un hyperviseur gère le noyau d’une VM au lieu juste de fournir l’émulation matérielle … ben, j’ai du mal à appeler ça une VM. On est plus proche de la logique de container de type docker que d’une VM.
Mais bon, si tu veux vendre WSL comme étant « un vrai linux » parce que MS aime Linux … pas de soucis, par contre c’est juste faux, WSL est une mascarade qui laisse à penser qu’il faut avoir Windows pour faire fonctionner Linux (c’est grossier comme raccourci mais l’idée est là)
Il fournit bien une virtualisation, avec émulation de certains composants, exactement comme il le fait avec n’importe quel autre VM. C’est simplement que au lieu d’avoir le noyau dans l’image disque de la VM, il est pris ailleurs. Mais la virtualisation est toujours bien là.
Et tu peux même remplacer le noyau par un autre, recompilé par tes soins à partir des sources.
Non, absolument pas. Toute l’isolation fournie par une container est gérée par des services et le noyau système, y a zéro virtualisation, tout ce qui tourne dans le container utilise le noyau de l’hôte.
Sauf dans un cas particulier, les Kata Containers, qui eux tournent effectivement avec leur propre noyau et un hyperviseur. Et je te le donne en mille… Tout ceux qui s’en servent considèrent justement que ces containers sont des VM.
Doit y avoir à peu près personne qui pense ça hein 
Prends un décideur non technique pour qui tout ça est incompréhensible : il lui faut des raccourcis faciles pour la tête … du coup, le WSL est la solution aux problèmes des développeurs parce que le commercial MS lui a dit.
Mais du coup pourquoi ne pas utiliser directement un VirtualBox ?
Quel est l’avantage de wsl ?
L’intégration.
Une Virtual Box, c’est un système complètement indépendant de l’OS, la communication entre les deux ne peut se faire que par le réseau.
Avec WSL, tu as un accès complet au système de fichiers de la machine (vu comme un système de fichier local, dans une VM tu peux aussi le faire, mais avec des montages réseau, ce qui limite certains cas d’usage), et tu peux même dans une certaine mesure faire des interactions directes entre des applications Windows et Linux.
Par exemple, tu peux intégrer dans un script Windows des commandes Linux, et inversement faire un script Bash qui utilise des commandes Windows.
Un exemple concret, j’ai un script qui utilise des outils Linux pour convertir une vidéo d’un format à l’autre, puis qui lance la lecture de cette vidéo sur la version Windows de VLC.
Mais quel est l’intérêt de faire ça du coup, vu qu’il existe une version GNU/Linux de VLC ?
1 « J'aime »
Je parle de l’intérêt par rapport à une VM… Quand l’hôte est un Windows, c’est quand même plus naturel et plus performant d’utiliser le VLC natif de Windows, plutôt que le VLC dans une VM, avec notamment un accès limité aux accélérateurs matériels…