Varför föredrar vi kommandoraden framför GUI?

Granska andra artiklar Jag stötte på den här lilla frågan som orsakade mig mycket roligt, det är sant att en av de första sakerna som användare av andra system (förutom FreeBSD) får i ansiktet är att vi inte använder GUI. Sanningen att säga verkade det också ganska nyfiken för mig i början av min GNU / Linux-resa. Jag måste erkänna att över tiden använder jag nu kommandoraden mycket mer än något annat GUI-program, och jag föredrar ofta kommandoradsprogram framför mer detaljerade program med bländande GUI.

Myten

Egentligen är detta inget annat än en urban myt, för till skillnad från andra system vars namn inte kommer att nämnas här, är det i GNU / Linux där du verkligen har frihet av val. Jag önskar att i andra system fanns den mångsidighet som finns här. Men låt oss ta en närmare titt på denna fråga, annars är många saker inte klara:

servrar

Vi har alla hört ordet Server, vissa tror att de är de superdatorer som driver Google eller Amazon, eller den i ditt företag. Men verkligheten är att en server svara på en arbetsmodell. Vi använder denna term för att hänvisa till det faktum att vi har ett program som är tillgängligt för användare (kunder) och ger dem något. Ett grundläggande exempel är Apache, som används för tjäna webbsidor på internet. Detta program levererar html till kunder som begär det.

Bildserver

Men inte bara en server kan finnas i de superdatorer som Google och många andra företag möjliggör, även den "äldsta" bärbara datorn kan vara en server, särskilt när vi pratar om bilder. Vi driver alla en server bilder på våra bärbara datorer för att ha en funktionell skärm, i det här fallet server och kund de är samma person. Det vanligaste exemplet är X (känd som xorg-server i många distributioner) och dess nya ersättning Wayland. Vi kommer inte att ge en detaljerad förklaring till varför organisationen, eller hur Wayland fungerar, eller de filosofier som finns bakom dessa fantastiska projekt, men vi kommer att klargöra att det är tack vare dem att vi kan ha en webbläsare som Firefox eller Chrome eller många andra program.

Fönsterhanterare

Fönsterhanterare arbetar direkt med bildservern, deras arbete är på en "lägre" nivå, eftersom de hanterar (förlåt redundansen) hur fönstren skapas, ändras, stängs. De är vanligtvis ganska enkla och skrivbordsmiljöer bygger på dessa. Listan är stor, men jag lämnar bara tanken att de är här minimalistiska programvaror, som gör det möjligt att ha en ganska grundläggande kontroll över bildservern.

Skrivbordsmiljö

En mer specialiserad uppsättning programvara som inte bara möjliggör bildserver, utan också ger anpassningsfunktioner. Bland dessa är de äldsta och tyngsta KDE och GNOME, men vi har också lättare miljöer som LXDE eller Mate, kanel, etc.

CLI (kommandoradsgränssnitt)

Efter en kort titt på bildservrarnas värld vänder vi oss nu till vårt ämne igen. CLI, antyder alla de program som körs av kommandoraden, antingen git, vim, weechat, eller ja, vad som än kommer att tänka på. Du kan se att jag pratar om program som, även om de körs på kommandoraden, visar ett slags "grafiskt gränssnitt" som weechat o vim. För alla som inte har provat dem rekommenderar jag dem, de är i princip de jag använder hela dagen.

Varför CLI är bättre än GUI

Låt oss prova något ganska enkelt 🙂 Häromdagen ville jag arbeta på en lapp till Portage (Gentoos pakethanterare). Liksom alla bra samarbetsprojekt överstiger antalet kodrader 70k. Försök att öppna det i en IDE som NinjaIDE (Portage är skriven i Python) och du kommer snart att märka att när skärmen börjar laddas blir din maskin extremt långsam (åtminstone gjorde min i7) och detta försöker bara öppna koden och ändra till standardfärgen «hjälp».

Försök nu göra detsamma med vimDet laddade mig på några millisekunder, och samtidigt lade det de "vackra" färgerna och allt annat.

CLI har varit länge tidigare

Vissa här kommer att säga att dessa program är Antiguos, Jag kallar dem robust. Om du kunde se antalet timmar som investerats i byggnaden emacs, vim, gdboch hundratals andra konsolprogram kanske märker att mängden kod och funktionalitet är så stor att de praktiskt taget har löst allt de behövde lösa. Många GUI för program som redan är robusta i sin CLI kommer de aldrig att ha samma mängd funktionalitet, bara för att om vi till exempel skapade en flik för varje tillgänglig underkommando gitskulle vi förlora oss mellan alternativen och det skulle vara kontraproduktivt, eftersom det skulle göra det svårt att arbeta.

CLI är snabbare

Magin börjar med nyckeln Tab, detta är inte bara din bästa vän när du surfar på stationära datorer i din terminal, men när den är korrekt konfigurerad låter den dig förkorta långa meningar till 2 bokstäver och en Tab, 3 bokstäver och en Tab, eller till och med en bokstav och en Tab .

Men det här är inte den enda fördelen, de av oss som har tagit oss tid att lära oss vim o emacs Vi kan säga att även om inlärningskurvan är lite högre än IDE: s nuförtiden, så är produktivitetsresultaten till slut fantastiska, man kan inte föreställa sig den tid som kan gå förlorad när man flyttar en mus. Att ha händerna på tangentbordet 90% av tiden lär inte bara koncentration, men det faktum att skriva så mycket på tangentbordet gör dig ganska smidig och produktiv. Och nu återgår vi till föregående punkt, efter att ha varit med oss ​​så länge, program som dessa har redan alla funktioner som någon kan tänka sig, ett ganska vanligt ordstäv för oss som använder vim kommer att tänka på:

Om du använder mer än fyra tangenter kan det finnas ett bättre sätt.

Enkelt men kraftfullt, vim låter dig göra allt med det stora antalet tangenter och möjliga kombinationer, man slutar aldrig lära sig, men det är också sant att det inte är nödvändigt att känna till dem för att kunna använda dem, ungefär 10 eller 15 är tillräckligt för att börja vara mer produktiva.

CLI ger dig fullständig kontroll

När man utför operationer med musen eller program från bildservern är inte alla extra konfigurationer som exekveras vid tidpunkten för klickning alltid närvarande, detta händer inte med terminalen, här har du den absoluta kraften i vad det är utförs eller inte, med vilket alternativ eller i vilken utsträckning. Med tiden inser du att du behöver mindre än du tror, ​​och det hjälper dig att göra saker på ett mer fokuserat sätt.

GUI har också sin egen sak

Jag tänker inte säga att vi alla ska använda CLI alltid, det är inte heller idealt, jag använder själv GUI nästan hela tiden, för att skriva det här inlägget använder jag min Chrome och för att se mina e-postmeddelanden använder jag Evolution (även om jag Jag använder också mutt ganska nyligen). Och jag antar att detta är den största myten av alla ... att folk tycker att GNU / Linux bara avslutar dem, jag gillar min skrivbordsmiljö, den är ganska minimalistisk, men jag gillar det på det sättet 🙂 Och jag har vanligtvis bara två eller tre program som körs, min Chrome, min Evolution och min terminal 🙂

Det här är några av anledningarna till att jag gillar CLI så mycket och varför jag uppmanar dig att prova, de kan senare hamna som att jag använder mer CLI än GUI reet Hälsningar


Lämna din kommentar

Din e-postadress kommer inte att publiceras. Obligatoriska fält är markerade med *

*

*

  1. Ansvarig för uppgifterna: Miguel Ángel Gatón
  2. Syftet med uppgifterna: Kontrollera skräppost, kommentarhantering.
  3. Legitimering: Ditt samtycke
  4. Kommunikation av uppgifterna: Uppgifterna kommer inte att kommuniceras till tredje part förutom enligt laglig skyldighet.
  5. Datalagring: databas värd för Occentus Networks (EU)
  6. Rättigheter: När som helst kan du begränsa, återställa och radera din information.

      anonym sade

    «Som alla bra samarbetsprojekt överstiger antalet kodrader 70k. Denna del gjorde mig för högljudd. Är det tekniskt omöjligt varför koden måste komprimeras i samma fil? Skulle det inte vara bättre att separera beteende i olika enheter (filer / klasser / moduler)?
    Det verkar inte vara ett giltigt skäl att påtvinga en teknik framför en annan, att lämna bort de fördelar som man föreslår på grund av brist på utvecklingsform. Hur som helst, jag pratar utan att veta vilket projekt det hänvisar till, det finns en större orsak som tvingar det sättet att arbeta på

         ChrisADR sade

      Hej,

      Det kanske kräver lite förklaring, men det jag kallar ett "bra projekt" innebär att antalet rader uttrycker att det är en hälsosam gemenskap som fortsätter växa. Det finns projekt med ett mycket mindre antal linjer, men ganska hälsosamma i sin utveckling. För att säga sanningen ja, är portage uppdelad i så många filer som möjligt, men det är alltid nödvändigt att hålla delar grupperade som bibliotek eller växlar som leder till en hel del andra funktioner. Men när man importerar ett projekt till många IDE idag innebär det att det kommer att läsa alla filer i projektet och försöka sätta rätt "visuellt" format.

      Jag hoppas kunna göra det lite tydligare 🙂 och tack för att ni kommenterade.
      hälsningar

      anonym sade

    Använder du kommandoraden? Ja, men bara när det är tillämpligt. Det vill säga när det är bekvämare och snabbare. Om jag till exempel vill installera ett visst program är det mer bekvämt för mig att skriva sudo apt install programnamn än att öppna en programvaruhanterare, söka efter det, markera det för att installera och tryck på "install". Men i allmänhet är detta inte fallet. Till exempel: om jag vill kopiera de 20 låtar som jag gillar mest från en katalog till en annan är det superbekvämt att göra Ctrl + Klicka medan du lugnt granskar en enorm lista från en filhanterare och sedan drar och släpper. Ett annat exempel: om jag vill partitionera en skiva är det mycket bättre att göra det genom gparted (ett program som kör en mängd kommandon samtidigt som du visar grafiskt hur skivan kommer att bli) än att göra det manuellt. Listan kan vara oändlig. GUI kan (faktiskt vanligtvis) göra arbetet mycket enklare, förutom att lägga till funktioner som för en viss cli-applikation kan vara omöjlig

         ChrisADR sade

      ja det beror på hur bekväm du är med kommandoraden ... till exempel:

      find dir/musica -name "archivo" -exec grep cp {} dir/nuevo \;

      med lite magi i bash kan du till och med göra en funktion som utför samma genom att sätta namnet på låten:

      Något liknande

      mover(){
      find dir/musica -name $1 -exec grep cp {} dir/nuevo \;
      }

      och redo! du kan flytta alla dina låtar med ett enkelt

      mover cancion1.mp3

      🙂 När det gäller den andra, även om GUI delvis gör jobbet "enklare" genom att undvika att komma ihåg och upprepa kommandon, är det bara användbart i allmänna ramar, när du behöver något specialiserat, gparted eller något annat GUI kan vara kort 🙂 och GUI: erna lägg inte till extra funktioner, de tar bara de som finns i CLI (inte alla) och grupperar dem, men skapar dem inte

      hälsningar

           anonym sade

        oavsett hur mycket processen automatiseras med:
        flytta sång1.mp3

        då kommer det nödvändigtvis att finnas:
        flytta sång2.mp3
        flytta sång3.mp3
        .
        .
        .
        flytta sång20.mp3
        det finns många rörliga låtar ...
        med vilken filhanterare som helst .. det tar bara 20 klick och en drag & drop-gest. Jag vet inte, men åtminstone min chef (Dolphin) tillåter mig att enkelt och supersnabbt (mindre än 5 sekunder) sortera en lista med 100 låtar efter namn, datum, storlek, taggar, ranking, album, artist, varaktighet etc. för mig är det PRODUKTIVITET och det lägger också till funktionalitet i kommandoraden.

        När det gäller det andra exemplet .. GParted: OK .. om du behöver något mycket specialiserat, som att variera standardvärdet för byte per inod vid formatering, ska du gå till konsolen .. men vän, det är inte normalt. 99% av tiden kommer GParted att tillgodose våra behov på ett mycket enkelt och mycket snabbt sätt, och åtminstone för mig, också produktiviteten

        hälsningar

             ChrisADR sade

          Tja, det är ett exempel på automatisering i sin enklaste form, som du sa "om jag vill kopiera mina 20 låtar som jag gillar mest från en katalog till en annan", räknas allt detta med den tid det tar dig att "lugnt" granska din lista efter att du har beställt den och även klicka och etc, terminalen tillåter det och mycket mer på bara en rad, kanske cirka 0.1 sekunders körning i din processor (även om den är gammal), om dina ögon och musen kan övervinna det , jag går till GUI: erna it's och det är inte så att jag sa att jag inte använder dem, de har många användbara saker, jag kommer inte att förneka det, men jag har åtminstone hittat mycket större mångsidighet i terminalen, i förutom att hjälpa mig att öva lite programmering varje dag när jag automatiserar jobb. Ett mycket vanligt ordspråk bland SysAdmins är "om du gör samma sak mer än en gång om dagen, automatisera det, om du gör det en gång om dagen i mer än två dagar, automatisera det, om du gör det ens en gång i månaden, automatisera det . "

          Men hej, när det gäller smak och färger, var och en har sin egen sak, jag begränsar mig till att dela de saker som jag gillar 🙂 och kanske finns det många människor som är "rädda" för saker som emacs, vim eller samma terminal , med dessa inlägg försöker jag bara ge dig lite självförtroende och nyfikenhet så att du kan prova dem och bestämma 🙂

          hälsningar

          PS: Jag känner till många utvecklare för vilka GUI: er inte löser saker på grund av den mängd komplexitet de behöver i sitt dagliga liv, vilket en "vanlig" användare kanske aldrig kommer att se, men det innebär inte att fler "Commons" "kan använda dessa verktyg och få samma mer mångsidiga fördelar.

               anonym sade

            Jag tror fortfarande att för den här uppgiften (och många andra) krävs det mycket mindre att använda en filhanterare än med kommandoraden ... men hej, som ni säger finns det smak och färger för alla.

            Jag förnekar inte heller är jag rädd för terminalen, men jag ser det inte som en nästan obligatorisk mening, så jag började med att säga "Kommandorad ja, men när det är lämpligt"

            När det gäller utvecklare finns det allt, men skalan tipsar helt klart åt ena sidan: Jag inbjuder dig att titta på:

            https://pypl.github.io/IDE.html

            Det verkar som om "vanliga" utvecklare ser fördelarna med att arbeta i en grafisk miljö full av anläggningar om vi jämför det med dem som satsar på att arbeta med "endast text" -redigerare.

         du bränner sade

      Till exempel: om jag vill kopiera de 20 låtar som jag gillar mest från en katalog till en annan är det superbekvämt att göra Ctrl + Klicka medan du lugnt granskar en enorm lista från en filhanterare och sedan drar och släpper.

      Det finns kommandoradsfilhanterare som är lika praktiska eller mer än grafik, som Vifm eller Ranger. Även för partitioneringsskivor finns kommandoradsapplikationer som cgdisk med ett e-curses-gränssnitt.

           ChrisADR sade

        Tja, det stämmer 🙂 Jag vet inte riktigt varför det finns så många människor som fruktar terminalen, det är faktiskt ett mycket robust och mångsidigt verktyg, något som alla bör prova minst en gång i djupet.

        Tack för delning och hälsningar.

           anonym sade

        Ja, terminalfilhanterare finns före grafik. När det gäller praktik beror det på vad du vill ha. Alla grafiska filhanterare är försedda med flikar, favoriter, visningslägen, förhandsgranskning, möjligheten att beställa den på 1000 olika sätt, ansluta en terminal, installera plugins, etc, etc, etc. vilket gör dem mycket mer mångsidiga än någon textfilhanterare.

        Bra behöver inte nödvändigtvis vara ful

         chupy35 sade

      det är bara att du lär dig att göra vad du gör i cli, och jag garanterar att det blir lättare, vad du nämner väldigt enkelt skulle du göra med rsync och du kan enkelt göra det till ett manus.

      Jag rekommenderar en cli-filhanterare som heter ranger som har allt du nämner.

           godel sade

        För att kopiera de 20 låtarna gör jag en lista med "ls * .ogg> top20". Sedan går jag till Vim och väljer (ta bort det jag inte vill ha) de låtar jag vill ha. I slutet gör jag "cp $ (cat top20) otrodir" och det är allt. Detta är bekvämare än att välja med musen och att de 19 låtarna som redan hade valts bort av misstag.

      Alberto cardona sade

    Underbar!!
    Jag kan fortfarande inte bestämma mig för att installera Gentoo 🙁 (jag är på BunsenLabs) Jag använder för närvarande openbox och använder nano för mina Bash-skript
    Men det får mig att vilja våga in i Vim eller Emacs!
    hälsningar
    Jag tycker om att läsa dina inlägg

         ChrisADR sade

      Tack så mycket Alberto 🙂 Jag är väldigt glad att du gillar mina artiklar, jag tycker om att skriva inläggen.
      Jag hoppas att du muntrar upp och naturligtvis gör det, saken är att alltid prova något nytt 🙂

      ChrisADR sade

    Nåväl med detta svarar jag slutligen på de två sista kommentarerna och jag skulle uppskatta att moderatorerna inte accepterar mer om det, detta går ingenstans och tanken är inte att fylla listan med kommentarer med en rad argument för eller emot en eller Övrig.

    När det gäller "mångsidighet", kanske de som tycker detta anser att endast GUI har plugins, men sanningen är att terminal-plugins är lika varierade och funktionella som de som använder dem, det tydligaste exemplet är

    https://vimawesome.com/

    En nästan oändlig lista med plugin-program för vim som gör den mer mångsidig än många IDEs ... och talar om, den länken nämner inte att den listan innehåller personer som använder IDE på Windows och Mac, vilket faktiskt talar mycket bättre om Vim talar om Förmörkelse eftersom om vi jämför antalet personer som använder Eclipse på de tre plattformarna, har Vim inget att skämmas för att ha en välförtjänt 4: e plats.

    Men att gå lite längre ... att "vanliga" människor använder något säger inte att detta nödvändigtvis är bra, men förmodligen skulle Windows vara mycket bättre än andra system 🙂 kanske är det bara att de föredrar att inte lära sig att använda något för att de föredrar det enkla alternativet ... eller för att ditt företag alltså har beslutat att implementera standarden (Eclipse är standarden i många företag, det skulle förklara det stora antalet användare ... precis som Android och Visual Studio, som är det enda sättet att arbeta med sina respektive språk ... medan Vim Det är ett GRATIS val för dem som använder det)

    . "Ful" är en mycket subjektiv term, jag kan betrakta "ful" utformningen av Qt, eller WebKit, eller till och med Mac OS-gränssnittet ... men det betyder inte att någon annan ser det så, det är bara en fråga om vana paraplyer

    hälsningar

         anonym sade

      Jag respekterar önskan att inte vilja ge rätten att svara.

      endast för information:
      https://vim.sourceforge.io/download.php

      Claudio sade

    Jag håller helt med Anonym, men i mitt fall är jag en enkel användare utan djup kunskap från en analytiker eller programmerare. Och som sådan behöver jag ett GUI för att misslyckas med mig många av skatterna i Linux, till exempel idag och eftersom det är år 2017 finns det inget GUI-program som gör det enkelt att dela mappar i ett Linux-nätverk, och jag säger Linux, jag inte få dem Med Samba och Windows talar jag om ett rent Linux-nätverk. För att kunna dela i ett Linux-nätverk måste du konfigurera en viss NFS och bara från kommandoraden, det slösar bort tid och jag förklarar inte varför det är så svårt att ha ett GUI som gör det enkelt som det händer i Windows .
    Enligt ChrisADR "Jag är en ung mjukvaruutvecklare" och du ser att du vet mycket om ämnet, ska du utveckla ett GUI-program som underlättar det jag just har förklarat eller är din en ren titel och skryter? Det är samma som om en läkare gav en åsikt om hur det är bättre att utföra en operation utan att någonsin ha gjort en. "Du ser pingon på banan" bör du utveckla en GUI-applikation innan du ger din åsikt från din plats som "programutvecklare" och om det är bättre eller inte att använda terminalen måste du sätta dig själv i stället för vem som använder Linux och vem som använder det. Förhoppningsvis kan du se en artikel av ChrisADR, presentera och dela dess GUI-applikation, för fildelning i ett Linux-nätverk. För närvarande finns det inga, såvida du inte använder Samba bara för Windows-delning.

         Guillermo sade

      Att skapa ett program är inte något lätt på en eftermiddag, det kräver åtminstone flera veckors ansträngning och det som är värre, då har vi ansträngningen av år att fixa fel, uppdatera det tillsammans med de nya funktionsbiblioteken som gör de tidigare använda föråldrade ., förpackningen för de olika distributionerna, ...
      Men också, om du redan har SAMBA som du också kan använda mellan två GNU / Linux utan behov av Windows, varför vill du använda NFS-lösningen?
      Även om manualerna du ser online talar om Linux och Windows, följ bara instruktionerna för att dela en mapp desde linux och sedan för att ansluta till en annan nätverksmapp desde linux också.
      Det verkar som om Ubuntu 16.04 fortfarande har en enkel implementering av detta tema: http://www.hernanprograma.es/ubuntu/como-compartir-una-carpeta-desde-ubuntu-16-04-a-traves-de-samba/