{"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\/da\/blog\/administrirovanie\/obzor-emulyatorov-terminala","title":{"rendered":"Oversigt over terminalemulatorer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Et par ord fra vores overs\u00e6ttelsesbureau: normalt str\u00e6ber alle efter at overs\u00e6tte de nyeste materialer og publikationer, og vi er ingen undtagelse. Men terminaler er ikke noget, der opdateres hver uge. Derfor har vi oversat artikel af Antoine Beaulieu, der blev offentliggjort for\u00e5ret 2018: p\u00e5 trods af dens respektable 'alder' i moderne m\u00e5lestok mener vi, at materialet er helt aktuelt. Desuden er det i originalen en serie p\u00e5 to artikler, men vi har besluttet at kombinere dem til et stort indl\u00e6g.<\/i><\/p>\n

\"Oversigt
\n
\nTerminaler har en s\u00e6rlig plads i computerhistorien, men i de seneste \u00e5rtier har de v\u00e6ret 'n\u00f8dt til' bogstaveligt talt at overleve sammen med kommandoprompten midt i den udbredte brug af grafiske brugerflader. Terminal-emulatorer<\/a><\/noindex> erstatte deres hardwaref\u00e6tre<\/a><\/noindex>, som i sin tur var en modifikation af systemer baseret p\u00e5 perforerede kort og drejekontakter. Moderne distributioner leveres med et v\u00e6ld af terminalemulatorer i alle former og farver. Og mens mange er tilfredse med den standardterminal, der leveres med deres arbejdsomr\u00e5de, bruger nogle stolt eksotisk software til at k\u00f8re deres foretrukne shell eller teksteditor. Men som vi vil se i denne artikel, er ikke alle terminaler skabt ens: de varierer meget i funktionalitet, st\u00f8rrelse og ydeevne.
\n<\/a><\/noindex><\/p>\n

Nogle terminaler har direkte overraskende sikkerhedshuller, plus de fleste har en helt forskellig s\u00e6t af funktioner, fra underst\u00f8ttelse af fanebladgr\u00e6nseflader til scripts. Selvom vi tidligere har d\u00e6kket terminalemulatorer<\/a><\/noindex>, er denne artikel en opdatering af det tidligere materiale, der hj\u00e6lper l\u00e6serne med at afg\u00f8re, hvilken terminal de skal bruge i 2018. I den f\u00f8rste halvdel af artiklen sammenlignes funktionerne, mens der i den anden halvdel vurderes ydeevnen.<\/p>\n

Her er de terminaler, jeg har gennemg\u00e5et:<\/p>\n

\"Oversigt
\n
\nM\u00e5ske er dette ikke de nyeste versioner, da jeg har begr\u00e6nset mig til stabile builds p\u00e5 tidspunktet for skrivningen, som jeg kunne installere p\u00e5 Debian 9 eller Fedora 27. Det eneste undtagelse er Alacritty. Det er efterkommer af terminaler med GPU-acceleration og skrevet i et us\u00e6dvanligt og nyt sprog for denne opgave - Rust. Jeg udelod webterminaler (inklusive, og p\u00e5 Electron<\/a><\/noindex>), fordi de indledende tests viste deres ekstremt lave ydeevne.<\/p>\n

Unicode-support<\/h4>\n

\nJeg startede mine tests med underst\u00f8ttelse af unicode. Den f\u00f8rste test af terminalerne var at vise en tekststreng om unicode fra artiklen p\u00e5 Wikipedia<\/a><\/noindex>: \u00ab\u00e9, \u0394, \u0419, \u05e7, \u0645, \u0e57, \u3042, \u53f6, \u8449 og \ub9d0\u00bb. Denne enkle test viser, om terminalen korrekt kan arbejde over hele verden. Terminalen xterm viser ikke det arabiske tegn Mem<\/a><\/noindex> i standardkonfigurationen:<\/p>\n

\"Oversigt
\n
\nSom standard bruger xterm den klassiske \u00abfixed\u00bb skrifttype, som if\u00f8lge den samme Wiki<\/a><\/noindex>, har \u00abbetydelig unicode-d\u00e6kning siden 1997\u00bb. I denne skrifttype sker der noget, der f\u00e5r symbolet til at vises som en tom ramme, og kun n\u00e5r tekstst\u00f8rrelsen \u00f8ges til 20+ punkter, begynder symbolet endelig at blive vist korrekt. Men denne \u00abfix\u00bb \u00f8del\u00e6gger visningen af andre unicode-tegn:<\/p>\n

\"Oversigt
\n
\nDisse sk\u00e6rmbilleder blev taget i Fedora 27, da det gav de bedste resultater sammenlignet med Debian 9, hvor nogle \u00e6ldre versioner af terminaler (specifikt - mlterm) ikke kunne fungere korrekt med skrifttyper. Heldigvis blev dette rettet i senere versioner.<\/p>\n

Nu skal du bem\u00e6rke visningen af strengen i xterm. Det viser sig, at symbolet Mem og det f\u00f8lgende semitiske Qoph<\/a><\/noindex> tilh\u00f8rer skriftscenarierne RTL (right-to-left<\/a><\/noindex>), s\u00e5 teknisk set skal de vises fra h\u00f8jre mod venstre. Webbrowsere, som f.eks. Firefox 57, behandler korrekt den tidligere n\u00e6vnte streng. En lettere variant af RTL-tekst er ordet \u00abSara<\/a><\/noindex>\u00bb p\u00e5 hebraisk (\u05e9\u05e8\u05d4<\/a><\/noindex>). Wiki-siden om tovejstekster<\/a><\/noindex> siger f\u00f8lgende:<\/p>\n

\u00abMange computerprogrammer kan ikke korrekt vise tovejstekst. For eksempel best\u00e5r det hebraiske navn \u00abSara\u00bb af tegnene sin (\u05e9) (som vises til h\u00f8jre), derefter resh (\u05e8) og til sidst he (\u05d4) (som skal vises til venstre).\u00bb<\/p><\/blockquote>\n

\nMange terminaler best\u00e5r ikke testen: Alacritty, VTE-baserede Gnome og XFCE terminaler, urxvt, st og xterm viser \"Sara\" i omvendt r\u00e6kkef\u00f8lge, som om vi skrev dette navn som \"Aras\".<\/p>\n

\"Oversigt
\n
\nEt andet problem med tovejs tekster er, at de skal justeres p\u00e5 en eller anden m\u00e5de, is\u00e6r n\u00e5r det handler om blanding af RTL og LTR-tekster. RTL-scripts skal starte fra h\u00f8jre side af terminalvinduet, men hvad skal der ske med terminaler, der normalt arbejder med LTR-engelsk? De fleste har ikke nogen s\u00e6rlige mekanismer og venstrejusterer al tekst (inklusive i Konsole). Undtagelsen er pterm og mlterm, som f\u00f8lger standarderne og h\u00f8jrejusterer s\u00e5danne strenge.<\/p>\n

\"Oversigt
\n<\/p>\n

Beskyttelse mod inds\u00e6ttelse<\/h4>\n

\nDen n\u00e6ste kritiske funktion, jeg har identificeret, er beskyttelse mod inds\u00e6ttelse. Selvom det er velkendt, at kommandoer som:<\/p>\n

$ curl http:\/\/example.com\/ | sh<\/code><\/pre>\n
\ner push-kommandoer til udf\u00f8relse af kode, ved f\u00e5 at skjulte kommandoer kan tr\u00e6nge ind i konsollen ved kopiering-inds\u00e6t fra en webbrowser, selv efter en grundig inspektion. Janna Horns verificeringswebsted<\/a><\/noindex> viser glimrende, hvordan en tilsyneladende harml\u00f8s kommando:<\/p>\n
git clone git:\/\/git.kernel.org\/pub\/scm\/utils\/kup\/kup.git<\/code><\/pre>\n
\nbliver ved inds\u00e6ttelse fra Horns websted i terminalen til s\u00e5dan noget ubehageligt:<\/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. Don'\"'\"'t copy code from websites you don'\"'\"'t trust! \n\tHer'\"'\"'s the first line of your \/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 det? Den skadelige kode er taget ud i en blok <\/b>, som er flyttet uden for brugerens synsfelt ved hj\u00e6lp af CSS.<\/p>\n
Bracketed paste tilstand<\/a><\/noindex> er specifikt designet til at neutralisere s\u00e5danne angreb. I denne tilstand indkapsler terminaler den indsatte tekst i et par specielle escape-sekvenser for at informere shellen om oprindelsen af denne tekst. S\u00e5 shellen f\u00e5r signal om, at den kan ignorere specialtegn, som den indsatte tekst kan indeholde. Alle terminaler, selv den \u00e6dle xterm, underst\u00f8tter denne funktion, men inds\u00e6ttelse i Bracketed-tilstand kr\u00e6ver support fra shellen eller applikationen, der k\u00f8rer p\u00e5 terminalen. For eksempel kr\u00e6ver software, der bruger GNU Readline<\/a><\/noindex> (den samme Bash), en fil ~\/.inputrc<\/b>:<\/p>\n
set enable-bracketed-paste on<\/code><\/pre>\n
\nDesv\u00e6rre viser Horns testsite ogs\u00e5, hvordan man kan omg\u00e5 denne beskyttelse gennem selve tekstformateringen og forhastet afslutte anvendelsen af Bracketed-tilstand. Det fungerer, fordi nogle terminaler filtrerer escape-sekvenser forkert, f\u00f8r de tilf\u00f8jer deres egne. For eksempel kunne jeg i mine tests ikke afslutte Konsole-testene med korrekt konfiguration. .inputrc<\/b> fil. Det betyder, at du nemt kan f\u00e5 skader p\u00e5 systemkonfigurationen p\u00e5 grund af en unsupported applikation eller en forkert konfigureret shell. Dette er is\u00e6r farligt, n\u00e5r du logger ind p\u00e5 fjernservere, hvor grundig konfiguration sj\u00e6ldnere forekommer, is\u00e6r hvis du har mange af s\u00e5danne fjernmaskiner.<\/p>\n
En god l\u00f8sning p\u00e5 dette problem er en inds\u00e6tningsbekr\u00e6ftelsespluggin til terminalen urxvt<\/b>, som simpelthen anmoder om tilladelse, n\u00e5r du inds\u00e6tter tekst, der indeholder nye linjer. Jeg har ikke fundet en mere sikker l\u00f8sning p\u00e5 den tekstlige angreb beskrevet af Horn.<\/p>\n
Faner og profiler<\/h4>\n
\nEn popul\u00e6r funktion nu er underst\u00f8ttelse af en gr\u00e6nseflade med faner, som vi definerer som et terminalvindue, der indeholder flere terminaler. For forskellige terminaler adskiller denne funktion sig, og mens traditionelle terminaler som xterm slet ikke underst\u00f8tter faner, har mere moderne terminaler som Xfce Terminal, GNOME Terminal og Konsole denne funktion. Urxvt underst\u00f8tter ogs\u00e5 faner, men kun n\u00e5r der anvendes en pluggin. Men med hensyn til ren fanest\u00f8tte er Terminator ubestridt f\u00f8rende: den underst\u00f8tter ikke blot faner, men kan ogs\u00e5 placere terminaler i vilk\u00e5rlig r\u00e6kkef\u00f8lge (se billede nedenfor).<\/p>\n
\"Oversigt
\n
\nEn anden funktion ved Terminator er muligheden for at \"gruppere\" disse faner sammen og sende de samme tastetryk til flere terminaler samtidigt, hvilket giver et groft v\u00e6rkt\u00f8j til at udf\u00f8re masseoperationer p\u00e5 flere servere samtidigt. En lignende funktion er ogs\u00e5 implementeret i Konsole. For at bruge denne funktion i andre terminaler er det n\u00f8dvendigt at anvende tredjeparts software, som Cluster SSH<\/a><\/noindex>, xlax<\/a><\/noindex> eller tmux<\/a><\/noindex>.<\/p>\n
Specielt fungerer fanerne godt sammen med profiler: for eksempel kan du have \u00e9n fane til e-mail, en anden til chat osv. Dette underst\u00f8ttes godt af Konsole-terminalen og GNOME Terminal. Begge tillader hver fane at starte sin egen profil automatisk. Terminator underst\u00f8tter ogs\u00e5 profiler, men jeg kunne ikke finde en m\u00e5de at starte specifikke programmer automatisk, n\u00e5r en bestemt fane \u00e5bnes. Andre terminaler har slet ikke begrebet \"profil\".<\/p>\n
Volanger<\/h4>\n
\nDet sidste, jeg vil se p\u00e5 i f\u00f8rste del af denne artikel, er udseendet af terminalerne. For eksempel underst\u00f8tter GNOME, Xfce og urxvt gennemsigtighed, men for nylig har de droppet underst\u00f8ttelsen af baggrundsbilleder, hvilket fik nogle brugere til at skifte terminal. Tilix<\/a><\/noindex>. Personligt er jeg glad for den enkle l\u00f8sning. Xresources<\/b>, som s\u00e6tter et grundl\u00e6ggende farveskema for urxvt. Men ikke-standard farvetemaer kan skabe problemer. For eksempel, Solarized<\/a><\/noindex> virker ikke<\/a><\/noindex> med applikationer htop<\/a><\/noindex> og IPTraf<\/a><\/noindex>, da de allerede bruger deres egne farver.<\/p>\n
Den originale VT100-terminal<\/a><\/noindex> underst\u00f8ttede ikke farver, og nyere terminaler var ofte begr\u00e6nset til en 256-farvepalette. For erfarne brugere, der designer deres terminaler med komplekse stilarter, kan dette v\u00e6re en ubehagelig begr\u00e6nsning. Gist<\/a><\/noindex> sporer, hvilke terminaler der har underst\u00f8ttelse af \"True Color\". Mine tests bekr\u00e6fter, at st, Alacritty og terminaler baseret p\u00e5 VTE underst\u00f8tter True Color perfekt. Andre terminaler fungerer ikke s\u00e5 godt i denne henseende og viser faktisk ikke engang 256 farver. Nedenfor kan du se forskellen i underst\u00f8ttelse af True Color i terminalerne GNOME, st og xterm, der h\u00e5ndterer denne opgave godt med deres 256-farvepalette, og urxvt, der ikke kun misser testen, men endda viser blinkende symboler i stedet.<\/p>\n
\"Oversigt
\n
\nNogle terminaler analyserer ogs\u00e5 teksten for URL-m\u00f8nstre for at g\u00f8re links klikbare. Dette g\u00e6lder alle VTE-baserede terminaler, mens urxvt kr\u00e6ver et s\u00e6rligt tilf\u00f8jelsesmodul, der kan transformere URL-adresser ved klik eller med en genvejstast. Andre terminaler, jeg testede, viser URL-adresser p\u00e5 andre m\u00e5der.<\/p>\n
Endelig er en ny trend inden for terminaler valgfrie scroll-buffere. For eksempel i st er der ingen scroll-buffer; det antages, at brugeren vil bruge en terminal multiplexer som tmux, og GNU Screen<\/a><\/noindex>.<\/p>\n
I Alacritty findes der heller ikke tilbageholdte scroll-buffere, men de vil snart blive tilf\u00f8jet<\/a><\/noindex> p\u00e5 grund af det 'store antal feedback' fra brugerne om dette emne. Bortset fra disse undtagelser underst\u00f8tter hver terminal, jeg har taget et kig p\u00e5, tilbageholdt scrolling.<\/p>\n
Mellemsammenfatning<\/h4>\n
\nI del to af materialet (i originalen var der to forskellige artikler, - bem. red.<\/i>) vil vi sammenligne ydeevne, hukommelsesforbrug og forsinkelse. Men vi ser allerede, at nogle af de betragtede terminaler har alvorlige mangler. For eksempel kan brugere, der regelm\u00e6ssigt arbejder med RTL-scripts, bem\u00e6rke mlterm og pterm, da de klarer disse opgaver bedre end de fleste. Konsole har ogs\u00e5 vist sig at v\u00e6re god. Brugere, der ikke arbejder med RTL-scripts, kan v\u00e6lge noget andet.<\/p>\n
Set fra et sikkerhedsm\u00e6ssigt perspektiv skiller urxvt sig ud p\u00e5 grund af sin s\u00e6rlige implementering af beskyttelse mod denne slags angreb, som jeg bestemt synes er praktisk. Dem, der leder efter nogle sp\u00e6ndende funktioner, b\u00f8r se p\u00e5 Konsole. Endelig skal det bem\u00e6rkes, at VTE er et fremragende grundlag for terminaler, der sikrer farveunderst\u00f8ttelse, genkendelse af URL'er og s\u00e5 videre. Ved f\u00f8rste \u00f8jekast kan den standardterminal, der leveres med dit yndlingsmilj\u00f8, opfylde alle krav, men lad os lade dette sp\u00f8rgsm\u00e5l st\u00e5 \u00e5bent, indtil vi har unders\u00f8gt ydeevnen.<\/p>\n
<\/p>\n
Lad os forts\u00e6tte samtalen<\/h4>\n
<\/i>
\nGenerelt kan ydeevnen ved terminaler synes at v\u00e6re en opfundet problemstilling, men som det viser sig, demonstrerer nogle af dem en overraskende h\u00f8j forsinkelse for s\u00e5 grundl\u00e6ggende software. Desuden vil vi se p\u00e5, hvad der traditionelt kaldes 'hastighed' (faktisk er dette scrolling-hastighed) og terminalens hukommelsesforbrug (med den tanke, at dette i dag ikke er s\u00e5 kritisk som for \u00e5rtier siden).<\/p>\n
Forsinkelse<\/h4>\n
\nEfter n\u00f8je at have unders\u00f8gt terminalernes ydeevne er jeg kommet frem til, at den vigtigste parameter i denne sammenh\u00e6ng er forsinkelsens st\u00f8rrelse (ping). I min artikel \u00abVi skriver med forn\u00f8jelse\u00bb<\/a><\/noindex> Pavel Fatin har unders\u00f8gt forsinkelsen i forskellige tekstredakt\u00f8rer og antydet, at terminaler p\u00e5 dette omr\u00e5de kan fungere langsommere end de hurtigste tekstredakt\u00f8rer. Netop denne antydning f\u00f8rte mig til at starte mine egne tests og skrive denne artikel.<\/p>\n
Men hvad er forsinkelse, og hvorfor er den s\u00e5 vigtig? I sin artikel definerede Fatin den som \u00abforsinkelsen mellem tryk p\u00e5 en tast og den tilsvarende opdatering af sk\u00e6rmen\u00bb og citerede \u00abManual for menneske-computer interaktion\u00bb<\/a><\/noindex>, hvori der st\u00e5r: \u00abForsinkelsen i visuel feedback p\u00e5 computerens sk\u00e6rm har en vigtig indflydelse p\u00e5 skrivers adf\u00e6rd og tilfredshed\u00bb.<\/p>\n
Fatin forklarer, at s\u00e5dan en ping har dybere konsekvenser end blot tilfredshed: \u00abat skrive bliver langsommere, der opst\u00e5r flere fejl, og muskel- og \u00f8jensp\u00e6nding \u00f8ges\u00bb. Med andre ord kan en stor forsinkelse f\u00f8re til tastefejl samt nedsat kodens kvalitet, da det medf\u00f8rer en ekstra kognitiv belastning for hjernen. Men hvad der er v\u00e6rre, pingen \u00ab\u00f8ver \u00f8jensp\u00e6nding og muskelsp\u00e6nding\u00bb, hvilket tilsyneladende antyder udvikling af erhvervssygdomme<\/a><\/noindex> i fremtiden (tilsyneladende henviser forfatteren til problemer med \u00f8jenmusklerne, ryggen, h\u00e6nderne og selvf\u00f8lgelig synet \u2014 red.<\/i>) p\u00e5 grund af gentagen belastning.<\/p>\n
Nogle af disse effekter er kendte l\u00e6nge, og resultaterne unders\u00f8gelser<\/a><\/noindex>, offentliggjort allerede i 1976 i tidsskriftet Ergonomics, viser, at en forsinkelse p\u00e5 100 millisekunder \u00abbetydeligt forv\u00e6rrer skrivehastigheden\u00bb. For nylig blev det i brugervejledningen til GNOME indf\u00f8rt et acceptabelt svartid<\/a><\/noindex> p\u00e5 10 millisekunder, og hvis man ser l\u00e6ngere frem, s\u00e5 Microsoft Research<\/a><\/noindex> viser, at idealet er 1 millisekund.<\/p>\n
Fatin udf\u00f8rte sine tests p\u00e5 tekstredakt\u00f8rer; han skabte et b\u00e6rbart v\u00e6rkt\u00f8j kaldet Typometer<\/a><\/noindex>, som jeg brugte til at teste ping i terminalemulatorer. Bem\u00e6rk, at testen blev udf\u00f8rt i simuleringsmodus: i virkeligheden skal vi tage hensyn til indtastningsforsinkelsen (tastatur, USB-controller osv.) og udgangsforsinkelsen (grafikbuffer, sk\u00e6rm). If\u00f8lge Fatin er den typiske konfiguration omkring 20 ms. Med gaming-udstyr kan man opn\u00e5 en forsinkelse p\u00e5 kun 3 millisekunder. Da vi allerede har s\u00e5 hurtigt udstyr, b\u00f8r applikationen ikke tilf\u00f8je sin egen forsinkelse. Fatins m\u00e5l er at reducere applikationens forsinkelse til 1 millisekund, eller helt undg\u00e5 forsinkelse i ops\u00e6tningen. m\u00e5lbar forsinkelse<\/a><\/noindex>, som i IntelliJ IDEA 15<\/a><\/noindex>.<\/p>\n
Her er resultaterne af mine m\u00e5linger samt nogle af Fatins resultater for at vise, at mit eksperiment stemmer overens med hans tests:<\/p>\n
\"Oversigt
\n
\nDet f\u00f8rste, der overraskede mig, var den bedre responstid hos \u00e6ldre programmer som xterm og mlterm. Med en registreringsforsinkelse (2,4 ms) pr\u00e6sterede de bedre end den hurtigste moderne terminal (10,6 ms for st). Ingen moderne terminal kommer under t\u00e6rsklen p\u00e5 10 millisekunder. Is\u00e6r opfylder Alacritty ikke kravene til 'den hurtigste af eksisterende terminalemulatorer', selvom dets resultater er blevet forbedret siden den f\u00f8rste test i 2017. Faktisk er forfatterne af projektet opm\u00e6rksomme p\u00e5 situationen<\/a><\/noindex> og arbejder p\u00e5 at forbedre ydeevnen. Det er ogs\u00e5 vigtigt at bem\u00e6rke, at Vim, der bruger GTK3, er v\u00e6sentligt langsommere end sin GTK2-modpart. Dette tyder p\u00e5, at GTK3 introducerer ekstra forsinkelse, hvilket ogs\u00e5 p\u00e5virker andre terminaler, der bruger det (Terminator, Xfce4 Terminal og GNOME Terminal).<\/p>\n
Dog kan forskellene v\u00e6re usynlige for \u00f8jet. Som Fatin forklarer: 'Det er ikke n\u00f8dvendigt at v\u00e6re klar over forsinkelsen for at den p\u00e5virker dig'. Fatin advarer ogs\u00e5 om standardafvigelsen: 'Enhver variation i varigheden af forsinkelsen (rysten) skaber en ekstra belastning p\u00e5 grund af deres uforudsigelighed'.<\/p>\n
\"Oversigt
\n
\nGrafikken ovenfor er opn\u00e5et p\u00e5 ren Debian 9 (stretch) med i3 vinduesmanager<\/a><\/noindex>. Dette milj\u00f8 giver de bedste resultater i latensm\u00e5linger. Som det viser sig, tilf\u00f8jer GNOME en ekstra ping p\u00e5 20 ms til alle m\u00e5linger. En mulig forklaring p\u00e5 dette er tilstedev\u00e6relsen af programmer med synkron behandling af indgangsh\u00e6ndelser. Fatin giver et eksempel p\u00e5 en s\u00e5dan situation Workrave<\/a><\/noindex>, som tilf\u00f8jer forsinkelse ved at behandle alle input-h\u00e6ndelser synkront. Som standard leveres GNOME ogs\u00e5 med vinduesleder Mutter<\/a><\/noindex>, som skaber et ekstra niveau af buffering, hvilket p\u00e5virker ping og tilf\u00f8jer mindst 8 millisekunders forsinkelse.<\/p>\n
\"Oversigt
\n<\/p>\n
Rullemulighed<\/h4>\n
\nDen n\u00e6ste test er den traditionelle kontrol af \"hastighed\" eller \"b\u00e5ndbredde\", der m\u00e5ler hvor hurtigt terminalen kan rulle en side, der viser en stor m\u00e6ngde tekst p\u00e5 sk\u00e6rmen. Testens mekanik varierer; den oprindelige test bestod i at generere den samme tekststreng ved hj\u00e6lp af kommandoen seq. Andre tests inkluderer Thomas E. Dickes test (som underst\u00f8tter xterm), hvorved der gentagne gange udl\u00e6gges filen terminfo.src<\/a><\/noindex>. I en anden terminalpr\u00e6stationsvurdering Den Luu<\/a><\/noindex> bruger en r\u00e6kke tilf\u00e6ldige bytes i base32-kodning, som vises i terminalen ved hj\u00e6lp af cat. Luu anser en s\u00e5dan test for \"s\u00e5 nyttel\u00f8s som en benchmark kan v\u00e6re\" og foresl\u00e5r at bruge terminalens respons som hovedm\u00e5leparameter i stedet. Dicke beskriver ogs\u00e5 sin test som vildledende. Ikke desto mindre anerkender begge forfattere, at b\u00e5ndbredden i terminalvinduet kan v\u00e6re et problem. Luu opdagede lag i Emacs Eshell, n\u00e5r der vises store filer, og Dicke optimerede terminalen for at eliminere den visuelle forsinkelse i xterm. Derfor er der stadig en vis relevans i denne test, men da renderingsprocessen varierer betydeligt mellem terminaler, kan den ogs\u00e5 bruges som et testkomponent til at evaluere andre parametre.<\/p>\n
\"Oversigt
\n
\nHer ser vi, at rxvt og st klarer sig bedre end konkurrenterne, efterfulgt af det meget nyere Alacritty, der er udviklet med fokus p\u00e5 hastighed. Dern\u00e6st kommer Xfce (VTE-familien) og Konsole, som n\u00e6sten fungerer dobbelt s\u00e5 hurtigt. Til sidst er xterm, som er fem gange langsommere end rxvt. Under testen rystede xterm ogs\u00e5 kraftigt, og det var sv\u00e6rt at se den passerende tekst, selv n\u00e5r det var den samme linje. Konsole viste sig at v\u00e6re hurtig, men den 'snyder' nogle gange: Sk\u00e6rmen hang ind imellem, hvilket viste teksten delvist eller slet ikke. Andre terminaler viste linjerne klart, herunder st, Alacritty og rxvt.<\/p>\n
Diki forklarer, at forskellene i ydeevne skyldes designet af rullebufre i forskellige terminaler. Is\u00e6r beskylder han rxvt og andre terminaler for ikke at 'f\u00f8lge de almindelige regler':<\/p>\n
\u00abI mods\u00e6tning til xterm, fors\u00f8gte rxvt ikke at vise alle opdateringer. Hvis den falder bagud, vil den opgive nogle opdateringer for at indhente det fors\u00f8mte. Dette havde st\u00f8rre indflydelse p\u00e5 den tilsyneladende rullehastighed end p\u00e5 organiseringen af intern hukommelse. En ulempe var, at ASCII-animationen var lidt un\u00f8jagtig\u00bb.<\/p><\/blockquote>\n
\nFor at rette op p\u00e5 denne tilsyneladende langsomhed i xterm, foresl\u00e5r Diki at bruge ressourcen fastScroll<\/a><\/noindex>, som g\u00f8r det muligt for xterm at falde noget screen updates, s\u00e5 den ikke falder bagud i str\u00f8mmen. Mine tests bekr\u00e6fter, at fastScroll forbedrer ydeevnen og bringer xterm op p\u00e5 niveau med rxvt. Dette er dog en temmelig grov l\u00f8sning, som Diki selv forklarer: \u00abNogle gange virker xterm \u2013 ligesom konsole \u2013 til at stoppe, da den venter p\u00e5 et nyt s\u00e6t sk\u00e6rmopdateringer, efter at nogle af dem er blevet fjernet\u00bb. I denne sammenh\u00e6ng ser det ud til, at andre terminaler har fundet den bedste kompromis mellem hastighed og sk\u00e6rmintegritet.<\/p>\n
Ressourceforbrug<\/h4>\n
\nUanset hvor praktisk det er at overveje rullehastighed som en indikator for ydeevne, g\u00f8r denne test det muligt at simulere belastningen p\u00e5 terminalerne, hvilket igen giver os mulighed for at m\u00e5le andre parametre s\u00e5som hukommelse eller diskbrug. Metrikkerne blev opn\u00e5et ved at k\u00f8re den angivne test seq<\/b> under overv\u00e5gning af Python-processen. Den indsamlede data fra t\u00e6llerne getrusage ()<\/a><\/noindex> for ru_maxrss<\/b>, summen af ru_oublock<\/b> og ru_inblock<\/b> og en simpel tidsm\u00e5ler.<\/p>\n
\"Oversigt
\n
\nI denne test indtager ST f\u00f8rstepladsen med det laveste gennemsnitlige hukommelsesforbrug p\u00e5 8 MB, hvilket ikke er overraskende, n\u00e5r hovedideen bag projektet er enkelhed. Mlterm, xterm og rxvt bruger lidt mere - omkring 12 MB. En anden bem\u00e6rkelsesv\u00e6rdig pr\u00e6station kommer fra Alacritty, som kr\u00e6ver 30 MB for at fungere. Derfter f\u00f8lger terminalerne i VTE-familien med forbrug p\u00e5 mellem 40 og 60 MB, hvilket er ret meget. Denne forbrug kan forklares med, at disse terminaler bruger h\u00f8jere niveau biblioteker, s\u00e5som GTK. Konsole kommer sidst med et kolossalt forbrug p\u00e5 65 MB hukommelse under testene, selvom dette kan retf\u00e6rdigg\u00f8res med dets ret brede funktionss\u00e6t.<\/p>\n
Sammenlignet med de tidligere resultater, der blev opn\u00e5et for ti \u00e5r siden, er alle programmer blevet betydeligt mere hukommelseskr\u00e6vende. Tidligere kr\u00e6vede Xterm 4 MB, og nu kr\u00e6ver det 15 MB bare for at starte. Et tilsvarende forbrug er ogs\u00e5 set hos rxvt, som nu kr\u00e6ver 16 MB fra start. Xfce-terminalen optager 34 MB, hvilket er tre gange mere end f\u00f8r, mens GNOME Terminal kun kr\u00e6ver 20 MB. Selvf\u00f8lgelig blev alle tidligere test udf\u00f8rt p\u00e5 en 32-bit arkitektur. P\u00e5 LCA 2012, Rasty Russell. fortalte<\/a><\/noindex>, hvilket der er mange dybere \u00e5rsager til, som kan forklare stigningen i hukommelsesforbruget. Alt dette til trods lever vi nu i en tid, hvor vi har hele gigabyte af hukommelse, s\u00e5 vi klarer os p\u00e5 en eller anden m\u00e5de.<\/p>\n
Ikke desto mindre kan jeg ikke slippe af med f\u00f8lelsen af, at det at tildele mere hukommelse til s\u00e5dan en grundl\u00e6ggende software som terminalen er en spild af ressourcer. Disse programmer b\u00f8r v\u00e6re de mindste blandt de mindste og v\u00e6re i stand til at k\u00f8re p\u00e5 enhver '\u00e6ske', selv en skoboks, hvis vi nogensinde kommer dertil, hvor de skal udstyres med Linux-systemer (og du ved, at det vil ske). Men med disse tal vil hukommelsesforbruget i fremtiden blive et problem i ethvert milj\u00f8 ved k\u00f8rsel af flere terminaler, undtagen i tilf\u00e6lde hvor der bruges de letteste og mest begr\u00e6nsede versioner. For at kompensere for dette har GNOME Terminal, Konsole, urxvt, Terminator og Xfce Terminal daemon-tilstand, som tillader styring af flere terminaler gennem \u00e9n proces, hvilket begr\u00e6nser deres hukommelsesforbrug.<\/p>\n
\"Oversigt
\n
\nI l\u00f8bet af mine tests kom jeg til et andet uventet resultat vedr\u00f8rende disk l\u00e6sning-skrivning: Jeg forventede overhovedet ikke at se noget her, men det viste sig, at nogle terminaler skriver de mest omfattende data til disk. S\u00e5, VTE-biblioteket holder faktisk en scroll-buffer p\u00e5 disken (denne funktion blev bem\u00e6rket allerede i 2010<\/a><\/noindex>, og det sker stadig). Men i mods\u00e6tning til de gamle implementeringer, er disse data nu i det mindste krypteret med AES256 GCM (fra version 0.39.2<\/a><\/noindex>). Men der opst\u00e5r et rimeligt sp\u00f8rgsm\u00e5l: Hvad er s\u00e5 specielt ved VTE-biblioteket, at det kr\u00e6ver en s\u00e5 us\u00e6dvanlig tilgang til implementeringen\u2026<\/p>\n
Konklusion<\/h4>\n
\nI den f\u00f8rste del af artiklen opdagede vi, at terminaler baseret p\u00e5 VTE har et godt udvalg af funktioner, men nu ser vi, at dette er relateret til nogle omkostninger for at sikre deres ydeevne. I \u00f8jeblikket er hukommelse ikke et problem, fordi alle VTE-terminaler kan styres via en daemon-proces, der begr\u00e6nser deres appetit. Alligevel kan gamle systemer, der har fysiske begr\u00e6nsninger i m\u00e6ngden af RAM og kernens buffer, stadig have brug for tidligere versioner af terminalerne, da de forbruger betydeligt f\u00e6rre ressourcer. Selvom VTE-terminalerne har vist sig godt i tests af b\u00e5ndbredde (scrolling), er deres forsinkelse i visningen af data p\u00e5 sk\u00e6rmen h\u00f8jere end den fastsatte gr\u00e6nse i brugervejledningen til GNOME. Sandsynligvis b\u00f8r udviklerne af VTE tage dette i betragtning. N\u00e5r man overvejer, at selv for nye Linux-brugere er m\u00f8det med terminalen uundg\u00e5eligt, kan de g\u00f8re den mere brugervenlig. For erfarne n\u00f8rder kan overgangen fra standardterminalen endda betyde en reduktion i belastningen p\u00e5 synet og muligheden for at undg\u00e5 professionelle skader og sygdomme i fremtiden p\u00e5 grund af lange arbejds-sessioner. Desv\u00e6rre f\u00f8rer kun de gamle xterm og mlterm os til den magiske ping-gr\u00e6nse p\u00e5 10 millisekunder, hvilket for mange er uacceptabelt.<\/p>\n
M\u00e5lingerne viste ogs\u00e5, at udviklingen af grafiske milj\u00f8er i Linux har f\u00e5et udviklere til at indg\u00e5 et par kompromisser. Nogle brugere b\u00f8r overveje at se p\u00e5 almindelige vinduesforvaltere, da de giver en betydelig reduktion i ping. Desv\u00e6rre var det ikke muligt at m\u00e5le latensen for Wayland: programmet Typometer, som jeg brugte, blev skabt for netop det, som Wayland sigter mod at forhindre - overv\u00e5gning af andre vinduer. Jeg h\u00e5ber, at Waylands sammens\u00e6tning pr\u00e6sterer bedre end X.org, og jeg h\u00e5ber ogs\u00e5, at nogen i fremtiden finder en m\u00e5de at vurdere latenstiden i dette milj\u00f8.
\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\udd47Oversigt over terminalemulatorer | ProHoster","description":"Et par ord fra vores overs\u00e6ttelsesbureau: normalt str\u00e6ber alle efter at overs\u00e6tte de nyeste materialer og publikationer, og vi er ingen undtagelse. Men terminaler er ikke noget, der opdateres hver uge.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/obzor-emulyatorov-terminala","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/37222","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=37222"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/37222\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/27911"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=37222"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=37222"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=37222"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}