Nokkur orð frá þýðingarskrifstofunni okkar: vanalega leggja allir sig fram við að þýða nýjustu efni og rit og við erum engin undantekning. En útstöðvar eru ekki eitthvað sem er uppfært einu sinni í viku. Þess vegna höfum við þýtt fyrir þig grein eftir Antoine Beaupré, sem gefin var út vorið 2018: þrátt fyrir töluverðan „aldur“ á nútíma mælikvarða hefur efnið að okkar mati alls ekki glatað mikilvægi sínu. Auk þess var þetta upphaflega röð tveggja greina en við ákváðum að sameina þær í eina stóra færslu.
Útstöðvar skipa sérstakan sess í tölvusögunni en á síðustu áratugum hafa þær neyðst til að lifa af samhliða skipanalínunni þar sem grafísk viðmót verða alls staðar nálæg. komið í stað þeirra eigin , sem aftur á móti voru breyting á kerfum sem byggðust á gatakortum og skiptirofum. Nútíma dreifingar koma með ýmsum flugstöðvum af öllum stærðum og litum. Og þó að margir séu ánægðir með stöðluðu flugstöðina sem vinnuumhverfið býður upp á, nota sumir stoltir beinlínis framandi hugbúnað til að keyra uppáhalds skelina sína eða textaritil. En eins og við munum sjá úr þessari grein, voru ekki allar skautanna búnar til í sömu mynd: þeir eru mjög mismunandi hvað varðar virkni, stærð og frammistöðu.
Sumar útstöðvar hafa beinlínis óvæntar öryggisgöt, auk þess sem flestar hafa allt annað sett af aðgerðum, allt frá stuðningi við flipaviðmót til forskrifta. Þó við , þessi grein er uppfærsla á fyrra efni sem mun hjálpa lesendum að ákvarða hvaða flugstöð á að nota árið 2018. Fyrri helmingur greinarinnar ber saman eiginleika og seinni helmingurinn metur árangur.
Hér eru skautanna sem ég skoðaði:
Þetta eru kannski ekki nýjustu útgáfurnar, þar sem ég var takmarkaður við stöðugar byggingar þegar þetta var skrifað, sem ég gat sett út á Debian 9 eða Fedora 27. Eina undantekningin er Alacritty. Það er afkomandi GPU-hröðunar skautanna og er skrifað á óvenjulegu og nýju tungumáli fyrir þetta verkefni - Ryð. Ég útilokaði vefútstöðvar frá skoðun minni (þar á meðal þær sem eru á ), vegna þess að forprófanir sýndu afar lélega frammistöðu þeirra.
Unicode stuðningur
Ég byrjaði prófin mín með Unicode stuðningi. Fyrsta prófið á skautunum var að sýna Unicode strenginn frá : "é, Δ, И, K, م, ๗, あ, 叶, 葉 og 말." Þetta einfalda próf sýnir hvort flugstöðin geti starfað rétt um allan heim. xterm terminal sýnir ekki arabíska staf í sjálfgefna stillingu:
Sjálfgefið er að xterm notar klassískt "fast" leturgerð, sem skv , hefur "verulega Unicode umfjöllun síðan 1997". Það er eitthvað að gerast í þessu letri sem veldur því að stafurinn birtist sem auður rammi og það er aðeins þegar texta leturgerð er aukin í 20+ punkta sem stafurinn fer loksins að birtast rétt. Hins vegar brýtur þessi „leiðrétting“ birtingu annarra Unicode-stafa:
Þessar skjámyndir voru teknar í Fedora 27, þar sem það gaf betri niðurstöður en Debian 9, þar sem sumar eldri útgáfur af útstöðvum (sérstaklega mlterm) réðu ekki við leturgerðir almennilega. Sem betur fer var þetta lagað í síðari útgáfum.
Taktu nú eftir hvernig línan birtist í xterm. Það kemur í ljós að táknið Mem og eftirfarandi Semitic vísa til forskrifta í RTL stíl (), þannig að tæknilega séð ættu þær að birtast frá hægri til vinstri. Vefvafrar eins og Firefox 57 höndla línuna hér að ofan á réttan hátt. Einfaldari útgáfa af RTL texta er orðið "" á hebresku (). segir eftirfarandi:
„Mörg tölvuforrit geta ekki birt tvíátta texta rétt. Til dæmis samanstendur hebreska nafnið „Sarah“ af stöfunum sin (ש) (sem birtist hægra megin), síðan resh (ר) og loks hann (ה) (sem ætti að koma til vinstri).“
Margar skautanna falla í þessu prófi: Alacritty, VTE-afleidd Gnome og XFCE skautanna, urxvt, st og xterm sýna "Sara" í öfugri röð, eins og við hefðum skrifað nafnið sem "Aras".
Annað vandamál með tvíátta texta er að þeir þurfa að vera samræmdir einhvern veginn, sérstaklega þegar kemur að því að blanda saman RTL og LTR texta. RTL forskriftir ættu að keyra frá hægri hlið flugstöðvargluggans, en hvað ætti að gerast fyrir útstöðvar sem sjálfgefið eru LTR ensku? Flest þeirra eru ekki með neina sérstaka aðferð og stilla allan texta til vinstri (þar á meðal í Konsole). Undantekningarnar eru pterm og mlterm, sem fylgja stöðlunum og stilla slíkar línur til hægri.
Innsetningarvörn
Næsti mikilvægi eiginleiki sem ég hef bent á er vörn gegn innsetningu. Þó það sé almennt þekkt að galdrar eins og:
$ curl http://example.com/ | sheru ýtaskipanir fyrir keyrslu kóða, fáir vita að faldar skipanir geta laumast inn í stjórnborðið þegar afritað er og límt úr vafra, jafnvel eftir vandlega skoðun. sýnir á frábæran hátt hversu skaðlaus skipunin er:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitbreytist í svona óþægindi þegar það er límt af vefsíðu Horns inn í flugstöðina:
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.gitHvernig það virkar? Spillikóði er innifalinn í blokkinni , sem er fært úr sjónarhorni notandans með CSS.
er greinilega hannað til að gera slíkar árásir óvirkar. Í þessum ham umlykja skautarnir límda textann í par af sérstökum flóttaröðum til að segja skelinni um uppruna textans. Þetta segir skelinni að hún geti hunsað sérstafi sem límdi textinn gæti innihaldið. Allar útstöðvar aftur á virðulegan xterm styðja þennan eiginleika, en að líma í svigastillingu krefst stuðnings frá skelinni eða forritinu sem keyrir á flugstöðinni. Til dæmis hugbúnaður sem notar (sama Bash), þarf skrá ~/.inputrc:
set enable-bracketed-paste onÞví miður sýnir prófunarsíða Horns einnig hvernig hægt er að komast framhjá þessari vernd í gegnum textasniðið sjálft og endar ótímabært með því að nota svigastillingu á hana. Þetta virkar vegna þess að sumar skautanna sía ekki escape-raðir rétt áður en þær eru bættar við. Til dæmis, í mínum gat ég aldrei lokið Konsole prófunum með góðum árangri jafnvel með rétta uppsetningu .inputrc skrá. Þetta þýðir að þú getur auðveldlega skemmt kerfisstillingar þínar vegna óstudds forrits eða rangt stillt skel. Þetta er sérstaklega hættulegt þegar þú skráir þig inn á ytri netþjóna, þar sem vandlega stillingarvinna er sjaldgæfari, sérstaklega ef þú ert með margar slíkar ytri vélar.
Góð lausn á þessu vandamáli er límstaðfestingarforritið fyrir flugstöðina urxvt, sem einfaldlega biður um leyfi til að setja inn hvaða texta sem inniheldur nýjar línur. Ég hef ekki fundið öruggari valkost fyrir textaárásina sem Horn lýsir.
Flipar og snið
Vinsæll eiginleiki núna er stuðningur við flipaviðmót, sem við munum skilgreina sem einn flugstöðvarglugga sem inniheldur nokkrar aðrar útstöðvar. Þessi aðgerð er mismunandi eftir mismunandi útstöðvum, og þó hefðbundnar xterm útstöðvar styðji alls ekki flipa, hafa nútímalegri útstöðvar eins og Xfce Terminal, GNOME Terminal og Konsole þessa aðgerð. Urxvt styður einnig flipa, en aðeins ef þú notar viðbót. En hvað varðar flipastuðning sjálfan, þá er Terminator óumdeildur leiðtogi: hann styður ekki aðeins flipa, heldur getur hann einnig raðað útstöðvum í hvaða röð sem er (sjá mynd hér að neðan).
Annar eiginleiki Terminator er hæfileikinn til að "flokka" þessa flipa saman og senda sömu ásláttirnar til margra útstöðva á sama tíma, sem gefur gróft tól til að framkvæma magnaðgerðir á mörgum netþjónum samtímis. Svipaður eiginleiki er einnig útfærður í Konsole. Til að nota þennan eiginleika í öðrum útstöðvum verður þú að nota hugbúnað frá þriðja aðila eins og , eða .
Flipar virka sérstaklega vel þegar þeir eru paraðir við prófíla: til dæmis geturðu haft einn flipa fyrir tölvupóst, annan fyrir spjall, og svo framvegis. Þetta er vel stutt af Konsole Terminal og GNOME Terminal. Báðir leyfa hverjum flipa að ræsa sinn eigin prófíl sjálfkrafa. Terminator styður einnig snið, en ég gat ekki fundið leið til að ræsa ákveðin forrit sjálfkrafa þegar þú opnar ákveðinn flipa. Aðrar útstöðvar hafa alls ekki hugtakið „snið“.
Rúfur
Það síðasta sem ég mun fjalla um í fyrri hluta þessarar greinar er útlit skautanna. Til dæmis styðja GNOME, Xfce og urxvt gagnsæi, en hafa nýlega sleppt stuðningi við bakgrunnsmyndir, sem neyða sumir notendur til að skipta yfir í flugstöðina . Persónulega er ég ánægður með það og það er einfalt Xheimildir, sem setur grunnsett bakgrunnslita fyrir urxvt. Hins vegar geta óstöðluð litaþemu einnig skapað vandamál. Til dæmis, með umsóknum и , þar sem þeir nota nú þegar sína eigin liti.
studdu ekki liti og nýir voru oft takmarkaðir við 256 lita litatöflu. Fyrir háþróaða notendur sem stíla útstöðvar sínar geta skeljatilkynningar eða stöðustikur á flókinn hátt verið pirrandi takmörkun. lög sem eru með „True Color“ stuðning. Prófanir mínar staðfesta að st, Alacritty og VTE-undirstaða skautanna styðja True Color fullkomlega. Aðrar útstöðvar standa sig ekki vel hvað þetta varðar og sýna reyndar ekki einu sinni 256 liti. Hér að neðan má sjá muninn á True Color stuðningi í GNOME skautunum, st og xterm, sem gera þetta vel með 256 litaspjaldinu sínu, og urxvt, sem ekki bara stenst prófið, heldur sýnir jafnvel nokkra blikkandi stafi í staðinn.
Sumar útstöðvar greina einnig texta fyrir vefslóðamynstur til að gera tengla smellanlega. Þetta á við um allar VTE-afleiddar skautanna, á meðan urxvt krefst sérstakrar tappi sem myndi breyta vefslóðum með því að smella eða nota flýtilykla. Aðrar útstöðvar sem ég hef prófað birtingarslóðir á annan hátt.
Að lokum, ný stefna í útstöðvum er valmöguleikinn á flettabuffi. Til dæmis, st hefur engin fletta biðminni; það er gert ráð fyrir að notandinn noti terminal multiplexer eins og tmux og .
Alacritty skortir líka bakfletunarbuffa, en stuðningur þess vegna „viðamikilla viðbragða“ um þetta efni frá notendum. Burtséð frá þessum uppátækjum styður hver flugstöð sem ég hef prófað sem ég gæti fundið öfuga skrun.
Undirliðar
Í seinni hluta efnisins (í frumritinu voru þetta tvær ólíkar greinar - ca. braut) við munum bera saman árangur, minnisnotkun og leynd. En við sjáum nú þegar að sumir af umræddum skautstöðvum hafa alvarlega annmarka. Til dæmis gætu notendur sem vinna reglulega með RTL forskriftir viljað íhuga mlterm og pterm, þar sem þeir eru betri í að sinna svipuðum verkefnum en aðrir. Konsole stóð sig líka vel. Notendur sem vinna ekki með RTL forskriftir geta valið eitthvað annað.
Hvað varðar vernd gegn innsetningu skaðlegra kóða, þá skera urxvt sig úr vegna sérstakra útfærslu á vörn gegn þessari tegund af árásum, sem mér virðist örugglega þægilegt. Fyrir þá sem eru að leita að bjöllum og flautum er Konsole þess virði að skoða. Að lokum er rétt að taka fram að VTE er frábær grunnur fyrir útstöðvar, sem tryggir litastuðning, vefslóðaþekkingu og svo framvegis. Við fyrstu sýn gæti sjálfgefna flugstöðin sem fylgir uppáhaldsumhverfinu þínu uppfyllt allar kröfur, en við skulum skilja þessa spurningu eftir opna þar til við skiljum árangurinn.
Höldum samtalinu áfram
Almennt séð getur frammistaða útstöðva í sjálfu sér virst vera langsótt vandamál, en eins og það kemur í ljós sýna sumar þeirra furðu mikla leynd fyrir hugbúnað af slíkri grundvallartegund. Næst munum við líka skoða það sem venjulega er kallað „hraði“ (reyndar er þetta skrunhraði) og minnisnotkun flugstöðvarinnar (með þeim fyrirvara að þetta er ekki eins mikilvægt í dag og það var fyrir áratugum).
Töf
Eftir ítarlega rannsókn á lokaafköstum komst ég að þeirri niðurstöðu að mikilvægasta færibreytan í þessu sambandi er leynd (ping). Í grein sinni Pavel Fatin skoðaði leynd ýmissa textaritla og gaf í skyn að útstöðvar í þessum efnum gætu verið hægari en hraðvirkustu textaritlar. Það var þessi vísbending sem að lokum leiddi mig til að keyra mín eigin próf og skrifa þessa grein.
En hvað er leynd og hvers vegna er það svo mikilvægt? Í grein sinni skilgreindi Fatin það sem „töf milli þess að ýta á takka og samsvarandi skjáuppfærslu“ og vitnaði í , þar sem segir: „Töfin á sjónrænum endurgjöf á tölvuskjá hefur mikilvæg áhrif á hegðun og ánægju vélritara.“
Fatin útskýrir að þetta ping hafi dýpri afleiðingar en bara ánægju: „innsláttur verður hægari, fleiri villur eiga sér stað og augn- og vöðvaspenna eykst. Með öðrum orðum, mikil seinkun getur leitt til innsláttarvillna og einnig minni kóðagæða, þar sem það leiðir til aukins vitrænnar álags á heilann. En það sem verra er er að ping „eykur álag á augum og vöðvum,“ sem virðist gefa til kynna Í framtíðinni (Greinilega meinar höfundur vandamál með augnvöðva, bak, handleggi og auðvitað sjón - u.þ.b. braut) vegna endurtekinnar streitu.
Sum þessara áhrifa hafa verið þekkt í langan tíma og afleiðingarnar , sem birt var aftur árið 1976 í tímaritinu Ergonomics, sagði að 100 millisekúndur seinkun "skerði verulega innsláttarhraða." Nýlega var GNOME notendahandbókin kynnt á 10 millisekúndum, og ef þú ferð lengra, þá sýnir að 1 millisekúnda er tilvalið.
Fatin framkvæmdi próf sín á textaritlum; hann bjó til flytjanlegt hljóðfæri sem heitir , sem ég notaði til að prófa ping í terminal emulators. Hafðu í huga að prófið var framkvæmt í hermiham: í raun þurfum við að taka tillit til bæði inntaks (lyklaborð, USB stjórnandi, osfrv.) og úttaks (skjákortsbuffi, skjár) leynd. Samkvæmt Fatin, í dæmigerðum stillingum er það um 20 ms. Ef þú ert með leikjabúnað geturðu náð þessari tölu á aðeins 3 millisekúndum. Þar sem við erum nú þegar með svo hraðan vélbúnað þarf forritið ekki að bæta við eigin leynd. Markmið Fatin er að færa biðtíma forritsins í 1 millisekúndu, eða jafnvel ná hringingu án þess , hvernig í .
Hér eru niðurstöður mælinga minna, sem og nokkrar af niðurstöðum Fatins, til að sýna að tilraunin mín sé í samræmi við prófanir hans:
Það fyrsta sem sló mig var betri viðbragðstími eldri forrita eins og xterm og mlterm. Með verstu skráningartímann (2,4 ms), stóðu þeir sig betur en hraðasta nútíma flugstöðin (10,6 ms fyrir st). Engin nútíma flugstöð fellur undir 10 millisekúndna þröskuldinn. Sérstaklega tekst Alacritty ekki að uppfylla kröfur um „hraðasta flugstöðvahermi sem völ er á“, þó að stig hennar hafi batnað frá fyrstu endurskoðun hennar árið 2017. Reyndar höfundar verkefnisins og vinna að því að bæta skjáinn. Það skal líka tekið fram að Vim sem notar GTK3 er stærðargráðu hægari en GTK2 hliðstæða hans. Af þessu getum við dregið þá ályktun að GTK3 skapar viðbótar leynd og það endurspeglast í öllum öðrum útstöðvum sem nota það (Terminator, Xfce4 Terminal og GNOME Terminal).
Hins vegar gæti munurinn ekki verið áberandi fyrir augað. Eins og Fatin útskýrir, "þú þarft ekki að vera meðvitaður um seinkunina til að það hafi áhrif á þig." Fatin varar einnig við staðalfráviki: „allar truflanir á leynd (jitter) skapa aukna streitu vegna ófyrirsjáanlegs þeirra.
Grafið hér að ofan er tekið á hreinu Debian 9 (teygja) með . Þetta umhverfi skilar bestum árangri í leyniprófum. Eins og það kemur í ljós býr GNOME til 20 ms ping til viðbótar fyrir allar mælingar. Hugsanleg skýring á þessu er tilvist forrita með samstilltri vinnslu inntaksatburða. Fatin gefur dæmi um slíkt tilvik , sem bætir við seinkun með því að vinna alla inntaksviðburði samstillt. Sjálfgefið er að GNOME kemur einnig með gluggastjóra , sem býr til viðbótarlag af biðminni, sem hefur áhrif á ping og bætir við að minnsta kosti 8 millisekúndum af leynd.
Skrunahraði
Næsta próf er hefðbundið „hraða“ eða „bandbreidd“ próf, sem mælir hversu hratt flugstöðin getur flett síðu á meðan hún sýnir mikið magn af texta á skjánum. Aflfræði prófsins er mismunandi; Upprunalega prófið var einfaldlega að búa til sama textastreng með því að nota seq skipunina. Önnur próf eru meðal annars próf Thomas E. Dickey (xterm viðhald) sem ítrekað . Í annarri umfjöllun um árangur flugstöðvarinnar notar base32 kóðaðan streng af handahófskenndum bætum, sem er gefið út í flugstöðina með því að nota cat. Luu telur slíkt próf vera "eins gagnslaus viðmið og hægt er að ímynda sér" og leggur til að nota lokasvörun sem aðal mæligildi í staðinn. Dickey kallar prófið sitt villandi. Hins vegar viðurkenna báðir höfundar að bandbreidd flugstöðvarglugga getur verið vandamál. Luu uppgötvaði Emacs Eshell að frjósa þegar stórar skrár voru sýndar og Dickey fínstillti flugstöðina til að losna við sjónræna tregðu xtrerm. Svo það er enn nokkur kostur á þessu prófi, en þar sem flutningsferlið er mjög mismunandi frá flugstöð til enda, getur það einnig verið notað sem prófunarhluti til að prófa aðrar breytur.
Hér sjáum við rxvt og st draga fram úr keppendum, á eftir mun nýrri Alacritty, sem er hannaður með áherslu á frammistöðu. Næst eru Xfce (VTE fjölskylda) og Konsole, sem eru næstum tvöfalt hraðari. Síðastur er xterm, sem er fimm sinnum hægari en rxvt. Meðan á prófinu stóð, fór xterm einnig mikið, sem gerði það að verkum að textasending var erfitt að sjá, jafnvel þótt það væri sama línan. Konsole var hröð, en stundum var hún erfið: skjárinn frjós af og til, sýndi texta að hluta eða sýndi hann alls ekki. Aðrar útstöðvar sýndu strengi greinilega, þar á meðal st, Alacritty og rxvt.
Dickey útskýrir að munurinn á afköstum stafar af hönnun skrollbjóðra í mismunandi skautum. Sérstaklega sakar hann rxvt og aðrar útstöðvar um að „fylgja ekki almennum reglum“:
„Ólíkt xterm reyndi rxvt ekki að birta allar uppfærslur. Ef það verður á eftir mun það neita einhverjum uppfærslum til að ná sér. Þetta hafði meiri áhrif á sýnilegan skrunhraða en á skipulag innra minnis. Einn galli var að ASCII hreyfimyndin var nokkuð ónákvæm.“
Til að laga þessa áleitnu tregðu, mælir Dickey með því að nota auðlindina , sem gerir xterm kleift að henda nokkrum skjáuppfærslum til að fylgjast með flæðinu. Prófanir mínar staðfesta að fastScroll bætir árangur og kemur xterm á pari við rxvt. Þetta er hins vegar frekar gróf hækja, eins og Dickey útskýrir sjálfur: "stundum virðist xterm - eins og konsole - staðna þar sem það bíður eftir nýju setti af skjáuppfærslum eftir að sumar hafa verið fjarlægðar." Í þessum dúr virðist sem aðrar skautanna hafi fundið bestu málamiðlunina milli hraða og skjáheilleika.
Auðlindanotkun
Burtséð frá því hvort skynsamlegt sé að líta á skrunhraða sem frammistöðumælingu, þá gerir þetta próf okkur kleift að líkja eftir álagi á skautunum, sem aftur gerir okkur kleift að mæla aðrar breytur eins og minni eða disknotkun. Mælingarnar voru fengnar með því að keyra tilgreint próf NÚMER undir Python ferlivöktun. Hann safnaði mæligögnum í ru_maxrss, magn ru_oublock и ru_inblock og einfaldur teljari.
Í þessu prófi er ST í fyrsta sæti með lægstu meðalminnisnotkunina 8 MB, sem kemur ekki á óvart miðað við að meginhugmynd hönnunarinnar er einfaldleiki. mlterm, xterm og rxvt eyða aðeins meira - um 12 MB. Önnur athyglisverð niðurstaða er Alacritty, sem þarf 30 MB til að keyra. Svo eru útstöðvar af VTE fjölskyldunni með tölum frá 40 til 60 MB, sem er frekar mikið. Þessa neyslu má skýra með því að þessar skautanna nota bókasöfn á hærra stigi, til dæmis GTK. Konsole kemur í síðasta sæti með heila 65MB af minnisnotkun meðan á prófunum stendur, þó að það sé hægt að réttlæta með mjög breitt úrval af eiginleikum.
Samanborið við fyrri niðurstöður sem fengust fyrir tíu árum síðan fóru öll forrit að eyða áberandi meira minni. Xterm þurfti áður 4 MB, en núna þarf það 15 MB bara við ræsingu. Svipuð aukning er í neyslu fyrir rxvt, sem þarf nú 16 MB úr kassanum. Xfce Terminal tekur 34 MB, sem er þrisvar sinnum stærra en áður, en GNOME Terminal þarf aðeins 20 MB. Auðvitað voru allar fyrri prófanir gerðar á 32-bita arkitektúr. Á LCA 2012 Rusty Russell , að það eru margar lúmskari ástæður sem gætu skýrt aukna minnisnotkun. Að þessu sögðu lifum við núna á tímum þar sem við erum með gígabæt af minni, þannig að okkur tekst einhvern veginn.
Hins vegar get ég ekki annað en fundið að það að úthluta meira minni í eitthvað jafn grundvallaratriði og flugstöðina sé sóun á auðlindum. Þessi forrit ættu að vera minnstu af þeim minnstu, ættu að geta keyrt á hvaða „kassa“ sem er, jafnvel skókassa, ef við komum einhvern tíma á þann stað að þau þurfi að vera búin Linux kerfum (og þú veist að það verður svo ). En með þessum tölum mun minnisnotkun verða vandamál í framtíðinni í hvaða umhverfi sem keyrir margar útstöðvar aðrar en nokkrar af þeim léttustu og takmörkuðustu í getu. Til að bæta upp fyrir þetta eru GNOME Terminal, Konsole, urxvt, Terminator og Xfce Terminal með Púkaham sem gerir þér kleift að stjórna mörgum útstöðvum í gegnum eitt ferli, sem takmarkar minnisnotkun þeirra.
Í prófunum mínum komst ég að annarri óvæntri niðurstöðu varðandi lestur og ritun disks: Ég bjóst við að sjá alls ekkert hér, en það kom í ljós að sumar útstöðvar skrifa fyrirferðarmestu gögnin á diskinn. Svo, VTE bókasafnið geymir í raun og veru flettabuffi á disknum (þessi eiginleiki , og þetta er enn að gerast). En ólíkt eldri útfærslum, nú eru að minnsta kosti þessi gögn dulkóðuð með AES256 GCM (). En eðlileg spurning vaknar: hvað er svona sérstakt við VTE bókasafnið að það krefst svo óstöðluðrar nálgunar við innleiðingu...
Ályktun
Í fyrsta hluta greinarinnar komumst við að því að VTE-undirstaða skautanna eru með gott sett af eiginleikum, en nú sjáum við að þessu fylgir nokkur frammistöðukostnaður. Nú er minnið ekki vandamál vegna þess að hægt er að stjórna öllum VTE skautunum með Púkaferli, sem takmarkar matarlyst þeirra. Hins vegar gætu eldri kerfi sem hafa líkamlegar takmarkanir á magni vinnsluminni og kjarnabiðminni þurft fyrri útgáfur af útstöðvum, þar sem þau neyta verulega færri auðlinda. Þrátt fyrir að VTE skautanna hafi staðið sig vel í gegnumstreymisprófunum (skroll) er birtingartími þeirra yfir þröskuldinum sem settur er í GNOME notendahandbókinni. VTE verktaki ættu líklega að taka tillit til þessa. Ef við tökum með í reikninginn að jafnvel fyrir nýliði Linux notendur að lenda í flugstöð er óhjákvæmilegt, geta þeir gert hana notendavænni. Fyrir reynda nörda gæti það jafnvel þýtt minni augnálag að skipta úr sjálfgefna flugstöðinni og getu til að forðast vinnutengd meiðsli og sjúkdóma í framtíðinni vegna langrar vinnustunda. Því miður, aðeins gamla xterm og mlterm koma okkur að töfra ping þröskuldinum 10 millisekúndur, sem er óviðunandi fyrir marga.
Viðmiðunarmælingar sýndu einnig að vegna þróunar á Linux grafísku umhverfi þurftu verktaki að gera ýmsar málamiðlanir. Sumir notendur gætu viljað skoða venjulega gluggastjóra þar sem þeir veita verulega minnkun á ping. Því miður var ekki hægt að mæla leynd fyrir Wayland: Typometer forritið sem ég notaði var búið til fyrir það sem Wayland er hannað til að koma í veg fyrir: njósnir um aðra glugga. Ég vona að Wayland compositing skili betri árangri en X.org, og ég vona líka að í framtíðinni muni einhver finna leið til að mæla leynd í þessu umhverfi.
Heimild: www.habr.com