Terminali emulatorite ülevaade

Mõned sõnad meie tõlkebüroost: tavaliselt püütakse tõlkida kõige värskemaid materjale ja avaldusi, ja me ei ole erand. Kuid terminalid ei ole just need, mis uuenevad kord nädalas. Seetõttu tõlkisime teile Antoine Bopré artikli, mis ilmus 2018. aasta kevadel: vaatamata oma „vanusele” on see meie arvates endiselt asjakohane. Lisaks on originaal kahe artikli seeria, kuid otsustasime need ühendada üheks suureks postituseks.

Terminalid mängivad arvuti ajaloos erilist rolli, kuid viimastel aastakümnetel on nad olnud sunnitud koos käsureaga ellu jääma, kuna graafilised liidesed on laialdaselt levinud. Terminalide emulaatorid asendasid oma riistvaralised venna, mis olid omakorda muudetud süsteemidest, mis kasutasid puidust kaartide ja lülitite süsteemi. Kaasaegsed distributsioonid pakuvad hulganisti terminali emulaatoreid eri vormide ja värvitoonidega. Kuigi paljud on rahul standardse terminaliga, mille nende töökeskkond pakub, kasutavad mõned uhkusega tõeliselt eksootilist tarkvara, et käivitada oma lemmik shelli või tekstiredaktorit. Kuid nagu me sellest artiklist näeme, ei ole kõik terminalid loodud ühesuguseks: need erinevad üksteisest funktsionaalsuse, suuruse ja tulemuslikkuse osas.

Mõned terminalid on varustatud üllatavalt suurte turvaaukudega, lisaks omavad enamik täiesti erinevat funktsioonide komplekti, alates vahekaardiga liidese tosupportamisest kuni skriptideni. Kuigi me oleme varem käsitlenud terminali emulaatoreid, on see artikkel varasemate materjalide uuendamine, mis aitab lugejatel kindlaks teha, millist terminali kasutada 2018. aastal. Artikli esimeses pooles võrreldakse funktsioone ja teises hinnatakse tulemuslikkust.

Siin on minu ülevaatuses seotud terminalid:

Võimalik, et need ei ole kõige uuemad versioonid, kuna piirdusin stabiilsete kogumitega hetkel, mil materjali kirjutasingi, mille suutsin tööle saada Debian 9 või Fedora 27 peal. Ainsaks erandiks on Alacritty. See on GPU-kiirenduse kasutav terminal ja on kirjutatud ebatavalisel ja uuel keelel - Rust. Välja jätsin oma ülevaatest veebiterminalid (sealhulgas ka Electron), sest eeltestid näitasid nende äärmiselt madalat jõudlust.

Unicode-toe olemasolu

Alustasin oma teste Unicode-toe hindamisega. Terminaalide esimene test oli kuvada Unicode'i stringi Wikipedias: "é, Δ, Й, ק, م, ๗, あ, 叶, 葉 ja 말". See lihtne test näitab, kas terminal suudab töötada kogu maailmas. Terminal xterm ei kuva araabia tähemärki Mälu vaikimisi seadistuses:

Vaikimisi kasutab xterm klassikalist "fikseeritud" fonti, mis vastavalt samale Wikile, sisaldab „märkimisväärset Unicode katvust alates 1997. aastast“. Selles fondis toimub midagi, mis põhjustab sümboli kuvamise tühjana, ja ainult siis, kui teksti fondi suurust suurendada 20+ punktini, hakkab sümbol lõpuks õigesti kuvama. Siiski rikub selline „parandus“ teiste Unicode sümbolite kuvamist:

Need ekraanipildid tehti Fedora 27-s, kuna see andis paremaid tulemusi kui Debian 9, kus mõned vanemad terminaliversioonid (konkreetsemalt — mlterm) ei suutnud fonte korralikult käsitleda. Õnneks on see hiljemates versioonides parandatud.

Nüüd pöörake tähelepanu xterm-is oleva rea kuvamisele. Selgub, et sümbol Mem ja sellele järgnev Semitic Qoph kuuluvad RTL (right-to-left) stiilide alla, seega peaksid nad tehniliselt kuvama paremale. Veebibrauserid, näiteks Firefox 57, töötlevad ülaltoodud rida õigesti. Lihtsam näide RTL-tekstist on sõna „Sarah“ heebrea keeles (שרה). Wiki leht kahepoolsest tekstist ütleb järgmist:

„Paljud arvutiprogrammid ei suuda kahe suunalist teksti õigesti kuvada. Näiteks juudi nimi „Sara” koosneb tähtedest sin (ש) (mis tuleb paremale), seejärel resh (ר) ja lõpuks chet (ה) (mis peaks ilmuma vasakule).“

Paljud terminalid ei läbinud seda testi: Alacritty, Gnome ja XFCE VTE-põhised terminalid, urxvt, st ja xterm kuvavad „Sara” vastupidises järjekorras, nagu oleksime selle nime kirjutanud kui „Aras”.

Teine kahe suunalise teksti probleem on see, et neid tuleb kuidagi joondada, eriti kui tegemist on RTL ja LTR tekstide segamisega. RTL stsenaariumid peaksid algama terminali akna paremas servas, kuid mis peaks juhtuma terminalidega, mis vaikimisi töötavad LTR-inglise keeles? Enamik neist ei oma mingeid spetsiaalseid mehhanisme ja joondavad kogu teksti vasakule (sealhulgas Konsole). Eranditeks on pterm ja mlterm, mis järgivad standardeid ja joondavad sellised read paremale.

Sisestamise kaitse

Järgmine kriitiline omadus, mille ma enda jaoks määratlesin, on sisestamise kaitse. Kuigi on laialdaselt teada, et sellised loitsud:

$ curl http://example.com/ | sh

on koodide täitmiseks mõeldud push-käsklused, kuid vähe on neid, kes teavad, et peidetud käsud võivad kopitud ja kleebitud veebibrauserist konsooli sattuda, isegi pärast põhjalikku ülevaatamist. Janna Horni kontrollimisleht tõhusalt illustreerib, kuidas näiliselt kahjutu käsk:

git clone git://git.kernel.org/pub/scm/utils/kup/kup.git

muutub Horni saidilt kleepimisel terminalis tõeliseks probleemiks:

git clone /dev/null;
    clear;
	echo -n "Tere ";
	whoami|tr -d 'n';
	echo -e '!nSee oli halb mõte. Ära kopeeri koodi veebilehtedelt, mida sa ei usalda! 
	Siin on esimene rida sinu /etc/passwd: ';
	head -n1 /etc/passwd
	git clone git://git.kernel.org/pub/scm/utils/kup/kup.git

Kuidas see töötab? Kahjulik kood on eraldatud plokki , mis on CSS-i vahendite abil kasutaja silmist eemaldatud.

Bracketed paste režiim on selgelt ette nähtud sarnaste rünnakute neutraliseerimiseks. Sel moel paigutavad terminalid sisestatud teksti paaridesse erilistesse escape-järjestustesse, et teavitada shelli selle teksti päritolust. Nii saab shell signaali, et ta võib ignoreerida neid erimärke, mida sisestatud tekst võiks sisaldada. Kõik terminalid, sealhulgas austatav xterm, toetavad seda funktsiooni, kuid Bracketed-režiim vajab toetust samuti shellilt või rakenduselt, mis töötab terminalis. Näiteks tarkvara, mis kasutab GNU Readline (sama Bash), vajab faili ~ /.inputrc:

set enable-bracketed-paste on

Kahjuks näitab Horni testimisait ka seda, kuidas seda kaitset ületada teksti enda vormindamise kaudu ja Bracketed-režiimi rakendamise enneaegse lõpetamisega. See töötab, sest mõned terminalid filtreerivad escape-järjestused valesti enne omaenda lisamist. Näiteks ei suutnud ma isegi õige konfiguratsiooni korral oma teste Konsole'is edukalt lõpetada .inputrc faili. See tähendab, et saate kergesti kahjustada süsteemi konfiguratsiooni toetamata rakenduse või vale seadistuse tõttu. See on eriti ohtlik kaugserveritele logimise korral, kus konfiguratsiooni hoolikas töötlus esineb harvemini, eriti kui teid on palju selliseid kaugmasinaid.

Hea lahendus selle probleemi jaoks on terminali kinnitusplugin urxvt, mis lihtsalt küsib luba igasuguste uute ridadega teksti kleepimiseks. Minu jaoks pole selle kirjeldatud Horno tekstirünnaku jaoks turvalisemat varianti.

Vahekaartide ja profiilide

Populaarne funktsioon, mida nüüd toetatakse, on sakkide liidese tugi, mida määratleme kui ühe terminali akna, mis sisaldab endas veel mitmeid terminale. Erinevate terminalide jaoks erineb see funktsioon ning kuigi traditsioonilised xterm tüüpi terminalid ei toeta üldse sakke, on kaasaegsemad terminali versioonid nagu Xfce Terminal, GNOME Terminal ja Konsole selle funktsiooni omavad. Samuti on sakivaatamistoetuse olemas Urxvt, kuid ainult juhul, kui kasutatakse pluginat. Kuid sakivaatamise toetuse osas on terminator absoluutne liider: see toetab mitte ainult sakke, vaid suudab terminale paigutada ka suvalisse järjekorda (vt allolevat pilti).

Teise olulise omadusena võimaldab Terminator „rühmitada“ need sakkid kokku ja saata samu klahvivajutusi mitu terminali korraga, mis pakub jämedat tööriista massiliste toimingute tegemiseks mitmel serveril korraga. Sarnane funktsioon on olemas ka Konsole'is. Selle funktsiooni kasutamiseks teistes terminalides on vajalik kolmanda osapoole tarkvara, nagu Cluster SSH, xlax või tmux.

Eriti hästi töötavad sakkid koos profiilidega: näiteks võite omada ühte sakkid e-kirjade jaoks, teist jututoas jne. Seda toetavad hästi terminalid Konsole ja GNOME Terminal. Mõlemad võimaldavad igal sakkidel automaatselt käivitada oma profiili. Terminator toetab samuti profiile, kuid ma ei leidnud viisi teatud programmide automaatseks käivitamiseks, kui avatakse konkreetne sakk. Teised terminalid ei tunne üldse mõistet „profiil“.

Rüüsid

Viimased, mida ma esimeses osas käsitlen, on terminalide välimus. Näiteks GNOME, Xfce ja urxvt toetavad läbipaistvust, kuid hiljuti on nad taustapiltide toe lõpetanud, mis on sundinud mõnda kasutajat üle minema terminalile. Tilix. Isiklikult mul see sobib ja on lihtsalt Xresources, mis seadistab urxvt jaoks põhikomplekti taustavärve. Siiski võivad mittestandardsete värviteemade kasutamine tekitada probleeme. Näiteks, Solarized ei toimi rakendustega htop ja IPTraf, kuna need kasutavad juba oma värve.

Originaalne VT100 terminal ei toetanud värve ja uued olid sageli piiratud 256 värvi paletiga. Kogenud kasutajatele, kes stiilivad oma terminale, võivad käsurea või oleku ridadel keerulised viisid osutuda ebamugavaks piiranguks. Gist jälgib, millised terminalid toetavad "True Color". Minu testid kinnitavad, et st, Alacritty ja VTE-põhised terminalid toetavad True Colorit suurepäraselt. Teised terminalid ei tunne end selles osas eriti hästi ja ei näita isegi 256 värvi. Allpool näete erinevust True Color toetuses GNOME, st ja xterminaalide vahel, mis teevad selle ülesande 256-värvilise paletiga hästi, ja urxvt, mis mitte ainult ei pruugi testi läbida, vaid näitab isegi vilkuvaid sümboleid.

Mõned terminalid analüüsivad ka teksti URL-mustrite tuvastamiseks, et muuta lingid klikkimiseks sobivaks. See kehtib kõigi VTE-põhiste terminalide kohta, samas kui urxvt vajab spetsiaalset plugina, mis muudab URL-aadresse klikkimise või klahvikombinatsiooni abil. Teised testitud terminalid kuvavad URL-e muul viisil.

Lõpuks on uus trend terminalides - kerimisbuffri valikulisus. Näiteks st-s puudub kerimisbuffers; eeldatakse, et kasutaja kasutab terminali multiplexerit, nagu tmux ja GNU Screen.

Alacritty-l puuduvad ka tagasikerimise moodulid, kuid peagi lisandub selle tugi «ulatusliku tagasiside» tõttu sellel teemal kasutajatelt. Lisaks nendele eranditele toetab iga kontrollitud terminal, mille ma suutsin leida, tagasikerimist.

Vahekokkuvõte

Teises osas materjalist (originaalis olid need kaks erinevat artiklit, — toimetaja märkus.) võrdleme jõudlust, mälu kasutamist ja viivitust. Kuid me näeme juba, et mõned arutatavad terminalid omavad tõsiseid puudusi. Näiteks võivad regulaarsetes RTL-skriptidega töötavad kasutajad pöörata tähelepanu mltermile ja ptermile, kuna need saavad sellega paremini hakkama kui teised. Konsole on samuti hästi esinenud. RTL-skriptidega mitte töötavad kasutajad võivad valida midagi muud.

Turvalisuse seisukohalt paistab urxvt silma oma erilise kaitsetehnoloogia poolest, mis kaitseb kahjuliku koodi lisamise rünnakute eest – see tundub tõeliselt mugav. Neile, kes otsivad rohkem funktsioone, tasub vaadata Konsole'i. Lõpuks väärib märkimist, et VTE on suurepärane baas terminalide jaoks, tagades toega värve, URL-ide tuvastamise ja nii edasi. Esmapilgul võib teie lemmikeskeskkonnaga kaasasolev vaike-terminal vastata kõigile nõudmistele, kuid jätame selle küsimuse lahtiseks, kuni saame aru jõudlusest.

Jätkame vestlust

Tegelikult võib terminalide jõudlus tunduda liialdatud probleemina, kuid nagu selgus, näitavad mõned neist üllatavalt suurt viivitust sellise fundamentaalse tarkvara jaoks. Samuti vaatleme edasi seda, mida tavaliselt nimetatakse ‘kiirus’ (tõepoolest, see on kerimise kiirus) ja terminali mälu tarbimist (kortsu silmas pidades, et täna ei ole see nii kriitiline kui kümneid aastaid tagasi).

Viivitus

Pärast terminalide jõudluse põhjalikku uurimist jõudsin järeldusele, et selle osas on kõige olulisem parameeter viivituse suurus (ping). Oma artiklis «Trüki rõõmuga» Pavel Fatin vaatas erinevate tekstiredaktorite viivitust ja vihjas, et terminalid võivad selles osas töötada aeglasemalt kui kõige kiiremad tekstiredaktorid. Just see vihje tõi mind lõpuks oma testide läbiviimisele ja selle artikli kirjutamisele.

Aga mis on viivitus ja miks see on nii oluline? Oma artiklis määratles Fatin selle kui «viivituse klahvi vajutamise ja vastava ekraani uuendamise vahel» ning tsiteeris «Inimese ja arvuti interaktsiooni juhend», milles öeldakse: «Ekraanil visuaalse tagasiside viivitus mõjutab oluliselt masinakirjutaja käitumist ja rahulolu».

Fatin selgitab, et see pinge on sügavamate tagajärgedega kui pelgalt rahulolu: "trükkimine muutub aeglasemaks, vigu tekib rohkem, silmade ja lihaste pinge suureneb." Teisisõnu, suurem viivitus võib viia trükivigadeni ning koodi kvaliteedi langusele, suurendades aju täiendavat kognitiivset koormust. Kuid mis veel hullem, pinge "suurendab silmade ja lihaste pinget", mis viitab selgelt sellele, et kutsehaiguste areng tulevikus (ilmselt mõtleb autor silmade, selja, käte ja loomulikult nägemise probleemidele — tõlkija märkus.) korduva pinge tõttu.

Mõned neist mõjudest on ammu tuntud ning 1976. aastal ajakirjas Ergonomics avaldatud tulemused näitavad, et 100 millisekundi viivitus "halvendab märkimisväärselt trükkimise kiirus." Hiljuti viidi GNOME'i kasutajate juhendisse uurimisevastuvõetav reageerimisaeg 10 millisekundit, ja kui edasi minna, siis Microsoft Research näitab, et ideaalne on 1 millisekund. näitab, et ideaal on 1 millisekund.

Fatin viis oma teste läbi tekstiredaktorites; ta lõi portaabeltööriista nimega Typometer, mida kasutasin pingete kontrollimiseks terminali emulatorites. Pidage meeles, et test viidi läbi simuleerimisrežiimis: tegelikult peab arvesse võtma ka sisendi (klaviatuur, USB-kontroller jne) ja väljundi (videokaardi puhversäilitamine, monitor) hilinemist. Fateri sõnul on tüüpilistes konfiguratsioonides see umbes 20 ms. Mängijate varustusega on võimalik saavutada tulemuseks ainult 3 millisekundit. Kuna meil on juba nii kiire varustus, ei tohiks rakendus veelgi oma viivitust lisada. Fatini eesmärk on viia rakenduse viivitus 1 millisekundini või võimalusel saavutada määramatute viivitustenii, kuiIntelliJ IDEA 15 Siin on aga minu mõõtmiste tulemused ja mõned Fatini tulemused, et näidata, et minu katse on kooskõlas tema testidega:.

Siin on minu mõõtmiste tulemused, samuti mõned Fatini tulemused, et näidata, et minu eksperiment on kooskõlas tema testidega:

Esimene, mis mind üllatas, oli vanade programmide, nagu xterm ja mlterm, parem reageerimisaeg. Kehvema katkestuse latentsus (2,4 ms) saavutas tulemused, mis olid paremad kui kõige kiiremal tänapäevasel terminalil (10,6 ms st jaoks). Ükski tänapäevane terminal ei jää alla 10 millisekundi lävendile. Eriti Alacritty ei vasta nõuetele, et olla "kiireim olemasolevatest terminali emulatoritest," kuigi selle tulemused on paranenud pärast esimese kontrolli 2017. aastal. Tõepoolest, projekti autorid on teadlikud olukorrast ja töötavad kuvamise parendamise nimel. Samuti tuleb märkida, et GTK3-d kasutav Vim on oma GTK2 analoogist võrreldes oluliselt aeglasem. Sellest võib järeldada, et GTK3 tekitab täiendavat latentsust, mis kajastub kõigis teistes terminalides, mis seda kasutavad (Terminator, Xfce4 Terminal ja GNOME Terminal).

Kuid silmale võivad erinevused olla märkamatud. Nagu selgitab Fatin: "ei ole alati vajalik teadvustada viivitust, et see oleks teie jaoks efektiivne." Fatin hoiatab ka standardhälbe eest: "kõik katkestused viivituse kestuses (värisemine) põhjustavad täiendavat koormust nende ettearvamatuse tõttu."

Ülaltoodud graafik on saadud puhtal Debian 9 (stretch) põhjal i3 aknahaldurist. See keskkond annab parimad tulemused viivituse määramise testides. Nagu selgus, loob GNOME kõigi mõõtmiste jaoks täiendava 20 ms pingi. Sellele võib olla võimalik seletus, et olemas on programmid, mis töötlevad sisendite sündmusi sünkroonselt. Fatin toob selle juhtumi jaoks näiteks Workrave, mis lisab viivituse, töötledes kõik sisend-sündmused sünkroonselt. Vaikimisi on GNOME varustatud ka aknahalduriga Mutter, mis loob täiendava puhverdamise taseme, mis mõjutab pingi ja lisab vähemalt 8 millisekundi viivitust.

Kerimiskiirus

Järgmine test on traditsiooniline «kiirus» või «bännide» kontroll, mis mõõdab, kui kiiresti terminal suudab lehte sirvida, kuvades suurt hulka teksti ekraanil. Testi mehhaanika varieerub; algne test koosnes lihtsalt sama teksti rea genereerimisest käsuga seq. Teised testid hõlmavad Thomas E. Dicki kontrolli (kaasa arvatud xterm), mille raames toimub korduv faili terminfo.src eksportimine. Veel ühes terminalide jõudluse ülevaates Den Luu kasutab base32 kodeeringus juhuslike baitide rida, mis näidatakse terminalis käsuga cat. Luu peab sellist testi "nii kasutuks standardiks, kui see vaid mõeldav on", ning soovitab selle asemel kasutada terminali vastust põhinäitajana. Diki nimetab oma testi eksitavaks. Siiski tunnustavad mõlemad autorid, et terminali akna läbilaskevõime võib olla probleem. Luu avastas Emacs Eshelli külmumise suurte failide kuvamisel, samas kui Diki optimeeris terminali, et vabaneda visuaalsest aeglustumisest xtrerm. Seetõttu on selles testis ikkagi teatud mõte, kuid kuna renderdamisprotsess erineb terminalist terminali, saab seda kasutada ka testkomponendina teiste parameetrite kontrollimiseks.

Siit näeme, et rxvt ja st tõusevad konkurentide seas esile, neid järgneb palju uuem Alacritty, mis on välja töötatud jõudluse rõhuasetusega. Järgmised on Xfce (VTE perekond) ja Konsole, mis töötavad peaaegu kaks korda kiiremini. Lõpus on xterm, mis on viis korda aeglasem kui rxvt. Testi ajal näitas xterm ka tugevat virvendamist, mööduvat teksti oli raske näha, isegi kui see oli sama rida. Konsole osutus kiireks, kuid aeg-ajalt „pettes“: kuvamine jääb mõnikord pidama, näidates teksti osaliselt või mitte näidates seda üldse. Teised terminalid, sealhulgas st, Alacritty ja rxvt, näitasid ridu selgelt.

Diki selgitab, et jõudluse erinevused tulenevad erinevate terminalide kerimisbuffrite disainist. Eelkõige süüdistab ta rxvt ja teisi terminale selles, et need "ei järgi üldisi reegleid":

Erinevalt xterm'ist ei püüdnud rxvt kõiki värskendusi kuvada. Kui see jääb maha, loobub see mõnedest värskendustest, et järgida, mis on rohkem mõjutanud näiliselt kerimise kiirusest kui sise-mälu korraldusest. Üheks puuduseks oli see, et ASCII animatsioon oli pisut ebatäpne.

Selle näilise aegluse parandamiseks xterm'i puhul soovitab Dick kasutada ressurssi fastScroll, mis võimaldab xterm'il filtreerida mõned ekraani värskendused, et mitte maha jääda voost. Minu testid kinnitavad, et fastScroll parandab jõudlust ja tõstab xterm'i rxvt tasemele. See aga on üsna jäik lahendus, nagu Dick ise selgitab: "Mõnikord tundub xterm - nagu konsool - peatuma, kuna ootab uut ekraani värskenduste komplekti pärast seda, kui mõned neist on eemaldatud". Sellega seoses näib, et teised terminalid on leidnud parima tasakaalu kiiruse ja ekraani terviklikkuse vahel.

Ressursikasutamine

Hoolimata sellest, kui asjakohaseks võiks pidada kerimise kiirusest rääkimist kui jõudluse näitajast, võimaldab see test simuleerida koormust terminalides, mis omakorda võimaldab meil mõõta teisi parameetreid, nagu mälu või ketta kasutamine. Metrika saadakse, käivitades antud testi. seq Python protsessi jälgimise all. See kogus loenduri andmeid. getrusage () kuna ru_maxrss, summa ru_oublock ja ru_inblock ja lihtne ajataimer.

Sel testil saavutab ST esikoha kõige väiksema keskmise mälu tarbimisega 8 MB, mis pole üllatav, arvestades, et projekti põhieesmärk on lihtsus. Natuke rohkem tarbivad mlterm, xterm ja rxvt — umbes 12 MB.Veel üks silmapaistev tulemus on Alacritty, mille tööks on vajalik 30 MB. Järgmisel kohal on VTE pere terminálid, mille näitajad ulatuvad 40-60 MB-ni, mis on üsna palju. Selline tarbimine on seletatav sellega, et need terminalid kasutavad kõrgema taseme teeke, nagu GTK. Konsole jääb viimaseks, tarbides testi ajal tohutult 65 MB mälu, kuigi seda saab õigustada tema ulatusliku funktsioonide komplektiga.

võrreldes kümne aasta taguste tulemustega, on kõik programmid hakanud oluliselt rohkem mälu tarbima. Varem nõudis Xterm 4 MB, kuid nüüd vajab see käivitamiseks 15 MB. Samuti on rxvt kasvanud ja nõuab nüüd koheselt 16 MB. Xfce terminal võtab 34 MB, mis on kolm korda rohkem kui varem, samas kui GNOME Terminal vajab vaid 20 MB. Loomulikult viidi kõik varasemad testid läbi 32-bitistel arhitektuuridel. LCA 2012 sündmuses rääkis Rasti Russell rääkis, et on palju peenemaid põhjuseid, mis võivad seletada mälutarbimise suurenemist. Sellega seoses elame tänapäeval ajal, mil meil on terveid gigabaite mälu, nii et me saame sellega kuidagi hakkama.

Siiski ei saa ma minema jätta tunnet, et suurema mälu eraldamine nii põhilisele tarkvarale nagu terminal on lihtsalt ressursi raiskamine. Need programmid peaksid olema kõige väiksemad, suutma töötada igasugune 'karbis', isegi kingakarbis, kui peaksime kunagi olukorda, kus need peavad olema varustatud Linux-süsteemidega (ja teate küll, et see tuleb). Kuid nende numbritega muutub mälu kasutamine tulevikus probleemiks igas keskkonnas, kui avada mitu terminali, välja arvatud olukord, kus on mõned kõige kergemad ja piiratud võimalustega. Selle kompenseerimiseks on GNOME Terminalil, Konsolel, urxvt-l, Terminatoril ja Xfce Terminalil Daemon-režiim, mis võimaldab hallata mitut terminali ühe protsessi kaudu, piirates nende mälu tarbimist.

Oma testide käigus jõudsin veel ühe ootamatu tulemuseni, mis puudutab ketta lugemist-kirjutamist: ma ei oodanud siit üldse midagi näha, kuid selgus, et mõned terminalid kirjutavad kõige suuremaid andmeid ketta. Näiteks VTE teek hoiab tegelikult ketas kerimise vahemälu (see omadus märgati juba 2010. aastal, ja see toimub siiani). Kuid erinevalt vanadest rakendustest on nüüd vähemalt need andmed AES256 GCM krüptimisega kaitstud (versioonist 0.39.2). Kuid tekib mõistlik küsimus, mis on siis nii erilist VTE raamatukogus, et see vajab sellist ebatavalist lähenemist rakendusele…

Kokkuvõte

Artikli esimeses osas leidsime, et VTE-põhised terminalid omavad head funktsioonide kogumit, kuid nüüd näeme, et nende jõudluse tagamine toob kaasa teatud kulud. Praegu pole mälu probleem, kuna kõiki VTE-terminalid saab hallata Daemon-protsessi kaudu, mis piirab nende vajadusi. Siiski võivad vanad süsteemid, millel on füüsilised piirangud operatiivmälu ja tuuma pufferi koguse osas, endiselt vajada varasemaid versioone terminalidest, kuna need tarbivad märgatavalt vähem ressursse. Kuigi VTE-terminalid on läbi teinud head testid ribalaiuse (kerimise) osas, on nende andmete kuvamise latentsus ekraanil kõrgem kui GNOME'i kasutajajuhendi kehtestatud piir. Tõenäoliselt peaks VTE arendajatele seda silmas pidama. Arvestades, et isegi Linuxi algajate kasutajate jaoks on terminaliga kohtumine vältimatu, võiksid nad muuta selle kasutajasõbralikumaks. Kogenud tehnikutele tähendab vaikimisi terminali vahetus isegi visuaalse koormuse vähendamist ja professionaalsete vigastuste ning haiguste vältimist tulevikus pikaajaliste töösessioonide tõttu. Kahjuks viivad meid maagilisse 10 millisekundi pingepingesse ainult vanad xterm ja mlterm, mis on paljudele vastuvõetamatud.

Kontrollmõõtmised on samuti näidanud, et tänu Linuxi graafiliste keskkondade arengule pidid arendajad tegema mitmeid kompromisse. Mõned kasutajad peaksid vaatama tavapäraste aknahaldurite poole, kuna need pakuvad märkimisväärset pingelangust. Kahjuks ei õnnestunud Waylandi viivitust mõõta: programm Typometer, mida kasutasin, oli loodud selleks, et Wayland takistab — teiste aknade pealt nuhkimise. Loodan, et Waylandi komposiit on jõudluselt parem kui X.org, ja loodan ka, et tulevikus keegi leiab viisi viivituse taseme hindamiseks selles keskkonnas.

Allikas: habr.com