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

Door , , 187 reacties
Submitter: Rafe

PowerShell in Windows krijgt ondersteuning voor OpenSSH. Dat heeft Microsoft aangekondigd. Hoe de functionaliteit er precies uitziet en of zowel de server- als de clientversie wordt ondersteund, is nog niet helemaal duidelijk.

Windows 8Ondersteuning voor ssh in PowerShell kan in potentie betekenen dat een Windows-server op afstand kan worden aangestuurd over ssh, bijvoorbeeld vanaf een Linux-desktop. Ook zouden Windows-gebruikers zonder third party-software als Putty verbinding kunnen maken met OpenSSH-servers.

Uit de aankondiging van Microsoft blijkt niet of dat ook daadwerkelijk kan, en of zowel client- als server-ondersteuning zal worden ingebouwd. Microsoft hint er wel op: het bedrijf schrijft dat ondersteuning voor ssh in PowerShell ervoor zou zorgen dat Linux-servers 'kunnen worden beheerd via ssh,en vice versa'.

Naast de onduidelijkheid over de precieze functionaliteit is ook nog niet bekend wanneer ssh-ondersteuning zal worden geïntroduceerd. Mogelijk wordt de functionaliteit meegeleverd met Windows 10 en Windows Server 2016, maar dat is niet zeker; het zou ook kunnen dat ssh-ondersteuning met een update ook wordt toegevoegd aan oudere Windows-versies. Microsoft belooft zelf ook bij te dragen aan het OpenSSH-project.

In de aankondiging schrijft het PowerShell-team dat twee keer eerder is gepoogd om ssh in te bouwen in Windows, maar dat beide implementaties werden afgewezen. Vanwege de 'wijzigingen in leiderschap en cultuur' zou het bedrijf het nu toch nog een keer proberen. Vrijwel elk ander besturingssysteem heeft ingebouwde ondersteuning voor ssh.

Moderatie-faq Wijzig weergave

Reacties (187)

Goed nieuws. Voor de professionele beheerder is CLI-toegang erg belangrijk. Windows heeft natuurlijk ook allerlei mogelijkheden voor remote management maar niks met de eenvoud van SSH.
SSH heeft nauwelijks overhead en is over een gebrekkige internetverbinding nog prima te gebruiken. Omdat je met commando's werkt is het niet afhankelijk van een bepaalde resolutie of een aantal pixels en is het zelfs vanaf je telefoon bruikbaar (mits je een beetje handig bent met het toetsenbord van je telefoon).

In de Unix-wereld is er een enorme berg aan ervaring met SSH en die kennis kan nu ook Windows ten goede komen. Door SSH te gebruiken in plaats van zelf een nieuw protocol te gebruiken kan Windows een vliegende start maken; er is al een heel ecosysteem rond SSH.

Wat niet iedereen weet is dat SSH meer is dan alleen CLI-toegang. Het kan ook worden gebruikt als tunnel voor andere protocollen. Als je ergens SSH-toegang hebt dan kun je die verbinding ook als een soort VPN gebruiken om te verbinden met adressen/poorten waar je niet rechstreeks bij kan. Zo wordt het soms ingezet als een eenvoudige proxy voor webverkeer. Als je ergens op een onbetrouwbaar WIFI-netwerk zit kun je een SSH-verbinding met je eigen server bouwen en al je verkeer daar over laten gaan. Een aparte VPN-verbinding is dan niet meer nodig.
Nu nog tmux of screen en we zijn compleet! Dan kan je daadwerkelijk bijna alles doen wat je op Linux en Unix qua remote management kan verwachten. Hopelijk gaan andere software leveranciers die Windows software bakken dan inzien dat een GUI-only versie van hun product niet de beste keuze is, dan kunnen we behalve een kale windows server ook daadwerkelijke productiemachines volledige CLI beheren.
Screen is niet nodig want sinds 3.0 ondersteunt powershell ook reconnect:
https://technet.microsoft.com/en-us/library/jj149006.aspx
Ja, maar ik bedoel meerdere screens, of multiplexing zoals tmux.
het lijkt me dat je screen gewoon kan hercompileren op windows, desnoods in cygwin.
En je kunt dan ook veilig remote TV kijken op je Linux settop box zonder met VPN te hoeven gaan klooien.

http://www.milosoftware.c...l/index.php?body=dropbear
Ik ben geen expert op windows gebied, maar hoeveel kan je via de powershell in windows beheren, dus zonder gebruik van een GUI?
Onderschat Powershell niet. In de nieuwere Windows Server versies, en dan met name 2012 R2, is zo goed als elke optie in Windows Server uitvoerbaar met een Powershell commando. Veel IT beheerders moeten hier niets van hebben, "Iegh, een command line, eng", maar het werkt echt goed!
Powershell is qua concept door MS helaas over-engineered. Ja het is krachtig, maar valt tussen wal en schip mbt positie tussen programmeertaal en scriptingtaal. Voor programmeurs heeft het veel onlogische eigenaardigheden, voor administrators is het nodeloos ingewikkeld. Administrators moeten onderhand programmeurs worden om er iets mee te doen (afgezien van de simpele one liners). Het is foutgevoelig en niet vergevingsgezind, meedenkend. Dat objecten concept is heel leuk voor programmeurs. Ik ben recentelijk gedoken in Perl. Ook dat heeft zijn eigenaardigheden, maar wel fijner dan Powershell. Ook concepten als scoping en option explicit zijn in PS onpraktisch geïmplementeerd. Het heeft lang geduurd voordat praktische admin dingetjes als AD erin zaten. Het is overal zichtbaar dat het een laag bovenop .NET is.

[Reactie gewijzigd door Rinzwind op 3 juni 2015 10:09]

Perl op Windows is leuk, maar Windows is nou eenmaal object georienteerd. De registry is niet iets waar je met regexp op wil hacken, en dan heb je WMI, CIM, enzovoort. Powershell is om die reden object georienteerd. Op www.microsoftvirtualacademy.com kan je een paar geweldige cursussen vinden met Jeffrey Snover, die de bedenker is van Powershell. Ten zeerste aan te raden.

En straks gaat het nog veel meer Powershell worden: Je kan het links proberen te laten liggen, maar dan loop je het risico je zelf onverkoopbaar te maken als sysadmin..
Hoe hebben de mensen pre-windows dan hun machines beheerd? Hoe doen de Linux/Unix/Z-os mensen dat nu dan?

Netwerk beheerders (routers switches ed.), afgezien van de firewall administrators, willen niet anders dan een commandline. Da's veel efficienter en nauwkeuriger werken.

Een grafische weergave en invoermethode is wel makkelijk maar zeker niet de enige en beste methode van beheren.
Ik ben fan van beide. In een grafische weergave kun je veel makkelijker zien welke opties je in kan stellen en wat de mogelijkheden zijn. Als je die eenmaal gevonden hebt dan kun je vaak de commandline commando's uit de config trekken en die hergebruiken. Verder heb je in een GUI ook de mogelijkheid om grafieken e.d. weer te geven en je kan er gewoon meer info kwijt. Het beste is natuurlijk de twee gecombineerd tot een soort van IDE.

Kortom, de GUI (bij switches/firewalls/loadbalancers) is er voor informatieoverzicht en te leren welke commando's je allemaal kan geven en de console is er om die vervolgens (vaak) uit te voeren ;)
Gewoon simpel een gui met daaronder de commando's die uitgevoerd worden in een Shell laten zien. En als je wilt kun je dan elk moment of gui gebruiken of de Shell
Dat klinkt een beetje als SMIT(ty) in AIX. Je kan via een menu de juiste opties selecteren om vervolgens de bijbehorende commando's te laten zien. Erg handig als je nog een junior bent op AIX en alle lsdev, chdev, etc nog niet kent. De gegenereerde commado's kan je hergebruiken en aanpassen naar behoefte.
Daar moest ik ook gelijk aan denken. Verdomde handig.
En Aix had dit al begin jaren 90.
In bijvoorbeeld Virtual Machine Manager kan dit al doormiddel van het 'script' knopje.

De tooling zal dan meer code genereren dan je zelf nodig hebt, (denk aan GUID's van alle objecten i.p.v. hostnames) maar je kan dit prima gebruiken om zelf je eigen PowerShell code te extraheren.
Je kan in pakketbeheerders onder linux vaak zien wat er gebeurt in de commandline als je die optie aanzet (synaptic is daar erg handig in)
Dat zou fantastisch zijn voor zoveel systemen inderdaad.
Commandline is superhandig, maar ook erg foutgevoelig, als je een typfout maakt kan dat desastreuze gevolgen hebben, ik heb het idee dat die fouten met een gui veel minder snel gemaakt worden.
Dat klopt helemaal. Laatst nog wilde ik mijn Downloads directory even opschonen. De remote videoconsole die ik gebruik om servers op afstand te beheren laat altijd een heleboed 'viewer([a-z]*32)' bestanden achter. Nu had ik die recent al opgeruimt, maar voordat ik een nieuwe sessie starte wilde ik de oude bestanden weer even weg hebben.

In een GUI selecteer je de bestanden en druk je op delete en je bent klaar. Ik deed het deze keer via de commandline en ik had even niet door dat er maar 1 viewer bestand stond. Dus ik type: 'rm vie[tab]*' en voila, mijn hele download directory leeg. De tab stopt normaal bij 'viewer(' waardoor het hele commando 'rm viewer*' word wat alleen de viewer* bestanden weggooit. Echter, er was maar 1 bestand, dus het commando werd rm 'viewer-langenaam *' waardoor alle files weg waren.

Maar goed, met een GUI werk je in het algemeen langzamer en het is ook geen zekerheid dat je geen fouten maakt.
Bij CLI's heb je dan weer het voordeel dat je kan terugzien wat je hebt gedaan. Als je in een GUI per ongeluk op het verkeerde knopje drukt kan het heel moeilijk zijn om te achterhalen wat er fout is gegaan. Bij een CLI kun je precies zien welke commando's er zijn gegeven.
Inderdaad, een groot gedeelte van mijn documentatie staat dan ook in 'history' O-)
Dan hoop ik dat je per server altijd maar een shell tegelijk open hebt.
De *nix mensen hebben vaak zaken als bash, csh, zsh, ksh enz. wat een gewone shell is en niet een object oriented parser/shell/ISE zoals PoSH dat is.

Van een standaard console kan je verwachten dat je er gewoon commando's mee kan draaien en aan elkaar kan knopen, in PoSH wordt verwacht dat je je commando's in de vorm van methodes aan elkaar knoopt wat meteen een hele hoop verplichtingen en beperkingen qua keuzes met zich mee brengt. Het is heel goed te gebruiken, maar ook maar op 1 manier en 1 verplichte manier te gebruiken.

Voor alle non-Windows CLI management werkt alles als een normale shell, geen scripting interpreter met IDE/ISE. Daar kan je als beheerder zonder programmeerkennis dus gewoon gebruik van maken. Het ergste wat je dan kan overkomen is dat je piping, i/o redirection en commando-specifieke parameters moet leren. Dat zijn over het algemeen 3 of 4 dingen die je even moet onthouden + de tools die je vaak gebruikt, en dan ben je er al.
Inderdaad. In vergelijking met de linux command line vind ik powershell eerlijk gezegd nog wat rommelig. Een van de dingen waar ik vooral een degout aan heb is dat commando's en variablen vaak onnodig lang zijn en camelcased. Combineer daarbij dat expanden met tab niet overal even goed geimplementeerd is en je hebt een resultaat dat mij vaak ergert.

Nu, de linux command line heeft een ontwikkelperiode gekend ondertussen van een paar decennia en powershell an sich nog maar een paar jaar. Dus ik heb wel goede hoop dat het goed komt :)
Ondertussen gebruiken Linux sysadmins al weer tools als Chef en Puppet om dingen te doen. Dus die jongens zitten ook niet stil.
System Center is daar het antwoord van Microsoft op. :)
Ik vind dat niet zo'n probleem. Je moet als doel hebben om zoveel mogelijk uit de CLI/GUI weg te blijven en te zorgen dat alles draait. PowerShell helpt om dat doel te verwezenlijken d.m.v. simpele scripting. Ik vind het minder geschikt als CLI (ook omdat Windows gewoon een GUI heeft).
Het beroep van system engineer is veranderd. Ik denk dat basiskennis programmeren/software ontwikkeling onontbeerlijk is voor een goede engineer.

Ook moet je powershell vergelijken met wat er al bestond. batch, vbscript/jscript, WMI en -letterlijk- honderden mgmt tools met verschillende syntax.
Mijn ervaring leert dat ik met Powershell dingen sneller en eenvoudiger gedaan krijg dan vroeger met vbscript (hoewel ik qua syntax ed nog steeds vlotter code in vbscript). Ook zijn er echt heel veel configuraties die je voorheen enkel via de GUI kon doen die nu eenvoudig zijn met Powershell.
Even een kleine correctie:
Het beroep van een windows system engineer is veranderd.
Zolang ik linux servers beheer (17+ jaar) is programeren een onmisbaar onderdeel van mijn skillset geweest. Aan de ene kant omdat je dan bugs in opensource projecten kan oplossen (er zitten twee kleine bugfixes van mijn hand in de LVS kernel module) en aan de andere kant omdat je gewoon niet ver komt zonder kennis van een scriptingtaal als beheerder.
Afhankelijk van wat je beheert kom je tegenwoordig natuurlijk steeds minder ver als je niet ook wat programmeer skills hebt. Het gat tussen developers en administrators wordt steeds kleiner en met de focus op een goede handhaving van DevOps begint het zelfs al te mengen.

Ik kan stellen dat ik zonder mijn software engineering vaardigheden en minder goede beheerder geweest was, en zonder mijn kennis van beheer minder goed software kan afleveren die daarna goed te beheren is. Dat klinkt heel logisch, maar ik denk dat dat iets is wat pas de laatste paar jaren echt steeds breder gedragen wordt en steeds meer verwacht wordt dan dat het 'mooi meegenomen' is.

Nadeel is natuurlijk dat als de IT wereld eenmaal zo ver is, je met een junior Windows GUI beheerder helemaal niks meer kan, die heeft dan nul bruikbare kennis en zal de jaren die in een opleiding gestopt zijn weg kunnen gooien om dat het hele beeld van wat er onder water gebeurt in een OS, met een server en met services gewoon niet aanwezig is. En laat dat nou toevallig de grootste groep entry-level beheerders zijn...
Terwijl de opleidingen (zeker op MBO) steeds meer Windows-minded zijn. Dat was bij mij in 2001-2005 al zichtbaar, maar is alleen maar erger geworden, helaas.
Het is nog erger : tot nu toe alle stagemedewerkers welke wij gehad hebben leren 0,0 over Powershell (buiten het feit dat ze opdrachten krijgen welke dusdanig ver van de realiteit verwijderd zijn en dat ze nu ook nog gewoon 2008 - nieteens R2 - moeten gebruiken on veel gevallen) geeft mij een zeer slecht gevoel over de kwaliteit van de huidige opleidingen MBO systeembeheer.

Daarom hamer ik er ook altijd op : werk aan je powershell kennis als systeembeheerder.
Bij mijn vorige werkgever wisten de stagiaires nooit wat een floppydrive is... :X Kregen ze wel van die leuke glazige ogen: "Hoe en waarom moet ik dit weten?"... :P

[Reactie gewijzigd door CH40S op 3 juni 2015 17:23]

Systeembeheer wordt ook steeds meer uitbesteed, bv door cloud-applicaties te gebruiken. Hierdoor hoeven je lokale beheerders steeds minder op laag niveau te doen.
Functionele beheerders en applicatie-experts blijven echter nodig. Dat soort werk is vaak helemaal op GUI's gericht.
Ik geloof niet dat Rinzwind bang is voor wat scriptwerk aangezien hij schrijft dat hij Perl gebruikt. Dat is nou niet echt de meest newbie-vriendelijke taal.
Zelf heb ik nauwelijks ervaring met Powershell maar wat ik er wel mee heb gedaan vond ik vaak een beetje omslachtig dus ik kan me wel vinden in zijn commentaar. Dingen die ik in bash of perl kan doen met een paar korte commando's zijn in powershell een heel verhaal. Die verbose commando's zijn wel makkelijker te leren dan het cryptische gebrabbel van bash of perl maar als je er veel gebruik van maakt is een compacte formulering ook erg fijn. Bij ingewikkelde objecten wint powershell het wel maar voor de bulk van de kleine dingetjes voel ik me meer thuis bij de Unix tools.
Het kan ook gewoon aan mijn gebrek aan ervaring liggen.
En die laag bovenop .net is slecht want?

Powershell is niet bedoeld als programmeertaal, daarvoor heb je programmeertalen zoals c# e.d.. Powershell is bedoeld als CLI en scripttaal.

Als je als administrator dit nodeloos ingewikkeld vindt ben ik bang dat je over een paar jaar patat verkoopt. Powershell blijft, en alle nieuw uit te komen software van microsoft dient hiermee te werken. De toegankelijkheid is mijn inziens juist vrij laag, een stuk beter dan bijvoorbeeld vbscript was. Ik kan me voorstellen dat je als programmeur je ei hier niet in kwijt kunt maar daar is het ook niet voor bedoelt. Het is bedoelt om op een efficiente manier meerdere servers te kunnen beheren.

mbt foutmeldingen, als je een foutmelding krijgt in powershell krijg je een FullyQualifiedErrorId te zien die je invoert in google/bing en vaak krijg je dan al flink te zien wat je fout doet.
Eens. Ik gebruik PowerShell om een Windows Server 2012R2 te prepareren voor onze Software Solutions. Wat ik voorheen manueel deed in 1,5 uur, doet het PowerShell script dit nu in 5 minuten.
Alles kun je vinden m.b.t. commando's en scripting. Het is een zeer krachtige tool die de standaard command prompt al heel lang in z'n hemd laat staan.
De standaard command prompt staat dan al sinds Unix/Linux/BSD goede shells had in z'n hemd, het is eigenlijk niks meer dan een glorified launcher... ;)
Eens, de ISE wordt standaard met Windows meegeleverd en is heel laagdrempelig.

Die laagdrempeligheid maakt het dat het heel eenvoudig wordt om scripts af te vuren voor monitoring, deployment en/of configuratie. Ook omdat het een scripttaal is kan iedereen zien wat de code doet. Nooit meer klikken "omdat het moet" zonder dat je weet wat de precieze consequenties zijn.
Nee, BASH onder Linux is overzichtelijk... als ik daarin iets moet doen, denk ik altijd direct dat ik in 1975 zit.

Dat is geen bash (pun not intended :p) richting Linux; ik gebruik de Linux commandline bijna dagelijks. Het is alleen maar om aan te geven dat elke omgeving zijn eigen eigenaardigheden heeft. Ik ben allang blij dat Windows EINDELIJK (OK, vanaf 2006/2007 ofzo) via de commandline kan worden beheerd, op welke manier dan ook.
Bash is inderdaad een puinhoop. Geen enkele moderne ontwerper zou het zo durven doen. Maar het is wel heel handig in een hoop eenvoudige situaties en die komen nu eenmaal het meeste voor. Als het wat complexer wordt kun je beter naar Perl of Python kijken. Daar tussen in zin een broot grijs gebied waarin je heel makkelijk en snel met bash kan werken als je goed bekend bent met alle eigenaardigheden en uitzonderingen. Als je dat niet bent dan trek je al snel de haren uit je hoofd. (Unix-beheerders hebben vaak een baard om daar voor te compenseren ;) )
Bash is handig om een "skelet" van je project mee te bouwen en de boel in de eerste plaats werkend te krijgen.
Maar wanneer gaan ze er eens voor zorgen dat een variabele die door een while-loop is veranderd ook daana in die staat blijft? En die syntax-checking, ook een hell: als op regel 10 van de 1000 een aanhalingsteken of een haakje mist komt ie daar meestal pas ergens bij het einde achter. Kun je je hele script gaan afbreken om uit te sluiten waar de fout zit. ( Of met de editor van mc kijken waar de highlighting raar gaat doen :P )
Ook een goeie: een bash script editten en saven tijdens runtime. Niet doen.
Maar wanneer gaan ze er eens voor zorgen dat een variabele die door een while-loop is veranderd ook daana in die staat blijft? En die syntax-checking, ook een hell
Ik denk nooit. Het botst met de manier waarop bash ontworpen is en zou ook nog eens voor een hoop compatibiliteitsproblemen zorgen. Het is niet voor niets dat Perl en Python zo populair zijn geworden voot wat complexere scriptjes.
Bash is handig om een "skelet" van je project mee te bouwen en de boel in de eerste plaats werkend te krijgen.
O, heerlijk... 200 regels Bash schrijven, en dan bedenken dat het misschien een strak plan is om te porten naar Python / PHP (heurt niet, maar dat zit dusdanig in mijn skillset dat ik die vaak gebruik ja..).
Het vergt (veel) tijd, maar er zijn enorm goede cursussen te vinden en ook de Microsoft documentatie is enorm goed op gebied van Powershell.

Tegenwoordig is het imo echt dé tool om je servers te beheren. Zo gebruiken wij nu bijvoorbeeld Powershell om een volledige AD+RDS omgeving uit te rollen. Inclusief third party applicaties.

Omslachtig, tja... het is vooral bedoeld om scripts te bouwen die je werk een stuk vereenvoudigen. Ik denk dat er niet een betere alternatief is voor Windows op dit moment.
Voor veel dingen vind ik C# eigenlijk prima werken. Je hebt gewoon een gratis prima IDE, je kunt eventueel dingen makkelijk grafisch maken, of anders CLI.
Waarom het per se een interpreted taal zou moeten zijn.
Helemaal met je eens. Ik ben een ervaren rot op gebied van C, C++ en C# op het Windows platform. Ook ken ik verschillende script-talen, maar Powershell heeft net even een te hoge learning-curve voor de relatief eenvoudige taken die ik er mee wou doen.

Pas toen ik TeamCity ben gaan gebruiken en toch wat meer advanced features nodig had, ben ik in Powershell gedoken. En inderdaad... Het kan erg veel en vaak ook met relatief weinig regels code, maar het duurt even voordat je die paar regels hebt geschreven.

Ook gebruik ik het te weinig om de kennis up-to-date te houden. Je moet het echt vaak gebruiken om het een beetje te onthouden.
Als je als IT beheerder bang bent voor een CLI, heb je IMHO het verkeerde beroep gekozen. Vaak zijn dingen veel efficiënter met de command line te doen, dan met een GUI.
Is dat zo? Heeft dit ook niet alles te maken met stukje verantwoordelijkheidsgevoel?
Je moet soms wel mogelijkheid hebben om ook te proberen. Als aanpassing het hele bedrijf raakt wil je niet even "wat proberen".
Daarnaast zie ik dat bedrijven soms beheerders ook geen simulatieomgeving geven of mogelijk maken om nieuwe technieken te werken. Standaard reacties zijn vaak "Het werkt nu toch gewoon goed, waarom iets nieuws?"
Als een beheerder "bang" is voor de comandline, blijft het toch zijn eigen schuld. Er houdt je echt niets tegen om een virtuele omgeving op te zetten op je eigen computer. Windows Server ISO'tjes heb je waarschijnlijk toch al liggen, zo niet, dan zijn ze te downloaden. KMS key er in zetten, en je kan twee maanden er mee spelen.
Daarnaast zie ik dat bedrijven soms beheerders ook geen simulatieomgeving geven of mogelijk maken om nieuwe technieken te werken.
Een 'simulatieomgeving' aka testomgeving kan je gratis zelf maken met bijvoorbeeld Virtualbox en een trial versie van Windows (van alle versies kan je die wel vinden).
Daarnaast heeft een werkgever ook gelijk voor "het werkt nu goed", het heeft alleen zin om iets te gaan automatiseren/scripten als het er nu nog niet is, waarbij dus automatisch het 'het werkt nu goed' argument niet op gaat.
Sommige dingen zijn niet eens meer te doen zonder command line neem Lync b.v. maak maar een common area phone aan in de GUI.

Of uploaden van nieuwe firmware voor je UC phones.

[Reactie gewijzigd door Distrax1988 op 3 juni 2015 10:17]

Ze zijn in ieder geval makkelijker te documenteren en te versie-beheren dan de GUI. Ook tools als Puppet en Chocolatey hebben het beheer van een Windows farm vereenvoudigt.
Wat mij vooral tegenstaat is de syntax. Het is verschrikkelijk onduidelijk en documentatie is lastig te vinden. Ik ben zelf ontwikkelaar en ik had het geweldig gevonden als ze hier een .NET variant van gemaakt hadden, maar nu hebben ze iets nieuws bedacht wat volledig anders werkt dan bestaande alternatieven. Met C# of desnoods VB.NET hadden ze dat kunnen voorkomen en hadden ze het met kleine wijzigingen voor systeembeheerders eenvoudig kunnen houden.

Het kan heel veel, maar als niemand weet hoe het werkt heeft dat ongeveer hetzelfde resultaat als toen Powershell nog niet bestond.
Get-help commando. Tadaa, je help documentatie.

Zoals Jeffrey Snover himself zegt, you only need 3 cmdlets to do Powershell, get-help, get-command and get-member.

Overigens loopt er nu een feature request om op de msdn pagina's ook een tabje powershell code op te nemen. Of dat erdoor komt is nog de vraag.

Om mee te stemmen, Klik hier. https://connect.microsoft...t-reference-pages-in-msdn

[Reactie gewijzigd door @r!k op 3 juni 2015 10:34]

De kracht van de Unix-shell zit 'm niet zo zeer in de shell zelf maar alles eromheen. Honderden command-line tools die je aan elkaar kan knopen, het feit dat alles gewoon in leesbare config files staat in plaats van iets als het registry. etc. Met alleen een goeie shell ben je er niet.

Hoe werkt dit op Windows met powershell ? Aangezien er vrijwel geen command-line tools zijn voor Windows en alle config in het register staat ?
Met PowerShell browse je gewoon door "databronnen" browsen zoals je door je directories browsed. Dus HKLM: of CERT: en je kan bij je keys of certificaten Je kunt zo ook door SQL database of AD wandelen, maar moet je de modules hiervoor eerst actief maken. Je kan ook mappings maken naar data formaten als XML / JSON en daar door heen lopen.
Voordeel bij alles is dat je geen plain waarde/text terug krijgt (zoals bash) maar een object met daarin een waarde/text.

Kortom, als je iets verder kijkt dan kun je als server admin (zonder echte programmeer kennis) goed je gang gaan met simpele objecten. Uiteraard kun je het mooier, groter en beter maken door gebruik te maken van .NET. Maar dit hoeft niet.
T`is niet echt eng, maar meer onwennig als je jaren met GUI`s hebt gewerkt.
Het mooie van dat commando is dat je ook erg eenvoudig het uit kan voeren naar verschillende PC's in één commando. En die commando's en cmdlets zijn erg makkelijk (die kunnen op zichzelf weer aliasses zijn of volledig class/function based REST interfaces gaan aanspreken). Powershell leest uit zichzelf ook XML en JSON formaten, wat het en/decoderen van gegevens naar conventionele niet-powershell rest-interfaces erg eenvoudig maakt.

En voor de instap-powershell users zijn er dingen die het toevoegen van een nieuwe role + features op een server erg makkelijk maken. Voorbeeldje van een mild weirde IIS installatie:

import-module servermanager
add-windowsfeature web-webserver, web-common-http, web-static-content, web-default-doc, web-dir-browsing, web-http-errors, web-app-dev, web-net-ext, web-isapi-ext, web-isapi-filter, web-health, web-http-logging, web-request-monitor, web-security, web-basic-auth, web-windows-auth, web-filtering, web-performance, web-stat-compression, web-mgmt-tools, web-mgmt-console, web-scripting-tools, web-mgmt-service, web-mgmt-compat, web-metabase, web-wmi, web-lgcy-scripting, web-mgmt-console
Ik weet niet wat voor IT-beheerders jij dan kent, maar een ervaren IT sysadmin kan met zowel commandlines als gui overweg waarbij een lichtelijke voorkeur voor de cmdline en scripts prevaleert :)
remote powershell is al mogelijk, maar is proprietair: Enkel van windows naar windows.

Waar we nu van kunnen dromen is dat we via linux en ssh een windows pc kunnen beheren met powershell.
dat kan reeds dmv 3rd party software (en hoeft dus geen droom te zijn)
Mij lijkt het dat ondersteuning voor openssh onder meer interssant zal zijn omwille de automatische updates. Nu wordt OpenSSH server/client meegeleverd met allerhande software (zoals van HP...). Als er dan geen strikt lifecycle beheer en updatemanagement gedaan wordt, blijken allerhande oude en onveilige versies her en der verspreid te zijn in de omgeving (jammer genoeg heb ik dat maar al te vaak gezien, tewijl een oude en/of slecht geconfigureerde remote console tool toch een duidelijk veiligheidsprobleem is).

Door SSH te integreren in het OS neemt Microsoft de verantwoordelijkheid voor de beveiliging (en dus updates) en wordt het leven van de sysadmin wellicht (weer) iets makkelijker
dat kan reeds dmv 3rd party software (en hoeft dus geen droom te zijn)
Hij bedoelt zonder 3rd parties, dus out of the box.
Ik denk ook dat het de natte droom is van veel IT-ers om zonder 3rd party software een Windowsmachine te beheren met behulp van een Linux/SSH-machine.
Vaak zit je in de positie dat je geen software mag installeren op een bak. Of het mag wel, maar je wil het risico niet nemen omdat je niets overhoop wilt halen. In dat geval zou het fijn zijn als je met je Linuxbakje via SSH een dumpje kunt trekken van de remote database van een Windowsbakje.
Nope, in combinatie met de CIM cmdlets en OMI kun je ook Linux, Unix netwerkswitches en dergelijke beheren. Je bent alleen wel afhankelijk van de OMI implementaties op die machines. Powershell kan er echter mee omgaan. Zoek maar eens op de blog en video's van bartek bielawsky, hij is Powershell MVP en doet hier vrij veel mee. :)
De huidige remote powershell implementatie is om te huilen. Niet iets wat ik ooit in productie zal draaien.
Ik hoop ook dat sftp ook wordt mee genomen. Het remote kopiëren naar een cli only windows is erg omslachtig.
Dat wordt mogelijk vanaf versie 5 :) is een vereiste voor Nano server.
Via Powershell kun je heel wat zaken instellen en/of wijzigen aan Windows. Zeker administratieve taken kunnen er prima mee gedaan worden. Voorwaarde is wel dat je weet hoe 't moet. Verder vind ik de commando's die je uit kunt voeren lang niet zo prettig werken (en lange namen hebben) dan in Linux. Meer informatie en mogelijkheden kun je op hun eigen pagina vinden :)
Maak je toch een alias aan? Er zijn een paar standaard aliasses. Get-Childitem = "LS" bijvoorbeeld. LS kent iedereen wel.
Dat kan wel maar het is een workaround. Verder moet je ook voor bepaalde dingen weer snapins of modules laden. Powershell is heel krachtig maar zeker niet altijd even gebruiksvriendelijk.
Niets weerhoud je er natuurlijk van om aliassen te maken voor die powershell commands :)
Enige probleem is natuurlijk dat je het op een eventuele server ook zou moeten doen..
Powershell is zelfs krachtiger dan de GUI. Voor Exchange / SQL / System Centre en andere grote pakketten komt het al regelmatig voor dat je zaken zelfs alleen maar in powershell kunt uitvoeren. Een bekend voorbeeldje voor Exchange is het exporteren van een mailbox naar een PST. Dit is Powershell-only en kan niet gedaan worden vanuit de GUI.
Bij Exchange 2013 niet meer; Dat kun je gewoon doen via de EMC.
Exchange wellicht, maar je hebt ook nog Office 365. Daar is het aantal taken wat je kunt uitvoeren via de GUI echt minimaal.

Probeer maar eens een iewat customized message tracing te doen.
Ik weet het. Ook als je meerdere globale adreslijsten wilt aanmaken kom je niet onder de powershell uit. Tevens vind ik powershell best wel een zeer prettige shell. Het is iig lekker krachtig.
Je kunt windows 2012 server zonder UI installeren en enkel via CLI installeren. Wordt vooral gedaan met Hyper-v images servers.. :) Dit gaat zonder problemen.

Hoe je het zelf kunt testen door aan en uit te zetten:
http://www.howtogeek.com/...n-in-windows-server-2012/

Hier staat de officiele handleiding van microsoft
https://technet.microsoft.com/en-us/library/jj574205.aspx

IMHo
SSH is een goede toevoeging, makkelijk files doorsturen hopelijk (gaat ook wel via FTP command... maar is dan onbeveiligd/zonder ssl)

[Reactie gewijzigd door Icekiller2k6 op 3 juni 2015 09:52]

Microsoft maakt er een punt van geen software meer te releasen zonder powershell cmdlets om het beheer te doen.
Sinds server 2012 is Windows daarom meer dan prima te managen zonder GUI.
Je kan zo ongeveer alles via PS beheren.

Als je bijvoorbeeld kijkt naar server 2012 R2 dan voert de GUI op de achtergrond PS uit. Je zou dus ook zelf de commando's in kunnen voeren :-)
zonder gekheid meld je aan bij Microsoft Virtual Academy en volg de les van powershell. Duurt niet al te lang en het hele concept welke kan tMS opgaat wordt duidelijk.
Volgens mij (bijna) alles. Powershell is heel erg vergelijkbaar met de terminal.
Je kunt basale commando's uitvoeren, zoals het stoppen van alle processen op je pc (don't try this at home ;) ):
Get Process | Stop-Process
of het aanmaken van tekstfiles, het uitlezen van tekstfiles, het converteren van tekst naar csv of xml

Maar het wordt pas echt interessant om met productspecifieke modules (bijv. voor SQL, Exchange of Active Directory) dingen aan elkaar te knopen. Je kunt bijv. gebruikers geautomatiseerd laten aanmaken op basis van een excel-sheet, vervolgens een mailbox laten koppelen, en indien de gebruiker ook lid is van applicatie X ook gelijk security-rechten zetten op een specifieke database.

In aanvulling op dit nieuwsartikel: met SSH zou je dus ook makkelijk tekstfiles vanaf unix kunen kopieren naar een userprofile. Of indien een windows-service een error uitgooit, waarvan bekend is dat er een unix process herstart moet worden; dan kun je dit ook relatief zeer gemakkelijk via powershell scripten.
Zo'n beetje alle nieuwe producten en diensten zijn scripting first.
De GUI roept dan powershell aan
Alles kun je met Powershel beheren!
Vaak zelfs meer als in de GUI.
Eigenlijk doet je GUI niets anders dan onderwater Powershell commando's uitvoeren.

Ik zie in SSH eigenlijk geen toevoeging. Je heb ook Windows Remote Management (Geen RDP) waarmee je een server/client extern kunt beheren.
Je kunt in powershell meer beheren dan met de GUI
Veel functies zijn niet meer in de GUI te vinden en zitten wel in powershell.
Om een paar voorbeelden te noemen kun je Windows via zonder GUI makkelijk beheren. Gebruiker uitloggen. PC herstarten. Inloggen via command-line sessie. Screensaver instellen. Powersettings veranderen. Diskgrootte uitlezen. Virusscanner starten. Taken inplannen. SSH en FTP clients kun je ook via command-line doen.

MS Batch command-line was simpel en effectief maar beperkt omdat je bij complexe scripts delayed variables moest gebruiken.

Met WMIC scripting in combinatie met commandline kwam je vaak een heel eind wat betreft OS modificatie. Het nadeel sinds Vista was dat je Elevated Rights bij een command promt moest openen. In het tijdperk van XP kon dat nog niet.

Powershell is een combinatie van WMIC en command-line en VBScript. Het is zeer geavanceerd en het is eigenlijk zo functioneel dat het veel diepgaande kennis en vaardigheid vereist. Het is door iemand verzonnen die goed kon programmeren. Het is niet bepaald een laagdrempelig script om 1-2-3 zelf aan te leren. Powershell kan ik wel aanbevelen.

WMIC en Powershell zijn in een domein omgeving onmisbaar. Je makkelijk gegevens in of uit AD/Exchange halen en is zeker velen sneller dan met GUI als je het daarna door een tekst verwerker wilt halen.
28ste bij TechDays een presentatie gevolgd over PS en wat er aan zit te komen en je kan er echt veel mee (mede mogelijk gemaakt door .net op de achtergrond). Het is een Cmd prompt on steroids.

Scripting is doable en je kan tegenwoordig ook met Visual studio de PS scripts debuggen e.d.
Alles...

De meeste microsoft GUI's zijn tegenwoordig ook niet meer dan een shell die onder water een powershell script uitvoert. Goed voorbeeld hiervan is EMC (exchange management console) en SQL management studio.

Die geven aan het einde van je next-next-finish verhaal ook netjes aan welk powershell commando er wordt uitgevoerd.
Of een van de vele andere mogelijkheiden dat als EMC afgekort word

http://en.wikipedia.org/wiki/EMC

De Exchange Management Console heet gewoon in de "volksmond" EMC.
Hopelijk gaat windows meer unix programmas gebruiken in windows

Mingw en cygwin vind ik persoonlijk niet fijn werken. Terwijl de gcc compiler en makefiles geweldig zijn.
Windows kent ook een UNIX compatibility tools feature. Biedt ook e.e.a. voor de die-hards, maar op zich biedt cygwin meer. Mingw ken ik niet, maar als je Unix shells gewend bent, is cygwin net zo intuitief. Ken je (de kracht van) Unix shells niet, dan valt denk ik elke UNIX-like ding op Windows tegen.

Het grote nadeel van de gcc compiler van cygwin op Windows is dat ook altijd de cygwin runtime nodig is. Als je dan executables maakt die naar klanten moeten, moet ook de runtime mee. Daarom is de reguliere Windows/Visual Studio runtime in dat geval een handiger keuze.

Ik kom de geoptimaliseerde Intel runtime ook zelden tegen. W.s. om voornoemde reden (en de kosten).

Windows is eigenwijs (waar de keuze voor de backslash en spaties in een directory wel aan de top staan), maar heeft door de jaren heen steeds meer handige command-line tools (findstr is een aardige grep vervanger).
Eindelijk native SSH support! Hier zal PuTTy vast niet zo blij mee zijn :P Wel ben ik bang dat ze weer een eigen implementatie gebruiken, waar wellicht veiligheidsissues mee gepaard gaan (niet open source) en met een beetje pech wat Windows-only eigenaardigheden..
volgens mij ben je nog steeds niet verplicht om dan gebruik te gaan maken van de Microsoft SSH Client. Putty zal zeker nog lang blijven gok ik.
Natuurlijk zul je Putty nog steeds kunnen gebruiken, maar de noodzaak om het te gebruiken als je iets met SSH wil verdwijnt natuurlijk wel :)
ligt er aan of microsoft ook de security features van Putty gaan implementeren.
En of de Powershell "terminal" (weet niet hoe je dat noemt in Windowsland, ben zelf UNIX nerd) ook alle terminal emulatie functies support die op UNIX-achtige gebruikt worden (VT100/102 of xterm-color bijvoorbeeld). Als hij dat niet doet heb je alsnog niet zo gek veel aan die SSH client voor remote beheer.

Ben wel blij dat Windows nu eindelijk misschien net zoals de rest van de wereld SSH gaat praten en ook hoop ik daarbij gelijk SFTP. Zal mijn leven als UNIX-tuigh makkelijker maken.
Natuurlijk zit er een MS-sausje over de SSH implementatie. Ik kan me voorstellen dat MS het volgende toevoegt aan een ssh-server/client:
- Inloggen met je AD-account
- Kerberos-tickets voor autologin
- Vanuit AD U&C: Rechtermuis op een computerobject, Start SSH-Session
Zo zijn er nog wel meer nuttige toevoegingen te bedenken
Met openssh & pam zijn die eerste twee al mogelijk.
Hoezo? Putty is een opensource client voor oa (maar niet uitsluitend) SSH. Een bredere adoptatie van het protocol zal alleen maar bijdragen aan hun succes.
Het zou overigens verwonderlijk zijn mocht de functionaliteit in Windows vergelijkbaar zijn met Putty. Ik verwacht eerder een telnet vs putty of notepad vs notepad++ verhouding.

Daarnaast ben ik het er niet mee eens dat niet open source betekent dat het persé een veiligheidsprobleem is. Ook heeft Microsoft een cultuursverandering ondergaan; opensource is niet langer hun vijand, maar wel hun toolbox (dixit MS employees). Een engineer omarmt en soigneert zijn toolbox. Bovendien heeft Microsft zelf aangegegven OpenSSH als basis te gaan gebruiken en, aangezien dit GPL is, ook code te submitten en dus *samen* met de OSS communities aan deze belangrijke tools gaat werken.

* the_stickie denkt dat Microsoft echt de goed kant op gaat!
Dat zou best kunnen, maar het is niet dat de markt voor de SSH-clients groter wordt omdat ze een breder publiek bereiken. Er zijn dus meer mogelijkheden om te verbinden met een SSH-server dan voorheen, die te verdelen zijn over een zelfde aantal gebruikers. Het kan inderdaad goed zijn dat Putty superieur is ten opzichte van de Windows-implementatie, maar dat is Notepad++ ook tegenover kladblok. Toch zijn er nog mensen die kladblok gebruiken.

Verder stel ik ook niet dat het niet open maken van de sources per se een veiligheidsprobleem is. Ik stel echter wel dat het gebrek aan controle van een communitie een potentieel risico is hierop. Backdoors en dergelijke zijn een stuk lastiger in te bouwen als er een grote community mee kan kijken.
Ach er zijn al sinds jaar en dag concurrenten van putty, toch blijft het een handige client. Denk dat mensen die het gewend zijn het wel blijven gebruiken.

SSH ondersteuning is vooral handig voor allerlei scriptjes etc, waar je dan niet een extern programma voor hoeft op te starten. Hopelijk ondersteunen ze ook scp, wordt inmiddels wel een beetje moe van Windows klanten die zeggen alleen te kunnen ftp'en waarna ik ze dan weer mag gaan uitleggen dat winscp ook prima cmdline werkt.
Eindelijk native SSH support! Hier zal PuTTy vast niet zo blij mee zijn :P
Microsoft kennende zal het vele jaren duren voordat alle opties van PuTTTY ingebouwd zijn in de software van Microsoft. Bijvoorbeeld, in het eerste jaar ken je wel via SSH inloggen maar er is niet de mogelijkheid om via een proxy in te loggen waardoor je toch weer PuTTY nodig hebt of je moet handmatig gaan klooien met de Microsoft software. Het is maar een illustratief voorbeeld.
Ik gebruik Putty vooral vanwege het window management en de configureerbaarheid. Een OpenSSH client was altijd al los te installeren op Windows, bijv. via Cygwin, maar je zat dan vast aan die vervelende cmd.exe of powershell.exe die niet makkelijk full-screen kunnen, waarin je niet makkelijk tekst kunt kopieren en plakken, etc. Putty brengt de kracht van een linux-terminal naar Windows met slechts één executable zonder verdere configuratie te vereisen. Ook het sessie-management is makkelijk in Putty.

Met name een ingebouwde SSH *server* in Windows zal ik erg waarderen. Een client moet ik nog zien.
Tsjonge, nou nog bash en rsync, dan ga ik het overwegen.

Serieus, het is wel een goede move. Hiermee wordt uniform beheer over meerdere besturingssystemen weer een stukje eenvoudiger.
Bash is in zó veel vormen al lang mogelijk. Posix compliancy is er ook. Rsync... why should you? Eenmalige synchronisaties zijn enorm eenvoudig, en zolang je alles kan mounten en er DFS support is... why sync? FS kan sowieso een hele hoop replicates zelf uitvoeren...
Nou, er zijn anders veel voordelen aan rsync, met name tussen heterogene systemen en het internet. We hebben niet allemaal een Windows-only netwerk dat ook nog eens in één AD forest hangt.
Tsjonge, nou nog bash en rsync, dan ga ik het overwegen.
Daar hebben we cygwin voor :)
Als ze de (SOCKS) port forwarding functionaliteit meenemen krijgt Microsoft wat pluspuntjes van me.
Dat en SSH multiplexing.
Als ze de (SOCKS) port forwarding functionaliteit meenemen krijgt Microsoft wat pluspuntjes van me.
Microsoft kennende zullen dat soort opties pas over vele jaren ingebouwd worden. Net zoals PDF. Veel mensen hebben jarenlang PDF-printers gebruikt voordat Microsoft eindelijk een optie heeft toegevoegd om documenten te bewaren als PDF.
Ze houden ervan om gebruikers te pesten. Sterker nog, ik vermoed zelfs dat er een complete afdeling bestaat binnen Microsoft die alle mooie opties verwijderen vlak voordat het product live gaat ;)
Als Microsoft de SOCKS port forwarding functionaliteit direct bij de eerste versie inbouwt, dan trakteer ik je op een biertje :)
Dat is niet pesten.. Dat is een stukje logica. Als Microsoft PDF printing inbouwt is er in no-time iemand die gaat roepen dat ze daarmee pdfcreator en andere applicaties dwars zitten.
Dat was ook zo met media player en met internet explorer.
Dat is niet pesten.. Dat is een stukje logica. Als Microsoft PDF printing inbouwt is er in no-time iemand die gaat roepen dat ze daarmee pdfcreator en andere applicaties dwars zitten.
Dat was ook zo met media player en met internet explorer.
  • Waarom hebben ze command line dan niet 10 jaar eerder uitgevonden? (ehh... DOS-box reken ik hier uiteraard niet mee) Zelfs als ze de command line van Linux/GNU letterlijk copy/pasten, dan nog zitten ze niemand in de weg want het is open software.
  • Waarom hebben ze openSSH niet 10 jaar eerder ingebouwd? Daar zitten ze toch niemand mee in de weg? Is toch open software?
  • Waarom hebben ze niet hun eigen PuTTY-achtige tool ingebouwd onder "Bureau accesoires"? Met zoveel programmeurs in dienst kennen ze een dergelijke tool in enkele dagen bouwen en zitten ze niemand in de weg.
Waarom hebben ze sowieso vanaf het begin propaganda gemaakt tegen command line interface? In de beginjaren van Windows was het echt erg hoor. Een computer was geen computer meer als er geen grafische interface op zat. Pas de laatste jaartjes komen ze er voorzichtig voor uit dat CLI toch weleens nuttig zou kunnen zijn.

Trouwens, ik neem aan dat je het niet al te letterlijk opvatte wat ik zei over het pesten. Er staat een smiley bij. Het spijt me als ik je heb doen geloven dat Microsoft een heuse afdeling heeft om gebruikers te pesten O-)
Droom lekker verder. Waarom zou Microsoft zijn gebruikers willen pesten? Met zo'n insteek gaan ze het nooit goed doen dan. Je kan al zeker weten sinds office 2003 PDF bestanden opslaan. Nu voegen ze inderdaad een PDF printer toe. Maar dat hebben ze volgens jou al die tijd niet gedaan om de gebruikers te pesten... Tuurlijk, dat zal het vast zijn. Ze hielden je inderdaad heel erg tegen als je het via 3rdparty deed. Niet dus.

Microsoft moet toch niet alles implementeren wat iedereen gebruikt? Het is mooi dat het nu out of the box kan maar "extreem nodig" was het zeker niet.
Droom lekker verder. Waarom zou Microsoft zijn gebruikers willen pesten?
Ik denk dat je een smiley over het hoofd hebt gezien.
Kijk dat is mooi zeg nou nog sftp support in de explorer dat zou mooi zijn, en als ze toch bezig zijn voeg dan ook even support voor ext2/3/4 toe.
Ik denk niet dat dit op korte termijn gaat gebeuren. Tenslotte heeft het bij Linux ook lang geduurd voordat er fatsoenlijke ondersteuning voor NTFS stations werd ingevoerd. Daarbij kun je je afvragen wat de toegevoegde waarde is; hoevaak zul je een ext2/3/4 geformatteerd station op een Windows systeem aansluiten ?

Juist omdat veel apparaten hier geen ondersteuning voor bieden is het verstandiger om gewoon FAT32 te gebruiken, of als je bestanden van 4GB+ hebt kun je voor NTFS of eventueel exFAT gaan; hoewel laatstgenoemde volgens mij ook niet uitgebreid wordt ondersteund.
Dual boot pc's/laptops kunnen wel eens nut hebben aan ext ondersteuning in Windows. Momenteel is mijn data partitie op mijn laptop NTFS en dat zorgt voor de nodige overhead in Linux (wat ik het meeste gebruik). Moest Windows een werkende read-write implementatie hebben voor ext dan had ik die partitie wel in ext4 gemaakt.
Er bestaan wel tooltjes om ext partities te lezen in Windows, maar diegene dat ik geprobeerd heb waren niet echt handig of goed. Denk niet dat ze schrijf mogelijkheden hadden ook.

NTFS is volgens mij niet open en is dat de reden waarom het zo lang geduurd heeft voor je het in Linux volledig kon gebruiken. Reverse engineeren is namelijk niet zo simpel. Het zou voor MS al heel wat makkelijker zijn om een mooie ext implementatie te maken.

Als je een Linux gebruiker bent en een externe harde schijf hebt die je voornamelijk op je Linux toestellen gebruikt kan het ook heel leuk zijn wanneer Windows ext ondersteunt, dan kan je gewoon je externe schijf in ext formatteren en ben je van die NTFS overhead af in Linux. Als ext dan wat overhead heeft in Windows is dat niet erg.

Het zal waarschijnlijk niet zo veel voorvallen dat MS het een nuttige toevoeging vindt, of misschien zijn ze wel bang dat NTFS gebruik verminderd zou worden, dus ik denk niet dat we dit meteen zullen zien, maar het zou wel leuk zijn voor diegenen die het wel willen (zoals ikzelf).
Als je beide gebruikt dan is het makkelijk, er zijn genoeg dualbooters. Het verschil met exFAT en NTFS is dat ext opensource is en zou in die zin makkelijker te porten moeten zijn naar Windows, of het binnen korte termijnen gaat gebeuren... dat denk ik niet maar het zou wel een mooie feature zijn.

Het voegt natuurlijk wel een security issue toe bij het gebruik van Windows want dan zou een Windows gerichte malware specifiek gericht op deze feature dus ook een Linux systeem kunnen infecteren met wazige code.
Ik ben benieuwd of ze een vertaalslag zullen inbouwen, en ook de GNU commando's zullen gaan implementeren in Windows. Hoogstwaarschijnlijk niet, maar ik hoop dat er dan wat community members aan de slag kunnen gaan om daar een pack voor te leveren.
Als je Windows en Linux servers met exact dezelfde commando's en syntax, tot op zekere hoogte natuurlijk, kan beheren zou dat het leven van aardig wat sysadmins drastisch verbeteren lijkt me; scheelt zoveel tijd. :)

Microsoft hoopt weer wat marktaandeel terug te claimen denk ik zo. ;)
Wat bedoel je in vredesnaam met GNU commando's? Je weet hopelijk toch waar GNU voor staat (zie: www,gnu,org). GNU heeft (bijna) niets te maken met SSH of SSL van het nieuwsbericht.

Dat GNU voor diverse gebruikelijke *NIX tools een alternatief heeft, maakt het nog geen GNU commando... Ik heb het idee dat je naar Linux verwijst, waar i.d.d. (veel) GNU spullen (maar ook andere spullen in zitten). Echt er, voordat Linux er was, had je al vele jaren andere UNIX smaken, met dezelfde of soortgelijke commando's. En ook op die UNIX varianten zie je sommige GNU tools standaard aanwezig (bijv. gzip).

Daarbij, de gebruikte licentie van GNU (vaak GPL v2 of v3) heeft ook diverse nadelen. Als is dat een compleet ander verhaal.
GNU Software*
Verkeerd gephrased.

Er is bijvoorbeeld een GNU for Windows pakket. Dat zit standaard niet bijgeleverd natuurlijk, en de huidige pakketten zijn ook lichtelijk gelimiteerd.
Maar als dit geimplementeerd wordt in de SSH ondersteuning aan de Windows kant, waardoor je dus hetzelfde resultaat kan bereiken met exact hetzelfde commando + syntax onder zowel Windows als Linux, dan maakt dat het een stuk makkelijker en minder tijdrovend om bijvoorbeeld bash scriptjes te schrijven.
Daar is volgens mij de bash van cygwin een prima alternatief voor. Dat werkt eigenlijk hetzelfde als een UNIX shell (ik gebruik zelf op Unix bijna altijd ksh, maar bash lijkt daar ook sterk op).
Oh absoluut, maar als Microsoft standaard ondersteuning wil inbouwen in Powershell en de commando's wil laten rechttrekken (aldanniet de keuze bieden om Windows of Linux syntax te gebruiken in PS zelf), dan scheelt dat wel natuurlijk. :) Dan zal waarschijnlijk de integratie ook wat beter tot z'n recht komen.
Ik gebruikte altijd PuTTY voor SSH, maar dat is straks verleden tijd denk ik. Ik ben hier erg blij mee!
Putty is een terminal client waarmee je, onder andere, kan verbinden via SSH.

Wellicht breng MS ook een SSH client uit, maar ik denk dat dei eerder eenvoudig zal zijn (zeker in vergelijking met Putty) en dat het grote nieuws eerder de SSH server component is ;)
Dit is zeer interessant voor IT-specialisten die Powershell gebruiken in hun dagelijks werk om processen te automatiseren. Er gaat een wereld open m.b.t. het aansturen van Linux en Cisco op basis van native powershell-modules. Geautomatiseerd wijzigen/backuppen van configs op Cisco switches, Unix hosts aanpassen op basis van Powershell-condities...
Dit lijkt me een goede ontwikkeling voor alle systemen!
Zeer zeker... Ook custom monitoring scripts die via ssh uit te vragen zijn wordt zo heel makkelijk.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True