Keletas žodžių iš mūsų vertimų biuro: dažniausiai visi stengiasi išversti naujausią medžiagą ir publikacijas, ne išimtis ir mes. Tačiau terminalai nėra atnaujinami kartą per savaitę. Todėl išvertėme jums 2018 metų pavasarį paskelbtą Antoine'o Beaupré straipsnį: nepaisant nemažo „amžiaus“ pagal šiuolaikinius standartus, mūsų nuomone, medžiaga neprarado savo aktualumo. Be to, iš pradžių tai buvo dviejų straipsnių serija, tačiau nusprendėme juos sujungti į vieną didelį įrašą.
Kompiuterių istorijoje terminalai užima ypatingą vietą, tačiau pastaraisiais dešimtmečiais jie buvo priversti išgyventi kartu su komandų eilute, nes grafinės sąsajos tapo visur paplitusios. pakeitė savo , kurios, savo ruožtu, buvo sistemų modifikacijos, pagrįstos perforuotomis kortelėmis ir perjungimo jungikliais. Šiuolaikiniuose platinimuose yra įvairių formų ir spalvų terminalų emuliatoriai. Ir nors daugelis yra patenkinti standartiniu terminalu, kurį suteikia jų darbo aplinka, kai kurie išdidžiai naudojasi egzotiška programine įranga, kad paleistų savo mėgstamą apvalkalą ar teksto rengyklę. Tačiau, kaip matysime iš šio straipsnio, ne visi terminalai buvo sukurti pagal tą patį vaizdą: jie labai skiriasi funkcionalumu, dydžiu ir našumu.
Kai kuriuose terminaluose yra visiškai stebinančių saugumo spragų, be to, dauguma jų turi visiškai kitokias funkcijas – nuo sąsajos su skirtukais palaikymo iki scenarijų. Nors mes , šis straipsnis yra ankstesnės medžiagos atnaujinimas, kuris padės skaitytojams nuspręsti, kurį terminalą naudoti 2018 m. Pirmoje straipsnio pusėje palyginamos savybės, o antroje – vertinamas veikimas.
Štai terminalai, kuriuos peržiūrėjau:
Tai gali būti ne naujausios versijos, nes rašymo metu apsiribojau stabiliomis versijomis, kurias galėjau įdiegti Debian 9 arba Fedora 27. Vienintelė išimtis yra Alacritty. Tai GPU spartintų terminalų palikuonis ir parašytas šiai užduočiai neįprasta ir nauja kalba – Rust. Iš savo apžvalgos neįtraukiau žiniatinklio terminalų (įskaitant tuos, kurie yra ), nes preliminarūs testai parodė itin prastus jų rezultatus.
Unicode palaikymas
Bandymus pradėjau naudodamas „Unicode“ palaikymą. Pirmasis terminalų bandymas buvo parodyti Unicode eilutę iš : „é, Δ, И, ק, م, ๗, あ, 叶, 葉 ir 말“. Šis paprastas testas parodo, ar terminalas gali tinkamai veikti visame pasaulyje. xterm terminalas nerodo arabiško simbolio numatytoje konfigūracijoje:
Pagal numatytuosius nustatymus xterm naudoja klasikinį „fiksuotą“ šriftą, kuris, pasak , turi „didelę Unicode aprėptį nuo 1997 m.“. Šiame šrifte vyksta kažkas, dėl ko simbolis atrodo kaip tuščias rėmelis, ir tik tada, kai teksto šriftas padidinamas iki 20+ taškų, simbolis pagaliau pradedamas rodyti teisingai. Tačiau šis „taisymas“ nutraukia kitų „Unicode“ simbolių rodymą:
Šios ekrano kopijos buvo padarytos naudojant „Fedora 27“, nes ji davė geresnių rezultatų nei „Debian 9“, kur kai kurios senesnės terminalų versijos (ypač mlterm) negalėjo tinkamai apdoroti šriftų. Laimei, vėlesnėse versijose tai buvo ištaisyta.
Dabar atkreipkite dėmesį, kaip eilutė rodoma xterm. Pasirodo, kad simbolis Mem ir sekantis semitas kreiptis į RTL stiliaus scenarijus (), todėl techniškai jie turėtų būti rodomi iš dešinės į kairę. Žiniatinklio naršyklės, pvz., Firefox 57, teisingai tvarko aukščiau pateiktą eilutę. Paprastesnė RTL teksto versija yra žodis "“ hebrajų kalba (). sako taip:
„Daugelis kompiuterių programų negali teisingai parodyti dvikrypčio teksto. Pavyzdžiui, hebrajiškas vardas „Sara“ susideda iš simbolių sin (ש) (jis rodomas dešinėje), tada resh (ר) ir galiausiai jis (ה) (kuris turėtų būti rodomas kairėje).
Daugelis terminalų šio testo neatlaiko: Alacritty, VTE gauti Gnome ir XFCE terminalai, urxvt, st ir xterm rodo "Sara" atvirkštine tvarka, tarsi pavadinimą būtume parašę kaip "Aras".
Kita dvikrypčių tekstų problema yra ta, kad juos reikia kažkaip lygiuoti, ypač kai reikia maišyti RTL ir LTR tekstus. RTL scenarijai turėtų paleisti iš dešinės terminalo lango pusės, bet kas turėtų nutikti terminalams, kuriuose numatytasis LTR anglų kalba? Dauguma jų neturi jokių specialių mechanizmų ir lygiuoja visą tekstą į kairę (taip pat ir Konsole). Išimtys yra pterm ir mlterm, kurios laikosi standartų ir lygiuoja tokias eilutes į dešinę.
Apsauga nuo įdėjimo
Kita svarbi funkcija, kurią nustatėu, yra apsauga nuo įterpimo. Nors plačiai žinoma, kad tokie burtai kaip:
$ curl http://example.com/ | shyra kodo vykdymo stūmimo komandos, nedaugelis žino, kad paslėptos komandos gali prasiskverbti į konsolę kopijuojant ir įklijuojant iš interneto naršyklės, net ir po kruopštaus patikrinimo. puikiai parodo, kaip nekenksmingai atrodo komanda:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitvirsta tokiu nepatogumu, kai įklijuota iš Horno svetainės į terminalą:
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.gitKaip tai veikia? Kenkėjiškas kodas įtrauktas į bloką , kuris pašalinamas iš naudotojo rodinio naudojant CSS.
yra aiškiai sukurtas neutralizuoti tokius išpuolius. Šiuo režimu terminalai įklijuotą tekstą įtraukia į porą specialių pabėgimo sekų, kad praneštų apvalkalui apie teksto kilmę. Tai nurodo apvalkalui, kad jis gali nepaisyti specialiųjų simbolių, kurių gali būti įklijuotame tekste. Visi terminalai, grįžtantys į gerbiamą xterm, palaiko šią funkciją, tačiau norint įklijuoti skliaustų režimu, reikalingas terminale veikiančio apvalkalo arba programos palaikymas. Pavyzdžiui, naudojant programinę įrangą (tas pats Bash), reikia failo ~/.inputrc:
set enable-bracketed-paste onDeja, „Horn“ bandymų svetainė taip pat parodo, kaip apeiti šią apsaugą naudojant patį teksto formatavimą ir per anksti jai pritaikyti skliaustų režimą. Tai veikia, nes kai kurie terminalai netinkamai filtruoja pabėgimo sekas prieš pridėdami savo. Pavyzdžiui, manojoje niekada negalėjau sėkmingai užbaigti Konsole testų net ir su teisinga konfigūracija .inputrc failą. Tai reiškia, kad galite lengvai sugadinti sistemos konfigūraciją dėl nepalaikomos programos arba netinkamai sukonfigūruoto apvalkalo. Tai ypač pavojinga prisijungiant prie nuotolinių serverių, kur kruopštus konfigūravimo darbas yra retesnis, ypač jei turite daug tokių nuotolinių mašinų.
Geras šios problemos sprendimas yra terminalo įklijavimo patvirtinimo papildinys urxvt, kuri tiesiog prašo leidimo įterpti bet kokį tekstą, kuriame yra naujų eilučių. Horno aprašytai teksto atakai saugesnio varianto neradau.
Skirtukai ir profiliai
Šiuo metu populiari funkcija yra sąsajos su skirtukais palaikymas, kurį apibūdinsime kaip vieną terminalo langą, kuriame yra keli kiti terminalai. Ši funkcija skirtingiems terminalams skiriasi ir nors tradiciniai xterm terminalai iš viso nepalaiko skirtukų, modernesni terminalų įsikūnijimai, tokie kaip Xfce Terminal, GNOME Terminal ir Konsole, turi šią funkciją. Urxvt taip pat palaiko skirtukus, bet tik tuo atveju, jei naudojate papildinį. Tačiau kalbant apie patį skirtukų palaikymą, „Terminator“ yra neabejotinas lyderis: jis ne tik palaiko skirtukus, bet ir gali išdėstyti terminalus bet kokia tvarka (žr. paveikslėlį žemiau).
Kita „Terminator“ ypatybė yra galimybė „sugrupuoti“ šiuos skirtukus ir tuo pačiu metu siųsti tuos pačius klavišų paspaudimus į kelis terminalus, o tai yra neapdorotas įrankis, leidžiantis vienu metu atlikti masines operacijas keliuose serveriuose. Panaši funkcija taip pat įdiegta Konsole. Norėdami naudoti šią funkciją kituose terminaluose, turite naudoti trečiosios šalies programinę įrangą, pvz , arba .
Skirtukai ypač gerai veikia, kai yra susieti su profiliais: pavyzdžiui, galite turėti vieną skirtuką el. paštui, kitą – pokalbiams ir pan. Tai gerai palaiko Konsole terminalas ir GNOME terminalas. Abu leidžia kiekvienam skirtukui automatiškai paleisti savo profilį. Terminatorius taip pat palaiko profilius, bet nepavyko rasti būdo, kaip automatiškai paleisti tam tikras programas, kai atidarote konkretų skirtuką. Kiti terminalai apskritai neturi „profilio“ sąvokos.
Raukiniai
Paskutinis dalykas, kurį aptarsiu pirmoje šio straipsnio dalyje, yra terminalų išvaizda. Pavyzdžiui, GNOME, Xfce ir urxvt palaiko skaidrumą, tačiau neseniai atsisakė fono vaizdų palaikymo, todėl kai kurie vartotojai turi pereiti prie terminalo. . Asmeniškai aš tuo džiaugiuosi ir viskas paprasta X šaltiniai, kuris nustato pagrindinį urxvt fono spalvų rinkinį. Tačiau problemų gali kilti ir dėl nestandartinių spalvų temų. Pavyzdžiui, su programomis и , nes jie jau naudoja savo spalvas.
nepalaikė spalvų, o naujos dažnai apsiribodavo 256 spalvų palete. Patyrusiems vartotojams, kurie savo terminalus formuoja sudėtingais būdais, apvalkalo raginimai arba būsenos juostos gali būti erzinantis apribojimas. seka, kurie terminalai palaiko „True Color“. Mano testai patvirtina, kad „st“, „Alacritty“ ir „VTE“ pagrindu veikiantys terminalai puikiai palaiko „True Color“. Kiti terminalai šiuo atžvilgiu nesiseka labai gerai ir, tiesą sakant, net nerodo 256 spalvų. Žemiau galite pamatyti skirtumą tarp True Color palaikymo GNOME terminaluose, st ir xterm, kurie puikiai atlieka šį darbą su savo 256 spalvų palete, ir urxvt, kuris ne tik neatlaiko testo, bet netgi rodo kai kuriuos mirksinčius simbolius vietoj jų.
Kai kurie terminalai taip pat analizuoja tekstą URL šablonams, kad nuorodas būtų galima spustelėti. Tai taikoma visiems VTE gautiems terminalams, o urxvt reikalingas specialus papildinys, kuris pakeistų URL spustelėjus arba naudojant spartųjį klavišą. Kiti terminalai Rodomus URL išbandžiau kitais būdais.
Galiausiai, nauja terminalų tendencija yra slinkties buferio galimybė. Pavyzdžiui, st neturi slinkties buferio; daroma prielaida, kad vartotojas naudos terminalo multiplekserį, pvz., tmux ir .
„Alacritty“ taip pat neturi atgalinio slinkties buferių, tačiau jos palaikymas dėl „plačių atsiliepimų“ šia tema iš vartotojų. Be šių pažangių, kiekvienas mano išbandytas terminalas, kurį radau, palaiko atvirkštinį slinkimą.
Tarpinės sumos
Antroje medžiagos dalyje (originale tai buvo du skirtingi straipsniai – apytiksliai. juosta) palyginsime našumą, atminties naudojimą ir delsą. Tačiau jau dabar matome, kad kai kurie aptariami terminalai turi rimtų trūkumų. Pavyzdžiui, vartotojai, kurie reguliariai dirba su RTL scenarijais, gali norėti apsvarstyti mlterm ir pterm, nes jie geriau atlieka panašias užduotis nei kiti. Konsole taip pat pasirodė gerai. Vartotojai, kurie nedirba su RTL scenarijais, gali pasirinkti ką nors kita.
Kalbant apie apsaugą nuo kenkėjiško kodo įterpimo, urxvt išsiskiria tuo, kad jame įdiegta ypatinga apsauga nuo tokio tipo atakų, kas man atrodo tikrai patogu. Tiems, kurie ieško varpelių ir švilpukų, verta pažvelgti į „Konsole“. Galiausiai verta paminėti, kad VTE yra puiki terminalų bazė, kuri garantuoja spalvų palaikymą, URL atpažinimą ir pan. Iš pirmo žvilgsnio numatytasis terminalas, pateikiamas su jūsų mėgstama aplinka, gali atitikti visus reikalavimus, tačiau palikime šį klausimą atvirą, kol suprasime našumą.
Tęskime pokalbį
Apskritai, terminalų veikimas pats savaime gali atrodyti kaip toli nulemta problema, tačiau, kaip paaiškėjo, kai kurie iš jų pasižymi stebėtinai dideliu tokio pagrindinio tipo programinės įrangos delsimu. Taip pat toliau apžvelgsime tai, kas tradiciškai vadinama „greičiu“ (iš tikrųjų tai yra slinkties greitis) ir terminalo atminties suvartojimą (su įspėjimu, kad šiandien tai nėra tokia svarbi, kaip prieš dešimtmečius).
Atidėti
Nuodugniai ištyręs terminalo veikimą, padariau išvadą, kad šiuo atžvilgiu svarbiausias parametras yra delsa (ping). Savo straipsnyje Pavelas Fatinas pažvelgė į įvairių teksto redaktorių delsą ir užsiminė, kad terminalai šiuo atžvilgiu gali būti lėtesni nei greičiausi teksto rengyklės. Būtent ši užuomina galiausiai paskatino mane atlikti savo testus ir parašyti šį straipsnį.
Bet kas yra delsa ir kodėl ji tokia svarbi? Savo straipsnyje Fatinas tai apibrėžė kaip „delsą nuo klavišo paspaudimo iki atitinkamo ekrano atnaujinimo“ ir pacitavo , kuriame teigiama: „Vizualinio grįžtamojo ryšio kompiuterio ekrane vėlavimas turi didelę įtaką mašininkės elgesiui ir pasitenkinimui“.
Fatinas aiškina, kad šis ping turi gilesnių pasekmių nei vien pasitenkinimas: „spausdinimas tampa lėtesnis, atsiranda daugiau klaidų, didėja akių ir raumenų įtampa“. Kitaip tariant, didelis delsimas gali sukelti rašybos klaidas ir taip pat prastesnę kodo kokybę, nes dėl to smegenims atsiranda papildoma pažinimo apkrova. Tačiau dar blogiau yra tai, kad ping „padidina akių ir raumenų įtampą“, o tai rodo ateityje (Matyt, autorius turi omenyje akių, nugaros, rankų raumenų ir, žinoma, regėjimo problemas – apytiksliai. juosta) dėl pasikartojančio streso.
Kai kurie iš šių poveikių buvo žinomi ilgą laiką, o rezultatai 1976 m. žurnale Ergonomics paskelbtame straipsnyje teigiama, kad 100 milisekundžių delsimas „labai pablogina spausdinimo greitį“. Visai neseniai buvo pristatytas GNOME vartotojo vadovas per 10 milisekundžių, o jei eisite toliau, tada rodo, kad 1 milisekundė yra ideali.
Fatinas atliko savo testus teksto rengyklėse; jis sukūrė nešiojamą instrumentą, vadinamą , kurį naudojau bandydamas ping terminalų emuliatoriuose. Turėkite omenyje, kad testas buvo atliktas modeliavimo režimu: iš tikrųjų turime atsižvelgti tiek į įvesties (klaviatūra, USB valdiklis ir kt.), tiek išvesties (vaizdo plokštės buferis, monitorius) delsą. Pasak Fatino, tipinėse konfigūracijose tai yra apie 20 ms. Jei turite žaidimų įrangą, šį skaičių galite pasiekti vos per 3 milisekundes. Kadangi jau turime tokią greitą aparatinę įrangą, programai nereikia pridėti savo delsos. Fatino tikslas yra sumažinti programos delsą iki 1 milisekundės arba net pasiekti, kad rinkimas būtų be jo , kaip .
Štai mano matavimų rezultatai, taip pat kai kurie Fatino rezultatai, rodantys, kad mano eksperimentas sutampa su jo bandymais:
Pirmas dalykas, kuris mane sužavėjo, buvo geresnis senesnių programų, tokių kaip xterm ir mlterm, atsako laikas. Turėdami blogiausią registro delsą (2,4 ms), jie veikė geriau nei greičiausias modernus terminalas (10,6 ms st). Nė vienas modernus terminalas nenukrenta žemiau 10 milisekundžių slenksčio. Visų pirma, „Alacritty“ neatitinka „greičiausio galimo terminalo emuliatoriaus“ reikalavimo, nors jo rezultatai pagerėjo nuo pirmosios peržiūros 2017 m. Išties, projekto autoriai ir stengiasi patobulinti ekraną. Taip pat reikėtų pažymėti, kad „Vim“, naudojanti GTK3, yra daug lėtesnis nei jo GTK2 atitikmuo. Iš to galime daryti išvadą, kad GTK3 sukuria papildomą delsą, ir tai atsispindi visuose kituose jį naudojančiuose terminaluose (Terminatorius, Xfce4 terminalas ir GNOME terminalas).
Tačiau skirtumai gali būti nepastebimi akiai. Kaip aiškina Fatinas, „jūs neturite žinoti apie vėlavimą, kad jis jus paveiktų“. Fatinas taip pat perspėja apie standartinį nuokrypį: „bet kokie delsos sutrikimai (drebėjimas) sukelia papildomą stresą dėl jų nenuspėjamumo“.
Aukščiau pateikta diagrama paimta naudojant gryną Debian 9 (ištemptą) su . Ši aplinka duoda geriausius delsos testų rezultatus. Kaip paaiškėjo, GNOME sukuria papildomą 20 ms ping visiems matavimams. Galimas to paaiškinimas yra programų su sinchroniniu įvesties įvykių apdorojimu buvimas. Fatinas pateikia tokio atvejo pavyzdį , kuris prideda delsą apdorojant visus įvesties įvykius sinchroniškai. Pagal numatytuosius nustatymus GNOME taip pat yra su langų tvarkykle , kuris sukuria papildomą buferio sluoksnį, kuris veikia ping ir prideda mažiausiai 8 milisekundžių delsos.
Slinkties greitis
Kitas testas yra tradicinis „greičio“ arba „pralaidumo“ testas, kuris matuoja, kaip greitai terminalas gali slinkti puslapiu, ekrane rodydamas didelius teksto kiekius. Bandymo mechanika skiriasi; pradinis bandymas buvo tiesiog sugeneruoti tą pačią teksto eilutę naudojant komandą seq. Kiti testai apima Thomas E. Dickey (xterm palaikytojo) testą, kuris kartojamas . Kitoje terminalo veikimo apžvalgoje naudoja base32 koduotą atsitiktinių baitų eilutę, kuri išvedama į terminalą naudojant cat. Luu mano, kad toks testas yra „toks nenaudingas etalonas, kokį galima įsivaizduoti“ ir siūlo naudoti terminalo atsaką kaip pagrindinę metriką. Dickey savo testą taip pat vadina klaidinančiu. Tačiau abu autoriai pripažįsta, kad terminalo lango pralaidumas gali būti problema. Luu atrado, kad „Emacs Eshell“ užstringa rodant didelius failus, o Dickey optimizavo terminalą, kad atsikratytų „xtrerm“ vaizdo vangumo. Taigi šis testas vis dar turi tam tikrų pranašumų, tačiau kadangi atvaizdavimo procesas labai skiriasi įvairiuose terminaluose, jis taip pat gali būti naudojamas kaip bandomasis komponentas kitiems parametrams išbandyti.
Čia matome, kad „rxvt“ ir „st“ traukia prieš konkurentus, o po to seka daug naujesnis „Alacritty“, kuris sukurtas daugiausia dėmesio skiriant našumui. Toliau rikiuojasi Xfce (VTE šeima) ir Konsole, kurios yra beveik dvigubai greitesnės. Paskutinis yra xterm, kuris yra penkis kartus lėtesnis nei rxvt. Bandymo metu xterm taip pat labai raibuliavo, todėl perduodamą tekstą sunku pamatyti, net jei tai buvo ta pati eilutė. „Konsole“ buvo greita, tačiau kartais buvo sudėtinga: ekranas retkarčiais užšaldavo, rodydamas dalinį tekstą arba jo visai nerodydamas. Kiti terminalai aiškiai rodė eilutes, įskaitant st, Alacrtty ir rxvt.
Dickey paaiškina, kad našumo skirtumai atsiranda dėl skirtingų terminalų slinkties buferių konstrukcijos. Visų pirma, jis kaltina „rxvt“ ir kitus terminalus „bendrųjų taisyklių nesilaikymu“:
„Skirtingai nei xterm, rxvt nebandė rodyti visų atnaujinimų. Jei jis atsiliks, jis atsisakys kai kurių atnaujinimų. Tai turėjo didesnį poveikį matomam slinkimo greičiui nei vidinės atminties organizavimui. Vienas trūkumas buvo tai, kad ASCII animacija buvo šiek tiek netiksli.
Dickey siūlo naudoti šaltinį, kad ištaisytų šį jaučiamą xterm vangumą , leidžianti „xterm“ atmesti kai kuriuos ekrano naujinimus, kad neatsiliktų nuo srauto. Mano testai patvirtina, kad „fastScroll“ pagerina našumą ir „xterm“ prilygsta „rxvt“. Tačiau tai yra gana grubus ramentas, kaip aiškina pats Dickey: „kartais xterm, kaip ir konsole, stringa, nes laukia naujo ekrano atnaujinimų rinkinio, kai kai kurie bus pašalinti“. Šiuo požiūriu atrodo, kad kiti terminalai rado geriausią kompromisą tarp greičio ir ekrano vientisumo.
Išteklių suvartojimas
Nepriklausomai nuo to, ar prasminga slinkimo greitį laikyti našumo metrika, šis testas leidžia imituoti gnybtų apkrovą, o tai savo ruožtu leidžia išmatuoti kitus parametrus, pvz., atminties ar disko naudojimą. Metrika buvo gauta vykdant nurodytą testą punktai pagal Python proceso stebėjimą. Jis rinko skaitiklio duomenis už ru_maxrss, suma ru_oublock и ru_inblock ir paprastas laikmatis.
Šiame teste ST užima pirmąją vietą su mažiausiu vidutiniu 8 MB atminties suvartojimu, o tai nenuostabu, turint omenyje, kad pagrindinė dizaino idėja yra paprastumas. mlterm, xterm ir rxvt sunaudoja šiek tiek daugiau – apie 12 MB. Kitas pastebimas rezultatas yra „Alacritty“, kuriai paleisti reikia 30 MB. Tada yra VTE šeimos terminalai, kurių skaičiai nuo 40 iki 60 MB, o tai yra gana daug. Tokį suvartojimą galima paaiškinti tuo, kad šie terminalai naudoja aukštesnio lygio bibliotekas, pavyzdžiui, GTK. „Konsole“ yra paskutinė – bandymų metu sunaudojama milžiniška 65 MB atminties, nors tai galima pateisinti labai plačiu funkcijų spektru.
Palyginti su ankstesniais rezultatais, gautais prieš dešimt metų, visos programos pradėjo vartoti pastebimai daugiau atminties. Anksčiau „Xterm“ reikėjo 4 MB, o dabar paleidžiant reikia 15 MB. Panašiai išaugo rxvt suvartojimas, kuriam dabar reikia 16 MB. Xfce terminalas užima 34 MB, o tai yra tris kartus daugiau nei anksčiau, tačiau GNOME terminalui reikia tik 20 MB. Žinoma, visi ankstesni bandymai buvo atlikti naudojant 32 bitų architektūrą. LCA 2012 Rusty Russell , kad yra daug subtilesnių priežasčių, galinčių paaiškinti atminties suvartojimo padidėjimą. Tai pasakius, dabar gyvename laikais, kai turime gigabaitų atminties, tad kaip nors susitvarkysime.
Tačiau negaliu nejausti, kad daugiau atminties skyrimas tokiam esminiam dalykui kaip terminalas yra išteklių švaistymas. Šios programos turėtų būti mažiausios iš mažiausių, turėtų veikti bet kurioje „dėžutėje“, net batų dėžėje, jei kada nors pasieksime iki taško, kad jose reikės įdiegti „Linux“ sistemas (ir jūs žinote, kad taip bus ). Tačiau atsižvelgiant į šiuos skaičius, atminties naudojimas ateityje taps problema bet kurioje aplinkoje, kurioje veikia keli terminalai, išskyrus kelis lengviausius ir ribotiausius pajėgumus. Norėdami tai kompensuoti, GNOME terminalas, Konsole, urxvt, Terminator ir Xfce terminalas turi demono režimą, kuris leidžia valdyti kelis terminalus vienu procesu, ribojant jų atminties suvartojimą.
Bandymų metu gavau dar vieną netikėtą disko skaitymo-rašymo rezultatą: tikėjausi, kad čia nieko nematysiu, bet paaiškėjo, kad kai kurie terminalai į diską įrašo didžiausius duomenis. Taigi, VTE biblioteka iš tikrųjų saugo slinkties buferį diske (ši funkcija , ir tai vis dar vyksta). Tačiau skirtingai nuo senesnių diegimų, dabar bent jau šie duomenys yra užšifruoti naudojant AES256 GCM (). Tačiau kyla pagrįstas klausimas: kuo ypatinga VTE biblioteka, kad reikia tokio nestandartinio požiūrio į diegimą...
išvada
Pirmoje straipsnio dalyje nustatėme, kad VTE pagrįsti terminalai turi gerą funkcijų rinkinį, tačiau dabar matome, kad tai apima tam tikras našumo išlaidas. Dabar atmintis nėra problema, nes visi VTE terminalai gali būti valdomi naudojant demono procesą, kuris riboja jų apetitą. Tačiau senesnėms sistemoms, turinčioms fizinius RAM kiekio ir branduolio buferių apribojimus, vis tiek gali prireikti ankstesnių terminalų versijų, nes jos sunaudoja žymiai mažiau išteklių. Nors VTE terminalai gerai atliko pralaidumo (slinkimo) testus, jų rodymo delsa viršija GNOME vartotojo vadove nustatytą slenkstį. VTE kūrėjai tikriausiai turėtų į tai atsižvelgti. Jei atsižvelgsime į tai, kad net pradedantiesiems Linux naudotojams susidurti su terminalu yra neišvengiama, jie gali padaryti jį patogesnį. Patyrusiems geekams perjungimas iš numatytojo terminalo netgi gali reikšti mažesnį akių įtampą ir galimybę ateityje išvengti su darbu susijusių traumų ir ligų dėl ilgų darbo seansų. Deja, tik senieji xterm ir mlterm atveda mus prie stebuklingo 10 milisekundžių ping slenksčio, o tai daugeliui nepriimtina.
Lyginamieji matavimai taip pat parodė, kad dėl Linux grafinės aplinkos kūrimo kūrėjai turėjo padaryti daugybę kompromisų. Kai kurie vartotojai gali norėti pažvelgti į įprastas langų tvarkykles, nes jos žymiai sumažina ping. Deja, Wayland delsos išmatuoti nepavyko: mano naudojama programa Typometer buvo sukurta tam, kad būtų išvengta Wayland: šnipinėjimo kituose languose. Tikiuosi, kad „Wayland“ komponavimas veikia geriau nei X.org, taip pat tikiuosi, kad ateityje kas nors ras būdą, kaip išmatuoti delsą šioje aplinkoje.
Šaltinis: www.habr.com