Пары слоў ад нашага translate-бюро: звычайна ўсе імкнуцца перакладаць самыя свежыя матэрыялы і публікацыі, і мы не выключэнне. Але тэрміналы - гэта не тое, што абнаўляецца раз у тыдзень. Таму мы пераклалі для вас артыкул Антуана Бопрэ, апублікаваны вясной 2018 года: нягледзячы на самавіты па сучасных мерках «узрост», на наш погляд, матэрыял зусім не страціў актуальнасці. Акрамя таго, у арыгінале гэта серыя з двух артыкулаў, але мы прынялі рашэнне аб'яднаць іх у адну вялікую пасаду.
Тэрміналы займаюць асаблівае месца ў кампутарнай гісторыі, але ў апошнія дзесяцігоддзі яны "вымушаныя" былі літаральна выжываць разам з камандным радком на фоне паўсюдна якія распаўсюджваюцца графічных інтэрфейсаў. замянілі сваіх , якія, у сваю чаргу, былі мадыфікацыяй сістэм на перфакартах і тумблерах. Сучасныя дыстрыбутывы пастаўляюцца з цэлым мноствам эмулятараў тэрмінала ўсіх формаў і расфарбовак. І пакуль шматлікія спакойна здавольваюцца стандартным тэрміналам, які падаецца іх працоўным асяроддзем, некаторыя з гонарам выкарыстаюць адкрыта экзатычнае праграмнае забеспячэнне для запуску сваёй каханай абалонкі ці тэкставага рэдактара. Але, як мы ўбачым з гэтага артыкула, не ўсе тэрміналы былі створаны па адной выяве і падабенству: яны моцна адрозніваюцца паміж сабой па функцыянальнасці, памеры і прадукцыйнасці.
Некаторыя тэрміналы маюць прама дзіўныя дзюры ў бяспецы, плюс, большасць валодае зусім розным наборам функцый, ад падтрымкі інтэрфейсу з укладкамі да сцэнарыяў. Хаця мы , гэты артыкул - абнаўленне папярэдняга матэрыялу, якое дапаможа чытачам вызначыць, якім тэрміналам карыстацца ў 2018 годзе. У першай палове артыкула параўноўваюцца функцыі, а ў другой ацэньваецца прадукцыйнасць.
Вось разгледжаныя мной тэрміналы:
Магчыма, гэта не самыя свежыя версіі, бо я абмяжоўваўся стабільнымі зборкамі на момант напісання матэрыялу, якія ў мяне атрымалася раскачаць на Debian 9 або Fedora 27. Адзінае выключэнне - Alacritty. Ён з'яўляецца нашчадкам тэрміналаў з GPU-паскарэннем і напісаны на незвычайнай і новай для гэтай задачы мове – Rust. Я выключыў са свайго агляду вэб-тэрміналы (у тым ліку, і на ), таму што папярэднія тэсты паказалі іх вельмі нізкую прадукцыйнасць.
Падтрымка юнікод
Свае тэсты я пачаў з падтрымкі юнікод. Першым тэстам тэрміналаў было адлюстраванне гэтымі радкі аб юнікод з : «é, Δ, Й, ק, م, ๗, あ, 叶, 葉 і 馬». Гэты просты тэст паказвае, ці можа тэрмінал карэктна працаваць ва ўсім свеце. Тэрмінал xterm не адлюстроўвае арабскі сімвал у канфігурацыі па змаўчанні:
Па дэфолце xterm выкарыстоўвае класічны «фіксаваны» шрыфт, які, паводле , мае «істотны ахоп юнікод з 1997 года». У гэтым шрыфце адбываецца нешта, што прымушае сімвал адлюстроўвацца ў выглядзе пустой рамкі і толькі пры павелічэнні шрыфта тэксту да 20+ пунктаў сімвал нарэшце пачынае адлюстроўвацца правільна. Аднак такі «фікс» ламае адлюстраванне іншых сімвалаў юнікод:
Гэтыя скрыншоты былі зроблены ў Fedora 27, бо менавіта яна давала лепшыя вынікі, чым Debian 9, дзе некаторыя старыя версіі тэрміналаў (а канкрэтна - mlterm) не маглі належным чынам працаваць са шрыфтамі. На шчасце, гэта было папраўлена ў пазнейшых версіях.
Цяпер звернеце ўвагу на адлюстраванне радка ў xterm. Аказваецца, сімвал Mem і наступны за ім Semitic ставяцца да сцэнарам напісання RTL (), таму тэхнічна яны павінны адлюстроўвацца справа налева. Вэб-браўзэры, напрыклад Firefox 57, правільна апрацоўваюць прыведзены вышэй радок. Прасцейшым варыянтам RTL-тэксту з'яўляецца слова «» на іўрыце (). кажа наступнае:
«Многія кампутарныя праграмы не могуць правільна адлюстроўваць двунакіраваны тэкст. Напрыклад, яўрэйскае імя «Сара» складаецца з сімвалаў сін (ש) (які з'яўляецца справа), затым раш (ר) і, нарэшце, хе (ה) (які павінен з'яўляцца злева)».
Многія тэрміналы не праходзяць гэты тэст: Alacritty, VTE-вытворныя тэрміналы Gnome і XFCE, urxvt, st і xterm адлюстроўваюць "Сара" у зваротным парадку, як калі б мы запісвалі гэтае імя як "Арас".
Іншая праблема двунакіраваных тэкстаў заключаецца ў тым, што іх трэба неяк выраўнаваць, асабліва калі гаворка ідзе аб змешванні RTL і LTR-тэкстаў. Сцэнары RTL павінны запускацца з правага боку акна тэрмінала, але што павінна адбывацца для тэрміналаў, па змаўчанні якія працуюць з LTR-ангельскай? Большасць з іх не валодаюць нейкімі спецыяльнымі механізмамі і выраўноўваюць увесь тэкст па левым краі (у тым ліку, і ў Konsole). Выключэннем з'яўляюцца 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.
відавочна прызначаны для нейтралізацыі падобных нападаў. У гэтым рэжыме тэрміналы складаюць які ўстаўляецца тэкст у пару адмысловых escape-паслядоўнасцяў, каб паведаміць абалонцы аб паходжанні гэтага тэксту. Так абалонка атрымлівае сігнал, што можа ігнараваць спецыяльныя сімвалы, якія можа змяшчаць устаўляемы тэкст. Усе тэрміналы, аж да шаноўнага xterm, падтрымліваюць дадзеную функцыю, але ўстаўка ў Bracketed-рэжыме мае патрэбу ў падтрымцы абалонкі ці прыкладанні, запушчанага на тэрмінале. Напрыклад, ПА выкарыстоўвалае (той жа Bash), мае патрэбу ў файле ~ / .inputrc:
set enable-bracketed-paste onНажаль, тэст-сайт Хорна таксама паказвае, як абыйсці гэтую абарону праз само фарматаванне тэксту і заўчасна скончыць ужыванне да яго Bracketed-рэжыму. Гэта працуе, таму што некаторыя тэрміналы некарэктна фільтруюць escape-паслядоўнасці перад даданнем сваіх уласных. Напрыклад, у маіх я так і не змог паспяхова завяршыць тэсты Konsole нават з улікам карэктнай канфігурацыі. .inputrc файла. Гэта азначае, што вы з лёгкасцю можаце атрымаць пашкоджанні канфігурацыі сістэмы з-за непадтрымоўванага прыкладання ці няправільна наладжанай абалонкі. Асабліва небяспечна гэта пры ўваходзе на выдаленыя серверы, дзе старанная прапрацоўка канфігурацыі сустракаецца радзей, тым больш калі такіх выдаленых машын у вас шмат.
Добрым рашэннем гэтай праблемы з'яўляецца плягін пацверджання ўстаўкі для тэрмінала urxvt, які проста запытвае дазвол на ўстаўку любога тэксту, які змяшчае ў сабе новыя радкі. Больш абароненага варыянту для апісванай Хорнам тэкставага нападу я не знайшоў.
Укладкі і профілі
Папулярнай зараз функцыяй з'яўляецца падтрымка інтэрфейсу з укладкамі, які мы будзем вызначаць як адно акно тэрмінала, якое змяшчае ў сабе яшчэ некалькі тэрміналаў. Для розных тэрміналаў гэтая функцыя адрозніваецца, і хоць традыцыйныя тэрміналы выгляду xterm наогул не падтрымліваюць укладкі, больш сучасныя інкарнацыі тэрмінала ў асобе Xfce Terminal, GNOME Terminal і Konsole гэтую функцыю маюць. Таксама падтрымка ўкладак ёсць і ў Urxvt, але толькі пры ўмове выкарыстання плагіна. Але з пункту гледжання падтрымкі ўкладак як такіх безумоўным лідэрам з'яўляецца Terminator: ён не толькі падтрымлівае ўкладкі, але таксама можа размяшчаць тэрміналы ў адвольным парадку (гл малюнак ніжэй).
Яшчэ адной асаблівасцю Terminator з'яўляецца магчымасць «групаваць» гэтыя ўкладкі разам і пасылаць адны і тыя ж націскі клавіш на некалькі тэрміналаў адначасова, што забяспечвае грубіянскую прыладу выканання масавых аперацый на некалькіх серверах адначасова. Аналагічная функцыя таксама рэалізавана і ў Konsole. Для выкарыстання гэтай функцыі ў іншых тэрміналах неабходна выкарыстоўваць іншае праграмнае забеспячэнне, такое як , або .
Асабліва добра ўкладкі працуюць разам з профілямі: напрыклад, у вас можа быць адна ўкладка для электроннай пошты, іншая для чата і гэтак далей. Гэта добра падтрымліваецца тэрміналам Konsole і 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 таксама адсутнічаюць буферы зваротнага скролла, але яго падтрымка з-за "шырокага фідбэка" на гэтую тэму з боку карыстачоў. Апроч гэтых выскачак, кожны правераны мною тэрмінал, які я змог знайсці, падтрымлівае зваротную пракрутку.
Прамежкавыя вынікі
У другой частцы матэрыялу (у арыгінале гэта былі два розныя артыкулы, - заўв. зав.) мы параўнаем прадукцыйнасць, выкарыстанне памяці і затрымку. Але мы ўжо бачым, што некаторыя з разгляданых тэрміналаў маюць сур'ёзныя недахопы. Напрыклад, карыстачы на рэгулярнай аснове якія працуюць з RTL-скрыптамі могуць звярнуць увагу на mlterm і pterm, бо яны лепш за іншых спраўляюцца з падобнымі задачамі. Konsole таксама добра выявіў сябе. Карыстальнікі, якія не працуюць з RTL-скрыптамі, могуць выбіраць што-небудзь іншае.
З пункта гледжання абароненасці ад устаўкі шкоднаснага кода urxvt варта асабняком з-за сваёй адмысловай рэалізацыі абароны ад гэтага выгляду нападаў, якая мне здаецца вызначана зручнай. Тым, хто шукае якія-небудзь навароты, варта паглядзець на Konsole. Нарэшце, варта адзначыць, што VTE – выдатная база для тэрміналаў, якая гарантуе падтрымку кветак, распазнанне URL і гэтак далей. На першы погляд, дэфолтны тэрмінал, які пастаўляецца з вашым каханым асяроддзем, можа адказваць усім патрабаванням, але пакінем гэтае пытанне адчыненым, пакуль не разбярэмся з прадукцыйнасцю.
Працягваем размову
Наогул, прадукцыйнасць тэрміналаў сама па сабе можа здацца надуманай праблемай, аднак, як аказалася, некаторыя з іх дэманструюць дзіўна вялікую затрымку для ПЗ такога фундаментальнага тыпу. Таксама далей мы разгледзім тое, што традыцыйна называюць хуткасцю (насамрэч, гэта хуткасць пракруткі) і спажыванне тэрміналам памяці (з аглядкай на тое, што сёння гэта не так крытычна, як дзесяцігоддзі таму).
затрымка
Пасля дбайнага даследавання прадукцыйнасці тэрміналаў я прыйшоў да высновы, што найважнейшым параметраў у гэтым плане з'яўляецца памер затрымкі (пінг). У сваім артыкуле Павел Фацін разгледзеў затрымку розных тэкставых рэдактараў і намякнуў, што тэрміналы ў гэтым плане могуць працаваць больш павольна, чым самыя хуткія тэкставыя рэдактары. Менавіта гэты намёк і прывёў мяне, у канчатковым выніку, да запуску ўласных тэстаў і напісанню гэтага артыкула.
Але што такое затрымка, і чаму яна такая важная? У сваім артыкуле Фацін вызначыў яе як "затрымку паміж націскам клавішы і адпаведным абнаўленнем экрана" і працытаваў , У якім гаворыцца: "Затрымка ў візуальнай зваротнай сувязі на дысплеі кампутара аказвае важны ўплыў на паводзіны машыністкі і яе задаволенасць".
Фацін тлумачыць, што такі пінг мае глыбейшыя наступствы, чым проста задавальненне: "друк становіцца павольней, узнікае больш памылак, павялічваецца напруга вачэй і цягліц". Іншымі словамі, вялікая затрымка можа прывесці да памылак друку, а таксама зніжэнню якасці кода, бо прыводзіць да дадатковай кагнітыўнай нагрузкі на мозг. Але што яшчэ горш, пінг «павялічвае напругу вачэй і цягліц», што, відаць, мае на ўвазе у будучыні (па ўсёй бачнасці, аўтар мае на ўвазе праблемы з цягліцамі вачэй, спіной, рукамі і, вядома ж, зрокам, - заўв. зав.) з-за паўтаральнай напругі.
Некаторыя з гэтых эфектаў вядомыя даўно, а вынікі , Апублікаванага яшчэ ў 1976 годзе ў часопісе Ergonomics, кажуць, што затрымка ў 100 мілісекунд "значна пагаршае хуткасць набору". Зусім нядаўна ў кіраўніцтве карыстальніка GNOME было занесена у 10 мілісекунд, а калі ісці далей, то паказвае, што ідэалам з'яўляецца 1 мілісекунда.
Фацін праводзіў свае тэсты на тэкставых рэдактарах; ён стварыў партатыўны інструмент пад назвай , Які я выкарыстаў для праверкі пінга ў эмулятарах тэрмінала. Майце на ўвазе, што тэст праводзіўся ў рэжыме сімуляцыі: у рэчаіснасці нам трэба ўлічваць і затрымку ўводу (клавіятура, USB-кантролер і гэтак далей) і вываду (буфер відэакарты, манітор). Па словах Фаціна, у тыповых канфігурацыях яна складае каля 20 ms. Пры наяўнасці геймерскага абсталявання можна дасягнуць паказчыка за ўсё ў 3 мілісекунды. Бо ў нас ужо ёсць такое хуткае абсталяванне, прыкладанне не павінна ўносіць яшчэ і сваю затрымку. Мэта Фаціна -давесці затрымку прыкладання да 1 мілісекунды, або зусім дасягнуць набору без , Як у .
А вось вынікі маіх вымярэнняў, а таксама некаторыя вынікі Фаціна для таго, каб паказаць, што мой эксперымент стасуецца з яго тэстамі:
Першае, што мяне ўразіла - гэта лепшы час водгуку ў старых праграм, такіх як xterm і mlterm. З наяўнасцю горшай затрымкі рэгістра (2,4 ms) яны паказалі вынік лепш, чым самы хуткі сучасны тэрмінал (10,6 ms для st). Ніводны сучасны тэрмінал не апускаецца ніжэй парога ў 10 мілісекунд. У прыватнасці, Alacritty не адпавядае патрабаванням да "самага хуткага з існуючых эмулятараў тэрмінала", хоць яго вынікі палепшыліся з моманту першай праверкі ў 2017 годзе. Сапраўды, аўтары праекту і працуюць над паляпшэннем адлюстравання. Таксама неабходна адзначыць, што Vim, які выкарыстоўвае GTK3, на парадак павольней свайго аналога GTK2. З гэтага можна зрабіць выснову, што GTK3 стварае дадатковую затрымку, і гэта адбіваецца на ўсіх іншых тэрміналах, якія яго выкарыстоўваюць (Terminator, Xfce4 Terminal і GNOME Terminal).
Аднак для вока адрозненні могуць быць незаўважныя. Як тлумачыць Фацін: "не абавязкова ўсведамляць наяўнасць затрымкі, каб яна мела на вас эфект". Фацін таксама папярэджвае аб стандартным адхіленні: "любыя парушэнні ў працягласці затрымкі (дрыгаценне) ствараюць дадатковую нагрузку з-за іх непрадказальнасці".
Графік вышэй узяты атрыманы на чыстым Debian 9 (stretch) з . Гэта асяроддзе дае найлепшыя вынікі ў тэстах на вызначэнне затрымкі. Як аказалася, GNOME стварае дадатковы пінг у 20 ms для ўсіх вымярэнняў. Магчымае тлумачэнне гэтаму - наяўнасць праграм з сінхроннай апрацоўкай ўваходных падзей. Фацін прыводзіць для такога выпадку ў прыклад , Які дадае затрымку апрацоўваючы ўсе input-падзеі сінхронна. Па змаўчанні GNOME таксама абсталяваны мэнэджэрам вокнаў , якія стварае дадатковы ўзровень буферызацыі, што ўплывае на пінг і дадае мінімум 8 мілісекунд затрымкі.
Хуткасць пракруткі
Наступны тэст - гэта традыцыйная праверка "хуткасці" або "паласы прапускання", якая вымярае, як хутка тэрмінал можа пракручваць старонку, адлюстроўваючы вялікую колькасць тэксту на экране. Механіка цеста вар'іруецца; арыгінальны тэст складаўся ў тым, каб проста генераваць адзін і той жа тэкставы радок з дапамогай каманды seq. Іншыя тэсты ўключаюць у сябе праверку Томаса Е. Дзікі (суправаджаючага xterm), у рамках якога шматкроць . У яшчэ адным аглядзе прадукцыйнасці тэрміналаў выкарыстоўвае радок выпадковых байтаў у кадоўцы base32, якая выводзіцца ў тэрмінал з дапамогай cat. Луу лічыць такі тэст "настолькі бескарысным эталонам, наколькі гэта можна сабе ўявіць" і прапануе выкарыстоўваць замест гэтага водгук тэрмінала ў якасці асноўнага паказчыка. Дзікі таксама называе свой тэст які ўводзіць у зман. Тым не менш, абодва аўтары прызнаюць, што прапускная здольнасць акна тэрмінала можа быць праблемай. Луу выявіў завісанне 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 МБ. Затым ідуць тэрміналы сямейства VTE з паказчыкамі ад 40 да 60 МБ, што дастаткова шмат. Падобнае спажыванне можна растлумачыць тым, што гэтыя тэрміналы выкарыстоўваюць бібліятэкі больш высокага ўзроўню, напрыклад, GTK. Konsole ідзе апошнім з каласальным спажываннем 65 МБ памяці падчас тэстаў, хоць і гэта можна апраўдаць яго вельмі шырокім наборам функцый.
У параўнанні з папярэднімі вынікамі, атрыманымі 4 гадоў таму, усе праграмы сталі спажываць прыкметна больш памяці. Раней Xterm патрабаваў 15 МБ, а зараз – 16 МБ проста на запуску. Аналагічнае павелічэнне спажывання ёсць і ў rxvt, які зараз са скрынкі патрабуе 34 МБ. Тэрмінал Xfce займае 20 МБ, што ў тры разы больш, чым раней, а вось GNOME Terminal патрабуе ўсяго 32 МБ. Вядома, усе папярэднія тэсты праводзіліся на 2012-бітнай архітэктуры. На LCA XNUMX Расці Расэл , што ёсць мноства больш тонкіх прычын, якія могуць растлумачыць рост спажывання памяці. Пры гэтым сёння мы жывем у часы, калі ў нас ёсць цэлыя гігабайты памяці, так што як-небудзь справімся.
Тым не менш, я не магу пазбавіцца ад адчування, што вылучэнне большай колькасці памяці на такое фундаментальнае ПЗ, як тэрмінал, - гэта пустая трата рэсурсаў. Гэтыя праграмы павінны быць найменшымі з самых маленькіх, павінны быць здольныя працаваць на любой "скрынцы", нават абутковай, калі мы калі-небудзь прыйдзем да таго, што іх трэба будзе абсталёўваць Linux-сістэмамі (а вы ведаеце, што так яно і будзе) . Але з гэтымі лічбамі выкарыстанне памяці стане ў будучыні праблемай у любым асяроддзі пры запуску некалькіх тэрміналаў, акрамя сітуацыі з некалькімі найлягчэйшымі і абмежаванымі ў магчымасцях. Каб кампенсаваць гэта, GNOME Terminal, Konsole, urxvt, Terminator і Xfce Terminal маюць Daemon-рэжым, які дазваляе кіраваць некалькімі тэрміналамі праз адзін працэс, што абмяжоўвае іх спажыванне памяці.
Падчас сваіх тэстаў я прыйшоў да яшчэ аднаго нечаканага выніку датычна дыскавага чытання-запісу: я чакаў наогул нічога тут не ўбачыць, але аказалася, што некаторыя тэрміналы запісваюць самыя аб'ёмныя дадзеныя на дыск. Так, бібліятэка VTE фактычна трымае на дыску буфер скролла (гэта асаблівасць , і гэта адбываецца да гэтага часу). Але ў адрозненне ад старых рэалізацыя, зараз, па меншай меры, гэтыя дадзеныя зашыфраваны з дапамогай AES256 GCM (). Але ўзнікае слушнае пытанне, што ж такога асаблівага ў бібліятэцы VTE, што яна патрабуе такога нестандартнага падыходу да рэалізацыі…
Заключэнне
У першай частцы артыкула мы выявілі, што тэрміналы на аснове VTE маюць добры набор функцый, але зараз мы бачым, што гэта звязана з некаторымі выдаткамі на забеспячэнне іх прадукцыйнасці. Цяпер памяць не з'яўляецца праблемай, таму што ўсімі VTE-тэрміналы можна кіраваць праз Daemon-працэс, які абмяжоўвае іх апетыт. Тым не менш, старыя сістэмы, якія маюць фізічныя абмежаванні па колькасці аператыўнай памяці і буфера ядра, могуць па-ранейшаму мець патрэбу ў больш ранніх версіях тэрміналаў, бо яны спажываюць значна менш рэсурсаў. Хоць тэрміналы VTE паказалі сябе добра ў тэстах на прапускную здольнасць (пракрутка), іх затрымка адлюстравання дадзеных на дысплеі вышэй усталяванага парога ў кіраўніцтве карыстальніка GNOME. Верагодна, распрацоўнікам VTE варта гэта ўлічыць. Калі прыняць у разлік тое, што нават для пачаткоўцаў карыстачоў Linux сустрэча з тэрміналам непазбежная, яны могуць зрабіць яго больш прыязным у адносінах да юзэра. Для вопытных гікаў пераход з тэрмінала па змаўчанні можа азначаць нават зніжэнне нагрузкі на зрок і магчымасць пазбегнуць прафесійных траўм і захворванняў у будучыні з-за працяглых працоўных сесій. Нажаль, толькі старыя xterm і mlterm падводзяць нас да чарадзейнага парога пінгу ў 10 мілісекунд, што для шматлікіх непрымальна.
Кантрольныя вымярэнні таксама паказалі, што з-за развіцця графічных асяроддзяў Linux распрацоўнікам прыйшлося пайсці на шэраг кампрамісаў. Некаторым карыстачам варта зірнуць на звычайныя аконныя мэнэджары, бо яны забяспечваюць значнае паніжэнне пінгу. На жаль, для Wayland вымераць затрымку не атрымалася: праграма Typometer, якой я карыстаўся, была створана для таго, што Wayland закліканы прадухіляць – шпіянаж за іншымі вокнамі. Я спадзяюся, што кампазітынг Wayland па прадукцыйнасці лепш, чым X.org, а таксама спадзяюся і на тое, што ў будучыні нехта знойдзе спосаб ацаніць узровень затрымкі ў гэтым асяроддзі.
Крыніца: habr.com