Няколко думи от нашето преводно бюро: обикновено всички се стремят да превеждат най-новите материали и публикации, и ние не сме изключение. Но терминалите не са нещо, което се обновява всяка седмица. Затова преведохме статията на Антоан Бопре, публикувана през пролетта на 2018 година: въпреки солидната си, от съвременна гледна точка, "възраст", според нас материалът изобщо не е загубил своята актуалност. Освен това, в оригинал е серия от две статии, но решихме да ги обединим в един голям пост.
Терминалите заемат специално място в компютърната история, но през последните десетилетия те бяха "принудени" буквално да оцеляват заедно с командния ред на фона на все по-разпространените графични интерфейси. замениха своите , които, от своя страна, бяха модификации на системи с перфокарти и ключалки. Съвременните дистрибуции идват с множество емулации на терминали с всякакви форми и цветове. И докато много потребители спокойно се задоволяват с стандартния терминал, предоставен от тяхната работна среда, някои гордо използват откровено екзотичен софтуер за стартиране на любимата си обвивка или текстов редактор. Но, както ще видим в тази статия, не всички терминали са създадени по един и същ образ и подобие: те силно се различават помежду си по функционалност, размер и производителност.
Някои терминали имат наистина удивителни дупки в сигурността, а повечето притежават напълно различен набор от функции, от поддръжка на интерфейс с раздели до скриптове. Въпреки че , тази статия е обновление на предишния материал, който ще помогне на читателите да определят кой терминал да използват през 2018 година. В първата половина на статията се сравняват функциите, а във втората се оценява производителността.
Ето терминалите, които разгледах:
Възможно е това да не са най-новите версии, тъй като се ограничих до стабилни сборки по времето на написване на материала, които успях да инсталирам на Debian 9 или Fedora 27. Единственото изключение е Alacritty. Той е наследник на терминали с GPU ускорение и е написан на необичайния и нов за тази задача език — Rust. Изключих от прегледа си уеб-терминали (включително и на ), тъй като предварителните тестове показаха тяхната изключително ниска производителност.
Поддръжка на юникод
С тестовете започнах с поддръжката на юникод. Първият тест на терминалите беше да покажат стринга за юникод от : „é, Δ, Й, ק, م, ๗, あ, 叶, 葉 и 말“. Тестът показва дали терминалът може да работи правилно по целия свят. Терминалът xterm не показва арабския символ в конфигурацията по подразбиране:
По подразбиране xterm използва класически „фиксирован“ шрифт, който, според , има „значително покритие на юникод от 1997 година“. В този шрифт се случва нещо, което прави символа да бъде показан под формата на празна рамка, и само при увеличаване на размера на текста до 20+ пункта символът най-накрая започва да се показва правилно. Въпреки това, такъв „фикс“ нарушава показването на другите юникод символи:
Тези скрийншотове бяха направени в Fedora 27, тъй като тя показа най-добри резултати в сравнение с Debian 9, където някои стари версии на терминалите (по-конкретно — mlterm) не можеха да работят правилно с шрифтовете. За щастие, това беше поправено в по-късни версии.
Сега обърнете внимание на показването на стринга в xterm. Оказва се, че символите Mem и следващият след него семитски са свързани със сценарии за начертаване RTL (), така че те трябва технически да се показват отдясно наляво. Уеб браузъри, например Firefox 57, правилно обработват горния стринг. По-прост вариант на RTL текста е думата „“ на иврит (). казва следното:
„Много компютърни програми не могат да показват правилно двупосочен текст. Например, еврейското име „Сара“ се състои от символи син (ש) (който се появява отдясно), след това реш (ר) и накрая хе (ה) (който трябва да се появи отляво).“
Много терминали не преминават този тест: Alacritty, производни терминали на 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 "Здравей ";
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.
явно е предназначен да неутрализира подобни атаки. В този режим терминалите обграждат вставения текст с двойка специални 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 за всички измервания. Възможно обяснение за това е наличието на програми с синхронна обработка на входните събития. Фатин дава пример за подобен случай , който добавя закъснение, обработвайки всички входни събития синхронно. По подразбиране 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 МБ, което не е удивително, като се има предвид, че основната идея на проекта е простотата. Малко повече консумират mlterm, xterm и rxvt — около 12 МБ. Друг забележителен резултат има Alacritty, който изисква 30 МБ за работа. Следват терминалите от семейството VTE с показатели от 40 до 60 МБ, което е доста много. Такава консумация може да се обясни с факта, че тези терминали използват библиотеки с по-високо ниво, като GTK. Konsole е на последно място с колосалната консумация от 65 МБ памет по време на тестовете, макар че това може да бъде оправдано с доста широкия набор от функции.
В сравнение с предишните резултати, получени преди десет години, всички програми започнаха да консумират забележимо повече памет. По-рано Xterm изискваше 4 МБ, а сега — 15 МБ просто за стартиране. Подобно увеличение в консумацията има и при rxvt, който сега изисква 16 МБ. Терминалът Xfce заема 34 МБ, което е три пъти повече от преди, докато GNOME Terminal изисква само 20 МБ. Разбира се, всички предишни тестове бяха извършени на 32-битна архитектура. На LCA 2012 Расти Ръсел , има много по-фини причини, които могат да обяснят увеличаването на консумацията на памет. Въпреки това, сега живеем в епоха, в която имаме цели гигабайти памет, така че ще се справим по някакъв начин.
Въпреки това, не мога да се отърва от усещането, че отделянето на повече памет за софтуер с такова основно значение като терминал е празна загуба на ресурси. Тези програми трябва да бъдат най-малките от най-малките, трябва да могат да работят на всяка „кутия“, дори и на обувни кутии, ако някога стигнем до момента, когато трябва да ги снабдим с 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
