Gennemgang af andre artikler Jeg stødte på dette lille spørgsmål, der forårsagede mig en masse sjov, det er rigtigt, at en af de første ting, som brugere af andre systemer (undtagen FreeBSD) får i vores ansigt, er at vi ikke bruger GUI'erne. For at fortælle sandheden syntes det mig også meget nysgerrig i starten af min GNU / Linux-rejse. Jeg må indrømme, at jeg over tid bruger kommandolinjen meget mere end noget andet GUI-program, og mange gange foretrækker jeg kommandolinjeprogrammer frem for mere detaljerede programmer med blændende GUI'er.
Myten
Faktisk er dette intet andet end en bymyte, for i modsætning til andre systemer, hvis navne ikke vil blive nævnt her, er det i GNU / Linux, hvor du virkelig har frihed efter valg. Jeg ville ønske, at der i andre systemer var den alsidighed, der findes her. Men lad os se nærmere på denne sag, ellers er mange ting ikke klare:
servere
Vi har alle hørt ordet Server, nogle mener, at det er de supercomputere, der driver Google eller Amazon, eller den der er i din virksomhed. Men virkeligheden er, at en server svare på en arbejdsmodel. Vi bruger dette udtryk til at henvise til det faktum, at vi har et program, der er tilgængeligt for brugere (clientes) og giver dem noget. Et grundlæggende eksempel er Apache, som bruges til tjene websider på internettet. Dette program leverer html til clientes at anmode om det.
Billedserver
Men ikke kun en server kan være på de supercomputere, som Google og mange andre virksomheder muliggør, selv den "ældste" bærbare computer kan være en server, især når vi taler om billeder. Vi kører alle en server af billeder i vores bærbare computere for at have en funktionel skærm, i dette tilfælde server og kunde de er den samme person. Det mest almindelige eksempel er X (kendt som xorg-server i mange distributioner) og dens nye erstatning Wayland. Vi vil ikke give en detaljeret forklaring på, hvorfor organisationen, eller hvordan Wayland fungerer, eller de filosofier, der findes bag disse store projekter, men vi vil gøre det klart, at det er takket være dem, at vi kan have en webbrowser som Firefox eller Chrome eller mange andre programmer.
Vindueschef
Vinduesadministratorer arbejder direkte med billedserveren, deres arbejde er på et "lavere" niveau, da de administrerer (tilgiv redundansen), hvordan vinduerne oprettes, ændres, lukkes. De er normalt ret enkle, og desktop-miljøer er bygget på disse. Listen er stor, men jeg vil kun efterlade ideen om, at de er minimalistiske software, som giver dig mulighed for at have en ret grundlæggende kontrol over billedserveren.
Desktop miljø
Et mere specialiseret sæt software, der ikke kun muliggør billedserverdrift, men også giver mulighed for tilpasning. Blandt disse er de ældste og tungeste KDE og GNOME, men vi har også lettere miljøer som LXDE eller Mate, kanel osv.
CLI (kommandolinjegrænseflade)
Efter en kort gennemgang af verdenen af billedservere vender vi nu tilbage til vores emne. CLI, antyder ethvert program, der enten udføres af kommandolinjen git, vim, weechateller godt, hvad der ellers kommer til at tænke på. Du kan se, at jeg taler om programmer, der, selvom de udføres på kommandolinjen, viser en slags "grafisk grænseflade" som weechat o vim. For alle dem, der ikke har prøvet dem, anbefaler jeg dem, de er dybest set dem, jeg bruger hele dagen.
Hvorfor CLI er bedre end GUI
Lad os prøve noget ret simpelt 🙂 Den anden dag ville jeg arbejde på en patch til Portage (Gentoos pakkeleder). Som ethvert godt samarbejdsprojekt overstiger antallet af kodelinjer 70k. Prøv at åbne det i en IDE som NinjaIDE (Portage er skrevet i Python), og du vil snart bemærke, at når skærmen begynder at indlæse, bliver din maskine ekstremt langsom (i det mindste min i7 gjorde), og dette prøver bare at åbn koden, og skift til standardfarven på «hjælp».
Prøv nu at gøre det samme med vim, det belastede mig i løbet af millisekunder, og på samme tid satte det de "smukke" farver og alt andet.
CLI har været længe før
Nogle her vil sige, at disse programmer er AntiguosJeg kalder dem robust. Hvis du kunne se antallet af timer investeret i bygningen emacs, vim, gdbog hundreder af andre konsolprogrammer, bemærker du muligvis, at mængden af kode og funktionaliteter er så stor, at de praktisk talt allerede har løst alt, hvad de har brug for at løse. Mange GUI for programmer, der allerede er robuste i deres CLI, har de aldrig den samme funktionalitet, dette simpelthen fordi hvis vi for eksempel lavede en fane for hver tilgængelig underkommando git, ville vi miste os mellem mulighederne, og det ville være kontraproduktivt, fordi det ville gøre det vanskeligt at arbejde.
CLI er hurtigere
Magien begynder med nøglen Tab, dette er ikke kun din bedste ven, når du gennemsøger desktops i din terminal, men når den er korrekt konfigureret, giver den dig mulighed for at forkorte lange sætninger til 2 bogstaver og en Tab, 3 bogstaver og en Tab, eller endda et bogstav og en Tab.
Men dette er ikke den eneste fordel, de af os, der har taget sig tid til at lære vim o emacs Vi kan sige, at selv om læringskurven er lidt højere end IDE'erne i disse dage, er produktivitetsresultaterne i sidste ende fantastiske, man kan ikke forestille sig den tid, der kan gå tabt, når man bevæger en mus. At have dine hænder på tastaturet 90% af tiden lærer ikke kun koncentration, desuden gør det faktum at skrive så meget på tastaturet dig ret smidig og produktiv. Og nu vender vi tilbage til det forrige punkt, der har været med os så længe, at programmer som disse allerede har alle de funktioner, som nogen kunne tænke på, et ret almindeligt ordsprog for dem af os, der bruger vim, kommer til at tænke på:
Hvis du bruger mere end 4 taster, kan der være en bedre måde.
Enkel, men kraftfuld, vim giver dig mulighed for at gøre alt med det store antal nøgler og mulige kombinationer, man stopper aldrig med at lære, men det er også rigtigt, at for at kunne bruge det er det ikke nødvendigt at kende dem alle, omkring 10 eller 15 er nok til at starte være mere produktive.
CLI giver dig fuld kontrol
Når man udfører operationer med musen eller programmer fra billedserveren, er alle de ekstra konfigurationer, der udføres i det øjeblik, man klikker, ikke altid til stede. Dette sker ikke med terminalen, her har man den absolutte kraft af hvad det udføres eller ej, med hvilken mulighed eller i hvilket omfang. Over tid indser du, at du har brug for mindre, end du tror, og det hjælper dig med at gøre tingene på en mere fokuseret måde.
GUI har også sin egen ting
Jeg vil ikke sige, at vi alle sammen altid skal bruge CLI, det er heller ikke ideelt, jeg bruger selv GUI næsten hele tiden til at skrive dette indlæg, jeg bruger min Chrome, og for at se mine e-mails bruger jeg Evolution (selvom mutt ganske for nylig). Og jeg antager, at dette er den største myte af alle ... at folk tror, at GNU / Linux bare afslutter dem, jeg kan godt lide mit skrivebordsmiljø, det er ret minimalistisk, men jeg kan lide det på den måde 🙂 Og jeg har normalt kun to eller tre programmer, der kører, min Chrome, min Evolution og min terminal 🙂
Dette er nogle af grundene til, at jeg kan lide CLI'erne så godt, og hvorfor jeg opfordrer dig til at prøve dem, de kan senere ende som om jeg bruger flere CLI'er end GUI'er.
«Som ethvert godt samarbejdsprojekt overstiger antallet af kodelinjer 70k. Denne del gjorde mig for støjende. Er der en teknisk umulighed, hvorfor koden skal komprimeres i den samme fil? Ville det ikke være bedre at adskille adfærd i forskellige enheder (filer / klasser / moduler)?
Det ser ikke ud til at være en gyldig grund til at påtvinge en teknologi frem for en anden og lade de fordele, som man foreslår på grund af manglende form for udvikling, til side. Under alle omstændigheder taler jeg uden at vide, hvilket projekt det refererer til, der er en større årsag, der tvinger den måde at arbejde på
Hej,
Nå, måske kræver dette lidt forklaring, men det, jeg kalder et "godt projekt", indebærer, at antallet af linjer udtrykker, at det er et sundt samfund, der fortsætter med at vokse. Der er projekter med et meget mindre antal linjer, men ganske sunde i deres udvikling. For at fortælle sandheden ja, er portage opdelt i så mange filer som muligt, men det er altid nødvendigt at holde dele grupperet som biblioteker eller switche, der fører til en hel del andre funktioner. Men når du importerer et projekt til mange IDE'er i dag, betyder det, at du vil læse alle filerne i projektet og prøve at sætte det rigtige "visuelle" format.
Jeg håber at gøre det lidt klarere 🙂 og tak for kommentaren.
hilsen
Brug af kommandolinjen? Ja, men kun når det er relevant. Når det er mere behageligt og hurtigere. For eksempel, hvis jeg vil installere et bestemt program, er det mere praktisk for mig at skrive sudo apt install programnavn end at åbne en softwaremanager, søge efter det, markere det for at installere og trykke på "install". Men generelt er dette ikke tilfældet. For eksempel: hvis jeg vil kopiere de 20 sange, som jeg bedst kan lide fra en mappe til en anden, er det superkomfortabelt at gøre Ctrl + Klik, mens du roligt gennemgår en enorm liste fra en filhåndtering og derefter trækker og slipper. Et andet eksempel: hvis jeg vil partitionere en disk, er det meget bedre at gøre det gennem gparted (et program, der udfører en lang række kommandoer, mens du viser dig grafisk, hvordan disken vil være) end at gøre det manuelt. Listen kunne være uendelig. GUI'er kan (faktisk normalt) gøre arbejdet meget lettere, ud over at tilføje funktioner, der for en given cli-applikation kan være umulig
godt det afhænger af hvor behagelig man er med kommandolinjen ... for eksempel:
find dir/musica -name "archivo" -exec grep cp {} dir/nuevo \;med lidt magi i bash kan du endda lave en funktion, der udfører det samme bare ved at sætte navnet på sangen:
Noget som
mover(){find dir/musica -name $1 -exec grep cp {} dir/nuevo \;
}
og klar! du kan flytte alle dine sange med en simpel
mover cancion1.mp3🙂 Hvad angår det andet, selvom GUI'erne til dels gør jobbet "enklere" ved at undgå at huske og gentage kommandoer, er dette kun nyttigt i generelle rammer, når du har brug for noget specialiseret, gparted eller en hvilken som helst anden GUI kan være kort 🙂 og GUI tilføj ikke ekstra funktioner, de tager kun dem, der findes i CLI (ikke alle) og grupperer dem, men opretter dem ikke las
hilsen
uanset hvor meget processen automatiseres med:
flyt sang1.mp3
så vil der nødvendigvis være:
flyt sang2.mp3
flyt sang3.mp3
.
.
.
flyt sang20.mp3
der er mange bevægende sange ...
med enhver filhåndtering .. det tager kun 20 klik og en træk-og-slip-gestus. Jeg ved det ikke, men i det mindste giver min manager (Dolphin) mig mulighed for simpelt og superhurtigt (mindre end 5 sekunder) at sortere en liste med 100 sange efter navn, dato, størrelse, tags, placering, album, kunstner, varighed osv. for mig er det PRODUKTIVITET, og det tilføjer også funktionalitet til kommandolinjen.
Hvad angår det andet eksempel .. GParted: OK .. hvis du har brug for noget meget specialiseret, såsom at variere standardværdien af bytes pr. Inode ved formatering, skal du gå til konsollen .. men ven, det er ikke det er normalt. 99% af tiden vil GParted perfekt imødekomme vores behov på en meget enkel og meget hurtig måde, og i det mindste for mig også den produktivitet
hilsen
Nå, det er et eksempel på automatisering i sin enkleste form, som du sagde "hvis jeg vil kopiere mine 20 sange, som jeg bedst kan lide fra en mappe til en anden", tæller alt dette med den tid, det tager dig "roligt" gennemgå din liste efter bestilling og også klikke og osv., terminalen tillader det og meget mere på bare en linje, måske ca. 0.1 sekunders udførelse i din processor (selvom den er gammel), hvis dine øjne og musen kan overvinde det , jeg går til GUI'erne 🙂 og det er ikke, at jeg sagde, at jeg ikke bruger dem, de har mange nyttige ting, jeg vil ikke benægte det, men jeg har i det mindste fundet meget større alsidighed i terminalen, i ud over at hjælpe mig med at øve lidt programmering hver dag, når jeg automatiserer job. Et meget almindeligt ordsprog blandt SysAdmins er "hvis du gør det samme mere end en gang om dagen, skal du automatisere det, hvis du gør det en gang om dagen i mere end to dage, skal du automatisere det, hvis du gør det endnu en gang om måneden, skal du automatisere det . "
Men hej, med hensyn til smag og farver, hver har deres egne ting, jeg begrænser mig til at dele de ting, som jeg kan lide 🙂 og måske er der mange mennesker, der er "bange" for ting som emacs, vim eller den samme terminal , med disse indlæg forsøger jeg bare at give dig lidt selvtillid og nysgerrighed, så du kan prøve og beslutte 🙂
hilsen
PS: Jeg kender mange udviklere, for hvilke GUI'er ikke løser ting på grund af den mængde kompleksitet, de har brug for i deres daglige liv, som en "almindelig" bruger måske aldrig vil se, men det betyder ikke, at flere "Commons" "kan bruge disse værktøjer og få de samme mere alsidige fordele.
Jeg tror stadig, at det til denne opgave (og mange andre) tager meget kortere tid at bruge en filhåndtering end med kommandolinjen ... men hej, som du siger, der er smag og farver for alle.
Jeg benægter ikke eller er ikke bange for terminalen, men jeg ser det ikke som en næsten obligatorisk sætning, så jeg startede med at sige "Kommandolinje ja, men når det er relevant"
Med hensyn til udviklere er der alt, men skalaen giver tydeligt tip til den ene side: Jeg inviterer dig til at se på:
https://pypl.github.io/IDE.html
Det ser ud til, at "almindelige" udviklere ser fordelene ved at arbejde i et grafisk miljø fyldt med faciliteter sammenlignet med dem, der satser på at arbejde med "kun tekst-redaktører"
Der er kommandolinjefiladministratorer, der er så praktiske eller mere end grafik, såsom Vifm eller Ranger. Også til partitioneringsdiske er der kommandolinjeapplikationer som cgdisk med en e-curses-interface.
Nå, det er sandt 🙂 Jeg ved ikke rigtig, hvorfor så mange mennesker frygter terminalen, det er faktisk et meget robust og alsidigt værktøj, noget som alle skal prøve mindst en gang i dybden.
Tak for deling og hilsner.
Ja, terminalfilhåndtering findes før grafik. Med hensyn til anvendelighed afhænger det af, hvad du vil have. Enhver grafisk filhåndtering er forsynet med faner, favoritter, visningstilstande, forhåndsvisning, muligheden for at bestille den på 1000 forskellige måder, tilslutte en terminal, installere plugins osv. Osv. Osv. hvilket gør dem meget mere alsidige end nogen tekstfilhåndtering.
Godt behøver ikke nødvendigvis at være grim
det er bare, at du lærer at gøre, hvad du gør i cli, og jeg garanterer det, at det bliver lettere, hvad du nævner meget let, du ville gøre med rsync, og du kan nemt gøre det til et script.
Jeg anbefaler en cli-filhåndtering kaldet ranger, der har alt det, du nævner.
For at kopiere de 20 sange laver jeg en liste med "ls * .ogg> top20". Derefter går jeg til Vim og vælger (sletter det, jeg ikke vil have) de sange, jeg vil have. Til sidst laver jeg "cp $ (cat top20) otrodir", og det er det. Dette er mere praktisk end at vælge med musen, og at de 19 sange, der allerede var blevet valgt, er fravalgt ved en fejl.
Vidunderlig!!
Jeg kan stadig ikke beslutte at installere Gentoo 🙁 (jeg er på BunsenLabs) Jeg bruger i øjeblikket openbox og bruger nano til mine Bash-scripts
Men det får mig til at ønske at vove mig ind i Vim eller Emacs!
hilsen
Jeg nyder at læse dine indlæg
Mange tak Alberto 🙂 Jeg er meget glad for, at du kan lide mine artikler, jeg nyder at skrive indlæggene.
Jeg håber du muntrer op og selvfølgelig gør du det, sagen er altid at prøve noget nyt 🙂
Nå, med dette svarer jeg færdig med at svare på de sidste to kommentarer, og jeg vil sætte pris på, at moderatorerne ikke accepterer mere om det, dette går ingen steder, og ideen er ikke at udfylde listen med kommentarer med en række argumenter til fordel eller mod den ene eller den anden.
Hvad angår "alsidighed", er det måske den, der mener, at den der mener, at kun GUI'er har plugins, men sandheden er, at terminal-plugins er så varierede og funktionelle som de mennesker, der bruger dem, det klareste eksempel er
https://vimawesome.com/
En næsten uendelig liste over plugins til vim, der gør det mere alsidigt end mange IDE'er ... og når det tales om, nævnes dette link ikke, at listen inkluderer folk, der bruger IDE'er på Windows og Mac, hvilket faktisk taler meget bedre om Vim taler om Formørkelse, hvis vi sammenligner antallet af mennesker, der bruger Eclipse på de tre platforme, har Vim intet at skamme sig over at have en velfortjent 4. plads.
Men at gå lidt længere ... at "almindelige" mennesker bruger noget, siger ikke, at dette nødvendigvis er godt, men sandsynligvis ville Windows være meget bedre end andre systemer 🙂 måske er det bare, at de foretrækker ikke at lære at bruge noget, fordi de foretrækker den nemme mulighed ... eller fordi din virksomhed således har besluttet at implementere standarden (Eclipse er standarden i mange virksomheder, der ville forklare det store antal brugere ... ligesom Android og Visual Studio, som er det eneste middel at arbejde med deres respektive sprog ... mens Vim Det er et GRATIS valg for dem, der bruger det)
. "Grimt" er et meget subjektivt udtryk, jeg kan overveje "grimt" design af Qt eller WebKit eller endda Mac OS-grænsefladen ... men det betyder ikke, at en anden ser det på den måde, det er bare et spørgsmål om vane paraplyer
hilsen
Jeg respekterer ønsket om ikke at give ret til at svare.
kun til information:
https://vim.sourceforge.io/download.php
Jeg er helt enig med Anonym, men i mit tilfælde er jeg en simpel bruger uden dyb viden fra en analytiker eller programmør. og som sådan har jeg brug for en GUI for at fejle mig mange af skatte i Linux, for eksempel i dag, og da det er året 2017, er der ingen GUI-applikation, der gør det let at dele mapper på et Linux-netværk, og jeg siger Linux, jeg kan ikke få dem Med Samba og Windows taler jeg om et rent Linux-netværk. For at kunne dele i et Linux-netværk skal du konfigurere en bestemt NFS og kun fra kommandolinjen spildes tiden, og jeg forklarer heller ikke, hvorfor det er så svært at have en GUI, der gør det let, som det sker i Windows.
Ifølge ChrisADR "Jeg er en ung softwareudvikler", og du ser, at du ved meget om emnet, skal du udvikle et GUI-program, der letter det, jeg lige har forklaret, eller er din en ren titel og skryt? Det er det samme som om en læge gav sin mening om, hvordan det er bedre at udføre en operation uden nogensinde at have foretaget en. "Du ser pingos på banen", du skal udvikle en GUI-applikation, før du giver din mening fra dit sted som "softwareudvikler", og hvis det er bedre eller ikke at bruge terminalen, skal du placere dig selv i stedet for, hvem der bruger Linux og til hvem der bruger det. Forhåbentlig kan du se en artikel af ChrisADR, der præsenterer og deler sin GUI-applikation til fildeling på et Linux-netværk. I øjeblikket er der ikke nogen, medmindre du bruger Samba kun til Windows-deling.
Oprettelse af et program er ikke noget let på en eftermiddag, det kræver en indsats i det mindste flere uger, og hvad der er værre, så har vi mange års indsats for at rette fejl, opdatere det sammen med de nye funktionsbiblioteker, der gør de tidligere anvendte dem forældede ., emballagen til de forskellige distributioner, ...
Men det er også, at hvis du allerede har SAMBA, kan du også bruge mellem to GNU / Linux uden behov for nogen Windows, hvorfor vil du så bruge NFS-løsningen?
Aunque los manuales que veas por internet hablen de linux y windows, simplemente sigue las instrucciones para compartir una carpeta desde linux y luego para conectarte a otra carpeta en red desde linux også.
Det ser ud til, at Ubuntu 16.04 stadig har en nem implementering af dette tema: http://www.hernanprograma.es/ubuntu/como-compartir-una-carpeta-desde-ubuntu-16-04-a-traves-de-samba/