Een paar woorden van ons vertaalbureau: meestal proberen we de meest recente materialen en publicaties te vertalen, en we zijn daar geen uitzondering op. Maar terminalen zijn niet iets dat elke week vernieuwd wordt. Daarom hebben we het artikel van Antoine Bopre, dat in de lente van 2018 is gepubliceerd, voor u vertaald: ondanks de aanzienlijke 'leeftijd' volgens moderne maatstaven, is het materiaal naar onze mening absoluut nog relevant. Bovendien is het origineel een serie van twee artikelen, maar we hebben besloten ze in één groot bericht te combineren.
Terminalen nemen een bijzondere plek in de computerhistorie in, maar in de afgelopen decennia hebben ze zich 'moeten' aanpassen aan de commandoregel, terwijl grafische interfaces overal om hen heen opkwamen. vervangen hun , die op hun beurt weer een afgeleide waren van systemen op ponskaarten en tuimelschakelaars. Moderne distributies worden geleverd met een heleboel terminalemulators in allerlei vormen en kleuren. En terwijl velen rustig tevreden zijn met de standaardterminal die door hun werkomgeving wordt aangeboden, gebruiken sommigen met trots openlijk exotische software om hun favoriete shell of tekstverwerker te draaien. Maar zoals we in dit artikel zullen zien, zijn niet alle terminalen op dezelfde manier ontworpen: ze verschillen aanzienlijk in functionaliteit, grootte en prestaties.
Sommige terminalen hebben verbazingwekkende beveiligingslekken, bovendien heeft de meerderheid een totaal verschillend functieset, van ondersteuning voor tabbladen tot scripts. Hoewel we , is dit artikel een update van het vorige materiaal dat lezers helpt te bepalen welke terminal ze in 2018 moeten gebruiken. In de eerste helft van het artikel worden de functies vergeleken, en in de tweede helft wordt de prestaties beoordeeld.
Hier zijn de terminalen die ik heb bekeken:
Misschien zijn dit niet de meest recente versies, aangezien ik me heb beperkt tot stabiele builds op het moment van schrijven, die ik met succes heb geïnstalleerd op Debian 9 of Fedora 27. De enige uitzondering is Alacritty. Het is een afstammeling van terminals met GPU-versnelling en is geschreven in een ongebruikelijke en nieuwe taal voor deze taak — Rust. Ik heb webterminals (inclusief die op ) uitgesloten omdat voorlopige tests hun extreem lage prestaties aantoonde.
Unicode-ondersteuning
Ik begon mijn tests met Unicode-ondersteuning. De eerste test van de terminals was het weergeven van een Unicode-rij van : «é, Δ, Й, ק, م, ๗, あ, 叶, 葉 en 말». Deze eenvoudige test toont aan of de terminal correct kan functioneren over de hele wereld. De xterm-terminal geeft het Arabische teken niet weer in de standaardconfiguratie:
Standaard gebruikt xterm het klassieke 'fixed' lettertype, dat volgens «een significante dekking van Unicode sinds 1997» heeft. In dit lettertype gebeurt er iets dat ervoor zorgt dat het teken wordt weergegeven als een lege doos en pas wanneer de tekstgrootte tot 20+ punten wordt vergroot, begint het teken eindelijk correct weer te geven. Dit soort 'fix' verstoort echter de weergave van andere Unicode-tekens:
Deze screenshots zijn gemaakt in Fedora 27, aangezien deze betere resultaten bood dan Debian 9, waar sommige oudere versies van terminals (specifiek — mlterm) niet goed konden omgaan met lettertypen. Gelukkig is dit opgelost in latere versies.
Let nu op de weergave van de rij in xterm. Blijkt dat het teken Mem en het volgende Semitische tot de rechts-naar-links schrijfwijzen behoren (), dus technisch gezien moeten ze van rechts naar links worden weergegeven. Webbrowser, zoals Firefox 57, behandelt de bovenstaande rij correct. Een eenvoudigere vorm van RTL-tekst is het woord «» in het Hebreeuws (). zegt het volgende:
«Veel computerprogramma's kunnen bidirectionele tekst niet correct weergeven. Bijvoorbeeld, de Hebreeuwse naam 'Sara' bestaat uit de letters sin (ש) (die rechts verschijnt), dan resh (ר) en tenslotte he (ה) (die links moet verschijnen)».
Veel terminals slagen niet voor deze test: Alacritty, Gnome en XFCE afgeleide VTE-terminals, urxvt, st en xterm tonen "Sara" in omgekeerde volgorde, alsof we deze naam als "Aras" hebben geschreven.
Een ander probleem met bidirectionele teksten is dat ze op de een of andere manier moeten worden uitgelijnd, vooral als het gaat om mengeling van RTL en LTR-teksten. RTL-scripts moeten aan de rechterkant van het terminalvenster beginnen, maar wat moet er gebeuren voor terminals die standaard met LTR-Engels werken? De meeste hebben geen speciale mechanismen en lijnen de hele tekst links uit (inclusief in Konsole). Uitzonderingen zijn pterm en mlterm, die zich aan de standaarden houden en dergelijke regels rechts uitlijnen.
Bescherming tegen plakken
De volgende kritische functie die ik voor mezelf heb vastgesteld, is de bescherming tegen plakken. Hoewel algemeen bekend is dat commando's zoals:
$ curl http://example.com/ | shuitvoerbare code push-commando's zijn, weet weinig mensen dat verborgen commando's de console kunnen binnendringen bij het kopiëren-plakken vanuit een webbrowser, zelfs na zorgvuldige inspectie. toont perfect aan hoe een ogenschijnlijk onschuldige opdracht:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitbij het plakken vanuit Horne's site in de terminal zo'n probleem kan veroorzaken:
git clone /dev/null;
clear;
echo -n "Hallo ";
whoami|tr -d 'n';
echo -e '!nDat was een slecht idee. Kopieer geen code van websites die je niet vertrouwt!
Hier is de eerste regel van je /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitHoe werkt dit? Kwaadaardige code wordt in een blok , dat uit het gezichtsveld van de gebruiker wordt verplaatst met behulp van CSS.
is duidelijk ontworpen om dergelijke aanvallen te neutraliseren. In deze modus omhullen terminals de ingevoegde tekst in een paar speciale escape-sequenties om de shell over de oorsprong van deze tekst te informeren. Zo krijgt de shell het signaal dat het speciale tekens kan negeren die mogelijk in de ingevoerde tekst aanwezig zijn. Alle terminals, tot aan de eerbiedwaardige xterm, ondersteunen deze functie, maar plakken in Bracketed-modus vereist ondersteuning van de shell of applicatie die op de terminal draait. Bijvoorbeeld, software die gebruik maakt van (dezelfde Bash), heeft een bestand nodig ~ /.inputrc:
set enable-bracketed-paste onHelaas toont de testsite van Horna ook hoe je deze beveiliging kunt omzeilen via de opmaak van de tekst en voortijdig het gebruik van de Bracketed-modus kunt beëindigen. Dit werkt omdat sommige terminals escape-sequenties niet correct filteren voordat ze hun eigen toevoegen. Bijvoorbeeld, in mijn geval kon ik de tests van Konsole niet succesvol afsluiten, zelfs niet met een correcte configuratie. .inputrc bestand. Dit betekent dat je gemakkelijk beschadigingen aan de systeemconfiguratie kunt oplopen door een niet-ondersteund programma of een foutief geconfigureerde shell. Dit is vooral gevaarlijk bij toegang tot externe servers, waar een zorgvuldige configuratie minder gebruikelijk is, zeker als je veel van zulke externe machines hebt.
Een goede oplossing voor dit probleem is de invoegtoepassing voor knippen en plakken voor de terminal urxvt, die gewoon om toestemming vraagt voor het plakken van elke tekst die nieuwe regels bevat. Een veiligere optie voor de tekstaanval zoals beschreven door Horna heb ik niet gevonden.
Tabs en profielen
Een momenteel populaire functie is de ondersteuning van een tabbladinterface, die we zouden definiëren als één terminalvenster dat meerdere terminals bevat. Deze functie verschilt per terminal en hoewel traditionele terminals zoals xterm tabbladen helemaal niet ondersteunen, hebben modernere versies zoals Xfce Terminal, GNOME Terminal en Konsole deze functie wel. Urxvt ondersteunt ook tabs, maar alleen bij gebruik van een plug-in. Maar qua tabbladondersteuning is Terminator de onbetwiste leider: het ondersteunt niet alleen tabs, maar kan ook terminals in willekeurige volgorde plaatsen (zie afbeelding hieronder).
Een andere functie van Terminator is de mogelijkheid om deze tabs 'te groeperen' en dezelfde toetsindrukken naar meerdere terminals tegelijkertijd te sturen, wat een ruwe tool biedt voor het uitvoeren van massabewerkingen op meerdere servers tegelijkertijd. Een soortgelijke functie is ook geïmplementeerd in Konsole. Voor gebruik van deze functie in andere terminals is het nodig om externe software te gebruiken, zoals , of .
Tabs work especially well in conjunction with profiles: for instance, you might have one tab for email, another for chat, and so on. This is well supported by the Konsole and GNOME Terminal. Both allow each tab to automatically launch its profile. Terminator also supports profiles, but I couldn't find a way to automatically run specific programs when opening a certain tab. Other terminals do not even recognize the concept of a 'profile'.
Ruffles
The last thing I will consider in the first part of this article is the appearance of terminals. For example, GNOME, Xfce, and urxvt support transparency, but recently dropped support for background images, which forced some users to switch to another terminal. . Personally, I am fine with just Xresources, which sets the basic background color set for urxvt. However, non-standard color themes can also create issues. For instance, with applications en , as they already use their own colors.
did not support colors, while newer ones were often limited to a 256-color palette. For advanced users who style their terminals in complex ways, shell requests or status lines can become a frustrating limitation. tracks which terminals have 'True Color' support. My tests confirm that st, Alacritty, and VTE-based terminals handle True Color very well. Other terminals are not doing well in this regard and actually do not display even 256 colors. Below you can see the difference in True Color support among GNOME, st, and xterm terminals, which perform decently with their 256-color palette, compared to urxvt, which not only fails the test but even shows some flickering characters instead.
Some terminals also analyze text for URL patterns to make links clickable. This applies to all VTE-derived terminals, while urxvt requires a special plugin that transforms URLs on click or via a keyboard shortcut. Other terminals I tested display URLs in different ways.
Ten slotte is een nieuwe trend bij terminals de optionele scrollbuffer. Bijvoorbeeld, in st is er geen scrollbuffer; het is de bedoeling dat de gebruiker een terminalmultiplexer zoals tmux gebruikt en .
Bij Alacritty ontbreken ook de reverse scrollbuffers, maar ondersteuning door 'uitgebreide feedback' van gebruikers over dit onderwerp. Behalve deze uitzonderingen ondersteunt elke terminal die ik heb onderzocht om te vinden, terugscrollen.
Tussenstand
In het tweede deel van het materiaal (in het origineel waren dit twee verschillende artikelen, — opmerking van de vertaler.) vergelijken we de prestaties, geheugengebruik en latentie. Maar we zien al dat sommige van de onderzochte terminals ernstige tekortkomingen vertonen. Gebruikers die regelmatig met RTL-scripts werken, kunnen letten op mlterm en pterm, omdat zij beter met deze taken omgaan. Konsole heeft zich ook goed bewezen. Gebruikers die niet met RTL-scripts werken, kunnen iets anders kiezen.
Vanuit het perspectief van bescherming tegen het injecteren van malware steekt urxvt er met zijn unieke implementatie van bescherming tegen dit soort aanvallen met kop en schouders bovenuit, wat ik zeker handig vind. Degenen die op zoek zijn naar enkele franje, moeten naar Konsole kijken. Tot slot moet opgemerkt worden dat VTE een uitstekende basis biedt voor terminals, die ondersteuning voor kleuren, URL-herkenning, enzovoorts garandeert. Op het eerste gezicht lijkt de standaardterminal die met je favoriete omgeving wordt geleverd aan alle eisen te voldoen, maar laten we deze kwestie openlaten totdat we de prestaties hebben beoordeeld.
Laten we het gesprek voortzetten
Over het algemeen lijkt de prestatie van terminals een probleem te zijn dat te veel aandacht krijgt, maar zoals bleek, vertonen sommige van hen verrassend veel latentie voor software van zo'n fundamentele aard. Verder zullen we kijken naar wat traditioneel 'snelheid' wordt genoemd (in feite is dit de scrollsnelheid) en het geheugenverbruik van de terminal (met de kanttekening dat dit tegenwoordig niet zo kritisch is als decennia geleden).
Vertraging
Na grondig onderzoek naar de prestaties van terminals ben ik tot de conclusie gekomen dat de belangrijkste parameter op dit gebied de grootte van de latentie (ping) is. In mijn artikel Pavel Fatin examined the delay of various text editors and hinted that terminals might operate slower than the fastest text editors. This hint ultimately led me to run my own tests and write this article.
But what is delay, and why is it so important? In his article, Fatin defined it as "the delay between pressing a key and the corresponding update on the screen" and quoted , which states: "The delay in visual feedback on a computer display has a significant impact on the typist's behavior and their satisfaction."
Fatin explains that such ping has deeper consequences than just satisfaction: "typing becomes slower, more errors occur, and eye and muscle tension increases." In other words, greater delay can lead to typos and reduced code quality, as it adds cognitive load on the brain. But worse still, ping "increases eye and muscle tension," which apparently implies in the future (presumably, the author refers to issues with eye muscles, back, hands, and, of course, vision — note from the translator.) due to repetitive strain.
Some of these effects have been known for a long time, and the results , published as early as 1976 in the journal Ergonomics, indicate that a delay of 100 milliseconds "significantly impairs typing speed." Recently, the GNOME user guide included of 10 milliseconds, and if we go further, shows that the ideal is 1 millisecond.
Fatin conducted his tests on text editors; he created a portable tool called , die ik heb gebruikt om de ping in terminalemulators te controleren. Houd er rekening mee dat de test werd uitgevoerd in simulatiemodus: in werkelijkheid moeten we ook de invoervertraging (toetsenbord, USB-controller, enzovoort) en uitvoervertraging (videokaartbuffer, monitor) in aanmerking nemen. Volgens Fatin ligt deze bij typische configuraties rond de 20 ms. Met gamingapparatuur kan dit tot slechts 3 milliseconden worden verlaagd. Aangezien we al zo'n snelle apparatuur hebben, zou de applicatie geen extra vertraging moeten introduceren. Fatins doel is om de applicatietijd te laten dalen tot 1 milliseconde of zelfs een set zonder , zoals in .
Hier zijn de resultaten van mijn metingen, evenals enkele resultaten van Fatin om aan te tonen dat mijn experiment in overeenstemming is met zijn tests:
Het eerste dat me opviel, was de betere responstijd van oude programma's zoals xterm en mlterm. Ondanks de slechtste registratietijd (2,4 ms) lieten zij betere resultaten zien dan de snelste moderne terminal (10,6 ms voor st). Geen enkele moderne terminal komt onder de drempel van 10 milliseconden. In het bijzonder voldoet Alacritty niet aan de eisen van 'snelste terminal emulator die er bestaat', hoewel de resultaten zijn verbeterd sinds de eerste controle in 2017. De auteurs van het project en werken aan verbeteringen in de weergave. Ook is het belangrijk om op te merken dat Vim, dat GTK3 gebruikt, aanzienlijk trager is dan zijn GTK2-tegenhanger. Hieruit kunnen we concluderen dat GTK3 extra vertraging introduceert, wat invloed heeft op alle andere terminals die het gebruiken (Terminator, Xfce4 Terminal en GNOME Terminal).
Echter, voor het oog kunnen de verschillen onopgemerkt blijven. Zoals Fatin uitlegt: 'het is niet nodig om zich bewust te zijn van een vertraging om effect op je te hebben'. Fatin wijst ook op de standaardafwijking: 'elke schommeling in de duur van de vertraging (trilling) creëert extra belasting door hun onvoorspelbaarheid'.
De bovenstaande grafiek is verkregen op een schone Debian 9 (stretch) met . Deze omgeving levert de beste resultaten in latency-testen. Blijkbaar creëert GNOME een extra ping van 20 ms voor alle metingen. Een mogelijke verklaring hiervoor is de aanwezigheid van programma's die input-events synchroon verwerken. Fatin geeft hiervoor een voorbeeld. , dat vertraging toevoegt door alle input-events synchroon te verwerken. Standaard is GNOME ook uitgerust met de vensterbeheerder , die een extra bufferingsniveau creëert, wat invloed heeft op de ping en minimaal 8 milliseconden vertraging toevoegt.
Scrollsnelheid
De volgende test is een traditionele controle van de "snelheid" of "bandbreedte", die meet hoe snel een terminal een pagina kan scrollen door een grote hoeveelheid tekst op het scherm weer te geven. De testmechanica varieert; de originele test bestond eruit om simpelweg dezelfde tekstregel te genereren met de seq-opdracht. Andere tests omvatten de controle van Thomas E. Dick (de begeleidende xterm), waarbij herhaaldelijk In een andere beoordeling van terminalprestaties gebruikt een string van willekeurige bytes in base32-codering, die wordt weergegeven in de terminal met behulp van cat. Luu beschouwt deze test als "zo'n nutteloze benchmark als je je maar kunt voorstellen" en stelt voor om in plaats daarvan de respons van de terminal als belangrijkste indicator te gebruiken. Dick noemt zijn test ook misleidend. Desondanks erkennen beide auteurs dat de bandbreedte van het terminalvenster een probleem kan zijn. Luu ontdekte een bevriezing van Emacs Eshell bij het weergeven van grote bestanden, terwijl Dick de terminal optimaliseerde om de visuele traagheid van xterm te verhelpen. Daarom is er in deze test nog steeds enige reden om het te gebruiken, maar aangezien het rendert proces sterk varieert van terminal tot terminal, kan het ook worden gebruikt als een testcomponent om andere parameters te controleren.
Hier zien we dat rxvt en st de concurrentie voorblijven, gevolgd door het veel recentere Alacritty, dat is ontwikkeld met een focus op snelheid. Vervolgens komen Xfce (VTE-familie) en Konsole, die bijna twee keer zo snel werken. Laatst is xterm met een score die vijf keer langzamer is dan rxvt. Tijdens de test vertoonde xterm ook veel rimpeling, de doorlopende tekst was moeilijk te onderscheiden, zelfs als het dezelfde regel was. Konsole bleek snel te zijn, maar ‘bedrogde’ soms: het scherm bevroor af en toe, waardoor de tekst gedeeltelijk of helemaal niet werd weergegeven. Andere terminals gaven de regels duidelijk weer, waaronder st, Alacritty en rxvt.
Diki legt uit dat de verschillen in prestaties te maken hebben met het ontwerp van de scrolbuffers in verschillende terminals. In het bijzonder beschuldigt hij rxvt en andere terminals ervan dat ze "niet de algemene regels volgen":
„In tegenstelling tot xterm, probeerde rxvt niet alle updates weer te geven. Als hij achterbleef, zou hij sommige updates negeren om het in te halen. Dit had een grotere invloed op de schijnbare snelheid van de scroll dan op de organisatie van het interne geheugen. Een nadeel was dat de ASCII-animatie enigszins onnauwkeurig was.”
Om deze schijnbare traagheid van xterm te verhelpen, stelt Diki voor om de hulpbron te gebruiken, waarmee xterm sommige schermupdates kan negeren om niet achter te raken op de stroom. Mijn tests bevestigen dat fastScroll de prestaties verbetert en xterm op een niveau brengt met rxvt. Dit is echter een vrij brutale oplossing, zoals Diki zelf uitlegt: ‘soms lijkt xterm - net als konsole - stil te staan, omdat hij wacht op een nieuwe set schermupdates, nadat sommige zijn verwijderd.’ In dit licht lijkt het erop dat andere terminals de beste compromis hebben gevonden tussen snelheid en de integriteit van het display.
Hulpgebruik
Ongeacht de doeltreffendheid van het overwegen van de scrollsnelheid als prestatiemetriek, maakt deze test het mogelijk om de belasting op de terminals te simuleren, wat op zijn beurt ons in staat stelt om andere parameters te meten, zoals het gebruik van geheugen of schijf. De metrieken zijn verkregen door de gespecificeerde test uit te voeren seq onder procesmonitoring van Python. Dit verzamelde gegevens van de tellers voor ru_maxrss, de som ru_oublock en ru_inblock en een eenvoudige tijdtimer.
In deze test staat ST op de eerste plaats met het laagste gemiddelde geheugengebruik van 8 MB, wat niet verwonderlijk is gezien het hoofddoel van het project eenvoud is. Iets meer verbruiken mlterm, xterm en rxvt — ongeveer 12 MB. Een andere opvallende uitkomst is Alacritty, dat 30 MB vereist om te functioneren. Vervolgens komen de terminals van het VTE-boek met verbruiken van 40 tot 60 MB, wat vrij veel is. Dit grote verbruik kan worden verklaard doordat deze terminals gebruikmaken van complexere bibliotheken, zoals GTK. Konsole eindigt als laatste met een enorm verbruik van 65 MB geheugen tijdens de tests, hoewel dit verantwoord kan worden door de uitgebreide set functionaliteiten.
In vergelijking met de eerdere resultaten van tien jaar geleden, verbruiken alle programma's nu aanzienlijk meer geheugen. Voorheen vereiste Xterm 4 MB, en nu 15 MB alleen al voor het opstarten. Een soortgelijke toename in verbruik is ook zichtbaar bij rxvt, dat nu standaard 16 MB vereist. De Xfce-terminal verbruikt 34 MB, wat drie keer zoveel is als vroeger, terwijl GNOME Terminal slechts 20 MB vereist. Natuurlijk zijn alle eerdere tests uitgevoerd op een 32-bits architectuur. Op LCA 2012 zei Rusty Russell. , dat er talloze subtiele redenen zijn die de toename van het geheugengebruik kunnen verklaren. Desondanks leven we in een tijd waarin we beschikken over hele gigabytes aan geheugen, dus we zullen er wel mee omgaan.
Desondanks kan ik de indruk niet loslaten dat het toewijzen van meer geheugen aan zo'n fundamenteel stuk software als een terminal een verspilling van middelen is. Deze programma's zouden de kleinste van de kleinste moeten zijn, in staat om op elke "doos" te draaien, zelfs een schoendoos, als we ooit zover komen dat ze uitgerust moeten worden met Linux-systemen (en je weet dat dat zal gebeuren). Maar met deze cijfers wordt geheugengebruik in de toekomst een probleem in elke omgeving bij het draaien van meerdere terminals, behalve in de situatie met een paar van de lichtste en meest beperkte opties. Om dit te compenseren hebben GNOME Terminal, Konsole, urxvt, Terminator en Xfce Terminal een daemon-modus, waarmee meerdere terminals via één proces kunnen worden beheerd, wat hun geheugengebruik beperkt.
Tijdens mijn tests kwam ik tot een onverwacht resultaat met betrekking tot de schijfleessnelheid: ik verwachtte hier helemaal niets te zien, maar het blijkt dat sommige terminals de grootste hoeveelheden gegevens op de schijf schrijven. Zo houdt de VTE-bibliotheek feitelijk een scrollbuffer op de schijf (dit kenmerk , en dit gebeurt nog steeds). Maar in tegenstelling tot oude implementaties zijn deze gegevens nu ten minste versleuteld met AES256 GCM (). Maar er rijst een legitieme vraag: wat is er zo bijzonder aan de VTE-bibliotheek dat deze een dergelijke ongewone aanpak voor implementatie vereist…
Conclusie
In het eerste deel van het artikel ontdekten we dat terminals op basis van VTE een goede set functies hebben, maar nu zien we dat dit gepaard gaat met bepaalde kosten om hun prestaties te waarborgen. Momenteel is geheugen geen probleem, omdat alle VTE-terminals kunnen worden beheerd via een Daemon-proces dat hun behoeften beperkt. Desondanks kunnen oudere systemen, die fysieke beperkingen hebben ten aanzien van de hoeveelheid RAM en kernelbuffer, nog steeds behoefte hebben aan eerdere versies van terminals, omdat deze aanzienlijk minder middelen verbruiken. Hoewel VTE-terminals goed presteerden in tests op doorvoersnelheid (scrollen), ligt de vertragingsweergave van gegevens op het scherm boven de vastgestelde drempel in de gebruikershandleiding van GNOME. Vermoedelijk moeten de ontwikkelaars van VTE hier rekening mee houden. Gezien het feit dat zelfs voor beginnende Linux-gebruikers een ontmoeting met de terminal onontkoombaar is, kunnen ze het gebruiksvriendelijker maken. Voor ervaren gebruikers kan de overgang van de standaardterminal zelfs een vermindering van de belasting van de ogen betekenen en de mogelijkheid bieden om professionele verwondingen en aandoeningen in de toekomst te vermijden door langdurige werkuren. Helaas brengen alleen de oudere xterm en mlterm ons naar de magische pingdrempel van 10 milliseconden, wat voor velen onaanvaardbaar is.
Controlemetingen hebben ook aangetoond dat ontwikkelaars door de ontwikkeling van grafische omgevingen in Linux een aantal compromissen moesten sluiten. Sommige gebruikers zouden moeten kijken naar de reguliere windowmanagers, aangezien deze een aanzienlijke vermindering van de ping bieden. Helaas kon ik voor Wayland de vertraging niet meten: het programma Typometer dat ik gebruikte, was ontworpen om precies dat te voorkomen waar Wayland voor bedoeld is — het bespioneren van andere vensters. Ik hoop dat de compositing van Wayland qua prestaties beter is dan X.org, en ik hoop ook dat in de toekomst iemand een manier vindt om het niveau van vertraging in deze omgeving te evalueren.
Bron: habr.com
