Algumas palavras do nosso escritório de tradução: normalmente todos se esforçam para traduzir os materiais e publicações mais recentes, e nós não somos exceção. Mas os terminais não são atualizados uma vez por semana. Por isso, traduzimos para você um artigo de Antoine Beaupré, publicado na primavera de 2018: apesar de sua considerável “idade” para os padrões modernos, em nossa opinião, o material não perdeu em nada sua relevância. Além disso, originalmente esta era uma série de dois artigos, mas decidimos combiná-los em uma grande postagem.
Os terminais ocupam um lugar especial na história dos computadores, mas nas últimas décadas foram forçados a sobreviver ao lado da linha de comando à medida que as interfaces gráficas se tornaram onipresentes. substituiu o seu próprio , que, por sua vez, foram uma modificação de sistemas baseados em cartões perfurados e interruptores. As distribuições modernas vêm com uma variedade de emuladores de terminal de todos os formatos e cores. E embora muitos estejam satisfeitos com o terminal padrão fornecido por seu ambiente de trabalho, alguns usam orgulhosamente softwares exóticos para executar seu shell ou editor de texto favorito. Mas, como veremos neste artigo, nem todos os terminais foram criados na mesma imagem: eles diferem muito em funcionalidade, tamanho e desempenho.
Alguns terminais apresentam falhas de segurança surpreendentes, e a maioria possui um conjunto de funções completamente diferente, desde suporte para interface com guias até scripts. Embora nós , este artigo é uma atualização do material anterior que ajudará os leitores a determinar qual terminal usar em 2018. A primeira metade do artigo compara recursos e a segunda avalia o desempenho.
Aqui estão os terminais que analisei:
Estas podem não ser as versões mais recentes, já que eu estava limitado a compilações estáveis no momento em que escrevi, que consegui implementar no Debian 9 ou Fedora 27. A única exceção é o Alacritty. É descendente de terminais acelerados por GPU e é escrito em uma linguagem nova e incomum para esta tarefa - Rust. Excluí terminais web da minha análise (incluindo aqueles em ), porque os testes preliminares mostraram seu desempenho extremamente fraco.
Suporte Unicode
Comecei meus testes com suporte Unicode. O primeiro teste dos terminais foi exibir a string Unicode do : “é, Δ, И, ק, م, ๗, あ, 叶, 葉 e 말.” Este teste simples mostra se o terminal pode funcionar corretamente em todo o mundo. terminal xterm não exibe caracteres árabes na configuração padrão:
Por padrão, o xterm usa a fonte clássica "fixa", que, de acordo com , tem "cobertura Unicode substancial desde 1997". Há algo acontecendo nesta fonte que faz com que o caractere apareça como um quadro em branco e somente quando a fonte do texto é aumentada para mais de 20 pontos é que o caractere finalmente começa a ser exibido corretamente. No entanto, esta “correção” interrompe a exibição de outros caracteres Unicode:
Essas capturas de tela foram tiradas no Fedora 27, pois deu melhores resultados que o Debian 9, onde algumas versões mais antigas de terminais (especificamente mlterm) não conseguiam lidar com fontes corretamente. Felizmente isso foi corrigido em versões posteriores.
Agora observe como a linha é exibida no xterm. Acontece que o símbolo Mem e o seguinte semítico consulte scripts de estilo RTL (), portanto, tecnicamente, eles devem ser exibidos da direita para a esquerda. Navegadores da Web como o Firefox 57 lidam corretamente com a linha acima. Uma versão mais simples do texto RTL é a palavra ""em hebraico (). diz o seguinte:
“Muitos programas de computador não conseguem exibir texto bidirecional corretamente. Por exemplo, o nome hebraico "Sarah" consiste nos caracteres sin (ש) (que aparece à direita), depois resh (ר) e finalmente he (ה) (que deve aparecer à esquerda)."
Muitos terminais falham neste teste: Alacritty, terminais Gnome e XFCE derivados de VTE, urxvt, st e xterm exibem "Sara" na ordem inversa, como se tivéssemos escrito o nome como "Aras".
Outro problema com textos bidirecionais é que eles precisam estar alinhados de alguma forma, especialmente quando se trata de misturar textos RTL e LTR. Os scripts RTL devem ser executados no lado direito da janela do terminal, mas o que deve acontecer com os terminais cujo padrão é o inglês LTR? A maioria deles não possui nenhum mecanismo especial e alinha todo o texto à esquerda (inclusive no Konsole). As exceções são pterm e mlterm, que aderem aos padrões e alinham essas linhas à direita.
Proteção de inserção
O próximo recurso crítico que identifiquei é a proteção anti-inserção. Embora seja amplamente conhecido que feitiços como:
$ curl http://example.com/ | shsão comandos push de execução de código, poucas pessoas sabem que comandos ocultos podem entrar no console ao copiar e colar de um navegador da web, mesmo após uma inspeção cuidadosa. mostra brilhantemente o quão inócuo é o comando:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitse torna um grande incômodo quando colado do site de Horn no terminal:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust!
Here'"'"'s the first line of your /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitComo funciona? Código malicioso está incluído no bloco , que é removido da visualização do usuário usando CSS.
foi claramente concebido para neutralizar tais ataques. Neste modo, os terminais colocam o texto colado em um par de sequências de escape especiais para informar ao shell sobre a origem do texto. Isso informa ao shell que ele pode ignorar caracteres especiais que o texto colado possa conter. Todos os terminais até o venerável xterm suportam esse recurso, mas colar no modo colchetes requer suporte do shell ou aplicativo em execução no terminal. Por exemplo, software que utiliza (mesmo Bash), precisa de um arquivo ~/.inputrc:
set enable-bracketed-paste onInfelizmente, o site de teste de Horn também mostra como contornar essa proteção por meio da própria formatação do texto e acabar prematuramente aplicando o modo entre colchetes a ele. Isso funciona porque alguns terminais não filtram corretamente as sequências de escape antes de adicionar as suas próprias. Por exemplo, no meu nunca consegui completar com sucesso os testes do Konsole mesmo com a configuração correta .inputrc arquivo. Isso significa que você pode facilmente corromper a configuração do sistema devido a um aplicativo não compatível ou a um shell configurado incorretamente. Isto é especialmente perigoso ao fazer login em servidores remotos, onde o trabalho cuidadoso de configuração é menos comum, especialmente se você tiver muitas dessas máquinas remotas.
Uma boa solução para este problema é o plugin de confirmação de colagem para o terminal urxvt, que simplesmente pede permissão para inserir qualquer texto que contenha novas linhas. Não encontrei uma opção mais segura para o ataque de texto descrito por Horn.
Guias e perfis
Um recurso popular no momento é o suporte para uma interface com guias, que definiremos como uma janela de terminal contendo vários outros terminais. Esta função difere para terminais diferentes e, embora os terminais xterm tradicionais não suportem guias, encarnações de terminais mais modernas, como Terminal Xfce, Terminal GNOME e Konsole, têm esta função. Urxvt também oferece suporte a guias, mas apenas se você usar um plugin. Mas em termos de suporte de guias em si, o Terminator é o líder indiscutível: ele não apenas suporta guias, mas também pode organizar os terminais em qualquer ordem (veja a imagem abaixo).
Outro recurso do Terminator é a capacidade de “agrupar” essas guias e enviar as mesmas teclas para vários terminais ao mesmo tempo, fornecendo uma ferramenta rudimentar para realizar operações em massa em vários servidores simultaneamente. Um recurso semelhante também está implementado no Konsole. Para usar este recurso em outros terminais, você deve usar software de terceiros, como , ou .
As guias funcionam especialmente bem quando combinadas com perfis: por exemplo, você pode ter uma guia para e-mail, outra para bate-papo e assim por diante. Isto é bem suportado pelo Terminal Konsole e Terminal GNOME. Ambos permitem que cada guia inicie automaticamente seu próprio perfil. O Terminator também oferece suporte a perfis, mas não consegui encontrar uma maneira de iniciar automaticamente determinados programas quando uma guia específica é aberta. Outros terminais não possuem nenhum conceito de “perfil”.
Babados
A última coisa que abordarei na primeira parte deste artigo é a aparência dos terminais. Por exemplo, GNOME, Xfce e urxvt suportam transparência, mas recentemente abandonaram o suporte para imagens de fundo, forçando alguns usuários a mudar para o terminal . Pessoalmente, estou feliz com isso e é simples xresources, que define o conjunto básico de cores de plano de fundo para urxvt. No entanto, temas de cores fora do padrão também podem criar problemas. Por exemplo, com aplicativos и , pois já utilizam cores próprias.
não suportava cores, e os novos eram frequentemente limitados a uma paleta de 256 cores. Para usuários avançados que estilizam seus terminais, prompts de shell ou barras de status de maneiras complexas podem ser uma limitação irritante. rastreia quais terminais têm suporte para "True Color". Meus testes confirmam que os terminais baseados em st, Alacritty e VTE suportam perfeitamente True Color. Outros terminais não se saem muito bem nesse quesito e, na verdade, nem exibem 256 cores. Abaixo você pode ver a diferença entre o suporte True Color nos terminais GNOME, st e xterm, que fazem um bom trabalho com sua paleta de 256 cores, e urxvt, que não apenas falha no teste, mas até mostra alguns caracteres piscando em seu lugar.
Alguns terminais também analisam o texto em busca de padrões de URL para tornar os links clicáveis. Isso se aplica a todos os terminais derivados de VTE, enquanto o urxvt requer um plug-in especial que transformaria URLs com um clique ou usando um atalho de teclado. Outros terminais que testei URLs de exibição de outras maneiras.
Finalmente, uma nova tendência nos terminais é a opcionalidade do buffer de rolagem. Por exemplo, st não possui buffer de rolagem; presume-se que o usuário usará um multiplexador de terminal como tmux e .
Alacritty também não possui buffers de retrocesso, mas seu apoio devido ao “amplo feedback” dos usuários sobre este tópico. Além desses novatos, todos os terminais que testei e que encontrei suportam rolagem reversa.
Subtotais
Na segunda parte do material (no original eram dois artigos diferentes - aprox. faixa) compararemos desempenho, uso de memória e latência. Mas já podemos constatar que alguns dos terminais em questão apresentam graves deficiências. Por exemplo, os usuários que trabalham regularmente com scripts RTL podem querer considerar mlterm e pterm, pois são melhores em lidar com tarefas semelhantes do que outros. O Konsole também teve um bom desempenho. Os usuários que não trabalham com scripts RTL podem escolher outra coisa.
Em termos de proteção contra inserção de código malicioso, o urxvt se destaca pela implementação especial de proteção contra esse tipo de ataque, o que me parece definitivamente conveniente. Para quem procura alguns recursos, vale a pena dar uma olhada no Konsole. Por fim, vale ressaltar que o VTE é uma excelente base para terminais, o que garante suporte a cores, reconhecimento de URL e assim por diante. À primeira vista, o terminal padrão que acompanha seu ambiente favorito pode atender a todos os requisitos, mas vamos deixar essa questão em aberto até entendermos o desempenho.
Nós continuamos a conversa
Em geral, o desempenho dos terminais em si pode parecer um problema absurdo, mas acontece que alguns deles apresentam latência surpreendentemente alta para software desse tipo fundamental. A seguir também veremos o que é tradicionalmente chamado de “velocidade” (na verdade, esta é a velocidade de rolagem) e o consumo de memória do terminal (com a ressalva de que isso não é tão crítico hoje como era décadas atrás).
O atraso
Após um estudo aprofundado do desempenho do terminal, cheguei à conclusão de que o parâmetro mais importante nesse sentido é a latência (ping). Em seu artigo Pavel Fatin analisou a latência de vários editores de texto e sugeriu que os terminais nesse aspecto podem ser mais lentos do que os editores de texto mais rápidos. Foi essa dica que me levou a realizar meus próprios testes e a escrever este artigo.
Mas o que é latência e por que é tão importante? Em seu artigo, Fatin definiu como “o atraso entre o pressionamento de uma tecla e a atualização da tela correspondente” e citou , que afirma: “O atraso no feedback visual na tela de um computador tem um impacto importante no comportamento e na satisfação do digitador.”
Fatin explica que esse ping tem consequências mais profundas do que apenas satisfação: “a digitação fica mais lenta, ocorrem mais erros e a tensão ocular e muscular aumenta”. Em outras palavras, um grande atraso pode levar a erros de digitação e também diminuir a qualidade do código, pois leva a uma carga cognitiva adicional no cérebro. Mas o pior é que o ping “aumenta a tensão ocular e muscular”, o que parece implicar no futuro (Aparentemente, o autor se refere a problemas nos músculos dos olhos, costas, braços e, claro, visão - aprox. faixa) devido ao estresse repetitivo.
Alguns destes efeitos são conhecidos há muito tempo e os resultados , publicado em 1976 na revista Ergonomics, disse que um atraso de 100 milissegundos “prejudica significativamente a velocidade de digitação”. Mais recentemente, o Guia do Usuário do GNOME introduziu em 10 milissegundos, e se você for mais longe, então mostra que 1 milissegundo é o ideal.
Fatin conduziu seus testes em editores de texto; ele criou um instrumento portátil chamado , que usei para testar o ping em emuladores de terminal. Lembre-se de que o teste foi realizado em modo de simulação: na realidade, precisamos levar em consideração a latência de entrada (teclado, controlador USB, etc.) e de saída (buffer da placa de vídeo, monitor). Segundo Fatin, em configurações típicas é cerca de 20 ms. Se você tiver equipamento de jogo, poderá atingir esse número em apenas 3 milissegundos. Como já temos um hardware tão rápido, o aplicativo não precisa adicionar sua própria latência. O objetivo de Fatin é trazer a latência do aplicativo para 1 milissegundo, ou até mesmo conseguir discar sem , como em .
Aqui estão os resultados das minhas medições, bem como alguns dos resultados de Fatin, para mostrar que meu experimento está de acordo com seus testes:
A primeira coisa que me impressionou foi o melhor tempo de resposta de programas mais antigos, como xterm e mlterm. Com a pior latência de registro (2,4 ms), eles tiveram desempenho melhor que o terminal moderno mais rápido (10,6 ms para st). Nenhum terminal moderno fica abaixo do limite de 10 milissegundos. Em particular, o Alacritty não atende à reivindicação de “emulador de terminal mais rápido disponível”, embora suas pontuações tenham melhorado desde sua primeira análise em 2017. Na verdade, os autores do projeto e estamos trabalhando para melhorar a exibição. Deve-se notar também que o Vim usando GTK3 é uma ordem de magnitude mais lenta que seu equivalente GTK2. Disto podemos concluir que GTK3 cria latência adicional, e isso se reflete em todos os outros terminais que o utilizam (Terminator, Terminal Xfce4 e Terminal GNOME).
No entanto, as diferenças podem não ser perceptíveis a olho nu. Como explica Fatin, “você não precisa estar ciente do atraso para que isso tenha efeito sobre você”. Fatin também alerta sobre o desvio padrão: “quaisquer perturbações na latência (jitter) criam estresse adicional devido à sua imprevisibilidade”.
O gráfico acima foi obtido no Debian 9 puro (stretch) com . Este ambiente produz os melhores resultados em testes de latência. Acontece que o GNOME cria um ping adicional de 20 ms para todas as medições. Uma possível explicação para isso é a presença de programas com processamento síncrono de eventos de entrada. Fatin dá um exemplo para tal caso , que adiciona um atraso ao processar todos os eventos de entrada de forma síncrona. Por padrão, o GNOME também vem com um gerenciador de janelas , que cria uma camada adicional de buffer, que afeta o ping e adiciona pelo menos 8 milissegundos de latência.
Velocidade de rolamento
O próximo teste é um teste tradicional de “velocidade” ou “largura de banda”, que mede a rapidez com que o terminal pode rolar uma página enquanto exibe grandes quantidades de texto na tela. A mecânica do teste varia; o teste original era simplesmente gerar a mesma string de texto usando o comando seq. Outros testes incluem o teste de Thomas E. Dickey (mantenedor do xterm), que repetidamente . Em outra revisão do desempenho do terminal usa uma string codificada em base32 de bytes aleatórios, que é enviada para o terminal usando cat. Luu considera tal teste "um benchmark tão inútil quanto se pode imaginar" e sugere o uso da resposta terminal como métrica primária. Dickey também considera seu teste enganoso. No entanto, ambos os autores reconhecem que a largura de banda da janela do terminal pode ser um problema. Luu descobriu o congelamento do Emacs Eshell ao exibir arquivos grandes, e Dickey otimizou o terminal para se livrar da lentidão visual do xtrerm. Portanto, ainda há algum mérito neste teste, mas como o processo de renderização é muito diferente de terminal para terminal, ele também pode ser usado como componente de teste para testar outros parâmetros.
Aqui vemos o rxvt e o st à frente da concorrência, seguidos pelo muito mais recente Alacritty, que foi projetado com foco no desempenho. Em seguida estão o Xfce (família VTE) e o Konsole, que são quase duas vezes mais rápidos. O último é o xterm, que é cinco vezes mais lento que o rxvt. Durante o teste, o xterm também ondulou bastante, dificultando a visualização da passagem do texto, mesmo que fosse a mesma linha. O Konsole era rápido, mas às vezes complicado: a tela congelava de vez em quando, exibindo texto parcial ou nem exibindo. Outros terminais exibiam strings claramente, incluindo st, Alacritty e rxvt.
Dickey explica que as diferenças de desempenho se devem ao design dos buffers de rolagem em diferentes terminais. Em particular, ele acusa o rxvt e outros terminais de “não seguirem as regras gerais”:
“Ao contrário do xterm, o rxvt não tentou exibir todas as atualizações. Se ficar para trás, recusará algumas atualizações para recuperar o atraso. Isso teve um impacto maior na velocidade aparente de rolagem do que na organização da memória interna. Uma desvantagem era que a animação ASCII era um tanto imprecisa."
Para corrigir essa lentidão percebida do xterm, Dickey sugere usar o recurso , permitindo que o xterm descarte algumas atualizações de tela para acompanhar o fluxo. Meus testes confirmam que o fastScroll melhora o desempenho e coloca o xterm no mesmo nível do rxvt. Esta é, no entanto, uma muleta bastante difícil, como o próprio Dickey explica: "às vezes o xterm - como o konsole - parece parar enquanto espera por um novo conjunto de atualizações de tela depois de algumas terem sido removidas." Nesse sentido, parece que outros terminais encontraram o melhor compromisso entre velocidade e integridade da tela.
Consumo de recursos
Independentemente de fazer sentido considerar a velocidade de rolagem como uma métrica de desempenho, este teste nos permite simular a carga nos terminais, o que por sua vez nos permite medir outros parâmetros como memória ou uso de disco. As métricas foram obtidas executando o teste especificado seq no monitoramento de processos Python. Ele coletou dados do medidor para ru_maxrss, quantia ru_oublock и ru_inblock e um temporizador simples.
Neste teste, o ST fica em primeiro lugar com o menor consumo médio de memória de 8 MB, o que não surpreende considerando que a ideia principal do design é a simplicidade. mlterm, xterm e rxvt consomem um pouco mais - cerca de 12 MB. Outro resultado notável é o Alacritty, que requer 30 MB para ser executado. Depois, há terminais da família VTE com cifras de 40 a 60 MB, o que é bastante. Este consumo pode ser explicado pelo fato de estes terminais utilizarem bibliotecas de nível superior, por exemplo, GTK. O Konsole vem em último lugar com um impressionante consumo de memória de 65 MB durante os testes, embora isso possa ser justificado pela sua ampla gama de recursos.
Em comparação com resultados anteriores obtidos há dez anos, todos os programas começaram a consumir visivelmente mais memória. O Xterm costumava exigir 4 MB, mas agora requer 15 MB apenas na inicialização. Há um aumento semelhante no consumo do rxvt, que agora requer 16 MB prontos para uso. O Terminal Xfce ocupa 34 MB, três vezes maior do que antes, mas o Terminal GNOME requer apenas 20 MB. Claro, todos os testes anteriores foram realizados na arquitetura de 32 bits. Na LCA 2012 Rusty Russell , que existem muitas razões mais sutis que poderiam explicar o aumento no consumo de memória. Dito isto, vivemos agora numa época em que temos gigabytes de memória, por isso vamos conseguir de alguma forma.
No entanto, não posso deixar de sentir que alocar mais memória para algo tão fundamental como o terminal é um desperdício de recursos. Esses programas deveriam ser os menores dos menores, deveriam ser capazes de rodar em qualquer “caixa”, até mesmo uma caixa de sapatos, se algum dia chegarmos ao ponto em que eles precisem ser equipados com sistemas Linux (e você sabe que assim será). ). Mas com esses números, o uso de memória se tornará um problema no futuro em qualquer ambiente que execute vários terminais, exceto alguns dos mais leves e com capacidades mais limitadas. Para compensar isso, Terminal GNOME, Konsole, urxvt, Terminator e Terminal Xfce possuem um modo Daemon que permite controlar vários terminais através de um único processo, limitando seu consumo de memória.
Durante meus testes, cheguei a outro resultado inesperado em relação à leitura e gravação de disco: não esperava ver nada aqui, mas descobri que alguns terminais gravam os dados mais volumosos no disco. Portanto, a biblioteca VTE na verdade mantém um buffer de rolagem no disco (esse recurso , e isso ainda está acontecendo). Mas, diferentemente das implementações mais antigas, agora pelo menos esses dados são criptografados usando AES256 GCM (). Mas surge uma questão razoável: o que há de tão especial na biblioteca VTE que exige uma abordagem tão não padronizada para implementação...
Conclusão
Na primeira parte do artigo, descobrimos que os terminais baseados em VTE possuem um bom conjunto de recursos, mas agora vemos que isso acarreta alguns custos de desempenho. Agora a memória não é um problema porque todos os terminais VTE podem ser controlados através de um processo Daemon, o que limita o seu apetite. No entanto, sistemas mais antigos que possuem limitações físicas na quantidade de RAM e buffers de kernel ainda podem precisar de versões anteriores de terminais, pois consomem significativamente menos recursos. Embora os terminais VTE tenham tido um bom desempenho em testes de rendimento (rolagem), sua latência de exibição está acima do limite definido no Guia do Usuário do GNOME. Os desenvolvedores de VTE provavelmente deveriam levar isso em consideração. Se levarmos em conta que mesmo para usuários novatos do Linux encontrar um terminal é inevitável, eles podem torná-lo mais amigável. Para geeks experientes, mudar do terminal padrão pode até significar menos cansaço visual e a capacidade de evitar futuras lesões e doenças relacionadas ao trabalho devido a longas sessões de trabalho. Infelizmente, apenas os antigos xterm e mlterm nos levam ao limite mágico do ping de 10 milissegundos, o que é inaceitável para muitos.
As medições de benchmark também mostraram que, devido ao desenvolvimento dos ambientes gráficos Linux, os desenvolvedores tiveram que fazer uma série de concessões. Alguns usuários podem querer consultar gerenciadores de janelas regulares, pois eles fornecem uma redução significativa de ping. Infelizmente, não foi possível medir a latência do Wayland: o programa Typometer que usei foi criado para o que o Wayland foi projetado para evitar: espionar outras janelas. Espero que a composição do Wayland tenha um desempenho melhor do que o X.org e também espero que no futuro alguém encontre uma maneira de medir a latência neste ambiente.
Fonte: habr.com