ტერმინალის ემულატორების მიმოხილვა

რამდენიმე სიტყვა ჩვენი მთარგმნელობითი ბიუროდან: როგორც წესი, ყველა ცდილობს თარგმნოს უახლესი მასალები და პუბლიკაციები და ჩვენ არ ვართ გამონაკლისი. მაგრამ ტერმინალები არ არის ის, რაც განახლდება კვირაში ერთხელ. ამიტომ, ჩვენ ვთარგმნეთ თქვენთვის ანტუან ბოპრეს სტატია, რომელიც გამოქვეყნდა 2018 წლის გაზაფხულზე: მიუხედავად თანამედროვე სტანდარტებით მნიშვნელოვანი „ასაკისა“, ჩვენი აზრით, მასალამ საერთოდ არ დაკარგა აქტუალობა. გარდა ამისა, ეს თავდაპირველად ორი სტატიისგან შემდგარი სერია იყო, მაგრამ ჩვენ გადავწყვიტეთ მათი გაერთიანება ერთ დიდ პოსტად.

ტერმინალებს განსაკუთრებული ადგილი უკავია კომპიუტერის ისტორიაში, მაგრამ ბოლო ათწლეულების განმავლობაში ისინი იძულებულნი გახდნენ გადარჩნენ ბრძანების ხაზთან ერთად, რადგან გრაფიკული ინტერფეისები საყოველთაო გახდა. ტერმინალის ემულატორები შეცვალეს საკუთარი ტექნიკის ძმები, რომელიც, თავის მხრივ, წარმოადგენდა სისტემების მოდიფიკაციას დაფუძნებული პუნჩირებული ბარათებისა და გადართვის გადამრთველებზე. თანამედროვე დისტრიბუციებს გააჩნიათ სხვადასხვა ფორმის და ფერის ტერმინალის ემულატორები. და მიუხედავად იმისა, რომ ბევრი კმაყოფილია სამუშაო გარემოს მიერ მოწოდებული სტანდარტული ტერმინალით, ზოგი ამაყად იყენებს ეგზოტიკურ პროგრამულ უზრუნველყოფას საყვარელი გარსის ან ტექსტური რედაქტორის გასაშვებად. მაგრამ, როგორც ამ სტატიიდან დავინახავთ, ყველა ტერმინალი არ შეიქმნა ერთი და იგივე სურათით: ისინი ძალიან განსხვავდებიან ფუნქციონალურობით, ზომითა და შესრულებით.

ზოგიერთ ტერმინალს აქვს სრულიად გასაკვირი უსაფრთხოების ხვრელები, გარდა ამისა, უმეტესობას აქვს სრულიად განსხვავებული ფუნქციების ნაკრები, დაწყებული ჩანართების ინტერფეისის მხარდაჭერიდან სკრიპტირებამდე. მიუხედავად იმისა, რომ ჩვენ დაათვალიერა ტერმინალის ემულატორები შორეულ წარსულში, ეს სტატია არის წინა მასალის განახლება, რომელიც დაეხმარება მკითხველს განსაზღვრონ რომელი ტერმინალი გამოიყენონ 2018 წელს. სტატიის პირველი ნახევარი ადარებს მახასიათებლებს, ხოლო მეორე ნახევარი აფასებს შესრულებას.

აქ არის ტერმინალები, რომლებიც გადავხედე:

ეს შეიძლება არ იყოს უახლესი ვერსიები, რადგან წერის დროს შემოვიფარგლებოდი სტაბილური ნაგებობებით, რომელთა გამოშვება შემეძლო Debian 9-ზე ან Fedora 27-ზე. ერთადერთი გამონაკლისი არის Alacritty. ის არის GPU-ით დაჩქარებული ტერმინალების შთამომავალი და დაწერილია ამ ამოცანისთვის უჩვეულო და ახალ ენაზე - Rust. მე გამოვრიცხე ვებ ტერმინალები ჩემი მიმოხილვიდან (მათ შორის, მათ შორის Electron), რადგან წინასწარმა ტესტებმა აჩვენა მათი უკიდურესად ცუდი შესრულება.

Unicode მხარდაჭერა

მე დავიწყე ჩემი ტესტები Unicode-ის მხარდაჭერით. ტერმინალების პირველი ტესტი იყო Unicode სტრიქონის ჩვენება ვიკიპედიის სტატიები: "é, Δ, И, ק, م, ๗, あ, 叶, 葉 და 말." ეს მარტივი ტესტი აჩვენებს, შეუძლია თუ არა ტერმინალი სწორად იმუშაოს მთელ მსოფლიოში. xterm ტერმინალი არ აჩვენებს არაბულ სიმბოლოს მემ ნაგულისხმევ კონფიგურაციაში:

ნაგულისხმევად, xterm იყენებს კლასიკურ "ფიქსირებულ" შრიფტს, რომელიც, შესაბამისად ისევ იგივე ვიკი, აქვს "არსებითი Unicode დაფარვა 1997 წლიდან". რაღაც ხდება ამ შრიფტში, რაც იწვევს სიმბოლოს ცარიელი ჩარჩოს სახით და მხოლოდ ტექსტის შრიფტის 20+ ქულამდე გაზრდის შემთხვევაში, სიმბოლო საბოლოოდ იწყებს სწორად ჩვენებას. თუმცა, ეს „გამოსწორება“ არღვევს უნიკოდის სხვა სიმბოლოების ჩვენებას:

ეს ეკრანის ანაბეჭდები გადაღებულია Fedora 27-ში, რადგან მან უკეთეს შედეგს იძლეოდა ვიდრე Debian 9, სადაც ტერმინალების ზოგიერთი ძველი ვერსია (კონკრეტულად mlterm) ვერ უმკლავდებოდა შრიფტებს სწორად. საბედნიეროდ, ეს დაფიქსირდა შემდგომ ვერსიებში.

ახლა დააკვირდით, როგორ არის ნაჩვენები ხაზი xterm-ში. გამოდის, რომ სიმბოლო მემ და შემდეგი სემიტური ქოფ მიმართეთ RTL სტილის სკრიპტებს (მარჯვნივ-მარცხნივ), ამიტომ ტექნიკურად ისინი უნდა იყოს ნაჩვენები მარჯვნიდან მარცხნივ. ვებ ბრაუზერები, როგორიცაა Firefox 57, სწორად ამუშავებენ ზემოთ მოცემულ ხაზს. RTL ტექსტის უფრო მარტივი ვერსია არის სიტყვა "სარა"ებრაულად (სარა). ვიკი გვერდი ორმხრივ ტექსტებზე ამბობს შემდეგს:

„ბევრ კომპიუტერულ პროგრამას არ შეუძლია ორმხრივი ტექსტის სწორად ჩვენება. მაგალითად, ებრაული სახელი "სარა" შედგება სიმბოლოებისგან sin (ש) (რომელიც ჩანს მარჯვნივ), შემდეგ resh (ר) და ბოლოს he (ה) (რომელიც მარცხნივ უნდა გამოჩნდეს).

ბევრი ტერმინალი ვერ ახერხებს ამ ტესტს: Alacritty, VTE-გან მიღებული Gnome და XFCE ტერმინალები, urxvt, st და xterm აჩვენებს "Sara"-ს საპირისპირო თანმიმდევრობით, თითქოს ჩვენ გვეწერა სახელი როგორც "Aras".

ორმხრივი ტექსტების კიდევ ერთი პრობლემა არის ის, რომ ისინი გარკვეულწილად უნდა იყოს გასწორებული, განსაკუთრებით მაშინ, როდესაც საქმე ეხება RTL და LTR ტექსტების შერევას. RTL სკრიპტები უნდა გაშვებული იყოს ტერმინალის ფანჯრის მარჯვენა მხრიდან, მაგრამ რა უნდა მოხდეს ტერმინალებისთვის, რომლებიც ნაგულისხმევია LTR English? მათ უმეტესობას არ გააჩნია რაიმე სპეციალური მექანიზმი და ასწორებს მთელ ტექსტს მარცხნივ (მათ შორის კონსოლში). გამონაკლისი არის pterm და mlterm, რომლებიც იცავენ სტანდარტებს და ასწორებენ ასეთ ხაზებს მარჯვნივ.

ჩასმის დაცვა

შემდეგი მნიშვნელოვანი მახასიათებელი, რომელიც მე დავადგინე, არის ჩასმის საწინააღმდეგო დაცვა. მიუხედავად იმისა, რომ საყოველთაოდ ცნობილია, რომ შელოცვები, როგორიცაა:

$ curl http://example.com/ | sh

არის კოდის შესრულების push ბრძანებები, ცოტამ თუ იცის, რომ ფარული ბრძანებები შეიძლება შევიდეს კონსოლში ვებ ბრაუზერიდან კოპირების და ჩასმისას, თუნდაც ფრთხილად შემოწმების შემდეგ. გადამოწმების საიტი ჯიანა ჰორნა ბრწყინვალედ აჩვენებს, თუ რამდენად უვნებელია ბრძანება:

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-ის გამოყენებით.

ფრჩხილიანი პასტის რეჟიმი აშკარად შექმნილია ასეთი თავდასხმების გასანეიტრალებლად. ამ რეჟიმში, ტერმინალები ათავსებენ ჩასმულ ტექსტს სპეციალურ გაქცევის წყვილში, რათა აცნობონ გარსს ტექსტის წარმოშობის შესახებ. ეს ეუბნება shell-ს, რომ მას შეუძლია იგნორირება გაუკეთოს სპეციალურ სიმბოლოებს, რომლებსაც შეიძლება შეიცავდეს ჩასმული ტექსტი. პატივცემული xterm-ის ყველა ტერმინალი მხარს უჭერს ამ ფუნქციას, მაგრამ Bracketed რეჟიმში ჩასმა მოითხოვს ტერმინალზე გაშვებული ჭურვის ან აპლიკაციის მხარდაჭერას. მაგალითად, პროგრამული უზრუნველყოფის გამოყენება GNU Readline (იგივე Bash), სჭირდება ფაილი ~/.inputrc:

set enable-bracketed-paste on

სამწუხაროდ, ჰორნის სატესტო საიტი ასევე გვიჩვენებს, თუ როგორ შეიძლება გვერდის ავლით ეს დაცვა თავად ტექსტის ფორმატირებით და ნაადრევად დასრულდეს მასზე Bracketed რეჟიმის გამოყენება. ეს მუშაობს იმის გამო, რომ ზოგიერთი ტერმინალი სწორად არ ფილტრავს გაქცევის მიმდევრობებს, სანამ მათ დაამატებენ. მაგალითად, ჩემში მე ვერასოდეს შევძელი წარმატებით დავასრულო კონსოლის ტესტები სწორი კონფიგურაციის შემთხვევაშიც კი .inputrc ფაილი. ეს ნიშნავს, რომ თქვენ შეგიძლიათ მარტივად დააზიანოთ თქვენი სისტემის კონფიგურაცია მხარდაჭერილი აპლიკაციის ან არასწორი კონფიგურაციის გამო. ეს განსაკუთრებით საშიშია დისტანციურ სერვერებზე შესვლისას, სადაც კონფიგურაციის ფრთხილად მუშაობა ნაკლებად ხშირია, განსაკუთრებით თუ თქვენ გაქვთ მრავალი ასეთი დისტანციური მანქანა.

ამ პრობლემის კარგი გამოსავალი არის ტერმინალის პასტის დადასტურების მოდული urxvt, რომელიც უბრალოდ ითხოვს ნებართვას ჩასვას ნებისმიერი ტექსტი, რომელიც შეიცავს ახალ ხაზებს. მე ვერ ვიპოვე უფრო უსაფრთხო ვარიანტი ჰორნის მიერ აღწერილი ტექსტური შეტევისთვის.

ჩანართები და პროფილები

პოპულარული ფუნქცია ამჟამად არის ჩანართიანი ინტერფეისის მხარდაჭერა, რომელსაც ჩვენ განვსაზღვრავთ, როგორც ერთ ტერმინალის ფანჯარას, რომელიც შეიცავს რამდენიმე სხვა ტერმინალს. ეს ფუნქცია განსხვავდება სხვადასხვა ტერმინალებისთვის და მიუხედავად იმისა, რომ ტრადიციული xterm ტერმინალები საერთოდ არ უჭერენ მხარს ჩანართებს, უფრო თანამედროვე ტერმინალის ინკარნაციებს, როგორიცაა Xfce Terminal, GNOME Terminal და Konsole, აქვთ ეს ფუნქცია. Urxvt ასევე მხარს უჭერს ჩანართებს, მაგრამ მხოლოდ იმ შემთხვევაში, თუ თქვენ იყენებთ დანამატს. მაგრამ თავად ჩანართების მხარდაჭერის თვალსაზრისით, Terminator არის უდავო ლიდერი: ის არა მხოლოდ მხარს უჭერს ჩანართებს, არამედ შეუძლია ტერმინალების მოწყობა ნებისმიერი თანმიმდევრობით (იხილეთ სურათი ქვემოთ).

Terminator-ის კიდევ ერთი მახასიათებელია ამ ჩანართების ერთად „დაჯგუფების“ და ერთდროულად რამდენიმე ტერმინალზე ერთიდაიგივე კლავიშების გაგზავნის შესაძლებლობა, რაც უზრუნველყოფს უხეში ინსტრუმენტს მრავალ სერვერზე ერთდროულად ნაყარი ოპერაციების შესასრულებლად. მსგავსი ფუნქცია ასევე დანერგილია Konsole-ში. ამ ფუნქციის სხვა ტერმინალებში გამოსაყენებლად, თქვენ უნდა გამოიყენოთ მესამე მხარის პროგრამული უზრუნველყოფა, როგორიცაა კლასტერი SSH, xlax ან tmux.

ჩანართები განსაკუთრებით კარგად მუშაობს პროფილებთან დაწყვილებისას: მაგალითად, შეგიძლიათ გქონდეთ ერთი ჩანართი ელფოსტისთვის, მეორე ჩატისთვის და ა.შ. ამას კარგად უჭერს მხარს Konsole Terminal და GNOME Terminal. ორივე საშუალებას აძლევს თითოეულ ჩანართს ავტომატურად გაუშვას საკუთარი პროფილი. Terminator ასევე მხარს უჭერს პროფილებს, მაგრამ მე ვერ ვიპოვე გზა, რომ ავტომატურად გაუშვა გარკვეული პროგრამები, როდესაც თქვენ გახსნით კონკრეტულ ჩანართს. სხვა ტერმინალებს საერთოდ არ აქვთ „პროფილის“ კონცეფცია.

რუფლები

ბოლო, რასაც ამ სტატიის პირველ ნაწილში განვიხილავ, არის ტერმინალების გარეგნობა. მაგალითად, GNOME, Xfce და urxvt მხარს უჭერენ გამჭვირვალობას, მაგრამ ახლახან შეწყვიტეს ფონის სურათების მხარდაჭერა, რაც აიძულა ზოგიერთი მომხმარებელი გადაერთო ტერმინალზე. ტილიქსი. პირადად მე კმაყოფილი ვარ და ეს მარტივია რესურსები, რომელიც ადგენს ფონის ფერების საბაზისო კომპლექტს urxvt-ისთვის. თუმცა, არასტანდარტული ფერის თემებსაც შეუძლია პრობლემები შეუქმნას. Მაგალითად, Solarized არ მუშაობს აპლიკაციებით htop и IPTraf, ვინაიდან ისინი უკვე იყენებენ საკუთარ ფერებს.

ორიგინალი VT100 ტერმინალი არ უჭერდა მხარს ფერებს და ახლები ხშირად შემოიფარგლებოდა 256 ფერის პალიტრით. მოწინავე მომხმარებლებისთვის, რომლებიც აწყობენ თავიანთ ტერმინალებს, ჭურვის მოთხოვნები ან სტატუსის ზოლები რთული გზებით შეიძლება იყოს შემაშფოთებელი შეზღუდვა. გის ტრეკებს, რომელ ტერმინალებს აქვთ "True Color" მხარდაჭერა. ჩემი ტესტები ადასტურებს, რომ st, Alacritty და VTE-ზე დაფუძნებული ტერმინალები სრულყოფილად უჭერენ მხარს True Color-ს. სხვა ტერმინალები ამ მხრივ არც თუ ისე კარგად სარგებლობენ და, ფაქტობრივად, 256 ფერსაც კი არ აჩვენებენ. ქვემოთ შეგიძლიათ იხილოთ განსხვავება True Color მხარდაჭერას შორის GNOME ტერმინალებში, st და xterm, რომლებიც ამას კარგად აკეთებენ თავიანთი 256 ფერის პალიტრით, და urxvt, რომელიც არა მხოლოდ ვერ ახერხებს ტესტს, არამედ აჩვენებს რამდენიმე მოციმციმე სიმბოლოსაც კი მათ ნაცვლად.

ზოგიერთი ტერმინალი ასევე აანალიზებს ტექსტს URL შაბლონებისთვის, რათა ბმულების დაწკაპუნება გახდეს. ეს ეხება VTE-დან გამომდინარე ყველა ტერმინალს, ხოლო urxvt მოითხოვს სპეციალურ დანამატს, რომელიც გარდაქმნის URL-ებს დაწკაპუნებით ან კლავიატურის მალსახმობის გამოყენებით. სხვა ტერმინალები, რომლებიც მე გამოვცადე ჩვენების URL-ების სხვა გზებით.

დაბოლოს, ტერმინალებში ახალი ტენდენციაა გადახვევის ბუფერის არჩევითობა. მაგალითად, st არ აქვს გადახვევის ბუფერი; ვარაუდობენ, რომ მომხმარებელი გამოიყენებს ტერმინალის მულტიპლექსერს, როგორიცაა tmux და GNU ეკრანი.

Alacritty-ს ასევე აკლია უკანა გადახვევის ბუფერები, მაგრამ მალე დაემატება მისი მხარდაჭერა ამ თემაზე მომხმარებლების "ვრცელი გამოხმაურების" გამო. ამ დაწყების გარდა, ყველა ტერმინალი, რომელიც მე გამოვცადე, რომელიც ვიპოვე, მხარს უჭერს საპირისპირო გადახვევას.

ქვედანაყოფები

მასალის მეორე ნაწილში (ორიგინალში ეს იყო ორი განსხვავებული სტატია - დაახლ. შესახვევი) ჩვენ შევადარებთ შესრულებას, მეხსიერების გამოყენებას და შეყოვნებას. მაგრამ ჩვენ უკვე ვხედავთ, რომ ზოგიერთ ტერმინალს აქვს სერიოზული ხარვეზები. მაგალითად, მომხმარებლებს, რომლებიც რეგულარულად მუშაობენ RTL სკრიპტებთან, შეიძლება მოისურვონ განიხილონ mlterm და pterm, რადგან ისინი უკეთ ასრულებენ მსგავს ამოცანებს, ვიდრე სხვები. კონსოლმაც კარგად ითამაშა. მომხმარებლებს, რომლებიც არ მუშაობენ RTL სკრიპტებთან, შეუძლიათ აირჩიონ სხვა რამ.

მავნე კოდის ჩასმისგან დაცვის თვალსაზრისით, urxvt გამოირჩევა ამ ტიპის თავდასხმისგან დაცვის სპეციალური განხორციელებით, რაც ჩემთვის ნამდვილად მოსახერხებელია. მათთვის, ვინც ეძებს ზარებს და სასტვენებს, კონსოლი ღირს ნახვა. და ბოლოს, აღსანიშნავია, რომ VTE არის შესანიშნავი ბაზა ტერმინალებისთვის, რაც გარანტიას იძლევა ფერების მხარდაჭერას, URL-ის ამოცნობას და ა.შ. ერთი შეხედვით, ნაგულისხმევი ტერმინალი, რომელიც მოყვება თქვენს საყვარელ გარემოს, შეიძლება აკმაყოფილებდეს ყველა მოთხოვნას, მაგრამ მოდით ეს კითხვა ღიად დავტოვოთ, სანამ არ გავიგებთ შესრულებას.

გავაგრძელოთ საუბარი

ზოგადად, ტერმინალების შესრულება თავისთავად შეიძლება შორს მიგდებულ პრობლემად ჩანდეს, მაგრამ როგორც ირკვევა, ზოგიერთი მათგანი საოცრად მაღალ შეყოვნებას ავლენს ასეთი ფუნდამენტური ტიპის პროგრამული უზრუნველყოფისთვის. ასევე შემდეგ ჩვენ გადავხედავთ იმას, რასაც ტრადიციულად უწოდებენ "სიჩქარეს" (სინამდვილეში, ეს არის გადახვევის სიჩქარე) და ტერმინალის მეხსიერების მოხმარება (გაფრთხილებით, რომ ეს არ არის ისეთი კრიტიკული დღეს, როგორც ეს იყო ათწლეულების წინ).

შეფერხება

ტერმინალის მუშაობის საფუძვლიანი შესწავლის შემდეგ მივედი დასკვნამდე, რომ ამ მხრივ ყველაზე მნიშვნელოვანი პარამეტრი არის ლატენტურობა (პინგი). თავის სტატიაში „სიამოვნებით ვბეჭდავთ“ პაველ ფატინმა შეხედა სხვადასხვა ტექსტური რედაქტორების შეყოვნებას და მიანიშნა, რომ ტერმინალები ამ მხრივ შეიძლება უფრო ნელი იყოს ვიდრე უსწრაფესი ტექსტური რედაქტორები. ეს იყო მინიშნება, რამაც საბოლოოდ მიმიყვანა საკუთარი ტესტების ჩატარებისა და ამ სტატიის დაწერისკენ.

მაგრამ რა არის ლატენტურობა და რატომ არის ეს ასე მნიშვნელოვანი? თავის სტატიაში ფათინმა ეს განსაზღვრა, როგორც „გადაწყვეტა კლავიშის დაჭერასა და ეკრანის შესაბამის განახლებას შორის“ და ციტირებდა "ადამიანისა და კომპიუტერის ურთიერთქმედების გზამკვლევი", სადაც ნათქვამია: „კომპიუტერის ეკრანზე ვიზუალური გამოხმაურების შეფერხება მნიშვნელოვან გავლენას ახდენს მბეჭდავის ქცევასა და კმაყოფილებაზე“.

ფატინი განმარტავს, რომ ამ პინგს აქვს უფრო ღრმა შედეგები, ვიდრე უბრალოდ კმაყოფილება: „აკრეფა ხდება ნელა, უფრო მეტი შეცდომა ხდება და იზრდება თვალებისა და კუნთების დაძაბულობა“. სხვა სიტყვებით რომ ვთქვათ, დიდმა დაგვიანებამ შეიძლება გამოიწვიოს ბეჭდვითი შეცდომები და ასევე კოდის ხარისხის დაქვეითება, რადგან ეს იწვევს ტვინზე დამატებით კოგნიტურ დატვირთვას. მაგრამ ყველაზე უარესი ის არის, რომ პინგი "ზრდის თვალისა და კუნთების დაძაბვას", რაც, როგორც ჩანს, გულისხმობს პროფესიული დაზიანებების განვითარება მომავალში (როგორც ჩანს, ავტორი გულისხმობს თვალების, ზურგის, მკლავების კუნთების პრობლემებს და, რა თქმა უნდა, მხედველობას - დაახლ. შესახვევი) განმეორებითი სტრესის გამო.

ზოგიერთი ამ ეფექტის შესახებ დიდი ხანია ცნობილია და შედეგები კვლევა, რომელიც ჯერ კიდევ 1976 წელს გამოქვეყნდა ჟურნალში Ergonomics, ნათქვამია, რომ 100 მილიწამის შეფერხება "მნიშვნელოვნად აფერხებს აკრეფის სიჩქარეს". ცოტა ხნის წინ შემოვიდა GNOME-ის მომხმარებლის სახელმძღვანელო პასუხის მისაღები დრო 10 მილიწამში და თუ უფრო შორს წახვალ, მაშინ Microsoft კვლევის აჩვენებს, რომ 1 მილიწამი იდეალურია.

ფატინმა ჩაატარა ტესტები ტექსტის რედაქტორებზე; მან შექმნა პორტატული ინსტრუმენტი ე.წ ტიპომეტრი, რომელიც გამოვიყენე ტერმინალის ემულატორებში პინგის შესამოწმებლად. გაითვალისწინეთ, რომ ტესტი ჩატარდა სიმულაციური რეჟიმში: რეალურად უნდა გავითვალისწინოთ როგორც შეყვანის (კლავიატურა, USB კონტროლერი და ა.შ.) ასევე გამომავალი (ვიდეო ბარათის ბუფერი, მონიტორი) შეყოვნება. ფატინის თქმით, ტიპიურ კონფიგურაციებში ეს არის დაახლოებით 20 ms. თუ თქვენ გაქვთ სათამაშო აღჭურვილობა, ამ მაჩვენებლის მიღწევა მხოლოდ 3 მილიწამში შეგიძლიათ. ვინაიდან ჩვენ უკვე გვაქვს ასეთი სწრაფი აპარატურა, აპლიკაციას არ სჭირდება საკუთარი შეყოვნების დამატება. Fatin-ის მიზანია აპლიკაციის შეყოვნების მიყვანა 1 მილიწამამდე, ან თუნდაც მიაღწიოს აკრეფის გარეშე გაზომვადი შეფერხებაროგორ IntelliJ IDEA 15.

აქ არის ჩემი გაზომვების შედეგები, ისევე როგორც ფატინის ზოგიერთი შედეგი, რათა დავანახოთ, რომ ჩემი ექსპერიმენტი ეთანხმება მის ტესტებს:

პირველი, რაც გამიკვირდა, იყო ძველი პროგრამების უკეთესი რეაგირების დრო, როგორიცაა xterm და mlterm. ყველაზე ცუდი რეგისტრის შეყოვნებით (2,4 ms), ისინი უკეთესად მუშაობდნენ, ვიდრე უსწრაფესი თანამედროვე ტერმინალი (10,6 ms for st). არცერთი თანამედროვე ტერმინალი არ ჩამოდის 10 მილიწამის ზღურბლზე ქვემოთ. კერძოდ, Alacritty ვერ აკმაყოფილებს „ყველაზე სწრაფი ტერმინალის ემულატორის“ მოთხოვნას, თუმცა მისი ქულები გაუმჯობესდა 2017 წლის პირველი მიმოხილვის შემდეგ. მართლაც, პროექტის ავტორები სიტუაციის გაცნობიერება და მუშაობენ ეკრანის გასაუმჯობესებლად. აქვე უნდა აღინიშნოს, რომ Vim GTK3-ის გამოყენებით არის სიდიდის რიგითობა უფრო ნელი ვიდრე მისი GTK2 კოლეგა. აქედან შეგვიძლია დავასკვნათ, რომ GTK3 ქმნის დამატებით შეყოვნებას და ეს აისახება ყველა სხვა ტერმინალში, რომელიც იყენებს მას (Terminator, Xfce4 Terminal და GNOME Terminal).

თუმცა, განსხვავებები შეიძლება არ იყოს შესამჩნევი თვალისთვის. როგორც ფატინი განმარტავს, „არ უნდა იცოდეთ დაგვიანების შესახებ, რომ მან გავლენა მოახდინოს თქვენზე“. ფატინი ასევე აფრთხილებს სტანდარტული გადახრის შესახებ: ”ნებისმიერი დარღვევა ლატენტურობაში (ჟიტერი) ქმნის დამატებით სტრესს მათი არაპროგნოზირებადობის გამო”.

ზემოთ მოცემული გრაფიკი აღებულია სუფთა Debian 9-ზე (გაჭიმვა). i3 ფანჯრის მენეჯერი. ეს გარემო იძლევა საუკეთესო შედეგებს ლატენტურ ტესტებში. როგორც ირკვევა, GNOME ქმნის დამატებით პინგს 20 ms ყველა გაზომვისთვის. ამის შესაძლო ახსნა არის პროგრამების არსებობა შეყვანის მოვლენების სინქრონული დამუშავებით. ფატინი მაგალითს მოჰყავს ასეთი შემთხვევისთვის სამუშაო, რომელიც ამატებს შეფერხებას ყველა შეყვანის მოვლენის სინქრონულად დამუშავებით. ნაგულისხმევად, GNOME-ს ასევე გააჩნია ფანჯრის მენეჯერი Mutter, რომელიც ქმნის ბუფერირების დამატებით ფენას, რომელიც გავლენას ახდენს პინგზე და ამატებს მინიმუმ 8 მილიწამის შეყოვნებას.

გადახვევის სიჩქარე

შემდეგი ტესტი არის ტრადიციული "სიჩქარის" ან "სიჩქარის" ტესტი, რომელიც ზომავს რამდენად სწრაფად შეუძლია ტერმინალის გადახვევა გვერდის ეკრანზე დიდი რაოდენობით ტექსტის ჩვენებისას. ტესტის მექანიკა განსხვავდება; თავდაპირველი ტესტი იყო უბრალოდ იგივე ტექსტის სტრიქონის გენერირება seq ბრძანების გამოყენებით. სხვა ტესტები მოიცავს თომას ე. დიკის (xterm შენარჩუნება) ტესტს, რომელიც არაერთხელ terminfo.src ფაილი ჩამოტვირთულია. ტერმინალის მუშაობის სხვა მიმოხილვაში დენ ლუუ იყენებს base32 დაშიფრულ სტრიქონს შემთხვევითი ბაიტით, რომელიც გამოდის ტერმინალში კატის გამოყენებით. ლუუ მიიჩნევს, რომ ასეთი ტესტი არის "ისეთი უსარგებლო საორიენტაციო ნიშანი, როგორც შეიძლება წარმოიდგინოთ" და გვთავაზობს ტერმინალური პასუხის გამოყენებას, როგორც პირველადი მეტრიკის ნაცვლად. დიკი თავის გამოცდას შეცდომაში შემყვანსაც უწოდებს. თუმცა, ორივე ავტორი აღიარებს, რომ ტერმინალის ფანჯრის გამტარობა შეიძლება იყოს პრობლემა. ლუუმ აღმოაჩინა Emacs Eshell-ის გაყინვა დიდი ფაილების ჩვენებისას და დიკიმ მოახდინა ტერმინალის ოპტიმიზაცია xtrerm-ის ვიზუალური სისუსტისგან თავის დასაღწევად. ამრიგად, ამ ტესტს ჯერ კიდევ აქვს გარკვეული დამსახურება, მაგრამ რადგან რენდერის პროცესი ძალიან განსხვავდება ტერმინალიდან ტერმინალამდე, ის ასევე შეიძლება გამოყენებულ იქნას როგორც ტესტის კომპონენტი სხვა პარამეტრების შესამოწმებლად.

აქ ჩვენ ვხედავთ rxvt და st pull-ს კონკურენციის წინ, რასაც მოჰყვება ბევრად უფრო ახალი Alacritty, რომელიც შექმნილია შესრულებაზე ორიენტირებული. შემდეგი არის Xfce (VTE ოჯახი) და Konsole, რომლებიც თითქმის ორჯერ უფრო სწრაფია. ბოლო არის xterm, რომელიც ხუთჯერ ნელია ვიდრე rxvt. ტესტის დროს, xterm ასევე ბევრი ტალღოვანი იყო, რაც ართულებდა ტექსტის გავლას, თუნდაც ეს იგივე ხაზი ყოფილიყო. კონსოლი სწრაფი იყო, მაგრამ ზოგჯერ რთული იყო: ეკრანი დროდადრო იყინებოდა, აჩვენებდა ნაწილობრივ ტექსტს ან საერთოდ არ აჩვენებდა მას. სხვა ტერმინალები ნათლად აჩვენებს სტრიქონებს, მათ შორის st, Alacritty და rxvt.

დიკი განმარტავს, რომ შესრულების განსხვავებები გამოწვეულია გადახვევის ბუფერების დიზაინით სხვადასხვა ტერმინალებში. კერძოდ, ის rxvt-ს და სხვა ტერმინალებს "ზოგადი წესების შეუსრულებლობაში" ადანაშაულებს:

”Xterm-ისგან განსხვავებით, rxvt არ ცდილობდა ყველა განახლების ჩვენებას. თუ ის ჩამორჩება, ის უარს იტყვის ზოგიერთ განახლებაზე დაჭერაზე. ამან უფრო დიდი გავლენა მოახდინა გადახვევის აშკარა სიჩქარეზე, ვიდრე შიდა მეხსიერების ორგანიზაციაზე. ერთი ნაკლი ის იყო, რომ ASCII ანიმაცია გარკვეულწილად არაზუსტი იყო.

ამ აღქმული xterm სისუსტის გამოსასწორებლად, დიკი გვთავაზობს რესურსის გამოყენებას სწრაფი გადახვევა, საშუალებას აძლევს xterm-ს, გააუქმოს ეკრანის ზოგიერთი განახლება, რათა თვალყური ადევნოს დინებას. ჩემი ტესტები ადასტურებს, რომ fastScroll აუმჯობესებს შესრულებას და აყვანს xterm-ს rxvt-თან. თუმცა, ეს საკმაოდ უხეში ყავარჯენია, როგორც თავად დიკი განმარტავს: "ზოგჯერ xterm - კონსოლის მსგავსად - ჩერდება, რადგან ელოდება ეკრანის განახლებების ახალ კომპლექტს ზოგიერთის წაშლის შემდეგ." ამ თვალსაზრისით, როგორც ჩანს, სხვა ტერმინალებმა იპოვეს საუკეთესო კომპრომისი სიჩქარესა და ეკრანის მთლიანობას შორის.

რესურსების მოხმარება

მიუხედავად იმისა, აქვს თუ არა აზრი გადახვევის სიჩქარის შესრულების მეტრიკას განხილვას, ეს ტესტი საშუალებას გვაძლევს მოვახდინოთ დატვირთვის სიმულაცია ტერმინალებზე, რაც თავის მხრივ საშუალებას გვაძლევს გავზომოთ სხვა პარამეტრები, როგორიცაა მეხსიერება ან დისკის გამოყენება. მეტრიკა მიღებული იქნა მითითებული ტესტის გაშვებით შემდგომი პითონის პროცესის მონიტორინგის ქვეშ. მან შეაგროვა მრიცხველის მონაცემები getrusage () ამისთვის ru_maxrss, თანხა ru_oublock и ru_inblock და მარტივი ტაიმერი.

ამ ტესტში ST პირველ ადგილს იკავებს მეხსიერების ყველაზე დაბალი საშუალო მოხმარებით 8 მბ, რაც გასაკვირი არ არის იმის გათვალისწინებით, რომ დიზაინის მთავარი იდეა სიმარტივეა. mlterm, xterm და rxvt მოიხმარენ ცოტა მეტს - დაახლოებით 12 მბ. კიდევ ერთი შესამჩნევი შედეგია Alacritty, რომლის გასაშვებად საჭიროა 30 მბ. შემდეგ არის VTE ოჯახის ტერმინალები 40-დან 60 მბ-მდე ფიგურებით, რაც საკმაოდ ბევრია. ეს მოხმარება შეიძლება აიხსნას იმით, რომ ეს ტერმინალები იყენებენ უფრო მაღალი დონის ბიბლიოთეკებს, მაგალითად, GTK. კონსოლი ბოლო ადგილზეა 65 მბ მეხსიერების მოხმარებით ტესტების დროს, თუმცა ეს შეიძლება გამართლდეს ფუნქციების ძალიან ფართო სპექტრით.

ათი წლის წინ მიღებულ წინა შედეგებთან შედარებით, ყველა პროგრამამ შესამჩნევად მეტი მეხსიერების მოხმარება დაიწყო. Xterm ადრე მოითხოვდა 4 MB, მაგრამ ახლა ის მოითხოვს 15 MB მხოლოდ გაშვებისას. მოხმარების ანალოგიური ზრდაა rxvt-ისთვის, რომელიც ახლა 16 მბ-ს მოითხოვს. Xfce ტერმინალი იკავებს 34 მბ-ს, რაც სამჯერ მეტია, ვიდრე ადრე, მაგრამ GNOME ტერმინალს სჭირდება მხოლოდ 20 მბ. რა თქმა უნდა, ყველა წინა ტესტი ჩატარდა 32-ბიტიან არქიტექტურაზე. LCA 2012-ზე Rusty Russell მე ვუთხარი,, რომ არსებობს კიდევ ბევრი დახვეწილი მიზეზი, რამაც შეიძლება აიხსნას მეხსიერების მოხმარების ზრდა. როგორც ვთქვით, ჩვენ ახლა ვცხოვრობთ დროში, სადაც გვაქვს გიგაბაიტი მეხსიერება, ასე რომ, როგორმე მოვახერხებთ.

თუმცა, არ შემიძლია არ ვგრძნობ, რომ მეტი მეხსიერების გამოყოფა ისეთი ფუნდამენტურისთვის, როგორიც ტერმინალია, რესურსების ფუჭად ხარჯვაა. ეს პროგრამები უნდა იყოს უმცირესთა შორის უმცირესი, უნდა შეეძლოს ნებისმიერ „ყუთზე“ გაშვება, თუნდაც ფეხსაცმლის ყუთზე, თუკი ოდესმე მივალთ იქამდე, რომ ისინი უნდა იყოს აღჭურვილი 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 compositing უკეთესად მუშაობს, ვიდრე X.org და ასევე იმედი მაქვს, რომ მომავალში ვინმე იპოვის გზას ამ გარემოში ლატენტურობის გაზომვისთვის.

წყარო: www.habr.com