Quelques mots de notre bureau de traduction : généralement, tout le monde souhaite traduire les matériaux et publications les plus récents, et nous ne faisons pas exception. Mais les terminaux ne se mettent pas à jour chaque semaine. C'est pourquoi nous avons traduit pour vous l'article d'Antoine Bopré, publié au printemps 2018 : malgré un « âge » respectable pour les normes modernes, à notre avis, le contenu n'a absolument pas perdu de sa pertinence. De plus, à l'origine, il s'agit d'une série de deux articles, mais nous avons décidé de les fusionner en un grand post.
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 face à la montée des interfaces graphiques. ont remplacé leurs , qui, à leur tour, étaient une modification de systèmes à cartes perforées et à commutateurs. Les distributions modernes sont livrées avec une multitude d'émulateurs de terminaux de toutes formes et couleurs. Et pendant que beaucoup se contentent du terminal standard fourni par leur environnement de travail, certains utilisent fièrement des logiciels manifestement exotiques pour lancer leur interface ou éditeur de texte préféré. Mais, comme nous le verrons dans cet article, tous les terminaux n'ont pas été créés égaux : ils varient considérablement en termes de fonctionnalité, de taille et de performance.
Certains terminaux présentent des failles de sécurité étonnantes, et la plupart offrent un ensemble de fonctionnalités très différent, de la prise en charge des interfaces à 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, tandis que la seconde évalue la performance.
Voici les terminaux que j'ai examinés :
Peut-être que ce ne sont pas les versions les plus récentes, car je me suis limité aux versions stables au moment de la rédaction de cet article, que j'ai réussi à déployer sur Debian 9 ou Fedora 27. La seule exception est Alacritty. C'est un descendant des terminaux avec accélération GPU et il est écrit dans un langage inhabituel et nouveau pour cette tâche : Rust. J'ai exclu de ma revue les terminaux web (y compris ceux sur ), car des tests préliminaires ont montré leur très faible performance.
Prise en charge de l'unicode
J'ai commencé mes tests avec la prise en charge de l'unicode. Le premier test des terminaux consistait à afficher une ligne concernant l'unicode à partir de : «é, Δ, Й, ק, م, ๗, あ, 叶, 葉 et 말». Ce test simple montre si le terminal peut correctement fonctionner dans le monde entier. Le terminal xterm n'affiche pas le caractère arabe dans la configuration par défaut :
Par défaut, xterm utilise une police « fixe » classique qui, selon , a « une couverture unicode significative depuis 1997 ». Dans cette police, quelque chose se passe qui fait que le caractère s'affiche sous forme de cadre vide et seulement en augmentant la taille du texte à 20 points, le caractère commence enfin à s'afficher correctement. Cependant, ce « patch » casse l'affichage d'autres caractères unicode :
Ces captures d'écran ont été prises sous Fedora 27, car c'est elle qui a donné les meilleurs résultats, contrairement à Debian 9, où certaines anciennes versions de terminaux (en particulier - mlterm) ne pouvaient pas fonctionner correctement avec les polices. Heureusement, cela a été corrigé dans les versions ultérieures.
Maintenant, regardez l'affichage de la ligne dans xterm. En fait, les caractères Mem et le suivant Semitic appartiennent à des scripts d'écriture RTL (), donc techniquement ils doivent être affichés de droite à gauche. Les navigateurs web, comme Firefox 57, gèrent correctement la ligne ci-dessus. Une variante plus simple du texte RTL est le mot «» en hébreu (). indique ce qui suit :
«De nombreux programmes informatiques ne peuvent pas afficher correctement le texte bidirectionnel. Par exemple, le nom hébreu «Sara» se compose des caractères sin (ש) (qui apparaît à droite), puis resh (ר) et enfin hei (ה) (qui doit apparaître à gauche) ».
De nombreux terminaux échouent à ce test : Alacritty, les terminaux dérivés de Gnome et XFCE, urxvt, st et xterm affichent « Sara » à l'envers, comme si nous écrivions ce nom comme « Aras ».
Un autre problème des textes bidirectionnels est qu'ils doivent être alignés d'une certaine manière, surtout lorsqu'il s'agit de mélanger des textes RTL et LTR. Les scripts RTL doivent commencer à droite de la fenêtre du terminal, mais que doit-on faire pour les terminaux qui fonctionnent par défaut avec 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 le collage
La prochaine caractéristique critique que j'ai identifiée pour moi-même est la protection contre le collage. Bien qu'il soit largement connu que des commandes telles que :
$ curl http://example.com/ | shsont des commandes de code d'exécution, peu de gens savent que des commandes cachées peuvent pénétrer dans la console lors du collage depuis un navigateur web, même après une inspection minutieuse. montre brillamment comment une commande apparemment inoffensive :
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitse transforme lors de son collage depuis le site de Horn dans le terminal en un tel désastre :
git clone /dev/null;
clear;
echo -n "Bonjour ";
whoami|tr -d 'n';
echo -e '!nC'était une mauvaise idée. Ne copiez pas de code depuis des sites web que vous ne connaissez pas !
Voici la première ligne de votre /etc/passwd : ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitComment cela fonctionne-t-il ? Le code malveillant est déplacé dans un bloc , qui est déplacé hors de la portée de l'utilisateur par les moyens du CSS.
est explicitement conçu pour neutraliser de telles attaques. Dans ce mode, les terminaux encadrent le texte collé avec une paire de séquences d'échappement spéciales pour informer le shell de l'origine de ce texte. Ainsi, le shell reçoit un signal qu'il peut ignorer les caractères spéciaux que le texte collé pourrait contenir. Tous les terminaux, y compris le vénérable xterm, prennent en charge cette fonction, mais le collage en mode Bracketed nécessite le soutien du shell ou de l'application exécutée sur le terminal. Par exemple, le logiciel utilisant (le même Bash), nécessite un fichier ~ /.inputrc:
set enable-bracketed-paste onMalheureusement, le site de test de Horne montre également comment contourner cette protection à travers le formatage du texte et terminer prématurément l'application du mode Bracketed. Cela fonctionne parce que certains terminaux filtrent incorrectement les séquences d'échappement avant d'ajouter les leurs. Par exemple, je n'ai pas pu réussir mes tests avec Konsole même avec la configuration correcte. .inputrc fichier. Cela signifie que vous pouvez facilement subir des dommages de configuration système dues à une application non prise en charge ou à un shell mal configuré. C'est particulièrement dangereux lorsque vous vous connectez à des serveurs distants, où une configuration soignée est plus rare, surtout si vous avez de nombreuses machines distantes.
Une bonne solution à ce problème est le plugin de confirmation pour le terminal urxvt, qui demande simplement la permission d'insérer tout texte contenant des nouvelles lignes. Je n'ai trouvé aucune option plus sécurisée pour l'attaque textuelle décrite par Horne.
Onglets et profils
Une fonction populaire de nos jours est la prise en charge de l'interface à onglets, que nous définirons comme une fenêtre de terminal contenant plusieurs autres terminaux. Pour différents terminaux, cette fonction varie, et bien que les terminaux traditionnels tels que xterm ne prennent pas en charge les onglets, des incarnations plus modernes du terminal comme Xfce Terminal, GNOME Terminal et Konsole possèdent cette fonctionnalité. Urxvt prend également en charge les onglets, mais uniquement si un plugin est utilisé. Cependant, en ce qui concerne le support des onglets, le leader incontesté est Terminator : non seulement il prend en charge les onglets, mais il peut également disposer les terminaux dans n'importe quel ordre (voir l'image ci-dessous).
Une autre caractéristique de Terminator est la possibilité de 'grouper' ces onglets ensemble et d'envoyer les mêmes frappes de touches à plusieurs terminaux simultanément, ce qui offre un outil brut pour exécuter des opérations en masse sur plusieurs serveurs en même temps. Une fonctionnalité similaire est également disponible dans Konsole. Pour utiliser cette fonctionnalité dans d'autres terminaux, il est nécessaire d'utiliser des logiciels tiers tels que , ou .
Les onglets fonctionnent particulièrement bien avec les profils : par exemple, vous pouvez avoir un onglet pour les e-mails, un autre pour le chat, et ainsi de suite. Cela est bien pris en charge par le terminal Konsole et GNOME Terminal. Les deux permettent à chaque onglet de lancer automatiquement son profil. Terminator prend également en charge les profils, mais je n'ai pas réussi à trouver un moyen de lancer automatiquement des programmes spécifiques lors de l'ouverture d'un onglet particulier. D'autres terminaux n'ont absolument pas la notion de « profil ».
Fronces
La dernière chose que je vais aborder 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 récemment, ils ont abandonné le support des images d'arrière-plan, ce qui a conduit certains utilisateurs à passer à d'autres terminaux. . Personnellement, ça me convient et c'est simplement Xresources, qui établit un ensemble de couleurs de fond de base pour urxvt. Cependant, les thèmes de couleurs non standard peuvent également poser des problèmes. Par exemple, pour les applications et , car elles utilisent déjà leurs propres couleurs.
ne supportait pas la couleur, et les nouveaux étaient souvent limités à une palette de 256 couleurs. Pour les utilisateurs expérimentés qui stylisent leurs terminaux avec des requêtes shell ou des lignes de statut de manière complexe, cela peut devenir une limitation désagréable. suivre quels terminaux prennent en charge la « True Color ». Mes tests confirment que st, Alacritty et les terminaux basés sur VTE supportent très bien la True Color. D'autres terminaux ne s'en sortent pas vraiment bien et en fait ne rendent même pas 256 couleurs. Vous pouvez voir ci-dessous la différence de prise en charge de la True Color entre les terminaux GNOME, st et xterm, qui gèrent plutôt bien cela avec leur palette de 256 couleurs, et urxvt, qui échoue non seulement au test, mais montre même des caractères clignotants à la place.
Certains terminaux analysent également le texte pour détecter les schémas d'URL afin de rendre les liens cliquables. Cela s'applique à tous les terminaux dérivés de VTE, tandis qu'urxvt nécessite un module complémentaire spécial pour transformer les adresses URL par un clic ou via un raccourci clavier. D'autres terminaux que j'ai testés affichent les adresses URL de manières différentes.
Enfin, la nouvelle tendance des terminaux est l'optionnalité du buffer de défilement. Par exemple, dans st, il n'y a pas de buffer de défilement ; il est prévu que l'utilisateur utilise un multiplexeur de terminal, comme tmux et .
Alacritty manque également de buffers de défilement inversé, mais en raison des « nombreux retours » à ce sujet de la part des utilisateurs. En dehors de ces exceptions, chaque terminal que j'ai pu vérifier prend en charge le défilement inversé.
Intermédiaire résultats
Dans la deuxième partie du matériel (dans l'original, il s'agissait de deux articles différents, — note du traducteur.) nous comparerons les performances, l'utilisation de la mémoire et la latence. Mais nous voyons déjà que certains des terminaux examinés présentent des défauts sérieux. Par exemple, les utilisateurs travaillant régulièrement avec des scripts RTL peuvent se tourner vers mlterm et pterm, car ils gèrent ces tâches mieux que les autres. Konsole s'est également bien comporté. Les utilisateurs qui ne travaillent pas avec des scripts RTL peuvent choisir quelque chose d'autre.
En termes de protection contre l'injection de code malveillant, urxvt se distingue par sa mise en œuvre particulière de la protection contre ce type d'attaques, qui me semble définitivement pratique. Ceux qui recherchent des fonctionnalités avancées devraient jeter un œil à Konsole. Enfin, il convient de noter que VTE est une excellente base pour les terminaux, garantissant le support des couleurs, la reconnaissance des URL, etc. À première vue, le terminal par défaut livré avec votre environnement préféré peut répondre à tous les besoins, mais laissons cette question ouverte jusqu'à ce que nous ayons examiné les performances.
Poursuivons la discussion
En général, les performances des terminaux peuvent sembler être un problème artificiel, cependant, il s'avère que certains d'entre eux présentent une latence étonnamment élevée pour un logiciel de ce type fondamental. Nous examinerons également ce que l'on appelle traditionnellement la « vitesse » (en réalité, il s'agit de la vitesse de défilement) et la consommation de mémoire par le terminal (en tenant compte du fait qu'aujourd'hui cela n'est pas aussi critique qu'il y a des décennies).
Latence
Après une étude approfondie des performances des terminaux, je suis arrivé à la conclusion que le facteur le plus important à cet égard est la taille de la latence (ping). Dans mon article Pavel Fatin a examiné le délai des différents éditeurs de texte et a suggéré que les terminaux, à cet égard, pouvaient fonctionner plus lentement que les éditeurs de texte les plus rapides. C'est cette suggestion qui m'a conduit, finalement, à lancer mes propres tests et à rédiger cet article.
Mais qu'est-ce que le délai et pourquoi est-il si important ? Dans son article, Fatin le définit comme « le délai entre l'appui sur une touche et la mise à jour correspondante de l'écran » et cite , qui affirme : « Le délai de retour visuel sur l'écran de l'ordinateur a une influence significative sur le comportement de la dactylo et sa satisfaction ».
Fatin explique que ce ping a des conséquences plus profondes que la simple satisfaction : « taper devient plus lent, il y a plus d'erreurs, et la tension des yeux et des muscles augmente ». En d'autres termes, un délai plus long peut entraîner des fautes de frappe ainsi qu'une diminution de la qualité du code, car il impose une charge cognitive supplémentaire au cerveau. Mais ce qui est encore pire, c'est que le ping « augmente la tension des yeux et des muscles », ce qui, apparemment, implique à l'avenir (apparemment, l'auteur fait référence à des problèmes liés aux muscles des yeux, du dos, des mains et, bien sûr, de la vue, - note de traduction.) en raison de la tension répétée.
Certains de ces effets sont connus depuis longtemps, et les résultats , publiés en 1976 dans le journal Ergonomics, indiquent qu'un délai de 100 millisecondes « dégrade considérablement la vitesse de frappe ». Plus récemment, le guide de l'utilisateur GNOME a établi à 10 millisecondes, et si nous allons plus loin, montre que l'idéal est de 1 milliseconde.
Fatin a mené ses tests sur des éditeurs de texte ; il a créé un outil portatif appelé , que j'ai utilisé pour vérifier le ping dans les émulateurs de terminal. Gardez à l'esprit que le test a été effectué en mode simulation : en réalité, nous devons prendre en compte à la fois la latence d'entrée (clavier, contrôleur USB, etc.) et de sortie (tampon de la carte graphique, moniteur). Selon Fatin, dans les configurations typiques, cela tourne autour de 20 ms. Avec du matériel gamer, il est possible d'atteindre une latence de seulement 3 millisecondes. Puisque nous avons déjà un tel matériel rapide, l'application ne devrait pas ajouter de latence supplémentaire. L'objectif de Fatin est de ramener la latence de l'application à 1 milliseconde, voire d'atteindre un ensemble sans , comme dans .
Voici les résultats de mes mesures, ainsi que certains résultats de Fatin pour montrer que mon expérience concorde avec ses tests :
La première chose qui m'a frappé, c'est le meilleur temps de réponse des anciens programmes, comme xterm et mlterm. Avec la latence de registre la plus élevée (2,4 ms), ils ont montré 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 de 10 millisecondes. En particulier, Alacritty ne répond pas aux exigences de « le plus rapide des émulateurs de terminal existants », bien que ses résultats se soient améliorés depuis le premier contrôle en 2017. En effet, les auteurs du projet et travaillent à améliorer l'affichage. Il convient également de noter que Vim, utilisant GTK3, est de manière significative plus lent que son équivalent GTK2. On peut en conclure que GTK3 introduit une latence supplémentaire, et cela se reflète dans tous les autres terminaux qui l'utilisent (Terminator, Xfce4 Terminal et GNOME Terminal).
Cependant, pour l'œil, les différences peuvent être imperceptibles. Comme l'explique Fatin : « il n'est pas nécessaire d'être conscient de la latence pour qu'elle ait un effet sur vous ». Fatin avertit également sur l'écart type : « toute variation dans la durée de la latence (tremblement) crée une charge supplémentaire en raison de son imprévisibilité. »
Le graphique ci-dessus a été obtenu sur Debian 9 (stretch) pur avec . Cet environnement donne les meilleurs résultats dans les tests de latence. Il s'avère que GNOME ajoute un ping supplémentaire de 20 ms pour toutes les mesures. Une explication possible à cela est la présence de programmes traitant les événements d'entrée de manière synchrone. Fatin prend cet exemple pour un tel cas. , qui ajoute un délai en traitant tous les événements d'entrée de manière synchrone. Par défaut, GNOME est également équipé d'un gestionnaire de fenêtres , qui crée un niveau supplémentaire de mise en mémoire tampon, ce qui affecte le ping et ajoute au moins 8 millisecondes de latence.
Vitesse de défilement
Le test suivant est une vérification traditionnelle de la « vitesse » ou de la « bande passante », qui mesure à quelle vitesse le terminal peut faire défiler une page, affichant une grande quantité de texte à l'écran. La mécanique du test varie ; 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. Dick (accompagnant xterm), dans lequel un fichier terminfo.src est régulièrement Dans une autre revue de performance des terminaux, utilise une chaîne de bytes aléatoires en codage base32 qui est affichée dans le terminal avec cat. Liu considère ce test comme « un étalon tellement inutile qu’on peut l’imaginer » et propose d’utiliser à la place la réactivité du terminal comme principal indicateur. Dick qualifie également son test de trompeur. Néanmoins, les deux auteurs reconnaissent que la bande passante de la fenêtre du terminal peut poser problème. Liu a constaté un gel d'Emacs Eshell lors de l'affichage de fichiers volumineux, tandis que Dick a optimisé le terminal pour éliminer la lenteur visuelle d'xterm. Par conséquent, ce test a encore un certain intérêt, mais comme le processus de rendu varie considérablement d’un terminal à l’autre, il peut également être utilisé comme un composant de test pour vérifier d'autres paramètres.
Ici, nous voyons que rxvt et st se démarquent des concurrents, suivis de près par le bien plus récent Alacritty, qui est développé avec une focalisation sur la rapidité. Ensuite, nous avons Xfce (famille VTE) et Konsole, qui fonctionnent presque deux fois plus vite. Enfin, xterm arrive en dernier, avec une performance cinq fois plus lente que rxvt. Pendant le test, xterm avait également une forte rémanence ; le texte défilant était difficile à distinguer, même s'il s'agissait de la même ligne. Konsole s'est montré rapide, mais affichait parfois un comportement « capricieux » : l'affichage se figeait de temps en temps, montrant le texte partiellement ou ne l'affichant pas du tout. D'autres terminaux affichaient les lignes clairement, y compris st, Alacritty et rxvt.
Diki explique que les différences de performance sont liées à la conception des tampons de défilement dans différents terminaux. En particulier, il reproche à rxvt et à d'autres terminaux de ne « pas suivre les règles générales » :
« Contrairement à xterm, rxvt ne tente pas d'afficher toutes les mises à jour. S'il accuse du retard, il abandonne 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 inexacte. »
Pour corriger cette lenteur apparente d'xterm, Diki propose d'utiliser la ressource , qui permet à xterm de rejeter certaines mises à jour d'écran afin de ne pas perdre le fil. Mes tests confirment que fastScroll améliore les performances et place xterm au même niveau que rxvt. Cela dit, c'est un correctif assez grossier, comme l'explique Diki lui-même : « parfois, xterm — tout comme konsole — semble se figer, car il attend un nouvel ensemble de mises à jour d'écran après que certaines d'entre elles ont été supprimées. » Dans ce sens, il semble que d'autres terminaux aient trouvé le meilleur compromis entre vitesse et intégrité de l'affichage.
Consommation des ressources
Indépendamment de la pertinence de considérer la vitesse de défilement comme un indicateur de performance, ce test permet de simuler une 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 indiqué seq sous la surveillance d'un processus Python. Il a collecté les données des compteurs pour ru_maxrss, le total ru_oublock et ru_inblock et un simple chronomètre.
Dans ce test, ST se classe premier avec une consommation moyenne de mémoire de 8 Mo, ce qui n'est pas surprenant compte tenu que l'idée principale du projet 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. Ensuite viennent les terminaux de la famille VTE avec une consommation variant de 40 à 60 Mo, ce qui est assez élevé. Cette consommation peut s'expliquer par le fait que ces terminaux utilisent des bibliothèques de niveau supérieur, comme GTK. Konsole arrive en dernière position avec une consommation énorme de 65 Mo de mémoire pendant les tests, bien que cela puisse être justifié par son large éventail de fonctionnalités.
Comparé aux résultats précédents obtenus il y a dix ans, tous les programmes consomment maintenant beaucoup plus de mémoire. Auparavant, Xterm nécessitait 4 Mo, et maintenant il en faut 15 juste pour se lancer. Une augmentation similaire de la consommation est constatée avec rxvt, qui nécessite maintenant 16 Mo dès l'installation. Le terminal Xfce occupe 34 Mo, soit trois fois plus qu'avant, tandis que GNOME Terminal nécessite seulement 20 Mo. Bien sûr, tous les tests précédents ont été réalisés sur une architecture 32 bits. Lors de l'LCA 2012, Rusty Russell , il existe de nombreuses raisons plus subtiles qui peuvent expliquer l'augmentation de la consommation de mémoire. Cela dit, nous vivons actuellement à une époque où nous disposons de plusieurs gigaoctets de mémoire, donc nous nous en sortirons d'une manière ou d'une autre.
Néanmoins, je ne peux m'empêcher de penser qu'allouer davantage de mémoire à un logiciel fondamental comme un terminal est un gaspillage de ressources. Ces programmes devraient être les plus légers parmi les plus légers, capables de fonctionner sur n'importe quelle "boîte", même une boîte à chaussures, si jamais nous en venons à les équiper de systèmes Linux (et vous savez que cela arrivera). Mais avec ces chiffres, l'utilisation de la mémoire posera un problème dans le futur dans n'importe quel environnement lors du lancement de plusieurs terminaux, à l'exception de la situation avec quelques-uns des terminaux les plus légers et aux capacités limitées. Pour compenser cela, GNOME Terminal, Konsole, urxvt, Terminator et Xfce Terminal disposent d'un mode Daemon, qui permet de gérer plusieurs terminaux à travers un seul processus, ce qui limite leur consommation de mémoire.
Au cours de mes tests, j'ai découvert un autre résultat inattendu concernant la lecture et l'écriture sur disque : je ne m'attendais à rien ici, mais il s'avère que certains terminaux écrivent les données les plus volumineuses sur le disque. Ainsi, la bibliothèque VTE maintient en fait un tampon de défilement sur le disque (cette caractéristique , et cela se produit encore aujourd'hui). Mais contrairement aux anciennes implémentations, maintenant, au moins, ces données sont chiffrées avec AES256 GCM (). Mais une question légitime se pose : qu'est-ce qui est si particulier dans la bibliothèque VTE qu'elle nécessite une approche aussi non standard pour son implémentation…
Conclusion
Dans la première partie de l'article, nous avons découvert que les terminaux basés sur VTE ont un bon ensemble de fonctionnalités, mais nous voyons maintenant que cela implique certains coûts pour assurer leur performance. Actuellement, la mémoire n'est pas un problème, car tous les terminaux VTE peuvent être gérés via un processus Daemon, qui limite leur appétit. Cependant, les anciens systèmes, ayant des limitations physiques sur la quantité de mémoire vive et le tampon du noyau, peuvent encore avoir besoin d'anciennes versions de terminaux, car elles consomment significativement moins de ressources. Bien que les terminaux VTE aient bien performé lors des tests de bande passante (défilement), leur latence d'affichage des données à l'écran dépasse le seuil établi dans le manuel de l'utilisateur GNOME. Il est probable que les développeurs de VTE devraient en tenir compte. Si l'on considère que même pour les utilisateurs débutants de Linux, la rencontre avec le terminal est inévitable, ils pourraient le rendre plus convivial. Pour les geeks expérimentés, passer à un terminal par défaut peut même signifier une réduction de la charge visuelle et éviter des blessures professionnelles et maladies à l'avenir à cause de longues sessions de travail. Malheureusement, seuls les anciens xterm et mlterm nous amènent à ce seuil magique de ping de 10 millisecondes, ce qui est inacceptable pour beaucoup.
Les mesures de contrôle ont également montré qu'en raison du développement des environnements graphiques Linux, les développeurs ont dû faire plusieurs compromis. Certains utilisateurs devraient se tourner vers des gestionnaires de fenêtres classiques, car ils permettent une réduction significative du ping. Malheureusement, il n’a pas été possible de mesurer la latence pour Wayland : le programme Typometer, que j'utilisais, a été conçu pour ce que Wayland se propose de prévenir - l'espionnage des autres fenêtres. J'espère que le compositing de Wayland est plus performant que celui de X.org, et j'espère également qu'à l'avenir, quelqu'un trouvera un moyen d'évaluer le niveau de latence dans cet environnement.
Source : habr.com
