Ein paar Worte von unserem Übersetzungsbüro: Oft neigen alle dazu, die neuesten Materialien und Publikationen zu übersetzen, und wir sind da keine Ausnahme. Doch Terminals sind nicht etwas, das wöchentlich aktualisiert wird. Aus diesem Grund haben wir für Sie den Artikel von Antoine Beaupré übersetzt, der im Frühjahr 2018 veröffentlicht wurde: Trotz seines für heutige Verhältnisse „hohen Alters“ hat das Material unserer Meinung nach an Relevanz nicht verloren. Außerdem handelt es sich im Original um eine Serie von zwei Artikeln, aber wir haben entschieden, sie in einen großen Post zu kombinieren.
Terminals nehmen einen besonderen Platz in der Computerhistorie ein, mussten in den letzten Jahrzehnten jedoch buchstäblich zusammen mit der Eingabeaufforderung überleben, während sich grafische Benutzeroberflächen überall durchsetzten. haben ihre , die wiederum eine Modifikation von Systemen auf Lochkarten und Relais waren. Moderne Distributionen kommen mit einer Vielzahl von Terminalemulatoren in allen Formen und Farben. Während viele zufrieden sind mit dem Standardterminal, das ihre Arbeitsumgebung bereitstellt, nutzen einige stolz exzentrische Software, um ihre Lieblingsshell oder ihren Texteditor zu betreiben. Doch wie wir in diesem Artikel sehen werden, wurden nicht alle Terminals gleich geschaffen: Sie unterscheiden sich erheblich in Funktionalität, Größe und Leistung.
Einige Terminals weisen geradezu erstaunliche Sicherheitslücken auf, und zudem haben die meisten ganz unterschiedliche Funktionalitäten, von der Unterstützung von Tab-Interfaces bis hin zu Scripts. Obwohl wir , ist dieser Artikel ein Update auf das frühere Material, das den Lesern hilft zu erkennen, welches Terminal sie im Jahr 2018 verwenden sollten. 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 der Erstellung des Materials auf Debian 9 oder Fedora 27 einsetzen konnte. Die einzige Ausnahme bildet Alacritty. Es ist ein Nachfahre von Terminalen mit GPU-Beschleunigung und in einer für diese Aufgabe ungewöhnlichen und neuen Sprache — Rust — geschrieben. Ich habe Web-Terminals (einschließlich, und auf ), ausgeschlossen, da erste Tests eine extrem niedrige Leistung gezeigt haben.
Unicode-Unterstützung
Ich begann meine Tests mit der Unterstützung von Unicode. Der erste Test der Terminals war die Darstellung eines Unicode-Strings aus : «é, Δ, Й, ק, م, ๗, あ, 叶, 葉 und 말». Dieser einfache Test zeigt, ob das Terminal weltweit korrekt arbeiten kann. Das Terminal xterm zeigt das arabische Zeichen in der Standardkonfiguration:
Standardmäßig verwendet xterm die klassische 'fixed' Schriftart, die laut , hat eine „signifikante Unicode-Abdeckung seit 1997“. In dieser Schriftart passiert etwas, das das Zeichen als leeres Kästchen darstellt, und nur durch Erhöhen der Schriftgröße auf über 20 Punkte beginnt das Zeichen endlich korrekt angezeigt zu werden. Allerdings bricht dieser „Fix“ die Anzeige anderer Unicode-Zeichen:
Diese Screenshots wurden in Fedora 27 aufgenommen, da diese Version die besten Ergebnisse lieferte, während Debian 9, wo einige ältere Terminalversionen (insbesondere mlterm) nicht richtig mit Schriftarten arbeiten konnten, schlechter abschnitt. Glücklicherweise wurde das in späteren Versionen behoben.
Achten Sie nun auf die Anzeige der Zeile in xterm. Es stellt sich heraus, dass das Zeichen Mem und das folgende semitische zu den RTL-Skripten gehören (), und sollten daher technisch von rechts nach links angezeigt werden. Webbrowser wie Firefox 57 verarbeiten die obige Zeile korrekt. Ein einfacheres Beispiel für 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 Terminale bestehen diesen Test nicht: Alacritty, die VTE-abgeleiteten Terminale von Gnome und XFCE, urxvt, st und xterm zeigen „Sara“ in umgekehrter Reihenfolge an, als würden wir diesen Namen als „Aras“ schreiben.
Ein weiteres Problem bei bidirektionalen Texten besteht darin, dass sie irgendwie ausgerichtet werden müssen, insbesondere wenn es um die Mischung von RTL- und LTR-Texten geht. RTL-Szenarien sollten von der rechten Seite des Terminalfensters gestartet werden, aber was passiert mit Terminalen, die standardmäßig mit LTR-Englisch arbeiten? Die meisten haben keine speziellen Mechanismen und richten den gesamten Text linksbündig aus (einschließlich in Konsole). Ausnahmen bilden pterm und mlterm, die sich an die Standards halten und solche Zeilen rechtsbündig ausrichten.
Schutz vor Einfügen
Die nächste kritische Eigenschaft, die ich für mich definiert habe, ist der Schutz vor Einfügen. Obwohl allgemein bekannt ist, dass Zauber wie:
$ curl http://example.com/ | shsind Push-Befehle zur Codeausführung. Weniger bekannt ist, dass versteckte Befehle über die Konsole eingeschleust werden können, wenn man sie aus dem Webbrowser kopiert und einfügt, selbst nach eingehender Überprüfung. zeigt auf brillante Weise, wie eine scheinbar harmlose Eingabe:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitbeim Einfügen von Horns Seite ins Terminal in folgendes Problem umschlägt:
git clone /dev/null;
clear;
echo -n "Hallo ";
whoami|tr -d 'n';
echo -e '!nDas war eine schlechte Idee. Kopieren Sie keinen Code von Websites, denen Sie nicht vertrauen!
Hier ist die erste Zeile Ihrer /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitWie funktioniert das? Der schadhafte Code wird in einen Block , der durch CSS aus dem Blickfeld des Benutzers entfernt wird.
ist eindeutig 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. Dadurch erhält die Shell das Signal, dass sie die speziellen Zeichen, die der eingefügte Text enthalten kann, ignorieren kann. Alle Terminals, einschließlich des ehrwürdigen xterm, unterstützen diese Funktion, aber das Einfügen im Bracketed-Modus erfordert Unterstützung von der Shell oder der Anwendung, die im Terminal ausgeführt wird. Zum Beispiel benötigt Software, die (dasselbe wie Bash), eine Datei ~ /.inputrc:
set enable-bracketed-paste onLeider zeigt die Testseite von Horna auch, wie man diesen Schutz durch die Formatierung des Textes umgehen und die Anwendung des Bracketed-Modus vorzeitig beenden kann. Dies funktioniert, weil einige Terminals die Escape-Sequenzen vor dem Hinzufügen ihrer eigenen nicht korrekt filtern. Zum Beispiel konnte ich in meinen Tests Konsole auch mit korrekter Konfiguration nicht erfolgreich abschließen. .inputrc Dies bedeutet, dass Sie leicht Systemkonfigurationsfehler aufgrund von nicht unterstützten Anwendungen oder falsch konfigurierten Shells erhalten können. Besonders gefährlich ist dies beim Zugriff auf Remote-Server, wo eine sorgfältige Konfiguration seltener erfolgt, insbesondere wenn Sie viele solcher Remote-Maschinen haben.
Eine gute Lösung für dieses Problem ist das Einfügebestätigungs-Plugin für das Terminal urxvt, das einfach um Erlaubnis zur Einfügung von beliebigem Text mit Zeilenumbrüchen bittet. Eine sicherere Variante für den beschriebenen Horn-Textangriff habe ich nicht gefunden.
Tabs und Profile
Eine derzeit sehr beliebte Funktion ist die Unterstützung von Tab-Interfaces, die wir als ein Terminalfenster definieren, das mehrere weitere Terminals enthält. Diese Funktion variiert je nach Terminaltyp. Während traditionelle Terminals wie xterm keine Tab-Unterstützung bieten, verfügen neuere Terminalvarianten wie Xfce Terminal, GNOME Terminal und Konsole über diese Funktion. Auch Urxvt unterstützt Tabs, jedoch nur mit einem Plugin. In Bezug auf die Tab-Unterstützung ist Terminator der unangefochtene Champion: Er unterstützt nicht nur Tabs, sondern kann auch Terminals beliebig anordnen (siehe Abbildung unten).
Eine weitere Besonderheit von Terminator ist die Möglichkeit, diese Tabs zusammenzufassen und dieselben Tastendrücke gleichzeitig an mehrere Terminals zu senden, was ein praktisches Tool für die Durchführung von Massenoperationen auf mehreren Servern gleichzeitig bietet. Eine ähnliche Funktion ist auch in Konsole implementiert. Um diese Funktion in anderen Terminals zu nutzen, muss zusätzliche Software wie , oder .
Insbesondere funktionieren die Tabs gut zusammen mit Profilen: Zum Beispiel können Sie einen Tab für E-Mails, einen anderen für Chats usw. haben. Diese Funktion wird von Terminallösungen wie Konsole und GNOME Terminal gut unterstützt. Beide ermöglichen es, dass jeder Tab automatisch sein eigenes Profil startet. Terminator unterstützt ebenfalls Profile, aber ich konnte keinen Weg finden, bestimmte Programme beim Öffnen eines bestimmten Tabs automatisch zu starten. Andere Terminals haben überhaupt kein Konzept von ‚Profilen‘.
Rüschchen
Das Letzte, was ich im ersten Teil dieses Artikels betrachten möchte, ist das Aussehen der Terminals. Zum Beispiel unterstützen GNOME, Xfce und urxvt Transparenz, haben jedoch kürzlich die Unterstützung für Hintergrundbilder eingestellt, was einige Benutzer dazu veranlasst hat, auf ein anderes Terminal umzusteigen. . Persönlich schätze ich einfachheit. Xresources, welches die grundlegenden Hintergrundfarben für urxvt festlegt. Allerdings können nicht standardisierte Farbthemen auch Probleme verursachen. Zum Beispiel bei Anwendungen und , da sie bereits eigene Farben verwenden.
unterstützte keine Farben, und neue sind oft auf eine Palette von 256 Farben beschränkt. Für erfahrene Benutzer, die ihre Terminals auf komplexe Weise anpassen, können Abfragen im Shell oder Statuszeilen zu einer lästigen Einschränkung werden. verfolgt, welche Terminals "True Color" unterstützen. Meine Tests bestätigen, dass st, Alacritty und VTE-basierte Terminals True Color hervorragend unterstützen. Andere Terminals schneiden in dieser Hinsicht nicht so gut ab und zeigen tatsächlich nicht einmal 256 Farben an. Unten können Sie den Unterschied zwischen der Unterstützung von True Color in den GNOME-, st- und xterm-Terminals sehen, die mit ihrer 256-Farben-Palette gut abschneiden, und urxvt, das nicht nur den Test nicht besteht, sondern sogar flackernde Symbole anzeigt.
Einige Terminals analysieren auch den Text auf URL-Muster, um Links klickbar zu machen. Dies gilt für alle VTE-basierten Terminals, während urxvt ein spezielles Plug-in benötigt, um URLs durch einen Klick oder eine Tastenkombination zu transformieren. Andere von mir getestete Terminals zeigen URLs auf andere Weise an.
Schließlich ist ein neuer Trend bei Terminals die optionale Scrollback-Pufferung. Zum Beispiel hat st keinen Scrollback-Puffer; es wird angenommen, dass der Benutzer einen Terminal-Multiplexer wie tmux oder .
Auch Alacritty verfügt nicht über Rückscroll-Puffer, jedoch die Unterstützung dafür aufgrund des "umfangreichen Feedbacks" von Nutzern hinzugefügt. Neben diesen Ausreißern unterstützt jeder Terminal, den ich finden konnte, Rückscrolling.
Zwischenfazit
Im zweiten Teil des Materials (im Original waren dies zwei verschiedene Artikel, — Anm. d. Ü.) werden wir die Leistung, den Speicherverbrauch und die Latenz vergleichen. Doch bereits jetzt sehen wir, dass einige der betrachteten Terminals ernsthafte Mängel aufweisen. Beispielsweise können Benutzer, die regelmäßig mit RTL-Skripten arbeiten, auf mlterm und pterm achten, da diese besser mit solchen Aufgaben umgehen können. Konsole hat sich ebenfalls gut bewährt. Benutzer, die nicht mit RTL-Skripten arbeiten, können etwas anderes wählen.
In Bezug auf den Schutz vor der Einschleusung von Schadcode sticht urxvt aufgrund seiner speziellen Implementierung von Schutzmechanismen gegen diese Art von Angriffen hervor, die ich definitiv als nützlich empfinde. Wer nach etwas mehr Komfort sucht, sollte sich Konsole ansehen. Schließlich ist VTE eine hervorragende Basis für Terminal-Emulatoren, die Farbsupport, URL-Erkennung und mehr gewährleistet. Auf den ersten Blick mag das Standardterminal, das mit Ihrer bevorzugten Umgebung geliefert wird, allen Anforderungen genügen, aber lassen wir diese Frage zunächst offen, bis wir die Leistung genauer untersuchen können.
Wir setzen das Gespräch fort
Die Leistung von Terminals kann zwar als übertriebenes Thema erscheinen, jedoch zeigen einige von ihnen überraschend hohe Latenzen für solche grundlegende Software. Außerdem werden wir uns mit dem befassen, was traditionell als "Geschwindigkeit" bezeichnet wird (tatsächlich ist es die Scrollgeschwindigkeit) und dem Speicherverbrauch des Terminals (unter Berücksichtigung der Tatsache, dass dies heutzutage nicht mehr so kritisch ist wie vor Jahrzehnten).
Latenz
Nach gründlicher Untersuchung der Terminalleistung bin ich zu dem Schluss gekommen, dass die wichtigste Kennzahl in diesem Zusammenhang die Verzögerung (Ping) ist. In seinem Artikel hat Pavel Fatin die Verzögerung verschiedener Texteditoren beleuchtet und angedeutet, dass Terminals in dieser Hinsicht langsamer arbeiten könnten als die schnellsten Texteditoren. Genau dieser Hinweis veranlasste mich letztendlich, meine eigenen Tests durchzuführen und diesen Artikel zu schreiben.
Aber was ist Verzögerung und warum ist sie so wichtig? In seinem Artikel definierte Fatin sie als «die Verzögerung zwischen dem Drücken einer Taste und der entsprechenden Aktualisierung des Bildschirms» und zitierte , in dem steht: «Die Verzögerung in der visuellen Rückmeldung auf dem Computerbildschirm hat einen wichtigen Einfluss auf das Verhalten der Schreibkraft und deren Zufriedenheit».
Fatin erklärt, dass ein solcher Ping tiefere Konsequenzen hat als nur die Zufriedenheit: „Das Tippen wird langsamer, es treten mehr Fehler auf, und die Belastung von Augen und Muskeln nimmt zu.“ Mit anderen Worten kann eine höhere Verzögerung zu Tippfehlern führen und auch die Code-Qualität beeinträchtigen, da sie eine zusätzliche kognitive Belastung für das Gehirn darstellt. Aber noch schlimmer ist, dass der Ping „die Belastung von Augen und Muskeln erhöht“, was anscheinend auf in der Zukunft (offensichtlich meint der Autor Probleme mit Augenmuskeln, Rücken, Händen und natürlich dem Sehvermögen – Anm. d. Übers.) aufgrund wiederholter Belastungen.
Einige dieser Effekte sind schon lange bekannt, und die Ergebnisse , veröffentlicht bereits 1976 im Journal Ergonomics, zeigen, dass eine Verzögerung von 100 Millisekunden die Tippgeschwindigkeit erheblich verschlechtert. Vor kurzem wurde im Benutzerhandbuch von GNOME von 10 Millisekunden festgelegt, und wenn man noch weiter geht, dann , dass das Ideal bei 1 Millisekunde liegt.
Fatin führte seine Tests in Texteditoren durch; er entwickelte ein tragbares Tool mit dem Namen , das ich zur Ping-Überprüfung in Terminalemulatoren verwendet habe. Bitte beachten Sie, dass der Test im Simulationsmodus durchgeführt wurde: In der Realität müssen wir auch die Eingabeverzögerung (Tastatur, USB-Controller usw.) und die Ausgabeverzögerung (Grafikkartenpuffer, Monitor) berücksichtigen. Laut Fatin liegt sie in typischen Konfigurationen bei etwa 20 ms. Mit Gamer-Hardware kann man jedoch einen Wert von nur 3 Millisekunden erreichen. Da wir bereits über solch schnelle Hardware verfügen, sollte die Anwendung keine zusätzliche Verzögerung verursachen. Fatins Ziel ist es, die Verzögerung der Anwendung auf 1 Millisekunde zu senken oder ganz auf eine , wie bei .
. Hier sind die Ergebnisse meiner Messungen sowie einige Ergebnisse von Fatin, um zu zeigen, dass mein Experiment mit seinen Tests übereinstimmt:
Das Erste, was mich beeindruckte, war die bemerkenswert bessere Reaktionszeit älterer Programme wie xterm und mlterm. Mit einer signifikanten Eingabeverzögerung von nur 2,4 ms zeigten sie bessere Ergebnisse als der schnellste moderne Terminal (10,6 ms für st). Kein moderner Terminal fällt unter die Grenze von 10 Millisekunden. Besonders Alacritty erfüllt nicht die Ansprüche an den "schnellsten aller existierenden Terminalemulatoren", obwohl sich die Ergebnisse seit dem ersten Test 2017 verbessert haben. Tatsächlich sind die Autoren des Projekts und arbeiten an einer Verbesserung der Darstellung. Es ist ebenfalls erwähnenswert, dass Vim, das GTK3 verwendet, um ein Vielfaches langsamer ist als seine GTK2-Äquivalente. Daraus lässt sich schließen, dass GTK3 zusätzliche Verzögerungen erzeugt, die sich auch auf andere Terminals auswirken, die es nutzen (Terminator, Xfce4 Terminal und GNOME Terminal).
Allerdings können die Unterschiede auf den ersten Blick unsichtbar sein. Wie Fatine erklärt: „Es ist nicht notwendig, sich der Verzögerung bewusst zu sein, damit sie Auswirkungen auf Sie hat.“ Fatine warnt auch vor der Standardabweichung: „Jede Abweichung in der Dauer der Verzögerung (z. B. Ruckeln) verursacht zusätzliche Belastungen aufgrund ihrer Unvorhersehbarkeit.“
Das obige Diagramm wurde auf einem reinen Debian 9 (Stretch) mit . Diese Umgebung liefert die besten Ergebnisse in Tests zur Messung der Verzögerung. Es hat sich herausgestellt, dass GNOME zusätzliche 20 ms Ping für alle Messungen erzeugt. Eine mögliche Erklärung dafür ist das Vorhandensein von Programmen mit synchroner Verarbeitung von Eingabeveranstaltungen. Fatine nennt als Beispiel , das Verzögerungen hinzufügt, indem es alle Eingabeveranstaltungen synchron verarbeitet. Standardmäßig ist GNOME auch mit einem Fenstermanager ausgestattet, der eine zusätzliche Pufferungsebene schafft, die den Ping beeinflusst und mindestens 8 Millisekunden Verzögerung hinzufügt.
Scrollgeschwindigkeit
Der folgende Test ist eine traditionelle Überprüfung der „Geschwindigkeit“ oder der „Bandbreite“, die misst, wie schnell das Terminal eine Seite scrollen kann, während es eine große Menge Text auf dem Bildschirm anzeigt. Die Mechanik des Tests variiert; der ursprüngliche Test bestand darin, einfach die gleiche Textzeile mit dem Befehl seq zu generieren. Weitere Tests umfassen den Thomas E. Dick-Test (begleitend zu xterm), bei dem mehrfach . In einer weiteren Leistungsbewertung von Terminals verwendet eine Reihe zufälliger Bytes im base32-Format, die über den Befehl cat im Terminal ausgegeben werden. Liu bezeichnet diesen Test als "so nutzlos, wie man sich nur vorstellen kann", und schlägt vor, stattdessen die Terminalantwort als Hauptindikator zu verwenden. Dick bezeichnet seinen Test ebenfalls als irreführend. Dennoch erkennen beide Autoren an, dass die Bandbreite des Terminalfensters problematisch sein kann. Liu hat ein Einfrieren von Emacs Eshell beim Anzeigen großer Dateien festgestellt, während Dick das Terminal optimiert hat, um die visuelle Trägheit von xterm zu beseitigen. Daher gibt es in diesem Test immer noch einen gewissen Sinn, aber da der Rendering-Prozess 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 anderen Terminalemulatoren deutlich abstechen, gefolgt von dem deutlich neueren Alacritty, das mit einem starken Fokus auf Leistung entwickelt wurde. Danach kommen Xfce (VTE-Familie) und Konsole, die fast doppelt so schnell arbeiten. Am langsamsten ist xterm, das fünfmal langsamer als rxvt ist. Während des Tests zeigte xterm auch starke Verzerrungen, und es war schwierig, den durchlaufenden Text zu erkennen, selbst wenn es sich um denselben Satz handelte. Konsole erwies sich als schnell, hatte jedoch gelegentlich „Probleme“: Der Display frierte manchmal ein, sodass der Text teilweise oder gar nicht angezeigt wurde. Andere Terminals, einschließlich st, Alacritty und rxvt, zeigten die Zeilen klar an.
Diki erklärt, dass die Unterschiede in der Leistung mit dem Design der Bildlaufpuffer in den verschiedenen Terminals zusammenhängen. Insbesondere wirft er rxvt und anderen Terminals vor, dass sie "die allgemeinen Regeln nicht einhalten":
Im Gegensatz zu xterm hat rxvt nicht versucht, alle Aktualisierungen anzuzeigen. Wenn es hinterherhinkt, überspringt es einige Aktualisierungen, um den Rückstand aufzuholen. Dies hatte einen größeren Einfluss auf die vermeintliche 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 Dick vor, die Ressource , zu verwenden, die es xterm ermöglicht, einige Bildschirmaktualisierungen zu ignorieren, um im Fluss zu bleiben. Meine Tests bestätigen, dass fastScroll die Leistung steigert und xterm auf das Niveau von rxvt hebt. Dies ist jedoch ein recht grober Workaround, wie Dick selbst erklärt: „Manchmal scheint xterm – wie auch konsole – zu stoppen, da es auf einen neuen Satz von Bildschirmaktualisierungen wartet, nachdem einige von ihnen entfernt wurden.“ In diesem Zusammenhang scheint es, dass andere Terminals den besten Kompromiss zwischen Geschwindigkeit und Integrität der Anzeige gefunden haben.
Ressourcennutzung
Unabhängig von der Sinnhaftigkeit, die Scrollgeschwindigkeit als Leistungsmaßstab zu betrachten, ermöglicht dieser Test eine Simulation der Belastung der Terminals, was es uns wiederum erlaubt, andere Parameter wie Speicher- oder Festplattennutzung zu messen. Die Metriken wurden durch die Ausführung des angegebenen Tests ermittelt. seq unter der Überwachung des Python-Prozesses. Er sammelte die Zählerdaten. für ru_maxrss, die Summe ru_oublock und ru_inblock und einen einfachen Zeit-Timer.
In diesem Test hat ST mit dem niedrigsten durchschnittlichen Speicherverbrauch von 8 MB den ersten Platz belegt, was nicht überraschend ist, wenn man bedenkt, dass die Hauptidee des Projekts 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. Dann folgen die Terminals der VTE-Familie mit Verbrauchswerten von 40 bis 60 MB, was ziemlich viel ist. Ein derartiger Verbrauch lässt sich erklären, da diese Terminals höhere Bibliotheken wie GTK verwenden. Konsole belegt mit einem enormen Verbrauch von 65 MB während der Tests den letzten Platz, was jedoch durch eine recht umfangreiche Funktionsvielfalt gerechtfertigt werden kann.
Im Vergleich zu den Ergebnissen von vor zehn Jahren verbrauchen alle Programme deutlich mehr Speicher. Früher benötigte Xterm 4 MB, jetzt sind es 15 MB nur zum Starten. Ein ähnlicher Anstieg ist bei rxvt zu beobachten, das mittlerweile standardmäßig 16 MB benötigt. Das Terminal Xfce belegt 34 MB, was dreimal so viel ist wie früher, während GNOME Terminal nur 20 MB benötigt. Natürlich wurden alle vorherigen Tests auf einer 32-Bit-Architektur durchgeführt. Auf der LCA 2012 sagte Rusty Russell , dass es viele feinere Gründe gibt, die den Anstieg des Speicherverbrauchs erklären können. In der heutigen Zeit leben wir jedoch mit mehreren Gigabyte an Speicher, sodass wir das schon irgendwie bewältigen werden.
Dennoch habe ich das Gefühl, dass das Zuweisen von mehr Speicher für so grundlegende Software wie ein Terminal eine Verschwendung von Ressourcen ist. Diese Programme sollten die kleinsten der kleinen sein und selbst auf den einfachsten Geräten lauffähig sein - sogar auf einem Schuhkarton, falls wir jemals dazu kommen, sie mit Linux-Systemen auszustatten (und Sie wissen, dass es so kommen wird). Aber mit diesen Zahlen wird der Speicherverbrauch in Zukunft ein Problem in jeder Umgebung darstellen, besonders beim Start mehrerer Terminals, abgesehen von den leichtesten und am stärksten eingeschränkten. Um dem entgegenzuwirken, verfügen GNOME Terminal, Konsole, urxvt, Terminator und Xfce Terminal über einen Daemon-Modus, der es ermöglicht, mehrere Terminals über einen Prozess zu verwalten, wodurch ihr Speicherverbrauch eingeschränkt wird.
Während meiner Tests kam ich zu einem weiteren unerwarteten Ergebnis bezüglich des Lese- und Schreibvorgangs auf der Festplatte: Ich hatte erwartet, hier gar nichts zu sehen, aber tatsächlich schreiben einige Terminals die umfangreichsten Daten auf die Festplatte. So hält die VTE-Bibliothek tatsächlich einen Scrollpuffer auf der Festplatte (dieses Merkmal , und das passiert bis heute). Aber im Gegensatz zu den alten Implementierungen sind diese Daten jetzt zumindest mit AES256 GCM verschlüsselt (). Aber es stellt sich die berechtigte Frage, was so Besonderes an der VTE-Bibliothek ist, dass sie einen so unkonventionellen Ansatz für die Implementierung erfordert…
Fazit
Im ersten Teil des Artikels haben wir festgestellt, dass VTE-basierte Terminals eine gute Auswahl an Funktionen bieten. Doch nun sehen wir, dass dies mit einigen Kosten zur Gewährleistung ihrer Leistung verbunden ist. Aktuell stellt der Speicher kein Problem dar, da alle VTE-Terminals über einen Daemon-Prozess gesteuert werden, der ihren Ressourcenbedarf begrenzt. Dennoch könnten ältere Systeme, die physikalische Einschränkungen bei der Menge an RAM und Kernel-Pufferspeicher aufweisen, weiterhin auf frühere Versionen der Terminals angewiesen sein, da diese erheblich weniger Ressourcen verbrauchen. Obwohl sich die VTE-Terminals in Tests zur Durchsatzleistung (Scrolling) gut geschlagen haben, liegt ihre Datenanzeigeverzögerung über dem in den GNOME-Benutzerhandbuch festgelegten Grenzwert. Es wäre ratsam, dass die Entwickler von VTE dies berücksichtigen. Angesichts der Tatsache, dass selbst für Anfänger in Linux der Kontakt mit einem Terminal unvermeidlich ist, könnten sie es benutzerfreundlicher gestalten. Für erfahrene Nerds kann der Wechsel vom Standardterminal sogar eine Reduzierung der Augenbelastung und die Möglichkeit vermeiden, zukünftige berufliche Verletzungen und Krankheiten durch längere Arbeitssitzungen zu entwickeln. Leider bringen uns nur die alten xterm- und mlterm-Terminals an den magischen Ping-Grenzwert von 10 Millisekunden, was für viele inakzeptabel ist.
Die Kontrollmessungen haben auch gezeigt, dass die Entwicklung grafischer Umgebungen in Linux die Entwickler zu einer Reihe von Kompromissen gezwungen hat. Einige Benutzer sollten einen Blick auf herkömmliche Fenster-Manager werfen, da sie eine erhebliche Verringerung der Latenz bieten. Leider konnte die Verzögerung bei Wayland nicht gemessen werden: Das Programm Typometer, das ich verwendet habe, wurde entwickelt, um das zu verhindern, was Wayland zu bekämpfen versucht – das Ausspionieren anderer Fenster. Ich hoffe, dass das Compositing von Wayland in Bezug auf die Leistung besser ist als bei X.org, und ich hoffe auch, dass in Zukunft jemand einen Weg findet, die Verzögerung in dieser Umgebung zu bewerten.
Quelle: habr.com
