Манай орчуулгын товчооны хэдэн үг: ихэвчлэн хүн бүр хамгийн сүүлийн үеийн материал, хэвлэлийг орчуулахыг хичээдэг бөгөөд бид ч үл хамаарах зүйл биш юм. Гэхдээ терминал нь долоо хоногт нэг удаа шинэчлэгддэг зүйл биш юм. Тиймээс бид танд зориулж 2018 оны хавар хэвлэгдсэн Антуан Бопрэгийн нийтлэлийг орчуулав: орчин үеийн жишгээр нэлээд "настай" байсан ч бидний бодлоор уг материал нь ач холбогдлоо алдаагүй байна. Нэмж дурдахад, энэ нь анхандаа хоёр нийтлэлийн цуврал байсан боловч бид тэдгээрийг нэг том нийтлэл болгон нэгтгэхээр шийдсэн.
Терминалууд нь компьютерийн түүхэнд онцгой байр суурь эзэлдэг ч сүүлийн хэдэн арван жилд график интерфэйсүүд хаа сайгүй тархсан тул командын мөртэй зэрэгцэн амьдрахаас өөр аргагүй болсон. өөрсдөө сольсон , энэ нь эргээд цоолбортой карт болон унтраалга дээр суурилсан системийн өөрчлөлт байв. Орчин үеийн түгээлтүүд нь янз бүрийн хэлбэр, өнгөт терминалын эмуляторуудтай ирдэг. Олон хүмүүс ажлын орчноосоо олгосон стандарт терминалд сэтгэл хангалуун байдаг ч зарим нь дуртай бүрхүүл эсвэл текст засварлагчийг ажиллуулахын тулд үнэхээр чамин программ хангамж ашигладаг. Гэхдээ энэ өгүүллээс харахад бүх терминалууд ижил дүр төрхөөр бүтээгдээгүй: тэдгээр нь ажиллагаа, хэмжээ, гүйцэтгэлийн хувьд ихээхэн ялгаатай байдаг.
Зарим терминалууд нь аюулгүй байдлын цоорхойтой бөгөөд тэдгээрийн ихэнх нь цонхны интерфейсийг дэмжихээс эхлээд скрипт бичих хүртэл огт өөр функцтэй байдаг. Хэдийгээр бид , энэ нийтлэл нь уншигчдад 2018 онд аль терминалыг ашиглахыг тодорхойлоход туслах өмнөх материалын шинэчлэл юм. Өгүүллийн эхний хагаст онцлог шинж чанаруудыг харьцуулж, хоёрдугаар хагаст гүйцэтгэлийг үнэлдэг.
Миний хянаж үзсэн терминалууд энд байна:
Эдгээр нь хамгийн сүүлийн үеийн хувилбарууд биш байж магадгүй, учир нь би үүнийг бичиж байх үед тогтвортой бүтээцүүдээр хязгаарлагдаж байсан бөгөөд үүнийг Debian 9 эсвэл Fedora 27 дээр ашиглах боломжтой байсан. Ганц үл хамаарах зүйл бол Alacritty юм. Энэ нь GPU хурдасгасан терминалуудын удам бөгөөд энэ даалгаварт зориулсан ер бусын, шинэ хэлээр бичигдсэн байдаг - Rust. Би өөрийн үнэлгээнээс вэб терминалуудыг хассан (үүнд ), учир нь урьдчилсан туршилтууд маш муу гүйцэтгэлийг харуулсан.
Юникод дэмжлэг
Би Юникод дэмжлэгтэйгээр туршилтуудаа эхлүүлсэн. Терминалуудын эхний туршилт нь Юникод мөрийг харуулах явдал байв : “é, Δ, И, ק, م, ๗, あ, 叶, 葉 болон 말.” Энэхүү энгийн тест нь терминал дэлхий даяар зөв ажиллаж чадах эсэхийг харуулдаг. xterm терминал нь араб тэмдэгтийг харуулахгүй анхдагч тохиргоонд:
Анхдагч байдлаар, xterm нь сонгодог "тогтмол" фонтыг ашигладаг бөгөөд үүний дагуу , "1997 оноос хойш их хэмжээний Юникод хамрах хүрээтэй". Энэ фонтанд ямар нэг зүйл болж байгаа бөгөөд энэ нь тэмдэгтийг хоосон хүрээ болгон харуулахад хүргэдэг бөгөөд зөвхөн текстийн фонтыг 20+ оноо болгон нэмэгдүүлэхэд л тэмдэгт зөв гарч эхэлдэг. Гэсэн хэдий ч энэхүү "засах" нь бусад Юникод тэмдэгтүүдийн дэлгэцийг эвддэг:
Эдгээр дэлгэцийн агшинг Fedora 27 дээр авсан, учир нь энэ нь Debian 9-ээс илүү сайн үр дүнд хүрсэн тул терминалуудын зарим хуучин хувилбарууд (ялангуяа mlterm) фонтуудыг зөв зохицуулж чадахгүй байв. Аз болоход үүнийг дараагийн хувилбаруудад зассан.
Одоо xterm дээр мөр хэрхэн харагдаж байгааг анзаараарай. Энэ нь тэмдэг Mem болон дараах семит гэж болж байна RTL загварын скриптүүдийг үзнэ үү (), техникийн хувьд тэдгээрийг баруунаас зүүн тийш харуулах ёстой. Firefox 57 гэх мэт вэб хөтчүүд дээрх мөрийг зөв зохицуулдаг. RTL текстийн энгийн хувилбар бол ""Еврей хэлээр (). дараах зүйлийг хэлж байна.
"Компьютерийн олон программууд хоёр чиглэлтэй текстийг зөв харуулах боломжгүй. Жишээлбэл, "Сара" гэсэн еврей нэр нь sin (ש) (баруун талд харагдана), дараа нь resh (ר), эцэст нь тэр (ה) (зүүн талд гарч ирэх ёстой) гэсэн тэмдэгтүүдээс бүрддэг."
Олон терминалууд энэ шалгалтанд тэнцээгүй: Alacritty, VTE-ээс гаралтай Gnome болон XFCE терминалууд, urxvt, st болон xterm нь "Sara" гэж урвуу дарааллаар харуулдаг бөгөөд энэ нь бид нэрийг "Арас" гэж бичсэн мэт.
Хоёр чиглэлтэй текстийн өөр нэг асуудал бол тэдгээрийг ямар нэгэн байдлаар тохируулах шаардлагатай байдаг, ялангуяа RTL болон LTR текстийг холих үед. RTL скриптүүд нь терминалын цонхны баруун талаас ажиллах ёстой, гэхдээ LTR англи хэл дээр анхдагчаар тохируулагдсан терминалуудад юу тохиолдох вэ? Тэдгээрийн ихэнх нь тусгай механизмгүй бөгөөд бүх текстийг зүүн тийш (Konsole-д оруулаад) зэрэгцүүлдэг. Үл хамаарах зүйл бол стандартыг дагаж мөрддөг, ийм мөрүүдийг баруун тийш тэгшилдэг pterm болон mlterm юм.
Оруулах хамгаалалт
Миний тодорхойлсон дараагийн чухал шинж чанар бол оруулахаас хамгаалах хамгаалалт юм. Хэдийгээр шившлэгүүд нь дараахь зүйлийг мэддэг.
$ curl http://example.com/ | shЭдгээр нь кодыг гүйцэтгэх түлхэх командууд бөгөөд нарийн шалгасны дараа ч вэб хөтчөөс хуулах, буулгах үед далд командууд консол руу сэм нэвтэрдэг гэдгийг цөөхөн хүн мэддэг. Энэ тушаал нь ямар гэм хоргүй болохыг гайхалтай харуулж байна:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitHorn-ийн вэбсайтаас терминал руу буулгахад ийм төвөг учруулж байна:
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Харамсалтай нь Horn-ийн туршилтын сайт нь текст форматаар дамжуулан энэ хамгаалалтыг хэрхэн даван туулж, хаалттай горимыг хугацаанаас нь өмнө ашиглахыг харуулж байна. Энэ нь зарим терминалууд өөрсдийнхөө хувилбарыг нэмэхээсээ өмнө escape дарааллыг зөв шүүдэггүй тул ажилладаг. Жишээлбэл, би консолын туршилтыг зөв тохируулсан ч амжилттай хийж чадаагүй .inputrc файл. Энэ нь дэмжигдээгүй програм эсвэл буруу тохируулагдсан бүрхүүлийн улмаас та өөрийн системийн тохиргоог амархан гэмтээж болно гэсэн үг юм. Энэ нь ялангуяа алсын серверт нэвтрэх үед маш аюултай бөгөөд тохиргооны нарийн ажиллагаа бага байдаг, ялангуяа танд ийм алсын машин байгаа бол.
Энэ асуудлыг шийдэх сайн шийдэл бол терминалыг баталгаажуулах залгаас юм urxvt, энэ нь зүгээр л шинэ мөр агуулсан текст оруулах зөвшөөрөл хүсдэг. Би Horn-ийн тайлбарласан текст халдлагын илүү найдвартай сонголтыг олсонгүй.
Таб болон профайл
Яг одоо алдартай функц бол таб-тай интерфейсийг дэмжих явдал бөгөөд бид үүнийг хэд хэдэн терминал агуулсан нэг терминалын цонх гэж тодорхойлох болно. Энэ функц нь өөр өөр терминалуудын хувьд өөр өөр байдаг бөгөөд уламжлалт xterm терминалууд нь табуудыг огт дэмждэггүй ч Xfce Terminal, GNOME Terminal, Konsole зэрэг илүү орчин үеийн терминалууд ийм функцтэй байдаг. Urxvt нь мөн табуудыг дэмждэг, гэхдээ зөвхөн залгаас ашигладаг бол. Гэхдээ табын дэмжлэгийн хувьд Терминатор бол маргаангүй удирдагч юм: энэ нь зөвхөн табуудыг дэмждэг төдийгүй терминалуудыг ямар ч дарааллаар байрлуулж чаддаг (доорх зургийг үз).
Терминаторын өөр нэг онцлог нь эдгээр табуудыг нэг дор "бүлэглэх" болон ижил товчлуурын даралтыг олон терминал руу нэгэн зэрэг илгээх чадвар бөгөөд олон сервер дээр нэгэн зэрэг бөөнөөр үйлдэгдэх бүдүүлэг хэрэглүүр болж өгдөг. Үүнтэй төстэй функцийг Консол дээр хэрэгжүүлсэн. Энэ функцийг бусад терминалуудад ашиглахын тулд та гуравдагч талын програм хангамжийг ашиглах ёстой , буюу .
Табууд нь профайлтай хослуулсан тохиолдолд маш сайн ажилладаг: жишээлбэл, та имэйлд зориулсан нэг таб, чат хийх өөр нэг табтай байж болно. Үүнийг Konsole Terminal болон GNOME Terminal сайн дэмждэг. Аль аль нь таб бүр өөрийн профайлыг автоматаар эхлүүлэх боломжийг олгодог. Терминатор нь мөн профайлыг дэмждэг боловч тодорхой табыг нээх үед зарим програмыг автоматаар эхлүүлэх арга замыг би олж чадсангүй. Бусад терминалуудад "профайл" гэсэн ойлголт огт байдаггүй.
Ruffles
Энэ өгүүллийн эхний хэсэгт миний ярих хамгийн сүүлчийн зүйл бол терминалуудын дүр төрх юм. Жишээлбэл, GNOME, Xfce болон urxvt нь ил тод байдлыг дэмждэг боловч сүүлийн үед арын зургийн дэмжлэгийг зогсоож, зарим хэрэглэгчид терминал руу шилжихээс өөр аргагүй болсон. . Би хувьдаа үүнд сэтгэл хангалуун байдаг бөгөөд энэ нь энгийн зүйл юм Эх сурвалж, энэ нь urxvt-ийн дэвсгэр өнгөний үндсэн багцыг тохируулдаг. Гэсэн хэдий ч стандарт бус өнгөт сэдэв нь асуудал үүсгэж болно. Жишээлбэл, програмуудтай и , учир нь тэд аль хэдийн өөрсдийн өнгө хэрэглэдэг.
өнгийг дэмждэггүй байсан бөгөөд шинэ нь ихэвчлэн 256 өнгөт палитраар хязгаарлагддаг байв. Терминалуудыг загварчлах дэвшилтэт хэрэглэгчдийн хувьд бүрхүүлийн сануулга эсвэл төлөвийн самбарыг нарийн төвөгтэй байдлаар дүрслэх нь ядаргаатай хязгаарлалт байж болно. аль терминалууд "Жинхэнэ өнгө"-г дэмждэг болохыг хянадаг. Миний туршилтууд st, Alacritty болон VTE дээр суурилсан терминалууд нь True Color-ийг төгс дэмждэг болохыг баталж байна. Бусад терминалууд энэ талаар тийм ч сайн ажилладаггүй бөгөөд үнэндээ 256 өнгийг ч харуулдаггүй. 256 өнгөний палитраараа үүнийг сайн гүйцэтгэдэг GNOME терминалууд дахь True Color дэмжлэг, st болон xterm болон urxvt хоёрын ялгааг доороос харж болно, энэ нь шалгалтанд тэнцэхгүй төдийгүй зарим нэг анивчдаг тэмдэгтүүдийг харуулдаг.
Зарим терминалууд холбоосыг товших боломжтой болгохын тулд URL загварт зориулсан текстийг шинжилдэг. Энэ нь VTE-ээс үүсэлтэй бүх терминалуудад хамаатай бол urxvt нь URL-г товшилтоор эсвэл гарын товчлолыг ашиглан хувиргах тусгай залгаас шаарддаг. Миний туршиж үзсэн бусад терминалууд URL-уудыг өөр аргаар харуулдаг.
Эцэст нь терминалуудын шинэ чиг хандлага бол гүйлгэх буферийн сонголт юм. Жишээлбэл, st нь гүйлгэх буфергүй; Хэрэглэгч tmux болон гэх мэт терминалын мультиплексер ашиглах болно гэж таамаглаж байна .
Alacritty мөн backscroll буфер дутагдалтай, гэхдээ Энэ сэдвээр хэрэглэгчдийн "өргөн санал хүсэлт"-ийн ачаар дэмжлэг үзүүлэв. Эдгээр эхлэлээс гадна миний туршиж үзсэн терминал бүр урвуу гүйлгэхийг дэмждэг.
Дэд дүн
Материалын хоёр дахь хэсэгт (эх хувилбарт эдгээр нь хоёр өөр нийтлэл байсан - ойролцоогоор. эгнээ) бид гүйцэтгэл, санах ойн ашиглалт, хоцролт зэргийг харьцуулах болно. Гэхдээ энэ терминалуудын зарим нь ноцтой дутагдалтай байгааг бид аль хэдийн харж байна. Жишээлбэл, RTL скрипттэй тогтмол ажилладаг хэрэглэгчид mlterm болон pterm-ийг анхаарч үзэхийг хүсч болно, учир нь тэд ижил төстэй ажлуудыг бусдаас илүү сайн гүйцэтгэдэг. Консол бас сайн тоглосон. RTL скрипттэй ажилладаггүй хэрэглэгчид өөр зүйл сонгож болно.
Хорлонтой код оруулахаас хамгаалах тал дээр urxvt нь энэ төрлийн халдлагаас хамгаалах тусгай хэрэгжүүлэлтээрээ бусдаас ялгардаг бөгөөд энэ нь надад үнэхээр тохиромжтой юм шиг санагддаг. Зарим хонх, шүгэл хайж байгаа хүмүүсийн хувьд Консолыг үзэх нь зүйтэй юм. Эцэст нь хэлэхэд, VTE нь өнгөний дэмжлэг, URL таних гэх мэтийг баталгаажуулдаг терминалуудын маш сайн суурь гэдгийг тэмдэглэх нь зүйтэй. Эхлээд харахад таны дуртай орчинд ирдэг анхдагч терминал нь бүх шаардлагыг хангасан байж болох ч гүйцэтгэлийг ойлгох хүртэл энэ асуултыг нээлттэй үлдээе.
Яриагаа үргэлжлүүлье
Ерөнхийдөө терминалуудын гүйцэтгэл нь өөрөө хэцүү асуудал мэт санагдаж болох ч зарим нь ийм үндсэн төрлийн програм хангамжийн хувьд гайхалтай өндөр хоцролттой байдаг. Дараа нь бид уламжлалт байдлаар "хурд" гэж нэрлэгддэг (үнэндээ энэ бол гүйлгэх хурд) болон терминалын санах ойн хэрэглээг (энэ нь өнөөдөр хэдэн арван жилийн өмнөх шиг тийм ч чухал биш гэдгийг анхааруулж) авч үзэх болно.
Хойшлуулах
Терминалын гүйцэтгэлийг сайтар судалсны дараа би энэ талаархи хамгийн чухал параметр бол хоцролт (ping) юм гэсэн дүгнэлтэд хүрсэн. Түүний нийтлэлд Павел Фатин янз бүрийн текст засварлагчдын хоцролтыг судалж, энэ талаархи терминалууд нь хамгийн хурдан текст засварлагчдаас удаан байж магадгүй гэдгийг сануулав. Энэ зөвлөгөө намайг эцэст нь өөрийнхөө туршилтыг явуулж, энэ нийтлэлийг бичихэд хүргэсэн юм.
Гэхдээ хоцролт гэж юу вэ, яагаад ийм чухал вэ? Фатин нийтлэлдээ үүнийг "товчлуур дарах болон холбогдох дэлгэцийн шинэчлэлтийн хоорондох саатал" гэж тодорхойлж, иш татав. , үүнд: "Компьютерийн дэлгэц дээрх харааны санал хүсэлтийн саатал нь бичгийн хүний зан байдал, сэтгэл ханамжид чухал нөлөө үзүүлдэг."
Энэ пинг нь сэтгэл ханамжаас илүү гүнзгий үр дагавартай гэж Фатин тайлбарлав: "Бичих нь удааширч, илүү олон алдаа гарч, нүд, булчингийн хурцадмал байдал нэмэгддэг." Өөрөөр хэлбэл, их хэмжээний саатал нь үсгийн алдаа, кодын чанар буурахад хүргэдэг бөгөөд энэ нь тархинд танин мэдэхүйн нэмэлт ачаалал үүсгэдэг. Гэхдээ хамгийн муу зүйл бол пинг нь "нүд, булчингийн ачааллыг нэмэгдүүлдэг" гэсэн үг юм. Ирээдүйд (Зохиогч нь нүдний булчин, нуруу, гар, мэдээжийн хэрэг алсын хараатай холбоотой асуудлуудыг хэлдэг бололтой - ойролцоогоор. эгнээ) давтагдах стрессийн улмаас.
Эдгээр нөлөөллийн зарим нь удаан хугацааны туршид мэдэгдэж байсан бөгөөд үр дүн нь 1976 онд Эргономикс сэтгүүлд нийтлэгдсэн бөгөөд 100 миллисекунд удаашрах нь "бичих хурдыг ихээхэн бууруулдаг" гэжээ. Саяхан GNOME хэрэглэгчийн гарын авлагыг танилцууллаа 10 миллисекундэд, хэрэв та цааш явбал, дараа нь 1 миллисекунд хамгийн тохиромжтой гэдгийг харуулж байна.
Фатин текст засварлагч дээр туршилтаа явуулсан; хэмээх зөөврийн хэрэгсэл бүтээжээ , үүнийг би терминал эмуляторууд дээр ping-г туршиж үздэг байсан. Туршилтыг загварчлалын горимд явуулсан гэдгийг санаарай: бодит байдал дээр бид оролт (гар, USB хянагч гэх мэт) болон гаралтын (видео картын буфер, дэлгэц) хоцролтыг хоёуланг нь харгалзан үзэх шаардлагатай. Фатины хэлснээр ердийн тохиргоонд 20 мс орчим байдаг. Хэрэв танд тоглоомын тоног төхөөрөмж байгаа бол ердөө 3 миллисекундэд энэ үзүүлэлтэд хүрч чадна. Бидэнд ийм хурдан техник хангамж байгаа тул програм нь өөрийн хоцролтыг нэмэх шаардлагагүй. Фатины зорилго бол програмын хоцролтыг 1 миллисекунд болгох, тэр ч байтугай залгахад хүрэх явдал юм шиг .
Миний хэмжилтийн үр дүн, мөн Фатины зарим үр дүн нь миний туршилт түүний туршилтуудтай тохирч байгааг харуулахын тулд энд байна.
Миний гайхшруулсан хамгийн эхний зүйл бол xterm, mlterm зэрэг хуучин програмуудын хариу өгөх хугацаа илүү сайн байсан. Бүртгэлийн хамгийн муу хоцролттой (2,4 мс) тэд орчин үеийн хамгийн хурдан терминалаас (st-ийн хувьд 10,6 мс) илүү сайн ажилласан. Орчин үеийн ямар ч терминал 10 миллисекундын босгоос доош ордоггүй. Ялангуяа Alacritty нь "хамгийн хурдан терминал эмулятор" гэсэн шаардлагыг хангаж чадахгүй байгаа ч 2017 онд анх хянаснаас хойш оноо нь сайжирсан байна. Үнэхээр төслийн зохиогчид мөн дэлгэцийг сайжруулахаар ажиллаж байна. GTK3 ашигладаг Vim нь GTK2-тэй харьцуулахад удаашралтай гэдгийг тэмдэглэх нь зүйтэй. Эндээс бид GTK3 нь нэмэлт хоцролт үүсгэдэг гэж дүгнэж болох бөгөөд энэ нь түүнийг ашигладаг бусад бүх терминалуудад (Terminator, Xfce4 Terminal болон GNOME Terminal) тусгагдсан байдаг.
Гэсэн хэдий ч ялгаа нь нүдэнд харагдахгүй байж болно. Фатины тайлбарласнаар, "энэ нь танд нөлөө үзүүлэхийн тулд та хойшлуулсныг мэдэх шаардлагагүй." Фатин мөн стандарт хазайлтын талаар анхааруулж байна: "хоцрогдол (житрэх) нь урьдчилан таамаглах боломжгүйгээс болж нэмэлт стресс үүсгэдэг."
Дээрх графикийг цэвэр Debian 9 (сунгах) дээр авсан болно . Энэ орчин нь хоцрогдлын тестийн хамгийн сайн үр дүнг гаргадаг. Эндээс харахад GNOME нь бүх хэмжилтийн хувьд нэмэлт 20 мс пинг үүсгэдэг. Үүний боломжит тайлбар нь оролтын үйл явдлуудыг синхроноор боловсруулдаг програмууд байдаг. Фатин ийм тохиолдлын жишээг өгдөг , энэ нь оролтын бүх үйл явдлыг синхроноор боловсруулах замаар саатал нэмнэ. Анхдагч байдлаар GNOME нь цонхны менежертэй хамт ирдэг , энэ нь буферийн нэмэлт давхарга үүсгэдэг бөгөөд энэ нь ping-д нөлөөлж, дор хаяж 8 миллисекунд хоцрогдол нэмдэг.
Гүйлгэх хурд
Дараагийн тест нь уламжлалт "хурд" эсвэл "зурвасын өргөн" тест бөгөөд дэлгэцэн дээр их хэмжээний текстийг харуулах үед терминал хуудсыг хэр хурдан гүйлгэж болохыг хэмждэг. Туршилтын механик нь өөр өөр байдаг; анхны тест нь seq командыг ашиглан ижил текстийн мөрийг үүсгэх явдал байв. Бусад сорилтод Томас Э.Дикки (xterm засварлагч) тестийг давтан хийдэг . Терминалын гүйцэтгэлийн өөр нэг тоймд нь санамсаргүй байтаас бүрдэх base32 кодлогдсон мөрийг ашигладаг бөгөөд энэ нь cat ашиглан терминал руу гарна. Луу ийм тестийг "хүний төсөөлж байгаа шиг ашиггүй жишиг" гэж үзэж, оронд нь терминалын хариултыг үндсэн хэмжигдэхүүн болгон ашиглахыг санал болгож байна. Дики мөн туршилтаа төөрөгдүүлсэн гэж нэрлэдэг. Гэсэн хэдий ч, терминалын цонхны зурвасын өргөн нь асуудал байж болохыг зохиогч хоёулаа хүлээн зөвшөөрдөг. Луу том файлуудыг харуулах үед Emacs Eshell хөлддөг болохыг олж мэдсэн бөгөөд Дики xtrerm-ийн харааны сулралыг арилгахын тулд терминалыг оновчтой болгосон. Тиймээс энэ туршилтын давуу тал байсаар байгаа ч дүрслэх үйл явц нь терминалаас терминал хүртэл өөр өөр байдаг тул үүнийг бусад параметрүүдийг шалгах тестийн бүрэлдэхүүн хэсэг болгон ашиглаж болно.
Эндээс бид rxvt болон st pull-ийг өрсөлдөөнөөс түрүүлж, дараа нь гүйцэтгэлд анхаарлаа төвлөрүүлэн бүтээсэн илүү шинэ Alacritty-г харж байна. Дараа нь Xfce (VTE family) болон Konsole нь бараг хоёр дахин хурдан байдаг. Сүүлийнх нь xterm буюу rxvt-ээс тав дахин удаан. Туршилтын явцад xterm мөн маш их долгионтой байсан тул дамжуулж буй текст нь ижил мөр байсан ч харахад хэцүү болгосон. Консол нь хурдан байсан ч заримдаа төвөгтэй байдаг: дэлгэц үе үе хөлддөг, хэсэгчилсэн текстийг харуулах эсвэл огт харуулахгүй байх болно. Бусад терминалууд нь st, Alacritty, rxvt зэрэг мөрүүдийг тодорхой харуулсан.
Гүйцэтгэлийн ялгаа нь өөр өөр терминал дахь гүйлгэх буферийн дизайнтай холбоотой гэж Дики тайлбарлав. Ялангуяа тэрээр rxvt болон бусад терминалуудыг "ерөнхий дүрмийг дагаж мөрдөөгүй" гэж буруутгаж байна.
"Xterm-ээс ялгаатай нь rxvt нь бүх шинэчлэлтийг харуулахыг оролдоогүй. Хэрэв энэ нь хоцрох юм бол түүнийг гүйцэхийн тулд зарим шинэчлэлтүүдээс татгалзах болно. Энэ нь дотоод санах ойн зохион байгуулалтаас илүү гүйлгэх хурдад илүү нөлөөлсөн. Нэг сул тал нь ASCII хөдөлгөөнт дүрс нь тодорхой бус байсан."
Энэ удаашралыг засахын тулд Дики эх сурвалжийг ашиглахыг санал болгож байна , xterm-д урсгалыг дагаж мөрдөхийн тулд зарим дэлгэцийн шинэчлэлтүүдийг хаях боломжийг олгодог. Миний туршилтууд fastScroll нь гүйцэтгэлийг сайжруулж, xterm-ийг rxvt-тэй эн зэрэгцүүлдэг болохыг баталж байна. Гэсэн хэдий ч энэ бол нэлээд бүдүүлэг суга таяг бөгөөд үүнийг Дики өөрөө тайлбарлаж байна: "заримдаа xterm - konsole шиг - заримыг нь устгасны дараа дэлгэцийн шинэ шинэчлэлтийг хүлээж зогсох мэт санагддаг." Энэ утгаараа бусад терминалууд хурд болон дэлгэцийн бүрэн бүтэн байдлын хоорондох хамгийн сайн тохирлыг олсон бололтой.
Нөөцийн хэрэглээ
Гүйлгэх хурдыг гүйцэтгэлийн хэмжүүр гэж үзэх нь утга учиртай эсэхээс үл хамааран энэхүү тест нь терминал дээрх ачааллыг дуурайлган хийх боломжийг олгодог бөгөөд энэ нь эргээд санах ой, дискний ашиглалт зэрэг бусад параметрүүдийг хэмжих боломжийг олгодог. Заасан тестийг ажиллуулснаар хэмжигдэхүүнүүдийг олж авсан SEQ Python процессын хяналтын дор. Тэр тоолуурын мэдээллийг цуглуулсан нь ru_maxrss, хэмжээ ru_oublock и ru_inblock мөн энгийн таймер.
Энэхүү туршилтанд ST нь хамгийн бага санах ойн хэрэглээ буюу 8 МБ-аар эхний байрыг эзэлдэг бөгөөд энэ нь дизайны гол санаа нь энгийн байдал гэдгийг бодоход гайхмаар зүйл биш юм. mlterm, xterm болон rxvt нь арай илүү зарцуулдаг - ойролцоогоор 12 MB. Өөр нэг анхаарал татахуйц үр дүн бол ажиллахын тулд 30 MB шаарддаг Alacritty юм. Дараа нь 40-60 МБ хэмжээтэй VTE гэр бүлийн терминалууд байдаг бөгөөд энэ нь нэлээд их юм. Энэхүү хэрэглээг эдгээр терминалууд нь дээд түвшний номын сангууд, жишээлбэл, GTK ашигладагтай холбон тайлбарлаж болно. Консол нь туршилтын явцад 65 МБ санах ойн хэрэглээгээрээ хамгийн сүүлд ордог ч үүнийг маш өргөн хүрээний функцээр зөвтгөж болно.
Арван жилийн өмнө олж авсан үр дүнтэй харьцуулахад бүх програмууд мэдэгдэхүйц илүү их санах ой зарцуулж эхэлсэн. Xterm нь өмнө нь 4 MB шаарддаг байсан бол одоо дөнгөж эхлүүлэхэд 15 MB шаардлагатай. Rxvt-ийн хэрэглээ ижил төстэй өсөлттэй байгаа бөгөөд одоо хайрцагнаас 16 МБ шаардлагатай. Xfce Терминал 34 МБ багтаамжтай бөгөөд энэ нь өмнөхөөсөө гурав дахин том боловч GNOME терминалд ердөө 20 МБ шаардлагатай. Мэдээжийн хэрэг, өмнөх бүх туршилтыг 32 битийн архитектур дээр хийсэн. LCA 2012 дээр Rusty Russell , санах ойн хэрэглээний өсөлтийг тайлбарлах өөр олон нарийн шалтгаанууд байдаг. Үүнийг хэлэхэд бид одоо гигабайт санах ойтой цаг үед амьдарч байгаа тул бид ямар нэгэн байдлаар зохицуулах болно.
Гэсэн хэдий ч терминал шиг үндсэн зүйлд илүү их санах ой хуваарилах нь нөөцийг дэмий үрсэн хэрэг гэдгийг би мэдрэхгүй байхын аргагүй юм. Эдгээр программууд нь хамгийн жижиг нь байх ёстой, ямар ч "хайрцаг", тэр ч байтугай гутлын хайрцаг дээр ажиллах чадвартай байх ёстой, хэрэв бид хэзээ нэгэн цагт Линукс системээр тоноглогдсон байх ёстой (мөн энэ нь тийм байх болно гэдгийг та мэднэ) ) . Гэхдээ эдгээр тоонуудын тусламжтайгаар санах ойн хэрэглээ нь хамгийн хөнгөн бөгөөд хязгаарлагдмал боломжуудаас бусад олон терминал ажиллуулдаг ямар ч орчинд ирээдүйд асуудал болно. Үүнийг нөхөхийн тулд GNOME Terminal, Konsole, urxvt, Terminator болон Xfce Terminal нь санах ойн хэрэглээг хязгаарлаж, олон терминалыг нэг процессоор удирдах боломжийг олгодог Daemon горимтой.
Туршилтын үеэр би дискний унших-бичихтэй холбоотой өөр нэг гэнэтийн үр дүнд хүрсэн: би энд юу ч харахгүй гэж бодож байсан ч зарим терминалууд хамгийн их хэмжээний өгөгдлийг диск рүү бичдэг болох нь тогтоогдсон. Тиймээс VTE номын сан нь дискэн дээр гүйлгэх буферийг хадгалдаг (энэ функц , мөн энэ нь хэвээр байна). Гэхдээ хуучин хэрэгжүүлэлтүүдээс ялгаатай нь одоо ядаж энэ өгөгдлийг AES256 GCM ашиглан шифрлэсэн болно.). Гэвч үндэслэлтэй асуулт гарч ирнэ: МСҮТ-ийн номын сан нь хэрэгжүүлэхэд ийм стандарт бус хандлагыг шаарддаг онцгой зүйл юу вэ...
дүгнэлт
Өгүүллийн эхний хэсэгт бид VTE-д суурилсан терминалууд нь сайн функцуудтай болохыг олж мэдсэн боловч одоо энэ нь гүйцэтгэлийн зарим зардалтай байгааг бид харж байна. Одоо санах ой нь асуудал биш, учир нь бүх VTE терминалуудыг Демон процессоор удирдаж болох бөгөөд энэ нь тэдний хоолны дуршилыг хязгаарладаг. Гэсэн хэдий ч RAM болон цөмийн буферийн хэмжээгээр физик хязгаарлалттай хуучин системүүд нь хамаагүй бага нөөц зарцуулдаг тул терминалуудын өмнөх хувилбаруудыг ашиглах шаардлагатай хэвээр байж магадгүй юм. Хэдийгээр VTE терминалууд дамжуулах чадварын (гүйлгэх) туршилтыг сайн гүйцэтгэсэн ч дэлгэцийн хоцролт нь GNOME хэрэглэгчийн гарын авлагад заасан босго хэмжээнээс давсан байна. VTE хөгжүүлэгчид үүнийг анхаарч үзэх хэрэгтэй. Хэрэв бид шинэхэн Линукс хэрэглэгчид ч гэсэн терминалтай тулгарах нь гарцаагүй гэдгийг харгалзан үзвэл тэд үүнийг илүү хэрэглэгчдэд ээлтэй болгож чадна. Туршлагатай инээдмийн хувьд үндсэн терминалаас шилжих нь нүдний ядаргаа багасч, урт хугацааны ажлын улмаас ирээдүйд ажилтай холбоотой гэмтэл, өвчнөөс зайлсхийх боломжтой гэсэн үг юм. Харамсалтай нь зөвхөн хуучин xterm болон mlterm нь биднийг 10 миллисекундын ид шидийн ping босгонд хүргэдэг бөгөөд энэ нь олон хүмүүсийн хувьд хүлээн зөвшөөрөгдөхгүй юм.
Линукс график орчныг хөгжүүлснээр хөгжүүлэгчид хэд хэдэн буулт хийх шаардлагатай болсныг жишиг хэмжилтүүд харуулсан. Зарим хэрэглэгчид ердийн цонхны менежерүүдийг үзэхийг хүсч магадгүй, учир нь тэдгээр нь пинг багасгах боломжийг олгодог. Харамсалтай нь Wayland-ийн хоцролтыг хэмжих боломжгүй байсан: миний ашигласан Typometer программыг Wayland бусад цонхнууд дээр тагнуул хийхээс урьдчилан сэргийлэх зорилгоор бүтээсэн. Wayland compositing нь X.org-ээс илүү сайн ажилладаг гэж найдаж байна, мөн ирээдүйд хэн нэгэн энэ орчинд хоцролтыг хэмжих арга олно гэж найдаж байна.
Эх сурвалж: www.habr.com