Quelques mots de notre bureau de traduction : en général, tout le monde s'efforce de traduire les derniers documents et publications, et nous ne faisons pas exception. Mais les terminaux ne sont pas mis à jour une fois par semaine. Nous avons donc traduit pour vous un article d'Antoine Beaupré, publié au printemps 2018 : malgré son « âge » considérable selon les normes modernes, à notre avis, le matériau n'a pas du tout perdu de sa pertinence. De plus, il s'agissait à l'origine d'une série de deux articles, mais nous avons décidé de les combiner en un seul grand article.
Les terminaux occupent une place particulière dans l’histoire de l’informatique, mais au cours des dernières décennies, ils ont été contraints de survivre aux côtés de la ligne de commande alors que les interfaces graphiques sont devenues omniprésentes. remplacé le leur , qui, à leur tour, étaient une modification de systèmes basés sur des cartes perforées et des interrupteurs à bascule. Les distributions modernes sont livrées avec une variété d'émulateurs de terminaux de toutes formes et couleurs. Et si beaucoup se contentent du terminal standard fourni par leur environnement de travail, certains utilisent fièrement des logiciels carrément exotiques pour faire tourner leur shell ou éditeur de texte préféré. Mais, comme nous le verrons dans cet article, tous les terminaux n'ont pas été créés à la même image : ils diffèrent grandement par leurs fonctionnalités, leur taille et leurs performances.
Certains terminaux présentent des failles de sécurité tout à fait surprenantes, et la plupart disposent d'un ensemble de fonctions complètement différent, de la prise en charge d'une interface à onglets aux scripts. Bien que nous , cet article est une mise à jour du matériel précédent qui aidera les lecteurs à déterminer quel terminal utiliser en 2018. La première moitié de l'article compare les fonctionnalités et la seconde moitié évalue les performances.
Voici les terminaux que j'ai examinés :
Ce ne sont peut-être pas les dernières versions, car j'étais limité aux versions stables au moment de la rédaction, que j'ai pu déployer sur Debian 9 ou Fedora 27. La seule exception est Alacritty. Il s'agit d'un descendant des terminaux accélérés par GPU et est écrit dans un langage inhabituel et nouveau pour cette tâche : Rust. J'ai exclu les terminaux Web de mon avis (y compris ceux sur ), car les tests préliminaires ont montré leurs performances extrêmement médiocres.
Prise en charge d'Unicode
J'ai commencé mes tests avec le support Unicode. Le premier test des terminaux consistait à afficher la chaîne Unicode de : "é, Δ, И, ק, م, ๗, あ, 叶, 葉 et 말." Ce test simple montre si le terminal peut fonctionner correctement dans le monde entier. Le terminal xterm n'affiche pas le caractère arabe en configuration par défaut :
Par défaut, xterm utilise la police classique « fixe » qui, selon , a « une couverture Unicode substantielle depuis 1997 ». Il se passe quelque chose dans cette police qui fait que le caractère apparaît comme un cadre vide et ce n'est que lorsque la police du texte est augmentée à plus de 20 points que le caractère commence enfin à s'afficher correctement. Cependant, ce « correctif » interrompt l'affichage des autres caractères Unicode :
Ces captures d'écran ont été prises dans Fedora 27, car elles donnaient de meilleurs résultats que Debian 9, où certaines anciennes versions de terminaux (en particulier mlterm) ne pouvaient pas gérer correctement les polices. Heureusement, cela a été corrigé dans les versions ultérieures.
Remarquez maintenant comment la ligne est affichée dans xterm. Il s'avère que le symbole Mem et le sémitique suivant reportez-vous aux scripts de style RTL (), donc techniquement, ils devraient être affichés de droite à gauche. Les navigateurs Web tels que Firefox 57 gèrent correctement la ligne ci-dessus. Une version plus simple du texte RTL est le mot "" en hébreu (). dit ce qui suit :
« De nombreux programmes informatiques ne peuvent pas afficher correctement le texte bidirectionnel. Par exemple, le nom hébreu « Sarah » est constitué des caractères sin (ש) (qui apparaît à droite), puis resh (ר) et enfin he (ה) (qui doit apparaître à gauche)."
De nombreux terminaux échouent à ce test : Alacritty, les terminaux Gnome et XFCE dérivés de VTE, urxvt, st et xterm affichent "Sara" dans l'ordre inverse, comme si nous avions écrit le nom "Aras".
Un autre problème avec les textes bidirectionnels est qu'ils doivent être alignés d'une manière ou d'une autre, notamment lorsqu'il s'agit de mélanger des textes RTL et LTR. Les scripts RTL doivent s'exécuter à partir du côté droit de la fenêtre du terminal, mais que doit-il se passer pour les terminaux qui utilisent par défaut l'anglais LTR ? La plupart d'entre eux n'ont pas de mécanismes spéciaux et alignent tout le texte à gauche (y compris dans Konsole). Les exceptions sont pterm et mlterm, qui respectent les normes et alignent ces lignes à droite.
Protection contre l'insertion
La prochaine fonctionnalité critique que j’ai identifiée est la protection anti-insertion. Bien qu'il soit largement connu que des sorts comme :
$ curl http://example.com/ | shsont des commandes push d'exécution de code, peu de gens savent que des commandes cachées peuvent se faufiler dans la console lors d'un copier-coller depuis un navigateur Web, même après une inspection minutieuse. montre brillamment à quel point la commande semble inoffensive :
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitse transforme en une telle nuisance lorsqu'il est collé depuis le site Web de Horn dans le 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.gitComment ça fonctionne? Un code malveillant est inclus dans le bloc , qui est déplacé hors de la vue de l'utilisateur à l'aide de CSS.
est clairement conçu pour neutraliser de telles attaques. Dans ce mode, les terminaux enferment le texte collé dans une paire de séquences d'échappement spéciales pour indiquer au shell l'origine du texte. Cela indique au shell qu'il peut ignorer les caractères spéciaux que le texte collé peut contenir. Tous les terminaux du vénérable xterm prennent en charge cette fonctionnalité, mais le collage en mode Bracketed nécessite la prise en charge du shell ou de l'application exécutée sur le terminal. Par exemple, un logiciel utilisant (même Bash), nécessite un fichier ~/.inputrc:
set enable-bracketed-paste onMalheureusement, le site de test de Horn montre également comment contourner cette protection via le formatage du texte lui-même et finir par lui appliquer prématurément le mode Bracketed. Cela fonctionne car certains terminaux ne filtrent pas correctement les séquences d'échappement avant d'ajouter les leurs. Par exemple, dans le mien, je n'ai jamais réussi à terminer avec succès les tests de Konsole, même avec la bonne configuration. .inputrc déposer. Cela signifie que vous pouvez facilement corrompre la configuration de votre système en raison d'une application non prise en charge ou d'un shell mal configuré. Ceci est particulièrement dangereux lors de la connexion à des serveurs distants, où un travail de configuration minutieux est moins courant, surtout si vous disposez de nombreuses machines distantes de ce type.
Une bonne solution à ce problème est le plugin de confirmation de collage pour le terminal urxvt, qui demande simplement la permission d'insérer tout texte contenant des nouvelles lignes. Je n'ai pas trouvé d'option plus sécurisée pour l'attaque textuelle décrite par Horn.
Onglets et profils
Une fonctionnalité populaire à l'heure actuelle est la prise en charge d'une interface à onglets, que nous définirons comme une fenêtre de terminal contenant plusieurs autres terminaux. Cette fonction diffère selon les terminaux, et bien que les terminaux xterm traditionnels ne prennent pas du tout en charge les onglets, les incarnations de terminaux plus modernes telles que Xfce Terminal, GNOME Terminal et Konsole ont cette fonction. Urxvt prend également en charge les onglets, mais uniquement si vous utilisez un plugin. Mais en termes de prise en charge des onglets lui-même, Terminator est le leader incontesté : il prend non seulement en charge les onglets, mais peut également organiser les terminaux dans n'importe quel ordre (voir l'image ci-dessous).
Une autre fonctionnalité de Terminator est la possibilité de « regrouper » ces onglets et d'envoyer les mêmes frappes à plusieurs terminaux en même temps, fournissant ainsi un outil rudimentaire pour effectuer des opérations groupées sur plusieurs serveurs simultanément. Une fonctionnalité similaire est également implémentée dans Konsole. Pour utiliser cette fonctionnalité sur d'autres terminaux, vous devez utiliser un logiciel tiers tel que , ou .
Les onglets fonctionnent particulièrement bien lorsqu'ils sont associés à des profils : par exemple, vous pouvez avoir un onglet pour le courrier électronique, un autre pour le chat, etc. Ceci est bien pris en charge par Konsole Terminal et GNOME Terminal. Les deux permettent à chaque onglet de lancer automatiquement son propre profil. Terminator prend également en charge les profils, mais je n'ai pas trouvé de moyen de lancer automatiquement certains programmes lorsque vous ouvrez un onglet spécifique. Les autres terminaux n'ont pas du tout la notion de « profil ».
Froufrous
La dernière chose que j'aborderai dans la première partie de cet article est l'apparence des terminaux. Par exemple, GNOME, Xfce et urxvt prennent en charge la transparence, mais ont récemment abandonné la prise en charge des images d'arrière-plan, obligeant certains utilisateurs à passer au terminal. . Personnellement, j'en suis content et c'est simple Xresources, qui définit l'ensemble de base des couleurs d'arrière-plan pour urxvt. Cependant, les thèmes de couleurs non standard peuvent également créer des problèmes. Par exemple, avec candidatures и , puisqu'ils utilisent déjà leurs propres couleurs.
ne prenait pas en charge les couleurs et les nouvelles étaient souvent limitées à une palette de 256 couleurs. Pour les utilisateurs avancés qui stylisent leurs terminaux, les invites du shell ou les barres d'état de manière complexe peuvent constituer une limitation ennuyeuse. suit quels terminaux prennent en charge "True Color". Mes tests confirment que les terminaux basés sur st, Alacritty et VTE supportent parfaitement True Color. Les autres terminaux ne s'en sortent pas très bien à cet égard et, en fait, n'affichent même pas 256 couleurs. Ci-dessous, vous pouvez voir la différence entre la prise en charge de True Color dans les terminaux GNOME, st et xterm, qui font du bon travail avec leur palette de 256 couleurs, et urxvt, qui non seulement échoue au test, mais affiche même des caractères clignotants à leur place.
Certains terminaux analysent également le texte à la recherche de modèles d'URL afin de rendre les liens cliquables. Cela s'applique à tous les terminaux dérivés de VTE, tandis que urxvt nécessite un plugin spécial qui transformerait les URL en un clic ou en utilisant un raccourci clavier. D'autres terminaux que j'ai testés affichent les URL d'autres manières.
Enfin, une nouvelle tendance dans les terminaux est le caractère facultatif du tampon de défilement. Par exemple, st n'a pas de tampon de défilement ; on suppose que l'utilisateur utilisera un multiplexeur de terminal comme tmux et .
Alacritty manque également de tampons de défilement arrière, mais son soutien en raison des « nombreux commentaires » sur ce sujet de la part des utilisateurs. En dehors de ces nouveaux arrivants, tous les terminaux que j'ai testés et que j'ai pu trouver prennent en charge le défilement inversé.
Sous-totaux
Dans la deuxième partie du matériel (dans l'original, il s'agissait de deux articles différents - env. voie), nous comparerons les performances, l'utilisation de la mémoire et la latence. Mais on constate déjà que certains des terminaux en question présentent de sérieuses lacunes. Par exemple, les utilisateurs qui travaillent régulièrement avec des scripts RTL voudront peut-être envisager mlterm et pterm, car ils sont plus à même de gérer des tâches similaires que d'autres. Konsole a également bien performé. Les utilisateurs qui ne travaillent pas avec des scripts RTL peuvent choisir autre chose.
En termes de protection contre l'insertion de code malveillant, urxvt se distingue par son implémentation particulière de protection contre ce type d'attaque, ce qui me semble tout à fait pratique. Pour ceux qui recherchent des fonctionnalités, Konsole vaut le détour. Enfin, il convient de noter que VTE constitue une excellente base pour les terminaux, qui garantit la prise en charge des couleurs, la reconnaissance des URL, etc. À première vue, le terminal par défaut fourni avec votre environnement préféré peut répondre à toutes les exigences, mais laissons cette question ouverte jusqu'à ce que nous comprenions les performances.
Nous continuons la conversation
En général, les performances des terminaux en elles-mêmes peuvent sembler un problème farfelu, mais il s'avère que certains d'entre eux présentent une latence étonnamment élevée pour un logiciel d'un type aussi fondamental. Ensuite, nous examinerons également ce qu'on appelle traditionnellement la « vitesse » (en fait, il s'agit de la vitesse de défilement) et la consommation de mémoire du terminal (avec l'avertissement que ce n'est pas aussi critique aujourd'hui qu'il y a des décennies).
Retardé
Après une étude approfondie des performances du terminal, je suis arrivé à la conclusion que le paramètre le plus important à cet égard est le temps de latence (ping). Dans son article Pavel Fatin a examiné la latence de divers éditeurs de texte et a laissé entendre que les terminaux à cet égard pourraient être plus lents que les éditeurs de texte les plus rapides. C’est cet indice qui m’a finalement amené à effectuer mes propres tests et à rédiger cet article.
Mais qu’est-ce que la latence et pourquoi est-elle si importante ? Dans son article, Fatin le définit comme « le délai entre l'appui sur une touche et la mise à jour de l'écran correspondante » et cite , qui déclare : « Le retard dans le retour visuel sur un écran d’ordinateur a un impact important sur le comportement et la satisfaction du dactylographe. »
Fatin explique que ce ping a des conséquences plus profondes que la simple satisfaction : « la frappe devient plus lente, davantage d’erreurs se produisent et la tension oculaire et musculaire augmente ». En d’autres termes, un retard important peut entraîner des fautes de frappe et également une qualité inférieure du code, car il entraîne une charge cognitive supplémentaire sur le cerveau. Mais ce qui est pire, c'est que le ping "augmente la fatigue oculaire et musculaire", ce qui semble impliquer dans le futur (Apparemment, l'auteur parle de problèmes avec les muscles des yeux, du dos, des bras et, bien sûr, de la vision - env. voie) en raison d'un stress répétitif.
Certains de ces effets sont connus depuis longtemps et les résultats , publié en 1976 dans la revue Ergonomie, a déclaré qu'un délai de 100 millisecondes "altère considérablement la vitesse de frappe". Plus récemment, le guide de l'utilisateur GNOME a introduit en 10 millisecondes, et si vous allez plus loin, alors montre que 1 milliseconde est idéale.
Fatin a effectué ses tests sur des éditeurs de texte ; il a créé un instrument portable appelé que j'ai utilisé pour tester le ping dans les émulateurs de terminaux. Gardez à l'esprit que le test a été réalisé en mode simulation : en réalité, nous devons prendre en compte à la fois la latence des entrées (clavier, contrôleur USB, etc.) et des sorties (tampon de la carte vidéo, moniteur). Selon Fatin, dans les configurations typiques, elle est d'environ 20 ms. Si vous possédez un équipement de jeu, vous pouvez atteindre ce chiffre en seulement 3 millisecondes. Puisque nous disposons déjà d’un matériel aussi rapide, l’application n’a pas besoin d’ajouter sa propre latence. L'objectif de Fatin est de ramener la latence des applications à 1 milliseconde, voire de parvenir à une numérotation sans comme dans .
Voici les résultats de mes mesures, ainsi que certains résultats de Fatin, pour montrer que mon expérience est en accord avec ses tests :
La première chose qui m'a frappé a été le meilleur temps de réponse des programmes plus anciens tels que xterm et mlterm. Avec la pire latence de registre (2,4 ms), ils ont obtenu de meilleurs résultats que le terminal moderne le plus rapide (10,6 ms pour st). Aucun terminal moderne ne descend en dessous du seuil des 10 millisecondes. En particulier, Alacritty ne parvient pas à répondre à la revendication de « l'émulateur de terminal le plus rapide disponible », bien que ses scores se soient améliorés depuis sa première évaluation en 2017. En effet, les auteurs du projet et travaillons à améliorer l'affichage. Il convient également de noter que Vim utilisant GTK3 est un ordre de grandeur plus lent que son homologue GTK2. De là, nous pouvons conclure que GTK3 crée une latence supplémentaire, et cela se reflète dans tous les autres terminaux qui l'utilisent (Terminator, Terminal Xfce4 et Terminal GNOME).
Cependant, les différences peuvent ne pas être perceptibles à l’œil nu. Comme l’explique Fatin, « il n’est pas nécessaire d’être conscient du délai pour que cela ait un effet sur vous ». Fatin met également en garde contre l’écart type : « toute perturbation de la latence (jitter) crée un stress supplémentaire en raison de son imprévisibilité ».
Le graphique ci-dessus est pris sur Debian 9 pur (stretch) avec . Cet environnement produit les meilleurs résultats dans les tests de latence. Il s'avère que GNOME crée un ping supplémentaire de 20 ms pour toutes les mesures. Une explication possible à cela est la présence de programmes avec traitement synchrone des événements d'entrée. Fatin donne un exemple pour un tel cas , ce qui ajoute un délai en traitant tous les événements d'entrée de manière synchrone. Par défaut, GNOME est également livré avec un gestionnaire de fenêtres , qui crée une couche supplémentaire de mise en mémoire tampon, qui affecte le ping et ajoute au moins 8 millisecondes de latence.
Vitesse de défilement
Le test suivant est un test traditionnel de « vitesse » ou de « bande passante », qui mesure la rapidité avec laquelle le terminal peut faire défiler une page tout en affichant de grandes quantités de texte à l'écran. Les mécanismes du test varient ; le test original consistait simplement à générer la même chaîne de texte à l'aide de la commande seq. D'autres tests incluent le test de Thomas E. Dickey (responsable de xterm), qui à plusieurs reprises . Dans une autre revue des performances du terminal utilise une chaîne d'octets aléatoires codée en base32, qui est envoyée au terminal à l'aide de cat. Luu considère qu'un tel test est « une référence aussi inutile qu'on peut l'imaginer » et suggère d'utiliser la réponse du terminal comme mesure principale à la place. Dickey qualifie également son test de trompeur. Cependant, les deux auteurs reconnaissent que la bande passante de la fenêtre du terminal peut constituer un problème. Luu a découvert qu'Emacs Eshell se gelait lors de l'affichage de fichiers volumineux, et Dickey a optimisé le terminal pour éliminer la lenteur visuelle de xtrerm. Ce test a donc encore un certain mérite, mais comme le processus de rendu est très différent d'un terminal à l'autre, il peut également être utilisé comme composant de test pour tester d'autres paramètres.
Ici, nous voyons les rxvt et st devancer la concurrence, suivis par le beaucoup plus récent Alacritty, conçu en mettant l'accent sur la performance. Viennent ensuite Xfce (famille VTE) et Konsole, qui sont presque deux fois plus rapides. Le dernier est xterm, qui est cinq fois plus lent que rxvt. Pendant le test, xterm a également beaucoup ondulé, rendant le texte difficile à voir même s'il s'agissait de la même ligne. Konsole était rapide, mais c'était parfois délicat : l'affichage se figeait de temps en temps, affichant une partie du texte ou ne l'affichant pas du tout. D'autres terminaux affichaient clairement les chaînes, notamment st, Alacritty et rxvt.
Dickey explique que les différences de performances sont dues à la conception des tampons de défilement dans les différents terminaux. Il accuse notamment rxvt et les autres terminaux de « ne pas suivre les règles générales » :
« Contrairement à xterm, rxvt n'a pas tenté d'afficher toutes les mises à jour. S'il prend du retard, il refusera certaines mises à jour pour rattraper son retard. Cela a eu un impact plus important sur la vitesse de défilement apparente que sur l’organisation de la mémoire interne. Un inconvénient était que l'animation ASCII était quelque peu imprécise."
Pour remédier à cette lenteur perçue de xterm, Dickey suggère d'utiliser la ressource , permettant à xterm d'ignorer certaines mises à jour d'écran pour suivre le flux. Mes tests confirment que fastScroll améliore les performances et place xterm à égalité avec rxvt. Il s'agit cependant d'une béquille plutôt rudimentaire, comme l'explique Dickey lui-même : "parfois, xterm - comme la console - semble caler en attendant une nouvelle série de mises à jour d'écran après que certaines aient été supprimées". Dans cette optique, il semble que d’autres terminaux aient trouvé le meilleur compromis entre vitesse et intégrité d’affichage.
La consommation de ressources
Qu'il soit judicieux de considérer la vitesse de défilement comme une mesure de performance, ce test nous permet de simuler la charge sur les terminaux, ce qui nous permet à son tour de mesurer d'autres paramètres tels que l'utilisation de la mémoire ou du disque. Les métriques ont été obtenues en exécutant le test spécifié suivants sous surveillance des processus Python. Il a collecté les données des compteurs pour ru_maxrss, montant ru_oublock и ru_inblock et une simple minuterie.
Dans ce test, le ST occupe la première place avec la consommation moyenne de mémoire la plus faible de 8 Mo, ce qui n'est pas surprenant étant donné que l'idée principale du design est la simplicité. mlterm, xterm et rxvt consomment un peu plus - environ 12 Mo. Un autre résultat notable est Alacritty, qui nécessite 30 Mo pour fonctionner. Il existe ensuite des terminaux de la famille VTE avec des chiffres de 40 à 60 Mo, ce qui est beaucoup. Cette consommation peut s'expliquer par le fait que ces terminaux utilisent des bibliothèques de niveau supérieur, par exemple GTK. Konsole arrive en dernière position avec une énorme consommation de mémoire de 65 Mo lors des tests, même si cela peut être justifié par sa très large gamme de fonctionnalités.
Par rapport aux résultats précédents obtenus il y a dix ans, tous les programmes ont commencé à consommer sensiblement plus de mémoire. Xterm nécessitait auparavant 4 Mo, mais maintenant il nécessite 15 Mo juste au démarrage. On constate une augmentation similaire de la consommation pour rxvt, qui nécessite désormais 16 Mo prêts à l'emploi. Le terminal Xfce occupe 34 Mo, soit trois fois plus qu'auparavant, mais le terminal GNOME ne nécessite que 20 Mo. Bien entendu, tous les tests précédents ont été réalisés sur une architecture 32 bits. Au LCA 2012, Rusty Russell , qu'il existe de nombreuses raisons plus subtiles qui pourraient expliquer l'augmentation de la consommation de mémoire. Cela dit, nous vivons désormais à une époque où nous disposons de gigaoctets de mémoire, nous allons donc nous en sortir d'une manière ou d'une autre.
Cependant, je ne peux m'empêcher de penser qu'allouer plus de mémoire à quelque chose d'aussi fondamental que le terminal est un gaspillage de ressources. Ces programmes devraient être les plus petits des plus petits, devraient pouvoir fonctionner sur n'importe quelle « boîte », même une boîte à chaussures, si jamais nous arrivons au point où ils doivent être équipés de systèmes Linux (et vous savez qu'il en sera ainsi). ) . Mais avec ces chiffres, l'utilisation de la mémoire deviendra un problème à l'avenir dans tout environnement exécutant plusieurs terminaux autres que quelques-uns des plus légers et des plus limités en capacités. Pour compenser cela, GNOME Terminal, Konsole, urxvt, Terminator et Xfce Terminal disposent d'un mode Daemon qui permet de contrôler plusieurs terminaux via un seul processus, limitant leur consommation de mémoire.
Lors de mes tests, je suis arrivé à un autre résultat inattendu concernant la lecture-écriture sur le disque : je m'attendais à ne rien voir du tout ici, mais il s'est avéré que certains terminaux écrivent les données les plus volumineuses sur le disque. Ainsi, la bibliothèque VTE conserve en fait un tampon de défilement sur le disque (cette fonctionnalité , et cela se produit toujours). Mais contrairement aux anciennes implémentations, au moins ces données sont désormais cryptées à l'aide de AES256 GCM (). Mais une question raisonnable se pose : quelle est la particularité de la bibliothèque VTE pour qu'elle nécessite une approche de mise en œuvre aussi non standard...
Conclusion
Dans la première partie de l'article, nous avons constaté que les terminaux basés sur VTE disposent d'un bon ensemble de fonctionnalités, mais nous voyons maintenant que cela entraîne des coûts en termes de performances. Désormais, la mémoire n'est plus un problème car tous les terminaux VTE peuvent être contrôlés via un processus Daemon, ce qui limite leur appétit. Cependant, les systèmes plus anciens qui ont des limitations physiques en termes de quantité de RAM et de tampons du noyau peuvent toujours avoir besoin de versions antérieures de terminaux, car ils consomment beaucoup moins de ressources. Bien que les terminaux VTE aient obtenu de bons résultats lors des tests de débit (défilement), leur latence d'affichage est supérieure au seuil défini dans le guide de l'utilisateur GNOME. Les développeurs VTE devraient probablement en tenir compte. Si l'on tient compte du fait que même pour les utilisateurs Linux novices, la rencontre avec un terminal est inévitable, ils peuvent le rendre plus convivial. Pour les geeks expérimentés, passer du terminal par défaut peut même signifier moins de fatigue oculaire et la possibilité d'éviter de futures blessures et maladies liées au travail dues à de longues sessions de travail. Malheureusement, seuls les anciens xterm et mlterm nous amènent au seuil magique de ping de 10 millisecondes, ce qui est inacceptable pour beaucoup.
Les mesures de référence ont également montré qu'en raison du développement des environnements graphiques Linux, les développeurs ont dû faire un certain nombre de compromis. Certains utilisateurs voudront peut-être consulter les gestionnaires de fenêtres classiques, car ils offrent une réduction significative du ping. Malheureusement, il n'a pas été possible de mesurer la latence pour Wayland : le programme Typometer que j'ai utilisé a été créé pour ce que Wayland est conçu pour empêcher : espionner d'autres fenêtres. J'espère que la composition Wayland fonctionnera mieux que X.org, et j'espère également qu'à l'avenir quelqu'un trouvera un moyen de mesurer la latence dans cet environnement.
Source: habr.com