Disa fjalë nga byroja jonë e përkthimit: zakonisht të gjithë përpiqen të përkthejnë materialet dhe botimet më të fundit, dhe ne nuk bëjmë përjashtim. Por terminalet nuk janë diçka që përditësohet një herë në javë. Prandaj, ne kemi përkthyer për ju një artikull nga Antoine Beaupré, botuar në pranverën e vitit 2018: megjithë "moshën" e tij të konsiderueshme sipas standardeve moderne, sipas mendimit tonë, materiali nuk e ka humbur fare rëndësinë e tij. Për më tepër, kjo ishte fillimisht një seri prej dy artikujsh, por ne vendosëm t'i kombinojmë ato në një postim të madh.
Terminalet kanë një vend të veçantë në historinë e kompjuterit, por në dekadat e fundit ata janë detyruar të mbijetojnë së bashku me linjën e komandës pasi ndërfaqet grafike bëhen të kudogjendura. zëvendësuan të tyren , të cilat, nga ana tjetër, ishin një modifikim i sistemeve të bazuara në kartat me grushta dhe ndërprerës. Shpërndarjet moderne vijnë me një sërë emulatorësh terminalesh të të gjitha formave dhe ngjyrave. Dhe ndërsa shumë janë të kënaqur me terminalin standard të ofruar nga mjedisi i tyre i punës, disa përdorin me krenari softuerin ekzotik për të ekzekutuar redaktuesin e tyre të preferuar të guaskës ose tekstit. Por, siç do të shohim nga ky artikull, jo të gjithë terminalet u krijuan në të njëjtin imazh: ato ndryshojnë shumë në funksionalitet, madhësi dhe performancë.
Disa terminale kanë vrima sigurie krejtësisht befasuese, plus shumica kanë një grup funksionesh krejtësisht të ndryshme, nga mbështetja për një ndërfaqe me skeda te skriptet. Edhe pse ne , ky artikull është një përditësim i materialit të mëparshëm që do t'i ndihmojë lexuesit të përcaktojnë se cilin terminal të përdorin në 2018. Gjysma e parë e artikullit krahason veçoritë, dhe gjysma e dytë vlerëson performancën.
Këtu janë terminalet që kam shqyrtuar:
Këto mund të mos jenë versionet më të fundit, pasi isha i kufizuar në ndërtime të qëndrueshme në kohën e shkrimit, të cilat munda t'i shpërndaja në Debian 9 ose Fedora 27. Përjashtimi i vetëm është Alacritty. Është një pasardhës i terminaleve të përshpejtuar nga GPU dhe është shkruar në një gjuhë të pazakontë dhe të re për këtë detyrë - Rust. I përjashtova terminalet e internetit nga rishikimi im (përfshirë ato në ), sepse testet paraprake treguan performancën e tyre jashtëzakonisht të dobët.
Mbështetje Unicode
Fillova testet e mia me mbështetjen e Unicode. Testi i parë i terminaleve ishte shfaqja e vargut Unicode nga : "é, Δ, И, ק, م, ๗, あ, 叶, 葉 dhe 말." Ky test i thjeshtë tregon nëse terminali mund të funksionojë siç duhet në mbarë botën. Terminali xterm nuk shfaq karakter arab në konfigurimin e paracaktuar:
Si parazgjedhje, xterm përdor fontin klasik "fiks", i cili, sipas , ka "mbulim të konsiderueshëm të Unicode që nga viti 1997". Ka diçka që po ndodh në këtë font që bën që karakteri të shfaqet si një kornizë bosh dhe vetëm kur fonti i tekstit rritet në 20+ pikë, karakteri më në fund fillon të shfaqet saktë. Sidoqoftë, ky "rregullim" prish shfaqjen e karaktereve të tjera të Unicode:
Këto pamje nga ekrani u morën në Fedora 27, pasi dha rezultate më të mira se Debian 9, ku disa versione më të vjetra të terminaleve (veçanërisht mlterm) nuk mund të trajtonin fontet siç duhet. Për fat të mirë kjo u rregullua në versionet e mëvonshme.
Tani vini re se si shfaqet rreshti në xterm. Rezulton se simboli Mem dhe semiti në vijim referojuni skripteve të stilit RTL (), kështu që teknikisht ato duhet të shfaqen nga e djathta në të majtë. Shfletuesit e uebit si Firefox 57 trajtojnë saktë rreshtin e mësipërm. Një version më i thjeshtë i tekstit RTL është fjala ""në hebraisht (). thotë sa vijon:
“Shumë programe kompjuterike nuk mund të shfaqin saktë tekstin dydrejtimësh. Për shembull, emri hebraik "Sarah" përbëhet nga karakteret sin (ש) (që shfaqet në të djathtë), pastaj resh (ר) dhe në fund ai (ה) (që duhet të shfaqet në të majtë).
Shumë terminale dështojnë në këtë test: Alacritty, terminalet Gnome dhe XFCE të rrjedhura nga VTE, urxvt, st dhe xterm shfaqin "Sara" në rend të kundërt, sikur të kishim shkruar emrin si "Aras".
Një problem tjetër me tekstet me dy drejtime është se ato duhet të përafrohen disi, veçanërisht kur bëhet fjalë për përzierjen e teksteve RTL dhe LTR. Skriptet RTL duhet të ekzekutohen nga ana e djathtë e dritares së terminalit, por çfarë duhet të ndodhë me terminalet që parazgjedhin në LTR English? Shumica e tyre nuk kanë ndonjë mekanizëm të veçantë dhe rreshtojnë të gjithë tekstin në të majtë (përfshirë në Konsole). Përjashtimet janë pterm dhe mlterm, të cilat i përmbahen standardeve dhe rreshtojnë linja të tilla djathtas.
Mbrojtja e futjes
Tipari tjetër kritik që kam identifikuar është mbrojtja kundër futjes. Edhe pse dihet gjerësisht se magji si:
$ curl http://example.com/ | shjanë komanda shtytëse të ekzekutimit të kodit, pak njerëz e dinë se komandat e fshehura mund të futen fshehurazi në tastierë kur kopjoni dhe ngjitni nga një shfletues uebi, edhe pas inspektimit të kujdesshëm. tregon shkëlqyeshëm se sa e padëmshme është komanda:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitkthehet në një telash të tillë kur ngjitet nga faqja e internetit e Horn në terminal:
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.gitSi punon? Kodi me qëllim të keq është përfshirë në bllok , e cila zhvendoset nga pamja e përdoruesit duke përdorur CSS.
është krijuar qartë për të neutralizuar sulme të tilla. Në këtë modalitet, terminalet e mbyllin tekstin e ngjitur në një palë sekuencash të veçanta ikjeje për t'i treguar predhës rreth origjinës së tekstit. Kjo i tregon shell-it se mund të injorojë karaktere të veçanta që mund të përmbajë teksti i ngjitur. Të gjithë terminalet e kthyera në xterm të nderuar e mbështesin këtë veçori, por ngjitja në modalitetin Bracketed kërkon mbështetje nga guaska ose aplikacioni që funksionon në terminal. Për shembull, përdorimi i softuerit (i njëjti Bash), ka nevojë për një skedar ~/.inputrc:
set enable-bracketed-paste onFatkeqësisht, faqja e testimit të Horn tregon gjithashtu se si të anashkalohet kjo mbrojtje përmes vetë formatimit të tekstit dhe të përfundojë para kohe duke aplikuar modalitetin Bracketed në të. Kjo funksionon sepse disa terminale nuk filtrojnë saktë sekuencat e ikjes përpara se të shtojnë të tyren. Për shembull, në timin nuk kam qenë kurrë në gjendje të përfundoj me sukses testet e Konsole edhe me konfigurimin e duhur .inputrc dosje. Kjo do të thotë që ju mund ta prishni lehtësisht konfigurimin e sistemit tuaj për shkak të një aplikacioni të pambështetur ose një guaskë të konfiguruar gabimisht. Kjo është veçanërisht e rrezikshme kur hyni në serverë në distancë, ku puna e kujdesshme e konfigurimit është më pak e zakonshme, veçanërisht nëse keni shumë makina të tilla në distancë.
Një zgjidhje e mirë për këtë problem është shtojca e konfirmimit të ngjitjes për terminalin urxvt, i cili thjesht kërkon leje për të futur çdo tekst që përmban rreshta të rinj. Nuk kam gjetur një opsion më të sigurt për sulmin e tekstit të përshkruar nga Horn.
Skedat dhe profilet
Një veçori e njohur tani është mbështetja për një ndërfaqe me skeda, të cilën ne do ta përcaktojmë si një dritare terminale që përmban disa terminale të tjera. Ky funksion ndryshon për terminale të ndryshëm dhe megjithëse terminalet tradicionale xterm nuk mbështesin fare skedat, mishërimet më moderne të terminaleve si Xfce Terminal, GNOME Terminal dhe Konsole e kanë këtë funksion. Urxvt gjithashtu mbështet skedat, por vetëm nëse përdorni një shtesë. Por për sa i përket vetë mbështetjes së skedave, Terminator është lideri i padiskutueshëm: ai jo vetëm që mbështet skedat, por gjithashtu mund të rregullojë terminalet në çdo mënyrë (shih imazhin më poshtë).
Një veçori tjetër e Terminator është aftësia për të "grupuar" këto skeda së bashku dhe për të dërguar të njëjtat goditje në terminale të shumta në të njëjtën kohë, duke ofruar një mjet të papërpunuar për kryerjen e operacioneve me shumicë në serverë të shumtë në të njëjtën kohë. Një veçori e ngjashme zbatohet gjithashtu në Konsole. Për ta përdorur këtë veçori në terminale të tjera, duhet të përdorni softuer të palëve të treta si p.sh , ose .
Skedat funksionojnë veçanërisht mirë kur çiftohen me profile: për shembull, mund të keni një skedë për email, një tjetër për chat etj. Kjo mbështetet mirë nga Konsole Terminal dhe GNOME Terminal. Të dyja lejojnë që çdo skedë të hapë automatikisht profilin e vet. Terminator gjithashtu mbështet profile, por nuk mund të gjeja një mënyrë për të nisur automatikisht programe të caktuara kur hapni një skedë specifike. Terminalet e tjerë nuk e kanë fare konceptin e "profilit".
Rrafet
Gjëja e fundit që do të mbuloj në pjesën e parë të këtij artikulli është pamja e terminaleve. Për shembull GNOME, Xfce dhe urxvt mbështesin transparencën, por kohët e fundit kanë hequr mbështetjen për imazhet e sfondit, duke detyruar disa përdorues të kalojnë në terminal . Personalisht, jam i kënaqur me të dhe është e thjeshtë Burimet X, i cili vendos grupin bazë të ngjyrave të sfondit për urxvt. Megjithatë, temat me ngjyra jo standarde mund të krijojnë gjithashtu probleme. Për shembull, me aplikacione и , pasi ato tashmë përdorin ngjyrat e tyre.
nuk mbështeste ngjyrat, dhe ato të reja shpesh kufizoheshin në një gamë me 256 ngjyra. Për përdoruesit e avancuar që stilojnë terminalet e tyre, kërkesat e guaskës ose shiritat e statusit në mënyra komplekse mund të jenë një kufizim i bezdisshëm. gjurmon se cilat terminale kanë mbështetje "True Color". Testet e mia konfirmojnë se terminalet st, Alacritty dhe VTE mbështesin në mënyrë perfekte True Color. Terminalet e tjerë nuk shkojnë shumë mirë në këtë drejtim dhe, në fakt, nuk shfaqin as 256 ngjyra. Më poshtë mund të shihni ndryshimin midis mbështetjes True Color në terminalet GNOME, st dhe xterm, të cilat e bëjnë mirë këtë me paletën e tyre 256 të ngjyrave, dhe urxvt, e cila jo vetëm që dështon në test, por edhe tregon disa karaktere që vezullojnë në vend të tyre.
Disa terminale gjithashtu analizojnë tekstin për modelet e URL-ve për t'i bërë lidhjet të klikueshme. Kjo vlen për të gjithë terminalet e prejardhur nga VTE, ndërsa urxvt kërkon një shtojcë të veçantë që do të transformonte URL-të me një klikim ose duke përdorur një shkurtore të tastierës. Terminalet e tjerë që kam testuar i shfaqin URL-të në mënyra të tjera.
Së fundi, një prirje e re në terminale është opsionaliteti i tamponit të lëvizjes. Për shembull, st nuk ka tampon lëvizës; supozohet se përdoruesi do të përdorë një multiplekser terminal si tmux dhe .
Alacritty-it gjithashtu i mungojnë buferat e rrotullimit, por mbështetjen e tij për shkak të "përgjigjeve të gjera" për këtë temë nga përdoruesit. Përveç këtyre fillimeve, çdo terminal që kam testuar dhe që kam gjetur mbështet lëvizjen e kundërt.
Nëntotalet
Në pjesën e dytë të materialit (në origjinal këto ishin dy artikuj të ndryshëm - përafërsisht. korsi) do të krahasojmë performancën, përdorimin e kujtesës dhe vonesën. Por tashmë mund të shohim se disa nga terminalet në fjalë kanë mangësi serioze. Për shembull, përdoruesit që punojnë rregullisht me skriptet RTL mund të dëshirojnë të marrin në konsideratë mlterm dhe pterm, pasi ata janë më të mirë në trajtimin e detyrave të ngjashme se të tjerët. Konsole gjithashtu performoi mirë. Përdoruesit që nuk punojnë me skriptet RTL mund të zgjedhin diçka tjetër.
Përsa i përket mbrojtjes kundër futjes së kodit me qëllim të keq, urxvt dallohet për shkak të zbatimit të veçantë të mbrojtjes kundër këtij lloji të sulmit, që më duket padyshim i përshtatshëm. Për ata që kërkojnë disa zile dhe bilbila, Konsole ia vlen të shikohet. Së fundi, vlen të përmendet se VTE është një bazë e shkëlqyer për terminalet, e cila garanton mbështetjen e ngjyrave, njohjen e URL-së, etj. Në pamje të parë, terminali i paracaktuar që vjen me mjedisin tuaj të preferuar mund të plotësojë të gjitha kërkesat, por le ta lëmë të hapur këtë pyetje derisa të kuptojmë performancën.
Le të vazhdojmë bisedën
Në përgjithësi, performanca e terminaleve në vetvete mund të duket si një problem i largët, por siç rezulton, disa prej tyre shfaqin vonesë çuditërisht të lartë për softuer të një lloji kaq themelor. Gjithashtu në vijim do të shikojmë atë që tradicionalisht quhet "shpejtësi" (në fakt, kjo është shpejtësia e lëvizjes) dhe konsumi i memories së terminalit (me paralajmërimin se kjo nuk është aq kritike sot sa ishte dekada më parë).
vonesë
Pas një studimi të plotë të performancës së terminalit, arrita në përfundimin se parametri më i rëndësishëm në këtë drejtim është vonesa (ping). Në artikullin e tij Pavel Fatin shikoi vonesën e redaktuesve të ndryshëm të tekstit dhe la të kuptohet se terminalet në këtë drejtim mund të jenë më të ngadaltë se redaktuesit më të shpejtë të tekstit. Ishte kjo aluzion që më çoi në fund të kryej testet e mia dhe të shkruaj këtë artikull.
Por çfarë është vonesa dhe pse është kaq e rëndësishme? Në artikullin e tij, Fatin e përkufizoi atë si "vonesa midis shtypjes së një tasti dhe përditësimit përkatës të ekranit" dhe citoi , i cili thotë: "Vonesa në reagimet vizuale në një ekran kompjuteri ka një ndikim të rëndësishëm në sjelljen dhe kënaqësinë e daktilografistëve."
Fatin shpjegon se ky ping ka pasoja më të thella sesa thjesht kënaqësi: "Shkrimi bëhet më i ngadalshëm, ndodhin më shumë gabime dhe tensioni i syve dhe muskujve rritet". Me fjalë të tjera, një vonesë e madhe mund të çojë në gabime shtypi dhe gjithashtu cilësi më të ulët të kodit, pasi çon në ngarkesë shtesë njohëse në tru. Por ajo që është më e keqja është se ping "rrit tendosjen e syve dhe muskujve", gjë që duket se nënkupton në të ardhmen (Me sa duket, autori nënkupton probleme me muskujt e syve, shpinës, krahëve dhe, natyrisht, shikimin - përafërsisht. korsi) për shkak të stresit të përsëritur.
Disa nga këto efekte janë të njohura për një kohë të gjatë dhe rezultatet , botuar në vitin 1976 në revistën Ergonomics, tha se një vonesë prej 100 milisekondash "dëmton ndjeshëm shpejtësinë e shtypjes". Kohët e fundit, u prezantua Udhëzuesi i Përdoruesit GNOME në 10 milisekonda, dhe nëse shkoni më tej, atëherë tregon se 1 milisekondë është ideale.
Fatin kreu testet e tij në redaktorët e tekstit; ai krijoi një instrument portativ të quajtur , të cilin e përdora për të testuar ping në emulatorët e terminalit. Mbani në mend se testi u krye në modalitetin e simulimit: në realitet, duhet të marrim parasysh si vonesën e hyrjes (tastierë, kontrollues USB, etj.) ashtu edhe në dalje (buferi i kartës video, monitor). Sipas Fatinit, në konfigurimet tipike është rreth 20 ms. Nëse keni pajisje për lojëra, mund ta arrini këtë shifër në vetëm 3 milisekonda. Meqenëse tashmë kemi një pajisje kaq të shpejtë, aplikacioni nuk duhet të shtojë vonesën e vet. Qëllimi i Fatin është të sjellë vonesën e aplikacionit në 1 milisekondë, ose edhe të arrijë numrin pa , si në .
Këtu janë rezultatet e matjeve të mia, si dhe disa nga rezultatet e Fatinit, për të treguar se eksperimenti im përputhet me testet e tij:
Gjëja e parë që më goditi ishte koha më e mirë e përgjigjes së programeve më të vjetra si xterm dhe mlterm. Me vonesën më të keqe të regjistrit (2,4 ms), ata performuan më mirë se terminali më i shpejtë modern (10,6 ms për st). Asnjë terminal modern nuk bie nën pragun e 10 milisekondave. Në veçanti, Alacritty nuk arrin të përmbushë pretendimin e "emulatorit më të shpejtë të terminalit në dispozicion", megjithëse rezultatet e tij janë përmirësuar që nga rishikimi i tij i parë në 2017. Në të vërtetë, autorët e projektit dhe po punojnë për të përmirësuar ekranin. Duhet gjithashtu të theksohet se Vim duke përdorur GTK3 është një rend i madhësisë më i ngadalshëm se homologu i tij GTK2. Nga kjo mund të konkludojmë se GTK3 krijon vonesë shtesë, dhe kjo reflektohet në të gjithë terminalet e tjerë që e përdorin atë (Terminator, Xfce4 Terminal dhe Terminal GNOME).
Megjithatë, dallimet mund të mos jenë të dukshme për syrin. Siç shpjegon Fatin, "nuk duhet të jeni të vetëdijshëm për vonesën që ajo të ndikojë tek ju." Fatin paralajmëron gjithashtu për devijimin standard: "çdo shqetësim në latente (dridhje) krijon stres shtesë për shkak të paparashikueshmërisë së tyre."
Grafiku i mësipërm është marrë në Debian 9 të pastër (shtrirje) me . Ky mjedis prodhon rezultatet më të mira në testet e vonesës. Siç rezulton, GNOME krijon një ping shtesë prej 20 ms për të gjitha matjet. Një shpjegim i mundshëm për këtë është prania e programeve me përpunim sinkron të ngjarjeve hyrëse. Fatin jep një shembull për një rast të tillë , e cila shton një vonesë duke përpunuar të gjitha ngjarjet e hyrjes në mënyrë sinkronike. Si parazgjedhje, GNOME vjen gjithashtu me një menaxher të dritareve , e cila krijon një shtresë shtesë buffering, e cila ndikon në ping dhe shton të paktën 8 milisekonda vonesë.
Shpejtësia e lëvizjes
Testi tjetër është një test tradicional i "shpejtësisë" ose "gjerësisë së brezit", i cili mat se sa shpejt terminali mund të lëvizë një faqe ndërsa shfaq sasi të mëdha teksti në ekran. Mekanika e testit ndryshon; testi origjinal ishte thjesht të gjeneronte të njëjtin varg teksti duke përdorur komandën seq. Teste të tjera përfshijnë testin e Thomas E. Dickey (mirëmbajtësi i xterm), i cili në mënyrë të përsëritur . Në një rishikim tjetër të performancës së terminalit përdor një varg të koduar bazë 32 me bajt të rastësishëm, i cili del në terminal duke përdorur cat. Luu e konsideron një test të tillë si "një pikë referimi të padobishme sa mund të imagjinohet" dhe sugjeron përdorimin e përgjigjes terminale si një metrikë parësore. Dickey gjithashtu e quan testin e tij mashtrues. Megjithatë, të dy autorët e pranojnë se gjerësia e brezit të dritares së terminalit mund të jetë një problem. Luu zbuloi ngrirjen e Emacs Eshell kur shfaqte skedarë të mëdhenj dhe Dickey optimizoi terminalin për të hequr qafe ngadalësinë vizuale të xtrerm. Pra, ka ende disa merita për këtë test, por duke qenë se procesi i paraqitjes është shumë i ndryshëm nga terminali në terminal, ai mund të përdoret gjithashtu si një komponent testimi për të testuar parametra të tjerë.
Këtu shohim tërheqjen rxvt dhe st përpara konkurrencës, të ndjekur nga Alacritty shumë më i ri, i cili është projektuar me fokus në performancë. Më pas janë Xfce (familja VTE) dhe Konsole, të cilat janë pothuajse dy herë më të shpejta. E fundit është xterm, e cila është pesë herë më e ngadalshme se rxvt. Gjatë provës, xterm gjithashtu lulëzoi shumë, duke e bërë kalimin e tekstit të vështirë për t'u parë edhe nëse ishte i njëjti rresht. Konsole ishte e shpejtë, por ndonjëherë ishte e ndërlikuar: ekrani ngrinte herë pas here, duke shfaqur tekst të pjesshëm ose duke mos e shfaqur fare. Terminalet e tjerë shfaqnin qartë vargjet, duke përfshirë st, Alacritty dhe rxvt.
Dickey shpjegon se ndryshimet e performancës janë për shkak të dizajnit të buferave të lëvizjes në terminale të ndryshëm. Në veçanti, ai akuzon rxvt dhe terminalet e tjerë se "nuk respektojnë rregullat e përgjithshme":
“Ndryshe nga xterm, rxvt nuk u përpoq të shfaqte të gjitha përditësimet. Nëse bie prapa, do të refuzojë disa përditësime për të kapur hapin. Kjo kishte një ndikim më të madh në shpejtësinë e dukshme të lëvizjes sesa në organizimin e kujtesës së brendshme. Një pengesë ishte se animacioni ASCII ishte disi i pasaktë."
Për të rregulluar këtë plogështi të perceptuar xterm, Dickey sugjeron përdorimin e burimit , duke lejuar xterm të heqë disa përditësime të ekranit për të vazhduar me rrjedhën. Testet e mia konfirmojnë se fastScroll përmirëson performancën dhe sjell xterm në të njëjtin nivel me rxvt. Megjithatë, kjo është një patericë mjaft e ashpër, siç shpjegon vetë Dickey: "nganjëherë xterm - si konsole - duket se ngec ndërsa pret për një grup të ri përditësimesh të ekranit pasi disa janë hequr." Në këtë drejtim, duket se terminalet e tjerë kanë gjetur kompromisin më të mirë midis shpejtësisë dhe integritetit të ekranit.
Konsumi i burimeve
Pavarësisht nëse ka kuptim të konsiderojmë shpejtësinë e lëvizjes si një metrikë të performancës, ky test na lejon të simulojmë ngarkesën në terminale, gjë që nga ana tjetër na lejon të matim parametra të tjerë si memoria ose përdorimi i diskut. Metrikat u morën duke ekzekutuar testin e specifikuar seq nën monitorimin e procesit Python. Ai mblodhi të dhënat e njehsorit për ru_maxrss, shuma ru_oublock и ru_inblock dhe një kohëmatës i thjeshtë.
Në këtë test, ST zë vendin e parë me konsumin mesatar më të ulët të memories prej 8 MB, gjë që nuk është për t'u habitur duke pasur parasysh se ideja kryesore e dizajnit është thjeshtësia. mlterm, xterm dhe rxvt konsumojnë pak më shumë - rreth 12 MB. Një tjetër rezultat i dukshëm është Alacritty, i cili kërkon 30 MB për t'u ekzekutuar. Pastaj ka terminale të familjes VTE me shifra nga 40 në 60 MB, që është shumë. Ky konsum mund të shpjegohet me faktin se këto terminale përdorin biblioteka të nivelit më të lartë, për shembull, GTK. Konsole vjen në vendin e fundit me një konsum të jashtëzakonshëm 65 MB memorie gjatë testeve, megjithëse kjo mund të justifikohet me gamën e saj shumë të gjerë të veçorive.
Krahasuar me rezultatet e mëparshme të marra dhjetë vjet më parë, të gjitha programet filluan të konsumojnë dukshëm më shumë memorie. Xterm dikur kërkonte 4 MB, por tani kërkon 15 MB vetëm në fillim. Ka një rritje të ngjashme në konsum për rxvt, i cili tani kërkon 16 MB jashtë kutisë. Terminali Xfce merr 34 MB, që është tre herë më i madh se më parë, por Terminali GNOME kërkon vetëm 20 MB. Sigurisht, të gjitha testet e mëparshme janë kryer në arkitekturën 32-bit. Në LCA 2012 Rusty Russell , se ka shumë arsye më delikate që mund të shpjegojnë rritjen e konsumit të kujtesës. Duke thënë këtë, ne tani jetojmë në një kohë ku kemi gigabajt memorie, kështu që do t'ia dalim disi.
Megjithatë, nuk mund të mos mendoj se shpërndarja e më shumë memorie për diçka kaq thelbësore si terminali është humbje e burimeve. Këto programe duhet të jenë më të vegjlit nga më të vegjlit, duhet të jenë në gjendje të funksionojnë në çdo "kuti", qoftë edhe një kuti këpucësh, nëse ndonjëherë arrijmë në pikën ku duhet të pajisen me sisteme Linux (dhe ju e dini që do të jetë kështu ) . Por me këto shifra, përdorimi i kujtesës do të bëhet një problem në të ardhmen në çdo mjedis që përdor terminale të shumëfishta, përveç disa prej më të lehtave dhe më të kufizuara në aftësi. Për të kompensuar këtë, GNOME Terminal, Konsole, urxvt, Terminator dhe Xfce Terminal kanë një modalitet Daemon që ju lejon të kontrolloni terminale të shumta përmes një procesi të vetëm, duke kufizuar konsumin e tyre të kujtesës.
Gjatë testeve të mia, arrita në një rezultat tjetër të papritur në lidhje me shkrim-leximin e diskut: prisja të mos shihja asgjë këtu, por doli që disa terminale shkruajnë të dhënat më voluminoze në disk. Pra, biblioteka VTE në fakt mban një tampon rrotullimi në disk (kjo veçori , dhe kjo ende po ndodh). Por ndryshe nga implementimet e vjetra, tani të paktën këto të dhëna janë të koduara duke përdorur AES256 GCM (). Por lind një pyetje e arsyeshme: çfarë është kaq e veçantë për bibliotekën VTE që kërkon një qasje kaq jo standarde për zbatimin...
Përfundim
Në pjesën e parë të artikullit, ne zbuluam se terminalet e bazuara në VTE kanë një grup të mirë karakteristikash, por tani shohim se kjo vjen me disa kosto të performancës. Tani memoria nuk është problem sepse të gjitha terminalet VTE mund të kontrollohen përmes një procesi Daemon, i cili kufizon oreksin e tyre. Sidoqoftë, sistemet e vjetra që kanë kufizime fizike në sasinë e RAM-it dhe buferëve të kernelit mund të kenë nevojë ende për versionet e mëparshme të terminaleve, pasi ato konsumojnë dukshëm më pak burime. Megjithëse terminalet VTE performuan mirë në testet e xhiros (lëvizjes), vonesa e tyre e shfaqjes është mbi pragun e vendosur në Udhëzuesin e Përdoruesit GNOME. Zhvilluesit e VTE ndoshta duhet ta marrin parasysh këtë. Nëse marrim parasysh se edhe për përdoruesit fillestarë të Linux, takimi me një terminal është i pashmangshëm, ata mund ta bëjnë atë më miqësor për përdoruesit. Për personat me përvojë, kalimi nga terminali i paracaktuar mund të nënkuptojë edhe më pak tendosje të syve dhe aftësi për të shmangur lëndimet dhe sëmundjet e ardhshme të lidhura me punën për shkak të seancave të gjata të punës. Fatkeqësisht, vetëm xterm dhe mlterm i vjetër na sjellin në pragun magjik të ping-ut prej 10 milisekonda, gjë që është e papranueshme për shumë njerëz.
Matjet e standardeve treguan gjithashtu se për shkak të zhvillimit të mjediseve grafike Linux, zhvilluesit duhej të bënin një sërë kompromisesh. Disa përdorues mund të dëshirojnë të shikojnë menaxherët e rregullt të dritareve pasi ato ofrojnë reduktim të ndjeshëm të ping. Fatkeqësisht, nuk ishte e mundur të matej vonesa për Wayland: programi Typometer që përdora u krijua për atë që Wayland është krijuar për të parandaluar: spiunimin e dritareve të tjera. Shpresoj që kompozimi i Wayland të performojë më mirë se X.org, dhe gjithashtu shpresoj që në të ardhmen dikush të gjejë një mënyrë për të matur vonesën në këtë mjedis.
Burimi: www.habr.com