Några ord från vår översättningsbyrå: vanligtvis strävar alla efter att översätta det senaste materialet och publikationerna, och vi är inget undantag. Men terminaler är inget som uppdateras en gång i veckan. Därför har vi översatt för dig en artikel av Antoine Beaupré, publicerad våren 2018: trots sin avsevärda "ålder" med moderna mått mätt har materialet enligt vår mening inte förlorat sin relevans alls. Dessutom var detta ursprungligen en serie på två artiklar, men vi bestämde oss för att kombinera dem till ett stort inlägg.
Terminaler har en speciell plats i datorhistorien, men de senaste decennierna har de tvingats överleva vid sidan av kommandoraden eftersom grafiska gränssnitt blir allestädes närvarande. ersatt sina egna , som i sin tur var en modifiering av system baserade på hålkort och vippomkopplare. Moderna distributioner kommer med en mängd olika terminalemulatorer av alla former och färger. Och medan många nöjer sig med standardterminalen som tillhandahålls av deras arbetsmiljö, använder vissa stolta rent exotisk programvara för att köra sitt favoritskal eller textredigerare. Men som vi kommer att se från den här artikeln skapades inte alla terminaler i samma bild: de skiljer sig mycket i funktionalitet, storlek och prestanda.
Vissa terminaler har rent överraskande säkerhetshål, plus att de flesta har en helt annan uppsättning funktioner, från stöd för ett flikgränssnitt till skript. Även om vi , den här artikeln är en uppdatering av det tidigare materialet som hjälper läsarna att avgöra vilken terminal de ska använda under 2018. Den första halvan av artikeln jämför funktioner och den andra halvan utvärderar prestanda.
Här är terminalerna jag granskade:
Dessa kanske inte är de senaste versionerna, eftersom jag var begränsad till stabila versioner när jag skrev, som jag kunde rulla ut på Debian 9 eller Fedora 27. Det enda undantaget är Alacritty. Det är en ättling till GPU-accelererade terminaler och är skriven på ett ovanligt och nytt språk för denna uppgift - Rust. Jag uteslöt webbterminaler från min recension (inklusive de på ), eftersom preliminära tester visade deras extremt dåliga prestanda.
Unicode-stöd
Jag började mina tester med Unicode-stöd. Det första testet av terminalerna var att visa Unicode-strängen från : "é, Δ, И, K, م, ๗, あ, 叶, 葉 och 말." Detta enkla test visar om terminalen kan fungera korrekt över hela världen. xterm terminal visar inte arabiska tecken i standardkonfiguration:
Som standard använder xterm det klassiska "fasta" typsnittet, som enl , har "avsevärd Unicode-täckning sedan 1997". Det är något på gång i det här typsnittet som gör att tecknet visas som en tom ram och det är först när textfonten ökas till 20+ punkter som tecknet äntligen börjar visas korrekt. Men denna "fix" bryter visningen av andra Unicode-tecken:
Dessa skärmdumpar togs i Fedora 27, eftersom det gav bättre resultat än Debian 9, där vissa äldre versioner av terminaler (särskilt mlterm) inte kunde hantera teckensnitt ordentligt. Lyckligtvis fixades detta i senare versioner.
Lägg nu märke till hur linjen visas i xterm. Det visar sig att symbolen Mem och följande semitiska se skript i RTL-stil (), så tekniskt sett bör de visas från höger till vänster. Webbläsare som Firefox 57 hanterar ovanstående rad korrekt. En enklare version av RTL-text är ordet ""på hebreiska (). säger följande:
"Många datorprogram kan inte visa dubbelriktad text korrekt. Till exempel består det hebreiska namnet "Sarah" av tecknen sin (ש) (som visas till höger), sedan resh (ר) och slutligen han (ה) (som ska visas till vänster)."
Många terminaler misslyckas med detta test: Alacritty, VTE-härledda Gnome och XFCE terminaler, urxvt, st och xterm visar "Sara" i omvänd ordning, som om vi hade skrivit namnet som "Aras".
Ett annat problem med dubbelriktade texter är att de måste anpassas på något sätt, speciellt när det gäller att blanda RTL- och LTR-texter. RTL-skript bör köras från höger sida av terminalfönstret, men vad ska hända för terminaler som har LTR engelska som standard? De flesta av dem har inga speciella mekanismer och justerar all text till vänster (inklusive i Konsole). Undantagen är pterm och mlterm, som följer standarderna och högerjusterar sådana linjer.
Insticksskydd
Nästa kritiska funktion jag har identifierat är skydd mot införing. Även om det är allmänt känt att trollformler som:
$ curl http://example.com/ | shär push-kommandon för kodexekvering, få människor vet att dolda kommandon kan smyga sig in i konsolen när du kopierar och klistrar in från en webbläsare, även efter noggrann inspektion. visar på ett briljant sätt hur ofarligt kommandot är:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitblir till en sådan olägenhet när den klistras in från Horns webbplats 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.gitHur det fungerar? Skadlig kod ingår i blocket , som flyttas ur användarens vy med CSS.
är tydligt utformad för att neutralisera sådana attacker. I det här läget omsluter terminaler den inklistrade texten i ett par speciella escape-sekvenser för att berätta för skalet om textens ursprung. Detta talar om för skalet att det kan ignorera specialtecken som den inklistrade texten kan innehålla. Alla terminaler tillbaka till den ärevördiga xterm stöder denna funktion, men att klistra in i parentesläge kräver stöd från skalet eller applikationen som körs på terminalen. Till exempel programvara som använder (samma Bash), behöver en fil ~/.inputrc:
set enable-bracketed-paste onTyvärr visar Horns testsajt också hur man kan kringgå detta skydd genom själva textformateringen och i förtid sluta med att använda bracketed-läge på det. Detta fungerar eftersom vissa terminaler inte korrekt filtrerar escape-sekvenser innan de lägger till sina egna. Till exempel, i min kunde jag aldrig slutföra Konsole-testerna ens med rätt konfiguration .inputrc fil. Detta innebär att du lätt kan få din systemkonfiguration skadad på grund av en applikation som inte stöds eller ett felaktigt konfigurerat skal. Detta är särskilt farligt när du loggar in på fjärrservrar, där noggrant konfigurationsarbete är mindre vanligt, särskilt om du har många sådana fjärrmaskiner.
En bra lösning på detta problem är insticksprogrammet för inklistringsbekräftelse för terminalen urxvt, som helt enkelt ber om tillåtelse att infoga all text som innehåller nyrader. Jag har inte hittat ett säkrare alternativ för textattacken som beskrivits av Horn.
Flikar och profiler
En populär funktion just nu är stöd för ett flikgränssnitt, som vi kommer att definiera som ett terminalfönster som innehåller flera andra terminaler. Denna funktion skiljer sig för olika terminaler, och även om traditionella xterm-terminaler inte stöder flikar alls, har modernare terminalinkarnationer som Xfce Terminal, GNOME Terminal och Konsole denna funktion. Urxvt stöder också flikar, men bara om du använder ett plugin. Men när det gäller flikstöd i sig är Terminator den obestridda ledaren: den stöder inte bara flikar, utan kan också ordna terminaler i valfri ordning (se bilden nedan).
En annan funktion hos Terminator är möjligheten att "gruppera" dessa flikar tillsammans och skicka samma tangenttryckningar till flera terminaler samtidigt, vilket ger ett grovt verktyg för att utföra bulkoperationer på flera servrar samtidigt. En liknande funktion är också implementerad i Konsole. För att använda denna funktion i andra terminaler måste du använda programvara från tredje part som t.ex , eller .
Flikar fungerar särskilt bra när de är ihopparade med profiler: du kan till exempel ha en flik för e-post, en annan för chatt och så vidare. Detta stöds väl av Konsole Terminal och GNOME Terminal. Båda låter varje flik automatiskt starta sin egen profil. Terminator stöder också profiler, men jag kunde inte hitta ett sätt att automatiskt starta vissa program när du öppnar en specifik flik. Andra terminaler har inte begreppet "profil" alls.
Volanger
Det sista jag kommer att ta upp i den första delen av den här artikeln är terminalernas utseende. Till exempel GNOME, Xfce och urxvt stöder transparens, men har nyligen tappat stödet för bakgrundsbilder, vilket tvingar vissa användare att byta till terminalen . Själv är jag nöjd med det och det är enkelt xresources, som ställer in basuppsättningen av bakgrundsfärger för urxvt. Men icke-standardiserade färgteman kan också skapa problem. Till exempel, med applikationer и , eftersom de redan använder sina egna färger.
stödde inte färger, och nya var ofta begränsade till en palett med 256 färger. För avancerade användare som stylar sina terminaler kan skal-meddelanden eller statusfält på komplexa sätt vara en irriterande begränsning. spår vilka terminaler som har "True Color"-stöd. Mina tester bekräftar att st, Alacritty och VTE-baserade terminaler stödjer True Color perfekt. Andra terminaler klarar sig inte särskilt bra i detta avseende och visar faktiskt inte ens 256 färger. Nedan kan du se skillnaden mellan True Color-stöd i GNOME-terminaler, st och xterm, som gör ett bra jobb med detta med sin 256 färgpalett, och urxvt, som inte bara klarar testet, utan även visar några blinkande tecken istället dem.
Vissa terminaler analyserar också text för URL-mönster för att göra länkar klickbara. Detta gäller alla VTE-härledda terminaler, medan urxvt kräver en speciell plugin som skulle transformera webbadresser vid ett klick eller med ett kortkommando. Andra terminaler Jag har testat visningsadresser på andra sätt.
Slutligen, en ny trend inom terminaler är valbarheten av rullningsbufferten. Till exempel har st ingen rullningsbuffert; det antas att användaren kommer att använda en terminal multiplexer som tmux och .
Alacritty saknar också backscroll-buffertar, men dess stöd på grund av "omfattande feedback" om detta ämne från användare. Förutom dessa uppkomlingar stöder varje terminal jag har testat som jag kunde hitta omvänd rullning.
delsummor
I den andra delen av materialet (i originalet var det två olika artiklar - ca. körfält) kommer vi att jämföra prestanda, minnesanvändning och latens. Men vi kan redan nu se att några av terminalerna i fråga har allvarliga brister. Till exempel kan användare som regelbundet arbetar med RTL-skript vilja överväga mlterm och pterm, eftersom de är bättre på att hantera liknande uppgifter än andra. Konsole presterade också bra. Användare som inte arbetar med RTL-skript kan välja något annat.
När det gäller skydd mot skadlig kodinsättning, sticker urxvt ut på grund av dess speciella implementering av skydd mot denna typ av attack, vilket verkar definitivt bekvämt för mig. För den som letar efter lite klockor och visselpipor är Konsole värt en titt. Slutligen är det värt att notera att VTE är en utmärkt bas för terminaler, vilket garanterar färgstöd, URL-igenkänning och så vidare. Vid första anblicken kan standardterminalen som följer med din favoritmiljö uppfylla alla krav, men låt oss lämna denna fråga öppen tills vi förstår prestandan.
Vi fortsätter samtalet
Generellt sett kan prestandan hos terminaler i sig verka som ett långsökt problem, men som det visar sig uppvisar vissa av dem förvånansvärt hög latens för mjukvara av en så grundläggande typ. Härnäst kommer vi också att titta på vad som traditionellt kallas "hastighet" (i själva verket är detta rullningshastigheten) och minnesförbrukning för terminalen (med förbehållet att detta inte är lika kritiskt idag som det var för decennier sedan).
Fördröjning
Efter en grundlig studie av terminalprestanda kom jag till slutsatsen att den viktigaste parametern i detta avseende är latensen (ping). I hans artikel Pavel Fatin tittade på latensen hos olika textredigerare och antydde att terminaler i detta avseende kan vara långsammare än de snabbaste textredigerarna. Det var denna ledtråd som till slut fick mig att köra mina egna tester och skriva den här artikeln.
Men vad är latens, och varför är det så viktigt? I sin artikel definierade Fatin det som "fördröjningen mellan att trycka på en tangent och motsvarande skärmuppdatering" och citerade , som säger: "Fördröjningen i visuell feedback på en datorskärm har en viktig inverkan på maskinskrivarens beteende och tillfredsställelse."
Fatin förklarar att denna ping har djupare konsekvenser än bara tillfredsställelse: "att skriva blir långsammare, fler fel uppstår och ögon- och muskelspänningar ökar." En stor fördröjning kan med andra ord leda till stavfel och även lägre kodkvalitet, eftersom det leder till ytterligare kognitiv belastning på hjärnan. Men vad värre är att ping "ökar ögon- och muskelansträngning", vilket verkar antyda i framtiden (Tydligen menar författaren problem med musklerna i ögonen, ryggen, armarna och förstås synen - ca. körfält) på grund av upprepad stress.
Vissa av dessa effekter har varit kända under lång tid, och resultaten , publicerad redan 1976 i tidskriften Ergonomics, sa att en fördröjning på 100 millisekunder "avsevärt försämrar skrivhastigheten." Mer nyligen introducerades GNOME User Guide på 10 millisekunder, och om du går längre, då visar att 1 millisekund är idealiskt.
Fatin genomförde sina tester på textredigerare; han skapade ett bärbart instrument som heter , som jag använde för att testa ping i terminalemulatorer. Tänk på att testet utfördes i simuleringsläge: i verkligheten måste vi ta hänsyn till både ingång (tangentbord, USB-styrenhet, etc.) och utgång (grafikkortsbuffert, bildskärm) latens. Enligt Fatin är det i typiska konfigurationer cirka 20 ms. Om du har spelutrustning kan du uppnå denna siffra på bara 3 millisekunder. Eftersom vi redan har så snabb hårdvara behöver applikationen inte lägga till sin egen latens. Fatins mål är att få applikationens latens till 1 millisekund, eller till och med uppnå uppringning utan , hur in .
Här är resultaten av mina mätningar, såväl som några av Fatins resultat, för att visa att mitt experiment stämmer överens med hans tester:
Det första som slog mig var den bättre svarstiden för äldre program som xterm och mlterm. Med den sämsta registerlatensen (2,4 ms) presterade de bättre än den snabbaste moderna terminalen (10,6 ms för st). Ingen modern terminal faller under tröskeln på 10 millisekunder. I synnerhet misslyckas Alacritty med att uppfylla kravet om "snabbaste terminalemulatorn som finns tillgänglig", även om dess poäng har förbättrats sedan den första granskningen 2017. Ja, författarna till projektet och arbetar med att förbättra displayen. Det bör också noteras att Vim som använder GTK3 är en storleksordning långsammare än sin GTK2-motsvarighet. Av detta kan vi dra slutsatsen att GTK3 skapar ytterligare latens, och detta återspeglas i alla andra terminaler som använder den (Terminator, Xfce4 Terminal och GNOME Terminal).
Men skillnaderna kanske inte är märkbara för ögat. Som Fatin förklarar, "du behöver inte vara medveten om förseningen för att det ska ha en effekt på dig." Fatin varnar också för standardavvikelse: "alla störningar i latens (jitter) skapar ytterligare stress på grund av deras oförutsägbarhet."
Grafen ovan är tagen på ren Debian 9 (stretch) med . Denna miljö ger de bästa resultaten i latenstest. Som det visar sig skapar GNOME en extra ping på 20 ms för alla mätningar. En möjlig förklaring till detta är förekomsten av program med synkron behandling av ingångshändelser. Fatin ger ett exempel för ett sådant fall , vilket lägger till en fördröjning genom att bearbeta alla ingångshändelser synkront. Som standard kommer GNOME också med en fönsterhanterare , vilket skapar ett extra lager av buffring, vilket påverkar ping och lägger till minst 8 millisekunders latens.
Scrollhastighet
Nästa test är ett traditionellt "hastighet" eller "bandbredd"-test, som mäter hur snabbt terminalen kan scrolla en sida samtidigt som den visar stora mängder text på skärmen. Mekaniken i testet varierar; det ursprungliga testet var att helt enkelt generera samma textsträng med kommandot seq. Andra tester inkluderar Thomas E. Dickeys (xterm underhållare) test, som upprepade gånger . I en annan recension av terminalprestanda använder en base32-kodad sträng med slumpmässiga byte, som matas ut till terminalen med hjälp av cat. Luu anser att ett sådant test är "ett så värdelöst riktmärke som man kan föreställa sig" och föreslår att man istället använder terminalsvar som ett primärt mått. Dickey kallar också sitt test missvisande. Båda författarna erkänner dock att terminalfönstrets bandbredd kan vara ett problem. Luu upptäckte att Emacs Eshell fryser när stora filer visas, och Dickey optimerade terminalen för att bli av med xtrerms visuella tröghet. Så det finns fortfarande vissa fördelar med detta test, men eftersom renderingsprocessen är väldigt olika från terminal till terminal kan den också användas som en testkomponent för att testa andra parametrar.
Här ser vi rxvt och st dra före konkurrenterna, följt av den betydligt nyare Alacritty, som är designad med fokus på prestanda. Nästa är Xfce (VTE-familjen) och Konsole, som är nästan dubbelt så snabba. Sist är xterm, som är fem gånger långsammare än rxvt. Under testet krusade xterm också mycket, vilket gjorde det svårt att se att skicka text även om det var samma rad. Konsole var snabb, men det var knepigt ibland: displayen frös då och då, visade en del text eller visade den inte alls. Andra terminaler visade strängar tydligt, inklusive st, Alacritty och rxvt.
Dickey förklarar att prestandaskillnaderna beror på utformningen av rullningsbuffertar i olika terminaler. I synnerhet anklagar han rxvt och andra terminaler för att "inte följa de allmänna reglerna":
"Till skillnad från xterm försökte rxvt inte visa alla uppdateringar. Om det hamnar på efterkälken kommer det att vägra några uppdateringar att komma ikapp. Detta hade en större inverkan på skenbar rullningshastighet än på internminnets organisation. En nackdel var att ASCII-animationen var något oprecis."
För att åtgärda denna upplevda tröghet föreslår Dickey att du använder resursen , vilket gör att xterm kan ignorera vissa skärmuppdateringar för att hänga med i flödet. Mina tester bekräftar att fastScroll förbättrar prestandan och ger xterm i paritet med rxvt. Detta är dock en ganska grov krycka, som Dickey själv förklarar: "ibland verkar xterm - som konsole - stanna upp när den väntar på en ny uppsättning skärmuppdateringar efter att några har tagits bort." I denna anda verkar det som om andra terminaler har hittat den bästa kompromissen mellan hastighet och skärmintegritet.
Resursförbrukning
Oavsett om det är vettigt att betrakta rullningshastighet som ett prestandamått, tillåter detta test oss att simulera belastningen på terminalerna, vilket i sin tur låter oss mäta andra parametrar som minne eller diskanvändning. Mätvärdena erhölls genom att köra det angivna testet seq under Python-processövervakning. Han samlade mätardata för ru_maxrss, belopp ru_oublock и ru_inblock och en enkel timer.
I det här testet tar ST förstaplatsen med den lägsta genomsnittliga minnesförbrukningen på 8 MB, vilket inte är förvånande med tanke på att huvudidén med designen är enkelhet. mlterm, xterm och rxvt förbrukar lite mer - cirka 12 MB. Ett annat anmärkningsvärt resultat är Alacritty, som kräver 30 MB för att köras. Sedan finns det terminaler i VTE-familjen med siffror från 40 till 60 MB, vilket är ganska mycket. Denna förbrukning kan förklaras av det faktum att dessa terminaler använder bibliotek på högre nivå, till exempel GTK. Konsole kommer sist med hela 65 MB minnesförbrukning under tester, även om detta kan motiveras av dess mycket breda utbud av funktioner.
Jämfört med tidigare resultat som erhölls för tio år sedan började alla program förbruka märkbart mer minne. Xterm brukade kräva 4 MB, men nu kräver det 15 MB precis vid uppstart. Det finns en liknande ökning av förbrukningen för rxvt, som nu kräver 16 MB ur lådan. Xfce Terminal tar upp 34 MB, vilket är tre gånger större än tidigare, men GNOME Terminal kräver bara 20 MB. Naturligtvis utfördes alla tidigare tester på 32-bitars arkitektur. På LCA 2012 Rusty Russell , att det finns många fler subtila skäl som kan förklara ökningen av minnesförbrukningen. Med det sagt så lever vi nu i en tid där vi har gigabyte minne, så vi klarar oss på något sätt.
Jag kan dock inte låta bli att känna att det är ett slöseri med resurser att allokera mer minne till något så grundläggande som terminalen. Dessa program borde vara de minsta av de minsta, borde kunna köras på vilken "låda" som helst, till och med en skokartong, om vi någonsin kommer till den punkt där de behöver utrustas med Linux-system (och du vet att det kommer att vara så ) . Men med dessa siffror kommer minnesanvändning att bli ett problem i framtiden i alla miljöer som kör flera terminaler förutom några av de lättaste och mest begränsade i kapacitet. För att kompensera för detta har GNOME Terminal, Konsole, urxvt, Terminator och Xfce Terminal ett Daemon-läge som låter dig styra flera terminaler genom en enda process, vilket begränsar deras minnesförbrukning.
Under mina tester kom jag till ett annat oväntat resultat angående diskläsa-skriva: Jag förväntade mig att inte se något alls här, men det visade sig att vissa terminaler skriver de mest omfattande data till disken. Så, VTE-biblioteket håller faktiskt en rullningsbuffert på disken (denna funktion , och detta händer fortfarande). Men till skillnad från äldre implementeringar, nu är åtminstone denna data krypterad med AES256 GCM (). Men en rimlig fråga uppstår: vad är det som är så speciellt med VTE-biblioteket att det kräver ett så icke-standardiserat tillvägagångssätt för implementering...
Slutsats
I den första delen av artikeln fann vi att VTE-baserade terminaler har en bra uppsättning funktioner, men nu ser vi att detta kommer med vissa prestandakostnader. Nu är minnet inget problem eftersom alla VTE-terminaler kan styras genom en Daemon-process, vilket begränsar deras aptit. Äldre system som har fysiska begränsningar för mängden RAM och kärnbuffertar kan dock fortfarande behöva tidigare versioner av terminaler, eftersom de förbrukar betydligt färre resurser. Även om VTE-terminaler presterade bra i genomströmningstest (rullning) är deras visningslatens över tröskeln som ställts in i GNOME Användarhandbok. VTE-utvecklare bör nog ta hänsyn till detta. Om vi tar hänsyn till att även för nybörjare av Linux-användare att stöta på en terminal är oundvikligt, kan de göra den mer användarvänlig. För erfarna nördar kan byte från standardterminalen till och med innebära mindre ansträngda ögon och möjligheten att undvika framtida arbetsrelaterade skador och sjukdomar på grund av långa arbetspass. Tyvärr är det bara den gamla xterm och mlterm som tar oss till den magiska pingtröskeln på 10 millisekunder, vilket är oacceptabelt för många.
Benchmarkmätningar visade också att på grund av utvecklingen av Linux grafiska miljöer var utvecklarna tvungna att göra ett antal kompromisser. Vissa användare kanske vill titta på vanliga fönsterhanterare eftersom de ger betydande ping-reduktion. Tyvärr gick det inte att mäta latens för Wayland: Typometer-programmet jag använde skapades för vad Wayland är designat för att förhindra: spionera på andra fönster. Jag hoppas att Wayland compositing presterar bättre än X.org, och jag hoppas också att någon i framtiden kommer att hitta ett sätt att mäta latens i den här miljön.
Källa: will.com