Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Le titre de cette info n'en décrit pas le contenu, selon ce que je comprends. La nouveauté n'est pas la simple ajoute du shell bash (ce qui est trivial et existe déjà). Ce n'est pas non plus la disponibilité d'outils communs (genre ls, du etc), ce qui existe aussi déjà (Cygwin le fait) ...
Mais ce serait l'introduction d'un environnement POSIX complet permettant l'exécutions de binaires (et de libraries partagées) ELF ? C'est ça ?
Il s'agit bien de ça (sauf qu'Ubuntu n'est pas certifié POSIX), mais c'est en fait beaucoup plus car un environnement Ubuntu (Debian), même limité à la ligne de commande, est largement plus riche et étendu que ce que définit POSIX.
L'exécution de binaires et bibliothèques dans un format non natif (ELF au lieu de PE) est bien la nouveauté sous Windows.
ɹǝsn *sıɹɐlos*
Après m'être renseigné sur le sujet, cette exécution des binaires ELF n'est supportée que depuis bash.exe. Le loader système de Windows n'a pas été modifié pour reconnaître les binaires Linux. Ce n'est donc pas, il me semble, la même notion de sous-système que ce que l'on a pu connaitre avec le précédent (mini) sous-système POSIX de NT. J'aimerais bien en savoir plus
L'exécution des binaires ELF est possible à partir d'autres binaires ELF via l'appel système exec, pas seulement de bash mais c'est vrai que cette exécution n'est pas (pour l'instant?) accessible d'un binaire Windows classique.
Le sous système POSIX de Windows NT était lui aussi confiné et comme il ne contenait de base à peu près rien d'intéressant, même pas un shell, il ne servait essentiellement à rien. Interix/SFU a légèrement amélioré les choses mais a été abandonné par Microsoft. Cygwin s'est imposé comme environnement de type Unix sur Windows.
ɹǝsn *sıɹɐlos*
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
Windows 7 / Debian 8 jessie / Kali 2 / Nas Synology ds214se / Arduino Mega 2560 / Raspberry Pi 3
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.
"Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain
Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).
Que savez-vous du noyau Linux intégré à Windows 10 ?
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 ?
Voir aussi
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
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.
Ç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
La liberté est à la sociologie ce que l'instant présent est à la physique relativiste.
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.
Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.
En quoi est-ce mieux que Cygwin ?
Du coup, est-ce mieux que Bash for Windows ?
Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi
Ma page sur DVP
Mon Portfolio
Qui connaît l'erreur, connaît la solution.
Je m'en doutais. J'ai mal choisi mes mots.Envoyé par abriotde
On est tous des hackersTu voulais peut-être parler des crackers
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 liberté est à la sociologie ce que l'instant présent est à la physique relativiste.
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.
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.C'est plus comme "Cygwin" c'est a dire un wrapper des appel system Linux pour les transformer en appel system 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.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.
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.
ɹǝsn *sıɹɐlos*
Pardon, je voulais dire "Git Bash", l'implémentation de Bash pour Windows, proposée ici : https://git-scm.com/download/win
Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi
Ma page sur DVP
Mon Portfolio
Qui connaît l'erreur, connaît la solution.
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
"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.
ɹǝsn *sıɹɐlos*
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...
Bash sur Windows
Tout ceci, c'est bien. La question est pour quelle intérêt?
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.
Linux et Windows utilisent ici la même architecture matérielle (x86), aucune adaptation de code machine n'est nécessaire.
ɹǝsn *sıɹɐlos*
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager