Terminalide emulaatorite ülevaade

Mõned sõnad meie tõlkebüroost: tavaliselt püütakse tõlkida kõige uuemaid materjale ja avaldusi, ning me ei ole erand. Kuid terminalid ei ole asi, mis uuendatakse iga nädal. Seetõttu tõlkisime teile Antoine Bopre'i artikli, mis avaldati 2018. aasta kevadel: vaatamata kaasaegsete mõõtmete järgi "vanusele" pole meie arvates materjal kaotanud oma aktuaalsust. Lisaks on originaalis tegemist kahe artikli sarjaga, kuid otsustasime need ühte suure postitusse koondada.

Terminalid omavad arvutiajaloos erilist kohta, kuid viimastel aastakümnetel on nad pidanud sõna otseses mõttes koos käsureaga ellu jääma laialdaselt levinud graafiliste liidesete taustal. Terminali emulaatorid asendasid oma riistvaralised kolleegid, mis omakorda olid perforaarkaardisüsteemide ja lülitite modifikatsioon. Kaasaegsed distribtsioonid tulevad koos hulga erinevate terminali emulaatoritega, mis on igasuguste vormide ja värvidega. Ja seni kui paljud on rahul oma töökeskkonna pakutava standardsel terminaliga, siis mõned uhkelt kasutavad tõeliselt eksootilist tarkvara oma lemmikterminali või tekstiredaktori käivitamiseks. Kuid nagu me näeme sellest artiklist, ei ole kõik terminalid loodud ühtemoodi: nad erinevad omavahel oluliselt funktsionaalsuse, suuruse ja jõudluse poolest.

Mõned terminalid omavad otseselt hämmastavaid turvaauke, lisaks on enamikul neist täiesti erinev funktsioonide komplekt, alates vahetustega liidese toimest kuni skriptideni. Kuigi me vaatasime terminali emulaatoreid kauges minevikus, on see artikkel varasema materjali ajakohastamine, mis aitab lugejatel määrata, millist terminali kasutada 2018. aastal. Artikli esimeses osas võrreldakse funktsioone ja teises hinnatakse jõudlust.

Siin on minu käsitletud terminalid:

Võimalik, et need ei ole kõige värskemaid versioone, kuna ma piirdusin stabiilsete kogumitega selle sisu kirjutamise hetkel, mis mul õnnestus paigaldada Debian 9-le või Fedora 27-le. Ainsaks erandiks on Alacritty. See on GPU-kiirendusega terminalide järeltulija ja on kirjutatud selle ülesande jaoks uues ja ebatavalises keeles - Rust. Ma ei toonud oma ülevaatesse veebiterminale (sealhulgas ka) Electron), sest eelteated näitasid nende ekstremalselt madalat jõudlust.

Unicode'i tugi

Oma testid alustasin Unicode'i toega. Esimene terminalide test oli nende võime kuvada Unicode'i rida, mille sain Wikipeedia artiklist: „é, Δ, Й, ק, م, ๗, あ, 叶, 葉 ja 말“. See lihtne test näitab, kas terminal suudab üle maailma korrektselt töötada. Terminal xterm ei kuva araabia sümbolit Mem vaikimisi seadistustes:

Vaikimisi kasutab xterm klassikalist "fikseeritud" fonte, mis, nagu väidab sama Wikipeedia, omab „olulist Unicode'i katvust alates 1997. aastast“. Selles fondis toimub midagi, mis põhjustab sümboli kuvamise tühja raamina ja ainult siis, kui teksti fonti suurendada 20+ punktini, hakkab sümbol lõpuks õigesti kuvatama. Kuid selline "parandus" rikub teiste Unicode'i sümbolite kuvamist:

Need ekraanipildid tehti Fedora 27-s, kuna see andis paremaid tulemusi võrreldes Debian 9-ga, kus mõned vanemad terminalid (konkreetsemalt - mlterm) ei suutnud korralikult fonte töödelda. Õnneks parandati see hilisemates versioonides.

Nüüd pöörake tähelepanu real xterm-is. Selgub, et sümbol Mem ja selle järel olev semitiline Qoph kuulu RTS-i (right-to-left), seega peaksid nad tehniliselt olema kuvatud paremalt vasakule. Veebibrauserid, nagu näiteks Firefox 57, töötlevad eelnevalt toodud rida õigesti. Lihtsamaks RTL-teksti näiteks on sõna „Sara“ heebrea keeles (שרה). Wikipeedia leht kahe suunda tekste ütleb järgmist:

„Paljud arvutiprogrammid ei suuda õigesti kuvada kahe suunda teksti. Näiteks heebrea nimi „Sara“ koosneb sümbolitest sin (ש) (mis ilmub paremale), seejärel resh (ר) ja lõpuks he (ה) (mis peaks ilmuma vasakule).“

Paljud terminalid ei läbi seda testi: Alacritty, Gnome ja XFCE VTE-põhised terminalid, urxvt, st ja xterm kuvavad 'Sara' tagurpidi, justkui oleksime seda nime kirjutanud kui 'Aras'.

Teine kaheastmeliste tekstide probleem on see, et neid tuleb kuidagi joondada, eriti kui segatakse RTL ja LTR tekste. RTL-skeemid peaksid algama terminali akna paremal poolel, kuid mis peaks toimuma terminalides, mis vaikimisi töötavad LTR-inglise keeles? Enamik neist ei oma mingeid erilisi mehhanisme ning joondavad kogu teksti vasakule (sealhulgas Konsole'is). Eranditeks on pterm ja mlterm, mis järgivad standardeid ning joondavad sellised read paremale.

Kleepimisvastane kaitse

Järgmine kriitiline omadus, mille ma endale defineerisin, on kleepimisvastane kaitse. Kuigi on laialt tuntud, et järgmised käsud:

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

on koodi käitamise push-käsud, siis vähe teatakse, et varjatud käsud võivad kopeerimise ja kleepimise käigus veebibrauserist konsooli pääseda, isegi pärast põhjalikku kontrollimist. Janna Horne'i kontrollitud veebisait näitab, kuidas esmapilgul kahjutu käsk:

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

muutub Horne'i saidilt kleebitud kust 'paha asja' terminali selliseks:

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

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

Bracketed paste režiim on selgelt loodud sarnaste rünnakute neutraliseerimiseks. Selles režiimis ümbritsevad terminalid kleepitava teksti spetsiaalsete escape-järjestuste paariga, et teavitada shelli selle teksti päritolust. Nii saab shell signaali, et see võib ignoreerida spetsiaalseid märke, mida kleepitav tekst sisaldab. Kõik terminalid, sealhulgas austatud xterm, toetavad seda funktsiooni, kuid Bracketed-režiimis kleepimine vajab shelli või terminalis käivitatud rakenduse toetust. Näiteks GNU Readline'iga (sama Bash) töötav tarkvara vajab faili ~ /.inputrc set enable-bracketed-paste on ~ / .inputrc:

set enable-bracketed-paste on

Kahjuks näitab Horni testidesait ka seda, kuidas seda kaitset tekstivorminduse kaudu ringi hiilida ja Bracketed-režiimi enneaegset rakendamist lõpetada. See toimib, kuna mõned terminalid filtreerivad escape-järjestusi valesti enne, kui lisavad oma. Näiteks ei suutnud ma oma Konsole testide edukat lõpetamist isegi pärast õiget seadistamist. .inputrc fail. See tähendab, et võite kergesti saada süsteemi konfiguratsiooni kahjustusi, tulenevalt mitte toetatud rakendusest või valesti seadistatud kestast. See on eriti ohtlik kaugetele serveritele sisenemisel, kus põhjalikku seadistamist kohatakse harvem, eriti kui teil on palju selliseid kaugeid masinaid.

Hea lahendus sellele probleemile on terminali kleepimise kinnituse plugin urxvt, mis lihtsalt küsib luba mistahes tekstide kleepimiseks, mis sisaldavad uusi ridu. Ma ei leidnud turvalisemat varianti Horni kirjeldatud tekstirünnaku jaoks.

Vahekaardid ja profiilid

Praegu populaarne funktsioon on vahekaartide toe olemasolu, mida me defineerime kui üht terminali akent, mis sisaldab veel mitmeid terminale. See funktsioon erineb erinevates terminalides, ja kuigi traditsioonilised xterm tüüpi terminalid ei toeta vahekaarte, on selle funktsiooni olemasolevad kaasaegsed terminalid nagu Xfce Terminal, GNOME Terminal ja Konsole. Urxvt toetab samuti vahekaarte, kuid ainult plugina kasutamisel. Samuti on vahekaartide poolest absoluutne liider Terminator: see mitte ainult ei toeta vahekaarte, vaid suudab ka terminale paigutada vabalt (vt allolevat pilti).

Teine Terminatori omadus on võimalus „grupida” need vahekaardid kokku ja saata sama klahvivajutuse mitmele terminalile korraga, pakkudes toorest tööriista massiliste toimingute teostamiseks mitmel serveril korraga. Sarnane funktsioon on rakendatud ka Konsole'is. Selle funktsiooni kasutamiseks teistes terminalides on vajalik kolmanda osapoole tarkvara, nagu Cluster SSH, xlax või tmux.

Erakordne on see, et kaardid töötavad koos profiilidega: näiteks võib teil olla üks kaart e-posti jaoks, teine vestluse jaoks ja nii edasi. Seda toetavad hästi Konsole ja GNOME Terminal. Mõlemad võimaldavad igal kaardil automaatselt käivitada oma profiili. Terminator toetab samuti profiile, kuid ma ei suutnud leida viisi, kuidas teatud programme automaatselt avada, kui avada konkreetne kaart. Teised terminalid ei tunne üldse "profiili" mõistet.

Volang

Viimase asjana, mida ma selle artikli esimeses osas käsitlen, on terminalide välimus. Näiteks GNOME, Xfce ja urxvt toetavad läbipaistvust, kuid hiljuti lõpetasid nad taustapiltide toe, mis sundis mõnda kasutajat ülemineku terminalile. Tilix. Isiklikult mulle piisab sellest lihtsalt. Xresources, mis seab urxvt jaoks põhi taustavärvide komplekti. Siiski võivad mitte-standardsed värviteemad tekitada probleeme. Näiteks Solarized ei tööta rakendustega htop ja IPTraf, kuna need kasutavad juba oma värve.

Originaalne VT100 terminal ei toetanud värve, samas kui uued olid sageli piiratud 256 värvi paletiga. Kogenud kasutajatele, kes kohandavad oma terminale, võivad keerukate skriptide või olekuread olla ebameeldivaks piiramise allikaks. Gist jälgib, millised terminalid toetavad "True Color"-it. Minu testid kinnitavad, et st, Alacritty ja VTE-põhised terminalid toetavad suurepäraselt True Colorit. Teised terminalid ei toimi sellega hästi ja ei näita isegi 256 värvi. Allpool näete erinevust True Colori toetuses GNOME, st ja xterm terminalide vahel, mis teevad oma 256 värvi paletiga head tööd, ja urxvt, mis mitte ainult ei läbi testi, vaid näitab isegi vilkuvaid märke nende asemel.

Mõned terminalid analüüsivad ka teksti URL-mallide osas, et muuta lingid klikatavaks. See kehtib kõigi VTE-põhiste terminalide kohta, samas kui urxvt vajab spetsiaalset pistikprogrammi, mis muudab URL-aadressid klikitavateks või otseteede abil. Muud testitud terminalid näitavad URL-aadresse muude viiside kaudu.

Lõfinally, uus trend terminalides on kerimispuu valikuline olemasolu. Näiteks st ei sisalda kerimispuhvrit; eeldatakse, et kasutaja kasutab terminali multiplexerit nagu tmux ja GNU Screen.

Alacritty's puuduvad ka tagasikerimispuhvrid, kuid see lisatakse peagi tema tugi tõttu "ulatuslikule tagasisidele" selle teemaga seoses kasutajatelt. Peale nende erandite toetab iga terminal, mida olen suutnud leida, tagasikerimist.

Vahekokkuvõte

Teise osa materjalist (alguses olid need kaks erinevat artiklit — toimetaja märkus) võrdleme jõudlust, mälukasutust ja viivitust. Kuid me näeme juba, et mõned arutletud terminalid omavad tõsiseid puudusi. Näiteks võivad kasutajad, kes regulaarselt töötavad RTL-skriptidega, pöörata tähelepanu mltermile ja ptermile, kuna need teevad sarnaste ülesannete täitmisel paremat tööd. Konsole on samuti hästi esinenud. RTL-skriptidega mitte tegelevad kasutajad võivad valida midagi muud.

Kaitstuse osas kuritegevuse kodeerimise vastu eristub urxvt oma erilise kaitse realiseerimise tõttu, mis tundub mulle kindlasti mugav. Neile, kes otsivad mingit sära, tasub vaadata Konsole’i. Lõpuks peab märkima, et VTE on suurepärane baas terminalide jaoks, mis garanteerib värvide toe, URL-ide tuvastamise jpm. Esmapilgul võib teie lemmikkeskkonna vaike-terminal vastata kõigile nõudmistele, kuid jätame selle küsimuse avatuks seni, kuni oleme jõudluse kohta rohkem teada saanud.

Jätkame juttu

Üldiselt võib terminalide jõudlus iseenesest tunduda liialdatud probleemina, kuid üllataval kombel näitavad mõned neist üllatavalt suurt viivitust sellise fundamentaalse tarkvara jaoks. Samuti vaatame lähemalt seda, mida traditsiooniliselt nimetatakse „kiirusel“ (tõepoolest, see on kerimise kiirus) ja terminalide mälukasutust (vaadates, et see ei ole täna nii kriitiline kui dekadeid tagasi).

Viivitus

Pärast terminalide jõudluse põhjalikku uurimist olen jõudnud järeldusele, et sellel alal on kõige olulisem parameeter viivituse suurus (ping). Ometi on oma artiklis „Kirjutame rõõmuga“ Pavel Fatin vaatas erinevate tekstiredaktorite viivitusi ja vihjas, et terminalid võivad selles osas töötada aeglasemalt kui kõige kiiremad tekstiredaktorid. Just see vihje viis mind lõpuks oma testide käivitamise ja selle artikli kirjutamiseni.

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“ ja tsiteeris „Inimese ja arvuti interaktsiooni juhend“, kus öeldakse: „Viivitus visuaalses tagasisides arvuti ekraanil mõjutab olulisel määral kirjutaja käitumist ja tema rahulolu“.

Fatin selgitab, et sellisel pingel on sügavamad tagajärjed kui lihtsalt rahulolu: „kirjutamine muutub aeglasemaks, vigu tekib rohkem, silmade ja lihaste pinget suureneb“. Teisisõnu, suurem viivitus võib viia trükivigadeni ja ka koodi kvaliteedi languseni, kuna see tekitab ajus täiendavat kognitiivset koormust. Kuid mis veel hullem, pinget „suureneb silmade ja lihaste pinge“, mis näib viitavat ametialastele vigastustele tulevikus (ilmselt peab autor silmas silmade, selja, käte ja loomulikult nägemisega seotud probleeme, — toimetaja märk.) korduva pingete tõttu.

Mõned neist mõjudest on teada juba pikka aega ja tulemused uuringud, mis avaldati juba 1976. aastal ajakirjas Ergonomics, näitavad, et 100 millisekundi viivitus „halvendab oluliselt sisestamise kiirus“. Hiljuti lisati GNOME'i kasutajajuhendisse vastuvõetav reageerimisaeg 10 millisekundit, ja kui minna kaugemale, siis Microsoft Research

näitab, et ideaalne on 1 millisekund. Fatin tegi oma testid tekstiredaktorites; ta lõi portatiivse tööriista nimega, mida kasutasin terminali emulatorite pingide kontrollimiseks. Pidage meeles, et test viidi läbi simuleerimisrežiimis: reaalsuses tuleb arvesse võtta ka sisendi (klaviatuur, USB-kontroller jne) ja väljundi (videokaardi puhversälu, monitor) viivitust. Fatini sõnul on tüüpilistes konfiguratsioonides see umbes 20 ms. Gamerite varustuse olemasolul võib saavutada vaid 3 millisekundi näitaja. Kuna meil on juba selline kiire varustus, ei tohiks rakendus oma viivitust lisada. Fatini eesmärk on viia rakenduse viivitus 1 millisekundini või täielikult viivitusteta komplekti saavutamisele. mõõdetava viivitusega, nagu IntelliJ IDEA 15.

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

Esimene asi, mis mind üllatas, oli vanade programmide, nagu xterm ja mlterm, parem reageerimisaeg. Halvema registra viivitusega (2,4 ms) näitasid nad paremat tulemust kui kõige kiirem kaasaegne terminal (10,6 ms st jaoks). Ükski kaasaegne terminal ei ulatu alla 10 millisekundi piiri. Eelkõige ei vasta Alacritty nõuetele „kõige kiiremal olemasoleval terminali emulatoril“, ehkki selle tulemused on alates esimesest kontrollist 2017. aastal paranenud. Tõepoolest, projekti autorid on teadlikud olukorrast ja töötavad kuvamise parandamise nimel. Oluline on märkida, et Vim, mis kasutab GTK3, on oma GTK2 analoogist märgatavalt aeglasem. Sellest võib järeldada, et GTK3 tekitab täiendavat viivitust, ja see kajastub kõigis teistes terminalides, mis seda kasutavad (Terminator, Xfce4 Terminal ja GNOME Terminal).

Kuid silmale võivad erinevused jääda märkamatuks. Nagu selgitab Fatin: „ei ole tingimata vajalik viivitust teadvustada, et sellel oleks teile mõju“. Fatin hoiatab ka standardhälbe eest: „kõik viivituse pikkuse (võnkumine) häired lisavad täiendavat koormust nende ettearvamatuse tõttu“.

Ülaltoodud graafik on saadud puhtal Debian 9 (stretch) koos i3 aknahalduriga. See keskkond annab parimaid tulemusi viivituskatsete korral. Selgus, et GNOME tekitab kõigi mõõtmiste jaoks 20 ms lisaviivituse. Üks võimalik seletus on see, et töötavad programmid, mis töötlevad sisendüritusi sünkroonselt. Fatin toob sellise juhtumi jaoks välja Workrave, mille tõttu tekib viivitus, sest kõik sisendüritused töödeldakse sünkroonselt. Vaikimisi on GNOME varustatud ka aknahalduriga Mutter, mis loob lisataseme puhvrisse, mis mõjutab viivitust ning lisab vähemalt 8 millisekundi viivituse.

Kerimiskiirus

Järgmine katse on traditsiooniline "kiirus" või "läbivoolu" kontroll, mis mõõdab, kui kiiresti terminal suudab lehte kerida, kuvades suurt hulka teksti ekraanil. Katse mehhanika varieerub; algne test seisnes lihtsalt sama teksti rea genereerimises seq käsuga. Muud testid hõlmavad Thomas E. Dicki testi (xterm'i kaaslane), millega korduvalt väljastatakse fail terminfo.src. Veel ühes terminallide jõudlusülevaates Den Luu kasutab juhuslike baitide rida base32 kodeeringus, mis edastatakse terminalile cat abil. Luu peab sellist testi "nii kasutu standardiks, kui seda ette kujutada saab" ja soovitab kasutada terminali vastust peamise näitajana. Dick nimetab ka oma testi eksitavaks. Sellegipoolest tunnustavad mõlemad autorid, et terminali akna läbilaskvus võib olla probleem. Luu leidis, et Emacs Eshell hangub suurte failide kuvamisel, ja Dick optimeeris terminali, et vabaneda xterm'i visuaalsest aeglusest. Seetõttu on selles testis endiselt mõningane mõte, kuid kuna renderdusprotsess erineb terminalist terminali, saab seda kasutada ka testikomponendina teiste parameetrite kontrollimiseks.

Siin näeme, et rxvt ja st tõukavad konkurentidest ette, seejärel tuleb palju uuem Alacritty, mis on välja töötatud jõudlusele keskendudes. Järgnevateks on Xfce (VTE perekond) ja Konsole, mis töötavad peaaegu kaks korda kiiremini. Viimasena on xterm, mille tulemus on viis korda aeglasem kui rxvt. Testi käigus kõikus xterm ka tugevalt, liikuv tekst oli raske lugeda, isegi kui see oli sama rida. Konsole osutus kiireks, kuid mõnikord „trikitas“: ekraan seisis aeg-ajalt, näidates teksti osaliselt või mitte näidates seda üldse. Teised terminalid, sealhulgas st, Alacritty ja rxvt, esitasid read selgelt.

Diki selgitab, et jõudluse erinevused on seotud erinevate terminalide kerimisbufferite disainiga. Eelkõige süüdistab ta rxvt-d ja teisi terminale selles, et nad „ei järgi üldisi reegleid“:

„Erinevalt xtermist ei püüdnud rxvt kuvada kõiki uuendusi. Kui ta jäi maha, loobus ta mõnest uuendusest, et järele jõuda. See mõjutas rohkem näilist kerimiskiirus, kui sisemiste mälude korraldamine. Ühe miinusena oli ASCII animatsioon veidi ebatäpne.“

Selle näiliselt aeglase xterm'i parandamiseks soovitab Diki kasutada ressurssi fastScroll, mis võimaldab xterm'il ekraani mõned uuendused kõrvaldada, et mitte jääda voost maha. Minu testid kinnitavad, et fastScroll parandab jõudlust ja viib xterm'i rxvt tasemele. Kuid see on üsna kark, nagu Diki ise selgitab: „mõnikord xterm - nagu ka konsole - näib seisvat, kuna ta ootab uut ekraaniuuenduste komplekti pärast seda, kui mõned neist on eemaldatud“. Sellega seoses tundub, et teised terminalid on leidnud parima kompromissi kiirus ja ekraani terviklikkuse vahel.

Ressursitarbimine

Olenemata selle praktikalisusest, kas käimise kiirus on jõudlusnäitaja, võimaldab see test simuleerida koormust terminalides, mis omakorda võimaldab meil mõõta teisi parameetreid, nagu mälu- või ketta kasutamine. mõõdikud saadi antud testi käivitamisega seq Python protsessi jälgimise all. See kogus loendurite andmeid getrusage () jaoks ru_maxrss, summa ru_oublock ja ru_inblock ja lihtne ajataimer.

Selles testis saavutab ST esikoha, tarbides keskmiselt vaid 8 MB mälu, mis pole üllatav, arvestades, et projekti põhidee on lihtsus. Veidi rohkem vajavad mlterm, xterm ja rxvt — umbes 12 MB. Märkimisväärne tulemus on ka Alacritty, mille tööks on vaja 30 MB. Järgmistena on VTE perekonna terminalid, mille näitajad ulatuvad 40-60 MB-ni, mis on üsna palju. Sellist tarbimist saab seletada sellega, et need terminalid kasutavad kõrgema taseme teeke, nagu GTK. Konsole on viimane, tarbides testide ajal hiiglaslikku 65 MB mälu, kuigi seda saab õigustada selle üsna ulatusliku funktsioonide kogumiga.

Võrreldes kümne aasta taguste tulemustega on kõik programmid hakkanud tarbima märgatavalt rohkem mälu. Varem nõudis Xterm 4 MB, nüüd aga 15 MB lihtsalt käivitamiseks. Sarnane tarbimise tõus on ka rxvt-l, mis nõuab nüüd kastist välja tulles 16 MB. Xfce terminal kulutab 34 MB, mis on kolm korda rohkem kui varem, samas GNOME Terminal nõuab vaid 20 MB. Muidugi viidi kõik eelnevad testid läbi 32-bitise arhitektuuri peal. LCA 2012 Rasti Russell rääkis, on palju peenemaid põhjuseid, mis võivad selgitada mälu tarbimise kasvu. Sellegipoolest elame nüüd ajal, mil meil on terveid gigabaite mälu, nii et me saame sellega hakkama.

Küll aga ei saa ma rahuldust, et sellise fundamentaalse tarkvara nagu terminal jaoks suurema mälu eraldamine on ressursside raiskamine. Need programmid peaksid olema väiksemad kui kõige väiksemad, olema võimelised töötama igasugustes "karpidest", isegi kingakarbid, kui peaksime kunagi jõudma selleni, et neid tuleb varustada Linuxi süsteemidega (ja teate, et see nii ka on). Selliste numbritega muutub mälu kasutamine tulevikus probleemiks igas keskkonnas mitme terminali käivitamisel, välja arvatud olukordades, kus on mitu kõige kergemat ja piiratud võimalustega. Selle kompenseerimiseks on GNOME Terminalil, Konsole'il, urxvt-l, Terminatoril ja Xfce Terminalil Deemon-režiim, mis võimaldab hallata mitmeid terminale ühe protsessi kaudu, piirates nende mälu tarbimist.

Testide käigus jõudsin ma veel ühe ootamatu tulemuse juurde seoses ketta lugemise ja kirjutamisega: ootasin, et siin ei näe ma üldse midagi, kuid selgus, et mõned terminalid kirjutavad kõige mahukamaid andmeid kettale. Nii hoiab VTE teek tegelikult kettal kerimispuud; see omadus oli märgatud juba 2010. aastal, ja see toimub siiani). Kuid erinevalt vanadest teostustest on nüüd, vähemalt, need andmed AES256 GCM abil krüpteeritud (versioonist 0.39.2). Kuid tekib põhjendatud küsimus, mis on siis niivõrd erilist biblioteegis VTE, et see nõuab sellist ebastandardset lähenemist…

Kokkuvõte

Artikli esimeses osas avastasime, et VTE-baasil terminalidel on hea funktsioonide kogum, kuid nüüd näeme, et see on seotud mõningate kuludega nende soorituse tagamiseks. Praegu ei ole mälu probleemiks, kuna kõiki VTE-terminalide saab hallata Daemon-protsessi kaudu, mis piirab nende isu. Siiski võivad vanad süsteemid, millel on füüsilised piirangud operatiivmälu ja tuuma vahemälu kogusele, endiselt vajada varasemaid terminalide versioone, kuna need tarbivad oluliselt vähem ressursse. Kuigi VTE-terminalid on osutunud hästi läbilaskevõimetest (kerimine) testides, on nende andmete kuvamise viivitus ekraanil kõrgem kui GNOME-i kasutusjuhendi kehtestatud lävi. Tõenäoliselt peaksid VTE arendajad seda arvesse võtma. Arvestades, et isegi algajatele Linuxi kasutajatele on terminaliga kohtumine vältimatu, võiksid nad muuta selle kasutajasõbralikumaks. Kogenud geekide jaoks võib vaikimisi terminalilt üleminek tähendada isegi koormuse vähenemist silmadele ja võimalust vältida tulevasi ametikahjustusi ja -haigusi pikaajaliste tööseansside tõttu. Kahjuks toovad meid vaid vanad xterm ja mlterm maagilise 10 millisekundi pingi lävepunkti, mis on paljudele vastuvõetamatu.

Kontrollmõõtmised näitasid ka, et Linuxi graafiliste keskkondade arengu tõttu pidid arendajad tegema mitu kompromissi. Mõned kasutajad peaksid vaatama tavapäraseid aknahaldureid, kuna need pakuvad märkimisväärset pingelangust. Kahjuks ei õnnestunud Waylandi viivitust mõõta: Typometeri programm, mida kasutasin, oli loodud selleks, et Wayland peaks takistama — teiste akende nuhkimist. Lootan, et Waylandi kompositsioon on jõudluselt parem kui X.org, ja loodan ka, et tulevikus leiab keegi viisi selle keskkonna viivituse taseme hindamiseks.

Allikas: habr.com