Effectivement mais il faudrait plutôt comparer bash avec PowerShell pour faire une comparaison raisonnable.cmd, c'est vraiment le truc d'un autre âge.
Effectivement mais il faudrait plutôt comparer bash avec PowerShell pour faire une comparaison raisonnable.cmd, c'est vraiment le truc d'un autre âge.
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Consultez nos FAQ : Windows, Linux, Virtualisation
OK pour les dév. Je n'y connaît rien.
Mais des cmd comme "net" restent très puissantes pour les tech de support.
Les tech sont heureux de trouver intactes des commandes comme winrm ou sc sans que ça change tout les trois ans ;-)
Je ne sais si tu connais webmin. Ca peut t'aider.
[/HS]
Windows 10 : la première build avec le support du Shell Unix Bash est disponible
pour les testeurs du programme Windows Insider
Build 2016, la conférence annuelle de Microsoft dédiée aux développeurs s’est déroulée la semaine dernière et a livré une série d’annonces intéressantes. Parmi celles-ci, le support de Bash dans Windows 10 était l’une des plus surprenantes, mais également des plus appréciées par les développeurs. Pour rappel, Bash (l’acronyme de Bourne Again Shell) est un interpréteur de ligne de commande de type script et le Shell Unix du projet GNU.
Comme Microsoft l’a expliqué, il ne s’agit ni d’une compilation croisée ni d’une machine virtuelle qui permettra d’exécuter l’interpréteur de ligne de commande sous Windows 10. L’exécution de Bash sous Windows 10 sera native, et cela grâce à un partenariat avec Canonical qui a permis la création d'un sous-système dédié, Windows Subsystem for Linux (WSL), capable d’exécuter des binaires Linux. WSL a été discrètement débarqué dans la build 14251 de Windows 10. « La résultante est qu’il vous est désormais possible d’exécuter du Bash natif Ubuntu sur Windows », a annoncé Microsoft lors de sa conférence.
À peine une semaine après l’annonce, les développeurs membres du programme Windows Insider pourront déjà commencer à tester l’interpréteur de ligne de commande, dont le support vient de débarquer dans une nouvelle build de l’OS. En effet, dans un billet de blog dédié à la sortie de la build 14316, Microsoft a annoncé hier que « vous pouvez exécuter Bash en mode natif sous Windows comme annoncé la semaine dernière à la Build 2016 ». La société fournit également les instructions pour installer l’interpréteur de ligne commande sous Windows 10.
Toutefois, avant de se lancer, il est important de rappeler quelques précisions fournies la semaine dernière par Mike Harsh de Microsoft :
- tout d’abord, c’est la première fois que cet outil est proposé (et est catégorisé « bêta » pour cette raison) : nous savons qu’il y aura des choses qui ne fonctionneront pas comme vous vous y attendiez. N’espérez pas voir des scripts Bash qui vont fonctionner à la perfection. Mais essayer cette fonctionnalité nous permet de savoir ce sur quoi nous avons besoin de travailler afin de l’améliorer ;
- ensuite, bien que vous serez en mesure d’exécuter du Bash en natif ainsi que plusieurs lignes de commande Linux sur Windows, il est important de garder à l’esprit que c’est une boîte à outils développeurs qui a été pensée pour vous aider à écrire et concevoir vos codes pour vos scénarios et plateformes. Il ne s’agit pas là d’une plateforme serveur sur laquelle vous pourrez héberger vos sites, exécuter des infrastructures serveur, etc. ;
- enfin, rappelez-vous que Bash et les outils Linux ne peuvent pas interagir avec les applications et outils Windows. Alors vous ne serez pas en mesure de lancer Notepad depuis Bash ou de lancer Ruby sur Bash depuis PowerShell.
Si le Shell Bash ne sera pour l'instant disponible que pour les Windows Insiders, la nouvelle fonctionnalité pourrait débarquer chez tout le monde l’été prochain, avec la mise à jour anniversaire de Windows 10.
Source : Microsoft
Et vous ?
Qu’en pensez-vous ?
Voir aussi :
Microsoft apporte le Shell Unix Bash à Windows 10, le résultat d'une collaboration avec Canonical
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
Ils ont donc réellement implémenté un nouveau subsystem ! Faut savoir qu'à la base, NT dispose de 3 sous-systèmes : Win32 (avec option GUI ou console), OS/2, et... POSIX. Un sous-système est en quelque sorte une API user mode qui s'interface directement avec le kernel. C'est vraiment un environnement d'exécution à part, "natif", au lieu d'un couche supplémentaire à la Cygwin implémentée au dessus de Win32. Là, il n'y a pas de Win32 du tout. Du coup il devrait y avoir un respect de la casse dans les noms de fichiers, du fork de process (que le kernel supporte)...
L’existence du sous système OS/2, c'est lié à l'histoire de NT qui était à l'origine un projet pour remplacer l'OS/2 16 bits d'IBM (=> OS/2 NT). POSIX 1, il me semble que c'est parce que le DoD demandait cela comme condition d'acceptation d'un OS dans leur administration. Ces deux sous systèmes ont été supprimés avec Windows XP... Qui aurait cru que cette "fonctionnalité" allait refaire surface !
Mais là où je me pose une question, c'est que normalement, il va y avoir un nouveau flag spécifique de créé au niveau du format exécutable (PE Header). Et donc gcc & clang (enfin leur linker plus précisément) vont devoir être patchés pour savoir cibler ce sous-système. Je sais pas comment ils vont gérer cela de façon la plus transparente possible (si on veut faire des compilations).
Il ne s'agit pas de binaires classiques Windows (PE) mais de binaires Linux ELF, crées par le gcc natif d'Ubuntu, puisqu'on installe directement un userland Ubuntu.
Le sous système POSIX renaît donc sous la forme d'un sous système Gnu/Windows...
Faudra voir à l'usage. ça fait longtemps que j'avais en grande partie résolu le problème en optant pour tcl/tk (ActiveTcl) qui avait l'avantage d'être multiplateforme Linux/Mac/Windows/Solaris/... depuis le milieu des années 1990 et de proposer un mode de scripting ainsi qu'un mode console pour toutes les plateformes.
Windows est devenu «*case-sensitive » ?![]()
Reste à se débarrasser de la couche Windows
Plus sérieusement, c'est intéressant sur le principe, mais je ne vois pas trop d’intérêt à l'usage. Linux c'est les scripts Bash, Windows c'est PowerShell, vbs. Chacun son identité. Ce que l'on fait avec l'un peut être fait avec l'autre dans les grandes lignes.
Peut-être pour Docker.
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Consultez nos FAQ : Windows, Linux, Virtualisation
A mon avis, l'utilisateur trouvera beaucoup trop compliqué de faire touche démarrer puis de taper bash afin d'y entrer une ligne de PATH pour enfin pouvoir lancer firefox& et accéder à la page de developpez.net. Je pense, après je peux me tromper
Et inversement : de bash vers Powershell/vbs.
Par contre, un script lié à une belle icône ( or whatelse ) implémentant la fonctionnalité, ce sera transparent et il sera donc partant.
Dans le même principe
Avec, entre autre, je pense, l'avantage au niveau securité de l'isolation d'environnement .![]()
Ca veut dire quoi?
Que l’on pourra déployer un serveur DNS pour 0€ depuis un W10 pro?
Non.
Que ma boite pourra s'affranchir de ExceedOnDemand pour accéder à des serveurs de calculs fonctionnant sous Linux?
Non.
Que MS va porter la suite Office vers le manchot? Incitant Oracle à porter EssBase/Smartview vers une destinée ornithologique?
Non.
C'est sympa de contribuer au noyau concurrent pour mieux l’intégrer dans son nuage... Avec l’appui de Cannonical.
Mais Linux reste Linux.
Je me suis dit "formidable !", mais en y réfléchissant j'en reviens.
C'est con. L'intérêt n°1 de Bash sur Windows est là : avoir des scripts systèmes multi-plateformes. Du coup autant garder des scripts créés dans des technos multi-plateformes, genre Python. Bash ne peut pas remplacer Batch donc peu d'intérêt au final. Circulez il n'y a rien à voir et gardez vos scripts Python (ou Perl, Ruby, Node.js, PHP, ou autre) pour vos tâches systèmes.
Pour le reste c'est bien aussi, mais ça reste un WINE inversé. Rien ne valant une configuration proche de la machine, les devs voulant / devant développer sous Linux resteront sous Linux. Ubuntu dans Windows (pas d'humour grivois et sodomite sur le sujet ? Les trolls ne sont plus ce qu'ils étaient.) est une alternative au dual-boot, mais pour bien tester rien ne vaudra la vraie navette entre le manchot et la fenêtre. Quelqu'un qui développe pour Windows ne va pas dire que ça marche sur Windows car ça marche sur Linux avec WINE. L'inverse ne peut donc qu'être tout aussi vrai.
Même avec les AAA, ce n'est pas le gaming sous Linux qui changera cela. Le problème du joueur PC est que sa ludothèque ne comporte quasiment que des jeux ne tournant que sur Windows. Passer sous Linux signifie donc faire le deuil de ces jeux là, ce qui n'est pas un bon point. Pire, les jeux qui sortent sur Linux sortent aussi sous Windows. Linux n'a pas encore de jeux en exclu justifiant le passage au manchot pour jouer. VALVe n'a pas (encore ?) sorti de Half-Life / Portal / Left 4 Dead / Team Fortress 3 en exclusivité Steam OS. Bref autant rester sur Windows. Les jeux du passé en plus des jeux du futur (dispos partout). Windows 2 - Linux 1, victoire de la fenêtre.
Tu as la virtualisation pour ça : un système dans une fenêtre d'un autre système, et valable dans les deux sens (Windows inrtégrant Linux ou Linux intégrant Windows).une alternative au dual-boot, mais pour bien tester rien ne vaudra la vraie navette entre le manchot et la fenêtre.
Non car c'est juste un interpréteur de commande.ça reste un WINE inversé
Et ce que fais bash, si cmd ne peux pas le faire PowerShell le peut, du moins je pense. Et sinon, comme tu le disais air-dex, il y a Python et autres, attention cependant à la compatibilité des bibliothèques externes.
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Consultez nos FAQ : Windows, Linux, Virtualisation
Pas faux. Après ça reste deux OS distincts avec les problématiques de circulation de données entre les 2 (ou alors je ne suis pas asez câlé sur ce sujet). Tandis qu'avec un dual boot tu peux toujours te démerder pour avoir des partitions pouvant être montées sur les 2 OS (au pire Linux lit nativement la partition NTFS avec Windows dessus).
L'intérêt n°1 de bash.exe serait qu'il fasse tout comme sur Linux.
Vous êtes sure que se n'est pas parce que l'ajout de se "truc" ne rajoute pas de faille de sécurité qu'il n'y aurait pas en utilisant un outil Microsoft?
W.H.Q.L. biensur!!!!
Ils ne leurs manque plus qu'une plateforme de téléchargement dédiée aux logiciels W.H.Q.L..
https://forums.geforce.com/default/t...date-3-7-2016/![]()
Dernière modification par MikeRowSoft ; 01/04/2016 à 09h40.
Pas plus pas moins qu'installer n'importe quel logiciel, tout logiciel pouvant comporter des failles. Et je ne vois pas le rapport avec WHQL.Vous êtes sure que se n'est pas parce que l'ajout de se "truc" ne rajoute pas de faille de sécurité qu'il n'y aurait pas en utilisant un outil Microsoft?
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Consultez nos FAQ : Windows, Linux, Virtualisation
Si une carte mère à un firmware évolué (médiateur base niveau) et que le B.I.O.S. est un "grub" sous forme de système embarqué servant de boite à outils (médiateur évolué ex: NTFS en dual boot inaccessible et interface de configuration réseau et droits d'administration local) et que le système d'exploitation se retrouve encapsulé dans la gestion du "grub" évolué, grub évolué restant accessible via une interface overlay, oui à l'époque j'aurais eu un ordinateur presque correct lors de mes études. Proche des consoles de jeux moderne, oui, mais presque correct.
C'est la propagation et la porté de la faille. Être le middleware qui crée une faille en reliant deux bouts qui n'aurait jamais dû se rencontrer.
Dans mon cas pour certains ordinateurs le pilote n'étais pas correct et pour d'autres tous allaient bien. D'un Windows 10 à un autre Windows 10 il y a eu un problème d’intégration d'un même driver. Les bus d'un fabriquant de carte graphique à l'autre sont-ils si différents? Vue que Windows est gestionnaire des adresses affectés au même titre que le B.I.OS..
J'espère que tu comprend mon étonnement.
De plus une telle incohérence (voir image qui suit) leur a été signalé, mais je crois bien qu'elle ne sera jamais résolu à se rythme...
Pièce jointe 205668
Normalement un seul port HDMI physique sur chaqu'une des deux cartes graphiques se retrouve bogués et en affiche deux et cela depuis Windows 7.
J'espère que tu as vérifier qu'un administrateur d'un système dont tu n'es pas d'administrateur ou même utilisateur ne peux modifier ou supprimer tes fichiers!!!
Dernière modification par MikeRowSoft ; 02/04/2016 à 10h20.
Pour l'instant rien sur le store ...
C'est déjà possible avec la cross-compilation ou la virtualisation.Pour être plus clair, vous aurez Ubuntu et Winodws sur la mème machine. Vous pourrez compiler, en natif, des exécutables linux avec GCC depuis ce bash lancé sous Windows. Ces exécutables seront pleinement fonctionnels sur les distributions linux.
Pour résumer : on pourra, sous Windows, faire du dev linux en natif! C'est énorme!!
Çà intègre une libc ? je ne pense pas.Ce bash intégré á Windows fonctionnera en natif. C'est á dire que l'on aura des appplis linux qui vont tourner en natif sous Windows!
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Consultez nos FAQ : Windows, Linux, Virtualisation
Sauf que la ce bash ubuntu tournera en natif sous Windows. Les appels systéme linux seront directement traduit au niveau du noyaux. Pas de Win32, c'est pour cela que les applis Windows ne pourront être lancées depuis ce bash. Il faut voir ce bash comme la possibilité d'avoir Linux sous Windows. Et d'avoir Linux en natif. C'est assez révolutionnaire, non ?
Donc oui pour la libc puisque GCC pourra tourner en natif sous Windows.
EDIT : Par exemple avec ce bash tu pourras obtenir GCC en faisant : apt-get install build-essential. Et les binaires seront directement téléchargés depuis les serveurs Ubuntu, installés sous Windows et pleinement fonctionnels.
RE-EDIT : C'est tellement incroyable de la part de Microsoft que ça a du les faire marrer que d'annoncer cette nouvelle fonctionnalité la veille d'un premier avril.
RE-RE-EDIT : Ou alors c'est vraiment un poisson d'avril, on le saura très vite.
Partager