Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Microsoft brengt PowerShell Core 6.0 uit voor Windows, macOS en Linux

Microsoft maakt de stabiele versie van zijn crossplatformversie van PowerShell breed beschikbaar. PowerShell Core 6.0, zoals de versie heet, is opensourcesoftware die niet alleen te gebruiken is op Windows, maar ook op macOS en Linux.

PowerShellWie de laatste versie van PowerShell Core niet als update binnenkreeg, kan deze voor Windows en voor macOS en Linux handmatig binnenhalen. Microsoft waarschuwt dat er een probleem is op Linux, waarbij de tool niet zal updaten, omdat packagemanagers denken dat powershell-6.0.0 een eerdere versie is dan powershell-6.0.0-rc2. Het bedrijf werkt eraan om dit op te lossen.

PowerShell Core 6.0 is een doorontwikkeling van PowerShell, die alleen voor Windows beschikbaar was en waarvan de releasecyclus eindigt bij versie 5.1. De tool krijgt alleen nog fixes voor kritieke bugs. PowerShell is gebaseerd op .Net, terwijl PowerShell Core op .Net Core gebaseerd is en daarmee crossplatform kan draaien.

Het betekent wel dat sommige functies, zoals Workflows en Snap-ins, ontbreken in de nieuwe versie. Volgens Microsoft komen enkele functies wellicht terug, maar veel niet. Microsoft ondersteunt PowerShell Core op Windows 7, 8.1 en 10, Windows Server 2008 R2, 2012 R2 en 2016, Ubuntu 14.04, 16.04 en 17.04, Debian 8.7+ en 9, CentOS 7, RHEL 7, OpenSuse 42.2, Fedora 25 en 26 en macOS 10.12 en latere versies. Op Arch Linux, Kali Linux en AppImage, Windows op ARM en Raspbian werkt de tool ook, maar op deze platforms is er nog geen officiële ondersteuning.

 

Door

Nieuwscoördinator

88 Linkedin Google+

Submitter: NoReseth

Reacties (88)

Wijzig sortering
Het betekent wel dat sommige functies, zoals Workflows en Snap-ins, missen in de nieuwe versie.
Ik heb geen ervaring met Snap-ins en Workflows, maar het klinkt nogal zwaar om die zomaar te verwijderen. Doet me denken aan Office for Mac 2008 waarin opeens geen VBA-ondersteuning zat: hele bedrijven leunen op Macro's in Office, je kunt dat niet zomeer stopzetten zoals je een icoontje aanpast of een snelkoppeling veranderd. Hetzelfde lijkt mij gelden voor systeembeheerders die Workflows and Snap-ins gebruiken.
Beetje klok/klepel reactie...
Snap-Ins worden eigenlijk niet meer gemaakt sinds Powershell met V2 de modules introduceerde. Microsoft adviseert ook sinds de komst van PSv2 (2011??) om geen snapins meer te maken vanwege de modules.
En Workflows worden echt niet zoveel gebruikt. Sowieso is het een Windows dingetje.

Ik snap jouw vergelijking met Macro's in Office ook totaal niet, Powershell is een Shell, dit werkt echt totaal anders als een GUI suite zoals Office.
Beetje klok/klepel reactie..
Het is dan ook bedoeld als een vraag naar uitleg. Bedankt dat je die gegeven hebt.
Ik snap jouw vergelijking met Macro's in Office ook totaal niet, Powershell is een Shell, dit werkt echt totaal anders als een GUI suite zoals Office.
Ik snap jouw spelling, grammatica, en zinkbetekenis niet. Macro's in Office zijn geen GUI-suite, macro's zijn een manier om taken te automatiseren. PowerShell is ook geschikt om taken te automatiseren, en even snel op internet zoeken leerde mij dat Snapp-Inns en Workflows daarbij van dienst konden zijn. Vandaar mijn vergelijking: Microsoft trekt zomaar (voor een paar jaar) de stekker uit een feature. Als deze feature zo goed als niet (meer) gebruikt wordt, zoals ik hierboven van @Meekoh begrijp, dan snap ik dat wel. Maar de relevantie van het argument dat Office een GUI heeft en PowerShell niet ontgaat mij volledig.
Er wordt geen stekker uit een feature gehaald, PS5.1 werkt nog gewoon en is voorlopig ook nog gewoon supported.
Snapins (wordt sinds 2011 afgeraden) werken nog gewoon evenals workflows (windows specifiek). De ontwikkeling gaat echter wel alleen door met PS6.

Zelf zit ik vooral nog met de vraag of COM objecten nog wel werken (wat ik vaak gebruik voor bepaalde zaken).
waar ik vooral op zit te wachten is een vereenvoudiging van het OAUTH systeem als je bv met invoke-restmethod / invoke-webrequest werkt om api's aan te spreken... ik geloof da'k daar een tijdje terug iets over gelezen heb dat dit ingebouwd zou worden zodat het authenticaten met api's een pak simpeler wordt gemaakt. (en dan bedoel ik dus vooral op 2way authentication waarbij oauth gebruikt ipv een vaste login + een api-access key die om de x tijd wijzigt of die je constant moet refreshen)
Ooh, dat zou ook wel heerlijk zijn.
Voor de MS API's (Graph etc) heb ik inmiddels wel scripts gebouwd voor oath, maar het was destijds redelijk zoeken om werkend te krijgen (ook de verschillende manieren van je token verkrijgen zorgde ervoor dat niet alles duidelijk was voor mij destijds)
Dat valt wel mee.
Powershell Workflows zijn sowieso een Windows only dingetje op het moment. Ze zijn namelijk gebaseerd op Windows Workflow Foundation wat obviously niet aanwezig is in Linux/OSX.
Het lijkt ook totaal niet op Macro's in office kan ik je vertellen ;)
Ook de Snap-In's zul je niet snel missen denk ik. De meeste dingen worden tegenwoordig in Modules gemaakt ipv Snap-in's
Ik denk dat dat komt doordat die functionaliteit wel in .NET zit, maar niet naar .NET Core geport is.
Onder Windows is Powershell een redelijke alternatief voor de command prompt als Cygwin niet (goed) werkt. Het is echter niet in staat om de pijp te roken tegen de Gnu shell alternatieven. Powershell onder Linux past dus niet in mijn toolset.
PowerShell is een heel ander beestej dan de GNU shell alternatieven waarbij PowerShell zeker ook voordelen heeft. PowerShell geeft je de mogelijkheid om aan de slag te gaan met WMI, COM en .Net objecten op een command line. Bash bijvoorbeeld geeft je geen 1 van die mogelijkheden maar heeft enkel text based input en output.

PowerShell heeft een stijlere leercurve omdat je al heel snel object georienteerd moet leren denken als je er ook maar een iets complexere taak mee wenst uit te voeren waardoor het eigenlijk al bijna een omgeving voor programmeurs lijkt. Maar aan de andere kant heeft een rsync of wget ook een hele hoop mogelijke argumenten die een beginner ook kunnen afschrikken. Je zou dus eigenlijk kunnen zeggen dat je zowel voor een PowerShell als voor een Linux terminal een hoop ervaring en kennis moet hebben om het onderste uit de kan te halen.
Dat je voor een command line interface meer kennis en ervaring nodig hebt dan een menu gestuurde omgeving zijn we het hier denk ik allemaal wel over eens. Als je die kennis en ervaring eenmaal hebt merkt je dat een CLI veel krachtiger is.

Jij geeft een aantal prima voorbeelden van dingen die je met PowerShell kunt doen en die je dan dus ook kunt doen vanuit een Linux of MacOS omgeving, maar uiteindelijk komt het allemaal neer op het beheren van een Microsoft omgeving vanaf een een niet-Microsoft OS. Ik vind dat persoonlijk een beperkte use-case, beheerders zouden naar mijn mening best iets meer een "eat your own dogfood" mentaliteit mogen hebben en dus gewoon de Microsoft gebaseerde kantooromgeving mogen beheren vanaf een Windows machine in het domein, ondersteund door de IT afdeling. Als je binnen je bedrijf eigenlijk alleen werkt met Office 365 en Azure en andere Microsoft cloud producten dan ligt dat natuurlijk anders, maar ik blijf er bij dat de use-case beperkt is.

Iets anders wat ik lees als een veel geprezen eigenschap van PowerShell is dat het object georiënteerd is. Eigenlijk ligt dit in het verlengde van wat ik hierboven al benoem, namelijk dat dit vooral voordelen heeft in een Windows-gebaseerde omgeving. Er is een reden dat alle shells op Unix-achtige OS-en file en character gebaseerd zijn, het hele OS is namelijk file gebaseerd. Ik vraag me dan ook echt af welke voordelen het gebruik van PowerShell op Linux en MacOS heeft op de Linux machine of Mac zelf. Want dat zie ik niet en ik denk dus ook niet dat er veel mensen hun shell op Linux of MacOS zullen vervangen met PowerShell.
Het voordeel van Powershell op Linux is juist zodat Windows beheerders ook Linux/MacOS kunnen beheren zonder eerst in de CLI te hoeven leren.

Daarnaast is "eat your own dogfood" niet echt toepasselijk voor DBA, Sharepoint of Exchange beheerder. Moeten zij een server OS op hun werkplek installeren? De werkplek is ten slotte niet onderdeel van hun expertise en in grote omgevingen zijn ze er niet eens lokaal administrator.
Hoe beheer je dan een Linux machine door middel van PowerShell? Dat werkt dat toch ook op basis van een CLI, alleen is PowerShell dan de shell in plaats van Bash. En meestal roep je voor het daadwerkelijke beheer van een Linux machine toch externe binaries aan via je shell. Als dat in PowerShell ook kan prima, maar dan biedt PowerShell nog steeds geen voordelen ten opzichte van Bash want de command line opties van de Linux binaries veranderen echt niet als je een andere shell gebruikt.

Wat ik bedoel is dat de typen beheerders die jij noemt gewoon een Windows pc op hun bureau moeten hebben die wordt beheerd door de IT afdeling. Uiteraard met voldoende rechten om hun werk te kunnen doen, maar lokaal administrator valt daar inderdaad waarschijnlijk niet onder. Waarschijnlijk hebben ze aan gewone gebruikersrechten genoeg op de PC zelf, op de servers die ze beheren hebben ze uiteraard meer rechten maar ik neem aan dat PowerShell wel een nette voorziening heeft om te authenticeren, zoals je dat via SSH doet met key's. Microsoft kennende werkt het met certificaten. In ieder geval ben ik van mening dat je deze mensen geen Linux machine of een dure Macbook moet geven en dat ze dus ook geen PowerShell op deze OS-en nodig hebben.
Als je die kennis en ervaring eenmaal hebt merkt je dat een CLI veel krachtiger is.
Een command line interface is niet noodzakelijkerwijs krachtiger dan een GUI interface.
Sterker nog, meestal is dat juist niet zo en is een grafische interface veel krachtiger.
Moderne grafische tekstverwerkers zijn bijvoorbeeld veel krachtiger dan command line tekstverwerkers.
LaTeX is niet een tekst verwerker, het is een opmaak taal net als HTML en MarkDown. Al is LaTeX wel heel uitgedreid.

Om LaTeX document te maken kun je zowel een grafische editor gebruiken als een meer cli georienteerde.

Ik vind de CLI erg prettig onder Linux, gebruik dan eigenlijk altijd VI, niet de meest makkelijker editor om te leren. Maar wel bijna op elk Unix system aanwezig.

Voor development gebruik ik het liefst een grafische editor, dat werkt gewoon weg makkelijker en sneller.
Dan stel ik voor om je even in te lezen, zie bijvoorbeeld vi/vim.
Ik heb vroeger geprogrammeerd met vi op een CLI.
Geen haar op mijn hoofd die daar ooit weer naar terug zou willen.
Dan heb je het nooit geleerd, ik zou willen dat ik goed zou zijn in vim.
De meeste grafische interfaces zijn voor een groot gedeelte gebaseerd op commandline:

Noem mij een msWindows programma wat een ikoontje heeft dat geen commandline in de 'shortcut' heeft.

Dat zo'n programma geen opties heeft om zich vanaf de commandline te laten aansturen is een andere zaak, dat heeft veel, zo niet alles, te maken met het programma zelf.
Ik ben het niet eens met je stelling; Een grafische interface is makkelijker vanwege de minder stijle leercurve. Echter is een text verwerker als vim toch vele malen krachtiger als het gaat om daadwerkelijke tekst manipulatie. Opmaak e.d. kan je weer met latex doen.
De kracht van een grafische interface zit niet alleen in tekst manipulatie maar ook in tekst presentatie en in een lagere leercurve voor het gebruik van de features.
Zo kan een grafische interface heel goed tekst presenteren in een veel duidelijkere view dan een CLI dat ooit kan. Als je gaat programmeren in een moderne grafische interface als UltraEdit of zoiets dan zie je die voordelen meteen.
Het voordeel is dat als een tool niet doet wat ik wil ik er snel een kan maken die crossplatform werken dit gelijk weer mee kan nemen in mijn scripts. Ik vind de vergelijking met python dan ook een betere dan die met bash.
Powershell is juist makkelijker op te pakken omdat alle commando's een logische naam hebben. Een klein beetje basiskennis van powershell zelf en het systeem wat je wil beheren is voldoende om scripts van derden te begrijpen. En alle cmdlets werken op dezelfde manier, met tab-completion voor de arguments.

Als ik dat vergelijk met bash waar je moet weten wat die cryptische namen precies betekenen en waar velen andere argumenten gebruiken, zonder tab completion van die argumenten, dan is powershell toch makkelijker te leren.
Laten we even een paar dingen goed definiëren. Ik denk namelijk dat wat jij hier voor het gemak aan duidt als "bash" daar eigenlijk helemaal niet onder valt. Veel van de commando's die je onder Linux via de commandline gebruikt zijn gewoon losse executables, geprogrammeerd door verschillende mensen en dus vaak met verschillende en niet altijd even duidelijke opties. Via een shell, zoals Bash maar er zijn vele anderen, kan je die programma's met elkaar gebruiken door middel van de Unix pipeline. Bash is een uitgebreide shell die je de beschikking geeft over zogenaamde build-ins waarmee je tekst uitvoer kunt geven (echo, printf) of gebruikersinvoer kunt inlezen (read).

De meeste moderne shells zoals Bash beschikken wel degelijk over tab completion. Bovendien is in moderne Linux distributies vaak een package "bash-completion" beschikbaar waarmee je door middel van configuratiefiles tab completion aan Bash kunt toevoegen voor de eerder genoemde externe commando's. Verder zijn er natuurlijk de oude vertrouwde 'man pages' als je wilt weten wat een stuk software voor command line opties heeft.

Ik neem aan dat tab completion vanaf het allereerste begin in het ontwerk van PowerShell zit. Hou er wel rekening mee dat PowerShell een relatief jonge shell is die volledig ontwikkeld en onderhouden wordt door Microsoft. Er ontstaat als het goed is dus geen versplintering zoals je dat in de open source wereld nog wel eens tegen komt. Dat maakt het logisch dat alle namen voor commando's en opties nu nog uniform en duidelijk zijn, maar het is niet gezegd dat dat altijd zo zal blijven. En stel dat je in PowerShell een extern programma wilt gebruiken, bijvoorbeeld Putty.exe om een ssh verbinding te maken (ja, Putty werkt prima vanaf een CLI). Volgens mij heb je dan ook in PowerShell niet automatisch tab completion, dat zal iemand dan toch echt moeten toevoegen. En die opties voldoen waarschijnlijk niet aan de conventies die momenteel binnen PowerShell gelden voor naamgeving.

[Reactie gewijzigd door rbr320 op 12 januari 2018 15:22]

Powershell is juist makkelijker op te pakken omdat alle commando's een logische naam hebben. Een klein beetje basiskennis van powershell zelf en het systeem wat je wil beheren is voldoende om scripts van derden te begrijpen. En alle cmdlets werken op dezelfde manier, met tab-completion voor de arguments.
Zucht ... alsof er niet genoeg beheerders zijn die niet weten dat gc een alias is voor get-content. Als je op Linux man pages deftig leert *pagen* dan ben je er in mijn opinie ook.
Alsof powershell geen onlogische benamingen heeft. Ik maak even een vergelijking hieronder door de inhoud van een directory te tonen:

Powershell: Get-ChildItem C:\Directory
Bash: ls /directory

Ik vind "Get-ChildItem" echt niet voor de hand liggend als naamgeving voor het tonen van directory inhoud (afgezien van het feit dat "dir" als alias ook werkt in ps).

Met een beetje basiskennis en nader uitzoekwerk kom je met beide systemen gewoon wel waar je moet wezen maar ik zie echt niet waarom Powershell beter is dan Bash. Persoonlijk had ik liever gezien dat Microsoft een systeem bedacht had dat gelijkenissen heeft met hetgeen we in linux/unix al >30 jaar gebruiken, in plaats daarvan hebben we weer een scriptingtaaltje erbij dat qua syntax helemaal nergens op lijkt en voor zover ik kan zien geen bijzondere meerwaarde bied dan andere volwaardige programmeertalen.

tl;dr powershell is rare shit en bied niks nieuws naar mijn mening.
Get-ChildItem is ook niet specifiek voor directories bedoeld.
Get-ChildItem -path hklm:\software... werkt bijv. ook om regkeys te vinden/zoeken
of
Get-ChildItem -path Cert:\* dito in je cert. store


De naamgeving zelf komt voor uit een conventie get-iets, set-iets, remove-iets
Door deze opgelegde beperking heb je niet zoveel meer opties dan ChildItem wat de lading dekt. Maar ik begrijp dat als je gewend bent binnen Linux ls te gebruiken, dat dit even wennen is.

Begrijp me niet verkeerd, zowel bash, als powershell hebben beide hun nut, en in sommige dingen is bash handiger, en in sommige dingen powershell
Ik vind bijv. in Powershell text replacement in een file of string veel simpeler uitgevoerd:
$Variable -replace "text1","text2"
en in bash doe ik dan:
Text="Ik wil pizza"
Replacing="Bier"
Text=${Text//pizza/$Replacing}
Maar in alle eerlijkheid ben ik in geen van beide tegen issues aangelopen die niet op te lossen zijn.

1 argument voor Powershell Core mis ik hier nog: Voor mijn werk doe ik erg veel aan scripting. En het is voor mij i.i.g. erg handig als ik al mijn scripting in 1 taal kan doen
Als ik dus powershell core cross platform kan uitvoeren, kan ik delen van mijn code hergebruiken onder linux..
Als ik powershell zie als commandline dan vergelijk ik het vooral met de vms-commandline: veel te lange commando's, de (oude, cmd-box) alternativen hebben hun voor en nadelen.

Als ik powershell zie als script-taal, dan zie ik dat als een 4-e generatie c.q. object-oriented script taal. Met als 'nadeel' het gekozen groeipad via wmi en .net en zo wat het hele object-oriented zijn onderuit haalt... Gelukkig komt daar met de laatste versies wat verbetering in. Nu de voorbeeld scripts (DrGoogle en zo) op internet nog aanpassen...

Nu ben ik een tijdje uit de unix wereld, maar is daar al een 4-e generatie en/of object-oriented script taal?

Aan de andere kant, powershell is nog niet zo consistent als ik zou willen: Om een gebruiker te selecteren kan je soms uit 4 methodes kiezen, soms maar uit 2.

[Reactie gewijzigd door beerse op 13 januari 2018 21:08]

Mijn opmerking was meer vanuit het optiek van een primair Linux gebruiker. Binnen de Linux ecosysteem zou iets als Perl cli of een van de andere scripting talen een logische uitval zijn voor zo'n toepassing. Wat mijn opmerking natuurlijk achterwege liet is de equivalent van mijn use case voor Cygwin. Het is een van de eerste tools die ik op Windows installeer (icm conemu). De primair Windows gebruiker die op Linux aan de slag moet kan het wel een optie zijn om een bekende interface beschikbaar te hebben.
Mijn gedachte was vanuit een script-taal perspectief: Powershell heeft de intentie/potentie om object-oriented te werken: Het zijn niet alleen strings die in variables zitten, het zijn hele objecten met bijpassende methodes en zo. Zolang netjes powershell gebruikt wordt, werkt dat best aardig, al is het even wennen (net zoals tussen C en C++)
Maar helaas heeft PowerShell, zeker in het begin, nogal wat hulp nodig gehad van wmi en .net en de functies die daaruit gebruikt zijn doorbreken in mijn optiek nogal eens het object-oriented model van powershell.
Daarnaast is mijn huidige ervaring dat powershell niet zo consistent is als ik zou wensen.

Maar nu powershell meer open-source is en meer op andere platformen gebruikt kan worden, hoop ik dat er minder uitstapjes naar andere talen nodig zijn.

Aan de andere kant zie ik microsoft meer en meer richting linux schuiven... het zal mij benieuwen waar dat heen gaat.
En perl met zijn cli is voor de x platform oo taal niet een alternatief?
Perl is toch niet oo...
al moet ik zeggen dat ik na perl 4 er niet echt veel mee bezig ben geweest...
Perl heeft zeker OO ondersteuning in. https://perldoc.perl.org/perlootut.html...

Maargoed, de meer die ik heb gelezen is de doel van de port mij wel duidelijk. MS wilt support op hun Azure platform voor hun Powershell en de sprong om het beschikbaar te maken op de andere Linux platformen met .net core is een kleine. Het is echt niet de bedoeling om de die hard Linux sysadmin/dev/gebruiker overstag te krijgen om hun shell te gebruiken.

De beschikbaarheid gaat vast en zeker een aantal Winmannen een welkome omgeving bieden als zij op Linux aan de slag willen. Net als wat de Linux s/d/g als eerste cygwin (met eventueel conemu) installeert op een Windows machine. Gebruiken van de tools die bekend is, is vaak een eerste keuze, toch?
Wat is nou het verschil tussen Powershell 6.0 en 5.1 op Windows, afgezien van de nieuwe .Net Core?
En heeft het wel nut als je versie 6.0 installeert op Windows?

Vind het wel een goede alternatief, als je veel met Windows en Linux doet, zo hoef je dan niet de hele tijd te wisselen van OS
Het verschil is enorm, teveel om in ieder geval in één post toe te lichten.
Zie het maar zo : .NET Core is een nieuwe versie van .NET (welke cross platform is). Hierbij zijn een heleboel zaken die in de volledige .NET voor Windows zitten niet aanwezig.
Powershell 1 t/m 5 draaien op de volledige .NET framework, PS6 draait op .NET core (dus de cross platform variant).

Zie https://blogs.msdn.micros.../04/introducing-net-core/ voor meer info over .NET core.
Ik mis onderbouwing waar deze software voor gebruikt word, ben een linux/mac gebruiker, waar zou ik powershell op mijn linux bak voor kunnen gebruiken ? Wat voegt het toe voor mijn huidige OS ?

De github page helpt me ook niet echt verder. Heeft iemand hier meer informatie over of ervaring mee ?
PowerShell is een shell met scripting features etc. Ik weet alleen niet hoeveel het echt gebruikt word aangezien Bash zeer populair is op Linux. Het zal dus eerder een smaak kwestie zijn.

Op Windows is het redelijk populair, omdat het heel erg lekker integreerd met allerlei APIs en services van Microsoft.

[Reactie gewijzigd door Laurens-R op 12 januari 2018 12:49]

Het wordt in de IT veelal gebruikt als hulp bij problemen met Exchange (mail) of problemen in het ADDS (domaincontroler) Hierdoor kunnen we met commando's veel problemen opsporen en weer oplossen.

Daarnaast is scripting van belang, tijdstippen, taken, etc. bepaald programma laten uitvoeren en ga zo maar door.
er is veel mogelijk met PS.

Toevoeging aan Linux, nee niet echt. Toolbox in Linux is veel verder dan PS.
Powershell is object georienteerd, dit is niet te vergelijken met bv Bash en een heleboel andere shells en tools welke je op Linux hebt (met uitzondering van bv Pearl enzo).
Zelf doe ik ontzettend veel in Powershell : standaard beheer van AD, Office 365 (Exchange Online, SharePoint etc).
Ik bouw GUIs in Powershell (niet mogelijk in Core op Linux ivm het ontbreken van de assemblies voor een GUI in .NET code), ik heb een simpele WoL tool gemaakt, noem het maar op.

Vrijwel alles wat je in C# kunt doen kun je ook met Powershell doen. De kracht van deze shell ligt eigenlijk bij de integratie met het .NET framework en dus de mogelijkheid om vrijwel alles uit het .NET framework te gebruiken (en als ik daarmee niet verder kom dan gebruik ik Pinvoke binnen Powershell).

Voor Linux zie ik eigenlijk als enige echte meerwaarde momenteel de mogelijkheid om vanaf je Linux bak een Windows server of bv Office 365 te beheren.

Edit : wel weer typisch Microsoft, de AD module van Powershell (de "oude versie") werkt dus niet met PS6 (ik denk ivm het ontbreken van System.DirectoryServices in .NET Core).. Laat dit nou net één van de meest gebruikte modules zijn voor sysadmins..

[Reactie gewijzigd door Killah_Priest op 12 januari 2018 13:37]

Voor Linux zie ik eigenlijk als enige echte meerwaarde momenteel de mogelijkheid om vanaf je Linux bak een Windows server of bv Office 365 te beheren.
Die meerwaarde is nou ook niet erg groot omdat het voorheen allemaal opgevangen werd met zogenaamde bastion servers. In wat grotere omgevingen worden die toch al gebruikt vanwege security: je kunt hiermee namelijk de nodige scheiding aanbrengen (beheertools kunnen alleen bij een beperkte set servers komen). Je zou het ook met een VPN tunnel kunnen doen maar dat houdt dan weer in dat je op 1 machine tunnels naar allerlei omgevingen open hebt staan en dus feitelijk nog met 1 machine overal bij kunt. M.a.w. een fatsoenlijke up to date RDP client voor Mac/Linux zou heel wat meer zoden aan de dijk zetten.

Als je kijkt naar beheer in het Linux domein dan is dat toch vaak een gevalletje van inloggen op de betreffende server en dan daar lokaal je beheer doen of alles middels beheerscripts/tools als Ansible, Chef en Puppet. Ook die hoeven niet per definitie vanaf je eigen machine te worden gedraaid (met iets als Puppet gebeurd dat ook helemaal niet).
Niet helemaal. In een Bash terminal is het niet zo eenvoudig om met objecten te werken, dat kan dan weer wel zeer eenvoudig met PowerShell. Je hebt een andere benadering en het hangt voor een groot stuk af van welke je gewoon bent.
Omdat je een object georienteerde shell wil?
Wil ik dat ? Python en Perl lossen alles op wat je wil op dat vlak.

Het zal vast krachtig zijn, zeker op Windows systemen, daar integreert het mee. Maar als ik naar de naming conventions kijk dan krijg ik al een onbehaaglijk gevoel van het gebruik van PascalCase icm met dashes en case sensitive properties.

- VoorbeeldCase
- Voorbeeld-VoorbeeldCase.
- Get-Help -Name bla

Het zal gewenning zijn maar doet voor mij heel erg a-computer aan.
De naming convention is opzich vrij duidelijk. Het is doorgaans Action-TargetOfAction.
Bijvoorbeeld Start-AzureVM.

Maar opzich is powershell helemaal niet case sensitive, dus start-azurevm werkt even goed.

Ik vind python stukken onlogischer met zijn indent sensitive syntax. Verplichte tabs in plaats van spaces enzo.
ah ok, het is niet case sensitive, de documentatie lijkt dat zo voor te schijven, scheelt heel wat hoofdbrekens.

Python is voor anderen zeer logisch, dat is dan ook een discussie die nergens heen zal gaan ;)
*spaces ipv tabs :9 (PEP8 preferred method), en niet verplicht, als je maar niet mixt.
Deze conventie ActionTarget() wordt ook bij vele andere MS Windows API's gebruikt, bijv. de Win32 CreateFile(). Eerst gewend aan de omgekeerde conventie onder OS/2, TargetAction() heb ik die MS conventie altijd lastiger, rommeliger, gevonden. Als programmeur zoek en gebruik je immers APIs die toepasbaar zijn bij een bepaald object (file, scherm, muis, I/O middel enz). Veel UNIX APIs hadden de conventie Action() omdat de meeste op een file werken.
Case-sensitive properties? In Powershell? Dat ben ik nog niet tegengekomen.
Die zijn er ook niet, tenzij iemand ze in één of andere brakke module heeft ingebakken.
De commando's zijn juist zeer logisch qua opbouw : Verb-Noun.
De Verb is bv Get, Set, Invoke, Create,Write,Test, etc.
De Nouns beschrijven vervolgens weer WAT er gedaan wordt.
Dus bv Get-Item, Set-Item, Add-Item, Invoke-Command etc.

Juist door deze logische opbouw kun je vaak al vrij snel zien wat een commando ongeveer zal doen (en dus ook wel commando je nodig hebt).
Parameters hoef je NIET voluit te schrijven (tenzij een andere parameter er qua naam op lijkt). Tevens kun je voor zowel parameters als voor CMDlets gewoon aliassen aanmaken. Get-ChildItem heeft bv dir en ls als alias.

Het is inderdaad een stukje gewenning, maar wat jij neer hebt gezet klopt niet....
De commando's zijn juist zeer logisch qua opbouw
De Verb is bv Get, Set, Invoke, Create,Write,Test, etc.
De Nouns beschrijven vervolgens weer WAT er gedaan wordt.
Ik vind dit geen heldere uitleg, sorry. Ik denk dat je het woordje "mee" bent vergeten in je noun zin.

Mijn uitleg zou zijn:

Het eerste gedeelte is het werkwoord: dus wat ermee gedaan wordt.

Het tweede gedeelte is het onderwerp: dus waar wat mee gedaan wordt.

Ik weet verder weinig van Powershell, maar dit begrijp ik wel.
Waarom zou je Perl en Python gebruiken en niet een van de twee? En waarom geen Bash? Ieder zijn ding.

Voor de rest is de naamgeving in Powershell juist wel consistent.
Zelf doe ik veel met VMware en deze hebben hier ook een fling voor uitgebracht (PowerCLI Core). Ik beheer hier grotendeels mijn VMware omgeving mee zonder dat ik de webinterface in hoef (wat af en toe best vervelend is) of een Windows VM hoef op te zoeken om even wat snel uit te voeren.

Alleen jammer dat VMware fling niet compatible is met de beta of deze release, hoop dat ze dat wel snel oplossen
Ik zit in het zelfde bootje, zie ook dat de vmware fling lang op zich laat wachten als het om compatibiliteit gaat met powershell...nog niet te spreken over de ondersteuning op linux of macos.
Het is in de afgelopen maanden heel hard gegaan met versies van powershell en ik denk dat ze die ontwikkelingen niet hebben kunnen bijbenen. Ik hoop wel dat nu de release uit is, ze snel zullen gaan werken aan de restpunten. In mijn geval is dat de bekende "VMware.VimAutomation.Vds.Types'. The system cannot find the file specified."
Powershell heeft een andere basis, het is veel meer object oriented dan bash wat meer filebased is. Wat zo weer zijn eigen voordelen opleverd.

Maar het komt voornamelijk neer op voorkeur. Je hebt ook veel Windows beheerders die regelmatig op Linux of OSX werken, dan is het fijn om dezelfde CLI mee te kunnen nemen en gebruiken. MS hoopt natuurlijk ook dat het ook door Linux volk opgepikt wordt.

Op freenode zijn redelijk wat Linux mensen best blij met Powershell core, men schaamt zich er niet meer om als men de voorkeur heeft voor Powershell over Bash (lang niet iedereen, wil geen scheve indruk wekken).
Ik denk dat het doel vooral is om de toepasbaarheid van PowerShell uit te breiden voor de huidige gebruikers.

Met .NET Core kan je je .NET applicaties behalve op Windows ook op Mac/Linux draaien. Het is handig als je dan je bijbehoordende management scripts in PowerShell kan blijven gebruiken.
Zoals velen voor mij al aangeven, Object Oriented vs Plain Text. Voor iemand die al vanaf Powershell 1 een fan is, was het heel irritant om ineens in iets als bash te moeten werken. Al dat gekut met grep dit, textfiletje dat, ik kan er wel mee werken, maar Objecten zijn zoveel relaxter!

Bovendien werk ik in gemengde omgevingen, ik heb collega's die vanaf hun mac eerst naar een windows bak moeten hoppen omdat ze anders niet een service op een windows server kunnen herstarten. Met Powershell op de Mac kan dat gewoon allemaal wel. Of wat dacht je van werken met Azure vanuit een Mac of Linux? Ja er zijn ook wel plugins voor bash e.d. maar Powershell werkt echt het makkelijkst. Vooral als je collega's op een Windows laptop dezelfde code kunnen gebruiken ;)

Kortom vooral in Mixed environments kun je hier heel veel aan hebben. Heb ik Bash op Windows ook niet meer nodig :P
Ik denk dat het grotere plaatje niet gezien wordt.
Het voordeel van deze crossplatformversie plaats je best in de cloud (van microsoft).
Eén scriptingtaal die de 3 grootste OS'en kan aanspreken. (hoewel mac os weinig zal profiteren van de cloud)
3 keer minder werk om dezelfde scripts / azure automation flows te schrijven.

Op basis van devops, automation en CI/CD is dit ook een voordeel.
Integratie van DSC komt vaker voor zoals bij Puppet, Chef, Ansible
DSC gebruiken om je testomgeving op te zetten, unit testing,...
Eigenlijk alles dat steunt op PowerShell in de loop der jaren profiteert hiervan.
Microservices op basis van .net core en asp.net core

Als je kijkt welke kant microsoft de laatste jaren opgaat, dan snap je dat dit volledig in hun strategie ligt.
Ondersteuning van bash & ssh via powershell, nanoserver, Docker containers,...
Ze streven naar de grootst gemeenschappelijke deler.
En ze willen goed genoeg concurreren met AWS

Het zal Microsoft een worst wezen of je Windows server of centos, redhat linux draait in hun cloud.
Het voornaamste is dat je hun cloud gebruikt.

Als je daardoor het gemak van één tool/scripting taal bij aanbiedt.
Zorg je dat veel IT OPS de sprong sneller gaan wagen naar een andere OS of cloudplatform.
Zolang je maar iets vertrouwds hebt dat je al een paar jaren mee werkt, is een stap naar iets nieuws zetten net dat iets makkelijker.

[Reactie gewijzigd door nagasy op 12 januari 2018 14:32]

jij snapt het, dit is inderdaad wat Jeffrey Snover uitlegde bij de introductie van 6.0 op de PowerShell conference in 2017. https://github.com/psconfeu/2017
Een Linux/Mac gebruiker kan hiermee ook Office365 beheren.
Wat mij ideaal lijkt van PowerShell onder linux is dat je ook makkelijk Office 365 kan beheren
Als ze nou ook Office365 voor Linux uitbrengen, dan is het helemaal mooi.
Office 2010 draait nog prima onder wine (in een 32-bit bottle!!), mocht je dat graag willen. Kleine patch aan de DLL’s voor PowerPoint en alles werkt. :) Ben je niet meer veroordeeld tot libre/openo. En qua functies zit er niet zo’n gek groot verschil tussen 2016/365, al is de UI een tikje anders.

[Reactie gewijzigd door WhatsappHack op 12 januari 2018 13:42]

en voor kde waar soms problemen zijn met office windows maximizen/minimizen even een rule toevoegen:
System Settings -> Window Behaviour -> Window Rules -> New
Window Class: Regular Expression: .*\b(winword.exe|excel.exe|powerpnt.exe)\b.*
vink "Match whole window class"
Size & Position
Full screen: Forced No
Ignore Requested Geometry: Forced Yes

[Reactie gewijzigd door GiLuX op 12 januari 2018 13:57]

En hoe zie jij dat voor je? Office 365 is een platform wat bestaat uit een hele zooi clouddiensten en een aantal losse applicaties, waarbij je er ook voor kan kiezen om niet alles af te nemen (je kunt prima Exchange Online hebben zonder een Office client).

De Office client is NIET hetzelfde als Office 365... 365 is zoveel meer (Exchange Online, SharePoint, Skype for Business, PowerBI, Dynamics, Teams, OneDrive for business, staffhub en zo zitten er nog tig tools onder deze cloud dienst).
Dan verkoopt Windows straks niet meer
Als dat net zo gaat als bij Office voor Mac zal dat best wel meevallen. Excel voor Mac heeft bijvoorbeeld geen ondersteuning voor meerdere cores, waar Excel voor Windows dit wel heeft.
package managers denken dat powershell-6.0.0 een eerdere versie is dan powershell-6.0.0-rc2.
Uitbrengen als versie powershell-6.0.1 met als changelog "fix for package managers in Linux" of denk ik te eenvoudig? :+
Omdat het nu een stable release is en geen release candidate.
powershell-6.0.0-rc3 toch zo gedaan
Nee want dat klopt toch niet. Het is geen Release Candidate meer het is een stable release.
Powershell werkt fundamenteel anders dan Linuxalternatieven die genoemd worden, een scripttaal die objectgeoriënteerd is kan heel krachtig zijn
In principe kan je ook bijvoorbeel dlisp als shell gebruiken, daar kan je ook alles mee.

Maar los daarvan ik denk dat het juist voor shells heel interessant is om zo crossplatform te kunnen werken, dus ik juich powershell op alle platforms toe.

[Reactie gewijzigd door begintmeta op 12 januari 2018 13:35]

Ik had gereageerd:
En dan vindt Microsoft het vreemd dat 'iemand' (c.q. de package managers) denkt dat versie 6.0.0 van Powershel nieuwer is dan 6.0.0.rc2 ?
Dat vind ik dan weer vreemd...
Ik vind ook een release candidate versie ouder dan een 6.0.0. (zonder release candidate).


Maar dat staat er dus toch niet. De package manager vinden 6.0.0.rc2 nieuwer dan 6.0.0, dat is inderdaad niet correct.

[Reactie gewijzigd door kh65 op 12 januari 2018 15:57]

Precies andersom: de package managers denken dat 6.0.0 ouder is dan 6.0.0-rc2
Beter lezen:
Microsoft waarschuwt dat er een probleem is op Linux, waarbij de tool niet zal updaten, omdat package managers denken dat powershell-6.0.0 een eerdere versie is dan powershell-6.0.0-rc2.
Eens even mee spelen, ben benieuwd.
Ik gebruik het vaak voor Skype for business inclusief SIP locks en het beheren van alle polycom/spider phones. Ideale tool voor dat.


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S9 Google Pixel 2 Far Cry 5 Microsoft Xbox One X Apple iPhone 8

© 1998 - 2018 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*