mboost-dp1
Er du Windows admin ? Har du et job om 5 år?
Windcape (44) skrev:
Ellers skal Hubert, som jo er "oh så erfarn med drift" give et eksempel på hvor han mener at GUI ikke kan løse en opgave bedre end et script :-)
Jeg kan komme med et endnu mere kompliseret eksempel hvor din gui kommer til kort...
Jeg skal migrer fra en firewall til en anden. Hvilken måde er hurtigst din gui eller min cli?
Scripts/macroer er til at løse gentagende opgaver, som sker sjældent. "Daglig drift", altså alm. gentagende opgaver, vil altid have fordel af et GUI frem for at være CLI baseret.
Nopes. Opgaver der gentages ofte skal automatiseres såfremt det er muligt.
~edit~
forkert post jeg fik citeret fra
/~edit~
Software eller Hardware Firewall? Og hvis hardware, er det samme firmware/producentHubert (52) skrev:Jeg skal migrer fra en firewall til en anden. Hvilken måde er hurtigst din gui eller min cli?
Eller samme OS og/eller firewall produkt, hvis det er software mellem to maskiner?
Hvis der et interface på begge firewalls, der tillader import/export af en settings fil, så vil jeg sige at GUI er hurtigere.
Ellers afhænger det meget af omstændighederne.
Windcape (40) skrev:F.eks. at der er dropdown med mulige konfigurationer til den valgte option (måske endda med beskrivelse fra dokumentationen), frem for at du skal lede dokumentationen igennem efter valgmuligheder, og sikre dig du ikke taster forkert osv...Corholio (36) skrev:og hvad er så forskellen på at skrive et script i en prompt / terminal der kompilerer din kode, i forhold til at skrive et script i et IDE, som du kører derfra?
Og hvorfor er dropdowns så essentielle, du kan også bruge auto-completion i CLI-miljøer. F.eks dette eksempel: http://naleid.com/blog/2008/03/25/autocomplete-gra...
Dokumentation, tjah... flere terminalvinduer, eller "screen" ? Pipe indholdet af en man-page igennem less og bruge "/<search-term>", så behøves du ikke at "lede dokumentationen igennem efter valgmuligheder".
Du kan også bruge copy/paste, så skal du ikke bekymre dig om at "sikre dig du ikke taster forkert osv..."
Windcape (53) skrev:Software eller Hardware Firewall? Og hvis hardware, er det samme firmware/producent
Nu er det et tænkt eksempel basseret på erfaring med drift. Men når det kommer til stykket så er der jo faktisk ikke en hardware firewall... ;) Der er en applience boks der kører en software firewall og det er så det nogle folk vælger at kalde for en hw fw.
Eller samme OS og/eller firewall produkt, hvis det er software mellem to maskiner?
Jeg kender ikke noget til en enterprice fw der ikke er ligeglad med hvilken underlæggende hw der kører når det kommer til regelsættet.
Hvis der et interface på begge firewalls, der tillader import/export af en settings fil, så vil jeg sige at GUI er hurtigere.
Ellers afhænger det meget af omstændighederne.
Aha... så når vi har siddet og brugt scripts til at uploade config filer på gamle cisco pix fw's så har vi i virkeligheden gjort det forkert..?
Ikke forkert, men jeg vil jo netop mene at hvis det var et GUI værktøj til formålet, som måske kunne forbedre processen (og det kan man næsten altid), så ville det være udformet bedre.Hubert (55) skrev:Aha... så når vi har siddet og brugt scripts til at uploade config filer på gamle cisco pix fw's så har vi i virkeligheden gjort det forkert..?
Ellers bliver det uafgjort.
Det afhænger også af hvor besværligt det rent faktisk er at benytte sådanne scripts.
F.eks. til routere er det jo i dag også normalt med et webinterface, som jeg tvivler på at nogen vil beskrive som mere besværligt at bruge, end at telnet til sin router manuelt!
Windcape (56) skrev:Ikke forkert, men jeg vil jo netop mene at hvis det var et GUI værktøj til formålet, som måske kunne forbedre processen (og det kan man næsten altid), så ville det være udformet bedre.
Ellers bliver det uafgjort.
Det afhænger også af hvor besværligt det rent faktisk er at benytte sådanne scripts.
F.eks. til routere er det jo i dag også normalt med et webinterface, som jeg tvivler på at nogen vil beskrive som mere besværligt at bruge, end at telnet til sin router manuelt!
Der findes et gui til cisco netværks udstyr og jeg har da også set det brugt et enkelt sted.
Jeg kan desværre ikke administrerer min router via cli. Du mangler iøvrigt stadig at tage stilling til fw spørgsmålet...
Umiddelbart virker det som om at begge løsninger er lige gode, uden at skulle tage hensyn til mere specifikke løsninger.Hubert (57) skrev:Du mangler iøvrigt stadig at tage stilling til fw spørgsmålet...
Så er det jo bare at vælge den nemmeste. Og så vil jeg sige at et GUI vinder.
Corholio (54) skrev:
Dokumentation, tjah... flere terminalvinduer, eller "screen" ? Pipe indholdet af en man-page igennem less og bruge "/<search-term>", så behøves du ikke at "lede dokumentationen igennem efter valgmuligheder".
Mig bekendt plejer man(1) også at have /<search-term>. <search-term> kan være et regular expression, i øvrigt.
#off-topic
Jeg lavede et memory-dump på min router og kørte strings på resultatet. Jeg fandt den her linje:
Kernel compiled little-endian, but running on a big-endian cpulol!
Caught WATCH exception - probably caused by stack overflow.
EDIT: nevermind...
scp -P 1023 -r [email protected]:/var/www ./
GUI ? - no no
Alene det at starte en eller anden ftp(ssh) client op er alt for besværligt.
GUI ? - no no
Alene det at starte en eller anden ftp(ssh) client op er alt for besværligt.
Windcape (58) skrev:Umiddelbart virker det som om at begge løsninger er lige gode, uden at skulle tage hensyn til mere specifikke løsninger.
Så er det jo bare at vælge den nemmeste. Og så vil jeg sige at et GUI vinder.
Lad os se på checkpoint... De har valgt samme løsning som dig og det er et helvede at migrer fra en r65 til en tilsvarende r65 er et helvede fordi det kører via gui. Dvs du manuelt skal oprette alle regler inklusiv objekter. No fun...
På juniper har jeg ladet mig fortælle at du kan gøre det via cli og så er det et spørgsmål om copy/paste. Fun...
Windcape (62) skrev:#61
Men det beviser alligevel min pointe. GUI værktøjet er tydeligvis dårlig designet.
Erm nej det beviser ikke din pointe. Det viser med alt tydelighed at gui ikke nødvendigvis er det rette værktøj til opgaven. Gui'en er ok til at oprettelse/nedlæggelse af regler men til migrerning ville en cli være optimal
Jeg linker mobil og computer via bluetooth, så jeg kan sms'e via gnokii og terminalen:
echo "hva så har du fået noget på den dumme ?" | gnokii --sendsms [mobilnummer]
Det er hunderede gange nemmere og hurtigere end ...
Der er også xgnokii men hvorfor det.
Det gode ved terminalen er jo også at der automatisk er historik på.
Ang eks. med databasen hvor man skulle rette nogle bruger data, så kan det godt være det er hurtigst første gang at bruge GUI'en men når du har komandoen på plads, så er det meget nemt at rette den til og bruge den på den næste bruger.
Shell el. GUI - for mig handler det om hvor meget man bruger det. - Det handler jo lidt om hvor god man er til at bruge huskeren.
echo "hva så har du fået noget på den dumme ?" | gnokii --sendsms [mobilnummer]
Det er hunderede gange nemmere og hurtigere end ...
Der er også xgnokii men hvorfor det.
Det gode ved terminalen er jo også at der automatisk er historik på.
Ang eks. med databasen hvor man skulle rette nogle bruger data, så kan det godt være det er hurtigst første gang at bruge GUI'en men når du har komandoen på plads, så er det meget nemt at rette den til og bruge den på den næste bruger.
Shell el. GUI - for mig handler det om hvor meget man bruger det. - Det handler jo lidt om hvor god man er til at bruge huskeren.
Men modsat så skal du rette i scriptet hele tiden, og du glemmer måske at fjerne en rettelse, som ikke skulle med næste gang, og så overskrive vigtig information!røvskæg (64) skrev:Ang eks. med databasen hvor man skulle rette nogle bruger data, så kan det godt være det er hurtigst første gang at bruge GUI'en men når du har komandoen på plads, så er det meget nemt at rette den til og bruge den på den næste bruger.
(Been there, done that - mainly SQL)
GUI er mere oplagt til formålet (TUI er også fint).
Windcape (66) skrev:Men modsat så skal du rette i scriptet hele tiden, og du glemmer måske at fjerne en rettelse, som ikke skulle med næste gang, og så overskrive vigtig information!
Idiotsikring. - samme kunne ske via en gui, hvis du har samme mulighedder og sidder og sover. 'next' -> 'ok' -> 'next' -- OUPS !!!
Windcape (65) skrev:#63
Nej, GUI ville også være fint til migrerning. Om noget, så bare som et abstrakt c&p for at få alle mulighederne i samme værktøj!
Det er her forskellen er. Vi har forskellige opfattelse af hvordan GUI kan bruges og udvikles.
Så er vi ude i eksport/import... Jeg vil påstå at jeg stadig kan klare det hurtigere med copy/paste end du kan med eksport/import
Jeg tror såmænd ikke at vi har en så forskellig opfattelse af hvad en gui kan udvikles til. Du ved bare ikke at du tager fejl... :p
Hele konceptet med mange skærmbilleder er jo også bevist at være en utrolig dårlig løsning.røvskæg (67) skrev:Idiotsikring. - samme kunne ske via en gui, hvis du har samme mulighedder og sidder og sover. 'next' -> 'ok' -> 'next' -- OUPS !!!
Nej, du har en klar opfattelse af GUI som noget der er dårligt og besværligt, og ser det sjældent som en god løsning, fordi du har for mange dårlige erfaringer.Hubert (68) skrev:Jeg tror såmænd ikke at vi har en så forskellig opfattelse af hvad en gui kan udvikles til. Du ved bare ikke at du tager fejl... :p
Mit perspektiv er udvikling af GUIs, hvor man netop arbejder meget med brugeren omkring forbedringer fra gamle systemer.
arne_v (20) skrev:Programmer der skal bruges i PS er også designet omkring et text interface.
Du har sikkert ret. Min praktiske erfaring med PS er meget begrænset, så vil slet ikke argumentere for eller imod. :)
Min kilde er forresten arkitekten bag sproget. Hørte hans præsentation af PS på JAOO, hvor han netop fremhævede at en shell med tekst i centrum ikke giver mening på Windows platformen, som det gør i et unix system.
Mht. sprogdesign er jeg faktisk overbevist om at PS er bedre. Dels er det designet senere, så kravene til hvad en god shell bør indeholde har sikkert være klarere. Dels har MS en god track record med at lave sprog.
#70
Jeg tror altså at han har ment noget lidt andet. PS er i høj grad bygget op omkring multi pipes af kommandoer, hvilket jo er så tekstet som noget kan blive.
Udover at kunne trække på erfaring, så er PS også fokuseret på administratorer - ikke på udviklere eller almindelige brugere.
Jeg tror altså at han har ment noget lidt andet. PS er i høj grad bygget op omkring multi pipes af kommandoer, hvilket jo er så tekstet som noget kan blive.
Udover at kunne trække på erfaring, så er PS også fokuseret på administratorer - ikke på udviklere eller almindelige brugere.
Et af problemerne med GUI vs. CLI er, at man kan risikere at skulle åbne utroligt mange programmer for at udføre simple operationer.
Tænkt eksempel:
Man vil lave en ipconfig /renew og en ipconfig /flushdns efterfulgt af en ipconfig /all.
Dernæst vil man måske pinge en specifik ip-adresse, traceroute selvsamme ip-adresse osv. Fortsæt selv i samme dur.
I cmd.exe tager det ikke mange sekunder at fyre de kommandoer af, men hvis man skulle åbne ét eller flere programmer for at udføre kommandoerne ville det tage noget længere tid (museklik fra og til mv.). Samler man det i ét program kan det hurtigt blive uoverskueligt.
Normalt er jeg enig med dig i mange ting Windcape, men der må være en grund til, at MS har udviklet Powershell og tilbyder Windows 2008 uden GUI.
Tænkt eksempel:
Man vil lave en ipconfig /renew og en ipconfig /flushdns efterfulgt af en ipconfig /all.
Dernæst vil man måske pinge en specifik ip-adresse, traceroute selvsamme ip-adresse osv. Fortsæt selv i samme dur.
I cmd.exe tager det ikke mange sekunder at fyre de kommandoer af, men hvis man skulle åbne ét eller flere programmer for at udføre kommandoerne ville det tage noget længere tid (museklik fra og til mv.). Samler man det i ét program kan det hurtigt blive uoverskueligt.
Normalt er jeg enig med dig i mange ting Windcape, men der må være en grund til, at MS har udviklet Powershell og tilbyder Windows 2008 uden GUI.
arne_v (71) skrev:Jeg tror altså at han har ment noget lidt andet. PS er i høj grad bygget op omkring multi pipes af kommandoer, hvilket jo er så tekstet som noget kan blive.
Som jeg prøvede at fremhæve har jeg ikke erfaring nok med det til at kunne diskutere, og vælger derfor den nemme løsning. Du får ret ;)
Jeg troede egentlig også at den pipe streamede objekter, og ikke kun tekst.
Windcape (69) skrev:Nej, du har en klar opfattelse af GUI som noget der er dårligt og besværligt, og ser det sjældent som en god løsning, fordi du har for mange dårlige erfaringer.
Mit perspektiv er udvikling af GUIs, hvor man netop arbejder meget med brugeren omkring forbedringer fra gamle systemer.
Gad vide hvor den erfaring kommer fra..? Næppe fra at sidde som udvikler :p
Det er da kun godt at du mener du kan være med til at design bedre gui løsninger men det hjælper ikke meget hvis du ikke vil høre på hvad dem der skal bruge lortet fortæller dig..
Windcape (28) skrev:Jeg tror du mener at admins skal BÅDE bruge GUI og CLI.
Der vil stadig blive brugt GUI til nogen ting.
Windcape (28) skrev:At de vil give *muligheden* for mere terminal-baseret administration er jo fint. Men jeg tror tvivler stærkt på at det er et mål i sig selv.
MS's mål er vel at levere det som kunderne vil have.
Windcape (40) skrev:
Selv mainframes har et terminal baseret GUI. Hvor man kan tabbe mellem felter. Du mener måske at terminal baseret GUI på en AS/400 er mindre effiktivt end at skrive kommandoer direkte i en promt?
På andre styresystemer - ja ofte, så det er sikkert også tilfældet på i.
Windcape (43) skrev:Lad os give et mere kompliceret eksempel:
Du skal åbne en liste af brugere, for at finde en bestemt bruger, og rette nogle oplysninger.
Brugerne er listed i et DataGridView med en søgemulighed (der søger på alle mulige properties).
Du finder personen du leder efter, trykker på "rediger", får et nyt skærmbillede, og retter informationerne, og klikker på "gem".
Vil i på nogen som helst måde mene at overstående operation ville være smartere i CLI?
Ja - meget.
CLI er hurtigere til at lave det samme til mange brugere.
CLI er bedre til at få lavet præcist samme rettelse hver gang.
CLI er nemmere at dokumentere (to linier tekst med en kommando linier er noget fixere end et par sider med screen dumps).
Windcape (44) skrev:Scripts/macroer er til at løse gentagende opgaver, som sker sjældent.
System administration drejer sig i høj grad om gentagne opgaver. Systemer, konti, apps etc. skal sættes ens op.
Windcape (62) skrev:Men det beviser alligevel min pointe. GUI værktøjet er tydeligvis dårlig designet.
Hvis logikken er:
GUI bedre end CLI til opgave X => beviser at GUI er bedst
CLI bedre end GUI til opgave Y => beviser at den pågældende GUI er dårlig
så er det lidt svært at argumentere mod dig.
#VS
Som nævnt er VS ikke ægte GUI build men derimod en hybrid - VS builder fra GUI men maintainer også et MSBuild script for manuel build.
Og der er visse ting som man faktisk ikke kan fra GUI af, men skal scripte:
- lave en EXE eller DLL udfra source code i 2 forskellige sprog
- aktivere en AOP weaver
etc.
Indrømmet - det er ikke de mest gængse opgaver, men de findes.
Som nævnt er VS ikke ægte GUI build men derimod en hybrid - VS builder fra GUI men maintainer også et MSBuild script for manuel build.
Og der er visse ting som man faktisk ikke kan fra GUI af, men skal scripte:
- lave en EXE eller DLL udfra source code i 2 forskellige sprog
- aktivere en AOP weaver
etc.
Indrømmet - det er ikke de mest gængse opgaver, men de findes.
arne_v (80) skrev:lave en EXE eller DLL udfra source code i 2 forskellige sprog
Tilgengæld kan du blot tilføje de 2 typer source code, via 2 forskellige projekter, som du tilføjer din solution. Alt sammen via din GUI.
Det er også en lidt pænere løsning, end at prekompile forskellige typer source filer og så linke dem. (Som jeg går ud fra, at du mener?)
Den eneste grund du giver er at du synes det er nemmere i et produkt end i et andet.Hubert (76) skrev:Gad vide hvor den erfaring kommer fra..? Næppe fra at sidde som udvikler :p
Det er da kun godt at du mener du kan være med til at design bedre gui løsninger men det hjælper ikke meget hvis du ikke vil høre på hvad dem der skal bruge lortet fortæller dig..
Du har aldrig skænket det en tanke at det produkt du synes om, godt kunne forbedres yderligere?
Windcape (82) skrev:Den eneste grund du giver er at du synes det er nemmere i et produkt end i et andet.
Du har aldrig skænket det en tanke at det produkt du synes om, godt kunne forbedres yderligere?
I det her tilfælde ville det have hjulpet mig gevaldigt at kunne copy/paste da regelsættet skulle være fuldstændig identisk.
Det ville jeg have kunne gjort i et andet produkt. Det var en sammenligning af gui vs cli til samme opgave. Nu er cli metoden ikke mulig på det produkt jeg skulle udføre arbejdet på men havde det været muligt havde det taget betydeligt kortere tid. Altså vil det her have været en fordel med en cli løsning.
Du skal ikke hænge dig i at det er forskellge produkter. Det er blot til sammenligning.
illishar (81) skrev:Tilgengæld kan du blot tilføje de 2 typer source code, via 2 forskellige projekter, som du tilføjer din solution.
Det kan man. Men så er det IDE'ens restriktioner som bestemmer ens opdeling i deployable komponenter ikke ens design.
illishar (81) skrev:Det er også en lidt pænere løsning,
Det synes jeg så ikke. Jeg mener at det må være en del af designet hvormange og hvilke DLL's man skal have.
illishar (81) skrev:end at prekompile forskellige typer source filer og så linke dem. (Som jeg går ud fra, at du mener?)
Jeg snakker om netmodule's og add module.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund