Няколко думи от нашето бюро за преводи: обикновено всеки се стреми да превежда най-новите материали и публикации и ние не сме изключение. Но терминалите не са нещо, което се актуализира веднъж седмично. Затова преведохме за вас статия на Антоан Бопре, публикувана през пролетта на 2018 г.: въпреки значителната си „възраст“ по съвременните стандарти, според нас материалът изобщо не е загубил своята актуалност. Освен това първоначално това беше поредица от две статии, но ние решихме да ги комбинираме в една голяма публикация.
Терминалите имат специално място в компютърната история, но през последните десетилетия те бяха принудени да оцелеят заедно с командния ред, тъй като графичните интерфейси станаха повсеместни. замениха собствените си , които от своя страна бяха модификация на системи, базирани на перфокарти и превключватели. Съвременните дистрибуции идват с разнообразие от терминални емулатори с всякакви форми и цветове. И докато мнозина се задоволяват със стандартния терминал, осигурен от тяхната работна среда, някои гордо използват откровено екзотичен софтуер, за да стартират любимата си обвивка или текстов редактор. Но, както ще видим от тази статия, не всички терминали са създадени по едно и също изображение: те се различават значително по функционалност, размер и производителност.
Някои терминали имат направо изненадващи пропуски в сигурността, плюс повечето имат напълно различен набор от функции, от поддръжка на интерфейс с раздели до скриптове. Въпреки че ние , тази статия е актуализация на предишния материал, който ще помогне на читателите да определят кой терминал да използват през 2018 г. Първата половина на статията сравнява характеристиките, а втората половина оценява ефективността.
Ето терминалите, които прегледах:
Това може да не са най-новите версии, тъй като бях ограничен до стабилни компилации по време на писането, които успях да пусна на Debian 9 или Fedora 27. Единственото изключение е Alacritty. Той е потомък на GPU-ускорени терминали и е написан на необичаен и нов език за тази задача - Rust. Изключих уеб терминали от моя преглед (включително тези на ), тъй като предварителните тестове показаха изключително лошото им представяне.
Поддръжка на Unicode
Започнах тестовете си с поддръжка на Unicode. Първият тест на терминалите беше да покажат Unicode низа от : „é, Δ, И, ק, م, ๗, あ, 叶, 葉 и 말.“ Този прост тест показва дали терминалът може да работи правилно по целия свят. терминалът xterm не показва арабски символи в конфигурация по подразбиране:
По подразбиране xterm използва класическия "фиксиран" шрифт, който според , има „значително Unicode покритие от 1997 г. насам“. Има нещо, което се случва в този шрифт, което кара знака да се показва като празна рамка и едва когато шрифтът на текста се увеличи до 20+ точки, знакът най-накрая започва да се показва правилно. Тази „корекция“ обаче нарушава показването на други Unicode знаци:
Тези екранни снимки са направени във Fedora 27, тъй като дава по-добри резултати от Debian 9, където някои по-стари версии на терминали (по-специално mlterm) не могат да обработват правилно шрифтовете. За щастие това беше поправено в по-късните версии.
Сега забележете как линията се показва в xterm. Оказва се, че символът Мем и следният семит вижте скриптове в стил RTL (), така че технически те трябва да се показват отдясно наляво. Уеб браузъри като Firefox 57 обработват горния ред правилно. По-проста версия на RTL текст е думата "" на иврит (). казва следното:
„Много компютърни програми не могат да показват правилно двупосочен текст. Например еврейското име „Сара“ се състои от знаците sin (ש) (което се появява вдясно), след това resh (ר) и накрая той (ה) (което трябва да се появи вляво).“
Много терминали се провалят на този тест: 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.
е ясно предназначен да неутрализира подобни атаки. В този режим терминалите затварят поставения текст в двойка специални екраниращи последователности, за да кажат на обвивката за произхода на текста. Това казва на обвивката, че може да игнорира специални символи, които може да съдържа поставеният текст. Всички терминали назад до почтения xterm поддържат тази функция, но поставянето в режим Bracketed изисква поддръжка от черупката или приложението, работещо на терминала. Например, използване на софтуер (същият Bash), има нужда от файл ~/.inputrc:
set enable-bracketed-paste onЗа съжаление, тестовият сайт на Horn също показва как да заобиколите тази защита чрез самото форматиране на текста и преждевременно да приложите режим Bracketed към него. Това работи, защото някои терминали не филтрират правилно екраниращите последователности, преди да добавят свои собствени. Например, в моя никога не успях да завърша успешно тестовете на Konsole дори с правилната конфигурация .inputrc файл. Това означава, че можете лесно да повредите системната си конфигурация поради неподдържано приложение или неправилно конфигурирана обвивка. Това е особено опасно при влизане в отдалечени сървъри, където внимателната работа по конфигуриране е по-рядко срещана, особено ако имате много такива отдалечени машини.
Добро решение на този проблем е плъгинът за потвърждение на поставяне за терминала urxvt, който просто иска разрешение за вмъкване на всеки текст, който съдържа нови редове. Не намерих по-сигурна опция за описаната от Хорн текстова атака.
Раздели и профили
Популярна функция в момента е поддръжката на интерфейс с раздели, който ще дефинираме като един терминален прозорец, съдържащ няколко други терминала. Тази функция е различна за различните терминали и въпреки че традиционните xterm терминали изобщо не поддържат раздели, по-модерните въплъщения на терминали като Xfce Terminal, GNOME Terminal и Konsole имат тази функция. Urxvt също поддържа раздели, но само ако използвате плъгин. Но по отношение на самата поддръжка на раздели, Terminator е безспорен лидер: той не само поддържа раздели, но също така може да подрежда терминали в произволен ред (вижте изображението по-долу).
Друга характеристика на Terminator е способността да „групирате“ тези раздели заедно и да изпращате едни и същи натискания на клавиши към множество терминали едновременно, предоставяйки груб инструмент за извършване на групови операции на множество сървъри едновременно. Подобна функция е внедрена и в Konsole. За да използвате тази функция в други терминали, трябва да използвате софтуер на трети страни, като напр , или .
Разделите работят особено добре, когато са сдвоени с профили: например можете да имате един раздел за имейл, друг за чат и т.н. Това се поддържа добре от терминала Konsole и терминала GNOME. И двата позволяват на всеки раздел автоматично да стартира свой собствен профил. 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 и .
Alacrity също няма буфери за обратно превъртане, но неговата подкрепа поради „обширната обратна връзка“ по тази тема от потребителите. Освен тези новопоявили се, всеки терминал, който съм тествал и който успях да намеря, поддържа обратно превъртане.
междинни суми
Във втората част на материала (в оригинал това бяха две различни статии - ок. платно) ще сравним производителността, използването на паметта и латентността. Но вече виждаме, че някои от въпросните терминали имат сериозни недостатъци. Например, потребители, които редовно работят с RTL скриптове, може да помислят за mlterm и pterm, тъй като те се справят по-добре със сходни задачи от други. Konsole също се представи добре. Потребителите, които не работят с RTL скриптове, могат да изберат нещо друго.
По отношение на защитата срещу вмъкване на зловреден код, urxvt се отличава със специалната си реализация на защита срещу този тип атаки, което ми се струва определено удобно. За тези, които търсят някои звънци и свирки, Konsole си заслужава да се види. И накрая, заслужава да се отбележи, че VTE е отлична база за терминали, което гарантира поддръжка на цветове, разпознаване на URL и т.н. На пръв поглед терминалът по подразбиране, който идва с любимата ви среда, може да отговаря на всички изисквания, но нека оставим този въпрос отворен, докато разберем производителността.
Да продължим разговора
Като цяло производителността на терминалите сама по себе си може да изглежда като пресилен проблем, но както се оказва, някои от тях показват изненадващо висока латентност за софтуер от такъв фундаментален тип. Освен това след това ще разгледаме това, което традиционно се нарича „скорост“ (всъщност това е скоростта на превъртане) и потреблението на памет от терминала (с уговорката, че това не е толкова критично днес, колкото беше преди десетилетия).
закъснение
След задълбочено проучване на производителността на терминала стигнах до извода, че най-важният параметър в това отношение е латентността (ping). В статията си Павел Фатин разгледа латентността на различните текстови редактори и намекна, че терминалите в това отношение може да са по-бавни от най-бързите текстови редактори. Именно този намек в крайна сметка ме накара да проведа собствени тестове и да напиша тази статия.
Но какво е латентност и защо е толкова важна? В статията си Фатин го дефинира като „закъснението между натискането на клавиш и съответната актуализация на екрана“ и цитира , който гласи: „Забавянето на визуалната обратна връзка на дисплея на компютъра оказва важно влияние върху поведението и удовлетворението на машинописците.“
Фатин обяснява, че този пинг има по-дълбоки последствия от простото удовлетворение: „пишете става по-бавно, появяват се повече грешки и напрежението в очите и мускулите се увеличава.“ С други думи, голямото забавяне може да доведе до печатни грешки, а също и до по-ниско качество на кода, тъй като води до допълнително когнитивно натоварване на мозъка. Но по-лошото е, че пингът "увеличава напрежението на очите и мускулите", което изглежда предполага в бъдеще (Очевидно авторът има предвид проблеми с мускулите на очите, гърба, ръцете и, разбира се, зрението - ок. платно) поради повтарящ се стрес.
Някои от тези ефекти са известни отдавна, както и резултатите , публикуван през 1976 г. в списание Ergonomics, се казва, че забавяне от 100 милисекунди „значително влошава скоростта на писане“. Съвсем наскоро беше въведено ръководството за потребителя на GNOME за 10 милисекунди и ако отидете по-нататък, тогава показва, че 1 милисекунда е идеална.
Фатин проведе своите тестове върху текстови редактори; той създаде преносим инструмент, наречен , който използвах за тестване на ping в терминални емулатори. Имайте предвид, че тестът беше проведен в режим на симулация: в действителност трябва да вземем предвид латентността както на входа (клавиатура, USB контролер и т.н.), така и на изхода (буфер на видеокарта, монитор). Според Фатин в типичните конфигурации е около 20 ms. Ако имате оборудване за игри, можете да постигнете тази цифра само за 3 милисекунди. Тъй като вече имаме толкова бърз хардуер, приложението не трябва да добавя своя собствена латентност. Целта на Fatin е да доведе латентността на приложението до 1 милисекунда или дори да постигне набиране без , как в .
Ето резултатите от моите измервания, както и някои от резултатите на Фатин, за да покажат, че моят експеримент е в съответствие с неговите тестове:
Първото нещо, което ми направи впечатление, беше по-доброто време за реакция на по-старите програми като xterm и mlterm. С най-лошото забавяне на регистъра (2,4 ms), те се представиха по-добре от най-бързия модерен терминал (10,6 ms за st). Нито един съвременен терминал не пада под прага от 10 милисекунди. По-специално, Alacritty не успява да изпълни твърдението за „най-бързия наличен терминален емулатор“, въпреки че резултатите му са се подобрили след първия преглед през 2017 г. Всъщност авторите на проекта и работят за подобряване на дисплея. Трябва също да се отбележи, че Vim, използващ GTK3, е с порядък по-бавен от своя аналог GTK2. От това можем да заключим, че GTK3 създава допълнително забавяне и това се отразява във всички други терминали, които го използват (Terminator, Xfce4 Terminal и GNOME Terminal).
Въпреки това, разликите може да не са забележими за окото. Както обяснява Фатин, "не е нужно да сте наясно със забавянето, за да има ефект върху вас." Фатин също предупреждава за стандартното отклонение: „всякакви смущения в латентността (трептене) създават допълнителен стрес поради тяхната непредсказуемост.“
Графиката по-горе е направена на чист Debian 9 (разтягане) с . Тази среда дава най-добри резултати при тестове за латентност. Както се оказва, GNOME създава допълнителен ping от 20 ms за всички измервания. Възможно обяснение за това е наличието на програми със синхронна обработка на входните събития. Фатин дава пример за такъв случай , което добавя забавяне, като обработва всички входни събития синхронно. По подразбиране GNOME се предлага и с мениджър на прозорци , което създава допълнителен слой на буфериране, който влияе на ping и добавя поне 8 милисекунди латентност.
Скорост на превъртане
Следващият тест е традиционен тест за "скорост" или "широчина на честотната лента", който измерва колко бързо терминалът може да превърти страница, докато показва голямо количество текст на екрана. Механиката на теста варира; първоначалният тест беше просто да се генерира същия текстов низ с помощта на командата seq. Други тестове включват теста на Thomas E. Dickey (xterm supporter), който многократно . В друг преглед на производителността на терминала използва base32 кодиран низ от произволни байтове, който се извежда към терминала с помощта на cat. Луу смята, че такъв тест е „толкова безполезен бенчмарк, колкото човек може да си представи“ и вместо това предлага да се използва реакцията на терминала като основен показател. Дики също нарича своя тест подвеждащ. И двамата автори обаче признават, че пропускателната способност на терминалния прозорец може да бъде проблем. Luu откри, че Emacs Eshell замръзва при показване на големи файлове, а Dickey оптимизира терминала, за да се отърве от визуалната мудност на xtrerm. Така че все още има някои предимства на този тест, но тъй като процесът на изобразяване е много различен от терминал до терминал, той може да се използва и като тестов компонент за тестване на други параметри.
Тук виждаме rxvt и st да изпреварват конкуренцията, последвани от много по-новия Alacritty, който е проектиран с фокус върху производителността. Следват Xfce (VTE семейство) и Konsole, които са почти двойно по-бързи. Последният е xterm, който е пет пъти по-бавен от rxvt. По време на теста xterm също се вълнува много, правейки преминаващия текст труден за виждане, дори ако е същият ред. Konsole беше бърз, но понякога беше трудно: дисплеят замръзваше от време на време, показвайки частичен текст или не го показваше изобщо. Други терминали показваха низове ясно, включително st, Alacritty и rxvt.
Дики обяснява, че разликите в производителността се дължат на дизайна на буферите за превъртане в различните терминали. По-специално, той обвинява rxvt и други терминали, че „не следват общите правила“:
„За разлика от xterm, rxvt не се опита да покаже всички актуализации. Ако изостане, ще откаже някои актуализации, за да навакса. Това имаше по-голямо влияние върху видимата скорост на превъртане, отколкото върху организацията на вътрешната памет. Един недостатък беше, че ASCII анимацията беше малко неточна."
За да коригирате тази предполагаема мудност на xterm, Дики предлага да използвате ресурса , което позволява на xterm да отхвърли някои актуализации на екрана, за да бъде в крак с потока. Моите тестове потвърждават, че fastScroll подобрява производителността и изравнява xterm с rxvt. Това обаче е доста груба патерица, както самият Дики обяснява: "понякога xterm - като конзолата - изглежда спира, докато чака нов набор от актуализации на екрана, след като някои са били премахнати." В този смисъл изглежда, че други терминали са намерили най-добрия компромис между скорост и цялост на дисплея.
Консумация на ресурси
Независимо от това дали има смисъл да разглеждаме скоростта на превъртане като показател за производителност, този тест ни позволява да симулираме натоварването на терминалите, което от своя страна ни позволява да измерваме други параметри като използване на памет или диск. Показателите са получени чрез изпълнение на посочения тест сл. под наблюдение на процеса на Python. Той събира данни от измервателните уреди за ru_maxrss, количество ru_oublock и ru_inblock и прост таймер.
В този тест ST заема първо място с най-ниска средна консумация на памет от 8 MB, което не е изненадващо, като се има предвид, че основната идея на дизайна е простотата. mlterm, xterm и rxvt консумират малко повече - около 12 MB. Друг забележителен резултат е Alacritty, който изисква 30 MB за работа. След това има терминали от семейството VTE с цифри от 40 до 60 MB, което е доста. Това потребление може да се обясни с факта, че тези терминали използват библиотеки от по-високо ниво, например GTK. Konsole е на последно място с колосалните 65 MB потребление на памет по време на тестове, въпреки че това може да бъде оправдано от много широкия му набор от функции.
В сравнение с предишни резултати, получени преди десет години, всички програми започнаха да консумират значително повече памет. Преди Xterm изискваше 4 MB, но сега изисква 15 MB само при стартиране. Има подобно увеличение на потреблението за rxvt, който сега изисква 16 MB извън кутията. Терминалът Xfce заема 34 MB, което е три пъти повече от преди, но терминалът GNOME изисква само 20 MB. Разбира се, всички предишни тестове бяха проведени на 32-битова архитектура. На LCA 2012 Ръсти Ръсел , че има много по-фини причини, които биха могли да обяснят увеличаването на потреблението на памет. Като каза това, сега живеем във време, в което имаме гигабайти памет, така че ще се справим някак.
Въпреки това не мога да не почувствам, че разпределянето на повече памет за нещо толкова фундаментално като терминала е загуба на ресурси. Тези програми трябва да са най-малките от най-малките, трябва да могат да работят на всяка „кутия“, дори на кутия за обувки, ако някога стигнем до точката, в която трябва да бъдат оборудвани с Linux системи (и знаете, че ще бъде така ) . Но с тези числа, използването на паметта ще се превърне в проблем в бъдеще във всяка среда, работеща с множество терминали, различни от няколко от най-леките и с най-ограничени възможности. За да компенсират това, GNOME Terminal, Konsole, urxvt, Terminator и Xfce Terminal имат режим Daemon, който ви позволява да контролирате множество терминали чрез един процес, ограничавайки тяхната консумация на памет.
По време на моите тестове стигнах до още един неочакван резултат по отношение на четене и запис на диск: очаквах да не видя абсолютно нищо тук, но се оказа, че някои терминали записват най-обемните данни на диска. И така, VTE библиотеката всъщност поддържа буфер за превъртане на диска (тази функция , и това все още се случва). Но за разлика от по-старите реализации, сега поне тези данни са криптирани с помощта на AES256 GCM (). Но възниква резонен въпрос: какво е толкова специално в библиотеката VTE, че изисква такъв нестандартен подход към внедряването...
Заключение
В първата част на статията открихме, че базираните на VTE терминали имат добър набор от функции, но сега виждаме, че това идва с някои разходи за производителност. Сега паметта не е проблем, защото всички VTE терминали могат да се контролират чрез процес Daemon, което ограничава техния апетит. Въпреки това, по-старите системи, които имат физически ограничения за количеството RAM и буферите на ядрото, все още може да се нуждаят от по-ранни версии на терминали, тъй като те консумират значително по-малко ресурси. Въпреки че VTE терминалите се представиха добре при тестове за пропускателна способност (превъртане), тяхната латентност на дисплея е над прага, зададен в Ръководството на потребителя на GNOME. Разработчиците на VTE вероятно трябва да вземат това предвид. Ако вземем предвид, че дори за начинаещи потребители на Linux срещата с терминал е неизбежна, те могат да го направят по-удобен за потребителя. За опитни маниаци преминаването от терминала по подразбиране може дори да означава по-малко напрежение на очите и възможност за избягване на бъдещи свързани с работата наранявания и заболявания поради дълги работни сесии. За съжаление, само старите xterm и mlterm ни довеждат до магическия праг на ping от 10 милисекунди, което е неприемливо за мнозина.
Сравнителните измервания също показаха, че поради развитието на графичните среди на Linux разработчиците трябваше да направят редица компромиси. Някои потребители може да искат да разгледат обикновените мениджъри на прозорци, тъй като те осигуряват значително намаляване на ping. За съжаление, не беше възможно да се измери латентността за Wayland: програмата Typometer, която използвах, беше създадена за това, което Wayland е предназначен да предотврати: шпиониране на други прозорци. Надявам се, че Wayland compositing се представя по-добре от X.org и също така се надявам, че в бъдеще някой ще намери начин да измери латентността в тази среда.
Източник: www.habr.com