Noen få ord fra vårt oversettelsesbyrå: vanligvis streber alle etter å oversette det siste materialet og publikasjonene, og vi er intet unntak. Men terminaler er ikke noe som oppdateres en gang i uken. Derfor har vi oversatt for deg en artikkel av Antoine Beaupré, publisert våren 2018: til tross for sin betydelige "alder" etter moderne standarder, har materialet etter vår mening ikke mistet sin relevans i det hele tatt. I tillegg var dette opprinnelig en serie på to artikler, men vi bestemte oss for å slå dem sammen til ett stort innlegg.
Terminaler har en spesiell plass i datahistorien, men de siste tiårene har de blitt tvunget til å overleve ved siden av kommandolinjen ettersom grafiske grensesnitt blir allestedsnærværende. erstattet sine egne , som igjen var en modifikasjon av systemer basert på hullkort og vippebrytere. Moderne distribusjoner kommer med en rekke terminalemulatorer i alle former og farger. Og mens mange er fornøyd med standardterminalen som leveres av arbeidsmiljøet, bruker noen stolt eksotisk programvare for å kjøre favorittskall- eller tekstredigeringsprogrammet. Men, som vi vil se fra denne artikkelen, ble ikke alle terminaler laget i samme bilde: de er veldig forskjellige i funksjonalitet, størrelse og ytelse.
Noen terminaler har direkte overraskende sikkerhetshull, pluss at de fleste har et helt annet sett med funksjoner, fra støtte for et fanebasert grensesnitt til skripting. Selv om vi , denne artikkelen er en oppdatering av det forrige materialet som vil hjelpe leserne med å finne ut hvilken terminal de skal bruke i 2018. Den første halvdelen av artikkelen sammenligner funksjoner, og den andre halvdelen evaluerer ytelsen.
Her er terminalene jeg har vurdert:
Dette er kanskje ikke de nyeste versjonene, siden jeg var begrenset til stabile bygg i skrivende stund, som jeg var i stand til å rulle ut på Debian 9 eller Fedora 27. Det eneste unntaket er Alacritty. Det er en etterkommer av GPU-akselererte terminaler og er skrevet på et uvanlig og nytt språk for denne oppgaven - Rust. Jeg ekskluderte nettterminaler fra anmeldelsen min (inkludert de på ), fordi foreløpige tester viste deres ekstremt dårlige ytelse.
Unicode-støtte
Jeg startet testene mine med Unicode-støtte. Den første testen av terminalene var å vise Unicode-strengen fra : "é, Δ, И, K, م, ๗, あ, 叶, 葉 og 말." Denne enkle testen viser om terminalen kan fungere riktig over hele verden. xterm terminal viser ikke arabisk tegn i standardkonfigurasjon:
Som standard bruker xterm den klassiske «faste» fonten, som iht , har "betydelig Unicode-dekning siden 1997". Det er noe som skjer i denne fonten som gjør at tegnet vises som en tom ramme og det er først når tekstfonten økes til 20+ poeng at tegnet endelig begynner å vises riktig. Imidlertid bryter denne "fiksen" visningen av andre Unicode-tegn:
Disse skjermbildene ble tatt i Fedora 27, da det ga bedre resultater enn Debian 9, der noen eldre versjoner av terminaler (spesielt mlterm) ikke kunne håndtere fonter ordentlig. Heldigvis ble dette fikset i senere versjoner.
Legg nå merke til hvordan linjen vises i xterm. Det viser seg at symbolet Mem og følgende semittiske se skript i RTL-stil (), så teknisk sett bør de vises fra høyre til venstre. Nettlesere som Firefox 57 håndterer linjen ovenfor på riktig måte. En enklere versjon av RTL-tekst er ordet ""på hebraisk (). sier følgende:
"Mange dataprogrammer kan ikke vise toveis tekst på riktig måte. For eksempel består det hebraiske navnet "Sarah" av tegnene sin (ש) (som vises til høyre), deretter resh (ר) og til slutt han (ה) (som skal vises til venstre)."
Mange terminaler mislykkes i denne testen: Alacritty, VTE-avledede Gnome og XFCE terminaler, urxvt, st og xterm viser "Sara" i omvendt rekkefølge, som om vi hadde skrevet navnet som "Aras".
Et annet problem med toveis tekster er at de må justeres på en eller annen måte, spesielt når det gjelder å blande RTL- og LTR-tekster. RTL-skript skal kjøres fra høyre side av terminalvinduet, men hva skal skje for terminaler som har LTR-engelsk som standard? De fleste av dem har ingen spesielle mekanismer og justerer all tekst til venstre (inkludert i Konsole). Unntakene er pterm og mlterm, som følger standardene og høyrejusterer slike linjer.
Innsettingsbeskyttelse
Den neste kritiske funksjonen jeg har identifisert er anti-innsettingsbeskyttelse. Selv om det er allment kjent at staver som:
$ curl http://example.com/ | sher push-kommandoer for kjøring av kode, er det få som vet at skjulte kommandoer kan snike seg inn i konsollen når du kopierer og limer inn fra en nettleser, selv etter nøye inspeksjon. viser på en glimrende måte hvor ufarlig kommandoen er:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitblir til en slik plage når den limes inn fra Horns nettside inn i terminalen:
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.gitHvordan det fungerer? Skadelig kode er inkludert i blokken , som flyttes ut av brukerens visning ved hjelp av CSS.
er tydelig designet for å nøytralisere slike angrep. I denne modusen omslutter terminaler den limte teksten i et par spesielle escape-sekvenser for å fortelle skallet om opprinnelsen til teksten. Dette forteller skallet at det kan ignorere spesialtegn som den limte teksten kan inneholde. Alle terminaler tilbake til den ærverdige xterm støtter denne funksjonen, men liming i bracketed-modus krever støtte fra skallet eller applikasjonen som kjører på terminalen. For eksempel programvare som bruker (samme Bash), trenger en fil ~/.inputrc:
set enable-bracketed-paste onDessverre viser Horns testside også hvordan man kan omgå denne beskyttelsen gjennom selve tekstformateringen og for tidlig ender opp med å bruke bracketed-modus på den. Dette fungerer fordi noen terminaler ikke filtrerer escape-sekvenser riktig før de legger til sine egne. For eksempel, i min klarte jeg aldri å fullføre Konsole-testene selv med riktig konfigurasjon .inputrc fil. Dette betyr at du enkelt kan få systemkonfigurasjonen ødelagt på grunn av en applikasjon som ikke støttes eller et feilkonfigurert skall. Dette er spesielt farlig når du logger på eksterne servere, hvor nøye konfigurasjonsarbeid er mindre vanlig, spesielt hvis du har mange slike eksterne maskiner.
En god løsning på dette problemet er innlimingsbekreftelsesplugin for terminalen urxvt, som ganske enkelt ber om tillatelse til å sette inn tekst som inneholder nye linjer. Jeg har ikke funnet et sikrere alternativ for tekstangrepet beskrevet av Horn.
Faner og profiler
En populær funksjon nå er støtte for et fanebasert grensesnitt, som vi vil definere som ett terminalvindu som inneholder flere terminaler. Denne funksjonen er forskjellig for forskjellige terminaler, og selv om tradisjonelle xterm-terminaler ikke støtter faner i det hele tatt, har mer moderne terminalinkarnasjoner som Xfce Terminal, GNOME Terminal og Konsole denne funksjonen. Urxvt støtter også faner, men bare hvis du bruker en plugin. Men når det gjelder fanestøtte i seg selv, er Terminator den ubestridte lederen: den støtter ikke bare faner, men kan også arrangere terminaler i hvilken som helst rekkefølge (se bildet nedenfor).
En annen funksjon ved Terminator er muligheten til å "gruppere" disse fanene sammen og sende de samme tastetrykkene til flere terminaler samtidig, noe som gir et grovt verktøy for å utføre bulkoperasjoner på flere servere samtidig. En lignende funksjon er også implementert i Konsole. For å bruke denne funksjonen i andre terminaler må du bruke tredjepartsprogramvare som f.eks , eller .
Faner fungerer spesielt godt når de er sammenkoblet med profiler: du kan for eksempel ha én fane for e-post, en annen for chat, og så videre. Dette støttes godt av Konsole Terminal og GNOME Terminal. Begge lar hver fane automatisk starte sin egen profil. Terminator støtter også profiler, men jeg kunne ikke finne en måte å automatisk starte visse programmer når du åpner en bestemt fane. Andre terminaler har ikke konseptet "profil" i det hele tatt.
Volanger
Det siste jeg skal dekke i den første delen av denne artikkelen er utseendet til terminalene. For eksempel støtter GNOME, Xfce og urxvt åpenhet, men har nylig droppet støtte for bakgrunnsbilder, noe som tvinger noen brukere til å bytte til terminalen . Personlig er jeg fornøyd med det og det er enkelt Xressurser, som setter grunnsettet med bakgrunnsfarger for urxvt. Ikke-standard fargetemaer kan imidlertid også skape problemer. For eksempel, med søknader и , siden de allerede bruker sine egne farger.
støttet ikke farger, og nye ble ofte begrenset til en palett med 256 farger. For avanserte brukere som stiler terminalene sine, kan shell-meldinger eller statuslinjer på komplekse måter være en irriterende begrensning. sporer hvilke terminaler som har "True Color"-støtte. Testene mine bekrefter at st, Alacritty og VTE-baserte terminaler støtter True Color perfekt. Andre terminaler har det ikke særlig bra i denne forbindelse og viser faktisk ikke engang 256 farger. Nedenfor kan du se forskjellen mellom True Color-støtte i GNOME-terminaler, st og xterm, som gjør en god jobb med dette med sin 256 fargepalett, og urxvt, som ikke bare mislykkes i testen, men til og med viser noen blinkende tegn i stedet for dem.
Noen terminaler analyserer også tekst for URL-mønstre for å gjøre koblinger klikkbare. Dette gjelder alle VTE-avledede terminaler, mens urxvt krever en spesiell plugin som vil transformere URL-er ved et klikk eller ved å bruke en hurtigtast. Andre terminaler jeg har testet visningsadresser på andre måter.
Til slutt, en ny trend innen terminaler er valgmuligheten til rullebufferen. For eksempel har st ingen rullebuffer; det antas at brukeren vil bruke en terminal multiplekser som tmux og .
Alacritty mangler også backscroll-buffere, men sin støtte på grunn av "omfattende tilbakemeldinger" om dette emnet fra brukere. Bortsett fra disse oppkomlingene, støtter hver terminal jeg har testet som jeg kunne finne omvendt rulling.
delsummer
I den andre delen av materialet (i originalen var dette to forskjellige artikler - ca. kjørefelt) vil vi sammenligne ytelse, minnebruk og ventetid. Men vi kan allerede nå se at noen av de aktuelle terminalene har alvorlige mangler. For eksempel kan brukere som regelmessig jobber med RTL-skript vurdere mlterm og pterm, da de er flinkere til å håndtere lignende oppgaver enn andre. Konsole presterte også bra. Brukere som ikke jobber med RTL-skript kan velge noe annet.
Når det gjelder beskyttelse mot ondsinnet kodeinnsetting, skiller urxvt seg ut på grunn av sin spesielle implementering av beskyttelse mot denne typen angrep, noe som virker definitivt praktisk for meg. For de som leter etter noen bjeller og fløyter, er Konsole verdt en titt. Til slutt er det verdt å merke seg at VTE er en utmerket base for terminaler, som garanterer fargestøtte, URL-gjenkjenning og så videre. Ved første øyekast kan standardterminalen som følger med favorittmiljøet ditt oppfylle alle kravene, men la oss la dette spørsmålet stå åpent til vi forstår ytelsen.
La oss fortsette samtalen
Generelt kan ytelsen til terminaler i seg selv virke som et langsøkt problem, men som det viser seg, viser noen av dem overraskende høy latenstid for programvare av en så grunnleggende type. Deretter vil vi også se på det som tradisjonelt kalles "hastighet" (faktisk er dette rullehastigheten) og minneforbruket til terminalen (med forbehold om at dette ikke er like kritisk i dag som det var for tiår siden).
Forsinkelse
Etter en grundig studie av terminalytelse, kom jeg til den konklusjonen at den viktigste parameteren i denne forbindelse er latensen (ping). I artikkelen hans Pavel Fatin så på latensen til forskjellige tekstredigerere og antydet at terminaler i denne forbindelse kan være tregere enn de raskeste tekstredigererne. Det var dette hintet som til slutt førte meg til å kjøre mine egne tester og skrive denne artikkelen.
Men hva er latens, og hvorfor er det så viktig? I artikkelen sin definerte Fatin det som "forsinkelsen mellom å trykke på en tast og den tilsvarende skjermoppdateringen" og siterte , som sier: "Forsinkelsen i visuell tilbakemelding på en dataskjerm har en viktig innvirkning på maskinskriverens oppførsel og tilfredshet."
Fatin forklarer at denne pingen har dypere konsekvenser enn bare tilfredsstillelse: "skrivingen blir tregere, flere feil oppstår, og øye- og muskelspenningene øker." Med andre ord kan en stor forsinkelse føre til skrivefeil og også lavere kodekvalitet, da det fører til ytterligere kognitiv belastning på hjernen. Men det som er verre er at ping «øker belastning på øyne og muskler», noe som ser ut til å antyde i fremtiden (Tilsynelatende mener forfatteren problemer med musklene i øynene, ryggen, armene og selvfølgelig synet - ca. kjørefelt) på grunn av gjentatt stress.
Noen av disse effektene har vært kjent i lang tid, og resultatene , publisert tilbake i 1976 i tidsskriftet Ergonomics, sa at en forsinkelse på 100 millisekunder "betraktelig svekker skrivehastigheten." Mer nylig introduserte GNOME-brukerveiledningen på 10 millisekunder, og hvis du går lenger, da viser at 1 millisekund er ideelt.
Fatin gjennomførte sine tester på tekstredigerere; han laget et bærbart instrument kalt , som jeg brukte til å teste ping i terminalemulatorer. Husk at testen ble utført i simuleringsmodus: i virkeligheten må vi ta hensyn til både inngang (tastatur, USB-kontroller, etc.) og utgang (skjermkortbuffer, skjerm) latens. Ifølge Fatin er det i typiske konfigurasjoner omtrent 20 ms. Hvis du har spillutstyr, kan du oppnå dette tallet på bare 3 millisekunder. Siden vi allerede har så rask maskinvare, trenger ikke applikasjonen legge til sin egen ventetid. Fatins mål er å bringe applikasjonsforsinkelsen til 1 millisekund, eller til og med oppnå oppringing uten , hvordan i .
Her er resultatene av målingene mine, samt noen av Fatins resultater, for å vise at eksperimentet mitt stemmer overens med testene hans:
Det første som slo meg var den bedre responstiden til eldre programmer som xterm og mlterm. Med dårligst registerlatens (2,4 ms) presterte de bedre enn den raskeste moderne terminalen (10,6 ms for st). Ingen moderne terminal faller under terskelen på 10 millisekunder. Spesielt klarer ikke Alacritty å oppfylle kravet om "raskeste terminalemulator som er tilgjengelig", selv om poengsummen har forbedret seg siden den første gjennomgangen i 2017. Faktisk forfatterne av prosjektet og jobber med å forbedre skjermen. Det skal også bemerkes at Vim som bruker GTK3 er en størrelsesorden langsommere enn GTK2-motstykket. Fra dette kan vi konkludere med at GTK3 skaper ekstra ventetid, og dette gjenspeiles i alle andre terminaler som bruker den (Terminator, Xfce4 Terminal og GNOME Terminal).
Det kan imidlertid hende at forskjellene ikke er merkbare for øyet. Som Fatin forklarer, "du trenger ikke å være klar over forsinkelsen for at det skal ha en effekt på deg." Fatin advarer også om standardavvik: "enhver forstyrrelse i latens (jitter) skaper ekstra stress på grunn av deres uforutsigbarhet."
Grafen over er tatt på ren Debian 9 (strekk) med . Dette miljøet gir de beste resultatene i latenstidstester. Som det viser seg, oppretter GNOME ytterligere 20 ms ping for alle målinger. En mulig forklaring på dette er tilstedeværelsen av programmer med synkron behandling av inngangshendelser. Fatin gir et eksempel for et slikt tilfelle , som legger til en forsinkelse ved å behandle alle inndatahendelser synkront. Som standard kommer GNOME også med en vindusbehandler , som skaper et ekstra lag med bufring, som påvirker ping og legger til minst 8 millisekunders ventetid.
Rullehastighet
Neste test er en tradisjonell "hastighet" eller "båndbredde"-test, som måler hvor raskt terminalen kan rulle en side mens den viser store mengder tekst på skjermen. Mekanikken i testen varierer; den opprinnelige testen var å ganske enkelt generere den samme tekststrengen ved å bruke seq-kommandoen. Andre tester inkluderer Thomas E. Dickeys (xterm vedlikeholder) test, som gjentatte ganger . I en annen gjennomgang av terminalytelse bruker en base32-kodet streng med tilfeldige byte, som sendes ut til terminalen ved hjelp av cat. Luu anser en slik test for å være "så ubrukelig en målestokk som man kan forestille seg" og foreslår å bruke terminalrespons som en primær metrikk i stedet. Dickey kaller også testen for misvisende. Begge forfatterne erkjenner imidlertid at terminalvinduets båndbredde kan være et problem. Luu oppdaget at Emacs Eshell fryser ved visning av store filer, og Dickey optimaliserte terminalen for å bli kvitt xtrerms visuelle treghet. Så det er fortsatt noen fordeler med denne testen, men siden gjengivelsesprosessen er veldig forskjellig fra terminal til terminal, kan den også brukes som en testkomponent for å teste andre parametere.
Her ser vi rxvt og st trekke foran konkurrentene, etterfulgt av den mye nyere Alacritty, som er designet med fokus på ytelse. Neste er Xfce (VTE-familie) og Konsole, som er nesten dobbelt så raske. Sist er xterm, som er fem ganger langsommere enn rxvt. Under testen bølget xterm også mye, noe som gjorde det vanskelig å se å sende tekst selv om det var samme linje. Konsole var rask, men det var vanskelig til tider: skjermen fryser fra tid til annen, viser delvis tekst eller viser den ikke i det hele tatt. Andre terminaler viste strenger tydelig, inkludert st, Alacritty og rxvt.
Dickey forklarer at ytelsesforskjellene skyldes utformingen av rullebuffere i forskjellige terminaler. Spesielt anklager han rxvt og andre terminaler for å "ikke følge de generelle reglene":
"I motsetning til xterm, forsøkte ikke rxvt å vise alle oppdateringer. Hvis den faller bak, vil den nekte noen oppdateringer å ta igjen. Dette hadde større innvirkning på den tilsynelatende rullehastigheten enn på organiseringen av internminnet. En ulempe var at ASCII-animasjonen var noe upresis."
For å fikse denne oppfattede tregheten, foreslår Dickey å bruke ressursen , slik at xterm kan forkaste noen skjermoppdateringer for å holde tritt med flyten. Testene mine bekrefter at fastScroll forbedrer ytelsen og bringer xterm på nivå med rxvt. Dette er imidlertid en ganske grov krykke, som Dickey selv forklarer: "noen ganger ser det ut til at xterm - som konsole - går i stå mens den venter på et nytt sett med skjermoppdateringer etter at noen har blitt fjernet." På denne måten ser det ut til at andre terminaler har funnet det beste kompromisset mellom hastighet og skjermintegritet.
Ressursforbruk
Uansett om det er fornuftig å vurdere rullehastighet som en ytelsesmåling, lar denne testen oss simulere belastningen på terminalene, som igjen lar oss måle andre parametere som minne eller diskbruk. Beregningene ble oppnådd ved å kjøre den spesifiserte testen seq under Python-prosessovervåking. Han samlet målerdata for ru_maxrss, beløp ru_oublock и ru_inblock og en enkel timer.
I denne testen tar ST førsteplassen med det laveste gjennomsnittlige minneforbruket på 8 MB, noe som ikke er overraskende med tanke på at hovedideen med designet er enkelhet. mlterm, xterm og rxvt bruker litt mer - ca 12 MB. Et annet bemerkelsesverdig resultat er Alacritty, som krever 30 MB for å kjøre. Så er det terminaler i VTE-familien med tall fra 40 til 60 MB, som er ganske mye. Dette forbruket kan forklares med det faktum at disse terminalene bruker biblioteker på høyere nivå, for eksempel GTK. Konsole kommer sist med hele 65 MB minneforbruk under tester, selv om dette kan rettferdiggjøres av dets svært brede spekter av funksjoner.
Sammenlignet med tidligere resultater oppnådd for ti år siden, begynte alle programmer å bruke merkbart mer minne. Xterm pleide å kreve 4 MB, men nå krever det 15 MB bare ved oppstart. Det er en tilsvarende økning i forbruket for rxvt, som nå krever 16 MB ut av esken. Xfce Terminal tar opp 34 MB, som er tre ganger større enn før, men GNOME Terminal krever bare 20 MB. Selvfølgelig ble alle tidligere tester utført på 32-bits arkitektur. På LCA 2012 Rusty Russell , at det er mange flere subtile grunner som kan forklare økningen i minneforbruk. Når det er sagt, lever vi nå i en tid hvor vi har gigabyte med minne, så vi klarer oss på en eller annen måte.
Jeg kan imidlertid ikke unngå å føle at det å tildele mer minne til noe så grunnleggende som terminalen er bortkastet ressurser. Disse programmene bør være de minste av de minste, bør kunne kjøres på hvilken som helst "boks", til og med en skoeske, hvis vi noen gang kommer til det punktet hvor de må utstyres med Linux-systemer (og du vet at det vil være slik ). Men med disse tallene vil minnebruk bli et problem i fremtiden i ethvert miljø som kjører flere terminaler bortsett fra noen få av de letteste og mest begrensede mulighetene. For å kompensere for dette har GNOME Terminal, Konsole, urxvt, Terminator og Xfce Terminal en Daemon-modus som lar deg kontrollere flere terminaler gjennom en enkelt prosess, noe som begrenser minneforbruket deres.
Under testene mine kom jeg til et annet uventet resultat angående disk lese-skriving: Jeg forventet ikke å se noe i det hele tatt her, men det viste seg at noen terminaler skriver de mest omfangsrike dataene til disken. Så VTE-biblioteket holder faktisk en rullebuffer på disken (denne funksjonen , og dette skjer fortsatt). Men i motsetning til eldre implementeringer, er nå i det minste disse dataene kryptert med AES256 GCM (). Men et rimelig spørsmål dukker opp: hva er så spesielt med VTE-biblioteket at det krever en så ikke-standard tilnærming til implementering...
Konklusjon
I den første delen av artikkelen fant vi ut at VTE-baserte terminaler har et godt sett med funksjoner, men nå ser vi at dette kommer med noen ytelseskostnader. Nå er ikke minne et problem fordi alle VTE-terminaler kan kontrolleres gjennom en Daemon-prosess, som begrenser appetitten deres. Imidlertid kan eldre systemer som har fysiske begrensninger på mengden RAM og kjernebuffere fortsatt trenge tidligere versjoner av terminaler, siden de bruker betydelig færre ressurser. Selv om VTE-terminaler presterte bra i gjennomstrømnings- (rulling)-tester, er visningsforsinkelsen deres over terskelen angitt i GNOME-brukerveiledningen. VTE-utviklere bør nok ta hensyn til dette. Hvis vi tar i betraktning at selv for nybegynnere av Linux-brukere å møte en terminal er uunngåelig, kan de gjøre den mer brukervennlig. For erfarne nerder kan bytte fra standardterminalen til og med bety mindre belastning på øynene og muligheten til å unngå fremtidige arbeidsrelaterte skader og sykdommer på grunn av lange arbeidsøkter. Dessverre er det bare de gamle xterm og mlterm som bringer oss til den magiske ping-terskelen på 10 millisekunder, noe som er uakseptabelt for mange.
Benchmark-målinger viste også at på grunn av utviklingen av Linux grafiske miljøer, måtte utviklere inngå en rekke kompromisser. Noen brukere vil kanskje se på vanlige vindusbehandlere da de gir betydelig ping-reduksjon. Dessverre var det ikke mulig å måle latens for Wayland: Typometer-programmet jeg brukte ble laget for det Wayland er designet for å forhindre: spionere på andre vinduer. Jeg håper at Wayland compositing yter bedre enn X.org, og jeg håper også at noen i fremtiden vil finne en måte å måle latens i dette miljøet.
Kilde: www.habr.com