Vārds no mūsu tulkošanas biroja: parasti visi cenšas tulkot jaunākos materiālus un publikācijas, un mēs neesam izņēmums. Taču termināļi nav tie, kas tiek atjaunināti katru nedēļu. Tāpēc mēs esam tulkojuši jums Antonīna Bopre rakstu, kas publicēts 2018. gada pavasarī: neskatoties uz to, ka tam ir ievērojams 'vecums' mūsdienu izpratnē, mūsuprāt, materiāls nav zaudējis savu aktualitāti. Turklāt oriģināli tas ir divu rakstu sērija, taču mēs nolēmām apvienot tos vienā lielā ierakstā.
Termināļi ieņem īpašu vietu datoru vēsturē, taču pēdējo desmitgažu laikā tie ir bijuši ‘spiesti’ izdzīvot kopā ar komandrindas saskarnēm, kamēr visur izplatījās grafiskās saskarnes. aizvietoja savus , kuri, savukārt, bija modificētas sistēmas, kas balstījās uz perforētām kartēm un slēdžiem. Mūsdienu distribūcijas tiek piegādātas ar daudzveidīgiem termināļu emulatoriem visās formās un krāsās. Un, kamēr daudzi mierīgi apmierinās ar standarta termināli, ko piedāvā viņu darba vide, citi ar lepnumu izmanto acīmredzami eksotisko programmatūru, lai palaistu savu iecienīto apvalku vai teksta redaktoru. Taču, kā mēs redzēsim šajā rakstā, ne visi termināļi ir radīti pēc viena un tā paša parauga: to funkcionalitāte, izmērs un ražīgums ievērojami atšķiras.
Daži termināļi ir ar tiešām pārsteidzošām drošības nepilnībām, plus vairums no tiem piedāvā pilnīgi atšķirīgu funkciju kopumu - no cilņu saskarnes atbalsta līdz skriptiem. Lai gan mēs , šis raksts ir iepriekšējā materiāla atjauninājums, kas palīdzēs lasītājiem noteikt, kuru termināli izmantot 2018. gadā. Raksta pirmajā pusē tiek salīdzinātas funkcijas, bet otrajā - novērtēta veiktspēja.
Šeit ir termināļi, kurus es apskatīju:
Iespējams, šīs nav vissvaigākās versijas, jo es ierobežojos pie stabilajiem izlaidumiem brīdī, kad rakstīju materiālu, kurus man izdevās uzinstalēt Debian 9 vai Fedora 27. Vienīgais izņēmums ir Alacritty. Tas ir GPU paātrinātu terminālu pēctečs un ir uzrakstīts neparastā un jaunā šim uzdevumam valodā — Rust. Es izslēdzu no savas apskata tīmekļa terminālus (ieskaitot, un uz ), jo iepriekšējie testi parādīja to ārkārtīgi zemo veiktspēju.
Atbalsts Unicode
Savus testus es sāku ar Unicode atbalstu. Pirmais terminālu tests bija attēlot Unicode virkni no : «é, Δ, Й, ק, م, ๗, あ, 叶, 葉 un 말». Šis vienkāršais tests parāda, vai termināls var pareizi darboties visā pasaulē. Termināls xterm nerāda arābu simbolu pēc noklusējuma iestatījumiem:
Noklusējuma xterm izmanto klasisko «fiksēto» fontu, kura, saskaņā ar , ir «būtisks Unicode pārklājums kopš 1997. gada». Šajā fontā notiek kaut kas, kas liek simbolam tikt attēlotam kā tukša kaste, un tikai palielinot teksta fontu līdz 20+ punktiem simbols beidzot sāk pareizi attēloties. Tomēr šāds «fix» izjauc citu Unicode simbolu attēlošanu:
Šie ekrānuzņēmumi tika veikti Fedora 27, jo tieši tā sniedza labākos rezultātus nekā Debian 9, kur dažas vecākas terminālu versijas (proti — mlterm) nespēja pareizi darboties ar fontiem. Par laimi, tas tika labots jaunākajās versijās.
Tagad pievērsiet uzmanību virknes attēlojumam xterm. Izrādās, simbols Mem un tam sekojošais semitiskais attiecās uz RTL (), tāpēc tehniski tiem vajadzētu tikt attēlotiem no labās uz kreiso. Tīmekļa pārlūkprogrammas, piemēram, Firefox 57, pareizi apstrādā iepriekš minēto virkni. Vienkāršāks RTL teksta variants ir vārds «» ivritā (). teic sekojošo:
«Daudzas datorprogrammas nespēj pareizi attēlot divvirzienu tekstu. Piemēram, ebreju vārds «Sāra» sastāv no simboliem sin (ש) (kas parādās no labās puses), tad reš (ר) un, visbeidzot, he (ה) (kas būtu jāparādās no kreisās puses)».
Daudzi termināļi neiztur šo testu: Alacritty, Gnome un XFCE atvasinātie VTE termināļi, urxvt, st un xterm attēlo "Saru" pretējā secībā, it kā mēs šo vārdu būtu pierakstījuši kā "Aras".
Vēl viena problēma ar divvirzienu tekstiem ir tā, ka tie jāizlīdzina, īpaši, ja runa ir par RTL un LTR tekstu sajaukšanu. RTL scenārijiem jāuzsāk darbs no termināla loga labās puses, bet kas notiek ar termināļiem, kas noklusējumā strādā ar LTR angļu valodu? Lielākā daļa no tiem nepiemīt nekādiem īpašiem mehānismiem un izlīdzina visu tekstu pa kreisi (tajā skaitā arī Konsole). Izņēmums ir pterm un mlterm, kas ievēro standartus un tādas rindas izlīdzina pa labi.
Ievades aizsardzība
Nākamā kritiskā funkcija, ko es sev definēju, ir ievades aizsardzība. Lai gan ir plaši zināms, ka šādi rīkojumi:
$ curl http://example.com/ | shir koda izpildes virzītājkomandas, maz kas zina, ka slēptie komandas var iekļūt konsolē, kopējot un ielīmējot no tīmekļa pārlūka, pat pēc rūpīgas pārbaudes. izcili parāda, kā izskatās nevainīga komanda:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitievietojot to no Horna vietnes terminālī, pārvēršas šādā nepatikšanā:
git clone /dev/null;
clear;
echo -n "Sveiks ";
whoami|tr -d 'n';
echo -e '!nTas bija slikta ideja. Neņemiet kodu no vietnēm, kam neuzticaties!
Šeit ir jūsu pirmā rinda no jūsu /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitKā tas darbojas? Vīrusu kods ir izvirzīts blokā , kas ar CSS līdzekļiem ir pārvietots no lietotāja redzesloka.
ir īpaši paredzēts, lai neitralizētu šādus uzbrukumus. Šajā režīmā termināļi iekļauj ievietoto tekstu pāris īpašās escape secībās, lai informētu apvalku par šī teksta izcelsmi. Tādējādi apvalks saņem signālu, ka var ignorēt speciālos simbolus, kurus var saturēt ievietotais teksts. Visi termināļi, sākot no cienījamā xterm, atbalsta šo funkciju, taču ielīmēšana Bracketed režīmā prasa atbalstu no apvalka vai lietojumprogrammas, kas darbojas terminālī. Piemēram, programmatūra, kas izmanto (tā pati Bash), prasa failu ~/.inputrc:
set enable-bracketed-paste onDiemžēl Horne testa vietne arī parāda, kā apiet šo aizsardzību, izmantojot teksta formatēšanu un pirmslaicīgu Bracketed režīma piemērošanas pārtraukšanu. Tas darbojas, jo daži termināļi nepareizi filtrē izvairīšanās secības, pirms pievieno savas. Piemēram, manā gadījumā pat ar pareizu konfigurāciju man neizdevās sekmīgi pabeigt Konsole testus. .inputrc fails. Tas nozīmē, ka jūs varat viegli sabojāt sistēmas konfigurāciju, izmantojot neatbalstītu programmu vai nepareizi konfigurētu apvalku. Tas ir īpaši bīstami, piekļūstot attāliem serveriem, kur rūpīga konfigurācija sastopama retāk, jo īpaši, ja jums ir daudzi šādi attāli datori.
Laba šīs problēmas risināšanas metode ir termināļa ielīmēšanas apstiprinājuma papildinājums urxvt, kas vienkārši prasa atļauju ielīmēt jebkuru tekstu, kas satur jaunas rindas. Es neatradu drošāku variantu Horne aprakstītajai tekstuālajai uzbrukumam.
Vārdu cilnes un profili
Populāra tagad ir interfeisa cilņu atbalsts, ko mēs definēsim kā vienu termināļa logu, kas satur vairākus termināļus. Šī funkcija atšķiras dažādiem termināļiem, un, lai gan tradicionālie termināļi, piemēram, xterm, vispār neatbalsta cilnes, mūsdienu terminālu versijas, piemēram, Xfce Terminal, GNOME Terminal un Konsole, šo funkciju ir ieguvušas. Arī Urxvt atbalsta cilnes, taču tikai ar papildinājuma izmantošanu. Tomēr, runājot par cilņu atbalsta dabas uzticamu līderi, ir Terminator: tas ne tikai atbalsta cilnes, bet arī var novietot termināļus pēc saviem ieskatiem (skatiet attēlu zemāk).
Vēl viena Terminator funkcija ir iespēja „grupēt” šīs cilnes kopā un nosūtīt vienādas taustiņu nospiešanas uz vairākiem termināļiem vienlaikus, nodrošinot rupju rīku masveida operāciju veidošanai vairāku serveru vidū. Līdzīga funkcija ir pieejama arī Konsole. Lai izmantotu šo funkciju citos termināļos, ir jāizmanto trešo pušu programmatūra, piemēram, , vai .
Īpaši labi cilnes darbojas kopā ar profiliem: piemēram, jums var būt viena cilne e-pastam, otra tērzēšanai un tā tālāk. To labi atbalsta termināls Konsole un GNOME Terminal. Abi ļauj katrai cilnei automātiski palaist savu profilu. Terminator arī atbalsta profilus, bet es nevarēju atrast veidu, kā automātiski palaist noteiktas programmas, atverot konkrētu cilni. Citas termināļi vispār nezina, kas ir 'risinājums'.
Rūšiņas
Pēdējais, ko es apskatīšu šīs raksta pirmās daļas noslēgumā, ir termināļu izskats. Piemēram, GNOME, Xfce un urxvt atbalsta caurejas efektu, taču nesen pārtrauca atbalstu fona attēliem, kas lika dažiem lietotājiem pāriet uz citu terminālu. . Personīgi man tas ir pietiekami vienkārši. Xresources, kas nosaka pamata fona krāsu komplektu urxvt. Tomēr nestandarta krāsu tēmas var radīt arī problēmas. Piemēram, ar lietotnēm un , jo tās jau izmanto savas krāsas.
neatbalstīja krāsu, bet jaunie bieži vien bija ierobežoti ar 256 krāsu paleti. Lai pieredzējušiem lietotājiem, kuri stilizē savus terminālus, komandu pieprasījumi vai statusa rindas sarežģītos veidos var kļūt par nepatīkamu ierobežojumu. seko līdzi, kuri termināļi atbalsta 'True Color'. Mani testi apstiprina, ka st, Alacritty un VTE bāzētie termināļi lieliski atbalsta True Color. Citi termināļi šajā ziņā nav tik labi un faktiski pat nerāda 256 krāsas. Zemāk varat redzēt atšķirību starp True Color atbalstu GNOME, st un xterm termināļu vidū, kas labi tiek galā ar šo uzdevumu, izmantojot savu 256 krāsu paleti, un urxvt, kas ne tikai neiztur testu, bet pat rāda dažus mirgojošus simbolus to vietā.
Daži termināļi arī analizē tekstu, lai noteiktu URL veidus, padarot saites klikšķināmas. Tas attiecas uz visiem VTE atvasinātajiem termināliem, kamēr urxvt prasa īpašu spraudni, kas pārvērš URL adreses klikšķināšanas vai taustiņu kombinācijas palīdzību. Citiem termināļiem, ko esmu testējis, URL adreses tiek attēlotas citos veidos.
Visbeidzot, jauns termināļu trends ir opcionalitāte ritināšanas buferiem. Piemēram, st nav ritināšanas bufera; tiek pieņemts, ka lietotājs izmantos termināla multiplexer, piemēram, tmux un .
Alacritty arī nesniedz atpakaļ ritināšanas buferus, bet tās atbalsts dēļ "plašā atsauksmju apjoma" par šo tēmu no lietotājiem. Izņemot šos izņēmumus, katrs pārbaudītais terminālis, ko esmu atradis, atbalsta atpakaļ ritināšanu.
Vidēji rezultāti
Otrajā raksta daļā (oriģinālā tas bija divas atsevišķas rakstu daļas, — red. piez.) mēs salīdzināsim veiktspēju, atmiņas patēriņu un aizturi. Bet jau tagad redzam, ka daži no aplūkotajiem termināļiem ir ar nopietnām trūkumām. Piemēram, lietotāji, kuri regulāri strādā ar RTL skriptiem, var pievērst uzmanību mlterm un pterm, jo tie labāk risina šādas problēmas. Konsole arī uzrādījusi labu sniegumu. Lietotāji, kuri nestrādā ar RTL skriptiem, var izvēlēties kaut ko citu.
No drošības viedokļa urxvt izceļas ar savu unikālo aizsardzību pret ļaunprātīgu kodu, kas man šķiet noteikti izdevīga. Tie, kas meklē kādu uzlabojumu, var apskatīt Konsole. Beigās jāatzīmē, ka VTE ir lieliska bāze termināļiem, kas garantē krāsu atbalstu, URL atpazīšanu un tā tālāk. Pirmajā acumirklī noklusējuma termināls, kas piegādāts ar jūsu mīļāko vidi, var apmierināt visas prasības, bet atstāsim šo jautājumu atklātu, kamēr nenodarbosimies ar veiktspēju.
Turpinām sarunu
Pati termināļu veiktspēja var šķist izdomāta problēma, tomēr, kā izrādījās, daži no tiem demonstrē pārsteidzoši lielu aizturi šāda fundamentāla tipa programmatūrai. Turpinājumā mēs aplūkosim to, ko tradicionāli sauc par "ātrumu" (patiesībā, tas ir ritināšanas ātrums) un termināla atmiņas patēriņu (ņemot vērā, ka šodien tas nav tik kritiski kā pirms desmitgadēm).
Aizture
Pēc rūpīgas termināļu veiktspējas izpētes es secināju, ka vissvarīgākais parametrs šajā ziņā ir aiztures lielums (ping). Savā rakstā Pāvels Fatins izvērtēja dažādu teksta redaktoru latentumu un norādīja, ka termināļi šajā ziņā var strādāt lēnāk nekā visstraujākie teksta redaktori. Tieši šī norāde galu galā mudināja mani uzsākt savus testus un uzrakstīt šo rakstu.
Bet kas ir latentums, un kāpēc tas ir tik svarīgi? Savā rakstā Fatins to definēja kā „latentumu starp taustiņa nospiešanu un attiecīgo ekrāna atjaunināšanu” un citēja , kurā teikts: „Latentums vizuālajā atgriezeniskajā saiknē uz datora ekrāna būtiski ietekmē mašīnrakstītāja uzvedību un viņas apmierinātību.”
Fatins izskaidro, ka šāds pings ir ar dziļākām sekām, nevis tikai apmierinātību: „rakstīšana paliek lēnāka, kļūst vairāk kļūdu, palielinās acu un muskuļu spriedze.” Citiem vārdiem sakot, lielāks latentums var novest pie drukāšanas kļūdām, kā arī samazināt koda kvalitāti, jo tas rada papildu kognitīvo slodzi uz smadzenēm. Bet vēl sliktāk, pings „palielina acu un muskuļu spriedzi”, kas, acīmredzot, nozīmē nākotnē (acīmredzot autors domā par acu, muguras, roku un, protams, redzes problēmām — piezīme tulkotājam.) sakarā ar atkārtoto spriedzi.
Daži no šiem efektiem ir zināmi jau sen, bet rezultāti , kas tika publicēti jau 1976. gadā žurnālā Ergonomics, liecina, ka latentums 100 milisekundēm „ievērojami pasliktina rakstīšanas ātrumu”. Pavisam nesen GNOME lietotāja rokasgrāmatā tika iekļauts 10 milisekundēs, bet, ja mēs skatāmies tālāk, parāda, ka ideāls ir 1 milisekunde.
Fatins veica savus testus uz teksta redaktoriem; viņš izveidoja portatīvu rīku ar nosaukumu , ko es izmantoju, lai pārbaudītu ping emulēto termināļu vidē. Ņemiet vērā, ka tests tika veikts simulācijas režīmā: patiesībā jāņem vērā arī ievades (klaviatūra, USB kontrolieris utt.) un izvades (videokartes buferis, monitors) aizture. Saskaņā ar Fatina teikto, tipiskajās konfigurācijās tā ir apmēram 20 ms. Ar spēļu aprīkojumu var sasniegt tikai 3 milisekundes. Tā kā mums jau ir tāds ātrs aprīkojums, lietojumprogrammai nevajadzētu izraisīt papildu aizturi. Fatina mērķis ir samazināt lietojumprogrammas aizturi līdz 1 milisekundei vai vispār panākt iestatījumu bez , kā .
Lūk, mani mērījumu rezultāti, kā arī daži Fatina rezultāti, lai parādītu, ka mans eksperiments ir saskaņots ar viņa testiem:
Pirmais, kas mani pārsteidza, bija labākais reakcijas laiks vecajām programmām, piemēram, xterm un mlterm. Ar sliktāko reģistrācijas aizturi (2,4 ms) tās parādīja rezultātu labāku nekā ātrākā mūsdienu termināļa (10,6 ms st). Neviens mūsdienu terminālis neiznāk zem 10 milisekundēm. It īpaši, Alacritty neatbilst prasībām kā „ātrākais no esošajiem termināla emulātoriem”, lai gan tā rezultāti ir uzlabojusies kopš pirmās pārbaudes 2017. gadā. Patiesi, projekta autori un strādā pie attēlošanas uzlabošanas. Tāpat jāatzīmē, ka Vim, kas izmanto GTK3, ir kārtīgi lēnāks par tā GTK2 analogu. No tā var secināt, ka GTK3 rada papildu aizturi, un tas atspoguļojas visos citos terminālos, kas to izmanto (Terminator, Xfce4 Terminal un GNOME Terminal).
Tomēr acīmredzot atšķirības var būt nemanāmas. Kā skaidro Fatins: „nav obligāti apzināties aizturi, lai tā ietekmētu jūs.” Fatins arī brīdina par standartnovirzēm: „jebkādas novirzes aiztures ilgumā (vibrācijas) rada papildu slodzi to neparedzamības dēļ.”
Iepriekš minētie dati iegūti uz tīra Debian 9 (stretch) ar . Šī vide sniedz labākos rezultātus aiztures noteikšanas testos. Izrādās, ka GNOME rada papildu pingu 20 ms visiem mērījumiem. Iespējams, tam par iemeslu ir programmas ar sinhronu ievades notikumu apstrādi. Fatin šādam gadījumam min piemēru , kas pievieno aizturi, apstrādājot visus ievades notikumus sinhroni. Pēc noklusējuma GNOME ir aprīkots arī ar logu menedžeri , kas rada papildu buferēšanas līmeni, kas ietekmē pingu un pievieno vismaz 8 milisekundes aizturi.
Ritināšanas ātrums
Nākamais tests ir tradicionāls "ātruma" vai "caurlaidspējas" pārbaudījums, kas mēra, cik ātri termināls var ritināt lapu, attēlojot lielu teksta apjomu ekrānā. Testa mehānika svārstās; oriģinālais tests bija vienkārši ģenerēt to pašu teksta rindu, izmantojot komandu seq. Citi testi ietver Toma E. Diki testu (kas nāk ar xterm), kura ietvaros vairākkārt . Vēl vienā termināļu veiktspējas pārskatā izmanto gadījuma baitu rindu base32 kodējumā, kas tiek izvadīta terminālī, izmantojot cat. Luu uzskata šādu testu par "tik bezjēdzīgu etalonu, cik vien iespējams" un piedāvā izmantot termināla atbildi kā galveno rādītāju. Diki arī dēvē savu testu par maldinošu. Tomēr abi autori atzīst, ka termināla loga caurlaidspēja var būt problēma. Luu ir konstatējis Emacs Eshell iestrēgšanu, attēlojot lielus failus, savukārt Diki ir optimizējis termināli, lai novērstu vizuālo lēnību xtrerm. Tādēļ šim testam joprojām ir kāda jēga, bet, ņemot vērā, ka renderēšanas process ievērojami atšķiras no termināļa uz termināli, to var izmantot arī kā testēšanas komponentu citu parametru pārbaudei.
Šeit mēs redzam, ka rxvt un st izvirzās priekšā konkurentiem, kam seko daudz jaunākais Alacritty, kas tiek izstrādāts ar fokusu uz ātrdarbību. Pēc tam seko Xfce (VTE ģimene) un Konsole, kas darbojas gandrīz divas reizes ātrāk. Pēdējais ir xterm ar piecu reizi lēnāku rādītāju nekā rxvt. Testa laikā xterm arī stipri raustījās, un pārojošo tekstu bija grūti saskatīt, pat ja tā bija viena un tā pati rinda. Konsole izrādījās ātrs, taču tajā bija mirkļi, kad tas “mānījās”: ekrāns laiku pa laikam apstājās, rādīdams tekstu daļēji vai to vispār nerādot. Citi termināļi rādīja rindas skaidri, tostarp st, Alacritty un rxvt.
Diki skaidro, ka veiktspējas atšķirības saistītas ar dažādu termināļu slīdēšanas buferu dizainu. Piemēram, viņš vaino rxvt un citus termināļus, ka tie “neievēro kopējās normas”:
„Atšķirībā no xterm, rxvt necentās attēlot visus atjauninājumus. Ja tas iepaliek, tas atteiksies no daļējiem atjauninājumiem, lai panāktu piedāvājumu. Tas vairāk ietekmēja maldīgo slīdēšanas ātrumu, nevis iekšējās atmiņas organizāciju. Viens trūkums bija tas, ka ASCII animācija bija nedaudz neprecīza.”
Lai labotu šo šķietamo lēnumu xterm, Diki iesaka izmantot resursu , kas ļauj xterm noraidīt dažus ekrāna atjauninājumus, lai netiktu iepalicēts no plūsmas. Mani testi apstiprina, ka fastScroll uzlabo veiktspēju un izvirza xterm uz vienu līmeni ar rxvt. Tomēr tas ir diezgan rupjš risinājums, kā pats Diki skaidro: „Dažreiz xterm – kā arī konsole – šķietapstājies, jo tas gaida jaunu ekrāna atjauninājumu kopumu, pēc tam, kad daži no tiem ir izdzēsti.” Šajā sakarā šķiet, ka citi termināļi atraduši labāko kompromisu starp ātrumu un ekrāna integritāti.
Resursu patēriņš
Neatkarīgi no tā, cik pamatoti ir apsvērt slīdēšanas ātrumu kā veiktspējas rādītāju, šis tests ļauj imitēt slodzi uz termināļiem, kas, savukārt, ļauj mums izmērīt citus parametrus, piemēram, atmiņas vai diska izmantošanu. Metricas tika iegūtas, palaižot norādīto testu seq zem Python procesa uzraudzības. Tas vākdati par rādītājiem lai ru_maxrss, summa ru_oublock un ru_inblock un vienkāršu laika taimeri.
Šajā testā ST ieņem pirmo vietu ar mazāko vidējo atmiņas patēriņu 8 MB apmērā, kas nav pārsteidzoši, ja ņem vērā, ka projekta galvenā ideja ir vienkāršība. Nedaudz vairāk izmanto mlterm, xterm un rxvt — apmēram 12 MB. Vēl viens ievērības cienīgs rezultāts ir Alacritty, kuram darbam nepieciešami 30 MB. Pēc tam seko VTE ģimenes termināļi ar rādītājiem no 40 līdz 60 MB, kas ir diezgan liels cipars. Šādu patēriņu var izskaidrot ar to, ka šie termināļi izmanto augstākas līmeņa bibliotēkas, piemēram, GTK. Konsole noslēdz sarakstu ar milzīgu 65 MB atmiņas patēriņu testu laikā, tomēr to var pamatot ar tā plašo funkcionalitāti.
Salīdzinājumā ar iepriekšējiem rezultātiem, kas iegūti pirms desmit gadiem, visi programmatūras rīki ir sākuši patērēt ievērojami vairāk atmiņas. Agrāk Xterm prasīja 4 MB, bet tagad — 15 MB tikai palaišanai. Līdzīga patēriņa palielināšanās ir arī pie rxvt, kuram tagad ‘out of the box’ nepieciešami 16 MB. Xfce termināls aizņem 34 MB, kas ir trīs reizes vairāk nekā agrāk, bet GNOME Terminal prasa tikai 20 MB. Protams, visi iepriekšējie testi tika veikti 32 bitu arhitektūrā. LCA 2012 Rasti Rasels , kas liecina par daudzām smalkākām izskaidrojošām apstākļiem, kas var izskaidrot atmiņas patēriņa pieaugumu. Ņemot vērā to, mēs šobrīd dzīvojam laikmetā, kad mums ir veseli gigabaiti atmiņas, tāpēc mēs noteikti tiksim galā.
Tomēr man ir sajūta, ka lielākas atmiņas piešķiršana tādam pamata programmatūras risinājumam kā termināls ir resursu izšķiešana. Šīm programmām vajadzētu būt vismazākajām starp vismazākajām, un tām jāspēj darboties uz jebkuras „kastes”, pat uz apavu kaste, ja mēs kādreiz noskaidrosim, ka tās ir jāapgādā ar Linux sistēmām (un jūs taču zināt, ka tā tas notiks). Bet ar šiem cipariem atmiņas izmantošana nākotnē kļūs par problēmu jebkurā vidē, palaižot vairākus terminālus, izņemot gadījumu ar dažiem pašiem vieglākajiem un ierobežotākajiem. Lai kompensētu šo, GNOME Terminal, Konsole, urxvt, Terminator un Xfce Terminal ir Daemon režīms, kas ļauj pārvaldīt vairākus terminālus caur vienu procesu, ierobežojot to atmiņas patēriņu.
Testējot es nonācu pie vēl vienas negaidītas atziņas attiecībā uz diska lasīšanas-ierakstīšanas procesiem: es gaidīju, ka šeit vispār neko neredzēšu, bet izrādījās, ka daži termināli ieraksta visplašākos datus uz diska. Tādējādi VTE bibliotēka faktiski tur uz diska skrull buferi (šī iezīme , un tas notiek joprojām). Bet atšķirībā no vecajām realizācijām, tagad vismaz šie dati ir šifrēti, izmantojot AES256 GCM (). Bet rodas saprātīgs jautājums, kas tieši ir tik īpašs VTE bibliotēkā, ka tai nepieciešama tāda nestandarta pieeja realizācijai…
Secinājums
Pirmajā raksta daļā mēs atklājām, ka VTE balstītajiem termināliem ir labs funkciju kopums, bet tagad redzam, ka tas saistīts ar noteiktām izmaksām, lai nodrošinātu to veiktspēju. Šobrīd atmiņa nav problēma, jo visus VTE terminālus var pārvaldīt caur Daemon procesu, kurš ierobežo to apetīti. Tomēr vecākām sistēmām, kurām ir fiziskas ierobežojumi attiecībā uz operatīvās atmiņas un kodola bufera daudzumu, joprojām var būt nepieciešamas agrākas terminālu versijas, jo tās patērē ievērojami mazāk resursu. Lai gan VTE termināli ir izrādījušies labi caurlaidspējas testos (skrolēšana), to datu attēlošanas aizture ekrānā ir augstāka par noteikto slieksni GNOME lietotāja rokasgrāmatā. Iespējams, VTE izstrādātājiem tas būtu jāņem vērā. Ņemot vērā to, ka pat Linux iesācēju lietotājiem satikšanās ar termināli ir neizbēgama, viņi varētu padarīt to draudzīgāku pret lietotāju. Pieredzējušiem entuziastiem pāreja no noklusējuma termināļa var pat nozīmēt slodzes samazināšanos uz acu un iespēju izvairīties no profesionālām traumām un saslimšanām nākotnē, ņemot vērā ilgstošas darba sesijas. Diemžēl vienīgi vecās xterm un mlterm mūs noved pie burvīgā 10 milisekunžu pings sliekšņa, kas daudziem ir nepieņemams.
Kontroles mērījumi arī parādīja, ka, attīstoties Linux grafiskajām vidēm, izstrādātājiem bija jāpieņem vairāki kompromisi. Dažiem lietotājiem būtu vērts apsvērt parastās logu menedžerus, jo tie nodrošina būtisku pings samazinājumu. Diemžēl Wayland gaidīto aizturi izmērīt nebija iespējams: programma Typometer, ko es izmantoju, bija radīta, lai novērstu to, ko Wayland cenšas pārtraukt — spiegošanu par citiem logiem. Es ceru, ka Wayland kompozīcija sniegs labāku veiktspēju nekā X.org, un ceru, ka nākotnē kāds atradīs veidu, kā novērtēt aiztures līmeni šajā vidē.
Avots: habr.com
