Биздин котормо бюробуздан бир нече сөз: адатта ар бир адам акыркы материалдарды жана басылмаларды которууга умтулат, биз да четте калбайбыз. Бирок терминалдар жумасына бир жолу жаңыла турган нерсе эмес. Ошондуктан, биз сиздер үчүн 2018-жылдын жазында жарык көргөн Антуан Бопринин макаласын котордук: заманбап стандарттар боюнча бир топ "жашына" карабастан, биздин оюбузча, материал актуалдуулугун такыр жогото элек. Кошумчалай кетсек, бул башында эки макаланын сериясы болчу, бирок биз аларды бир чоң постко бириктирүүнү чечтик.
Терминалдар компьютердик тарыхта өзгөчө орунду ээлейт, бирок акыркы он жылдыктарда графикалык интерфейстер бардык жерде колдонула баштагандыктан, алар командалык сап менен бирге аман калууга аргасыз болушту. өз алдынча алмаштырды , бул, өз кезегинде, перфокарталарга жана которгучтарга негизделген системалардын модификациясы болгон. Заманбап дистрибуциялар ар кандай формадагы жана түстөгү терминалдык эмуляторлор менен келет. Көптөр иштөө чөйрөсү тарабынан берилген стандарттык терминалга ыраазы болсо да, кээ бирлери сүйүктүү кабыкчасын же текст редакторун иштетүү үчүн экзотикалык программалык камсыздоону сыймыктануу менен колдонушат. Бирок, биз бул макаладан көрө тургандай, бардык терминалдар бир эле сүрөттө түзүлгөн эмес: алар иш, көлөмү жана аткаруу боюнча абдан айырмаланат.
Кээ бир терминалдарда таң калыштуу коопсуздук тешиктери бар, ошондой эле алардын көпчүлүгүндө таблицалуу интерфейсти колдоодон скриптке чейин такыр башка функциялар бар. Биз болсо да , бул макала окурмандарга 2018-жылы кайсы терминалды колдонууну аныктоого жардам бере турган мурунку материалдын жаңыртылышы. Макаланын биринчи жарымында өзгөчөлүктөр салыштырылат, ал эми экинчи жарымында аткаруу бааланат.
Бул жерде мен карап чыккан терминалдар:
Бул акыркы версиялар болушу мүмкүн эмес, анткени мен жазуу учурунда мен Debian 9 же Fedora 27де чыгара алган туруктуу түзүүлөр менен чектелгем. Бир гана Alacritty өзгөчөлүгү. Бул GPU-тездетилген терминалдардын тукуму жана бул тапшырма үчүн адаттан тыш жана жаңы тилде жазылган - Rust. Мен веб-терминалдарды кароодон чыгарып салдым (анын ичинде ), анткени алгачкы сыноолор алардын өтө начар көрсөткүчтөрүн көрсөттү.
Юникод колдоо
Мен тесттеримди Юникод колдоосу менен баштадым. Терминалдардын биринчи сыноосу Юникод сапты көрсөтүү болгон : “é, Δ, И, ק, م, ๗, あ, 叶, 葉 жана 말.” Бул жөнөкөй тест терминал дүйнө жүзү боюнча туура иштей алаарын көрсөтөт. xterm терминалы араб тамгасын көрсөтпөйт демейки конфигурацияда:
Демейки боюнча, xterm классикалык "туруктуу" шрифти колдонот, ага ылайык , "1997-жылдан бери олуттуу Юникод камтууга ээ". Бул шрифтте символдун бош алкак катары пайда болушуна алып келген бир нерсе болуп жатат жана тексттин шрифти 20+ упайга чейин көбөйтүлгөндө гана каарман акыры туура көрсөтө баштайт. Бирок, бул "оңдоо" башка Юникод белгилеринин дисплейин бузат:
Бул скриншоттор Fedora 27де тартылган, анткени ал Debian 9га караганда жакшыраак натыйжаларды берген, мында терминалдардын кээ бир эски версиялары (айрыкча mlterm) шрифттерди туура иштете алган эмес. Бактыга жараша, бул кийинки версияларда чечилген.
Эми сызык xtermде кандайча көрсөтүлгөнүнө көңүл буруңуз. Көрсө, символ Мем жана кийинки семит RTL стилиндеги скрипттерге кайрылыңыз (), ошондуктан техникалык жактан алар оңдон солго көрсөтүлүшү керек. Firefox 57 сыяктуу веб-браузерлер жогорудагы сапты туура иштетет. RTL текстинин жөнөкөй версиясы - бул ""еврейче (). мындай дейт:
«Көптөгөн компьютердик программалар эки багыттуу текстти туура көрсөтө албайт. Мисалы, "Сара" деген еврей аталышы sin (ש) (оң жакта көрүнөт), андан кийин resh (ר) жана акырында ал (ה) (сол жакта болушу керек) символдорунан турат."
Көптөгөн терминалдар бул сыноодон өтпөй калышат: Alacritty, VTEден алынган Gnome жана XFCE терминалдары, urxvt, st жана xterm дисплейлери "Sara" деген тескери тартипте, биз атын "Арас" деп жазгандай.
Эки багыттуу тексттердин дагы бир көйгөйү, алар RTL жана LTR тексттерин аралаштырууга келгенде, кандайдыр бир жол менен тегизделиши керек. RTL скрипттери терминалдын терезесинин оң жагынан иштеши керек, бирок LTR English демейки терминалдарда эмне болушу керек? Алардын көпчүлүгүнүн атайын механизмдери жок жана бардык текстти солго тегиздөө (анын ичинде Консолдо). Стандарттарды кармануучу жана мындай сызыктарды оң жагына тегиздөөчү pterm жана mlterm өзгөчөлүктөр болуп саналат.
Киргизүүнү коргоо
Мен аныктаган кийинки маанилүү өзгөчөлүк - бул киргизүүгө каршы коргоо. Бул кеңири белгилүү болгонуна карабастан, мындай дубалар:
$ curl http://example.com/ | shБул коддун аткарылышын түртүү буйруктары болсо, кылдат текшерүүдөн кийин да веб-браузерден көчүрүп жана чаптап жатканда жашыруун буйруктар консолго кирип кетиши мүмкүн экенин аз адамдар билет. буйруктун канчалык зыянсыз экенин эң сонун көрсөтөт:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitХорндун веб-сайтынан терминалга чапталганда мындай кыйынчылыкка айланат:
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 аркылуу колдонуучунун көрүнүшүнөн жылдырылат.
мындай чабуулдарды зыянсыздандыруу үчүн ачык-айкын иштелип чыккан. Бул режимде терминалдар тексттин келип чыгышы жөнүндө кабыкчага айтып берүү үчүн чапталган текстти атайын качуу ырааттуулугуна кошушат. Бул кабыкчага чапталган текст камтышы мүмкүн болгон атайын белгилерди этибарга албай турганын айтат. Урматтуу xterm'ге кайтып келген бардык терминалдар бул функцияны колдойт, бирок кашаа режиминде чаптоо терминалда иштеген кабыктан же тиркемеден колдоону талап кылат. Мисалы, программалык камсыздоону колдонуу (ошол эле Bash), файл керек ~/.inputrc:
set enable-bracketed-paste onТилекке каршы, Хорндун тесттик сайты бул коргоону текст форматынын өзү аркылуу кантип айланып өтүүнү жана ага кашаа режимин мөөнөтүнөн мурда колдонууну көрсөтөт. Бул кээ бир терминалдар өздөрүн кошуудан мурун качуу ырааттуулугун туура чыпкалабагандыктан иштейт. Мисалы, мен өзүмдүн конфигурациямда Konsole сыноолорун эч качан ийгиликтүү бүтүрө алган эмесмин .inputrc файл. Бул колдоого алынбаган тиркеме же туура эмес конфигурацияланган кабыктан улам системаңыздын конфигурациясын оңой эле бузуп алсаңыз болот дегенди билдирет. Бул өзгөчө алыскы серверлерге киргенде кооптуу, мында кылдат конфигурациялоо иштери азыраак кездешет, айрыкча, сизде мындай алыскы машиналар көп болсо.
Бул маселенин жакшы чечими терминал үчүн паста ырастоо плагини болуп саналат urxvt, бул жөн гана жаңы саптарды камтыган каалаган текстти киргизүүгө уруксат сурайт. Мен Horn сүрөттөгөн тексттик чабуул үчүн коопсуз вариантты тапкан жокмун.
Өтмөктөр жана профилдер
Популярдуу өзгөчөлүк - бул табулатура интерфейсин колдоо, аны биз дагы бир нече терминалдарды камтыган бир терминалдык терезе катары аныктайбыз. Бул функция ар кандай терминалдар үчүн айырмаланат жана салттуу xterm терминалдары өтмөктөрдү такыр колдоого албаса да, Xfce Terminal, GNOME Terminal жана Konsole сыяктуу заманбап терминалдарда бул функция бар. Urxvt да өтмөктөрдү колдойт, бирок сиз плагинди колдонсоңуз гана. Бирок өтмөктөрдү колдоо жагынан Терминатор талашсыз лидер: ал өтмөктөрдү гана колдобостон, терминалдарды каалаган тартипте жайгаштыра алат (төмөндөгү сүрөттү караңыз).
Терминатордун дагы бир өзгөчөлүгү - бул өтмөктөрдү чогуу "топтоо" жана бир эле баскычтарды бир эле учурда бир нече терминалга жөнөтүү, бир эле учурда бир нече серверлерде жапырт операцияларды аткаруу үчүн одоно куралды камсыз кылуу. Окшош өзгөчөлүк Konsole да ишке ашырылат. Бул мүмкүнчүлүктү башка терминалдарда колдонуу үчүн, сиз, мисалы, үчүнчү тараптын программаларын колдонушуңуз керек , же .
Өтмөктөр өзгөчө профилдер менен жупташканда жакшы иштейт: мисалы, сизде электрондук почта үчүн бир өтмөк, башкасы баарлашуу үчүн жана башкалар болушу мүмкүн. Бул Konsole Terminal жана GNOME Терминал тарабынан жакшы колдоого алынат. Экөө тең ар бир өтмөккө өзүнүн профилин автоматтык түрдө ишке киргизүүгө мүмкүндүк берет. Терминатор профилдерди да колдойт, бирок мен белгилүү бир өтмөктү ачканда белгилүү бир программаларды автоматтык түрдө ишке киргизүүнүн жолун таба алган жокмун. Башка терминалдарда “профиль” деген түшүнүк таптакыр жок.
Ruffles
Бул макаланын биринчи бөлүгүндө мен камтый турган акыркы нерсе - терминалдардын көрүнүшү. Мисалы, GNOME, Xfce жана urxvt ачык-айкындуулукту колдойт, бирок жакында фон сүрөттөрүн колдоону токтотуп, айрым колдонуучуларды терминалга өтүүгө мажбурлашты. . Жеке мен буга ыраазымын жана бул жөнөкөй xresources, ал urxvt үчүн фон түстөрүнүн негизги топтомун орнотот. Бирок, стандарттуу эмес түс темалары да көйгөйлөрдү жаратышы мүмкүн. Мисалы, колдонмолор менен и , анткени алар мурунтан эле өз түстөрүн колдонушат.
түстөрдү колдогон эмес жана жаңы түстөр көбүнчө 256 түстүү палитра менен чектелчү. Терминалдарын стилдештирген өнүккөн колдонуучулар үчүн, кабык чакырыктары же абал тилкелери татаал жол менен тажатма чектөө болушу мүмкүн. кайсы терминалдарда "True Color" колдоого ээ экенин байкайт. Менин тесттерим st, Alacritty жана VTE негизиндеги терминалдары True Color'ду эң сонун колдой турганын тастыктайт. Башка терминалдар бул жагынан абдан жакшы эмес жана, чынында, 256 түстү көрсөтпөйт. Төмөндө сиз 256 түс палитрасы менен бул ишти жакшы аткарган GNOME терминалдарындагы True Color колдоосу менен urxvtтин ортосундагы айырманы көрө аласыз, ал сыноодон өтпөй калбастан, ал тургай алардын ордуна кээ бир бүлбүлдөгөн белгилерди көрсөтөт.
Кээ бир терминалдар шилтемелерди чыкылдатуу үчүн URL үлгүлөрү үчүн текстти талдайт. Бул VTEден алынган бардык терминалдарга тиешелүү, ал эми urxvt бир чыкылдатууда же баскычтоптун жарлыгын колдонууда URL'дерди өзгөрткөн атайын плагинди талап кылат. Мен сынаган башка терминалдарда URL даректери башка жолдор менен көрсөтүлөт.
Акыр-аягы, терминалдарда жаңы тенденция - сыдырма буферинин тандоосу. Мисалы, st сыдыруу буфери жок; колдонуучу tmux жана сыяктуу терминалдык мультиплексорду колдонот деп болжолдонууда .
Alacritty да артка жылдыруу буферлери жок, бирок колдонуучулардын бул тема боюнча "кеңири пикири" менен анын колдоосу. Бул башталгычтардан тышкары, мен сынап көргөн ар бир терминал тескери сыдырууну колдойт.
Subtotals
Материалдын экинчи бөлүгүндө (түп нускада бул эки башка макала болгон - болжол менен. тилке) биз өндүрүмдүүлүктү, эстутумдун колдонулушун жана күтүү мөөнөтүн салыштырабыз. Бирок сөз болуп жаткан кээ бир терминалдарда олуттуу кемчиликтер бар экенин азыртадан эле көрүп жатабыз. Мисалы, RTL скрипттери менен үзгүлтүксүз иштеген колдонуучулар mlterm жана pterm жөнүндө ойлонушу мүмкүн, анткени алар башкаларга караганда окшош тапшырмаларды аткарууда жакшыраак. Konsole да жакшы аткарды. RTL скрипттери менен иштебеген колдонуучулар башка нерсени тандай алышат.
Зыяндуу кодду киргизүүдөн коргоо жагынан, urxvt чабуулдун бул түрүнөн коргоону атайын ишке ашыруусу менен өзгөчөлөнүп турат, бул мага албетте ыңгайлуу. Кээ бир коңгуроолорду жана ышкырыктарды издегендер үчүн Konsole карап чыгууга татыктуу. Акырында, VTE түстөрдү колдоого, URL таанууга жана башкаларга кепилдик берген терминалдар үчүн эң сонун база экенин белгилей кетүү керек. Бир караганда, сиздин сүйүктүү чөйрөңүз менен келген демейки терминал бардык талаптарга жооп бериши мүмкүн, бирок бул суроону аткарууну түшүнгүчө ачык калтыралы.
Маекти уланталы
Жалпысынан алганда, терминалдардын иштеши өзүнчө эле татаал маселедей сезилиши мүмкүн, бирок белгилүү болгондой, алардын айрымдары мындай фундаменталдык типтеги программалык камсыздоо үчүн таң калыштуу түрдө жогорку кечиктирүүнү көрсөтүшөт. Мындан тышкары, биз салттуу түрдө "ылдамдык" деп аталган нерсени (чындыгында, бул сыдыруу ылдамдыгы) жана терминалдын эстутумун керектөөнү (эскертүү менен, бул бүгүнкү күндө ондогон жылдар мурункудай маанилүү эмес) карап чыгабыз.
кармоо
Терминалдын иштешин кылдат изилдеп чыккандан кийин, мен бул жагынан эң маанилүү параметр кечигүү (пинг) деген жыйынтыкка келдим. Анын макаласында Павел Фатин ар кандай тексттик редакторлордун күтүү убактысын карап, бул жагынан терминалдар эң ылдам текст редакторлоруна караганда жайыраак болушу мүмкүн экенин кыйытты. Дал ушул кыйытма акыры мени өзүмдүн тесттеримди жүргүзүүгө жана бул макаланы жазууга алып келди.
Бирок кечигүү деген эмне жана ал эмне үчүн мынчалык маанилүү? Фатин өзүнүн макаласында муну “ачкычты басуу менен тиешелүү экранды жаңыртуу ортосундагы кечигүү” деп аныктаган жана цитата келтирген. , анда мындай деп айтылат: "Компьютер дисплейиндеги визуалдык пикирдин кечигүү машинисттин жүрүм-турумуна жана канааттануусуна чоң таасирин тийгизет."
Фатин бул пингдин канааттануу эмес, тереңирээк кесепеттери бар экенин түшүндүрөт: "терүү жайыраак болуп, каталар көбөйүп, көз менен булчуңдардын чыңалуусу күчөйт". Башка сөз менен айтканда, көп кечигүү мээге кошумча когнитивдик жүгүн алып келет, анткени, каталарды жана ошондой эле төмөнкү коддун сапатын алып келиши мүмкүн. Бирок эң жаманы, пинг "көздүн жана булчуңдардын чыңалуусун күчөтөт". келечекте (Сыягы, автор көздүн булчуңдары, арка, кол жана, албетте, көрүү менен байланышкан көйгөйлөрдү билдирет - болжол менен. тилке) кайталануучу стресстен улам.
Бул таасирлердин айрымдары узак убакыт бою белгилүү жана натыйжалары , 1976-жылы Ergonomics журналында жарыяланган, 100 миллисекунддук кечигүү "терүү ылдамдыгын олуттуу түрдө начарлатат" деп айтылат. Жакында, GNOME Колдонуучу колдонмосу киргизилген 10 миллисекундда, жана андан ары барсаңыз, анда 1 миллисекунд идеалдуу экенин көрсөтөт.
Фатин өзүнүн тесттерин тексттик редакторлордо өткөрдү; деп аталган көчмө аспапты жараткан Мен терминалдык эмуляторлордо пингди сынап көрчү элем. Сыноо симуляциялык режимде жүргүзүлгөнүн эсиңизден чыгарбаңыз: чындыгында биз киргизүүнү (клавиатура, USB контроллери ж.б.) жана чыгарууну (видео карта буфери, монитор) күтүү убактысын да эске алышыбыз керек. Фатиндин айтымында, типтүү конфигурацияларда бул болжол менен 20 мс. Эгер сизде оюн жабдуулары болсо, бул көрсөткүчкө 3 миллисекундда эле жетүүгө болот. Бизде ушундай тез жабдык бар болгондуктан, колдонмо өзүнүн кечигүү убактысын кошуунун кереги жок. Фатиндин максаты - колдонмонун кечигүү убактысын 1 миллисекундга чейин жеткирүү, ал тургай, ансыз да терүүгө жетишүү , кантип .
Бул жерде менин өлчөөлөрүмдүн натыйжалары, ошондой эле Фатиндин кээ бир жыйынтыктары, менин экспериментим анын сыноолору менен макул экендигин көрсөтүү үчүн:
Мени таң калтырган биринчи нерсе, xterm жана mlterm сыяктуу эски программалардын жакшыраак жооп берүү убактысы болду. Эң начар регистрдик кечигүү менен (2,4 мс), алар эң ылдам заманбап терминалга караганда жакшыраак иштешти (ст үчүн 10,6 мс). Эч бир заманбап терминал 10 миллисекунддук босогодон төмөн түшпөйт. Атап айтканда, Alacritty "эң ылдам терминал эмулятору" талабына жооп бере албайт, бирок анын упайлары 2017-жылы биринчи кароодон бери жакшырган. Чынында эле, долбоордун авторлору жана дисплейди жакшыртуу боюнча иштеп жатышат. GTK3 колдонгон Vim анын GTK2 кесиптешине караганда жайыраак экенин белгилей кетүү керек. Мындан биз GTK3 кошумча кечиктирүүнү жаратат жана бул аны колдонгон бардык башка терминалдарда (Terminator, Xfce4 Terminal жана GNOME Terminal) чагылдырылган деген жыйынтыкка келсек болот.
Бирок, айырмачылыктар көзгө байкалбашы мүмкүн. Фатин түшүндүргөндөй, "сизге таасир этиши үчүн кечиктирүүнү билишиңиз керек эмес". Фатин ошондой эле стандарттык четтөө жөнүндө эскертет: "кечиктирүүдөгү ар кандай бузулуулар (жыттер) күтүлбөгөндүктөн улам кошумча стрессти жаратат".
Жогорудагы график таза Debian 9 (созулган) менен алынган . Бул чөйрө күтүү сыноолорунда эң жакшы натыйжаларды берет. Көрсө, GNOME бардык өлчөөлөр үчүн 20 мс кошумча пингди түзөт. Бул үчүн мүмкүн болгон түшүндүрмө киргизүү окуяларды синхрондуу иштетүү менен программалардын болушу болуп саналат. Фатин мындай учурга мисал келтирет , бул бардык киргизүү окуяларын синхрондуу иштетүү менен кечиктирүүнү кошот. Демейки боюнча, GNOME ошондой эле терезе менеджери менен келет , бул пингге таасир этүүчү жана кеминде 8 миллисекунддук күтүү убактысын кошо турган буферлөөнүн кошумча катмарын түзөт.
Жылдыруу ылдамдыгы
Кийинки тест - бул экранда чоң көлөмдөгү текстти көрсөтүүдө терминалдын баракты канчалык тез жылдыра аларын өлчөй турган салттуу "тездик" же "өткөрүү жөндөмдүүлүгү" тести. Сыноонун механикасы ар түрдүү; баштапкы сыноо жөн гана seq буйругун колдонуп бир эле текст сапты түзүү болгон. Башка тесттерге Томас Э . Терминалдын иштешин дагы бир карап чыгууда cat аркылуу терминалга чыгарылуучу кокустук байттардын base32 коддолгон сапын колдонот. Луу мындай тестти "элестеткендей пайдасыз бенчмарк" деп эсептейт жана анын ордуна терминалдык жоопту негизги метрика катары колдонууну сунуштайт. Дики ошондой эле тестти адаштыруучу деп атайт. Бирок, эки автор тең терминалдык терезенин өткөрүү жөндөмдүүлүгү көйгөй болушу мүмкүн экенин моюнга алышат. Луу чоң файлдарды көрсөтүүдө Emacs Eshell катып калышын тапты жана Дики xtrermдин визуалдык жайлоосунан арылуу үчүн терминалды оптималдаштырды. Демек, бул тесттин дагы деле жакшы жактары бар, бирок рендеринг процесси терминалдан терминалга такыр башкача болгондуктан, аны башка параметрлерди текшерүү үчүн сыноо компоненти катары да колдонсо болот.
Бул жерде биз rxvt жана st тартууну атаандаштыктан алдыга жылдырууну, андан кийин аткаруучулукка басым жасоо менен жасалган алда канча жаңы Alacrittyди көрөбүз. Кийинки Xfce (VTE үй-бүлөсү) жана Konsole, алар дээрлик эки эсе ылдам. Акыркысы - xterm, бул rxvtден беш эсе жайыраак. Сыноо учурунда xterm да бир топ толкунданып, өтүп жаткан текст бир эле сызык болсо да көрүүнү кыйындаткан. Konsole тез эле, бирок кээде татаал болчу: дисплей мезгил-мезгили менен катып, текстти жарым-жартылай көрсөтүп же такыр көрсөтпөй турган. Башка терминалдарда саптар так көрсөтүлдү, анын ичинде st, Alacritty жана rxvt.
Дикки аткаруу айырмачылыктары ар кандай терминалдарда сыдырма буферлеринин дизайны менен шартталган деп түшүндүрөт. Тактап айтканда, ал rxvt жана башка терминалдарды "жалпы эрежелерди сактабагандыгы үчүн" айыптайт:
"Xtermден айырмаланып, rxvt бардык жаңыртууларды көрсөтүүгө аракет кылган жок. Эгерде ал артта калса, ал кууп чыгуу үчүн кээ бир жаңыртуулардан баш тартат. Бул ички эстутумду уюштурууга караганда көрүнөө сыдыруу ылдамдыгына көбүрөөк таасирин тийгизди. Бир кемчилиги ASCII анимациясынын бир аз так эмес болгондугу болду."
Бул кабыл алынган xterm солгундугун оңдоо үчүн, Дики ресурсту колдонууну сунуштайт , агымга туруштук берүү үчүн xterm айрым экран жаңыртууларын жокко чыгарууга мүмкүндүк берет. Менин тесттерим fastScroll майнаптуулугун жакшыртып, xtermди rxvt менен бирдей алып келерин тастыктайт. Бирок, бул өтө одоно балдак, Дикки өзү түшүндүргөндөй: "кээде xterm - konsole сыяктуу - кээ бирлери алынып салынгандан кийин экран жаңыртууларынын жаңы топтомун күтүп жатканда токтоп калгандай сезилет." Бул жагынан алганда, башка терминалдар ылдамдык менен дисплейдин бүтүндүгүнүн ортосунда эң жакшы компромиссти тапкан окшойт.
Ресурстарды керектөө
Жылдыруу ылдамдыгын аткаруунун көрсөткүчү катары кароонун мааниси барбы, жокпу, бул тест бизге терминалдардагы жүктөмдү окшоштурууга мүмкүндүк берет, бул өз кезегинде эстутум же дискти колдонуу сыяктуу башка параметрлерди өлчөөгө мүмкүндүк берет. Көрсөткүчтөр көрсөтүлгөн тестти жүргүзүү аркылуу алынган сек Python процессинин мониторинги астында. Ал эсептегичтердин маалыматтарын чогулткан үчүн ru_maxrss, сумма ru_oublock и ru_inblock жана жөнөкөй таймер.
Бул тестте ST 8 МБ эстутумдун эң төмөнкү керектөөсү менен биринчи орунду ээлейт, бул дизайндын негизги идеясы жөнөкөйлүк экенин эске алганда таң калыштуу эмес. mlterm, xterm жана rxvt бир аз көбүрөөк керектейт - болжол менен 12 МБ. Дагы бир көрүнүктүү натыйжа - Alacritty, аны иштетүү үчүн 30 МБ талап кылынат. Андан кийин 40тан 60 МБга чейинки сандар менен VTE үй-бүлө терминалдары бар, бул абдан көп. Бул керектөө бул терминалдарда жогорку деңгээлдеги китепканаларды, мисалы, GTK колдонгондугу менен түшүндүрсө болот. Konsole тесттер учурунда 65МБ эстутум керектөө менен акыркы орунда турат, бирок муну анын өзгөчөлүктөрүнүн кеңири спектри менен актоого болот.
Он жыл мурун алынган мурунку натыйжаларга салыштырмалуу, бардык программалар эстутумду кыйла көп керектей баштады. Мурда Xterm 4 МБ талап кылса, азыр ал ишке киргенде 15 МБ талап кылат. Rxvt үчүн керектөөнүн ушундай эле өсүшү бар, ал азыр кутудан 16 Мб талап кылат. Xfce Терминалы 34 Мб ээлейт, бул мурункуга караганда үч эсе чоң, бирок GNOME Терминалы 20 МБ гана талап кылат. Албетте, бардык мурунку сыноолор 32-бит архитектура боюнча жүргүзүлгөн. LCA 2012де Rusty Russell , эс керектөөнүн көбөйүшүн түшүндүрө турган дагы көптөгөн тымызын себептер бар. Муну айткандан кийин, биз азыр гигабайт эс тутумга ээ болгон мезгилде жашап жатабыз, ошондуктан биз кандайдыр бир жол менен башкарабыз.
Бирок, терминал сыяктуу фундаменталдуу нерсеге көбүрөөк эстутум бөлүү ресурстарды текке кетирүү экенин сезбей коё албайм. Бул программалар эң кичинесинин эң кичинеси болушу керек, кандайдыр бир "кутуда", атүгүл бут кутусунда иштей алышы керек, эгерде биз Linux системалары менен жабдылышы керек болгон жерге келсек (жана ушундай болорун билесиз) ). Бирок бул сандар менен эстутум колдонуу келечекте эң жеңил жана чектелген мүмкүнчүлүктөрдөн башка бир нече терминалдарды иштеткен ар кандай чөйрөдө көйгөй болуп калат. Мунун ордун толтуруу үчүн, GNOME Терминалында, Konsole, urxvt, Terminator жана Xfce Терминалында бир нече терминалдарды бир процесс аркылуу башкарууга мүмкүндүк берүүчү Демон режими бар, алардын эстутум керектөөсүн чектейт.
Сыноолордун жүрүшүндө мен дискти окуу-жазууга байланыштуу дагы бир күтүүсүз жыйынтыкка келдим: мен бул жерден эч нерсе көрбөйм деп ойлогом, бирок кээ бир терминалдар дискке эң көлөмдүү маалыматтарды жазат экен. Ошентип, VTE китепканасы дискте сыдырма буферин сактайт (бул функция , жана бул дагы эле болуп жатат). Бирок, эски ишке ашыруулардан айырмаланып, азыр жок дегенде бул маалымат AES256 GCM аркылуу шифрленген (). Бирок акылга сыярлык суроо туулат: VTE китепканасынын эмнеси мынчалык өзгөчөлүгү бар, ал ишке ашырууга мынчалык стандарттуу эмес мамилени талап кылат...
жыйынтыктоо
Макаланын биринчи бөлүгүндө биз VTE негизиндеги терминалдарда жакшы функциялардын топтому бар экенин көрдүк, бирок азыр биз бул кээ бир аткаруу чыгымдары менен коштолорун көрүп жатабыз. Азыр эстутум көйгөй эмес, анткени бардык VTE терминалдарын Daemon процесси аркылуу башкарууга болот, бул алардын табитин чектейт. Бирок, RAM жана ядро буферлеринин көлөмү боюнча физикалык чектөөлөрү бар эски системалар дагы эле терминалдардын мурунку версияларына муктаж болушу мүмкүн, анткени алар кыйла азыраак ресурстарды керектейт. VTE терминалдары өткөрүү жөндөмдүүлүгүн (сыдыруу) сыноолордо жакшы аткарганы менен, алардын дисплейдин күтүү мөөнөтү GNOME Колдонуучунун колдонмосунда белгиленген чектен жогору. VTE иштеп чыгуучулар, балким, муну эске алышы керек. Эгерде биз Linuxтун жаңы колдонуучулары үчүн терминалга туш болушу сөзсүз болоорун эске алсак, алар аны колдонуучуга ыңгайлуураак кыла алышат. Тажрыйбалуу геэктер үчүн демейки терминалдан өтүү көздүн азыраак чарчоосун жана узак иштөө сессияларынан улам келечектеги жумушка байланыштуу жаракаттарды жана ооруларды болтурбоо мүмкүнчүлүгүн билдирет. Тилекке каршы, эски xterm жана mlterm гана бизди 10 миллисекунддук сыйкырдуу пинг босогосуна алып келет, бул көпчүлүк үчүн кабыл алынгыс.
Эталондук өлчөөлөр ошондой эле Linux графикалык чөйрөлөрүнүн өнүгүшүнө байланыштуу иштеп чыгуучуларга бир катар компромисстерге барууга туура келгенин көрсөттү. Кээ бир колдонуучулар кадимки терезе менеджерлерин карап көргүсү келиши мүмкүн, анткени алар пингди олуттуу азайтат. Тилекке каршы, Wayland үчүн күтүү убактысын өлчөө мүмкүн болгон жок: мен колдонгон Typometer программасы Wayland алдын алуу үчүн түзүлгөн: башка терезелерде шпиондук кылуу. Мен Wayland композитинги X.org караганда жакшыраак иштейт деп үмүттөнөм жана келечекте кимдир бирөө бул чөйрөдө кечиктирүүнү өлчөө жолун табат деп үмүттөнөм.
Source: www.habr.com