{"id":37222,"date":"2019-10-31T22:16:26","date_gmt":"2019-10-31T19:16:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/obzor-emulyatorov-terminala\/"},"modified":"2019-10-31T22:16:26","modified_gmt":"2019-10-31T19:16:26","slug":"obzor-emulyatorov-terminala","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/obzor-emulyatorov-terminala","title":{"rendered":"En oversikt over terminalemulatorer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Noen ord fra v\u00e5rt oversettelsesbyr\u00e5: De fleste pr\u00f8ver \u00e5 oversette de ferskeste materialene og publikasjonene, og det gj\u00f8r vi ogs\u00e5. Men terminaler er ikke noe som oppdateres ukentlig. Derfor har vi oversatt artikkelen til Antoine Bopre, publisert v\u00e5ren 2018: til tross for den solide \u00abalderen\u00bb etter dagens standarder, mener vi at materialet fortsatt er helt relevant. I tillegg er dette originalt en serie p\u00e5 to artikler, men vi har besluttet \u00e5 kombinere dem til ett stort innlegg.<\/i><\/p>\n

\"En
\n
\nTerminaler har en spesiell plass i datamaskinhistorien, men de har i l\u00f8pet av de siste ti\u00e5rene v\u00e6rt \u00abtvunget\u00bb til \u00e5 overleve sammen med kommandolinjen i et landskap dominert av grafiske grensesnitt. Terminalemulatorer<\/a><\/noindex> erstatte sine maskinvarebr\u00f8dre<\/a><\/noindex>, som igjen var modifikasjoner av systemer basert p\u00e5 hullkort og brytere. Moderne distribusjoner kommer med en hel rekke terminalemulatorer i alle former og farger. Og mens mange er forn\u00f8yde med standardterminalen som tilbys av deres arbeidsmilj\u00f8, bruker noen stolt \u00e5penbart eksotisk programvare for \u00e5 kj\u00f8re sitt favoritt skall eller tekstredigerer. Men som vi skal se i denne artikkelen, er ikke alle terminaler laget p\u00e5 samme m\u00e5te: de varierer sterkt i funksjonalitet, st\u00f8rrelse og ytelse.
\n<\/a><\/noindex><\/p>\n

Noen terminaler har rett og slett overraskende sikkerhetshull, pluss at de fleste har helt forskjellige funksjonssett, fra st\u00f8tte for fanegrensesnitt til skripting. Selv om vi har sett p\u00e5 terminalemulatorer for lenge siden<\/a><\/noindex>, er denne artikkelen en oppdatering av tidligere materiale, som vil hjelpe leserne med \u00e5 avgj\u00f8re hvilken terminal de skal bruke i 2018. I den f\u00f8rste delen sammenlignes funksjonene, mens den andre vurderer ytelsen.<\/p>\n

Her er terminalene jeg har vurdert:<\/p>\n

\"En
\n
\nDette er muligens ikke de nyeste versjonene, da jeg har begrenset meg til stabile bygg ved tidspunktet for skrivingen, som jeg har f\u00e5tt til \u00e5 rulle ut p\u00e5 Debian 9 eller Fedora 27. Det eneste unntaket er Alacritty. Det er en etterkommer av terminaler med GPU-akselerasjon og er skrevet p\u00e5 et uvanlig og nytt spr\u00e5k for denne oppgaven \u2014 Rust. Jeg har ekskludert nett-terminaler (inkludert p\u00e5 Electron<\/a><\/noindex>), fordi forh\u00e5ndstestene viste deres ekstremt lave ytelse.<\/p>\n

Unicode-st\u00f8tte<\/h4>\n

\nMine tester begynte med Unicode-st\u00f8tte. Den f\u00f8rste testen av terminalene var \u00e5 vise en streng med Unicode fra en artikkel p\u00e5 Wikipedia<\/a><\/noindex>: \u00ab\u00e9, \u0394, \u0419, \u05e7, \u0645, \u0e57, \u3042, \u53f6, \u8449 og \ub9d0\u00bb. Denne enkle testen viser om terminalen kan fungere korrekt globalt. Terminalen xterm viser ikke det arabiske tegnet Minne<\/a><\/noindex> i standardkonfigurasjonen:<\/p>\n

\"En
\n
\nSom standard bruker xterm den klassiske \u00abfikserte\u00bb skrifttypen, som if\u00f8lge den samme Wikipedia<\/a><\/noindex>, har \u00abbetydelig Unicode-dekning siden 1997\u00bb. I denne skrifttypen skjer det noe som gj\u00f8r at symbolet vises som en tom ramme, og f\u00f8rst n\u00e5r tekstst\u00f8rrelsen \u00f8kes til 20+ punkter, begynner symbolet endelig \u00e5 vises korrekt. Imidlertid bryter en slik \u00abfix\u00bb visningen av andre Unicode-symboler:<\/p>\n

\"En
\n
\nDisse 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 \u2014 mlterm) ikke kunne fungere ordentlig med skrifttypene. Heldigvis ble dette rettet i senere versjoner.<\/p>\n

Legg n\u00e5 merke til visningen av strengen i xterm. Det viser seg at symbolet Mem og det p\u00e5f\u00f8lgende semittiske Qoph<\/a><\/noindex> tilh\u00f8rer skriftscenarier for RTL (right-to-left<\/a><\/noindex>), s\u00e5 teknisk sett b\u00f8r de vises fra h\u00f8yre til venstre. Nettlesere, som Firefox 57, behandler for eksempel den ovennevnte strengen korrekt. Et enklere eksempel p\u00e5 RTL-tekst er ordet \u00abSara<\/a><\/noindex>\u00bb p\u00e5 hebraisk (\u05e9\u05e8\u05d4<\/a><\/noindex>). Wikipedia-siden om toveis tekster<\/a><\/noindex> sier f\u00f8lgende:<\/p>\n

\u00abMange dataprogrammer kan ikke vise toveis tekst korrekt. For eksempel best\u00e5r det hebraiske navnet \u00abSara\u00bb av tegnene sin (\u05e9) (som vises til h\u00f8yre), s\u00e5 resh (\u05e8) og til slutt he (\u05d4) (som skal vises til venstre).\u00bb<\/p><\/blockquote>\n

\nMange terminaler klarer ikke denne testen: Alacritty, VTE-baserte terminaler fra Gnome og XFCE, urxvt, st og xterm viser \"Sara\" i omvendt rekkef\u00f8lge, som om vi skrev dette navnet som \"Aras\".<\/p>\n

\"En
\n
\nEt annet problem med toveis tekster er at de m\u00e5 p\u00e5 en eller annen m\u00e5te justeres, spesielt n\u00e5r det gjelder blanding av RTL- og LTR-tekster. RTL-scenarier b\u00f8r starte fra h\u00f8yre 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\u00f8lger standardene og justerer slike linjer til h\u00f8yre.<\/p>\n

\"En
\n<\/p>\n

Beskyttelse mot innliming<\/h4>\n

\nDen neste kritiske egenskapen jeg har identifisert, er beskyttelse mot innliming. Selv om det er allment kjent at kommandoer som:<\/p>\n

$ curl http:\/\/example.com\/ | sh<\/code><\/pre>\n
\ner push-kommandoer for \u00e5 kj\u00f8re kode, vet f\u00e5 at skjulte kommandoer kan infiltrere konsollen n\u00e5r man kopierer og limer inn fra nettleseren, selv etter grundig inspeksjon. Verifiseringsside for Janna Horn<\/a><\/noindex> viser glimrende hvordan en tilsynelatende ufarlig kommando:<\/p>\n
git clone git:\/\/git.kernel.org\/pub\/scm\/utils\/kup\/kup.git<\/code><\/pre>\n
\nblir til et ubehag ved innliming fra Horne sin side til terminalen:<\/p>\n
git clone \/dev\/null;\n    clear;\n\techo -n \"Hello \";\n\twhoami|tr -d 'n';\n\techo -e '!nDet var en d\u00e5rlig id\u00e9. Ikke kopier kode fra nettsider du ikke stoler p\u00e5! \n\tHer er den f\u00f8rste linjen i din \/etc\/passwd: ';\n\thead -n1 \/etc\/passwd\n\tgit clone git:\/\/git.kernel.org\/pub\/scm\/utils\/kup\/kup.git<\/code><\/pre>\n
\nHvordan fungerer dette? Skadelig kode er flyttet til en blokk <\/b>, som er flyttet ut av brukerens synsfelt ved hjelp av CSS.<\/p>\n
Bracketed paste-modus<\/a><\/noindex> er tydelig designet for \u00e5 n\u00f8ytralisere slike angrep. I denne modusen omgir terminaler innlimt tekst med et par spesielle escape-sekvenser for \u00e5 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 \u00e6rverdige xterm, st\u00f8tter denne funksjonen, men innliming i Bracketed-modus krever st\u00f8tte fra skallet eller programmet som kj\u00f8rer p\u00e5 terminalen. For eksempel, programvare som bruker GNU Readline<\/a><\/noindex> (det samme som Bash), trenger en fil ~\/ .inputrc<\/b>:<\/p>\n
set enable-bracketed-paste on<\/code><\/pre>\n
\nDessverre viser testnettstedet Horn ogs\u00e5 hvordan man kan omg\u00e5 dette beskyttelsessystemet gjennom formatering av teksten og avslutte Bracketed-modus for tidlig. Dette fungerer fordi noen terminaler feilaktig filtrerer escape-sekvenser f\u00f8r de legger til sine egne. For eksempel lyktes jeg ikke i \u00e5 fullf\u00f8re testene i Konsole selv med korrekt konfigurasjon. .inputrc<\/b> filen. Dette betyr at du lett kan for\u00e5rsake skader p\u00e5 systemkonfigurasjonen p\u00e5 grunn av en ikke-st\u00f8ttet applikasjon eller feilkonfigurert shell. Dette er spesielt farlig n\u00e5r du logger inn p\u00e5 eksterne servere, der grundig konfigurasjon sjelden er tilfelle, s\u00e6rlig hvis du har mange slike eksterne maskiner.<\/p>\n
En god l\u00f8sning p\u00e5 dette problemet er et innsettingsbekreftelses-plugin for terminalen urxvt<\/b>, som ganske enkelt ber om tillatelse til \u00e5 lime inn tekst som inneholder nye linjer. Jeg har ikke funnet en mer beskyttet variant for den tekstangrepsmetoden beskrevet av Horn.<\/p>\n
Faner og profiler<\/h4>\n
\nEn popul\u00e6r funksjon n\u00e5 er st\u00f8tte 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\u00f8tter faner i det hele tatt, har mer moderne terminalversjoner som Xfce Terminal, GNOME Terminal og Konsole denne funksjonen. Urxvt st\u00f8tter ogs\u00e5 faner, men bare hvis en plugin brukes. Men n\u00e5r det gjelder st\u00f8tte for faner, er Terminator den ubestridte lederen: den st\u00f8tter ikke bare faner, men kan ogs\u00e5 plassere terminaler i vilk\u00e5rlig rekkef\u00f8lge (se bildet nedenfor).<\/p>\n
\"En
\n
\nEn annen funksjon i Terminator er muligheten til \u00e5 \u00abgruppere\u00bb disse fanene sammen og sende de samme tasteintrykkene til flere terminaler samtidig, noe som gir et enkelt verkt\u00f8y for masseoperasjoner p\u00e5 flere servere samtidig. En lignende funksjon er ogs\u00e5 implementert i Konsole. For \u00e5 bruke denne funksjonen i andre terminaler m\u00e5 man bruke tredjeparts programvare, som Cluster SSH<\/a><\/noindex>, xlax<\/a><\/noindex> eller tmux<\/a><\/noindex>.<\/p>\n
Spesielt godt fungerer faner sammen med profiler: for eksempel kan du ha en fane for e-post, en annen for chat, og s\u00e5 videre. Dette st\u00f8ttes godt av terminalene Konsole og GNOME Terminal. Begge lar hver fane automatisk starte sin egen profil. Terminator st\u00f8tter ogs\u00e5 profiler, men jeg klarte ikke \u00e5 finne en m\u00e5te \u00e5 automatisk starte bestemte programmer n\u00e5r en bestemt fane \u00e5pnes. Andre terminaler har overhodet ikke noe begrep om \u00abprofil\u00bb.<\/p>\n
Ruffles<\/h4>\n
\nDet siste jeg vil se p\u00e5 i f\u00f8rste del av denne artikkelen er utseendet til terminaler. For eksempel st\u00f8tter GNOME, Xfce og urxvt transparens, men nylig droppet de st\u00f8tten for bakgrunnsbilder, noe som har f\u00e5tt enkelte brukere til \u00e5 g\u00e5 over til andre terminaler. Tilix<\/a><\/noindex>. Personlig er jeg forn\u00f8yd med det enkle Xresources<\/b>, som setter et grunnleggende sett med bakgrunnsfarger for urxvt. Men ikke-standard fargetemaer kan skape problemer. For eksempel, Solarized<\/a><\/noindex> ikke fungerer<\/a><\/noindex> med applikasjonene htop<\/a><\/noindex> og IPTraf<\/a><\/noindex>, siden de allerede bruker egne farger.<\/p>\n
Den opprinnelige VT100-terminalen<\/a><\/noindex> st\u00f8ttet ikke farger, og nyere var ofte begrenset til et 256-farge palett. For erfarne brukere som tilpasser sine terminaler, kan foresp\u00f8rslene i kommandolinjen eller statuslinjen p\u00e5 noen kompliserte m\u00e5ter bli en ubehagelig begrensning. Gist<\/a><\/noindex> sporer hvilke terminaler som har st\u00f8tte for \u00abTrue Color\u00bb. Mine tester bekrefter at st, Alacritty og VTE-baserte terminaler st\u00f8tter 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\u00f8tte for True Color i terminalene GNOME, st og xterm, som gj\u00f8r 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.<\/p>\n
\"En
\n
\nNoen terminaler analyserer ogs\u00e5 tekst for URL-m\u00f8nstre for \u00e5 gj\u00f8re 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\u00e5 andre m\u00e5ter.<\/p>\n
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 GNU Screen<\/a><\/noindex>.<\/p>\n
I Alacritty mangler ogs\u00e5 tilbakeskrollingsbuffere, men st\u00f8tte for dette vil snart bli lagt til<\/a><\/noindex> p\u00e5 grunn av \u00abomfattende tilbakemeldinger\u00bb om dette emnet fra brukerne. Bortsett fra disse unntakene, st\u00f8tter hver terminal jeg har sjekket, tilbakeskrolling.<\/p>\n
Mellomresultater<\/h4>\n
\nI den andre delen av materialet (i originalen var det to ulike artikler, - merkn. overs.<\/i>) 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\u00e5 prestert godt. Brukere som ikke jobber med RTL-skript, kan velge noe annet.<\/p>\n
N\u00e5r det gjelder beskyttelse mot innsetting av skadelig kode, skiller urxvt seg ut p\u00e5 grunn av sin spesielle implementering av beskyttelse mot denne typen angrep, som jeg definitivt synes er praktisk. De som ser etter spesielle funksjoner, b\u00f8r ta en titt p\u00e5 Konsole. Til slutt er det verdt \u00e5 merke seg at VTE er en utmerket base for terminaler, som garanterer st\u00f8tte for farger, gjenkjennelse av URL-er og s\u00e5 videre. Ved f\u00f8rste blikk kan terminalen som f\u00f8lger med ditt favorittmilj\u00f8, oppfylle alle krav, men la oss la dette sp\u00f8rsm\u00e5let st\u00e5 \u00e5pent til vi har unders\u00f8kt ytelsen n\u00e6rmere.<\/p>\n
<\/p>\n
La oss fortsette samtalen<\/h4>\n
<\/i>
\nGenerelt 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\u00e5 grunnleggende type. Videre vil vi se p\u00e5 det som tradisjonelt kalles \u00abhastighet\u00bb (egentlig, det er rullehastigheten) og minneforbruket til terminalen (med tanke p\u00e5 at dette i dag ikke er s\u00e5 kritisk som for ti\u00e5r siden).<\/p>\n
Forsinkelse<\/h4>\n
\nEtter en grundig unders\u00f8kelse av ytelsen til terminaler har jeg konkludert med at det viktigste parameteret i denne sammenhengen er st\u00f8rrelsen p\u00e5 forsinkelsen (ping). I artikkelen min \u00abVi skriver med glede\u00bb<\/a><\/noindex> 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\u00f8rte meg til slutt til \u00e5 starte egne tester og skrive denne artikkelen.<\/p>\n
Men hva er forsinkelse, og hvorfor er det s\u00e5 viktig? I sin artikkel definerte Fatin det som \u00abforsinkelsen mellom et tastetrykk og den tilsvarende oppdateringen av skjermen\u00bb og siterte \u00abH\u00e5ndbok for menneske-maskin interaksjon\u00bb<\/a><\/noindex>, som sier: \u00abForsinkelsen i visuell tilbakemelding p\u00e5 dataskjermen har betydelig innvirkning p\u00e5 oppf\u00f8rselen til skriveren og hennes tilfredshet\u00bb.<\/p>\n
Fatin forklarer at slik ping har dypere konsekvenser enn bare tilfredshet: \u00abskriving blir tregere, det oppst\u00e5r flere feil, og det \u00f8ker belastningen p\u00e5 \u00f8ynene og musklene\u00bb. Med andre ord kan stor forsinkelse f\u00f8re til skrivefeil, samt redusert kvalitet p\u00e5 koden, da det f\u00f8rer til ekstra kognitiv belastning p\u00e5 hjernen. Men enda verre er det at pingen \u00ab\u00f8ker belastningen p\u00e5 \u00f8ynene og musklene\u00bb, noe som \u00e5penbart antyder utvikling av yrkesrelaterte skader<\/a><\/noindex> i fremtiden (tilsynelatende refererer forfatteren til problemer med \u00f8yemusklene, ryggen, hendene og selvsagt synet, - kommentar fra oversetteren.<\/i>) p\u00e5 grunn av gjentatt belastning.<\/p>\n
Noen av disse effektene har v\u00e6rt kjent lenge, og resultatene fra forskning<\/a><\/noindex>, publisert allerede i 1976 i tidsskriftet Ergonomics, viser at en forsinkelse p\u00e5 100 millisekunder \u00absignifikant reduserer skrivehastigheten\u00bb. Nylig ble det i brukerh\u00e5ndboken for GNOME oppdatert akseptabel responstid<\/a><\/noindex> til 10 millisekunder, og hvis man g\u00e5r videre, s\u00e5 Microsoft Research<\/a><\/noindex> indikerer at idealet er 1 millisekund.<\/p>\n
Fatin utf\u00f8rte sine tester p\u00e5 tekstbehandlere; han laget et portabelt verkt\u00f8y kalt Typometer<\/a><\/noindex>, som jeg brukte for \u00e5 sjekke ping i terminalemulatorene. V\u00e6r oppmerksom p\u00e5 at testen ble utf\u00f8rt i simuleringsmodus: i virkeligheten m\u00e5 vi ogs\u00e5 ta hensyn til inngangs- (tastatur, USB-kontroller osv.) og utgangsforsinkelser (grafikkbuffer, skjerm). If\u00f8lge Fatin er den i typiske konfigurasjoner rundt 20 ms. Med gamerutstyr kan dette tallet reduseres til bare 3 millisekunder. Siden vi allerede har s\u00e5 raskt utstyr, b\u00f8r applikasjonen ikke for\u00e5rsake ytterligere forsinkelser. Fatin har som m\u00e5l \u00e5 redusere applikasjonsforsinkelsen til 1 millisekund, eller til og med oppn\u00e5 en inngang uten m\u00e5lelig forsinkelse<\/a><\/noindex>, som i IntelliJ IDEA 15<\/a><\/noindex>.<\/p>\n
Her er resultatene av mine m\u00e5linger, samt noen resultater fra Fatin for \u00e5 vise at eksperimentet mitt samsvarer med testene hans:<\/p>\n
\"En
\n
\nDet f\u00f8rste som overrasket meg, var den bedre responsen hos eldre programmer som xterm og mlterm. Med en d\u00e5rligere registeringforsinkelse (2,4 ms) viste de bedre resultater enn den raskeste moderne terminalen (10,6 ms for st). Ingen moderne terminal g\u00e5r under terskelen p\u00e5 10 millisekunder. Spesielt Alacritty lever ikke opp til kravene for \u00abden raskeste eksisterende terminalemulatoren\u00bb, selv om resultatene har forbedret seg siden den f\u00f8rste testen i 2017. Faktisk er prosjektets utviklere klar over situasjonen<\/a><\/noindex> og jobber med \u00e5 forbedre ytelsen. Det er ogs\u00e5 viktig \u00e5 bemerke at Vim, som bruker GTK3, er betydelig tregere enn sin GTK2-analog. Dette antyder at GTK3 introduserer ekstra forsinkelse, noe som p\u00e5virker alle andre terminaler som bruker det (Terminator, Xfce4 Terminal og GNOME Terminal).<\/p>\n
Men for \u00f8yet kan forskjellene v\u00e6re usynlige. Som Fatin forklarer: \u00abdet er ikke n\u00f8dvendig \u00e5 v\u00e6re klar over forsinkelsen for at den skal ha en effekt p\u00e5 deg\u00bb. Fatin advarer ogs\u00e5 mot standardavviket: \u00abenhver variasjon i varigheten av forsinkelsen (risting) skaper ekstra belastning p\u00e5 grunn av deres uforutsigbarhet\u00bb.<\/p>\n
\"En
\n
\nGrafen ovenfor ble hentet p\u00e5 en ren Debian 9 (stretch) med i3 vindusbehandler<\/a><\/noindex>. Dette milj\u00f8et gir de beste resultatene i tester for \u00e5 bestemme forsinkelse. Det viste seg at GNOME skaper en ekstra ping p\u00e5 20 ms for alle m\u00e5linger. En mulig forklaring p\u00e5 dette er tilstedev\u00e6relsen av programmer med synkron behandling av inngangshendelser. Fatin nevner et slikt tilfelle som eksempel. Workrave<\/a><\/noindex>, som legger til forsinkelse ved \u00e5 behandle alle input-hendelser synkront. Som standard leveres GNOME ogs\u00e5 med en vindusbehandling Mutter<\/a><\/noindex>, som skaper et ekstra lag av buffring, noe som p\u00e5virker ping og legger til minimum 8 millisekunders forsinkelse.<\/p>\n
\"En
\n<\/p>\n
Rullingshastighet<\/h4>\n
\nDen neste testen er en tradisjonell sjekk av \"hastighet\" eller \"b\u00e5ndbredde\", som m\u00e5ler hvor raskt terminalen kan rulle en side, mens den viser en stor mengde tekst p\u00e5 skjermen. Testmekanikken varierer; den originale testen besto i \u00e5 ganske enkelt generere den samme tekstlinjen ved hjelp av kommandoen seq. Andre tester inkluderer Thomas E. Dickeys sjekk (som f\u00f8lger med xterm), der en fil terminfo.src gjentatte ganger lastes ut<\/a><\/noindex>. I en annen ytelsestesting av terminaler Den Liu<\/a><\/noindex> bruker en linje med tilfeldige byte i base32-koding, som skrives ut til terminalen ved hjelp av cat. Liu anser en slik test for \u00e5 v\u00e6re \"s\u00e5 nyttel\u00f8s som det er mulig \u00e5 forestille seg\" og foresl\u00e5r \u00e5 bruke terminalresponsen som den prim\u00e6re meteren i stedet. Dickey anser ogs\u00e5 sin test for \u00e5 v\u00e6re misvisende. Likevel innr\u00f8mmer begge forfatterne at terminalvinduets b\u00e5ndbredde kan v\u00e6re et problem. Liu oppdaget at Emacs Eshell hang n\u00e5r han viste store filer, og Dickey optimaliserte terminalen for \u00e5 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\u00e5 brukes som en testkomponent for \u00e5 sjekke andre parametere.<\/p>\n
\"En
\n
\nHer ser vi at rxvt og st tar ledelsen i forhold til konkurrentene, etterfulgt av det betydelig nyere Alacritty, som er utviklet med fokus p\u00e5 ytelse. Deretter f\u00f8lger Xfce (VTE-familien) og Konsole, som fungerer nesten dobbelt s\u00e5 raskt. Sistnevnte er xterm, med en hastighet som er fem ganger tregere enn rxvt. Under testen var xterm ogs\u00e5 sv\u00e6rt uskarp, og det var vanskelig \u00e5 se teksten, selv om det var den samme linjen. Konsole viste seg \u00e5 v\u00e6re rask, men det \u00abjukset\u00bb tidvis: skjermen fr\u00f8s av og til, og viste deler av teksten eller klarte ikke \u00e5 vise den i det hele tatt. Andre terminaler viste linjene klart, inkludert st, Alacritty og rxvt.<\/p>\n
Diki forklarer at forskjellene i ytelse skyldes designet av rullebufferne i de ulike terminalene. Spesielt anklager han rxvt og andre terminaler for at de \u00abikke f\u00f8lger de generelle reglene\u00bb:<\/p>\n
\u00abI motsetning til xterm, pr\u00f8vde ikke rxvt \u00e5 vise alle oppdateringer. Hvis den henger etter, vil den ignorere noen oppdateringer for \u00e5 ta igjen det tapte. Dette hadde st\u00f8rre innvirkning p\u00e5 den tilsynelatende hastigheten p\u00e5 rullemekanismen enn p\u00e5 organiseringen av internminnet. En ulempe var at ASCII-animasjonen var noe un\u00f8yaktig.\u00bb<\/p><\/blockquote>\n
\nFor \u00e5 rette opp den tilsynelatende tregheten til xterm, foresl\u00e5r Diki \u00e5 bruke ressursen fastScroll<\/a><\/noindex>, som lar xterm kaste noen skjermoppdateringer for \u00e5 unng\u00e5 \u00e5 henge etter str\u00f8mmen. Mine tester bekrefter at fastScroll forbedrer ytelsen og bringer xterm opp p\u00e5 samme niv\u00e5 som rxvt. Det er imidlertid en ganske grov l\u00f8sning, som Diki selv forklarer: \u00abnoen ganger kan xterm \u2013 akkurat som konsole \u2013 se ut til \u00e5 stoppe, fordi den venter p\u00e5 en ny gruppe skjermoppdateringer etter at noen av dem er blitt fjernet\u00bb. I denne sammenhengen ser det ut til at andre terminaler har funnet den beste balansen mellom hastighet og skjermintegritet.<\/p>\n
Ressursforbruk<\/h4>\n
\nUavhengig av hvorvidt det er hensiktsmessig \u00e5 vurdere rullemekanismen som en prestasjonsindikator, lar denne testen oss simulere lasten p\u00e5 terminalene, noe som igjen gj\u00f8r oss i stand til \u00e5 m\u00e5le andre parametere, som minne- eller diskbruken. Metrikkene ble innhentet ved \u00e5 kj\u00f8re den angitte testen seq<\/b> under overv\u00e5king av Python-prosessen. Den samlet inn data fra tellerne getrusage ()<\/a><\/noindex> for ru_maxrss<\/b>, summen av ru_oublock<\/b> og ru_inblock<\/b> og en enkel tidtaker.<\/p>\n
\"En
\n
\nI denne testen tar ST f\u00f8rsteplass med det laveste gjennomsnittlige minneforbruket p\u00e5 8 MB, noe som ikke er overraskende gitt at prosjektets hovedid\u00e9 er enkelhet. Litt mer brukes av mlterm, xterm og rxvt \u2013 rundt 12 MB. Alacritty har ogs\u00e5 et merkbart resultat, med et minnebehov p\u00e5 30 MB. Deretter f\u00f8lger 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\u00f8yere niv\u00e5 biblioteker, som GTK. Konsole kommer til slutt med et kolossalt forbruk p\u00e5 65 MB under testene, selv om dette kan rettferdiggj\u00f8res med det omfattende funksjonssettet.<\/p>\n
Sammenlignet med resultatene fra for ti \u00e5r siden har alle programmene begynt \u00e5 bruke betydelig mer minne. Tidligere brukte Xterm 4 MB, men n\u00e5 krever det 15 MB bare for \u00e5 starte. En lignende \u00f8kning i forbruket er ogs\u00e5 observert hos rxvt, som n\u00e5 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\u00f8lgelig ble alle tidligere tester utf\u00f8rt p\u00e5 32-bits arkitektur. P\u00e5 LCA 2012, Rusty Russell fortalte<\/a><\/noindex>, er det mange finere grunner som kan forklare \u00f8kningen i minneforbruket. I alt dette lever vi n\u00e5 i en tid der vi har hele gigabyte med minne, s\u00e5 vi klarer oss.<\/p>\n
Likevel kan jeg ikke unng\u00e5 \u00e5 f\u00f8le at det \u00e5 tildele mer minne til s\u00e5 grunnleggende programvare som terminalen, er en bortkastet ressurs. Disse programmene b\u00f8r v\u00e6re de minste av de sm\u00e5, de b\u00f8r kunne fungere p\u00e5 hvilken som helst \"boks\", selv en skoeske, hvis vi noen gang kommer til det punktet hvor de m\u00e5 utstyres med Linux-systemer (og du vet at det vil skje). Men med disse tallene vil minneforbruket bli et problem i fremtiden n\u00e5r flere terminaler kj\u00f8res, bortsett fra i situasjoner med flere av de letteste og mest begrensede alternativene. For \u00e5 kompensere for dette har GNOME Terminal, Konsole, urxvt, Terminator og Xfce Terminal en Daemon-modus som lar deg kontrollere flere terminaler gjennom \u00e9n prosess, noe som begrenser minnebruken.<\/p>\n
\"En
\n
\nI l\u00f8pet av testene mine kom jeg til en annen overraskende konklusjon ang\u00e5ende disklesing og -skriving: Jeg forventet absolutt ikke \u00e5 finne noe her, men det viste seg at noen terminaler skriver de st\u00f8rste dataene til disken. Biblioteket VTE holder faktisk p\u00e5 disken en scroll-buffer (denne funksjonen ble lagt merke til allerede i 2010<\/a><\/noindex>, og dette skjer fortsatt). Men i motsetning til de eldre implementeringene, er n\u00e5, i det minste, disse dataene kryptert med AES256 GCM (siden versjon 0.39.2<\/a><\/noindex>). Men det oppst\u00e5r et rimelig sp\u00f8rsm\u00e5l: hva er s\u00e5 spesielt med biblioteket VTE, at det krever en slik uvanlig tiln\u00e6rming til implementeringen\u2026<\/p>\n
Konklusjon<\/h4>\n
\nI den f\u00f8rste delen av artikkelen oppdaget vi at terminaler basert p\u00e5 VTE har et godt sett av funksjoner, men n\u00e5 ser vi at dette er knyttet til noen kostnader for \u00e5 sikre ytelsen deres. For \u00f8yeblikket 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\u00e5 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\u00e5ndbredde-testing (scrolling), er forsinkelsen i \u00e5 vise data p\u00e5 skjermen over den etablerte terskelen i GNOME-brukermanualen. Det kan v\u00e6re lurt for VTE-utviklerne \u00e5 ta dette i betraktning. Gitt at selv for nybegynnere p\u00e5 Linux er m\u00f8tet med terminalen uunng\u00e5elig, kan de gj\u00f8re den mer brukervennlig. For erfarne entusiaster kan overgangen fra standardterminalen til og med bety mindre belastning p\u00e5 synet og mulighet til \u00e5 unng\u00e5 profesjonelle skader og helseproblemer i fremtiden p\u00e5 grunn av lange arbeidssesjoner. Dessverre f\u00f8rer bare de gamle xterm og mlterm oss til den magiske pingterskelen p\u00e5 10 millisekunder, noe som er uakseptabelt for mange.<\/p>\n
Kontrollm\u00e5lingene viste ogs\u00e5 at utviklingen av grafiske milj\u00f8er i Linux har f\u00e5tt utviklere til \u00e5 inng\u00e5 en rekke kompromisser. Noen brukere b\u00f8r vurdere de vanlige vindusbehandlerne, da de gir betydelig lavere ping. Dessverre klarte jeg ikke \u00e5 m\u00e5le forsinkelsen for Wayland: programmet Typometer, som jeg brukte, ble laget for \u00e5 hindre det Wayland er ment \u00e5 forhindre \u2013 overv\u00e5kning av andre vinduer. Jeg h\u00e5per at Waylands kompositing ytelsesmessig er bedre enn X.org, og jeg h\u00e5per ogs\u00e5 at noen i fremtiden finner en m\u00e5te \u00e5 vurdere forsinkelsesniv\u00e5et i dette milj\u00f8et.
\n
Kilde: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0430\u0440\u0430 \u0441\u043b\u043e\u0432 \u043e\u0442 \u043d\u0430\u0448\u0435\u0433\u043e translate-\u0431\u044e\u0440\u043e: \u043e\u0431\u044b\u0447\u043d\u043e \u0432\u0441\u0435 \u0441\u0442\u0440\u0435\u043c\u044f\u0442\u0441\u044f \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0438\u0442\u044c \u0441\u0430\u043c\u044b\u0435 \u0441\u0432\u0435\u0436\u0438\u0435 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u044b \u0438 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438, \u0438 \u043c\u044b \u043d\u0435 \u0438\u0441\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u0435. \u041d\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u0430\u043b\u044b \u2014 \u044d\u0442\u043e \u043d\u0435 \u0442\u043e, \u0447\u0442\u043e \u043e\u0431\u043d\u043e\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0440\u0430\u0437 \u0432 \u043d\u0435\u0434\u0435\u043b\u044e. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043c\u044b \u043f\u0435\u0440\u0435\u0432\u0435\u043b\u0438 \u0434\u043b\u044f \u0432\u0430\u0441 \u0441\u0442\u0430\u0442\u044c\u044e \u0410\u043d\u0442\u0443\u0430\u043d\u0430 \u0411\u043e\u043f\u0440\u0435, \u043e\u043f\u0443\u0431\u043b\u0438\u043a\u043e\u0432\u0430\u043d\u043d\u0443\u044e \u0432\u0435\u0441\u043d\u043e\u0439 2018 \u0433\u043e\u0434\u0430: \u043d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0441\u043e\u043b\u0438\u0434\u043d\u044b\u0439 \u043f\u043e \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u043c \u043c\u0435\u0440\u043a\u0430\u043c \u00ab\u0432\u043e\u0437\u0440\u0430\u0441\u0442\u00bb, \u043d\u0430 \u043d\u0430\u0448 \u0432\u0437\u0433\u043b\u044f\u0434, \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b \u0441\u043e\u0432\u0435\u0440\u0448\u0435\u043d\u043d\u043e \u043d\u0435 \u043f\u043e\u0442\u0435\u0440\u044f\u043b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27911,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37222","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Oversikt over terminalemulatorer | ProHoster","description":"Et par ord fra v\u00e5rt oversettelseskontor: vanligvis streber alle etter \u00e5 oversette de nyeste materialene og publikasjonene, og vi er ikke noe unntak. Men terminaler er ikke noe som oppdateres hver uke.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/obzor-emulyatorov-terminala","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0431\u0437\u043e\u0440 \u044d\u043c\u0443\u043b\u044f\u0442\u043e\u0440\u043e\u0432 \u0442\u0435\u0440\u043c\u0438\u043d\u0430\u043b\u0430 | ProHoster","og:description":"\u041f\u0430\u0440\u0430 \u0441\u043b\u043e\u0432 \u043e\u0442 \u043d\u0430\u0448\u0435\u0433\u043e translate-\u0431\u044e\u0440\u043e: \u043e\u0431\u044b\u0447\u043d\u043e \u0432\u0441\u0435 \u0441\u0442\u0440\u0435\u043c\u044f\u0442\u0441\u044f \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0438\u0442\u044c \u0441\u0430\u043c\u044b\u0435 \u0441\u0432\u0435\u0436\u0438\u0435 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u044b \u0438 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438, \u0438 \u043c\u044b \u043d\u0435 \u0438\u0441\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u0435. \u041d\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u0430\u043b\u044b \u2014 \u044d\u0442\u043e \u043d\u0435 \u0442\u043e, \u0447\u0442\u043e \u043e\u0431\u043d\u043e\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0440\u0430\u0437 \u0432 \u043d\u0435\u0434\u0435\u043b\u044e.","og:url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/obzor-emulyatorov-terminala","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:16:26+00:00","article:modified_time":"2019-10-31T19:16:26+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37222","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 16:48:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:31:24","updated":"2026-01-23 16:48:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/37222","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=37222"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/37222\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/27911"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=37222"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=37222"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=37222"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}