Pár slov od našej prekladovej agentúry: zvyčajne sa všetci snažia prekladať najnovšie materiály a publikácie, a my nie sme výnimkou. Avšak terminály nie sú niečo, čo sa aktualizuje každý týždeň. Preto sme pre vás preložili článok Antoine Bopre, publikovaný na jar 2018: napriek tomu, že má solídny „vek“ podľa moderných mierok, podľa nášho názoru materiál vôbec nestratil aktuálnosť. Okrem toho je v originále to séria dvoch článkov, ale rozhodli sme sa ich spojiť do jedného veľkého príspevku.
Terminály zaujímajú osobitné miesto v počítačovej histórii, ale v posledných desaťročiach museli doslova prežiť spolu s príkazovým riadkom na pozadí všadeprítomných grafických rozhraní. nahradili svojich , ktoré, na druhej strane, boli modifikáciou systémov na perforovaných kartách a prepínačoch. Moderné distribúcie prichádzajú s množstvom emulátorov terminálu všetkých tvarov a farieb. A zatiaľ čo mnohí sa spokojne uspokoja s bežným terminálom, ktorý poskytuje ich pracovné prostredie, niektorí s hrdosťou používajú otvorene exotický softvér na spustenie svojich obľúbených shellov alebo textových editorov. Ale, ako uvidíme z tohto článku, nie všetky terminály boli vytvorené rovnako: výrazne sa líšia vo funkčnosti, veľkosti a výkonnosti.
Niektoré terminály majú priamo ohromujúce bezpečnostné diery, plus väčšina z nich má úplne odlišný set funkcií, od podpory rozhrania s kartami po skripty. Hoci sme , tento článok je aktualizáciou predchádzajúceho materiálu, ktorý pomôže čitateľom určiť, aký terminál používať v roku 2018. V prvej polovici článku sa porovnávajú funkcie, a v druhej sa hodnotí výkon.
Tu sú terminály, ktoré som preskúmal:
Možno to nie sú najnovšie verzie, pretože som sa obmedzil na stabilné zostavy v čase písania materiálu, ktoré som dokázal rozbehnúť na Debian 9 alebo Fedora 27. Jedinou výnimkou je Alacritty. Je potomkom terminálov s GPU akceleráciou a je napísaný v nezvyčajnom a novom jazyku pre túto úlohu — Rust. Vylúčil som zo svojho prehľadu webové terminály (vrátane, a na ), pretože predbežné testy ukázali ich extrémne nízku výkonnosť.
Podpora Unicode
Svoje testy som začal s podporou Unicode. Prvým testom terminálov bolo zobrazenie stringu o Unicode z : „é, Δ, Й, ק, م, ๗, あ, 叶, 葉 a 말“. Tento jednoduchý test ukazuje, či terminál môže správne fungovať po celom svete. Terminál xterm nezobrazuje arabský znak v predvolenej konfigurácii:
Podľa predvoleného nastavenia xterm používa klasický „fixný“ font, ktorý, podľa , má „podstatný pokrytie Unicode od roku 1997“. V tomto fonte sa deje niečo, čo spôsobuje, že znak sa zobrazuje ako prázdny rámček a až pri zväčšení veľkosti textu na 20+ bodov sa znak konečne začne zobrazovať správne. Avšak takýto „oprava“ pokazí zobrazenie iných znakov Unicode.
Tieto snímky boli vyrobené vo Fedore 27, pretože táto verzia dávala lepšie výsledky než Debian 9, kde niektoré staršie verzie terminálov (konkrétne — mlterm) nemohli správne fungovať s fontami. Našťastie, to bolo opravené v novších verziách.
Teraz si všimnite zobrazenie line v xterm. Zjavne, znak Mem a nasledujúci za ním Semitic patria do scénarov písania RTL (), takže technicky by sa mali zobrazovať sprava doľava. Webové prehliadače, napríklad Firefox 57, správne spracovávajú vyššie uvedený riadok. Jednoduchšou alternatívou pre RTL text je slovo „“ v hebrejčine (). hovorí nasledovné:
„Mnoho počítačových programov nedokáže správne zobraziť obojsmerný text. Napríklad hebrejské meno „Sára“ pozostáva zo znakov sin (ש) (ktorý sa zobrazuje sprava), následne reš (ר) a nakoniec che (ה) (ktorý by sa mal zobraziť zľava)“.
Mnohé terminály tento test nesplňují: Alacritty, terminály odvozené od VTE pro Gnome a XFCE, urxvt, st a xterm zobrazují „Sara“ v obráceném pořadí, jako by bylo toto jméno zapsáno jako „Aras“.
Dalším problémem obousměrných textů je to, že je třeba nějak vyrovnat, zvláště pokud jde o mísení textů RTL a LTR. Skripty RTL by měly začínat z pravé strany okna terminálu, ale co by se mělo dít pro terminály, které ve výchozím nastavení pracují s LTR angličtinou? Většina z nich nemá žádné speciální mechanismy a vyrovnávají celý text vlevo (včetně Konsole). Výjimku tvoří pterm a mlterm, které dodržují standardy a vyrovnávají takové řádky vpravo.
Ochrana proti vkládání
Další kritická funkce, kterou jsem pro sebe určil, je ochrana proti vkládání. I když je široce známé, že příkazy typu:
$ curl http://example.com/ | shjsou příkazy pro vykoná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, dokonce i po pečlivém prozkoumání. skvěle ukazuje, jak nevinně vypadající příkaz:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitse při vložení ze stránky Horna do 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!
Zde 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 umístěn do bloku , který je CSS prostředky přesunut mimo zorné pole uživatele.
je jasně určen k neutralizaci podobných útoků. V tomto režimu terminály uzavírají vkládaný text do páru speciálních escape sekvencí, aby informovaly shell o původu tohoto textu. Shell tak dostane signál, že může ignorovat speciální znaky, které může vkládaný text obsahovat. Všechny terminály, až po venerovaný xterm, tuto funkci podporují, ale vkládání v režimu Bracketed vyžaduje podporu shellu nebo aplikace spuštěné na terminálu. Například software využívající (to samé Bash), potřebuje soubor ~/ .inputrc:
set enable-bracketed-paste onBohužiaľ, testovacia stránka Horn tiež ukazuje, ako obísť túto ochranu prostredníctvom samotného formátovania textu a predčasne ukončiť aplikáciu režimu uzavretého zoznamu. Funguje to, pretože niektoré terminály nesprávne filtrujú escape sekvencie pred pridaním vlastných. Napríklad, v mojich som sa nedokázal úspešne dokončiť testy Konsole ani pri správnej konfigurácii. .inputrc súboru. To znamená, že si môžete ľahko poškodiť konfiguráciu systému kvôli nepodporovanej aplikácii alebo nesprávne nastavenému shellu. Najmä nebezpečné je to pri prístupe na vzdialené servery, kde dôkladné prepracovanie konfigurácie sa vyskytuje menej často, a to najmä ak máte veľa takýchto vzdialených strojov.
Dobré riešenie tohto problému je plugin na potvrdenie vloženia pre terminál urxvt, ktorý jednoducho požaduje povolenie na vloženie akéhokoľvek textu, ktorý obsahuje nové riadky. Necital som nijakú bezpečnejšiu alternatívu pre textový útok popísaný Hornom.
Záložky a profily
Populárnou funkciou je podpora rozhrania so záložkami, ktoré budeme definovať ako jedno okno terminálu, obsahujúce niekoľko ďalších terminálov. Pre rôzne terminály sa táto funkcia líši a hoci tradičné terminály typu xterm vôbec nepodporujú záložky, modernejšie varianty terminálu ako Xfce Terminal, GNOME Terminal a Konsole túto funkciu majú. Zároveň Urxvt podporuje záložky, ale len pod podmienkou použitia pluginu. Z hľadiska podpory záložiek ako takých je bezpodmienečným lídrom Terminator: nielenže podporuje záložky, ale tiež môže umiestňovať terminály v náhodnom poradí (pozrite si obrázok nižšie).
Ďalšou vlastnosťou Terminatoru je možnosť „skupinovať“ tieto záložky spolu a posielať rovnaké stlačenia klávesov na niekoľko terminálov súčasne, čo poskytuje hrubý nástroj na vykonávanie masových operácií na niekoľkých serveroch naraz. Analógová funkcia je tiež implementovaná v Konsole. Na využitie tejto funkcie v iných termináloch je potrebné použiť externý softvér, ako je , alebo .
Zvlášť dobre fungujú karty v spolupráci s profilmi: napríklad môžete mať jednu kartu pre e-mail, druhú pre chat a tak ďalej. To dobre podporujú terminál Konsole a GNOME Terminal. Obe umožňujú, aby sa na každej karte automaticky spustil svoj profil. Terminátor tiež podporuje profily, ale nenašiel som spôsob, ako automaticky spustiť určité programy pri otvorení určitej karty. Iné terminály vôbec nemajú pojem „profil“.
Volániky
Posledné, čo v prvej časti tohto článku preskúmam, je vzhľad terminálov. Napríklad GNOME, Xfce a urxvt podporujú priehľadnosť, ale nedávno zrusili podporu pozadí, čo spôsobilo, že niektorí používatelia prešli na terminál. . Osobne mi vyhovuje a je to jednoduché. Xresources, ktorý nastavuje základnú sadu farieb pozadia pre urxvt. Avšak netradičné farebné témy môžu spôsobovať aj problémy. Napríklad, s aplikáciami a , pretože už používajú svoje vlastné farby.
nemal podporu farieb, a nové často obmedzovali na paletu 256 farieb. Pre pokročilých používateľov, ktorí štýlizujú svoje terminály žiadosťami shellu alebo riadkami stavu zložitými spôsobmi, to môže byť nepríjemné obmedzenie. sledovaním toho, ktoré terminály majú podporu „True Color“. Moje testovanie potvrdzuje, že st, Alacritty a terminály založené na VTE výborne podporujú True Color. Iné terminály v tomto ohľade nie sú veľmi dobre a v skutočnosti nezobrazujú ani 256 farieb. Nižšie môžete vidieť rozdiel medzi podporou True Color v GNOME, st a xterm, ktoré si s touto úlohou poradia pomocou svojej 256-farebnej palety, a urxvt, ktorý nielenže test neprejde, ale dokonca zobrazuje nejaké blikané symboly namiesto nich.
Niektoré terminály tiež analyzujú text na prítomnosť vzorov URL, aby urobili odkazy klikateľnými. To sa týka všetkých derivátov terminálov VTE, zatiaľ čo urxvt vyžaduje špeciálny modul, ktorý by transformoval URL adresy na kliknutie alebo pomocou klávesovej skratky. Iné terminály, ktoré som testoval, zobrazujú URL adresy inými spôsobmi.
Konečne, nový trend terminálov — voliteľnosť posuvného pántu. Napríklad v st nie je posuvný pánt; predpokladá sa, že používateľ bude používať terminálový multiplexor, ako je tmux a .
V Alacritty chýbajú aj spätné posuvné pánty, ale jeho podpora kvôli „rozsiahlom feedbacku“ na túto tému od používateľov. Okrem týchto výnimiek, každý overený terminál, ktorý som mohol nájsť, podporuje spätné posúvanie.
Medzičasné hodnotenie
V druhej časti materiálu (v originále to boli dva rôzne články — pozn. prekl.) porovnáme výkon, využitie pamäte a oneskorenie. Ale už vidíme, že niektoré z posudzovaných terminálov majú vážne nedostatky. Napríklad používatelia, ktorí pravidelne pracujú s RTL skriptami, môžu venovať pozornosť mlterm a pterm, pretože sa s takýmito úlohami vyrovnávajú lepšie ako ostatní. Konsole sa taktiež osvedčil. Používatelia, ktorí nepracujú s RTL skriptami, môžu zvoliť niečo iné.
Z hľadiska ochrany pred vkladaním škodlivého kódu sa urxvt vyníma svojou špeciálnou implementáciou ochrany proti tomuto typu útokov, ktorá je určite veľmi praktická. Tí, ktorí hľadajú akékoľvek vylepšenia, by sa mali pozrieť na Konsole. Nakoniec je potrebné poznamenať, že VTE je vynikajúca základňa pre terminály, ktorá zabezpečuje podporu farieb, rozpoznávanie URL a podobne. Na prvý pohľad sa môže predvolený terminál dodávaný s vašou obľúbenou prostredím javiť ako dostatočný, ale túto otázku si nechajme otvorenú, kým sa nezaoberáme výkonom.
Pokračujeme v diskusii
Vo všeobecnosti sa môže výkon terminálov zdať ako umelo vyvolaný problém, avšak ako sa ukázalo, niektoré z nich vykazujú neuveriteľne veľké oneskorenie pre softvér tohto fundamentálneho typu. Taktiež sa neskôr pozrieme na to, čo sa tradične nazýva „rýchlosťou“ (v skutočnosti je to rýchlosť posúvania) a spotrebu pamäte terminálom (s ohľadom na to, že dnes to nie je tak kritické, ako pred desaťročiami).
Oneskorenie
Po dôkladnom preskúmaní výkonu terminálov som dospel k záveru, že najdôležitejším parametrom v tomto ohľade je veľkosť oneskorenia (ping). Vo svojom článku Pavel Fatin preskúmal oneskorenie rôznych textových editorov a naznačil, že terminály môžu v tomto ohľade pracovať pomalšie ako najrýchlejšie textové editory. Tento náznak ma nakoniec priviedol k spusteniu vlastných testov a napísaniu tohto článku.
Ale čo to vlastne je oneskorenie a prečo je dôležité? Vo svojom článku Fatin definoval oneskorenie ako „oneskorenie medzi stlačením klávesy a zodpovedajúcej aktualizácie obrazovky“ a citoval , v ktorej sa uvádza: „Oneskorenie vo vizuálnej spätnej väzbe na obrazovke počítača má významný vplyv na správanie typistky a jej spokojnosť.“
Fatin vysvetľuje, že takéto oneskorenie má hlbšie dôsledky než len spokojnosť: „písanie sa spomaľuje, vzniká viac chýb, zvyšuje sa napätie očí a svalov.“ Inými slovami, veľké oneskorenie môže viesť k preklepom a zníženiu kvality kódu, pretože spôsobuje dodatočné kognitívne zaťaženie mozgu. Ale čo je ešte horšie, oneskorenie „zvyšuje napätie očí a svalov“, čo zjavne naznačuje v budúcnosti (zjavne autor má na mysli problémy so svalmi očí, chrbtom, rukami a, samozrejme, zrakom — pozn. prekladateľa.) kvôli opakovanému napätiu.
Niektoré z týchto efektov sú známe už dlhšie a výsledky , publikované už v roku 1976 v časopise Ergonomics, hovoria, že oneskorenie 100 milisekúnd „výrazne zhoršuje rýchlosť písania“. Nedávno bola do používateľskej príručky GNOME zahrnutá 10 milisekúnd, a ak ísť ďalej, tak ukazuje, že ideálom je 1 milisekunda.
Fatin vykonával svoje testy na textových editoroch; vytvoril prenosný nástroj nazvaný , ktorý som použil na kontrolu pingu v emulátoroch terminálu. Majte na pamäti, že test bol vykonaný v simulačnom režime: v skutočnosti musíme zohľadniť aj oneskorenie vstupu (klávesnica, USB ovládač a tak ďalej) a výstupu (buffer grafickej karty, monitor). Podľa Fatina sa v typických konfiguráciách pohybuje okolo 20 ms. Pri disponovaní herným zariadením je možné dosiahnuť hodnotu len 3 milisekundy. Keďže už máme také rýchle zariadenie, aplikácia by nemala spôsobovať ďalšie oneskorenie. Cieľom Fatina je znížiť oneskorenie aplikácie na 1 milisekundu, alebo dokonca dosiahnuť nastavenie bez , ako v .
Tu sú výsledky mojich meraní a niektoré výsledky Fatina, aby som ukázal, že môj experiment súhlasí s jeho testami:
Prvá vec, ktorá ma prekvapila — je lepší čas odozvy starých programov, ako sú xterm a mlterm. S najhorším oneskorením registrácie (2,4 ms) dosiahli lepší výsledok ako najrýchlejší moderný terminál (10,6 ms pre st). Žiadny moderný terminál sa nedostáva pod prah 10 milisekúnd. Konkrétne Alacritty nespĺňa požiadavky na "najrýchlejší z existujúcich emulátorov terminálu", hoci jeho výsledky sa zlepšili od prvej kontroly v roku 2017. Skutočne, autori projektu a pracujú na zlepšení zobrazenia. Je tiež potrebné poznamenať, že Vim, ktorý používa GTK3, je radovo pomalší ako jeho ekvivalent GTK2. Z toho možno vyvodiť, že GTK3 vytvára dodatočné oneskorenie, a to sa odráža na všetkých ostatných termináloch, ktoré ho používajú (Terminator, Xfce4 Terminal a GNOME Terminal).
Avšak pre oko môžu byť rozdiely neznateľné. Ako vysvetľuje Fatin: "nie je potrebné si uvedomiť existenciu oneskorenia, aby malo na vás vplyv". Fatin tiež varuje pred štandardnou odchýlkou: "akékolvek poruchy v trvaní oneskorenia (trasenie) spôsobujú dodatočnú záťaž kvôli ich nepredvídateľnosti."
Graf vyššie bol získaný na čistom Debian 9 (stretch) s Tento prostredie dosahuje najlepšie výsledky v testoch na určenie oneskorenia. Ukázalo sa, že GNOME vytvára dodatočný ping 20 ms pre všetky merania. Možným vysvetlením je prítomnosť programov so synchronným spracovaním vstupných udalostí. Fatin uvádza ako príklad pre takúto situáciu , ktorý pridáva oneskorenie spracovaním všetkých vstupných udalostí synchronne. Predvolene je GNOME tiež vybavený správcom okien , ktorý vytvára dodatočnú vrstvu vyrovnávacej pamäte, čo ovplyvňuje ping a pridáva minimálne 8 milisekúnd oneskorenia.
Rýchlosť posúvania
Ďalší test je tradičná kontrola „rýchlosti“ alebo „priepustnosti“, ktorá meria, ako rýchlo môže terminál posúvať stránku, zobrazujúc veľké množstvo textu na obrazovke. Mechanika testu sa líši; pôvodný test spočíval v jednoduchej generácii tej istej textovej rady pomocou príkazu seq. Iné testy zahŕňajú kontrolu Thomasa E. Dicka (sprevádzajúceho xterm), v rámci ktorej sa opakovane . V ďalšom prehľade výkonu terminálov používa radu náhodných bajtov v kódovaní base32, ktorá sa vypisuje do terminálu pomocou príkazu cat. Luu považuje takýto test za "takmer bezcenný benchmark, aký si len možno predstaviť" a navrhuje použiť namiesto toho reakciu terminálu ako hlavný ukazovateľ. Dick tiež uvádza, že jeho test môže byť mätúci. Napriek tomu obaja autori uznávajú, že priepustnosť okna terminálu môže byť problémom. Luu zistil zamrznutie Emacs Eshell pri zobrazovaní veľkých súborov, zatiaľ čo Dick optimalizoval terminál, aby eliminoval vizuálnu pomalosť xterm. Preto v tomto teste stále existuje určitý dôvod, ale pretože proces vykresľovania sa výrazne líši z terminálu na terminál, môže byť použitý aj ako testovací komponent pre overenie iných parametrov.
Tu vidíme, že rxvt a st sa dostávajú na vrchol v porovnaní s konkurenciou, za nimi nasleduje podstatne novší Alacritty, ktorý sa vyvíja s dôrazom na rýchlosť. Nasledujú Xfce (rodina VTE) a Konsole, ktoré pracujú takmer dvakrát rýchlejšie. Nakoniec je tu xterm, ktorý je päťkrát pomalší ako rxvt. Počas testu xterm tiež veľmi blikotal, prechádzajúci text bolo ťažké zaostriť, aj keď to bola jedna a tá istá línia. Konsole sa ukázal byť rýchly, no občas „klamal“: displej sa občas zasekol a zobrazoval text čiastočne alebo ho vôbec nezobrazoval. Iné terminály jasne zobrazovali riadky, vrátane st, Alacritty a rxvt.
Diki vysvetľuje, že rozdiely vo výkonnosti súvisia s dizajnom posuvných bufferov v rôznych termináloch. Konkrétne obviňuje rxvt a ďalšie terminály z toho, že „nedodržiavajú spoločné pravidlá“:
„Na rozdiel od xterm, rxvt sa nesnažil zobraziť všetky aktualizácie. Ak zaostával, odmietal niektoré aktualizácie, aby dobehol. To malo väčší dopad na zdánlivú rýchlosť posúvania než na organizáciu vnútornej pamäte. Jednou nevýhodou bolo, že animácia ASCII bola niekedy trochu nepresná.“
Aby sa napravila táto zdánlivá pomalosť xterm, Diki navrhuje použiť zdroj , ktorý umožňuje xterm ignorovať niektoré aktualizácie obrazovky, aby nezaostával za tokom. Moje testy potvrdzujú, že fastScroll zvyšuje výkonnosť a posúva xterm na úroveň rxvt. To je však dosť hrubé obchádzanie, ako sám Diki vysvetľuje: „Niekedy sa xterm — ako aj konsole — zdá, že sa zastavil, keď čaká na nový súbor aktualizácií obrazovky po tom, čo niektoré z nich boli vymazané.“ V tomto kontexte sa zdá, že iné terminály našli najlepší kompromis medzi rýchlosťou a celistvosťou displeja.
Spotreba zdrojov
Bez ohľadu na rozumnosť zvažovania rýchlosti posúvania ako ukazovateľa výkonu, tento test umožňuje simulovať zaťaženie terminálov, čo zase umožňuje merať iné parametre, ako je využitie pamäte alebo disku. Metódy boli získané vykonaním uvedeného testu seq pod dohľadom procesu Python. Zhromažďoval údaje o čítačoch pre ru_maxrss, súčet ru_oublock a ru_inblock a jednoduchý časovač.
V tomto teste ST obsadila prvé miesto s najnižšou priemernou spotrebou pamäte 8 MB, čo nie je prekvapujúce, keď zohľadníme, že hlavnou myšlienkou projektu je jednoduchosť. Trochu viac spotrebúva mlterm, xterm a rxvt - okolo 12 MB. Ďalší pozoruhodný výsledok má Alacritty, ktorá na svoju činnosť potrebuje 30 MB. Následne prichádzajú terminály zo skupiny VTE s hodnotami od 40 do 60 MB, čo je dosť veľa. Takúto spotrebu možno vysvetliť tým, že tieto terminály používajú vyššie knižnice, napríklad GTK. Konsole skončilo posledné s kolosálnou spotrebou 65 MB pamäte počas testovania, hoci to možno ospravedlniť jeho veľmi širokým súborom funkcií.
V porovnaní s predchádzajúcimi výsledkami získanými pred desiatimi rokmi všetky programy začali spotrebúvať výrazne viac pamäte. Predtým Xterm vyžadoval 4 MB, teraz - 15 MB len na spustenie. Podobné zvýšenie spotreby má aj rxvt, ktorý teraz z boxu vyžaduje 16 MB. Terminál Xfce zaberá 34 MB, čo je trikrát viac ako predtým, zatiaľ čo GNOME Terminal vyžaduje len 20 MB. Samozrejme, všetky predchádzajúce testy sa vykonávali na 32-bitovej architektúre. Na LCA 2012 Rastislav Russell , existuje množstvo jemnejších príčin, ktoré môžu vysvetliť rast spotreby pamäte. Napriek tomu teraz žijeme v časoch, keď máme celé gigabajty pamäte, takže nejakým spôsobom sa s tým vysporiadame.
Napriek tomu mám pocit, že pridelenie väčšieho množstva pamäte pre také základné softvérové vybavenie, ako sú terminály, je plytvanie zdrojmi. Tieto programy by mali byť najmenšími z najmenších, mali by byť schopné fungovať na akomkoľvek „boxe“, dokonca i na obuvi, ak sa niekedy dostaneme do situácie, kedy ich bude treba vybaviť systémami Linux (a viete, že to sa stane). Ale s týmito číslami sa spotreba pamäte stane v budúcnosti problémom v akomkoľvek prostredí pri spustení niekoľkých terminálov, okrem situácie s niekoľkými najľahšími a obmedzenými možnosťami. Na kompenzáciu tohto GNOME Terminal, Konsole, urxvt, Terminator a Xfce Terminal majú Daemon-režim, ktorý umožňuje spravovať viac terminálov cez jeden proces, čo obmedzuje ich spotrebu pamäte.
Počas svojich testov som prišiel k ďalšiemu prekvapujúcemu výsledku týkajúcemu sa čítania a písania na disku: očakával som, že tu nič neuvidím, ale ukázalo sa, že niektoré terminály zapisujú najväčšie dáta na disk. Tak, knižnica VTE fakticky drží na disku buffer posúvania (táto vlastnosť , a to sa deje dodnes). Ale na rozdiel od starých realizácií, teraz sú aspoň tieto dáta šifrované pomocou AES256 GCM (). Ale vyvstáva rozumná otázka, čo je na knižnici VTE také zvláštne, že si vyžaduje taký netradičný prístup k implementácii…
Záver
V prvej časti článku sme zistili, že terminály na báze VTE majú dobrú sadu funkcií, ale teraz vidíme, že to súvisí s určitými nákladmi na zabezpečenie ich výkonu. Teraz pamäť nie je problém, pretože všetky VTE terminály je možné spravovať prostredníctvom Daemon procesu, ktorý obmedzuje ich apetít. Napriek tomu staré systémy, ktoré majú fyzické obmedzenia z hľadiska počtu operačnej pamäte a bufferu jadra, môžu stále potrebovať staršie verzie terminálov, pretože spotrebujú oveľa menej zdrojov. Hoci terminály VTE preukázali dobré výsledky v testoch propustnosti (posúvanie), ich oneskorenie zobrazenia údajov na displeji je vyššie ako stanovený prah v užívateľskej príručke GNOME. Pravdepodobne by si vývojári VTE mali toto uvedomiť. Ak vezmeme do úvahy, že aj pre začiatočníkov na Linuxe je stretnutie s terminálom nevyhnutné, mohli by tento terminál spraviť viac priateľským pre používateľov. Pre skúsených geekov môže prechod z predvoleného terminálu znamenať dokonca zníženie zaťaženia zraku a možnosť vyhnúť sa profesionálnym zraneniam a ochoreniam v budúcnosti kvôli dlhým pracovným fázam. Bohužiaľ, len staré xterm a mlterm nás približujú k magickému prahu pingovania 10 milisekúnd, čo je pre mnohých neprijateľné.
Kontrolné merania tiež ukázali, že kvôli rozvoju grafických prostredí Linux museli vývojári pristúpiť k niekoľkým kompromisom. Niektorí používatelia by mali zvážiť tradičné správca okien, pretože ponúkajú významné zníženie latencie. Obávam sa však, že pre Wayland sa mi nepodarilo zmerať oneskorenie: program Typometer, ktorý som použil, bol navrhnutý na to, aby zabránil tomu, čo Wayland má zabrániť — špehovaniu iných okien. Dúfam, že výkon kompozície v Waylande je lepší ako v X.org, a tiež dúfam, že v budúcnosti niekto nájde spôsob, ako posúdiť úroveň latencie v tomto prostredí.
Zdroj: habr.com
