Översikt över terminalemulatorer

Ett par ord från vårt översättningskontor: vanligtvis strävar alla efter att översätta de senaste materialen och publikationerna, och vi är inget undantag. Men terminaler är inte något som uppdateras varje vecka. Därför har vi översatt artikeln av Antoine Bopre, publicerad våren 2018: trots sin anseende 'ålder' enligt moderna standarder, anser vi att materialet definitivt inte har förlorat sin relevans. Dessutom är originalet en serie av två artiklar, men vi har beslutat att sammanfoga dem till ett stort inlägg.

Terminaler har en särskild plats i datorhistorien, men under de senaste decennierna har de 'tvingats' bokstavligen överleva tillsammans med kommandoraden mot bakgrund av de grafiska gränssnittens allmäna spridning. Terminalemulatorer har ersatt sina hårdvarukamrater, som i sin tur var en modifiering av system baserade på hålkort och switchar. Moderna distributioner levereras med ett helt spektrum av terminalemulatorer i alla former och färger. Medan många nöjer sig med den standardterminal som tillhandahålls av deras arbetsmiljö, använder vissa stolt uppenbart exotisk programvara för att köra sitt favoritgränssnitt eller textredigerare. Men, som vi kommer att se i denna artikel, var inte alla terminaler skapade på samma sätt: de varierar kraftigt i funktionalitet, storlek och prestanda.

Vissa terminaler har helt fantastiska säkerhetsluckor, och dessutom har de flesta en helt olika uppsättning funktioner, från stöd för flikgränssnitt till skript. Även om vi redan har täckt terminalemulatorer för länge sedan, är denna artikel en uppdatering av det tidigare materialet som hjälper läsarna att avgöra vilken terminal de ska använda 2018. I första halvan av artikeln jämförs funktionerna, medan den andra halvan bedömer prestandan.

Här är de terminaler jag har diskuterat:

Det kan hända att dessa inte är de mest aktuella versionerna, eftersom jag har begränsat mig till stabila byggnader vid tidpunkten för skrivandet, som jag har kunnat installera på Debian 9 eller Fedora 27. Det enda undantaget är Alacritty. Det är en avkomling till terminaler med GPU-accelerering och skriven i ett ovanligt och nytt språk för denna uppgift - Rust. Jag exkluderade webbterminaler (inklusive, och på Electron), eftersom preliminära tester visade på deras extremt låga prestanda.

Unicode-stöd

Mina tester började med unicode-stöd. Det första testet av terminalerna var att visa en sträng om unicode från artikel på Wikipedia: "é, Δ, Й, ק, م, ๗, あ, 叶, 葉 och 말". Detta enkla test visar om terminalen kan fungera korrekt över hela världen. Terminalen xterm visar inte den arabiska symbolen Mem i standardkonfigurationen:

Som standard använder xterm det klassiska "monospace"-teckensnittet, som enligt samma Wiki, har "betydande unicode-kompatibilitet sedan 1997". I detta teckensnitt sker det något som gör att symbolen visas som en tom ram och endast vid ökning av textstorleken till 20+ punkter börjar symbolen äntligen visas korrekt. Men en sådan "fix" förstör visningen av andra unicode-symboler:

Dessa skärmdumpar togs i Fedora 27, eftersom det var där jag fick de bästa resultaten, medan Debian 9, där vissa äldre versioner av terminaler (specifikt - mlterm) inte fungerade ordentligt med typsNitten. Lyckligtvis åtgärdades detta i senare versioner.

Observera nu visningen av strängen i xterm. Det visar sig att symbolen Mem och den följande semitiska Qoph tillhör RTL-skript (right-to-left), så de borde tekniskt sett visas från höger till vänster. Webbläsare, till exempel Firefox 57, hanterar korrekt ovanstående sträng. En enklare variant av RTL-text är ordet "Sara" på hebreiska (שרה). Wikipedia-sidan om flerspråkig text säger följande:

"Många datorprogram kan inte korrekt visa flerspråkig text. Till exempel består det hebreiska namnet "Sara" av tecknen sin (ש) (som visas till höger), följt av resh (ר) och till sist he (ה) (som ska visas till vänster)."

Många terminaler klarar inte detta test: Alacritty, VTE-baserade terminaler i Gnome och XFCE, urxvt, st och xterm visar "Sara" baklänges, som om vi skulle skriva namnet som "Aras".

Ett annat problem med tvåvägs texter är att de måste på något sätt justeras, särskilt när det handlar om blandning av RTL och LTR-text. RTL-skript bör starta från höger sida av terminalfönstret, men vad ska hända i terminaler som normalt arbetar med LTR-engelska? De flesta av dem har inga specifika mekanismer och justerar hela texten till vänster (inklusive i Konsole). Undantagen är pterm och mlterm, som följer standarderna och justerar sådana rader till höger.

Skydd mot klipp och klistra

Den nästa kritiska egenskapen som jag har identifierat är skydd mot klipp och klistra. Även om det är allmänt känt att kommandon som:

$ curl http://example.com/ | sh

är push-kommandon för att köra kod, är det få som vet att dolda kommandon kan tränga in i konsolen vid klipp och klistra från en webbläsare, även efter noggrann inspektion. Janna Horns verifieringssida visar tydligt hur ett oskyldigt utseende kommando:

git clone git://git.kernel.org/pub/scm/utils/kup/kup.git

blir ett sådant problem vid insättning från Horns webbplats i terminalen:

git clone /dev/null;
    clear;
	echo -n "Hello ";
	whoami|tr -d 'n';
	echo -e '!nDet var en dålig idé. Kopiera inte kod från webbplatser du inte litar på! 
	Här är den första raden av din /etc/passwd: ';
	head -n1 /etc/passwd
	git clone git://git.kernel.org/pub/scm/utils/kup/kup.git

Hur fungerar det? Skadlig kod placeras i en block , som flyttas ut ur användarens synfält med hjälp av CSS.

Bracketed paste-läget är tydligt avsett för att neutralisera sådana attacker. I detta läge omger terminalerna den klippt texten med ett par speciella escape-sekvenser för att informera skalet om textens ursprung. Så skalet får signalen att det kan ignorera speciella tecken som kan finnas i den klippta texten. Alla terminaler, så långt tillbaka som det respekterade xterm, stöder denna funktion, men klippning i Bracketed-läge kräver stöd från skalet eller programmet som körs i terminalen. Till exempel behöver programvara som använder GNU Readline (samma Bash), en fil ~/.inputrc:

set enable-bracketed-paste on

Tyvärr visar testwebbplatsen Horn också hur man kringgår detta skydd genom att formatera texten och för tidigt avsluta tillämpningen av Bracketed-läget. Detta fungerar eftersom vissa terminaler filtrerar escape-sekvenser felaktigt innan de lägger till sina egna. Till exempel lyckades jag aldrig avsluta testerna för Konsole, även med korrekt konfiguration. .inputrc filen. Detta innebär att du enkelt kan få skador på systemkonfigurationen på grund av ett osupporterat program eller en felaktigt konfigurerad shell. Detta är särskilt farligt när man loggar in på fjärrservrar, där noggrant utförande av konfigurationen är mindre vanligt, särskilt om du har många sådana fjärrmaskiner.

En bra lösning på detta problem är ett insättningsbekräftelse-plugin för terminalen urxvt, som helt enkelt ber om tillstånd att klistra in vilken text som helst som innehåller nya rader. Jag har inte hittat en mer säker lösning för den textattack som beskrivits av Horn.

Flikar och profiler

En populär funktion just nu är stöd för flikar, vilket vi kommer att definiera som ett terminalfönster som innehåller flera terminaler. För olika terminaler skiljer sig denna funktion, och medan traditionella terminaler som xterm inte alls stöder flikar, har modernare versioner av terminaler som Xfce Terminal, GNOME Terminal och Konsole denna funktion. Urxvt har också stöd för flikar, men endast om ett plugin används. Men när det gäller stöd för flikar är Terminator den obestridda ledaren: den stöder inte bara flikar utan kan också placera terminaler i godtycklig ordning (se bilden nedan).

En annan funktion hos Terminator är möjligheten att "gruppera" dessa flikar tillsammans och skicka samma tangenttryckningar till flera terminaler samtidigt, vilket ger ett grovt verktyg för att utföra massoperationer på flera servrar samtidigt. En liknande funktion finns också i Konsole. För att använda denna funktion i andra terminaler måste man använda tredjepartsprogramvara som Cluster SSH, xlax eller tmux.

Särskilt bra fungerar flikarna tillsammans med profiler: till exempel kan du ha en flik för e-post, en annan för chatt och så vidare. Detta stöds bra av terminalerna Konsole och GNOME Terminal. Båda tillåter varje flik att automatiskt starta sin egen profil. Terminator stöder också profiler, men jag kunde inte hitta något sätt att automatiskt starta specifika program när en viss flik öppnas. Andra terminaler har överhuvudtaget ingen uppfattning om "profil".

Ryschki

Det sista jag kommer att gå igenom i den första delen av denna artikel är utseendet på terminalerna. Till exempel stöder GNOME, Xfce och urxvt genomskinlighet, men nyligen har de slutat stödja bakgrundsbilder, vilket fått vissa användare att byta till en annan terminal. Tilix. Personligen är jag nöjd med den enklaste formen. Xresources, som ställer in en grundläggande uppsättning bakgrundsfärger för urxvt. Men icke-standardfärgteman kan skapa problem. Till exempel, Solarized funkar inte med applikationerna htop och IPTraf, eftersom de redan använder sina egna färger.

Den ursprungliga VT100-terminalen stöddes inte av färger, och nya begränsades ofta till en 256-färgspalett. För erfarna användare som stylar sina terminaler, kan krav på komplexa skal eller statusrader bli en obehaglig begränsning. Gist spårar vilka terminaler som har stöd för "True Color". Mina tester bekräftar att st, Alacritty och terminaler baserade på VTE perfekt stöder True Color. Andra terminaler presterar inte så bra i detta avseende och visar egentligen inte ens 256 färger. Nedan kan du se skillnaden mellan stödet för True Color i terminalerna GNOME, st och xterm, som klarar detta bra med sin 256-färgspalett, och urxvt, som inte bara misslyckas testet men också visar olika blinkande symboler istället.

Vissa terminaler analyserar också texten för att hitta URL-mönster för att göra länkar klickbara. Detta gäller alla VTE-baserade terminaler, medan urxvt kräver en speciell plugin-modul som transformera URL-adresser vid klick eller med hjälp av kortkommandon. Andra terminaler som jag testat visar URL-adresser på andra sätt.

Slutligen är en ny trend för terminaler – valfri scrollbuffert. Till exempel, i st finns ingen scrollbuffert; det antas att användaren kommer att använda en terminalmultiplexer, som tmux och GNU Screen.

I Alacritty finns det också ingen bakåtrullningsbuffert, men stöd för den kommer snart att läggas till på grund av "omfattande feedback" från användare angående detta ämne. Förutom dessa avvikare har varje terminal jag har undersökt som jag kunnat hitta stöd för bakåtrullning.

Mellanliggande resultat

I den andra delen av materialet (i originalet var detta två olika artiklar, - anm. övers.) kommer vi att jämföra prestanda, minnesanvändning och latens. Men vi ser redan att vissa av de terminaler som övervägs har allvarliga brister. Till exempel kan användare som regelbundet arbetar med RTL-skript uppmärksamma mlterm och pterm, eftersom de hanterar sådana uppgifter bättre än andra. Konsole har också visat sig fungera bra. Användare som inte arbetar med RTL-skript kan välja något annat.

Ur säkerhetssynpunkt när det gäller skydd mot insättning av skadlig kod står urxvt ut på grund av sin särskilda implementering av skydd mot denna typ av attacker, vilket jag tycker är definitivt lämpligt. De som söker efter några funktioner bör titta på Konsole. Slutligen är det värt att notera att VTE är en utmärkt bas för terminaler, vilket garanterar färgstöd, URL-igenkänning och så vidare. Vid första anblicken kan den standardterminal som levereras med din favoritmiljö uppfylla alla krav, men vi lämnar den frågan öppen tills vi utreder prestandan.

Vi fortsätter diskussionen

Överlag kan terminalernas prestanda verka som en överdriven fråga, men som det visar sig uppvisar vissa av dem en överraskande hög latens för sådan grundläggande programvara. Vidare kommer vi att titta på det som traditionellt kallas "hastighet" (egentligen är det scrollhastigheten) och hur mycket minne terminalen använder (med tanke på att detta idag inte är lika kritiskt som för flera decennier sedan).

Fördröjning

Efter noggrant undersökande av terminalernas prestanda har jag kommit fram till att den viktigaste parametern i detta avseende är storleken på latensen (ping). I min artikel «Vi skriver med glädje» Pavel Fatin undersökte fördröjningen hos olika textredigerare och antydde att terminaler i detta avseende kan fungera långsammare än de snabbaste textredigerarna. Just denna antydan ledde mig, i slutändan, till att starta egna tester och skriva denna artikel.

Men vad är fördröjning, och varför är den så viktig? I sin artikel definierade Fatin den som «fördröjningen mellan tangenttryckningen och den motsvarande uppdateringen på skärmen» och citerade «Handbok för människans interaktion med datorer», där det står: «Fördröjningen i visuell återkoppling på datorskärmen har stor påverkan på skrivfötterens beteende och deras tillfredsställelse».

Fatin förklarar att denna ping har djupare konsekvenser än bara tillfredsställelse: «att skriva blir långsammare, fler misstag uppstår, ögon- och muskelspänningar ökar». Med andra ord kan en större fördröjning leda till skrivfel samt en minskning av kodkvaliteten, eftersom det medför en extra kognitiv belastning på hjärnan. Men vad som är ännu värre är att pingen «ökar ögon- och muskelspänningen», vilket tycks innebära utvecklingen av professionella skador i framtiden (till synes syftar författaren på problem med ögon, rygg, armar och givetvis synen, — övers. anm.) på grund av upprepad belastning.

Några av dessa effekter är välkända, och resultaten forskning, publicerade redan 1976 i tidskriften Ergonomics, visar att en fördröjning på 100 millisekunder «försämrar skrivhastigheten avsevärt». Nyligen har användarmanualen för GNOME angett ett acceptabelt svarstid på 10 millisekunder, och om vi går längre, så Microsoft Research visar att idealet är 1 millisekund.

Fatin utförde sina tester på textredigerare; han skapade ett bärbart verktyg som kallas Typometer, som jag använd för att kontrollera ping i terminalemulatorer. Tänk på att testet utfördes i simuleringsläge: i verkligheten måste vi ta hänsyn till både inmatningsfördröjning (tangentbord, USB-kontroller och så vidare) och utmatningsfördröjning (grafikkortsbuffer, monitor). Enligt Fatins uppgifter ligger den typiska fördröjningen runt 20 ms. Med spelutrustning kan den uppnås på endast 3 millisekunder. Eftersom vi redan har sådan snabb utrustning, bör applikationen inte introducera sin egen fördröjning. Fatins mål är att minska applikationens fördröjning till 1 millisekund, eller helst att nå ett fördröjningsfritt tillstånd. mätbar fördröjning, som i IntelliJ IDEA 15.

Här är resultaten av mina mätningar, samt några av Fatins resultat för att visa att mitt experiment överensstämmer med hans tester:

Det första som förvånade mig var den bättre svarstiden hos äldre program, som xterm och mlterm. Trots sämre registreringsfördröjning (2,4 ms) visade de ett bättre resultat än den snabbaste moderna terminalen (10,6 ms för st). Ingen modern terminal kommer under tröskeln på 10 millisekunder. I synnerhet uppfyller Alacritty inte kraven för att vara "den snabbaste av alla existerande terminalemulatorer", även om dess resultat har förbättrats sedan den första kontrollen 2017. Faktum är att projektets författare är medvetna om situationen och arbetar på att förbättra rendering. Det är också värt att notera att Vim, som använder GTK3, är avsevärt långsammare än sin GTK2-motsvarighet. Detta tyder på att GTK3 skapar en extra fördröjning, som påverkar alla andra terminaler som använder det (Terminator, Xfce4 Terminal och GNOME Terminal).

Men för ögat kan skillnaderna vara osynliga. Som Fatin förklarar: "Det är inte nödvändigt att vara medveten om fördröjningen för att den ska påverka dig." Fatin varnar också för standardavvikelsen: "Alla avvikelser i längden på fördröjningen (skakningar) skapar extra belastning på grund av deras oförutsägbarhet."

Diagrammet ovan är taget från en ren Debian 9 (stretch) med i3-fönsterhanteraren. Den här miljön ger de bästa resultaten i latensmätningar. Det visar sig att GNOME skapar en extra ping på 20 ms för alla mätningar. En möjlig förklaring till detta är att det finns program med synkron bearbetning av inmatningsevent. Fatin ger ett exempel på detta fall. Workrave, som lägger till latens genom att behandla alla input-events synkront. GNOME är också förinställt med ett fönsterhanteringssystem. Mutter, vilket skapar ett extra lager av buffring, vilket påverkar ping och lägger till minst 8 millisekunders latens.

Rullningshastighet

Nästa test är en traditionell kontroll av "hastighet" eller "bandbredd", som mäter hur snabbt terminalen kan rulla ner sidan och visa en stor mängd text på skärmen. Testets mekanik varierar; det ursprungliga testet bestod av att helt enkelt generera samma textsträng med kommandot seq. Andra tester inkluderar Thomas E. Dickys test (som är kopplad till xterm), där en fil med namnet terminfo.src upprepade gånger laddas ner.I en annan prestandaöversyn av terminaler Den Luu använder en sträng av slumpmässiga byte i base32-kodning, som skrivs ut till terminalen med hjälp av cat. Luu anser att detta test är "så oanvändbart referensvärde som man kan föreställa sig" och föreslår att man istället använder terminalens respons som det primära måttet. Dicky kallade också sitt test missvisande. Trots detta erkänner båda författarna att terminalfönstrets bandbredd kan vara ett problem. Luu upptäckte att Emacs Eshell hängde vid visning av stora filer, och Dicky optimerade terminalen för att eliminera den visuella segheten i xterm. Därför finns det fortfarande en viss poäng med detta test, men eftersom renderingsprocessen skiljer sig avsevärt mellan terminaler, kan det också användas som en testkomponent för att kontrollera andra parametrar.

Här ser vi att rxvt och st sticker ut bland konkurrenterna, följt av det mycket nyare Alacritty, som utvecklas med fokus på hastighet. Därefter kommer Xfce (familjen VTE) och Konsole, som arbetar nästan dubbelt så snabbt. Sist i tur står xterm, som är fem gånger långsammare än rxvt. Under testet visade xterm också mycket flimmer, och det var svårt att särskilja den passerande texten, även om det var samma rad. Konsole visade sig vara snabb, men hade ibland "tricks": skärmen hängde ibland, vilket gjorde att texten visades delvis eller inte alls. Andra terminaler visade rader tydligt, inklusive st, Alacritty och rxvt.

Diki förklarar att skillnaderna i prestanda beror på designen av scrollningsbuffrar i olika terminaler. I synnerhet anklagar han rxvt och andra terminaler för att "inte följa allmänna regler":

"Till skillnad från xterm försökte rxvt inte visa alla uppdateringar. Om det hamnade efter skulle det avstå från vissa uppdateringar för att kunna ikapp. Detta hade större inverkan på den upplevda scrollhastigheten än på organisationen av internminnet. En nackdel var att ASCII-animationen var något oprecis."

För att åtgärda den uppenbara trögheten hos xterm? föreslår Diki att använda resursen fastScroll, vilket gör att xterm kan avstå från vissa skärmutppdateringar för att inte hamna efter flödet. Mina tester bekräftar att fastScroll ökar prestandan och lyfter xterm till samma nivå som rxvt. Detta är dock en ganska grov tillfällig lösning, som Diki själv förklarar: "ibland verkar xterm - precis som konsole - stanna, eftersom det väntar på en ny uppsättning skärmutppdateringar efter att vissa har tagits bort." I detta sammanhang verkar det som om andra terminaler har hittat den bästa kompromissen mellan hastighet och integritet i skärmen.

Resursanvändning

Oavsett om det är rimligt att betrakta scrollhastighet som en prestandamätning, gör detta test det möjligt att simulera belastningen på terminalerna, vilket i sin tur gör att vi kan mäta andra parametrar, såsom minnes- eller disk-användning. Metrikerna erhölls genom att köra det angivna testet seq under övervakning av Python-processen. Den samlade in data om räknarna getrusage () för ru_maxrss, summan av ru_oublock och ru_inblock och en enkel tidsräknare.

I det här testet ligger ST på första plats med den lägsta genomsnittliga minnesanvändningen på 8 MB, vilket inte är förvånande med tanke på att projektets huvudidé är enkelhet. Lite mer använder mlterm, xterm och rxvt – cirka 12 MB. Ett annat anmärkningsvärt resultat är Alacritty, som kräver 30 MB för att fungera. Därefter kommer terminaler av VTE-familjen med siffror mellan 40 och 60 MB, vilket är ganska mycket. Denna förbrukning kan förklaras av att dessa terminaler använder mer avancerade bibliotek, som GTK. Konsole hamnar sist med en kolossal minnesanvändning på 65 MB under testerna, även om detta kan rättfärdigas av dess omfattande funktionsuppsättning.

Jämfört med tidigare resultat från för tio år sedan, har alla program nu mycket högre minnesanvändning. Tidigare krävde Xterm 4 MB, och nu 15 MB bara för att starta. En liknande ökning ses hos rxvt, som nu i standardutförande kräver 16 MB. Xfce Terminal tar 34 MB, vilket är tre gånger mer än tidigare, medan GNOME Terminal kräver 20 MB. Naturligtvis genomfördes alla tidigare tester på en 32-bitarsarkitektur. Vid LCA 2012, Rasty Russell berättade, finns det många mer subtila anledningar som kan förklara den ökade minnesanvändningen. Med allt detta lever vi nu i en tid då vi har hela gigabyte minne, så vi klarar oss på något sätt.

Trots det kan jag inte skaka av mig känslan av att avsätta mer minne för så grundläggande mjukvara som terminalen är en slöseri med resurser. Dessa program borde vara bland de minsta av de små och borde kunna fungera på vilken "låda" som helst, även en skokartong, om vi någonsin kommer dit att de behöver utrustas med Linux-system (och ni vet att så kommer att bli fallet). Men med dessa siffror kommer minnesanvändningen i framtiden att bli ett problem i alla miljöer vid start av flera terminaler, utom i situationer med några av de lättaste och mest begränsade alternativen. För att kompensera för detta har GNOME Terminal, Konsole, urxvt, Terminator och Xfce Terminal ett daemon-läge som gör det möjligt att hantera flera terminaler genom en process, vilket begränsar deras minnesanvändning.

Under mina tester kom jag fram till en annan oväntad slutsats angående diskens läs- och skrivprestanda: jag förväntade mig verkligen inte att se något här, men det visade sig att vissa terminaler skriver de mest omfattande data till disken. Således håller VTE-biblioteket faktiskt en scrollbuffert på disken (denna funktionalitet upptäcktes redan 2010, och det pågår fortfarande). Men till skillnad från de gamla implementeringarna, så är dessa data nu åtminstone krypterade med hjälp av AES256 GCM (från version 0.39.2). Men det väcks en rimlig fråga: vad är det som är så speciellt med VTE-biblioteket att det kräver en sådan icke-standardiserad implementering…

Slutsats

I den första delen av artikeln upptäckte vi att terminaler baserade på VTE har en bra uppsättning funktioner, men nu ser vi att detta är kopplat till vissa kostnader för att säkerställa deras prestanda. Just nu är minnet inte ett problem, eftersom alla VTE-terminaler kan hanteras via en Daemon-process som begränsar deras resursanvändning. Ändå kan gamla system, som har fysiska begränsningar av mängden RAM och kärnbuffer, fortfarande behöva tidigare versioner av terminalerna, eftersom de konsumerar betydligt mindre resurser. Även om VTE-terminaler har presterat bra i tester för bandbredd (scrollning), är deras visningsfördröjning av data på skärmen över den fastställda tröskeln i GNOME-användarhandboken. Troligtvis bör VTE-utvecklarna ta hänsyn till detta. Med tanke på att även nybörjare inom Linux oundvikligen kommer att stöta på terminalen, kan de göra den mer användarvänlig. För erfarna användare kan övergången från standardterminalen innebära en minskad belastning på ögonen och möjligheten att undvika yrkesskador och sjukdomar i framtiden på grund av långvariga arbetspass. Tyvärr ger endast de gamla xterm och mlterm oss den magiska pingtröskeln på 10 millisekunder, vilket är oacceptabelt för många.

Kontrollmätningar har också visat att utvecklingen av grafiska miljöer i Linux har tvingat utvecklarna att göra en rad kompromisser. Vissa användare bör överväga att använda vanliga fönsterhanterare, eftersom de ger en avsevärd minskning av ping. Tyvärr gick det inte att mäta fördröjningen för Wayland: programmet Typometer, som jag använde, skapades för att förhindra det som Wayland är avsett att göra - att spionera på andra fönster. Jag hoppas att Waylands sammansättning har bättre prestanda än X.org och att någon i framtiden hittar ett sätt att mäta fördröjningsnivån i denna miljö.

Källa: habr.com