Algumas palavras do nosso departamento de tradução: geralmente todo mundo quer traduzir os materiais e publicações mais recentes, e não somos exceção. Mas os terminais não são atualizados com uma vez por semana. Portanto, traduzimos para você um artigo de Antoine Bopre publicado na primavera de 2018: apesar da sólida “era” pelos padrões modernos, em nossa opinião, o material não perdeu completamente sua relevância. Além disso, o original é uma série de dois artigos, mas decidimos combiná-los em um grande post.
Os terminais ocupam um lugar especial na história do computador, mas nas últimas décadas eles foram "forçados" a sobreviver literalmente junto com a linha de comando no contexto de interfaces gráficas onipresentes.
Os emuladores de terminal substituíram seus
equivalentes de hardware , que, por sua vez, eram uma modificação de sistemas em cartões perfurados e interruptores. As distribuições modernas vêm com uma série de emuladores de terminal de todas as formas e cores. E embora muitos estejam silenciosamente satisfeitos com o terminal padrão fornecido por seu ambiente de trabalho, alguns se orgulham de usar um software francamente exótico para iniciar seu shell ou editor de texto favorito. Mas, como veremos neste artigo, nem todos os terminais foram criados com a mesma imagem e semelhança: eles variam muito em funcionalidade, tamanho e desempenho.
Alguns terminais possuem brechas de segurança surpreendentes, além disso, a maioria possui um conjunto de funções completamente diferente, do suporte à interface com guias até o script. Embora tenhamos
analisado emuladores de terminal no passado distante , 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 funções e a segunda metade avalia o desempenho.
Aqui estão os terminais que revi:
Talvez essas não sejam as versões mais recentes, já que me limitei às versões estáveis no momento em que escrevi, que pude lançar no Debian 9 ou no Fedora 27. A única exceção é Alacritty. Ele é descendente de terminais com aceleração de GPU e está escrito em um novo e incomum idioma para esta tarefa - Rust. Excluí os terminais da web da minha análise (inclusive no
Electron ), porque os testes preliminares mostraram seu desempenho extremamente ruim.
Suporte Unicode
Comecei meus testes com suporte a Unicode. O primeiro teste do terminal foi exibir uma string Unicode de
um artigo da Wikipedia : "é, Δ ,,, ק, م, ๗, あ, 叶, 葉 e 말". Este teste simples mostra se o terminal pode funcionar corretamente em todo o mundo. O terminal xterm não exibe o símbolo Árabe
Mem na configuração padrão:
Por padrão, o xterm usa a fonte "fixa" clássica, que, segundo o
Wiki , tem "cobertura Unicode significativa desde 1997". Algo acontece nessa fonte que faz com que o caractere apareça como um quadro vazio e somente quando a fonte de texto é aumentada para mais de 20 pontos é que o caractere finalmente começa a ser exibido corretamente. No entanto, essa "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 podiam funcionar corretamente com fontes. Felizmente, isso foi corrigido em versões posteriores.
Agora preste atenção ao mapeamento de strings no xterm. Acontece que o símbolo Mem e o
Qoph semítico subsequente pertencem aos scripts RTL (da
direita para a esquerda ); portanto, tecnicamente, eles devem ser exibidos da direita para a esquerda. Navegadores da Web, como o Firefox 57, manipulam corretamente a linha acima. Uma versão mais simples do texto RTL é a palavra "
Sarah " em hebraico (
שרה ).
A página wiki bidirecional diz o seguinte:
“Muitos programas de computador não podem exibir corretamente o texto bidirecional. Por exemplo, o nome hebraico “Sarah” consiste nos símbolos sin (ש) (que aparece à direita), depois resh (ר) e, finalmente, heh (ה) (que deve aparecer à esquerda). ”
Muitos terminais falham neste teste: Alacritty, os terminais derivados do VTE, Gnome e XFCE, urxvt, st e xterm, exibem "Sarah" na ordem inversa, como se escrevêssemos esse nome como "Aras".
Outro problema com os 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 para os terminais que usam o LTR English por padrão? A maioria deles não possui mecanismos especiais e alinha o texto inteiro à esquerda (incluindo o Konsole). As exceções são pterm e mlterm, que seguem os padrões e alinham essas linhas à direita.
Proteção de inserção
O próximo recurso crítico que eu determinei para mim mesmo é a proteção contra inserção. Embora seja sabido que feitiços como:
$ curl http://example.com/ | sh
são comandos de execução de código push; poucas pessoas sabem que comandos ocultos podem penetrar no console ao copiar e colar de um navegador da web, mesmo após uma inspeção completa.
O site de testes de Gianna Horne mostra brilhantemente como a equipe é inofensiva:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.git
isso se torna um incômodo ao colar do site da 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.git
Como isso funciona? O código malicioso é colocado no bloco
<span> , que é movido do campo de visão do usuário usando CSS.
O modo de pasta entre colchetes foi claramente projetado para neutralizar esses ataques. Nesse modo, os terminais envolvem o texto inserido em um par de seqüências de escape especiais para informar o shell sobre a origem desse texto. Portanto, o shell recebe um sinal de que pode ignorar caracteres especiais que o texto inserido pode conter. Todos os terminais, até o venerável xterm, suportam esta função, mas a inserção no modo entre colchetes requer suporte para um shell ou aplicativo em execução no terminal. Por exemplo, o software que usa o
GNU Readline (o mesmo Bash) precisa de um
arquivo ~ / .inputrc :
set enable-bracketed-paste on
Infelizmente, o site de teste do Horn também mostra como contornar essa proteção formatando o próprio texto e finalizando prematuramente a aplicação do modo Bracketed. Isso funciona porque alguns terminais não filtram corretamente as seqüências de escape antes de adicionar suas próprias. Por exemplo, no meu, não foi possível concluir com êxito os testes do Konsole, mesmo levando em consideração a configuração correta do arquivo
.inputrc . Isso significa que você pode facilmente obter danos à configuração do sistema devido a um aplicativo não suportado ou a um shell configurado incorretamente. Isso é especialmente perigoso ao entrar em servidores remotos, onde um estudo cuidadoso da configuração é menos comum, especialmente se você tiver muitas dessas máquinas remotas.
Uma boa solução para esse problema é o plug-in de confirmação de colagem para o terminal
urxvt , que simplesmente pede permissão para colar 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 agora é oferecer suporte a uma interface com guias, que definiremos como uma janela de terminal contendo mais alguns terminais. Essa função é diferente para terminais diferentes e, embora terminais tradicionais como o xterm não suportem guias, as encarnações de terminal mais modernas representadas pelo Xfce Terminal, GNOME Terminal e Konsole têm essa função. O Urxvt também tem suporte para guias, mas apenas se o plug-in for usado. Porém, em termos de guias de suporte, o Terminator é o líder indiscutível: ele não apenas suporta guias, mas também pode organizar 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, o que fornece uma ferramenta aproximada para executar operações em massa em vários servidores simultaneamente. Um recurso semelhante também é implementado no Konsole. Para usar esta função em outros terminais, você deve usar software de terceiros, como
Cluster SSH ,
xlax ou
tmux .
As guias funcionam especialmente bem em conjunto com os perfis: por exemplo, você pode ter uma guia para email, outra para bate-papo e assim por diante. Isso é bem suportado pelo Konsole e pelo GNOME Terminal. Ambos permitem que cada guia inicie automaticamente seu perfil. O Terminator também suporta perfis, mas não consegui encontrar uma maneira de iniciar automaticamente determinados programas quando abro uma determinada guia. Outros terminais não têm o conceito de perfil.
Ryushechki
A última coisa que considerarei na primeira parte deste artigo é a aparência dos terminais. Por exemplo, o GNOME, o Xfce e o urxvt oferecem suporte à transparência, mas recentemente eliminaram o suporte para imagens de segundo plano, forçando alguns usuários a mudarem para o terminal
Tilix . Pessoalmente, estou feliz com apenas
Xresources , que define o conjunto básico de cores de plano de fundo para o urxvt. No entanto, temas de cores personalizadas podem causar problemas. Por exemplo, o
Solarized não funciona com
aplicativos htop e
IPTraf , pois eles já usam suas próprias cores.
O terminal VT100 original não suporta cores, e os novos geralmente são limitados a uma paleta de 256 cores. Para usuários avançados que estilizam seus terminais, solicitações de shell ou barras de status de algumas maneiras complexas podem ser uma limitação desagradável.
O Gist monitora quais terminais têm suporte para True Color. Meus testes confirmam que os terminais baseados em st, Alacritty e VTE suportam perfeitamente o True Color. Outros terminais nesse sentido não se sentem muito bem 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 o urxvt, que não apenas falha no teste, mas também mostra alguns caracteres piscantes. eles.
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 do VTE, enquanto o urxvt requer um plug-in especial que transforma URLs com um clique ou um atalho de teclado. Outros terminais que testei exibem URLs de outras maneiras.
Finalmente, uma nova tendência para terminais é a opção de buffer de rolagem. Por exemplo, em st não há buffer de rolagem; assume-se que o usuário utilizará um multiplexador de terminal como o tmux e o
GNU Screen .
O Alacritty também não possui buffers de rolagem reversa, mas o suporte
será adicionado em
breve devido ao "amplo feedback" dos usuários sobre este tópico. Além dessas novas empresas, todos os terminais que testei que encontrei suportam rolagem para trás.
Subtotais
Na segunda parte do material (
no original, eram dois artigos diferentes, - aprox. Por. ) Compararemos desempenho, uso de memória e atraso. Mas já vemos que alguns dos terminais em questão apresentam sérias deficiências. Por exemplo, os usuários que trabalham regularmente com scripts RTL podem prestar atenção ao mlterm e pterm, pois lidam melhor com essas tarefas do que outros. O Konsole também teve um bom desempenho. Usuários que não trabalham com scripts RTL podem escolher outra coisa.
Do ponto de vista da segurança contra a inserção de código malicioso, o urxvt se destaca por causa de sua implementação especial de proteção contra esse tipo de ataque, o que me parece definitivamente conveniente. Quem procura sinos e assobios deve olhar para o 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 o seu ambiente favorito pode atender a todos os requisitos, mas vamos deixar essa pergunta em aberto até descobrirmos o desempenho.
Continue a conversa
Em geral, o desempenho do terminal por si só pode parecer um problema absurdo; no entanto, alguns deles demonstram um atraso surpreendentemente grande para softwares desse tipo fundamental. Também veremos o que é tradicionalmente chamado de "velocidade" (na verdade, é a velocidade de rolagem) e o consumo de memória do terminal (considerando que hoje não é tão crítico quanto décadas atrás).
Atraso
Após um estudo minucioso do desempenho do terminal, cheguei à conclusão de que o parâmetro mais importante nesse sentido é o tamanho do atraso (ping). Em seu artigo
“Imprimimos com prazer”, Pavel Fatin examinou o atraso de vários editores de texto e sugeriu que os terminais nesse sentido podem funcionar mais lentamente do que os editores de texto mais rápidos. Foi essa dica que me levou a lançar meus próprios testes e escrever este artigo.
Mas o que é um atraso e por que é tão importante? Em seu artigo, Fatin definiu como "o atraso entre pressionar uma tecla e a atualização da tela correspondente" e citou o
"Manual sobre interação homem-computador" , dizendo: "O atraso no feedback visual na tela do computador tem um efeito importante no comportamento da digitadora e em sua satisfação. "
Fatin explica que esse ping tem consequências mais profundas do que apenas satisfação: "a digitação se torna mais lenta, ocorrem mais erros, a tensão nos olhos e nos músculos aumenta". Em outras palavras, um grande atraso pode levar a erros de digitação, bem como uma diminuição na qualidade do código, pois leva a uma carga cognitiva adicional no cérebro. Pior ainda, o ping "aumenta a tensão dos olhos e músculos", o que, aparentemente, implica o
desenvolvimento de lesões profissionais no futuro (
aparentemente, o autor quer dizer problemas nos músculos dos olhos, costas, braços e, é claro, visão, - aprox. por. ) Devido ao estresse repetitivo.
Alguns desses efeitos são conhecidos há muito tempo, e os resultados de um
estudo publicado em 1976 na revista Ergonomics dizem que um atraso de 100 milissegundos "piora significativamente a velocidade da discagem". Mais recentemente,
um tempo de
resposta aceitável de 10 milissegundos foi introduzido no guia do usuário do GNOME e, se formos mais longe, a
Microsoft Research mostra que 1 milissegundo é ideal.
Fatin realizou seus testes em editores de texto; ele criou uma ferramenta portátil chamada
Typometer , que eu usei para testar o ping em emuladores de terminal. Lembre-se de que o teste foi realizado no modo de simulação: na realidade, também precisamos considerar o atraso de entrada (teclado, controlador USB etc.) e saída (buffer da placa de vídeo, monitor). Segundo Fatin, em configurações típicas é de cerca de 20 ms. Se você tiver equipamento de jogos, poderá obter um indicador de apenas 3 milissegundos. Como já temos equipamentos tão rápidos, o aplicativo também não deve apresentar seu atraso. O objetivo de Fatin é atrasar o aplicativo em até 1 milissegundo ou obter discagem sem
atraso mensurável , como no
IntelliJ IDEA 15 .
E aqui estão os resultados de minhas medições, bem como alguns resultados de Fatin, a fim de mostrar que meu experimento é consistente com seus testes:
A primeira coisa que me impressionou foi o melhor tempo de resposta para programas mais antigos, como xterm e mlterm. Com a pior latência de registro (2,4 ms), eles apresentaram melhores resultados do que o terminal moderno mais rápido (10,6 ms por st). Nem um único terminal moderno cai abaixo de um limite de 10 milissegundos. Em particular, a Alacritty não atende aos requisitos para o "emulador de terminal existente mais rápido", embora seus resultados tenham melhorado desde a primeira verificação em 2017. De fato, os autores do projeto
estão cientes da situação e estão trabalhando para melhorar a exibição. Também deve ser observado que o Vim usando o GTK3 é uma ordem de magnitude mais lenta que o seu equivalente no GTK2. A partir disso, podemos concluir que o GTK3 cria um atraso adicional, e isso se reflete em todos os outros terminais que o utilizam (Terminator, Xfce4 Terminal e GNOME).
No entanto, as diferenças podem não ser visíveis aos olhos. Como explica Fatin: "Não é necessário estar ciente do atraso para que ele tenha um efeito sobre você". Fatin também alerta para um desvio padrão: "Quaisquer irregularidades na duração do atraso (instabilidade) criam uma carga adicional devido à sua imprevisibilidade".
O gráfico acima foi tirado no Debian 9 puro (stretch) com o
gerenciador de janelas i3 . Esse ambiente fornece os melhores resultados em testes de atraso. Como se viu, o GNOME cria um ping extra de 20 ms para todas as dimensões. Uma possível explicação para isso é a presença de programas com processamento síncrono de eventos de entrada. Fatin cita um exemplo do
Workrave para este caso, que adiciona um atraso ao processar todos os eventos de entrada de forma síncrona. Por padrão, o GNOME também possui um gerenciador de janelas
Mutter que cria um nível extra de buffer, que afeta o ping e adiciona um atraso mínimo de 8 milissegundos.
Velocidade de rolagem
O próximo teste é o teste tradicional de "velocidade" ou "largura de banda", que mede a rapidez com que o terminal pode rolar por uma página, exibindo uma grande quantidade de texto na tela. A mecânica do teste varia; o teste original era apenas gerar a mesma sequência de texto com o comando seq. Outros testes incluem um teste de Thomas E. Dickey (o mantenedor do xterm), que
baixa repetidamente
o arquivo terminfo.src . Em outra análise de desempenho do terminal,
Den Luu usa uma cadeia de bytes aleatórios codificada em base32, que é enviada ao terminal usando cat. Luu considera que esse teste é "tão inútil quanto se pode imaginar" e sugere usar a resposta do terminal como o principal indicador. Dickey também considera seu teste enganoso. No entanto, os dois autores reconhecem que a largura de banda da janela do terminal pode ser um problema. Luu encontrou o Emacs Eshell congelando ao exibir arquivos grandes, e Dickie otimizou o terminal para se livrar da lentidão visual do xtrerm. Portanto, ainda há algumas razões para esse teste, mas como o processo de renderização é muito diferente de terminal para terminal, ele também pode ser usado como um componente de teste para verificar outros parâmetros.
Aqui vemos que rxvt e st estão à frente da concorrência, seguidos pela muito mais recente Alacritty, que está sendo desenvolvida com foco na velocidade. Em seguida, vêm o Xfce (família VTE) e o Konsole, que funcionam quase o dobro da velocidade. O último é xterm, com um índice cinco vezes mais lento que o rxvt. Durante o teste, o xterm também ondulou, era difícil ver o texto que passava, mesmo que fosse a mesma linha. O Konsole acabou sendo rápido, mas às vezes era "complicado": a tela pendia de vez em quando, mostrando o texto parcialmente ou não exibindo nada. Outros terminais exibiam strings claramente, incluindo st, Alacritty e rxvt.
Dickie explica que as diferenças de desempenho estão relacionadas ao design de buffers de rolagem em diferentes terminais. Em particular, ele acusa o rxvt e outros terminais de "não seguir as regras gerais":
“Ao contrário do xterm, o rxvt não tentou exibir todas as atualizações. Se ele ficar para trás, ele descartará algumas atualizações para recuperar o atraso. Isso teve um efeito maior na velocidade de rolagem imaginária do que na organização da memória interna. Uma desvantagem foi que a animação ASCII era um tanto imprecisa. ”
Para corrigir essa aparente lentidão do xterm, Dickey sugere o uso do recurso
fastScroll , que permite ao xterm descartar algumas atualizações da tela para acompanhar o fluxo. Meus testes confirmam que o fastScroll melhora o desempenho e eleva o xterm ao mesmo nível que o rxvt. Essa é, no entanto, uma muleta bastante grosseira, como explica o próprio Dickey: "às vezes o xterm - como o konsole - parece parar, pois espera um novo conjunto de atualizações de tela depois que algumas delas forem excluídas". Nesse sentido, parece que outros terminais encontraram o melhor compromisso entre velocidade e integridade da tela.
Consumo de recursos
Independentemente da conveniência de considerar a velocidade de rolagem como um indicador de desempenho, este teste permite simular a carga nos terminais, o que, por sua vez, permite medir outros parâmetros, como uso de memória ou disco. As métricas foram obtidas executando o teste
seq especificado sob o monitoramento do processo Python. Ele coletou dados do contador
getrusage () para
ru_maxrss , a soma de
ru_oublock e
ru_inblock e um timer simples.
Neste teste, o ST ocupa o primeiro lugar com o menor consumo médio de memória de 8 MB, o que não é surpreendente quando você considera que a principal idéia do projeto é a simplicidade. Mlterm, xterm e rxvt consomem um pouco mais - cerca de 12 MB. Alacritty tem outro resultado notável, que requer 30 MB para funcionar. Depois, existem terminais da família VTE com indicadores de 40 a 60 MB, o que é bastante. Esse consumo pode ser explicado pelo fato de que esses terminais usam bibliotecas de nível superior, por exemplo, GTK. O Konsole vem por último com um enorme consumo de 65 MB de memória durante os testes, embora isso possa ser justificado por sua ampla gama de funções.
Comparado aos resultados anteriores obtidos dez anos atrás, todos os programas começaram a consumir significativamente mais memória. Anteriormente, o Xterm exigia 4 MB, mas agora - 15 MB apenas para execução. O Rxvt tem um aumento semelhante no consumo, que agora requer 16 MB prontos para uso. O terminal Xfce ocupa 34 MB, três vezes mais que antes, mas o Terminal GNOME requer apenas 20 MB. Obviamente, todos os testes anteriores foram realizados em uma arquitetura de 32 bits. Na ACV de 2012, Rusty Russell
disse que existem muitos outros motivos sutis que podem explicar o aumento no consumo de memória. Com tudo isso, agora estamos vivendo uma época em que temos gigabytes de memória inteiros, para que possamos lidar com isso de alguma forma.
No entanto, não posso deixar de sentir que alocar mais memória para um software fundamental como um terminal é um desperdício de recursos. , «», , - , Linux- ( , ). , . , GNOME Terminal, Konsole, urxvt, Terminator Xfce Terminal Daemon-, , .
-: , , . , VTE (
2010 , ). , , , AES256 GCM (
0.39.2 ). , VTE, …
Conclusão
, VTE , , . , VTE- Daemon-, . , , , - , . VTE (), GNOME. , VTE . , Linux , . - . , xterm mlterm 10 , .
, - Linux . , . , Wayland : Typometer, , , Wayland — . , Wayland , X.org, , - .