Een paar woorden van ons vertaalbureau: normaal gesproken streeft iedereen ernaar de nieuwste materialen en publicaties te vertalen, en wij zijn daarop geen uitzondering. Maar terminals zijn niet iets dat één keer per week wordt bijgewerkt. Daarom hebben we voor u een artikel van Antoine Beaupré vertaald, gepubliceerd in het voorjaar van 2018: ondanks zijn aanzienlijke “leeftijd” naar moderne maatstaven, heeft het materiaal naar onze mening zijn relevantie helemaal niet verloren. Bovendien was dit oorspronkelijk een serie van twee artikelen, maar we hebben besloten deze te combineren tot één grote post.
Terminals nemen een speciale plaats in de computergeschiedenis in, maar zijn de afgelopen decennia gedwongen om naast de opdrachtregel te overleven, omdat grafische interfaces alomtegenwoordig zijn geworden. hun eigen vervangen , die op hun beurt een wijziging waren van systemen op basis van ponskaarten en tuimelschakelaars. Moderne distributies worden geleverd met een verscheidenheid aan terminalemulators in alle vormen en kleuren. En hoewel velen tevreden zijn met de standaardterminal die hun werkomgeving biedt, gebruiken sommigen vol trots ronduit exotische software om hun favoriete shell- of teksteditor te draaien. Maar zoals we in dit artikel zullen zien, zijn niet alle terminals in hetzelfde beeld gemaakt: ze verschillen enorm qua functionaliteit, grootte en prestaties.
Sommige terminals hebben ronduit verrassende beveiligingslekken, en de meeste hebben een compleet andere reeks functies, van ondersteuning voor een interface met tabbladen tot scripting. Hoewel wij , is dit artikel een update van het eerdere materiaal dat lezers zal helpen bepalen welke terminal ze in 2018 moeten gebruiken. In de eerste helft van het artikel worden de kenmerken vergeleken, in de tweede helft worden de prestaties geëvalueerd.
Dit zijn de terminals die ik heb beoordeeld:
Dit zijn misschien niet de nieuwste versies, aangezien ik op het moment van schrijven beperkt was tot stabiele builds, die ik kon uitrollen op Debian 9 of Fedora 27. De enige uitzondering is Alacritty. Het is een afstammeling van GPU-versnelde terminals en is voor deze taak geschreven in een ongebruikelijke en nieuwe taal: Rust. Ik heb webterminals uitgesloten van mijn beoordeling (inclusief die op ), omdat voorlopige tests hun extreem slechte prestaties aantoonden.
Unicode-ondersteuning
Ik begon mijn tests met Unicode-ondersteuning. De eerste test van de terminals was het weergeven van de Unicode-reeks van : “é, Δ, И, ק, م, ๗, あ, 叶, 葉 en 말.” Deze eenvoudige test laat zien of de terminal wereldwijd correct kan functioneren. xterm terminal geeft geen Arabisch karakter weer in standaardconfiguratie:
Standaard gebruikt xterm het klassieke "vaste" lettertype, dat volgens , heeft "substantiële Unicode-dekking sinds 1997". Er is iets aan de hand in dit lettertype waardoor het teken als een leeg kader verschijnt en pas wanneer het tekstlettertype wordt verhoogd tot 20+ punten, wordt het teken eindelijk correct weergegeven. Deze “oplossing” verbreekt echter de weergave van andere Unicode-tekens:
Deze schermafbeeldingen zijn gemaakt in Fedora 27, omdat het betere resultaten opleverde dan Debian 9, waar sommige oudere versies van terminals (met name mlterm) lettertypen niet goed konden verwerken. Gelukkig is dit in latere versies opgelost.
Merk nu op hoe de regel wordt weergegeven in xterm. Het blijkt dat het symbool Mem en het volgende Semitisch is zie scripts in RTL-stijl (), dus technisch gezien moeten ze van rechts naar links worden weergegeven. Webbrowsers zoals Firefox 57 verwerken bovenstaande regel correct. Een eenvoudigere versie van RTL-tekst is het woord "" in het Hebreeuws (). zegt het volgende:
“Veel computerprogramma's kunnen bidirectionele tekst niet correct weergeven. De Hebreeuwse naam "Sarah" bestaat bijvoorbeeld uit de letters sin (ש) (die aan de rechterkant verschijnt), vervolgens resh (ר) en tenslotte hij (ה) (die aan de linkerkant zou moeten verschijnen).
Veel terminals slagen niet voor deze test: Alacritty, VTE-afgeleide Gnome- en XFCE-terminals, urxvt, st en xterm geven "Sara" in omgekeerde volgorde weer, alsof we de naam als "Aras" hadden geschreven.
Een ander probleem met bidirectionele teksten is dat ze op de een of andere manier moeten worden uitgelijnd, vooral als het gaat om het mixen van RTL- en LTR-teksten. RTL-scripts moeten vanaf de rechterkant van het terminalvenster worden uitgevoerd, maar wat moet er gebeuren met terminals die standaard LTR English gebruiken? De meeste hebben geen speciale mechanismen en lijnen alle tekst links uit (ook in Konsole). De uitzonderingen zijn pterm en mlterm, die zich aan de normen houden en dergelijke lijnen rechts uitlijnen.
Bescherming tegen inbrengen
Het volgende cruciale kenmerk dat ik heb geïdentificeerd, is bescherming tegen inbrengen. Hoewel het algemeen bekend is dat spreuken als:
$ curl http://example.com/ | shzijn push-opdrachten voor het uitvoeren van code. Weinig mensen weten dat verborgen opdrachten de console kunnen binnensluipen bij het kopiëren en plakken vanuit een webbrowser, zelfs na zorgvuldige inspectie. laat op briljante wijze zien hoe onschuldig het commando lijkt:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitwordt zo hinderlijk als het van de website van Horn in de terminal wordt geplakt:
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.gitHoe het werkt? Schadelijke code is in het blok opgenomen , dat met CSS uit de weergave van de gebruiker wordt verplaatst.
is duidelijk bedoeld om dergelijke aanvallen te neutraliseren. In deze modus omsluiten terminals de geplakte tekst in een paar speciale escape-reeksen om de shell te vertellen over de oorsprong van de tekst. Dit vertelt de shell dat deze speciale tekens kan negeren die de geplakte tekst kan bevatten. Alle terminals terug naar de eerbiedwaardige xterm ondersteunen deze functie, maar plakken in de Bracketed-modus vereist ondersteuning van de shell of applicatie die op de terminal draait. Software die bijvoorbeeld gebruikt (dezelfde Bash), heeft een bestand nodig ~/.invoerrc:
set enable-bracketed-paste onHelaas laat de testsite van Horn ook zien hoe je deze bescherming kunt omzeilen via de tekstopmaak zelf en er voortijdig de Bracketed-modus op kunt toepassen. Dit werkt omdat sommige terminals escape-reeksen niet correct filteren voordat ze hun eigen reeksen toevoegen. In de mijne kon ik bijvoorbeeld nooit de Konsole-tests met succes voltooien, zelfs niet met de juiste configuratie .invoerrc bestand. Dit betekent dat uw systeemconfiguratie gemakkelijk beschadigd kan raken als gevolg van een niet-ondersteunde applicatie of een onjuist geconfigureerde shell. Dit is vooral gevaarlijk bij het inloggen op externe servers, waar zorgvuldig configuratiewerk minder gebruikelijk is, vooral als u veel van dergelijke externe machines heeft.
Een goede oplossing voor dit probleem is de plakbevestigingsplug-in voor de terminal uxvt, dat eenvoudigweg toestemming vraagt om tekst in te voegen die nieuwe regels bevat. Ik heb geen veiliger optie gevonden voor de tekstaanval beschreven door Horn.
Tabbladen en profielen
Een populaire functie op dit moment is ondersteuning voor een interface met tabbladen, die we zullen definiëren als één terminalvenster met daarin verschillende andere terminals. Deze functie verschilt per terminal, en hoewel traditionele xterm-terminals helemaal geen tabbladen ondersteunen, hebben modernere terminal-incarnaties zoals Xfce Terminal, GNOME Terminal en Konsole deze functie wel. Urxvt ondersteunt ook tabbladen, maar alleen als u een plug-in gebruikt. Maar wat betreft tabbladondersteuning zelf is Terminator de onbetwiste leider: het ondersteunt niet alleen tabbladen, maar kan ook terminals in willekeurige volgorde rangschikken (zie onderstaande afbeelding).
Een ander kenmerk van Terminator is de mogelijkheid om deze tabbladen te "groeperen" en dezelfde toetsaanslagen tegelijkertijd naar meerdere terminals te sturen, wat een ruw hulpmiddel biedt voor het tegelijkertijd uitvoeren van bulkbewerkingen op meerdere servers. Een soortgelijke functie is ook geïmplementeerd in Konsole. Om deze functie in andere terminals te gebruiken, moet u software van derden gebruiken, zoals , of .
Tabbladen werken vooral goed in combinatie met profielen: u kunt bijvoorbeeld één tabblad hebben voor e-mail, een ander voor chatten, enzovoort. Dit wordt goed ondersteund door Konsole Terminal en GNOME Terminal. Beide zorgen ervoor dat elk tabblad automatisch een eigen profiel kan starten. Terminator ondersteunt ook profielen, maar ik kon geen manier vinden om bepaalde programma's automatisch te starten wanneer een specifiek tabblad wordt geopend. Andere terminals kennen het concept ‘profiel’ helemaal niet.
Ruches
Het laatste dat ik in het eerste deel van dit artikel zal behandelen, is het uiterlijk van de terminals. GNOME, Xfce en urxvt ondersteunen bijvoorbeeld transparantie, maar hebben onlangs de ondersteuning voor achtergrondafbeeldingen stopgezet, waardoor sommige gebruikers gedwongen zijn over te schakelen naar de terminal . Persoonlijk ben ik er blij mee en het is eenvoudig xbronnen, waarmee de basisset achtergrondkleuren voor urxvt wordt ingesteld. Niet-standaard kleurthema's kunnen echter ook voor problemen zorgen. Bijvoorbeeld, met toepassingen и , omdat ze al hun eigen kleuren gebruiken.
ondersteunden geen kleuren, en nieuwe waren vaak beperkt tot een palet van 256 kleuren. Voor gevorderde gebruikers die hun terminals op een complexe manier vormgeven, kunnen shell-prompts of statusbalken een vervelende beperking zijn. houdt bij welke terminals "True Color"-ondersteuning hebben. Mijn tests bevestigen dat op st, Alacritty en VTE gebaseerde terminals True Color perfect ondersteunen. Andere terminals doen het in dit opzicht niet zo goed en geven zelfs niet eens 256 kleuren weer. Hieronder kun je het verschil zien tussen True Color-ondersteuning in GNOME-terminals, st en xterm, die dit goed doen met hun 256 kleurenpalet, en urxvt, dat niet alleen de test niet doorstaat, maar in plaats daarvan zelfs enkele knipperende tekens laat zien.
Sommige terminals analyseren ook tekst op URL-patronen om links klikbaar te maken. Dit geldt voor alle van VTE afgeleide terminals, terwijl urxvt een speciale plug-in vereist die URL's met één klik of met behulp van een sneltoets zou transformeren. Andere terminals Ik heb zichtbare URL's op andere manieren getest.
Een nieuwe trend op het gebied van terminals ten slotte is de optionele scrollbuffer. st heeft bijvoorbeeld geen scrollbuffer; Er wordt aangenomen dat de gebruiker een terminalmultiplexer zoals tmux en zal gebruiken .
Alacritty mist ook backscroll-buffers, maar zijn steun dankzij “uitgebreide feedback” over dit onderwerp van gebruikers. Afgezien van deze nieuwkomers ondersteunt elke terminal die ik heb getest en die ik kon vinden, omgekeerd scrollen.
subtotalen
In het tweede deel van het materiaal (in het origineel waren dit twee verschillende artikelen - ca. rijbaan) vergelijken we de prestaties, het geheugengebruik en de latentie. Maar we kunnen nu al zien dat sommige terminals in kwestie ernstige tekortkomingen vertonen. Gebruikers die regelmatig met RTL-scripts werken, willen bijvoorbeeld mlterm en pterm overwegen, omdat zij soortgelijke taken beter kunnen uitvoeren dan anderen. Konsole presteerde ook goed. Gebruikers die niet met RTL-scripts werken, kunnen voor iets anders kiezen.
In termen van bescherming tegen het invoegen van kwaadaardige code onderscheidt urxvt zich door de speciale implementatie van bescherming tegen dit soort aanvallen, wat mij zeker handig lijkt. Voor wie op zoek is naar wat toeters en bellen, is Konsole een kijkje waard. Ten slotte is het vermeldenswaard dat VTE een uitstekende basis is voor terminals, die kleurondersteuning, URL-herkenning, enzovoort garandeert. Op het eerste gezicht voldoet de standaardterminal die bij uw favoriete omgeving wordt geleverd aan alle vereisten, maar laten we deze vraag open laten totdat we de prestaties begrijpen.
We zetten het gesprek voort
Over het algemeen lijken de prestaties van terminals op zichzelf misschien een vergezocht probleem, maar het blijkt dat sommige ervan een verrassend hoge latentie vertonen voor software van een dergelijk fundamenteel type. Vervolgens zullen we ook kijken naar wat traditioneel “snelheid” wordt genoemd (in feite is dit de scrollsnelheid) en het geheugenverbruik van de terminal (met het voorbehoud dat dit vandaag de dag niet zo kritisch is als tientallen jaren geleden).
Vertraging
Na een grondige studie van de terminalprestaties kwam ik tot de conclusie dat de belangrijkste parameter in dit opzicht de latentie (ping) is. In zijn artikel Pavel Fatin keek naar de latentie van verschillende teksteditors en liet doorschemeren dat terminals in dit opzicht mogelijk langzamer zijn dan de snelste teksteditors. Het was deze hint die mij er uiteindelijk toe bracht mijn eigen tests uit te voeren en dit artikel te schrijven.
Maar wat is latentie en waarom is het zo belangrijk? In zijn artikel definieerde Fatin het als “de vertraging tussen het indrukken van een toets en de bijbehorende schermupdate” en citeerde hij dit , waarin staat: "De vertraging in visuele feedback op een computerscherm heeft een belangrijke impact op het gedrag en de tevredenheid van typisten."
Fatin legt uit dat deze ping diepere gevolgen heeft dan alleen bevrediging: “het typen wordt langzamer, er treden meer fouten op en de oog- en spierspanning neemt toe.” Met andere woorden: een grote vertraging kan leiden tot typefouten en ook tot een lagere codekwaliteit, omdat dit leidt tot extra cognitieve belasting van de hersenen. Maar wat nog erger is, is dat ping ‘de oog- en spierspanning verhoogt’, wat lijkt te impliceren in de toekomst (Blijkbaar bedoelt de auteur problemen met de spieren van de ogen, rug, armen en natuurlijk het gezichtsvermogen - ongeveer. rijbaan) als gevolg van herhaalde stress.
Sommige van deze effecten zijn al lang bekend, en de resultaten ervan , gepubliceerd in 1976 in het tijdschrift Ergonomics, zei dat een vertraging van 100 milliseconden "de typsnelheid aanzienlijk schaadt". Meer recentelijk is de GNOME-gebruikershandleiding geïntroduceerd in 10 milliseconden, en als je verder gaat, dan laat zien dat 1 milliseconde ideaal is.
Fatin voerde zijn tests uit op teksteditors; hij creëerde een draagbaar instrument genaamd , waarmee ik ping in terminalemulators testte. Houd er rekening mee dat de test is uitgevoerd in de simulatiemodus: in werkelijkheid moeten we rekening houden met de latentie van zowel de invoer (toetsenbord, USB-controller, enz.) als de uitvoer (videokaartbuffer, monitor). Volgens Fatin is dit in typische configuraties ongeveer 20 ms. Als je over gamingapparatuur beschikt, kun je dit cijfer in slechts 3 milliseconden bereiken. Omdat we al zulke snelle hardware hebben, hoeft de applicatie geen eigen latentie toe te voegen. Het doel van Fatin is om de latentie van de applicatie op 1 milliseconde te brengen, of zelfs om zonder te kunnen bellen , hoe zit het? .
Hier zijn de resultaten van mijn metingen, evenals enkele resultaten van Fatin, om aan te tonen dat mijn experiment overeenkomt met zijn tests:
Het eerste dat mij opviel was de betere responstijd van oudere programma's zoals xterm en mlterm. Met de slechtste registerlatentie (2,4 ms) presteerden ze beter dan de snelste moderne terminal (10,6 ms voor st). Geen enkele moderne terminal komt onder de drempel van 10 milliseconden. In het bijzonder slaagt Alacritty er niet in om te voldoen aan de claim van "snelste beschikbare terminalemulator", hoewel de scores zijn verbeterd sinds de eerste beoordeling in 2017. Inderdaad, de auteurs van het project en werken eraan om de weergave te verbeteren. Er moet ook worden opgemerkt dat Vim die GTK3 gebruikt een orde van grootte langzamer is dan zijn GTK2-tegenhanger. Hieruit kunnen we concluderen dat GTK3 extra latentie creëert, en dit wordt weerspiegeld in alle andere terminals die er gebruik van maken (Terminator, Xfce4 Terminal en GNOME Terminal).
De verschillen zijn echter mogelijk niet waarneembaar voor het oog. Zoals Fatin uitlegt: “Je hoeft je niet bewust te zijn van de vertraging om effect op je te hebben.” Fatin waarschuwt ook voor de standaarddeviatie: “elke verstoring van de latentie (jitter) zorgt vanwege hun onvoorspelbaarheid voor extra stress.”
De bovenstaande grafiek is genomen op pure Debian 9 (stretch). . Deze omgeving levert de beste resultaten op bij latentietests. Het blijkt dat GNOME voor alle metingen een extra ping van 20 ms creëert. Een mogelijke verklaring hiervoor is de aanwezigheid van programma's met synchrone verwerking van invoergebeurtenissen. Fatin geeft een voorbeeld van zo’n geval , wat een vertraging toevoegt door alle invoergebeurtenissen synchroon te verwerken. Standaard wordt GNOME ook geleverd met een vensterbeheerder , waardoor een extra bufferlaag ontstaat, die de ping beïnvloedt en minimaal 8 milliseconden latentie toevoegt.
Scrollsnelheid
De volgende test is een traditionele "snelheids"- of "bandbreedte"-test, die meet hoe snel de terminal door een pagina kan scrollen terwijl er grote hoeveelheden tekst op het scherm worden weergegeven. De werking van de test varieert; de oorspronkelijke test was om eenvoudigweg dezelfde tekstreeks te genereren met behulp van de opdracht seq. Andere tests zijn onder meer de test van Thomas E. Dickey (xterm-onderhouder), die herhaaldelijk wordt uitgevoerd . In een andere recensie van terminalprestaties gebruikt een base32-gecodeerde reeks willekeurige bytes, die naar de terminal wordt uitgevoerd met behulp van cat. Luu beschouwt een dergelijke test als "een zo nutteloze benchmark als je je kunt voorstellen" en stelt voor om in plaats daarvan de terminale respons als primaire maatstaf te gebruiken. Dickey noemt zijn test ook misleidend. Beide auteurs erkennen echter dat de bandbreedte van het terminalvenster een probleem kan zijn. Luu ontdekte dat Emacs Eshell vastliep bij het weergeven van grote bestanden, en Dickey optimaliseerde de terminal om de visuele traagheid van xtrerm te elimineren. Er zit dus nog steeds enige verdienste in deze test, maar aangezien het weergaveproces van terminal tot terminal sterk verschilt, kan het ook als testcomponent worden gebruikt om andere parameters te testen.
Hier zien we de rxvt en st een voorsprong nemen op de concurrentie, gevolgd door de veel nieuwere Alacritty, die is ontworpen met de nadruk op prestaties. De volgende zijn Xfce (VTE-familie) en Konsole, die bijna twee keer zo snel zijn. Als laatste is xterm, dat vijf keer langzamer is dan rxvt. Tijdens de test golfde xterm ook veel, waardoor passerende tekst moeilijk te zien was, zelfs als het dezelfde regel was. Konsole was snel, maar soms was het lastig: het scherm liep af en toe vast, waardoor gedeeltelijke tekst werd weergegeven of helemaal niet. Andere terminals gaven strings duidelijk weer, waaronder st, Alacritty en rxvt.
Dickey legt uit dat de prestatieverschillen te wijten zijn aan het ontwerp van scrollbuffers in verschillende terminals. In het bijzonder beschuldigt hij rxvt en andere terminals ervan "de algemene regels niet te volgen":
“In tegenstelling tot xterm heeft rxvt niet geprobeerd alle updates weer te geven. Als het achterop raakt, zal het enkele updates weigeren om de achterstand in te halen. Dit had een grotere impact op de schijnbare scrollsnelheid dan op de interne geheugenorganisatie. Een nadeel was dat de ASCII-animatie enigszins onnauwkeurig was."
Om deze waargenomen xterm-traagheid op te lossen, stelt Dickey voor om de bron te gebruiken , waardoor xterm enkele schermupdates kan negeren om de stroom bij te houden. Mijn tests bevestigen dat fastScroll de prestaties verbetert en xterm op één lijn brengt met rxvt. Dit is echter een nogal ruwe kruk, zoals Dickey zelf uitlegt: "soms lijkt xterm - net als konsole - vast te lopen terwijl het wacht op een nieuwe reeks schermupdates nadat sommige zijn verwijderd." In deze geest lijkt het erop dat andere terminals het beste compromis hebben gevonden tussen snelheid en weergave-integriteit.
Het verbruik van hulpbronnen
Ongeacht of het zinvol is om de scrollsnelheid als prestatiemaatstaf te beschouwen, deze test stelt ons in staat de belasting van de terminals te simuleren, waardoor we op zijn beurt andere parameters zoals geheugen- of schijfgebruik kunnen meten. De statistieken zijn verkregen door de opgegeven test uit te voeren seq onder Python-procesbewaking. Hij verzamelde metergegevens voor ru_maxrss, hoeveelheid ru_oublock и ru_inblock en een eenvoudige timer.
In deze test staat de ST op de eerste plaats met het laagste gemiddelde geheugenverbruik van 8 MB, wat niet verrassend is gezien het feit dat het hoofdidee van het ontwerp eenvoud is. mlterm, xterm en rxvt verbruiken iets meer - ongeveer 12 MB. Een ander opmerkelijk resultaat is Alacritty, waarvoor 30 MB nodig is om te kunnen werken. Dan zijn er terminals van de VTE-familie met cijfers van 40 tot 60 MB, wat behoorlijk veel is. Dit verbruik kan worden verklaard door het feit dat deze terminals bibliotheken van een hoger niveau gebruiken, bijvoorbeeld GTK. Konsole komt op de laatste plaats met maar liefst 65 MB geheugengebruik tijdens tests, hoewel dit kan worden gerechtvaardigd door het zeer brede scala aan functies.
Vergeleken met eerdere resultaten van tien jaar geleden begonnen alle programma's merkbaar meer geheugen te verbruiken. Xterm had vroeger 4 MB nodig, maar nu is er al bij het opstarten 15 MB nodig. Er is een vergelijkbare toename in het verbruik voor rxvt, waarvoor nu kant-en-klaar 16 MB nodig is. Xfce Terminal neemt 34 MB in beslag, wat drie keer groter is dan voorheen, maar GNOME Terminal heeft slechts 20 MB nodig. Uiteraard zijn alle eerdere tests uitgevoerd op 32-bits architectuur. Op LCA 2012 Rusty Russell , dat er veel subtielere redenen zijn die de toename van het geheugengebruik zouden kunnen verklaren. Dat gezegd hebbende, leven we nu in een tijd waarin we gigabytes aan geheugen hebben, dus we zullen het op de een of andere manier wel redden.
Ik kan echter niet anders dan het gevoel hebben dat het toewijzen van meer geheugen aan zoiets fundamenteels als de terminal een verspilling van middelen is. Deze programma's zouden de kleinste van de kleinste moeten zijn, zouden op elke “doos” moeten kunnen draaien, zelfs een schoenendoos, als we ooit op het punt komen waarop ze moeten worden uitgerust met Linux-systemen (en je weet dat dat zo zal zijn). ). Maar met deze cijfers zal geheugengebruik in de toekomst een probleem worden in elke omgeving met meerdere terminals, afgezien van enkele van de lichtste en meest beperkte mogelijkheden. Om dit te compenseren hebben GNOME Terminal, Konsole, urxvt, Terminator en Xfce Terminal een Daemon-modus waarmee u meerdere terminals via één enkel proces kunt besturen, waardoor hun geheugengebruik wordt beperkt.
Tijdens mijn tests kwam ik tot een ander onverwacht resultaat met betrekking tot het lezen en schrijven van schijven: ik had verwacht hier helemaal niets te zien, maar het bleek dat sommige terminals de meest omvangrijke gegevens naar schijf schrijven. De VTE-bibliotheek houdt dus feitelijk een scrollbuffer op schijf bij (deze functie en dit gebeurt nog steeds). Maar in tegenstelling tot oudere implementaties worden deze gegevens nu tenminste gecodeerd met AES256 GCM (). Maar er rijst een redelijke vraag: wat is er zo speciaal aan de VTE-bibliotheek dat deze een dergelijke niet-standaard benadering van implementatie vereist...
Conclusie
In het eerste deel van het artikel ontdekten we dat op VTE gebaseerde terminals over een goede reeks functies beschikken, maar nu zien we dat dit gepaard gaat met prestatiekosten. Nu is geheugen geen probleem meer, omdat alle VTE-terminals kunnen worden bestuurd via een Daemon-proces, wat hun eetlust beperkt. Oudere systemen met fysieke beperkingen op de hoeveelheid RAM en kernelbuffers hebben echter mogelijk nog steeds eerdere versies van terminals nodig, omdat deze aanzienlijk minder bronnen verbruiken. Hoewel VTE-terminals goed presteerden in doorvoertests (scrolltests), ligt hun weergavelatentie boven de drempel die is ingesteld in de GNOME-gebruikershandleiding. VTE-ontwikkelaars moeten hier waarschijnlijk rekening mee houden. Als we er rekening mee houden dat zelfs voor beginnende Linux-gebruikers het tegenkomen van een terminal onvermijdelijk is, kunnen ze deze gebruiksvriendelijker maken. Voor ervaren nerds kan het overstappen van de standaardterminal zelfs minder vermoeide ogen betekenen en de mogelijkheid om toekomstige werkgerelateerde verwondingen en ziektes als gevolg van lange werksessies te voorkomen. Helaas brengen alleen de oude xterm en mlterm ons naar de magische ping-drempel van 10 milliseconden, wat voor velen onaanvaardbaar is.
Uit benchmarkmetingen bleek ook dat ontwikkelaars door de ontwikkeling van grafische Linux-omgevingen een aantal compromissen moesten sluiten. Sommige gebruikers willen misschien naar gewone vensterbeheerders kijken, omdat deze een aanzienlijke pingreductie bieden. Helaas was het niet mogelijk om de latentie voor Wayland te meten: het Typometer-programma dat ik gebruikte, is gemaakt voor wat Wayland is ontworpen om te voorkomen: het bespioneren van andere vensters. Ik hoop dat Wayland-compositing beter presteert dan X.org, en ik hoop ook dat iemand in de toekomst een manier zal vinden om de latentie in deze omgeving te meten.
Bron: www.habr.com