Et par ord fra vores oversættelsesbureau: Normalt bestræber alle sig på at oversætte de nyeste materialer og publikationer, og vi er ingen undtagelse. Men terminaler er ikke noget, der opdateres en gang om ugen. Derfor har vi for dig oversat en artikel af Antoine Beaupré, udgivet i foråret 2018: På trods af dens betydelige "alder" efter moderne standarder, har materialet efter vores mening slet ikke mistet sin relevans. Derudover var dette oprindeligt en serie på to artikler, men vi besluttede at samle dem til ét stort indlæg.
Terminaler har en særlig plads i computerhistorien, men i de seneste årtier er de blevet tvunget til at overleve ved siden af kommandolinjen, da grafiske grænseflader bliver allestedsnærværende. erstattet deres egne , som igen var en modifikation af systemer baseret på hulkort og vippekontakter. Moderne distributioner kommer med en række terminalemulatorer i alle former og farver. Og selvom mange er tilfredse med standardterminalen fra deres arbejdsmiljø, bruger nogle stolt eksotisk software til at køre deres foretrukne shell eller teksteditor. Men som vi vil se fra denne artikel, blev ikke alle terminaler skabt i det samme billede: de adskiller sig meget i funktionalitet, størrelse og ydeevne.
Nogle terminaler har ligefrem overraskende sikkerhedshuller, plus de fleste har et helt andet sæt funktioner, fra understøttelse af en fanebaseret grænseflade til scripting. Selvom vi , denne artikel er en opdatering af det tidligere materiale, der vil hjælpe læserne med at bestemme, hvilken terminal de skal bruge i 2018. Den første halvdel af artiklen sammenligner funktioner, og den anden halvdel evaluerer ydeevnen.
Her er de terminaler, jeg har gennemgået:
Det er måske ikke de nyeste versioner, da jeg var begrænset til stabile builds i skrivende stund, som jeg var i stand til at udrulle på Debian 9 eller Fedora 27. Den eneste undtagelse er Alacritty. Det er en efterkommer af GPU-accelererede terminaler og er skrevet i et usædvanligt og nyt sprog til denne opgave - Rust. Jeg udelukkede webterminaler fra min anmeldelse (inklusive dem på ), fordi foreløbige test viste deres ekstremt dårlige ydeevne.
Unicode-understøttelse
Jeg startede mine tests med Unicode-understøttelse. Den første test af terminalerne var at vise Unicode-strengen fra : "é, Δ, И, K, م, ๗, あ, 叶, 葉 og 말." Denne simple test viser, om terminalen kan fungere korrekt på verdensplan. xterm terminal viser ikke arabisk tegn i standard konfiguration:
Som standard bruger xterm den klassiske "faste" skrifttype, som iflg , har "væsentlig Unicode-dækning siden 1997". Der sker noget i denne skrifttype, der får tegnet til at fremstå som en tom ramme, og det er først når tekstfonten øges til 20+ punkter, at tegnet endelig begynder at blive vist korrekt. Denne "fix" bryder dog visningen af andre Unicode-tegn:
Disse skærmbilleder blev taget i Fedora 27, da det gav bedre resultater end Debian 9, hvor nogle ældre versioner af terminaler (specifikt mlterm) ikke kunne håndtere skrifttyper korrekt. Heldigvis blev dette rettet i senere versioner.
Bemærk nu, hvordan linjen vises i xterm. Det viser sig, at symbolet Mem og den følgende semitiske se scripts i RTL-stil (), så teknisk set bør de vises fra højre mod venstre. Webbrowsere såsom Firefox 57 håndterer ovenstående linje korrekt. En enklere version af RTL-tekst er ordet ""på hebraisk (). siger følgende:
"Mange computerprogrammer kan ikke vise tovejstekst korrekt. For eksempel består det hebraiske navn "Sarah" af tegnene sin (ש) (som vises til højre), derefter resh (ר) og til sidst han (ה) (som skal vises til venstre)."
Mange terminaler fejler denne test: Alacritty, VTE-afledte Gnome og XFCE terminaler, urxvt, st og xterm viser "Sara" i omvendt rækkefølge, som om vi havde skrevet navnet som "Aras".
Et andet problem med tovejstekster er, at de skal justeres på en eller anden måde, især når det kommer til at blande RTL- og LTR-tekster. RTL-scripts skal køre fra højre side af terminalvinduet, men hvad skal der ske for terminaler, der som standard er LTR-engelsk? De fleste af dem har ingen specielle mekanismer og justerer al tekst til venstre (inklusive i Konsole). Undtagelserne er pterm og mlterm, som overholder standarderne og højrejusterer sådanne linjer.
Indføringsbeskyttelse
Den næste kritiske funktion, jeg har identificeret, er anti-indsættelsesbeskyttelse. Selvom det er almindeligt kendt, at besværgelser som:
$ curl http://example.com/ | sher push-kommandoer til udførelse af kode, er det de færreste, der ved, at skjulte kommandoer kan snige sig ind i konsollen, når du kopierer og indsætter fra en webbrowser, selv efter omhyggelig inspektion. viser på glimrende vis, hvor uskyldigt udseende kommandoen er:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitbliver til sådan en gene, når den indsættes fra Horns hjemmeside 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 virker? Ondsindet kode er inkluderet i blokken , som flyttes ud af brugerens visning ved hjælp af CSS.
er klart designet til at neutralisere sådanne angreb. I denne tilstand omslutter terminaler den indsatte tekst i et par specielle escape-sekvenser for at fortælle skallen om tekstens oprindelse. Dette fortæller skallen, at den kan ignorere specialtegn, som den indsatte tekst kan indeholde. Alle terminaler tilbage til den ærværdige xterm understøtter denne funktion, men indsættelse i bracketed-tilstand kræver support fra shellen eller applikationen, der kører på terminalen. For eksempel software ved hjælp af (samme Bash), har brug for en fil ~/.inputrc:
set enable-bracketed-paste onDesværre viser Horns testside også, hvordan man omgår denne beskyttelse gennem selve tekstformateringen og for tidligt ender med at anvende Bracketed-tilstand på den. Dette virker, fordi nogle terminaler ikke filtrerer escape-sekvenser korrekt, før de tilføjer deres egne. For eksempel, i min var jeg aldrig i stand til at fuldføre Konsole-testene, selv med den korrekte konfiguration .inputrc fil. Det betyder, at du nemt kan få din systemkonfiguration ødelagt på grund af en ikke-understøttet applikation eller en forkert konfigureret skal. Dette er især farligt, når du logger på fjernservere, hvor omhyggeligt konfigurationsarbejde er mindre almindeligt, især hvis du har mange sådanne fjernmaskiner.
En god løsning på dette problem er indsæt-bekræftelsesplugin til terminalen urxvt, som blot beder om tilladelse til at indsætte enhver tekst, der indeholder nye linjer. Jeg har ikke fundet en mere sikker mulighed for tekstangrebet beskrevet af Horn.
Faner og profiler
En populær funktion lige nu er understøttelse af en fanebaseret grænseflade, som vi vil definere som ét terminalvindue, der indeholder flere andre terminaler. Denne funktion er forskellig for forskellige terminaler, og selvom traditionelle xterm-terminaler slet ikke understøtter faner, har mere moderne terminalinkarnationer som Xfce Terminal, GNOME Terminal og Konsole denne funktion. Urxvt understøtter også faner, men kun hvis du bruger et plugin. Men med hensyn til faneunderstøttelse i sig selv er Terminator den ubestridte leder: den understøtter ikke kun faner, men kan også arrangere terminaler i enhver rækkefølge (se billedet nedenfor).
En anden funktion ved Terminator er evnen til at "gruppere" disse faner sammen og sende de samme tastetryk til flere terminaler på samme tid, hvilket giver et råt værktøj til at udføre bulk-operationer på flere servere samtidigt. En lignende funktion er også implementeret i Konsole. For at bruge denne funktion i andre terminaler skal du bruge tredjepartssoftware som f.eks , eller .
Faner fungerer særligt godt, når de er parret med profiler: Du kan f.eks. have én fane til e-mail, en anden til chat og så videre. Dette er godt understøttet af Konsole Terminal og GNOME Terminal. Begge tillader hver fane automatisk at starte sin egen profil. Terminator understøtter også profiler, men jeg kunne ikke finde en måde til automatisk at starte visse programmer, når du åbner en bestemt fane. Andre terminaler har slet ikke begrebet "profil".
Flæser
Den sidste ting, jeg vil dække i den første del af denne artikel, er terminalernes udseende. For eksempel understøtter GNOME, Xfce og urxvt gennemsigtighed, men har for nylig droppet understøttelse af baggrundsbilleder, hvilket tvinger nogle brugere til at skifte til terminalen . Personligt er jeg glad for det, og det er enkelt xressourcer, som indstiller basissættet af baggrundsfarver for urxvt. Ikke-standard farvetemaer kan dog også skabe problemer. For eksempel, med ansøgninger и , da de allerede bruger deres egne farver.
understøttede ikke farver, og nye var ofte begrænset til en palet med 256 farver. For avancerede brugere, der style deres terminaler, kan shell-prompter eller statuslinjer på komplekse måder være en irriterende begrænsning. spor, hvilke terminaler der understøtter "True Color". Mine test bekræfter, at st, Alacritty og VTE-baserede terminaler understøtter True Color perfekt. Andre terminaler klarer sig ikke særlig godt i denne henseende og viser faktisk ikke engang 256 farver. Nedenfor kan du se forskellen mellem True Color-understøttelse i GNOME-terminaler, st og xterm, som gør et godt stykke arbejde med dette med deres 256 farvepalet, og urxvt, som ikke kun fejler testen, men endda viser nogle blinkende tegn i stedet for dem.
Nogle terminaler analyserer også tekst for URL-mønstre for at gøre links klikbare. Dette gælder for alle VTE-afledte terminaler, mens urxvt kræver et specielt plugin, der vil transformere URL'er ved et klik eller ved at bruge en tastaturgenvej. Andre terminaler Jeg har testet annoncerede URL'er på andre måder.
Endelig er en ny trend inden for terminaler muligheden for rullebufferen. For eksempel har st ingen rullebuffer; det antages, at brugeren vil bruge en terminal multiplexer som tmux og .
Alacritty mangler også backscroll-buffere, men dets støtte på grund af "omfattende feedback" om dette emne fra brugere. Bortset fra disse opkomlinge understøtter hver terminal, jeg har testet, som jeg kunne finde, omvendt scrolling.
subtotaler
I anden del af materialet (i originalen var der tale om to forskellige artikler - ca. bane) vil vi sammenligne ydeevne, hukommelsesforbrug og latens. Men vi kan allerede nu se, at nogle af de pågældende terminaler har alvorlige mangler. For eksempel kan brugere, der regelmæssigt arbejder med RTL-scripts, overveje mlterm og pterm, da de er bedre til at håndtere lignende opgaver end andre. Konsole klarede sig også godt. Brugere, der ikke arbejder med RTL-scripts, kan vælge noget andet.
Med hensyn til beskyttelse mod indsættelse af ondsindet kode, skiller urxvt sig ud på grund af dens særlige implementering af beskyttelse mod denne type angreb, hvilket synes bestemt praktisk for mig. For dem, der leder efter nogle klokker og fløjter, er Konsole et kig værd. Endelig er det værd at bemærke, at VTE er en fremragende base for terminaler, som garanterer farveunderstøttelse, URL-genkendelse og så videre. Ved første øjekast kan standardterminalen, der følger med dit yndlingsmiljø, opfylde alle kravene, men lad os lade dette spørgsmål stå åbent, indtil vi forstår ydeevnen.
Lad os fortsætte samtalen
Generelt kan terminalernes ydeevne i sig selv virke som et langt ude problem, men som det viser sig, udviser nogle af dem overraskende høj latenstid for software af en så fundamental type. Herefter vil vi også se på det, der traditionelt kaldes "hastighed" (faktisk er dette rullehastigheden) og hukommelsesforbruget for terminalen (med det forbehold, at dette ikke er så kritisk i dag, som det var for årtier siden).
forsinkelse
Efter en grundig undersøgelse af terminalydelsen kom jeg til den konklusion, at den vigtigste parameter i denne forbindelse er latensen (ping). I hans artikel Pavel Fatin kiggede på forsinkelsen af forskellige teksteditorer og antydede, at terminaler i denne henseende kan være langsommere end de hurtigste teksteditorer. Det var dette tip, der i sidste ende førte mig til at køre mine egne tests og skrive denne artikel.
Men hvad er latency, og hvorfor er det så vigtigt? I sin artikel definerede Fatin det som "forsinkelsen mellem at trykke på en tast og den tilsvarende skærmopdatering" og citerede , som siger: "Forsinkelsen i visuel feedback på en computerskærm har en vigtig indflydelse på maskinskriverens adfærd og tilfredshed."
Fatin forklarer, at dette ping har dybere konsekvenser end blot tilfredshed: "at skrive bliver langsommere, flere fejl opstår, og øjen- og muskelspændinger stiger." En stor forsinkelse kan med andre ord føre til slåfejl og også lavere kodekvalitet, da det fører til yderligere kognitiv belastning af hjernen. Men hvad værre er, at ping "øger øjen- og muskelbelastning", hvilket synes at antyde i fremtiden (Tilsyneladende mener forfatteren problemer med musklerne i øjnene, ryggen, armene og selvfølgelig synet - ca. bane) på grund af gentagen stress.
Nogle af disse virkninger har været kendt i lang tid, og resultaterne , udgivet tilbage i 1976 i tidsskriftet Ergonomics, sagde, at en forsinkelse på 100 millisekunder "forringer skrivehastigheden væsentligt." For nylig blev GNOME-brugervejledningen introduceret på 10 millisekunder, og hvis du går længere, så viser, at 1 millisekund er ideelt.
Fatin udførte sine tests på teksteditorer; han skabte et bærbart instrument kaldet , som jeg brugte til at teste ping i terminalemulatorer. Husk, at testen blev udført i simuleringstilstand: i virkeligheden skal vi tage hensyn til både input (tastatur, USB-controller osv.) og output (videokortbuffer, skærm) latens. Ifølge Fatin er det i typiske konfigurationer omkring 20 ms. Hvis du har spilleudstyr, kan du opnå dette tal på kun 3 millisekunder. Da vi allerede har så hurtig hardware, behøver applikationen ikke at tilføje sin egen latenstid. Fatins mål er at bringe applikationens latens til 1 millisekund eller endda opnå opkald uden , hvordan i .
Her er resultaterne af mine målinger, samt nogle af Fatins resultater, for at vise, at mit eksperiment stemmer overens med hans tests:
Det første, der slog mig, var den bedre responstid for ældre programmer som xterm og mlterm. Med den dårligste registerlatens (2,4 ms) klarede de sig bedre end den hurtigste moderne terminal (10,6 ms for st). Ingen moderne terminal falder under tærsklen på 10 millisekunder. Især klarer Alacritty ikke at opfylde kravet om "hurtigste terminalemulator til rådighed", selvom dets score er forbedret siden dens første anmeldelse i 2017. Faktisk forfatterne af projektet og arbejder på at forbedre skærmen. Det skal også bemærkes, at Vim, der bruger GTK3, er en størrelsesorden langsommere end dens GTK2-modstykke. Ud fra dette kan vi konkludere, at GTK3 skaber yderligere latency, og dette afspejles i alle andre terminaler, der bruger det (Terminator, Xfce4 Terminal og GNOME Terminal).
Forskellene er dog muligvis ikke mærkbare for øjet. Som Fatin forklarer, "du behøver ikke at være opmærksom på forsinkelsen for at det har en effekt på dig." Fatin advarer også om standardafvigelse: "enhver forstyrrelse i latens (jitter) skaber yderligere stress på grund af deres uforudsigelighed."
Grafen ovenfor er taget på ren Debian 9 (stretch) med . Dette miljø giver de bedste resultater i latenstest. Som det viser sig, opretter GNOME et ekstra ping på 20 ms for alle målinger. En mulig forklaring på dette er tilstedeværelsen af programmer med synkron behandling af inputhændelser. Fatin giver et eksempel på sådan en sag , som tilføjer en forsinkelse ved at behandle alle inputhændelser synkront. Som standard kommer GNOME også med en vindueshåndtering , som skaber et ekstra lag af buffering, som påvirker ping og tilføjer mindst 8 millisekunders latenstid.
Scrollhastighed
Den næste test er en traditionel "hastighed" eller "båndbredde" test, som måler, hvor hurtigt terminalen kan rulle en side, mens den viser store mængder tekst på skærmen. Mekanikken i testen varierer; den oprindelige test var simpelthen at generere den samme tekststreng ved hjælp af kommandoen seq. Andre test inkluderer Thomas E. Dickeys (xterm vedligeholder) test, som gentagne gange . I en anden gennemgang af terminalens ydeevne bruger en base32-kodet streng af tilfældige bytes, som udsendes til terminalen ved hjælp af kat. Luu anser en sådan test for at være "et så ubrugeligt benchmark, som man kan forestille sig", og foreslår i stedet at bruge terminalrespons som en primær metrik. Dickey kalder også sin test for vildledende. Begge forfattere anerkender dog, at terminalvinduets båndbredde kan være et problem. Luu opdagede, at Emacs Eshell fryser, når store filer blev vist, og Dickey optimerede terminalen for at slippe af med xtrerms visuelle træghed. Så der er stadig en vis fordel ved denne test, men da gengivelsesprocessen er meget forskellig fra terminal til terminal, kan den også bruges som en testkomponent til at teste andre parametre.
Her ser vi rxvt og st trække foran konkurrenterne, efterfulgt af den meget nyere Alacritty, som er designet med fokus på ydeevne. Dernæst er Xfce (VTE-familien) og Konsole, som er næsten dobbelt så hurtige. Sidst er xterm, som er fem gange langsommere end rxvt. Under testen bølgede xterm også meget, hvilket gjorde det svært at se, selvom det var den samme linje, at sende tekst. Konsole var hurtig, men det var til tider vanskeligt: Displayet fryser fra tid til anden, viser delvis tekst eller viser det slet ikke. Andre terminaler viste strenge tydeligt, inklusive st, Alacritty og rxvt.
Dickey forklarer, at ydelsesforskellene skyldes designet af rullebuffere i forskellige terminaler. Især anklager han rxvt og andre terminaler for at "ikke følge de generelle regler":
"I modsætning til xterm forsøgte rxvt ikke at vise alle opdateringer. Hvis det kommer bagud, vil det nægte nogle opdateringer at indhente. Dette havde en større indflydelse på den tilsyneladende rullehastighed end på den interne hukommelsesorganisation. En ulempe var, at ASCII-animationen var noget upræcis."
For at rette op på denne opfattede xterm træghed, foreslår Dickey at bruge ressourcen , hvilket giver xterm mulighed for at kassere nogle skærmopdateringer for at følge med strømmen. Mine tests bekræfter, at fastScroll forbedrer ydeevnen og bringer xterm på niveau med rxvt. Dette er dog en ret barsk krykke, som Dickey selv forklarer: "sommetider ser xterm - som konsole - ud til at gå i stå, da den venter på et nyt sæt skærmopdateringer, efter at nogle er blevet fjernet." På den måde ser det ud til, at andre terminaler har fundet det bedste kompromis mellem hastighed og skærmintegritet.
Ressourceforbrug
Uanset om det giver mening at betragte scrollehastighed som en ydeevnemåling, giver denne test os mulighed for at simulere belastningen på terminalerne, hvilket igen giver os mulighed for at måle andre parametre såsom hukommelse eller diskbrug. Metrikken blev opnået ved at køre den specificerede test seq under Python-procesovervågning. Han indsamlede målerdata for ru_maxrss, beløb ru_oublock и ru_inblock og en simpel timer.
I denne test indtager ST en førsteplads med det laveste gennemsnitlige hukommelsesforbrug på 8 MB, hvilket ikke er overraskende i betragtning af, at hovedideen med designet er enkelhed. mlterm, xterm og rxvt bruger lidt mere - omkring 12 MB. Et andet bemærkelsesværdigt resultat er Alacritty, som kræver 30 MB for at køre. Så er der terminaler af VTE-familien med tal fra 40 til 60 MB, hvilket er ret meget. Dette forbrug kan forklares med, at disse terminaler bruger biblioteker på højere niveau, for eksempel GTK. Konsole kommer sidst med hele 65 MB hukommelsesforbrug under test, selvom dette kan retfærdiggøres af dens meget brede vifte af funktioner.
Sammenlignet med tidligere resultater opnået for ti år siden, begyndte alle programmer at forbruge mærkbart mere hukommelse. Xterm krævede tidligere 4 MB, men nu kræver det 15 MB lige ved opstart. Der er en tilsvarende stigning i forbruget til rxvt, som nu kræver 16 MB ud af kassen. Xfce Terminal fylder 34 MB, hvilket er tre gange større end før, men GNOME Terminal kræver kun 20 MB. Selvfølgelig blev alle tidligere test udført på 32-bit arkitektur. Ved LCA 2012 Rusty Russell , at der er mange flere subtile grunde, der kunne forklare stigningen i hukommelsesforbruget. Når det er sagt, så lever vi nu i en tid, hvor vi har gigabyte hukommelse, så vi klarer os på en eller anden måde.
Jeg kan dog ikke undgå at føle, at det er spild af ressourcer at allokere mere hukommelse til noget så grundlæggende som terminalen. Disse programmer bør være de mindste af de mindste, bør kunne køre på enhver "æske", selv en skoæske, hvis vi nogensinde kommer til det punkt, hvor de skal udstyres med Linux-systemer (og du ved, at det vil være sådan ). Men med disse tal vil hukommelsesbrug blive et problem i fremtiden i ethvert miljø, der kører flere terminaler bortset fra nogle få af de letteste og mest begrænsede i muligheder. For at kompensere for dette har GNOME Terminal, Konsole, urxvt, Terminator og Xfce Terminal en Daemon-tilstand, der giver dig mulighed for at styre flere terminaler gennem en enkelt proces, hvilket begrænser deres hukommelsesforbrug.
Under mine tests kom jeg til et andet uventet resultat vedrørende disk read-write: Jeg forventede slet ikke at se noget her, men det viste sig, at nogle terminaler skriver de mest omfangsrige data til disken. Så VTE-biblioteket holder faktisk en rullebuffer på disken (denne funktion , og dette sker stadig). Men i modsætning til ældre implementeringer er nu i det mindste disse data krypteret ved hjælp af AES256 GCM (). Men et rimeligt spørgsmål opstår: hvad er så specielt ved VTE-biblioteket, at det kræver en sådan ikke-standard tilgang til implementering...
Konklusion
I den første del af artiklen fandt vi ud af, at VTE-baserede terminaler har et godt sæt funktioner, men nu ser vi, at dette kommer med nogle ydelsesomkostninger. Nu er hukommelsen ikke et problem, fordi alle VTE-terminaler kan styres gennem en Daemon-proces, som begrænser deres appetit. Ældre systemer, der har fysiske begrænsninger på mængden af RAM og kernebuffere, kan dog stadig have brug for tidligere versioner af terminaler, da de bruger væsentligt færre ressourcer. Selvom VTE-terminaler klarede sig godt i gennemløbstest (rulning), er deres visningsforsinkelse over den tærskel, der er angivet i GNOME-brugervejledningen. VTE-udviklere bør nok tage højde for dette. Hvis vi tager i betragtning, at selv for nybegyndere Linux-brugere støder på en terminal er uundgåelig, kan de gøre den mere brugervenlig. For erfarne nørder kan skift fra standardterminalen endda betyde mindre anstrengte øjne og muligheden for at undgå fremtidige arbejdsrelaterede skader og sygdomme på grund af lange arbejdssessioner. Desværre er det kun de gamle xterm og mlterm, der bringer os til den magiske ping-tærskel på 10 millisekunder, hvilket er uacceptabelt for mange.
Benchmark-målinger viste også, at på grund af udviklingen af Linux grafiske miljøer, var udviklere nødt til at indgå en række kompromiser. Nogle brugere vil måske se på almindelige vinduesadministratorer, da de giver betydelig ping-reduktion. Desværre var det ikke muligt at måle latens for Wayland: Typometer-programmet, jeg brugte, blev oprettet til det, Wayland er designet til at forhindre: spionage mod andre vinduer. Jeg håber, at Wayland compositing klarer sig bedre end X.org, og jeg håber også, at nogen i fremtiden vil finde en måde at måle latens i dette miljø.
Kilde: www.habr.com