In pear wurden fan ús oersetburo: meastentiids stribbet elkenien nei it oersetten fan de nijste materialen en publikaasjes, en wy binne gjin útsûndering. Mar terminals binne net wat dat ien kear yn 'e wike wurdt bywurke. Dêrom hawwe wy foar jo in artikel oerset fan Antoine Beaupré, publisearre yn 'e maitiid fan 2018: nettsjinsteande syn grutte "leeftyd" troch moderne noarmen, nei ús miening, hat it materiaal syn relevânsje hielendal net ferlern. Derneist wie dit oarspronklik in searje fan twa artikels, mar wy hawwe besletten se te kombinearjen yn ien grutte post.
Terminals hawwe in spesjaal plak yn 'e kompjûterskiednis, mar yn' e lêste desennia binne se twongen om te oerlibjen neist de kommandorigel, om't grafyske ynterfaces ubiquitêr wurde. ferfongen harren eigen . Moderne distribúsjes komme mei in ferskaat oan terminalemulators fan alle foarmen en kleuren. En hoewol in protte tefreden binne mei de standertterminal dy't troch har wurkomjouwing wurdt levere, brûke guon grutsk gewoan eksoatyske software om har favorite shell of tekstbewurker út te fieren. Mar, lykas wy sille sjen út dit artikel, net alle terminals waarden makke yn deselde ôfbylding: se ferskille sterk yn funksjonaliteit, grutte en prestaasjes.
Guon terminals hawwe regelmjittich ferrassende feiligens gatten, plus de measte hawwe in folslein oare set fan funksjes, fan stipe foar in ljepper ynterface oan skripting. Hoewol't wy , dit artikel is in fernijing fan it foarige materiaal dat lêzers sil helpe om te bepalen hokker terminal te brûken yn 2018. De earste helte fan it artikel fergeliket funksjes, en de twadde helte evaluearret prestaasjes.
Hjir binne de terminals dy't ik hifke:
Dit binne miskien net de lêste ferzjes, om't ik op it momint fan skriuwen beheind wie ta stabile builds, dy't ik koe útrolje op Debian 9 of Fedora 27. De ienige útsûndering is Alacritty. It is in neisiet fan GPU-fersnelde terminals en is skreaun yn in ûngewoane en nije taal foar dizze taak - Rust. Ik haw webterminals útsletten fan myn resinsje (ynklusyf dy op ), om't foarriedige testen har ekstreem minne prestaasjes sjen litte.
Unicode-stipe
Ik begon myn tests mei Unicode-stipe. De earste test fan de terminals wie te werjaan de Unicode string fan : "é, Δ, И, K, م, ๗, あ, 叶, 葉 en 말." Dizze ienfâldige test lit sjen oft de terminal wrâldwiid goed kin operearje. xterm terminal toant gjin Arabysk karakter yn standert konfiguraasje:
Standert brûkt xterm it klassike "fêste" lettertype, dat neffens , hat "oansjenlike Unicode-dekking sûnt 1997". D'r bart wat yn dit lettertype dat feroarsaket dat it karakter as in leech frame ferskynt en it is pas as it tekstlettertype ferhege wurdt nei 20+ punten dat it karakter úteinlik begjint te werjaan. Dizze "fix" brekt lykwols de werjefte fan oare Unicode-karakters:
Dizze skermôfbyldings waarden nommen yn Fedora 27, om't it bettere resultaten joech as Debian 9, wêr't guon âldere ferzjes fan terminals (spesifyk mlterm) lettertypen net goed kinne omgean. Lokkich is dit fêst yn lettere ferzjes.
Notysje no hoe't de line wurdt werjûn yn xterm. It docht bliken dat it symboal Mem en de folgjende Semityske ferwize nei RTL-stylskripts (), sadat se technysk moatte wurde werjûn fan rjochts nei lofts. Webbrowsers lykas Firefox 57 behannelje de boppesteande rigel goed. In ienfâldiger ferzje fan RTL-tekst is it wurd "" yn it Hebrieusk (). seit it folgjende:
"In protte kompjûterprogramma's kinne bidirectionele tekst net goed werjaan. Bygelyks, de Hebrieuske namme "Sarah" bestiet út de karakters sin (ש) (dy't oan de rjochterkant stiet), dan resh (ר) en as lêste hy (ה) (dat moat ferskine oan de linkerkant)."
In protte terminals mislearje dizze test: Alacritty, VTE-ôflaat Gnome en XFCE terminals, urxvt, st en xterm werjaan "Sara" yn omkearde folchoarder, as hiene wy skreaun de namme as "Aras".
In oar probleem mei bidirectionele teksten is dat se op ien of oare manier ôfstimd wurde moatte, benammen as it giet om it mingen fan RTL- en LTR-teksten. RTL-skripts moatte rinne fanôf de rjochterkant fan it terminalfinster, mar wat moat der barre foar terminals dy't standert LTR Ingelsk binne? De measte fan harren hawwe gjin spesjale meganismen en rjochtsje alle tekst nei links (ynklusyf yn Konsole). De útsûnderingen binne pterm en mlterm, dy't har oan de noarmen hâlde en sokke rigels rjochts ôfstimme.
Ynstekken beskerming
De folgjende krityske funksje dy't ik haw identifisearre is anty-ynfoegje beskerming. Hoewol it algemien bekend is dat spreuken lykas:
$ curl http://example.com/ | shbinne push-kommando's foar útfiering fan koade, in pear minsken witte dat ferburgen kommando's yn 'e konsole kinne sneupe by it kopiearjen en plakke fan in webblêder, sels nei soarchfâldige ynspeksje. lit briljant sjen hoe ûnskuldich it kommando is:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitferoaret yn sa'n oerlêst as se plakke fan 'e webside fan Horn yn' e 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.gitHoe't it wurket? Malicious koade is opnaam yn it blok , dy't mei CSS út 'e werjefte fan 'e brûker ferpleatst wurdt.
is dúdlik ûntwurpen om sokke oanfallen te neutralisearjen. Yn dizze modus omslute terminals de plakke tekst yn in pear spesjale escape-sekwinsjes om de shell te fertellen oer de oarsprong fan 'e tekst. Dit fertelt de shell dat it spesjale tekens kin negearje dy't de plakke tekst kin befetsje. Alle terminals werom nei de earbiedweardige xterm stipet dizze funksje, mar plakke yn Bracketed modus fereasket stipe fan de shell of applikaasje rint op de terminal. Bygelyks, software mei help fan (deselde Bash), moat in triem ~/.inputrc:
set enable-bracketed-paste onSpitigernôch lit de testside fan Horn ek sjen hoe't jo dizze beskerming troch de tekstopmaak sels kinne omgean en betiid einigje mei it tapassen fan Bracketed-modus derop. Dit wurket om't guon terminals escape-sekwinsjes net korrekt filterje foardat se har eigen tafoegje. Bygelyks, yn mines koe ik de Konsole-tests noait mei sukses foltôgje, sels mei de juste konfiguraasje .inputrc map. Dit betsjut dat jo jo systeemkonfiguraasje maklik beskeadige kinne krije troch in net-stipe applikaasje of in ferkeard ynstelde shell. Dit is benammen gefaarlik by it oanmelden op tsjinners op ôfstân, wêr't soarchfâldich konfiguraasjewurk minder gewoan is, foaral as jo in protte sokke masines op ôfstân hawwe.
In goede oplossing foar dit probleem is it plakbefestigingsplugin foar it terminal urxvt, dy't gewoan tastimming freget om elke tekst yn te foegjen dy't nije rigels befettet. Ik haw net fûn in feiliger opsje foar de tekst oanfal beskreaun troch Horn.
Ljeppers en profilen
In populêre funksje op it stuit is stipe foar in ljepperynterface, dy't wy sille definiearje as ien terminalfinster mei ferskate oare terminals. Dizze funksje ferskilt foar ferskate terminals, en hoewol tradisjonele xterm-terminals hielendal gjin ljeppers stypje, hawwe modernere terminal-ynkarnaasjes lykas Xfce Terminal, GNOME Terminal en Konsole dizze funksje. Urxvt stipet ek ljeppers, mar allinich as jo in plugin brûke. Mar yn termen fan ljepperstipe sels, Terminator is de ûnbestriden lieder: it stipet net allinich ljeppers, mar kin ek terminals yn elke folchoarder regelje (sjoch ôfbylding hjirûnder).
In oar skaaimerk fan Terminator is de mooglikheid om dizze ljeppers byinoar te "groepearje" en deselde toetsoanslaggen tagelyk nei meardere terminals te stjoeren, wat in rûch ark biedt foar it útfieren fan bulk operaasjes op meardere servers tagelyk. In ferlykbere funksje wurdt ek ymplementearre yn Konsole. Om dizze funksje yn oare terminals te brûken, moatte jo software fan tredden brûke, lykas , of .
Ljeppers wurkje foaral goed as se binne keppele mei profilen: jo kinne bygelyks ien ljepper hawwe foar e-post, in oar foar petear, ensfh. Dit wurdt goed stipe troch Konsole Terminal en GNOME Terminal. Beide tastean elke ljepper automatysk syn eigen profyl te starten. Terminator stipet ek profilen, mar ik koe gjin manier fine om automatysk bepaalde programma's te starten as jo in spesifike ljepper iepenje. Oare terminals hawwe it konsept fan "profyl" hielendal net.
Ruffels
It lêste ding dat ik yn it earste diel fan dit artikel sil dekke is it uterlik fan 'e terminals. Bygelyks GNOME, Xfce en urxvt stypje transparânsje, mar hawwe koartlyn stipe foar eftergrûnôfbyldings ferlitten, wat guon brûkers twingt om te wikseljen nei it terminal . Persoanlik bin ik der bliid mei en it is ienfâldich xresources, dy't de basisset fan eftergrûnkleuren ynstelt foar urxvt. Net-standert kleurtema's kinne lykwols ek problemen meitsje. Bygelyks, mei applikaasjes и , om't se al har eigen kleuren brûke.
stipe gjin kleuren, en nije waarden faak beheind ta in palet fan 256 kleuren. Foar avansearre brûkers dy't har terminals stylje, kinne shell-prompts of statusbalken op komplekse manieren in ferfelende beheining wêze. tracks hokker terminals hawwe "True Color" stipe. Myn tests befêstigje dat st, Alacritty en VTE-basearre terminals stipet True Color perfekt. Oare terminals dogge it net sa goed yn dit ferbân en, yn feite, net iens werjaan 256 kleuren. Hjirûnder kinne jo it ferskil sjen tusken True Color-stipe yn GNOME-terminals, st en xterm, dy't dit goed dogge mei har 256 kleurenpalet, en urxvt, dy't net allinich de test mislearret, mar sels wat blinkende karakters sjen litte ynstee fan har.
Guon terminals analysearje ek tekst foar URL-patroanen om keppelings klikber te meitsjen. Dit jildt foar alle VTE-ôflaat terminals, wylst urxvt in spesjale plugin fereasket dy't URL's soe transformearje op in klik of mei in toetseboerd fluchtoets. Oare terminals dy't ik op oare manieren werjaan URL's hifke.
Ta beslút, in nije trend yn terminals is de opsjonaliteit fan de scroll buffer. Bygelyks, st hat gjin scroll buffer; it wurdt oannommen dat de brûker sil brûke in terminal multiplexer lykas tmux en .
Alacritty mist ek backscroll buffers, mar syn stipe fanwege "wiidweidige feedback" oer dit ûnderwerp fan brûkers. Neist dizze opstarten, stipet elke terminal dy't ik haw hifke dy't ik koe fine reverse scrolling.
Subtotals
Yn it twadde diel fan it materiaal (yn it orizjineel wiene dat twa ferskillende artikels - ca. lane) sille wy prestaasjes, ûnthâldgebrûk en latency fergelykje. Mar wy kinne al sjen dat guon fan 'e terminals yn kwestje hawwe serieuze tekortkomingen. Bygelyks, brûkers dy't geregeld wurkje mei RTL skripts meie wolle beskôgje mlterm en pterm, sa't se binne better yn it behanneljen fan ferlykbere taken as oaren. Konsole prestearre ek goed. Brûkers dy't net mei RTL-skripts wurkje meie wat oars kieze.
Yn termen fan beskerming tsjin kweade koade ynfoegje, urxvt stiet út fanwege syn spesjale ymplemintaasje fan beskerming tsjin dit soarte fan oanfal, dat liket perfoarst handich foar my. Foar dyjingen op syk nei wat toeters en bellen, is Konsole in blik wurdich. Uteinlik is it de muoite wurdich op te merken dat VTE in poerbêste basis is foar terminals, dy't kleurstipe, URL-erkenning, ensfh. Op it earste each kin de standertterminal dy't komt mei jo favorite omjouwing foldwaan oan alle easken, mar litte wy dizze fraach iepen litte oant wy de prestaasjes begripe.
Litte wy it petear trochgean
Yn it algemien, de prestaasjes fan terminals op himsels kin lykje as in fier-socht probleem, mar as it docht bliken, guon fan harren fertoane ferrassend hege latency foar software fan sa'n fûnemintele type. Ek neist sille wy sjen nei wat wurdt tradisjoneel neamd "snelheid" (yn feite, dit is de scrolling snelheid) en ûnthâld konsumpsje fan de terminal (mei it behertiging dat dit is net sa kritysk hjoed as it wie tsientallen jierren lyn).
Fertraagje
Nei in yngeande stúdzje fan terminalprestaasjes kaam ik ta de konklúzje dat de wichtichste parameter yn dit ferbân is de latency (ping). Yn syn artikel Pavel Fatin seach nei de latency fan ferskate tekstbewurkers en joech oan dat terminals yn dit ferbân stadiger wêze kinne as de fluchste tekstbewurkers. It wie dizze hint dy't my úteinlik late ta it útfieren fan myn eigen tests en it skriuwen fan dit artikel.
Mar wat is latency, en wêrom is it sa wichtich? Yn syn artikel definieare Fatin it as "de fertraging tusken it drukken op in toets en de byhearrende skermfernijing" en sitearre , dy't stelt: "De fertraging yn fisuele feedback op in kompjûterskerm hat in wichtige ynfloed op typistgedrach en tefredenheid."
Fatin leit út dat dizze ping djipper gefolgen hat dan allinich tefredenheid: "typen wurdt stadiger, mear flaters komme foar, en each- en spierspanning nimt ta." Mei oare wurden, in grutte fertraging kin liede ta typfouten en ek legere koade kwaliteit, sa't it liedt ta ekstra kognitive lêst op it brein. Mar wat slimmer is, is dat ping "eagen- en spierspanning fergruttet", wat liket te ymplisearjen yn de takomst (Blykber betsjut de skriuwer problemen mei de spieren fan 'e eagen, rêch, earms en, fansels, fisy - ca. lane) fanwege repetitive stress.
Guon fan dizze effekten binne bekend foar in lange tiid, en de resultaten , publisearre werom yn 1976 yn it tydskrift Ergonomics, sei dat in fertraging fan 100 millisekonden "de typsnelheid signifikant beynfloedet." Mear resint yntrodusearre de GNOME User Guide yn 10 millisekonden, en as jo gean fierder, dan lit sjen dat 1 millisekonde ideaal is.
Fatin die syn tests op tekstbewurkers; hy makke in draachbere ynstrumint neamd , dy't ik brûkte om ping te testen yn terminalemulators. Hâld der rekken mei dat de test waard útfierd yn simulaasje modus: yn werklikheid, wy moatte rekken hâlde sawol input (toetseboerd, USB controller, ensfh) en útfier (fideokaart buffer, monitor) latency. Neffens Fatin is it yn typyske konfiguraasjes sawat 20 ms. As jo gaming apparatuer, Jo kinne berikke dit figuer yn mar 3 millisekonden. Om't wy al sa'n rappe hardware hawwe, hoecht de applikaasje syn eigen latency net ta te foegjen. It doel fan Fatin is om de wachttiid fan 'e applikaasje op 1 millisekonde te bringen, of sels sûnder skiljen te berikken , hoe yn .
Hjir binne de resultaten fan myn mjittingen, lykas guon fan Fatin's resultaten, om sjen te litten dat myn eksperimint oerienkomt mei syn tests:
It earste dat my opfoel wie de bettere reaksjetiid fan âldere programma's lykas xterm en mlterm. Mei de slimste register latency (2,4 ms), sy prestearre better as de fluchste moderne terminal (10,6 ms foar st). Gjin moderne terminal falt ûnder de drompel fan 10 millisekonden. Benammen Alacritty slagget net om te foldwaan oan 'e rapste beskikbere terminalemulator, hoewol syn skoares binne ferbettere sûnt syn earste resinsje yn 2017. Yndied, de skriuwers fan it projekt en wurkje oan it ferbetterjen fan it display. It moat ek opmurken wurde dat Vim mei GTK3 in folchoarder fan grutte stadiger is as syn GTK2-tsjinhinger. Hjirút kinne wy konkludearje dat GTK3 ekstra latency makket, en dit wurdt wjerspegele yn alle oare terminals dy't it brûke (Terminator, Xfce4 Terminal en GNOME Terminal).
De ferskillen kinne lykwols net te merken wêze foar it each. As Fatin ferklearret, "jo moatte net bewust wêze fan 'e fertraging om it effekt op jo te hawwen." Fatin warskôget ek foar standertdeviaasje: "elke fersteuringen yn latency (jitter) meitsje ekstra stress fanwege har ûnfoarspelberens."
De grafyk hjirboppe is nommen op suver Debian 9 (stretch) mei . Dizze omjouwing produseart de bêste resultaten yn latencytests. As it docht bliken, makket GNOME in ekstra ping fan 20 ms foar alle mjittingen. In mooglike ferklearring hjirfoar is de oanwêzigens fan programma's mei syngroane ferwurking fan ynfiereveneminten. Fatin jout in foarbyld foar sa'n gefal , dy't in fertraging tafoege troch alle ynfier-eveneminten synchroon te ferwurkjen. Standert komt GNOME ek mei in finsterbehearder , dy't in ekstra laach fan buffering makket, dy't ping beynfloedet en op syn minst 8 millisekonden fan latency tafoege.
Scroll snelheid
De folgjende test is in tradysjonele "snelheid" of "bânbreedte" test, dy't mjit hoe fluch de terminal in side kin rôlje by it werjaan fan grutte hoemannichten tekst op it skerm. De meganika fan 'e test fariearje; de oarspronklike test wie gewoan deselde tekststring te generearjen mei it kommando seq. Oare tests befetsje Thomas E. Dickey (xterm ûnderhâlder) test, dy't ferskate kearen . Yn in oare resinsje fan terminal prestaasjes brûkt in base32-kodearre string fan willekeurige bytes, dy't wurdt útfierd nei de terminal mei kat. Luu beskôget sa'n test as "sa nutteloos in benchmark as men kin yntinke" en suggerearret it brûken fan terminal antwurd as in primêre metrysk ynstee. Dickey neamt syn test ek misliedend. Beide auteurs erkenne lykwols dat bânbreedte fan terminalfinster in probleem kin wêze. Luu ûntduts Emacs Eshell freezing by it werjaan fan grutte bestannen, en Dickey optimalisearre de terminal om de fisuele traagheid fan xtrerm kwyt te reitsjen. Dat d'r is noch wat fertsjinste foar dizze test, mar om't it renderingsproses hiel oars is fan terminal nei terminal, kin it ek brûkt wurde as testkomponint om oare parameters te testen.
Hjir sjogge wy de rxvt en st pull foarút fan de konkurrinsje, folge troch de folle nijere Alacritty, dat is ûntwurpen mei in fokus op prestaasjes. Folgjende binne Xfce (VTE-famylje) en Konsole, dy't hast twa kear sa fluch binne. Lêste is xterm, dat is fiif kear stadiger as rxvt. Tidens de test riffele xterm ek in protte, wêrtroch it trochjaan fan tekst lestich te sjen wie, sels as it deselde rigel wie. Konsole wie rap, mar it wie soms lestich: it display soe fan tiid ta tiid befrieze, in part fan tekst sjen litte of it hielendal net sjen. Oare terminals werjûn snaren dúdlik, ynklusyf st, Alacritty, en rxvt.
Dickey leit út dat de prestaasjes ferskillen binne fanwege it ûntwerp fan scroll buffers yn ferskillende terminals. Benammen beskuldige hy rxvt en oare terminals fan "net folgje de algemiene regels":
"Oars as xterm hat rxvt net besocht alle updates wer te jaan. As it efter falt, sil it guon updates wegerje om op te heljen. Dit hie in gruttere ynfloed op skynbere rôlsnelheid dan op ynterne ûnthâldorganisaasje. Ien neidiel wie dat de ASCII-animaasje wat ûnkrekt wie."
Om dizze waarnommen xterm traagheid te reparearjen, suggerearret Dickey de boarne te brûken , wêrtroch xterm guon skermupdates kin wegerje om by te hâlden mei de stream. Myn tests befêstigje dat fastScroll de prestaasjes ferbettert en xterm op par mei rxvt bringt. Dit is lykwols in nochal rûge kruk, lykas Dickey sels ferklearret: "soms liket xterm - lykas konsole - te stean as it wachtet op in nije set skermupdates nei't guon binne fuortsmiten." Yn dizze trant liket it derop dat oare terminals it bêste kompromis hawwe fûn tusken snelheid en werjefte-yntegriteit.
Resource konsumpsje
Nettsjinsteande oft it sin makket om scrollsnelheid as in prestaasjemetrysk te beskôgjen, lit dizze test ús de lading op 'e terminals simulearje, wat ús op syn beurt mooglik makket om oare parameters te mjitten lykas ûnthâld of skiifgebrûk. De metriken waarden krigen troch de opjûne test út te fieren seq ûnder Python proses tafersjoch. Hy sammele metergegevens foar ru_maxrss, bedrach ru_oublock и ru_inblock en in ienfâldige timer.
Yn dizze test nimt de ST it earste plak mei it leechste gemiddelde ûnthâldferbrûk fan 8 MB, wat net ferrassend is, sjoen dat it haadidee fan it ûntwerp ienfâld is. mlterm, xterm en rxvt konsumearje in bytsje mear - oer 12 MB. In oar opmerklik resultaat is Alacritty, dy't 30 MB fereasket om te rinnen. Dan binne d'r terminals fan 'e VTE-famylje mei sifers fan 40 oant 60 MB, wat in protte is. Dit konsumpsje kin ferklearre wurde troch it feit dat dizze terminals brûke heger-nivo bibleteken, Bygelyks, GTK. Konsole komt as lêste mei in heulende 65MB oan ûnthâldferbrûk tidens testen, hoewol dit kin wurde rjochtfeardige troch syn heul breed oanbod fan funksjes.
Yn ferliking mei eardere resultaten krigen tsien jier lyn, begûnen alle programma's merkber mear ûnthâld te konsumearjen. Xterm frege eartiids 4 MB, mar no fereasket it 15 MB krekt by it opstarten. D'r is in ferlykbere ferheging fan konsumpsje foar rxvt, dy't no 16 MB út 'e doaze fereasket. Xfce Terminal nimt 34 MB op, wat trije kear grutter is as earder, mar GNOME Terminal fereasket mar 20 MB. Fansels waarden alle eardere testen útfierd op 32-bit-arsjitektuer. By LCA 2012 Rusty Russell , dat d'r folle mear subtile redenen binne dy't de ferheging fan ûnthâldferbrûk ferklearje kinne. Dat sei, wy libje no yn in tiid wêryn wy gigabytes oan ûnthâld hawwe, dus wy sille it op ien of oare manier beheare.
Ik kin lykwols net oars as it gefoel dat it tawizen fan mear ûnthâld oan iets sa fûneminteel as de terminal in fergriemerij fan boarnen is. Dizze programma's moatte de lytste fan 'e lytste wêze, moatte kinne rinne op elke "doaze", sels in skuondoaze, as wy oait op it punt komme wêr't se moatte wurde útrist mei Linux-systemen (en jo witte dat it sa sil wêze ). Mar mei dizze nûmers sil ûnthâldgebrûk in probleem wurde yn 'e takomst yn elke omjouwing dy't meardere terminals útfiert, oars as in pear fan' e lichtste en meast beheind yn mooglikheden. Om dit te kompensearjen, hawwe GNOME Terminal, Konsole, urxvt, Terminator en Xfce Terminal in Daemon-modus wêrmei jo meardere terminals kinne kontrolearje fia ien proses, en har ûnthâldferbrûk beheine.
Tidens myn tests kaam ik ta in oar ûnferwacht resultaat oangeande disk read-write: ik ferwachte hjir hielendal neat te sjen, mar it die bliken dat guon terminals de meast volumineuze gegevens op skiif skriuwe. Dat, de VTE-bibleteek hâldt eins in scrollbuffer op skiif (dizze funksje , en dit bart noch altyd). Mar yn tsjinstelling ta âldere ymplemintaasjes, no binne dizze gegevens teminsten fersifere mei AES256 GCM (). Mar in ridlike fraach ûntstiet: wat is sa spesjaal oan 'e VTE-biblioteek dat it sa'n net-standert oanpak foar ymplemintaasje fereasket ...
konklúzje
Yn it earste diel fan it artikel fûnen wy dat VTE-basearre terminals in goede set funksjes hawwe, mar no sjogge wy dat dit komt mei wat prestaasjeskosten. No is ûnthâld gjin probleem, om't alle VTE-terminals kinne wurde kontroleare troch in Daemon-proses, wat har appetit beheint. Aldere systemen dy't fysike beheiningen hawwe op 'e hoemannichte RAM en kernelbuffers kinne lykwols noch eardere ferzjes fan terminals nedich hawwe, om't se signifikant minder boarnen konsumearje. Hoewol VTE-terminals goed presteare yn trochput (scrolling) tests, is har display-latinsje boppe de drompel ynsteld yn 'e GNOME-brûkersgids. VTE-ûntwikkelders moatte dit wierskynlik rekken hâlde. As wy rekken hâlde dat sels foar begjinnende Linux-brûkers in terminal tsjinkomme ûnûntkomber is, kinne se it brûkerfreonliker meitsje. Foar betûfte geeks kin it wikseljen fan 'e standertterminal sels minder eachspanning betsjutte en de mooglikheid om takomstige wurkferwûnings en sykten te foarkommen fanwege lange wurksesjes. Spitigernôch bringe allinich de âlde xterm en mlterm ús nei de magyske ping-drompel fan 10 millisekonden, wat foar in protte ûnakseptabel is.
Benchmarkmjittingen lieten ek sjen dat troch de ûntwikkeling fan Linux grafyske omjouwings ûntwikkelders in oantal kompromissen meitsje moasten. Guon brûkers wolle miskien nei reguliere finsterbehearders sjen, om't se signifikante ping-reduksje leverje. Spitigernôch wie it net mooglik om latency te mjitten foar Wayland: it Typometer-programma dat ik brûkte is makke foar wat Wayland is ûntworpen om foar te kommen: spionearje op oare finsters. Ik hoopje dat Wayland-komposysje better prestearret dan X.org, en ik hoopje ek dat yn 'e takomst immen in manier sil fine om latency yn dizze omjouwing te mjitten.
Boarne: www.habr.com