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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 238, views: 167.219 •
Geraadpleegde experts: jpm.lensen, Bor de Wollef, Cheatah, Radiant, TvdW

Compatibiliteit

Zoals eerder al aangegeven kunnen gebruikers van Windows Server compatibiliteitsproblemen verwachten als ze Server Core, of de versie met gui-ondersteuning maar zonder shell gebruiken. Ontwikkelaars wordt aangeraden om hun software zo in te richten dat alle handelingen die via een eventuele grafische interface kunnen worden uitgevoerd, ook zonder gui beschikbaar zijn. De grafische shell, indien aanwezig, zou optioneel moeten zijn. Microsoft geeft zelf het goede voorbeeld: zijn nieuwe Server Manager - mét Metro-interface - bestaat in feite uit een grafische schil waaronder PowerShell-commando's worden uitgevoerd.

Windows Server 8 Manager

Applicaties met een grafische interface kunnen problemen krijgen in de Windows Server-versie met minimale interface: problemen kunnen worden verwacht met shell namespace extension-api's en de common dialog box-library. Die laatste, die door applicaties wordt gebruikt om bestanden te openen of op te slaan, werkt alleen als het oude type wordt gebruikt: de nieuwe vereist aanwezigheid van Windows Explorer. Ook applicaties die Internet Explorer gebruiken zullen de nodige foutmeldingen weergeven. Daarnaast is Windows Help afwezig.

Ontwikkelaars kunnen hun applicaties aanpassen om deze te laten controleren welke Windows Server-versie is geïnstalleerd, door de waarden van bepaalde registersleutels uit te lezen of dism-api's te gebruiken. Daardoor kan een nette foutmelding worden weergegeven als gebruikers bijvoorbeeld Windows Help proberen te openen op een server die zonder shell draait.

Voor de Server Core-versie geldt dat software sowieso zonder grafische schil moet kunnen draaien. Dergelijke software moet dus via de command line of met configuratiebestanden kunnen worden bediend, al zijn remote beheersoftware of webinterfaces ook goed bruikbaar.

Of de grafische interface in een toekomstige versie van Windows Server helemaal verdwijnt, is volgens Snover nog onduidelijk. "We onthullen nog niets over nieuwe versies", zegt de lead architect, "maar een gui conflicteert met wat je van een server kan verwachten."


Reacties (238)

Reactiefilter:-12380232+1111+224+30
1 2 3 ... 7
Ja en nee. Ken genoeg server software wat nog steeds via een GUI geconfigureerd moet worden. Ik zie zeker de pluspunten ervan in m.b.t. de resources, maar niet alle software is aangepast hierop. Ken er bijna geen met uitzondering van webapps.

Dit zal zeker gaan aanslaan als de ontwikkelaars ook meegaan.
Daarom wordt er op de tweede pagina ook het volgende gezegd:
De grafische interface zal voorlopig nog niet helemaal uit Windows Server verdwijnen, omdat dat problemen kan opleveren met bestaande software.
Maar ja ze gaan je gewoon dwingen. Dat is een goede strategie naar mijn mening want een GUI is natuurlijk niets meer dan een interface wat commando's uitvoert waar je, ipv het commando in typt gewoon op een knopje klikt.

Ik vind de Linux manier in deze veel beter, in veel gevallen heb je software wat bediend moet worden via de command line en daarna zetten ze daar een GUI op waardoor je de GUI nooit nodig hebt

Edit: Ik ben wel bang dat ze een compleet losse terminal services versie gaan opzetten wanneer dit helemaal is doorgevoerd. Ik hoop dat de prijzen dan een beetje acceptabel blijven

[Reactie gewijzigd door Mellow Jack op 21 september 2011 09:16]

Mja, ik kom in mijn werk behoorlijk wat "beheerders" tegen die die term eigenlijk niet waardig zijn, die mensen zie ik echt niet met een commandline werken... Als MS ooit echt de GUI helemaal afschaft ben ik benieuwd of er dan een soort server lite versie komt (SBS?) die toch nog een GUI heeft, voor de beheerders die eigenlijk geen IT-er zijn maar het er bij doen zodat ze niet overal een extern IT bureau voor hoeven te betalen.
Ik vermoed dat ze dan eerder de kant opgaan van een webbased management console, naar goed voorbeeld van veel huidige NAS-sen, die volledig webbased te beheren zijn en toch flink wat functionliteit bieden.
Echte beheerder of niet, in veel gevallen vergemakkelijkt het je werk gewoon..
Vind ik ook. Soms is 2X klikken sneller dat een commando van 100 characters.
En soms moet je 100 x klikken voor een commando van 10 characters... Beetje non argument natuurlijk omdat het beide kanten op geldt
Het scheelt je echter wel een enorme learning curve voor nieuwe instroom. Niet iedereen is opgegroeid met een command line en een Gui leert makkelijker. Opleiding kost ook tijd en geld uiteraard :)
Het scheelt je echter wel een enorme learning curve voor nieuwe instroom. Niet iedereen is opgegroeid met een command line en een Gui leert makkelijker. Opleiding kost ook tijd en geld uiteraard :)
Het mooie van cmd-line (cli) is dat de leercurve juist minimaal is. Sinds jaar en dag zijn de commando's en syntax altijd het zelfde op iedere implementatie van OS en device, kijk maar eens naar Cisco, HP Procurve, Brocade, unix, linux, VMS etc. etc.

Enige wat anders is door de jaren heen dat er commando's bij komen. Maar de basale commando's van 20 jaar geleden gelden nog steeds, dir en ls betekenen nog steeds dir en ls, evenals sh int nnn op cisco etc. etc.

Het nadeel van GUI klikkers is dat ze ieder OS weer omgeschoold moeten worden omdat een fabrikant weer besluit om iets op een andere plaats te stoppen.

Persoonlijk wordt ik altijd verweten dat ik te veel naar de prompt ga of ssh gebruik, echter weet ik uit ervaring dat je met 1 commandoregel vaak meer kan bewerkstelligen dan met muisklikken. Neem als voorbeeld het commando for %f in (%temp%\*.*) do del "%f" & for /d %f in (%temp%\*.*) do rd /s /q "%f" wat vele malen sneller is om te typen dan eerst naar temp te navigeren, alles te selecteren en dan 30 keer Ignore te drukken omdat er gelockte bestanden tussen zitten.

En van vaste taken kan je altijd nog .cmd/.sh scripts maken eventueel in combinatie met powershel, vbscript of perl.

[Reactie gewijzigd door Wim-Bart op 21 september 2011 15:34]

Neem als voorbeeld het commando for %f in (%temp%\*.*) do del "%f" & for /d %f in (%temp%\*.*) do rd /s /q "%f" wat vele malen sneller is om te typen dan eerst naar temp te navigeren, alles te selecteren en dan 30 keer Ignore te drukken omdat er gelockte bestanden tussen zitten.
Lol, zei de nerd in hart en nieren. ;) Vat dit niet verkeerd op hoor, prima als het voor jou zo allemaal veel simpeler is. Maar tegen de tijd dat ik alle opties bij die commando's goed heb ingetikt, had ik de GUI-manier al minstens 10 keer kunnen uitvoeren. En je hoeft niet 30 keer 'ignore' te klikken trouwens. Daar heb je de shift-toets voor. Oftewel, ook met een GUI werken is een kunst. ;)
[...]

Lol, zei de nerd in hart en nieren. ;) Vat dit niet verkeerd op hoor, prima als het voor jou zo allemaal veel simpeler is. Maar tegen de tijd dat ik alle opties bij die commando's goed heb ingetikt, had ik de GUI-manier al minstens 10 keer kunnen uitvoeren. En je hoeft niet 30 keer 'ignore' te klikken trouwens. Daar heb je de shift-toets voor. Oftewel, ook met een GUI werken is een kunst. ;)
Dat is waar, maar de volgende keer dat je die operatie wil uitvoeren moet je dat weer 10 keer uitvoeren terwijl hij zijn batch file gewoon weer moet uitvoeren of schedulen.

Persoonlijk vind ik de gui op server niveau er ook teveel aan. Ik zou wel graag web console hebben voor management te doen omdat sommige taken wel eenvoudiger zijn.
wat jij hier aanstipt is echter nogal vergankelijk, een goed ontwikkelde gui zou je namelijk niet 100x vragen maar slechts 1 keer voor alle files die gelockt zijn...
dat windows dit niet goed doet, heeft te maken met een stukje 'luiheid' ondoordachtheid bij de ontwerper van de gui... niet met het point n click principe zelf...

met ander woorden je beschrijft hiet gewoon een bug/onvolkomendheid van 1 specifiek os.
Uhm die zijn allemaal Unix/Linux based of afgeleide daarvan. Bij MS zijn er nog wat commando´s anders (tenminste in Dos volgens mij)
Ten eerste lijkt hier een misverstand te ontstaan. Het is niet zo dat je een command line moet gaan gebruiken omdat de UI verdwenen zou zijn. De UI is er nog steeds, alleen de UI wordt geïnstalleerd op de client en niet op de server. Op die client is ook de commandline tool geïnstalleerd, en je gebruikt als beheerder het gereedschap dat op dat moment het beste resultaat geeft. Als ik in Exchange een groot aantal mailboxen op basis van vaste criteria wil verplaatsen naar een andere database, dan ben ik gek als ik dat één voor één in een UI ga doen. Als ik echter performance statistieken van een server ga analyseren dan heb ik toch liever een grafische UI met mooie duidelijke grafieken.

In het algemeen kan je zeggen dat bulk operaties beter te scripten zijn, en eenmalige acties zijn meestal wat makkelijker te leren met een UI. Het sneller leren van een UI moet niet onderschat worden. Het is voor veel bedrijven lastig om gekwalificeerd personeel te krijgen voor een acceptabele prijs. Voor kleinere bedrijven is het heel normaal dat een klein aantal beheerders de hele ICT infrastructuur moeten kennen. Daarnaast kan dan af en toe voor specifieke projecten een consultant worden ingehuurd. Dan houd het echter wel op.

Ik werk als beheerder bij zo’n relatief klein bedrijf en ik heb af en toe het idee dat ik een duizendpoot moet zijn. Ik beheer: storage, switches, routers, firewalls, mail servers, database servers, hypervisors, VDI, backup, monitoring server, configuratie server, etc, etc. Het is onmogelijk voor mij om van ieder product de kleinste details te kennen. Het zou voor mij werkelijk onmogelijk worden om het beheer te doen met uitsluitend commandline. Ik gebruik commandline als het zinnig is, maar ik ga niet mijn hele omgeving beheren vanuit bv. Powershell.
maar als je nu begint aan een opleiding heb je 0,0 aan de commando's die al jaar en dag gelden natuurlijk.

Vind de keuze van microsoft eigenlijk nogal opmerkelijk in een tijd dat hardware dusdanig krachtig is dat de grafische interface niet voor een gigantische belasting zorgt.
Vind de keuze van microsoft eigenlijk nogal opmerkelijk in een tijd dat hardware dusdanig krachtig is dat de grafische interface niet voor een gigantische belasting zorgt.
De keuze zou wellicht vreemd zijn als het gaat om een enkele fysieke server die afzonderlijk beheert zou worden. Voor die servers is een volwaardige UI wellicht heel nuttig. Er draaien echter soms vele tienduizenden virtuele servers in datacenters. Die servers worden constant van de ene fysieke server naar de andere getransporteert. Als die sever twee keer zo groot is dan kost dat twee keer zo veel bandbreedte. Het is voor dergelijke servers essentieel dat ze zo efficient mogelijk zijn.

Bovendien moet je je voorstellen dat een belangrijk argument van cloudcomputing is dat het flexibel en schaalbaar is. Stel je hebt ineens 100 extra virtuele webservers nodig omdat een bepaalde website ineens enorm veel aandacht krijgt. In dat geval worden die servers gecloned vanaf een template. Als die template twee keer zo groot is vanwege een UI dan duurt het twee keer zo lang voordat je capaciteit aan de vraag kan voldoen.

Een zeer groot aandeel van de servers wordt niet meer individueel beheert. Deze servers worden volledig geautomatiseerd geinstalleerd en geconfigureerd. Niemand logt meer in op deze servers, dus waarom zou je er een UI op zetten. Een UI kost alleen maar extra hardware en resources. Het is dan ook logisch dat Microsoft af wil van de verplichting om bij dit soort servers een UI te installeren. In Windows 2008 was er al de mogelijkheid om een core installatie te doen, maar veel server software kon niet overweg met de core versie. Producten als Exchange, SQL, Sharepoint, etc. konden alleen op de volledige versie geinstalleerd worden.

Daarnaast geldt nog steeds het argument dat alles wat niet geinstalleerd is, geen fouten kan bevatten die een beveiligingsrisico betekenen.

[Reactie gewijzigd door RazorBlade72nd op 23 september 2011 11:38]

Ik geloof al die nonargumenten, zoals processorbelasting, bugs en memory footprint van een gui dan ook niet.

Volgns mij is het omdat ze weten dat geen enkele beheerder nog niet dood met een metro interface voor zijn server gezien wil worden.
Verzer zie ik noet hoe je een degelijk beheerinterface in metro kwijt kan. Veel te veel opties.
Dus dan maar weglaten. Dat staat lekker Linux/Unix en zal wel beter vallen.

Tenslotte zullen het de beheerders zijn die beslissen welke hardware er gekocht gaat worden.

[Reactie gewijzigd door Durandal op 24 september 2011 12:49]

Het mooie van cmd-line (cli) is dat de leercurve juist minimaal is. Sinds jaar en dag zijn de commando's en syntax altijd het zelfde op iedere implementatie van OS en device, kijk maar eens naar Cisco, HP Procurve, Brocade, unix, linux, VMS etc. etc.
als je ziet welke mogelijkheden er zijn, dan zal je ze sneller onthouden en de volgende keer weten waar je op moet klikken, ipv het commando en de syntax ervan te moeten onthouden.
leukste "voorbeeld" is powershell. als ik daar af en toe in moet werken, gaat het haar op m'n rug rechtstaan, want quasi nix komt overeen met de command prompt commando's.

een GUI maakt het gebruik makkelijker, waarom zou dat plots niet zo mogen zijn met servers ? Moesten ze die keuze 20 jaar geleden gemaakt hebben had ik ze nog gesnapt, omdat resources toen écht duur waren.

Moesten de user en serverversies niet zo hard met elkaar verweven zijn, dan kon je gewoon de classic windows2000 GUI behouden, maar nu ze die domme metro interface in windows 8 proppen, beseffen ze zelfs wel hoe halstarrig ze bezig zijn om alles geforceerd naar elkaar toe te trekken ??
Ook dat valt om te draaien. Beheerders die in de jaren 80 of begin jaren 90 startten konden alles met de CLI omdat je op de PC's en PC netwerken simpelweg geen GUI had.

Ik ben van die generatie en heb met lede ogen toegezien hoe er steeds meer instant-beheerders in bedrijven rond kwamen te lopen die compleet hulpeloos waren als de GUI vastliep of het niet deed. GUI's hebben ook de neiging erg weinig informatie te leveren als een systeem niet goed werkt en je probeert te troubleshooten.

Regelmatig kom ik tegenwoordig beheerders tegen die helemaal verrast zijn als ze horen dat er nog iets anders is dan Windows en dat er echt systemen bestaan (Linux) die zonder GUI hun werk doen.

Die uitleg over de voordelen van een server zonder GUI door MS in het artikel is wel een verzameling dingen die elke ICT-er al jaren had moeten weten hoor.
Helaas zijn er legio die dit soort elementaire kennis niet bezitten en die moeten zich echt gaan schamen. In elk geval heeft Redmond het licht eens gezien.
Ik ben het helemaal met je eens.

Als er iets in de gui vast loopt is het via de cli eenvoudig te restarten en anders force killen.

Op een server hoort geen GUI te draaien dat vreet alleen maar resources die veel beter ingezet kunnen worden voor het uitvoeren van taken waarvoor de server ingezet word.
Ook een web GUI slaat nergens op want het enige wat je doet is resources verspillen aan een webserver die enkel en alleen draait om de beheerder een paar simpele commando's of scripts via point en click te laten uitvoeren.

Het word tijd dat opleidingen weer tijd gaan spenderen aan beheer via cli.
Laatste cursus die ik moest volgen was een cursus op expert niveau voor het beheren/distribueren/installeren/verwijderen/updaten van antivirus software... en dat alles met point en click.
(overigens had ik de basis cursus nooit gevolgd maar de expert cursus was qua niveau ook niet bepaald hoog te noemen, zegt wellicht iets over het niveau waarop de huidige beheerders werken en de grote weerstand hier tegen de cli)
Naar mijn idee had het met een cli veel sneller gekund (er werd gebruik gemaakt van een langzame web gui).

Point en Click computer beheer is leuk voor thuisgebruikers en services voor gebruikers beheerders zijn gewoon beter af met de cli.
Wat aan de andere kant natuurlijk maakt, dat de mensen die opgeleid zijn, wel waarschijnlijk ook beter weten wat ze doen.

Het is voor IT'ers natuurlijk interessant omdat zo het kaf van het koren gescheiden kan worden
Misschien moet je de post van Benne dan even anders lezen: Vaak is 2x klikken sneller dan een commando van 100 chars.

Een cliënt omgeving heeft niet voor niets een GUI. Als losse commando's intikken makkelijker zou zijn dan was er geen GUI. Beetje kort door de bocht, i know, maar het komt er wel op neer.
Kunt zelf een .bat of .btm script in elkaar knutselen als je teveel handelingen moet uitvoeren. Voor een dergelijke script heb je heel weinig kennis nodig, en je kunt ook gewoon een basic menuutje in elkaar scripten.
Voordelen van een kale windows zijn belangrijker dan de kleine investering die wordt gevraagd. Verschil in opleiding/kwaliteit zal nu wel duidelijk zichtbaar worden, echter W2k8 was al een signaal dat microsoft de cmd belangrijker wil maken. Toch weer 4 jaar de tijd gehad om enkele modules te volgen. En tegen de tijd dat dit weer gemeengoed is, zijn ze al weer twee jaartjes verder.
maak je aliassen voor aan (linux), script's, macro's, robot's of whatever
in gui-land ga je herhaaldelijk van keyboard > muis > keyboard > muis > ..
in terminal-hemel blijf je productief(er) omdat je handen in dezelfde positie blijven.

maar goed dit is eeuwige discussie - maar net waar je persoonlijke afwijking ligt

[Reactie gewijzigd door himlims_ op 21 september 2011 19:00]

Ik gebruik standaard de gui maar heb cmd ook in me taakbalk gepint omdat allebij zo nu en dan hun voor en nadelen hebben idd.
En soms moet je 100 x klikken voor een commando van 10 characters... Beetje non argument natuurlijk omdat het beide kanten op geldt
Waarom is dat een non-argument dan? Je beaamt precies juist wat Benne zegt: dat zowel een GUI als 'GUI-loos' beiden een eigen bestaansrecht hebben. Maar laat dat nu net dus de weg zijn die Microsoft niet in lijkt te willen slaan.
Jawel. Je mag gewoon de beheer tooling installeren op je Windows 8 machine, vervolgens tik je daar in dat je die server wilt beheren, en tadaa, geen gui meer nodig op je server.
Echte beheerder of niet, in veel gevallen vergemakkelijkt het je werk gewoon..
En dat gaat altijd nog met remote tools of de commandline :)

GUI op server is leuk voor de heb, maar totaal overbodig :D
De GUI verdwijnt misschien op de server, maar configuratie zal dan remote gebeuren. Iemand start dan met de juiste credentials gewoon een grafische interface op zijn desktop waarmee alles geconfigureerd kan worden.
Zo'n grafische interface zal dan niets anders zijn dan een programma op je desktop dat via remote powershell de windows machine kopieert (zie ook hierboven wat Microsoft zelf doet met het Server Manager Dashboard.
Exchange managen is simpel, installeer de Exchange Management Tools op een werkplek en je kunt de boel beheren.
SQL beheren, hetzelfde.
Event log worden door SCOM (of iets soortgelijks) uitgelezen en weergegeven aan de beheerders, die vervolgens actie kunnen ondernemen.

Het beheren van de server zal dus veel meer remote gebeuren, in plaats van rechtstreeks op de machine.

Ik vind het wel een goede zet overigens. Het OS zelf vreet dan minder resources,
Wel mooi blijft de volgende quote : Those who don't understand UNIX are condemned to reinvent it, poorly.
De GUI verdwijnt misschien op de server, maar configuratie zal dan remote gebeuren. Iemand start dan met de juiste credentials gewoon een grafische interface op zijn desktop waarmee alles geconfigureerd kan worden.
Waarna je dus alsnog patches nodig hebt voor dié interface. En als dat gehacked kan worden, kunnen ze waarschijnlijk (nog) makkelijk(er) bij je server, waar je 'elevated' bent.

MS is groot geworden omdat mensen gewoon een grafische schil willen/nodig hebben. Mensen reageren simpelweg beter en sneller op iconen/plaatjes dan tekst.

Het is een stomme set. Net zoals Metro op niet-touchscreens.

Wie heeft er ooit een command-line OS gezien in Star-Trek? Niemand. Waarom? Omdat het geen toekomst heeft :P haha. (uh oh, hier komen de bashers op af }> )
Bedoel je soms: Library Computer Access/Retrieval System? :z

[Reactie gewijzigd door Liberteque op 23 september 2011 13:13]

Wie heeft er ooit een command-line OS gezien in Star-Trek? Niemand. Waarom? Omdat het geen toekomst heeft :P haha. (uh oh, hier komen de bashers op af }> )
Moest gelijk hier aan denken:
http://media.photobucket....jeumdewq/th_data-bsod.gif :+

[Reactie gewijzigd door Raven op 21 september 2011 11:28]

Nee, daar lopen ze de systemen te programmeren/configureren door middel van hardwarematige aanpassingen. Dat is beter wil je zeggen? :P
Het mooiste vind ik dat controle panelen altijd ontploffen, wie mafketel bedacht heeft dat het handig is om alle "main power" kabels door de controle kamer te laten lopen is me een raadsel.
Nee, Microsoft is juist groot geworden door de command line, namelijk MS-DOS waarna het met Windows 3.11 kwam wat eigenlijk Windows op MS-DOS kwam toen werd de command line geschrapt en was het GUI only geworden. En iedereen stapte over omdat ze het al kenden van MS-DOS

@svenk91 Bedankt

[Reactie gewijzigd door Edek op 21 september 2011 20:00]

Met windows 2000/xp werd het pas gui only. Windows 98 en ME draaiden nog lekker bovenop dos.
Ben blij dat met deze stap eindelijk (meer) gepromote wordt beheer op een beheerserver/werkstation te doen en niet op de server zelf.

Over het algemeen zijn servers gesized om een specifieke taak te uit te voeren -- en daarin wordt niet een GUI + allerlei applicaties meegenomen. Het inloggen alleen al kan een negatieve impact hebben op de performance van een server...

[Reactie gewijzigd door pistole op 23 september 2011 21:24]

Wat een onzin statement, alsof het één iets met het ander te maken heeft. Ik kan hier ook wel gaan roepen dat de gemiddelde Linux / CLI klopper een puisterig, in zwart met kettinkjes gehuld wereldvreemd figuur is waar je niet normaal mee kunt praten, maar ook dat zou onzin zijn, niet waar?

Feit is dat je via de GUI veel zaken veel sneller en overzichtelijker kan regelen. Ik vermijd zelf CLI's waar mogelijk. Ondanks dat denk ik dat ik met de meeste zelfverklaarde "goeroe's" volledig de vloer aanveeg.
Feit is dat je via de GUI veel zaken veel sneller en overzichtelijker kan regelen
Maar het is ook een feit dat je via de CLI veel dingen veel sneller kan als je weet waar je mee bezig bent. Een windows voorbeeldje: iisreset intoetsen is vrijwel altijd sneller dan IIS via een GUI te resetten.

Onder Linux een programma installeren kan vrijwel altijd via een apt-get commando. Als je iemand wil uitleggen hoe je een programma installeert kan dat in 1 lijn tekst. Geen GUI kan daar tegenop.

Als je de CLI bewust vermijd ben je naar mijn mening geen volwaardige nerd.
Een windows voorbeeldje: iisreset intoetsen is vrijwel altijd sneller dan IIS via een GUI te resetten.
Dus omdat jij een voorbeeld kan verzinnen waarvoor het geldt gaat het ook altijd op? In jouw voorbeeld heb je totaal geen data nodig (sowieso, de enige reden waarom jouw voorbeeld werkt is omdat er wel een handig CLI commando voor is maar geen handige GUI knop). Maar als je met veel data werkt is een GUI al vrij snel een stuk rapper. Denk aan het configureren van die ene firewall rule uit een lijst van 100 rules. Het kost je vanuit een CLI veel meer tijd om er te komen en de juiste te vinden en dan de benodigde aanpassingen te maken dan met een GUI.

Er is zoiets als the right tool for the job, en dat kan zowel CLI als GUI zijn, afhankelijk van de situatie.

[Reactie gewijzigd door .oisyn op 21 september 2011 11:35]

en daarvoor zijn dus scripts uitgevonden (hoewel ik betwijfel of jou firewall voorbeeld met de gui echt wel sneller is). Jammer dat automatisering van de gui nog steeds zwarte magie is.
[...]

Dus omdat jij een voorbeeld kan verzinnen waarvoor het geldt gaat het ook altijd op? In jouw voorbeeld heb je totaal geen data nodig (sowieso, de enige reden waarom jouw voorbeeld werkt is omdat er wel een handig CLI commando voor is maar geen handige GUI knop). Maar als je met veel data werkt is een GUI al vrij snel een stuk rapper. Denk aan het configureren van die ene firewall rule uit een lijst van 100 rules. Het kost je vanuit een CLI veel meer tijd om er te komen en de juiste te vinden en dan de benodigde aanpassingen te maken dan met een GUI.

Er is zoiets als the right tool for the job, en dat kan zowel CLI als GUI zijn, afhankelijk van de situatie.
En voor werk met veel data is CLI in mijn opinie altijd nog het snelste :) Eventjes een AD kopieeren, welkom in de wereld van CLI, of een DHCP server vervangen met behoud van data maar wel met andere naam en nieuw OS, welkom in de wereld van CLI. Of dagelijks even een handmatig rapportje draaien, CLI en scripten.

Jee, als je het toch kan scripten of met CLI kan doen, dan kan je bepaalde taken gewoon automatiseren en houd je van 40 uur per week beheer opeens 2 uur over waardoor je 38 uur lang kan stoeien met leuke en nieuwe dingen :D

[Reactie gewijzigd door Wim-Bart op 21 september 2011 16:06]

sowieso, de enige reden waarom jouw voorbeeld werkt is omdat er wel een handig CLI commando voor is maar geen handige GUI knop
Vind ik ook, en een snelkoppeling maken naar iisreset op het bureaublad is nog sneller natuurlijk
Jep doe dat met elke handeling en je bureaublad wordt een zooitje! (als je dan een x downtime hebt duurt het booten lekker lang }> zeker met windows! :X )

Op internet kun je hele handige vellen vinden met de commando´s voor in CLI en terminal. Daarnaast met een beetje Perl of bash kun je ook aardig scripten ;)
mapje op je bureaublad?

Clean Desk Policy Mandatory Mode: off
Tuurlijk. Een simpel commando is sneller te doen via een CLI. Ik erger me echter vaak dood aan "Guru's" die bv een complete firewall gaan zitten inrichten via de CLI en halverwege niet meer weten welke impact de eerder ingevoerde regels precies hadden met als gevolg een firewall die zo lek als een zeef is. Een GUI waar je vele malen meer informatie kan krijgen over je configuratie maakt de zaken dan niet alleen sneller, maar ook veiliger.

Gui en Cli kunnen prima naast elkaar bestaan maar voor complexere aangelegenheden heb je veel meer aan een (goede) Gui dan aan een Cli.

Deze stap van Microsoft is dan ook in mijn ogen geen stap richting Cli, maar een stap richting remote beheer. Simpele snel te installeren (virtuele) servers en goede tools waarmee vanuit het kantoor de servers beheerd kunnen worden.
Tuurlijk. Een simpel commando is sneller te doen via een CLI. Ik erger me echter vaak dood aan "Guru's" die bv een complete firewall gaan zitten inrichten via de CLI en halverwege niet meer weten welke impact de eerder ingevoerde regels precies hadden met als gevolg een firewall die zo lek als een zeef is. Een GUI waar je vele malen meer informatie kan krijgen over je configuratie maakt de zaken dan niet alleen sneller, maar ook veiliger.
dus met een GUI weet je opeens wel wat je doet? Hoe maakt het het veiliger als ik eerst de eigenschap knop moet aanklikken voordat ik alle eigenschappen van een firewall rule wil zien in Win2k8 ? Scope in 1 opzicht zien? onmogelijk,

Kijk ik daarentegen naar de gemiddelde IPFW/iptables config file zie ik daar in 1 opzicht een stuk meer.

dus sneller en ook veiliger? Wat een rare conclusie. Je zei het zelf al beter in je intro, met iets andere woorden: PEBKAC

[Reactie gewijzigd door DLGandalf op 21 september 2011 12:46]

Neem een Cisco ASA of een Cisco PIX. Config file geeft zo veel meer info en inzicht dan al die andere pagina's waar je tussen moet schakelen en je op papier een trail moet bijhouden van je bevindingen.
In de SLI maak je sneller een type fout en in de GUI maak je sneller een klik fout.
Een vinkje net naast waar je hem graag wilt hebben, een protecol koppelen aan net de verkeerde adapter. Het is in de GUI zo gedaan.

MAW onzorgvuldige fouten zijn er altijd zo gemaakt. Waar je meer aan hebt of waar je sneller mee werkt ligt voor een zeeeer groot gedeelte aan wat je gewent bent.

Het voordeel van een CLI en uitgebreide commando's is ook dat je door een paar simpele copy paste actie's heel veel dingen klaar krijgt.
Gui en Cli kunnen prima naast elkaar bestaan maar voor complexere aangelegenheden heb je veel meer aan een (goede) Gui dan aan een Cli.
In mijn ervaring zijn GUI's juist te beperkt voor de complexere dingen en is het voor dat soort dingen eenvoudiger om de terminal in te duiken en daar verschillende programma's aan elkaar te knopen om je probleem op te lossen.
Als je de CLI bewust vermijd ben je naar mijn mening geen volwaardige nerd.
Nerd is gelukkig ook niet synoniem voor systeem BEHEERDER.

Het voordeel van een gui is dat je alles in een overzichterlijk formaat kan weergeven. En een typefout maken is in een gui ook veel lastiger.

Het is zo onzinnig om te zeggen dat de CLI altijd beter is dan de GUI en als je de CLI niet gebruikt je geen nerd of echte beheerder bent... Get a life, 98% van de beheerders gebruikt de GUI: maar de 2% die dat niet doet weet het beter. Sure...

Ik neem aan dat je dit hebt getikt in Lynx toch? Anders ben je wel echt een noob web user hoor...
@osiyn en Mecallie
Ik heb niet gezegd dat de CLI altijd beter is. Ik heb niet gezegd dat ik een GUI vermijd. Ik heb gezegd dat de GUI niet altijd beter is en ik heb gezegd dat ik het niet slim vind om de CLI te vermijden.
Ik heb niet gezegd dat de CLI altijd beter is
Nee, maar je zegt wel voor veel dingen, wat ik enorm betwijfel. Wel frappant dat je juist niet reageert op de imho zeer inzichtvolle post van humbug.
En een typefout maken is in een gui ook veel lastiger.
In een gui vind ik dat juist veel makkelijker. Een TUI dwingt je op te letten, en dat is precies wat je wilt. Een GUI is prima op desktops, maar op servers is een shell het enige wat ik wil zien.

ik doe via de shell dingen sneller dan veel van m'n collega's via de gui voor elkaar krijgen, van simpele dingen tot complexe dingen. Dat heeft gewoon te maken met de nodige kennis en ervaring hebben. Ze zijn minstens net zo slim als ik ben, dus daar ligt het zeker niet aan.

Een GUI vind ik veel te snel alles zoekmaken in een oerwoud van pulldowns, tabbladen en radiobuttons. Een configfile is simpel, overzichtelijk. True, het vergt misschien iets meer leerwerk. Hoort bij 't vak.
[...]
Ik neem aan dat je dit hebt getikt in Lynx toch? Anders ben je wel echt een noob web user hoor...
Ahh, hier wil ik tegen bashen!
Lynx is een text interface, maar geen command line interface! Sterker nog, lynx komt meer in de buurt van een graphic user interface. Ik zou het eventueel een visual user interface of text interface application noemen.
Nee, als je een CLI browser wilt hebben, gebruik dan telnet, ftp of snort, maar lynx is geen command line tool!

Dan even terug naar de focus: microsoft maakt een expliciete scheiding tussen functionaliteit en user interface. Door deze scheiding af te dwingen is er nagenoeg geen verschil meer tussen lokaal iets instellen of remote iets instellen; beide frontends praten tegen dezelfde backend (via http, rpc, commandline/ssh/telnet of proprietary TCP protocol).
Waar voorheen een scheiding lag in de WIN32/COM32/OLE laag, wordt dit nu gedaan in de TCP laag. Maakt dat voor de gebruikservaring iets uit? Ja, je moet perse altijd inloggen omdat je niet meer (per definitie) op één en dezelfde machine zit. Hebben we daar last van? Waarschijnlijk niet.

Het grappige (zonder zijde te kiezen), is dat dit al langer gemeen goed was bij *NIX servers, immers worden die beheerd via SSH of SSH/HTTP frontends. Denk hierbij aan PHPmyAdmin. Microsoft zet deze trend voort door GUI's zo ongeveer te verbieden, en mocht je dan toch via een website configureren (waarbij de "GUI" engine toch op de server draait, maar lokaal gerendered) dan is de processorkracht daarvoor alleen nodig tijdens configuratie, daarna kan dat deel van de applicatie gewoon afgeschoten worden (zoals een thread van een PHP applicatie).
Een beheerder gebruikt wat hij kan. Als je in een omgeving zit van 9000+ gebruikers en je moet iets voor veel gebruikers aanpassen dan script je de boel in Powershell met het grootste gemak. Even voor een 1.000-tal medewerkers een extension attribute aanpassen of mailboxen voor alle marketing medewerkers vergroten doe je niet met de hand. Voor een account kan je dat best met de gui doen, al is het met een zelfgemaakt cmd-let nog steeds sneller.

Meer en meer Microsoft producten zijn te beheren via Powershell. Probeer maar eens Office 365 mailboxen te beheren...

Maar ook ik verbaas me over de onwil om te leren scripten en te cmd-line-en onder veel windows admins.
Maar ook ik verbaas me over de onwil om te leren scripten en te cmd-line-en onder veel windows admins.
Een beheerder die niet kan scripten is dan ook niet meer dan een junior beheerder :)

Of iemand die andere zaken belangrijk vindt en daar goed in is. Maar voor een goede beheerder is scriptkennis, ook al is met basiskennis in mijn ogen onmisbaar.

[Reactie gewijzigd door Wim-Bart op 21 september 2011 15:45]

ja, dat dacht ik vanmiddag dus ook.

iisreset gebruikt; wazige melding teruggekregen dat de services niet binnen de beschikbare tijd reageerden.
IIS manager gestart, en reset aangeklikt.. en binnen 3 seconden een reactie.

ofwel; het intypen ging een stuk sneller, maar via de GUI reageerde het weer een stuk sneller.
Dat klinkt als sluitend bewijs...

Kan het niet zo zijn dat door de command de IIS al een keer was gereset voordat je de IIS manager had opgestart waardoor deze op dat moment wel weer goed reageerde?

via de GUI krijg ik ook meldingen dat een proces niet reageerd. Als je dan in de CLI zit is een eenvoudige opdracht om te killen zo klaar, in de GUI moet je eerst naar de taskmanager het proces zoeken en dan killen.
Op een Ubuntu/Debian server werkt APT(-get) inderdaad als een trein. Maar stel je hebt een gentoo/Slackware server?

Vanaf source compileren kan een bitch zijn:

tar xvf softwarepakket.tar.bz2
cd softwarepakket
./configure && make && sudo make install

Kan bij een groot pakket aardig lang duren.

[Reactie gewijzigd door sfranken op 22 september 2011 03:10]

Het van de source compileren lang kan duren heeft niets met CLI of GUI te maken dat duurt in beide gevallen net zo lang.
Maar als ik ergens een help site vind met een pakket dat mij kan helpen dan staat er vaak de juiste grep enz er direct bij dan is het CRTL-C en CRTL-v en klaar ben ik. :)
Op Gentoo ga je ook niet handmatig source compileren. Daarvoor gebruik je ook gewoon een standaard progsel als apt-get, alleen heet het onder Gentoo dan emerge. FYI Gentoo's portage systeem biedt trouwens ook de mogelijkheid om binary packages te installeren.

Maar installeren van packages gaat via de meeste distro's behoorlijk eenvoudig. Vaak kun je ook gewoon na het typen van de beginletters van een package een paar keer op de TAB toets en pijltjes toetsen rammen (Als je je shell hip geconfigureerd hebt) voor autocompletion. Moeilijk is de CLI dan niet meer.

[Reactie gewijzigd door onox op 22 september 2011 14:40]

Geloof ik niet. Met CLI's kan je veel sneller werken omdat je echt heel veel commando's achter elkaar kan maken waardoor je in 1 line verschrikkelijk veel dingen kan doen.
Iets wat je in een GUI nooit snel voor elkaar krijgt.

Bij een GUI zit er een limiet aan jou snelheid van handelen. Bij een CLI kan je veel efficiënter werken en je snelheid is afhankelijk van je typsnelheid en kennis van CLI.

Dus dat sneller is onzin. Overzichtelijker is een mening wat bij iedereen kan verschillen. Het is een gevoel wat je bij iets hebt of iets overzichtelijk is of niet. Dus gewoon jou gevoel erbij.

Voor Windows admins is een cursus powershell en dergelijke denk ik wel heel belangrijk. Ik zelf ben wat meer bekend met Linux.

[Reactie gewijzigd door Texamicz op 21 september 2011 11:18]

"Geloof ik niet. Met CLI's kan je veel sneller werken omdat je echt heel veel commando's achter elkaar kan maken waardoor je in 1 line verschrikkelijk veel dingen kan doen.
Iets wat je in een GUI nooit snel voor elkaar krijgt."

Maar 10 een vinkje aanvinken en apply drukken is sneller dan 10X een commando invoeren. Als het een goede GUi is natuurlijk.

Dus ja elk heeft zijn voordeel.
Je gaat niet 10x een commando invoeren 8)7 Je voert 1 commando in die met 10 dingen iets doet.
Dus dat sneller is onzin.
Neem een map met honderd bestanden. De bestandsnamen zijn voornamen, zowel mannen als vrouwen, geen namen die voor zowel mannen als vrouwen gebruikt worden.
Verwijder alle mappen met mannelijke namen.
Dit ga je echt niet sneller doen in een CLI. Selectie gaat veel sneller in een GUI.
get-childitem | where-object { $_.PsIsContainer} | remove-item -Confirm
Nu heb je nog niet enkel de 'mannen namen' of 'vrouwen namen' te pakken.
En op welke basis wilde je die selectie maken? Dat doet de user dus met aanklikken (GUI) of yes/no (CLI).
Jup, maar een selectie in een venster met een lijst (GUI) gaat veel sneller dan regel voor regel ja of nee kiezen. Dit komt omdat mensen visueel ingesteld zijn
En dan druk je per ongeluk na 130 selecties op [shift] in plaats van [ctrl] :)
Kwestie van het in KDE* doen. Daar kan het zonder :P

http://userbase.kde.org/i...olphin_folder_hovered.png

Overigens is CLI niet perse sneller dan GUI en andersom. Mijn foto's sorteer ik stukken makkelijker in een GUI ;-) Daarentegen installeer ik een pakket weer sneller met een command in de GUI. F12 roept Yakuake op (console) en 'zypper in pakket' maakt het af. Mochten er veel dependency problemen zijn dan kies ik weer voor GUI.

Conclusie van mijn verhaal: Het zijn geen concurrenten maar ze zijn goed in hun eigen ding en kunnen elkaar dus aanvullen.

*Voor een server veel te zwaar maar je snapt het punt...overal is een oplossing voor

[Reactie gewijzigd door BartOtten op 22 september 2011 22:53]

Je moet ook geen GUI practices in een CLI gaan toepassen :) Handiger is om een lijst van mannelijke namen aan te maken en dan door de bestanden in de folder te itereren en vervolgens de bestanden te verwijderen waarvan de naam matcht met een element uit de lijst. Zoiets moet echt te doen zijn in een paar regels in (bijv.) Python :) Kost minder tijd dan handmatig een folder te gaan lopen scannen met je ogen. Als het om een folder gaat met een beperkt aantal bestanden, dan is het nog wel te overwegen om dit handmatig in een GUI te doen. Maar als je folder hebt met heel veel bestanden, dan is de keuze snel gemaakt ;)
[...]

Neem een map met honderd bestanden. De bestandsnamen zijn voornamen, zowel mannen als vrouwen, geen namen die voor zowel mannen als vrouwen gebruikt worden.
Verwijder alle mappen met mannelijke namen.
Dit ga je echt niet sneller doen in een CLI. Selectie gaat veel sneller in een GUI.
Ben ik niet met je eens: del /p *.*

Zelfde actie, en gewoon ja of nee geven :)

Edit:
Daarnaast, is Anne een man of een vrouw?

[Reactie gewijzigd door Wim-Bart op 21 september 2011 16:08]

@Zer0: Wat je daar schrijft, getuigt niet van veel inzicht.

Jouw voorbeeld gaat enkel maar op omdat de computer het verschil niet kent tussen een jongensvoornaam en een meisjesvoornaarm.

Dit komt omdat er geen vastliggende criteria zijn om te bepalen wat een jongensvoornaam of een meisjesvoornaam is. Als jij de eerste wil zijn die de criteria ondubbelzinnig kan geven, probeer maar...

Het zal je nooit lukken, je geeft zelf al aan waarom, er zijn immers voornamen die zowel voor jongens als voor meisjes gebruikt kunnen worden)

Neem een map met tienduizend bestanden en verwijder alle bestanden die eindigen op de letter n.

Deze stelling is bijna gelijk aan de jouwe, alleen, hier ligt het criterium wel ondubbelzinnig vast. En in dat geval geldt net het omgekeerde:

Dit ga je echt niet sneller doen in een GUI. Selectie gaat veel sneller in een CLI.

Waarom? Omdat de computer heel snel kan selecteren (honderden bestanden per seconde), als jij dat manueel met de CTRL-toets en het klikken van je muis moet doen, zal 't iets langer duren en dat is dan nog zacht uitgedrukt.
Met Webmin moet je een Windows bak ook aan kunnen sturen via de browser: http://www.webmin.com/windows.html Hier staat hoe dat moet.
Wat een ongelooflijke BS praat je hier zeg

Alsof een Systeembeheerder niet goed zou zijn omdat hij/zij een GUI gebruikt
En waarom geen CLI interface?
Gebruiksvriendelijkheid bieden zonder een grafische schil te moeten voorzien.
Dat zorgt voor twee vliegen in één klap ... je bespaart resources en je biedt toch een goed overzicht tijdens het installeren/configureren van services.

Op de mainframe doen ze het al tientallen jaren. Een standaard TSO omgeving is tientallen keren gebruiksvriendelijker dan de huidige Linux-omgeving. Op CICS zijn ook al honderderden frameworks beschikbaar die met menu's en kleuren (als de terminal het ondersteunt) alles mooi en proper voorschotelen aan de gebruiker.
Soms is het daar zelfs mogelijk om met een muis te werken.

Een grafische schil is het niet, wel een CLI-interface.
OK ... geen icoontjes, 100-en lettertypes, logo's en gradients, maar geef toe ... in 99% van de gevallen is toch enkel de tekst belangrijk.

Nee ... vandaag de dag moet ik nieuwe software installeren via een apt-get die met 20 lijnen onoverzichtelijke tekst al flitsend over het scherm moet komen vertellen dat hij nog 2Mb extra dependencies moet installeren.
Dat kan toch mooi in een CLI-dialoogbox?

En als ik wat vreemdere software moet installeren, kan ik via de configure, make en make install commando's 1000'en files over het scherm zien flitsen die ik zelfs niet kan lezen omdat het allemaal zo snel gaat.
Een dialoogbox met een mooie teller van 0 naar 100% is te makkelijk?
En even vriendelijk maar toch opvallend aan de gebruiker laten weten wanneer iets foutgelopen is ... die foutboodschap bevat dan uiteraard wel genoeg informatie en niet gewoon 'Error!'.

Of laten we de software even configureren ... een ellenlange configfile omdat elke lijn moet voorafgegaan worden door 20 lijnen commentaar.
Of via de configtool 100 keer op enter moeten duwen om de standaardwaarde te nemen en dan één maal teveel op enter geduwd te hebben, zodat je opnieuw kan beginnen.
Zou het niet makkelijker zijn om door een gebruiksvriendelijke configprocedure geleid te worden?
Een schermpje met verschillende pagina's waar we even de correcte optie met [X] kunnen aanduiden of een path specifiëren door je files toch te kiezen via een file dialog (in CLI is dat perfect mogelijk ... maar nee ... de beheerder moet maar weten waar al zijn files staan).
Dit uiteraard allemaal op die manier dat de gebruiker (of beheerder ... al is dat hetzelfde ... ze horen het alleen niet zo graag) snel kan switchen tussen de betreffende pagina's, zodat hij snel naar de desgewenste optie kan gaan.
En oh ja ... het is maar een interface voor diezelfde configfile natuurlijk ... de expert van het bedrijf kan bij onverwachte problemen nog even wat prutsen in de configfile ...

Het is allemaal geen rocket science ... het bestaat al tientallen jaren ... kijk trouwens maar naar de installatieprocedure van vele linux distro's (of het aanpassen van de kernel, al is dat ook wel voor verbetering vatbaar).

Wat zeg je?
Teveel tijd (en dus geld) voor programmeurs om zoiets te maken voor elke applicatie die ze maken?
Absoluut waar, maar:
- Als de linux community nu een bepaald framework maakt hiervoor ... moet je enkel nog de configopties en bepaalde retricties eraan vastleggen en je menu wordt voor je geprepareerd. Dan kan het misschien zelfs nog sneller dan zelf een configtool te schrijven. Noem het een .NET/Mono framework voor de CLI interface.
- Als het dan toch duurder zou uitvallen, kan je hier gerust mee pronken ... het zou je een hele hoop 'beheerders' opleveren die voor je oplossing kiezen. Kijk naar het beste voorbeeld binnen de Linux-community: Ubuntu. De 'eerste' gebruiksvriendelijke Linux en al meteen het eerste waaraan gedacht wordt als het woord 'Linux' valt in de koffieruimte.

Ik wil maar zeggen ... je zou niet moeten kiezen tussen gebruiksvriendelijkheid en performantie. Combineer de beide gewoon ... de 'experts' kunnen wat ze voorheen konden en de minder begaafde/beschaamde beheerder kan ook verder zonder in te moeten boeten aan performantie.
Hoewel ik het niet eens ben met je gedachtegang, wil ik je toch op een aantal dingen wijzen die je wellicht kan waarderen.

In Debian-based distributies kan je aptitude intypen voor een TUI programma om software te installeren. Leer jezelf ook aan programma's te installeren via aptitude (niet via de tui omgeving echter, maar direct vanaf de prompt, dus aptitude install <pakket>)

En Red Hat levert heel veel TUI based programma's mee. Bijvoorbeeld om de Firewall te configureren. Deze wil ik nog weleens gebruiken om bijvoorbeeld snel poort 80 open te zetten.
Een standaard TSO omgeving is tientallen keren gebruiksvriendelijker dan de huidige Linux-omgeving. Op CICS zijn ook al honderderden frameworks beschikbaar die met menu's en kleuren (als de terminal het ondersteunt) alles mooi en proper voorschotelen aan de gebruiker.
Soms is het daar zelfs mogelijk om met een muis te werken.
Ook op linux kun je ook wel met ncursus of andere non-x omgevingen werken, ik werk dagelijks op TSO systemen en ik zie het verschil niet echt.

Feit is dat je met een GUI vaak nooit de flexibiliteit en beheersbaarheid van een CLI kunt vervangen en dat je omgekeerd met de CLI vaak slechts door je eigen (gebrek aan) kunde gehinderd wordt maar in feite dezelfde functionaliteit kunt krijgen als de GUI.
Neem niet weg dat in sommige gevallen een GUI een welcome aanvulling kan zijn wat betreft gemak en natuurlijk voor de minder onderlegde systeembeheerder de eerste keus is (ik gok dat dat de reden is dat er zo'n verhitte discussie is over deze wijziging).

[Reactie gewijzigd door blouweKip op 21 september 2011 16:46]

ncurses wordt inderdaad gebruikt voor bijvoorbeeld de kernel te configureren en dat is reeds aangehaald.
Ik ken bijvoorbeeld geen enkel ander weidverspreid programma dat ncurses gebruikt om een programma te installeren/configureren.
*edit*: blijkt dat aptitude gebaseerd is op curses

Ik ben absoluut niet tegen het verwijderen van de GUI ... een server draait nu eenmaal voor zijn services en dan is de performantie prioriteit 1.
Het opzetten en configureren ervan zou echter ook geen 'pain in the *ss' mogen zijn.

[Reactie gewijzigd door Nullius op 21 september 2011 18:38]

sudo apt-get install (package) | pv

Krijg je een heeeeeele mooie voortgangs balk.
Het feit dat er onder Linux gevraagd wordt om dependentie's bij het installeren heeft niets te maken met CLI of GUI, maar met de systeem architectuur.
Als ik in Windows ook iets wil installeren wat met .NET 3.5 nodig is en ik heb het niet dan moet ik dat ook extra installeren.

Tevens klaag je dat de tekst te snel over het scherm vliegt om te kunnen lezen, inplaats daarvan wil je het helemaal weg laten zodat je het nog steeds niet kan lezen. Wat schiet je daar mee op dan?

Je kan Linux CLI en Windows GUi niet 1 op 1 vergelijken omdat de hele systeem anders is! Het blijft een stukje voorkeur en gewenning en sommige dingen gaan sneller via GUI en andere sneller via CLI.
Maar als je gewend bent om via de verkenner bestanden te vinden is het vooral een stukje gewenning om het via de CLI te doen en vooral de TAB bij het afmaken van bestands namen of directory's kan heel snel werken.
Waar zeg ik ergens dat het een probleem is dat er dependencies moeten geïnstalleerd worden?
Ik zeg alleen maar dat dat in een mooi overzicht kan ipv plain text zonder enige vorm van layouting.

Verder heb ik ook niet gezegd dat je alles moet weglaten van de flitsende tekst ... meestal ben je echter enkel geïnteresseerd in die dingen als er een warning of error voorkomt.
Een mooi dialoogscherm met een voortgangsmetertje en op het einde een overzicht van het aantal warnings en/of error. In dat schermpje kan de gebruiker eventueel zelf de warnings/error openklappen.
Zo wordt er geen enkele informatie achterwege gelaten en kan ik zelfs mijn warnings beter bekijken.

Aptitude is een stap in de goede richting uiteraard ... en ik jarenlang maar apt-get gebruiken :-).

Verder vergelijk ik zelfs nergens linux CLI met Windows GUI.
Ook haal ik nergens aan of een GUI nu wel of niet sneller werkt dan een CLI.
Mijn post was vooral bedoeld om op te merken dat gebruiksvriendelijkheid samengaat met performantie, zodat het best een goed idee is of kan zijn om de GUI uit de serverversie van Windows weg te laten ...

[Reactie gewijzigd door Nullius op 22 september 2011 15:53]

Ben benieuwd hoe het werkt met resources die een GUI nodig hebben bij installatie. Kun je dan na installatie alsnog overstappen op de GUI-less versie? Lijkt mij best praktisch.
Meeste installers hebben vandaag reeds een silent optie zodat je kan installeren vanaf een cli zonder tussenkomst van de gebruiker. Alleen moet de software daarna wel aangepast zijn voor beheer vanaf een cli of remote.
De resources die een GUI innemen zijn echt minimaal, heb je op een server met vele cores, GHzen en vele GB's RAM werkelijk problemen met 0.1% cpu belasting extra en 30 MB geheugengebruik? Vanuit veiligheid is het in theorie wel een verbetering - wat niet draait kan je ook niet exploiten. Maar ja, zaten er werkelijk zoveel gaten in GUI frameworks?

Maar goed, Microsoft blijft een commercieel bedrijf. Als de klant een CLI-only interface wil, dan krijgt hij die.

[Reactie gewijzigd door Dreamvoid op 21 september 2011 09:12]

Ik denk dat je het iets te beperkt bekijkt, veel processen hebben een GUI en die blijft altijd actief. Het gaat dus niet alleen op voor Explorer maar gewoon voor al de programma's. Ik kan mij voorstellen dat dit een hogere belasting veroorzaakt
Zelfs als blijft die GUI sessie van een beheerder actief, dan word ie vanzelf uitgeswapt.

In de praktijk blijkt altijd dat de extra resources van een GUI peanuts zijn in echte servers.
En zelfs al zou dat niet zo zijn, dan zou ik graag een gig RAM toevoegen, omdat dat geen zier kost, en daarmee het beheer eenvoudiger en eenvoudiger is en er minder fouten gemaakt worden.
Eenvoudig in de zin van wat jij handig vind. Dit betekend niet dat het voor iedereen handig is. Als je bijv IIS manager opent ben je al flink wat KB's aan het verbranden puur en alleen voor de GUI, je verbruikt dus meer RAM, je moet wachten totdat de GUI is opgestart en dan moet je nog wat handelingen uitvoeren. Het lijkt mij handiger om via de command line wat commando's te typen zodat je niet hoeft te laden en na 3 regels (als voorbeeld, een restart is sowieso 1 regel) klaar bent...

Ik begrijp dat het gebruiken van de GUI voor veel mensen een vereiste is maar ik heb wel gemerkt dat als je even de tijd neemt om de commando's te leren je veel voordeel haalt uit het gebruik daarvan

Sinds ik Linux servers heb draaien ben ik bijv 100 x sneller in het navigeren dan ooit mogelijk zou zijn via een GUI :P Eerst vond ik het 3x niks, elke keer maar tab in drukken om de mogelijke navigeer opties te krijgen maar sinds ik de structuur ken tab ik alleen maar ter aanvulling (voor de mensen die niet snappen wat ik bedoel, sq + tab kan bijv squid worden)
Voor een enkele server, ja. Voor 15+ virtuele servers op een host gaat dat niet op, en ben ik de GUI liever kwijt als rijk.
Maar de klant wil helemaal geen CLI-only interface.

Kijk naar pakketten zoals Lynx en Exchange waar ze al fanatiek bezig zijn geweest met powershell. Daar klaagt iedereen steen en been dat simpele GUI handelingen nu ineens hele complexe CLI handelingen zijn geworden.
Complex is relatief. Die mensen moeten gewoon ff weer studeren en dan kunnen ze juist sneller handelen dan met een GUI.
Ik ben een klant van MS en wil ik best een CLI-only interface. Het moet dan wel CLI only gemaakt worden en niet zoals het nu is dmv een cli "module". Je moet onthouden dat mensen lui zijn, ze beheren bijv Exchange jaren op 1 manier, het is dan lastig om over te schakelen naar een andere manier. Dit heeft helemaal niks te maken met wat nou precies beter is, dit heeft alles te maken met het feit dat mensen heel slecht tegen veranderingen kunnen. Dwingen met die hap en laten wennen, dan een jaar later nog eens ondervragen en de meningen zijn weer compleet anders
Maar waarom? Niet elke exchange beheerder doet dit fulltime. Er zijn ook een hoop MKB's waar een exchange draait die beheerd wordt door 1 persoon die ondertussen ook het werkplekbeheer, netwerk, fileservers enz. doet.

Die heeft dan helemaal geen tijd om zich in zoiets te verdiepen, die wil gewoon met een paar keer klikken een nieuwe gebruiker kunnen aanmaken zonder steeds uit te zoeken hoe dat allemaal moet.

Voor enterprise beheerders is het prima te verwachten dat ze zich goed inleren omdat dat het enige is wat ze doen, maar in het MKB is dat heel anders. Ik ben zelf ook een specialist maar ik heb ook in MKB omgevingen gewerkt vroeger en ik weet zeker dat die niet gaan upgraden als het opeens zonder GUI moet.

Het bieden van desktop software op een server is heel wat anders: Dat vind ik ook een slecht idee, ivm malware e.d. Maar op zich vind ik een GUI op een server geen slecht plan.

[Reactie gewijzigd door GekkePrutser op 21 september 2011 14:14]

Maar op zich vind ik een GUI op een server geen slecht plan.
[Nerd modus]
Idd GUI is handig, want dan kan je meerdere terminals naast elkaar draaien }>
[/nerd modus]
Daar heb je toch gewoon screen voor :Y)
Ik ben niet echt vertrouwd met ClI interfaces , maar we zijn onlangs geupgrade naar Exchange 2007 en de CLI daar is toch wel echt handig.
Ben er nog niet heel snel in omdat ik de commands nog niet allemaal ken , maar het zit heel logisch in mekaar en als je een vereiste optie vergeet dan vraagt hij hierachter .
Ik ben er wel over te spreken.
Ik zie eigenlijk meer brood in een GUI die je apart opstart van bijvoorbeeld een snelle USB stick, waarbij alles wat je daarin doet simultaan in CMD commando's wordt geconverteerd.
Op die manier kun je in noodgevallen toch op de server met een GUI aan de gang, maar heb je de voordelen van een kalere server.
Of hetzelfde, maar dan via de netwerkpoort of sowieso via het netwerk (variant op Remote Desktop).
Ik zie eigenlijk meer brood in een GUI die je apart opstart van bijvoorbeeld een snelle USB stick, waarbij alles wat je daarin doet simultaan in CMD commando's wordt geconverteerd.
Op die manier kun je in noodgevallen toch op de server met een GUI aan de gang, maar heb je de voordelen van een kalere server.
Of hetzelfde, maar dan via de netwerkpoort of sowieso via het netwerk (variant op Remote Desktop).
Ik zie eigenlijk meer brood in het ontslaan van beheerders die met tooltjes op een USB disk aan komen zetten en die stick in een productieserver stoppen. Of beheerders die uberahaubt inloggen op de desktop van een server via een RDP sessie of op een console voor reguliere beheertaken.

[Reactie gewijzigd door Wim-Bart op 21 september 2011 15:55]

Ik zou niet weten waarom je die persoon daarvoor moet ontslaan.
Ik zie meer in het onslaan van personen die zo reageren. als jij dat doet :)
en waarom je zo op tegen bent om met rdp de server over te nemen.
Voor een regulieren taak wat dan ook wezen mag. snap ik ook niet
gui is voor vele kleine omgeving beheerders reuze handig.

Natuurlijk is het handig om comando's te gebruiken voor veel uitgevoerde taken die meerdere keren een handeling uitvoeren.
Maar voor je dat scripts zonder voorkennis in elkaar gezet hebt ben je ook een paar dagen verder. Het is dus een hele ander manier van werken.
er zullen wel meer tools worden ontwikkeld door handige scripters die alles netjes in een gui omgeving op je desktop stoppen. enkle even domein user naam pasw en server in tikken. en lekker klikken op voorgeprogrammeerde commando's. Kan de kleinbedrijf met een sbs servertje gewoon weer lekker zelf zijn servetje beheerder.
en hoeft DAN niet een eigenwijze zelf ingenomen beheerder te hoeven inhuren.
en als het tegen zit zodanig de boel dicht timmert dat het installeren van enkele applicatie op hun eigencomputer in het geheel niet mogelijk is.
En wat nu als je de windows servers gevirtualiseerd draait? Zoals bijna alle bedrijven tegenwoordig doen?

Dan heb je plots 20 servers met gui draaien. Het telt allemaal wel bij elkaar op.
Je kan gewoon een remote GUI gebruiken.
Installeer een beheer GUI op je admin desktop en zorg zo dat je eea installeert op je server.
Vele tools draaien tegenwoordig al als een soort webserver en kan je heel makkelijk via je eigen PC beheren.
Eventueel via een eigen beheer tool van MS kan je zo sofrware naar de server pushen.
Dan draait de server zonder gui maar is het toch makkelijk te beheren.
Wat betreft security is het helemaal geen goed idee om een remote GUI te gebruiken.

Ik heb liever dat mensen met een normale account hun email lezen op hun desktop/laptop en dat de malware onder dat account werkt.
En vervolgens gebruiken ze hun veel krachtiger admin account op de server.
Maar ik mag toch hopen dat men op een server geen email gaan, of uberhaupt kunnen lezen?
Dan installeer je een (virtuele) server met GUI waarop je beheerders kunnen inloggen en hun beheertaken kunnen doen.
Of (en dat lijkt me nog beter) je geeft je beheerders geen admin rechten (zoals jij hier denk ik stelt) maar legt aan je beheerders uit dat ze hun remote management software opstarten als een andere gebruiker. Ze loggen tenslotte ook niet in op de server met hun eigen gebruikersnaam en wachtwoord voor beheer taken.

Security technisch is dit dus wel te overzien, alleen een audit trail is wat lastiger in te richten.
Dus om 0,01 % resources vrij te maken op mijn exchange server moet ik een virtuele server gaan inrichten wat mij VEEEL meer resources kost... Dat is bepaald niet logisch.

Remote management software opstarten als een andere gebruiker is uiteraard al verplicht. Maar dan zit je nog steeds te werken op een client die veel kwetsbaarder is dan die server.
En als je client kwetsbaar is, dan is daarmee meteen die management software die op die client draait kwetsbaar.

Hou de boel lekker gescheiden, dat is veel veiliger.
Waarom is die client kwetsbaarder. Daar werk je zelf toch mee , dus eigen verantwoordelijkheid. op een server kan je ook domme dingen doen net zoals op je client.
Dat is heel simpel.

Op een client doe je een heleboel dingen die je op een server niet doet. Ik zit bv niet te webbrowsen op een server, dus ik heb ook geen kans dat er malware binnen kan komen via die webbrowser.

En nee, dat is ook voor verstandige mensen niet altijd te voorkomen. Ook normale websites kunnen gehacked worden en virusscanners lopen altijd iets achter op de nieuwste virussen.
Je kan malware oplopen zonder dat je ooit iets doms hebt gedaan. Het gebeurd niet elke dag, maar het gebeurd wel.
Maar je weet wel naar waar je browsed. Dan weet je ook wel of die site wel of niet veilig is. Als je dat niet weet dan doe je het niet of op een virtuele machine.

En als je er echt geen vertrouwen in hebt , dan regel je een dedicated beheer pc waarmee je niet mee op internet kan.
En een dedicated PC kost geen resources? Kun je net zo goed RDP gebruiken ...
Gebruikers horen niet op een server te werken . Dan gaat het fout ja.
Ik heb liever dat mensen met een normale account hun email lezen op hun desktop/laptop en dat de malware onder dat account werkt.
Waarschijnlijk nog nooit remote beheer gedaan op een Windows server. Windows heeft zoiets als runas, en alle remote beheer-tools kun je dus onder andere credentials als die waarmee je je normale taken doet draaien.
Alleen jammer als er een rootkitje op die client staat.
Leuk dat je dan een runas doet, maar dan ben je nog steeds de klos.

Daarnaast heb je het probleem dat mensen runas maar vervelend vinden en dus binnen de korste keer driekwart van je admins onder hun admin account inloggen op hun client.

En dat is niet alleen in het MKB een probleem maar juist ook bij grote enterprise omgevingen waar men beter zou moeten weten.

Juist omdat ik wel degelijk veel ervaring met remote beheer heb weet ik dat uit de praktijk.
Als er een rootkit op de client draait zal die niet onder hetzelfde account draaien als warmee je runas gebruikt, en zal derhalve ook geen toegang hebben tot dat proces..
Wat betreft beheerders die als admin inloggen op hun werkstation, als je dar al niet blokkeert via een GPO knikker je ze de deur uit wegens het niet volgen van beveiligingsbeleid. Kijken wat ze vervelender vinden, geen baan of runas gebruiiken.
Sterker nog, beheerders behoren twee accounts te hebben. Een standaard generiek KA account zonder specifieke admin rechten en een separaat beheer account. Separate beheer account is bedoeld om in te loggen op een Terminal/Citrix beheerserver met alle benodigde tooling en gewone account is voor e-mail en KA werkzaamheden.
kun je ook met goede argumenten onderbouwen waarom de gui per definitie onveilig is.
dan alleen meer code dus meer lekken.
en waarom die remote gui helemaal geen goed idee is begrijp ik ook niet. dus je mysql database beheren met ph admin is eigenlijk en slecht idee.
verschillende applicatie die een mooie webinterface hebben zoals bv een san. nee niet doen. het is een slecht idee niet veilig.
ook voor niet gui systemen zijn virussen de bouwen.
en met een cli interface vallen die nog minder op dan met een gui.
Server Core is een fiasco. Wordt vrijwel niet gebruikt en met goede redenen. Performanceverbetering is zeer minimaal en je hebt toch nog steeds een explorer lopen... de cmd prompt zit nog steeds in een... window (waarmee je verbinding maakt via... het grafische remote desktop protocol). En dat is ook niet erg. Maar de basic interface starten is wel zo handig en maakt voor prestaties niks uit.

Marketing priet praat. En de eindgebruiker negeert het natuurlijk. Logisch ook. Een GUI is wel zo handig, en je bent het gewend, net als de software zelf. En als je wilt scripten is er altijd de command prompt en .net shell.

[Reactie gewijzigd door Rinzwind op 21 september 2011 09:17]

Het is ook erg raar dat juist Microsoft dat als geen ander de voordelen van een GUI tov een CLI weet, al die kennis nu ineens overboord gooit en volledig negeert.

Er zijn situaties waarin een GUI handiger is en situaties waarin een CLI handiger is.
Zorg daarom gewoon dat je voor beide situaties de beste oplossing aanbied.

Bij Exchange zie ik dat ze compleet doorgeschoten zijn naar CLI, en vervolgens moeten de deelnemers van de TAPs met veel moeite weer zorgen dat de GUI terug komt voor die situaties waarin een CLI onhandig is.
Ik denk dat ze net hopen om doorwinterde *nix gebruikers te overtuigen van de kwaliteiten van Windows. Er word vaak beweerd dat *nix beheerders net meer machines beter kunnen beheren omdat ze remote via een cli werken, en power users werken zowiezo liefst zoveel mogelijk met een toetsenbord. Telkens die muis opzoeken om handellingen te doen en dan weer naar het toetsenbord terugkeren kost tijd.

Enige nadeel aan een CLI is dat er meer kennis voor nodig is, je kan niet snel een help raadplegen en eenvoudig doorbladeren. Je kan niet met eenvoudig benoemde tabbladen en vensters werken maar hebt vaak alles in 1 grote config file.
De groep windows beheerders is volgens mij stukken groter dan *nix beheerders. Die moeten dus allemaal anders gaan werken?

Ik zie de voordelen van zowel gui als cli. Daarom is de huidige Windows met powershell ook zo mooi. Kun je kiezen. Dat toekomstige Windows zelf geen gui hebben is minder een punt. Zo goed als alles kan met remote tools (moeten die wel hun gui houden).

Dat zoals met exchange simpele gui dingetjes eruit worden gehaald die je nu met powershell moet vind ik echt een slecht idee. Een gui is toch wat intuitiever, als je iets moet doen wat weinig voorkomt hoef je niet eerst commando's op te zoeken.

Met de huidige hardware lijkt de performance winst niet echt een issue.

[Reactie gewijzigd door Altijd_Lastig op 21 september 2011 13:41]

De groep windows beheerders is volgens mij stukken groter dan *nix beheerders. Die moeten dus allemaal anders gaan werken?
Maar als ik het begrijp leer je in alle MCSE trajecten en sessies over Microsoft Server producten juist dat je je beheer consoles op je werkplek gebruikt en daarmee verbinding maakt met de juiste servers. Op die wijze is het ook eenvoudiger om roll-based beheer in te voeren, want in principe heeft niemand meer Administrator toegang nodig tot de console en kan je volstaan met de juiste rollen.

Dat iedereen werkt met Console toegang is iets wat eigenlijk gewoonweg niet nodig is en security technisch ook nog eens is af te raden.

Dus wanneer er een hele grote groep beheerders anders moet gaan werken dan is er iets mis met een hele grote groep beheerders. Bij de meeste grote bedrijven werkt men ook met roll-based beheer en hebben de meeste beheerders ook nog nooit de console van een server gezien. De console is eigenlijk alleen interessant voor de mensen welke a) de server installeren en afconfigureren (wanneer je dat niet gescript doet met Altiris of ander pakket) b) Voor hen die een rol toevoegen zoals een Exchange-, SQL- of ander soort Server.
Marketing priet praat. En de eindgebruiker negeert het natuurlijk. Logisch ook. Een GUI is wel zo handig, en je bent het gewend, net als de software zelf. En als je wilt scripten is er altijd de command prompt en .net shell.
En als je geen plaatjes nodig hebt om een server te bedienen dan gebruik je geen Windows. Volgens mij is het gebruikersgemak namelijk een heel belangrijp USP van Microsoft Windows Server.
Het zou fijner zijn om de gui tijdelijk in te schakelen als je beheertaken gaat uitvoeren en uit te schakelen als je niets op de server doet.
Toch vind ik het ergens wel bizar klinken. Windows zonder windows :+
i.p.v de hele interface te dumpen met een cmdline, kunnen ze niet gewoon de skinning gedoe weghalen en terug naar een kale nt type interface :\ ik zit niet echt te wachten op een cmdline interface waarop ik alles moet intypen :X

voor sommige commando's is het wel handig als je iets snel wil laten gebeuren, maar voor sommige taken kan je echt niet zonder een gui. active directory met meerdere ou's en users beheren zonder een gui :o , no fracking way!

[Reactie gewijzigd door majetta op 21 september 2011 09:23]

Je AD beheer je ook niet op je server, die beheer je via de remote tools ;)
Overigens kan alle taken voor het beheer van de AD doen via powershell en de oude cli commando's; dsquery, dsget, dsadd, dsmod, etc

[Reactie gewijzigd door TMDevil op 21 september 2011 10:27]

Het is al jaren zo dat Microsoft aanraad om via een client de server te beheren. In de praktijk blijkt dit toch wel beperkt maar is het met Windows 2008 zeker verbeterd.

Ik ben het met de gedachte eens dat een server geen GUI nodig zou moeten hebben. Echter moet je dan wel via de client (mmc) de boel via een makkelijke GUI beheren. De beweging richting PowerShell geloof ik niet zo in. Microsoft beheerders (ik ben er zelf 1) zijn over het algemeen toch wel gebonden aan de GUI.

Ik ben dan ook heel benieuwd naar Windows server 8!
Dat is ook hun bedoeling: ze willen eigenlijk dat je een server deployed, en dan met de RSAT-tools of een variant (denk maar gewoon aan de Server Manager in 2008 (R2) die automatisch opspringt bij het aanloggen) beheert en zo rollen installeert...

Net hetzelfde als met bv Act Directory beheren, verbinden met een AD-server en zo beheren, allemaal lokaal en de commando's gaan over de lijn...

Plus nu kan je toch al servers beheren zonder aan te melden via RDP, installeer de RSAT-tools maar eens, en verbind maar eens naar een server... :) . OK, nog niet alles is beschikbaar, maar geef het wat tijd...

Eigenlijk... :+ gaan ze een beetje de weg op zoals VMware en ESXi, ESXi installeer je ook en heeft geen deftige GUI en het beheer loopt verder over IP met de vSphere Client...

[Reactie gewijzigd door HyperBart op 21 september 2011 09:40]

Microsoft beheerders (ik ben er zelf 1) zijn over het algemeen toch wel gebonden aan de GUI.
Kwestie van wat je gewoon bent. Windows beheerders zien de beweging naar PS niet zitten, linux beheerders vinden dan weer dat je met een GUI niets kunt aanvangen. Het is maar wat je gewoon bent.
Windows server is juist zo sterk/groot geworden door de GUI. Ga die eruit slopen en een groot deel van je afzetmarkt haakt af. Denk aan het MKB en de beheerder die het erbij doet, de junior beheerders, de oude beheerder die al jaren kleinere omgevingen beheren omdat het zo gegroeid is. Ga alleen de shell versie aanbieden en de stap voor nieuwelingen gaat veel sneller richting Linux.
De mooie management tools werken natuurlijk nog allemaal gewoon, maar wel vanaf je eigen workstation. Zie bijvoorbeeld de gratis Hyper-V Server 2008, die ook zonder echte vorm van GUI draait.
Dat kunnen ze dus wel. Mijn ESXi hobbybak heeft een prachtig geel-grijs text-only menu maar dat zie ik amper want de vSphere Client op je desktop is je beheerstool. En die heeft een prima GUI. Met afdoende client-side security ben je dus klaar.

Dat zal Win8 ook gaan doen: verplaatsen van server naar client waarbij de beheerstool cmdlets uitspuugt richting server.

[Reactie gewijzigd door Bundin op 21 september 2011 13:27]

Als fervent Linux gebruiker denk ik dat je er volledig naast zit. Windows is wel meer dan enkel een GUI, het is ook de naadloze samenwerking van verschillende servertoepassingen, Active Directory en alles wat daar rond hangt. In Linux is zoiets opzetten toch een pak lastiger of soms onmogelijk (als je kijkt naar de tijd/moeite die je er in moet steken, je kan/mag gewoon niet té lang met iets bezig zijn).

Windows heeft altijd dat streepje voor vanwege de tools (o.a. MS Management Console) en de kennis van de systeembeheerders zal vast niet verloren gaan.

Ik heb het trouwens niet over webservers e.d.. Ik ken genoeg sysadmins waar ik mee gepraat heb die Linux gewoon wegwuiven zodra ik het woord laat vallen omdat ze te diep in Windows zitten. De overgang Win2008 naar Win8 zal vast wel "makkelijker" zijn dan van Win2008 naar Linux als server.
Ook binnen Linux heb je (helaas wel afhankelijk van je distro) vaak ook een (g)ui voor het configureren van diverse zaken. Benodigde tijd voor het configureren van complexe zaken is veelal ook afhankelijk van al eerder opgedane kennis.

Iemand die al lang met Windows werkt kent daarin beter zijn weg en daardoor kost het configureren minder tijd.
Iemand uit de *nix-hoek zal ongeveer dezelfde tijd nodig hebben voor het configureren van een vergelijkbaar situatie op een Linux-machine.
1 2 3 ... 7

Op dit item kan niet meer gereageerd worden.