{"id":37222,"date":"2019-10-31T22:16:26","date_gmt":"2019-10-31T19:16:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/obzor-emulyatorov-terminala\/"},"modified":"2019-10-31T22:16:26","modified_gmt":"2019-10-31T19:16:26","slug":"obzor-emulyatorov-terminala","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/obzor-emulyatorov-terminala","title":{"rendered":"Vis\u00e3o geral dos emuladores de terminal","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Algumas palavras do nosso escrit\u00f3rio de tradu\u00e7\u00e3o: geralmente todos se esfor\u00e7am para traduzir os materiais e publica\u00e7\u00f5es mais recentes, e n\u00e3o somos a exce\u00e7\u00e3o. No entanto, os terminais n\u00e3o s\u00e3o algo que se atualiza toda semana. Por isso, traduzimos para voc\u00ea o artigo de Antoine Bopr\u00e9, publicado na primavera de 2018: apesar de sua idade consider\u00e1vel para os padr\u00f5es atuais, acreditamos que o material n\u00e3o perdeu relev\u00e2ncia. Al\u00e9m disso, o original \u00e9 uma s\u00e9rie de dois artigos, mas decidimos combin\u00e1-los em um grande post.<\/i><\/p>\n

\"Vis\u00e3o
\n
\nOs terminais ocupam um lugar especial na hist\u00f3ria da computa\u00e7\u00e3o, mas nas \u00faltimas d\u00e9cadas eles foram obrigados a sobreviver junto com a linha de comando, em meio \u00e0 prolifera\u00e7\u00e3o de interfaces gr\u00e1ficas. Emuladores de terminais<\/a><\/noindex> substitu\u00edram seus irm\u00e3os de hardware<\/a><\/noindex>, que, por sua vez, eram modifica\u00e7\u00f5es de sistemas baseados em cart\u00f5es perfurados e comutadores. Distributivos modernos v\u00eam com uma infinidade de emuladores de terminal de todas as formas e cores. Enquanto muitos se contentam com o terminal padr\u00e3o fornecido pelo seu ambiente de trabalho, alguns orgulhosamente utilizam softwares ex\u00f3ticos para rodar seus shells favoritos ou editores de texto. Mas, como veremos neste artigo, nem todos os terminais foram criados da mesma forma: eles diferem significativamente em funcionalidade, tamanho e desempenho.
\n<\/a><\/noindex><\/p>\n

Alguns terminais apresentam falhas de seguran\u00e7a bastante surpreendentes, al\u00e9m de a maioria ter conjuntos de funcionalidades completamente diferentes, desde suporte a interfaces com abas at\u00e9 scripts. Embora n\u00f3s tenhamos examinado emuladores de terminais no passado<\/a><\/noindex>, este artigo \u00e9 uma atualiza\u00e7\u00e3o do material anterior, que ajudar\u00e1 os leitores a determinar qual terminal usar em 2018. Na primeira metade do artigo, comparamos as funcionalidades, enquanto na segunda avaliamos o desempenho.<\/p>\n

Aqui est\u00e3o os terminais que eu examinei:<\/p>\n

\"Vis\u00e3o
\n
\nTalvez estas n\u00e3o sejam as vers\u00f5es mais recentes, uma vez que me limitei a compila\u00e7\u00f5es est\u00e1veis no momento em que escrevi este material, que consegui instalar no Debian 9 ou Fedora 27. A \u00fanica exce\u00e7\u00e3o \u00e9 o Alacritty. Ele \u00e9 um descendente de terminais com acelera\u00e7\u00e3o por GPU e foi escrito em uma linguagem incomum e nova para essa tarefa \u2014 Rust. Exclu\u00ed da minha an\u00e1lise os terminais baseados na web (inclusive, na Electron<\/a><\/noindex>), pois testes preliminares mostraram desempenho extremamente baixo.<\/p>\n

Suporte a Unicode<\/h4>\n

\nComecei meus testes com suporte a Unicode. O primeiro teste dos terminais foi a exibi\u00e7\u00e3o de uma linha sobre Unicode de um artigo na Wikip\u00e9dia<\/a><\/noindex>: \"\u00e9, \u0394, \u0419, \u05e7, \u0645, \u0e57, \u3042, \u53f6, \u8449 e \ub9d0\". Este simples teste mostra se o terminal pode funcionar corretamente em todo o mundo. O terminal xterm n\u00e3o exibe o caractere \u00e1rabe Mem<\/a><\/noindex> na configura\u00e7\u00e3o padr\u00e3o:<\/p>\n

\"Vis\u00e3o
\n
\nPor padr\u00e3o, o xterm usa uma fonte \"fixa\" cl\u00e1ssica, que, segundo a mesma Wiki<\/a><\/noindex>, tem \"abrang\u00eancia substancial em Unicode desde 1997\". Nesta fonte, algo acontece que faz o caractere aparecer como uma caixa vazia e s\u00f3 quando aumento o tamanho do texto para 20+ pontos o caractere finalmente come\u00e7a a aparecer corretamente. No entanto, esse \"conserto\" quebra a exibi\u00e7\u00e3o de outros caracteres Unicode:<\/p>\n

\"Vis\u00e3o
\n
\nEssas capturas de tela foram feitas no Fedora 27, pois este sistema ofereceu os melhores resultados em compara\u00e7\u00e3o ao Debian 9, onde algumas vers\u00f5es mais antigas dos terminais (especificamente \u2014 mlterm) n\u00e3o puderam funcionar corretamente com as fontes. Felizmente, isso foi corrigido em vers\u00f5es posteriores.<\/p>\n

Agora, observe a exibi\u00e7\u00e3o da linha no xterm. Aparentemente, o caractere Mem e o seguinte Semitic Qoph<\/a><\/noindex> pertencem a scripts de escrita RTL (right-to-left<\/a><\/noindex>), portanto, tecnicamente, eles devem ser exibidos da direita para a esquerda. Navegadores da web, como o Firefox 57, processam corretamente a linha acima. Uma variante mais simples de texto RTL \u00e9 a palavra \"Sar\u00e1<\/a><\/noindex>\" em hebraico (\u05e9\u05e8\u05d4<\/a><\/noindex>). A p\u00e1gina da Wiki sobre textos bidirecionais<\/a><\/noindex> diz o seguinte:<\/p>\n

\"Muitos programas de computador t\u00eam dificuldade em exibir corretamente texto bidirecional. Por exemplo, o nome hebraico 'Sar\u00e1' consiste nos caracteres sin (\u05e9) (que aparece \u00e0 direita), seguido de resh (\u05e8) e, finalmente, hei (\u05d4) (que deve aparecer \u00e0 esquerda)\".<\/p><\/blockquote>\n

\nMuitos terminais n\u00e3o passam neste teste: Alacritty, terminais derivados do VTE do Gnome e XFCE, urxvt, st e xterm exibem \"Sara\" ao contr\u00e1rio, como se estiv\u00e9ssemos escrevendo esse nome como \"Aras\".<\/p>\n

\"Vis\u00e3o
\n
\nOutro problema dos textos bidirecionais \u00e9 que eles precisam ser alinhados de alguma forma, especialmente quando se trata da mistura de textos RTL e LTR. Scripts RTL devem come\u00e7ar do lado direito da janela do terminal, mas o que deve acontecer para terminais que, por padr\u00e3o, funcionam com ingl\u00eas LTR? A maioria deles n\u00e3o possui mecanismos especiais e alinha todo o texto \u00e0 esquerda (incluindo no Konsole). A exce\u00e7\u00e3o s\u00e3o pterm e mlterm, que seguem os padr\u00f5es e alinham essas linhas \u00e0 direita.<\/p>\n

\"Vis\u00e3o
\n<\/p>\n

Prote\u00e7\u00e3o contra inser\u00e7\u00e3o<\/h4>\n

\nA pr\u00f3xima caracter\u00edstica cr\u00edtica que defini para mim \u00e9 a prote\u00e7\u00e3o contra inser\u00e7\u00e3o. Embora seja amplamente conhecido que feiti\u00e7os como:<\/p>\n

$ curl http:\/\/example.com\/ | sh<\/code><\/pre>\n
\ns\u00e3o comandos de execu\u00e7\u00e3o de c\u00f3digo, poucos sabem que comandos ocultos podem penetrar no console ao copiar e colar de um navegador, mesmo ap\u00f3s cuidadosa inspe\u00e7\u00e3o. Site de verifica\u00e7\u00e3o de Janna Horn<\/a><\/noindex> mostra brilhantemente como um comando que parece inofensivo:<\/p>\n
git clone git:\/\/git.kernel.org\/pub\/scm\/utils\/kup\/kup.git<\/code><\/pre>\n
\nse transforma, ao ser colado do site de Horn para o terminal, em algo bastante problem\u00e1tico:<\/p>\n
git clone \/dev\/null;\n    clear;\n\techo -n \"Hello \";\n\twhoami|tr -d 'n';\n\techo -e '!nEssa foi uma m\u00e1 ideia. N\u00e3o copie c\u00f3digo de sites nos quais voc\u00ea n\u00e3o confia! \n\tAqui est\u00e1 a primeira linha do seu \/etc\/passwd: ';\n\thead -n1 \/etc\/passwd\n\tgit clone git:\/\/git.kernel.org\/pub\/scm\/utils\/kup\/kup.git<\/code><\/pre>\n
\nComo isso funciona? O c\u00f3digo malicioso \u00e9 colocado em um bloco <\/b>, que \u00e9 movido fora da vista do usu\u00e1rio atrav\u00e9s de CSS.<\/p>\n
Modo de colagem com colchetes<\/a><\/noindex> \u00e9 explicitamente projetado para neutralizar tais ataques. Nesse modo, terminais envolvem o texto colado em um par de sequ\u00eancias de escape especiais para informar ao shell sobre a origem desse texto. Assim, o shell recebe o sinal de que pode ignorar caracteres especiais que podem estar presentes no texto colado. Todos os terminais, at\u00e9 o respeit\u00e1vel xterm, suportam essa fun\u00e7\u00e3o, mas a colagem no modo com colchetes necessita do suporte do shell ou do aplicativo executado no terminal. Por exemplo, o software que usa GNU Readline<\/a><\/noindex> (o mesmo Bash), precisa de um arquivo ~ \/.inputrc<\/b>:<\/p>\n
set enable-bracketed-paste on<\/code><\/pre>\n
\nInfelizmente, o site de testes do Horn tamb\u00e9m demonstra como contornar essa prote\u00e7\u00e3o por meio da pr\u00f3pria formata\u00e7\u00e3o do texto e finalizar prematuramente a aplica\u00e7\u00e3o do modo Bracketed. Isso funciona porque alguns terminais filtram incorretamente as sequ\u00eancias de escape antes de adicionar as suas pr\u00f3prias. Por exemplo, eu n\u00e3o consegui concluir com sucesso os testes do Konsole, mesmo considerando a configura\u00e7\u00e3o correta. .inputrc<\/b> de arquivo. Isso significa que voc\u00ea pode facilmente causar danos \u00e0 configura\u00e7\u00e3o do sistema devido a um aplicativo n\u00e3o suportado ou a um shell mal configurado. Isso \u00e9 particularmente perigoso ao acessar servidores remotos, onde uma configura\u00e7\u00e3o bem elaborada \u00e9 menos comum, especialmente se voc\u00ea tiver muitas dessas m\u00e1quinas remotas.<\/p>\n
Uma boa solu\u00e7\u00e3o para esse problema \u00e9 o plugin de confirma\u00e7\u00e3o de colagem para terminais urxvt<\/b>, que simplesmente solicita permiss\u00e3o para colar qualquer texto que contenha novas linhas. N\u00e3o encontrei uma op\u00e7\u00e3o mais segura para a ataque textual descrito pelo Horn.<\/p>\n
Guias e perfis<\/h4>\n
\nUm recurso popular atualmente \u00e9 o suporte \u00e0 interface com guias, que definiremos como uma \u00fanica janela de terminal que cont\u00e9m v\u00e1rios terminais. Para diferentes terminais, essa fun\u00e7\u00e3o varia, e embora terminais tradicionais como o xterm n\u00e3o suportem guias, as encarna\u00e7\u00f5es mais modernas, como Xfce Terminal, GNOME Terminal e Konsole, possuem tal fun\u00e7\u00e3o. O Urxvt tamb\u00e9m suporta guias, mas apenas com o uso de um plugin. No entanto, em termos de suporte a guias, o l\u00edder absoluto \u00e9 o Terminator: ele n\u00e3o apenas suporta guias, mas tamb\u00e9m pode dispor os terminais em qualquer ordem (veja a imagem abaixo).<\/p>\n
\"Vis\u00e3o
\n
\nOutra caracter\u00edstica do Terminator \u00e9 a capacidade de \"agrupar\" essas guias juntas e enviar as mesmas combina\u00e7\u00f5es de teclas para v\u00e1rios terminais ao mesmo tempo, o que fornece uma ferramenta rudimentar para executar opera\u00e7\u00f5es em massa em v\u00e1rios servidores simultaneamente. Uma fun\u00e7\u00e3o semelhante tamb\u00e9m est\u00e1 presente no Konsole. Para usar essa fun\u00e7\u00e3o em outros terminais, \u00e9 necess\u00e1rio recorrer a software de terceiros, como Cluster SSH<\/a><\/noindex>, xlax<\/a><\/noindex> ou , dem\u00f4nio<\/a><\/noindex>.<\/p>\n
As abas funcionam especialmente bem em conjunto com perfis: por exemplo, voc\u00ea pode ter uma aba para e-mail, outra para chat e assim por diante. Isso \u00e9 bem suportado pelo terminal Konsole e pelo GNOME Terminal. Ambos permitem que cada aba inicie automaticamente seu perfil. O Terminator tamb\u00e9m suporta perfis, mas n\u00e3o consegui encontrar uma maneira de iniciar automaticamente programas espec\u00edficos ao abrir uma aba determinada. Outros terminais n\u00e3o t\u00eam ideia do que \u00e9 um 'perfil'.<\/p>\n
Babados<\/h4>\n
\nA \u00faltima coisa que vou considerar na primeira parte deste artigo \u00e9 a apar\u00eancia dos terminais. Por exemplo, GNOME, Xfce e urxvt suportam transpar\u00eancia, mas recentemente retiraram o suporte para imagens de fundo, o que levou alguns usu\u00e1rios a mudarem para outro terminal. Tilix<\/a><\/noindex>. Pessoalmente, estou satisfeito e \u00e9 simples. Xresources<\/b>, que define um conjunto b\u00e1sico de cores de fundo para urxvt. No entanto, temas de cores n\u00e3o padronizados podem causar problemas. Por exemplo, Solarized<\/a><\/noindex> n\u00e3o funciona<\/a><\/noindex> com aplicativos htop<\/a><\/noindex> e IPTraf<\/a><\/noindex>, uma vez que j\u00e1 usam suas pr\u00f3prias cores.<\/p>\n
O terminal original VT100<\/a><\/noindex> n\u00e3o suportava cores, e os novos muitas vezes eram limitados a uma paleta de 256 cores. Para usu\u00e1rios avan\u00e7ados que estilizam seus terminais, as solicita\u00e7\u00f5es de shell ou as barras de estado de maneiras complexas podem se tornar uma limita\u00e7\u00e3o inconveniente. Gist<\/a><\/noindex> monitora quais terminais t\u00eam suporte para 'True Color'. Meus testes confirmam que st, Alacritty e terminais baseados em VTE suportam perfeitamente True Color. Outros terminais n\u00e3o se saem bem nesse aspecto e, na verdade, nem exibem 256 cores. Abaixo voc\u00ea pode ver a diferen\u00e7a entre o suporte a True Color nos terminais GNOME, st e xterm, que lidam bem com essa tarefa com sua paleta de 256 cores, e urxvt, que n\u00e3o s\u00f3 n\u00e3o passa no teste, mas tamb\u00e9m exibe alguns s\u00edmbolos piscantes em vez deles.<\/p>\n
\"Vis\u00e3o
\n
\nAlguns terminais tamb\u00e9m analisam texto em busca de padr\u00f5es de URL para tornar links clic\u00e1veis. Isso se aplica a todos os terminais derivados de VTE, enquanto urxvt requer um m\u00f3dulo plug-in espec\u00edfico que transforme URLs em cliques ou por meio de uma combina\u00e7\u00e3o de teclas. Outros terminais que testei exibem URLs de maneiras diferentes.<\/p>\n
Finalmente, a nova tend\u00eancia dos terminais \u00e9 a op\u00e7\u00e3o de buffer de rolagem. Por exemplo, no st n\u00e3o h\u00e1 buffer de rolagem; presume-se que o usu\u00e1rio usar\u00e1 um multiplexador de terminal, como o tmux e GNU Screen<\/a><\/noindex>.<\/p>\n
No Alacritty, tamb\u00e9m n\u00e3o h\u00e1 buffers de rolagem reversa, mas em breve haver\u00e1 suporte<\/a><\/noindex> devido ao \"extenso feedback\" sobre esse t\u00f3pico por parte dos usu\u00e1rios. Al\u00e9m desses, cada terminal que verifiquei tinha suporte \u00e0 rolagem reversa.<\/p>\n
Resultados intermedi\u00e1rios<\/h4>\n
\nNa segunda parte do material (originalmente eram dois artigos diferentes \u2014 nota do tradutor.<\/i>) vamos comparar o desempenho, o uso de mem\u00f3ria e a lat\u00eancia. Mas j\u00e1 vemos que alguns dos terminais analisados t\u00eam s\u00e9rias desvantagens. Por exemplo, usu\u00e1rios que trabalham regularmente com scripts RTL podem se interessar pelo mlterm e pterm, pois eles lidam melhor com essas tarefas. O Konsole tamb\u00e9m se destacou. Usu\u00e1rios que n\u00e3o trabalham com scripts RTL podem optar por outra op\u00e7\u00e3o.<\/p>\n
Do ponto de vista da prote\u00e7\u00e3o contra a inser\u00e7\u00e3o de c\u00f3digo malicioso, o urxvt se destaca devido \u00e0 sua implementa\u00e7\u00e3o especial de prote\u00e7\u00e3o contra esse tipo de ataque, que me parece definitivamente conveniente. Aqueles que procuram recursos adicionais devem considerar o Konsole. Por fim, \u00e9 importante mencionar que o VTE \u00e9 uma excelente base para terminais, garantindo suporte a cores, reconhecimento de URL e assim por diante. \u00c0 primeira vista, o terminal padr\u00e3o fornecido com seu ambiente favorito pode atender a todas as necessidades, mas deixaremos essa quest\u00e3o em aberto at\u00e9 analisarmos o desempenho.<\/p>\n
<\/p>\n
Continuando a conversa<\/h4>\n
<\/i>
\nNo geral, o desempenho dos terminais pode parecer uma quest\u00e3o exagerada, no entanto, descobriu-se que alguns deles demonstram uma lat\u00eancia surpreendentemente alta para um software de natureza t\u00e3o fundamental. Tamb\u00e9m discutiremos o que tradicionalmente \u00e9 chamado de \"velocidade\" (na verdade, essa \u00e9 a velocidade de rolagem) e o consumo de mem\u00f3ria do terminal (considerando que hoje isso n\u00e3o \u00e9 t\u00e3o cr\u00edtico como d\u00e9cadas atr\u00e1s).<\/p>\n
Lat\u00eancia<\/h4>\n
\nAp\u00f3s uma pesquisa minuciosa sobre o desempenho dos terminais, cheguei \u00e0 conclus\u00e3o de que o par\u00e2metro mais importante nesse aspecto \u00e9 o tamanho da lat\u00eancia (ping). Em meu artigo \u00abDigitamos com prazer\u00bb<\/a><\/noindex> Pavel Fatin analisou a lat\u00eancia de v\u00e1rios editores de texto e sugeriu que os terminais podem funcionar mais lentamente do que os editores de texto mais r\u00e1pidos. Essa sugest\u00e3o me levou, afinal, a iniciar meus pr\u00f3prios testes e escrever este artigo.<\/p>\n
Mas o que \u00e9 lat\u00eancia e por que \u00e9 t\u00e3o importante? Em seu artigo, Fatin definiu-a como \"a lat\u00eancia entre pressionar a tecla e a correspondente atualiza\u00e7\u00e3o na tela\" e citou o \"Manual de Intera\u00e7\u00e3o Humano-Computador\"<\/a><\/noindex>, que afirma: \"A lat\u00eancia na retroalimenta\u00e7\u00e3o visual na tela do computador tem um impacto significativo no comportamento do digitador e sua satisfa\u00e7\u00e3o.\"<\/p>\n
Fatin explica que essa lat\u00eancia tem consequ\u00eancias mais profundas do que apenas a satisfa\u00e7\u00e3o: \"digitar se torna mais lento, ocorrem mais erros, e a tens\u00e3o nos olhos e m\u00fasculos aumenta.\" Em outras palavras, uma maior lat\u00eancia pode resultar em erros de digita\u00e7\u00e3o, assim como na redu\u00e7\u00e3o da qualidade do c\u00f3digo, pois aumenta a carga cognitiva no c\u00e9rebro. Mas o que \u00e9 ainda pior, a lat\u00eancia \"aumenta a tens\u00e3o nos olhos e m\u00fasculos\", o que aparentemente implica no desenvolvimento de les\u00f5es ocupacionais<\/a><\/noindex> futuramente (aparentemente, o autor se refere a problemas com os m\u00fasculos dos olhos, costas, m\u00e3os e, claro, vis\u00e3o \u2013 nota da tradu\u00e7\u00e3o.<\/i>) devido \u00e0 tens\u00e3o repetida.<\/p>\n
Alguns desses efeitos s\u00e3o conhecidos h\u00e1 muito tempo, e os resultados Sistemas de gest\u00e3o de consumo de energia<\/a><\/noindex>, publicados em 1976 na revista Ergonomics, indicam que uma lat\u00eancia de 100 milissegundos \"reduz significativamente a velocidade de digita\u00e7\u00e3o\". Recentemente, no manual do usu\u00e1rio GNOME, foi introduzido um tempo de resposta aceit\u00e1vel<\/a><\/noindex> de 10 milissegundos, e se formos al\u00e9m, a Microsoft Research<\/a><\/noindex> mostra que o ideal \u00e9 de 1 milissegundo.<\/p>\n
Fatin realizou seus testes em editores de texto; ele criou uma ferramenta port\u00e1til chamada Typometer<\/a><\/noindex>, que eu usei para verificar o ping em emuladores de terminal. Lembre-se de que o teste foi realizado em modo de simula\u00e7\u00e3o: na realidade, precisamos considerar tamb\u00e9m a lat\u00eancia de entrada (teclado, controlador USB etc.) e de sa\u00edda (buffer da placa de v\u00eddeo, monitor). Segundo Fatina, em configura\u00e7\u00f5es t\u00edpicas, essa lat\u00eancia \u00e9 de cerca de 20 ms. Com equipamentos voltados para gamers, \u00e9 poss\u00edvel alcan\u00e7ar apenas 3 milissegundos. Como j\u00e1 temos esse tipo de equipamento r\u00e1pido, o aplicativo n\u00e3o deve adicionar mais lat\u00eancia. O objetivo de Fatina \u00e9 reduzir a lat\u00eancia do aplicativo para 1 milissegundo ou at\u00e9 mesmo alcan\u00e7ar um conjunto sem lat\u00eancia mensur\u00e1vel<\/a><\/noindex>, como em IntelliJ IDEA 15<\/a><\/noindex>.<\/p>\n
Aqui est\u00e3o os resultados das minhas medi\u00e7\u00f5es, assim como alguns resultados de Fatina, para mostrar que meu experimento est\u00e1 em conformidade com seus testes:<\/p>\n
\"Vis\u00e3o
\n
\nA primeira coisa que me impressionou foi o melhor tempo de resposta em programas mais antigos, como xterm e mlterm. Com uma lat\u00eancia de registro pior (2,4 ms), eles mostraram resultados melhores do que o terminal moderno mais r\u00e1pido (10,6 ms para st). Nenhum terminal moderno fica abaixo do limite de 10 milissegundos. Em particular, o Alacritty n\u00e3o atende aos requisitos de 'o mais r\u00e1pido de todos os emuladores de terminal existentes', embora seus resultados tenham melhorado desde a primeira verifica\u00e7\u00e3o em 2017. De fato, os autores do projeto est\u00e3o cientes da situa\u00e7\u00e3o<\/a><\/noindex> e est\u00e3o trabalhando na melhoria da exibi\u00e7\u00e3o. Tamb\u00e9m \u00e9 importante notar que o Vim, que usa GTK3, \u00e9 consideravelmente mais lento do que seu equivalente GTK2. Isso leva \u00e0 conclus\u00e3o de que o GTK3 cria uma lat\u00eancia adicional, refletindo-se em todos os outros terminais que o usam (Terminator, Xfce4 Terminal e GNOME Terminal).<\/p>\n
No entanto, as diferen\u00e7as podem ser impercept\u00edveis para o olho. Como explica Fatina: 'n\u00e3o \u00e9 necess\u00e1rio perceber a lat\u00eancia para que ela tenha efeito sobre voc\u00ea'. Fatina tamb\u00e9m alerta sobre a variabilidade: 'qualquer discrep\u00e2ncia na dura\u00e7\u00e3o da lat\u00eancia (tremula\u00e7\u00e3o) gera uma carga adicional devido \u00e0 sua imprevisibilidade'.<\/p>\n
\"Vis\u00e3o
\n
\nO gr\u00e1fico acima foi obtido em um Debian 9 puro (stretch) com o gerenciador de janelas i3<\/a><\/noindex>. Este ambiente oferece os melhores resultados nos testes de lat\u00eancia. Descobriu-se que o GNOME adiciona um ping extra de 20 ms para todas as medi\u00e7\u00f5es. Uma poss\u00edvel explica\u00e7\u00e3o para isso \u00e9 a presen\u00e7a de programas com processamento s\u00edncrono de eventos de entrada. Fatin d\u00e1 um exemplo disso Workrave<\/a><\/noindex>, que adiciona lat\u00eancia ao processar todos os eventos de entrada de forma s\u00edncrona. Por padr\u00e3o, o GNOME tamb\u00e9m vem com um gerenciador de janelas Mutter<\/a><\/noindex>, que cria um n\u00edvel adicional de buffer, o que afeta o ping e adiciona pelo menos 8 milissegundos de lat\u00eancia.<\/p>\n
\"Vis\u00e3o
\n<\/p>\n
Velocidade de Rolar<\/h4>\n
\nO pr\u00f3ximo teste \u00e9 uma verifica\u00e7\u00e3o tradicional de \"velocidade\" ou \"largura de banda\", que mede qu\u00e3o rapidamente o terminal pode rolar pela p\u00e1gina, exibindo uma grande quantidade de texto na tela. A mec\u00e2nica do teste varia; o teste original consistia simplesmente em gerar a mesma linha de texto usando o comando seq. Outros testes envolvem a verifica\u00e7\u00e3o de Thomas E. Dick (que acompanha o xterm), onde um arquivo terminfo.src \u00e9 descarregado repetidamente.<\/a><\/noindex>Em outra revis\u00e3o de desempenho de terminais, Den Liu<\/a><\/noindex> usa uma string de bytes aleat\u00f3rios em codifica\u00e7\u00e3o base32, que \u00e9 exibida no terminal usando cat. Liu considera esse teste \"um benchmark t\u00e3o in\u00fatil quanto se pode imaginar\" e sugere usar a resposta do terminal como o principal indicador. Dick tamb\u00e9m considera seu teste enganoso. No entanto, ambos os autores reconhecem que a largura de banda da janela do terminal pode ser um problema. Liu descobriu um travamento no Emacs Eshell ao exibir arquivos grandes, enquanto Dick otimizou o terminal para eliminar a lentid\u00e3o visual do xtrerm. Portanto, ainda h\u00e1 algum valor neste teste, mas como o processo de renderiza\u00e7\u00e3o varia significativamente de terminal para terminal, ele pode ser utilizado como um componente de teste para verificar outros par\u00e2metros.<\/p>\n
\"Vis\u00e3o
\n
\nAqui vemos que rxvt e st se destacam em rela\u00e7\u00e3o aos concorrentes, seguidos pelo muito mais novo Alacritty, desenvolvido com foco em desempenho. Em seguida, v\u00eam Xfce (fam\u00edlia VTE) e Konsole, que funcionam quase duas vezes mais r\u00e1pido. Por \u00faltimo, xterm apresenta-se com uma velocidade cinco vezes menor que a do rxvt. Durante o teste, o xterm tamb\u00e9m apresentou um tremido significativo, tornando dif\u00edcil visualizar o texto que passava, mesmo que fosse a mesma linha. O Konsole mostrou-se r\u00e1pido, mas \u00e0s vezes 'trapaceava': a tela travava de vez em quando, exibindo texto parcialmente ou n\u00e3o mostrando nada. Outros terminais apresentaram linhas com clareza, incluindo st, Alacritty e rxvt.<\/p>\n
Diki explica que as diferen\u00e7as de desempenho est\u00e3o relacionadas ao design dos buffers de rolagem em diferentes terminais. Em particular, ele culpa o rxvt e outros terminais por 'n\u00e3o seguirem as regras gerais':<\/p>\n
\u00abAo contr\u00e1rio do xterm, o rxvt n\u00e3o tentou exibir todas as atualiza\u00e7\u00f5es. Se ele fica atrasado, ele descarta algumas atualiza\u00e7\u00f5es para recuperar o tempo. Isso teve um impacto maior na velocidade aparente da rolagem do que na organiza\u00e7\u00e3o da mem\u00f3ria interna. Uma desvantagem foi que a anima\u00e7\u00e3o ASCII era um tanto imprecisa\u00bb.<\/p><\/blockquote>\n
\nPara corrigir essa aparente lentid\u00e3o do xterm, Diki sugere usar o recurso fastScroll<\/a><\/noindex>, que permite ao xterm descartar algumas atualiza\u00e7\u00f5es de tela para n\u00e3o ficar para tr\u00e1s no fluxo. Meus testes confirmam que o fastScroll melhora o desempenho e coloca o xterm em um n\u00edvel semelhante ao do rxvt. No entanto, \u00e9 uma solu\u00e7\u00e3o bastante rudimentar, como explica o pr\u00f3prio Diki: '\u00e0s vezes o xterm \u2014 assim como o konsole \u2014 parece parar enquanto espera um novo conjunto de atualiza\u00e7\u00f5es de tela depois que algumas delas foram descartadas'. Nesse sentido, parece que outros terminais encontraram o melhor compromisso entre velocidade e integridade da exibi\u00e7\u00e3o.<\/p>\n
Consumo de recursos<\/h4>\n
\nIndependentemente da viabilidade de considerar a velocidade de rolagem como um indicador de desempenho, este teste permite simular a carga nos terminais, o que, por sua vez, nos permite medir outros par\u00e2metros, como uso de mem\u00f3ria ou disco. As m\u00e9tricas foram obtidas ao executar o teste indicado seq<\/b> sob monitoramento do processo Python. Ele coletava dados dos contadores getrusage ()<\/a><\/noindex> para ru_maxrss<\/b>, a soma de ru_oublock<\/b> e ru_inblock<\/b> e um cron\u00f4metro de tempo.<\/p>\n
\"Vis\u00e3o
\n
\nNeste teste, o ST ocupa o primeiro lugar com o menor consumo m\u00e9dio de mem\u00f3ria, de 8 MB, o que n\u00e3o \u00e9 surpreendente, considerando que a principal ideia do projeto \u00e9 a simplicidade. O mlterm, xterm e rxvt consomem um pouco mais \u2014 cerca de 12 MB. Outro resultado not\u00e1vel \u00e9 o Alacritty, que requer 30 MB para funcionar. Em seguida, temos os terminais da fam\u00edlia VTE com consumos variando de 40 a 60 MB, o que \u00e9 bastante. Esse consumo pode ser explicado pelo fato de que esses terminais utilizam bibliotecas de n\u00edvel mais alto, como o GTK. O Konsole fica por \u00faltimo, com um consumo colossal de 65 MB durante os testes, embora isso possa ser justificado por seu conjunto bastante amplo de recursos.<\/p>\n
Comparado aos resultados anteriores obtidos h\u00e1 dez anos, todos os programas passaram a consumir significativamente mais mem\u00f3ria. Antes, o Xterm exigia 4 MB, e agora requer 15 MB apenas para iniciar. O mesmo aumento de consumo \u00e9 observado no rxvt, que agora requer 16 MB por padr\u00e3o. O terminal Xfce ocupa 34 MB, o que \u00e9 tr\u00eas vezes mais do que antes, enquanto o GNOME Terminal exige apenas 20 MB. Claro, todos os testes anteriores foram realizados em uma arquitetura de 32 bits. No LCA 2012, Rasti Russell contou<\/a><\/noindex>, existem muitas raz\u00f5es mais sutis que podem explicar o aumento do consumo de mem\u00f3ria. Com tudo isso, agora vivemos em tempos em que temos gigabytes inteiros de mem\u00f3ria, ent\u00e3o conseguiremos lidar com isso de alguma forma.<\/p>\n
No entanto, n\u00e3o consigo me livrar da sensa\u00e7\u00e3o de que alocar uma quantidade maior de mem\u00f3ria para um software t\u00e3o fundamental quanto um terminal \u00e9 um desperd\u00edcio de recursos. Esses programas devem ser os menores dos pequenos, capazes de funcionar em qualquer \"caixinha\", mesmo em uma caixa de sapatos, se algum dia chegarmos ao ponto de que precisar\u00e3o ser equipados com sistemas Linux (e voc\u00ea sabe que isso vai acontecer). Mas com esses n\u00fameros, o uso de mem\u00f3ria se tornar\u00e1 um problema no futuro em qualquer ambiente ao executar v\u00e1rios terminais, exceto em casos de alguns dos mais leves e limitados em recursos. Para compensar isso, o GNOME Terminal, Konsole, urxvt, Terminator e Xfce Terminal possuem um modo Daemon, que permite gerenciar v\u00e1rios terminais atrav\u00e9s de um \u00fanico processo, limitando seu consumo de mem\u00f3ria.<\/p>\n
\"Vis\u00e3o
\n
\nDurante meus testes, cheguei a outro resultado inesperado sobre a leitura e grava\u00e7\u00e3o de disco: esperava n\u00e3o ver nada aqui, mas descobri que alguns terminais gravam os dados mais volumosos no disco. Assim, a biblioteca VTE efetivamente mant\u00e9m um buffer de rolagem no disco (essa caracter\u00edstica foi notada j\u00e1 em 2010<\/a><\/noindex>, e isso continua at\u00e9 hoje). Mas, ao contr\u00e1rio das implementa\u00e7\u00f5es antigas, agora, pelo menos, esses dados est\u00e3o criptografados com AES256 GCM (a partir da vers\u00e3o 0.39.2<\/a><\/noindex>). Mas surge uma pergunta razo\u00e1vel: o que h\u00e1 de t\u00e3o especial na biblioteca VTE que exige essa abordagem n\u00e3o convencional \u00e0 implementa\u00e7\u00e3o...<\/p>\n
Conclus\u00e3o<\/h4>\n
\nNa primeira parte do artigo, descobrimos que os terminais baseados em VTE t\u00eam um bom conjunto de recursos, mas agora vemos que isso est\u00e1 relacionado a alguns custos para garantir seu desempenho. Atualmente, a mem\u00f3ria n\u00e3o \u00e9 um problema, pois todos os terminais VTE podem ser gerenciados atrav\u00e9s de um processo daemon que limita seu uso. No entanto, sistemas mais antigos, com limita\u00e7\u00f5es f\u00edsicas na quantidade de mem\u00f3ria RAM e buffer do kernel, podem ainda precisar de vers\u00f5es anteriores dos terminais, j\u00e1 que consomem significativamente menos recursos. Embora os terminais VTE tenham se sa\u00eddo bem em testes de largura de banda (rolagem), sua lat\u00eancia na exibi\u00e7\u00e3o de dados na tela est\u00e1 acima do limite estabelecido no guia do usu\u00e1rio do GNOME. Provavelmente, os desenvolvedores do VTE deveriam considerar isso. Considerando que, mesmo para usu\u00e1rios iniciantes do Linux, o encontro com o terminal \u00e9 inevit\u00e1vel, eles podem torn\u00e1-lo mais amig\u00e1vel ao usu\u00e1rio. Para geeks experientes, a troca do terminal padr\u00e3o pode significar at\u00e9 uma redu\u00e7\u00e3o na carga sobre a vis\u00e3o e a possibilidade de evitar les\u00f5es e doen\u00e7as profissionais no futuro devido a longas sess\u00f5es de trabalho. Infelizmente, apenas os antigos xterm e mlterm nos levam ao m\u00e1gico limite de lat\u00eancia de 10 milissegundos, o que \u00e9 inaceit\u00e1vel para muitos.<\/p>\n
As medi\u00e7\u00f5es de controle tamb\u00e9m mostraram que, devido ao desenvolvimento de ambientes gr\u00e1ficos no Linux, os desenvolvedores tiveram que fazer uma s\u00e9rie de concess\u00f5es. Alguns usu\u00e1rios devem considerar gerenciadores de janelas comuns, pois eles proporcionam uma redu\u00e7\u00e3o significativa no ping. Infelizmente, para o Wayland, n\u00e3o consegui medir a lat\u00eancia: o programa Typometer, que usei, foi criado para evitar exatamente o que o Wayland se prop\u00f5e a prevenir \u2014 a espionagem de outras janelas. Espero que a composi\u00e7\u00e3o no Wayland tenha um desempenho melhor do que o X.org, e tamb\u00e9m espero que, no futuro, algu\u00e9m encontre uma maneira de avaliar o n\u00edvel de lat\u00eancia nesse ambiente.
\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0430\u0440\u0430 \u0441\u043b\u043e\u0432 \u043e\u0442 \u043d\u0430\u0448\u0435\u0433\u043e translate-\u0431\u044e\u0440\u043e: \u043e\u0431\u044b\u0447\u043d\u043e \u0432\u0441\u0435 \u0441\u0442\u0440\u0435\u043c\u044f\u0442\u0441\u044f \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0438\u0442\u044c \u0441\u0430\u043c\u044b\u0435 \u0441\u0432\u0435\u0436\u0438\u0435 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u044b \u0438 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438, \u0438 \u043c\u044b \u043d\u0435 \u0438\u0441\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u0435. \u041d\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u0430\u043b\u044b \u2014 \u044d\u0442\u043e \u043d\u0435 \u0442\u043e, \u0447\u0442\u043e \u043e\u0431\u043d\u043e\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0440\u0430\u0437 \u0432 \u043d\u0435\u0434\u0435\u043b\u044e. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043c\u044b \u043f\u0435\u0440\u0435\u0432\u0435\u043b\u0438 \u0434\u043b\u044f \u0432\u0430\u0441 \u0441\u0442\u0430\u0442\u044c\u044e \u0410\u043d\u0442\u0443\u0430\u043d\u0430 \u0411\u043e\u043f\u0440\u0435, \u043e\u043f\u0443\u0431\u043b\u0438\u043a\u043e\u0432\u0430\u043d\u043d\u0443\u044e \u0432\u0435\u0441\u043d\u043e\u0439 2018 \u0433\u043e\u0434\u0430: \u043d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0441\u043e\u043b\u0438\u0434\u043d\u044b\u0439 \u043f\u043e \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u043c \u043c\u0435\u0440\u043a\u0430\u043c \u00ab\u0432\u043e\u0437\u0440\u0430\u0441\u0442\u00bb, \u043d\u0430 \u043d\u0430\u0448 \u0432\u0437\u0433\u043b\u044f\u0434, \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b \u0441\u043e\u0432\u0435\u0440\u0448\u0435\u043d\u043d\u043e \u043d\u0435 \u043f\u043e\u0442\u0435\u0440\u044f\u043b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27911,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37222","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Revis\u00e3o de emuladores de terminal | ProHoster","description":"Algumas palavras do nosso escrit\u00f3rio de tradu\u00e7\u00e3o: geralmente, todos tentam traduzir o material e as publica\u00e7\u00f5es mais recentes, e n\u00f3s n\u00e3o somos exce\u00e7\u00e3o. Mas terminais n\u00e3o s\u00e3o algo que se atualiza de semana em semana.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/obzor-emulyatorov-terminala","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0431\u0437\u043e\u0440 \u044d\u043c\u0443\u043b\u044f\u0442\u043e\u0440\u043e\u0432 \u0442\u0435\u0440\u043c\u0438\u043d\u0430\u043b\u0430 | ProHoster","og:description":"\u041f\u0430\u0440\u0430 \u0441\u043b\u043e\u0432 \u043e\u0442 \u043d\u0430\u0448\u0435\u0433\u043e translate-\u0431\u044e\u0440\u043e: \u043e\u0431\u044b\u0447\u043d\u043e \u0432\u0441\u0435 \u0441\u0442\u0440\u0435\u043c\u044f\u0442\u0441\u044f \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0438\u0442\u044c \u0441\u0430\u043c\u044b\u0435 \u0441\u0432\u0435\u0436\u0438\u0435 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u044b \u0438 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438, \u0438 \u043c\u044b \u043d\u0435 \u0438\u0441\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u0435. \u041d\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u0430\u043b\u044b \u2014 \u044d\u0442\u043e \u043d\u0435 \u0442\u043e, \u0447\u0442\u043e \u043e\u0431\u043d\u043e\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0440\u0430\u0437 \u0432 \u043d\u0435\u0434\u0435\u043b\u044e.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/obzor-emulyatorov-terminala","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:16:26+00:00","article:modified_time":"2019-10-31T19:16:26+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37222","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 16:48:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:31:24","updated":"2026-01-23 16:48:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/37222","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=37222"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/37222\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/27911"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=37222"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=37222"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=37222"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}