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