{"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\/es\/blog\/administrirovanie\/obzor-emulyatorov-terminala","title":{"rendered":"Revisi\u00f3n de emuladores de terminal","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Unas palabras de nuestra agencia de traducci\u00f3n: por lo general, todos buscan traducir los materiales y publicaciones m\u00e1s recientes, y nosotros no somos la excepci\u00f3n. Pero los terminales no son algo que se actualice cada semana. Por eso, hemos traducido para ustedes el art\u00edculo de Antoine Bopr\u00e9, publicado en la primavera de 2018: a pesar de su \"edad\" considerable de acuerdo con los est\u00e1ndares actuales, en nuestra opini\u00f3n, el material no ha perdido su relevancia. Adem\u00e1s, en el original se trata de una serie de dos art\u00edculos, pero decidimos combinarlos en una gran publicaci\u00f3n.<\/i><\/p>\n

\"Revisi\u00f3n
\n
\nLos terminales ocupan un lugar especial en la historia de la computaci\u00f3n, pero en las \u00faltimas d\u00e9cadas han tenido que \"sobrevivir\" junto a la l\u00ednea de comandos en medio de la proliferaci\u00f3n de interfaces gr\u00e1ficas. Emuladores de terminales<\/a><\/noindex> han reemplazado a sus hermanos de hardware<\/a><\/noindex>, que a su vez eran una modificaci\u00f3n de sistemas basados en tarjetas perforadas y conmutadores. Las distribuciones modernas vienen con una gran variedad de emuladores de terminal de diferentes formas y colores. Y mientras que muchos se conforman con el terminal est\u00e1ndar proporcionado por su entorno de trabajo, algunos utilizan con orgullo software claramente ex\u00f3tico para operar su shell o editor de texto favorito. Pero, como veremos en este art\u00edculo, no todos los terminales fueron creados de la misma manera: var\u00edan significativamente en funcionalidad, tama\u00f1o y rendimiento.
\n<\/a><\/noindex><\/p>\n

Algunos terminales tienen vulnerabilidades de seguridad sorprendentemente graves, adem\u00e1s, la mayor\u00eda posee un conjunto de funciones completamente diferente, que va desde soporte para interfaces con pesta\u00f1as hasta scripts. Aunque ya hemos analizado emuladores de terminal en el pasado<\/a><\/noindex>, este art\u00edculo es una actualizaci\u00f3n del material anterior que ayudar\u00e1 a los lectores a decidir qu\u00e9 terminal usar en 2018. En la primera mitad del art\u00edculo se comparan funciones, y en la segunda se eval\u00faa el rendimiento.<\/p>\n

Los terminales que he considerado son:<\/p>\n

\"Revisi\u00f3n
\n
\nQuiz\u00e1s estas no sean las versiones m\u00e1s recientes, ya que me limit\u00e9 a las compilaciones estables en el momento de redactar el material, que pude implementar en Debian 9 o Fedora 27. La \u00fanica excepci\u00f3n es Alacritty. Este es un descendiente de terminales con aceleraci\u00f3n GPU y est\u00e1 escrito en un lenguaje inusual y nuevo para esta tarea: Rust. Exclu\u00ed de mi revisi\u00f3n los terminales web (incluyendo, y en Electron<\/a><\/noindex>), porque las pruebas preliminares mostraron su extremadamente bajo rendimiento.<\/p>\n

Soporte de unicode<\/h4>\n

\nComenc\u00e9 mis pruebas con el soporte de unicode. La primera prueba de los terminales fue mostrar una l\u00ednea sobre unicode de un art\u00edculo en Wikipedia<\/a><\/noindex>: \u00ab\u00e9, \u0394, \u0419, \u05e7, \u0645, \u0e57, \u3042, \u53f6, \u8449 y \ub9d0\u00bb. Esta prueba simple muestra si el terminal puede funcionar correctamente en todo el mundo. La terminal xterm no muestra el car\u00e1cter \u00e1rabe Mem<\/a><\/noindex> en la configuraci\u00f3n por defecto:<\/p>\n

\"Revisi\u00f3n
\n
\nPor defecto, xterm utiliza una cl\u00e1sica fuente \u00abmonoespaciada\u00bb, que, seg\u00fan la misma Wiki<\/a><\/noindex>, tiene \u00abuna cobertura significativa de unicode desde 1997\u00bb. En esta fuente, ocurre algo que provoca que el car\u00e1cter se muestre como un marco vac\u00edo y solo al aumentar el tama\u00f1o de la fuente a 20+ puntos, el car\u00e1cter finalmente comienza a mostrarse correctamente. Sin embargo, este \u00abarreglo\u00bb rompe la visualizaci\u00f3n de otros caracteres unicode:<\/p>\n

\"Revisi\u00f3n
\n
\nEstas capturas de pantalla se realizaron en Fedora 27, ya que esta brind\u00f3 los mejores resultados en comparaci\u00f3n con Debian 9, donde algunas versiones antiguas de terminales (espec\u00edficamente - mlterm) no pod\u00edan funcionar adecuadamente con las fuentes. Afortunadamente, esto se corrigi\u00f3 en versiones posteriores.<\/p>\n

Ahora, observe la visualizaci\u00f3n de la l\u00ednea en xterm. Resulta que el car\u00e1cter Mem y el siguiente Semitic Qoph<\/a><\/noindex> pertenecen a guiones de escritura RTL (right-to-left<\/a><\/noindex>), por lo que t\u00e9cnicamente deber\u00edan mostrarse de derecha a izquierda. Los navegadores web, como Firefox 57, manejan correctamente la l\u00ednea anterior. Una variante m\u00e1s simple de texto RTL es la palabra \u00abSara<\/a><\/noindex>\u00bb en hebreo (\u05e9\u05e8\u05d4<\/a><\/noindex>). La p\u00e1gina de la Wiki sobre textos bidireccionales<\/a><\/noindex> dice lo siguiente:<\/p>\n

\u00abMuchos programas inform\u00e1ticos no pueden representar correctamente el texto bidireccional. Por ejemplo, el nombre hebreo \u00abSara\u00bb est\u00e1 compuesto por los caracteres sin (\u05e9) (que aparece a la derecha), luego resh (\u05e8) y, finalmente, he (\u05d4) (que debe aparecer a la izquierda)\u00bb.<\/p><\/blockquote>\n

\nMuchos terminales no pasan esta prueba: Alacritty, los terminales derivados de VTE de Gnome y XFCE, urxvt, st y xterm muestran \"Sara\" al rev\u00e9s, como si escribi\u00e9ramos este nombre como \"Aras\".<\/p>\n

\"Revisi\u00f3n
\n
\nOtro problema de los textos bidireccionales es que deben alinearse de alguna manera, especialmente si se trata de la mezcla de textos RTL y LTR. Los scripts RTL deben comenzar desde el lado derecho de la ventana del terminal, pero \u00bfqu\u00e9 debe ocurrir con los terminales que, por defecto, funcionan con ingl\u00e9s LTR? La mayor\u00eda de ellos no tienen mecanismos especiales y alinean todo el texto a la izquierda (incluido Konsole). Las excepciones son pterm y mlterm, que cumplen con los est\u00e1ndares y alinean tales l\u00edneas a la derecha.<\/p>\n

\"Revisi\u00f3n
\n<\/p>\n

Protecci\u00f3n contra pegado<\/h4>\n

\nLa siguiente caracter\u00edstica cr\u00edtica que he identificado para m\u00ed es la protecci\u00f3n contra pegado. Aunque es ampliamente conocido que hechizos como:<\/p>\n

$ curl http:\/\/example.com\/ | sh<\/code><\/pre>\n
\nson comandos push para ejecutar c\u00f3digo, pocos saben que comandos ocultos pueden infiltrarse en la consola al copiar y pegar desde el navegador web, incluso despu\u00e9s de una inspecci\u00f3n minuciosa. El sitio de verificaci\u00f3n de Djanna Horn<\/a><\/noindex> muestra brillantemente c\u00f3mo un comando que parece inofensivo:<\/p>\n
git clone git:\/\/git.kernel.org\/pub\/scm\/utils\/kup\/kup.git<\/code><\/pre>\n
\nse convierte al pegarlo desde el sitio de Horn en el terminal en este desagradable resultado:<\/p>\n
git clone \/dev\/null;\n    clear;\n\techo -n \"Hola \";\n\twhoami|tr -d 'n';\n\techo -e '!n\u00a1Esa fue una mala idea! No copies c\u00f3digo de sitios web en los que no conf\u00edas! \n\tAqu\u00ed est\u00e1 la primera l\u00ednea de tu \/etc\/passwd: ';\n\thead -n1 \/etc\/passwd\n\tgit clone git:\/\/git.kernel.org\/pub\/scm\/utils\/kup\/kup.git<\/code><\/pre>\n
\n\u00bfC\u00f3mo funciona esto? El c\u00f3digo malicioso se ha extra\u00eddo en un bloque <\/b>, que se mueve fuera de la vista del usuario mediante CSS.<\/p>\n
Modo de pegado bracketed<\/a><\/noindex> est\u00e1 dise\u00f1ado precisamente para neutralizar tales ataques. En este modo, los terminales envuelven el texto que se est\u00e1 pegando en un par de secuencias de escape especiales para informar al shell sobre el origen de este texto. As\u00ed, el shell recibe la se\u00f1al de que puede ignorar los caracteres especiales que puede contener el texto pegado. Todos los terminales, incluso el venerable xterm, admiten esta funci\u00f3n, pero la inserci\u00f3n en modo bracketed necesita apoyo del shell o de la aplicaci\u00f3n que se ejecuta en el terminal. Por ejemplo, el software que utiliza GNU Readline<\/a><\/noindex> (el mismo Bash), necesita un archivo ~ \/.inputrc<\/b>:<\/p>\n
set enable-bracketed-paste on<\/code><\/pre>\n
\nDesafortunadamente, el sitio de prueba de Horn tambi\u00e9n muestra c\u00f3mo eludir esta protecci\u00f3n a trav\u00e9s del formato de texto y finalizar prematuramente la aplicaci\u00f3n del modo enmarcado. Esto funciona porque algunas terminales filtran incorrectamente las secuencias de escape antes de agregar las propias. Por ejemplo, en mis pruebas, no logr\u00e9 completar exitosamente las pruebas de Konsole, incluso considerando una configuraci\u00f3n correcta. .inputrc<\/b> del archivo. Esto significa que puedes da\u00f1ar f\u00e1cilmente la configuraci\u00f3n del sistema debido a una aplicaci\u00f3n no soportada o una shell mal configurada. Esto es especialmente peligroso al acceder a servidores remotos, donde el trabajo cuidadoso de configuraci\u00f3n es menos com\u00fan, especialmente si tienes muchas de estas m\u00e1quinas remotas.<\/p>\n
Una buena soluci\u00f3n a este problema es un plugin de confirmaci\u00f3n de inserci\u00f3n para terminales urxvt<\/b>, que simplemente solicita permiso para insertar cualquier texto que contenga nuevas l\u00edneas. No encontr\u00e9 una opci\u00f3n m\u00e1s segura frente al ataque textual descrito por Horn.<\/p>\n
Pesta\u00f1as y perfiles<\/h4>\n
\nUna funci\u00f3n popular en la actualidad es el soporte para interfaces de pesta\u00f1as, que definiremos como una ventana de terminal que contiene m\u00faltiples terminales. Para diferentes terminales, esta funci\u00f3n var\u00eda, y aunque los terminales tradicionales como xterm no soportan pesta\u00f1as, las encarnaciones m\u00e1s modernas del terminal, como Xfce Terminal, GNOME Terminal y Konsole, s\u00ed la tienen. Urxvt tambi\u00e9n soporta pesta\u00f1as, pero solo si se utiliza un plugin. Sin embargo, en t\u00e9rminos de soporte de pesta\u00f1as como tal, el l\u00edder indiscutible es Terminator: no solo soporta pesta\u00f1as, sino que tambi\u00e9n puede organizar terminales en un orden arbitrario (ver imagen a continuaci\u00f3n).<\/p>\n
\"Revisi\u00f3n
\n
\nOtra caracter\u00edstica de Terminator es la posibilidad de \"agrupar\" estas pesta\u00f1as y enviar las mismas pulsaciones de teclas a m\u00faltiples terminales simult\u00e1neamente, lo que proporciona una herramienta b\u00e1sica para realizar operaciones masivas en varios servidores al mismo tiempo. Una funci\u00f3n similar tambi\u00e9n est\u00e1 implementada en Konsole. Para usar esta funci\u00f3n en otros terminales, es necesario utilizar software de terceros, como Cluster SSH<\/a><\/noindex>, xlax<\/a><\/noindex> o tmux<\/a><\/noindex>.<\/p>\n
Las pesta\u00f1as funcionan especialmente bien en conjunto con los perfiles: por ejemplo, puedes tener una pesta\u00f1a para el correo electr\u00f3nico, otra para el chat, y as\u00ed sucesivamente. Esto est\u00e1 bien soportado por el terminal Konsole y el GNOME Terminal. Ambos permiten que cada pesta\u00f1a ejecute autom\u00e1ticamente su propio perfil. Terminator tambi\u00e9n soporta perfiles, pero no pude encontrar una manera de iniciar autom\u00e1ticamente programas espec\u00edficos al abrir una pesta\u00f1a determinada. Otros terminales no tienen el concepto de \"perfil\" en absoluto.<\/p>\n
Volantes<\/h4>\n
\nLo \u00faltimo que considerar\u00e9 en la primera parte de este art\u00edculo es el aspecto de los terminales. Por ejemplo, GNOME, Xfce y urxvt soportan transparencia, pero recientemente eliminaron el soporte para im\u00e1genes de fondo, lo que llev\u00f3 a algunos usuarios a cambiar a otro terminal. Tilix<\/a><\/noindex>. A m\u00ed personalmente me parece suficiente y simple. Xresources<\/b>, que establece un conjunto b\u00e1sico de colores de fondo para urxvt. Sin embargo, los temas de color personalizados pueden crear problemas. Por ejemplo, Solarized<\/a><\/noindex> no funciona<\/a><\/noindex> con aplicaciones htop<\/a><\/noindex> y IPTraf<\/a><\/noindex>, ya que ya utilizan sus propios colores.<\/p>\n
El terminal original VT100<\/a><\/noindex> no soportaba colores, y los nuevos a menudo estaban limitados a una paleta de 256 colores. Para los usuarios avanzados que estilizan sus terminales, las solicitudes de shell o las barras de estado de maneras complejas pueden ser una limitaci\u00f3n molesta. Gist<\/a><\/noindex> rastrea qu\u00e9 terminales tienen soporte para \"True Color\". Mis pruebas confirman que st, Alacritty y los terminales basados en VTE soportan perfectamente True Color. Otros terminales se sienten bastante mal en este aspecto y de hecho no muestran ni siquiera 256 colores. A continuaci\u00f3n puedes ver la diferencia entre el soporte de True Color en los terminales GNOME, st y xterm, que manejan bien esta tarea 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.<\/p>\n
\"Revisi\u00f3n
\n
\nAlgunos terminales tambi\u00e9n analizan el texto en busca de patrones de URL para hacer los enlaces clicables. Esto se aplica a todos los terminales derivados de VTE, mientras que urxvt requiere un m\u00f3dulo complementario espec\u00edfico que transforme las direcciones URL al hacer clic o mediante un atajo de teclado. Otros terminales que he probado muestran las URL de maneras diferentes.<\/p>\n
Finalmente, la nueva tendencia en los terminales es la opcionalidad del b\u00fafer de desplazamiento. Por ejemplo, en st no hay b\u00fafer de desplazamiento; se supone que el usuario utilizar\u00e1 un multiplexor de terminal, como tmux y GNU Screen<\/a><\/noindex>.<\/p>\n
En Alacritty tambi\u00e9n faltan los b\u00faferes de desplazamiento inverso, pero pronto se a\u00f1adir\u00e1<\/a><\/noindex> su soporte debido a \"amplios comentarios\" al respecto por parte de los usuarios. Aparte de estas excepciones, cada terminal que he comprobado y que pude encontrar soporta el desplazamiento inverso.<\/p>\n
Resultados intermedios<\/h4>\n
\nEn la segunda parte del material (en el original eran dos art\u00edculos diferentes, \u2014 nota del traductor.<\/i>) compararemos el rendimiento, el uso de memoria y la latencia. Pero ya vemos que algunos de los terminales analizados tienen serias desventajas. Por ejemplo, los usuarios que trabajan regularmente con guiones en RTL pueden prestar atenci\u00f3n a mlterm y pterm, ya que se desenvuelven mejor que otros en estas tareas. Konsole tambi\u00e9n se ha desempe\u00f1ado bien. Los usuarios que no trabajan con guiones en RTL pueden elegir otra opci\u00f3n.<\/p>\n
Desde el punto de vista de la protecci\u00f3n contra la inyecci\u00f3n de c\u00f3digo malicioso, urxvt se destaca por su implementaci\u00f3n \u00fanica de protecci\u00f3n contra este tipo de ataques, que me parece ciertamente conveniente. Aquellos que buscan algunas caracter\u00edsticas avanzadas deber\u00edan considerar Konsole. Por \u00faltimo, vale la pena mencionar que VTE es una excelente base para terminales, que garantiza soporte para colores, reconocimiento de URL, y m\u00e1s. A primera vista, el terminal predeterminado que viene con tu entorno favorito puede cumplir con todos los requisitos, pero dejaremos esa cuesti\u00f3n abierta hasta que aclaremos el rendimiento.<\/p>\n
<\/p>\n
Continuamos la conversaci\u00f3n<\/h4>\n
<\/i>
\nEn general, la performance de los terminales puede parecer un problema exagerado, sin embargo, como se ha demostrado, algunos de ellos muestran retrasos sorprendentemente altos para un software de tan fundamental naturaleza. Tambi\u00e9n m\u00e1s adelante examinaremos lo que tradicionalmente se llama \"velocidad\" (en realidad, se refiere a la velocidad de desplazamiento) y el consumo de memoria del terminal (teniendo en cuenta que hoy en d\u00eda esto no es tan cr\u00edtico como hace d\u00e9cadas).<\/p>\n
Retraso<\/h4>\n
\nDespu\u00e9s de una cuidadosa investigaci\u00f3n sobre el rendimiento de los terminales, he llegado a la conclusi\u00f3n de que el par\u00e1metro m\u00e1s importante en este aspecto es el tama\u00f1o de la latencia (ping). En mi art\u00edculo \u00abEscribimos con placer\u00bb<\/a><\/noindex> Pavel Fatin examin\u00f3 la latencia de diversos editores de texto y sugiri\u00f3 que en este aspecto, las terminales pueden funcionar m\u00e1s lentas que los editores de texto m\u00e1s r\u00e1pidos. Esta sugerencia fue lo que, en \u00faltima instancia, me llev\u00f3 a realizar mis propias pruebas y a redactar este art\u00edculo.<\/p>\n
Pero, \u00bfqu\u00e9 es la latencia y por qu\u00e9 es tan importante? En su art\u00edculo, Fatin la defini\u00f3 como \u00abla latencia entre presionar una tecla y la correspondiente actualizaci\u00f3n de la pantalla\u00bb y cit\u00f3 \u00abLas gu\u00edas sobre la interacci\u00f3n humano-computadora\u00bb<\/a><\/noindex>, que dice: \u00abLa latencia en la retroalimentaci\u00f3n visual en la pantalla del ordenador tiene un gran impacto en el comportamiento del mecan\u00f3grafo y su satisfacci\u00f3n\u00bb.<\/p>\n
Fatin explica que tal ping tiene consecuencias m\u00e1s profundas que simplemente la satisfacci\u00f3n: \u00abescribir se vuelve m\u00e1s lento, se cometen m\u00e1s errores, aumenta la tensi\u00f3n en los ojos y los m\u00fasculos\u00bb. En otras palabras, una mayor latencia puede llevar a errores tipogr\u00e1ficos y a una disminuci\u00f3n en la calidad del c\u00f3digo, ya que genera una carga cognitiva adicional en el cerebro. Pero lo que es a\u00fan peor, el ping \u00abaumenta la tensi\u00f3n en los ojos y los m\u00fasculos\u00bb, lo que, aparentemente, implica el desarrollo de lesiones laborales<\/a><\/noindex> en el futuro (aparentemente, el autor se refiere a problemas con los m\u00fasculos oculares, la espalda, las manos y, por supuesto, la visi\u00f3n, \u2014 nota del traductor.<\/i>) debido a la tensi\u00f3n repetitiva.<\/p>\n
Algunos de estos efectos se conocen desde hace tiempo, y los resultados investigaci\u00f3n<\/a><\/noindex>, publicados en 1976 en la revista Ergonomics, indican que una latencia de 100 milisegundos \u00abempeora significativamente la velocidad de escritura\u00bb. Muy recientemente, se ha a\u00f1adido en la gu\u00eda de usuario de GNOME un tiempo de respuesta aceptable<\/a><\/noindex> de 10 milisegundos, y si se va m\u00e1s all\u00e1, Microsoft Research<\/a><\/noindex> demuestra que el ideal es 1 milisegundo.<\/p>\n
Fatin llev\u00f3 a cabo sus pruebas en editores de texto; cre\u00f3 una herramienta port\u00e1til llamada Typometer<\/a><\/noindex>, que utilic\u00e9 para verificar el ping en emuladores de terminal. Tenga en cuenta que la prueba se realiz\u00f3 en modo de simulaci\u00f3n: en realidad, debemos considerar el retraso de entrada (teclado, controlador USB, etc.) y de salida (buffer de la tarjeta gr\u00e1fica, monitor). Seg\u00fan Fat\u00edn, en configuraciones t\u00edpicas es de alrededor de 20 ms. Con hardware para gamers, se puede alcanzar un valor de solo 3 milisegundos. Dado que ya tenemos ese hardware r\u00e1pido, la aplicaci\u00f3n no debe introducir su propio retraso. El objetivo de Fat\u00edn es reducir el retraso de la aplicaci\u00f3n a 1 milisegundo, o incluso lograr una entrada sin retraso medible<\/a><\/noindex>, como en IntelliJ IDEA 15<\/a><\/noindex>.<\/p>\n
Aqu\u00ed est\u00e1n los resultados de mis mediciones, as\u00ed como algunos resultados de Fat\u00edn para mostrar que mi experimento coincide con sus pruebas:<\/p>\n
\"Revisi\u00f3n
\n
\nLo primero que me sorprendi\u00f3 fue el mejor tiempo de respuesta en programas antiguos como xterm y mlterm. Con el peor retraso de registro (2,4 ms), mostraron un resultado mejor que el terminal moderno m\u00e1s r\u00e1pido (10,6 ms para st). Ning\u00fan terminal moderno baja del umbral de 10 milisegundos. En particular, Alacritty no cumple con los requisitos para ser \"el m\u00e1s r\u00e1pido de los emuladores de terminal existentes\", aunque sus resultados mejoraron desde la primera verificaci\u00f3n en 2017. De hecho, los autores del proyecto est\u00e1n al tanto de la situaci\u00f3n<\/a><\/noindex> y est\u00e1n trabajando en mejorar la visualizaci\u00f3n. Tambi\u00e9n es importante se\u00f1alar que Vim, que utiliza GTK3, es considerablemente m\u00e1s lento que su contraparte de GTK2. De esto se puede concluir que GTK3 introduce un retraso adicional, y esto se refleja en todos los dem\u00e1s terminales que lo utilizan (Terminator, Xfce4 Terminal y GNOME Terminal).<\/p>\n
Sin embargo, para el ojo, las diferencias pueden ser imperceptibles. Como explica Fat\u00edn: \"no es necesario ser consciente del retraso para que tenga un efecto sobre usted\". Fat\u00edn tambi\u00e9n advierte sobre la desviaci\u00f3n est\u00e1ndar: \"cualquier variaci\u00f3n en la duraci\u00f3n del retraso (temblor) crea una carga adicional debido a su impredecibilidad\".<\/p>\n
\"Revisi\u00f3n
\n
\nEl gr\u00e1fico anterior se obtuvo en Debian 9 puro (stretch) con i3 window manager<\/a><\/noindex>. Este entorno proporciona los mejores resultados en pruebas de latencia. Como result\u00f3, GNOME genera un ping adicional de 20 ms para todas las mediciones. Una posible explicaci\u00f3n para esto es la presencia de programas con procesamiento s\u00edncrono de eventos de entrada. Fatin menciona como ejemplo para tal caso Workrave<\/a><\/noindex>, que a\u00f1ade latencia al procesar todos los eventos de entrada de manera s\u00edncrona. Por defecto, GNOME tambi\u00e9n cuenta con un gestor de ventanas Mutter<\/a><\/noindex>, que crea un nivel adicional de buffering, lo que influye en el ping y a\u00f1ade un m\u00ednimo de 8 milisegundos de latencia.<\/p>\n
\"Revisi\u00f3n
\n<\/p>\n
Velocidad de desplazamiento<\/h4>\n
\nLa siguiente prueba es una verificaci\u00f3n tradicional de \u00abvelocidad\u00bb o \u00abancho de banda\u00bb, que mide qu\u00e9 tan r\u00e1pido puede el terminal desplazarse por una p\u00e1gina mostrando una gran cantidad de texto en la pantalla. La mec\u00e1nica de la prueba var\u00eda; la prueba original consist\u00eda en generar simplemente la misma l\u00ednea de texto utilizando el comando seq. Otras pruebas incluyen la verificaci\u00f3n de Thomas E. Dick (acompa\u00f1ando a xterm), en la que se descarga repetidamente el archivo terminfo.src<\/a><\/noindex>. En otra revisi\u00f3n del rendimiento de los terminales Den Luu<\/a><\/noindex> utiliza una cadena de bytes aleatorios en codificaci\u00f3n base32, que se muestra en el terminal utilizando cat. Luu considera que esta prueba es \u00abun banco de pruebas tan in\u00fatil como se puede imaginar\u00bb y sugiere utilizar en su lugar la respuesta del terminal como principal indicador. Dick tambi\u00e9n califica su prueba como enga\u00f1osa. Sin embargo, ambos autores reconocen que el ancho de banda de la ventana del terminal puede ser un problema. Luu encontr\u00f3 un bloqueo de Emacs Eshell al mostrar archivos grandes, y Dick optimiz\u00f3 el terminal para eliminar la lentitud visual de xterm. Por lo tanto, todav\u00eda hay algo de raz\u00f3n en esta prueba, pero dado que el proceso de renderizaci\u00f3n var\u00eda mucho de un terminal a otro, tambi\u00e9n puede usarse como un componente de prueba para verificar otros par\u00e1metros.<\/p>\n
\"Revisi\u00f3n
\n
\nAqu\u00ed vemos que rxvt y st se destacan frente a la competencia, seguido de Alacritty, que es mucho m\u00e1s nuevo y se desarrolla con un enfoque en el rendimiento. Luego vienen Xfce (familia VTE) y Konsole, que funcionan casi el doble de r\u00e1pido. Por \u00faltimo, xterm tiene un rendimiento cinco veces m\u00e1s lento que rxvt. Durante la prueba, xterm tambi\u00e9n present\u00f3 mucho parpadeo, siendo dif\u00edcil ver el texto que pasaba, incluso si era la misma l\u00ednea. Konsole fue r\u00e1pido, pero a veces \"enga\u00f1aba\": la pantalla se congelaba intermitentemente, mostrando texto parcialmente o sin mostrarlo en absoluto. Otros terminales mostraron las l\u00edneas claramente, incluyendo st, Alacritty y rxvt.<\/p>\n
Diki explica que las diferencias en rendimiento est\u00e1n relacionadas con el dise\u00f1o de los b\u00faferes de desplazamiento en diferentes terminales. En particular, acusa a rxvt y otros terminales de \"no seguir las reglas comunes\":<\/p>\n
\"A diferencia de xterm, rxvt no intentaba mostrar todas las actualizaciones. Si se retrasa, omitir\u00e1 algunas actualizaciones para ponerse al d\u00eda. Esto tuvo un mayor impacto en la percepci\u00f3n de la velocidad de desplazamiento que en la organizaci\u00f3n de la memoria interna. Una desventaja fue que la animaci\u00f3n ASCII era algo imprecisa.\"<\/p><\/blockquote>\n
\nPara corregir esta aparente lentitud de xterm, Diki sugiere utilizar el recurso fastScroll<\/a><\/noindex>, que permite a xterm descartar algunas actualizaciones de la pantalla para no quedarse atr\u00e1s del flujo. Mis pruebas confirman que fastScroll mejora el rendimiento y lleva a xterm al mismo nivel que rxvt. Sin embargo, es un parche algo tosco, como explica Diki: \"a veces xterm \u2014al igual que konsole\u2014 parece detenerse, ya que espera un nuevo conjunto de actualizaciones de pantalla despu\u00e9s de que se han eliminado algunas de ellas\". En este sentido, parece que otros terminales han encontrado el mejor compromiso entre velocidad e integridad de la pantalla.<\/p>\n
Consumo de recursos<\/h4>\n
\nIndependientemente de la viabilidad de considerar la velocidad de desplazamiento como una medida de rendimiento, esta prueba permite simular la carga en los terminales, lo que a su vez nos permite medir otros par\u00e1metros, como el uso de memoria o disco. Las m\u00e9tricas se obtuvieron ejecutando la prueba mencionada seq<\/b> bajo la supervisi\u00f3n de un proceso de Python. Recopil\u00f3 datos de los contadores getrusage ()<\/a><\/noindex> para ru_maxrss<\/b>, la suma de ru_oublock<\/b> y ru_inblock<\/b> y un temporizador simple de tiempo.<\/p>\n
\"Revisi\u00f3n
\n
\nEn esta prueba, ST ocupa el primer lugar con el menor consumo promedio de memoria de 8 MB, lo cual no es sorprendente, ya que la idea principal del proyecto es la simplicidad. Un poco m\u00e1s consumen mlterm, xterm y rxvt, alrededor de 12 MB. Otro resultado notable es Alacritty, que requiere 30 MB para funcionar. Luego est\u00e1n los terminales de la familia VTE con un consumo de entre 40 y 60 MB, lo cual es bastante. Este tipo de consumo se puede explicar porque esos terminales utilizan bibliotecas de m\u00e1s alto nivel, como GTK. Konsole ocupa el \u00faltimo lugar con un consumo colosal de 65 MB de memoria durante las pruebas, aunque esto se puede justificar por su amplia gama de funciones.<\/p>\n
En comparaci\u00f3n con los resultados anteriores, obtenidos hace diez a\u00f1os, todos los programas han comenzado a consumir notablemente m\u00e1s memoria. Antes, Xterm requer\u00eda 4 MB, y ahora 15 MB simplemente para iniciar. Un aumento similar en el consumo se observa en rxvt, que ahora requiere 16 MB por defecto. El terminal de Xfce ocupa 34 MB, lo que es tres veces m\u00e1s que antes, mientras que GNOME Terminal necesita solo 20 MB. Por supuesto, todas las pruebas anteriores se realizaron en una arquitectura de 32 bits. En LCA 2012, Rusty Russell cont\u00f3<\/a><\/noindex>, hay muchas razones m\u00e1s sutiles que pueden explicar el aumento del consumo de memoria. Dicho esto, ahora vivimos en una \u00e9poca en la que tenemos varios gigabytes de memoria, as\u00ed que nos las arreglaremos de alguna manera.<\/p>\n
Sin embargo, no puedo deshacerme de la sensaci\u00f3n de que asignar m\u00e1s memoria a un software tan fundamental como un terminal es un desperdicio de recursos. Estos programas deber\u00edan ser los m\u00e1s ligeros de todos, deber\u00edan ser capaces de funcionar en cualquier \"caja\", incluso en una de zapatos, si alguna vez llegamos al punto de equiparlos con sistemas Linux (y saben que as\u00ed ser\u00e1). Pero con estas cifras, el uso de memoria se convertir\u00e1 en un problema en cualquier entorno al ejecutar varias terminales, excepto en situaciones con las m\u00e1s ligeras y limitadas en funciones. Para compensar esto, GNOME Terminal, Konsole, urxvt, Terminator y Xfce Terminal tienen un modo Daemon, que permite gestionar m\u00faltiples terminales a trav\u00e9s de un solo proceso, lo que limita su consumo de memoria.<\/p>\n
\"Revisi\u00f3n
\n
\nDurante mis pruebas, llegu\u00e9 a otro resultado inesperado respecto a la lectura y escritura en disco: esperaba no ver nada aqu\u00ed, pero result\u00f3 que algunas terminales escriben los datos m\u00e1s pesados en el disco. As\u00ed, la biblioteca VTE de hecho mantiene un b\u00fafer de desplazamiento en el disco (esta caracter\u00edstica fue observada ya en 2010<\/a><\/noindex>, y esto sigue ocurriendo hasta hoy). Pero a diferencia de las viejas implementaciones, ahora, al menos, estos datos est\u00e1n cifrados con AES256 GCM (a partir de la versi\u00f3n 0.39.2<\/a><\/noindex>). Pero surge una pregunta razonable, \u00bfqu\u00e9 tiene de especial la biblioteca VTE que requiere un enfoque tan poco convencional para su implementaci\u00f3n\u2026?<\/p>\n
Conclusi\u00f3n<\/h4>\n
\nEn la primera parte del art\u00edculo descubrimos que las terminales basadas en VTE tienen un buen conjunto de caracter\u00edsticas, pero ahora vemos que esto conlleva ciertos costos para garantizar su rendimiento. Ahora la memoria no es un problema, ya que todas las terminales VTE pueden ser gestionadas a trav\u00e9s de un proceso Daemon, que limita su apetito. Sin embargo, los sistemas antiguos, que tienen limitaciones f\u00edsicas en la cantidad de memoria RAM y b\u00fafer del n\u00facleo, pueden todav\u00eda necesitar versiones anteriores de las terminales, ya que consumen significativamente menos recursos. Aunque las terminales VTE se han comportado bien en las pruebas de ancho de banda (desplazamiento), su latencia para mostrar datos en la pantalla supera el umbral establecido en la gu\u00eda del usuario de GNOME. Probablemente, los desarrolladores de VTE deber\u00edan tener esto en cuenta. Dado que incluso para los nuevos usuarios de Linux el encuentro con la terminal es inevitable, podr\u00edan hacerla m\u00e1s amigable para el usuario. Para los geeks experimentados, cambiar de la terminal predeterminada puede incluso significar una reducci\u00f3n de la carga visual y la posibilidad de evitar lesiones y enfermedades profesionales en el futuro debido a largas sesiones de trabajo. Desafortunadamente, solo los viejos xterm y mlterm nos llevan al m\u00e1gico umbral de ping de 10 milisegundos, lo cual es inaceptable para muchos.<\/p>\n
Las mediciones de control tambi\u00e9n mostraron que, debido al desarrollo de entornos gr\u00e1ficos en Linux, los desarrolladores se vieron obligados a hacer varios compromisos. Algunos usuarios deber\u00edan considerar los gestores de ventanas tradicionales, ya que proporcionan una reducci\u00f3n significativa de la latencia. Desafortunadamente, no pude medir la latencia en Wayland: el programa Typometer que utilic\u00e9 fue creado para lo que Wayland pretende prevenir: la vigilancia de otras ventanas. Espero que el rendimiento del compositador de Wayland sea mejor que el de X.org, y tambi\u00e9n espero que en el futuro alguien encuentre una manera de evaluar el nivel de latencia en este entorno.
\n
Fuente: 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\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\udd47Revisi\u00f3n de emuladores de terminal | ProHoster","description":"Unas palabras de nuestra agencia de traducci\u00f3n: normalmente todos buscan traducir los materiales y publicaciones m\u00e1s recientes, y nosotros no somos la excepci\u00f3n. Pero los emuladores de terminales no son algo que se actualice cada semana.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/obzor-emulyatorov-terminala","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/37222","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=37222"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/37222\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/27911"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=37222"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=37222"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=37222"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}