Noen ord fra vÄrt oversettelsesbyrÄ: De fleste prÞver Ä oversette de ferskeste materialene og publikasjonene, og det gjÞr vi ogsÄ. Men terminaler er ikke noe som oppdateres ukentlig. Derfor har vi oversatt artikkelen til Antoine Bopre, publisert vÄren 2018: til tross for den solide «alderen» etter dagens standarder, mener vi at materialet fortsatt er helt relevant. I tillegg er dette originalt en serie pÄ to artikler, men vi har besluttet Ä kombinere dem til ett stort innlegg.
Terminaler har en spesiell plass i datamaskinhistorien, men de har i lÞpet av de siste tiÄrene vÊrt «tvunget» til Ä overleve sammen med kommandolinjen i et landskap dominert av grafiske grensesnitt. erstatte sine , som igjen var modifikasjoner av systemer basert pÄ hullkort og brytere. Moderne distribusjoner kommer med en hel rekke terminalemulatorer i alle former og farger. Og mens mange er fornÞyde med standardterminalen som tilbys av deres arbeidsmiljÞ, bruker noen stolt Äpenbart eksotisk programvare for Ä kjÞre sitt favoritt skall eller tekstredigerer. Men som vi skal se i denne artikkelen, er ikke alle terminaler laget pÄ samme mÄte: de varierer sterkt i funksjonalitet, stÞrrelse og ytelse.
Noen terminaler har rett og slett overraskende sikkerhetshull, pluss at de fleste har helt forskjellige funksjonssett, fra stĂžtte for fanegrensesnitt til skripting. Selv om vi , er denne artikkelen en oppdatering av tidligere materiale, som vil hjelpe leserne med Ă„ avgjĂžre hvilken terminal de skal bruke i 2018. I den fĂžrste delen sammenlignes funksjonene, mens den andre vurderer ytelsen.
Her er terminalene jeg har vurdert:
Dette er muligens ikke de nyeste versjonene, da jeg har begrenset meg til stabile bygg ved tidspunktet for skrivingen, som jeg har fĂ„tt til Ă„ rulle ut pĂ„ Debian 9 eller Fedora 27. Det eneste unntaket er Alacritty. Det er en etterkommer av terminaler med GPU-akselerasjon og er skrevet pĂ„ et uvanlig og nytt sprĂ„k for denne oppgaven â Rust. Jeg har ekskludert nett-terminaler (inkludert pĂ„ ), fordi forhĂ„ndstestene viste deres ekstremt lave ytelse.
Unicode-stĂžtte
Mine tester begynte med Unicode-stĂžtte. Den fĂžrste testen av terminalene var Ă„ vise en streng med Unicode fra : «é, Î, Đ, Ś§, Ù , àč, ă, ć¶, è og ë§Â». Denne enkle testen viser om terminalen kan fungere korrekt globalt. Terminalen xterm viser ikke det arabiske tegnet i standardkonfigurasjonen:
Som standard bruker xterm den klassiske «fikserte» skrifttypen, som ifÞlge , har «betydelig Unicode-dekning siden 1997». I denne skrifttypen skjer det noe som gjÞr at symbolet vises som en tom ramme, og fÞrst nÄr tekststÞrrelsen Þkes til 20+ punkter, begynner symbolet endelig Ä vises korrekt. Imidlertid bryter en slik «fix» visningen av andre Unicode-symboler:
Disse skjermbildene ble tatt i Fedora 27, ettersom denne distribusjonen ga de beste resultatene, i motsetning til Debian 9, hvor noen eldre versjoner av terminalene (spesielt â mlterm) ikke kunne fungere ordentlig med skrifttypene. Heldigvis ble dette rettet i senere versjoner.
Legg nÄ merke til visningen av strengen i xterm. Det viser seg at symbolet Mem og det pÄfÞlgende semittiske tilhÞrer skriftscenarier for RTL (), sÄ teknisk sett bÞr de vises fra hÞyre til venstre. Nettlesere, som Firefox 57, behandler for eksempel den ovennevnte strengen korrekt. Et enklere eksempel pÄ RTL-tekst er ordet «» pÄ hebraisk (). sier fÞlgende:
«Mange dataprogrammer kan ikke vise toveis tekst korrekt. For eksempel bestĂ„r det hebraiske navnet «Sara» av tegnene sin (Ś©) (som vises til hĂžyre), sĂ„ resh (Śš) og til slutt he (Ś) (som skal vises til venstre).»
Mange terminaler klarer ikke denne testen: Alacritty, VTE-baserte terminaler fra Gnome og XFCE, urxvt, st og xterm viser "Sara" i omvendt rekkefĂžlge, som om vi skrev dette navnet som "Aras".
Et annet problem med toveis tekster er at de mÄ pÄ en eller annen mÄte justeres, spesielt nÄr det gjelder blanding av RTL- og LTR-tekster. RTL-scenarier bÞr starte fra hÞyre side av terminalvinduet, men hva skal skje for terminaler som jobber som standard med LTR-engelsk? De fleste av dem har ikke spesielle mekanismer og justerer all tekst til venstre (inkludert i Konsole). Unntakene er pterm og mlterm, som fÞlger standardene og justerer slike linjer til hÞyre.
Beskyttelse mot innliming
Den neste kritiske egenskapen jeg har identifisert, er beskyttelse mot innliming. Selv om det er allment kjent at kommandoer som:
$ curl http://example.com/ | sher push-kommandoer for Ä kjÞre kode, vet fÄ at skjulte kommandoer kan infiltrere konsollen nÄr man kopierer og limer inn fra nettleseren, selv etter grundig inspeksjon. viser glimrende hvordan en tilsynelatende ufarlig kommando:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitblir til et ubehag ved innliming fra Horne sin side til terminalen:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nDet var en dÄrlig idé. Ikke kopier kode fra nettsider du ikke stoler pÄ!
Her er den fĂžrste linjen i din /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitHvordan fungerer dette? Skadelig kode er flyttet til en blokk , som er flyttet ut av brukerens synsfelt ved hjelp av CSS.
er tydelig designet for Ä nÞytralisere slike angrep. I denne modusen omgir terminaler innlimt tekst med et par spesielle escape-sekvenser for Ä informere skallet om opprinnelsen til denne teksten. Slik mottar skallet signalet om at det kan ignorere spesielle tegn som innlimt tekst kan inneholde. Alle terminaler, inkludert den Êrverdige xterm, stÞtter denne funksjonen, men innliming i Bracketed-modus krever stÞtte fra skallet eller programmet som kjÞrer pÄ terminalen. For eksempel, programvare som bruker (det samme som Bash), trenger en fil ~/ .inputrc:
set enable-bracketed-paste onDessverre viser testnettstedet Horn ogsÄ hvordan man kan omgÄ dette beskyttelsessystemet gjennom formatering av teksten og avslutte Bracketed-modus for tidlig. Dette fungerer fordi noen terminaler feilaktig filtrerer escape-sekvenser fÞr de legger til sine egne. For eksempel lyktes jeg ikke i Ä fullfÞre testene i Konsole selv med korrekt konfigurasjon. .inputrc filen. Dette betyr at du lett kan forÄrsake skader pÄ systemkonfigurasjonen pÄ grunn av en ikke-stÞttet applikasjon eller feilkonfigurert shell. Dette er spesielt farlig nÄr du logger inn pÄ eksterne servere, der grundig konfigurasjon sjelden er tilfelle, sÊrlig hvis du har mange slike eksterne maskiner.
En god lÞsning pÄ dette problemet er et innsettingsbekreftelses-plugin for terminalen urxvt, som ganske enkelt ber om tillatelse til Ä lime inn tekst som inneholder nye linjer. Jeg har ikke funnet en mer beskyttet variant for den tekstangrepsmetoden beskrevet av Horn.
Faner og profiler
En populÊr funksjon nÄ er stÞtte for grensesnitt med faner, som vi definerer som et enkelt terminalvindu som inneholder flere terminaler. Denne funksjonen varierer mellom forskjellige terminaler, og selv om tradisjonelle terminaler som xterm ikke stÞtter faner i det hele tatt, har mer moderne terminalversjoner som Xfce Terminal, GNOME Terminal og Konsole denne funksjonen. Urxvt stÞtter ogsÄ faner, men bare hvis en plugin brukes. Men nÄr det gjelder stÞtte for faner, er Terminator den ubestridte lederen: den stÞtter ikke bare faner, men kan ogsÄ plassere terminaler i vilkÄrlig rekkefÞlge (se bildet nedenfor).
En annen funksjon i Terminator er muligheten til Ä «gruppere» disse fanene sammen og sende de samme tasteintrykkene til flere terminaler samtidig, noe som gir et enkelt verktÞy for masseoperasjoner pÄ flere servere samtidig. En lignende funksjon er ogsÄ implementert i Konsole. For Ä bruke denne funksjonen i andre terminaler mÄ man bruke tredjeparts programvare, som , eller .
Spesielt godt fungerer faner sammen med profiler: for eksempel kan du ha en fane for e-post, en annen for chat, og sÄ videre. Dette stÞttes godt av terminalene Konsole og GNOME Terminal. Begge lar hver fane automatisk starte sin egen profil. Terminator stÞtter ogsÄ profiler, men jeg klarte ikke Ä finne en mÄte Ä automatisk starte bestemte programmer nÄr en bestemt fane Äpnes. Andre terminaler har overhodet ikke noe begrep om «profil».
Ruffles
Det siste jeg vil se pÄ i fÞrste del av denne artikkelen er utseendet til terminaler. For eksempel stÞtter GNOME, Xfce og urxvt transparens, men nylig droppet de stÞtten for bakgrunnsbilder, noe som har fÄtt enkelte brukere til Ä gÄ over til andre terminaler. . Personlig er jeg fornÞyd med det enkle Xresources, som setter et grunnleggende sett med bakgrunnsfarger for urxvt. Men ikke-standard fargetemaer kan skape problemer. For eksempel, med applikasjonene og , siden de allerede bruker egne farger.
stÞttet ikke farger, og nyere var ofte begrenset til et 256-farge palett. For erfarne brukere som tilpasser sine terminaler, kan forespÞrslene i kommandolinjen eller statuslinjen pÄ noen kompliserte mÄter bli en ubehagelig begrensning. sporer hvilke terminaler som har stÞtte for «True Color». Mine tester bekrefter at st, Alacritty og VTE-baserte terminaler stÞtter True Color veldig bra. Andre terminaler er ikke like gode i denne forbindelse og viser faktisk ikke engang 256 farger. Nedenfor kan du se forskjellen i stÞtte for True Color i terminalene GNOME, st og xterm, som gjÞr en god jobb med sin 256-farge palett, og urxvt, som ikke bare ikke klarer testen, men til og med viser noen flimrende symboler i stedet.
Noen terminaler analyserer ogsÄ tekst for URL-mÞnstre for Ä gjÞre lenker klikkbare. Dette gjelder alle VTE-baserte terminaler, mens urxvt krever en spesialplugin som transformerer URL-er ved klikk eller ved hjelp av tastekombinasjoner. Andre terminaler jeg testet viser URL-er pÄ andre mÄter.
Endelig er den nye trenden for terminaler valgfri rullebuffer. For eksempel har st ingen rullebuffer; det er forventet at brukeren vil bruke en terminalmultiplexer, som tmux og .
I Alacritty mangler ogsÄ tilbakeskrollingsbuffere, men pÄ grunn av «omfattende tilbakemeldinger» om dette emnet fra brukerne. Bortsett fra disse unntakene, stÞtter hver terminal jeg har sjekket, tilbakeskrolling.
Mellomresultater
I den andre delen av materialet (i originalen var det to ulike artikler, - merkn. overs.) vil vi sammenligne ytelse, minnebruk og forsinkelse. Men vi ser allerede at noen av de vurderte terminalene har alvorlige mangler. For eksempel kan brukere som jobber regelmessig med RTL-skript, merke seg mlterm og pterm, da de takler slike oppgaver bedre enn andre. Konsole har ogsÄ prestert godt. Brukere som ikke jobber med RTL-skript, kan velge noe annet.
NÄr det gjelder beskyttelse mot innsetting av skadelig kode, skiller urxvt seg ut pÄ grunn av sin spesielle implementering av beskyttelse mot denne typen angrep, som jeg definitivt synes er praktisk. De som ser etter spesielle funksjoner, bÞr ta en titt pÄ Konsole. Til slutt er det verdt Ä merke seg at VTE er en utmerket base for terminaler, som garanterer stÞtte for farger, gjenkjennelse av URL-er og sÄ videre. Ved fÞrste blikk kan terminalen som fÞlger med ditt favorittmiljÞ, oppfylle alle krav, men la oss la dette spÞrsmÄlet stÄ Äpent til vi har undersÞkt ytelsen nÊrmere.
La oss fortsette samtalen
Generelt kan ytelsen til terminaler virke som et konstruert problem, men som det viser seg har noen av dem en overraskende stor forsinkelse for programvare av en sÄ grunnleggende type. Videre vil vi se pÄ det som tradisjonelt kalles «hastighet» (egentlig, det er rullehastigheten) og minneforbruket til terminalen (med tanke pÄ at dette i dag ikke er sÄ kritisk som for tiÄr siden).
Forsinkelse
Etter en grundig undersÞkelse av ytelsen til terminaler har jeg konkludert med at det viktigste parameteret i denne sammenhengen er stÞrrelsen pÄ forsinkelsen (ping). I artikkelen min Pavel Fatin har vurdert forsinkelsen til forskjellige tekstbehandlere og antydet at terminaler i denne sammenhengen kan fungere tregere enn de raskeste tekstbehandlerne. Nettopp denne antydningen fÞrte meg til slutt til Ä starte egne tester og skrive denne artikkelen.
Men hva er forsinkelse, og hvorfor er det sÄ viktig? I sin artikkel definerte Fatin det som «forsinkelsen mellom et tastetrykk og den tilsvarende oppdateringen av skjermen» og siterte , som sier: «Forsinkelsen i visuell tilbakemelding pÄ dataskjermen har betydelig innvirkning pÄ oppfÞrselen til skriveren og hennes tilfredshet».
Fatin forklarer at slik ping har dypere konsekvenser enn bare tilfredshet: «skriving blir tregere, det oppstÄr flere feil, og det Þker belastningen pÄ Þynene og musklene». Med andre ord kan stor forsinkelse fÞre til skrivefeil, samt redusert kvalitet pÄ koden, da det fÞrer til ekstra kognitiv belastning pÄ hjernen. Men enda verre er det at pingen «Þker belastningen pÄ Þynene og musklene», noe som Äpenbart antyder i fremtiden (tilsynelatende refererer forfatteren til problemer med Þyemusklene, ryggen, hendene og selvsagt synet, - kommentar fra oversetteren.) pÄ grunn av gjentatt belastning.
Noen av disse effektene har vÊrt kjent lenge, og resultatene , publisert allerede i 1976 i tidsskriftet Ergonomics, viser at en forsinkelse pÄ 100 millisekunder «signifikant reduserer skrivehastigheten». Nylig ble det i brukerhÄndboken for GNOME oppdatert til 10 millisekunder, og hvis man gÄr videre, sÄ indikerer at idealet er 1 millisekund.
Fatin utfÞrte sine tester pÄ tekstbehandlere; han laget et portabelt verktÞy kalt , som jeg brukte for Ä sjekke ping i terminalemulatorene. VÊr oppmerksom pÄ at testen ble utfÞrt i simuleringsmodus: i virkeligheten mÄ vi ogsÄ ta hensyn til inngangs- (tastatur, USB-kontroller osv.) og utgangsforsinkelser (grafikkbuffer, skjerm). IfÞlge Fatin er den i typiske konfigurasjoner rundt 20 ms. Med gamerutstyr kan dette tallet reduseres til bare 3 millisekunder. Siden vi allerede har sÄ raskt utstyr, bÞr applikasjonen ikke forÄrsake ytterligere forsinkelser. Fatin har som mÄl Ä redusere applikasjonsforsinkelsen til 1 millisekund, eller til og med oppnÄ en inngang uten , som i .
Her er resultatene av mine mÄlinger, samt noen resultater fra Fatin for Ä vise at eksperimentet mitt samsvarer med testene hans:
Det fÞrste som overrasket meg, var den bedre responsen hos eldre programmer som xterm og mlterm. Med en dÄrligere registeringforsinkelse (2,4 ms) viste de bedre resultater enn den raskeste moderne terminalen (10,6 ms for st). Ingen moderne terminal gÄr under terskelen pÄ 10 millisekunder. Spesielt Alacritty lever ikke opp til kravene for «den raskeste eksisterende terminalemulatoren», selv om resultatene har forbedret seg siden den fÞrste testen i 2017. Faktisk er prosjektets utviklere og jobber med Ä forbedre ytelsen. Det er ogsÄ viktig Ä bemerke at Vim, som bruker GTK3, er betydelig tregere enn sin GTK2-analog. Dette antyder at GTK3 introduserer ekstra forsinkelse, noe som pÄvirker alle andre terminaler som bruker det (Terminator, Xfce4 Terminal og GNOME Terminal).
Men for Þyet kan forskjellene vÊre usynlige. Som Fatin forklarer: «det er ikke nÞdvendig Ä vÊre klar over forsinkelsen for at den skal ha en effekt pÄ deg». Fatin advarer ogsÄ mot standardavviket: «enhver variasjon i varigheten av forsinkelsen (risting) skaper ekstra belastning pÄ grunn av deres uforutsigbarhet».
Grafen ovenfor ble hentet pÄ en ren Debian 9 (stretch) med . Dette miljÞet gir de beste resultatene i tester for Ä bestemme forsinkelse. Det viste seg at GNOME skaper en ekstra ping pÄ 20 ms for alle mÄlinger. En mulig forklaring pÄ dette er tilstedevÊrelsen av programmer med synkron behandling av inngangshendelser. Fatin nevner et slikt tilfelle som eksempel. , som legger til forsinkelse ved Ä behandle alle input-hendelser synkront. Som standard leveres GNOME ogsÄ med en vindusbehandling , som skaper et ekstra lag av buffring, noe som pÄvirker ping og legger til minimum 8 millisekunders forsinkelse.
Rullingshastighet
Den neste testen er en tradisjonell sjekk av "hastighet" eller "bÄndbredde", som mÄler hvor raskt terminalen kan rulle en side, mens den viser en stor mengde tekst pÄ skjermen. Testmekanikken varierer; den originale testen besto i Ä ganske enkelt generere den samme tekstlinjen ved hjelp av kommandoen seq. Andre tester inkluderer Thomas E. Dickeys sjekk (som fÞlger med xterm), der en fil terminfo.src gjentatte ganger . I en annen ytelsestesting av terminaler bruker en linje med tilfeldige byte i base32-koding, som skrives ut til terminalen ved hjelp av cat. Liu anser en slik test for Ä vÊre "sÄ nyttelÞs som det er mulig Ä forestille seg" og foreslÄr Ä bruke terminalresponsen som den primÊre meteren i stedet. Dickey anser ogsÄ sin test for Ä vÊre misvisende. Likevel innrÞmmer begge forfatterne at terminalvinduets bÄndbredde kan vÊre et problem. Liu oppdaget at Emacs Eshell hang nÄr han viste store filer, og Dickey optimaliserte terminalen for Ä fjerne den visuelle treigheten i xterm. Derfor er det fortsatt en viss resonans i denne testen, men siden renderingprosessen varierer sterkt fra terminal til terminal, kan den ogsÄ brukes som en testkomponent for Ä sjekke andre parametere.
Her ser vi at rxvt og st tar ledelsen i forhold til konkurrentene, etterfulgt av det betydelig nyere Alacritty, som er utviklet med fokus pÄ ytelse. Deretter fÞlger Xfce (VTE-familien) og Konsole, som fungerer nesten dobbelt sÄ raskt. Sistnevnte er xterm, med en hastighet som er fem ganger tregere enn rxvt. Under testen var xterm ogsÄ svÊrt uskarp, og det var vanskelig Ä se teksten, selv om det var den samme linjen. Konsole viste seg Ä vÊre rask, men det «jukset» tidvis: skjermen frÞs av og til, og viste deler av teksten eller klarte ikke Ä vise den i det hele tatt. Andre terminaler viste linjene klart, inkludert st, Alacritty og rxvt.
Diki forklarer at forskjellene i ytelse skyldes designet av rullebufferne i de ulike terminalene. Spesielt anklager han rxvt og andre terminaler for at de «ikke fÞlger de generelle reglene»:
«I motsetning til xterm, prÞvde ikke rxvt Ä vise alle oppdateringer. Hvis den henger etter, vil den ignorere noen oppdateringer for Ä ta igjen det tapte. Dette hadde stÞrre innvirkning pÄ den tilsynelatende hastigheten pÄ rullemekanismen enn pÄ organiseringen av internminnet. En ulempe var at ASCII-animasjonen var noe unÞyaktig.»
For Ă„ rette opp den tilsynelatende tregheten til xterm, foreslĂ„r Diki Ă„ bruke ressursen , som lar xterm kaste noen skjermoppdateringer for Ă„ unngĂ„ Ă„ henge etter strĂžmmen. Mine tester bekrefter at fastScroll forbedrer ytelsen og bringer xterm opp pĂ„ samme nivĂ„ som rxvt. Det er imidlertid en ganske grov lĂžsning, som Diki selv forklarer: «noen ganger kan xterm â akkurat som konsole â se ut til Ă„ stoppe, fordi den venter pĂ„ en ny gruppe skjermoppdateringer etter at noen av dem er blitt fjernet». I denne sammenhengen ser det ut til at andre terminaler har funnet den beste balansen mellom hastighet og skjermintegritet.
Ressursforbruk
Uavhengig av hvorvidt det er hensiktsmessig Ä vurdere rullemekanismen som en prestasjonsindikator, lar denne testen oss simulere lasten pÄ terminalene, noe som igjen gjÞr oss i stand til Ä mÄle andre parametere, som minne- eller diskbruken. Metrikkene ble innhentet ved Ä kjÞre den angitte testen seq under overvÄking av Python-prosessen. Den samlet inn data fra tellerne for ru_maxrss, summen av ru_oublock og ru_inblock og en enkel tidtaker.
I denne testen tar ST fĂžrsteplass med det laveste gjennomsnittlige minneforbruket pĂ„ 8 MB, noe som ikke er overraskende gitt at prosjektets hovedidĂ© er enkelhet. Litt mer brukes av mlterm, xterm og rxvt â rundt 12 MB. Alacritty har ogsĂ„ et merkbart resultat, med et minnebehov pĂ„ 30 MB. Deretter fĂžlger terminalene i VTE-familien med forbruk mellom 40 og 60 MB, som er ganske mye. Dette minneforbruket kan forklares med at disse terminalene bruker hĂžyere nivĂ„ biblioteker, som GTK. Konsole kommer til slutt med et kolossalt forbruk pĂ„ 65 MB under testene, selv om dette kan rettferdiggjĂžres med det omfattende funksjonssettet.
Sammenlignet med resultatene fra for ti Är siden har alle programmene begynt Ä bruke betydelig mer minne. Tidligere brukte Xterm 4 MB, men nÄ krever det 15 MB bare for Ä starte. En lignende Þkning i forbruket er ogsÄ observert hos rxvt, som nÄ fra starten krever 16 MB. Terminalen Xfce tar 34 MB, som er tre ganger mer enn tidligere, mens GNOME Terminal bare krever 20 MB. SelvfÞlgelig ble alle tidligere tester utfÞrt pÄ 32-bits arkitektur. PÄ LCA 2012, Rusty Russell , er det mange finere grunner som kan forklare Þkningen i minneforbruket. I alt dette lever vi nÄ i en tid der vi har hele gigabyte med minne, sÄ vi klarer oss.
Likevel kan jeg ikke unngÄ Ä fÞle at det Ä tildele mer minne til sÄ grunnleggende programvare som terminalen, er en bortkastet ressurs. Disse programmene bÞr vÊre de minste av de smÄ, de bÞr kunne fungere pÄ hvilken som helst "boks", selv en skoeske, hvis vi noen gang kommer til det punktet hvor de mÄ utstyres med Linux-systemer (og du vet at det vil skje). Men med disse tallene vil minneforbruket bli et problem i fremtiden nÄr flere terminaler kjÞres, bortsett fra i situasjoner med flere av de letteste og mest begrensede alternativene. For Ä kompensere for dette har GNOME Terminal, Konsole, urxvt, Terminator og Xfce Terminal en Daemon-modus som lar deg kontrollere flere terminaler gjennom én prosess, noe som begrenser minnebruken.
I lĂžpet av testene mine kom jeg til en annen overraskende konklusjon angĂ„ende disklesing og -skriving: Jeg forventet absolutt ikke Ă„ finne noe her, men det viste seg at noen terminaler skriver de stĂžrste dataene til disken. Biblioteket VTE holder faktisk pĂ„ disken en scroll-buffer (denne funksjonen , og dette skjer fortsatt). Men i motsetning til de eldre implementeringene, er nĂ„, i det minste, disse dataene kryptert med AES256 GCM (). Men det oppstĂ„r et rimelig spĂžrsmĂ„l: hva er sĂ„ spesielt med biblioteket VTE, at det krever en slik uvanlig tilnĂŠrming til implementeringenâŠ
Konklusjon
I den fÞrste delen av artikkelen oppdaget vi at terminaler basert pÄ VTE har et godt sett av funksjoner, men nÄ ser vi at dette er knyttet til noen kostnader for Ä sikre ytelsen deres. For Þyeblikket er ikke minne et problem, fordi alle VTE-terminaler kan administreres gjennom en Daemon-prosess, som begrenser appetitten deres. Likevel kan eldre systemer med fysiske begrensninger pÄ mengden RAM og kjernebuffere fortsatt trenge eldre versjoner av terminalene, da de bruker betydelig mindre ressurser. Selv om VTE-terminalene har prestert godt i bÄndbredde-testing (scrolling), er forsinkelsen i Ä vise data pÄ skjermen over den etablerte terskelen i GNOME-brukermanualen. Det kan vÊre lurt for VTE-utviklerne Ä ta dette i betraktning. Gitt at selv for nybegynnere pÄ Linux er mÞtet med terminalen uunngÄelig, kan de gjÞre den mer brukervennlig. For erfarne entusiaster kan overgangen fra standardterminalen til og med bety mindre belastning pÄ synet og mulighet til Ä unngÄ profesjonelle skader og helseproblemer i fremtiden pÄ grunn av lange arbeidssesjoner. Dessverre fÞrer bare de gamle xterm og mlterm oss til den magiske pingterskelen pÄ 10 millisekunder, noe som er uakseptabelt for mange.
KontrollmĂ„lingene viste ogsĂ„ at utviklingen av grafiske miljĂžer i Linux har fĂ„tt utviklere til Ă„ inngĂ„ en rekke kompromisser. Noen brukere bĂžr vurdere de vanlige vindusbehandlerne, da de gir betydelig lavere ping. Dessverre klarte jeg ikke Ă„ mĂ„le forsinkelsen for Wayland: programmet Typometer, som jeg brukte, ble laget for Ă„ hindre det Wayland er ment Ă„ forhindre â overvĂ„kning av andre vinduer. Jeg hĂ„per at Waylands kompositing ytelsesmessig er bedre enn X.org, og jeg hĂ„per ogsĂ„ at noen i fremtiden finner en mĂ„te Ă„ vurdere forsinkelsesnivĂ„et i dette miljĂžet.
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish