Por que preferimos a liña de comandos ás GUI?

Revisando outros artigos atopeime con esta pequena pregunta que me causou moita diversión, é certo que unha das primeiras cousas que os usuarios doutros sistemas (excepto FreeBSD) teñen na nosa cara é que non usamos as GUI. A dicir verdade, tamén me pareceu bastante curioso ao comezo da miña viaxe GNU / Linux. Debo recoñecer que co paso do tempo agora uso a liña de comandos moito máis que calquera outro programa GUI e, a miúdo, prefiro os programas de liña de comandos aos programas máis elaborados con GUI abraiantes.

O mito

En realidade isto non é máis que un mito urbano, porque a diferenza doutros sistemas cuxos nomes non se mencionarán aquí, é en GNU / Linux onde realmente tes liberdade de elección. Gustaríame que noutros sistemas houbese a versatilidade que existe aquí. Pero vexamos de preto este asunto, se non, non quedan claras moitas cousas:

Servidores

Todos escoitamos a palabra servidor, algúns cren que son esas súper computadoras que alimentan Google ou Amazon ou a da túa empresa. Pero a realidade é que a Servidor responder a modelo de traballo. Usamos este termo para referirnos ao feito de que temos un programa dispoñible para os usuarios (clientes) e dálles algo. Un exemplo básico é Apache, que se usa para servir páxinas web en internet. Este programa entrega html a clientes que o soliciten.

Servidor de imaxes

Pero non só un servidor pode estar nas súper computadoras que Google e moitas outras empresas fan posible, incluso o portátil "máis antigo" pode ser un servidor, especialmente cando falamos de imaxes. Todos corremos a servidor de imaxes nos nosos portátiles para ter unha pantalla funcional, neste caso a servidor cliente son a mesma persoa. O exemplo máis común é X (coñecido como xorg-server en moitas distribucións) e a súa nova substitución Wayland. Non imos dar unha explicación detallada de por que a organización, nin como funciona Wayland, nin as filosofías que existen detrás destes grandes proxectos, pero deixaremos claro que é grazas a eles que podemos contar cunha rede navegador como Firefox ou Chrome, ou moitos outros programas.

Xestor de xanelas

Os xestores de xanelas traballan directamente co servidor de imaxes, o seu traballo é dun nivel "máis baixo", xa que xestionan (perdoen a redundancia) como se crean, modifican e pechan as xanelas. Normalmente son bastante sinxelos e sobre eles están construídos ambientes de escritorio. A lista é grande, pero só deixarei aquí a idea de que son programas minimalistas, que permiten ter un control bastante básico do servidor de imaxes.

Contorno de escritorio

Un conxunto de software máis especializado que permite non só o funcionamento do servidor de imaxes, senón que tamén ofrece capacidades de personalización. Entre estes, o máis antigo e o máis pesado son KDE e GNOME, pero tamén temos ambientes máis lixeiros como LXDE ou Mate, Cinnamon, etc.

CLI (interface de liña de comandos)

Despois dunha breve ollada ao mundo dos servidores de imaxes, volvemos agora ao noso tema. CLI, implica calquera programa que se execute por liña de comandos git, vim, weechat, ou ben, o que máis se me ocorra. Podes ver que falo de programas que, aínda que se executan na liña de comandos, mostran unha especie de "interface gráfica" como weechat o vim. Recoméndollo a todos os que non os probaron, son basicamente os que uso todo o día.

Por que CLI é mellor que GUI

Imos probar algo bastante sinxelo 🙂 O outro día quería traballar nun parche para Portage (xestor de paquetes de Gentoo). Como calquera bo proxecto colaborativo, o número de liñas de código supera os 70. Tenta abrilo nun IDE como NinjaIDE (Portage está escrito en Python) e pronto notarás que a medida que a pantalla comeza a cargarse, a túa máquina faise moi lenta (polo menos o meu i7) e isto só intenta abrir o código e cambie á cor predeterminada de «axuda».

Agora tenta facer o mesmo con vim, cargoume en cuestión de milésimas de segundo e, ao mesmo tempo, puxo as cores "bonitas" e todo o demais.

CLI foi moito antes

Algúns aquí dirán que eses programas o son antiga, Chámolles robusto. Se puidese ver o número de horas investidas na construción emacs, vim, gdb, e outros centos de programas de consola, poden notar que a cantidade de código e funcionalidade é tan grande que practicamente resolveron todo o que precisaban resolver. Moitos GUI para os programas que xa son robustos na súa CLI nunca terán a mesma cantidade de funcionalidade, simplemente porque se fixemos unha pestana para cada subcomando dispoñible, por exemplo git, perderiamos entre as opcións e sería contraproducente, porque dificultaría o traballo.

A CLI é máis rápida

A maxia comeza coa clave Tab, este non só é o seu mellor amigo cando navega polos escritorios do seu terminal, senón que, cando está configurado correctamente, permítelle acurtar frases longas a 2 letras e unha Tabulación, 3 letras e unha Tabulación, ou incluso unha letra e unha Tabulación .

Pero esta non é a única vantaxe, os que levamos tempo para aprender vim o emacs Podemos dicir que, aínda que a curva de aprendizaxe é un pouco superior á das IDE nestes días, ao final os resultados da produtividade son sorprendentes, non se pode imaxinar o tempo que se pode perder ao mover un rato. Ter as mans no teclado o 90% das veces non só ensina a concentración, ademais, o feito de escribir tanto no teclado faino bastante áxil e produtivo. E agora volvemos ao punto anterior, estando connosco durante tanto tempo, programas coma estes xa teñen todas as funcionalidades que alguén podería pensar, vénme á cabeza un dito bastante común para os que usamos vim:

Se usa máis de 4 teclas, pode haber unha mellor forma.

Sinxelo pero potente, vim permíteche facer todo coa gran cantidade de teclas e combinacións posibles, nunca se deixa de aprender, pero tamén é certo que para usalo non é necesario coñecelas todas, unhas 10 ou 15 son o suficiente para comezar a ser máis produtivo.

CLI ofrécelle un control completo

Cando se executan operacións co rato ou programas desde o servidor de imaxes, non sempre están presentes todas as configuracións adicionais que se executan no momento de facer clic, isto non ocorre co terminal, aquí tes a potencia absoluta do que é executado ou non, con que opción ou en que medida. Co tempo decátaste de que necesitas menos do que pensas e iso axúdache a facer as cousas dun xeito máis centrado.

A GUI tamén ten o seu

Non vou dicir que todos debemos usar CLI sempre, tampouco iso é ideal, eu mesmo uso GUI case todo o tempo, para escribir este post estou usando o meu Chrome e para ver os meus correos electrónicos uso Evolution (aínda que usar tamén mutt ultimamente). E supoño que este é o mito máis grande de todos ... que a xente pensa que GNU / Linux só os termina, gústame o meu ambiente de escritorio, é bastante minimalista, pero gústame así 🙂 E normalmente só teño dous ou tres programas en execución, o meu Chrome, o meu Evolution e o meu terminal 🙂

Estas son algunhas das razóns polas que me gustan tanto as CLIs e por que te invito a que probes, máis tarde poden acabar coma min usando máis CLIs que GUI 😉 Saúdos


O contido do artigo adhírese aos nosos principios de ética editorial. Para informar dun erro faga clic en aquí.

17 comentarios, deixa os teus

Deixa o teu comentario

Enderezo de correo electrónico non será publicado. Os campos obrigatorios están marcados con *

*

*

  1. Responsable dos datos: Miguel Ángel Gatón
  2. Finalidade dos datos: controlar SPAM, xestión de comentarios.
  3. Lexitimación: o seu consentimento
  4. Comunicación dos datos: os datos non serán comunicados a terceiros salvo obrigación legal.
  5. Almacenamento de datos: base de datos aloxada por Occentus Networks (UE)
  6. Dereitos: en calquera momento pode limitar, recuperar e eliminar a súa información.

  1.   Anónimo dixo

    «Como calquera bo proxecto colaborativo, o número de liñas de código supera os 70k. Esta parte fíxome demasiado ruidoso. ¿Hai algunha imposibilidade técnica por que se teña que compactar o código no mesmo ficheiro? Non sería mellor separar o comportamento en diferentes entidades (ficheiros / clases / módulos)?
    Non parece ser unha razón válida para impoñer unha tecnoloxía sobre outra, deixar de lado as vantaxes que un propón por falta de forma de desenvolvemento. En calquera caso, falo sen saber a que proxecto concreto se refire, hai unha causa maior que obriga a esa forma de traballar

    1.    ChrisADR dixo

      Ola,

      Ben, quizais isto requira un pouco de explicación, pero o que chamo "bo proxecto" implica que o número de liñas expresa que é unha comunidade sa que segue crecendo. Hai proxectos cun número de liñas moito menor, pero bastante saudables no seu desenvolvemento. A verdade, si, o portage divídese en tantos ficheiros como sexa posible, pero sempre é necesario manter porcións agrupadas como bibliotecas ou conmutadores que leven a outras moitas funcións. Pero cando se importa un proxecto a moitos IDE hoxe, iso implica que lerá todos os ficheiros do proxecto e intentará poñer o formato "visual" correcto.

      Espero facelo un pouco máis claro 🙂 e grazas por comentar.
      lembranzas

  2.   Anónimo dixo

    Usando a liña de comandos? Si, pero só cando corresponda. É dicir, cando é máis cómodo e rápido. Por exemplo, se quero instalar un determinado programa, é máis cómodo para min escribir sudo apt install programname que abrir un xestor de software, buscalo, marcalo para a instalación e premer "instalar". Pero polo xeral este non é o caso. Por exemplo: se quero copiar as 20 cancións que máis me gustan dun directorio a outro é moi cómodo facer Ctrl + Faga clic mentres revisa tranquilamente unha enorme lista dun xestor de ficheiros e despois arrastra e solta. Outro exemplo: se quero particionar un disco é moito mellor facelo a través de gparted (un programa que executa multitude de comandos mentres che mostra gráficamente como será o disco) que facelo manualmente. A lista podería ser interminable. As GUI poden (de feito normalmente) facer o traballo moito máis doado, ademais de engadir funcións que para unha determinada aplicación de cli poden ser imposibles

    1.    ChrisADR dixo

      ben, iso depende do cómodo que estea coa liña de comandos ... por exemplo:

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

      cun pouco de maxia en bash pode incluso facer unha función que execute o mesmo só poñendo o nome da canción:

      Algo así

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

      e listo! podes mover todas as túas cancións cun sinxelo

      mover cancion1.mp3

      🙂 En canto ao segundo, aínda que en parte as GUI fan o traballo "máis sinxelo" evitando recordar e repetir comandos, isto só é útil nos marcos xerais, cando precisa algo especializado, gparted ou calquera outra GUI pode ser curta 🙂 e as GUI non engaden funcionalidades adicionais, só toman as que existen en CLI (non todas) e agrupalas, pero non as crean

      lembranzas

      1.    Anónimo dixo

        por moito que se automatice o proceso con:
        move a canción1.mp3

        entón, necesariamente, haberá:
        move a canción2.mp3
        move a canción3.mp3
        .
        .
        .
        move a canción20.mp3
        hai moitas cancións conmovedoras ...
        con calquera xestor de ficheiros .. só leva 20 clics e un xesto de arrastrar e soltar. Non sei, pero polo menos o meu xestor (Dolphin) permíteme ordenar de xeito sinxelo e súper rápido (menos de 5 segundos) unha lista de 100 cancións por nome, data, tamaño, etiquetas, ranking, álbum, artista, duración , etc. para min iso é PRODUCTIVIDADE e tamén está engadindo funcionalidades á liña de comandos.

        En canto ao outro exemplo .. GParted: OK .. se necesitas algo moi especializado como variar o valor predeterminado dos bytes por inodo ao formatear, debes ir á consola .. pero amigo, iso non é normal. O 99% das veces GParted satisfará perfectamente as nosas necesidades dun xeito moi sinxelo e moi rápido e, polo menos para min, que tamén a produtividade

        lembranzas

        1.    ChrisADR dixo

          Ben, ese é un exemplo de automatización na súa forma máis sinxela, como dixeches "se quero copiar as miñas 20 cancións que máis me gustan dun directorio a outro", todo iso conta co tempo que che leva revisar "con calma" a túa lista Despois de ordenala e facer clic en etc, o terminal permite iso e moito máis nunha soa liña, quizais aproximadamente 0.1 segundos de execución no teu procesador (aínda que sexa vello), se os teus ollos e o rato poden superalo, ben, vou ás GUI 🙂 e non é que dixen que non as uso, teñen moitas cousas útiles, non o negarei, pero polo menos atopei moita maior versatilidade no terminal, ademais a axudarme a practicar un pouco a programación todos os días ao automatizar traballos. Un dito moi común entre SysAdmins é "se fas o mesmo máis dunha vez ao día, automatízalo, se o fas unha vez ao día durante máis de dous días, automatízalo, se o fas incluso unha vez ao mes, automatízalo . "

          Pero bueno, en canto a gustos e cores, cada un ten o seu, limítome a compartir as cousas que me gustan 🙂 e quizais hai moita xente que ten "medo" a cousas como emacs, vim ou o mesmo terminal, con estas publicacións só intento darche un pouco de confianza e curiosidade para que poidas intentar decidir 🙂

          lembranzas

          PD: Coñezo a moitos desenvolvedores para os que as GUI non solucionan as cousas debido á complexidade que requiren no seu día a día, que quizais un usuario "común" nunca vexa, pero iso non implica que máis "Commons" "pode ​​usar estas ferramentas e obter os mesmos beneficios máis versátiles.

          1.    Anónimo dixo

            Aínda creo que para esta tarefa (e para moitas máis) leva moito menos tempo empregando un xestor de ficheiros que coa liña de comandos ... pero bueno, como dis, hai gustos e cores para todos.

            Non nego nin teño medo ao terminal, pero non o vexo como unha frase case obrigatoria, así que comecei dicindo "Liña de comando si, pero cando corresponde"

            En canto aos desenvolvedores, hai de todo, pero a escala claramente inclúe un lado: invítovos a que botedes unha ollada a:

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

            Parece que os desenvolvedores "comúns" ven as vantaxes de traballar nun ambiente gráfico cheo de facilidades se o comparamos cos que apostan por traballar con editores de "só texto".

    2.    queimas dixo

      Por exemplo: se quero copiar as 20 cancións que máis me gustan dun directorio a outro é moi cómodo facer Ctrl + Faga clic mentres revisa tranquilamente unha enorme lista dun xestor de ficheiros e despois arrastra e solta.

      Hai xestores de ficheiros de liña de comandos que son tan prácticos ou máis que gráficos, como Vifm ou Ranger. Tamén para particionar discos hai aplicacións en liña de comandos como cgdisk cunha interface e ncurses.

      1.    ChrisADR dixo

        Ben, é certo 🙂 Non sei realmente por que hai moita xente que teme o terminal, en realidade é unha ferramenta moi robusta e versátil, algo que todos deberían probar polo menos unha vez en profundidade.

        Grazas por compartir e saúdos.

      2.    Anónimo dixo

        Si, hai xestores de ficheiros de terminal antes dos gráficos. En canto á práctica, depende do que queiras. Calquera xestor de ficheiros gráficos inclúe pestanas, favoritos, modos de vista, vista previa, a posibilidade de ordenalo de 1000 xeitos diferentes, de conectar un terminal, instalar complementos, etc, etc, etc. o que os fai moito máis versátiles que calquera xestor de ficheiros de texto.

        O bo non ten por que ser feo

    3.    chupy35 dixo

      é só que aprendes a facer o que fas en cli e garántolle que será máis doado, o que mencionas moi fácil farías con rsync e podes facelo facilmente cun script.

      Recomendo un xestor de ficheiros cli chamado ranger que teña todo o que mencionas.

  3.   Alberto cardona dixo

    Marabilloso !!
    Aínda non podo decidir instalar Gentoo 🙁 (estou en BunsenLabs) Actualmente uso openbox e uso nano para os meus scripts de Bash
    Pero dáme ganas de aventurarme en Vim ou Emacs!
    lembranzas
    Gústame ler as túas publicacións

    1.    ChrisADR dixo

      Moitas grazas Alberto 🙂 Estou moi contento de que che gusten os meus artigos, gústame escribir as publicacións.
      Espero que vos animedes e por suposto que o fagades, a cousa é probar sempre algo novo 🙂

  4.   ChrisADR dixo

    Ben, con isto remato de responder aos dous últimos comentarios e agradecería que os moderadores non aceptasen máis ao respecto, isto non vai a ningures e a idea non é encher a lista de comentarios cunha serie de argumentos a favor ou en contra dun ou a outra.

    En canto á "versatilidade", quizais os que pensan isto consideran que só as GUI teñen complementos, pero o certo é que os complementos de terminal son tan variados e funcionais como as persoas que os usan, o exemplo máis claro é

    https://vimawesome.com/

    Unha lista case interminable de complementos para vim que o fan máis versátil que moitos IDE ... e falando diso, esa ligazón non menciona que esa lista inclúa persoas que usan IDE en Windows e Mac, o que realmente fala moito mellor de Vim Eclipse xa que se comparamos o número de persoas que usan Eclipse nas tres plataformas, Vim non ten nada que avergoñarse de ter un merecido 4o posto.

    Pero indo un pouco máis alá ... que a xente "común" use algo non di que isto sexa necesariamente bo, pero probablemente Windows sería moito mellor que outros sistemas 🙂 quizais sexa que prefiren non aprender a usar algo porque prefiren a opción fácil ... ou porque a súa empresa decidiu implementar o estándar (Eclipse é o estándar en moitas empresas, o que explicaría o gran número de usuarios ... igual que Android e Visual Studio, que son os únicos significa traballar coas súas respectivas linguas ... mentres que Vim é unha elección GRATUÍTA para quen o usa)

    . "Feo" é un termo moi subxectivo, podo considerar "feo" o deseño de Qt, ou WebKit, ou incluso a interface Mac OS ... pero iso non significa que alguén o vexa así, é só cuestión de hábito umbres

    lembranzas

    1.    Anónimo dixo

      Respecto o desexo de non querer dar dereito a contestar.

      só para información:
      https://vim.sourceforge.io/download.php

  5.   Claudio dixo

    Estou plenamente de acordo con Anonymous, pero no meu caso, son un usuario sinxelo, sen o profundo coñecemento dun analista ou programador. E, como tal, necesito unha GUI para fallarme moitos dos tesouros de Linux, por exemplo hoxe e sendo o ano 2017, non hai ningunha aplicación GUI que facilite compartir cartafoles nunha rede Linux, e digo Linux, eu non os obteñas Con Samba e Windows, falo dunha rede Linux en rede. Para poder compartir nunha rede Linux tes que configurar un determinado NFS e só desde a liña de comandos pérdese o tempo e tampouco explico por que é tan difícil ter unha GUI que o faga doado como sucede en Windows .
    Segundo ChrisADR "Son un mozo desenvolvedor de software" e ves que sabes moito sobre o tema, deberías desenvolver unha aplicación GUI que facilite o que acabo de explicar ou o teu é un título puro e gabar? É o mesmo que se un médico opinase sobre como é mellor practicar unha cirurxía sen ter feito nunca. «Os pingos vense no xulgado» debes desenvolver unha aplicación GUI antes de opinar desde o teu lugar de «desenvolvedor de software» e se é mellor ou non usar o terminal, tes que poñerte no lugar de quen usa Linux e para quen o usa. Afortunadamente podes ver un artigo de ChrisADR, que presenta e comparte a súa aplicación GUI, para compartir ficheiros nunha rede Linux. Polo momento, non os hai, a menos que esteas a usar Samba só para compartir Windows.

    1.    Guillermo dixo

      Crear un programa non é doado unha tarde, require un esforzo de varias semanas polo menos e o que é peor, entón temos o esforzo de corrixir anos, actualizándoo xunto coas novas bibliotecas de funcións que deixan obsoletas as usadas anteriormente. , o envase para as diferentes distribucións, ...
      Pero tamén, se xa ten SAMBA que tamén pode usar entre dous GNU / Linux sen necesidade de ningún Windows, por que quere empregar a solución NFS?
      Aínda que os manuais que ves en liña falan de Linux e Windows, só tes que seguir as instrucións para compartir un cartafol de Linux e despois conectarte a outro cartafol de rede de Linux.
      Parece que Ubuntu 16.04 aínda ten unha implementación sinxela deste tema: http://www.hernanprograma.es/ubuntu/como-compartir-una-carpeta-desde-ubuntu-16-04-a-traves-de-samba/