Discussion :

[hepha1970]

Bonjours à tous, d'un autre côté c'est un peu dire "tiens je veux bien une aide pour intégrer Bash dans windows, mais en contre-partie pour donner les sources des librairies windows pour aider Wine ou autre tu peux toujours te brosser". en gros, on fait reculer les parts de marché de linux ni vu, ni connu. Je ne sais pas trop si à terme ce sera bon pour les systèmes linux ? l'utilisateur lambda se dira alors pourquoi installer linux , si je peux faire la même chose sous windows ? Concernant les sociétés de développement, pareil, pourquoi développer ou porter sous linux , si l'utilisateur final n'a plus besoin d'installer linux, donc continuons à développer et a distribuer pour windows... Peut-être est-ce moi qui résonne mal , mais c'est comme cela que je vois la chose, pour moi je vois cela comme une menace au monde linux plutôt qu'un bienfait. Cordialement

[air-dex]

Que vient faire WINE dans un partenariat entre Microsoft et Canonical ?

Après le but de Microsoft reste au fond le même. Ils s'en foutent DU MOMENT QUE ça tourne sur des solutions Microsoft. Si le libre leur permet d'atteindre cet objectif alors tant mieux pour eux.

[Olivier Famien]

Que savez-vous du noyau Linux intégré à Windows 10 ?
Alex Ionescu, développeur du noyau de ReactOS, revient sur le sujet pendant la conférence Black Hat 2016

Dans le mois de mars dernier, Microsoft a annoncé l’intégration du Shell Unix Bash dans son système d’exploitation Windows 10. Avec cette nouvelle implémentation, les utilisateurs sont désormais capables d’exécuter les scripts Bash directement sur Windows sans avoir besoin de passer par l’installation d’une machine virtuelle Linux ou encore recourir à des solutions comme Cygwin.

Après plusieurs mois d’essais et d’améliorations, Alex Ionescu, le développeur principal du noyau de ReactOS et fondateur de Winsider Seminars & Solutions Inc., revient sur les détails du noyau Linux intégré à Windows lors de la conférence Black Hat qui a eu lieu il y a quelque temps de cela.

Dans son exposé, Ionescu explique que l’intégration de Windows Subsystem for Linux (WSL) est partie du projet Drawbridge. Le but de ce projet était de concevoir une version allégée de Windows afin d’exécuter les applications dans un environnement tiers. En principe, en exécutant les systèmes dans un environnement virtuel, on obtient ce résultat. Toutefois, cette méthode fait appel à beaucoup de ressources, ce qui constitue un inconvénient majeur.

Avec le projet Drawbridge, les choses ont été pensées autrement. Les ingénieurs chez Microsoft ont souhaité mettre en œuvre l’exécution d’un OS et des applications affiliées dans un environnement minimal requérant peu de ressources. Les avancées dans cette voie ont abouti à l’implémentation du principe de library OS, ou simplement un système d’exploitation en bibliothèque et des processus pico.

Un système d’exploitation en bibliothèque est en fait un système d’exploitation recomposé et exécuté sous la forme d’un ensemble de bibliothèques. Compte tenu du fait qu’il s’exécute sous la forme de bibliothèques, il nécessite des ressources matérielles réduites. Toutefois, pour éviter que l’évolution ou les changements du système hôte interfèrent avec les processus de ce système d’exploitation réduit et aussi assurer la sécurité de ce dernier, les ingénieurs ont isolé cette implémentation dans ce qu’ils ont appelé un processus pico. Un processus pico n’est plus ni moins qu’un conteneur permettant d’isoler les appels d’application exécutés comme des processus.

Et dans le contexte du projet Drawbridge, le library OS peut exécuter des applications dans un environnement fermé sans interférer avec certaines applications ou certains processus du système hôte. Et comme pièce maîtresse pour assurer l’intégrité du fonctionnement, nous avons le pilote du mode kernel supportant le processus pico.

Il s’assure de la séparation entre le noyau du système hôte et le library OS en mode utilisateur. Les processus pico sont apparus pour la première fois dans Windows 8.1 et Windows Server 2012R2, mais étaient limités au projet Drawbridge. Au fil des années, de nouvelles fonctionnalités et des améliorations ont été bâties sur ces deux composantes à savoir le processus pico et le library OS. C’est à partir de ce système que Microsoft a pu intégrer la couche WSL pour assurer la compatibilité entre Linux et Windows au sein de Windows 10.

À la conférence Black Hat, en plus d’avoir abordé la genèse du projet, Ionescu s’est également étendu sur différents points relatifs au noyau Linux dans Windows. Ci-dessous, un résumé des points abordés :

• De nouveaux pilotes (lxcore.sys et lxss.sys) ont été intégrés dans la version de Windows 10 Anniversary afin d’implémenter les appels système Linux et permettre la compatibilité du noyau en tant que sous-système Windows ;
• Aucun réel code Linux ou code GPL semble être utilisé dans ces pilotes dans la mesure où la plupart de l’implémentation est juste un wrapper autour des appels système du noyau NT (fichier IO, réseau IO, ordonnancement CPU, etc.) ;
• Il y a des communications interprocessus pour communiquer et exécuter directement les processus sous le sous-système Linux à partir de Windows en faisant recours à une interface COM exposée non documentée ;
• Les processus créés et exécutés par le sous-système ne paraissent pas être des processus Windows normaux. Ils sont créés comme des processus Pico avec peu d’informations provenant à leur sujet. Il n’y a pas de documentation des API sur la possibilité d’inspecter les processus, car la réponse aux appels système provient du kernel ;
• Le fait de ne pas savoir comment les binaires Linux sont gérés sous Windows peut être exploité par des tiers malveillants pour mener des attaques puisque les solutions d’antivirus actuels ne sont pas à même de gérer les binaires Linux sous Windows comme cela se fait avec les binaires de la plateforme hôte. Certains pourraient même exploiter cette méconnaissance de l’environnement du sous-système pour installer des portes dérobées dans la mesure où le sous-système Linux peut accéder au système de fichier entier.

Source : YouTube

Et vous ?

Que pensez-vous de ce sous-système Linux ?

L'avez-vous utilisez depuis son intégration dans Windows 10 ? Quel retour en faites-vous ?

Voir aussi

La rubrique Windows, Forum Windows 10, Cours et tutoriels Windows, Forum Windows

[youx]

Sur la stratégie de Microsoft dans le domaine cela me fait penser à leur vieux adage remis au goût du jour par la nouvelle équipe de direction:" Étreindre, Étendre, Éteindre".

Avec leur direction open source et d'ouverture ils essais de ce rendre indispensable pour pléthore de service sur le thème "avec moi c'est plus simple que la concurrence". Techniquement intéressant comme projet, c'est tout pour moi.

[SkyZoThreaD]

Ça ressemble plus à de la virtualisation qu'a un kernel. Et heureusement par-ce que le jour ou windows tourne sur un kernel linux je descend à Redmond foutre le feu
Quoi qu'il en soit j'apprécie beaucoup les efforts de crosoft pour les linuxiens. C'est très agréable de lancer cmd.exe et de faire du ssh et des ls, alors j'imagine des pipes, des grep des vim et du gcc
Linux sera toujours mon système principal pour son ouverture et le fait que j'ai le contrôle de ma machine mais faut pas se le cacher, on est souvent confronté à du Windows et c'est un bonheur de retrouver ses habitudes dessus.
Mais ce dernier ne sera jamais opensource car le jours où ça arrive, un fork sortira et la vente de licences risque d'en prendre un coup

[abriotde]

Ce n'est en aucun cas de la virtualisation. C'est plus comme "Cygwin" c'est a dire un wrapper des appel system Linux pour les transformer en appel system Windows. Mais en plus ce qu'il explique c'est que les process sont encapsuler dans un "pico process" autrement dit des process spéciaux au niveau du noyau Windows.

J'ai testé testé WSL sur un Windows du bureau (car à la maison et au bureau je travail sous Linux). Et ma fois c'est mieux que Cygwin. Windows joue là un grand coup car ainsi il peux espérer récupérer les Windowsien partis sous Linux ou plus récupérer les serveur Linux qui pourraient à terme y trouver un avantage... mais c'est risqué car, les développeurs pourraient privilégié Linux et adapté pour que cela fonctionne sous WSL pour Windows. Bien sûr les premiers a franchir ce pas seront sûrement des Hackers. Mais pourça il faudra attendre que WSL soit en standard sur tous les Windows 10 ce qui n'est pas encore le cas.

[LittleWhite]

En quoi est-ce mieux que Cygwin ?
Du coup, est-ce mieux que Bash for Windows ?

[SkyZoThreaD]

Ce n'est en aucun cas de la virtualisation. C'est plus comme "Cygwin" c'est a dire un wrapper des appel system Linux pour les transformer en appel system Windows. Mais en plus ce qu'il explique c'est que les process sont encapsuler dans un "pico process" autrement dit des process spéciaux au niveau du noyau Windows.

Je m'en doutais. J'ai mal choisi mes mots.

Bien sûr les premiers a franchir ce pas seront sûrement des Hackers. Mais pourça il faudra attendre que WSL soit en standard sur tous les Windows 10 ce qui n'est pas encore le cas.

On est tous des hackers Tu voulais peut-être parler des crackers

Windows joue là un grand coup car ainsi il peux espérer récupérer les Windowsien partis sous Linux ou plus récupérer les serveur Linux qui pourraient à terme y trouver un avantage... mais c'est risqué car, les développeurs pourraient privilégié Linux et adapté pour que cela fonctionne sous WSL pour Windows.

Certainement. Mais faut pas rêver. On a bien d'autres raisons de tourner sous tux. Pourquoi acheter de la licence pour faire tourner des programmes tux ?

[foetus]

Certainement. Mais faut pas rêver. On a bien d'autres raisons de tourner sous tux. Pourquoi acheter de la licence pour faire tourner des programmes tux ?

La licence, Microsoft s'en tape

Je pense que Microsoft veut vendre du nuage Azur : donc pour le client c'est transparent, mais peut-être pas pour les applications/ sites/ autres hébergés

[jlliagre]

Ce n'est en aucun cas de la virtualisation.

Ok, ce n'est en aucun cas de la virtualisation matérielle, mais c'est bien une variante de virtualisation de système d'exploitation, comme les LXC, zones, jails et autres docker.

C'est plus comme "Cygwin" c'est a dire un wrapper des appel system Linux pour les transformer en appel system Windows.

Si on veut, mais il y des différences fondamentales entre cygwin et wsl. Cygwin, c'est du portage relativement classique, on recompile tout pour l'OS cible (ici windows) après s'être arrangé pour gommer les différences à l'aide de bibiothèques (userland), les binaires cygwin sont des exécutables Windows au format PE. Avec wsl, on ne touche pas du tout aux exécutables Linux qui restent donc au format ELF et on leur présente l'environnement noyau qu'ils attendent. Cet environnement est fourni par le noyau Windows, il n'y a pas de bibliothèque. La seule entorse à ce modèle est le processus parent de tous les autres qui n'est pas systemd ou un init Linux, mais un init Microsoft maison.

Mais en plus ce qu'il explique c'est que les process sont encapsuler dans un "pico process" autrement dit des process spéciaux au niveau du noyau Windows.

Ils ne sont pas encapsulés dans des pico processes, les processus Linux sont implémentés en tant que pico-processes et ces processes ne tournent pas dans le noyau, c'est du "userland" comme les autres.

Du coup, est-ce mieux que Bash for Windows ?

Ni mieux, ni moins bien, c'est exactement la même chose, "Bash for windows" est un appellation plus marketing que "Windows susbsystem for linux" plus technique.

[LittleWhite]

Pardon, je voulais dire "Git Bash", l'implémentation de Bash pour Windows, proposée ici : https://git-scm.com/download/win

[jlliagre]

"Git Bash" est un environnement minimaliste et n'a pas l'ambition de cygwin qui est de faire croire le plus possible qu'on est dans un gnu/linux. Bash et les autres utilitaires livrés avec mingw (ce qui est réellement la partie "linux" de bash for git) sont compilés nativement pour windows en utilisant les fonctionnalités disponibles, ils ne s'appuient pas sur une dll supplémentaire qui apporte une couche de conversion comme c'est le cas avec cygwin.

[MikeRowSoft]

Ils ont voulu éviter machine virtuelle façons Java ou virtualisation façons virtual PC ou application façons Cygwin.
Mais j'admet avoir lu rapidement... Donc je dirais machine virtuelle façons linker x86, sachant que pour chaque environnement de systèmes d'exploitations il y a des caractéristiques d'intégrations...

[Benjamin Gates]

Tout ceci, c'est bien. La question est pour quelle intérêt?

[MikeRowSoft]

Je suppose que c'est une judicieuse alternative à Qemu.
Mais sans avoir besoin du noyau compilé d'un autre système d'exploitation.

Cela permet aussi d'éviter "l'émulation" matériel du composants, comme les CPU d'une autre architecture. L'émulation de périphériques étant plutôt abordable dû aux bus de communications.

[jlliagre]

Linux et Windows utilisent ici la même architecture matérielle (x86), aucune adaptation de code machine n'est nécessaire.

[jack-ft]

Je ne voudrais pas lancer un troll, mais, à titre de comparaison, macOS est basé sur un kernel Unix depuis 1999, ce qui lui donne une certaine robustesse et des outils de ligne de commande assez puissants (un peu moins toutefois que ceux de linux).

[talvins]

Ce n'est pas du tout un troll @jack-ft, c'est pourquoi on attendait ça sur Windows depuis fort longtemps. Le principe n'est pas le même mais ça permet enfin de se libérer de la nullité des lignes de commandes Windows et de tous avoir, enfin, une plateforme quasi identique lorsque l'on utilise des outils de développements web.

[Aurelien.Regat-Barrel]

Ah ça y est, ça arrive enfin !

Rappelons cette news récente qui donne les détails:
http://www.developpez.com/actu/10548...-sur-ce-sujet/

[jlliagre]

Rappelons cette news récente qui donne les détails

Ca sent la récursivité. Il n'est peut-être pas indispensable de rappeler cette news dans un post qui se retouve précisément comme commentaire de la dite news ...