Besede od naše prevajalske agencije: običajno se vsi trudijo prevajati najnovejše vsebine in objave, in mi nismo nobena izjema. A terminali niso nekaj, kar se posodablja vsak teden. Zato smo za vas prevedli članek Antoine Bopre, objavljen spomladi 2018: kljub svoji precejšnji „starosti“ v sodobnem мерilu menimo, da material ni izgubil svoje aktualnosti. Poleg tega je bil v izvirniku to niz dveh člankov, vendar smo se odločili, da ju združimo v en obsežen post.
Terminali imajo posebno mesto v zgodovini računalništva, vendar so bili v zadnjih desetletjih prisiljeni dobesedno preživeti skupaj s ukazno vrstico ob ozadju vseprisotnih grafičnih vmesnikov. so zamenjali , ki so bili sami po sebi modifikacija sistemov na perforiranih karticah in preklopnikih. Sodobne distribucije prihajajo s celotno množico emulatorjev terminalov vseh oblik in barv. In medtem ko so mnogi povsem zadovoljni s standardnim terminalom, ki ga nudi njihovo delovno okolje, nekateri s ponosom uporabljajo izrazito eksotično programsko opremo za zagon svojih najljubših lupin ali urejevalnikov besedil. Vendar, kot bomo videli v tem članku, niso vsi terminali ustvarjeni po istem vzorcu: med seboj se močno razlikujejo po funkcionalnosti, velikosti in zmogljivosti.
Nekateri terminali imajo presenetljive varnostne luknje, poleg tega pa ima večina popolnoma različen nabor funkcij, od podpore za vmesnik s zavihki do skript. Čeprav smo , je ta članek posodobitev prejšnjega materiala, ki bo bralcem pomagal določiti, kateri terminal uporabiti v letu 2018. V prvi polovici članka se primerjajo funkcije, v drugi pa se ocenjuje zmogljivost.
Tukaj so obravnavani terminali:
Mogoče to niso najnovejše različice, saj sem se omejil na stabilne različice ob času pisanja materiala, ki sem jih uspel namestiti na Debian 9 ali Fedora 27. Edina izjema je Alacritty. Ta je potomka terminalov z GPU pospeševanjem in napisan v nenavadnem in novem jeziku za to nalogo — Rust. V svojem pregledu sem izključil spletne terminale (tudi na ), ker so predhodni testi pokazali izjemno nizko zmogljivost.
Podpora za unicode
Svoje teste sem začel s podporo za unicode. Prvi test terminalov je bilo prikazovanje stringa o unicode iz : „é, Δ, Й, ק, م, ๗, あ, 叶, 葉 in 말“. Ta enostaven test pokaže, ali terminal pravilno deluje po vsem svetu. Terminal xterm ne prikazuje arabske znake v privzeti konfiguraciji:
Privzeto xterm uporablja klasično „fiksno“ pisavo, ki ima, po besedah , „znaten pokritost unicode od leta 1997“. V tej pisavi se zgodi nekaj, kar povzroča, da se znak prikaže kot prazna okvir, in šele ob povečanju pisave na 20+ točk se znak končno začne pravilno prikazovati. Vendar pa ta „popravilo“ zruši prikazovanje drugih unicode znakov:
Ti posnetki zaslona so bili narejeni na Fedora 27, saj je ta dajala najboljše rezultate, v primerjavi z Debian 9, kjer nekatere stare različice terminalov (natančneje - mlterm) niso mogle pravilno delovati s pisavami. Na srečo je to bilo popravljenih v novejših različicah.
Zdaj pozornost na prikazovanje niza v xterm. Izkazalo se je, da znak Mem in naslednji Semitični spadajo v scenarije pisanja RTL (), zato bi se tehnično morali prikazovati z desne proti levi. Spletni brskalniki, na primer Firefox 57, pravilno obravnavajo zgornji niz. Enostavnejša različica besedila RTL je beseda „“ v hebrejščini (). pravi naslednje:
„Mnogi računalniški programi ne morejo pravilno prikazati dvosmernega besedila. Na primer, hebrejsko ime „Sara“ je sestavljeno iz znakov sin (ש) (ki se pojavi na desni), nato reš (ר) in končno he (ה) (ki se mora pojaviti na levi)“.
Mnogi terminali ne uspejo prestati tega testa: Alacritty, VTE-izvedeni terminali Gnome in XFCE, urxvt, st in xterm prikazujejo 'Sara' v obratnem vrstnem redu, kot da bi to ime zapisali kot 'Aras'.
Drug problem dvosmernih besedil je, da jih je treba nekako poravnati, še posebej, če gre za mešanje besedil RTL in LTR. RTL scenariji se morajo začeti z desne strani okna terminala, toda kaj se mora zgoditi v terminalih, ki privzeto delujejo z LTR-angleščino? Večina jih nima posebnih mehanizmov in poravnava celotno besedilo na levo (tudi v Konsole). Izključitev sta pterm in mlterm, ki upoštevata standarde in poravnata takšne vrstice na desno.
Zaščita pred lepljenjem
Naslednja kritična značilnost, ki sem jo določil, je zaščita pred lepljenjem. Čeprav je splošno znano, da so ukazi, kot so:
$ curl http://example.com/ | shpotisni ukazi za izvajanje kode, malo kdo ve, da lahko skriti ukazi vstopijo v konzolo pri kopiranju in lepljenju iz spletnega brskalnika, celo po natančnem pregledu. odlično prikazuje, kako videti nedolžen ukaz:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitse pri lepljenju s Horneve spletne strani v terminal spremeni v takšno neprijetnost:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nTo je bila slaba ideja. Ne kopirajte kode s spletnih mest, ki jim ne zaupate!
Tukaj je prva vrstica vašega /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitKako to deluje? Zlonamerna koda je prestavljena v blok , ki je CSS sredstva premaknjena iz vidnega polja uporabnika.
je zasnovan za nevtralizacijo podobnih napadov. V tem načinu terminali vstavljenemu besedilu priložijo par posebnih escape-sekvenc, da obvestijo lupino o izvoru tega besedila. Tako lupina prejme signal, da lahko ignorira posebne znake, ki jih lahko vsebuje vstavljen tekst. Vse terminali, razen častitljivega xterm, podpirajo to funkcijo, vendar vstavljanje v Bracketed načinu zahteva podporo lupine ali aplikacije, ki teče v terminalu. Na primer, programska oprema, ki uporablja (ista Bash), potrebuje datoteko ~/.inputrc:
set enable-bracketed-paste onŽal se testna stran Horna prav tako izkaže, kako zaobiti to zaščito preko samega formatiranja besedila in prezgodnjega prenehanja uporabe Bracketed načina. To deluje, ker nekateri terminali nepravilno filtrirajo escape zaporedja pred dodajanjem lastnih. Na primer, v mojih nisem uspel uspešno zaključiti testov Konsole, kljub pravilni konfiguraciji. .inputrc datoteke. To pomeni, da lahko zlahka poškodujete konfiguracijo sistema zaradi nepodprte aplikacije ali nepravilno nastavljene lupine. Še posebej nevarno je to pri vstopu na oddaljene strežnike, kjer se skrbna obdelava konfiguracije redkeje srečuje, še posebej, če imate veliko takšnih oddaljenih strojev.
Dober način reševanja tega problema je vtičnik za potrditev lepljenja za terminal urxvt, ki preprosto zahteva dovoljenje za lepljenje katere koli besedila, ki vsebuje nova vrstice. Boljšega zaščitenega načina za opisani Hornov napad s tekstom nisem našel.
Zavihki in profili
Priljubljena funkcija danes je podpora za vmesnik z zavihki, ki ga bomo opredelili kot eno okno terminala, ki vsebuje več terminalov. Za različne terminale se ta funkcija razlikuje, in čeprav tradicionalni terminali, kot je xterm, sploh ne podpirajo zavihkov, bolj sodobne inkarnacije terminala, kot so Xfce Terminal, GNOME Terminal in Konsole, to funkcijo omogočajo. Tudi Urxvt podpira zavihke, vendar le ob uporabi vtičnika. Vendar je Terminator brezpogojni voditelj glede podpore zavihkom: ne le, da podpira zavihke, ampak prav tako lahko postavlja terminale v poljubnem vrstnem redu (glejte sliko spodaj).
Še ena značilnost Terminatorja je možnost, da te zavihke »skupina« skupaj in pošlje enake pritiske tipk na več terminalov hkrati, kar zagotavlja grob instrument za izvajanje množičnih operacij na več strežnikih hkrati. Podobna funkcija je prav tako implementirana v Konsole. Za uporabo te funkcije v drugih terminalih je potrebno uporabiti programsko opremo tretjih oseb, kot je , ili .
Še posebej dobro delujejo zavihki skupaj s profili: na primer, lahko imate en zavihek za e-pošto, drugega za klepet in tako naprej. To dobro podpira terminal Konsole in GNOME Terminal. Obe omogočata, da vsak zavihek samodejno zažene svoj profil. Terminator prav tako podpira profile, vendar nisem mogel najti načina za samodejno zagon določenih programov ob odpiranju določenega zavihka. Drugi terminali sploh nimajo koncepta 'profil'.
Volančki
Zadnja stvar, ki jo bom obravnaval v prvem delu tega članka, je videz terminalov. Na primer, GNOME, Xfce in urxvt podpirajo prosojnost, vendar so nedavno opustili podporo za ozadja, kar je nekaterim uporabnikom povzročilo prehod na terminal. . Osebno me zadostuje in preprosto Xresources, ki nastavi osnovni niz barv ozadja za urxvt. Vendar pa lahko nestandardne barvne teme prinesejo tudi težave. Na primer, s aplikacijami in , ker že uporabljajo svoje barve.
ni podpiral barv, novosti pa so pogosto omejene na 256-barvno paleto. Za izkušene uporabnike, ki stilizirajo svoje terminale, lahko zahtevki lupine ali vrstic stanja na nekakšne zapletene načine postanejo neprijetna omejitev. sledi, kateri terminali podpirajo „True Color“. Moji testi potrjujejo, da st, Alacritty in terminali na osnovi VTE odlično podpirajo True Color. Drugi terminali se na tem področju ne obnesejo najbolje in dejansko ne prikažejo niti 256 barv. Spodaj lahko vidite razliko med podporo True Color v terminalih GNOME, st in xterm, ki se dobro spopadajo s to nalogo s svojo 256-barvno paleto, ter urxvt, ki ne samo, da ne prestane testa, temveč tudi prikazuje nekaj utripajočih simbolov namesto njih.
Nekateri terminali tudi analizirajo besedilo za vzorce URL-jev, da bi naredili povezave klikabilne. To velja za vse različice terminalov VTE, medtem ko urxvt zahteva poseben vtičnik, ki bi URL-naslove pretvoril ob kliku ali s kombinacijo tipk. Drugi terminali, ki sem jih testiral, prikazujejo URL-naslove na drugačne načine.
Končno, nov trend terminalov je opcionalnost pomičnega pomagalnika. Na primer, v st ni pomičnega pomagalnika; domneva se, da bo uporabnik uporabljal terminalski multiplexer, kot je tmux. .
V Alacritty prav tako ni pomičnih pomagalnikov, vendar Njihova podpora se bo pojavila zaradi "obsežne povratne informacije" na to temo s strani uporabnikov. Poleg teh izjem je vsak terminal, ki sem ga preizkusil in našel, podpiral obratno pomikanje.
Vmesni rezultati
V drugem delu gradiva (v izvirniku sta bili to dve ločeni članki, — op. red.) bomo primerjali zmogljivost, uporabo pomnilnika in zakasnitve. Vendar pa že vidimo, da imajo nekateri od obravnavanih terminalov resne pomanjkljivosti. Na primer, uporabniki, ki redno delajo z RTL-skripti, lahko opazijo mlterm in pterm, saj se bolje spopadajo s tovrstnimi nalogami. Konsole se je prav tako dobro izkazal. Uporabniki, ki ne delajo z RTL-skripti, lahko izberejo kaj drugega.
Z vidika zaščite pred vstavitvijo zlonamerne kode urxvt izstopa zaradi svoje posebne izvedbe zaščite pred tovrstnimi napadi, kar se mi zdi zagotovo koristno. Tistim, ki iščejo kakšne posebne funkcije, naj pogledajo Konsole. Na koncu pa je vredno omeniti, da je VTE odlična osnova za terminale, ki zagotavlja podporo za barve, prepoznavanje URL-jev in tako naprej. Na prvi pogled se lahko privzeti terminal, ki ga ponuja vaša najljubša okolica, zdi, da izpolnjuje vse zahteve, a pustimo to vprašanje odprto, dokler ne razjasnimo zmogljivosti.
Nadaljujemo pogovor
Na splošno se lahko zmogljivost terminalov zdi umetno ustvarjen problem, vendar se je izkazalo, da nekateri med njimi kažejo izjemno velika zakasnitve za tako temeljno programsko opremo. Nadalje bomo pregledali tisto, kar tradicionalno imenujemo "hitrost" (pravzaprav gre za hitrost pomikanja) in porabo pomnilnika terminala (ob upoštevanju, da to danes ni tako kritično, kot je bilo pred desetletji).
Kašnjenje
Po temeljitem raziskovanju zmogljivosti terminalov sem prišel do zaključka, da je najpomembnejši parameter v tem smislu velikost zakasnitve (ping). V svojem članku Pavel Fatin je obravnaval zamudo različnih urejevalnikov besedil in namignil, da terminali na tem področju morda delujejo počasneje od najhitrejših urejevalnikov besedil. Ta namig me je na koncu spodbudil, da sem začel lastne teste in napisal ta članek.
Ampak kaj je zamuda in zakaj je tako pomembna? V svojem članku je Fatin opredelil zamudo kot »zamudo med pritiskom na tipko in ustreznim posodobitvijo zaslona« in citiral , v katerem piše: »Zamuda v vizualni povratni informaciji na računalniškem zaslonu pomembno vpliva na vedenje tipkovnice in njeno zadovoljstvo.«
Fatin pojasnjuje, da ta ping ima globlje posledice od preproste zadovoljstva: »tipkanje postane počasnejše, napak je več, povečana je napetost oči in mišic«. Z drugimi besedami, večja zamuda lahko vodi do tipkarskih napak ter zmanjšanja kakovosti kode, saj povečuje dodatno kognitivno obremenitev možganov. A kar je še huje, ping »povečuje napetost oči in mišic«, kar očitno pomeni v prihodnosti (očitno avtor misli na težave z očmi, hrbtom, rokami in seveda vidom — op. prev.) zaradi ponavljajoče se napetosti.
Nekateri od teh učinkov so znani že dolgo, rezultati , objavljeni že leta 1976 v reviji Ergonomics, pa trdijo, da zamuda 100 milisekund »znatno poslabša hitrost tipkanja«. Pred kratkim je bilo v uporabniškem priročniku GNOME dodano v 10 milisekundah, in če gremo še naprej, prikazuje, da je ideal 1 milisekunda.
Fatin je izvajal svoje teste na urejevalnikih besedil; ustvaril je prenosno orodje z imenom , ki sem ga uporabil za preverjanje pinga v emulatorskih terminalih. Upoštevajte, da je bil test izveden v simulacijskem načinu: v resnici je treba upoštevati tudi zamudo vnosa (tipkovnica, USB krmilnik itd.) in izpisa (pomnilniški pomnilnik grafične kartice, monitor). Po Fatinhovih besedah je pri tipičnih konfiguracijah približno 20 ms. Ob uporabi igralne opreme je mogoče doseči vrednost le 3 milisekunde. Ker že imamo tako hitro opremo, aplikacija ne sme dodati nobene dodatne zamude. Fatinov cilj je zmanjšati zamudo aplikacije na 1 milisekundo ali celo doseči igro brez , kot v .
Tukaj so rezultati mojih meritev in nekateri rezultati Fatina, da pokažem, da se moj eksperiment strinja z njegovimi testi:
Prva stvar, ki me je presenetila, je bila boljša odzivnost starih programov, kot sta xterm in mlterm. Kljub najslabši zamudi registracije (2,4 ms) so dosegli boljši rezultat kot najhitrejši sodobni terminal (10,6 ms za st). Noben sodoben terminal ne pade pod prag 10 milisekund. Zlasti Alacritty ne izpolnjuje zahtev po »najhitrejšem med obstoječimi emulatorji terminalov«, čeprav so se njegovi rezultati izboljšali od prvega pregleda leta 2017. Resnično so avtorji projekta in delajo na izboljšanju prikazovanja. Prav tako je treba opozoriti, da je Vim, ki uporablja GTK3, precej počasnejši od svojega ustreznika GTK2. Iz tega lahko sklepamo, da GTK3 ustvarja dodatno zamudo, kar vpliva na vse druge termine, ki ga uporabljajo (Terminator, Xfce4 Terminal in GNOME Terminal).
Vendar so lahko razlike za oko nevidne. Kot pojasnjuje Fatin: »ni nujno biti zavedajoč se prisotnosti zamude, da bi imela učinek name«. Fatin tudi opozarja na standardni odklon: »vsaka odstopanja v trajanju zamude (trešenje) ustvarjajo dodatno obremenitev zaradi svoje nepredvidljivosti«.
Grafikon zgoraj je bil pridobljen iz čistih Debian 9 (stretch) z . To okolje daje najboljše rezultate pri testih za določitev zakasnitve. Izkazalo se je, da GNOME ustvari dodatni ping 20 ms za vse meritve. Možno razlago za to predstavlja prisotnost programov z sinhronim obdelovanjem vhodnih dogodkov. Fatin za ta primer navaja , ki dodaja zakasnitev, ko obdeluje vse vhodne dogodke sinhrono. Privzeto je GNOME opremljen tudi z upraviteljem oken , ki ustvarja dodatno raven predpomnjenja, kar vpliva na ping in doda vsaj 8 milisekund zakasnitve.
Hitrost pomikanja
Naslednji test je tradicionalni preizkus »hitrosti« ali »pasovne širine«, ki meri, kako hitro terminal lahko pomika stran, prikazuje veliko število besedila na zaslonu. Mehanika testa se razlikuje; izvorni test je bil preprosto generirati isto besedilno vrstico z uporabo ukaza seq. Drugi testi vključujejo preverjanje Thomasa E. Dicka (s spremljajočim xterm), v okviru katerega se večkrat . V še enem pregledu zmogljivosti terminalov uporablja vrstico naključnih bajtov v kodiranju base32, ki se izpiše v terminalu z uporabo cat. Luu šteje ta test za »toliko neuporabnega etalona, kolikor si ga lahko zamislite« in predlaga, da se namesto tega uporabi odziv terminala kot glavni kazalnik. Dick prav tako imenuje svoj test zavajajoč. Kljub temu oba avtorja priznavajo, da je propustnost okna terminala lahko problem. Luu je opazil zamrznitev Emacs Eshell pri prikazovanju velikih datotek, Dick pa je optimiziral terminal, da se znebi vizualne počasnosti xterm. Zato ima ta test še vedno nekaj smisla, vendar ker se proces upodabljanja močno razlikuje od terminala do terminala, ga je mogoče uporabiti tudi kot testni komponent za preverjanje drugih parametrov.
Tukaj vidimo, da sta rxvt in st prehitela konkurenco, za njima pa sledi precej novejši Alacritty, razvijan z osredotočenostjo na hitro delovanje. Naslednja sta Xfce (družina VTE) in Konsole, ki delujeta skoraj dvakrat hitreje. Zadnji je xterm, ki je petkrat počasnejši od rxvt. Med testom je xterm tudi močno migal, prehajajočega besedila ni bilo mogoče dobro prebrati, tudi če je bila to ista vrstica. Konsole se je izkazal za hitrega, vendar je včasih „prevaral“: zaslon se je občasno ustavil, delno prikazoval besedilo ali ga sploh ni prikazoval. Drugi terminali, vključno s st, Alacritty in rxvt, so prikazovali vrstice jasno.
Diki pojasnjuje, da so razlike v zmogljivosti povezane z oblikovanjem pomnilnika za pomikanje v različnih terminalih. Š particularly, obtožuje rxvt in druge terminale, da „ne sledijo splošnim pravilom“:
„Za razliko od xterm, rxvt ni poskušal prikazati vseh posodobitev. Če zaostaja, se odreče nekaterim posodobitvam, da bi nadoknadil zamudo. To je imelo večji vpliv na zaznano hitrost pomikanja, kot pa na organizacijo notranjega pomnilnika. Ena pomanjkljivost pa je bila, da je bila animacija ASCII nekoliko netočna.“
Za odpravo te očitne počasnosti xterm Diki predlaga uporabo vira , ki omogoča xterm, da zavrže nekatere posodobitve zaslona, da ne bi zaostal za tokom. Moji testi potrjujejo, da fastScroll povečuje zmogljivost in izenačuje xterm z rxvt. Vendar pa je to precej grob popravek, kot sam Diki pojasnjuje: „včasih se zdi, da xterm — kot tudi konsole — ustavi, ker čaka na nov sklop posodobitev zaslona, potem ko so nekateri od njih bili odstranjeni“. V tej luči se zdi, da so drugi terminali našli najboljši kompromis med hitrostjo in celovitostjo zaslona.
Poraba virov
Ne glede na to, ali je smiselno obravnavati hitrost pomikanja kot merilo zmogljivosti, ta test omogoča simulacijo obremenitve terminalov, kar nam omogoča merjenje drugih parametrov, kot so raba pomnilnika ali diska. Metrični podatki so bili pridobljeni z izvajanjem navedenega testa seq pod nadzorom procesa Python. Zbiral je podatke števcov za ru_maxrss, skupno ru_oublock in ru_inblock in preprost časomer.
V tem testu ST zaseda prvo mesto z najnižjo povprečno porabo pomnilnika, ki znaša 8 MB, kar ni presenetljivo, če upoštevamo, da je osnovna ideja projekta preprostost. Mlterm, xterm in rxvt porabijo nekoliko več — okoli 12 MB. Drugi opazni rezultati se pojavijo pri Alacritty, ki za delovanje potrebuje 30 MB. Nato so tu terminali družine VTE z rezultati med 40 in 60 MB, kar je precej veliko. Tako visoka poraba je razložena s tem, da ti terminali uporabljajo knjižnice višje ravni, kot je GTK. Konsole je na koncu s kolosalno porabo 65 MB pomnilnika med testi, čeprav je to mogoče opravičiti z njegovim širokim naborom funkcij.
V primerjavi s prejšnjimi rezultati, pridobljenimi pred desetimi leti, so vse aplikacije začele porabljati znatno več pomnilnika. V preteklosti je Xterm potreboval 4 MB, zdaj pa 15 MB samo za zagon. Podobno povečanje porabe je pri rxvt, ki zdaj iz škatle potrebuje 16 MB. Terminal Xfce zavzema 34 MB, kar je trikrat več kot prej, medtem ko GNOME Terminal potrebuje le 20 MB. Seveda so vsi prejšnji testi potekali na 32-bitni arhitekturi. Na LCA 2012 Rasti Russell , kar pomeni, da obstaja veliko bolj subtilnih razlogov, ki lahko razložijo rast porabe pomnilnika. Kljub temu zdaj živimo v času, ko imamo cele gigabajte pomnilnika, zato se bomo že nekako spoprijeli.
Kljub temu ne morem znebiti občutka, da je dodelitev več pomnilnika za tako temeljno programsko opremo, kot je terminal, prazna izguba virov. Te aplikacije bi morale biti najmanjše med najmanjšimi, zmožne delovati na vsakem 'škatlu', celo na čevljarski, če kdaj pridemo do točke, ko jih bomo morali opremiti z Linux sistemi (in veste, da bo tako). Toda s temi številkami bo poraba pomnilnika v prihodnosti problem v kateremkoli okolju pri zagonu več terminalov, razen v primerih z večimi najlažjimi in najbolj omejenimi možnostmi. Da bi to kompenzirali, imajo GNOME Terminal, Konsole, urxvt, Terminator in Xfce Terminal način Daemon, ki omogoča upravljanje več terminalov preko enega procesa, kar omejuje njihovo porabo pomnilnika.
Med svojim testiranjem sem naletel na še en nepričakovan rezultat glede branja in pisanja podatkov na disk: pričakoval sem, da tukaj ne bom videl ničesar, a se je izkazalo, da nekateri terminali zapisujejo največje količine podatkov na disk. Tako knjižnica VTE dejansko hraní v spominu pomnilniški predpomnilnik (to lastnost , in to se dogaja še danes). Toda v nasprotju s starimi implementacijami, so zdaj vsaj ti podatki šifrirani z uporabo AES256 GCM (). Vendar se postavlja razumen vprašanje, kaj je tako posebnega v knjižnici VTE, da zahteva takšen nestandarden pristop k implementaciji…
Zaključek
V prvem delu članka smo ugotovili, da terminali, zasnovani na VTE, ponujajo dober nabor funkcij, a zdaj vidimo, da je to povezano z nekaterimi stroški za zagotavljanje njihove zmogljivosti. Trenutno spomin ni težava, ker vse VTE terminale nadzira Daemon proces, ki omejuje njihov apetit. Kljub temu pa lahko starejši sistemi, ki imajo fizične omejitve glede količine delovnega spomina in predpomnilnika jedra, še vedno potrebujejo zgodnejše različice terminalov, saj porabijo bistveno manj virov. Čeprav so se terminali VTE dobro odrezali pri testih prepustnosti (pomikanje), je njihova zakasnitev pri prikazu podatkov na zaslonu nad določenim pragom v uporabniškem priročniku GNOME. Verjetno bi si morali razvijalci VTE to zapomniti. Če upoštevamo, da se tudi začetniki v Linuxu ne morejo izogniti srečanju s terminalom, bi lahko ta postal bolj prijazen do uporabnikov. Za izkušene geek-e pa bi prehod na privzeti terminal lahko pomenil tudi zmanjšanje obremenitve za oči in možnost izogibanja poklicnim poškodbam ter boleznim v prihodnosti zaradi dolgotrajnih delovnih sej. Na žalost nas samo stari xterm in mlterm pripeljeta do čarobnega praga pinga pri 10 milisekundah, kar mnogim ni sprejemljivo.
Kontrolne mere so prav tako pokazale, da so se zaradi razvoja grafičnih okolij Linux razvijalci morali odločiti za vrsto kompromisov. Nekaterim uporabnikom bi bilo smiselno pogledati običajne upravljavce oken, saj zagotavljajo znatno zmanjšanje pinga. Na žalost ni bilo mogoče izmeriti zakasnitve za Wayland: program Typometer, ki sem ga uporabljal, je bil ustvarjen za to, kar Wayland želi preprečiti — vohunjenje za drugimi okni. Upam, da je kompozicija Waylanda boljša glede zmogljivosti kot X.org, prav tako pa upam, da bo v prihodnosti nekdo našel način za oceno ravni zakasnitve v tem okolju.
Izvor: habr.com
