Gure itzulpen bulegotik hitz batzuk: normalean denak ahalegintzen dira azken materialak eta argitalpenak itzultzen, eta gu ez gara salbuespena. Baina terminalak ez dira astean behin eguneratzen den zerbait. Hori dela eta, 2018ko udaberrian argitaratutako Antoine Beaupréren artikulu bat itzuli dizuegu: estandar modernoen arabera “adin” handia izan arren, gure ustez, materialak ez du batere garrantzirik galdu. Horrez gain, hasiera batean bi artikuluko seriea zen, baina mezu handi batean konbinatzea erabaki genuen.
Terminalek leku berezia dute ordenagailuen historian, baina azken hamarkadetan komando-lerroaren ondoan bizirautera behartuta egon dira interfaze grafikoak nonahikoak diren heinean. berenak ordezkatu zituzten , hau da, txartel zulatuetan eta etengailu etengailuetan oinarritutako sistemen aldaketa bat ziren. Banaketa modernoak forma eta kolore guztietako terminal emuladore ugarirekin datoz. Eta asko beren lan-inguruneak eskaintzen duen terminal estandarrekin konforme dauden arren, batzuek harro erabiltzen dute software exotikoa bere gogoko shell edo testu editorea exekutatzeko. Baina, artikulu honetan ikusiko dugunez, terminal guztiak ez dira irudi berean sortu: funtzionalitatean, tamainan eta errendimenduan oso desberdinak dira.
Terminal batzuek segurtasun-zulo harrigarriak dituzte, eta gehienek funtzio multzo guztiz desberdinak dituzte, fitxadun interfazearen euskarritik hasi eta script-era arte. Guk arren , artikulu hau aurreko materialaren eguneraketa bat da, irakurleei 2018an zein terminal erabili behar duten zehazten lagunduko diena. Artikuluaren lehen zatiak ezaugarriak alderatzen ditu eta bigarren zatiak errendimendua ebaluatzen du.
Hona hemen berrikusi ditudan terminalak:
Hauek ez dira azken bertsioak izan, idazteko garaian konpilazio egonkorrera mugatuta nengoen eta Debian 9 edo Fedora 27-n zabaldu ahal izan nituen. Salbuespen bakarra Alacritty da. GPU azeleratutako terminalen ondorengoa da eta zeregin honetarako ezohiko eta hizkuntza berri batean idatzita dago - Rust. Nire berrikuspenetik web terminalak baztertu nituen (aurrekoak barne ), aurretiazko probek oso errendimendu eskasa erakutsi zutelako.
Unicode laguntza
Unicode laguntzarekin hasi nintzen nire probak. Terminalen lehen proba Unicode katea bistaratzea izan zen : "é, Δ, И, ק, م, ๗, あ, 叶, 葉 eta 말." Proba sinple honek terminalak mundu osoan behar bezala funtziona dezakeen erakusten du. xterm terminalak ez du arabiar karaktererik erakusten konfigurazio lehenetsian:
Lehenespenez, xterm-ek letra-tipo "finko" klasikoa erabiltzen du, hau da, arabera , "Unicode estaldura handia du 1997tik". Zerbait gertatzen ari da letra-tipo honetan karakterea marko huts gisa agertzea eragiten duena eta testuaren letra-tipoa 20 puntu baino gehiagora igotzen denean bakarrik hasten da karakterea behar bezala bistaratzen. Hala ere, "konponketa" honek beste Unicode karaktereen bistaratzea hausten du:
Pantaila-argazki hauek Fedora 27-n egin ziren, Debian 9k baino emaitza hobeak eman baitzituen, non terminalen bertsio zaharrago batzuek (zehazki mlterm) ezin baitzituzten letra-tipoak behar bezala kudeatu. Zorionez, ondorengo bertsioetan konpondu zen.
Orain konturatu lerroa xterm-en nola bistaratzen den. Gertatzen da Mem sinboloa eta ondorengo semitikoa erreferentzia RTL estiloko scriptetara (), beraz, teknikoki eskuinetik ezkerrera bistaratu behar dira. Firefox 57 bezalako web arakatzaileek zuzen kudeatzen dute goiko lerroa. RTL testuaren bertsio sinpleago bat hitza da ""hebreeraz (). honako hau dio:
“Konputagailu-programa askok ezin dute bi norabideko testua behar bezala bistaratu. Adibidez, "Sarah" hebreerazko izena sin (ש) karaktereek osatzen dute (eskuinean agertzen dena), gero resh (ר) eta azkenik he (ה) (ezkerrean agertu beharko litzatekeena)."
Terminal askok huts egiten du proba hau: Alacritty, VTE-tik eratorritako Gnome eta XFCE terminalek, urxvt, st eta xterm-ek "Sara" alderantzizko ordenan bistaratzen dute, izena "Aras" bezala idatzi izan bagenu bezala.
Bi norabideko testuen beste arazo bat da nolabait lerrokatu behar direla, batez ere RTL eta LTR testuak nahasteko orduan. RTL script-ak terminal-leihoaren eskuineko aldean exekutatu beharko lirateke, baina zer gertatu beharko litzateke lehenetsita LTR ingelesa duten terminalekin? Gehienek ez dute mekanismo berezirik eta testu guztia ezkerrera lerrokatzen dute (Konsolen barne). Salbuespenak pterm eta mlterm dira, estandarrei atxikitzen zaizkienak eta eskuinera lerrokatzen dituztenak.
Txertatzeko babesa
Identifikatu dudan hurrengo ezaugarri kritikoa sartzearen aurkako babesa da. Nahiz eta oso ezaguna den honela idazten dela:
$ curl http://example.com/ | shkodea exekutatzeko push komandoak dira, jende gutxik daki ezkutuko komandoak kontsolara sartu daitezkeela web arakatzailetik kopiatu eta itsatsitakoan, arretaz aztertu ondoren ere. bikain erakusten du komandoa zein itxuragabea den:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.githalako traba bihurtzen da Horn-en webgunetik terminalera itsatsitakoan:
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.gitNola dabil? Kode gaiztoa blokean sartzen da , erabiltzailearen ikuspegitik kanpo ateratzen dena CSS erabiliz.
argi dago horrelako erasoak neutralizatzeko diseinatuta. Modu honetan, terminalek itsatsitako testua ihes-sekuentzia berezi pare batean sartzen dute shell-ari testuaren jatorriaren berri emateko. Honek shellari esaten dio itsatsitako testuak izan ditzakeen karaktere bereziak alde batera utzi ditzakeela. Xterm agurgarrira itzuli diren terminal guztiek funtzio hau onartzen dute, baina Parentesi moduan itsatsitzeak terminalean exekutatzen den shell edo aplikazioaren laguntza behar du. Adibidez, softwarea erabiltzea (Bash bera), fitxategi bat behar du ~/.inputrc:
set enable-bracketed-paste onZoritxarrez, Horn-en proba-guneak babes hori nola saihestu ere erakusten du testu-formatuaren beraren bidez eta aurretik parentesi modua aplikatzen amaitzen da. Honek funtzionatzen du terminal batzuek ez dituztelako behar bezala iragazten ihes-sekuentziak eurenak gehitu aurretik. Adibidez, nirean ez nintzen inoiz Konsoleko probak behar bezala burutu konfigurazio zuzenarekin ere .sarrera fitxategia. Horrek esan nahi du zure sistemaren konfigurazioa erraz hondatu dezakezula onartzen ez den aplikazio bat edo gaizki konfiguratutako shell baten ondorioz. Hau bereziki arriskutsua da urruneko zerbitzarietan saioa hasten denean, non konfigurazio-lan zaindua ez da hain ohikoa, batez ere horrelako urruneko makina asko badituzu.
Arazo honen konponbide ona terminalerako itsatsi berrespen plugina da urxvt, lerro berriak dituen edozein testu txertatzeko baimena besterik ez du eskatzen. Hornek deskribatutako testu-erasorako ez dut aukera seguruagorik aurkitu.
Fitxak eta profilak
Oraingo ezaugarri ezagun bat fitxadun interfazearen laguntza da, beste hainbat terminal dituen terminal-leiho gisa definituko duguna. Funtzio hau desberdina da terminal desberdinetarako, eta xterm terminal tradizionalek fitxak batere onartzen ez dituzten arren, terminal modernoagoek, hala nola, Xfce Terminal, GNOME Terminal eta Konsole funtzio hori dute. Urxvt-ek fitxak ere onartzen ditu, baina plugin bat erabiltzen baduzu bakarrik. Baina fitxen euskarria berari dagokionez, Terminator da eztabaidaezina den liderra: fitxak onartzen ditu ez ezik, terminalak edozein ordenatan antolatu ditzake (ikus beheko irudia).
Terminator-en beste ezaugarri bat fitxa hauek elkarrekin "taldekatzeko" eta aldi berean tekla sakatu berdinak hainbat terminaletara bidaltzeko gaitasuna da, hainbat zerbitzarietan aldi berean eragiketa ugari egiteko tresna gordina eskaintzen duena. Konsolen ere antzeko ezaugarri bat ezartzen da. Ezaugarri hau beste terminal batzuetan erabiltzeko, hirugarrenen softwarea erabili behar duzu, adibidez , edo .
Fitxek bereziki ondo funtzionatzen dute profilekin parekatzen direnean: adibidez, fitxa bat izan dezakezu posta elektronikorako, beste bat txateko eta abar. Konsole Terminalek eta GNOME Terminalek ondo onartzen dute. Biek aukera ematen dute fitxa bakoitzari bere profila automatikoki abiarazteko. Terminator-ek profilak ere onartzen ditu, baina ezin izan dut aurkitu fitxa zehatz bat irekitzen duzunean programa batzuk automatikoki abiarazteko modurik. Beste terminalek ez dute batere "profil" kontzeptua.
Ruffles
Artikulu honen lehen zatian azalduko dudan azken gauza terminalen itxura da. Adibidez, GNOMEk, Xfcek eta urxvt-ek gardentasuna onartzen dute, baina duela gutxi atzeko planoko irudietarako laguntza kendu dute, erabiltzaile batzuk terminalera aldatzera behartuz. . Pertsonalki, pozik nago eta erraza da Xbaliabideak, urxvt-rako atzeko planoko koloreen oinarrizko multzoa ezartzen duena. Hala ere, kolore ez-estandarrak arazoak ere sor ditzakete. Adibidez, aplikazioekin и , dagoeneko euren koloreak erabiltzen baitituzte.
ez zituen koloreak onartzen, eta berriak 256 koloreko paleta batera mugatzen ziren askotan. Beren terminalak estiloa duten erabiltzaile aurreratuentzat, shell-en abisuak edo egoera-barrak modu konplexuan muga gogaikarria izan daitezke. "True Color" euskarria duten terminalek jarraitzen dute. Nire probek st, Alacritty eta VTEn oinarritutako terminalek True Color ezin hobeto onartzen dutela baieztatzen dute. Beste terminal batzuek ez dute oso ondo ateratzen zentzu honetan eta, izan ere, 256 kolore ere ez dituzte bistaratzen. Jarraian, True Color euskarriaren arteko aldea ikus dezakezu GNOME terminaletan, st eta xterm, hauek lan ona egiten baitute beren 256 kolore-paletarekin, eta urxvt, proban huts egiteaz gain, karaktere keinukari batzuk erakusten dituena haien ordez.
Terminal batzuek testua ere aztertzen dute URL ereduetarako, estekak klikagarriak izan daitezen. Hau VTEtik eratorritako terminal guztietan aplikatzen da, eta urxvt-ek, berriz, URLak klik batean edo teklatuko lasterbide bat erabiliz eraldatuko dituen plugin berezi bat behar du. Probatu ditudan beste terminal batzuk bistaratzeko URLak beste modu batzuetan.
Azkenik, terminalen joera berri bat desplazamendu-buffer-aren aukera da. Adibidez, st-k ez du korritze-bufferrik; erabiltzaileak tmux eta bezalako terminal-multiplexadorea erabiliko duela suposatzen da .
Alacrittyk ere backscroll buffer-ak falta ditu, baina bere laguntza gai honi buruzko "iritzi zabala" dela eta, erabiltzaileek. Hasiberri hauetaz gain, probatu ditudan terminal guztiek alderantzizko korritzea onartzen dute.
guztizko partzialak
Materialaren bigarren zatian (jatorrizkoan bi artikulu ezberdin ziren - gutxi gorabehera. erreia) errendimendua, memoriaren erabilera eta latentzia alderatuko ditugu. Baina dagoeneko ikusten dugu aipatutako terminal batzuek gabezia larriak dituztela. Esate baterako, RTL scriptekin aldian-aldian lan egiten duten erabiltzaileek mlterm eta pterm kontuan hartu nahi dituzte, besteek baino hobeak baitira antzeko zereginak kudeatzen. Konsole ere ondo aritu zen. RTL scriptekin lan egiten ez duten erabiltzaileek beste zerbait aukeratu dezakete.
Kode maltzurren txertatzeen aurkako babesari dagokionez, urxvt-ek eraso mota honen aurkako babesaren ezarpen bereziagatik nabarmentzen da, eta hori guztiz komenigarria iruditzen zait. Kanpai eta txistu batzuen bila dabiltzanentzat, Konsolek begirada bat merezi du. Azkenik, nabarmentzekoa da VTE terminaletarako oinarri bikaina dela, koloreen euskarria, URL aitorpena eta abar bermatzen dituena. Lehen begiratuan, zure ingurune gogokoenarekin datorren terminal lehenetsiak baldintza guztiak bete ditzake, baina utz dezagun galdera hau zabalik errendimendua ulertu arte.
Jarrai dezagun elkarrizketa
Orokorrean, terminalen errendimendua berez urruneko arazoa dela dirudi, baina antza denez, horietako batzuek latentzia harrigarri handia dute oinarrizko mota horretako softwarerako. Ondoren, tradizionalki "abiadura" deitzen dena (hau da, korritze-abiadura da) eta terminalaren memoria-kontsumoa aztertuko dugu (oharra ez dela gaur egun duela hamarkada batzuk bezain kritikoa).
atzerapenik
Terminalaren errendimenduaren azterketa sakon baten ondoren, zentzu honetan parametrorik garrantzitsuena latentzia (ping) dela ondorioztatu nuen. Bere artikuluan Pavel Fatinek hainbat testu-editoreren latentzia aztertu zuen eta zentzu honetan terminalak testu-editore azkarrenak baino motelagoak izan daitezkeela adierazi zuen. Iradokizun hau izan zen azkenean nire probak egitera eta artikulu hau idaztera eraman ninduena.
Baina zer da latentzia, eta zergatik da hain garrantzitsua? Bere artikuluan, Fatinek "tekla bat sakatzearen eta dagokion pantaila eguneratzearen arteko atzerapena" bezala definitu zuen eta aipatu zuen. , hauxe dio: "Ordenagailuaren pantailan ikusizko feedbackaren atzerapenak eragin handia du mekanografoaren portaeran eta gogobetetasunean".
Fatinek azaldu duenez, ping horrek asebetetze hutsa baino ondorio sakonagoak ditu: "idazketa motelago bihurtzen da, akats gehiago gertatzen dira eta begien eta giharren tentsioa areagotzen da". Beste era batera esanda, atzerapen handi batek akatsak sor ditzake eta, gainera, kodearen kalitatea txikiagoa izan daiteke, garunean karga kognitibo gehigarria dakarrelako. Baina okerrena da ping-ak "begi eta muskuluen tentsioa areagotzen duela", eta horrek esan nahi duela dirudi. etorkizunean (Dirudienez, egileak begien, bizkarraren, besoen eta, noski, ikusmenaren muskuluen arazoak esan nahi ditu - gutxi gorabehera. erreia) errepikakorra den estresaren ondorioz.
Efektu horietako batzuk aspalditik ezagutzen dira, eta emaitzak , Ergonomics aldizkarian 1976an argitaratua, 100 milisegundoko atzerapenak "nabarmen hondatzen du idazteko abiadura". Duela gutxi, GNOME Erabiltzaile Gida aurkeztu da 10 milisegundotan, eta harago joanez gero, orduan milisegundo 1 ideala dela erakusten du.
Fatinek testu-editoreetan egin zituen bere probak; izeneko tresna eramangarri bat sortu zuen terminal emuladoreetan ping probatzeko erabiltzen nuena. Kontuan izan proba simulazio moduan egin dela: errealitatean, sarrera (teklatua, USB kontrolagailua, etab.) zein irteera (bideo txartelaren buffer, monitorea) latentzia kontuan hartu behar ditugu. Fatinen arabera, konfigurazio tipikoetan 20 ms ingurukoa da. Jolas-ekiporik baduzu, zifra hori 3 milisegundotan lor dezakezu. Dagoeneko hardware hain azkarra dugunez, aplikazioak ez du bere latentziarik gehitu beharrik. Fatinen helburua aplikazioaren latentzia milisegundo 1era ekartzea da, edo baita markarik gabe markatzea ere , nola sartu .
Hona hemen nire neurketen emaitzak, baita Fatinen emaitza batzuk ere, nire esperimentua bere probekin bat datorrela erakusteko:
Xterm eta mlterm bezalako programa zaharren erantzun-denbora hobea izan da deigarria izan ninduen lehenengo gauza. Erregistroko latentziarik txarrenarekin (2,4 ms), terminal moderno bizkorrenak baino hobeto aritu dira (10,6 ms st-rako). Ez dago terminal modernorik 10 milisegundoko atalasearen azpitik. Bereziki, Alacrittyk ez du betetzen "eskuragarri dagoen terminal-emuladore azkarrena" erreklamazioa, nahiz eta bere puntuazioak hobetu egin diren 2017an egin zuen lehen berrikuspenetik. Izan ere, proiektuaren egileak eta pantaila hobetzeko lanean ari dira. Kontuan izan behar da, halaber, Vim GTK3 erabiliz bere GTK2 parekoa baino magnitude ordena bat motelagoa dela. Hortik ondoriozta dezakegu GTK3-k latentzia gehigarria sortzen duela, eta hori erabiltzen duten beste terminal guztietan islatzen da (Terminator, Xfce4 Terminal eta GNOME Terminal).
Hala ere, baliteke desberdintasunak begien aurrean ez nabaritzea. Fatinek azaldu duenez, "ez duzu atzerapenaren berri izan behar zuregan eragina izan dezan". Fatinek desbideratze estandarrari buruz ere ohartarazten du: "latentzian (jitter) edozein asaldurak estres gehigarria sortzen du ezustekoaren ondorioz".
Goiko grafikoa Debian 9 (stretch) hutsean hartuta dago . Ingurune honek emaitzarik onenak ematen ditu latentzia-probetan. Ikusten denez, GNOMEk 20 ms-ko ping gehigarria sortzen du neurketa guztietarako. Horren azalpen posible bat sarrera-gertaeren prozesamendu sinkronikoa duten programen presentzia da. Fatinek adibide bat ematen du halako kasu baterako , eta horrek atzerapena gehitzen du sarrera-gertaera guztiak modu sinkronoan prozesatuz. Lehenespenez, GNOME leiho kudeatzaile batekin ere dator , buffer-geruza gehigarri bat sortzen duena, ping-a eragiten duena eta gutxienez 8 milisegundoko latentzia gehitzen duena.
Korritzeko abiadura
Hurrengo proba "abiadura" edo "banda-zabalera" ohiko proba bat da, eta horrek terminalak orri bat korritu dezakeen abiadura neurtzen du pantailan testu kantitate handiak erakusten dituen bitartean. Probaren mekanika aldatu egiten da; jatorrizko proba testu-kate bera sortzea besterik ez zen seq komandoa erabiliz. Beste proba batzuen artean Thomas E. Dickeyren (xterm mantentzailea) proba, behin eta berriz . Terminalaren errendimenduaren beste berrikuspen batean ausazko byteen base32 kodetutako kate bat erabiltzen du, katu erabiliz terminalera ateratzen dena. Luu-k uste du horrelako proba bat "iruditzen den bezain alferrikako erreferentziatzat" dela eta, horren ordez, terminaleko erantzuna metrika nagusi gisa erabiltzea proposatzen du. Dickeyk ere engainagarria deritzo bere proba. Hala ere, bi egileek onartzen dute terminaleko leihoaren banda zabalera arazo bat izan daitekeela. Luuk Emacs Eshell izoztuta aurkitu zuen fitxategi handiak erakustean, eta Dickeyk terminala optimizatu zuen xtrerm-en ikusmen geldotasuna kentzeko. Beraz, proba honek badu oraindik merituren bat, baina errendatze-prozesua terminal batetik terminalera oso desberdina denez, proba-osagai gisa ere erabil daiteke beste parametro batzuk probatzeko.
Hemen rxvt eta st tiraka ikusten ditugu lehiaketaren aurretik, eta ondoren, askoz berriagoa den Alacritty, errendimenduan arreta jarrita diseinatua. Ondoren, Xfce (VTE familia) eta Konsole daude, ia bi aldiz azkarragoak. Azken xterm da, rxvt baino bost aldiz motelagoa dena. Proban zehar, xterm-ek ere asko eragin zuen, eta testua pasatzea zaila izan zen lerro bera izan arren. Konsole azkarra zen, baina delikatua zen batzuetan: pantaila izoztu egiten zen noizean behin, testu partziala erakutsiz edo ez zuen batere erakusten. Beste terminal batzuek kateak argi erakusten zituzten, st, Alacritty eta rxvt barne.
Dickeyk azaldu duenez, errendimendu desberdintasunak terminal ezberdinetako korritze-bufferen diseinuari dagozkio. Bereziki, rxvt eta beste terminal batzuei "arau orokorrak ez betetzea" leporatzen die:
"Xterm ez bezala, rxvt ez zen saiatu eguneratze guztiak bistaratzen. Atzean geratzen bada, eguneratze batzuei uko egingo die harrapatzeko. Horrek eragin handiagoa izan zuen itxurazko korritze-abiaduran barne-memoriaren antolaketan baino. Eragozpen bat izan zen ASCII animazioa zehaztasun samarra zela".
Antzemandako xterm geldotasun hori konpontzeko, Dickeyk baliabidea erabiltzea proposatzen du , xtermek pantailaren eguneratze batzuk baztertzeko aukera emanez, fluxuarekin jarraitzeko. Nire probek baieztatzen dute fastScroll-ek errendimendua hobetzen duela eta xterm rxvt-en parean jartzen duela. Hau, ordea, makulu zakarra da, Dickeyk berak azaldu duenez: "batzuetan xterm - konsole bezala - gelditzen dela dirudi, batzuk kendu ondoren pantaila-eguneratze-multzo berri baten zain dagoela". Ildo horretatik, badirudi beste terminal batzuek abiaduraren eta pantailaren osotasunaren arteko konpromisorik onena aurkitu dutela.
Baliabideen kontsumoa
Mugimendu-abiadura errendimendu-neurri gisa kontuan hartzea zentzuzkoa den ala ez kontuan hartu gabe, proba honek terminalen karga simulatzeko aukera ematen digu, eta, aldi berean, beste parametro batzuk neurtzeko aukera ematen digu, hala nola memoria edo diskoaren erabilera. Neurri horiek zehaztutako proba eginez lortu dira sek Python prozesuen jarraipenaren pean. Kontagailuen datuak bildu zituen egiteko ru_maxrss, zenbatekoa ru_oblock и ru_blokeatu eta tenporizadore sinple bat.
Proba honetan, ST-k lehen postua hartzen du 8 MB-ko batez besteko memoria-kontsumo txikienarekin, eta hori ez da harritzekoa diseinuaren ideia nagusia sinpletasuna dela kontuan hartuta. mlterm, xterm eta rxvt-ek apur bat gehiago kontsumitzen dute - 12 MB inguru. Beste emaitza aipagarri bat Alacritty da, exekutatzeko 30 MB behar dituena. Gero, VTE familiako terminalak daude 40 eta 60 MB bitarteko zifrak, hau da, asko. Kontsumo hori terminal hauek goi-mailako liburutegiak erabiltzen dituztelako azal daiteke, adibidez, GTK. Konsole-k 65 MB-ko memoria-kontsumo izugarria du azkena probetan, nahiz eta hori bere ezaugarri sorta zabalagatik justifika daitekeen.
Duela hamar urte lortutako aurreko emaitzekin alderatuta, programa guztiak memoria nabarmen gehiago kontsumitzen hasi ziren. Xterm-ek 4 MB behar zituen, baina orain 15 MB behar ditu abiaraztean. rxvt-en kontsumoaren antzeko igoera dago, orain 16 MB behar ditu kutxatik kanpo. Xfce Terminalak 34 MB hartzen ditu, hau da, lehen baino hiru aldiz handiagoa, baina GNOME Terminalek 20 MB baino ez ditu behar. Jakina, aurreko proba guztiak 32 biteko arkitekturan egin ziren. LCA 2012 Rusty Russell-en , memoria-kontsumoaren igoera azal dezaketen arrazoi sotilagoak daudela. Hori esanda, gigabyte memoria ditugun garai batean bizi gara, beraz, nolabait kudeatuko dugu.
Hala ere, ezin dut saihestu terminala bezain oinarrizkoa den zerbaiti memoria gehiago esleitzea baliabideak xahutzea dela. Programa hauek txikienetatik txikienak izan behar dute, edozein "kutxatan" exekutatu ahal izan behar dute, baita zapata-kutxa batean ere, inoiz Linux sistemaz hornitu behar diren puntura iristen bagara (eta badakizu hala izango dela). ) . Baina zenbaki hauekin, memoriaren erabilera arazo bihurtuko da etorkizunean hainbat terminal exekutatzen dituzten inguruneetan, gaitasun arinen eta mugatuenetako batzuk ez ezik. Hori konpentsatzeko, GNOME Terminalek, Konsolek, urxvt-ek, Terminator-ek eta Xfce Terminalek Daemon modua dute, prozesu bakar baten bidez hainbat terminal kontrolatzeko aukera ematen duena, haien memoria-kontsumoa mugatuz.
Nire probetan, ustekabeko beste emaitza batera iritsi nintzen diskoaren irakurketa-idazketari dagokionez: hemen ezer ez ikustea espero nuen, baina konturatu zen terminal batzuek datu bolumentsuenak diskoan idazten dituztela. Beraz, VTE liburutegiak korritze-buffer bat gordetzen du diskoan (eginbide hau , eta oraindik gertatzen ari da). Baina inplementazio zaharragoak ez bezala, orain gutxienez datu hauek AES256 GCM erabiliz enkriptatzen dira (). Baina arrazoizko galdera bat sortzen da: zer den VTE liburutegiak hain berezia ezartzeko ikuspegi ez-estandar bat behar duela...
Ondorioa
Artikuluaren lehen zatian, VTEn oinarritutako terminalek funtzio multzo ona dutela ikusi dugu, baina orain ikusten dugu horrek errendimendu kostu batzuk dakartzala. Orain memoria ez da arazo bat, VTE terminal guztiak Daemon prozesu baten bidez kontrolatu daitezkeelako, eta horrek gosea mugatzen du. Hala ere, RAM eta nukleoen buffer kopuruan muga fisikoak dituzten sistema zaharrek baliteke terminalen aurreko bertsioak behar izatea, baliabide askoz gutxiago kontsumitzen baitute. VTE terminalek errendimenduko (korritze) probetan ondo funtzionatu zuten arren, haien bistaratzeko latentzia GNOMEren Erabiltzailearen Gidan ezarritako atalasearen gainetik dago. VTE garatzaileek ziurrenik hori kontuan hartu beharko lukete. Kontuan hartzen badugu Linux erabiltzaile hasiberrientzat ere terminal batekin topo egitea saihestezina dela, erabilerrazagoa izan daitekeela. Esperientziadun geekentzat, lehenetsitako terminaletik aldatzeak begien neke gutxiago izatea eta lan saio luzeen ondorioz etorkizuneko lan-lesioak eta gaixotasunak saihesteko gaitasuna ere ekar dezake. Zoritxarrez, xterm eta mlterm zaharrak soilik 10 milisegundoko ping magikora eramaten gaituzte, askorentzat onartezina dena.
Erreferentziazko neurketek ere erakutsi zuten Linux ingurune grafikoen garapenaren ondorioz, garatzaileek hainbat konpromiso egin behar izan dituztela. Baliteke erabiltzaile batzuek leiho kudeatzaile arruntei begiratu nahi izatea, ping murrizketa nabarmena ematen baitute. Zoritxarrez, ezin izan da Wayland-en latentzia neurtu: erabili dudan Typometer programa Wayland-ek saihesteko diseinatuta dagoenerako sortu da: beste leihoak zelatatzeko. Espero dut Wayland-en konposizioak X.org-ek baino errendimendu hobea izatea, eta etorkizunean norbaitek ingurune honetan latentzia neurtzeko modua aurkitzea ere espero dut.
Iturria: www.habr.com