Microsoft vient de passer son PowerShell en open source, annonçant dans la foulée une arrivée prochaine sur Linux et macOS. La décision concerne aussi bien le langage de script que le shell lui-même.
Microsoft continue d’avancer sur le terrain de l’open source, en ouvrant aux yeux de tous le code d’un nombre croissant de produits ayant surtout trait au développement. Les cas les plus connus sont l’environnement .NET, la machine virtuelle JavaScript Chakra et l’environnement de développement intégré Visual Studio Code.
PowerShell passe sous licence open source
Le nouveau venu est PowerShell, qui concerne davantage les utilisateurs avancés et administrateurs réseau que les développeurs. Il s’agit d’un shell fourni apparu en 2009, initialement pour s’installer sur Windows XP et Vista. Avec Windows 7, il est devenu pleinement intégré et reste donc l’un des composants standards du système depuis. Il fournit une interface en ligne de commande permettant d’exécuter notamment des scripts, avec un langage propre.
PowerShell est bâti sur l’environnement .NET. Or, cet environnement est devenu en bonne partie open source (licence MIT) et a donné lieu récemment à la première version finale de .NET Core. Conséquence, PowerShell suit le mouvement. L’intégralité du code source est désormais disponible sur GitHub, en licence MIT encore une fois. Les développeurs peuvent donc y plonger et en faire à peu près ce qu’ils veulent.
Des préversions pour Linux et macOS
Outre le fait d’augmenter l’aspect communautaire autour de PowerShell, Microsoft espère bien récolter des avis, critiques, contributions et autres pull requests. Les bénéfices espérés sont évidemment toujours les mêmes : attirer le regard et diffuser l’utilisation de l’outil. Ce PowerShell open source s’appuie sur .NET Core, lui permettant d’être proposé sur Linux et macOS.
Pour ne pas laisser les développeurs compiler par eux-mêmes les sources, l’éditeur fournit plusieurs téléchargements. Il ne s’agit pour l’instant que d’une version alpha, donc clairement un matériel brut comportant un nombre potentiellement élevé de bugs. Cette préversion vient de la branche 6.0 de développement et est disponible sous forme de paquet DEB pour les versions 14.04 ou 16.04 d’Ubuntu, et comme paquet RPM pour CentOS 7.1. Côté macOS, l’alpha est prévue pour Yosemite (10.11). Les instructions d’installation sont disponibles dans le README sur GitHub.
Une longue liste de travaux prévus
Puisqu’il s’agit d’un nouveau projet, il existe déjà une longue liste de travaux prévus. En premier lieu, une parité avec .NET Core sur le support des autres distributions Linux. Il n’est pas rare qu’une première ébauche ne propose que quelques paquets, mais on imagine que des systèmes connus comme Fedora, Linux Mint ou OpenSuse devraient être de la partie dans les mois qui viennent. Microsoft prévoit en outre d’ajouter la possibilité d’écrire des Cmdlets en Python et d’autres langages de scripts.
La participation au code de PowerShell ne réclame pas obligatoirement Visual Studio. Microsoft met ainsi en place les PowerShell Editor Services, qui permettent d’intégrer des fonctionnalités à certains éditeurs, pour « une expérience de développement cohérente et robuste sur PowerShell ». Actions de navigation, IntelliSense, analyse sémantique temps-réel, Debugging Service ou encore possibilité d’écrire des fonctionnalités supplémentaires sont au programme. Par ailleurs, le PowerShell Remoting Protocol sera modifié pour pouvoir utiliser OpenSSH. Les utilisateurs auront donc le choix entre SSH et le classique WINRM (Windows Remote Management).
Une surprise prévue la semaine prochaine
Il est à noter que même si l’annonce est significative, Microsoft en aurait une autre, plus importante, en réserve. C’est la réaction du responsable Carmen Crincoli sur Twitter, qui s’étonnait de la surprise générée par l’annonce sur PowerShell. Les pistes ne manquent pas, mais certaines hypothèses retiennent l’attention, comme EdgeHTML (moteur de rendu d’Edge), WPF ou encore UWP.
En attendant, ceux qui s’intéressent au nouveau PowerShell open source pourront utiliser les liens suivants :
- Annonce complète
- Dépôt GitHub de PowerShell
- Instructions d'installation
- PowerShell Editor Services
- Problèmes connus
Commentaires (159)
#1
Mais sur GNU/Linux y’a déjà un shell, pas trop d’intérêt…
#2
Le choix n’en a jamais eu
#3
C’est impressionnant le virage à 180° pris par Microsoft depuis plusieurs années.
Ils sont passés d’une logique avec toute leur technologie vue uniquement comme exécutable sur leurs systèmes à une dualité. Il va y avoir les produits Microsoft (Consummer and Enterprise) visible sur de nombreuses plateformes et les systèmes Microsoft présent à côté.
#4
#5
J’vois plutôt ça comme un truc chiant à installer encore.
" />
#6
Les deux ne sont pas comparables, l’un est clairement orienté objet dans son fonctionnement.
Pour l’instant, il n’y a que des snap-in ouvert aux produits Microsoft (à peu de chose près), mais si dans le futur tu as des équivalents définies pour des plateformes hébergées sur des plateformes UNIX, ça peut être sympa.
Edit : Bon, je gère pas de WAMP ou de Tomcat sous Windows donc j’avais jamais regardé mais des extensions pour Apache, MySQL et Tomcat existent déjà en Powershell.
#7
Parce que Microsoft te met le couteau sous la gorge ?
Si tu n’en as pas besoin, tu ne l’installes pas et puis c’est tout.
#8
Si ça se répand, j’aurais pas vraiment le choix
#9
Je ne saisi pas la différence l’importance qu’il peut y avoir entre le shell Windows et le shell de Linux
#10
Il est à noter que même si l’annonce est significative, Microsoft aurait en réserve une annonce plus importante en réserve.
Le bouton “Démarrer” pour arrêter ?
Je viens de découvrir avec tristesse qu’il n’était plus présent sous W10
#11
Beau ça ! On va arriver à de plus en plus d’inter-portabilité concret entre les différents types d’OS.
#12
Si tu gères aucun système Microsoft et que tu as pas envie de passer sur Powershell, je vois pas trop l’obligation ? Même si ça devient répandu, tu auras toujours la possibilité de faire comme tu fais maintenant.
Je vois plus ça comme une possibilité de gestion unifiée d’environnement mixte de puis une plateforme Microsoft (arrivée du Bash sous Windows) ou depuis une plateforme Unix (arrivée de Powershell sous UNIX). Possibilité, pas obligation.
#13
Il manquerait plus que Microsoft intègre uwp dans linux, macos et android et la c’est a se demander si Microsoft n’a pas pris un coup ou si il compte draguer le libre pour mieux l’enfermer dans son monde ?
Je vois ça d’un bon œil mais j’ai un mauvais presentiment pour l’avenir du logiciel et du libre …
#14
Ca commence à faire quelques temps qu’ils ont adopté cette stratégie. Je me demande s’ils ont vraiment réussi à attirer des contributions sur leurs produits. Ils ont un mode de fonctionnement à la Google : développement behind closed doors, code dump à chaque version, pas d’accès à la branche de développement, pas de mailing list publique, signature d’un Contributor Licence Agreement obligatoire pour contribuer, etc…
A part l’intégration de Mono à .NET Core (Mono qui a été racheté par Microsoft…), est-ce qu’ils ont vraiment eu des contributions majeures de la part de la communauté ?
#15
Ca fait depuis Windows Vista que ce bouton ne s’appelle plus démarrer je crois. :p
Ou alors j’ai mal compris ce que tu voulais dire. ^^”
#16
L’importance dépend de ton utilisation.
La différence entre les deux est fondamentalement architecturale. L’un à une vision beaucoup plus basée sur un concept d’Objet et de classe d’extension.
A conception équivalent, faudrait comparer le Shell Linux avec CMD sous Windows (et là, jeu set et match pour le shell Linux), Powershell est différent dans sa conception.
#17
Ou alors Microsoft compte abandonner Windows pour passer à un système client sous Linux afin de diminuer le cout de la r&d OS et se “limiter” aux applications et aux services : voie sur laquelle il est depuis plusieurs années maintenant.
Ce n’est pas si impossible en réalité, même si peu probable.
#18
Merci, ça m’intriguais
#19
Ce sera utile pour les grosses structures je pense.
#20
Ou une fragmentation complète de l’entreprise un peu à la Google qui devient Alphabet.
Microsoft Corp
#21
A partir de l’instant où tu as un environnement mixte en fait.
Si tu es sur un environnement Microsoft, tu vas te retouver avec la possibilté d’héberger des applis UNIX-based dans des dockers et de les gérer soit via le bash, soit via Powershell.
Si tu es sur un environnement Unix, tu as te retrouver avec la possibilité d’héberger des applis Microsoft et de les gérer avec bash ou avec Powershell.
Ce type de nouvelle est pas tellement dangereuse pour UNIX, c’est même un avantage pour eux. Ceux qui doivent avoir mal au derche, c’est Oracle avec Java dont l’universalité comme gros argument différenciateur est entrain de disparaître.
#22
Euh… Tu appuies sur le bouton Windows (en bas à gauche, le truc qui a un drapeau qui forme le logo Windows quoi), et juste au dessus de ce bouton, dans le menu, tu as un autre symbole qui signifie On/Off depuis 60 ans.
#23
Bah quand je veux utiliser powershell, je me connecte sur le serveur en bureau à distance.
" />
#24
Il me semble que Microsoft est en guerre contre oracle, nan? En tout cas ils ont l’air de vouloir le couler…
#25
#26
#27
J’ai jamais essayé mais il y a toujours RDP en installtion minimale ? (core)
" />
Et puis Powershell peut se connecter “à distance” sur des services : pour automatiser des tâches, pour du monitoring etc. c’est plus simple de se passer de RDP
#28
Je suis pas un expert en powershell, ni en shell en général, je sais que dans ma boite on a qu’un AD, DNS, Exchange et FTP sous Windows Server,le reste que du GNU/Linux et quand on a besoin de faire un truc on se co en RDP .
" />
#29
@wpayen
" />
“First they ignore you, then they laugh at you, then they fight you, then you win”
#30
C’est toujours un bouton “Démarrer” sur Windows 7 hein, ça a pas changé ça, ils l’ont juste masqué par une icône circulaire ^^
#31
.NET qui arrive sur UNIX là ou Java était en chasse gardée.
MSSQL qui arrive sur UNIX
MSSQL qui pond un nouveau modèle relationnel qui se rapproche d’Oracle DB
Avec les casseroles de licensing qu’Oracle a au cul, je serai pas confiant perso.
#32
Plus depuis windows server 2012, un bon sysadmin windows server passe par PowerShell maintenant.
#33
#34
L’avantage de passer par Powershell est la limitation de session utilisateur posée sur les serveurs applicatifs (gain d’espace) et la réduction du parasitage de ressource par des sessions utilisateurs (gain de performance).
Le premier que je vois loggué sur mes environnements SharePoint, je lui colle une mandale.
#35
Ba du coup je vois pas la différence dans windows 10 (le bouton est juste devenu carré :p).
#36
#37
Tu veux dire que même chez MS ils se sont rendu compte que Linux c’est l’avenir et que Windows n’en a plus aucun d’avenir ?
" />
" />) histoire d’assurer la compatibilité avec l’existant tant qu’elle est nécessaire et se concentrer sur ses produits “bankables” comme Office.
" />
Plus sérieusement même si c’est hautement improbable ce serait vraiment pas mal d’avoir Windows comme “simple” surcouche graphique d’un système Linux standard (un peu comme OSX avec BSD) histoire d’homogénéiser la gestion des parcs.
Au lieu de dépenser des fortunes pour développer et maintenir un(voir des) OS complet MS pourrait se contenter de devenir contributeur privilégié de Wine (eux n’ont pas besoin de reverse engineering pour savoir qui fait/sert à quoi
Bon comme dans la pub “oui je sais je rêve”
#38
#39
#40
#41
#42
Ils veulent pas porter tous les outils .NET Core sur les systèmes Unix, pour ensuite permettre le déploiement des applications .NET, pour après rendre compatible UWP sur Linux, mettre en place un store, et enfin utiliser ce moyen comme cheval de troie pour rendre dispo les UWP sur Android ?
" />
Bien sûr sur du très long terme.
#43
#44
#45
#46
Oui enfin on est plus proche d’une hypothétique ouverture du noyau NT qu’un passage de Windows au noyau Linux…
#47
“Allez, la semaine prochaine, Windows”
" />
Ou DirectX, peut être.
#48
Pas forcément mauvais”, entre bon et mauvais il y encore le “normal” au millieu
" />
Aux techdays tu le vois dans les conférences un poil touchy où tu as l’auditeur qui demande “si je vous dis administration windows server, vous me dites” (et là tu as même pas 10% du public qui gueule en cœur “PowerShell”)
#49
#50
Je suis encore en formation, pour ça que je suis nul.
" />
#51
#52
#53
#54
Je te laisse regarder par toi même :)
https://github.com/Microsoft
#55
C’est pas très gentils ça.
" />
#56
C’est quoi, j’ai trouvé ça sur wiki.
Je me doute que c’est pas Ecole Espagnol d’Equitation…
#57
#58
Anéfé
" />
Pour ça que je disais que c’est pas comparable.
Le shell Linux est comparable à CMD (où il lui met une patée au passage)
#59
Pourquoi il font pas carrément une distrib d’ailleurs ?
" />
Ms-Linux ça aurait de la gueule quand même
#60
#61
#62
#63
Vivement le passage en open source de cmd.exe.
" />
#64
Direct x opensource ?
#65
Sur Windows 10 faut que je regarde, mais je pense pas qu’il y est du changement, il doit toujours être identifié dans Windows comme un bouton démarrer.
De toute façon je vois pas l’intérêt d’un changement du bouton qui sert de menu, c’est le truc de base commun à l’ensemble des os desktop, donc osef au final :)
#66
Sinon alt+F4 sur le bureau, c’est aussi pratique.
#67
Sérieusement j’ai jamais compris l’utilité de ce truc là par rapport à un Wine qui s’améliore de plus en plus niveau stabilité et compatibilité et qui lui a l’avantage d’avoir un Linux complet et fonctionnel derrière.
De mon point de vue ReactOS c’est juste du gaspillage de ressources et les mecs qui bossent dessus emploieraient leur temps de façon bien plus pertinente en contribuant à Wine (si ça n’est pas déja le cas, j’avoue ne pas avoir été regarder)
#68
Microsoft Bob version HoloLens en Open Source.
#69
C’est ma blague ca
" />
http://www.nextinpact.com/news/101006-microsoft-diffusera-holographic-sur-tous-p…
#70
C’est une blague opensource
http://www.nextinpact.com/news/100886-autonomie-windows-10-recommande-edge-quand…
#71
Le tweet ne mentionne pas du tout la semaine prochaine pour la prochaine mise en open source d’un produit Microsoft.
#72
Exact.
Et vu que le mecs bosse dans le storage, je dirais un passage en licence MIT de NTFS et un support d’EXT dans Windows.
#73
Intéressant. Perso, j’ai voulu regarder un peu PowerShell, mais ça manque cruellement de petit tuto sur internet, on se retrouve souvent avec un énorme cours à ingurgiter.
En soit, PowerShell est intéressant, il semble plus adapter que la plupart des shell pour faire des scripts avec un fort besoin de programmation.
Ensuite, c’est un langage objet, le retour des cmdlet étant des objets, un programme peut retourner en ensemble de valeur (et au passage simplifie le parsing du coup, pas besoin de passer sa vie à faire du “cut”)
Enfin, le langage suit des normes de nommage pour les cmdletet même les paramètres. Ca permet grandement de simplifier la programmation.
#74
J’utilise installé sur la distrib.
" />
Je maitrise déjà pas à fond le shell…
#75
#76
Le Jbsh aussi (Jason Bourne Shell).
C’est pas fameux, désolé.
#77
J’avais pourtant mis un smiley ironique… Apparemment ce n’est pas suffisant.
#78
#79
La sortie, c’est par la ———–>
" />
#80
Bash, fish, zsh et j’en passe, le choix a toujours été la
#81
Il me semble que la plupart de ceux que j’ai cité sont installés de base dans la majorité des distributions.
Cependant, le shell par défaut est une variable associé à ton compte. Tu as de grande chance que ce soit le Bash (/bin/bash) dans ton cas qui est très proche du Shell (/bin/sh) au point que les 2 sont difficiles à différencier Bash étant principalement une extension du Shell.
J’avoue ne connaitre aussi que le bash/shell.
#82
J’utilise celui de Debian.
#83
Tu peux taper
echo $0
dans un terminal pour savoir quel shell tu utilises par défaut. De grandes chances que ce soit Bash en effet si tu as rien changé.
#84
Yes, c’est bash
#85
#86
#87
Le smiley qui s’incline pour l’ironie. OK.
#88
donc bash par défaut.
Celui ci “s’invoque” dans un script en mettant à la première ligne “#!/bin/bash”.
Au passage petite astuce, si tu mets “#!/usr/bin/env python” à la place, le script sera automatiquement exécuté avec l’interpréteur python sans avoir besoin de faire appel à celui-ci dans la ligne de commande (il faut juste rendre executable ton fichier). Cela marche pour toute sorte de langage script : “#!/usr/bin/env ruby” pour ruby, “#!/usr/bin/env perl” pour perl…
(ouai, ça me faisait chier d’écrire “python +nom du script” à chaque fois)
#89
#90
Non, l’argument pour ça, c’est “–torture” (avec différente option pour les détail voir la doc)
#91
Pour l’instant je suis sur W10, j’attendais la MAJ 1607 pour pas niquer mon dualboot, faut que je le réinstalle, Debian Stretch a du pas mal changer.
#92
#93
Du mal a voir si t’as compris la réponse de Vincent et que donc, tu la soutiens par l’exemple ou si au contraire, t’as pas compris
" />
#94
#95