Pár slov od našeho překladatelského studia: obvykle se všichni snaží překládat nejnovější materiály a publikace, a my nejsme výjimkou. Avšak terminály nejsou něco, co se aktualizuje každých pár týdnů. Proto jsme pro vás přeložili článek Antoina Boprea, publikovaný na jaře 2018: přestože je jeho 'věk' podle současných měřítek solidní, podle našeho názoru materiál neztratil na aktuálnosti. Navíc, v originále se jedná o sérii dvou článků, ale rozhodli jsme se je sloučit do jednoho velkého příspěvku.
Terminály zaujímají zvláštní místo v historii výpočetní techniky, ale v posledních desetiletích byly doslova nuceny přežít spolu s příkazovým řádkem na pozadí rozšířených grafických rozhraní. nahradily své , které byly zase modifikacemi systémů na děrných štítcích a přepínačích. Moderní distribuce přicházejí s celou řadou emulátorů terminálu všech tvarů a barev. A zatímco mnozí spokojeni používají standardní terminál, který poskytuje jejich pracovní prostředí, někteří s hrdostí používají otevřeně exotický software pro spuštění své oblíbené shell nebo textového editoru. Ale, jak uvidíme v tomto článku, ne všechny terminály byly vytvořeny podle jednoho vzoru: výrazně se liší co do funkcionality, velikosti a výkonu.
Některé terminály mají přímo ohromující bezpečnostní díry, navíc většina má naprosto odlišnou sadu funkcí, od podpory vícero oken po skripty. Ačkoli jsme , tento článek je aktualizací předchozího materiálu, který pomůže čtenářům určit, který terminál použít v roce 2018. V první polovině článku se porovnávají funkce, zatímco ve druhé se hodnotí výkon.
Zde jsou terminály, které jsem zkoumal:
Možná to nejsou nejnovější verze, protože jsem se omezil na stabilní sestavení k okamžiku psaní materiálu, která jsem mohl nainstalovat na Debian 9 nebo Fedora 27. Jedinou výjimkou je Alacritty. Je potomkem terminálů s GPU akcelerací a je napsán na neobvyklém a novém jazyce pro tento úkol — Rust. Vyloučil jsem z mého přehledu webové terminály (včetně na ), protože předběžné testy ukázaly jejich extrémně nízkou výkonnost.
Podpora Unicode
Svůj test jsem začal s podporou Unicode. Prvním testem terminálů bylo zobrazení řetězce o Unicode z : „é, Δ, Й, ק, م, ๗, あ, 叶, 葉 a 말“. Tento jednoduchý test ukazuje, zda terminál správně funguje na celém světě. Terminál xterm nezobrazuje arabský symbol v základní konfiguraci:
Podle defaultu xterm používá klasické „pevné“ písmo, které, podle , má „podstatný pokrytí Unicode od roku 1997“. V tomto písmu se něco děje, co způsobuje, že symbol se zobrazuje jako prázdný rámeček, a až při zvýšení velikosti textu na 20+ bodů se symbol konečně začne správně zobrazovat. Ovšem takový „oprava“ narušuje zobrazení dalších symbolů Unicode:
Tyto snímky obrazovky byly pořízeny na Fedoře 27, jelikož ta poskytovala lepší výsledky než Debian 9, kde některé staré verze terminálů (konkrétně — mlterm) nemohly správně fungovat s písmem. Naštěstí to bylo opraveno v novějších verzích.
Nyní si všimněte zobrazení řetězce v xterm. Ukazuje se, že symbol Mem a následující po něm Semitic patří do scénářů psaní RTL (), takže technicky by měly být zobrazeny zprava doleva. Webové prohlížeče, například Firefox 57, správně zpracovávají výše uvedený řetězec. Jednodušším příkladem textu RTL je slovo „“ na hebrejštině (). říká následující:
„Mnoho počítačových programů nedokáže správně zobrazovat obousměrný text. Například hebrejské jméno „Sara“ se skládá ze znaků sin (ש) (který se zobrazuje zprava), pak reš (ר) a nakonec chej (ה) (který by se měl zobrazit zleva)“.
Mnoho terminálů tento test neprojde: Alacritty, VTE-deriváty terminálů Gnome a XFCE, urxvt, st a xterm zobrazují „Sara“ obráceně, jako by bylo toto jméno napsáno jako „Aras.“
Dalším problémem obousměrných textů je, že je nutné je nějak vyrovnat, zvlášť pokud se mluví o kombinaci RTL a LTR textů. Scénáře RTL by měly začínat z pravé strany okna terminálu, ale co by se mělo dít v terminálech, které ve výchozím nastavení pracují s LTR angličtinou? Většina z nich nemá žádné speciální mechanismy a zarovnává celý text na levý okraj (včetně Konsole). Vynikají pterm a mlterm, které dodržují standardy a zarovnávají takové řádky na pravý okraj.
Ochrana před vkládáním
Další kritická vlastnost, kterou jsem pro sebe určil, je ochrana před vkládáním. Ačkoli je všeobecně známo, že příkazy typu:
$ curl http://example.com/ | shjsou příkazy pro spuštění kódu, málokdo ví, že skryté příkazy mohou proniknout do konzole při kopírování-a-vkládání z webového prohlížeče, i po důkladné prohlídce. skvěle ukazuje, jak bezobslužný příkaz:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitse po vložení ze stránek Horna v terminálu promění v takovou nepříjemnost:
git clone /dev/null;
clear;
echo -n "Ahoj ";
whoami|tr -d 'n';
echo -e '!nTo byla špatná myšlenka. Nekopírujte kód z webů, kterým nedůvěřujete!
Toto je první řádek vašeho /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitJak to funguje? Škodlivý kód je vytažen do bloku , který je přesunut z dohledu uživatele pomocí CSS.
je určena k neutralizaci podobných útoků. V tomto režimu terminály obklopují vkládaný text párem speciálních escape sekvencí, aby informovaly shell o původu tohoto textu. Tímto způsobem shell dostává signál, že může ignorovat speciální znaky, které může vkládaný text obsahovat. Všechny terminály, až po vážený xterm, tuto funkci podporují, ale vkládání v režimu Bracketed potřebuje podporu shellu nebo aplikace, která běží na terminálu. Například software používající (stejné Bash), potřebuje soubor ~/ .inputrc:
set enable-bracketed-paste onBohužel, testovací stránka Horna také ukazuje, jak obejít tuto ochranu prostřednictvím formátování textu a předčasně ukončit aplikaci režimu Bracketed. Funguje to, protože některé terminály nesprávně filtrují únikové sekvence před přidáním svých vlastních. Například v mých pokusech jsem nebyl schopen úspěšně dokončit testy Konsole, i při správné konfiguraci. .inputrc souboru. To znamená, že můžete snadno poškodit konfiguraci systému kvůli nepodporované aplikaci nebo nesprávně nastavené shell. To je obzvlášť nebezpečné při přihlašování na vzdálené servery, kde pečlivé zpracování konfigurace je méně běžné, zvlášť pokud máte více takových vzdálených strojů.
Dobré řešení tohoto problému je plugin pro potvrzení vkládání pro terminál urxvt, který jednoduše požaduje povolení k vložení jakéhokoli textu obsahujícího nové řádky. Nenašel jsem bezpečnější variantu pro popisovanou textovou útok Horna.
Záložky a profily
Populární funkcí v současnosti je podpora rozhraní se záložkami, které definujeme jako jedno okno terminálu obsahující více terminálů. Tato funkce se liší mezi různými terminály a zatímco tradiční terminály jako xterm tuto funkci vůbec nepodporují, modernější verze terminálů jako Xfce Terminal, GNOME Terminal a Konsole tuto funkci mají. Také Urxvt podporuje záložky, ale pouze za podmínky použití pluginu. Z hlediska podpory záložek je bezesporu lídrem Terminator: nejen že podporuje záložky, ale také může rozmístit terminály v libovolném uspořádání (viz obrázek níže).
Další zajímavostí Terminatoru je možnost "skupinovat" tyto záložky dohromady a posílat stejné stisky kláves na více terminálů současně, což poskytuje hrubý nástroj pro provádění hromadných operací na více serverech souběžně. Podobná funkce je také realizována v Konsole. K použití této funkce v jiných terminálech je nutné použít třetí software, jako je , nebo .
Zvlášť dobře fungují panely ve spojení s profily: například můžete mít jednu kartu pro e-mail, další pro chat a tak dále. To dobře podporují terminály Konsole a GNOME Terminal. Oba umožňují, aby každá karta automaticky spouštěla svůj profil. Terminator také podporuje profily, ale nedokázal jsem najít způsob, jak automaticky spouštět určité programy při otevření určité karty. Ostatní terminály nemají pojmy o 'profilu' vůbec.
Rybí filetky
Poslední, co budu zkoumat v první části tohoto článku, je vzhled terminálů. Například GNOME, Xfce a urxvt podporují průhlednost, ale nedávno ukončili podporu pozadí obrázků, což donutilo některé uživatele přejít na jiný terminál. . Osobně mi stačí a jednoduše Xresources, který nastavuje základní sadu barev pozadí pro urxvt. Nicméně nestandardní barevné témata mohou způsobovat problémy. Například, s aplikacemi a , protože již používají své vlastní barvy.
nepodporoval barvy, a nové často omezovaly na paletu 256 barev. Pro zkušené uživatele, kteří stylizují své terminály pomocí složitých způsobů, může být tohle nepříjemné omezení. sledoval, které terminály mají podporu 'True Color'. Mé testy potvrzují, že st, Alacritty a terminály na bázi VTE skvěle podporují True Color. Ostatní terminály si v tomhle ohledu nevedou příliš dobře a ve skutečnosti neukazují ani 256 barev. Níže můžete vidět rozdíl mezi podporou True Color v terminálech GNOME, st a xterm, které se tímto úkolem zdatně vypořádávají pomocí své palety 256 barev, a urxvt, který nejen že testem neprochází, ale dokonce ukazuje nějaké blikající symboly místo nich.
Některé terminály také analyzují text na přítomnost URL vzorů, aby odkazy byly klikatelné. To platí pro všechny odvozené terminály od VTE, zatímco urxvt vyžaduje speciální plugin, který by transformoval URL adresy po kliknutí nebo pomocí klávesové zkratky. Ostatní terminály, které jsem testoval, zobrazují URL adresy jinými způsoby.
Nakonec je tu nový trend terminálů – volitelný posuvník. Například v st není žádný posuvník; předpokládá se, že uživatel bude používat terminálový multiplexor, jako je tmux a .
V Alacritty také chybí zpětné posuvníky, ale podpora kvůli "rozsáhlé zpětné vazbě" na toto téma od uživatelů. Kromě těchto výjimek, každý terminál, který jsem našel, podporuje zpětné posouvání.
Mezivýsledky
Ve druhé části materiálu (v originále to byly dva různé články, — pozn. red.) porovnáme výkon, využití paměti a latenci. Ale už vidíme, že některé z probíraných terminálů mají závažné nedostatky. Například uživatelé, kteří pravidelně pracují s RTL skripty, by měli věnovat pozornost mlterm a pterm, protože si s těmito úlohami poradí lépe než ostatní. Konsole se také osvědčila. Uživatelé, kteří nepracují s RTL skripty, si mohou vybrat něco jiného.
Z pohledu ochrany před vkládáním škodlivého kódu se urxvt vyznačuje svou jedinečnou realizací ochrany proti tomuto typu útoků, což mi připadá rozhodně užitečné. Ti, kteří hledají nějaké vymoženosti, by měli podívat na Konsole. Nakonec stojí za zmínku, že VTE – skvělá základna pro terminály, zaručuje podporu barev, rozpoznávání URL a tak dále. Na první pohled může výchozí terminál dodávaný s vaší oblíbenou pracovní plochou splnit všechny požadavky, ale tuto otázku necháme otevřenou, dokud neprozkoumáme výkon.
Pokračujeme v diskusi
Výkon terminálů se na první pohled může zdát jako umělý problém, avšak jak se ukázalo, některé z nich vykazují překvapivě vysokou latenci pro tak zásadní typ softwaru. Také se dále podíváme na to, co se obvykle nazývá "rychlostí" (ve skutečnosti je to rychlost posouvání) a na spotřebu paměti terminálem (s ohledem na to, že dnes to není tak kritické, jak tomu bylo před desetiletími).
Zpoždění
Po důkladném prozkoumání výkonu terminálů jsem dospěl k závěru, že nejdůležitějším parametrem v tomto ohledu je velikost latentnosti (ping). Ve svém článku Pavel Fatin prozkoumal zpoždění různých textových editorů a naznačil, že terminály v tomto ohledu mohou fungovat pomaleji než nejrychlejší textové editory. Právě toto naznačení mě nakonec vedlo k provedení vlastních testů a napsání tohoto článku.
Ale co je to zpoždění a proč je tak důležité? Ve svém článku Fatin definoval zpoždění jako „odstup mezi stisknutím klávesy a odpovídající aktualizací na obrazovce“ a citoval , ve které se uvádí: „Zpoždění ve vizuální odezvě na displeji počítače má významný dopad na chování písaře a jeho spokojenost.“
Fatin vysvětluje, že takový ping má hlubší důsledky než pouhá spokojenost: „psaní se zpomaluje, vzniká více chyb, zvyšuje se napětí očí a svalů“. Jinými slovy, větší zpoždění může vést k překlepům a také ke snížení kvality kódu, protože zvyšuje kognitivní zátěž na mozek. Co je ale ještě horší, ping „zvyšuje napětí očí a svalů“, což zřejmě naznačuje v budoucnu (zřejmě autor má na mysli problémy s očima, zády, rukama a samozřejmě se zrakem, – pozn. př.) kvůli opakovanému napětí.
Některé z těchto efektů jsou známé dávno, a výsledky , publikované již v roce 1976 v časopise Ergonomics, ukazují, že zpoždění o 100 milisekund „významně zhoršuje rychlost psaní“. Nedávno byl do uživatelské příručky GNOME přidán o 10 milisekund, a pokud budeme pokračovat dále, ukazuje, že ideálem je 1 milisekunda.
Fatin prováděl své testy na textových editorech; vytvořil přenosný nástroj nazvaný , který jsem použil k testování pingu v emulátorech terminálu. Mějte na paměti, že test byl proveden v simulačním režimu: ve skutečnosti musíme brát v úvahu i zpoždění vstupu (klávesnice, USB ovladač atd.) a výstupu (buffer grafické karty, monitor). Podle Fatina je v běžných konfiguracích přibližně 20 ms. Při použití herního vybavení lze dosáhnout hodnoty pouze 3 milisekundy. Protože už máme tak rychlé vybavení, aplikace by neměla přidávat další zpoždění. Fatina cílí na snížení zpoždění aplikace na 1 milisekundu, nebo dokonce na dosažení bez , jako v .
A tady jsou výsledky mých měření a také některé výsledky Fatina, abych ukázal, že můj experiment souhlasí s jeho testy:
První, co mě překvapilo, bylo lepší reakční čas u starých programů, jako jsou xterm a mlterm. S nejhorším zpožděním registrace (2,4 ms) dosáhly lepšího výsledku než nejrychlejší moderní terminál (10,6 ms pro st). Žádný moderní terminál se nedostává pod hranici 10 milisekund. Concretě, Alacritty nesplňuje požadavky na "nejrychlejší z existujících emulátorů terminálu", ačkoli jeho výsledky se zlepšily od prvního testování v roce 2017. Opravdu, autoři projektu a pracují na zlepšení vykreslování. Také je nutné poznamenat, že Vim, který používá GTK3, je mnohem pomalejší než jeho protějšek GTK2. Z toho lze usoudit, že GTK3 vytváří další zpoždění, a to se odráží na všech ostatních terminálech, které jej používají (Terminator, Xfce4 Terminal a GNOME Terminal).
Nicméně pro oko nemusí být rozdíly patrné. Jak vysvětluje Fatina: "není nutné být si vědom přítomnosti zpoždění, aby to na vás mělo efekt". Fatina také varuje před standardní odchylkou: "jakékoli odchylky v délce zpoždění (chvění) vytvářejí další zátěž kvůli své nepředvídatelnosti."
Graf výše byl získán na čistém Debianu 9 (stretch) s . Toto prostředí poskytuje nejlepší výsledky v testech latence. Jak se ukázalo, GNOME vytváří dodatečný ping o 20 ms pro všechna měření. Možným vysvětlením je, že existují aplikace se synchronním zpracováním vstupních událostí. Fatín uvádí k takovému případu příklad , který přidává zpoždění zpracováním všech input událostí synchronně. Ve výchozím nastavení je GNOME také vybaveno správcem oken , který vytváří další úroveň vyrovnávací paměti, což ovlivňuje ping a přidává minimálně 8 milisekund zpoždění.
Rychlost posunu
Následný test je tradiční kontrola "rychlosti" nebo "propustnosti", která měří, jak rychle může terminál posouvat stránku, zobrazující velké množství textu na obrazovce. Mechanika testu se liší; původní test spočíval v tom, že se jednoduše generoval stejný textový řetězec pomocí příkazu seq. Další testy zahrnují kontrolu Thomase E. Dickse (doprovodící xterm), v rámci které se opakovaně . V dalším přehledu výkonu terminálů používá řetězec náhodných bytů v kódování base32, který se zobrazuje v terminálu pomocí cat. Luu považuje tento test za "tak bezvýznamný benchmark, jaký si lze představit" a navrhuje místo toho používat odezvu terminálu jako hlavní metriku. Dick také označuje svůj test za zavádějící. Přesto oba autoři uznávají, že propustnost okna terminálu může být problémem. Luu zjistil zpoždění Emacs Eshell při zobrazování velkých souborů, zatímco Dick optimalizoval terminál, aby se zbavil vizuální pomalosti xtermu. Tudíž má tento test stále určité opodstatnění, ale protože proces vykreslování se značně liší od terminálu k terminálu, může být použit jako testovací komponent pro kontrolu dalších parametrů.
Zde vidíme, že rxvt a st vyčnívají na pozadí konkurence, za nimi následuje mnohem novější Alacritty, vyvíjený s důrazem na rychlost. Další jsou Xfce (rodina VTE) a Konsole, které fungují téměř dvakrát rychleji. Na posledním místě je xterm s výkonem pětkrát pomalejším než rxvt. Během testu xterm také silně blikalo, procházející text bylo těžké rozpoznat, i když to byla stejná řádka. Konsole se ukázal být rychlým, ale občas „švindloval“: displej občas zamrzl, ukazující text částečně nebo ho vůbec nezobrazoval. Ostatní terminály zobrazovaly řádky jasně, včetně st, Alacritty a rxvt.
Diki vysvětluje, že rozdíly v výkonu souvisejí s návrhem bufferů rolování v různých terminálech. Především obviňuje rxvt a další terminály, že „následují obecná pravidla“:
„Na rozdíl od xtermu, rxvt se nesnažil zobrazit všechny aktualizace. Pokud zaostal, vzdá se některých aktualizací, aby dohnal zpoždění. To mělo větší vliv na zdánlivou rychlost rolování než na organizaci interní paměti. Jedinou nevýhodou bylo, že animace ASCII byla poněkud nepřesná.“
Abychom tuto zdánlivou pomalost xtermu napravili, Diki navrhuje použít zdroj , který umožňuje xtermu ignorovat některé aktualizace obrazovky, aby nezaostával za tokem. Mé testy potvrzují, že fastScroll zvyšuje výkon a dostává xterm na úroveň rxvt. Toto je však poměrně hrubé řešení, jak sám Diki vysvětluje: „někdy xterm – stejně jako konsole – vypadá, že se zastavil, protože čeká na novou sadu aktualizací obrazovky poté, co některé z nich byly odstraněny“. V tomto ohledu se zdá, že ostatní terminály našly nejlepší kompromis mezi rychlostí a integritou displeje.
Spotřeba zdrojů
Bez ohledu na to, zda je smysluplné zvážit rychlost rolování jako ukazatel výkonu, tento test umožňuje simulovat zatížení terminálů, což nám zase umožňuje měřit další parametry, jako je využití paměti nebo disku. Metriky byly získány spuštěním uvedeného testu seq pod monitorováním procesu Python. Shromažďoval data čítačů pro ru_maxrss, součet ru_oublock a ru_inblock a jednoduchý časovač.
V tomto testu ST zaujímá první místo s nejnižší průměrnou spotřebou paměti 8 MB, což není překvapivé, když vezmeme v úvahu, že hlavní myšlenkou projektu je jednoduchost. O něco více spotřebovává mlterm, xterm a rxvt – kolem 12 MB. Dalším výrazným výsledkem je Alacritty, který potřebuje 30 MB k provozu. Následují terminály rodiny VTE s ukazateli od 40 do 60 MB, což je poměrně hodně. Taková spotřeba může být vysvětlena tím, že tyto terminály používají knihovny vyšší úrovně, jako je GTK. Konsole končí s obrovskou spotřebou 65 MB paměti během testů, ačkoliv to lze obhájit jeho velmi širokým souborem funkcí.
Ve srovnání s předchozími výsledky z před deseti let všechny programy začaly spotřebovávat znatelně více paměti. Dříve Xterm vyžadoval 4 MB, nyní však 15 MB pouze na spuštění. Podobné zvýšení spotřeby se objevilo také u rxvt, který nyní z krabice vyžaduje 16 MB. Terminál Xfce zabírá 34 MB, což je třikrát více než dříve, zatímco GNOME Terminal potřebuje pouze 20 MB. Samozřejmě, všechny předchozí testy byly prováděny na 32bitové architektuře. Na LCA 2012 Rasty Russell , že existuje mnoho subtilnějších příčin, které mohou vysvětlit růst spotřeby paměti. Přesto nyní žijeme v časech, kdy máme celé gigabajty paměti, takže si nějak poradíme.
Nicméně, nemohu se zbavit pocitu, že přidělování většího množství paměti pro tak základní software, jako je terminál, je zbytečné plýtvání zdroji. Tyto programy by měly být co nejmenší, měly by být schopny fungovat na jakémkoliv „boxu“, dokonce i na botě, pokud někdy dojdeme k tomu, že je budeme muset vybavovat Linuxovými systémy (a víte, že to tak bude). Ale s těmito čísly se spotřeba paměti stane v budoucnosti problémem v jakémkoliv prostředí při spuštění několika terminálů, kromě situace s těmi nejlehčími a nejvíce omezenými možnostmi. Aby to kompenzovaly, GNOME Terminal, Konsole, urxvt, Terminator a Xfce Terminal mají Daemon-režim, který umožňuje spravovat několik terminálů skrze jeden proces, čímž se omezuje jejich spotřeba paměti.
Během svých testů jsem narazil na další překvapivý výsledek týkající se diskového čtení a zápisu: očekával jsem, že tu nic neobjevím, ale ukázalo se, že některé terminály zapisují největší objemy dat na disk. Knihovna VTE v podstatě uchovává na disku buffer pro scrolling (tato vlastnost , a to se děje dodnes). Ale na rozdíl od starých implementací, nyní jsou alespoň tato data šifrována pomocí AES256 GCM (). Ale vyvstává logická otázka, co je na knihovně VTE tak výjimečného, že vyžaduje tak netradiční přístup k implementaci…
Závěr
V první části článku jsme zjistili, že terminály založené na VTE mají dobrý soubor funkcí, ale nyní vidíme, že to souvisí s některými náklady na zajištění jejich výkonu. V současnosti paměť nepředstavuje problém, protože všechny terminály VTE mohou být spravovány prostřednictvím Daemon procesu, který omezuje jejich spotřebu. Nicméně staré systémy s fyzickými omezeními ohledně množství operační paměti a bufferu jádra mohou stále potřebovat starší verze terminálů, jelikož spotřebovávají výrazně méně zdrojů. Ačkoli terminály VTE se osvědčily v testech propustnosti (scrolling), jejich latence zobrazení dat na displeji přesahuje stanovený práh v uživatelské příručce GNOME. Je pravděpodobné, že vývojáři VTE by si toho měli být vědomi. Pokud vezmeme v úvahu, že i pro začínající uživatele Linuxu je setkání s terminálem nevyhnutelné, mohli by ho učinit přívětivějším pro uživatele. Pro zkušené geeky může přechod z výchozího terminálu znamenat dokonce snížení zátěže na zrak a možnost vyhnout se profesionálním úrazům a nemocem v budoucnu způsobeným dlouhými pracovními sezeními. Bohužel pouze staré xterm a mlterm nás přivádějí k magické latenci 10 milisekund, což je pro mnoho nepřijatelné.
Kontrolní měření také ukázala, že v důsledku vývoje grafických prostředí Linuxu museli vývojáři učinit řadu kompromisů. Některým uživatelům se doporučuje podívat se na běžné správce oken, protože ty zajišťují značné snížení pingu. Bohužel pro Wayland se nepodařilo změřit zpoždění: program Typometer, který jsem používal, byl vytvořen právě pro to, co má Wayland zamezit — špehování ostatních oken. Doufám, že kompozice Wayland bude výkonnější než X.org, a také doufám, že v budoucnu někdo najde způsob, jak vyhodnotit úroveň zpoždění v tomto prostředí.
Zdroj: habr.com
