Një fjalë nga zyreton tonë të përkthimit: zakonisht të gjithë përpiqen të përkthejnë materialet më të freskëta dhe botimet, dhe ne nuk jemi përjashtim. Por terminalet nuk janë diçka që përditësohet çdo javë. Prandaj, përktheu për ju artikullin e Antoine Beaupré, publikuar pranverën e vitit 2018: pavarësisht nga mosha e konsiderueshme për standardet moderne, ne mendojmë se materiali nuk ka humbur aktualitetin. Për më tepër, në origjinë është një seri dy artikujsh, por ne vendosëm t'i bashkojmë ato në një postim të madh.
Terminalet zënë një vend të veçantë në historinë e kompjuterëve, por në dekadat e fundit ato janë "detyruar" të mbijetojnë së bashku me linjën e komandës në sfondin e përhapjes së gjerë të ndërfaqeve grafike. zëvendësuan homologët e tyre , të cilët, nga ana e tyre, ishin një modifikim i sistemeve me karta perforuese dhe ndërprerës. Distribucione moderne vijnë me një sërë të madhe emulatorësh terminali në të gjitha format dhe ngjyrat. Dhe ndërsa shumë janë të kënaqur me terminalin standard që u ofrohet nga mjedisi i tyre i punës, disa me krenari përdorin softuer të hapur qartë ekzotik për të nisur shell-in ose editorin e tyre të preferuar. Por, siç do të shohim nga ky artikull, jo të gjithë terminalet janë krijuar sipas një modeli: ato ndryshojnë ndjeshëm në funksionalitet, përmasë dhe performancë.
Disa terminale kanë vërtet vrima të jashtëzakonshme në siguri, plus, shumica kanë një grup krejtësisht të ndryshëm funksionesh, nga mbështetja e ndërfaqes me tabu deri te skriptet. Megjithatë ne , ky artikull është një përditësim i materialit të mëparshëm, që do të ndihmojë lexuesit të përcaktojnë se cili terminal të përdorin në vitin 2018. Në gjysmën e parë të artikullit, funksionet krahasohen, ndërsa në të dytën vlerësohet performanca.
Ja terminalet që shqyrtova:
Ndoshta këto nuk janë versionet më të reja, pasi kam qenë i kufizuar në ndërtimet stabile në momentin që kam shkruar materialin, të cilat kam arritur t'i instaloja në Debian 9 ose Fedora 27. Përjashtimi i vetëm është Alacritty. Ai është pasardhës i terminaleve me GPU të akceleruar dhe është shkruar në një gjuhë të pazakontë dhe të re për këtë detyrë — Rust. Kam përjashtuar terminalet e uebit (përfshirë dhe në ), sepse testet paraprake treguan performancën e tyre jashtëzakonisht të ulët.
Mbështetje Unicode
Testet e mia filluan me mbështetje për Unicode. Testi i parë i terminaleve ishte shfaqja e një vargu të tillë të 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 tij të paracaktuar:
Në parazgjedhje, xterm përdor shkrimin klasik «të fiksuar», i cili, sipas , ka «mbulim të konsiderueshëm të Unicode që nga viti 1997». Në këtë shkrim ndodh diçka që bën që simboli të shfaqet si një kornizë boshe dhe vetëm kur rrisim madhësinë e shkrimit në 20+ pikë, simboli fillon të shfaqet siç duhet. Megjithatë, ky «fix» prish shfaqjen e simboleve të tjera të Unicode:
Këto screenshot janë marrë në Fedora 27, pasi ajo ofronte rezultatet më të mira, krahasuar me Debian 9, ku disa versionet më të vjetra të terminaleve (në veçanti — mlterm) nuk mund të funksiononin siç duhej me shkrimet. Fatmirësisht, kjo u rregullua në versionet e mëvonshme.
Tani vini re shfaqjen e vargut në xterm. Çuditërisht, simboli Mem dhe i pasuar nga Semitic janë të lidhura me skenarët e shkruajtjes RTL (), prandaj teknikisht duhet të shfaqen nga dritarja në të djathtë. Shfletuesit e uebit, si Firefox 57, e trajtojnë siç duhet vargun e mësipërm. Një variant më i thjeshtë i tekstit RTL është fjala "" në hebraisht (). thotë të mëposhtme:
«Shumë programe kompjuterike nuk mund të shfaqin siç duhet tekstin bidireksional. Për shembull, emri hebraik “Sara” përbëhet nga simbolet sin (ש) (i cili shfaqet nga e djathta), pastaj resh (ר) dhe, përfundimisht, he (ה) (i cili duhet të shfaqet nga e majta)».
Shumë terminale nuk përfundojnë këtë test: Alacritty, terminalet e bazuara në VTE të Gnome dhe XFCE, urxvt, st dhe xterm e shfaqin "Sara" në rend të kundërt, siç do ta shkruanim këtë emër si "Aras".
Një tjetër problem me tekstet dykahëshe është se ato duhet siç do të duhet të janë të rreshtuar, veçanërisht kur bëhet fjalë për përzierjen e teksteve RTL dhe LTR. Skema RTL duhet të fillojë nga ana e djathtë e dritares së terminalit, por çfarë duhet të ndodhë për terminalet që funksionojnë nga default me anglishte LTR? Shumica e tyre nuk kanë ndonjë mekanizëm të veçantë dhe rreshtojnë të gjithë tekstin në anën e majtë (në të gjitha, edhe në Konsole). Përjashtim bëjnë pterm dhe mlterm, të cilat i përmbahen standardeve dhe rreshtojnë këto rreshta në anën e djathtë.
Mbrojtja nga ngjitja
Karakteristika e ardhshme thelbësore, që unë e kam përcaktuar për vete, është mbrojtja nga ngjitja. Ndërsa dihet gjerësisht se shprehjet si:
$ curl http://example.com/ | shjanë komanda të ekzekutimit të kodit push, shumë pak e dinë që komandat e fshehta mund të depërtojnë në konsolën duke kopjuar-ngjitur nga shfletuesi i internetit, edhe pas një kontrolli të kujdesshëm. tregon shkëlqyeshëm se si një komandë që duket e padëmshme:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitkthehet kur ngjitet nga faqja e Horne 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 kopi kod nga faqet që nuk i 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 keqdashës është nxjerrë në bllok , i cili është i zhvendosur nga fusha e shikimit të përdoruesit me mjete CSS.
është qartë i destinuar për të neutralizuar këto sulme. Në këtë mod, terminalet e vendosin tekstin e ngjitur në një palë sekvencash të veçanta të escape, për të njoftuar shell-in për origjinën e këtij teksti. Kështu shell-i merr një sinjal se mund të injorojë simbolet speciale që mund të përmbajë teksti i ngjitur. Të gjithë terminalet, deri në xterm të nderuar, mbështesin këtë funksion, por ngjitja në modin Bracketed kërkon mbështetje nga shell-i ose aplikacioni i ekzekutuar në terminal. Për shembull, softueri që përdor (i njëjti Bash), kërkon një skedë ~ /.inputrc:
set enable-bracketed-paste onFatkeq, një test-website i Hornës gjithashtu tregon se si të anashkalosh këtë mbrojtje përmes formatimit të tekstit dhe të përfundosh parakohësisht aplikimin e modalitetit Bracketed. Kjo funksionon sepse disa terminale filtrojnë gabimisht sekuencat e escape përpara se të shtojnë të tyret. Për shembull, në të mijat nuk kam mundur të përfundoj me sukses testet e Konsole, edhe duke marrë parasysh konfiguarimin e saktë. .inputrc file. Kjo do të thotë se mund të përballesh lehtësisht me dëmtime të konfigurimit të sistemit për shkak të një aplikacioni të papërshtatshëm ose një shell të keqkonfiguruar. Kjo është veçanërisht e rrezikshme kur hyn në serverë të largët, ku përpunimi i kujdesshëm i konfigurimit ndodhet më rrallë, aq më shumë nëse ke shumë nga këto makina të largëta.
Një zgjidhje e mirë për këtë problem është mjeti 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ë radhë të reja. Nuk kam gjetur një version më të sigurt për sulmin tekstual të përshkruar nga Horna.
Tab-at dhe profilet
Një funksion i popullarizuar tani është mbështetja e ndërfaqes me tab-e, të cilin do ta definonim si një dritare terminali që përmban disa terminale të tjera. Funksioni ndryshon për terminale të ndryshme, dhe ndonëse terminalet tradicionale si xterm nuk e mbështesin fare tab-et, inkarnacionet më moderne të terminalit si Xfce Terminal, GNOME Terminal dhe Konsole e kanë këtë funksion. Gjithashtu, mbështetje për tab-et ka edhe Urxvt, por vetëm nëse përdoret një plugin. Megjithatë, me sa i përket mbështetjes për tab-et si të tilla, lideri i padiskutueshëm është Terminator: ai mbështet jo vetëm tab-et, por gjithashtu mund të vendosë terminalet në rend të rastësishëm (shih skicën më poshtë).
Një tjetër veçori e Terminator është mundësia për "të gruposh" këto tab-e bashkë dhe të dërgosh të njëjtat shtypje çelësish në disa terminale njëkohësisht, e cila ofron një mjet të thjeshtë për të kryer operacione masive në disa servera njëkohësisht. Një funksion i ngjashëm është gjithashtu i realizuar në Konsole. Për të përdorur këtë funksion në terminale të tjera, duhet të përdorësh software të jashtëm, si , ose .
Veçanërisht, skedaret funksionojnë mirë në kombinim me profilin: për shembull, mund të keni një skedë për emailin, një tjetër për bisedën dhe kështu me radhë. Kjo mbështetet mirë nga terminali Konsole dhe GNOME Terminal. Të dy lejojnë që secila skedë të nisë automatikisht profilin e saj. Terminator gjithashtu mbështet profile, por nuk arrita të gjej një mënyrë për të nisur automatikisht programe të caktuara kur hap një skedë specifike. Terminalet e tjera në përgjithësi nuk kanë nocionin e "profilit".
Frutat e vogla
E fundit që do të shqyrtoj 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 së fundmi hoqën mbështetje për imazhet e sfondit, gjë që detyroi disa përdorues të kalojnë në terminalin . Personalish, unë jam i kënaqur me të thjesht Xresources, i cili vendos një grup bazik ngjyrash sfondi për urxvt. Megjithatë, temat e ngjyrave jo standarde mund të krijojnë probleme. Për shembull, me aplikacionet dhe , pasi ata tashmë përdorin ngjyrat e tyre.
nuk mbështeste ngjyrat, ndërsa të rinjtë shpesh ishin të kufizuar në një paletë ngjyrash 256. Për përdoruesit e avancuar, të cilët stilizojnë terminalet e tyre, kërkesat e shell-it ose të rreshtit të gjendjes në disa mënyra të ndërlikuara, mund të paraqesin një kufizim të pakëndshëm. ndjek se cilët terminale kanë mbështetje "True Color". Testet e mia konfirmojnë se st, Alacritty dhe terminalet e bazuara në VTE mbështesin shkëlqyeshëm True Color. Terminalet e tjera në këtë pikë ndihen jo shumë mirë 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 përballojnë këtë detyrë mjaft mirë me paletën e tyre 256-ngjyrëshe, dhe urxvt, që jo vetëm nuk ia del provimit, por madje tregon disa simbole që trembërisht në vend të tyre.
Disa terminale gjithashtu analizojnë tekstin për t'u siguruar që të kenë shabllone URL-sh, për t'i bërë lidhjet klikueshme. Kjo i përket të gjitha terminaleve të derivuar nga VTE, ndërsa urxvt kërkon një modul të posaçëm që të transformojë adresat URL me klikim ose me një kombinim të çelësave. Terminalet e tjera që kam testuar shfaqin adresat URL në mënyra të tjera.
Finalmente, trendi i ri i terminaleve është opsionaliteti i rrotullimit. Për shembull, në st nuk ka rrotullim; supozohet se përdoruesi do të përdorë një multiplexer terminali si tmux dhe .
Në Alacritty gjithashtu mungojnë tamponët e rrotullimit të prapshëm, por mbështetje për të për shkak të "feedback-ut të gjerë" që ka ardhur nga përdoruesit për këtë temë. Përveç këtyre daljesh, çdo terminal i verifikuar që kam gjetur mbështet rrotullimin prapa.
Të përmbledhura
Në pjesën e dytë të materialit (në origjinal ishte dy artikuj të ndara, — shënim i redaktorit.) do të krahasojmë performancën, përdorimin e memories dhe vonesat. Por tashmë shohim se disa nga terminalet në shqyrtim kanë disavantazhe të rëndësishme. Për shembull, përdoruesit që punojnë rregullisht me skriptet RTL mund të kenë parasysh mlterm dhe pterm, pasi ato i përballojnë këto detyra më mirë se të tjerët. Konsole gjithashtu ka performuar mirë. Përdoruesit që nuk punojnë me skriptet RTL mund të zgjedhin diçka tjetër.
Sa i përket mbrojtjes nga futja e kodit të dëmshëm, urxvt dallohet për shkak të implementimit të veçantë të mbrojtjes nga këtë lloj sulmi, që më duket me të vërtetë e dobishme. Ata që kërkojnë disa karakteristika shtesë duhet të shikojnë në Konsole. Në fund, duhet të theksohet se VTE është një bazë e shkëlqyer për terminalet, që garanton mbështetje për ngjyrat, njohjen e URL-ve dhe kështu me radhë. Në pamje të parë, terminali default që vjen me mjedisin tuaj të preferuar mund të plotësojë të gjitha kërkesat, por ta lëmë këtë pyetje të hapur derisa të shqyrtojmë performancën.
Vazhdoni bisedën
Në përgjithësi, performanca e terminaleve mund të duket si një problem i kushtezuar, megjithatë, siç u vërtetua, disa prej tyre tregojnë vonesa befasuese për një software kaq themelor. Gjithashtu më poshtë do të shqyrtojmë atë që zakonisht quhet "shpejtësi" (në të vërtetë, kjo është shpejtësia e rrotullimit) dhe konsumimin e memories nga terminali (duke marrë parasysh se sot kjo nuk është aq kritike sa ishte 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ë aspekt mund të funksionojnë më ngadalë se redaktorët më të shpejtë të teksteve. Ky sugjerim më çoi në fund të fundit në zhvillimin e testeve të mia dhe në shk writingimin e këtij artikulli.
Por çfarë është vonesa, dhe pse është kaq e rëndësishme? Në artikullin e tij, Fatin e përcaktoi atë si «vonësën midis shtypjes së butonit dhe përditësimit përkatës në ekran» dhe citoi , në të cilin thuhet: «Vonesa në reagimin vizual në ekranin e kompjuterit ka një ndikim të rëndësishëm në sjelljen e operatorëve dhe kënaqësinë e tyre».
Fatin shpjegon se kjo ping ka pasoja më të thella, më shumë se thjesht kënaqësinë: «shkrimi bëhet më i ngadaltë, ndodhin më shumë gabime, rritet tensioni i syve dhe muskujve». Me fjalë të tjera, një vonesë e madhe mund të çojë në gabime, si dhe në një cilësi më të ulët të kodit, pasi krijon një ngarkesë të qenësishme kognitive për trurin. Por ç'është edhe më keq, ping-u «rrit tensionin e syve dhe muskujve», që duket se nënkupton në të ardhmen (duket se autori nënkupton probleme me muskujt e syve, shpinë, duar dhe, natyrisht, shikimin, — shën. për.) për shkak të tensionit të përsëritur.
Disa nga këto efekte janë të njohura prej kohësh, dhe rezultatet , të publikuara që në 1976 në revistën Ergonomics, tregojnë se një vonesë prej 100 milisekondash «të dëmton rëndë shpejtësinë e shkruarjes». Së fundmi, në udhëzimin përdorues të GNOME është përfshirë në 10 milisekonda, e nëse vazhdojmë më tej, tregon se ideali është 1 milisekondë.
Fatin zhvilloi testet e tij në redaktorët e teksteve; ai krijoi një instrument portativ të quajtur , i cili e përdora për të kontrolluar pingun në emulatorët e terminaleve. Kini parasysh se testi u zhvillua në modin simulues: në të vërtetë duhet të marrim parasysh edhe vonesën e hyrjes (tastiera, kontrolluesi USB dhe kështu me radhë) dhe asaj të daljes (buferri i kartës grafike, monitori). Sipas Fatinit, në konfigurimet tipike ajo përbën rreth 20 ms. Me pajisje lojrash, mund të arrijmë një rezultat prej vetëm 3 milisekondash. Tani që kemi pajisje kaq të shpejta, aplikacioni nuk duhet të sjellë edhe vonesën e vet. Qëllimi i Fatinit është ta ulë vonesën e aplikacionit në 1 milisekondë, ose të arrijë një set pa , si në .
Ja rezultatet e matjeve të mia, si dhe disa rezultate të Fatinit për të treguar se eksperimentet e mia janë në përputhje me testet e tij:
E para që më befasoi ishte koha më e mirë e reagimit te programet e vjetra, si xterm dhe mlterm. Në prani të një vonese më të keqe regjistrimi (2.4 ms), ata treguan një rezultat më të 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 i përmbush kërkesat për "terminalin më të shpejtë të ekzistueshëm", megjithëse rezultatet e tij janë përmirësuar që nga verifikimi i parë në vitin 2017. Në të vërtetë, autorët e projektit dhe po punojnë për përmirësimin e shfaqjes. Është gjithashtu e nevojshme të theksohet se Vim, i cili përdor GTK3, është dukshëm më i ngadaltë se ekuivalenti i tij GTK2. Kjo mund të përfundojë në përfundimin se GTK3 krijon një vonesë shtesë, dhe kjo reflektohet në të gjithë terminalet e tjera që e përdorin atë (Terminator, Xfce4 Terminal dhe GNOME Terminal).
Megjithatë, për syrin dallimet mund të mos jenë të dukshme. Siç shpjegon Fatini: "nuk është e domosdoshme të kuptosh se ekziston një vonesë, që ajo të ketë një efekt mbi ty". Fatini gjithashtu paralajmëron për devijimin standard: "çdo shkelje në kohëzgjatjen e vonesës (dridhjet) krijon një ngarkesë shtesë për shkak të paparashikueshmërisë së saj".
Grafiku i mësipërm është marrë nga një Debian 9 (stretch) të pastër me . Ky kjo ndihmon në arritjen e rezultateve më të mira në provat e ndalimit. Siç doli, GNOME krijon një ping shtesë prej 20 ms për të gjitha matjet. Një shpjegim i mundshëm për këtë është përfshirja e programeve me përpunim sinkron të ngjarjeve hyrëse. Fatini jep për këtë rast si shembull , i cili shton vonesë duke përpunuar të gjitha ngjarjet hyrëse në sinkron. Në mënyrë të paracaktuar, GNOME gjithashtu ka menaxherin e dritareve , e cila krijon një nivel shtesë të tamponimit, e cila ndikon në ping dhe shton të paktën 8 milisekonda vonesë.
Shpejtësia e rrotullimit
Testi i ardhshëm është kontrolli tradicional i "shpejtësisë" ose "kapaciteteve të kalimit", i cili mat se sa shpejt terminali mund të rrotullojë faqen duke treguar një sasi të madhe teksti në ekran. Mekanika e testit ndryshon; testi origjinal përfshinte thjesht gjenerimin e të njëjtit string teksti me komandën seq. Teste të tjera përfshijnë verifikimin e Thomas E. Dick (shoqëruese e xterm), në kuadër të cilit shpesh . Në një shqyrtim tjetër të performancës së terminaleve përdor një varg bajtësh të rastësishëm në kodimin base32, i cili printohet në terminal me anë të cat. Luu e konsideron këtë test "aq të padobishëm si çdo standard që mund të jetë imagjinuar" dhe sugjeron që në vend të tij të përdoret përgjigjja e terminalit si tregues kryesor. Dick gjithashtu e quan testin e tij të gabuar. Megjithatë, të dy autorët pranojnë se kapaciteti i kalimit të dritares së terminalit mund të jetë një problem. Luu zbuloj bllokimin e Emacs Eshell kur shfaqte skedare të mëdha, dhe Dick optimizoi terminalin për të eliminuar ngadalësinë vizuale të xterm. Prandaj, në këtë test ka ende ndonjë arsyetim, por pasi processi i renderimit ndryshon shumë nga terminali në terminal, ai mund të përdoret gjithashtu si një komponent testues për të verifikuar parametrat e tjerë.
Këtu shohim se rxvt dhe st dalin përpara përballë konkurrentëve, ndërsa pas tyre vjen Alacritty, i zhvilluar duke u përqëndruar në shpejtësi. Më pas janë Xfce (familja VTE) dhe Konsole, të cilat punojnë pothuajse dyfish më shpejt. I fundit është xterm me një tregues pesë herë më të ngadaltë se rxvt. Gjatë testit, xterm gjithashtu kishte shumë ndriçim, duke e bërë tekstin e kalimshëm të vështirë për t’u parë, edhe nëse kjo ishte e njëjta rresht. Konsole rezultoi të ishte i shpejtë, por ndonjëherë ai 'këndonte': ekrani ndonjëherë ngec, duke treguar tekstin pjesërisht ose duke mos e shfaqur atë fare. Terminalet e tjera shfaqnin rreshta qartë, duke përfshirë st, Alacritty dhe rxvt.
Diki shpjegon se ndryshimet në performancë lidhen me dizajnin e buffers të skrollimit në terminalet e ndryshme. Në veçanti, ai i akuzon rxvt dhe terminalet e tjera se 'nuk ndjekin rregullat e përgjithshme':
«Në ndryshim nga xterm, rxvt nuk përpiqej të shfaqë të gjitha përditësimet. Nëse ai ngec, ai heq dorë nga disa përditësime për të përzbuluar. Kjo ka pasur një ndikim më të madh në shpejtësinë e dukshme të skrollimit sesa në organizimin e memories së brendshme. Një disavantazh ishte se animacioni ASCII ishte disi i pasaktë».
Për të korrigjuar këtë dukje të ngadalshme të xterm, Diki propozon përdorimin e burimit , i cili lejon xterm të heqë disa përditësime të ekranit për të mos ngecur pas rrjedhës. Testet e mia konfirmojnë se fastScroll rrit performancën dhe e çon xterm në të njëjtën nivel me rxvt. Megjithatë, kjo është një rregullim mjaft i ashpër, siç e shpjegon vetë Diki: «ndonjëherë xterm — ashtu si dhe konsole — duket se ndalon, pasi ai pret një grup të ri përditësimesh të ekranit pasi disa prej tyre janë hequr». Në këtë çështje, duket se terminalet e tjera kanë gjetur një kompromis të mirë mes shpejtësisë dhe integritetit të ekranit.
Konsumimi i resurseve
Pavarësisht nga përshtatshmëria për të marrë në konsideratë shpejtësinë e skrollimit si një tregues të performancës, ky test mundëson simtimin e ngarkesës në terminalet, që nga ana tjetër na lejon të masim parametra të tjerë, si përdorimi i memories ose diskut. Metrikat u morën duke ekzekutuar testin e specifikuar seq nën monitorimin e procesit Python. Ai mbledh të dhënat e numëruesve për ru_maxrss, shumën ru_oublock dhe ru_inblock dhe një orar të thjeshtë të kohës.
Në këtë test, ST zë vendin e parë me konsumimin më të ulët të memories, 8 MB, që nuk është befasi duke marrë parasysh se qëllimi kryesor i projektit është thjeshtësia. Pak më shumë konsumojnë mlterm, xterm dhe rxvt — rreth 12 MB. Një rezultat tjetër i dukshëm është Alacritty, e cila kërkon 30 MB për të funksionuar. Më pas vijnë terminalet e familjes VTE me treguesit nga 40 në 60 MB, që është mjaft shumë. Ky konsum mund të shpjegohet me faktin se këto terminale përdorin biblioteka më të avancuara, si GTK. Konsole mbyll listën me një konsum kolosal prej 65 MB memorie gjatë testeve, megjithatë, kjo mund të justifikohet me gamën e gjerë të funksioneve të tij.
Në krahasim me rezultatet e mëparshme, të marra dhjetë vjet më parë, të gjitha programet kanë filluar të konsumojnë dukshëm më shumë memorie. Më parë Xterm kërkonte 4 MB, ndërsa tani kërkon 15 MB vetëm për të nisur. Një rritje e ngjashme e konsumit ndodh edhe me rxvt, i cili tani kërkon 16 MB nga kuti. 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ë arkitekturë 32-bit. Në LCA 2012, Rasti Russel. , që ekzistojnë shumë arsye më të thella, të cilat mund të shpjegojnë rritjen e konsumit të memory. Me gjithë këto, ne tani jetojmë në kohë kur kemi tërë gigabait memories, kështu që do ta kalojmë nga ndonjëherë.
Megjithatë, nuk mund të më largohet ndjenja se caktimi i më shumë memories për një softuer kaq themelor si terminali, është humbje e burimeve. Këto programe duhet të jenë më të voglat nga më të vegjlit, duhet të jenë në gjendje të funksionojnë në çdo "kutisë", madje edhe në atë të këpucëve, nëse ndonjëherë do të arrijmë që t'i pajisim me sisteme Linux (dhe ju e dini se kështu do të jetë). Por me këto shifra, përdorimi i memory do të bëhet një problem në të ardhmen në çdo mjedis kur hapen disa terminale, përveç situatave me disa nga më të lehtët dhe me kapacitete të kufizuara. Për ta kompensuar këtë, GNOME Terminal, Konsole, urxvt, Terminator dhe Xfce Terminal kanë një mod të Demon-it, i cili lejon menaxhimin e disa terminaleve nëpërmjet një procesi të vetëm, duke kufizuar konsumimin e tyre të memories.
Gjatë testeve të mia kam arritur në një rezultat tjetër të papritur në lidhje me leximin dhe shkrimin në disk: prisja të mos shihja asgjë këtu, por doli se disa terminale regjistrojnë të dhëna më të mëdha në disk. Pra, biblioteka VTE në fakt mban në disk një bufër skrollimi (kjo karakteristikë , dhe kjo ndodh ende). Por ndryshe nga realizimet e vjetrat, tani, së paku, këto të dhëna janë të koduara me AES256 GCM (). Por lind një pyetje e arsyeshme, çfarë është kaq e veçantë në bibliotekën VTE, saqë kërkon një qasje kaq jo standarte në implementim…
Përfundim
Në pjesën e parë të artikullit, ne zbuluam se terminalet e bazuara në VTE kanë një grup të mirë funksionesh, por tani ne shohim se kjo lidhet me disa shpenzime për sigurimin e performancës së tyre. Tani memoria nuk është një problem, sepse të gjithë terminalet VTE mund të menaxhohen përmes një procesi Daemon, i cili kufizon apetitin e tyre. Megjithatë, sistemet e vjetra, që kanë kufizime fizike për sa i përket sasisë së memories operative dhe bufës së bërthamës, mund të kenë ende nevojë për versione më të hershme të terminaleve, sepse ato konsumojnë ndjeshëm më pak burime. Megjithatë, terminalet VTE kanë treguar performancë të mirë në testet e kapacitetit (skrollimi), por vonesa e shfaqjes së të dhënave në ekran është mbi pragun e vendosur në udhëzuesin e përdoruesit GNOME. Ka të ngjarë që zhvilluesit e VTE duhet ta kenë parasysh këtë. Nëse merret parasysh se edhe për përdoruesit fillestarë të Linux-it, përballja me terminalin është e pashmangshme, ata mund ta bëjnë atë më miqësor për përdoruesit. Për geek-at e avancuar, kalimi nga terminali i paracaktuar mund të nënkuptojë edhe një ulje të ngarkesës në sy dhe mundësinë për të shmangur dëmtimet dhe sëmundjet profesionale në të ardhmen për shkak të sesioneve të gjata të punës. Fatkeqësisht, vetëm xterm dhe mlterm të vjetra na çojnë te pragu magjik i ping-ut prej 10 milisekondash, që për shumë është e papranueshme.
Masa e kontrollit gjithashtu tregoi se zhvillimi i mjediseve grafike të Linux-it ka detyruar zhvilluesit të bëjnë disa kompromise. Disa përdorues duhet të shikojnë menaxherët e zakonshëm të dritareve, pasi ata ofrojnë një ulje të dukshme të pingut. Fatkeqësisht, për Wayland nuk arrita të mat vonesën: programi Typometer, që përdorja, ishte krijuar për atë që Wayland është projektuar të parandalojë — spiunimin e dritareve të tjera. Shpresoj që kompozimi i Wayland të jetë më i efektshëm se ai i 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ë mjedis.
Burimi: habr.com
