Maneno machache kutoka kwa ofisi yetu ya utafsiri: kwa kawaida kila mtu hujitahidi kutafsiri nyenzo na machapisho ya hivi punde, na sisi pia si tofauti. Lakini vituo sio kitu ambacho kinasasishwa mara moja kwa wiki. Kwa hivyo, tumekutafsiria nakala ya Antoine Beaupré, iliyochapishwa katika chemchemi ya 2018: licha ya "umri" wake mkubwa na viwango vya kisasa, kwa maoni yetu, nyenzo hiyo haijapoteza umuhimu wake hata kidogo. Kwa kuongeza, hii ilikuwa awali mfululizo wa makala mbili, lakini tuliamua kuchanganya kwenye chapisho moja kubwa.
Vituo vina nafasi maalum katika historia ya kompyuta, lakini katika miongo ya hivi karibuni vimelazimika kuishi kando ya safu ya amri kwani violesura vya picha vinakuwa kila mahali. badala yao , ambayo, kwa upande wake, ilikuwa marekebisho ya mifumo kulingana na kadi zilizopigwa na swichi za kugeuza. Usambazaji wa kisasa huja na emulators anuwai za maumbo na rangi zote. Na ingawa wengi wameridhika na terminal ya kawaida iliyotolewa na mazingira yao ya kazi, wengine hutumia programu ya kigeni kuendesha ganda au kihariri cha maandishi wanachopenda. Lakini, kama tutakavyoona kutoka kwa kifungu hiki, sio vituo vyote vilivyoundwa kwa picha sawa: vinatofautiana sana katika utendaji, saizi na utendaji.
Baadhi ya vituo vina mashimo ya usalama ya kustaajabisha, pamoja na mengi yana seti tofauti kabisa ya vitendakazi, kutoka kwa usaidizi wa kiolesura chenye kichupo hadi uandishi. Ingawa sisi , makala haya ni sasisho la nyenzo za awali ambazo zitasaidia wasomaji kuamua ni terminal gani ya kutumia mwaka wa 2018. Nusu ya kwanza ya makala inalinganisha vipengele, na nusu ya pili inatathmini utendaji.
Hapa kuna vituo nilivyokagua:
Hizi haziwezi kuwa matoleo ya hivi karibuni, kwa kuwa nilikuwa mdogo kwa kujenga imara wakati wa kuandika, ambayo niliweza kusambaza kwenye Debian 9 au Fedora 27. Mbali pekee ni Alacritty. Ni kizazi cha vituo vya kasi vya GPU na imeandikwa kwa lugha isiyo ya kawaida na mpya kwa kazi hii - Rust. Nilitenga vituo vya wavuti kutoka kwa ukaguzi wangu (pamoja na wale walio kwenye ), kwa sababu majaribio ya awali yalionyesha utendaji wao duni sana.
Msaada wa Unicode
Nilianza majaribio yangu kwa usaidizi wa Unicode. Jaribio la kwanza la vituo lilikuwa ni kuonyesha mfuatano wa Unicode kutoka : “é, Δ, И, ק, م, ๗, あ, 叶, 葉 na 말.” Jaribio hili rahisi linaonyesha kama terminal inaweza kufanya kazi ipasavyo duniani kote. terminal ya xterm haionyeshi herufi za Kiarabu katika usanidi chaguo-msingi:
Kwa msingi, xterm hutumia fonti ya "fasta", ambayo, kulingana na , ina "chanjo kubwa ya Unicode tangu 1997". Kuna kitu kinaendelea kwenye fonti hii ambayo husababisha mhusika kuonekana kama fremu tupu na ni wakati fonti ya maandishi inapoongezwa hadi alama 20+ ndipo mhusika hatimaye huanza kuonyesha ipasavyo. Walakini, "rekebisha" hii inavunja onyesho la herufi zingine za Unicode:
Picha hizi za skrini zilipigwa katika Fedora 27, kwani ilitoa matokeo bora kuliko Debian 9, ambapo matoleo mengine ya zamani ya vituo (haswa mlterm) hayakuweza kushughulikia fonti ipasavyo. Kwa bahati nzuri hii ilirekebishwa katika matoleo ya baadaye.
Sasa angalia jinsi mstari unaonyeshwa katika xterm. Inabadilika kuwa ishara Mem na Semitic ifuatayo rejelea maandishi ya mtindo wa RTL (), kwa hivyo kitaalam zinapaswa kuonyeshwa kutoka kulia kwenda kushoto. Vivinjari vya wavuti kama vile Firefox 57 hushughulikia mstari hapo juu kwa usahihi. Toleo rahisi zaidi la maandishi ya RTL ni neno ""kwa Kiebrania (). anasema yafuatayo:
"Programu nyingi za kompyuta haziwezi kuonyesha maandishi ya pande mbili kwa usahihi. Kwa mfano, jina la Kiebrania "Sarah" linajumuisha herufi sin (ש) (ambayo inaonekana upande wa kulia), kisha resh (ר) na hatimaye yeye (ה) (ambayo inapaswa kuonekana upande wa kushoto)."
Vituo vingi hufeli jaribio hili: Vituo vya Gnome na XFCE vinavyotokana na Alacritty, VTE, urxvt, st na xterm onyesho la "Sara" kwa mpangilio wa kinyume, kana kwamba tumeandika jina kama "Aras".
Tatizo jingine la maandishi yanayoelekeza pande mbili ni kwamba yanahitaji kuunganishwa kwa namna fulani, hasa linapokuja suala la kuchanganya maandishi ya RTL na LTR. Hati za RTL zinapaswa kuendeshwa kutoka upande wa kulia wa dirisha la terminal, lakini ni nini kinapaswa kutokea kwa vituo ambavyo chaguomsingi vya LTR English? Wengi wao hawana mifumo maalum na panga maandishi yote kushoto (pamoja na Konsole). Vighairi ni pterm na mlterm, ambazo hufuata viwango na kusawazisha mistari kama hiyo.
Ulinzi wa kuingizwa
Kipengele muhimu kinachofuata ambacho nimetambua ni ulinzi dhidi ya kuingizwa. Ingawa inajulikana sana kwamba inaelezea kama:
$ curl http://example.com/ | shni amri za kushinikiza za utekelezaji wa nambari, watu wachache wanajua kuwa amri zilizofichwa zinaweza kuingia kwenye koni wakati wa kunakili na kubandika kutoka kwa kivinjari cha wavuti, hata baada ya ukaguzi wa uangalifu. inaonyesha kwa uzuri jinsi amri ilivyo isiyo na hatia:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitinageuka kuwa kero kama hiyo inapobandikwa kutoka kwa tovuti ya Horn hadi kwenye terminal:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust!
Here'"'"'s the first line of your /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitInavyofanya kazi? Msimbo hasidi umejumuishwa kwenye kizuizi , ambayo hutolewa nje ya mwonekano wa mtumiaji kwa kutumia CSS.
ni wazi iliyoundwa na neutralize mashambulizi hayo. Katika hali hii, vituo huambatanisha maandishi yaliyobandikwa katika jozi ya mifuatano maalum ya kutoroka ili kueleza ganda kuhusu asili ya maandishi. Hii inaambia ganda kwamba inaweza kupuuza herufi maalum ambazo maandishi yaliyobandikwa yanaweza kuwa nayo. Vituo vyote vilivyorudi kwenye xterm inayoheshimika vinaauni kipengele hiki, lakini kubandika katika hali ya Mabano kunahitaji usaidizi kutoka kwa ganda au programu inayoendesha kwenye terminal. Kwa mfano, kutumia programu (Bash sawa), inahitaji faili ~/.inputrc:
set enable-bracketed-paste onKwa bahati mbaya, tovuti ya majaribio ya Horn pia inaonyesha jinsi ya kukwepa ulinzi huu kupitia uumbizaji wa maandishi yenyewe na kabla ya wakati wake kuishia kutumia Hali ya Mabano kwake. Hii inafanya kazi kwa sababu vituo vingine havichuji kwa usahihi mpangilio wa kutoroka kabla ya kuongeza vyao. Kwa mfano, katika mgodi sikuwahi kufanikiwa kukamilisha majaribio ya Konsole hata kwa usanidi sahihi .inputrc faili. Hii ina maana kwamba unaweza kupata usanidi wa mfumo wako kwa urahisi kutokana na programu isiyotumika au shell iliyosanidiwa vibaya. Hii ni hatari sana wakati wa kuingia kwenye seva za mbali, ambapo kazi ya usanidi wa uangalifu sio kawaida, haswa ikiwa una mashine nyingi za mbali.
Suluhisho nzuri kwa shida hii ni programu-jalizi ya uthibitishaji wa terminal urxvt, ambayo inauliza tu ruhusa ya kuingiza maandishi yoyote ambayo yana laini mpya. Sijapata chaguo salama zaidi kwa shambulio la maandishi lililoelezewa na Pembe.
Vichupo na wasifu
Kipengele maarufu sasa ni usaidizi wa kiolesura chenye kichupo, ambacho tutakifafanua kama kidirisha kimoja cha wastaafu kilicho na vituo kadhaa zaidi. Chaguo hili la kukokotoa hutofautiana kwa vituo tofauti, na ingawa vituo vya kawaida vya xterm havitumii vichupo hata kidogo, uimbaji wa kisasa zaidi wa wastaafu kama vile Kituo cha Xfce, Kituo cha GNOME na Konsole vina utendakazi huu. Urxvt pia inasaidia vichupo, lakini tu ikiwa unatumia programu-jalizi. Lakini kwa upande wa usaidizi wa kichupo yenyewe, Terminator ndiye kiongozi asiye na shaka: sio tu inasaidia tabo, lakini pia inaweza kupanga vituo kwa mpangilio wowote (tazama picha hapa chini).
Kipengele kingine cha Terminator ni uwezo wa "kuweka pamoja" vichupo hivi pamoja na kutuma vibonye vitufe sawa kwa vituo vingi kwa wakati mmoja, kutoa zana ghafi ya kufanya shughuli nyingi kwenye seva nyingi kwa wakati mmoja. Kipengele sawa pia kinatekelezwa katika Konsole. Ili kutumia kipengele hiki katika vituo vingine, lazima utumie programu ya wahusika wengine kama vile , au .
Vichupo hufanya kazi vizuri sana wakati vimeunganishwa na wasifu: kwa mfano, unaweza kuwa na kichupo kimoja cha barua pepe, kingine cha gumzo, na kadhalika. Hii inaungwa mkono vyema na Kituo cha Konsole na Kituo cha GNOME. Zote mbili huruhusu kila kichupo kuzindua kiotomati wasifu wake. Terminator pia inasaidia wasifu, lakini sikuweza kupata njia ya kuzindua kiotomatiki programu fulani unapofungua kichupo maalum. Vituo vingine havina dhana ya "wasifu" hata kidogo.
Ruffles
Kitu cha mwisho nitakachofunika katika sehemu ya kwanza ya makala hii ni kuonekana kwa vituo. Kwa mfano GNOME, Xfce na urxvt inasaidia uwazi, lakini hivi majuzi zimepunguza usaidizi wa picha za mandharinyuma, na kulazimisha watumiaji wengine kubadili kwenye terminal. . Binafsi, nimefurahishwa nayo na ni rahisi Vyanzo, ambayo huweka msingi wa rangi za mandharinyuma kwa urxvt. Hata hivyo, mandhari zisizo za kawaida za rangi pia zinaweza kuunda matatizo. Kwa mfano, na maombi и , kwa kuwa tayari hutumia rangi zao wenyewe.
haikuunga mkono rangi, na mpya mara nyingi zilipunguzwa kwa palette ya rangi 256. Kwa watumiaji wa hali ya juu wanaotengeneza vituo vyao, vidokezo vya shell au upau wa hali kwa njia changamano inaweza kuwa kizuizi cha kuudhi. nyimbo ambazo vituo vina usaidizi wa "Rangi ya Kweli". Majaribio yangu yanathibitisha kuwa vituo vya st, Alacritty na VTE vinaunga mkono Rangi ya Kweli kikamilifu. Vituo vingine havifanyiki vizuri katika suala hili na, kwa kweli, havionyeshi hata rangi 256. Hapo chini unaweza kuona tofauti kati ya usaidizi wa Rangi ya Kweli katika vituo vya GNOME, st na xterm, ambavyo hufanya kazi nzuri ya hii na paji lao la rangi 256, na urxvt, ambayo sio tu inafeli jaribio, lakini hata inaonyesha herufi zingine zinazopepesa badala yao.
Baadhi ya vituo pia huchanganua maandishi kwa ruwaza za URL ili kufanya viungo kubofya. Hii inatumika kwa vituo vyote vinavyotokana na VTE, ilhali urxvt inahitaji programu-jalizi maalum ambayo inaweza kubadilisha URL kwa kubofya au kutumia njia ya mkato ya kibodi. Vituo vingine nimejaribu URL za kuonyesha kwa njia zingine.
Hatimaye, mwelekeo mpya katika vituo ni chaguo la bafa ya kusogeza. Kwa mfano, st haina bafa ya kusogeza; inadhaniwa kuwa mtumiaji atatumia kiboreshaji cha terminal kama tmux na .
Alacritty pia haina bafa za kurudisha nyuma, lakini msaada wake kutokana na "maoni ya kina" juu ya mada hii kutoka kwa watumiaji. Kando na hizi za juu, kila terminal ambayo nimejaribu ambayo ningeweza kupata inasaidia kusonga nyuma.
Jumla ndogo
Katika sehemu ya pili ya nyenzo (katika asili hizi zilikuwa nakala mbili tofauti - takriban. njia) tutalinganisha utendaji, utumiaji wa kumbukumbu na ucheleweshaji. Lakini tunaweza kuona kwamba baadhi ya vituo vinavyohusika vina mapungufu makubwa. Kwa mfano, watumiaji wanaofanya kazi mara kwa mara na hati za RTL wanaweza kutaka kuzingatia mlterm na pterm, kwa kuwa wao ni bora katika kushughulikia kazi zinazofanana kuliko zingine. Konsole pia ilifanya vizuri. Watumiaji ambao hawafanyi kazi na hati za RTL wanaweza kuchagua kitu kingine.
Kwa upande wa ulinzi dhidi ya kuingizwa kwa msimbo hasidi, urxvt inajitokeza kwa sababu ya utekelezaji wake maalum wa ulinzi dhidi ya aina hii ya shambulio, ambayo inaonekana kwangu kuwa rahisi kwangu. Kwa wale wanaotafuta kengele na filimbi, Konsole inafaa kutazamwa. Hatimaye, ni muhimu kuzingatia kwamba VTE ni msingi bora wa vituo, ambayo inahakikisha usaidizi wa rangi, utambuzi wa URL, na kadhalika. Kwa mtazamo wa kwanza, terminal chaguo-msingi inayokuja na mazingira unayopenda inaweza kukidhi mahitaji yote, lakini hebu tuliache swali hili wazi hadi tuelewe utendakazi.
Tuendelee na mazungumzo
Kwa ujumla, utendakazi wa vituo vyenyewe unaweza kuonekana kama tatizo lisiloeleweka, lakini inavyotokea, baadhi yao huonyesha utulivu wa hali ya juu wa programu ya aina hiyo ya msingi. Pia ijayo tutaangalia kile kinachojulikana kama "kasi" (kwa kweli, hii ni kasi ya kusogeza) na utumiaji wa kumbukumbu ya terminal (pamoja na pango kwamba hii sio muhimu leo kama ilivyokuwa miongo kadhaa iliyopita).
Kuchelewa
Baada ya utafiti wa kina wa utendaji wa terminal, nilifikia hitimisho kwamba parameter muhimu zaidi katika suala hili ni latency (ping). Katika makala yake Pavel Fatin aliangalia muda wa kusubiri wa wahariri mbalimbali wa maandishi na akadokeza kwamba vituo katika suala hili vinaweza kuwa polepole zaidi kuliko vihariri vya maandishi vya haraka zaidi. Ilikuwa wazo hili ambalo hatimaye liliniongoza kufanya majaribio yangu mwenyewe na kuandika nakala hii.
Lakini latency ni nini, na kwa nini ni muhimu sana? Katika makala yake, Fatin alifafanua kuwa “kuchelewa kati ya kubonyeza kitufe na kusasisha skrini inayolingana” na kunukuliwa. , ambayo inasema: “Kuchelewa kwa maoni yanayoonekana kwenye skrini ya kompyuta kunaathiri sana tabia na uradhi wa wachapaji.”
Fatin anaeleza kwamba ping hii ina matokeo makubwa zaidi kuliko kuridhika tu: “kuandika kunakuwa polepole, makosa mengi hutokea, na mkazo wa macho na misuli huongezeka.” Kwa maneno mengine, ucheleweshaji mkubwa unaweza kusababisha typos na pia ubora wa chini wa msimbo, kwani husababisha mzigo wa ziada wa utambuzi kwenye ubongo. Lakini mbaya zaidi ni kwamba ping "huongeza mkazo wa macho na misuli," ambayo inaonekana kumaanisha katika siku zijazo (Inaonekana, mwandishi anamaanisha matatizo na misuli ya macho, nyuma, mikono na, bila shaka, maono - takriban. njia) kutokana na mkazo unaojirudia.
Baadhi ya athari hizi zimejulikana kwa muda mrefu, na matokeo yake , iliyochapishwa nyuma mwaka wa 1976 katika jarida la Ergonomics, ilisema kuwa kuchelewa kwa milliseconds 100 "huharibu kwa kiasi kikubwa kasi ya kuandika." Hivi majuzi, Mwongozo wa Mtumiaji wa GNOME ulianzishwa katika milliseconds 10, na ukienda zaidi, basi inaonyesha kuwa millisecond 1 ni bora.
Fatin alifanya majaribio yake kwa wahariri wa maandishi; aliunda chombo cha kubebeka kinachoitwa , ambayo nilitumia kujaribu ping katika emulators za wastaafu. Kumbuka kwamba jaribio lilifanyika katika hali ya kuiga: kwa kweli, tunahitaji kuzingatia pembejeo zote mbili (kibodi, kidhibiti cha USB, nk) na matokeo (bafa ya kadi ya video, kufuatilia) latency. Kulingana na Fatin, katika usanidi wa kawaida ni karibu 20 ms. Ikiwa una vifaa vya michezo ya kubahatisha, unaweza kufikia takwimu hii kwa milliseconds 3 tu. Kwa kuwa tayari tuna vifaa vya haraka sana, programu sio lazima iongeze muda wake wa kusubiri. Lengo la Fatin ni kuleta muda wa kusubiri wa programu hadi milisekunde 1, au hata kufikia upigaji bila kama ndani .
Haya hapa ni matokeo ya vipimo vyangu, pamoja na baadhi ya matokeo ya Fatin, kuonyesha kwamba majaribio yangu yanakubaliana na majaribio yake:
Jambo la kwanza ambalo lilinigusa ni wakati bora wa kujibu wa programu za zamani kama vile xterm na mlterm. Kwa latency mbaya zaidi ya rejista (2,4 ms), walifanya vizuri zaidi kuliko terminal ya kisasa ya haraka (10,6 ms kwa st). Hakuna terminal ya kisasa iliyo chini ya kizingiti cha milisekunde 10. Hasa, Alacritty inashindwa kukidhi dai la "emulator ya haraka zaidi inayopatikana", ingawa alama zake zimeboreshwa tangu ukaguzi wake wa kwanza mnamo 2017. Kwa kweli, waandishi wa mradi huo na wanafanya kazi ili kuboresha onyesho. Ikumbukwe pia kuwa Vim kutumia GTK3 ni agizo la ukubwa polepole kuliko mwenzake wa GTK2. Kutokana na hili tunaweza kuhitimisha kuwa GTK3 inaunda hali ya kusubiri ya ziada, na hii inaonekana katika vituo vingine vyote vinavyoitumia (Terminator, Xfce4 Terminal na GNOME Terminal).
Hata hivyo, tofauti hizo haziwezi kuonekana kwa jicho. Kama Fatin aelezavyo, “si lazima ujue kucheleweshwa ili kuwe na matokeo kwako.” Fatin pia anaonya kuhusu kupotoka kwa kawaida: "mvurugiko wowote wa muda wa kusubiri (jitter) hutokeza mkazo zaidi kwa sababu ya kutotabirika kwao."
Grafu hapo juu imechukuliwa kwenye Debian 9 safi (nyoosha) na . Mazingira haya hutoa matokeo bora katika majaribio ya latency. Kama inavyotokea, GNOME huunda ping ya ziada ya 20 ms kwa vipimo vyote. Ufafanuzi unaowezekana kwa hili ni uwepo wa programu na usindikaji wa synchronous wa matukio ya pembejeo. Fatin anatoa mfano kwa kesi kama hiyo , ambayo huongeza ucheleweshaji kwa kuchakata matukio yote ya ingizo kwa usawa. Kwa chaguo-msingi, GNOME pia inakuja na msimamizi wa dirisha , ambayo huunda safu ya ziada ya kuakibisha, ambayo huathiri ping na kuongeza angalau milisekunde 8 za muda.
Kasi ya kusogeza
Jaribio linalofuata ni jaribio la kawaida la "kasi" au "bandwidth", ambalo hupima jinsi terminal inavyoweza kusogeza ukurasa huku ikionyesha idadi kubwa ya maandishi kwenye skrini. Mechanics ya mtihani hutofautiana; jaribio la asili lilikuwa kutoa tu kamba ya maandishi sawa kwa kutumia seq amri. Majaribio mengine ni pamoja na mtihani wa Thomas E. Dickey (msimamizi wa xterm), ambao mara kwa mara . Katika mapitio mengine ya utendaji wa wastaafu hutumia mfuatano wa msingi32 uliosimbwa wa baiti nasibu, ambao hutolewa kwa terminal kwa kutumia paka. Luu anachukulia jaribio kama hilo kuwa "kigezo kisicho na maana kama mtu anavyoweza kufikiria" na anapendekeza kutumia majibu ya wastaafu kama kipimo cha msingi badala yake. Dickey pia anaita mtihani wake kuwa wa kupotosha. Walakini, waandishi wote wawili wanakubali kwamba bandwidth ya dirisha la terminal inaweza kuwa suala. Luu aligundua Emacs Eshell inagandisha wakati wa kuonyesha faili kubwa, na Dickey akaboresha terminal ili kuondoa uvivu wa kuona wa xtrerm. Kwa hivyo bado kuna sifa kwa jaribio hili, lakini kwa kuwa mchakato wa utoaji ni tofauti sana kutoka terminal hadi terminal, inaweza pia kutumika kama sehemu ya jaribio kujaribu vigezo vingine.
Hapa tunaona rxvt na st kuvuta mbele ya shindano, ikifuatiwa na Alacritty mpya zaidi, ambayo imeundwa kwa kuzingatia utendakazi. Inayofuata ni Xfce (familia ya VTE) na Konsole, ambayo ni karibu mara mbili zaidi. Mwisho ni xterm, ambayo ni polepole mara tano kuliko rxvt. Wakati wa jaribio, xterm pia ilisambaratika sana, na kufanya maandishi kuwa magumu kuona hata ikiwa ni laini sawa. Konsole ilikuwa na kasi, lakini ilikuwa ngumu wakati mwingine: onyesho lingeganda mara kwa mara, likionyesha sehemu ya maandishi au kutoionyesha kabisa. Vituo vingine vilionyesha mifuatano kwa uwazi, ikijumuisha st, Alacritty, na rxvt.
Dickey anaeleza kuwa tofauti za utendakazi zinatokana na muundo wa vibafa vya kusogeza katika vituo tofauti. Hasa, anashutumu rxvt na vituo vingine vya "kutofuata sheria za jumla":
"Tofauti na xterm, rxvt haikujaribu kuonyesha sasisho zote. Ikiwa itasalia nyuma, itakataa masasisho kadhaa kupatana. Hii ilikuwa na athari kubwa kwa kasi inayoonekana ya kusogeza kuliko kwenye shirika la kumbukumbu ya ndani. Kikwazo kimoja kilikuwa kwamba uhuishaji wa ASCII haukuwa sahihi kwa kiasi fulani."
Ili kurekebisha uvivu huu wa xterm, Dickey anapendekeza kutumia rasilimali , ikiruhusu xterm kutupa masasisho kadhaa ya skrini ili kuendana na mtiririko. Majaribio yangu yanathibitisha kuwa FastScroll inaboresha utendakazi na kuleta xterm sambamba na rxvt. Hii, hata hivyo, ni njia mbaya, kama Dickey mwenyewe anavyoeleza: "wakati mwingine xterm - kama konsole - inaonekana kukwama inaposubiri seti mpya ya masasisho ya skrini baada ya baadhi kuondolewa." Katika mshipa huu, inaonekana kwamba vituo vingine vimepata maelewano bora kati ya kasi na uadilifu wa kuonyesha.
Matumizi ya rasilimali
Bila kujali kama inaeleweka kuzingatia kasi ya kusogeza kama kipimo cha utendakazi, jaribio hili huturuhusu kuiga mzigo kwenye vituo, ambavyo huturuhusu kupima vigezo vingine kama vile kumbukumbu au matumizi ya diski. Vipimo vilipatikana kwa kufanya jaribio lililobainishwa seq chini ya ufuatiliaji wa mchakato wa Python. Alikusanya data za mita kwa ru_maxrss, kiasi ru_oublock и ru_inblock na kipima muda rahisi.
Katika jaribio hili, ST inachukua nafasi ya kwanza na wastani wa chini wa matumizi ya kumbukumbu ya 8 MB, ambayo haishangazi kwa kuzingatia kuwa wazo kuu la muundo ni unyenyekevu. mlterm, xterm na rxvt hutumia zaidi kidogo - takriban 12 MB. Matokeo mengine mashuhuri ni Alacritty, ambayo inahitaji MB 30 kukimbia. Halafu kuna vituo vya familia ya VTE na takwimu kutoka 40 hadi 60 MB, ambayo ni mengi sana. Matumizi haya yanaweza kuelezewa na ukweli kwamba vituo hivi vinatumia maktaba ya kiwango cha juu, kwa mfano, GTK. Konsole inakuja mwisho ikiwa na matumizi makubwa ya kumbukumbu ya MB 65 wakati wa majaribio, ingawa hii inaweza kuthibitishwa na anuwai ya vipengele.
Ikilinganishwa na matokeo ya awali yaliyopatikana miaka kumi iliyopita, programu zote zilianza kutumia kumbukumbu zaidi. Xterm ilikuwa ikihitaji MB 4, lakini sasa inahitaji MB 15 mwanzoni tu. Kuna ongezeko sawa la matumizi ya rxvt, ambayo sasa inahitaji MB 16 nje ya boksi. Kituo cha Xfce kinachukua hadi MB 34, ambayo ni kubwa mara tatu kuliko hapo awali, lakini Kituo cha GNOME kinahitaji MB 20 pekee. Kwa kweli, majaribio yote ya hapo awali yalifanywa kwenye usanifu wa 32-bit. Katika LCA 2012 Rusty Russell , kwamba kuna sababu nyingi zaidi za hila ambazo zinaweza kuelezea ongezeko la matumizi ya kumbukumbu. Baada ya kusema hivyo, sasa tunaishi katika wakati ambapo tuna kumbukumbu ya gigabytes, kwa hivyo tutasimamia kwa namna fulani.
Walakini, siwezi kusaidia lakini kuhisi kuwa kugawa kumbukumbu zaidi kwa kitu cha msingi kama terminal ni upotezaji wa rasilimali. Programu hizi zinapaswa kuwa ndogo zaidi ya ndogo zaidi, zinapaswa kuwa na uwezo wa kukimbia kwenye "sanduku" lolote, hata sanduku la viatu, ikiwa tutafikia mahali ambapo wanahitaji kuwa na mifumo ya Linux (na unajua kuwa itakuwa hivyo. ). Lakini kwa nambari hizi, utumiaji wa kumbukumbu utakuwa suala katika siku zijazo katika mazingira yoyote yanayoendesha vituo vingi isipokuwa chache cha uwezo mdogo na mdogo zaidi. Ili kufidia hili, Kituo cha GNOME, Konsole, urxvt, Terminator na Kituo cha Xfce kina modi ya Daemon inayokuruhusu kudhibiti vituo vingi kupitia mchakato mmoja, na kupunguza matumizi yao ya kumbukumbu.
Wakati wa majaribio yangu, nilikuja kwa matokeo mengine yasiyotarajiwa kuhusu diski kusoma-kuandika: Nilitarajia kuona chochote hapa, lakini ikawa kwamba vituo vingine huandika data kubwa zaidi kwa diski. Kwa hivyo, maktaba ya VTE kwa kweli huweka bafa ya kusogeza kwenye diski (kipengele hiki , na hii bado inafanyika). Lakini tofauti na utekelezaji wa zamani, sasa angalau data hii imesimbwa kwa kutumia AES256 GCM () Lakini swali linalofaa linatokea: ni nini maalum kuhusu maktaba ya VTE ambayo inahitaji mbinu isiyo ya kawaida ya utekelezaji ...
Hitimisho
Katika sehemu ya kwanza ya makala, tuligundua kwamba vituo vya VTE vina seti nzuri ya vipengele, lakini sasa tunaona kwamba hii inakuja na gharama fulani za utendaji. Sasa kumbukumbu sio suala kwa sababu vituo vyote vya VTE vinaweza kudhibitiwa kupitia mchakato wa Daemon, ambao unapunguza hamu yao ya kula. Hata hivyo, mifumo ya zamani ambayo ina vikwazo vya kimwili juu ya kiasi cha RAM na buffers ya kernel bado inaweza kuhitaji matoleo ya awali ya vituo, kwa kuwa hutumia rasilimali chache sana. Ingawa vituo vya VTE vilifanya vyema katika majaribio ya upitishaji (kusogeza), muda wa onyesho lao uko juu ya kiwango kilichowekwa kwenye Mwongozo wa Mtumiaji wa GNOME. Wasanidi wa VTE labda wanapaswa kuzingatia hili. Ikiwa tutazingatia kwamba hata kwa watumiaji wa novice wa Linux wanaokutana na terminal ni lazima, wanaweza kuifanya iwe ya kirafiki zaidi. Kwa majahili wenye uzoefu, kubadili kutoka kwa terminal chaguo-msingi kunaweza hata kumaanisha kupunguza matatizo ya macho na uwezo wa kuepuka majeraha na magonjwa yanayohusiana na kazi siku zijazo kutokana na vipindi virefu vya kazi. Kwa bahati mbaya, ni xterm ya zamani na mlterm hutuleta kwenye kizingiti cha uchawi cha milliseconds 10, ambayo haikubaliki kwa wengi.
Vipimo vya kulinganisha pia vilionyesha kuwa kwa sababu ya ukuzaji wa mazingira ya picha ya Linux, watengenezaji walilazimika kufanya maafikiano kadhaa. Watumiaji wengine wanaweza kutaka kuangalia wasimamizi wa kawaida wa dirisha kwani wanatoa upunguzaji mkubwa wa ping. Kwa bahati mbaya, haikuwezekana kupima muda wa kusubiri kwa Wayland: programu ya Typometer niliyotumia iliundwa kwa kile ambacho Wayland imeundwa kuzuia: kupeleleza kwenye madirisha mengine. Natumai kuwa utunzi wa Wayland utafanya vyema zaidi kuliko X.org, na pia ninatumai kuwa katika siku zijazo mtu atapata njia ya kupima muda katika mazingira haya.
Chanzo: mapenzi.com