Një fjalë nga zyra jonë e përkthimit: zakonisht të gjithë përpiqen të përkthejnë materialet dhe publikimet më të reja, dhe ne nuk jemi përjashtim. Por terminalet nuk janë diçka që përditësohet çdo javë. Prandaj, ne përktheu për ju artikullin e Antuan Bopre, botuar pranverën e vitit 2018: përkundër moshës së konsiderueshme sipas standardeve moderne, sipas mendimit tonë, materiali nuk ka humbur aspak aktualitetin. Për më tepër, në origjinal kjo është një seri dy artikujsh, por ne vendosëm t'i bashkojmë ata në një postim të madh.
Terminalet kanë një vend të veçantë në historinë e kompjuterëve, por në dekadat e fundit ato janë "detyruar" të mbijetojnë së bashku me komandën e linjës përballë përhapjes së gjerë të ndërfuqeve grafike. zëvendësuan , të cilët, nga ana e tyre, ishin modifikime të sistemeve me karta perforuese dhe tumblers. Distrot moderne vijnë me një sërë emuluesish terminali të të gjitha formave dhe ngjyrave. Dhe ndërsa shumë janë të kënaqur me terminalin standard që ofrohet nga ambienti i tyre të punës, disa me krenari përdorin softuer të hapur që është ndriçues për të parë shell-in e tyre të preferuar ose redaktuesin e tekstit. Por, si do ta shohim në këtë artikull, jo të gjithë terminalet janë krijuar në të njëjtën mënyrë: ato ndryshojnë shumë në funksionalitet, madhësi dhe performancë.
Disa terminale kanë ndisa vrima të habitshme në siguri, përveç kësaj, shumica kanë një grup tërësor funksionesh, nga mbështetje për ndërfaqen me skeda deri te skriptet. Megjithatë, ne , ky artikull është një azhurnim i materialeve të mëparshme që do t'u ndihmojë lexuesve të vendosin se cili terminal të përdorin në vitin 2018. Në gjysmën e parë të artikullit krahasohen funksionalitetet, ndërsa në gjysmën e dytë vlerësohet performanca.
Ja terminalet që shqyrtova:
Ndoshta ato nuk janë versionet më të fundit, pasi unë u kufizova në ndërtimet stabile në momentin e shkrimit të materialit, të cilat pata mundësi t'i instaloj në Debian 9 ose Fedora 27. Pjesa e vetme përjashtuese është Alacritty. Ajo është pasardhëse e terminaleve me GPU të përshpejtuar dhe është shkruar në një gjuhë të pazakonshme dhe të re për këtë detyrë — Rust. E kam përjashtuar nga shqyrtimi im terminalet në internet (përfshirë ato në ), pasi testet preliminare treguan performancë shumë të ulët.
Mbështetje për unicode
Testet e mia filluan me mbështetje për unicode. Testi i parë i terminaleve ishte shfaqja e këtyre karaktereve unicode nga : "é, Δ, Й, ק, م, ๗, あ, 叶, 葉 dhe 말". Ky test i thjeshtë tregon nëse terminali mund të funksionojë siç duhet në të gjithë botën. Terminali xterm nuk shfaq simbolin arab në konfigurimin e paracaktuar:
Sipas default, xterm përdor fontin klasik "të ngurtë", i cili, sipas , ka "mbulim të konsiderueshëm të unicode që nga viti 1997". Në këtë font ndodh diçka që e bën simbolin të shfaqet si një kuti bosh dhe vetëm kur rritet madhësia e tekstit në 20+ pikë, simboli fillon të shfaqet siç duhet. Megjithatë, ky "fix" prish shfaqjen e simboleve të tjera unicode:
Këto screenshot u bënë në Fedora 27, pasi kjo ofroi rezultatet më të mira, duke qenë se Debian 9 kishte disa versione të vjetra të terminaleve (në veçanti — mlterm) që nuk mund të funksiononin siç duhet me fontet. Fatmirësisht, kjo u rregullua në versionet më të reja.
Tani të kthehemi në shfaqjen e vargut në xterm. Me sa duket, simboli Mem dhe ai që e ndjek Semitic i përkasin skenarëve të tiparizimit RTL (), prandaj teknikisht ata duhet të shfaqen nga e drejta në të majtë. Shfletuesit e internetit, për shembull Firefox 57, e trajtojnë siç duhet vargun e mësipërm. Një variant më i thjeshtë i tekstit RTL është fjalë "" në hebraisht (). thotë si vijon:
"Shumë programe kompjuterike nuk mund të shfaqin siç duhet tekstin bidirekht. Për shembull, emri hebre "Sara" përbëhet nga simbolet sin (ש) (i cili shfaqet nga e djathta), pastaj resh (ר) dhe, në fund, he (ה) (i cili duhet të shfaqet nga e majta)."
Shumë terminale nuk kalojnë këtë test: Alacritty, terminalet e derivuara VTE Gnome dhe XFCE, urxvt, st dhe xterm shfaqin "Sara" në rend të kundërt, sikur ta shkruan emrin si "Aras".
Një problem tjetër i teksteve dyanshëm është se ato duhet të rregullohen ndonjëherë, veçanërisht nëse bëhet fjalë për përzierjen e teksteve RTL dhe LTR. Skenarët RTL duhet të fillojnë nga e djathta e dritares së terminalit, por çfarë duhet të ndodhë për terminalet që funksionojnë si standard me anglishten LTR? Shumica prej tyre nuk kanë mekanizma të veçantë dhe rregullojnë të gjithë tekstin në anën e majtë (përfshirë edhe në Konsole). Përjashtim nga kjo janë pterm dhe mlterm, të cilat përputhen me standardet dhe rregullojnë këto rreshta në anën e djathtë.
Mbrojtja nga ngjitja
Karakteristika tjetër kritike që e kam identifikuar është mbrojtja nga ngjitja. Edhe pse është e njohur gjerësisht që komanda:
$ curl http://example.com/ | shështë një komandë push për ekzekutimin e kodit, shumë pak njerëz e dinë se komandat e fshehura mund të depërtojnë në konsolë kur ngjiten nga shfletuesi, edhe pas një shqyrtimi të kujdesshëm. tregon shkëlqyeshëm se si komandë që duket e pafajshme:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitkthehet kur ngjitet nga faqja e Horner në terminal në këtë problem të pakëndshëm:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nIshte një ide e keqe. Mos kopjoni kod nga faqe që nuk besoni!
Ja rreshti i parë i /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitSi funksionon kjo? Kodi i dëmshëm është nxjerrë në një bllok , i cili është zhvendosur nga fusha e shikimit të përdoruesit me mjete CSS.
kjo është shprehimisht e destinuar për të neutralizuar këto sulme. Në këtë mënyrë, terminalet e mbyllin tekstin e ngjitur në një çift të veçantë të sekuencave escape, për t'i informuar shell-in për origjinën e këtij teksti. Kështu shell-i merr sinjalin se mund të injorojë simbolet speciale që mund të përmbajë teksti i ngjitur. Të gjithë terminalet, duke përfshirë xterm-in e nderuar, mbështesin këtë funksion, por ngjitja në Regjimin e Kllapave ka nevojë për mbështetje nga shell-i ose aplikacioni i ekzekutuar në terminal. Për shembull, softueri që përdor (edhe Bash), ka nevojë për skedarin ~/.inputrc:
set enable-bracketed-paste onFatkeqësisht, faqja e testit e Horner-it gjithashtu tregon se si të kalosh këtë mbrojtje përmes formatimit të tekstit dhe përfundimit të parakohshëm të përdorimit të Regjimit të Kllapave. Kjo funksionon, sepse disa terminale filtrojnë gabimisht sekuencat escape përpara se të shtojnë të kuptueshme të tyren. Për shembull, në të miat asnjëherë nuk kam arritur të përfundoj suksesisht testet në Konsole edhe duke marrë parasysh konfigurimin e saktë .inputrc të skedarit. Kjo do të thotë se mund të keni lehtë dëmtime në konfigurimin e sistemit për shkak të një aplikacioni të papërshtatshëm ose shell-i të keqkonfiguruar. Kjo është veçanërisht e rrezikshme kur hyni në servera të largët, ku një përpunim i kujdesshëm i konfigurimit ndodh më rrallë, sidomos nëse keni shumë nga këto makina të largëta.
Një zgjidhje e mirë për këtë problem është plugu i konfirmimit të ngjitjes për terminalin urxvt, i cili thjesht kërkon leje për të ngjitur çdo tekst që përmban në të rruaza të reja. Nuk kam gjetur një version më të sigurt për sulmin tekstual të përshkruar nga Horner.
Tabulat dhe profilet
Një funksion tani të njohur është mbështetje e ndërfaqes me tabula, të cilën do ta përcaktosh si një dritare terminali që përmban disa terminale të tjera. Për terminale të ndryshme, ky funksion ndryshon, dhe ndonëse terminalet tradicionale si xterm nuk mbështesin fare tabulat, inkarnacione më moderne të terminalit si Xfce Terminal, GNOME Terminal dhe Konsole e kanë këtë funksion. Po ashtu, mbështetje për tabulat ka edhe Urxvt, por vetëm nëse përdoret një plugin. Por nga pikëpamja e mbështetjes së tabave, që stili si qëndron, istori i padiskutueshëm është Terminator: ai jo vetëm që mbështet tabulat, por gjithashtu mund të vendosë terminalet në rendin sipas dëshires (shih imazhin më poshtë).
Një veçori tjetër e Terminator është mundësia për "të grupuar" këto tabula së bashku dhe të dërgojë të njëjtat shtypje çelësi në disa terminale në të njëjtën kohë, duke siguruar një mjet të thjeshtë për të ekzekutuar operacione masive në disa servera në të njëjtën kohë. Një funksion i ngjashëm është gjithashtu i implementuar në Konsole. Për të përdorur këtë funksion në terminale të tjera, është e nevojshme të përdorësh softuer të jashtëm, të tillë si , ose .
Veçanërisht, skedat fonctionojnë shumë mirë në bashkëpunim me profilët: për shembull, mund të keni një skedë për email, një tjetër për bisedë dhe kështu me radhë. Kjo mbështetet mirë nga terminali Konsole dhe GNOME Terminal. Të dy lejojnë që çdo skedë të niset automatikisht me profilin e saj. Terminator gjithashtu mbështet profilët, por nuk kam arritur të gjej një mënyrë për të nisur automatikisht programe të caktuara kur hap një skedë të caktuar. Terminalet e tjera nuk kanë fare konceptin e "profilit".
Ruzhe
Gjëja e fundit që do të shqyrtoj në këtë pjesë të parë të artikullit është pamja e terminaleve. Për shembull, GNOME, Xfce dhe urxvt mbështesin transparencën, por së fundmi ata kanë ndaluar mbështetje për imazhet e prapme, gjë që ka detyruar disa përdorues të kalojnë në terminalin . Personalisht, jam mjaft i kënaqur dhe mjaft Xresources, i cili vendos një grup bazik ngjyrash për sfondin për urxvt. Megjithatë, temat e ngjyrave jo standarde mund të krijojnë gjithashtu probleme. Për shembull, me aplikacionet dhe , pasi ata tashmë përdorin ngjyrat e tyre të veta.
nuk mbështeste ngjyrat, ndërsa të rejat shpesh kufizoheshin në një paletë 256-ngjyrash. Për përdoruesit e avancuar, të cilët personalizojnë terminalet e tyre, kërkesat për shell ose vijat e statusit në mënyra komplekse mund të bëhen një kufizim shqetësues. ndjek se cilat terminale kanë mbështetje për "True Color". Testet e mia konfirmojnë se st, Alacritty dhe terminalet e bazuara në VTE mbështesin perfekt True Color. Terminalet e tjera në këtë rast nuk performojnë mirë dhe në fakt nuk shfaqin as 256 ngjyra. Më poshtë mund të shihni diferencën midis mbështetjes True Color në terminalet GNOME, st dhe xterm, të cilat performojnë mirë me paletën e tyre 256-ngjyrash, dhe urxvt, i cili jo vetëm që nuk kalon testin, por madje shfaq disa simbole që dridhen në vend të tyre.
Disa terminale gjithashtu analizojnë tekstin për modele URL-sh, për ta bërë lidhjet klikueshme. Kjo i përket të gjitha terminaleve të dérivuar nga VTE, ndërsa urxvt kërkon një modul të veçantë që do të transformonte URL-të me klikim ose me një kombinim tastesh. Terminalet e tjera që kam testuar shfaqin URL-të në mënyra të tjera.
Finalmente, një trend i ri në terminale është opzioni për mbushjen e ri. Për shembull, në st nuk ka mbushje të ri; supozohet që përdoruesi do të përdorë një shumë-përdorues të terminalit, si tmux dhe .
Në Alacritty gjithashtu nuk ka mbushje të rikthimit, por për shkak të "feedback-it të gjerë" mbi këtë temë nga përdoruesit. Përveç këtyre rasteve, çdo terminal tjetër që kam testuar mbështet rikthimin.
Shkurtimisht
Në pjesën e dytë të materialit (në origjinë ishin dy artikuj të ndryshëm, — shën. red.) ne do të krahasojmë performancën, përdorimin e memories dhe vonesën. Por tashmë shohim se disa nga terminalet e shqyrtuara kanë mangësi të qëndrueshme. Për shembull, përdoruesit që punojnë rregullisht me skripte RTL mund të vërejnë mlterm dhe pterm, pasi ata i përballojnë këto detyra më mirë se të tjerët. Konsole gjithashtu ka treguar performancë të mirë. Përdoruesit që nuk punojnë me skripte RTL mund të zgjedhin ndonjë gjë tjetër.
Nga perspektiva e sigurisë ndaj ngjyrave të dëmshme, urxvt dallohet për implementimin e tij të veçantë të mbrojtjes nga këtë lloj sulmi, që më duket gjithsesi e dobishme. Ata që kërkojnë ndonjë luks mund të shikojnë Konsole. Së fundmi, është e rëndësishme të theksohet se VTE është një bazë e shkëlqyer për terminale, që siguron mbështetje për ngjyrat, njohjen e URL-ve dhe kështu me radhë. Në pamje të parë, terminali default që vjen me ambientin tuaj të preferuar mund të plotësojë të gjitha kërkesat, por do ta mbajmë këtë pyetje të hapur derisa të kuptojmë performancën.
Të vazhdojmë diskutimin
Në tërësi, performanca e terminaleve mund të duket një problem i tepruar, megjithatë, siç del, disa prej tyre tregojnë vonesa befasuese për një software të tillë bazik. Gjithashtu do të shqyrtojmë atë që tradicionalisht quhet "shpejtësi" (në të vërtetë, kjo është shpejtësia e skrollimit) dhe konsumimi i memories nga terminali (duke pasur parasysh se sot kjo nuk është aq kritike sa ka qenë disa dekada më parë).
Vonesa
Pas një shqyrtimi të kujdesshëm të performancës së terminaleve, kam arritur në përfundimin se parametri më i rëndësishëm në këtë aspekt është madhësia e vonesës (ping). Në artikullin tim Pavel Fatin shqyrtoi vonesat e redaktorëve të ndryshëm të teksteve dhe sugjeroi se terminalet në këtë drejtim mund të funksionojnë më ngadalë se redaktuesit më të shpejtë të teksteve. Ky sugjerim më çoi në fund të fundit në kryerjen e testeve të mia dhe shkruan këtë artikull.
Por çfarë është vonesa, dhe pse është kaq e rëndësishme? Në artikullin e tij, Fatin e përcakton atë si "vonese midis shtypjes së tastit dhe azhurnimit përkatës të ekranit" dhe citon , i cili thotë: "Vonesa në kthimin vizual në ekranin e kompjuterit ka një ndikim të rëndësishëm në sjelljen e përdoruesit dhe kënaqësinë e tij."
Fatin shpjegon se një vonesë e tillë ka pasoja më të thella, përveç thjesht kënaqësisë: "shkrimi bëhet më i ngadaltë, ndodhin më shumë gabime, tensioni i syve dhe muskujve rritet." Me fjalë të tjera, një vonesë më e madhe mund të çojë në gabime shtypi, po ashtu dhe në uljen e cilësisë së kodit, sepse shkakton një ngarkesë të shtuar kognitive në tru. Por çfarë është edhe më keq, vonesa "rrit tensionin e syve dhe muskujve", që duket se nënkupton në të ardhmen (duke pasur parasysh se autori ka në mendje problemet me muskujt e syve, shpinë, duar dhe, sigurisht, shikimin, - shënim i redaktorit.) për shkak të tensionit të përsëritur.
Disa nga këto efekte njihen prej kohësh, dhe rezultatet , të publikuara që në vitin 1976 në revistën Ergonomics, tregojnë se vonesa prej 100 milisekondash "përkeqëson ndjeshëm shpejtësinë e shkrimit". Së fundmi, në manualin e përdoruesit GNOME është futur prej 10 milisekondash, ndërsa nëse shkojmë më tej, tregon se ideali është 1 milisekondë.
Fatin kryen testet e tij në redaktorët e teksteve; ai krijoi një mjet portativ të quajtur , i cili e përdora për të testuar vonesën në emulatorët e terminaleve. Kini parasysh se testi u krye në mënyrë simuluese: në realitet, ne duhet të marrim parasysh dhe vonesën e hyrjes (tastiera, kontrolluesi USB etj.) dhe të daljes (bufferi i kartës grafike, monitori). Sipas Fatin, në konfiguratat tipike ajo është rreth 20 ms. Nëse kemi pajisje lojtarësh, mund të arrijmë një nivel prej vetëm 3 milisekondash. Pasi kemi tashmë pajisje kaq të shpejta, aplikacioni nuk duhet të shtojë një vonesë. Qëllimi i Fatin është ta ulim vonesën e aplikacionit në 1 milisekondë, ose të arrijmë të shkruajmë pa , si në .
Ja rezultatet e matjeve të mia, si dhe disa rezultate të Fatin për të treguar se eksperimentimi im është në përputhje me testet e tij:
Gjithçka që më befasoi ishte koha më e mirë e reagimit te programet e vjetra, si xterm dhe mlterm. Me një vonesë të keqe regjistrimi (2,4 ms), ato treguan rezultate më të mira se terminali më i shpejtë modern (10,6 ms për st). Asnjë terminal modern nuk shkonte më poshtë pragu prej 10 milisekondash. Në veçanti, Alacritty nuk i përmbush kërkesat për "terminalin më të shpejtë që ekziston", edhe pse rezultatet e tij janë përmirësuar që nga kontrolli i parë në vitin 2017. Në fakt, autorët e projektit dhe po punojnë për përmirësimin e shfaqjes. Gjithashtu, është e rëndësishme të theksohet se Vim, që përdor GTK3, është dukshëm më i ngadaltë se ai GTK2. Nga kjo mund të konkludohet se GTK3 krijon një vonesë shtesë, dhe kjo reflektohet në të gjitha terminalet e tjera që e përdorin atë (Terminator, Xfce4 Terminal dhe GNOME Terminal).
Megjithatë, për syrin dallimet mund të jenë të padukshme. Siç shpjegon Fatin: "nuk është e nevojshme të jesh i vetëdijshëm për ekzistencën e vonesës që ajo të ketë një efekt mbi ty." Fatin gjithashtu paralajmëron për devijimin standard: "çdo ndërhyrje në kohën e vonesës (dridhje) krijon një ngarkesë shtesë për shkak të paparashikueshmërisë së tyre."
Grafiku më sipër është marrë në një Debian 9 (stretch) të pastër me . Ky mjedis tregon rezultatet më të mira në testet për përcaktimin e vonesave. Siç duket, GNOME shkakton një ping shtesë prej 20 ms për të gjitha matjet. Një shpjegim i mundshëm për këtë është pranija e programeve me përpunim sinkron të ngjarjeve hyrëse. Fatin citon për këtë rast , i cili shton një vonesë duke përpunuar të gjitha ngjarjet hyrëse në mënyrë sinkrone. Në mënyrë që, GNOME gjithashtu vjen me një menaxher dritare , i cili krijon një nivel të shtuar buferimi, që ndikon në ping dhe shton të paktën 8 milisekonda vonesë.
Shpejtësia e rrotullimit
Testi i ardhshëm është një kontroll tradicional i "shpejtësisë" ose "gjerësisë së brejtjes", i cili mat se sa shpejt terminali mund të rrokullisë një faqe, duke shfaqur një sasi të madhe teksti në ekran. Mekanika e testit variaton; testi origjinal përfshinte thjesht gjenerimin e të njëjtës varg teksti duke përdorur komandën seq. Teste të tjera përfshijnë provimin e Thomas E. Dick, ku përfshihet një xterm, në kuadër të cilit shkarkohet përsëritshëm . Në një shqyrtim të tjetër performance të terminaleve, përdor një varg bytesh të rastësishme në kodimin base32, i cili shfaqet në terminal përmes cat. Liu e konsideron këtë test "në mënyrë aq hiperbolike të padobishme sa është e mundur" dhe sugjeron të përdorë përgjigjen e terminalit si treguesin kryesor. Dick gjithashtu e quajti testin e tij të dyshimtë. Megjithatë, të dy autorët e pranojnë se gjerësia e brejtjes së dritares së terminalit mund të jetë një problem. Liu vuri re që Emacs Eshell ngec gjatë shfaqjes së fajllave të mëdhenj, dhe Dick optimizoi terminalin për të eleminuar ngadalësinë vizuale të xterm. Prandaj, në këtë test ka ende një farë sensi, por për shkak se procesi i renderingut ndikon ndjeshëm nga terminali në terminal, mund të përdoret gjithashtu si një komponent testi për të kontrolluar parametra të tjerë.
Këtu shohim se rxvt dhe st dalin përpara në krahasim me konkurrencën, pasuar nga Alacritty, i cili është zhvilluar me fokus në performancë. Më pas vijnë Xfce (familja VTE) dhe Konsole, të cilat funksionojnë pothuajse dyfish më shpejt. I fundit është xterm, me një tregues pesë herë më të ngadaltë se rxvt. Gjatë testit, xterm gjithashtu pati shumë shkëlqime, duke bërë që të ishte e vështirë të dallohej teksti që kalonte, edhe nëse ishte e njëjta linjë. Konsole rezultoi të ishte i shpejtë, por nganjëherë "gënjente": ekrani nganjëherë ngec, duke shfaqur tekstin pjesërisht ose duke mos e shfaqur fare. Terminalet e tjera shfaqin linjat qartë, duke përfshirë st, Alacritty dhe rxvt.
Dick shpjegon se dallimet në performancë lidhen me dizajnin e bufferave të rrokullisjes në terminale të ndryshme. Në veçanti, ai akuzon rxvt dhe terminalet e tjera për "mos ndjekjen e rregullave të përgjithshme":
"Ndryshe nga xterm, rxvt nuk përpiqej të shfaqte të gjitha përditësimet. Nëse ndalonte, do të ndalonte disa përditësime për t'u rikthyer në kohë. Kjo kishte një ndikim më të madh në shpejtësinë e rrokullisjes sesa në organizimin e memories së brendshme. Një dobësi ishte se animacioni ASCII ishte disi i pasaktë."
Për të korrigjuar këtë dukje të ngadalësisë së xterm, Dick sugjeron përdorimin e burimit , i cili lejon xterm të heqë disa përditësime të ekranit për të mos u prapa nga fluksi. Testet e mia konfirmojnë se fastScroll rrit performancën dhe e bën xterm të krahasueshëm me rxvt. Megjithatë, kjo është një zgjidhje mjaft e papërpunuar, siç shpjegon vetë Dick: "në disa raste xterm — si dhe konsole — duket se ndalonte, pasi pret një set të ri përditësimesh të ekranit pasi disa nga ato janë hequr." Në këtë drejtim, duket se terminalet e tjera kanë gjetur kompromisin optimal midis shpejtësisë dhe integritetit të ekranit.
Konsumimi i burimeve
Pavarësisht nga dobia e shqyrtimit të shpejtësisë së rrokullisjes si një tregues performancë, ky test lejon përshkaktimin e ngarkesave në terminale, duke na mundësuar të matim parametra të tjerë si përdorimi i memories ose i diskut. Metrit janë arritur duke ekzekutuar testin e caktuar seq në mbikëqyrje të procesit Python. Ai grumbulloi të dhëna për numrat e caktuar për ru_maxrss, shumën ru_oublock dhe ru_inblock dhe një thjesht timer të kohës.
Në këtë test, ST zë vendin e parë me vëllimin më të ulët mesatar të memories së konsumuar në 8 MB, gjë që nuk është befasi, nëse merren parasysh se ideja kryesore e projektit është thjeshtësia. Pak më shumë konsumon mlterm, xterm dhe rxvt — rreth 12 MB. Një rezultat tjetër domethënës është Alacritty, i cili kërkon 30 MB për të funksionuar. Më pas vijnë terminalet e familjes VTE me tregues nga 40 në 60 MB, që është mjaft e lartë. Një konsum i tillë mund të shpjegohet nga fakti se këto terminale përdorin biblioteka të nivelit më të lartë, si GTK. Konsole mbyll listën me një konsum të jashtëzakonshëm prej 65 MB memories gjatë testeve, edhe pse kjo mund të justifikohet me setin e tij të gjerë të funksionaliteteve.
Në krahasim me rezultatet e mëparshme, të marra dhjetë vjet më parë, të gjitha programet tani konsumojnë dukshëm më shumë memorie. Disa vite më parë, Xterm kërkonte 4 MB, ndërsa tani — 15 MB thjesht për të filluar. Po ashtu, rxvt tani kërkon 16 MB direkt nga kutia. Terminali Xfce zë 34 MB, që është tri herë më shumë se më parë, ndërsa GNOME Terminal kërkon vetëm 20 MB. Sigurisht, të gjitha testet e mëparshme janë kryer në një arkitekturë 32-bit. Në LCA 2012, Rasti Russell , ka shumë arsye më të ndërlikuara që mund të shpjegojnë rritjen e konsumit të memories. Megjithatë, tani jetojmë në një kohë kur kemi gigabajtë të tëra memorie, kështu që do t'ia dalim mbanë në një farë mënyre.
Megjithatë, nuk mund të shmang ndjenjën se ndarja e më shumë memories për një softuer kaq thelbësor si terminali — është një shpërdorim i burimeve. Këto programe duhet të jenë më të voglat nga më të vegjlit, duhet të jenë në gjendje të punojnë në çdo ‘kutizë’, madje edhe në një kutinë e këpucëve, nëse ndonjëherë do të arrijmë të pajisim kutitë me sisteme Linux (dhe ju e dini se kështu do të ndodhë). Po me këto shifra, përdorimi i memories do të bëhet një problem në të ardhmen në çdo mjedis kur hapim disa terminale, përveç rasteve me disa nga terminalet më të lehta dhe të kufizuara. Për ta kompensuar këtë, GNOME Terminal, Konsole, urxvt, Terminator dhe Xfce Terminal kanë një mod të Daemon-it, i cili lejon menaxhimin e disa terminaleve përmes një procesi, që kufizon konsumimin e memories.
Gjatë testeve të mia kam arritur në një rezultat tjetër të papritur në lidhje me leximin-shkrimin në disk: prisja të mos shihja asgjë këtu, por doli se disa terminale shkruajnë të dhënat më të mëdha në disk. Pra, biblioteka VTE në fakt mban në disk buferin e skrollingut (kjo veçori , dhe kjo vazhdon deri tani). Por ndryshe nga zbatimet e vjetra, tani të paktën këto të dhëna janë të koduara me AES256 GCM (). Por lind një pyetje e arsyeshme, çfarë ka kaq të veçantë biblioteka VTE, saqë kërkon një qasje të tillë të pazakontë në zbatim…
Përfundimi
Në pjesën e parë të artikullit, zbuluam se terminalet e bazuara në VTE kanë një set të mirë funksionesh, por tani shohim se kjo lidhet me disa shpenzime për të siguruar performancën e tyre. Tani memoria nuk është një problem, sepse të gjitha terminalet VTE mund të menaxhohen përmes një procesi Daemon të cilat kufizojnë apetitin e tyre. Megjithatë, sistemi i vjetër, që ka kufizime fizike për sa i përket memories dhe buferit të bërthamës, mund të ketë ende nevojë për versionet e mëparshme të terminaleve, pasi ato konsumojnë ndjeshëm më pak burime. Edhe pse terminalet VTE e kanë treguar veten mirë në testet për kapacitetin (skrollim), vonesa e paraqitjes së të dhënave në ekran është mbi pragun e përcaktuar në manualin e përdoruesit GNOME. Ka shumë mundësi që zhvilluesit e VTE të duhet ta kenë parasysh këtë. Duke marrë parasysh se edhe për përdoruesit fillestarë të Linux është e pashmangshme të takojnë terminalin, ata mund ta bëjnë atë më miqësor ndaj përdoruesve. Për geek-at e njohur, kalimi nga terminali në parazgjedhje mund të nënkuptojë madje edhe një ulje në ngarkesën në sy dhe mundësinë për të shmangur lëndimet dhe sëmundjet profesionale në të ardhmen për shkak të sesioneve të gjata të punës. Fatkeqësisht, vetëm xterm-i i vjetër dhe mlterm na çojnë në pragun magjik të pingut prej 10 milisekondash, që për shumë njerëz është e papranueshme.
Masat e kontrolleve gjithashtu treguan se për shkak të zhvillimit të ambientit grafik në Linux, zhvilluesit u detyruan të bënin një sërë kompromisesh. Disa përdorues duhet të shikojnë menaxherët e zakonshëm të dritareve, pasi ata ofrojnë një ulje të konsiderueshme të pingut. Fatkeqësisht, për Wayland nuk arrita të mas përdorimin e vonesave: programi Typometer, që kam përdorur, ishte krijuar për atë që Wayland është caktuar të parandalojë — spiunimin e dritareve të tjera. Shpresoj se kompozimi i Wayland ka performancë më të mirë se X.org, dhe gjithashtu shpresoj se në të ardhmen dikush do të gjejë një mënyrë për të vlerësuar nivelin e vonesës në këtë ambient.
Burimi: habr.com
