Paar sõna meie tõlkebüroolt: tavaliselt püüavad kõik tõlkida uusimaid materjale ja väljaandeid ning meie pole erand. Kuid terminale ei uuendata kord nädalas. Seetõttu oleme teile tõlkinud Antoine Beaupré artikli, mis ilmus 2018. aasta kevadel: vaatamata tänapäevaste standardite järgi arvestatavale “vanusele” pole materjal meie hinnangul oma aktuaalsust sugugi kaotanud. Lisaks oli see algselt kahest artiklist koosnev sari, kuid otsustasime need üheks suureks postituseks ühendada.
Arvutiajaloos on terminalidel eriline koht, kuid viimastel aastakümnetel on nad sunnitud ellu jääma käsurea kõrval, kuna graafilised liidesed muutuvad kõikjale. asendasid omad , mis omakorda olid perfokaartidel ja lülititel põhinevate süsteemide modifikatsioonid. Kaasaegsed distributsioonid on varustatud mitmesuguste iga kuju ja värviga terminali emulaatoritega. Ja kuigi paljud on rahul oma töökeskkonna pakutava standardse terminaliga, kasutavad mõned uhkusega oma lemmikkesta või tekstiredaktori käitamiseks lausa eksootilist tarkvara. Kuid nagu sellest artiklist näeme, ei loodud kõiki terminale sama pildiga: need erinevad suuresti funktsionaalsuse, suuruse ja jõudluse poolest.
Mõnel terminalil on täiesti üllatavad turvaaugud, lisaks on enamikul täiesti erinevad funktsioonid, alates vahekaartide liidese toest kuni skriptimiseni. Kuigi meie , see artikkel on eelmise materjali värskendus, mis aitab lugejatel otsustada, millist terminali 2018. aastal kasutada. Artikli esimeses pooles võrreldakse funktsioone ja teises pooles hinnatakse jõudlust.
Siin on terminalid, mille üle vaatasin:
Need ei pruugi olla uusimad versioonid, kuna kirjutamise ajal piirdusin stabiilsete järgudega, mida suutsin Debian 9 või Fedora 27 jaoks välja panna. Ainsaks erandiks on Alacritty. See on GPU-kiirendusega terminalide järeltulija ja on kirjutatud selle ülesande jaoks ebatavalises ja uues keeles - Rust. Jätsin oma ülevaatest välja veebiterminalid (sh need, mis on ), sest esialgsed testid näitasid nende äärmiselt kehva jõudlust.
Unicode'i tugi
Alustasin oma teste Unicode'i toega. Terminalide esimene test oli Unicode'i stringi kuvamine : "é, Δ, И, ק, م, ๗, あ, 叶, 葉 ja 말." See lihtne test näitab, kas terminal suudab kogu maailmas õigesti töötada. xterm terminal ei kuva araabia tähemärki vaikekonfiguratsioonis:
Vaikimisi kasutab xterm klassikalist "fikseeritud" fonti, mis vastavalt , millel on "oluline Unicode'i katvus aastast 1997". Selles fondis toimub midagi, mille tõttu märk ilmub tühja raamina ja alles siis, kui tekstifonti suurendatakse 20+ punktini, hakkab tähemärki lõpuks õigesti kuvama. Kuid see "parandus" katkestab teiste Unicode'i märkide kuvamise:
Need ekraanipildid on tehtud Fedora 27-s, kuna see andis paremaid tulemusi kui Debian 9, kus mõned vanemad terminalide versioonid (täpsemalt mlterm) ei suutnud fonte korralikult käsitleda. Õnneks parandati see hilisemates versioonides.
Nüüd pange tähele, kuidas rida xtermis kuvatakse. Selgub, et sümbol Mem ja sellele järgnev semiit viidata RTL stiilis skriptidele (), seega tuleks neid tehniliselt kuvada paremalt vasakule. Veebibrauserid, nagu Firefox 57, käsitlevad ülaltoodud rida õigesti. RTL-teksti lihtsam versioon on sõna "" heebrea keeles (). ütleb järgmist:
"Paljud arvutiprogrammid ei suuda kahesuunalist teksti õigesti kuvada. Näiteks heebrea nimi "Sarah" koosneb tähemärkidest sin (ש) (mis asub paremal), siis resh (ר) ja lõpuks he (ה) (mis peaks ilmuma vasakul)."
Paljud terminalid ebaõnnestuvad selles testis: Alacritty, VTE-st tuletatud Gnome ja XFCE terminalid, urxvt, st ja xterm kuvavad "Sara" vastupidises järjekorras, nagu oleksime selle nime kirjutanud "Aras".
Teine probleem kahesuunaliste tekstide puhul on see, et neid tuleb kuidagi joondada, eriti mis puudutab RTL ja LTR tekstide segamist. RTL-skriptid peaksid jooksma terminali akna paremast servast, kuid mis peaks juhtuma terminalidega, mille vaikimisi on LTR inglise keel? Enamikul neist pole erilisi mehhanisme ja need joondavad kogu teksti vasakule (ka Konsoolis). Erandiks on pterm ja mlterm, mis järgivad standardeid ja joodavad sellised read paremale.
Sisestuskaitse
Järgmine oluline omadus, mille olen tuvastanud, on sisestusvastane kaitse. Kuigi on laialt teada, et sellised loitsud nagu:
$ curl http://example.com/ | shon koodi täitmise tõukekäsud, vähesed teavad, et peidetud käsud võivad isegi pärast hoolikat kontrollimist veebibrauserist kopeerimisel ja kleepimisel konsooli hiilida. näitab suurepäraselt, kui kahjutu välja näeb käsk:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitmuutub Horni veebisaidilt terminali kleepides selliseks ebameeldivaks:
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.gitKuidas see töötab? Plokis on pahatahtlik kood , mis teisaldatakse CSS-i abil kasutaja vaatest välja.
on selgelt loodud selliste rünnakute neutraliseerimiseks. Selles režiimis lisavad terminalid kleebitud teksti paari spetsiaalsesse paojärjestusse, et öelda kestale teksti päritolu. See ütleb kestale, et see võib ignoreerida erimärke, mida kleebitud tekst võib sisaldada. Kõik terminalid, mis on tagasi auväärsesse xtermi, toetavad seda funktsiooni, kuid kleepimine sulgudes nõuab terminalis töötava kesta või rakenduse tuge. Näiteks tarkvara kasutamine (sama Bash), vajab faili ~/.inputrc:
set enable-bracketed-paste onKahjuks näitab Horni testsait ka seda, kuidas sellest kaitsest tekstivormingu enda kaudu mööda minna ja enneaegselt rakendada sellele režiimi Bracketed. See toimib, kuna mõned terminalid ei filtreeri enne omade lisamist paojärjestusi õigesti. Näiteks minu omas ei suutnud ma kunagi Konsole teste edukalt sooritada isegi õige konfiguratsiooniga .inputrc faili. See tähendab, et saate oma süsteemi konfiguratsiooni kergesti rikkuda toetamata rakenduse või valesti konfigureeritud kesta tõttu. See on eriti ohtlik kaugserveritesse sisselogimisel, kus hoolikas seadistamine on vähem levinud, eriti kui teil on palju selliseid kaugmasinaid.
Selle probleemi hea lahendus on terminali kleepimise kinnituse pistikprogramm urxvt, mis lihtsalt küsib luba lisada reavahetusi sisaldav tekst. Horni kirjeldatud tekstirünnakule pole ma turvalisemat varianti leidnud.
Vahekaardid ja profiilid
Praegu on populaarne funktsioon vahekaartidega liidese tugi, mida määratleme ühe terminali aknana, mis sisaldab mitut teist terminali. See funktsioon on erinevate terminalide puhul erinev ja kuigi traditsioonilised xtermi terminalid ei toeta üldse sakke, on kaasaegsematel terminalide kehastustel, nagu Xfce Terminal, GNOME Terminal ja Konsole, see funktsioon olemas. Urxvt toetab ka vahekaarte, kuid ainult siis, kui kasutate pistikprogrammi. Kuid vahekaartide toe enda osas on Terminator vaieldamatu liider: see mitte ainult ei toeta vahekaarte, vaid suudab ka terminale korraldada mis tahes järjekorras (vt pilti allpool).
Terminaatori teine omadus on võimalus need vahelehed "rühmitada" ja saata samad klahvivajutused korraga mitmele terminalile, pakkudes toores tööriista hulgitoimingute tegemiseks mitmes serveris samaaegselt. Sarnane funktsioon on rakendatud ka Konsoolis. Selle funktsiooni kasutamiseks teistes terminalides peate kasutama kolmanda osapoole tarkvara, näiteks , või .
Vahekaardid töötavad eriti hästi siis, kui need on seotud profiilidega: näiteks võib üks vahekaart olla meili jaoks, teine vestluse jaoks jne. Seda toetavad hästi Konsole terminal ja GNOME terminal. Mõlemad võimaldavad igal vahekaardil automaatselt oma profiili käivitada. Terminator toetab ka profiile, kuid ma ei leidnud viisi, kuidas teatud vahekaardi avamisel teatud programme automaatselt käivitada. Teistel terminalidel puudub mõiste "profiil" üldse.
Volangid
Viimane asi, mida ma selle artikli esimeses osas käsitlen, on terminalide välimus. Näiteks GNOME, Xfce ja urxvt toetavad läbipaistvust, kuid on hiljuti taustapiltide toest loobunud, sundides mõnda kasutajat terminali kasutama. . Mina isiklikult olen sellega rahul ja see on lihtne X ressursid, mis määrab urxvt taustavärvide baaskomplekti. Probleeme võivad tekitada aga ka mittestandardsed värviteemad. Näiteks, rakendustega и , kuna nad kasutavad juba oma värve.
ei toetanud värve ja uued piirdusid sageli 256 värvipaletiga. Kogenud kasutajatele, kes kujundavad oma terminale, võivad shellisviibad või olekuribad keerulisel viisil olla tüütuks piiranguks. jälgib, millistel terminalidel on "True Color" tugi. Minu testid kinnitavad, et st, Alacrtty ja VTE-põhised terminalid toetavad ideaalselt True Colori. Teistel terminalidel selles osas väga hästi ei lähe ja tegelikult ei kuvata isegi 256 värvi. Allpool näete erinevust True Colori toe vahel GNOME terminalides, st ja xterm, mis oma 256 värvipaletiga saavad sellega hästi hakkama, ja urxvt vahel, mis mitte ainult ei ebaõnnestu testis, vaid näitab nende asemel isegi vilkuvaid märke.
Mõned terminalid analüüsivad teksti ka URL-i mustrite jaoks, et muuta linke klõpsatavaks. See kehtib kõigi VTE-st tuletatud terminalide kohta, samas kui urxvt nõuab spetsiaalset pistikprogrammi, mis muudaks URL-id klõpsu või kiirklahvi abil. Muud terminalid Olen kuvatavaid URL-e muul viisil testinud.
Lõpuks on terminalide uus trend kerimispuhvri valikulisus. Näiteks st ei ole kerimispuhvrit; eeldatakse, et kasutaja kasutab terminali multiplekserit nagu tmux ja .
Alacritty puuduvad ka tagasikerimise puhvrid, kuid selle toe kasutajate "laiaulatusliku tagasiside" tõttu sellel teemal. Peale nende tõusuteed toetavad kõik minu testitud terminalid, mida leidsin, pöördkerimist.
Vahesumma
Materjali teises osas (originaalis olid need kaks erinevat artiklit - u. sõidurada) võrdleme jõudlust, mälukasutust ja latentsust. Kuid juba praegu on näha, et mõnel kõnealusel terminalil on tõsiseid puudujääke. Näiteks võivad kasutajad, kes töötavad regulaarselt RTL-skriptidega, kaaluda mltermi ja ptermi kasutamist, kuna nad saavad sarnaste ülesannetega paremini hakkama kui teised. Hästi esines ka Konsole. Kasutajad, kes ei tööta RTL-skriptidega, võivad valida midagi muud.
Pahatahtliku koodi sisestamise vastase kaitse osas paistab urxvt silma seda tüüpi rünnakute vastase kaitse erilise teostuse poolest, mis tundub mulle kindlasti mugav. Kelle ja vilede otsijatele tasub Konsole vaadata. Lõpetuseks väärib märkimist, et VTE on suurepärane baas terminalidele, mis tagab värvitoe, URL-i tuvastamise jne. Esmapilgul võib teie lemmikkeskkonnaga kaasas olev vaiketerminal vastata kõigile nõuetele, kuid jätkem see küsimus lahtiseks, kuni jõudlusest aru saame.
Jätkame vestlust
Üldiselt võib terminalide jõudlus iseenesest tunduda kaugeleulatuva probleemina, kuid nagu selgub, on mõnel neist sellist fundamentaalset tüüpi tarkvara puhul üllatavalt kõrge latentsusaeg. Järgmisena vaatleme ka seda, mida traditsiooniliselt nimetatakse "kiiruseks" (tegelikult on see kerimiskiirus) ja terminali mälutarbimist (ettepanekuga, et see pole tänapäeval nii kriitiline kui aastakümneid tagasi).
Viivitus
Pärast terminali jõudluse põhjalikku uurimist jõudsin järeldusele, et kõige olulisem parameeter selles osas on latentsus (ping). Oma artiklis Pavel Fatin vaatas erinevate tekstiredaktorite latentsusaega ja andis mõista, et terminalid võivad sellega seoses olla aeglasemad kui kiireimad tekstiredaktorid. Just see vihje viis mind lõpuks oma testide läbiviimiseni ja selle artikli kirjutamiseni.
Kuid mis on latentsusaeg ja miks see nii oluline on? Oma artiklis määratles Fatin seda kui "viivitust klahvi vajutamise ja vastava ekraanivärskenduse vahel" ja tsiteeris , milles öeldakse: "Arvutikuvari visuaalse tagasiside viivitus mõjutab oluliselt masinakirjutaja käitumist ja rahulolu."
Fatin selgitab, et sellel pingil on sügavamad tagajärjed kui lihtsalt rahulolu: "trükkimine muutub aeglasemaks, esineb rohkem vigu ning silmade ja lihaste pinge suureneb." Teisisõnu võib suur viivitus põhjustada kirjavigu ja ka madalamat koodi kvaliteeti, kuna see toob kaasa täiendava kognitiivse koormuse ajule. Kuid hullem on see, et ping "suurendab silmade ja lihaste pinget", mis näib vihjavat tulevikus (Ilmselt peab autor silmas probleeme silma-, selja-, käte- ja muidugi nägemisega - u. sõidurada) korduva stressi tõttu.
Mõned neist mõjudest on olnud teada juba pikka aega ja tulemused 1976. aastal ajakirjas Ergonomics avaldatud artiklis öeldi, et 100 millisekundiline viivitus "kahandab märkimisväärselt tippimiskiirust". Hiljuti tutvustati GNOME'i kasutusjuhendit 10 millisekundi jooksul ja kui lähete kaugemale, siis näitab, et 1 millisekund on ideaalne.
Fatin viis oma testid läbi tekstiredaktorite peal; ta lõi kaasaskantava instrumendi nimega , mida kasutasin pingi testimiseks terminali emulaatorites. Pidage meeles, et test viidi läbi simulatsioonirežiimis: tegelikkuses peame arvestama nii sisendi (klaviatuur, USB-kontroller jne) kui ka väljundi (videokaardi puhver, monitor) latentsusega. Fatini sõnul on tüüpilistes konfiguratsioonides umbes 20 ms. Kui teil on mänguvarustus, saate selle näitaja saavutada vaid 3 millisekundiga. Kuna meil on juba nii kiire riistvara, ei pea rakendus lisama oma latentsust. Fatini eesmärk on viia rakenduse latentsus 1 millisekundini või isegi saavutada ilma helistamine nagu sisse .
Siin on minu mõõtmiste tulemused ja mõned Fatini tulemused, mis näitavad, et minu katse on tema testidega kooskõlas:
Esimene asi, mis mind silma hakkas, oli vanemate programmide, nagu xterm ja mlterm, parem reageerimisaeg. Halvima registri latentsusega (2,4 ms) toimisid need paremini kui kiireim kaasaegne terminal (st jaoks 10,6 ms). Ükski kaasaegne terminal ei jää alla 10 millisekundi läve. Eelkõige ei suuda Alacrtty täita "kiireima saadaoleva terminali emulaatori" väidet, kuigi selle tulemused on pärast esimest ülevaatamist 2017. aastal paranenud. Tõepoolest, projekti autorid ja töötavad ekraani täiustamise nimel. Samuti tuleb märkida, et GTK3 kasutav Vim on suurusjärgu võrra aeglasem kui tema GTK2 vaste. Sellest võime järeldada, et GTK3 loob täiendava latentsuse ja see kajastub kõigis teistes seda kasutavates terminalides (Terminaator, Xfce4 terminal ja GNOME terminal).
Erinevused ei pruugi aga silmaga märgatavad olla. Nagu Fatin selgitab, "te ei pea olema viivitusest teadlik, et see teid mõjutaks." Fatin hoiatab ka standardhälbe eest: "kõik latentsuse häired (värinad) tekitavad oma ettearvamatuse tõttu lisapingeid."
Ülaltoodud graafik on tehtud puhtal Debian 9-l (venitada) koos . See keskkond annab latentsustestides parimaid tulemusi. Nagu selgub, loob GNOME kõigi mõõtmiste jaoks täiendava 20 ms pingi. Selle võimalikuks seletuseks on sisendsündmuste sünkroonse töötlemisega programmide olemasolu. Fatin toob selliseks juhtumiks näite , mis lisab viivituse, töötledes kõiki sisendsündmusi sünkroonselt. Vaikimisi on GNOME-ga kaasas ka aknahaldur , mis loob täiendava puhverduskihi, mis mõjutab pingi ja lisab latentsusaega vähemalt 8 millisekundit.
Kerimiskiirus
Järgmine test on traditsiooniline "kiiruse" või "ribalaiuse" test, mis mõõdab, kui kiiresti suudab terminal lehekülge kerida, kuvades samal ajal ekraanil suures koguses teksti. Katse mehaanika on erinev; algne test oli lihtsalt sama tekstistring genereerimine, kasutades käsku seq. Teiste testide hulka kuulub Thomas E. Dickey (xtermi hooldaja) test, mis korduvalt . Teises terminali jõudluse ülevaates kasutab base32 kodeeritud juhuslike baitide stringi, mis väljastatakse terminali kasutades cat. Luu peab sellist testi "nii kasutuks etaloniks, kui võib ette kujutada" ja soovitab selle asemel kasutada esmase mõõdikuna terminali vastust. Dickey nimetab oma testi ka eksitavaks. Kuid mõlemad autorid tunnistavad, et terminali akna ribalaius võib olla probleem. Luu avastas Emacs Eshelli külmumise suurte failide kuvamisel ja Dickey optimeeris terminali, et vabaneda xtrermi visuaalsest loidusest. Seega on sellel testil veel mõningaid eeliseid, kuid kuna renderdusprotsess on terminaliti väga erinev, saab seda kasutada ka testkomponendina muude parameetrite testimiseks.
Siin näeme rxvt ja st tõmbejõudu konkurentidest ees, millele järgneb palju uuem Alacrtty, mis on disainitud jõudlusele keskendudes. Järgmised on Xfce (VTE perekond) ja Konsole, mis on peaaegu kaks korda kiiremad. Viimane on xterm, mis on viis korda aeglasem kui rxvt. Testi ajal lainetas ka xterm palju, muutes edastatava teksti raskesti nähtavaks isegi siis, kui see oli sama rida. Konsole oli kiire, kuid kohati keeruline: ekraan tardus aeg-ajalt, näidates osalist teksti või üldse mitte. Teised terminalid kuvasid stringe selgelt, sealhulgas st, Alacrtty ja rxvt.
Dickey selgitab, et jõudluse erinevused on tingitud kerimispuhvrite konstruktsioonist erinevates terminalides. Eelkõige süüdistab ta rxvt-d ja teisi terminale "üldreeglite mittejärgimises":
"Erinevalt xtermist ei püüdnud rxvt kõiki värskendusi kuvada. Kui see jääb maha, keeldub see mõnest värskendusest järele jõudmast. Sellel oli suurem mõju näilisele kerimiskiirusele kui sisemälu korraldusele. Üks puudus oli see, et ASCII animatsioon oli mõnevõrra ebatäpne.
Selle tajutava xtermi loiduse parandamiseks soovitab Dickey kasutada ressurssi , mis võimaldab xtermil vooluga sammu pidamiseks mõned ekraanivärskendused kõrvale jätta. Minu testid kinnitavad, et fastScroll parandab jõudlust ja viib xtermi rxvt-ga võrdsele tasemele. See on siiski üsna karm kark, nagu Dickey ise selgitab: "mõnikord näib xterm - nagu konsool - seiskuvat, kuna see ootab uut ekraanivärskenduste komplekti pärast mõne eemaldamist." Selles mõttes tundub, et teised terminalid on leidnud parima kompromissi kiiruse ja kuva terviklikkuse vahel.
Ressursi tarbimine
Sõltumata sellest, kas kerimiskiirust on mõttekas pidada jõudlusnäitajaks, võimaldab see test simuleerida terminalide koormust, mis omakorda võimaldab mõõta muid parameetreid, näiteks mälu- või kettakasutust. Mõõdikud saadi määratud testi käivitamisega seq Pythoni protsessi jälgimise all. Ta kogus arvestite andmeid eest ru_maxrss, summa ru_oublock и ru_inblock ja lihtne taimer.
Selles testis saavutab ST esikoha madalaima keskmise mälutarbimisega 8 MB, mis pole üllatav, kui arvestada, et disaini põhiidee on lihtsus. mlterm, xterm ja rxvt tarbivad veidi rohkem - umbes 12 MB. Veel üks märkimisväärne tulemus on Alakritty, mille käitamiseks on vaja 30 MB. Siis on VTE perekonna terminalid numbritega 40–60 MB, mis on üsna palju. Seda tarbimist võib seletada asjaoluga, et need terminalid kasutavad kõrgema taseme raamatukogusid, näiteks GTK-d. Konsole on testimise ajal viimaseks jäänud ilmatu 65 MB mälutarbimisega, kuigi seda võib põhjendada selle väga laia funktsioonide valikuga.
Võrreldes varasemate kümne aasta taguste tulemustega, hakkasid kõik programmid märkimisväärselt rohkem mälu kulutama. Xterm nõudis varem 4 MB, kuid nüüd nõuab see käivitamisel 15 MB. Sarnane tarbimine on suurenenud ka rxvt jaoks, mis vajab nüüd karbist 16 MB. Xfce Terminal võtab enda alla 34 MB, mis on kolm korda suurem kui varem, kuid GNOME terminal vajab vaid 20 MB. Loomulikult viidi kõik eelnevad testid läbi 32-bitise arhitektuuriga. LCA 2012 Rusty Russell , et on palju peenemaid põhjuseid, mis võivad seletada mälutarbimise suurenemist. Seda öeldes elame praegu ajal, kus meil on gigabaiti mälu, nii et saame kuidagi hakkama.
Kuid ma ei saa jätta muljet, et rohkem mälu eraldamine millelegi nii olulisele asjale nagu terminal on ressursi raiskamine. Need programmid peaksid olema väikseimatest väikseimad, suutma töötada mis tahes "kastis", isegi kingakarbis, kui me kunagi jõuame selleni, et need tuleb varustada Linuxi süsteemidega (ja teate, et see on nii ) . Kuid nende numbritega muutub mälukasutus tulevikus probleemiks igas keskkonnas, kus töötab mitu terminali, välja arvatud mõned kõige kergemad ja piiratud võimalustega. Selle kompenseerimiseks on GNOME-i terminalil, Konsoolil, urxvt-l, Terminaatoril ja Xfce-terminalil deemonirežiim, mis võimaldab juhtida mitut terminali ühe protsessi kaudu, piirates nende mälutarbimist.
Testide käigus jõudsin ketta lugemise-kirjutamise osas veel ühe ootamatu tulemuseni: eeldasin, et ei näe siin midagi, kuid selgus, et mõned terminalid kirjutavad kettale kõige mahukamaid andmeid. Niisiis, VTE teek hoiab tegelikult kettal kerimispuhvrit (see funktsioon ja see juhtub ikka veel). Kuid erinevalt vanematest rakendustest on nüüd vähemalt need andmed krüptitud AES256 GCM (). Kuid tekib mõistlik küsimus: mis on VTE raamatukogus nii erilist, et see nõuab nii ebastandardset lähenemist rakendamisele...
Järeldus
Artikli esimeses osas leidsime, et VTE-põhistel terminalidel on hea hulk funktsioone, kuid nüüd näeme, et sellega kaasnevad mõned jõudluskulud. Nüüd pole mälu probleem, sest kõiki VTE terminale saab juhtida Daemoni protsessi kaudu, mis piirab nende isu. Kuid vanemad süsteemid, millel on RAM-i ja tuumapuhvrite füüsilised piirangud, võivad siiski vajada terminalide varasemaid versioone, kuna need tarbivad oluliselt vähem ressursse. Kuigi VTE terminalid toimisid läbilaskevõime (kerimise) testides hästi, on nende kuva latentsus üle GNOME'i kasutusjuhendis seatud läve. VTE arendajad peaksid ilmselt sellega arvestama. Kui võtta arvesse, et isegi algajatele Linuxi kasutajatele on terminaliga kokku puutumine vältimatu, saavad nad selle kasutajasõbralikumaks muuta. Kogenud nohikutele võib vaiketerminalilt üleminek tähendada isegi väiksemat silmade väsitamist ja võimalust vältida tulevasi tööga seotud vigastusi ja haigusi pikkade tööseansside tõttu. Kahjuks toovad vaid vanad xterm ja mlterm meid maagilise pingi läveni 10 millisekundit, mis on paljude jaoks vastuvõetamatu.
Ka võrdlusuuringud näitasid, et Linuxi graafiliste keskkondade arendamise tõttu pidid arendajad tegema mitmeid kompromisse. Mõned kasutajad võivad soovida vaadata tavalisi aknahaldureid, kuna need vähendavad oluliselt pingimist. Kahjuks ei olnud Waylandi latentsusaega võimalik mõõta: programm Typometer, mida kasutasin, loodi selleks, et Wayland ära hoida: teiste akende luuramiseks. Loodan, et Waylandi koostamine toimib paremini kui X.org, ja loodan ka, et tulevikus leiab keegi võimaluse selles keskkonnas latentsusaega mõõta.
Allikas: www.habr.com