Algunhas palabras da nosa oficina de tradución: normalmente todo o mundo se esforza en traducir os últimos materiais e publicacións, e nós non somos unha excepción. Pero os terminais non son algo que se actualice unha vez á semana. Por iso, traducimos para vostede un artigo de Antoine Beaupré, publicado na primavera de 2018: a pesar da súa considerable "idade" para os estándares modernos, na nosa opinión, o material non perdeu a súa relevancia en absoluto. Ademais, este era orixinalmente unha serie de dous artigos, pero decidimos combinalos nunha única publicación grande.
Os terminais teñen un lugar especial na historia dos ordenadores, pero nas últimas décadas víronse obrigados a sobrevivir xunto á liña de comandos a medida que as interfaces gráficas se fan omnipresentes. substituíron os seus , que, á súa vez, eran unha modificación de sistemas baseados en tarxetas perforadas e interruptores de palanca. As distribucións modernas veñen cunha variedade de emuladores de terminais de todas as formas e cores. E aínda que moitos se contentan co terminal estándar proporcionado polo seu ambiente de traballo, algúns usan con orgullo un software francamente exótico para executar o seu shell ou editor de texto favorito. Pero, como veremos neste artigo, non todos os terminais foron creados na mesma imaxe: difiren moito en funcións, tamaño e rendemento.
Algúns terminais teñen buratos de seguridade francamente sorprendentes, ademais a maioría teñen un conxunto de funcións completamente diferente, desde soporte para unha interface con pestanas ata scripts. Aínda que nós , este artigo é unha actualización do material anterior que axudará aos lectores a determinar que terminal usar en 2018. A primeira metade do artigo compara características e a segunda metade avalía o rendemento.
Aquí están os terminais que revisei:
Estas poden non ser as versións máis recentes, xa que estaba limitado a compilacións estables no momento de escribir, que puiden lanzar en Debian 9 ou Fedora 27. A única excepción é Alacritty. É un descendente de terminais acelerados por GPU e está escrito nunha linguaxe inusual e nova para esta tarefa: Rust. Excluín os terminais web da miña revisión (incluídos os que están en ), porque as probas preliminares mostraron o seu rendemento extremadamente pobre.
Soporte Unicode
Comecei as miñas probas co soporte de Unicode. A primeira proba dos terminais foi mostrar a cadea Unicode de : "é, Δ, И, ק, م, ๗, あ, 叶, 葉 e 말." Esta sinxela proba mostra se o terminal pode funcionar correctamente en todo o mundo. O terminal xterm non mostra caracteres árabes na configuración predeterminada:
Por defecto, xterm usa o tipo de letra "fixo" clásico, que, segundo , ten "unha cobertura Unicode substancial desde 1997". Hai algo neste tipo de letra que fai que o carácter apareza como un marco en branco e só cando a fonte do texto se incrementa a máis de 20 puntos o carácter finalmente comeza a mostrarse correctamente. Non obstante, esta "corrección" rompe a visualización doutros caracteres Unicode:
Estas capturas de pantalla foron tomadas en Fedora 27, xa que deu mellores resultados que Debian 9, onde algunhas versións máis antigas de terminais (específicamente mlterm) non podían manexar as fontes correctamente. Afortunadamente, isto foi solucionado en versións posteriores.
Agora observe como se mostra a liña en xterm. Resulta que o símbolo Mem e o seguinte semítico consulte scripts de estilo RTL (), polo que tecnicamente deberían mostrarse de dereita a esquerda. Os navegadores web como Firefox 57 manexan correctamente a liña anterior. Unha versión máis sinxela do texto RTL é a palabra ""en hebreo (). di o seguinte:
"Moitos programas informáticos non poden mostrar texto bidireccional correctamente. Por exemplo, o nome hebreo "Sarah" consta dos caracteres sin (ש) (que aparece á dereita), despois resh (ר) e finalmente el (ה) (que debería aparecer á esquerda)."
Moitos terminais fallan nesta proba: os terminais Alacritty, Gnome e XFCE derivados de VTE, urxvt, st e xterm mostran "Sara" en orde inversa, coma se escribiramos o nome como "Aras".
Outro problema dos textos bidireccionais é que deben aliñarse dalgún xeito, especialmente cando se trata de mesturar textos RTL e LTR. Os scripts RTL deberían executarse desde o lado dereito da xanela do terminal, pero que debería pasar cos terminais que usan LTR inglés por defecto? A maioría deles non teñen ningún mecanismo especial e aliñan todo o texto á esquerda (incluído en Konsole). As excepcións son pterm e mlterm, que se adhiren aos estándares e aliñan as liñas á dereita.
Protección de inserción
A seguinte característica crítica que identifique é a protección anti-inserción. Aínda que se sabe que se fala como:
$ curl http://example.com/ | shson comandos push de execución de código, poucas persoas saben que os comandos ocultos poden colarse na consola ao copiar e pegar desde un navegador web, mesmo despois dunha inspección coidadosa. mostra brillantemente o inocuo que é o comando:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitconvértese nunha molestia cando se pega desde o sitio web 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.gitCómo funciona? O código malicioso inclúese no bloque , que se move fóra da vista do usuario mediante CSS.
está claramente deseñado para neutralizar tales ataques. Neste modo, os terminais encerran o texto pegado nun par de secuencias de escape especiais para indicarlle ao shell a orixe do texto. Isto indica ao shell que pode ignorar os caracteres especiais que pode conter o texto pegado. Todos os terminais de volta ao venerable xterm admiten esta función, pero para pegar no modo entre corchetes é necesario o soporte do shell ou da aplicación que se executa no terminal. Por exemplo, o uso de software (o mesmo Bash), necesita un ficheiro ~/.inputrc:
set enable-bracketed-paste onDesafortunadamente, o sitio de proba de Horn tamén mostra como evitar esta protección a través do propio formato de texto e terminar prematuramente aplicándolle o modo entre corchetes. Isto funciona porque algúns terminais non filtran correctamente as secuencias de escape antes de engadir as súas propias. Por exemplo, no meu nunca puiden completar con éxito as probas de Konsole nin sequera coa configuración correcta .inputrc arquivo. Isto significa que pode corromper facilmente a configuración do seu sistema debido a unha aplicación non compatible ou a un shell configurado incorrectamente. Isto é especialmente perigoso ao iniciar sesión en servidores remotos, onde o traballo de configuración coidadoso é menos común, especialmente se tes moitas máquinas remotas deste tipo.
Unha boa solución a este problema é o complemento de confirmación de pegado para o terminal urxvt, que simplemente pide permiso para inserir calquera texto que conteña novas liñas. Non atopei unha opción máis segura para o ataque de texto descrito por Horn.
Fichas e perfís
Unha característica popular neste momento é o soporte para unha interface con pestanas, que definiremos como unha ventá de terminal que contén varios outros terminais. Esta función difire para os distintos terminais, e aínda que os terminais xterm tradicionais non admiten pestanas en absoluto, as encarnacións de terminais máis modernas como Xfce Terminal, GNOME Terminal e Konsole teñen esta función. Urxvt tamén admite pestanas, pero só se usa un complemento. Pero en termos de soporte de pestanas, Terminator é o líder indiscutible: non só admite pestanas, senón que tamén pode organizar terminais en calquera orde (ver imaxe a continuación).
Outra característica de Terminator é a posibilidade de "agrupar" estas pestanas e enviar as mesmas pulsacións de teclas a varios terminais ao mesmo tempo, proporcionando unha ferramenta burda para realizar operacións masivas en varios servidores ao mesmo tempo. Unha característica similar tamén se implementa en Konsole. Para utilizar esta función noutros terminais, debes utilizar software de terceiros como , ou .
As pestanas funcionan especialmente ben cando se combinan con perfís: por exemplo, podes ter unha pestana para o correo electrónico, outra para o chat, etc. Isto é ben compatible con Konsole Terminal e GNOME. Ambos permiten que cada pestana inicie automaticamente o seu propio perfil. Terminator tamén admite perfís, pero non puiden atopar un xeito de iniciar automaticamente certos programas ao abrir unha pestana específica. Outros terminais non teñen o concepto de "perfil" en absoluto.
Volantes
O último que tratarei na primeira parte deste artigo é a aparición dos terminais. Por exemplo, GNOME, Xfce e urxvt admiten a transparencia, pero recentemente deixaron de admitir imaxes de fondo, o que obriga a algúns usuarios a cambiar ao terminal . Persoalmente, estou contento con el e é sinxelo Xrecursos, que establece o conxunto base de cores de fondo para urxvt. Non obstante, os temas de cores non estándar tamén poden crear problemas. Por exemplo, con aplicacións и , xa que xa usan as súas propias cores.
non admitía cores, e as novas adoitaban limitarse a unha paleta de 256 cores. Para os usuarios avanzados que diseñan os seus terminais, as indicacións de shell ou as barras de estado de xeito complexo poden ser unha limitación molesta. rastrexa os terminais que admiten "True Color". As miñas probas confirman que os terminais baseados en st, Alacritty e VTE admiten perfectamente True Color. A outros terminais non lles vai moi ben neste sentido e, de feito, nin sequera mostran 256 cores. A continuación podes ver a diferenza entre a compatibilidade con True Color nos terminais de GNOME, st e xterm, que fan un bo traballo coa súa paleta de cores de 256, e urxvt, que non só supera a proba, senón que mesmo mostra algúns caracteres parpadeantes no seu lugar.
Algúns terminais tamén analizan o texto en busca de patróns de URL para facer clic nas ligazóns. Isto aplícase a todos os terminais derivados de VTE, mentres que urxvt require un complemento especial que transformaría os URL cun clic ou usando un atallo de teclado. Outros terminais que probei mostrar URL doutros xeitos.
Finalmente, unha nova tendencia nos terminais é a opcionalidade do búfer de desprazamento. Por exemplo, st non ten búfer de desprazamento; suponse que o usuario utilizará un multiplexor de terminal como tmux e .
Alacritty tamén carece de búfers de retroceso, pero o seu apoio debido aos "amplos comentarios" sobre este tema dos usuarios. Ademais destes advenedizos, todos os terminales que probei que puiden atopar admiten o desprazamento inverso.
Subtotales
Na segunda parte do material (no orixinal eran dous artigos diferentes -aprox. carril) compararemos o rendemento, o uso da memoria e a latencia. Pero xa vemos que algúns dos terminais en cuestión presentan graves carencias. Por exemplo, os usuarios que traballan habitualmente con scripts RTL poden querer considerar mlterm e pterm, xa que son mellores para xestionar tarefas similares que outros. Konsole tamén funcionou ben. Os usuarios que non traballan con scripts RTL poden escoller outra cousa.
En canto á protección contra a inserción de código malicioso, urxvt destaca pola súa especial implantación de protección contra este tipo de ataques, que me parecen definitivamente convenientes. Para aqueles que buscan unhas campás e asubíos, Konsole paga a pena botarlle unha ollada. Finalmente, cómpre salientar que VTE é unha excelente base para terminais, que garante soporte de cores, recoñecemento de URL, etc. A primeira vista, o terminal predeterminado que vén co teu ambiente favorito pode cumprir todos os requisitos, pero deixemos esta pregunta aberta ata que entendamos o rendemento.
Continuemos a conversa
En xeral, o rendemento dos terminais en si mesmo pode parecer un problema descabellado, pero polo que se ve, algúns deles presentan unha latencia sorprendentemente alta para un software de tipo tan fundamental. Tamén a continuación analizaremos o que tradicionalmente se chama "velocidade" (de feito, esta é a velocidade de desprazamento) e o consumo de memoria do terminal (coa advertencia de que isto non é tan crítico hoxe como hai décadas).
Atraso
Despois dun estudo exhaustivo do rendemento do terminal, cheguei á conclusión de que o parámetro máis importante a este respecto é a latencia (ping). No seu artigo Pavel Fatin analizou a latencia de varios editores de texto e deu a entender que os terminais neste sentido poden ser máis lentos que os editores de texto máis rápidos. Foi esta pista a que finalmente me levou a realizar as miñas propias probas e escribir este artigo.
Pero que é a latencia e por que é tan importante? No seu artigo, Fatin definiuna como "o atraso entre a pulsación dunha tecla e a correspondente actualización da pantalla" e citou , que afirma: "O atraso na retroalimentación visual na pantalla dun ordenador ten un impacto importante no comportamento e satisfacción do mecanógrafo".
Fatin explica que este ping ten consecuencias máis profundas que a simple satisfacción: "a escritura faise máis lenta, ocorren máis erros e aumenta a tensión ocular e muscular". Noutras palabras, un gran atraso pode levar a erros tipográficos e tamén a baixar a calidade do código, xa que leva a unha carga cognitiva adicional no cerebro. Pero o que é peor é que o ping "aumenta a tensión ocular e muscular", o que parece implicar no futuro (Ao parecer, o autor significa problemas cos músculos dos ollos, as costas, os brazos e, por suposto, a visión - aprox. carril) debido ao estrés repetitivo.
Algúns destes efectos coñécense desde hai moito tempo e os resultados , publicado en 1976 na revista Ergonomics, dixo que un atraso de 100 milisegundos "prexudica significativamente a velocidade de escritura". Máis recentemente, presentouse a Guía de usuario de GNOME en 10 milisegundos, e se vai máis lonxe, entón mostra que 1 milisegundo é ideal.
Fatin realizou as súas probas en editores de texto; creou un instrumento portátil chamado , que usei para probar o ping nos emuladores de terminais. Teña en conta que a proba realizouse en modo simulación: en realidade, cómpre ter en conta tanto a latencia de entrada (teclado, controlador USB, etc.) como de saída (búfer da tarxeta de vídeo, monitor). Segundo Fatin, nas configuracións típicas é duns 20 ms. Se tes equipos de xogos, podes conseguir esta cifra en só 3 milisegundos. Como xa temos un hardware tan rápido, a aplicación non ten que engadir a súa propia latencia. O obxectivo de Fatin é levar a latencia da aplicación a 1 milisegundo ou incluso lograr marcar sen , como dentro .
Aquí están os resultados das miñas medicións, así como algúns dos resultados de Fatin, para demostrar que o meu experimento concorda coas súas probas:
O primeiro que me chamou a atención foi o mellor tempo de resposta dos programas máis antigos como xterm e mlterm. Coa peor latencia de rexistro (2,4 ms), funcionaron mellor que o terminal moderno máis rápido (10,6 ms para st). Ningún terminal moderno cae por debaixo do limiar dos 10 milisegundos. En particular, Alacritty non cumpre coa afirmación do "emulador de terminal máis rápido dispoñible", aínda que as súas puntuacións melloraron desde a súa primeira revisión en 2017. De feito, os autores do proxecto e traballan para mellorar a visualización. Tamén hai que ter en conta que Vim usando GTK3 é unha orde de magnitude máis lento que o seu homólogo GTK2. A partir diso podemos concluír que GTK3 crea latencia adicional, e isto reflíctese en todos os demais terminais que a usan (Terminator, Xfce4 Terminal e GNOME).
Non obstante, as diferenzas poden non ser perceptibles a simple vista. Como explica Fatin, "non tes que ser consciente do atraso para que teña un efecto sobre ti". Fatin tamén advirte sobre a desviación estándar: "calquera perturbación na latencia (jitter) crea estrés adicional debido á súa imprevisibilidade".
O gráfico anterior está tomado en Debian 9 puro (estirado) con . Este ambiente produce os mellores resultados nas probas de latencia. Como resultado, GNOME crea un ping adicional de 20 ms para todas as medicións. Unha posible explicación para isto é a presenza de programas con procesamento sincrónico de eventos de entrada. Fatin pon un exemplo para tal caso , que engade un atraso ao procesar todos os eventos de entrada de forma sincronizada. Por defecto, GNOME tamén inclúe un xestor de fiestras , que crea unha capa adicional de búfer, que afecta ao ping e engade polo menos 8 milisegundos de latencia.
Velocidade de desprazamento
A seguinte proba é unha proba tradicional de "velocidade" ou "ancho de banda", que mide a rapidez con que o terminal pode desprazarse por unha páxina mentres mostra grandes cantidades de texto na pantalla. A mecánica da proba varía; a proba orixinal consistía en xerar simplemente a mesma cadea de texto usando o comando seq. Outras probas inclúen a proba de Thomas E. Dickey (mantedor de xterm), que repetidamente . Noutra revisión do rendemento do terminal usa unha cadea de bytes aleatorios codificada en base32, que se envía ao terminal usando cat. Luu considera que esa proba é "un punto de referencia tan inútil como se pode imaxinar" e suxire usar a resposta do terminal como métrica principal. Dickey tamén cualifica que a súa proba é enganosa. Non obstante, ambos os autores recoñecen que o ancho de banda da xanela do terminal pode ser un problema. Luu descubriu que Emacs Eshell se conxelaba ao mostrar ficheiros grandes, e Dickey optimizou o terminal para desfacerse da lentitud visual de xtrerm. Polo tanto, aínda hai algo de mérito para esta proba, pero como o proceso de renderizado é moi diferente dun terminal a outro, tamén se pode usar como compoñente de proba para probar outros parámetros.
Aquí vemos o rxvt e o st tirar por diante da competencia, seguidos do moito máis novo Alacritty, que está deseñado con foco no rendemento. A continuación están Xfce (familia VTE) e Konsole, que son case o dobre de rápido. O último é xterm, que é cinco veces máis lento que rxvt. Durante a proba, xterm tamén ondulaba moito, facendo que o texto fose difícil de ver aínda que fose a mesma liña. Konsole era rápido, pero ás veces era complicado: a pantalla conxélase de cando en vez, mostrando texto parcial ou non amosándoo en absoluto. Outros terminais mostraron as cadeas claramente, incluíndo st, Alacritty e rxvt.
Dickey explica que as diferenzas de rendemento débense ao deseño de búfers de desprazamento en diferentes terminais. En particular, acusa a rxvt e outros terminais de "non seguir as regras xerais":
"A diferenza de xterm, rxvt non intentou mostrar todas as actualizacións. Se queda atrás, rexeitará algunhas actualizacións para poñerse ao día. Isto tivo un maior impacto na aparente velocidade de desprazamento que na organización da memoria interna. Un inconveniente foi que a animación ASCII era algo imprecisa".
Para corrixir esta percepción de lentitud de xterm, Dickey suxire usar o recurso , permitindo que xterm descarte algunhas actualizacións da pantalla para seguir o fluxo. As miñas probas confirman que fastScroll mellora o rendemento e trae xterm á par con rxvt. Non obstante, esta é unha muleta bastante tosca, como explica o propio Dickey: "ás veces xterm -como a konsole- parece pararse mentres espera un novo conxunto de actualizacións de pantalla despois de que algunhas foron eliminadas". Neste sentido, parece que outros terminais atoparon o mellor compromiso entre velocidade e integridade da pantalla.
Consumo de recursos
Independentemente de que teña sentido considerar a velocidade de desprazamento como unha métrica de rendemento, esta proba permítenos simular a carga dos terminais, o que á súa vez nos permite medir outros parámetros como a memoria ou o uso do disco. As métricas obtivéronse mediante a realización da proba especificada seq baixo a supervisión de procesos de Python. Recolleu datos do contador para ru_maxrss, importe ru_oblock и ru_inblock e un temporizador sinxelo.
Nesta proba, o ST ocupa o primeiro lugar co menor consumo medio de memoria de 8 MB, o que non é de estrañar tendo en conta que a idea principal do deseño é a sinxeleza. mlterm, xterm e rxvt consomen un pouco máis: uns 12 MB. Outro resultado notable é Alacritty, que require 30 MB para executarse. Despois están os terminais da familia VTE con cifras de 40 a 60 MB, que é bastante. Este consumo pódese explicar polo feito de que estes terminais utilizan bibliotecas de nivel superior, por exemplo, GTK. Konsole é o último con 65 MB de consumo de memoria durante as probas, aínda que isto pode xustificarse pola súa ampla gama de funcións.
En comparación cos resultados anteriores obtidos hai dez anos, todos os programas comezaron a consumir notablemente máis memoria. Xterm antes requiría 4 MB, pero agora precisa 15 MB só ao iniciar. Hai un aumento similar no consumo para rxvt, que agora require 16 MB fóra da caixa. O terminal Xfce ocupa 34 MB, o que é tres veces máis grande que antes, pero o terminal GNOME só require 20 MB. Por suposto, todas as probas anteriores realizáronse en arquitectura de 32 bits. En LCA 2012 Rusty Russell , que hai moitas razóns máis sutís que poderían explicar o aumento do consumo de memoria. Dito isto, agora vivimos nunha época na que temos gigabytes de memoria, polo que imos facelo dalgún xeito.
Porén, non podo evitar sentir que destinar máis memoria a algo tan fundamental como o terminal é un desperdicio de recursos. Estes programas deberían ser os máis pequenos dos máis pequenos, deberían poder executarse en calquera "caixa", incluso nunha caixa de zapatos, se algunha vez chegamos ao punto de que teñan que estar equipados con sistemas Linux (e xa sabes que así será. ). Pero con estes números, o uso da memoria converterase nun problema no futuro en calquera ambiente que execute varios terminais agás algúns dos máis lixeiros e limitados en capacidades. Para compensalo, GNOME Terminal, Konsole, urxvt, Terminator e Xfce Terminal contan cun modo Daemon que permite controlar varios terminais mediante un único proceso, limitando o seu consumo de memoria.
Durante as miñas probas, cheguei a outro resultado inesperado con respecto á lectura-escritura do disco: esperaba non ver nada, pero resultou que algúns terminais escriben os datos máis voluminosos no disco. Entón, a biblioteca VTE realmente mantén un búfer de desprazamento no disco (esta función , e isto segue a suceder). Pero a diferenza das implementacións máis antigas, agora polo menos estes datos están cifrados usando AES256 GCM (). Pero xorde unha pregunta razoable: que ten de especial a biblioteca VTE que require un enfoque tan non estándar para a implementación...
Conclusión
Na primeira parte do artigo, descubrimos que os terminais baseados en VTE teñen un bo conxunto de funcións, pero agora vemos que isto leva consigo algúns custos de rendemento. Agora a memoria non é un problema porque todos os terminais VTE poden controlarse mediante un proceso Daemon, o que limita o seu apetito. Non obstante, os sistemas máis antigos que teñen limitacións físicas na cantidade de memoria RAM e búfers do núcleo aínda poden necesitar versións anteriores de terminais, xa que consumen moito menos recursos. Aínda que os terminais VTE funcionaron ben nas probas de rendemento (desprazamento), a súa latencia de visualización está por encima do limiar establecido na Guía de usuario de GNOME. Os desenvolvedores de VTE probablemente deberían telo en conta. Se temos en conta que incluso para usuarios novatos de Linux atoparse cun terminal é inevitable, poden facelo máis amigable. Para os frikis experimentados, cambiar desde o terminal predeterminado pode incluso significar menos fatiga ocular e a capacidade de evitar futuras lesións e enfermidades relacionadas co traballo debido a longas sesións de traballo. Desafortunadamente, só os antigos xterm e mlterm achégannos ao limiar de ping máxico de 10 milisegundos, o que é inaceptable para moitos.
As medicións de referencia tamén mostraron que debido ao desenvolvemento de ambientes gráficos Linux, os desenvolvedores tiveron que facer unha serie de compromisos. Algúns usuarios poden querer consultar os xestores de fiestras habituais xa que ofrecen unha redución significativa de ping. Desafortunadamente, non foi posible medir a latencia para Wayland: o programa Typometer que usei foi creado para o que Wayland está deseñado para evitar: espiar outras fiestras. Espero que a composición de Wayland funcione mellor que X.org, e tamén espero que no futuro alguén atope unha forma de medir a latencia neste ambiente.
Fonte: www.habr.com