Няколко думи от нашето translate-бюро: обикновено всички се стремят да превеждат най-новите материали и публикации, и ние не сме изключение. Но терминалите не са нещо, което се обновява всяка седмица. Затова преведохме за вас статията на Антоан Бопре, публикувана през пролетта на 2018 година: въпреки солидния си, според съвременните стандарти, "възраст", материалът напълно не е загубил актуалността си, според нас. Освен това, в оригинал това е серия от две статии, но решихме да ги обединим в един голям пост.
Терминалите заемат специално място в историята на компютрите, но през последните десетилетия те "бяха принудени" да оцеляват заедно с командния ред на фона на широко разпространените графични интерфейси. замениха своите , които от своя страна бяха модификации на системи с перфокарти и превключватели. Съвременните дистрибуции идват с цял набор от емулятори на терминали във всички форми и цветове. И докато много хора спокойно се задоволяват със стандартния терминал, предоставен от тяхната работна среда, някои с гордост използват откровено екзотичен софтуер за стартиране на любимата си обвивка или текстов редактор. Но, както ще видим в тази статия, не всички терминали са създадени по един и същи образ и подобие: те значително се различават помежду си по функционалност, размер и производителност.
Някои терминали имат направо удивителни пропуски в сигурността, плюс това, повечето предлагат напълно различен набор от функции, от поддръжка на интерфейс с вкладки до скриптове. Въпреки че ние , тази статия е обновление на предходния материал, който ще помогне на читателите да определят кой терминал да използват през 2018 година. В първата част на статията се сравняват функциите, а във втората се оценява производителността.
Ето разгледаните от мен терминали:
Вероятно, това не са най-новите версии, тъй като се ограничих до стабилни сборки към момента на написване на материала, които успях да инсталирам на Debian 9 или Fedora 27. Единственото изключение е Alacritty. Той е потомък на терминали с GPU ускорение и е написан на необичайния и нов за тази задача език — Rust. Изключих от прегледа си уеб терминали (включително и на ), тъй като предварителните тестове показаха изключително ниската им производителност.
Поддръжка на юникод
Започнах тестовете си с поддръжка на юникод. Първият тест на терминалите беше показването на низ от юникод от : «é, Δ, Й, ק, م, ๗, あ, 叶, 葉 и 말». Тестът показва дали терминалът може да работи правилно по целия свят. Терминалът xterm не показва арабския знак в конфигурацията по подразбиране:
По подразбиране xterm използва класическия „фиксирован” шрифт, който, според , има „значително покритие на юникод от 1997 година“. Този шрифт има нещо, което кара символа да се показва като празен квадрат и само при увеличаване на шрифта до 20+ пункта символът най-накрая започва да се показва правилно. Въпреки това, такъв „фикс“ разваля показването на други юникодни символи:
Тези скрийншотове бяха направени в Fedora 27, тъй като именно тя даваше най-добри резултати в сравнение с Debian 9, където някои стари версии на терминали (по-конкретно — mlterm) не можеха правилно да работят с шрифтовете. За щастие, това бе поправено в по-късни версии.
Сега обърнете внимание на показването на низа в xterm. Оказва се, че символът Mem и следващият след него семитски са част от сценарии за рисуване отдясно наляво (), така че технически те трябва да се показват отдясно наляво. Уеб браузърите, например 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 '!nТова беше лоша идея. Не копирайте код от уебсайтове, на които не се доверявате!
Ето първия ред на вашия /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За съжаление, тестовият сайт Хорна също показва как да заобиколите тази защита чрез форматирането на текста и преждевременно да прекратите прилагането на режима 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 за всички измервания. Възможно обяснение за това е наличието на програми със синхронна обработка на входящите събития. Фатин дава като пример в такъв случай , който добавя закъснение, обработвайки всички входни събития синхронно. По подразбиране GNOME също е оборудван с мениджър на прозорци , който създава допълнителен слой буфериране, който влияе на пинга и добавя минимум 8 милисекунди закъснение.
Скорост на превъртане
Следващият тест е традиционна проверка на "скоростта" или "пропускателната способност", която измерва колко бързо терминалът може да превърта страница, показвайки голямо количество текст на екрана. Механиката на теста варира; оригиналният тест се състоеше в това да генерира една и съща текстова линия с командата seq. Други тестове включват проверката на Томас Е. Дики (сопровождащ xterm), в която многократно . В още едно ревю на производителността на терминалите използва редица случайни байтове в кодировка base32, която се извежда в терминала с помощта на cat. Луу смята, че такъв тест е "толкова безполезен еталон, колкото може да си представите" и предлага вместо това да се използва отговорът на терминала като основен показател. Дики също нарича своя тест подвеждащ. Независимо от това, и двамата автори признават, че пропускната способност на прозореца на терминала може да бъде проблем. Луу открива, че Emacs Eshell замръзва при показване на големи файлове, а Дики оптимизира терминала, за да се отърве от визуалната бавност на xterm. Така че в този тест все още има известен резон, но тъй като процесът на рендериране значително варира от терминал до терминал, той може да се използва и като тестов компонент за проверка на други параметри.
Тук виждаме, че rxvt и st изпреварват конкурентите, следвани от много по-новия Alacritty, който се разработва с акцент върху бързодействието. След това идват Xfce (семейство VTE) и Konsole, които работят почти два пъти по-бързо. На последно място е xterm с показател, пет пъти по-бавен от rxvt. По време на теста xterm също така силно трептеше; преминаващият текст беше трудно да бъде различен, дори и да ставаше дума за една и съща линия. Konsole се оказа бърз, но понякога „мами”: дисплеят време на време зависваше, показвайки текста частично или изобщо не го показваше. Други терминали показваха редовете ясно, включително st, Alacritty и rxvt.
Дики обяснява, че разликите в производителността са свързани с дизайна на буферите за превъртане в различните терминали. По-специално, той обвинява rxvt и други терминали, че „не следват общите правила”:
„За разлика от xterm, rxvt не се опитваше да показва всички обновления. Ако изостава, той ще откаже част от обновленията, за да навакса. Това оказа по-голямо влияние на предполагаемата скорост на превъртане, отколкото на организацията на вътрешната памет. Един недостатък беше, че ASCII анимацията беше донякъде неточна.”
За да отстрани тази видима бавност на xterm, Дики предлага да използва ресурса , който позволява на xterm да отхвърля част от обновленията на екрана, за да не изостава от потока. Моите тестове потвърдиха, че fastScroll повишава производителността и изравнява xterm с rxvt. Това обаче е доста груба поправка, както самият Дики обяснява: „понякога xterm – както и konsole – изглежда спира, тъй като очаква нов набор от обновления на екрана след като част от тях са били отстранени”. В тази връзка изглежда, че другите терминали са намерили най-добрия компромис между скорост и цялост на дисплея.
Използване на ресурси
Независимо от целесъобразността на разглеждането на скоростта на превъртане като показател за производителност, този тест позволява да имитираме натоварването на терминалите, което от своя страна ни позволява да измерваме и други параметри, като използване на памет или диск. Метричните данни бяха получени чрез стартиране на посочения тест seq под мониторинга на процеса 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 Terminal изисква само 20 MB. Разбира се, всички предишни тестове са проведени на 32-битна архитектура. На LCA 2012 Расти Рассел , че има много по-фини причини, които могат да обяснят растежа на потреблението на памет. Въпреки всичко, сега живеем в времена, когато имаме цели гигабайти памет, така че ще се справим по някакъв начин.
Въпреки това, не мога да се отърва от усещането, че отделянето на повече памет за такъв основен софтуер като терминал е почти празна загуба на ресурси. Тези програми трябва да са най-малките от най-малките, трябва да могат да работят на всяка "кутия", дори обувна, ако някога се стигне до там, че трябва да бъде оборудвана с Linux системи (а вие знаете, че така ще стане). Но с тези цифри използването на паметта ще стане проблем в бъдеще в която и да е среда при стартиране на няколко терминала, освен при ситуация с няколко от най-леките и ограничени по възможности. За да се компенсира това, GNOME Terminal, Konsole, urxvt, Terminator и Xfce Terminal имат Daemon режим, който позволява управлението на няколко терминала чрез един процес, което ограничава тяхното потребление на памет.
В хода на тестовете си открих още един неочакван резултат по отношение на дисковото четене и запис: очаквах изобщо да не видя нищо тук, но се оказа, че някои терминали записват най-обемистите данни на диска. Така, библиотеката VTE фактически държи на диска буфер за скролиране (това отличие , и това продължава да се случва и до днес). Но в contrast на старите реализации, сега, поне, тези данни са криптирани посредством AES256 GCM (). Но възниква резонен въпрос: какво е толкова специално в библиотеката VTE, че изисква такъв нестандартен подход към реализацията…
Заключение
В първата част на статията открихме, че терминалите, базирани на VTE, предлагат добър набор от функции, но сега виждаме, че това е свързано с определени разходи за осигуряване на тяхната производителност. В момента паметта не е проблем, тъй като всички VTE терминали могат да се управляват през Daemon процес, който ограничава техния апетит. Въпреки това, старите системи с физически ограничения относно количеството оперативна памет и буфер на ядрото все още могат да се нуждаят от по-ранни версии на терминалите, тъй като те консумират значително по-малко ресурси. Макар терминалите VTE да показаха добри резултати в тестовете за пропускателна способност (скролиране), закъснението на визуализацията на данни на екрана е над установеното ниво в ръководството на потребителя GNOME. Вероятно разработчиците на VTE трябва да вземат това под внимание. Възможно е, дори за начинаещи потребители на Linux, срещата с терминала да е неизбежна, и те могат да направят интерфейса по-приветлив за потребителя. За опитните геймъри, преминаването към подразбиращия се терминал може даже да означава намаляване на натоварването на зрението и избягване на професионални травми и заболявания в бъдеще заради продължителни работни сесии. За съжаление, само старите xterm и mlterm ни водят до магическия праг на пинга от 10 милисекунди, който за много хора е неприемлив.
Контролните измервания показаха, че поради развитието на графични среди в Linux разработчиците е трябвало да направят редица компромиси. На някои потребители е препоръчително да се обърнат към обикновени мениджъри на прозорци, тъй като те осигуряват значителен спад в пинга. За съжаление, за Wayland не успяхме да измерим закъснението: програмата Typometer, която използвах, беше проектирана за това, което Wayland се стреми да предотврати - шпионирането на други прозорци. Надявам се, че производителността на композитора в Wayland е по-добра от X.org и също така се надявам, че в бъдеще някой ще намери начин да оцени нивото на закъснение в тази среда.
Източник: habr.com
