Gå til innhold

Interressen for GNU/Linux nedadgående?


Anbefalte innlegg

Videoannonse
Annonse

Jeg vil påstå at noen ting er enklere å gjøre i et GUI, men det kommer fullstendig an på hva du skal gjøre. Andre ting er vesentlig enklere i terminalen.

Gi meg gjerne eksempler på ting som implisitt må være enklere i GUI. Jeg har tenkt rimelig mye på dette, og eneste jeg egentlig kommer frem til er tegning.

I stor grad tenker jeg på IDE i de tilfellene det er typisk å bruke et console basert grensesnitt. Noenting kan en rett og slett ikke gjøre i consoler, som real-time grafing av sample data med høy oppløsning, eller det er ihvertfall særdeles upraktisk. Andre ting er at en kan overlaye tekst med gjennomsiktighet, slik som Eclispe og Visual Studio som vil gjøre auto-complete halv-gjennomsiktig over teksten du skriver, slik at auto-complete ikke skjuler det du skriver, men likevel er hjelpsom. Du slipper å flytte blikket, eller slå opp i ekstern dokumentasjon mens du skriver.

Men det jeg tenker på først og fremst er ikke rent tekniske ting som dette, men hvordan et grafisk grensesnitt mot for eksempel brukersettet på systemet kan være mer effektivt i bruk, eller i det minste enklere i bruk. Her er grunnen: et grafisk grensesnitt kan vise deg endringer du gjør fortløpende, og vil vise deg mange ting av gangen. Terminalarbeid går ofte ut på å spørre etter status, gjøre endringer, og så spørre etter status på nytt. Alt du vil gjøre må du eksplisitt be om til enhver tid.

Et eksempel er behandling av brukere. Det grafiske kan vise deg hvilke brukere som finnes i systemet, hvilke grupper de tilhøre, og hvilke rettigheter de har, til enhver tid. Dersom du gjør endringer, vil disse være synlige umiddelbart.

 

Som powerbruker er en ikke alltid interessert i dette, og det kan ikke alltid erstatte terminalen, men for vanlige enkle operasjoner kan det ta kortere tid å bruke GUI-et selv om en ikke føler seg like 1337 da.

Lenke til kommentar

Dette har jeg observert på universitetet gang på gang. Universitetet tilbyr både GNU/Linux-maskiner og Windows-maskiner. Det er ikke uvanlig at man kommmer på en terminalstue og alle maskinene av den ene eller andre typen er opptatt. Dersom en bruker kommer inn og alle Windows-maskinene er opptatt, og denne brukeren ikke studerer informatikk, tar det som regel 5-10 minutter å gi brukeren nok kunnskap til å sette seg ned ved disse ferdigkonfigurerte GNU/Linux maskinene og jobbe like effektivt og like fornøyd som ved en Windows-maskin. Det finnes absolutt ingen behov for en «normal bruker» som ikke enkelt kan tilfredsstilles med alle moderne platformer. En informatikkstudent, derimot, kan du bare glemme å få til å bruke noe annet enn det som er deres personlige favoritt OS «aka det OS-et som passer best for alle, fordi det passer best for meg».

 

Jo mer man kan om operativsystemer, jo mer avhengig av det operativsystemet man kan. Personlig så har jeg ikke nubbesjanse å bruke en Windowsmaskin lenger. Jeg kunne like gjerne satt meg inn i en semitrailer og kjørt langtransport til Spania (jeg har ikke billappen en gang). Nære venner og personer i min familie derimot kan fint sette seg ned på Windows, OSX eller GNU/Linux og klare seg fint uansett. Nettopp fordi de bryr seg døyten om systemet de bruker, de bare bruker det.

Her forutsetter du allikevel noe som gjerne ikke er tilfellet:

 

#1 - Brukeren har evne til å lære (den finnes stort sett)

#2 - Brukeren har vilje til å lære.

  • Liker 1
Lenke til kommentar

Enig, de har begge sine områder. Men jeg synes eksemplene dine er svake Geir, sjekk ut blant annet gnuplot. Den er kommandolinje dreven og svært effen til å plotte, og du kan oppdatere grafen så ofte du vil. En kommando jeg gjerne bruker er tail -f, den gir deg interaktiv informasjon på kommandolinja. Effen hvis du skal følge med log-filer.

 

En av argumentene for GUI er at en godt gjennomført GUI kan gi mye implisitt informasjon som er vanskelig å legge i en config-fil. Eksempelvis en radio-button viser deg at du velger mellom obligatoriske alternativer mens en tick-boks forteller deg at det er en valgfri opsjon. GUI er også godt egnet til å gi oversikt.

Lenke til kommentar

Her forutsetter du allikevel noe som gjerne ikke er tilfellet:

 

#1 - Brukeren har evne til å lære (den finnes stort sett)

#2 - Brukeren har vilje til å lære.

Tja. Stykkevis og delt. Det var derfor jeg uthevet dette med ikke informatikkstudenter. De fleste vanlige brukere har, etter min erfaring, ikke noe problem med å bruke litt tid på å lære. De aller fleste som ikke har vilje til å lære, er brukere som allerede kjenner et system godt, og dermed bestemmer seg for å sette seg på bakbeina og hevde hardnakket at alt som ikke er akkurat slik som de er vant med er «tungvindt», «vanskelig» og «lite brukervennlig». Jeg har observert dette veldig mange steder, og ikke bare på universitetet, og ikke bare i tilknytning til PC-bruk heller. F. eks. da jeg jobbet som assisterende butikk. Hvilke nye ansatte tror du det var som hadde problem med å lære seg å bruke kassaapparatet, og syns det var «tungvindt», «vanskelig» og «lite brukervennlig»? Tror du det var de som ikke hadde erfaring fra butikk, eller tror du det var de som hadde erfaring fra en annen butikk med et annet kassasystem? Ei heller gjaldt det bare teknologien. Det gjaldt også noe så enkelt som rutiner.

Lenke til kommentar

Enig, de har begge sine områder. Men jeg synes eksemplene dine er svake Geir, sjekk ut blant annet gnuplot. Den er kommandolinje dreven og svært effen til å plotte, og du kan oppdatere grafen så ofte du vil. En kommando jeg gjerne bruker er tail -f, den gir deg interaktiv informasjon på kommandolinja. Effen hvis du skal følge med log-filer.

Jeg syns også de eksemplene var veldig svake. Jeg ba om ting som _implisitt_ var enklere i GUI. Ikke noen av eksemplene er implisitt enklere i GUI med unntak av den autocompletion-saken. Alt annet er fullt mulig i GUI.

Men det jeg tenker på først og fremst er ikke rent tekniske ting som dette, men hvordan et grafisk grensesnitt mot for eksempel brukersettet på systemet kan være mer effektivt i bruk, eller i det minste enklere i bruk. Her er grunnen: et grafisk grensesnitt kan vise deg endringer du gjør fortløpende, og vil vise deg mange ting av gangen. Terminalarbeid går ofte ut på å spørre etter status, gjøre endringer, og så spørre etter status på nytt. Alt du vil gjøre må du eksplisitt be om til enhver tid.

Jeg vil påstå at dette er direkte feil, men er gjerne det inntrykket en person som ikke faktisk har særlig erfaring med terminalbruk sitter igjen med. Mye arbeid i termninalen forgår slik, men bare hvor dette er den mest praktiske løsningen. Det finnes bøtter og spann av eksempler på at dette ikke stemmer. Noen som de fleste her i tråden nok kjenner til (og alle burde kjenne til med tanke på uttalelsene) er f. eks. top, htop, emacs, vi, og screen. Men det er bare noen ytterst få eksempler.

Et eksempel er behandling av brukere. Det grafiske kan vise deg hvilke brukere som finnes i systemet, hvilke grupper de tilhøre, og hvilke rettigheter de har, til enhver tid. Dersom du gjør endringer, vil disse være synlige umiddelbart.

Det skulle ikke forundre meg om noe slikt finnes til terminalen. Og om det ikke finnes, så tar det et par timer med perl, python, eller et annet valgfritt skriptspråk og ncurses å lage.

Som powerbruker er en ikke alltid interessert i dette, og det kan ikke alltid erstatte terminalen, men for vanlige enkle operasjoner kan det ta kortere tid å bruke GUI-et selv om en ikke føler seg like 1337 da.

Og plutselig forstår jeg hvor du kommer fra. En «poweruser» er ikke en bruker som sitter og jobber i terminalen fordi de føler seg «1337». Dessuten så bruker slike brukere som du sikter til her vanligvis masse GUI. Transparent terminal med matrix-skjermbeskytter-sak gjørende i bakgrunnen og masse grafisk dilldall overalt. Men det er ikke det som kjennetegner en «poweruser». En ekte «poweruser» vil naturligvis velge det alternativet som faktisk er det raskeste og beste alternativet, helt uavhengig av hvilket alternativ det er. Eller, man kan jo kanskje si at folk som sitter og utvikler i Visual Studio gjør det fordi de føler seg «1337» av alle de pene fargene og 1000-vis av knapper og menyer og saker, selv om et enklere alternativ hadde vært bedre. (Og før noen sier noe. Ja, jeg brukte Visual Studio i mange år, men jeg hatet det relativt mye etterhvert. Jeg ble eksponert for alt for mange unødvendige valg, og alt for mye unødvendig informasjon, og uansett hvor lenge man brukte det så fantes det saker man måtte lete lenge og godt for å finne). Uansett... Jeg har ingen problemer med å forstå at enkelte liker å jobbe i et slikt miljø, uten å måtte dra ting om at de «ikke føler seg 1337» eller lignende.

 

Og siden du først er inne på det, kom gjerne med eksempler på hva du mener tar kortere tid å gjøre i GUI.

Lenke til kommentar

Jeg syns også de eksemplene var veldig svake. Jeg ba om ting som _implisitt_ var enklere i GUI. Ikke noen av eksemplene er implisitt enklere i GUI med unntak av den autocompletion-saken. Alt annet er fullt mulig i GUI.

- Erstatte tekst med vilkårlige ikoner for å spare plass

- Vise kontekst eller tooltip informasjon for objekter uten å skjule tekst eller annen data

- Skalere en vilkårlig del av displayet til en vilkårlig størrelse, for eksempel for å få et kjapt overblitt over et stort datasett, eksempelvis et databasedesign. På Opera Mobile benyttes dette når siden først er lastet, så trykker en i området en er interessert i før det skaleres til 100% størrelse.

- Grafikk kan være gjennomsiktig (som allerede nevnt) og plasseres nesten helt vilkårlig

- Vilkårlig rotasjon av tekst og grafikk (for eksempel for å plassere tekst loddrett for å spare vertikal plass)

- Ser mye finere ut (dog ikke implisitt, finnes mye stygg GUI)

Lenke til kommentar

- Erstatte tekst med vilkårlige ikoner for å spare plass

- Vise kontekst eller tooltip informasjon for objekter uten å skjule tekst eller annen data

- Grafikk kan være gjennomsiktig (som allerede nevnt) og plasseres nesten helt vilkårlig

- Vilkårlig rotasjon av tekst og grafikk (for eksempel for å plassere tekst loddrett for å spare vertikal plass)

Men intet av dette er eksempler på ting som implisitt er enklere å gjøre i GUI. For det første er ingenting av dette ting man gjør, dette er måter å eksponere data på.

- Skalere en vilkårlig del av displayet til en vilkårlig størrelse, for eksempel for å få et kjapt overblitt over et stort datasett, eksempelvis et databasedesign. På Opera Mobile benyttes dette når siden først er lastet, så trykker en i området en er interessert i før det skaleres til 100% størrelse.

Nå er jo ikke noe av dette ting som implisitt er enklere å gjøre i GUI. Dette er eksempler på ting som bare kan gjøres grafisk og ikke i tekstmodus, og det var ikke det jeg spurte etter. Jeg er fullstendig klar over at til enkelte ting, er man nødt for å ha X11. Debatten her går på GUI vs. terminal, ikke X11-modus vs. textmodus.

Eksempelvis er feh og mplayer terminalprogram som benytter seg av X11 for å vise bilder og video, men likevell har et terminalbasert brukergrensesnitt fremfor et grafisk brukergrensesnitt.

- Ser mye finere ut (dog ikke implisitt, finnes mye stygg GUI)

Dette er jo bare en subjektiv observasjon...

 

Helt konkret. Jeg er ikke på jakt etter hva som er forskjellen på om skjermkortet er i grafisk - eller tekstmodus. Det er jeg fullt klar over. Det jeg er på jakt etter er ting man gjør som implisitt er lettere i et grafisk brukergrensesnitt fremfor et tekstbasert brukergrensensitt. mplayer illustrerer dette ganske bra. Det er en videoavspiller som bare har tekstbasert grensesnitt. Den spiller naturligvis av en grafisk video i grafikkmodus, men grensesnittet er fullstendig tekstbasert. Alt av kommunikasjon mellom mplayer og bruker foregår enten ved hjelp av input på terminal eller ved hjelp av tastatrykk. Programmet har ikke et eneste element av et grafisk brukergrensesnitt.

Lenke til kommentar

Du flytter målgrensen for å passe ditt eget argument. Presentasjon av data er en temmelig stor del av ethvert grensesnitt.

 

Tror det er på tide at vi snur diskusjonen:

mplayer har et tekst-basert grensesnitt. Hvilke fordeler har mplayer som tekst-grensesnitt fremfor vlc?

Hvordan er læringskurven til sammenligning? Tar det kortere tid å lære mplayer kontra vlc?

Er det raskere å bruke mplayer enn vlc, dersom du skal fortløpende bytte mellom vilkårlig medie? I såfall hvorfor?

  • Liker 1
Lenke til kommentar

Du tar nok feil så langt jeg har sett - jeg antar at GUIet kaller de samme metodene i samme bibliotek, men jeg tror ikke de kaller kommandolinjen direkte.

 

Noen er det nok riktignok, som KDE Parition manager. Den kaller vel bare en annen partition manager etter regler. Litt både og.

 

Du tar nok ikke helt feil heller, men det er ganske vanlig at det skrives som bibliotek, for at det så skrives en frontend mot.

Endret av Lycantrophe
Lenke til kommentar

Du flytter målgrensen for å passe ditt eget argument. Presentasjon av data er en temmelig stor del av ethvert grensesnitt.

Nei... Jeg flytter ikke noe som helst. Og jeg har ingen argumentasjon. Jeg spurte deg et spørsmål, som jeg gjerne ønsket å vite svar på. Jeg har ingen interesse av å diskutere hva som er «best», fordi det bare er en tåpelig diskusjon. Jeg vil vite, helt konkret, hva som implisitt er lettere å gjøre i et grafisk grensesnitt. Hverken mer eller mindre. Men jeg begynner å tro at det jeg til nå har opplevd, nemlig absolutt ikke noe, er svaret.

 

Presentasjon av data er en stor del av ethvert grensesnitt. Det er det ingen tvil om. Men det har veldig liten innvirkning, om noe, på forskjellen på et tekstbasert grensesnitt og et grafikk (eller kanskje jeg skal bruke ordet widget-basert) grensesnitt.

 

Denne diskusjonen startet med at en person hevded at GNU/Linux er grusomt fordi bruk av GNU/Linux består i 80% av å skrive kommandoer, og det har ikke spesielt mye med hvordan man presanterer data å gjøre.

Tror det er på tide at vi snur diskusjonen:

mplayer har et tekst-basert grensesnitt. Hvilke fordeler har mplayer som tekst-grensesnitt fremfor vlc?

Vi kunne sikkert gjort det, men jeg ser ikke poenget i å diskutere fordeler og ulemper med enkeltprogram, ei heller fordeler og ulemper med tekst-grensenitt, da dette, og særlig det siste, har blitt diskutert opp og i mente på forumet tidligere. Alt jeg egentlig er ute etter er konkrete eksempler på hva slags ting som implisitt må være raskere å gjøre i GUI. Du kom med påstanden om at det var ting som var raskere å gjøre i GUI, og jeg vil gjerne vite hva disse tingene er. Hverken mer eller mindre. Jeg kunne ramset side opp og side ned med ulike fordeler med tekstbasert og grafikk-basert/widget-basert kommunikasjon med programvare, men jeg ser rett og slett ikke poeng i å bruke tid på det.

Hvordan er læringskurven til sammenligning? Tar det kortere tid å lære mplayer kontra vlc?

Hvorfor i all verden skal vi diskutere det? Jeg har jo for lengst sagt at læringskurven for et tekstbasert grensesnitt er høyere...

Er det raskere å bruke mplayer enn vlc, dersom du skal fortløpende bytte mellom vilkårlig medie? I såfall hvorfor?

Absolutt ingen forskjell, for samme tekstbasert grensensitt jeg bruker i mplayer kan også brukes på vlc, i GNU/Linux i hvertfall. Men igjen, hva er poenget med å diskutere dette? Slikt er blitt diskutert ørten ganger før.

Lenke til kommentar

Du tar nok feil så langt jeg har sett - jeg antar at GUIet kaller de samme metodene i samme bibliotek, men jeg tror ikke de kaller kommandolinjen direkte.

 

Noen er det nok riktignok, som KDE Parition manager. Den kaller vel bare en annen partition manager etter regler. Litt både og.

 

Du tar nok ikke helt feil heller, men det er ganske vanlig at det skrives som bibliotek, for at det så skrives en frontend mot.

Ja det er både og, som du sier. Helt klart. Men, jeg tror det er en vanlig oppfatning at de fleste program bare er et skal oppå kommandolinjen, fordi det at det er enormt lett og fort gjort å lage et skal oppå kommandolinjen ofte fremmes som et argument for GNU/Linux. Det å lage egne «custom» GUI basert på kommandolinjen er ekstremt lett, og veldig raskt i GNU/Linux og er helt klart en stor fordel for tunge brukere som likevell trives best med GUI. Og når argumentet kommer frem så ofte som det gjør, så tror jeg det er lett for folk som observerer utenfra å tro at dette gjelder «alt».

 

Dessuten så mener jeg å huske fra mine tidlige dager i GNU/Linux at det før var langt mer vanlig med GUI som bare var et skall over kommandolinje-kommandoer.

Lenke til kommentar

mplayer har et tekst-basert grensesnitt. Hvilke fordeler har mplayer som tekst-grensesnitt fremfor vlc?

Mer effektivt å bruke hvis du behersker det. Når det gjelder IDE kan du ta en titt på Emac+CEDET, det er i hovedsak kommadolinje drevet, men tibyr full IDE funksjonalitet. Godt eksempel på effektivitet er at for små oppgaver tar det kortere tid å editere en fil i vi enn det tar å åpne en gui-editor. Personlig har jeg konkludert med at jeg egentlig burde tatt meg tid til å lære vi fra dag en, selv om jeg foretrekker emacs for større ting.
Lenke til kommentar

Nei Geir, man lager typisk ikke skall. Man har API'er man koder mot. Eksempelvis er kommunikasjon mellom gui-applikasjoner standardisert gjennom dbus, arvtageren til KDE's dcop. Du har hooks for det meste på linux rett inn i systemet. Kommandolinja er typisk bare en av flere måter å kalle de samme rutinene. Til og med oppstartskriptene er i ferd med å forsvinne med systemd.

 

Å lage en wrapper for et kommandolinjeprogram er sjeldent særlig effektivt. Med kildekode tilgjengelig er det typisk bedre å kompilere rutinene rett inn, eller linke de inn som biblioteker.

Endret av Del
Lenke til kommentar

Nå skal jeg ikke mobbe, de som kun bruker dos skjerm er jo bland de flinkeste av norges befolkning :yes: Men jeg forstår at de fleste ikke har tid eller lyst å leve på 80 tallet.

Hvor har du det her fra? Din egen fantasi?

 

Hvordan kan linux være bedre ellers? Det er neppe ennå ikke løgn å si 80% av linux er commandoer.

Spørs hva du mener som Linux. Om du mener kernel/core er jo selvsagt alt kommandoer, snakker du om Ubuntu kan det være 0% kommandoer om du vil.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...