Niekoľko slov z našej prekladateľskej kancelárie: zvyčajne sa každý snaží prekladať najnovšie materiály a publikácie a my nie sme výnimkou. Ale terminály nie sú niečo, čo sa aktualizuje raz týždenne. Preto sme pre vás preložili článok Antoina Beauprého, ktorý bol publikovaný na jar 2018: napriek svojmu značnému „vek“ podľa moderných štandardov podľa nášho názoru materiál vôbec nestratil svoju aktuálnosť. Navyše to bola pôvodne séria dvoch článkov, no rozhodli sme sa ich spojiť do jedného veľkého príspevku.
Terminály majú v histórii počítačov osobitné miesto, no v posledných desaťročiach boli nútené prežiť popri príkazovom riadku, keďže grafické rozhrania sa stali všadeprítomnými. nahradili svoje vlastné , ktoré boli zasa modifikáciou systémov založených na diernych štítkoch a prepínačoch. Moderné distribúcie prichádzajú s množstvom emulátorov terminálov všetkých tvarov a farieb. A zatiaľ čo mnohí sú spokojní so štandardným terminálom, ktorý poskytuje ich pracovné prostredie, niektorí hrdo používajú úplne exotický softvér na spustenie svojho obľúbeného shellu alebo textového editora. Ako však uvidíme v tomto článku, nie všetky terminály boli vytvorené na rovnakom obrázku: veľmi sa líšia funkčnosťou, veľkosťou a výkonom.
Niektoré terminály majú úplne prekvapivé bezpečnostné diery a väčšina z nich má úplne inú sadu funkcií, od podpory rozhrania s kartami až po skriptovanie. Hoci my , tento článok je aktualizáciou predchádzajúceho materiálu, ktorý čitateľom pomôže určiť, ktorý terminál použiť v roku 2018. Prvá polovica článku porovnáva funkcie a druhá polovica hodnotí výkon.
Tu sú terminály, ktoré som skontroloval:
Toto nemusia byť najnovšie verzie, keďže som bol v čase písania tohto článku obmedzený na stabilné zostavy, ktoré som mohol spustiť na Debian 9 alebo Fedore 27. Jedinou výnimkou je Alacritty. Je to potomok GPU akcelerovaných terminálov a je napísaný v nezvyčajnom a novom jazyku pre túto úlohu – Rust. Z mojej kontroly som vylúčil webové terminály (vrátane tých na ), pretože predbežné testy ukázali ich extrémne slabý výkon.
Podpora Unicode
Svoje testy som začal s podporou Unicode. Prvým testom terminálov bolo zobrazenie reťazca Unicode z : „é, Δ, И, ק, م, ๗, あ, 叶, 葉 a 말.“ Tento jednoduchý test ukazuje, či môže terminál správne fungovať na celom svete. Terminál xterm nezobrazuje arabské znaky v predvolenej konfigurácii:
Štandardne xterm používa klasický „pevný“ font, ktorý podľa , má „podstatné pokrytie Unicode od roku 1997“. V tomto písme sa deje niečo, čo spôsobuje, že znak sa zobrazuje ako prázdny rámik a znak sa konečne začne zobrazovať správne až vtedy, keď sa písmo textu zväčší na 20+ bodov. Táto „oprava“ však preruší zobrazenie iných znakov Unicode:
Tieto snímky obrazovky boli urobené vo Fedore 27, pretože poskytovala lepšie výsledky ako Debian 9, kde niektoré staršie verzie terminálov (konkrétne mlterm) nedokázali správne spracovať fonty. Našťastie to bolo opravené v neskorších verziách.
Teraz si všimnite, ako je riadok zobrazený v xterm. Ukazuje sa, že symbol Mem a nasledujúci semitský pozrite si skripty štýlu RTL (), takže technicky by sa mali zobrazovať sprava doľava. Webové prehliadače, ako napríklad Firefox 57, spravujú vyššie uvedený riadok správne. Jednoduchšia verzia RTL textu je slovo ""v hebrejčine (). hovorí nasledovné:
„Mnoho počítačových programov nedokáže správne zobraziť obojsmerný text. Napríklad hebrejské meno „Sarah“ pozostáva zo znakov sin (ש) (ktoré sa nachádzajú vpravo), potom resh (ר) a nakoniec on (ה) (ktoré by sa mali objaviť vľavo).“
Mnoho terminálov v tomto teste neprejde: Alacritty, terminály Gnome a XFCE odvodené od VTE, urxvt, st a xterm zobrazujú „Sara“ v opačnom poradí, ako keby sme názov napísali ako „Aras“.
Ďalším problémom obojsmerných textov je, že ich treba nejako zarovnať, najmä pokiaľ ide o miešanie textov RTL a LTR. Skripty RTL by sa mali spúšťať z pravej strany okna terminálu, ale čo by sa malo stať pre terminály, ktoré majú predvolenú angličtinu LTR? Väčšina z nich nemá žiadne špeciálne mechanizmy a zarovnáva všetok text doľava (aj v Konsole). Výnimkou sú pterm a mlterm, ktoré dodržiavajú štandardy a zarovnávajú takéto čiary doprava.
Ochrana pri vložení
Ďalšou kritickou vlastnosťou, ktorú som identifikoval, je ochrana proti vloženiu. Hoci je všeobecne známe, že kúzla ako:
$ curl http://example.com/ | shsú príkazy push spúšťania kódu, málokto vie, že skryté príkazy sa môžu vkradnúť do konzoly pri kopírovaní a vkladaní z webového prehliadača, a to aj po dôkladnej kontrole. brilantne ukazuje, aký neškodný je príkaz:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitpo vložení z Hornovej webovej stránky do terminálu sa zmení na takú nepríjemnosť:
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.gitAko to funguje? V bloku je zahrnutý škodlivý kód , ktorý sa pomocou CSS presunie z pohľadu používateľa.
je jednoznačne určený na neutralizáciu takýchto útokov. V tomto režime terminály uzatvoria prilepený text do páru špeciálnych escape sekvencií, aby shell informovali o pôvode textu. To povie shellu, že môže ignorovať špeciálne znaky, ktoré môže obsahovať prilepený text. Všetky terminály späť na úctyhodný xterm podporujú túto funkciu, ale prilepenie v režime hranatých zátvoriek vyžaduje podporu od shellu alebo aplikácie spustenej na termináli. Napríklad pomocou softvéru (rovnaký Bash), potrebuje súbor ~/.inputrc:
set enable-bracketed-paste onBohužiaľ, Horn testovacia stránka tiež ukazuje, ako obísť túto ochranu cez samotné formátovanie textu a predčasne skončiť s aplikáciou Bracketed módu. Funguje to preto, lebo niektoré terminály správne nefiltrujú sekvencie escape pred pridaním svojich vlastných. Napríklad v mojom sa mi nikdy nepodarilo úspešne dokončiť testy Konsole ani pri správnej konfigurácii .inputrc súbor. To znamená, že môžete ľahko poškodiť konfiguráciu systému v dôsledku nepodporovanej aplikácie alebo nesprávne nakonfigurovaného shellu. Toto je obzvlášť nebezpečné pri prihlasovaní sa na vzdialené servery, kde je starostlivá konfiguračná práca menej bežná, najmä ak máte veľa takýchto vzdialených počítačov.
Dobrým riešením tohto problému je doplnok na potvrdenie prilepenia pre terminál urxvt, ktorý jednoducho žiada o povolenie vložiť akýkoľvek text, ktorý obsahuje nové riadky. Nenašiel som bezpečnejšiu možnosť pre textový útok opísaný Hornom.
Karty a profily
Populárnou funkciou je v súčasnosti podpora rozhrania s kartami, ktoré budeme definovať ako jedno okno terminálu obsahujúce niekoľko ďalších terminálov. Táto funkcia sa líši pre rôzne terminály, a hoci tradičné terminály xterm nepodporujú karty vôbec, modernejšie inkarnácie terminálov, ako sú Xfce Terminal, GNOME Terminal a Konsole, túto funkciu majú. Urxvt tiež podporuje karty, ale iba ak používate doplnok. Ale pokiaľ ide o samotnú podporu kariet, Terminator je nesporným lídrom: nielenže podporuje karty, ale môže tiež usporiadať terminály v ľubovoľnom poradí (pozri obrázok nižšie).
Ďalšou vlastnosťou Terminátora je schopnosť „zoskupovať“ tieto karty a odosielať rovnaké stlačenia kláves na viacero terminálov súčasne, čo poskytuje hrubý nástroj na vykonávanie hromadných operácií na viacerých serveroch súčasne. Podobná funkcia je implementovaná aj v Konsole. Ak chcete použiť túto funkciu v iných termináloch, musíte použiť softvér tretích strán ako napr , alebo .
Karty fungujú obzvlášť dobre, keď sú spárované s profilmi: napríklad môžete mať jednu kartu pre e-mail, druhú pre chat atď. Toto je dobre podporované terminálmi Konsole a GNOME. Obe umožňujú každej karte automaticky spustiť svoj vlastný profil. Terminator podporuje aj profily, no nenašiel som spôsob, ako automaticky spustiť určité programy pri otvorení konkrétnej karty. Ostatné terminály pojem „profil“ vôbec nemajú.
Volániky
Posledná vec, ktorej sa budem venovať v prvej časti tohto článku, je vzhľad terminálov. Napríklad GNOME, Xfce a urxvt podporujú transparentnosť, ale nedávno upustili od podpory obrázkov na pozadí, čo núti niektorých používateľov prejsť na terminál . Osobne som s ním spokojný a je jednoduchý xresources, ktorý nastavuje základnú množinu farieb pozadia pre urxvt. Problémy však môžu spôsobiť aj neštandardné farebné motívy. Napríklad, s aplikáciami и , keďže už používajú svoje vlastné farby.
nepodporovali farby a nové boli často obmedzené na 256-farebnú paletu. Pre pokročilých používateľov, ktorí upravujú svoje terminály, môžu byť výzvy shellu alebo stavové riadky zložitým spôsobom nepríjemným obmedzením. sleduje, ktoré terminály majú podporu „True Color“. Moje testy potvrdzujú, že terminály st, Alacritty a VTE dokonale podporujú True Color. Ostatné terminály na tom nie sú v tomto smere príliš dobre a v podstate nezobrazujú ani 256 farieb. Nižšie môžete vidieť rozdiel medzi podporou True Color v termináloch GNOME, st a xterm, ktoré to robia dobre so svojou 256 farebnou paletou, a urxvt, ktorý nielenže neprejde testom, ale dokonca namiesto nich zobrazuje niektoré blikajúce znaky.
Niektoré terminály tiež analyzujú text na vzory adries URL, aby bolo možné kliknúť na odkazy. Platí to pre všetky terminály odvodené od VTE, zatiaľ čo urxvt vyžaduje špeciálny doplnok, ktorý by transformoval adresy URL kliknutím alebo pomocou klávesovej skratky. Iné terminály Zobrazované adresy URL som testoval inými spôsobmi.
Nakoniec, novým trendom v termináloch je voliteľnosť vyrovnávacej pamäte. Napríklad st nemá vyrovnávaciu pamäť rolovania; predpokladá sa, že používateľ použije terminálový multiplexer ako tmux a .
Alacritty tiež nemá vyrovnávacie pamäte spätného posunu, ale jeho podporu vďaka „rozsiahlej spätnej väzbe“ na túto tému od používateľov. Okrem týchto povýšencov každý terminál, ktorý som testoval a ktorý som našiel, podporuje spätné posúvanie.
medzisúčty
V druhej časti materiálu (v origináli to boli dva rôzne články - cca. pruh) porovnáme výkon, využitie pamäte a latenciu. Ale už teraz vidíme, že niektoré z predmetných terminálov majú vážne nedostatky. Napríklad používatelia, ktorí pravidelne pracujú s RTL skriptami, môžu chcieť zvážiť mlterm a pterm, pretože zvládajú podobné úlohy lepšie ako ostatní. Výborne sa predviedol aj Konsole. Používatelia, ktorí nepracujú so skriptami RTL, si môžu vybrať niečo iné.
Z hľadiska ochrany pred vložením škodlivého kódu urxvt vyniká špeciálnou implementáciou ochrany proti tomuto typu útoku, ktorá sa mi zdá rozhodne vhodná. Pre tých, ktorí hľadajú nejaké zvončeky a píšťalky, stojí za to pozrieť sa na Konsole. Nakoniec stojí za zmienku, že VTE je vynikajúci základ pre terminály, ktorý zaručuje podporu farieb, rozpoznávanie URL atď. Na prvý pohľad môže predvolený terminál, ktorý sa dodáva s vaším obľúbeným prostredím, spĺňať všetky požiadavky, no nechajme túto otázku otvorenú, kým nepochopíme výkon.
Pokračujme v rozhovore
Vo všeobecnosti sa samotný výkon terminálov môže zdať ako pritiahnutý problém, ale ako sa ukazuje, niektoré z nich vykazujú prekvapivo vysokú latenciu pre softvér takého základného typu. Ďalej sa pozrieme na to, čo sa tradične nazýva „rýchlosť“ (v skutočnosti ide o rýchlosť rolovania) a spotrebu pamäte terminálu (s upozornením, že to dnes nie je také kritické ako pred desiatkami rokov).
Oneskorenie
Po dôkladnom preštudovaní výkonu terminálu som dospel k záveru, že najdôležitejším parametrom je v tomto smere latencia (ping). Vo svojom článku Pavel Fatin sa pozrel na latenciu rôznych textových editorov a naznačil, že terminály môžu byť v tomto smere pomalšie ako najrýchlejšie textové editory. Bol to tento náznak, ktorý ma nakoniec priviedol k tomu, že som si spustil vlastné testy a napísal tento článok.
Ale čo je latencia a prečo je taká dôležitá? Fatin to vo svojom článku definoval ako „oneskorenie medzi stlačením klávesu a príslušnou aktualizáciou obrazovky“ a citoval ho , v ktorom sa uvádza: „Oneskorenie vizuálnej spätnej väzby na obrazovke počítača má dôležitý vplyv na správanie a spokojnosť pisára.“
Fatin vysvetľuje, že tento ping má hlbšie dôsledky než len spokojnosť: „písanie sa stáva pomalším, vyskytuje sa viac chýb a zvyšuje sa napätie očí a svalov.“ Inými slovami, veľké oneskorenie môže viesť k preklepom a tiež nižšej kvalite kódu, pretože vedie k dodatočnej kognitívnej záťaži mozgu. Ale čo je horšie je, že ping „zvyšuje namáhanie očí a svalov“, čo z toho zrejme vyplýva nabudúce (Autor má zrejme na mysli problémy s očným svalstvom, chrbtom, rukami a samozrejme zrakom - cca. pruh) v dôsledku opakovaného stresu.
Niektoré z týchto účinkov sú známe už dlho a výsledky , publikovaný už v roku 1976 v časopise Ergonomics, uviedol, že oneskorenie 100 milisekúnd "výrazne zhoršuje rýchlosť písania." Nedávno bola predstavená používateľská príručka GNOME za 10 milisekúnd, a ak pôjdete ďalej, potom ukazuje, že 1 milisekunda je ideálna.
Fatin vykonal svoje testy na textových editoroch; vytvoril prenosný nástroj tzv , ktorý som použil na testovanie pingu v terminálových emulátoroch. Majte na pamäti, že test bol vykonaný v simulačnom režime: v skutočnosti musíme brať do úvahy latenciu vstupu (klávesnica, ovládač USB atď.) aj výstupu (vyrovnávacia pamäť grafickej karty, monitor). Podľa Fatina je to v typických konfiguráciách asi 20 ms. Ak máte herné vybavenie, môžete tento údaj dosiahnuť už za 3 milisekúndy. Keďže už máme takýto rýchly hardvér, aplikácia nemusí pridávať vlastnú latenciu. Fatinovým cieľom je dosiahnuť latenciu aplikácie na 1 milisekundu alebo dokonca dosiahnuť vytáčanie bez ako v .
Tu sú výsledky mojich meraní, ako aj niektoré Fatinove výsledky, aby som ukázal, že môj experiment súhlasí s jeho testami:
Prvá vec, ktorá ma zarazila, bola lepšia doba odozvy starších programov ako xterm a mlterm. S najhoršou latenciou registra (2,4 ms) dopadli lepšie ako najrýchlejší moderný terminál (10,6 ms pre st). Žiadny moderný terminál neklesne pod hranicu 10 milisekúnd. Najmä Alacritty nespĺňa tvrdenie „najrýchlejší dostupný emulátor terminálu“, hoci jeho skóre sa od prvého preskúmania v roku 2017 zlepšilo. Ozaj, autori projektu a pracuje sa na zlepšení displeja. Treba tiež poznamenať, že Vim používajúci GTK3 je rádovo pomalší ako jeho náprotivok GTK2. Z toho môžeme vyvodiť záver, že GTK3 vytvára dodatočnú latenciu a to sa odráža vo všetkých ostatných termináloch, ktoré ho používajú (Terminátor, Xfce4 Terminal a GNOME Terminal).
Rozdiely však nemusia byť okom badateľné. Ako vysvetľuje Fatin, „nemusíte si uvedomovať oneskorenie, aby to na vás malo vplyv.“ Fatin tiež varuje pred štandardnou odchýlkou: „akékoľvek poruchy latencie (jitter) vytvárajú dodatočný stres v dôsledku ich nepredvídateľnosti.
Vyššie uvedený graf je prevzatý na čistom Debiane 9 (stretch) s . Toto prostredie poskytuje najlepšie výsledky v testoch latencie. Ako sa ukázalo, GNOME vytvára dodatočný ping 20 ms pre všetky merania. Možným vysvetlením je prítomnosť programov so synchrónnym spracovaním vstupných udalostí. Fatin uvádza príklad pre takýto prípad , ktorý pridáva oneskorenie synchrónnym spracovaním všetkých vstupných udalostí. GNOME sa štandardne dodáva aj so správcom okien , čo vytvára ďalšiu vrstvu vyrovnávacej pamäte, ktorá ovplyvňuje ping a pridáva minimálne 8 milisekúnd latencie.
Rýchlosť posúvania
Ďalším testom je tradičný test „rýchlosti“ alebo „šírky pásma“, ktorý meria, ako rýchlo dokáže terminál posúvať stránku pri zobrazení veľkého množstva textu na obrazovke. Mechanika testu sa líši; pôvodný test bol jednoducho vygenerovať rovnaký textový reťazec pomocou príkazu seq. Medzi ďalšie testy patrí test Thomasa E. Dickeyho (správca xterm), ktorý opakovane . V ďalšom prehľade výkonu terminálu používa reťazec náhodných bajtov zakódovaný v base32, ktorý sa odošle do terminálu pomocou cat. Luu považuje takýto test za „tak zbytočný benchmark, aký si človek dokáže predstaviť“ a namiesto toho navrhuje použiť terminálnu odozvu ako primárnu metriku. Dickey tiež označuje svoj test za zavádzajúci. Obaja autori však uznávajú, že problémom môže byť šírka pásma terminálového okna. Luu objavil zamrznutie Emacs Eshell pri zobrazovaní veľkých súborov a Dickey optimalizoval terminál, aby sa zbavil vizuálnej pomalosti xtrermu. Takže tento test má stále určité výhody, ale keďže proces vykresľovania je veľmi odlišný od terminálu k terminálu, môže byť tiež použitý ako testovací komponent na testovanie iných parametrov.
Tu vidíme, že rxvt a st ťahajú pred konkurenciou, po ktorých nasleduje oveľa novší Alacritty, ktorý je navrhnutý so zameraním na výkon. Nasledujú Xfce (rodina VTE) a Konsole, ktoré sú takmer dvakrát rýchlejšie. Posledný je xterm, ktorý je päťkrát pomalší ako rxvt. Počas testu sa xterm tiež veľmi vlnil, takže prechádzajúci text bol ťažko viditeľný, aj keď išlo o rovnaký riadok. Konzola bola rýchla, ale občas to bolo zložité: displej z času na čas zamrzol, zobrazoval čiastočný text alebo ho nezobrazoval vôbec. Ostatné terminály zobrazovali reťazce jasne, vrátane st, Alacritty a rxvt.
Dickey vysvetľuje, že rozdiely vo výkone sú spôsobené dizajnom vyrovnávacích pamätí na posúvanie v rôznych termináloch. Najmä obviňuje rxvt a ďalšie terminály z „nedodržiavania všeobecných pravidiel“:
„Na rozdiel od xterm sa rxvt nepokúsil zobraziť všetky aktualizácie. Ak zaostáva, odmietne niektoré aktualizácie, aby to dohnal. To malo väčší vplyv na zdanlivú rýchlosť rolovania ako na organizáciu vnútornej pamäte. Jednou nevýhodou bolo, že animácia ASCII bola trochu nepresná."
Dickey navrhuje použiť tento zdroj, aby napravil túto vnímanú pomalosť xterm , čo umožňuje xterm zahodiť niektoré aktualizácie obrazovky, aby udržal krok s tokom. Moje testy potvrdzujú, že fastScroll zlepšuje výkon a prináša xterm na rovnakú úroveň ako rxvt. Toto je však dosť hrubá barlička, ako sám Dickey vysvetľuje: "niekedy sa zdá, že xterm - ako konzola - sa zastaví, pretože čaká na novú sadu aktualizácií obrazovky po odstránení niektorých." V tomto duchu sa zdá, že iné terminály našli najlepší kompromis medzi rýchlosťou a integritou displeja.
Spotreba zdrojov
Bez ohľadu na to, či má zmysel považovať rýchlosť rolovania za metriku výkonu, tento test nám umožňuje simulovať zaťaženie terminálov, čo nám zase umožňuje merať ďalšie parametre, ako je využitie pamäte alebo disku. Metriky sa získali vykonaním špecifikovaného testu nasledujúce pod monitorovaním procesov Python. Zbieral údaje z meračov pre ru_maxrss, suma ru_oublock и ru_inblock a jednoduchý časovač.
V tomto teste je ST na prvom mieste s najnižšou priemernou spotrebou pamäte 8 MB, čo nie je prekvapujúce vzhľadom na to, že hlavnou myšlienkou dizajnu je jednoduchosť. mlterm, xterm a rxvt spotrebujú o niečo viac - asi 12 MB. Ďalším pozoruhodným výsledkom je Alacritty, ktorý na spustenie vyžaduje 30 MB. Potom sú tu terminály rodiny VTE s číslami od 40 do 60 MB, čo je dosť veľa. Túto spotrebu možno vysvetliť skutočnosťou, že tieto terminály používajú knižnice vyššej úrovne, napríklad GTK. Konsole je na poslednom mieste s neuveriteľnou spotrebou pamäte 65 MB počas testov, aj keď to možno odôvodniť veľmi širokou škálou funkcií.
V porovnaní s predchádzajúcimi výsledkami získanými pred desiatimi rokmi začali všetky programy spotrebúvať citeľne viac pamäte. Xterm predtým vyžadoval 4 MB, ale teraz vyžaduje 15 MB len pri spustení. K podobnému zvýšeniu spotreby došlo aj pre rxvt, ktorý teraz vyžaduje 16 MB po vybalení. Xfce Terminal zaberá 34 MB, čo je trikrát viac ako predtým, ale GNOME Terminal vyžaduje len 20 MB. Samozrejme, všetky predchádzajúce testy boli realizované na 32-bitovej architektúre. Na LCA 2012 Rusty Russell , že existuje mnoho jemnejších dôvodov, ktoré by mohli vysvetliť zvýšenie spotreby pamäte. Napriek tomu teraz žijeme v dobe, kde máme gigabajty pamäte, takže si nejako poradíme.
Nemôžem sa však ubrániť pocitu, že vyčleniť viac pamäte na niečo tak zásadné, ako je terminál, je plytvanie zdrojmi. Tieto programy by mali byť najmenšie z najmenších, mali by byť schopné bežať na akejkoľvek „škatuľke“, dokonca aj na krabici od topánok, ak sa niekedy dostaneme do bodu, keď budú musieť byť vybavené systémami Linux (a viete, že to tak bude ). Ale s týmito číslami sa využitie pamäte stane v budúcnosti problémom v akomkoľvek prostredí s viacerými terminálmi, okrem niekoľkých najľahších a najviac obmedzených schopností. Aby sa to kompenzovalo, terminály GNOME, Konsole, urxvt, Terminator a Xfce Terminal majú režim démona, ktorý vám umožňuje ovládať viacero terminálov prostredníctvom jedného procesu, čím sa obmedzuje ich spotreba pamäte.
Počas svojich testov som prišiel k ďalšiemu neočakávanému výsledku ohľadom čítania a zápisu na disk: Čakal som, že tu neuvidím vôbec nič, ale ukázalo sa, že niektoré terminály zapisujú na disk najobjemnejšie dáta. Knižnica VTE teda v skutočnosti uchováva vyrovnávaciu pamäť posúvania na disku (táto funkcia a stále sa to deje). Ale na rozdiel od starších implementácií sú teraz aspoň tieto údaje šifrované pomocou AES256 GCM (). Vynára sa však rozumná otázka: čo je na knižnici VTE také výnimočné, že si vyžaduje taký neštandardný prístup k implementácii...
Záver
V prvej časti článku sme zistili, že terminály založené na VTE majú dobrú sadu funkcií, ale teraz vidíme, že to prichádza s určitými nákladmi na výkon. Pamäť teraz nie je problém, pretože všetky terminály VTE možno ovládať pomocou procesu Daemon, čo obmedzuje ich chuť do jedla. Avšak staršie systémy, ktoré majú fyzické obmedzenia týkajúce sa množstva pamäte RAM a vyrovnávacích pamätí jadra, môžu stále potrebovať staršie verzie terminálov, pretože spotrebúvajú podstatne menej zdrojov. Hoci terminály VTE fungovali dobre v testoch priepustnosti (rolovanie), ich latencia zobrazenia je nad hranicou nastavenou v používateľskej príručke GNOME. Vývojári VTE by s tým zrejme mali počítať. Ak vezmeme do úvahy, že aj pre začínajúcich používateľov Linuxu je stretnutie s terminálom nevyhnutné, môžu ho urobiť užívateľsky prívetivejším. Pre skúsených geekov môže prechod z predvoleného terminálu dokonca znamenať menšiu únavu očí a schopnosť vyhnúť sa budúcim pracovným zraneniam a chorobám v dôsledku dlhých pracovných stretnutí. Žiaľ, len starý xterm a mlterm nás privádza k magickej hranici pingu 10 milisekúnd, čo je pre mnohých neprijateľné.
Benchmarkové merania tiež ukázali, že vzhľadom na vývoj linuxových grafických prostredí museli vývojári urobiť množstvo kompromisov. Niektorí používatelia sa možno budú chcieť pozrieť na bežných správcov okien, pretože poskytujú výrazné zníženie počtu pingov. Bohužiaľ nebolo možné merať latenciu pre Wayland: program Typometer, ktorý som použil, bol vytvorený na to, aby Wayland zabránil: špehovanie iných okien. Dúfam, že Wayland compositing bude fungovať lepšie ako X.org a tiež dúfam, že v budúcnosti niekto nájde spôsob, ako merať latenciu v tomto prostredí.
Zdroj: hab.com