'n Paar woorde van ons vertaalburo: gewoonlik streef almal daarna om die nuutste materiaal en publikasies te vertaal, en ons is geen uitsondering nie. Maar terminale is nie iets wat een keer per week opgedateer word nie. Daarom het ons 'n artikel deur Antoine Beaupré, gepubliseer in die lente van 2018, vir jou vertaal: ten spyte van sy aansienlike "ouderdom" volgens moderne standaarde, het die materiaal na ons mening glad nie sy relevansie verloor nie. Boonop was hierdie oorspronklik 'n reeks van twee artikels, maar ons het besluit om dit in een groot plasing te kombineer.
Terminale het 'n spesiale plek in rekenaargeskiedenis, maar in die afgelope dekades is hulle gedwing om langs die opdragreël te oorleef namate grafiese koppelvlakke alomteenwoordig word. hul eie vervang , wat op sy beurt 'n wysiging was van stelsels gebaseer op ponskaarte en wisselskakelaars. Moderne verspreidings kom met 'n verskeidenheid terminale emulators van alle vorms en kleure. En hoewel baie tevrede is met die standaardterminale wat deur hul werksomgewing verskaf word, gebruik sommige met trots reguit eksotiese sagteware om hul gunsteling-dop of teksredigeerder te laat loop. Maar, soos ons uit hierdie artikel sal sien, is nie alle terminale in dieselfde beeld geskep nie: hulle verskil baie in funksionaliteit, grootte en werkverrigting.
Sommige terminale het heeltemal verrassende sekuriteitsgate, plus die meeste het 'n heeltemal ander stel funksies, van ondersteuning vir 'n oortjie-koppelvlak tot scripting. Alhoewel ons , is hierdie artikel 'n opdatering van die vorige materiaal wat lesers sal help om te bepaal watter terminaal om in 2018 te gebruik. Die eerste helfte van die artikel vergelyk kenmerke, en die tweede helfte evalueer prestasie.
Hier is die terminale wat ek nagegaan het:
Dit is dalk nie die nuutste weergawes nie, aangesien ek ten tyde van die skryf beperk was tot stabiele bouwerk, wat ek op Debian 9 of Fedora 27 kon uitrol. Die enigste uitsondering is Alacritty. Dit is 'n afstammeling van GPU-versnelde terminale en is geskryf in 'n ongewone en nuwe taal vir hierdie taak - Rust. Ek het webterminale uitgesluit van my resensie (insluitend dié op ), omdat voorlopige toetse hul uiters swak prestasie getoon het.
Unicode-ondersteuning
Ek het my toetse met Unicode-ondersteuning begin. Die eerste toets van die terminale was om die Unicode-string van te vertoon : “é, Δ, И, K, م, ๗, あ, 叶, 葉 en 말.” Hierdie eenvoudige toets wys of die terminale wêreldwyd reg kan werk. xterm terminale vertoon nie Arabiese karakter nie in verstek konfigurasie:
By verstek gebruik xterm die klassieke "vaste" lettertipe, wat volgens , het "aansienlike Unicode-dekking sedert 1997". Daar is iets aan die gang in hierdie font wat veroorsaak dat die karakter as 'n leë raam verskyn en dit is eers wanneer die teks font verhoog word na 20+ punte dat die karakter uiteindelik korrek begin vertoon. Hierdie "fix" breek egter die vertoning van ander Unicode-karakters:
Hierdie skermkiekies is in Fedora 27 geneem, aangesien dit beter resultate as Debian 9 gelewer het, waar sommige ouer weergawes van terminale (spesifiek mlterm) nie lettertipes behoorlik kon hanteer nie. Gelukkig is dit in latere weergawes reggestel.
Let nou op hoe die lyn in xterm vertoon word. Dit blyk dat die simbool Mem en die volgende Semitiese verwys na RTL-styl skrifte (), dus tegnies moet hulle van regs na links vertoon word. Webblaaiers soos Firefox 57 hanteer die reël hierbo korrek. 'n Eenvoudiger weergawe van RTL-teks is die woord ""in Hebreeus (). sê die volgende:
“Baie rekenaarprogramme kan nie tweerigtingteks korrek vertoon nie. Byvoorbeeld, die Hebreeuse naam "Sarah" bestaan uit die karakters sin (ש) (wat aan die regterkant verskyn), dan resh (ר) en uiteindelik hy (ה) (wat aan die linkerkant moet verskyn)."
Baie terminale druip hierdie toets: Alacritty, VTE-afgeleide Gnome en XFCE terminale, urxvt, st en xterm vertoon "Sara" in omgekeerde volgorde, asof ons die naam as "Aras" geskryf het.
Nog 'n probleem met tweerigtingtekste is dat hulle op een of ander manier in lyn gebring moet word, veral wanneer dit kom by die vermenging van RTL- en LTR-tekste. RTL-skrifte moet vanaf die regterkant van die terminale venster loop, maar wat moet gebeur vir terminale wat verstek na LTR Engels? Die meeste van hulle het geen spesiale meganismes nie en belyn alle teks na links (insluitend in Konsole). Die uitsonderings is pterm en mlterm, wat aan die standaarde voldoen en sulke lyne regs in lyn bring.
Invoegbeskerming
Die volgende kritieke kenmerk wat ek geïdentifiseer het, is beskerming teen invoeging. Alhoewel dit algemeen bekend is dat uitsprake soos:
$ curl http://example.com/ | shis kode uitvoering druk opdragte, min mense weet dat verborge opdragte kan sluip in die konsole wanneer kopieer en plak vanaf 'n webblaaier, selfs na noukeurige inspeksie. wys briljant hoe onskadelik die opdrag is:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitverander in so 'n oorlas wanneer dit vanaf Horn se webwerf in die terminaal geplak word:
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.gitHoe dit werk? Kwaadwillige kode is by die blok ingesluit , wat met CSS uit die gebruiker se aansig geskuif word.
is duidelik ontwerp om sulke aanvalle te neutraliseer. In hierdie modus omsluit terminale die geplakte teks in 'n paar spesiale ontsnappingsreekse om die dop te vertel van die oorsprong van die teks. Dit vertel die dop dat dit spesiale karakters kan ignoreer wat die geplakte teks mag bevat. Alle terminale terug na die eerbiedwaardige xterm ondersteun hierdie kenmerk, maar om in hakies af te plak, vereis ondersteuning van die dop of toepassing wat op die terminale loop. Byvoorbeeld, sagteware gebruik (selfde Bash), benodig 'n lêer ~/.inputrc:
set enable-bracketed-paste onOngelukkig wys Horn se toetswebwerf ook hoe om hierdie beskerming deur die teksformatering self te omseil en om voortydig Bracketed-modus daarop toe te pas. Dit werk omdat sommige terminale nie ontsnapreekse korrek filtreer voordat hulle hul eie byvoeg nie. Byvoorbeeld, in myne kon ek nooit die Konsole-toetse suksesvol voltooi nie, selfs met die korrekte konfigurasie .invoerrc lêer. Dit beteken dat jy maklik jou stelselkonfigurasie kan beskadig as gevolg van 'n nie-ondersteunde toepassing of 'n verkeerd gekonfigureerde dop. Dit is veral gevaarlik wanneer jy by afgeleë bedieners aanmeld, waar noukeurige konfigurasiewerk minder algemeen is, veral as jy baie sulke afgeleë masjiene het.
'n Goeie oplossing vir hierdie probleem is die plakbevestiging-inprop vir die terminaal urxvt, wat bloot toestemming vra om enige teks wat nuwe reëls bevat in te voeg. Ek het nie 'n veiliger opsie gevind vir die teksaanval wat deur Horn beskryf word nie.
Oortjies en profiele
'n Gewilde kenmerk op die oomblik is ondersteuning vir 'n oortjie-koppelvlak, wat ons sal definieer as een terminale venster wat verskeie ander terminale bevat. Hierdie funksie verskil vir verskillende terminale, en alhoewel tradisionele xterm terminale glad nie oortjies ondersteun nie, het meer moderne terminale inkarnasies soos Xfce Terminal, GNOME Terminal en Konsole wel hierdie funksie. Urxvt ondersteun ook oortjies, maar slegs as jy 'n inprop gebruik. Maar in terme van tab-ondersteuning self, is Terminator die onbetwiste leier: dit ondersteun nie net oortjies nie, maar kan ook terminale in enige volgorde rangskik (sien prent hieronder).
Nog 'n kenmerk van Terminator is die vermoë om hierdie oortjies saam te "groepeer" en dieselfde toetsaanslagen op dieselfde tyd na verskeie terminale te stuur, wat 'n kru instrument bied om grootmaatbewerkings op verskeie bedieners gelyktydig uit te voer. 'n Soortgelyke kenmerk word ook in Konsole geïmplementeer. Om hierdie kenmerk in ander terminale te gebruik, moet jy derdeparty sagteware gebruik soos , of .
Oortjies werk veral goed wanneer dit met profiele gepaar word: jy kan byvoorbeeld een oortjie vir e-pos hê, 'n ander vir klets, ensovoorts. Dit word goed ondersteun deur Konsole Terminal en GNOME Terminal. Beide laat elke oortjie toe om outomaties sy eie profiel te begin. Terminator ondersteun ook profiele, maar ek kon nie 'n manier vind om outomaties sekere programme te begin wanneer jy 'n spesifieke oortjie oopmaak nie. Ander terminale het glad nie die konsep van "profiel" nie.
Ruches
Die laaste ding wat ek in die eerste deel van hierdie artikel sal dek, is die voorkoms van die terminale. Byvoorbeeld GNOME, Xfce en urxvt ondersteun deursigtigheid, maar het onlangs die ondersteuning vir agtergrondprente laat vaar, wat sommige gebruikers dwing om na die terminale oor te skakel . Persoonlik is ek tevrede daarmee en dit is eenvoudig Xbronne, wat die basisstel agtergrondkleure vir urxvt stel. Nie-standaard kleurtemas kan egter ook probleme skep. Byvoorbeeld, met toepassings и , aangesien hulle reeds hul eie kleure gebruik.
het nie kleure ondersteun nie, en nuwes was dikwels beperk tot 'n 256-kleur palet. Vir gevorderde gebruikers wat hul terminale styl, kan dopaanwysings of statusbalke op komplekse maniere 'n irriterende beperking wees. snitte wat terminale het "True Color" ondersteuning. My toetse bevestig dat st, Alacritty en VTE-gebaseerde terminale True Color perfek ondersteun. Ander terminale vaar nie baie goed in hierdie opsig nie en vertoon in werklikheid nie eens 256 kleure nie. Hieronder kan jy die verskil sien tussen True Color-ondersteuning in GNOME-terminale, st en xterm, wat 'n goeie werk hiermee doen met hul 256-kleurpalet, en urxvt, wat nie net die toets druip nie, maar selfs 'n paar flikkerende karakters in plaas daarvan wys.
Sommige terminale ontleed ook teks vir URL-patrone om skakels klikbaar te maak. Dit is van toepassing op alle VTE-afgeleide terminale, terwyl urxvt 'n spesiale inprop vereis wat URL's met 'n klik of met 'n sleutelbordkortpad sal transformeer. Ander terminale wat ek op ander maniere vertoon-URL's getoets het.
Laastens, 'n nuwe neiging in terminale is die opsie van die rolbuffer. Byvoorbeeld, st het geen rolbuffer nie; daar word aanvaar dat die gebruiker 'n terminale multiplekser soos tmux en .
Alacritty het ook 'n gebrek aan terugrolbuffers, maar sy ondersteuning as gevolg van "uitgebreide terugvoer" oor hierdie onderwerp van gebruikers. Afgesien van hierdie opkoms, ondersteun elke terminale wat ek getoets het wat ek kon vind omgekeerde blaai.
Subtotale
In die tweede deel van die materiaal (in die oorspronklike was dit twee verskillende artikels - ongeveer. baan) sal ons werkverrigting, geheuegebruik en latensie vergelyk. Maar ons kan reeds sien dat sommige van die betrokke terminale ernstige tekortkominge het. Gebruikers wat byvoorbeeld gereeld met RTL-skrifte werk, sal dalk mlterm en pterm wil oorweeg, aangesien hulle beter is om soortgelyke take as ander te hanteer. Konsole het ook goed gevaar. Gebruikers wat nie met RTL-skrifte werk nie, kan iets anders kies.
Wat die beskerming teen kwaadwillige kode-invoeging betref, staan urxvt uit vanweë sy spesiale implementering van beskerming teen hierdie tipe aanval, wat vir my beslis gerieflik lyk. Vir diegene wat 'n bietjie klokkies en fluitjies soek, is Konsole die moeite werd om te kyk. Ten slotte is dit opmerklik dat VTE 'n uitstekende basis vir terminale is, wat kleurondersteuning, URL-herkenning, ensovoorts waarborg. Met die eerste oogopslag kan die verstekterminaal wat by jou gunsteling-omgewing kom, aan al die vereistes voldoen, maar kom ons laat hierdie vraag oop totdat ons die werkverrigting verstaan.
Kom ons gaan voort met die gesprek
Oor die algemeen kan die werkverrigting van terminale op sigself na 'n vergesogte probleem lyk, maar soos dit blyk, vertoon sommige van hulle verbasend hoë latensie vir sagteware van so 'n fundamentele tipe. Verder sal ons ook kyk na wat tradisioneel "spoed" genoem word (dit is trouens die blaaispoed) en geheueverbruik van die terminale (met die voorbehoud dat dit vandag nie so krities is soos dekades gelede nie).
Vertraag
Na 'n deeglike studie van terminale prestasie, het ek tot die gevolgtrekking gekom dat die belangrikste parameter in hierdie verband die latensie (ping) is. In sy artikel Pavel Fatin het na die vertraging van verskeie teksredigeerders gekyk en laat deurskemer dat terminale in hierdie verband stadiger kan wees as die vinnigste teksredigeerders. Dit was hierdie wenk wat my uiteindelik daartoe gelei het om my eie toetse uit te voer en hierdie artikel te skryf.
Maar wat is latency, en hoekom is dit so belangrik? In sy artikel het Fatin dit gedefinieer as "die vertraging tussen die druk van 'n sleutel en die ooreenstemmende skermopdatering" en aangehaal , wat sê: "Die vertraging in visuele terugvoer op 'n rekenaarskerm het 'n belangrike impak op tikstergedrag en -bevrediging."
Fatin verduidelik dat hierdie ping dieper gevolge het as net bevrediging: "tik word stadiger, meer foute kom voor, en oog- en spierspanning neem toe." Met ander woorde, 'n groot vertraging kan lei tot tikfoute en ook laer kodekwaliteit, aangesien dit tot bykomende kognitiewe las op die brein lei. Maar wat erger is, is dat ping "oog- en spierspanning verhoog", wat blyk te impliseer in die toekoms (Blykbaar bedoel die skrywer probleme met die spiere van die oë, rug, arms en natuurlik visie - ongeveer. baan) as gevolg van herhalende stres.
Sommige van hierdie effekte is bekend vir 'n lang tyd, en die resultate , gepubliseer in 1976 in die joernaal Ergonomics, het gesê dat 'n vertraging van 100 millisekondes "tikspoed aansienlik benadeel." Meer onlangs is die GNOME-gebruikersgids bekendgestel in 10 millisekondes, en as jy verder gaan, dan wys dat 1 millisekonde ideaal is.
Fatin het sy toetse op teksversorgers gedoen; hy het 'n draagbare instrument genaamd , wat ek gebruik het om ping in terminale emulators te toets. Hou in gedagte dat die toets in simulasiemodus uitgevoer is: in werklikheid moet ons beide insette (sleutelbord, USB-beheerder, ens.) en uitset (videokaartbuffer, monitor) latency in ag neem. Volgens Fatin is dit in tipiese konfigurasies ongeveer 20 ms. As jy speeltoerusting het, kan jy hierdie syfer in net 3 millisekondes bereik. Aangesien ons reeds sulke vinnige hardeware het, hoef die toepassing nie sy eie latensie by te voeg nie. Fatin se doelwit is om die programvertraging tot 1 millisekonde te bring, of selfs sonder om te skakel , hoe in .
Hier is die resultate van my metings, sowel as sommige van Fatin se resultate, om te wys dat my eksperiment met sy toetse ooreenstem:
Die eerste ding wat my opgeval het, was die beter reaksietyd van ouer programme soos xterm en mlterm. Met die swakste registervertraging (2,4 ms), het hulle beter gevaar as die vinnigste moderne terminaal (10,6 ms vir st). Geen moderne terminaal val onder die 10 millisekonde-drempel nie. Alacritty slaag veral nie daarin om aan die "vinnigste terminale emulator beskikbaar"-eis te voldoen nie, hoewel sy tellings verbeter het sedert sy eerste hersiening in 2017. Inderdaad, die skrywers van die projek en werk daaraan om die vertoning te verbeter. Daar moet ook op gelet word dat Vim wat GTK3 gebruik, 'n orde van grootte stadiger is as sy GTK2 eweknie. Hieruit kan ons aflei dat GTK3 addisionele latensie skep, en dit word weerspieël in alle ander terminale wat dit gebruik (Terminator, Xfce4 Terminal en GNOME Terminal).
Die verskille kan egter nie vir die oog opmerklik wees nie. Soos Fatin verduidelik, "jy hoef nie bewus te wees van die vertraging vir dit om 'n uitwerking op jou te hê nie." Fatin waarsku ook oor standaardafwyking: "enige versteurings in latensie (jitter) skep bykomende stres as gevolg van hul onvoorspelbaarheid."
Die grafiek hierbo is geneem op suiwer Debian 9 (rek) met . Hierdie omgewing lewer die beste resultate in latency toetse. Soos dit blyk, skep GNOME 'n bykomende ping van 20 ms vir alle metings. 'n Moontlike verklaring hiervoor is die teenwoordigheid van programme met sinchroniese verwerking van insetgebeurtenisse. Fatin gee 'n voorbeeld vir so 'n geval , wat 'n vertraging byvoeg deur alle invoergebeurtenisse sinchronies te verwerk. By verstek kom GNOME ook met 'n vensterbestuurder , wat 'n bykomende laag buffering skep, wat ping beïnvloed en ten minste 8 millisekondes se latensie byvoeg.
Scroll spoed
Die volgende toets is 'n tradisionele "spoed" of "bandwydte" toets, wat meet hoe vinnig die terminale 'n bladsy kan blaai terwyl groot hoeveelhede teks op die skerm vertoon word. Die meganika van die toets verskil; die oorspronklike toets was om eenvoudig dieselfde teksstring te genereer deur die seq-opdrag te gebruik. Ander toetse sluit in Thomas E. Dickey (xterm instandhouer) se toets, wat herhaaldelik . In 'n ander oorsig van terminale prestasie gebruik 'n base32-gekodeerde string van ewekansige grepe, wat na die terminaal uitgevoer word met kat. Luu beskou so 'n toets as 'n "so nuttelose maatstaf as wat 'n mens kan dink" en stel voor om terminale reaksie eerder as 'n primêre maatstaf te gebruik. Dickey noem sy toets ook misleidend. Albei skrywers erken egter dat terminale vensterbandwydte 'n probleem kan wees. Luu het ontdek dat Emacs Eshell vries wanneer groot lêers vertoon word, en Dickey het die terminaal geoptimaliseer om van xtrerm se visuele traagheid ontslae te raak. Daar is dus nog 'n mate van meriete aan hierdie toets, maar aangesien die leweringsproses baie verskil van terminaal tot terminaal, kan dit ook as 'n toetskomponent gebruik word om ander parameters te toets.
Hier sien ons die rxvt en st trek voor die kompetisie, gevolg deur die veel nuwer Alacritty, wat ontwerp is met 'n fokus op prestasie. Volgende is Xfce (VTE-familie) en Konsole, wat amper twee keer so vinnig is. Laaste is xterm, wat vyf keer stadiger is as rxvt. Tydens die toets het xterm ook baie gegolf, wat dit moeilik gemaak het om teks deur te gee, selfs al was dit dieselfde reël. Konsole was vinnig, maar dit was soms moeilik: die skerm het van tyd tot tyd gevries, gedeeltelike teks gewys of dit glad nie gewys nie. Ander terminale het snare duidelik vertoon, insluitend st, Alacritty en rxvt.
Dickey verduidelik dat die prestasieverskille te wyte is aan die ontwerp van rolbuffers in verskillende terminale. Hy beskuldig veral rxvt en ander terminale daarvan dat hulle "nie die algemene reëls volg nie":
"Anders as xterm, het rxvt nie probeer om alle opdaterings te vertoon nie. As dit agter raak, sal dit sommige opdaterings weier om in te haal. Dit het 'n groter impak gehad op oënskynlike blaaispoed as op interne geheue-organisasie. Een nadeel was dat die ASCII-animasie ietwat onakkuraat was."
Om hierdie waargenome xterm traagheid reg te stel, stel Dickey voor om die hulpbron te gebruik , wat xterm toelaat om sommige skermopdaterings weg te gooi om tred te hou met die vloei. My toetse bevestig dat fastScroll werkverrigting verbeter en xterm op gelyke voet met rxvt bring. Dit is egter 'n taamlike rowwe kruk, soos Dickey self verduidelik: "soms lyk dit of xterm - soos konsole - stilstaan terwyl dit wag vir 'n nuwe stel skermopdaterings nadat sommige verwyder is." In hierdie trant blyk dit dat ander terminale die beste kompromie tussen spoed en vertoonintegriteit gevind het.
Hulpbronverbruik
Ongeag of dit sin maak om blaaispoed as 'n prestasiemetriek te oorweeg, stel hierdie toets ons in staat om die las op die terminale te simuleer, wat ons weer in staat stel om ander parameters soos geheue of skyfgebruik te meet. Die maatstawwe is verkry deur die gespesifiseerde toets uit te voer ev onder Python-prosesmonitering. Hy het meterdata ingesamel vir ru_maxrss, bedrag ru_oublok и ru_inblok en 'n eenvoudige timer.
In hierdie toets neem die ST die eerste plek met die laagste gemiddelde geheueverbruik van 8 MB, wat nie verbasend is as in ag geneem word dat die hoofgedagte van die ontwerp eenvoud is nie. mlterm, xterm en rxvt verbruik 'n bietjie meer - ongeveer 12 MB. Nog 'n noemenswaardige resultaat is Alacritty, wat 30 MB benodig om te hardloop. Dan is daar terminale van die VTE-familie met syfers van 40 tot 60 MB, wat nogal baie is. Hierdie verbruik kan verklaar word deur die feit dat hierdie terminale hoër-vlak biblioteke gebruik, byvoorbeeld GTK. Konsole kom laaste met 'n yslike 65MB geheueverbruik tydens toetse, hoewel dit geregverdig kan word deur sy baie wye verskeidenheid kenmerke.
In vergelyking met vorige resultate wat tien jaar gelede verkry is, het alle programme merkbaar meer geheue begin verbruik. Xterm het vroeër 4 MB vereis, maar nou benodig dit 15 MB net by die opstart. Daar is 'n soortgelyke toename in verbruik vir rxvt, wat nou 16 MB uit die boks vereis. Xfce Terminal neem 34 MB in beslag, wat drie keer groter is as voorheen, maar GNOME Terminal benodig slegs 20 MB. Natuurlik is alle vorige toetse op 32-bis-argitektuur uitgevoer. By LCA 2012 Rusty Russell , dat daar baie meer subtiele redes is wat die toename in geheueverbruik kan verklaar. Dit gesê, ons leef nou in 'n tyd waar ons gigagrepe geheue het, so ons sal op een of ander manier regkom.
Ek kan egter nie help om te voel dat die toekenning van meer geheue aan iets so fundamenteel soos die terminale 'n vermorsing van hulpbronne is nie. Hierdie programme moet die kleinste van die kleinste wees, moet op enige "boks", selfs 'n skoendoos, kan loop as ons ooit by die punt kom waar hulle toegerus moet word met Linux-stelsels (en jy weet dat dit so sal wees ) . Maar met hierdie nommers sal geheuegebruik in die toekoms 'n probleem word in enige omgewing wat verskeie terminale gebruik behalwe 'n paar van die ligste en mees beperkte vermoëns. Om hiervoor te vergoed, het GNOME Terminal, Konsole, urxvt, Terminator en Xfce Terminal 'n Daemon-modus wat jou toelaat om verskeie terminale deur 'n enkele proses te beheer, wat hul geheueverbruik beperk.
Tydens my toetse het ek tot 'n ander onverwagte resultaat gekom met betrekking tot skyf lees-skryf: Ek het verwag om niks hier te sien nie, maar dit het geblyk dat sommige terminale die mees omvangryke data op skyf skryf. Dus, die VTE-biblioteek hou eintlik 'n blaaibuffer op skyf (hierdie kenmerk , en dit gebeur steeds). Maar anders as ouer implementerings, word hierdie data nou ten minste geïnkripteer met AES256 GCM (). Maar 'n redelike vraag ontstaan: wat is so spesiaal aan die VTE-biblioteek dat dit so 'n nie-standaard benadering tot implementering vereis ...
Gevolgtrekking
In die eerste deel van die artikel het ons gevind dat VTE-gebaseerde terminale 'n goeie stel kenmerke het, maar nou sien ons dat dit met 'n paar prestasiekoste gepaard gaan. Nou is geheue nie 'n probleem nie, want alle VTE-terminale kan deur 'n Daemon-proses beheer word, wat hul eetlus beperk. Ouer stelsels wat fisiese beperkings op die hoeveelheid RAM en kernbuffers het, kan egter steeds vroeër weergawes van terminale benodig, aangesien hulle aansienlik minder hulpbronne verbruik. Alhoewel VTE-terminale goed gevaar het in deurset (blaai) toetse, is hul vertoningsvertraging bo die drempel wat in die GNOME-gebruikersgids gestel is. VTE-ontwikkelaars moet dit waarskynlik in ag neem. As ons in ag neem dat selfs vir beginner Linux-gebruikers wat 'n terminale teëkom onvermydelik is, kan hulle dit meer gebruikersvriendelik maak. Vir ervare geeks, kan die oorskakeling van die verstekterminaal selfs minder oogstremming beteken en die vermoë om toekomstige werkverwante beserings en siektes as gevolg van lang werksessies te vermy. Ongelukkig bring net die ou xterm en mlterm ons by die magiese ping-drempel van 10 millisekondes, wat vir baie onaanvaarbaar is.
Normmetings het ook getoon dat ontwikkelaars weens die ontwikkeling van Linux grafiese omgewings 'n aantal kompromieë moes maak. Sommige gebruikers wil dalk na gereelde vensterbestuurders kyk, aangesien dit aansienlike ping-vermindering bied. Ongelukkig was dit nie moontlik om latensie vir Wayland te meet nie: die Typometer-program wat ek gebruik het, is geskep vir wat Wayland ontwerp is om te voorkom: spioenasie op ander vensters. Ek hoop dat Wayland compositing beter presteer as X.org, en ek hoop ook dat iemand in die toekoms 'n manier sal vind om latency in hierdie omgewing te meet.
Bron: will.com