Ein paar Worte von unserem Übersetzungsbüro: Üblicherweise streben alle danach, die aktuellsten Materialien und Publikationen zu übersetzen, und wir sind da keine Ausnahme. Aber Terminals sind nicht etwas, das wöchentlich aktualisiert wird. Daher haben wir den Artikel von Antoine Beaupré übersetzt, der im Frühjahr 2018 veröffentlicht wurde. Trotz eines für moderne Verhältnisse "hohen Alters" hat das Material unserer Meinung nach nicht an Relevanz verloren. Außerdem handelt es sich im Original um eine Reihe von zwei Artikeln, aber wir haben beschlossen, sie in einem großen Beitrag zusammenzufassen.
Terminals nehmen einen besonderen Platz in der Computergeschichte ein, aber in den letzten Jahrzehnten waren sie "gezwungen", zusammen mit der Kommandozeile zu überleben, während grafische Benutzeroberflächen zunehmend Verbreitung fanden. haben ihre , die ihrerseits Modifikationen von Systemen auf Lochkarten und Relais waren. Moderne Distributionen kommen mit einer Vielzahl von Terminalemulatoren in allen Formen und Farben. Während viele einfach mit dem Standardterminal zufrieden sind, das ihre Arbeitsumgebung bietet, nutzen einige stolz ganz exotische Software, um ihre bevorzugte Shell oder Texteditor zu starten. Aber wie wir in diesem Artikel sehen werden, wurden nicht alle Terminals gleich geschaffen: Sie unterscheiden sich stark in Funktionalität, Größe und Leistung.
Einige Terminals weisen direkt erstaunliche Sicherheitslücken auf, zudem verfügt die Mehrheit über völlig unterschiedliche Funktionssätze, von der Unterstützung für Tab-Interfaces bis hin zu Skripten. Obwohl wir , ist dieser Artikel eine Aktualisierung des vorherigen Materials, das den Lesern helfen wird, herauszufinden, welcher Terminal im Jahr 2018 verwendet werden sollte. In der ersten Hälfte des Artikels werden die Funktionen verglichen, während in der zweiten die Leistung bewertet wird.
Hier sind die von mir betrachteten Terminals:
Möglicherweise sind dies nicht die neuesten Versionen, da ich mich auf stabile Builds beschränkt habe, die ich zum Zeitpunkt des Schreibens des Materials auf Debian 9 oder Fedora 27 verwenden konnte. Die einzige Ausnahme ist Alacritty. Es ist ein Nachfolger von GPU-beschleunigten Terminals und wurde in einer für diese Aufgabe ungewöhnlichen und neuen Sprache – Rust – geschrieben. Ich habe webbasierte Terminals (einschließlich der auf ) ausgeschlossen, da erste Tests ihre extrem geringe Leistung gezeigt haben.
Unicode-Unterstützung
Ich begann meine Tests mit der Unterstützung von Unicode. Der erste Test der Terminals war die Darstellung einer Zeile über Unicode aus : "é, Δ, Й, ק, م, ๗, あ, 叶, 葉 und 말". Dieser einfache Test zeigt, ob das Terminal weltweit korrekt arbeiten kann. Das Terminal xterm zeigt das arabische Zeichen in der Standardkonfiguration nicht an:
Standardmäßig verwendet xterm die klassische "Fixed"-Schriftart, die, laut , "seit 1997 einen erheblichen Unicode-Support" hat. In dieser Schriftart geschieht etwas, das dazu führt, dass Zeichen als leere Kästchen dargestellt werden, und erst bei einer Vergrößerung der Schriftgröße auf über 20 Punkte beginnt das Zeichen richtig angezeigt zu werden. Allerdings verursacht dieser "Fix" andere Unicode-Zeichen darzustellen:
Diese Screenshots wurden in Fedora 27 aufgenommen, da diese die besten Ergebnisse lieferte, während Debian 9, wo einige alte Versionen von Terminals (insbesondere mlterm) nicht ordnungsgemäß mit Schriften arbeiten konnten, weniger gut abschnitt. Glücklicherweise wurde dies in späteren Versionen behoben.
Beachten Sie nun die Darstellung der Zeile in xterm. Es stellte sich heraus, dass das Zeichen Mem und das folgende semitische zu den RTL-Schriftsystemen gehören (), weshalb sie technisch gesehen von rechts nach links angezeigt werden sollten. Webbrowser wie Firefox 57 verarbeiten die obige Zeile korrekt. Eine einfachere Form von RTL-Text ist das Wort "" auf Hebräisch (). besagt Folgendes:
"Viele Computerprogramme können bidirektionalen Text nicht korrekt darstellen. Zum Beispiel besteht der hebräische Name 'Sara' aus den Zeichen Sin (ש) (das rechts erscheint), dann Resh (ר) und schließlich He (ה) (das links erscheinen sollte)".
Viele Terminals bestehen diesen Test nicht: Alacritty, Gnome- und XFCE-basierte VTE-Terminals, urxvt, st und xterm zeigen „Сара“ in umgekehrter Reihenfolge an, als ob wir diesen Namen als „Арас“ notiert haben.
Ein weiteres Problem bei bidirektionalen Texten ist, dass sie irgendwie ausgerichtet werden müssen, insbesondere wenn es um die Mischung von RTL- und LTR-Texten geht. RTL-Skripte sollten von der rechten Seite des Terminalfensters ausgeführt werden, aber was ist mit Terminals, die standardmäßig mit LTR-Englisch arbeiten? Die meisten von ihnen haben keine speziellen Mechanismen und richten den gesamten Text linksbündig aus (einschließlich Konsole). Eine Ausnahme bilden pterm und mlterm, die sich an die Standards halten und solche Zeilen rechtsbündig ausrichten.
Einfügeschutz
Ein weiteres kritisches Merkmal, das ich für mich definiert habe, ist der Einfügeschutz. Es ist allgemein bekannt, dass Befehle wie:
$ curl http://example.com/ | shausführbare Code-Push-Befehle sind, aber nur wenige wissen, dass versteckte Befehle beim Kopieren und Einfügen aus dem Webbrowser in die Konsole gelangen können, selbst nach sorgfältiger Prüfung. zeigt eindrucksvoll, wie scheinbar harmlose Befehle:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitbeim Einfügen von Хорн's Website ins Terminal in so einen Schlamassel verwandelt werden:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nDas war eine schlechte Idee. Kopiere keinen Code von Websites, denen du nicht vertraust!
Hier ist die erste Zeile deiner /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitWie funktioniert das? Schadhafter Code wird in einen Block , der mit CSS aus dem Sichtfeld des Benutzers verschoben wird.
ist ausdrücklich dazu gedacht, solche Angriffe zu neutralisieren. In diesem Modus umschließen Terminals den eingefügten Text mit einem Paar spezieller Escape-Sequenzen, um der Shell die Herkunft dieses Textes mitzuteilen. So erhält die Shell das Signal, dass sie spezielle Zeichen ignorieren kann, die der eingefügte Text enthalten kann. Alle Terminals, selbst das ehrwürdige xterm, unterstützen diese Funktion, aber das Einfügen im Bracketed-Modus erfordert Unterstützung durch die Shell oder die Anwendung, die im Terminal ausgeführt wird. Zum Beispiel benötigt Software, die (dieselbe Bash), eine Datei ~ /.inputrc:
set enable-bracketed-paste onLeider zeigt die Testseite von Horn auch, wie man diesen Schutz durch die Formatierung des Textes umgehen kann und vorzeitig die Anwendung des Bracketed-Modus beenden kann. Das funktioniert, weil einige Terminals Escape-Sequenzen vor dem Hinzufügen ihrer eigenen nicht korrekt filtern. Zum Beispiel konnte ich in meinen Tests Konsole nicht erfolgreich abschließen, selbst bei korrekter Konfiguration. .inputrc Datei. Das bedeutet, dass Sie aufgrund inkompatibler Anwendungen oder einer falsch konfigurierten Shell leicht Systemkonfigurationsschäden verursachen können. Dies ist besonders gefährlich, wenn Sie sich auf Remote-Server einloggen, wo eine sorgfältige Konfiguration seltener anzutreffen ist, insbesondere wenn Sie viele solcher entfernten Maschinen haben.
Eine gute Lösung für dieses Problem ist das Plugin zur Bestätigung des Einfügens für das Terminal urxvt, das einfach um Erlaubnis bittet, um jeden Text einzufügen, der Zeilenumbrüche enthält. Eine sicherere Variante gegen den von Horn beschriebenen Textangriff habe ich nicht gefunden.
Tabs und Profile
Eine derzeit beliebte Funktion ist die Unterstützung einer Schnittstelle mit Tabs, die wir als ein Terminalfenster definieren werden, das mehrere Terminals enthält. Diese Funktion unterscheidet sich zwischen verschiedenen Terminals, und während traditionelle Terminals wie xterm überhaupt keine Tabs unterstützen, haben modernere Terminalinkarnationen wie Xfce Terminal, GNOME Terminal und Konsole diese Funktion. Auch Urxvt unterstützt Tabs, jedoch nur, wenn das Plugin verwendet wird. Aber hinsichtlich der Tabunterstützung ist Terminator der unbestrittene Führer: Es unterstützt nicht nur Tabs, sondern kann auch Terminals beliebig anordnen (siehe Bild unten).
Eine weitere Funktion von Terminator ist die Möglichkeit, diese Tabs „zu gruppieren“ und dieselben Tasteneingaben gleichzeitig an mehrere Terminals zu senden, was ein grobes Werkzeug für die Durchführung von Massenvorgängen auf mehreren Servern gleichzeitig bereitstellt. Eine ähnliche Funktion ist auch in Konsole implementiert. Um diese Funktion in anderen Terminals zu nutzen, ist es notwendig, Software von Drittanbietern zu verwenden, wie zum Beispiel , oder .
Besonders gut funktionieren Tabs in Kombination mit Profilen: Zum Beispiel können Sie einen Tab für E-Mails, einen anderen für den Chat usw. haben. Dies wird gut vom Konsole- und GNOME-Terminal unterstützt. Beide ermöglichen es, dass jeder Tab automatisch mit seinem eigenen Profil gestartet wird. Terminator unterstützt ebenfalls Profile, aber ich konnte keinen Weg finden, bestimmte Programme automatisch zu starten, wenn ein bestimmter Tab geöffnet wird. Andere Terminal-Programme haben überhaupt kein Konzept von "Profilen".
Rüschen
Das Letzte, was ich im ersten Teil dieses Artikels betrachten möchte, ist das Aussehen von Terminals. Beispielsweise unterstützen GNOME, Xfce und urxvt Transparenz, haben aber kürzlich die Unterstützung für Hintergrundbilder eingestellt, was einige Benutzer dazu veranlasst hat, zu einem Terminal zu wechseln. . Persönlich finde ich es auch einfach. Xresources, das eine Grundfarbpalette für den Hintergrund von urxvt festlegt. Allerdings können benutzerdefinierte Farbschemata ebenfalls Probleme verursachen. Zum Beispiel, mit Anwendungen und , da sie bereits ihre eigenen Farben verwenden.
unterstützte keine Farben, und neuere waren oft auf eine 256-Farben-Palette beschränkt. Für erfahrene Benutzer, die ihre Terminals mit komplexen Anfragen oder Statuszeilen gestalten, kann dies eine unangenehme Einschränkung darstellen. verfolgt, welche Terminals Unterstützung für "True Color" haben. Meine Tests bestätigen, dass st, Alacritty und VTE-basierte Terminals True Color hervorragend unterstützen. Andere Terminals haben diesbezüglich eher schlechte Erfahrungen gemacht und zeigen nicht einmal 256 Farben an. Unten können Sie den Unterschied in der Unterstützung von True Color zwischen GNOME, st und xterm sehen, die diese Aufgabe mit ihrer 256-Farben-Palette gut bewältigen, und urxvt, das nicht nur den Test nicht besteht, sondern auch einige flackernde Symbole anzeigt.
Einige Terminals analysieren auch den Text auf URL-Muster, um Links klickbar zu machen. Dies gilt für alle von VTE abgeleiteten Terminals, während urxvt ein spezielles Plugin benötigt, das die URLs durch einen Klick oder eine Tastenkombination umwandelt. Andere Terminals, die ich getestet habe, zeigen die URLs auf andere Weise an.
Schließlich ist der neue Trend bei Terminals die Option auf einen Scrollpuffer. Zum Beispiel gibt es in st keinen Scrollpuffer; es wird angenommen, dass der Benutzer einen Terminal-Multiplexer wie tmux verwendet und .
In Alacritty fehlen ebenfalls Rückscroll-Puffer, jedoch aufgrund des "umfangreichen Feedbacks" der Benutzer zu diesem Thema. Abgesehen von diesen Ausreißern unterstützen alle getesteten Terminals, die ich finden konnte, Rückscrolling.
Zwischenstand
Im zweiten Teil des Materials (im Original waren das zwei verschiedene Artikel, Anm. d. Übers.) vergleichen wir die Leistung, den Speicherverbrauch und die Latenz. Aber wir sehen bereits, dass einige der betrachteten Terminals ernsthafte Mängel aufweisen. Zum Beispiel können Benutzer, die regelmäßig mit RTL-Skripten arbeiten, auf mlterm und pterm achten, da sie solche Aufgaben besser bewältigen als andere. Auch Konsole hat sich gut geschlagen. Benutzer, die nicht mit RTL-Skripten arbeiten, können etwas anderes wählen.
Aus Sicht des Schutzes vor Malware sticht urxvt aufgrund seiner speziellen Implementierung zum Schutz vor dieser Art von Angriffen hervor, die ich als definitiv praktisch empfinde. Wer nach Funktionen sucht, sollte sich Konsole ansehen. Schließlich ist VTE eine hervorragende Basis für Terminals, die Unterstützung für Farben, die Erkennung von URLs usw. garantiert. Auf den ersten Blick kann das Standardterminal, das mit Ihrer bevorzugten Umgebung geliefert wird, alle Anforderungen erfüllen, aber wir lassen diese Frage offen, bis wir die Leistung geklärt haben.
Wir setzen das Gespräch fort
Im Allgemeinen mag die Leistung von Terminals wie eine erfundene Problematik erscheinen, jedoch zeigen einige von ihnen überraschend hohe Latenzen für so grundlegende Software. Außerdem werden wir uns mit dem beschäftigen, was traditionell als "Geschwindigkeit" bezeichnet wird (eigentlich ist es die Scrollgeschwindigkeit) und dem Speicherverbrauch des Terminals (mit der Überlegung, dass dies heute nicht so kritisch ist wie vor Jahrzehnten).
Latenz
Nach eingehender Untersuchung der Leistung von Terminals bin ich zu dem Schluss gekommen, dass die wichtigste Kennzahl in dieser Hinsicht die Größe der Latenz (Ping) ist. In meinem Artikel Pavel Fatin hat die Verzögerung verschiedener Texteditoren untersucht und angedeutet, dass Terminals in dieser Hinsicht möglicherweise langsamer arbeiten als die schnellsten Texteditoren. Genau dieser Hinweis führte mich schließlich dazu, eigene Tests durchzuführen und diesen Artikel zu schreiben.
Aber was ist Verzögerung und warum ist sie so wichtig? In seinem Artikel definiert Fatin sie als „die Verzögerung zwischen dem Drücken einer Taste und der entsprechenden Aktualisierung des Bildschirms“ und zitiert , in dem steht: „Die Verzögerung bei der visuellen Rückmeldung auf dem Computerbildschirm hat einen wichtigen Einfluss auf das Verhalten des Benutzers und dessen Zufriedenheit.“
Fatin erklärt, dass ein solches Ping tiefere Konsequenzen hat als nur die Zufriedenheit: „Das Tippen wird langsamer, es treten mehr Fehler auf, die Augen- und Muskelverspannungen nehmen zu.“ Mit anderen Worten, eine größere Verzögerung kann zu Tippfehlern führen sowie die Qualität des Codes mindern, da sie eine zusätzliche kognitive Belastung für das Gehirn mit sich bringt. Doch noch schlimmer ist, dass das Ping „die Augen- und Muskelverspannungen erhöht“, was offenbar darauf hindeutet in der Zukunft (offensichtlich meint der Autor Probleme mit Augen- und Rückenmuskulatur, Händen und natürlich dem Sehen - Anmerkung des Übersetzers.) aufgrund wiederholter Belastungen.
Einige dieser Effekte sind schon lange bekannt, und die Ergebnisse des , die bereits 1976 in der Zeitschrift Ergonomics veröffentlicht wurden, zeigen, dass eine Verzögerung von 100 Millisekunden „die Tippgeschwindigkeit erheblich beeinträchtigt“. Vor kurzem wurde im Benutzerhandbuch von GNOME eine von 10 Millisekunden festgelegt, und wenn man noch weiter geht, zeigt , dass das Ideal bei 1 Millisekunde liegt.
Fatin führte seine Tests an Texteditoren durch; er entwickelte ein tragbares Tool namens , den ich zur Überprüfung des Pings in Terminalemulatoren verwendet habe. Bitte beachten Sie, dass der Test im Simulationsmodus durchgeführt wurde: In der Realität müssen wir auch die Eingangsverzögerung (Tastatur, USB-Controller usw.) und die Ausgangsverzögerung (Grafikkartenpuffer, Monitor) berücksichtigen. Laut Fatin beträgt sie in typischen Konfigurationen etwa 20 ms. Mit Gamer-Hardware können Werte von nur 3 Millisekunden erreicht werden. Da wir bereits über solch schnelle Geräte verfügen, sollte die Anwendung keine zusätzliche Verzögerung einführen. Fatins Ziel ist es, die Verzögerung der Anwendung auf 1 Millisekunde zu bringen oder sogar gänzlich ohne auskommend zu erreichen. , wie bei .
Hier sind die Ergebnisse meiner Messungen sowie einige Resultate von Fatin, um zu zeigen, dass mein Experiment mit seinen Tests übereinstimmt:
Das Erste, was mich überraschte, war die bessere Reaktionszeit bei älteren Programmen wie xterm und mlterm. Trotz der schlechteren Eingangsverzögerung (2,4 ms) erzielten sie bessere Ergebnisse als der schnellste moderne Terminal (10,6 ms für st). Kein moderner Terminal erreicht Werte unter 10 Millisekunden. Insbesondere erfüllt Alacritty nicht die Anforderungen an den 'schnellsten aller existierenden Terminalemulatoren', obwohl sich seine Ergebnisse seit der ersten Überprüfung im Jahr 2017 verbessert haben. In der Tat sind die Autoren des Projekts und arbeiten an der Verbesserung der Darstellung. Es ist auch wichtig zu erwähnen, dass Vim, das GTK3 verwendet, um ein Vielfaches langsamer ist als sein GTK2-Ableger. Daraus kann man schließen, dass GTK3 eine zusätzliche Verzögerung verursacht, die sich auf alle anderen Terminals auswirkt, die es verwenden (Terminator, Xfce4 Terminal und GNOME Terminal).
Für das Auge sind die Unterschiede jedoch möglicherweise nicht wahrnehmbar. Wie Fatin erklärt: 'Es ist nicht zwingend notwendig, sich der Verzögerung bewusst zu sein, damit sie einen Einfluss auf Sie hat.' Fatin warnt auch vor der Standardabweichung: 'Jede Variation in der Dauer der Verzögerung (Ruckeln) erzeugt eine zusätzliche Belastung aufgrund ihrer Unvorhersehbarkeit.'
Das obige Diagramm wurde auf reinem Debian 9 (stretch) mit . Diese Umgebung erzielt die besten Ergebnisse bei Latenztests. Wie sich herausstellte, erzeugt GNOME einen zusätzlichen Ping von 20 ms für alle Messungen. Eine mögliche Erklärung dafür ist die Anwesenheit von Programmen mit synchroner Verarbeitung von Eingabeveranstaltungen. Fatin nennt in diesem Fall ein Beispiel. , das Verzögerungen hinzufügt, indem es alle Eingabeereignisse synchron verarbeitet. Standardmäßig ist GNOME auch mit einem Fenstermanager , ausgestattet, der eine zusätzliche Pufferungsebene erstellt, was sich auf den Ping auswirkt und mindestens 8 Millisekunden Verzögerung hinzufügt.
Bildlaufgeschwindigkeit
Der nächste Test ist ein traditioneller Test der „Geschwindigkeit“ oder „Bandbreite“, der misst, wie schnell das Terminal eine Seite scrollen kann, während es eine große Menge an Text auf dem Bildschirm anzeigt. Die Mechanik des Tests variiert; der ursprüngliche Test bestand darin, einfach dieselbe Textzeile mit dem Befehl seq zu erzeugen. Andere Tests umfassen die Überprüfung von Thomas E. Dick, bei dem mehrfach ausgelagert wird. In einer weiteren Leistungsübersicht von Terminals verwendet eine Reihe zufälliger Bytes in Base32-Codierung, die mit cat im Terminal ausgegeben wird. Liu betrachtet diesen Test als „so nutzlosen Maßstab, wie man sich nur vorstellen kann“ und schlägt vor, stattdessen die Reaktionszeit des Terminals als Hauptindikator zu verwenden. Dick bezeichnet auch seinen Test als irreführend. Dennoch erkennen beide Autoren an, dass die Bandbreite des Terminalfensters problematisch sein kann. Liu stellte ein Hängenbleiben von Emacs Eshell bei großen Dateien fest, während Dick das Terminal optimierte, um visuelle Verzögerungen von xterm zu beseitigen. Daher hat dieser Test immer noch einen gewissen Sinn, aber da der Renderprozess von Terminal zu Terminal stark variiert, kann er auch als Testkomponente zur Überprüfung anderer Parameter verwendet werden.
Hier sehen wir, dass rxvt und st im Vergleich zu den Mitbewerbern deutlich vorne liegen, gefolgt von dem viel neueren Alacritty, das auf Geschwindigkeit ausgelegt ist. Danach kommen Xfce (VTE-Familie) und Konsole, die fast doppelt so schnell arbeiten. Letztendlich kommt xterm mit einer Geschwindigkeit, die fünfmal langsamer ist als rxvt. Während des Tests zeigte xterm auch starke Flimmern, was es schwierig machte, den durchlaufenden Text zu erkennen, selbst wenn es sich um dieselbe Zeile handelte. Konsole erwies sich als schnell, hatte jedoch zeitweise Probleme: Der Bildschirm fror gelegentlich ein und zeigte den Text nur teilweise oder gar nicht an. Andere Terminals zeigten die Zeilen klar an, einschließlich st, Alacritty und rxvt.
Diki erklärt, dass die Unterschiede in der Leistung mit dem Design der Scrollpuffer in verschiedenen Terminals zusammenhängen. Er macht besonders rxvt und andere Terminals dafür verantwortlich, dass sie "sich nicht an die allgemeinen Regeln halten":
"Im Gegensatz zu xterm versuchte rxvt nicht, alle Aktualisierungen darzustellen. Wenn es hinterherhinkt, verwirft es einige Aktualisierungen, um den Rückstand aufzuholen. Dies hatte einen größeren Einfluss auf die scheinbare Scrollgeschwindigkeit als auf die Organisation des internen Speichers. Ein Nachteil war, dass die ASCII-Animation etwas ungenau war."
Um diese scheinbare Langsamkeit von xterm zu beheben, schlägt Diki vor, die Ressource zu verwenden, die es xterm ermöglicht, einige Bildschirmaktualisierungen zu verwerfen, um nicht hinter dem Fluss zurückzubleiben. Meine Tests bestätigen, dass fastScroll die Leistung verbessert und xterm auf das Niveau von rxvt hebt. Dies ist jedoch ein eher grober Workaround, wie Diki selbst erklärt: "Manchmal scheint xterm – wie auch die Konsole – anzuhalten, während es auf einen neuen Satz Bildschirmaktualisierungen wartet, nachdem einige von ihnen verworfen wurden." In dieser Hinsicht scheint es, dass andere Terminals den besten Kompromiss zwischen Geschwindigkeit und Integrität des Displays gefunden haben.
Ressourcennutzung
Unabhängig von der Sinnhaftigkeit, die Scrollgeschwindigkeit als Leistungsindikator zu betrachten, ermöglicht dieser Test, die Belastung der Terminals zu simulieren, was es uns wiederum erlaubt, andere Parameter wie Speicher- oder Festplattennutzung zu messen. Die Metriken wurden durch Ausführen des angegebenen Tests seq unter der Überwachung eines Python-Prozesses gesammelt. Er sammelte Daten von den Zählern für ru_maxrss, der Summe ru_oublock und ru_inblock und einem einfachen Zeitgeber.
In diesem Test belegt ST mit einem durchschnittlichen Speicherverbrauch von 8 MB den ersten Platz, was nicht verwunderlich ist, wenn man bedenkt, dass die grundlegende Idee des Projekts die Einfachheit ist. Etwas mehr verbrauchen mlterm, xterm und rxvt – etwa 12 MB. Ein weiteres bemerkenswertes Ergebnis liefert Alacritty, das für den Betrieb 30 MB benötigt. Danach kommen die Terminals der VTE-Familie mit Werten von 40 bis 60 MB, was ziemlich viel ist. Diese Verbrauchswerte lassen sich damit erklären, dass diese Terminals höherwertige Bibliotheken wie GTK verwenden. Konsole ist mit einem enormen Verbrauch von 65 MB während der Tests zuletzt, obwohl dies durch sein recht umfangreiches Funktionsspektrum gerechtfertigt werden kann.
Verglichen mit den früheren Ergebnissen, die vor zehn Jahren erzielt wurden, verbrauchen alle Programme deutlich mehr Speicher. Früher benötigte Xterm 4 MB, jetzt sind es 15 MB nur zum Starten. Ein ähnlicher Anstieg des Verbrauchs ist auch bei rxvt zu beobachten, das mittlerweile sofort 16 MB benötigt. Das Xfce-Terminal belegt 34 MB, was dreimal so viel ist wie früher, während das GNOME Terminal nur 20 MB benötigt. Natürlich wurden alle vorherigen Tests auf einer 32-Bit-Architektur durchgeführt. Auf der LCA 2012 berichtete Rusty Russell , dass es viele subtilere Gründe gibt, die erklären können, warum der Speicherverbrauch wächst. In all dem leben wir jetzt in Zeiten, in denen wir ganze Gigabytes an Speicher zur Verfügung haben, also werden wir das irgendwie bewältigen.
Dennoch kann ich das Gefühl nicht loswerden, dass es eine Verschwendung von Ressourcen ist, so viel Speicher für so grundlegende Software wie ein Terminal zuzuweisen. Diese Programme sollten die kleinsten der Kleinsten sein, sie sollten auf jeder "Kiste" laufen können, sogar auf einer Schuhschachtel, falls wir jemals an den Punkt gelangen, an dem sie mit Linux-Systemen ausgestattet werden müssen (und Sie wissen, dass es so kommen wird). Aber mit diesen Zahlen wird der Speicherverbrauch in Zukunft ein Problem in jeder Umgebung darstellen, wenn mehrere Terminals gestartet werden, außer vielleicht bei den leichtesten und am meisten eingeschränkten. Um dem entgegenzuwirken, haben GNOME Terminal, Konsole, urxvt, Terminator und Xfce Terminal einen Daemon-Modus, der es ermöglicht, mehrere Terminals über einen Prozess zu verwalten, was ihren Speicherverbrauch begrenzt.
Während meiner Tests bin ich auf ein weiteres unerwartetes Ergebnis in Bezug auf das Lesen und Schreiben von Festplatten gestoßen: Ich hatte erwartet, hier überhaupt nichts zu sehen, aber es stellte sich heraus, dass einige Terminals die umfangreichsten Daten auf die Festplatte schreiben. So hält die VTE-Bibliothek praktisch einen Scroll-Puffer auf der Festplatte (dieser Umstand , und das geschieht bis heute). Aber im Gegensatz zu älteren Implementierungen sind diese Daten jetzt zumindest mit AES256 GCM verschlüsselt (). Doch es stellt sich die berechtigte Frage, was es so Besonderes an der VTE-Bibliothek gibt, dass sie einen so unkonventionellen Ansatz zur Implementierung erfordert…
Fazit
Im ersten Teil des Artikels haben wir festgestellt, dass VTE-basierte Terminals eine gute Funktionsvielfalt bieten, aber jetzt sehen wir, dass dies mit gewissen Kosten verbunden ist, um ihre Leistung zu gewährleisten. Momentan ist der Speicher kein Problem, da alle VTE-Terminals über einen Daemon-Prozess verwaltet werden, der ihren Appetit begrenzt. Dennoch benötigen ältere Systeme, die physische Einschränkungen bezüglich des Arbeitsspeichers und des Kern-Puffers haben, möglicherweise frühere Versionen der Terminals, da sie deutlich weniger Ressourcen verbrauchen. Obwohl sich die VTE-Terminals in Tests zur Bandbreite (Scrolling) gut geschlagen haben, liegt ihre Anzeigeverzögerung über dem im GNOME-Benutzerhandbuch festgelegten Schwellenwert. Wahrscheinlich sollten die Entwickler von VTE dies berücksichtigen. Wenn man bedenkt, dass selbst Anfänger in Linux mit dem Terminal konfrontiert werden, könnten sie es benutzerfreundlicher gestalten. Für erfahrene Nerds könnte der Wechsel vom Standardterminal sogar eine Verringerung der Augenbelastung und die Möglichkeit bedeuten, zukünftige berufliche Verletzungen und Erkrankungen aufgrund langer Arbeitssitzungen zu vermeiden. Leider bringen uns nur die alten xterm- und mlterm-Terminals an die magische Ping-Schwelle von 10 Millisekunden, was für viele inakzeptabel ist.
Die Kontrollmessungen haben auch gezeigt, dass die Entwicklung grafischer Umgebungen in Linux Entwickler dazu gezwungen hat, eine Reihe von Kompromissen einzugehen. Einige Benutzer sollten sich die herkömmlichen Fenster-Manager genauer ansehen, da sie eine signifikante Verringerung des Pings bieten. Leider konnte die Latenz für Wayland nicht gemessen werden: Das Programm Typometer, das ich verwendet habe, wurde entwickelt, um das zu verhindern, was Wayland eigentlich verhindern soll – das Ausspionieren anderer Fenster. Ich hoffe, dass das Compositing von Wayland in der Leistung besser ist als das von X.org, und ich bin auch zuversichtlich, dass in Zukunft jemand einen Weg finden wird, das Latenzniveau in dieser Umgebung zu bewerten.
Quelle: habr.com
