Пари слів від нашого translate-бюро: зазвичай усі прагнуть перекладати найсвіжіші матеріали та публікації, і ми не виняток. Але термінали це не те, що оновлюється раз на тиждень. Тому ми переклали для вас статтю Антуана Бопре, опубліковану навесні 2018 року: незважаючи на солідний за сучасними мірками «вік», на наш погляд, матеріал зовсім не втратив актуальності. Крім того, в оригіналі це серія з двох статей, але ми вирішили об'єднати їх в одну велику посаду.
Термінали займають особливе місце в комп'ютерній історії, але в останні десятиліття вони «змушені» були буквально виживати разом з командним рядком на тлі графічних інтерфейсів, що поширюються. замінили своїх , які, у свою чергу, були модифікацією систем на перфокартах та тумблерах. Сучасні дистрибутиви поставляються з безліччю емуляторів терміналу всіх форм і кольорів. І поки багато хто спокійно задовольняється стандартним терміналом, який надається їх робочим середовищем, деякі з гордістю використовують відверто екзотичне програмне забезпечення для запуску своєї улюбленої оболонки або текстового редактора. Але, як ми побачимо з цієї статті, не всі термінали були створені за одним образом і подобою: вони різняться між собою за функціональністю, розміром і продуктивністю.
Деякі термінали мають прямо дивовижні дірки в безпеці, плюс, більшість має зовсім різний набір функцій, від підтримки інтерфейсу з вкладками до сценаріїв. Хоча ми , ця стаття – оновлення попереднього матеріалу, яке допоможе читачам визначити, яким терміналом користуватись у 2018 році. У першій половині статті порівнюються функції, тоді як у другій оцінюється продуктивність.
Ось розглянуті мною термінали:
Можливо, це не найсвіжіші версії, тому що я обмежувався стабільними збірками на момент написання матеріалу, які мені вдалося розкотити на Debian 9 або Fedora 27. Єдиний виняток - Alacritty. Він є нащадком терміналів з GPU-прискоренням і написаний незвичайною і новою для цього завдання мовою – Rust. Я виключив зі свого огляду веб-термінали (у тому числі і на ), тому що попередні тести показали їхню вкрай низьку продуктивність.
Підтримка юнікоду
Свої тести я почав із підтримки юнікоду. Першим тестом терміналів було відображення рядка про юнікод з : «é, Δ, Й, ק, م, ๗, あ, 叶, 잎 і бік». Цей простий тест показує, чи термінал може коректно працювати по всьому світу. Термінал xterm не відображає арабського символу. у конфігурації за замовчуванням:
За дефолтом xterm використовує класичний «фіксований» шрифт, який, згідно , має «суттєве охоплення юнікоду з 1997 року». У цьому шрифті відбувається щось, що змушує символ відображатись у вигляді порожньої рамки і тільки при збільшенні шрифту тексту до 20+ пунктів символ нарешті починає відображатися правильно. Однак такий фікс ламає відображення інших символів юнікоду:
Ці скріншоти були зроблені в Fedora 27, оскільки саме вона давала кращі результати, ніж Debian 9, де деякі старі версії терміналів (а саме mlterm) не могли належним чином працювати зі шрифтами. На щастя, це було виправлено у пізніших версіях.
Тепер зверніть увагу на відображення рядка xterm. Виявляється, символ Mem і наступний за ним Semitic відносяться до сценаріїв зображення RTL (), тому технічно вони мають відображатися праворуч наліво. Веб-браузери, наприклад Firefox 57, правильно обробляють наведений вище рядок. Простішим варіантом RTL-тексту є слово «» на івриті (). каже таке:
«Багато комп'ютерних програм не можуть правильно відображати двонаправлений текст. Наприклад, єврейське ім'я «Сара» складається із символів син (ש) (який з'являється праворуч), потім реш (ר) і, нарешті, хе (ה) (який має з'являтися ліворуч)».
Багато терміналів не проходять цей тест: Alacritty, VTE-похідні термінали Gnome і XFCE, urxvt, st і xterm відображають «Сара» у зворотному порядку, якби ми записували це ім'я як «Арас».
Інша проблема двонаправлених текстів полягає в тому, що їх треба якось вирівняти, особливо якщо йдеться про змішування RTL та LTR-текстів. Сценарії RTL повинні запускатися з правого боку вікна терміналу, але що має відбуватися для терміналів, які за промовчанням працюють з LTR-англійською? Більшість з них не мають якихось спеціальних механізмів і вирівнюють весь текст по лівому краю (у тому числі, і в Konsole). Винятком є pterm та mlterm, які дотримуються стандартів та вирівнюють такі рядки з правого краю.
Захист від вставки
Наступна критична особливість, яку я собі визначив, — це захист від вставки. Хоча широко відомо, що заклинання типу:
$ curl http://example.com/ | shє пуш-командами виконання коду, мало хто знає, що приховані команди можуть проникнути в консоль при копіюванні-вставці з веб-браузера навіть після ретельного огляду. блискуче показує, як команда, що виглядає безневинно:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitперетворюється при вставці з сайту Хорна на термінал ось на таку неприємність:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust!
Here'"'"'s the first line of your /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitЯк це працює? Шкідливий код винесено до блоку , який переміщений з поля зору користувача засобами CSS
явно призначений для нейтралізації таких атак. У цьому режимі термінали укладають текст, що вставляється, в пару спеціальних escape-послідовностей, щоб повідомити оболонку про походження цього тексту. Так оболонка отримує сигнал, що може ігнорувати спеціальні символи, які може містити текст, що вставляється. Всі термінали, аж до поважного xterm, підтримують цю функцію, але вставка в Bracketed-режимі потребує підтримки оболонки або програми, запущеної на терміналі. Наприклад, ПЗ використовує (Той же Bash), потребує файлу ~ / .inputrc:
set enable-bracketed-paste onНа жаль, тест-сайт Хорна також показує, як обійти цей захист через форматування тексту і передчасно закінчити застосування до нього Bracketed-режиму. Це працює тому, що деякі термінали некоректно фільтрують escape-послідовності перед додаванням своїх власних. Наприклад, у моїх я так і не зміг успішно завершити тести Konsole навіть з урахуванням коректної конфігурації. .inputrc файлу. Це означає, що ви легко зможете отримати пошкодження конфігурації системи через непідтримувану програму або неправильно налаштованої оболонки. Особливо небезпечно це при вході на віддалені сервери, де ретельне опрацювання конфігурації зустрічається рідше, тим більше якщо таких віддалених машин у вас багато.
Хорошим вирішенням цієї проблеми є плагін підтвердження вставки для терміналу urxvt, який просто запитує дозвіл на вставку будь-якого тексту, що містить нові рядки. Більше захищеного варіанта для описуваної Хорном текстової атаки не знайшов.
Вкладки та профілі
Популярною зараз функцією є підтримка інтерфейсу з вкладками, який ми визначатимемо як одне вікно терміналу, що містить ще кілька терміналів. Для різних терміналів ця функція відрізняється, і хоча традиційні термінали виду xterm взагалі не підтримують вкладки, сучасніші інкарнації терміналу в особі Xfce Terminal, GNOME Terminal та Konsole цю функцію мають. Також підтримка вкладок є і Urxvt, але тільки за умови використання плагіна. Але з точки зору підтримки вкладок як таких безумовним лідером є Terminator: він не тільки підтримує вкладки, але також може розміщувати термінали у довільному порядку (див. нижче).
Ще однією особливістю Terminator є можливість «групувати» ці вкладки разом і посилати ті самі натискання клавіш на кілька терміналів одночасно, що забезпечує грубий інструмент виконання масових операцій на декількох серверах одночасно. Аналогічна функція також реалізована і Konsole. Для використання цієї функції в інших терміналах необхідно використовувати інше програмне забезпечення, таке як , або .
Особливо добре вкладки працюють разом із профілями: наприклад, у вас може бути одна вкладка для електронної пошти, інша для чату і так далі. Це добре підтримується терміналом Konsole та GNOME Terminal. Обидва дозволяють кожній вкладці автоматично запускати свій профіль. Terminator теж підтримує профілі, але я не зміг знайти спосіб автоматично запускати певні програми під час відкриття певної вкладки. Інші термінали взагалі мають поняття «профіль».
Рюшечки
Останнє, що я розгляну в першій частині цієї статті, є зовнішнім виглядом терміналів. Наприклад, GNOME, Xfce та urxvt підтримують прозорість, але нещодавно згорнули підтримку фонових зображень, що змусило деяких користувачів перейти на термінал . Особисто мене влаштовує і просто xresourcesякий встановлює базовий набір кольорів фону для urxvt. Однак нестандартні колірні теми можуть створювати проблеми. Наприклад, з додатками и оскільки вони вже використовують власні кольори.
не підтримував кольори, а нові часто обмежувалися 256-колірною палітрою. Для досвідчених користувачів, які стилізують свої термінали, запити оболонки чи рядки стану якимись складними способами можуть стати неприємним обмеженням. відстежує, які термінали мають підтримку True Color. Мої тести підтверджують, що st, Alacritty та термінали на базі VTE чудово підтримують True Color. Інші термінали у цьому плані почуваються не дуже добре і за фактом не відображають навіть 256 кольорів. Нижче ви можете побачити різницю між підтримкою True Color у терміналах GNOME, st і xterm, які непогано справляються з цим завданням за допомогою своєї 256-колірної палітри, та urxvt, який не тільки не проходить тест, але навіть показує якісь миготливі символи замість них.
Деякі термінали також аналізують текст на наявність URL-шаблонів, щоб зробити посилання клікабельними. Це відноситься до всіх похідних від VTE терміналів, тоді як urxvt вимагає спеціальний модуль, що підключається, який би трансформував URL-адреси по клацанню або за допомогою поєднання клавіш. Інші протестовані мною термінали відображають URL-адреси іншими способами.
Зрештою, новий тренд терміналів — опціональність буфера прокручування. Наприклад, у st немає буфера прокручування; передбачається, що користувач використовуватиме термінальний мультиплексор, на зразок tmux і .
У Alacritty також відсутні буфери зворотного скролла, але його підтримка через «великий фідбек» на цю тему з боку користувачів. Окрім цих вискочок, кожен перевірений мною термінал, який я зміг знайти, підтримує зворотну прокрутку.
Проміжні висновки
У другій частині матеріалу (в оригіналі це були дві різні статті, - прим. пров.) ми порівняємо продуктивність, використання пам'яті та затримку. Але ми вже бачимо, що деякі з терміналів, що розглядаються, мають серйозні недоліки. Наприклад, користувачі на регулярній основі працюють з RTL-скриптами можуть звернути увагу на mlterm і pterm, так як вони краще за інших справляються з подібними завданнями. Konsole також добре виявив себе. Користувачі, які не працюють з RTL-скриптами, можуть вибирати щось інше.
З точки зору захищеності від вставки шкідливого коду urxvt стоїть окремо через свою особливу реалізацію захисту від цього виду атак, яка мені здається виразно зручною. Тим, хто шукає якісь навороти, варто подивитися на Konsole. Нарешті, варто відзначити, що VTE – чудова база для терміналів, яка гарантує підтримку кольорів, розпізнавання URL тощо. На перший погляд, дефолтний термінал, що поставляється з вашим улюбленим середовищем, може відповідати всім вимогам, але залишимо це питання відкритим, доки не розберемося з продуктивністю.
Продовжуємо розмову
Взагалі, продуктивність терміналів сама по собі може здатися надуманою проблемою, проте, як виявилося, деякі з них демонструють напрочуд велику затримку для ПЗ такого фундаментального типу. Також далі ми розглянемо те, що традиційно називають «швидкістю» (насправді це швидкість прокручування) і споживання терміналом пам'яті (з огляду на те, що сьогодні це не так критично, як десятиліття тому).
затримка
Після ретельного дослідження продуктивності терміналів я дійшов висновку, що найважливішим параметром у цьому плані є розмір затримки (пінг). У своїй статті Павло Фатін розглянув затримку різних текстових редакторів і натякнув, що термінали в цьому плані можуть працювати повільніше, ніж найшвидші текстові редактори. Саме цей натяк і привів мене, зрештою, до запуску власних тестів та написання цієї статті.
Але що таке затримка, і чому вона така важлива? У своїй статті Фатін визначив її як «затримку між натисканням клавіші та відповідним оновленням екрана» та процитував , В якому говориться: «Затримка у візуальному зворотному зв'язку на дисплеї комп'ютера надає важливий вплив на поведінку друкарки та її задоволеність».
Фатін пояснює, що такий пінг має глибші наслідки, ніж просто задоволення: «друк стає повільнішим, виникає більше помилок, збільшується напруга очей і м'язів». Іншими словами, велика затримка може призвести до друкарських помилок, а також зниження якості коду, оскільки призводить до додаткового когнітивного навантаження на мозок. Але що ще гірше, пінг «збільшує напругу очей та м'язів», що, мабуть, має на увазі в майбутньому (мабуть, автор має на увазі проблеми з м'язами очей, спиною, руками і, звичайно ж, зором, — прим. пров.) через напругу, що повторюється.
Деякі з цих ефектів відомі давно, а результати , Опублікованого ще в 1976 році в журналі Ergonomics, кажуть, що затримка в 100 мілісекунд "значно погіршує швидкість набору". Нещодавно у посібнику користувача GNOME було внесено в 10 мілісекунд, а якщо йти далі, то показує, що ідеалом є 1 мілісекунд.
Фатін проводив свої тести на текстових редакторах; він створив портативний інструмент під назвою я використовував для перевірки пінгу в емуляторах терміналу. Майте на увазі, що тест проводився в режимі симуляції: насправді нам треба враховувати затримку введення (клавіатура, USB-контролер і так далі) і виведення (буфер відеокарти, монітор). За словами Фатіна, у типових конфігураціях вона становить близько 20 ms. За наявності геймерського обладнання можна досягти показника всього 3 мілісекунди. Так як у нас вже є таке швидке обладнання, програма не повинна вносити ще й свою затримку. Мета Фатіна - довести затримку програми до 1 мілісекунди, або взагалі досягти набору без , як в .
А ось результати моїх вимірювань, а також деякі результати Фатіна для того, щоб показати, що мій експеримент узгоджується з його тестами:
Перше, що мене вразило - це найкращий час відгуку у старих програм, таких як xterm та mlterm. З наявністю найгіршої затримки регістра (2,4 ms) вони показали результат краще, ніж найшвидший сучасний термінал (10,6 ms для st). Жоден сучасний термінал не опускається нижче порога 10 мілісекунд. Зокрема, Alacritty не відповідає вимогам «найшвидшого з існуючих емуляторів терміналу», хоча його результати покращилися з моменту першої перевірки в 2017 році. Справді, автори проекту та працюють над покращенням відображення. Також необхідно відзначити, що Vim, який використовує GTK3, на порядок повільніший за свій аналог GTK2. З цього можна зробити висновок, що GTK3 створює додаткову затримку, і це відбивається на інших терміналах, які його використовують (Terminator, Xfce4 Terminal і GNOME Terminal).
Однак для ока відмінності можуть бути непомітними. Як пояснює Фатін: "не обов'язково усвідомлювати наявність затримки, щоб вона мала на вас ефект". Фатін також попереджає про стандартне відхилення: «будь-які порушення в тривалості затримки (тремтіння) створюють додаткове навантаження через їхню непередбачуваність».
Графік вище взятий отриманий на чистому Debian 9 (stretch) з . Це середовище дає найкращі результати у тестах визначення затримки. Як виявилося, GNOME створює додатковий пінг 20 ms для всіх вимірювань. Можливе пояснення цього – наявність програм із синхронною обробкою вхідних подій. Фатін наводить для такого випадку приклад , який додає затримку, обробляючи всі input-події синхронно. За промовчанням GNOME також має менеджер вікон , які створює додатковий рівень буферизації, що впливає на пінг і додає щонайменше 8 мілісекунд затримки.
Швидкість прокручування
Наступний тест — це традиційна перевірка швидкості або смуги пропускання, яка вимірює, як швидко термінал може прокручувати сторінку, відображаючи велику кількість тексту на екрані. Механіка тіста варіюється; оригінальний тест полягав у тому, щоб просто генерувати один і той же текстовий рядок за допомогою команди seq. Інші тести включають перевірку Томаса Е. Дікі (супроводжуючого xterm), в рамках якого багаторазово . У ще одному огляді продуктивності терміналів використовує рядок випадкових байтів у кодуванні base32, який виводиться в термінал за допомогою cat. Луу вважає такий тест «настільки марним еталоном, наскільки це можна собі уявити» і пропонує використовувати натомість відгук терміналу як основний показник. Дікі також називає свій тест, що вводить в оману. Проте обидва автори визнають, що пропускна спроможність вікна терміналу може бути проблемою. Луу виявив зависання Emacs Eshell при відображенні великих файлів, а Дікі оптимізував термінал, щоб позбутися візуальної повільності xtrerm. Тому в цьому тесті все ще є певний резон, але оскільки процес рендерингу сильно відрізняється від терміналу до терміналу, його можна використовувати як тестовий компонент для перевірки інших параметрів.
Тут ми бачимо, що rxvt і st вириваються вперед на тлі конкурентів, слідом йде набагато новий Alacritty, що розробляється з упором на швидкодію. Далі йдуть Xfce (родина VTE) та Konsole, які працюють майже вдвічі швидше. Останнім йде xterm з показником у п'ять разів повільніше за rxvt. Під час тесту xterm також сильно песикав, текст, що проходить, було важко розглянути, навіть якщо це був один і той же рядок. Konsole виявився швидким, але він часом «хитрив»: дисплей час від часу зависав, показуючи текст частково або не відображаючи його зовсім. Інші термінали відображали рядки чітко, включаючи st, Alacritty та rxvt.
Дікі пояснює, що відмінності у продуктивності пов'язані з дизайном буферів прокручування в різних терміналах. Зокрема, він звинувачує rxvt та інші термінали в тому, що вони «не дотримуються загальних правил»:
«На відміну від xterm, rxvt не намагався відобразити всі оновлення. Якщо він відстає, він відмовиться від деяких оновлень, щоб надолужити втрачене. Це вплинуло на уявну швидкість прокручування, ніж організацію внутрішньої пам'яті. Один недолік полягав у тому, що анімація ASCII була дещо неточною».
Щоб виправити цю повільність xterm, Дікі пропонує використовувати ресурс , що дозволяє xterm відкидати деякі оновлення екрана, щоб не відставати від потоку. Мої випробування підтверджують, що fastScroll підвищує продуктивність і виводить xterm на один рівень з rxvt. Це, однак, досить грубий милиця, як пояснює сам Дікі: «іноді xterm — як і konsole — здається, зупиняється, оскільки він чекає на новий набор оновлень екрану після того, як деякі з них були видалені». У цьому ключі здається, що інші термінали знайшли найкращий компроміс між швидкістю та цілісністю дисплея.
Споживання ресурсів
Незалежно від доцільності розгляду швидкості прокручування як показника продуктивності, цей тест дозволяє імітувати навантаження на термінали, що, у свою чергу, дозволяє нам вимірювати інші параметри, такі як використання пам'яті або диска. Метрики були отримані шляхом запуску вказаного тесту далі під моніторингом процесу Python Він збирав дані лічильників для ru_maxrss, суму ru_oublock и ru_inblock та простий таймер часу.
У цьому тесті ST займає перше місце з найменшим середнім обсягом пам'яті, що споживається, в 8 МБ, що не дивно, якщо врахувати, що основна ідея проекту - це простота. Трохи більше споживає mlterm, xterm та rxvt – близько 12 МБ. Ще один помітний результат Alacritty, якому для роботи потрібно 30 МБ. Потім йдуть термінали сімейства VTE із показниками від 40 до 60 МБ, що досить багато. Подібне споживання можна пояснити тим, що ці термінали використовують бібліотеки вищого рівня, наприклад GTK. Konsole йде останнім із колосальним споживанням 65 МБ пам'яті під час тестів, хоч і це можна виправдати його досить широким набором функцій.
Порівняно з попередніми результатами, отриманими десять років тому, всі програми почали споживати помітно більше пам'яті. Раніше 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