Revendo outros artigos me deparei com essa pequena questão que me divertiu muito, é verdade que uma das primeiras coisas que os usuários de outros sistemas (exceto FreeBSD) nos vêem é que não usamos as GUIs. Para dizer a verdade, também achei bastante curioso no início da minha jornada GNU / Linux. Devo admitir que, com o tempo, agora uso a linha de comando muito mais do que qualquer outro programa de GUI e geralmente prefiro programas de linha de comando a programas mais elaborados com GUIs deslumbrantes.
O mito
Na verdade, isso nada mais é do que um mito urbano, porque ao contrário de outros sistemas cujos nomes não serão mencionados aqui, é no GNU / Linux que você realmente tem liberdade de escolha. Gostaria que em outros sistemas houvesse a versatilidade que existe aqui. Mas vamos dar uma olhada neste assunto, caso contrário, muitas coisas não ficarão claras:
Servidores
Todos nós ouvimos a palavra Servidor, alguns acreditam que são aqueles supercomputadores que impulsionam o Google ou a Amazon, ou o único da sua empresa. Mas a realidade é que um servidor responder a um modelo de trabalho. Usamos este termo para nos referir ao fato de que temos um programa disponível para os usuários (clientes) e entrega-lhes algo. Um exemplo básico é apache, que é usado para servir páginas da web na internet. Este programa fornece html para clientes quem o pede.
Servidor de imagem
Mas não apenas um servidor pode estar nos supercomputadores que o Google e muitas outras empresas tornam possíveis, até mesmo o laptop "mais antigo" pode ser um servidor, especialmente quando falamos sobre imagens. Todos nós dirigimos um servidor de imagens em nossos laptops para ter uma tela funcional, neste caso o servidor e pelo cliente eles são a mesma pessoa. O exemplo mais comum é X (conhecido como xorg-server em muitas distribuições) e sua nova substituição Wayland. Não vamos dar uma explicação detalhada de por que a org, ou como funciona o Wayland, ou as filosofias que existem por trás desses grandes projetos, mas vamos deixar claro que é graças a eles que podemos contar com um navegador da web como Firefox ou Chrome, ou muitos outros programas.
Gerenciador de janela
Os gerenciadores de janelas trabalham diretamente com o servidor de imagem, seu trabalho é de um nível "inferior", já que gerenciam (perdoe a redundância) como as janelas são criadas, modificadas, fechadas. Eles geralmente são bastante simples e os ambientes de desktop são desenvolvidos com base neles. A lista é grande, mas deixarei aqui apenas a ideia de que são software minimalista, que permitem que você tenha um controle bastante básico do servidor de imagem.
Ambiente desktop
Um conjunto mais especializado de software que permite não apenas a operação do servidor de imagem, mas também fornece recursos de personalização. Entre estes, os mais antigos e pesados são o KDE e o GNOME, mas também temos ambientes mais leves como LXDE ou Mate, Canela, etc.
CLI (interface de linha de comando)
Após uma breve olhada no mundo dos servidores de imagem, voltamos ao nosso tópico novamente. CLI, implica em qualquer programa executado por linha de comando, git, vim, weechat, ou bem, o que mais vier à mente. Você pode ver que estou falando de programas que, embora sejam executados na linha de comando, apresentam uma espécie de "interface gráfica" como weechat o vim. Recomendo a todos aqueles que ainda não experimentaram, são basicamente os que uso o dia todo.
Por que CLI é melhor do que GUI
Vamos tentar algo bem simples 🙂 Outro dia, eu queria trabalhar em um patch para Portage (gerenciador de pacotes do Gentoo). Como qualquer bom projeto colaborativo, o número de linhas de código ultrapassa 70k. Tente abri-lo em um IDE como o NinjaIDE (Portage é escrito em Python) e você logo notará que quando a tela começa a carregar, sua máquina fica extremamente lenta (pelo menos meu i7 ficou) e isso está apenas tentando abra o código e mude para a cor padrão de «ajuda».
Agora tente fazer o mesmo com vim, me carregou em questão de milissegundos, e ao mesmo tempo colocou as cores "bonitas" e tudo mais.
CLI foi muito antes
Alguns aqui dirão que esses programas são antigo, Eu ligo para eles robusto. Se você pudesse ver o número de horas investidas na construção emacs, vim, gdb, e centenas de outros programas de console, você pode perceber que a quantidade de código e funcionalidades é tão grande que eles praticamente já resolveram tudo o que precisavam resolver. Muitos GUI para programas que já são robustos em sua CLI eles nunca terão a mesma quantidade de funcionalidade, isso simplesmente porque se fizéssemos uma guia para cada subcomando disponível, por exemplo git, nos perderíamos entre as opções e seria contraproducente, pois dificultaria o trabalho.
CLI é mais rápido
A magia começa com a chave Tab, este não é apenas o seu melhor amigo ao navegar nos desktops do seu terminal, mas quando está devidamente configurado, permite encurtar frases longas para 2 letras e um Tab, 3 letras e um Tab, ou mesmo uma letra e um Aba.
Mas esta não é a única vantagem, aqueles de nós que dedicamos tempo para aprender vim o emacs Podemos dizer que embora a curva de aprendizado seja um pouco maior que a dos IDEs hoje em dia, no final os resultados de produtividade são surpreendentes, não se pode imaginar o tempo que se pode perder ao mover um mouse. Ter as mãos no teclado 90% do tempo não ensina apenas a concentração, além disso, o fato de digitar tanto no teclado o torna bastante ágil e produtivo. E agora voltamos ao ponto anterior, por estarmos conosco há tanto tempo, programas como esses já possuem todas as funcionalidades que alguém poderia imaginar, um ditado bastante comum para quem usa o vim vem à mente:
Se você usar mais de 4 chaves, pode haver uma maneira melhor.
Simples mas poderoso, o vim permite que você faça tudo com o grande número de teclas e combinações possíveis, nunca se para de aprender, mas também é verdade que para usá-lo não é necessário conhecê-los todos, cerca de 10 ou 15 são suficientes para começar ser mais produtivo.
CLI oferece controle completo
Quando se executa operações com o mouse, ou programas desde o servidor de imagem, nem sempre estão presentes todas as configurações extras que se executam no momento do clique, isso não acontece com o terminal, aqui você tem o poder absoluto do que é executado ou não, com que opção ou em que medida. Com o tempo, você percebe que precisa de menos do que pensa e isso o ajuda a fazer as coisas de uma forma mais focada.
GUI também tem seu próprio
Não vou dizer que todos devemos usar CLI sempre, isso também não é o ideal, eu mesmo uso GUIs quase o tempo todo, para escrever este post estou usando meu Chrome, e para ver meus e-mails eu uso o Evolution (embora também use mutt muito recentemente). E eu acho que este é o maior mito de todos ... que as pessoas pensam que GNU / Linux está apenas encerrando-os, eu gosto do meu ambiente de área de trabalho, é bastante minimalista, mas gosto assim 🙂 E normalmente só tenho dois ou três programas em execução, meu Chrome, meu Evolution e meu terminal 🙂
Estas são algumas das razões pelas quais eu gosto tanto das CLIs e porque eu convido você a experimentá-las, elas podem mais tarde acabar como eu usando mais CLIs do que GUIs 😉 Saudações
«Como qualquer bom projeto colaborativo, o número de linhas de código ultrapassa 70k. Essa parte me deixou muito barulhento. Existe uma impossibilidade técnica para que o código tenha que ser compactado no mesmo arquivo? Não seria melhor separar o comportamento em diferentes entidades (arquivos / classes / módulos)?
Não parece ser um motivo válido para impor uma tecnologia sobre outra, para deixar de lado as vantagens que se propõe por falta de forma de desenvolvimento. Em todo caso, estou falando sem saber a que projeto específico se refere, há uma causa maior que obriga essa forma de trabalhar
Olá,
Bem, talvez isso requeira um pouco de explicação, mas o que chamo de "bom projeto" implica que o número de linhas expressa que é uma comunidade saudável que continua crescendo. Existem projetos com um número de linhas bem menor, mas bastante saudáveis no seu desenvolvimento. Para falar a verdade sim, o portage é dividido em tantos arquivos quanto possível, mas é sempre necessário manter as partes agrupadas como bibliotecas, ou opções que levam a várias outras funções. Mas ao importar um projeto para muitos IDEs hoje, isso significa que você vai ler todos os arquivos do projeto e tentar colocar o formato "visual" correto.
Espero deixar um pouco mais claro 🙂 e obrigado por comentar.
lembranças
Usando a linha de comando? Sim, mas apenas quando aplicável. Ou seja, quando for mais confortável e rápido. Por exemplo, se eu quiser instalar um determinado programa, é mais conveniente para mim digitar sudo apt install nome do programa do que abrir um gerenciador de software, procurá-lo, marcá-lo para instalação e pressionar "instalar". Mas geralmente este não é o caso. Por exemplo: se eu quiser copiar as 20 músicas que mais gosto de um diretório para outro, é superconfortável fazer Ctrl + Clique enquanto você analisa calmamente uma lista enorme de um gerenciador de arquivos e depois arrasta e solta. Outro exemplo: se eu quero particionar um disco é muito melhor fazê-lo através do gparted (um programa que executa uma infinidade de comandos enquanto mostra graficamente como o disco ficará) do que manualmente. A lista pode ser interminável. GUIs podem (na verdade, geralmente) tornar o trabalho muito mais fácil, além de adicionar funcionalidades que para um determinado aplicativo CLI podem ser impossíveis
bem, isso depende de quão confortável se está com a linha de comando ... por exemplo:
find dir/musica -name "archivo" -exec grep cp {} dir/nuevo \;com um pouco de magia no bash você pode até fazer uma função que executa a mesma coisa apenas colocando o nome da música:
algo parecido
mover(){find dir/musica -name $1 -exec grep cp {} dir/nuevo \;
}
e pronto! você pode mover todas as suas músicas com um simples
mover cancion1.mp3🙂 Quanto ao segundo, embora em parte as GUIs tornem o trabalho "mais simples" evitando lembrar e repetir comandos, isso só é útil em estruturas gerais, quando você precisa de algo especializado, gparted ou qualquer outra GUI pode ser curta 🙂 e a GUI não adiciona funcionalidades extras, eles apenas pegam aquelas que existem na CLI (não todas) e as agrupam, mas não as criam
lembranças
não importa o quanto o processo seja automatizado com:
mover song1.mp3
então, necessariamente, haverá:
mover song2.mp3
mover song3.mp3
.
.
.
mover song20.mp3
tem muitas canções comoventes ...
com qualquer gerenciador de arquivos .. leva apenas 20 cliques e um gesto de arrastar e soltar. Eu não sei, mas pelo menos meu empresário (Dolphin) me permite de forma simples e super-rápida (menos de 5 segundos) classificar uma lista de 100 músicas por nome, data, tamanho, tags, classificação, álbum, artista, duração, etc. para mim isso é PRODUTIVIDADE e também é adicionar funcionalidade à linha de comando.
Quanto ao outro exemplo .. GParted: OK .. se você precisa de algo muito especializado, como variar o valor padrão de bytes por inode durante a formatação, você deve ir para o console .. mas amigo, isso não é é normal. 99% das vezes o GParted atenderá perfeitamente as nossas necessidades de uma forma muito simples e rápida e, pelo menos para mim, isso também produtividade
lembranças
Bom, esse é um exemplo de automação na sua forma mais simples, como você disse "se eu quiser copiar minhas 20 músicas que mais gosto de um diretório para outro", tudo isso conta com o tempo que você leva para revisar "com calma" sua lista depois de fazer o pedido e também clicar e etc, o terminal permite isso e muito mais em apenas uma linha, talvez cerca de 0.1 segundos de execução no seu processador (mesmo que seja antigo), se seus olhos e o mouse puderem superar isso, bem, vou para as GUIs 🙂 e não é que eu disse que não as uso, elas têm muitas coisas úteis, não vou negar, mas pelo menos encontrei uma versatilidade muito maior no terminal, além de me ajudar a praticar um pouco de programação todos os dias ao automatizar trabalhos. Um ditado muito comum entre SysAdmins é "se você faz a mesma coisa mais de uma vez por dia, automatize, se você fizer uma vez por dia por mais de dois dias, automatize, se você fizer até mesmo uma vez por mês, automatize."
Mas hey, em termos de gostos e cores, cada um tem o seu, eu me limito a compartilhar as coisas que gosto 🙂 e talvez haja muitas pessoas que tenham "medo" de coisas como emacs, vim ou o mesmo terminal, com essas postagens estou apenas tentando lhe dar um pouco de confiança e curiosidade para que você possa experimentá-las e decidir 🙂
lembranças
PS: Eu conheço muitos desenvolvedores para os quais GUIs não resolvem coisas devido à quantidade de complexidade que exigem no dia a dia, que talvez um usuário "comum" nunca verá, mas isso não significa que mais usuários "Commons" pode usar essas ferramentas e obter os mesmos benefícios mais versáteis.
Ainda acho que para esta tarefa (e muitas outras) leva muito menos tempo usando um gerenciador de arquivos do que com a linha de comando ... mas hey, como você diz, existem gostos e cores para todos.
Não nego nem tenho medo do terminal, mas não o vejo como uma frase quase obrigatória, por isso comecei por dizer "Linha de comandos sim, mas quando for apropriado"
Quanto aos desenvolvedores, há de tudo, mas a escala claramente oscila para o lado: Convido você a dar uma olhada em:
https://pypl.github.io/IDE.html
Parece que os desenvolvedores "comuns" veem as vantagens de trabalhar em um ambiente gráfico repleto de facilidades quando comparados àqueles que apostam em trabalhar com editores "somente texto"
Existem gerenciadores de arquivos de linha de comando que são tão práticos ou mais do que gráficos, como Vifm ou Ranger. Também para discos de particionamento, existem aplicativos de linha de comando como o cgdisk com uma interface e ncurses.
Bem, é verdade 🙂 Eu realmente não sei por que tantas pessoas temem o terminal, na verdade é uma ferramenta muito robusta e versátil, algo que todos deveriam experimentar pelo menos uma vez em profundidade.
Obrigado por compartilhar e saudações.
Sim, os gerenciadores de arquivos do terminal existem antes dos gráficos. Quanto à praticidade, depende do que você deseja. Qualquer gerenciador de arquivos gráficos é fornecido com guias, favoritos, modos de visualização, pré-visualização, a possibilidade de ordená-lo de 1000 maneiras diferentes, de conectar um terminal, instalar plug-ins, etc, etc, etc. o que os torna muito mais versáteis do que qualquer gerenciador de arquivos de texto.
Bom não precisa necessariamente ser feio
é só que você aprende a fazer o que faz no cli, e garanto que será mais fácil, o que você mencionou muito fácil faria com o rsync e pode facilmente torná-lo um script.
Eu recomendo um gerenciador de arquivos cli chamado ranger que tem tudo o que você mencionou.
Para copiar as 20 canções, faço uma lista com "ls * .ogg> top20". Então, eu vou para o Vim e seleciono (deletando o que eu não quero) as músicas que eu quero. No final eu faço "cp $ (cat top20) otrodir" e é isso. Isso é mais conveniente do que selecionar com o mouse e que as 19 músicas que já foram escolhidas sejam desmarcadas por engano.
Maravilhoso!!
Ainda não consigo decidir instalar o Gentoo 🙁 (estou na BunsenLabs) Atualmente uso openbox e nano para meus scripts Bash
Mas me dá vontade de me aventurar no Vim ou no Emacs!
lembranças
Eu gosto de ler seus posts
Muito obrigado Alberto 🙂 Fico muito feliz que você goste dos meus artigos, gosto de escrever os posts.
Espero que você se anime e claro que sim, o importante é sempre tentar algo novo 🙂
Bom, com isso termino de responder aos dois últimos comentários e gostaria que os moderadores não aceitassem mais a respeito, isso não vai a lugar nenhum e a ideia não é preencher a lista de comentários com uma série de argumentos a favor ou contra um ou outro.
Quanto à "versatilidade", talvez quem pense isso considere que apenas GUIs possuem plugins, mas a verdade é que os plugins de terminal são tão variados e funcionais quanto as pessoas que os utilizam, o exemplo mais claro é
https://vimawesome.com/
Uma lista quase infinita de plug-ins para o vim que o torna mais versátil que muitos IDEs ... e falando nisso, esse link não menciona que essa lista inclui pessoas que usam IDEs no Windows e Mac, o que na verdade fala muito melhor sobre O Vim fala sobre o Eclipse já que se compararmos a quantidade de pessoas que usam o Eclipse nas três plataformas, o Vim não tem o que se envergonhar de ter um merecido 4º lugar.
Mas indo um pouco além ... que pessoas "comuns" usam algo não quer dizer que isso seja necessariamente bom, mas provavelmente o Windows seria muito melhor do que outros sistemas 🙂 talvez seja apenas porque eles preferem não aprender a usar algo porque preferem a opção fácil ... ou porque sua empresa decidiu então implementar o padrão (Eclipse é o padrão em muitas empresas, isso explicaria o grande número de usuários ... assim como Android e Visual Studio, que são os únicos meios de trabalhar com suas respectivas linguagens ... enquanto Vim É uma escolha GRATUITA de quem o usa)
. "Feio" é um termo muito subjetivo, posso considerar "feio" o design do Qt, ou WebKit, ou mesmo a interface do Mac OS ... mas isso não significa que outra pessoa o veja dessa forma, é apenas uma questão de hábito 🙂
lembranças
Respeito o desejo de não querer dar o direito de resposta.
Somente para informação:
https://vim.sourceforge.io/download.php
Concordo totalmente com o Anonimo, mas no meu caso sou um simples usuário, sem o conhecimento profundo de analista ou programador. E, como tal, preciso de uma GUI que me falhe muitos dos tesouros do Linux, por exemplo, hoje e sendo o ano de 2017, não há nenhum aplicativo GUI que facilite o compartilhamento de pastas em uma rede Linux, e digo Linux, não entendo Com Samba e Windows, falo de uma rede Linux net. Para poder compartilhar em uma rede Linux você tem que configurar um determinado NFS e só a partir da linha de comando, é uma perda de tempo e também não explico porque é tão difícil ter uma GUI que facilite como acontece no Windows.
De acordo com ChrisADR “Eu sou um jovem desenvolvedor de software” e você vê que sabe muito sobre o assunto, você deveria desenvolver um aplicativo GUI que facilite o que acabei de explicar ou o seu é um título puro e fanfarrão? É como se um médico desse uma opinião sobre como é melhor fazer uma cirurgia, sem nunca ter feito. «Os pingos são vistos no tribunal» deves desenvolver uma aplicação GUI antes de dares a tua opinião desde a tua posição de «programador de software» e se é melhor ou não usar o terminal, tens que te colocar no lugar de quem usa Linux e quem o usa. Espero que você possa ver um artigo de ChrisADR, apresentando e compartilhando seu aplicativo GUI, para compartilhamento de arquivos em uma rede Linux. No momento, não há nenhum, a menos que você esteja usando o Samba apenas para compartilhamento do Windows.
Criar um programa não é uma tarde fácil, requer um esforço de várias semanas no mínimo e o que é pior, então temos o esforço de anos corrigindo erros, atualizando-o junto com as novas bibliotecas de funções que tornam obsoletas as anteriormente utilizadas. , a embalagem para as diferentes distribuições, ...
Mas também, se você já tem o SAMBA que também pode usar entre dois GNU / Linux sem a necessidade de nenhum Windows, por que deseja usar a solução NFS?
Mesmo que os manuais que você vê online falem sobre Linux e Windows, basta seguir as instruções para compartilhar uma pasta desde linux e depois se conectar a outra pasta de rede desde linux também.
Parece que o Ubuntu 16.04 ainda tem uma implementação fácil desse tema: http://www.hernanprograma.es/ubuntu/como-compartir-una-carpeta-desde-ubuntu-16-04-a-traves-de-samba/