Kelkaj vortoj de nia tradukburoo: kutime ĉiuj strebas traduki la plej novajn materialojn kaj eldonaĵojn, kaj ni ne estas escepto. Sed fina stacioj ne estas iu kiu ĝisdatigas unufoje semajne. Tial ni tradukis por vi artikolon de Antoine Beaupré, aperinta en la printempo de 2018: malgraŭ ĝia konsiderinda "aĝo" laŭ modernaj normoj, laŭ nia opinio, la materialo tute ne perdis sian gravecon. Krome, ĉi tio estis origine serio de du artikoloj, sed ni decidis kombini ilin en unu grandan afiŝon.
Terminaloj havas specialan lokon en komputila historio, sed en la lastaj jardekoj ili estis devigitaj pluvivi kune kun la komandlinio kiam grafikaj interfacoj iĝas ĉieaj. anstataŭigis sian propran , kiuj, en victurno, estis modifo de sistemoj bazitaj sur truitaj kartoj kaj baskuliloj. Modernaj distribuoj venas kun diversaj finaj emuliloj de ĉiuj formoj kaj koloroj. Kaj dum multaj kontentiĝas pri la norma terminalo provizita de sia labormedio, iuj fiere uzas tute ekzotikan programaron por ruli sian plej ŝatatan ŝelon aŭ tekstredaktilon. Sed, kiel ni vidos el ĉi tiu artikolo, ne ĉiuj fina stacioj estis kreitaj en la sama bildo: ili multe diferencas laŭ funkcieco, grandeco kaj rendimento.
Iuj fina stacioj havas tute surprizajn sekurecajn truojn, krome la plej multaj havas tute malsaman aron da funkcioj, de subteno por klapeta interfaco ĝis skripto. Kvankam ni , ĉi tiu artikolo estas ĝisdatigo de la antaŭa materialo, kiu helpos legantojn determini kiun terminalon uzi en 2018. La unua duono de la artikolo komparas trajtojn, kaj la dua duono taksas rendimenton.
Jen la terminaloj, kiujn mi recenzis:
Ĉi tiuj eble ne estas la plej novaj versioj, ĉar mi estis limigita al stabilaj konstruaĵoj dum la skribado, kiujn mi povis elŝuti sur Debian 9 aŭ Fedora 27. La sola escepto estas Alacritty. Ĝi estas posteulo de GPU-akcelitaj terminaloj kaj estas skribita en nekutima kaj nova lingvo por ĉi tiu tasko - Rust. Mi ekskludis retajn terminalojn de mia recenzo (inkluzive de tiuj sur ), ĉar preparaj testoj montris sian ekstreme malbonan efikecon.
Unikoda subteno
Mi komencis miajn testojn kun Unikoda subteno. La unua testo de la terminaloj estis montri la Unikodan ĉenon de : "é, Δ, И, ק, م, ๗, あ, 叶, 葉 kaj 말." Ĉi tiu simpla testo montras ĉu la terminalo povas funkcii ĝuste tutmonde. xterm terminalo ne montras araban karakteron en defaŭlta agordo:
Defaŭlte, xterm uzas la klasikan "fiksan" tiparon, kiu, laŭ , havas "grandan Unikodan priraportadon ekde 1997". Okazas io en ĉi tiu tiparo, kiu igas la signon aperi kiel malplena kadro kaj nur kiam la teksta tiparo estas pliigita al 20+ poentoj, ke la signo finfine komencas ĝuste montri. Tamen, ĉi tiu "korekto" rompas la montradon de aliaj Unikodaj signoj:
Ĉi tiuj ekrankopioj estis faritaj en Fedora 27, ĉar ĝi donis pli bonajn rezultojn ol Debian 9, kie kelkaj pli malnovaj versioj de terminaloj (specife mlterm) ne povis trakti tiparojn ĝuste. Feliĉe tio estis riparita en postaj versioj.
Nun rimarku kiel la linio estas montrata en xterm. Montriĝas, ke la simbolo Mem kaj la sekva semitiko raportu al RTL-stilskriptoj (), do teknike ili estu montrataj de dekstre maldekstre. TTT-legiloj kiel Firefox 57 ĝuste pritraktas la supran linion. Pli simpla versio de RTL-teksto estas la vorto "" en la hebrea (). diras la jenon:
"Multaj komputilaj programoj ne povas montri dudirektan tekston ĝuste. Ekzemple, la hebrea nomo "Sarah" konsistas el la karakteroj sin (ש) (kiu aperas dekstre), tiam resh (ר) kaj finfine li (ה) (kiu devus aperi maldekstre)."
Multaj terminaloj malsukcesas ĉi tiun provon: Alacritty, VTE-derived Gnome kaj XFCE terminaloj, urxvt, st kaj xterm montras "Sara" en inversa sinsekvo, kvazaŭ ni estus skribintaj la nomon kiel "Aras".
Alia problemo kun dudirektaj tekstoj estas, ke ili devas esti vicigitaj iel, precipe kiam temas pri miksado de RTL kaj LTR-tekstoj. RTL-skriptoj devus ruliĝi de la dekstra flanko de la fina fenestro, sed kio devus okazi por terminaloj kiuj defaŭlte al LTR-angla? Plej multaj el ili ne havas specialajn mekanismojn kaj vicigas la tutan tekston maldekstre (inkluzive en Konsole). La esceptoj estas pterm kaj mlterm, kiuj aliĝas al la normoj kaj dekstre vicigas tiajn liniojn.
Protekto de enmeto
La sekva kritika trajto, kiun mi identigis, estas kontraŭ-eniga protekto. Kvankam estas vaste konata, ke literumas kiel:
$ curl http://example.com/ | shestas kodaj ekzekutantaj puŝaj komandoj, malmultaj homoj scias, ke kaŝitaj komandoj povas ŝteliri en la konzolon kiam oni kopias kaj algluas de retumilo, eĉ post zorgema inspektado. brile montras kiom senkulpaspekta estas la komando:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitfariĝas tia ĝeno kiam algluite de la retejo de Horn en la terminalon:
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.gitKiel ĝi funkcias? Malica kodo estas inkluzivita en la bloko , kiu estas movita el la vidpunkto de la uzanto uzante CSS.
estas klare desegnita por neŭtraligi tiajn atakojn. En ĉi tiu reĝimo, terminaloj enfermas la algluitan tekston en paro de specialaj eskapaj sekvencoj por rakonti al la ŝelo pri la origino de la teksto. Ĉi tio diras al la ŝelo, ke ĝi povas ignori specialajn signojn, kiujn la algluita teksto povas enhavi. Ĉiuj fina stacioj reen al la respektinda xterm subtenas ĉi tiun funkcion, sed alglui en Bracketed-reĝimo postulas subtenon de la ŝelo aŭ aplikaĵo funkcianta sur la terminalo. Ekzemple, programaro uzante (sama Bash), bezonas dosieron ~/.inputrc:
set enable-bracketed-paste onBedaŭrinde, la testejo de Horn ankaŭ montras kiel preteriri ĉi tiun protekton per la tekstformatado mem kaj antaŭtempe fini apliki al ĝi Kramped-reĝimon. Ĉi tio funkcias ĉar iuj terminaloj ne ĝuste filtras eskapsekvencojn antaŭ ol aldoni siajn proprajn. Ekzemple, en la mia mi neniam povis sukcese plenumi la Konsole-testojn eĉ kun la ĝusta agordo .inputrc dosiero. Ĉi tio signifas, ke vi povas facile korupti vian sisteman agordon pro nesubtenata aplikaĵo aŭ malĝuste agordita ŝelo. Ĉi tio estas precipe danĝera dum ensaluto en foraj serviloj, kie zorgema agorda laboro estas malpli ofta, precipe se vi havas multajn tiajn forajn maŝinojn.
Bona solvo al ĉi tiu problemo estas la alglui konfirma kromaĵo por la terminalo urxvt, kiu simple petas permeson enmeti ajnan tekston kiu enhavas novliniojn. Mi ne trovis pli sekuran opcion por la teksta atako priskribita de Horn.
Langetoj kaj profiloj
Populara trajto nun estas subteno por klapeta interfaco, kiun ni difinos kiel unu fina fenestro enhavanta plurajn aliajn terminalojn. Ĉi tiu funkcio malsamas por malsamaj terminaloj, kaj kvankam tradiciaj xterm terminaloj tute ne subtenas langetojn, pli modernaj terminalaj enkarniĝoj kiel Xfce Terminal, GNOME Terminal kaj Konsole havas ĉi tiun funkcion. Urxvt ankaŭ subtenas langetojn, sed nur se vi uzas kromprogramon. Sed rilate al tabsubteno mem, Terminator estas la senkontesta gvidanto: ĝi ne nur subtenas langetojn, sed ankaŭ povas aranĝi terminalojn en ajna ordo (vidu bildon sube).
Alia trajto de Terminator estas la kapablo "grupigi" ĉi tiujn langetojn kune kaj sendi la samajn klavojn al pluraj terminaloj samtempe, provizante krudan ilon por fari grandajn operaciojn sur pluraj serviloj samtempe. Simila funkcio ankaŭ estas efektivigita en Konsole. Por uzi ĉi tiun funkcion en aliaj terminaloj, vi devas uzi triajn programojn kiel ekzemple , aŭ .
Langetoj funkcias precipe bone se kunigitaj kun profiloj: ekzemple, vi povas havi unu langeton por retpoŝto, alian por babilejo, ktp. Ĉi tio estas bone subtenata de Konsole Terminal kaj GNOME Terminal. Ambaŭ permesas al ĉiu langeto aŭtomate lanĉi sian propran profilon. Terminator ankaŭ subtenas profilojn, sed mi ne povis trovi manieron aŭtomate lanĉi iujn programojn kiam vi malfermas specifan langeton. Aliaj terminaloj tute ne havas la koncepton de "profilo".
Rufoj
La lasta afero, kiun mi kovros en la unua parto de ĉi tiu artikolo, estas la aspekto de la fina stacioj. Ekzemple GNOME, Xfce kaj urxvt subtenas travideblecon, sed lastatempe ĉesis subtenon por fonbildoj, devigante kelkajn uzantojn ŝanĝi al la terminalo. . Persone, mi estas kontenta pri ĝi kaj ĝi estas simpla X-rimedoj, kiu fiksas la bazan aron de fonkoloroj por urxvt. Tamen, ne-normaj koloraj temoj ankaŭ povas krei problemojn. Ekzemple, kun aplikoj и , ĉar ili jam uzas siajn proprajn kolorojn.
ne apogis kolorojn, kaj novaj ofte estis limigitaj al 256-kolora paletro. Por progresintaj uzantoj, kiuj stiligas siajn terminalojn, ŝelprogramoj aŭ statusbretoj en kompleksaj manieroj povas esti ĝena limigo. spuras kiuj terminaloj havas "True Color" subtenon. Miaj testoj konfirmas, ke st, Alacritty kaj VTE-bazitaj fina stacioj perfekte subtenas True Color. Aliaj fina stacioj ne tre bone fartas ĉi-rilate kaj, fakte, eĉ ne montras 256 kolorojn. Malsupre vi povas vidi la diferencon inter True Color-subteno en GNOME-terminaloj, st kaj xterm, kiuj faras bonan laboron per sia 256 kolora paletro, kaj urxvt, kiu ne nur malsukcesas la teston, sed eĉ montras kelkajn palpebrumajn signojn anstataŭe ilin.
Iuj terminaloj ankaŭ analizas tekston por URL-ŝablonoj por fari ligilojn klakeblaj. Ĉi tio validas por ĉiuj VTE-derivitaj terminaloj, dum urxvt postulas specialan kromprogramon kiu transformus URL-ojn per klako aŭ uzante klavaran ŝparvojon. Aliajn terminalojn mi testis montri URL-ojn alimaniere.
Fine, nova tendenco en terminaloj estas la laŭvolemo de la rulbufro. Ekzemple, st ne havas rulbufferon; oni supozas, ke la uzanto uzos terminalan multipleksilon kiel tmux kaj .
Al Alacritty ankaŭ mankas backscroll bufroj, sed ĝia subteno pro "ampleksaj sugestoj" pri ĉi tiu temo de uzantoj. Krom ĉi tiuj komencantoj, ĉiu fina stacio, kiun mi provis, ke mi povis trovi, subtenas inversan movadon.
Subtotaloj
En la dua parto de la materialo (en la originalo temis pri du malsamaj artikoloj – ĉ. lane) ni komparos rendimenton, memoruzon kaj latentecon. Sed ni jam povas vidi, ke iuj el la koncernaj fina stacioj havas gravajn mankojn. Ekzemple, uzantoj kiuj regule laboras kun RTL-skriptoj eble volas konsideri mlterm kaj pterm, ĉar ili pli bone pritraktas similajn taskojn ol aliaj. Konsole ankaŭ bone agis. Uzantoj, kiuj ne laboras kun RTL-skriptoj, povas elekti ion alian.
Rilate protekton kontraŭ malica kodo enmeto, urxvt elstaras pro sia speciala efektivigo de protekto kontraŭ ĉi tiu speco de atako, kiu ŝajnas al mi certe oportuna. Por tiuj, kiuj serĉas iujn sonorilojn kaj fajfilojn, Konsole valoras rigardi. Fine, indas noti, ke VTE estas bonega bazo por terminaloj, kiu garantias koloran subtenon, URL-rekonon ktp. Unuavide, la defaŭlta fina stacio, kiu venas kun via plej ŝatata medio, eble plenumas ĉiujn postulojn, sed ni lasu ĉi tiun demandon malfermita ĝis ni komprenos la agadon.
Ni daŭrigu la konversacion
Ĝenerale, la agado de fina stacioj en si mem povas ŝajni nepra problemo, sed kiel rezultas, kelkaj el ili elmontras surprize altan latentecon por programaro de tia fundamenta tipo. Ankaŭ poste ni rigardos tion, kion oni tradicie nomas "rapideco" (fakte, ĉi tio estas la rulrapideco) kaj memorkonsumon de la terminalo (kun la averto, ke ĉi tio ne estas tiel kritika hodiaŭ kiel antaŭ jardekoj).
Prokrasto
Post profunda studo pri fina agado, mi alvenis al la konkludo, ke la plej grava parametro ĉi-rilate estas la latencia (ping). En lia artikolo Pavel Fatin rigardis la latentecon de diversaj tekstredaktiloj kaj aludis, ke terminaloj tiurilate povas esti pli malrapidaj ol la plej rapidaj tekstredaktiloj. Estis ĉi tiu sugesto, kiu finfine kondukis min fari miajn proprajn testojn kaj verki ĉi tiun artikolon.
Sed kio estas latencia, kaj kial ĝi estas tiel grava? En sia artikolo, Fatin difinis ĝin kiel "la prokrasto inter premado de klavo kaj la ekvivalenta ĝisdatigo de ekrano" kaj citis , kiu deklaras: "La prokrasto en vidaj sugestoj sur komputila ekrano havas gravan efikon al tajpista konduto kaj kontento."
Fatin klarigas, ke ĉi tiu ping havas pli profundajn sekvojn ol nur kontentigo: "tajpado fariĝas pli malrapida, pli da eraroj okazas, kaj okulo kaj muskola streĉiĝo pliiĝas." Alivorte, granda prokrasto povas konduki al tajperaroj kaj ankaŭ malpliigi kodkvaliton, ĉar ĝi kondukas al plia kogna ŝarĝo sur la cerbo. Sed kio estas pli malbona estas ke ping "pliigas okulan kaj muskola streĉiĝon", kio ŝajnas implici estontece (Ŝajne, la aŭtoro signifas problemojn kun la muskoloj de la okuloj, dorso, brakoj kaj, kompreneble, vidado - ĉ. lane) pro ripetema streso.
Iuj el ĉi tiuj efikoj estas konataj delonge, kaj la rezultoj , publikigita reen en 1976 en la ĵurnalo Ergonomics , diris ke prokrasto de 100 milisekundoj "signife difektas tajprapidecon." Pli lastatempe, la GNOME Uzantgvidilo enkondukita en 10 milisekundoj, kaj se vi iros plu, tiam montras ke 1 milisekundo estas ideala.
Fatin faris siajn testojn pri tekstredaktiloj; li kreis porteblan instrumenton nomitan , kiun mi uzis por testi ping en finaj emuliloj. Memoru, ke la testo estis farita en simuladreĝimo: fakte, ni devas konsideri ambaŭ enigajn (klavaron, USB-regilon ktp.) kaj elirajn (vidkartbufron, monitoron) latencia. Laŭ Fatin, en tipaj agordoj ĝi estas ĉirkaŭ 20 ms. Se vi havas videoludan ekipaĵon, vi povas atingi ĉi tiun ciferon en nur 3 milisekundoj. Ĉar ni jam havas tian rapidan aparataron, la aplikaĵo ne devas aldoni sian propran latentecon. La celo de Fatin estas alporti la latencia de la aplikaĵo al 1 milisekundo, aŭ eĉ atingi diskadon sen , kiel en .
Jen la rezultoj de miaj mezuradoj, same kiel kelkaj el la rezultoj de Fatin, por montri, ke mia eksperimento konsentas kun liaj provoj:
La unua afero, kiu frapis min, estis la pli bona responda tempo de pli malnovaj programoj kiel xterm kaj mlterm. Kun la plej malbona registro latenteco (2,4 ms), ili rezultis pli bone ol la plej rapida moderna terminalo (10,6 ms por st). Neniu moderna terminalo falas sub la 10 milisekunda sojlo. Aparte, Alacritty ne plenumas la aserton pri "plej rapida disponebla terminala emulilo", kvankam ĝiaj poentoj pliboniĝis ekde ĝia unua revizio en 2017. Efektive, la aŭtoroj de la projekto kaj laboras por plibonigi la ekranon. Oni devas ankaŭ rimarki, ke Vim uzanta GTK3 estas grandordo pli malrapida ol sia GTK2 ekvivalento. El tio ni povas konkludi, ke GTK3 kreas plian latentecon, kaj tio reflektiĝas en ĉiuj aliaj terminaloj, kiuj uzas ĝin (Terminator, Xfce4 Terminal kaj GNOME Terminal).
Tamen, la diferencoj eble ne estas videblaj al la okulo. Kiel Fatin klarigas, "vi ne devas esti konscia pri la prokrasto por ke ĝi efektu vin." Fatin ankaŭ avertas pri norma devio: "ĉiaj perturboj en latenteco (jitter) kreas plian streson pro ilia neantaŭvidebleco."
La supra grafikaĵo estas prenita sur pura Debian 9 (streĉado) kun . Ĉi tiu medio produktas la plej bonajn rezultojn en latenciaj testoj. Kiel ĝi rezultas, GNOME kreas plian ping de 20 ms por ĉiuj mezuradoj. Ebla klarigo por tio estas la ĉeesto de programoj kun sinkrona prilaborado de enigokazaĵoj. Fatin donas ekzemplon por tia kazo , kiu aldonas prokraston prilaborante ĉiujn enigajn eventojn sinkrone. Defaŭlte, GNOME ankaŭ venas kun fenestra administranto , kiu kreas plian tavolon de bufro, kiu influas ping kaj aldonas almenaŭ 8 milisekundojn da latenteco.
Rulumrapido
La sekva testo estas tradicia "rapideco" aŭ "bendolarĝo" testo, kiu mezuras kiom rapide la terminalo povas rulumi paĝon dum montras grandajn kvantojn da teksto sur la ekrano. La mekaniko de la testo varias; la origina testo estis simple generi la saman tekstoĉenon uzante la seq-komandon. Aliaj testoj inkluzivas la teston de Thomas E. Dickey (xterm-prizorganto), kiu plurfoje . En alia recenzo pri fina agado uzas bazo32 ĉifritan ĉenon de hazardaj bajtoj, kiu estas eligita al la terminalo uzante katon. Luu konsideras tian teston kiel "tiel senutila komparnormo kiel oni povas imagi" kaj sugestas uzi fina respondon kiel primaran metrikon anstataŭe. Dickey ankaŭ nomas sian teston misgvida. Tamen ambaŭ aŭtoroj agnoskas, ke fina bendolarĝo povas esti problemo. Luu malkovris Emacs Eshell frostiĝi dum montrado de grandaj dosieroj, kaj Dickey optimumigis la terminalon por forigi la vidan malrapidecon de xtrerm. Do ankoraŭ estas iom da merito al ĉi tiu testo, sed ĉar la bildiga procezo estas tre malsama de terminalo al terminalo, ĝi ankaŭ povas esti uzata kiel testa komponanto por testi aliajn parametrojn.
Ĉi tie ni vidas la rxvt kaj st-tiron antaŭ la konkurado, sekvita de la multe pli nova Alacritty, kiu estas dizajnita kun fokuso sur efikeco. Sekvas Xfce (VTE-familio) kaj Konsole, kiuj estas preskaŭ duoble pli rapidaj. Lasta estas xterm, kiu estas kvinoble pli malrapida ol rxvt. Dum la testo, xterm ankaŭ ondetis multe, malfaciligante preterpasantan tekston eĉ se ĝi estis la sama linio. Konsole estis rapida, sed ĝi estis delikata foje: la ekrano frostiĝis de tempo al tempo, montrante partan tekston aŭ tute ne montrante ĝin. Aliaj terminaloj montris ŝnurojn klare, inkluzive de st, Alacritty, kaj rxvt.
Dickey klarigas ke la efikecodiferencoj ŝuldiĝas al la dezajno de rulbufroj en malsamaj terminaloj. Aparte, li akuzas rxvt kaj aliajn terminalojn je "ne sekvado de la ĝeneralaj reguloj":
"Malkiel xterm, rxvt ne provis montri ĉiujn ĝisdatigojn. Se ĝi malfruos, ĝi rifuzos iujn ĝisdatigojn por atingi. Tio havis pli grandan efikon al ŝajna paĝrulrapideco ol al interna memororganizo. Unu malavantaĝo estis ke la ASCII-animacio estis iom nepreciza."
Por ripari ĉi tiun perceptitan xterm malviglecon, Dickey sugestas uzi la rimedon , permesante al xterm forĵeti kelkajn ekranajn ĝisdatigojn por daŭrigi kun la fluo. Miaj testoj konfirmas, ke fastScroll plibonigas rendimenton kaj alportas xterm egale kun rxvt. Ĉi tio tamen estas sufiĉe malglata lambastono, kiel Dickey mem klarigas: "foje xterm - kiel konsole - ŝajnas ekhalti, kiam ĝi atendas novan aron da ekranaj ĝisdatigoj post kiam kelkaj estis forigitaj." En ĉi tiu maniero, ŝajnas, ke aliaj fina stacioj trovis la plej bonan kompromison inter rapideco kaj ekrana integreco.
Rimeda konsumo
Sendepende de ĉu havas sencon konsideri rulrapidecon kiel rendimentan metrikon, ĉi tiu testo ebligas al ni simuli la ŝarĝon sur la terminaloj, kio siavice permesas al ni mezuri aliajn parametrojn kiel memoron aŭ diskuzon. La metrikoj estis akiritaj per la specifita testo sek sub Python-proceza monitorado. Li kolektis metrodatenojn por ru_maxrss, kvanto ru_oblock и ru_inblock kaj simpla tempigilo.
En ĉi tiu provo, la ST prenas la unuan lokon kun la plej malalta averaĝa memorkonsumo de 8 MB, kio ne estas surpriza konsiderante, ke la ĉefa ideo de la dezajno estas simpleco. mlterm, xterm kaj rxvt konsumas iom pli - ĉirkaŭ 12 MB. Alia rimarkinda rezulto estas Alacritty, kiu postulas 30 MB por funkcii. Poste estas terminaloj de la familio VTE kun ciferoj de 40 ĝis 60 MB, kio estas sufiĉe multe. Ĉi tiu konsumo povas esti klarigita per la fakto, ke ĉi tiuj terminaloj uzas pli altnivelajn bibliotekojn, ekzemple GTK. Konsole venas la lasta kun enorma 65MB da memorkonsumo dum testoj, kvankam tio povas esti pravigita per ĝia tre larĝa gamo de funkcioj.
Kompare kun antaŭaj rezultoj akiritaj antaŭ dek jaroj, ĉiuj programoj komencis konsumi rimarkinde pli da memoro. Xterm antaŭe postulis 4 MB, sed nun ĝi postulas 15 MB nur ĉe ekfunkciigo. Estas simila pliiĝo en konsumo por rxvt, kiu nun postulas 16 MB el la skatolo. Xfce Terminalo okupas 34 MB, kio estas trioble pli granda ol antaŭe, sed GNOME Terminalo postulas nur 20 MB. Kompreneble, ĉiuj antaŭaj provoj estis faritaj sur 32-bita arkitekturo. Ĉe LCA 2012 Rusty Russell , ke ekzistas multaj pli subtilaj kialoj kiuj povus klarigi la pliiĝon en memorkonsumo. Dirinte tion, ni nun vivas en tempo, kie ni havas gigabajtojn da memoro, do ni iel administros.
Tamen, mi ne povas ne senti, ke asigni pli da memoro al io tiel fundamenta kiel la terminalo estas malŝparo de rimedoj. Ĉi tiuj programoj devus esti la plej malgrandaj el la plej malgrandaj, devus povi funkcii per iu ajn "skatolo", eĉ ŝuoskatolo, se ni iam venos al la punkto, kie ili devas esti ekipitaj per Linuksaj sistemoj (kaj vi scias, ke tiel estos. ). Sed kun ĉi tiuj nombroj, la uzado de memoro fariĝos problemo estonte en iu ajn medio, kiu funkcias plurajn terminalojn krom kelkaj el la plej malpezaj kaj plej limigitaj en kapabloj. Por kompensi tion, GNOME Terminal, Konsole, urxvt, Terminator kaj Xfce Terminal havas Daemon-reĝimon, kiu ebligas al vi kontroli plurajn terminalojn per ununura procezo, limigante ilian memorkonsumon.
Dum miaj provoj, mi venis al alia neatendita rezulto rilate disklegadon-skribadon: mi atendis vidi nenion ĉi tie, sed montriĝis, ke iuj terminaloj skribas la plej volumenajn datumojn al disko. Do, la VTE-biblioteko efektive konservas rulbufron sur disko (ĉi tiu funkcio , kaj ĉi tio ankoraŭ okazas). Sed male al pli malnovaj efektivigoj, nun almenaŭ ĉi tiuj datumoj estas ĉifritaj per AES256 GCM (). Sed akceptebla demando ekestas: kio estas tiel speciala pri la VTE-biblioteko, ke ĝi postulas tian nenorman aliron al efektivigo...
konkludo
En la unua parto de la artikolo, ni trovis, ke terminaloj bazitaj en VTE havas bonan aron da funkcioj, sed nun ni vidas, ke ĉi tio venas kun iuj rendimentaj kostoj. Nun memoro ne estas problemo ĉar ĉiuj VTE-terminaloj povas esti kontrolitaj per Daemon-procezo, kiu limigas ilian apetiton. Tamen, pli malnovaj sistemoj kiuj havas fizikajn limigojn sur la kvanto de RAM kaj kernaj bufroj eble ankoraŭ bezonas pli fruajn versiojn de terminaloj, ĉar ili konsumas signife malpli da resursoj. Kvankam VTE-terminaloj bone funkciis en testoj pri trairo (paĝrulado), ilia montra latenco estas super la sojlo fiksita en la Uzantgvidilo de GNOME. VTE-programistoj verŝajne devus konsideri tion. Se ni konsideras, ke eĉ por komencantoj de Linukso-uzantoj renkonti terminalon estas neevitebla, ili povas igi ĝin pli uzantamika. Por spertaj geeks, ŝanĝi de la defaŭlta terminalo povas eĉ signifi malpli da okulstreĉo kaj la kapablon eviti estontajn labor-rilatajn vundojn kaj malsanojn pro longaj laborsesioj. Bedaŭrinde, nur la malnovaj xterm kaj mlterm alportas nin al la magia ping-sojlo de 10 milisekundoj, kio estas neakceptebla por multaj.
Benchmark-mezuradoj ankaŭ montris ke pro la evoluo de Linuksaj grafikaj medioj, programistoj devis fari kelkajn kompromisojn. Iuj uzantoj eble volas rigardi regulajn fenestrajn administrantojn ĉar ili provizas gravan ping-redukton. Bedaŭrinde, ne eblis mezuri latentecon por Wayland: la programo Typometer kiun mi uzis estis kreita por tio, kion Wayland estas desegnita por malhelpi: spioni aliajn fenestrojn. Mi esperas, ke Wayland-komponado funkcias pli bone ol X.org, kaj mi ankaŭ esperas, ke estonte iu trovos manieron mezuri latentecon en ĉi tiu medio.
fonto: www.habr.com