Unes paraules de la nostra oficina de traducció: normalment tothom s'esforça per traduir els últims materials i publicacions, i no som una excepció. Però els terminals no són quelcom que s'actualitzi un cop a la setmana. Per això, us hem traduït un article d'Antoine Beaupré, publicat a la primavera de 2018: malgrat la seva considerable "edat" segons els estàndards moderns, al nostre parer, el material no ha perdut gens la seva rellevància. A més, originalment es tractava d'una sèrie de dos articles, però vam decidir combinar-los en una publicació gran.
Els terminals tenen un lloc especial en la història de l'ordinador, però en les últimes dècades s'han vist obligats a sobreviure al costat de la línia d'ordres a mesura que les interfícies gràfiques es fan omnipresents. substituït els seus , que, al seu torn, eren una modificació de sistemes basats en targetes perforades i interruptors de palanca. Les distribucions modernes inclouen una varietat d'emuladors de terminals de totes les formes i colors. I encara que molts es conformen amb el terminal estàndard que ofereix el seu entorn de treball, alguns utilitzen amb orgull programari francament exòtic per executar el seu shell o editor de text preferit. Però, com veurem en aquest article, no tots els terminals es van crear amb la mateixa imatge: difereixen molt en funcionalitat, mida i rendiment.
Alguns terminals tenen forats de seguretat francament sorprenents, a més de la majoria tenen un conjunt de funcions completament diferent, des de suport per a una interfície amb pestanyes fins a scripts. Encara que nosaltres , aquest article és una actualització del material anterior que ajudarà els lectors a determinar quin terminal utilitzar el 2018. La primera meitat de l'article compara les característiques i la segona meitat avalua el rendiment.
Aquests són els terminals que vaig revisar:
És possible que aquestes no siguin les darreres versions, ja que en el moment d'escriure m'he limitat a compilacions estables, que vaig poder implementar a Debian 9 o Fedora 27. L'única excepció és Alacritty. És un descendent de terminals accelerats per GPU i està escrit en un llenguatge inusual i nou per a aquesta tasca: Rust. He exclòs els terminals web de la meva revisió (inclosos els de ), perquè les proves preliminars van mostrar el seu rendiment extremadament pobre.
Suport Unicode
Vaig començar les meves proves amb suport Unicode. La primera prova dels terminals va ser mostrar la cadena Unicode de : "é, Δ, И, ק, م, ๗, あ, 叶, 葉 i 말." Aquesta senzilla prova mostra si el terminal pot funcionar correctament a tot el món. El terminal xterm no mostra caràcter àrab en la configuració per defecte:
Per defecte, xterm utilitza el tipus de lletra clàssic "fix", que, segons , té "una cobertura Unicode substancial des de 1997". Hi ha alguna cosa en aquest tipus de lletra que fa que el caràcter aparegui com a marc en blanc i és només quan el tipus de lletra del text augmenta a més de 20 punts que finalment el caràcter comença a mostrar-se correctament. Tanmateix, aquesta "correcció" trenca la visualització d'altres caràcters Unicode:
Aquestes captures de pantalla es van fer a Fedora 27, ja que donava millors resultats que Debian 9, on algunes versions anteriors de terminals (específicament mlterm) no podien manejar els tipus de lletra correctament. Afortunadament, això es va solucionar en versions posteriors.
Ara observeu com es mostra la línia a xterm. Resulta que el símbol Mem i el següent semític consulteu els scripts d'estil RTL (), així que tècnicament s'han de mostrar de dreta a esquerra. Els navegadors web com ara Firefox 57 gestionen correctament la línia anterior. Una versió més senzilla del text RTL és la paraula ""en hebreu (). diu el següent:
"Molts programes informàtics no poden mostrar correctament el text bidireccional. Per exemple, el nom hebreu "Sarah" consta dels caràcters sin (ש) (que apareix a la dreta), després resh (ר) i finalment he (ה) (que hauria d'aparèixer a l'esquerra)."
Molts terminals fallen aquesta prova: Alacritty, terminals Gnome i XFCE derivats de VTE, urxvt, st i xterm mostren "Sara" en ordre invers, com si haguéssim escrit el nom com "Aras".
Un altre problema amb els textos bidireccionals és que s'han d'alinear d'alguna manera, especialment quan es tracta de barrejar textos RTL i LTR. Els scripts RTL s'han d'executar des del costat dret de la finestra del terminal, però què hauria de passar amb els terminals que tinguin per defecte l'anglès LTR? La majoria d'ells no tenen cap mecanisme especial i alineen tot el text a l'esquerra (inclòs a Konsole). Les excepcions són pterm i mlterm, que s'adhereixen als estàndards i alineen aquestes línies a la dreta.
Protecció d'inserció
La següent característica crítica que he identificat és la protecció anti-inserció. Tot i que és àmpliament conegut que s'escriu com:
$ curl http://example.com/ | shsón ordres push d'execució de codi, poca gent sap que les ordres ocultes poden colar-se a la consola quan es copien i enganxen des d'un navegador web, fins i tot després d'una inspecció acurada. mostra de manera brillant l'aspecte innocu de l'ordre:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gites converteix en una molèstia quan s'enganxa des del lloc web de Horn al 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.gitCom funciona? El codi maliciós s'inclou al bloc , que es mou fora de la vista de l'usuari mitjançant CSS.
està clarament dissenyat per neutralitzar aquests atacs. En aquest mode, els terminals tanquen el text enganxat en un parell de seqüències d'escapament especials per indicar a l'intèrpret d'ordres l'origen del text. Això indica al shell que pot ignorar els caràcters especials que pot contenir el text enganxat. Tots els terminals que tornen al venerable xterm admeten aquesta funció, però per enganxar en mode entre parèntesis requereix suport de l'intèrpret d'ordres o de l'aplicació que s'executa al terminal. Per exemple, l'ús de programari (el mateix Bash), necessita un fitxer ~/.inputrc:
set enable-bracketed-paste onMalauradament, el lloc de proves de Horn també mostra com evitar aquesta protecció mitjançant el propi format de text i acabar-hi aplicant-hi prematurament el mode entre corchetes. Això funciona perquè alguns terminals no filtren correctament les seqüències d'escapada abans d'afegir les seves pròpies. Per exemple, a la meva mai no vaig poder completar amb èxit les proves de Konsole, fins i tot amb la configuració correcta .inputrc dossier. Això vol dir que podeu malmetre fàcilment la configuració del vostre sistema a causa d'una aplicació no compatible o d'un shell configurat incorrectament. Això és especialment perillós quan inicieu sessió en servidors remots, on el treball de configuració acurat és menys habitual, sobretot si teniu moltes màquines remotes.
Una bona solució a aquest problema és el connector de confirmació d'enganxament per al terminal urxvt, que simplement demana permís per inserir qualsevol text que contingui noves línies. No he trobat cap opció més segura per a l'atac de text descrit per Horn.
Pestanyes i perfils
Una característica popular ara mateix és el suport per a una interfície amb pestanyes, que definirem com una finestra de terminal que conté diversos terminals més. Aquesta funció és diferent per a diferents terminals, i tot i que els terminals xterm tradicionals no admeten en absolut les pestanyes, les encarnacions de terminals més modernes com ara Xfce Terminal, GNOME Terminal i Konsole sí que tenen aquesta funció. Urxvt també admet pestanyes, però només si feu servir un connector. Però pel que fa al suport de pestanyes, Terminator és el líder indiscutible: no només admet pestanyes, sinó que també pot organitzar terminals en qualsevol ordre (vegeu la imatge a continuació).
Una altra característica de Terminator és la capacitat d'"agrupar" aquestes pestanyes i enviar les mateixes pulsacions de tecles a diversos terminals alhora, proporcionant una eina crua per realitzar operacions massives en diversos servidors simultàniament. Una característica similar també s'implementa a Konsole. Per utilitzar aquesta funció en altres terminals, heu d'utilitzar programari de tercers com ara , o .
Les pestanyes funcionen especialment bé quan es combinen amb perfils: per exemple, podeu tenir una pestanya per al correu electrònic, una altra per al xat, etc. Això és ben compatible amb el terminal Konsole i el terminal GNOME. Tots dos permeten que cada pestanya iniciï automàticament el seu propi perfil. Terminator també admet perfils, però no he pogut trobar una manera d'iniciar automàticament determinats programes quan obriu una pestanya específica. Altres terminals no tenen cap concepte de "perfil".
Volants
L'últim que parlaré a la primera part d'aquest article és l'aparició dels terminals. Per exemple, GNOME, Xfce i urxvt admeten la transparència, però recentment han deixat de suportar les imatges de fons, obligant alguns usuaris a canviar al terminal. . Personalment, n'estic content i és senzill Recursos X, que estableix el conjunt base de colors de fons per a urxvt. Tanmateix, els temes de color no estàndard també poden crear problemes. Per exemple, amb aplicacions и , ja que ja utilitzen els seus propis colors.
no admetia colors, i els nous sovint es limitaven a una paleta de 256 colors. Per als usuaris avançats que dissenyen els seus terminals, les indicacions de l'intèrpret d'ordres o les barres d'estat de maneres complexes poden ser una limitació molesta. rastreja quins terminals tenen suport "True Color". Les meves proves confirmen que els terminals basats en st, Alacritty i VTE admeten perfectament True Color. A altres terminals no els va gaire bé en aquest sentit i, de fet, ni tan sols mostren 256 colors. A continuació podeu veure la diferència entre el suport True Color als terminals de GNOME, st i xterm, que fan una bona feina amb la seva paleta de colors de 256, i urxvt, que no només falla la prova, sinó que fins i tot mostra alguns caràcters parpellejants en lloc d'ells.
Alguns terminals també analitzen text per trobar patrons d'URL per fer clic als enllaços. Això s'aplica a tots els terminals derivats de VTE, mentre que urxvt requereix un connector especial que transformi els URL amb un clic o amb una drecera de teclat. Altres terminals que he provat mostrar URL d'altres maneres.
Finalment, una nova tendència en terminals és l'opcionalitat del buffer de desplaçament. Per exemple, st no té memòria intermèdia de desplaçament; se suposa que l'usuari utilitzarà un multiplexor de terminal com tmux i .
Alacritty també no té buffers de desplaçament enrere, però el seu suport a causa dels "amplis comentaris" sobre aquest tema dels usuaris. A part d'aquests principiants, tots els terminals que he provat que he pogut trobar admeten el desplaçament invers.
Subtotals
A la segona part del material (a l'original es tracta de dos articles diferents: aprox. carril) compararem el rendiment, l'ús de la memòria i la latència. Però ja veiem que alguns dels terminals en qüestió presenten greus mancances. Per exemple, els usuaris que treballen habitualment amb scripts RTL poden voler considerar mlterm i pterm, ja que són millors per gestionar tasques similars que altres. Konsole també va funcionar bé. Els usuaris que no treballen amb scripts RTL poden triar una altra cosa.
Pel que fa a la protecció contra la inserció de codi maliciós, urxvt destaca per la seva especial implementació de protecció contra aquest tipus d'atac, que em sembla definitivament convenient. Per a aquells que busquen campanes i xiulets, val la pena fer-hi una ullada a Konsole. Finalment, val la pena destacar que VTE és una excel·lent base per a terminals, que garanteix suport de color, reconeixement d'URL, etc. A primera vista, el terminal predeterminat que ve amb el vostre entorn preferit pot complir tots els requisits, però deixem aquesta pregunta oberta fins que entenem el rendiment.
Continuem la conversa
En general, el rendiment dels terminals en si mateix pot semblar un problema descabellat, però resulta que alguns d'ells presenten una latència sorprenentment alta per a un programari d'un tipus tan fonamental. També a continuació veurem el que tradicionalment s'anomena "velocitat" (de fet, aquesta és la velocitat de desplaçament) i el consum de memòria del terminal (amb l'advertència que això no és tan crític avui en dia com fa dècades).
Retard
Després d'un estudi exhaustiu del rendiment del terminal, vaig arribar a la conclusió que el paràmetre més important en aquest sentit és la latència (ping). En el seu article Pavel Fatin va analitzar la latència de diversos editors de text i va donar a entendre que els terminals en aquest sentit poden ser més lents que els editors de text més ràpids. Va ser aquesta pista la que finalment em va portar a fer les meves pròpies proves i escriure aquest article.
Però què és la latència i per què és tan important? En el seu article, Fatin ho va definir com "el retard entre prémer una tecla i l'actualització de la pantalla corresponent" i va citar , que diu: "El retard en la retroalimentació visual a la pantalla d'un ordinador té un impacte important en el comportament i la satisfacció del mecanògraf".
Fatin explica que aquest ping té conseqüències més profundes que la simple satisfacció: "l'escriptura es fa més lenta, es produeixen més errors i augmenta la tensió ocular i muscular". En altres paraules, un gran retard pot provocar errors ortogràfics i també una menor qualitat del codi, ja que comporta una càrrega cognitiva addicional al cervell. Però el pitjor és que el ping "augmenta la tensió ocular i muscular", cosa que sembla implicar en el futur (Pel que sembla, l'autor vol dir problemes amb els músculs dels ulls, l'esquena, els braços i, per descomptat, la visió - aprox. carril) a causa de l'estrès repetitiu.
Alguns d'aquests efectes es coneixen des de fa molt de temps, i els resultats , publicat el 1976 a la revista Ergonomics, va dir que un retard de 100 mil·lisegons "perjudica significativament la velocitat d'escriptura". Més recentment, s'ha introduït la Guia d'usuari de GNOME en 10 mil·lisegons, i si aneu més enllà, aleshores demostra que 1 mil·lisegon és ideal.
Fatin va realitzar les seves proves en editors de text; va crear un instrument portàtil anomenat , que vaig utilitzar per provar el ping als emuladors de terminal. Tingueu en compte que la prova s'ha fet en mode simulació: en realitat, hem de tenir en compte tant la latència d'entrada (teclat, controlador USB, etc.) com de sortida (búfer de la targeta de vídeo, monitor). Segons Fatin, en configuracions típiques és d'uns 20 ms. Si teniu equips de joc, podeu aconseguir aquesta xifra en només 3 mil·lisegons. Com que ja tenim un maquinari tan ràpid, l'aplicació no ha d'afegir la seva pròpia latència. L'objectiu de Fatin és portar la latència de l'aplicació a 1 mil·lisegon, o fins i tot aconseguir marcar sense , com dins .
Aquests són els resultats de les meves mesures, així com alguns dels resultats de Fatin, per demostrar que el meu experiment està d'acord amb les seves proves:
El primer que em va cridar l'atenció va ser el millor temps de resposta de programes antics com xterm i mlterm. Amb la pitjor latència de registre (2,4 ms), van tenir un millor rendiment que el terminal modern més ràpid (10,6 ms per st). Cap terminal modern cau per sota del llindar de 10 mil·lisegons. En particular, Alacritty no compleix la reclamació de "l'emulador de terminal més ràpid disponible", tot i que les seves puntuacions han millorat des de la seva primera revisió el 2017. En efecte, els autors del projecte i treballem per millorar la visualització. També cal tenir en compte que Vim utilitzant GTK3 és un ordre de magnitud més lent que el seu homòleg GTK2. D'això podem concloure que GTK3 crea una latència addicional, i això es reflecteix en tots els altres terminals que l'utilitzen (Terminator, Xfce4 Terminal i GNOME Terminal).
No obstant això, les diferències poden no ser perceptibles a la vista. Com explica Fatin, "no cal que siguis conscient del retard perquè tingui un efecte sobre tu". Fatin també adverteix sobre la desviació estàndard: "qualsevol alteració de la latència (jitter) crea una tensió addicional a causa de la seva impredictibilitat".
El gràfic anterior està fet amb Debian 9 pur (estirar) amb . Aquest entorn produeix els millors resultats en proves de latència. Com a resultat, GNOME crea un ping addicional de 20 ms per a totes les mesures. Una possible explicació d'això és la presència de programes amb processament síncron d'esdeveniments d'entrada. Fatin posa un exemple per a aquest cas , que afegeix un retard en processar tots els esdeveniments d'entrada de manera sincrònica. Per defecte, GNOME també inclou un gestor de finestres , que crea una capa addicional de memòria intermèdia, que afecta el ping i afegeix almenys 8 mil·lisegons de latència.
Velocitat de desplaçament
La següent prova és una prova tradicional de "velocitat" o "amplada de banda", que mesura la rapidesa amb què el terminal pot desplaçar-se per una pàgina mentre mostra grans quantitats de text a la pantalla. La mecànica de la prova varia; la prova original era generar simplement la mateixa cadena de text mitjançant l'ordre seq. Altres proves inclouen la prova de Thomas E. Dickey (mantenidor de xterm), que repetidament . En una altra revisió del rendiment del terminal utilitza una cadena codificada en base32 de bytes aleatoris, que s'envia al terminal mitjançant cat. Luu considera que aquesta prova és "un punt de referència tan inútil com es pot imaginar" i suggereix utilitzar la resposta del terminal com a mètrica principal. Dickey també qualifica la seva prova d'enganyosa. Tanmateix, tots dos autors reconeixen que l'amplada de banda de la finestra del terminal pot ser un problema. Luu va descobrir que l'Emacs Eshell es congelava quan mostrava fitxers grans i Dickey va optimitzar el terminal per eliminar la lentitud visual d'xtrerm. Per tant, aquesta prova encara té algun mèrit, però com que el procés de representació és molt diferent d'un terminal a un altre, també es pot utilitzar com a component de prova per provar altres paràmetres.
Aquí veiem el rxvt i el st tirar per davant de la competència, seguits del molt més nou Alacritty, que està dissenyat centrant-se en el rendiment. Els següents són Xfce (família VTE) i Konsole, que són gairebé el doble de ràpids. L'últim és xterm, que és cinc vegades més lent que rxvt. Durant la prova, l'xterm també es va mostrar molt, la qual cosa va fer que el text aprovat fos difícil de veure encara que fos la mateixa línia. Konsole era ràpid, però de vegades era complicat: la pantalla es congelava de tant en tant, mostrava text parcial o no el mostrava en absolut. Altres terminals mostraven cadenes clarament, com st, Alacritty i rxvt.
Dickey explica que les diferències de rendiment es deuen al disseny dels buffers de desplaçament en diferents terminals. En particular, acusa rxvt i altres terminals de "no seguir les regles generals":
"A diferència d'xterm, rxvt no va intentar mostrar totes les actualitzacions. Si es queda endarrerit, rebutjarà algunes actualitzacions per posar-se al dia. Això va tenir un impacte més gran en la velocitat de desplaçament aparent que en l'organització de la memòria interna. Un inconvenient va ser que l'animació ASCII era una mica imprecisa".
Per solucionar aquesta lentitud de xterm percebuda, Dickey suggereix utilitzar el recurs , permetent a xterm descartar algunes actualitzacions de pantalla per mantenir-se al dia amb el flux. Les meves proves confirmen que fastScroll millora el rendiment i aporta xterm a l'igual que rxvt. Això és, però, una crossa bastant tosca, com explica el mateix Dickey: "de vegades, xterm, com la konsole, sembla aturar-se mentre espera un nou conjunt d'actualitzacions de pantalla després d'haver eliminat algunes". En aquest sentit, sembla que altres terminals han trobat el millor compromís entre la velocitat i la integritat de la pantalla.
Consum de recursos
Independentment de si té sentit considerar la velocitat de desplaçament com a mètrica de rendiment, aquesta prova ens permet simular la càrrega dels terminals, que al seu torn ens permet mesurar altres paràmetres com la memòria o l'ús del disc. Les mètriques es van obtenir executant la prova especificada ss sota la supervisió de processos de Python. Va recollir les dades del comptador per ru_maxrss, import ru_oblock и ru_inblock i un simple temporitzador.
En aquesta prova, l'ST ocupa el primer lloc amb el consum mitjà de memòria més baix de 8 MB, la qual cosa no sorprèn tenint en compte que la idea principal del disseny és la simplicitat. mlterm, xterm i rxvt consumeixen una mica més: uns 12 MB. Un altre resultat notable és Alacritty, que requereix 30 MB per funcionar. Després hi ha terminals de la família VTE amb xifres de 40 a 60 MB, que és bastant. Aquest consum es pot explicar pel fet que aquests terminals utilitzen biblioteques de nivell superior, per exemple, GTK. Konsole arriba al final amb un consum de memòria de 65 MB durant les proves, tot i que això es pot justificar per la seva àmplia gamma de funcions.
En comparació amb els resultats anteriors obtinguts fa deu anys, tots els programes van començar a consumir notablement més memòria. Xterm solia requerir 4 MB, però ara requereix 15 MB només a l'inici. Hi ha un augment similar en el consum per a rxvt, que ara requereix 16 MB fora de la caixa. El terminal Xfce ocupa 34 MB, que és tres vegades més gran que abans, però el terminal GNOME només requereix 20 MB. Per descomptat, totes les proves anteriors es van dur a terme en arquitectura de 32 bits. A LCA 2012 Rusty Russell , que hi ha moltes raons més subtils que podrien explicar l'augment del consum de memòria. Dit això, ara vivim en una època on tenim gigabytes de memòria, així que ens en sortirem d'alguna manera.
Tanmateix, no puc evitar sentir que destinar més memòria a una cosa tan fonamental com el terminal és un malbaratament de recursos. Aquests programes haurien de ser els més petits dels més petits, haurien de poder executar-se en qualsevol "caixa", fins i tot una caixa de sabates, si mai arribem al punt en què cal que estiguin equipats amb sistemes Linux (i saps que serà així). ). Però amb aquests números, l'ús de la memòria es convertirà en un problema en el futur en qualsevol entorn amb diversos terminals que no siguin alguns dels més lleugers i amb capacitats limitades. Per compensar-ho, GNOME Terminal, Konsole, urxvt, Terminator i Xfce Terminal disposen d'un mode Daemon que permet controlar diversos terminals mitjançant un sol procés, limitant-ne el consum de memòria.
Durant les meves proves, vaig arribar a un altre resultat inesperat pel que fa a la lectura-escriptura del disc: esperava no veure res aquí, però va resultar que alguns terminals escriuen les dades més voluminoses al disc. Per tant, la biblioteca VTE en realitat manté una memòria intermèdia de desplaçament al disc (aquesta característica , i això encara està passant). Però a diferència de les implementacions anteriors, ara almenys aquestes dades es xifren mitjançant AES256 GCM (). Però sorgeix una pregunta raonable: què té d'especial la biblioteca VTE que requereix un enfocament tan no estàndard per a la implementació...
Conclusió
A la primera part de l'article, vam trobar que els terminals basats en VTE tenen un bon conjunt de funcions, però ara veiem que això comporta alguns costos de rendiment. Ara la memòria no és un problema perquè tots els terminals VTE es poden controlar mitjançant un procés Daemon, que limita la seva gana. Tanmateix, els sistemes més antics que tenen limitacions físiques en la quantitat de memòria RAM i els buffers del nucli encara poden necessitar versions anteriors de terminals, ja que consumeixen molt menys recursos. Tot i que els terminals VTE van funcionar bé en les proves de rendiment (desplaçament), la seva latència de visualització està per sobre del llindar establert a la Guia d'usuari de GNOME. Els desenvolupadors de VTE probablement haurien de tenir-ho en compte. Si tenim en compte que fins i tot per als usuaris novells de Linux trobar-se amb un terminal és inevitable, poden fer-lo més fàcil d'utilitzar. Per als frikis experimentats, canviar del terminal predeterminat pot significar fins i tot menys fatiga visual i la capacitat d'evitar futures lesions i malalties relacionades amb el treball a causa de llargues sessions de treball. Malauradament, només els antics xterm i mlterm ens porten al llindar màgic de ping de 10 mil·lisegons, que és inacceptable per a molts.
Les mesures de referència també van demostrar que a causa del desenvolupament d'entorns gràfics Linux, els desenvolupadors van haver de fer una sèrie de compromisos. És possible que alguns usuaris vulguin mirar els gestors de finestres habituals, ja que proporcionen una reducció significativa del ping. Malauradament, no va ser possible mesurar la latència per a Wayland: el programa Typometer que vaig utilitzar es va crear per al que Wayland està dissenyat per evitar: espiar altres finestres. Espero que Wayland compositing funcioni millor que X.org, i també espero que en el futur algú trobi una manera de mesurar la latència en aquest entorn.
Font: www.habr.com