ទិដ្ឋភាពទូទៅនៃកម្មវិធីត្រាប់តាមស្ថានីយ

ពាក្យពីរបីពីការិយាល័យបកប្រែរបស់យើង៖ ជាធម្មតាអ្នកគ្រប់គ្នាខិតខំបកប្រែសម្ភារៈ និងការបោះពុម្ពចុងក្រោយបង្អស់ ហើយយើងក៏មិនមានករណីលើកលែងដែរ។ ប៉ុន្តែស្ថានីយមិនមែនជាអ្វីដែលត្រូវបានធ្វើបច្ចុប្បន្នភាពម្តងក្នុងមួយសប្តាហ៍។ ដូច្នេះហើយ យើងបានបកប្រែសម្រាប់អ្នកនូវអត្ថបទមួយដោយ Antoine Beaupré ដែលបានបោះពុម្ពនៅនិទាឃរដូវឆ្នាំ 2018៖ ទោះបីជា "អាយុ" សន្ធឹកសន្ធាប់តាមស្តង់ដារទំនើបក៏ដោយ តាមគំនិតរបស់យើង សម្ភារៈមិនបាត់បង់ភាពពាក់ព័ន្ធរបស់វាទាល់តែសោះ។ លើសពីនេះទៀត នេះដើមឡើយជាស៊េរីនៃអត្ថបទពីរ ប៉ុន្តែយើងបានសម្រេចចិត្តបញ្ចូលវាទៅក្នុងប្រកាសធំមួយ។

ស្ថានីយមានកន្លែងពិសេសមួយនៅក្នុងប្រវត្តិសាស្ត្រកុំព្យូទ័រ ប៉ុន្តែក្នុងប៉ុន្មានទសវត្សរ៍ថ្មីៗនេះ ពួកគេត្រូវបានបង្ខំឱ្យរស់រានមានជីវិតជាមួយបន្ទាត់ពាក្យបញ្ជា ដោយសារចំណុចប្រទាក់ក្រាហ្វិកក្លាយជាគ្រប់ទីកន្លែង។ កម្មវិធីត្រាប់តាមស្ថានីយ បានជំនួសរបស់ពួកគេ។ បងប្អូនផ្នែករឹងដែល​ជា​ការ​កែប្រែ​ប្រព័ន្ធ​ដែល​មាន​មូលដ្ឋាន​លើ​កាត​ដែល​បាន​ដាល់​ និង​ការ​បិទ​បើក។ ការចែកចាយទំនើបមកជាមួយកម្មវិធីត្រាប់តាមស្ថានីយជាច្រើននៃរាង និងពណ៌ទាំងអស់។ ហើយខណៈពេលដែលមនុស្សជាច្រើនពេញចិត្តនឹងស្ថានីយស្តង់ដារដែលផ្តល់ដោយបរិយាកាសការងាររបស់ពួកគេ អ្នកខ្លះប្រើកម្មវិធីកម្រនិងអសកម្មដោយមោទនភាពដើម្បីដំណើរការសែល ឬកម្មវិធីនិពន្ធអត្ថបទដែលពួកគេចូលចិត្ត។ ប៉ុន្តែដូចដែលយើងនឹងឃើញពីអត្ថបទនេះ មិនមែនគ្រប់ស្ថានីយទាំងអស់ត្រូវបានបង្កើតក្នុងរូបភាពតែមួយទេ៖ ពួកវាខុសគ្នាខ្លាំងនៅក្នុងមុខងារ ទំហំ និងដំណើរការ។

ស្ថានីយមួយចំនួនមានរន្ធសុវត្ថិភាពដ៏គួរឱ្យភ្ញាក់ផ្អើល ហើយភាគច្រើនមានសំណុំមុខងារខុសគ្នាទាំងស្រុង ចាប់ពីការគាំទ្រសម្រាប់ចំណុចប្រទាក់ផ្ទាំងផ្ទាំងរហូតដល់ការសរសេរស្គ្រីប។ ទោះបីជាយើង បានមើលកម្មវិធីត្រាប់តាមស្ថានីយនៅអតីតកាលឆ្ងាយ, អត្ថបទនេះគឺជាការធ្វើបច្ចុប្បន្នភាពនៃសម្ភារៈមុនដែលនឹងជួយអ្នកអានកំណត់ថាតើស្ថានីយណាដែលត្រូវប្រើនៅឆ្នាំ 2018 ។ ពាក់កណ្តាលទីមួយនៃអត្ថបទប្រៀបធៀបលក្ខណៈពិសេស ហើយពាក់កណ្តាលទីពីរវាយតម្លៃការអនុវត្ត។

នេះគឺជាស្ថានីយដែលខ្ញុំបានពិនិត្យ៖

ទាំងនេះប្រហែលជាមិនមែនជាកំណែចុងក្រោយបង្អស់ទេ ដោយសារខ្ញុំត្រូវបានកំណត់ចំពោះការបង្កើតដែលមានស្ថេរភាពនៅពេលសរសេរ ដែលខ្ញុំអាចដាក់ចេញនៅលើ Debian 9 ឬ Fedora 27។ ករណីលើកលែងតែមួយគត់គឺ Alacritty ។ វាគឺជាកូនចៅនៃស្ថានីយបង្កើនល្បឿន GPU ហើយត្រូវបានសរសេរជាភាសាមិនធម្មតា និងថ្មីសម្រាប់កិច្ចការនេះ - Rust ។ ខ្ញុំ​បាន​ដក​ចេញ​ស្ថានីយ​បណ្ដាញ​ពី​ការ​ពិនិត្យ​របស់​ខ្ញុំ (រាប់​បញ្ចូល​ទាំង​កម្មវិធី​ដែល​នៅ​លើ អេឡិចត្រុង) ដោយសារតែការធ្វើតេស្តបឋមបានបង្ហាញពីដំណើរការមិនល្អរបស់ពួកគេ។

ការគាំទ្រយូនីកូដ

ខ្ញុំបានចាប់ផ្តើមការធ្វើតេស្តរបស់ខ្ញុំជាមួយនឹងការគាំទ្រយូនីកូដ។ ការធ្វើតេស្តដំបូងនៃស្ថានីយគឺដើម្បីបង្ហាញខ្សែអក្សរយូនីកូដពី អត្ថបទវិគីភីឌា៖ "é, Δ, И, ឃ, م, 7, あ, 叶, 葉 និង 말 ។" ការធ្វើតេស្តសាមញ្ញនេះបង្ហាញថាតើស្ថានីយអាចដំណើរការបានត្រឹមត្រូវនៅទូទាំងពិភពលោកដែរឬទេ។ ស្ថានីយ xterm មិនបង្ហាញតួអក្សរអារ៉ាប់ទេ។ មេមត់ នៅក្នុងការកំណត់លំនាំដើម៖

តាមលំនាំដើម xterm ប្រើពុម្ពអក្សរ "ថេរ" បុរាណ ដែលយោងទៅតាម នៅតែ Vicky ដដែលមាន "ការគ្របដណ្តប់យូនីកូដយ៉ាងច្រើនចាប់តាំងពីឆ្នាំ 1997" ។ មានអ្វីមួយកើតឡើងនៅក្នុងពុម្ពអក្សរនេះដែលបណ្តាលឱ្យតួអក្សរលេចឡើងជាស៊ុមទទេហើយវាគ្រាន់តែជាពេលដែលពុម្ពអក្សរអត្ថបទត្រូវបានកើនឡើងដល់ 20+ ចំណុចដែលតួអក្សរចាប់ផ្តើមបង្ហាញត្រឹមត្រូវ។ ទោះយ៉ាងណាក៏ដោយ "ការជួសជុល" នេះបំបែកការបង្ហាញតួអក្សរយូនីកូដផ្សេងទៀត៖

រូបថតអេក្រង់ទាំងនេះត្រូវបានថតនៅក្នុង Fedora 27 ព្រោះវាផ្តល់លទ្ធផលប្រសើរជាង Debian 9 ដែលកំណែចាស់មួយចំនួននៃស្ថានីយ (ជាពិសេស mlterm) មិនអាចគ្រប់គ្រងពុម្ពអក្សរបានត្រឹមត្រូវ។ ជាសំណាងល្អ វាត្រូវបានជួសជុលនៅក្នុងកំណែក្រោយៗទៀត។

ឥឡូវនេះសូមកត់សម្គាល់ពីរបៀបដែលបន្ទាត់ត្រូវបានបង្ហាញនៅក្នុង xterm ។ វាប្រែថានិមិត្តសញ្ញា Mem និង Semitic ខាងក្រោម qoph យោងទៅស្គ្រីបរចនាប័ទ្ម RTL (ពីស្តាំទៅឆ្វេង) ដូច្នេះតាមបច្ចេកទេស គេគួរតែបង្ហាញពីស្តាំទៅឆ្វេង។ កម្មវិធីរុករកតាមអ៊ីនធឺណិតដូចជា Firefox 57 ដោះស្រាយបន្ទាត់ខាងលើឱ្យបានត្រឹមត្រូវ។ កំណែសាមញ្ញនៃអត្ថបទ RTL គឺពាក្យ "Сара" ជា​ភាសា​ហេព្រើរ (អ៊ី). ទំព័រវិគីនៅលើអត្ថបទទ្វេទិស និយាយដូចតទៅ៖

“កម្មវិធីកុំព្យូទ័រជាច្រើនមិនអាចបង្ហាញអត្ថបទពីរទិសបានត្រឹមត្រូវទេ។ ជាឧទាហរណ៍ ឈ្មោះភាសាហេព្រើរ "សារ៉ា" មានតួអក្សរ sin (sh) (ដែលលេចឡើងនៅខាងស្តាំ) បន្ទាប់មក resh (r) ហើយចុងក្រោយគាត់ ( ה) (ដែលគួរតែលេចឡើងនៅខាងឆ្វេង) ។

ស្ថានីយជាច្រើនបរាជ័យក្នុងការសាកល្បងនេះ៖ Alacritty, VTE-derived Gnome និង XFCE terminals, urxvt, st និង xterm display "Sara" ក្នុងលំដាប់បញ្ច្រាស ដូចជាប្រសិនបើយើងបានសរសេរឈ្មោះជា "Aras"។

បញ្ហាមួយទៀតជាមួយអត្ថបទទ្វេទិសគឺថា ពួកគេត្រូវតែតម្រឹមតាមរបៀបណាមួយ ជាពិសេសនៅពេលនិយាយអំពីការលាយអត្ថបទ RTL និង LTR ។ ស្គ្រីប RTL គួរតែដំណើរការពីជ្រុងខាងស្តាំនៃបង្អួចស្ថានីយ ប៉ុន្តែតើមានអ្វីកើតឡើងចំពោះស្ថានីយដែលមានលំនាំដើមជា LTR English? ពួកគេភាគច្រើនមិនមានយន្តការពិសេសណាមួយឡើយ ហើយតម្រឹមអត្ថបទទាំងអស់ទៅខាងឆ្វេង (រួមទាំងនៅក្នុងកុងសូល)។ ករណីលើកលែងគឺ pterm និង mlterm ដែលប្រកាន់ខ្ជាប់នូវស្តង់ដារ និងតម្រឹមបន្ទាត់បែបនេះឱ្យត្រឹមត្រូវ។

ការការពារការបញ្ចូល

លក្ខណៈសំខាន់បន្ទាប់ដែលខ្ញុំបានកំណត់អត្តសញ្ញាណគឺការការពារប្រឆាំងនឹងការបញ្ចូល។ ទោះបីជាវាត្រូវបានគេស្គាល់យ៉ាងទូលំទូលាយថាអក្ខរាវិរុទ្ធដូចជា:

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

គឺជាពាក្យបញ្ជាជំរុញការប្រតិបត្តិកូដ មានមនុស្សតិចណាស់ដែលដឹងថាពាក្យបញ្ជាលាក់អាចជ្រៀតចូលទៅក្នុងកុងសូលនៅពេលចម្លង និងបិទភ្ជាប់ពីកម្មវិធីរុករកតាមអ៊ីនធឺណិត សូម្បីតែបន្ទាប់ពីការត្រួតពិនិត្យយ៉ាងប្រុងប្រយ័ត្នក៏ដោយ។ គេហទំព័រផ្ទៀងផ្ទាត់ Gianna Horna បង្ហាញយ៉ាងត្រចះត្រចង់នូវពាក្យបញ្ជាដែលមើលទៅគ្មានកំហុស៖

git clone git: //git.kernel.org/pub/scm/utils/kup/kup.git

ប្រែទៅជាភាពរំខាននៅពេលបិទភ្ជាប់ពីគេហទំព័ររបស់ Horn ទៅក្នុងស្ថានីយ៖

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 ដ៏ថ្លៃថ្លាគាំទ្រមុខងារនេះ ប៉ុន្តែការបិទភ្ជាប់ក្នុងទម្រង់តង្កៀបទាមទារការគាំទ្រពីសែល ឬកម្មវិធីដែលកំពុងដំណើរការនៅលើស្ថានីយ។ ឧទាហរណ៍ការប្រើប្រាស់កម្មវិធី បន្ទាត់អាន GNU (Bash ដូចគ្នា) ត្រូវការឯកសារ ~/.inputrc:

set enable-bracketed-paste on

ជាអកុសល គេហទំព័រសាកល្បងរបស់ Horn ក៏បង្ហាញពីរបៀបរំលងការការពារនេះតាមរយៈការធ្វើទ្រង់ទ្រាយអត្ថបទដោយខ្លួនឯង ហើយបញ្ចប់មុនកាលកំណត់ដោយអនុវត្តមុខងារ Bracketed លើវា។ វាដំណើរការដោយសារតែស្ថានីយមួយចំនួនមិនបានត្រងការរត់គេចខ្លួនឱ្យបានត្រឹមត្រូវមុនពេលបន្ថែមរបស់វាផ្ទាល់។ ជាឧទាហរណ៍ នៅក្នុងរបស់ខ្ញុំ ខ្ញុំមិនអាចបញ្ចប់ការសាកល្បង Konsole ដោយជោគជ័យទេ សូម្បីតែជាមួយនឹងការកំណត់ត្រឹមត្រូវក៏ដោយ។ .បញ្ចូល ឯកសារ។ នេះមានន័យថាអ្នកអាចធ្វើឱ្យការកំណត់រចនាសម្ព័ន្ធប្រព័ន្ធរបស់អ្នកខូចបានយ៉ាងងាយស្រួល ដោយសារកម្មវិធីដែលមិនគាំទ្រ ឬសែលដែលបានកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវ។ វាមានគ្រោះថ្នាក់ជាពិសេសនៅពេលចូលទៅក្នុងម៉ាស៊ីនមេពីចម្ងាយ ដែលការងារកំណត់រចនាសម្ព័ន្ធដោយប្រុងប្រយ័ត្នមិនសូវមានជាទូទៅ ជាពិសេសប្រសិនបើអ្នកមានម៉ាស៊ីនពីចម្ងាយបែបនេះច្រើន។

ដំណោះស្រាយដ៏ល្អចំពោះបញ្ហានេះគឺកម្មវិធីជំនួយការបញ្ជាក់បិទភ្ជាប់សម្រាប់ស្ថានីយ urxvtដែលគ្រាន់តែសុំការអនុញ្ញាតដើម្បីបញ្ចូលអត្ថបទណាមួយដែលមានបន្ទាត់ថ្មី។ ខ្ញុំ​មិន​បាន​រក​ឃើញ​ជម្រើស​សុវត្ថិភាព​ជាង​នេះ​សម្រាប់​ការ​វាយ​ប្រហារ​អត្ថបទ​ដែល​បាន​ពិពណ៌នា​ដោយ Horn ទេ។

ផ្ទាំង និងទម្រង់

មុខងារដ៏ពេញនិយមមួយនៅពេលនេះគឺការគាំទ្រសម្រាប់ចំណុចប្រទាក់ផ្ទាំងដែលយើងនឹងកំណត់ថាជាបង្អួចស្ថានីយមួយដែលមានស្ថានីយផ្សេងទៀតជាច្រើន។ មុខងារនេះមានភាពខុសប្លែកគ្នាសម្រាប់ស្ថានីយផ្សេងៗគ្នា ហើយទោះបីជាស្ថានីយ xterm ប្រពៃណីមិនគាំទ្រផ្ទាំងទាំងអស់ក៏ដោយ ការចាប់កំណើតរបស់ស្ថានីយទំនើបជាងមុនដូចជា Xfce Terminal, GNOME Terminal និង Konsole មានមុខងារនេះ។ Urxvt ក៏គាំទ្រផ្ទាំងផងដែរ ប៉ុន្តែប្រសិនបើអ្នកប្រើកម្មវិធីជំនួយ។ ប៉ុន្តែ​បើ​និយាយ​ពី​ការ​គាំទ្រ​ផ្ទាំង​ខ្លួន​ឯង Terminator គឺ​ជា​អ្នក​ដឹក​នាំ​ដែល​គ្មាន​ជម្លោះ៖ វា​មិន​ត្រឹម​តែ​គាំទ្រ​ផ្ទាំង​ប៉ុណ្ណោះ​ទេ ប៉ុន្តែ​វា​ក៏​អាច​រៀបចំ​ស្ថានីយ​តាម​លំដាប់​ណា​មួយ​ដែរ (មើល​រូបភាព​ខាងក្រោម)។

លក្ខណៈពិសេសមួយទៀតរបស់ Terminator គឺសមត្ថភាពក្នុងការ "ដាក់ជាក្រុម" ផ្ទាំងទាំងនេះជាមួយគ្នា ហើយផ្ញើការចុចគ្រាប់ចុចដូចគ្នាទៅកាន់ស្ថានីយជាច្រើនក្នុងពេលតែមួយ ដោយផ្តល់នូវឧបករណ៍ឆៅសម្រាប់ដំណើរការប្រតិបត្តិការច្រើននៅលើម៉ាស៊ីនមេជាច្រើនក្នុងពេលដំណាលគ្នា។ មុខងារស្រដៀងគ្នានេះក៏ត្រូវបានអនុវត្តនៅក្នុង Konsole ផងដែរ។ ដើម្បីប្រើលក្ខណៈពិសេសនេះនៅក្នុងស្ថានីយផ្សេងទៀត អ្នកត្រូវតែប្រើកម្មវិធីភាគីទីបីដូចជា ចង្កោម SSH, xlax ឬ tmux.

ផ្ទាំងដំណើរការល្អជាពិសេសនៅពេលផ្គូផ្គងជាមួយទម្រង់៖ ឧទាហរណ៍ អ្នកអាចមានផ្ទាំងមួយសម្រាប់អ៊ីមែល ផ្ទាំងមួយទៀតសម្រាប់ជជែកជាដើម។ វាត្រូវបានគាំទ្រយ៉ាងល្អដោយស្ថានីយកុងសូល និងស្ថានីយ GNOME ។ ទាំងពីរអនុញ្ញាតឱ្យផ្ទាំងនីមួយៗចាប់ផ្តើមទម្រង់ផ្ទាល់ខ្លួនរបស់វាដោយស្វ័យប្រវត្តិ។ Terminator ក៏គាំទ្រទម្រង់ផងដែរ ប៉ុន្តែខ្ញុំមិនអាចស្វែងរកវិធីដើម្បីចាប់ផ្តើមកម្មវិធីជាក់លាក់ណាមួយដោយស្វ័យប្រវត្តិនៅពេលអ្នកបើកផ្ទាំងជាក់លាក់មួយ។ ស្ថានីយផ្សេងទៀតមិនមានគំនិតនៃ "ទម្រង់" ទាល់តែសោះ។

រ៉ូហ្វែល

រឿងចុងក្រោយដែលខ្ញុំនឹងរៀបរាប់នៅក្នុងផ្នែកដំបូងនៃអត្ថបទនេះគឺរូបរាងរបស់ស្ថានីយ។ ឧទាហរណ៍ GNOME, Xfce និង urxvt គាំទ្រតម្លាភាព ប៉ុន្តែថ្មីៗនេះបានទម្លាក់ការគាំទ្រសម្រាប់រូបភាពផ្ទៃខាងក្រោយ ដោយបង្ខំឱ្យអ្នកប្រើប្រាស់មួយចំនួនប្តូរទៅស្ថានីយ Tilix. ដោយផ្ទាល់ខ្ញុំសប្បាយចិត្តជាមួយវាហើយវាសាមញ្ញ ប្រភពដែលកំណត់សំណុំមូលដ្ឋាននៃពណ៌ផ្ទៃខាងក្រោយសម្រាប់ urxvt ។ ទោះជាយ៉ាងណាក៏ដោយ ស្បែកពណ៌ដែលមិនមានស្តង់ដារក៏អាចបង្កើតបញ្ហាផងដែរ។ ឧទាហរណ៍, ប្រើថាមពលព្រះអាទិត្យ មិនដំណើរការ ជាមួយនឹងកម្មវិធី htop и អាយធីធីហ្វចាប់តាំងពីពួកគេបានប្រើពណ៌ផ្ទាល់ខ្លួនរបស់ពួកគេរួចហើយ។

ស្ថានីយ VT100 ដើម មិន​គាំទ្រ​ពណ៌​ទេ ហើយ​ពណ៌​ថ្មី​ត្រូវ​បាន​កំណត់​ជា​ញឹកញាប់​ចំពោះ​ក្ដារលាយ​ពណ៌ 256។ សម្រាប់អ្នកប្រើប្រាស់កម្រិតខ្ពស់ដែលកំណត់រចនាប័ទ្មស្ថានីយរបស់ពួកគេ ការជម្រុញសែល ឬរបារស្ថានភាពនៅក្នុងវិធីស្មុគស្មាញអាចជាការកំណត់ដែលគួរឱ្យរំខាន។ Gist បទដែលស្ថានីយមានការគាំទ្រ "ពណ៌ពិត" ។ ការធ្វើតេស្តរបស់ខ្ញុំបញ្ជាក់ថាស្ថានីយដែលមានមូលដ្ឋានលើ st, Alacritty និង VTE គាំទ្រពណ៌ពិតយ៉ាងល្អឥតខ្ចោះ។ ស្ថានីយផ្សេងទៀតមិនសូវល្អក្នុងរឿងនេះទេ ហើយតាមពិត ក៏មិនបង្ហាញ 256 ពណ៌ដែរ។ ខាងក្រោមនេះអ្នកអាចឃើញភាពខុសគ្នារវាងការគាំទ្រពណ៌ពិតនៅក្នុងស្ថានីយ GNOME, st និង xterm ដែលដំណើរការបានល្អជាមួយនឹងក្ដារលាយពណ៌ 256 និង urxvt របស់ពួកគេ ដែលមិនត្រឹមតែបរាជ័យក្នុងការសាកល្បងប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងបង្ហាញតួអក្សរភ្លឹបភ្លែតៗមួយចំនួនជំនួសពួកគេ។

ស្ថានីយខ្លះក៏វិភាគអត្ថបទសម្រាប់លំនាំ URL ដើម្បីធ្វើឱ្យតំណភ្ជាប់អាចចុចបាន។ នេះអនុវត្តចំពោះស្ថានីយដែលបានមកពី VTE ទាំងអស់ ខណៈពេលដែល urxvt ត្រូវការកម្មវិធីជំនួយពិសេសដែលនឹងបំប្លែង URLs នៅពេលចុច ឬប្រើផ្លូវកាត់ក្តារចុច។ ស្ថានីយផ្សេងទៀតដែលខ្ញុំបានសាកល្បងបង្ហាញ URLs តាមវិធីផ្សេងទៀត។

ចុងក្រោយ និន្នាការថ្មីនៅក្នុងស្ថានីយគឺជាជម្រើសនៃសតិបណ្ដោះអាសន្នរមូរ។ ឧទាហរណ៍ st មិនមានសតិបណ្ដោះអាសន្នរមូរទេ។ វាត្រូវបានសន្មត់ថាអ្នកប្រើប្រាស់នឹងប្រើ terminal multiplexer ដូចជា tmux និង អេក្រង់ GNU.

Alacritty ក៏ខ្វះទ្រនាប់ backscroll ប៉ុន្តែ នឹងត្រូវបានបន្ថែមក្នុងពេលឆាប់ៗនេះ ការគាំទ្ររបស់វាដោយសារតែ "មតិកែលម្អយ៉ាងទូលំទូលាយ" លើប្រធានបទនេះពីអ្នកប្រើប្រាស់។ ក្រៅពីការចាប់ផ្តើមទាំងនេះ រាល់ស្ថានីយដែលខ្ញុំបានសាកល្បងដែលខ្ញុំអាចស្វែងរកការគាំទ្រការរមូរបញ្ច្រាស។

សរុបរង

នៅក្នុងផ្នែកទីពីរនៃសម្ភារៈ (នៅក្នុងដើមទាំងនេះគឺជាអត្ថបទពីរផ្សេងគ្នា - ប្រហាក់ប្រហែល។ ផ្លូវ) យើងនឹងប្រៀបធៀបការអនុវត្ត ការប្រើប្រាស់អង្គចងចាំ និង ភាពយឺតយ៉ាវ។ ប៉ុន្តែ​យើង​អាច​ឃើញ​រួច​ហើយ​ថា​ស្ថានីយ​មួយ​ចំនួន​ដែល​ជា​សំណួរ​មាន​ចំណុច​ខ្វះខាត​ធ្ងន់ធ្ងរ។ ជាឧទាហរណ៍ អ្នកប្រើប្រាស់ដែលធ្វើការជាទៀងទាត់ជាមួយស្គ្រីប RTL ប្រហែលជាចង់ពិចារណា mlterm និង pterm ព្រោះថាពួកគេប្រសើរជាងក្នុងការដោះស្រាយកិច្ចការស្រដៀងគ្នាជាងអ្នកដទៃ។ កុងសូលក៏ដំណើរការបានល្អផងដែរ។ អ្នកប្រើប្រាស់ដែលមិនដំណើរការជាមួយស្គ្រីប RTL អាចជ្រើសរើសអ្វីផ្សេងទៀត។

នៅក្នុងលក្ខខណ្ឌនៃការការពារប្រឆាំងនឹងការបញ្ចូលកូដព្យាបាទ urxvt លេចធ្លោដោយសារតែការអនុវត្តពិសេសរបស់វានៃការការពារប្រឆាំងនឹងប្រភេទនៃការវាយប្រហារនេះ ដែលហាក់ដូចជាងាយស្រួលសម្រាប់ខ្ញុំ។ សម្រាប់​អ្នក​ដែល​កំពុង​ស្វែងរក​សំឡេង​កណ្ដឹង និង​សំឡេង​កណ្ដឹង Konsole គឺ​មានតម្លៃ​មើល។ ជាចុងក្រោយ វាគួរឱ្យកត់សម្គាល់ថា VTE គឺជាមូលដ្ឋានដ៏ល្អសម្រាប់ស្ថានីយ ដែលធានានូវការគាំទ្រពណ៌ ការទទួលស្គាល់ URL និងអ្វីៗផ្សេងទៀត។ នៅក្រឡេកមើលដំបូង ស្ថានីយលំនាំដើមដែលភ្ជាប់មកជាមួយបរិយាកាសដែលអ្នកចូលចិត្តអាចបំពេញតាមតម្រូវការទាំងអស់ ប៉ុន្តែសូមទុកសំណួរនេះឱ្យបើកចំហរហូតទាល់តែយើងយល់ពីដំណើរការ។

តោះបន្តការសន្ទនា

ជាទូទៅ ដំណើរការនៃស្ថានីយនៅក្នុងខ្លួនវាហាក់ដូចជាបញ្ហាឆ្ងាយ ប៉ុន្តែដូចដែលវាប្រែចេញ ពួកវាមួយចំនួនបង្ហាញភាពយឺតយ៉ាវខ្ពស់គួរឱ្យភ្ញាក់ផ្អើលសម្រាប់កម្មវិធីនៃប្រភេទមូលដ្ឋានបែបនេះ។ បន្ទាប់មកទៀត យើងនឹងពិនិត្យមើលនូវអ្វីដែលជាប្រពៃណីហៅថា "ល្បឿន" (តាមពិតទៅនេះគឺជាល្បឿនរមូរ) និងការប្រើប្រាស់អង្គចងចាំរបស់ស្ថានីយ (ដោយមានការព្រមានថាវាមិនសំខាន់ដូចសព្វថ្ងៃនេះដូចកាលពីប៉ុន្មានទសវត្សរ៍មុនទេ)។

ពន្យាពេល

បន្ទាប់ពីការសិក្សាហ្មត់ចត់នៃដំណើរការស្ថានីយខ្ញុំបានសន្និដ្ឋានថាប៉ារ៉ាម៉ែត្រសំខាន់បំផុតក្នុងន័យនេះគឺភាពយឺតយ៉ាវ (ping) ។ នៅក្នុងអត្ថបទរបស់គាត់។ "យើងបោះពុម្ពដោយសេចក្តីរីករាយ" Pavel Fatin បានក្រឡេកមើលភាពយឺតយ៉ាវរបស់អ្នកកែអត្ថបទផ្សេងៗ ហើយបានណែនាំថាស្ថានីយក្នុងរឿងនេះអាចយឺតជាងកម្មវិធីកែអត្ថបទលឿនបំផុត។ វាគឺជាតម្រុយនេះដែលនាំឱ្យខ្ញុំរត់ការសាកល្បងផ្ទាល់ខ្លួនរបស់ខ្ញុំ និងសរសេរអត្ថបទនេះ។

ប៉ុន្តែ​អ្វី​ទៅ​ជា​ភាព​យឺតយ៉ាវ ហើយ​ហេតុ​អ្វី​បាន​ជា​វា​សំខាន់​ម៉្លេះ? នៅក្នុងអត្ថបទរបស់គាត់ Fatin បានកំណត់វាជា "ការពន្យាពេលរវាងការចុចគ្រាប់ចុច និងការអាប់ដេតអេក្រង់ដែលត្រូវគ្នា" ហើយបានដកស្រង់ "មគ្គុទ្ទេសក៍ចំពោះអន្តរកម្មមនុស្ស-កុំព្យូទ័រ"ដែលចែងថា៖ "ការពន្យាពេលនៃមតិកែលម្អដែលមើលឃើញនៅលើអេក្រង់កុំព្យូទ័រមានផលប៉ះពាល់យ៉ាងសំខាន់ទៅលើអាកប្បកិរិយា និងការពេញចិត្តរបស់អ្នកវាយអត្ថបទ។"

Fatin ពន្យល់ថា ping នេះមានផលវិបាកច្រើនជាងការពេញចិត្ត៖ "ការវាយអក្សរកាន់តែយឺត កំហុសកាន់តែច្រើនកើតឡើង ហើយភាពតានតឹងនៃភ្នែក និងសាច់ដុំកើនឡើង។" ម្យ៉ាងវិញទៀត ការពន្យាពេលដ៏ធំមួយអាចនាំឱ្យមានការវាយអក្សរ និងគុណភាពកូដទាបផងដែរ ព្រោះវានាំទៅដល់ការផ្ទុកការយល់ដឹងបន្ថែមនៅលើខួរក្បាល។ ប៉ុន្តែអ្វីដែលកាន់តែអាក្រក់នោះគឺថា ភីង "បង្កើនភាពតានតឹងនៃភ្នែក និងសាច់ដុំ" ដែលហាក់ដូចជាមានន័យ ការអភិវឌ្ឍនៃការរងរបួសការងារ នៅ​ពេល​អនាគត (ជាក់ស្តែង, អ្នកនិពន្ធមានន័យថាបញ្ហាជាមួយនឹងសាច់ដុំនៃភ្នែក, ត្រឡប់មកវិញ, ដៃនិង, ជាការពិតណាស់, ចក្ខុវិស័យ - ប្រហាក់ប្រហែល។ ផ្លូវ) ដោយសារតែភាពតានតឹងដដែលៗ។

ផល​ប៉ះពាល់​មួយ​ចំនួន​នេះ​ត្រូវ​បាន​គេ​ដឹង​ជា​យូរ​មក​ហើយ​និង​លទ្ធផល ការស្រាវជ្រាវដែលត្រូវបានបោះពុម្ពនៅឆ្នាំ 1976 នៅក្នុងទស្សនាវដ្តី Ergonomics បាននិយាយថាការពន្យារពេល 100 មិល្លីវិនាទី "ធ្វើឱ្យខូចល្បឿនវាយអក្សរយ៉ាងខ្លាំង" ។ ថ្មីៗនេះ ការណែនាំអ្នកប្រើប្រាស់ GNOME បានណែនាំ ពេលវេលាឆ្លើយតបដែលអាចទទួលយកបាន។ ក្នុងរយៈពេល 10 មិល្លីវិនាទី ហើយប្រសិនបើអ្នកបន្តទៅទៀត។ Microsoft Research បង្ហាញថា 1 មិល្លីវិនាទីគឺល្អ។

Fatin បានធ្វើតេស្តរបស់គាត់លើកម្មវិធីនិពន្ធអត្ថបទ។ គាត់បានបង្កើតឧបករណ៍ចល័តមួយហៅថា ម៉ាស៊ីនវាយអក្សរដែលខ្ញុំធ្លាប់សាកល្បង ping នៅក្នុងឧបករណ៍ត្រាប់តាមស្ថានីយ។ សូមចងចាំថាការធ្វើតេស្តនេះត្រូវបានធ្វើឡើងក្នុងរបៀបក្លែងធ្វើ៖ តាមពិតយើងត្រូវគិតគូរទាំងការបញ្ចូល (ក្តារចុច ឧបករណ៍បញ្ជា USB ។ល។) និងទិន្នផល (សតិបណ្ដោះអាសន្នកាតវីដេអូ ម៉ូនីទ័រ) ភាពយឺតយ៉ាវ។ យោងទៅតាម Fatin នៅក្នុងការកំណត់ធម្មតាវាមានប្រហែល 20 ms ។ ប្រសិនបើអ្នកមានឧបករណ៍លេងហ្គេម អ្នកអាចសម្រេចបាននូវតួលេខនេះក្នុងរយៈពេលត្រឹមតែ 3 មិល្លីវិនាទីប៉ុណ្ណោះ។ ដោយសារយើងមានផ្នែករឹងលឿនបែបនេះរួចហើយ កម្មវិធីមិនចាំបាច់បន្ថែមភាពយឺតយ៉ាវរបស់វានោះទេ។ គោលដៅរបស់ Fatin គឺដើម្បីនាំយកភាពយឺតយ៉ាវនៃកម្មវិធីទៅ 1 មិល្លីវិនាទី ឬសូម្បីតែសម្រេចបានការហៅទូរសព្ទដោយគ្មាន ការពន្យារពេលដែលអាចវាស់វែងបាន។, របៀបនៅក្នុង IntelliJ IDEA ឆ្នាំ 15.

នេះគឺជាលទ្ធផលនៃការវាស់វែងរបស់ខ្ញុំ ក៏ដូចជាលទ្ធផលមួយចំនួនរបស់ Fatin ដើម្បីបង្ហាញថាការពិសោធន៍របស់ខ្ញុំយល់ស្របនឹងការធ្វើតេស្តរបស់គាត់៖

រឿងដំបូងដែលធ្វើអោយខ្ញុំចាប់អារម្មណ៍គឺពេលវេលាឆ្លើយតបកាន់តែប្រសើរឡើងនៃកម្មវិធីចាស់ៗដូចជា xterm និង mlterm ។ ជាមួយនឹងភាពយឺតនៃការចុះឈ្មោះដ៏អាក្រក់បំផុត (2,4 ms) ពួកគេដំណើរការបានល្អជាងស្ថានីយទំនើបលឿនបំផុត (10,6 ms សម្រាប់ st) ។ គ្មានស្ថានីយទំនើបធ្លាក់ក្រោមកម្រិត 10 មិល្លីវិនាទីទេ។ ជាពិសេស Alacritty បរាជ័យក្នុងការទាមទារ "កម្មវិធីត្រាប់តាមស្ថានីយលឿនបំផុតដែលមាន" ទោះបីជាពិន្ទុរបស់វាមានភាពប្រសើរឡើងចាប់តាំងពីការពិនិត្យឡើងវិញលើកដំបូងក្នុងឆ្នាំ 2017 ក៏ដោយ។ ជាការពិតអ្នកនិពន្ធនៃគម្រោង ដឹងពីស្ថានភាព និងកំពុងធ្វើការដើម្បីកែលម្អការបង្ហាញ។ វាគួរតែត្រូវបានគេកត់សម្គាល់ផងដែរថា Vim ប្រើ GTK3 គឺជាលំដាប់នៃរ៉ិចទ័រយឺតជាងសមភាគី GTK2 របស់វា។ ពីនេះយើងអាចសន្និដ្ឋានថា GTK3 បង្កើតភាពយឺតយ៉ាវបន្ថែម ហើយនេះត្រូវបានឆ្លុះបញ្ចាំងនៅក្នុងស្ថានីយផ្សេងទៀតទាំងអស់ដែលប្រើវា (ស្ថានីយ ស្ថានីយ Xfce4 និងស្ថានីយ GNOME)។

ទោះជាយ៉ាងណាក៏ដោយ ភាពខុសប្លែកគ្នាប្រហែលជាមិនគួរឱ្យកត់សម្គាល់ចំពោះភ្នែកទេ។ ដូចដែល Fatin ពន្យល់ថា "អ្នកមិនចាំបាច់ដឹងពីការពន្យារពេលដើម្បីឱ្យវាមានឥទ្ធិពលមកលើអ្នកទេ" ។ Fatin ក៏ព្រមានអំពីគម្លាតស្តង់ដារផងដែរ៖ "ការរំខានណាមួយនៅក្នុងភាពយឺតយ៉ាវ (ញ័រ) បង្កើតភាពតានតឹងបន្ថែមដោយសារតែការមិនអាចទាយទុកជាមុនបាន។

ក្រាហ្វខាងលើត្រូវបានយកនៅលើសុទ្ធ Debian 9 (stretch) ជាមួយ កម្មវិធីគ្រប់គ្រងបង្អួច i3. បរិយាកាសនេះបង្កើតលទ្ធផលល្អបំផុតក្នុងការធ្វើតេស្តភាពយឺតយ៉ាវ។ ដូចដែលវាប្រែថា GNOME បង្កើត ping 20 ms បន្ថែមសម្រាប់ការវាស់វែងទាំងអស់។ ការពន្យល់ដែលអាចធ្វើបានសម្រាប់នេះគឺវត្តមាននៃកម្មវិធីដែលមានដំណើរការស៊ីគ្នានៃព្រឹត្តិការណ៍បញ្ចូល។ Fatin ផ្តល់ឧទាហរណ៍សម្រាប់ករណីបែបនេះ ធ្វើការដែលបន្ថែមការពន្យារពេលដោយដំណើរការព្រឹត្តិការណ៍បញ្ចូលទាំងអស់ក្នុងពេលដំណាលគ្នា។ តាមលំនាំដើម GNOME ក៏ភ្ជាប់មកជាមួយកម្មវិធីគ្រប់គ្រងបង្អួចផងដែរ។ Mutterដែលបង្កើតស្រទាប់បន្ថែមនៃសតិបណ្ដោះអាសន្ន ដែលប៉ះពាល់ដល់ ping និងបន្ថែមភាពយឺតយ៉ាវយ៉ាងហោចណាស់ 8 មិល្លីវិនាទី។

ល្បឿនរមូរ

ការធ្វើតេស្តបន្ទាប់គឺជាការធ្វើតេស្ត "ល្បឿន" ឬ "កម្រិតបញ្ជូន" បែបប្រពៃណី ដែលវាស់ល្បឿនដែលស្ថានីយអាចរមូរទំព័រមួយបាន ខណៈពេលដែលបង្ហាញអត្ថបទជាច្រើននៅលើអេក្រង់។ មេកានិចនៃការធ្វើតេស្តខុសគ្នា; ការធ្វើតេស្តដើមគឺដើម្បីបង្កើតខ្សែអក្សរដូចគ្នាដោយប្រើពាក្យបញ្ជា seq ។ ការធ្វើតេស្តផ្សេងទៀតរួមមានការធ្វើតេស្ត Thomas E. Dickey (អ្នកថែទាំ xterm) ដែលម្តងហើយម្តងទៀត ឯកសារ terminfo.src ត្រូវបានទាញយក. នៅក្នុងការពិនិត្យឡើងវិញមួយផ្សេងទៀតនៃដំណើរការស្ថានីយ ដែនលូ ប្រើខ្សែអក្សរដែលបានអ៊ិនកូដ base32 នៃបៃចៃដន្យ ដែលជាលទ្ធផលទៅកាន់ស្ថានីយដោយប្រើឆ្មា។ Luu ចាត់ទុកការសាកល្បងបែបនេះថា "គ្មានប្រយោជន៍ដូចអ្វីដែលគេអាចស្រមៃបាន" ហើយស្នើឱ្យប្រើការឆ្លើយតបស្ថានីយជាម៉ែត្រចម្បងជំនួសវិញ។ Dickey ក៏​ហៅ​ការ​ធ្វើ​តេស្ត​របស់​គាត់​ថា​យល់​ច្រឡំ។ ទោះយ៉ាងណាក៏ដោយ អ្នកនិពន្ធទាំងពីរទទួលស្គាល់ថាកម្រិតបញ្ជូនរបស់បង្អួចស្ថានីយអាចជាបញ្ហា។ Luu បានរកឃើញ Emacs Eshell បង្កកនៅពេលបង្ហាញឯកសារធំ ហើយ Dickey បានបង្កើនប្រសិទ្ធភាពស្ថានីយដើម្បីកម្ចាត់ភាពយឺតដែលមើលឃើញរបស់ xtrerm ។ ដូច្នេះ វានៅតែមានគុណសម្បត្តិមួយចំនួនចំពោះការធ្វើតេស្តនេះ ប៉ុន្តែដោយសារដំណើរការបង្ហាញគឺខុសគ្នាខ្លាំងពីស្ថានីយទៅស្ថានីយ វាក៏អាចប្រើជាសមាសធាតុសាកល្បងដើម្បីសាកល្បងប៉ារ៉ាម៉ែត្រផ្សេងទៀតផងដែរ។

នៅទីនេះយើងឃើញ rxvt និង st នាំមុខការប្រកួតប្រជែង អមដោយ Alacritty ថ្មីជាងនេះ ដែលត្រូវបានរចនាឡើងដោយផ្តោតលើការអនុវត្ត។ បន្ទាប់គឺ Xfce (VTE family) និង Konsole ដែលលឿនជាងជិតពីរដង។ ចុងក្រោយគឺ xterm ដែលយឺតជាង rxvt ប្រាំដង។ កំឡុងពេលធ្វើតេស្ត xterm ក៏រើបម្រាស់ច្រើន ដែលធ្វើឱ្យការឆ្លងកាត់អត្ថបទពិបាកមើល ទោះបីជាវាជាបន្ទាត់ដូចគ្នាក៏ដោយ។ កុងសូល​មាន​ល្បឿន​លឿន ប៉ុន្តែ​វា​មាន​បញ្ហា​នៅ​ពេល​ខ្លះ៖ ការ​បង្ហាញ​នឹង​បង្កក​ពី​ពេល​មួយ​ទៅ​ពេល​មួយ ដោយ​បង្ហាញ​អត្ថបទ​មួយ​ផ្នែក ឬ​មិន​បង្ហាញ​វា​ទាល់​តែ​សោះ។ ស្ថានីយផ្សេងទៀតបានបង្ហាញខ្សែយ៉ាងច្បាស់ រួមទាំង st, Alacritty និង rxvt ។

Dickey ពន្យល់ថាភាពខុសគ្នានៃការអនុវត្តគឺដោយសារតែការរចនានៃរមូរសតិបណ្ដោះអាសន្ននៅក្នុងស្ថានីយផ្សេងគ្នា។ ជាពិសេសគាត់បានចោទប្រកាន់ rxvt និងស្ថានីយផ្សេងទៀតថា "មិនអនុវត្តតាមច្បាប់ទូទៅ"៖

“មិនដូច xterm ទេ rxvt មិនបានព្យាយាមបង្ហាញបច្ចុប្បន្នភាពទាំងអស់ទេ។ ប្រសិនបើវាធ្លាក់ពីក្រោយ វានឹងបដិសេធការអាប់ដេតមួយចំនួនដើម្បីតាមទាន់។ វាមានឥទ្ធិពលខ្លាំងលើល្បឿនរមូរជាក់ស្តែងជាងនៅលើអង្គចងចាំខាងក្នុង។ គុណវិបត្តិមួយគឺថា ចលនា ASCII មានភាពមិនច្បាស់លាស់។

ដើម្បីជួសជុលភាពយឺតនៃ xterm ដែលយល់ឃើញនេះ Dickey ស្នើឱ្យប្រើធនធាន fastScrollអនុញ្ញាតឱ្យ xterm បោះបង់ការអាប់ដេតអេក្រង់មួយចំនួន ដើម្បីរក្សាលំហូរ។ ការធ្វើតេស្តរបស់ខ្ញុំបញ្ជាក់ថា fastScroll ធ្វើអោយប្រសើរឡើងនូវការអនុវត្ត និងនាំមកនូវ xterm ស្មើរនឹង rxvt ។ ទោះជាយ៉ាងណាក៏ដោយ នេះគឺជាឈើច្រត់ដ៏លំបាកមួយ ដូចដែល Dickey ខ្លួនគាត់ពន្យល់ថា "ពេលខ្លះ xterm ដូចជាកុងសូល ហាក់ដូចជាជាប់គាំង ដោយសារវារង់ចាំការអាប់ដេតអេក្រង់ថ្មី បន្ទាប់ពីមួយចំនួនត្រូវបានដកចេញ។" នៅក្នុងសរសៃនេះ វាហាក់បីដូចជាស្ថានីយផ្សេងទៀតបានរកឃើញការសម្របសម្រួលដ៏ល្អបំផុតរវាងល្បឿន និងភាពត្រឹមត្រូវនៃការបង្ហាញ។

ការប្រើប្រាស់ធនធាន

ដោយមិនគិតពីថាតើវាសមហេតុផលទេក្នុងការពិចារណាល្បឿនរមូរជាមាត្រដ្ឋានដំណើរការ ការធ្វើតេស្តនេះអនុញ្ញាតឱ្យយើងក្លែងធ្វើការផ្ទុកនៅលើស្ថានីយ ដែលវាអនុញ្ញាតឱ្យយើងវាស់ប៉ារ៉ាម៉ែត្រផ្សេងទៀតដូចជាអង្គចងចាំ ឬការប្រើប្រាស់ថាស។ ម៉ែត្រត្រូវបានទទួលដោយការដំណើរការការធ្វើតេស្តដែលបានបញ្ជាក់ សេក នៅក្រោមការត្រួតពិនិត្យដំណើរការ Python ។ គាត់ប្រមូលទិន្នន័យម៉ែត្រ getrusage() សម្រាប់ ru_maxrss, ចំនួន ru_oublock и ru_inblock និងកម្មវិធីកំណត់ពេលវេលាសាមញ្ញ។

នៅក្នុងការធ្វើតេស្តនេះ ST ទទួលបានចំណាត់ថ្នាក់លេខមួយជាមួយនឹងការប្រើប្រាស់អង្គចងចាំជាមធ្យមទាបបំផុត 8 MB ដែលវាមិនគួរឱ្យភ្ញាក់ផ្អើលទេដែលពិចារណាថាគំនិតសំខាន់នៃការរចនាគឺភាពសាមញ្ញ។ mlterm, xterm និង rxvt ប្រើប្រាស់ច្រើនជាងនេះបន្តិច - ប្រហែល 12 MB ។ លទ្ធផលគួរឱ្យកត់សម្គាល់មួយទៀតគឺ Alacritty ដែលទាមទារ 30 MB ដើម្បីដំណើរការ។ បន្ទាប់មកមានស្ថានីយនៃគ្រួសារ VTE ដែលមានតួលេខពី 40 ទៅ 60 មេកាបៃ ដែលច្រើនណាស់។ ការប្រើប្រាស់នេះអាចត្រូវបានពន្យល់ដោយការពិតដែលថាស្ថានីយទាំងនេះប្រើបណ្ណាល័យកម្រិតខ្ពស់ឧទាហរណ៍ GTK ។ Konsole មកចុងក្រោយជាមួយនឹងការប្រើប្រាស់អង្គចងចាំ 65MB កំឡុងពេលធ្វើតេស្ត ទោះបីជានេះអាចបញ្ជាក់បានដោយសារមុខងារដ៏ធំទូលាយរបស់វាក៏ដោយ។

បើប្រៀបធៀបទៅនឹងលទ្ធផលពីមុនដែលទទួលបានកាលពី 4 ឆ្នាំមុន កម្មវិធីទាំងអស់ចាប់ផ្តើមប្រើប្រាស់អង្គចងចាំកាន់តែច្រើនគួរឱ្យកត់សម្គាល់។ Xterm ធ្លាប់ទាមទារ 15 MB ប៉ុន្តែឥឡូវនេះវាទាមទារ 16 MB គ្រាន់តែនៅពេលចាប់ផ្តើម។ មានការកើនឡើងស្រដៀងគ្នានៃការប្រើប្រាស់សម្រាប់ rxvt ដែលឥឡូវនេះត្រូវការ 34 MB ចេញពីប្រអប់។ Xfce Terminal យកទំហំ 20 MB ដែលធំជាងមុនបីដង ប៉ុន្តែ GNOME Terminal ត្រូវការត្រឹមតែ 32 MB ប៉ុណ្ណោះ។ ជាការពិតណាស់ រាល់ការធ្វើតេស្តមុនៗត្រូវបានអនុវត្តលើស្ថាបត្យកម្ម 2012 ប៊ីត។ នៅ LCA XNUMX Rusty Russell បានប្រាប់ថា​មាន​ហេតុផល​ស្រាលៗ​ជា​ច្រើន​ទៀត​ដែល​អាច​ពន្យល់​ពី​ការ​កើន​ឡើង​នៃ​ការ​ប្រើប្រាស់​អង្គ​ចងចាំ។ ដោយបាននិយាយថាឥឡូវនេះយើងរស់នៅក្នុងពេលដែលយើងមានការចងចាំជីហ្គាបៃ ដូច្នេះយើងនឹងគ្រប់គ្រងដូចម្ដេច។

ទោះយ៉ាងណាក៏ដោយ ខ្ញុំមិនអាចជួយអ្វីបានឡើយ ប៉ុន្តែមានអារម្មណ៍ថា ការបែងចែកអង្គចងចាំបន្ថែមទៅអ្វីមួយដែលជាមូលដ្ឋាន ដូចជាស្ថានីយគឺជាការខ្ជះខ្ជាយធនធាន។ កម្មវិធីទាំងនេះគួរតែតូចបំផុត តូចបំផុតគួរតែអាចដំណើរការលើ "ប្រអប់" ណាមួយ សូម្បីតែប្រអប់ស្បែកជើង ប្រសិនបើយើងធ្លាប់មកដល់ចំណុចដែលពួកគេត្រូវបំពាក់ជាមួយប្រព័ន្ធលីនុច (ហើយអ្នកដឹងថាវានឹងមានដូច្នេះ។ ) ។ ប៉ុន្តែជាមួយនឹងលេខទាំងនេះ ការប្រើប្រាស់អង្គចងចាំនឹងក្លាយទៅជាបញ្ហានាពេលអនាគតនៅក្នុងបរិយាកាសណាមួយដែលកំពុងដំណើរការស្ថានីយជាច្រើន ក្រៅពីសមត្ថភាពស្រាលបំផុត និងកម្រិតបំផុតមួយចំនួន។ ដើម្បីទូទាត់សងសម្រាប់ការនេះ GNOME Terminal, Konsole, urxvt, Terminator និង Xfce Terminal មានរបៀប Daemon ដែលអនុញ្ញាតឱ្យអ្នកគ្រប់គ្រងស្ថានីយច្រើនតាមរយៈដំណើរការតែមួយ ដោយកំណត់ការប្រើប្រាស់អង្គចងចាំរបស់វា។

ក្នុងអំឡុងពេលធ្វើតេស្តរបស់ខ្ញុំ ខ្ញុំបានទទួលបានលទ្ធផលដែលមិននឹកស្មានដល់មួយទៀតទាក់ទងនឹងការអាន-សរសេរថាស៖ ខ្ញុំរំពឹងថានឹងមិនឃើញអ្វីសោះនៅទីនេះ ប៉ុន្តែវាបានប្រែក្លាយថាស្ថានីយមួយចំនួនសរសេរទិន្នន័យដែលមានពន្លឺខ្លាំងបំផុតទៅថាស។ ដូច្នេះ បណ្ណាល័យ VTE ពិតជារក្សាសតិបណ្ដោះអាសន្នរមូរនៅលើថាស (លក្ខណៈពិសេសនេះ។ ត្រូវបានកត់សម្គាល់ឡើងវិញក្នុងឆ្នាំ 2010ហើយរឿងនេះនៅតែកើតឡើង) ។ ប៉ុន្តែមិនដូចការអនុវត្តចាស់ទេ ឥឡូវនេះយ៉ាងហោចណាស់ទិន្នន័យនេះត្រូវបានអ៊ិនគ្រីបដោយប្រើ AES256 GCM (ពីកំណែ 0.39.2) ប៉ុន្តែសំណួរសមហេតុផលមួយកើតឡើង៖ អ្វីដែលពិសេសអំពីបណ្ណាល័យ VTE ដែលវាទាមទារវិធីសាស្រ្តមិនស្តង់ដារក្នុងការអនុវត្ត...

សេចក្តីសន្និដ្ឋាន

នៅក្នុងផ្នែកដំបូងនៃអត្ថបទ យើងបានរកឃើញថាស្ថានីយដែលមានមូលដ្ឋានលើ VTE មានសំណុំមុខងារដ៏ល្អមួយ ប៉ុន្តែឥឡូវនេះយើងឃើញថាវាភ្ជាប់មកជាមួយតម្លៃប្រតិបត្តិការមួយចំនួន។ ឥឡូវនេះអង្គចងចាំមិនមែនជាបញ្ហាទេព្រោះស្ថានីយ VTE ទាំងអស់អាចត្រូវបានគ្រប់គ្រងតាមរយៈដំណើរការ Daemon ដែលកំណត់ចំណង់អាហាររបស់ពួកគេ។ ទោះជាយ៉ាងណាក៏ដោយ ប្រព័ន្ធចាស់ៗដែលមានកម្រិតរាងកាយលើចំនួន RAM និង kernel buffers អាចនៅតែត្រូវការកំណែមុនរបស់ terminals ព្រោះវាប្រើប្រាស់ធនធានតិចជាងច្រើន។ ទោះបីជាស្ថានីយ VTE ដំណើរការបានល្អក្នុងការធ្វើតេស្តឆ្លងកាត់ (រមូរ) ក៏ដោយ ភាពយឺតយ៉ាវក្នុងការបង្ហាញរបស់ពួកគេគឺលើសពីកម្រិតដែលបានកំណត់នៅក្នុងការណែនាំអ្នកប្រើប្រាស់ GNOME ។ អ្នកអភិវឌ្ឍន៍ VTE ប្រហែលជាត្រូវយកមកពិចារណា។ ប្រសិនបើយើងពិចារណាថា សូម្បីតែអ្នកប្រើប្រាស់លីនុចថ្មីថ្មោងដែលជួបប្រទះស្ថានីយគឺជៀសមិនរួច ពួកគេអាចធ្វើឱ្យវាកាន់តែងាយស្រួលប្រើ។ សម្រាប់អ្នកដែលមានបទពិសោធន៍ ការប្តូរពីស្ថានីយលំនាំដើមអាចមានន័យថា មិនសូវមានភាពតានតឹងក្នុងភ្នែក និងសមត្ថភាពក្នុងការជៀសវាងការរងរបួស និងជំងឺដែលទាក់ទងនឹងការងារនាពេលអនាគត ដោយសារការងារយូរ។ ជាអកុសល មានតែ xterm និង mlterm ចាស់ប៉ុណ្ណោះដែលនាំយើងទៅដល់កម្រិត ping វេទមន្ត 10 មិល្លីវិនាទី ដែលជាការមិនអាចទទួលយកបានសម្រាប់មនុស្សជាច្រើន។

ការវាស់វែង Benchmark ក៏បានបង្ហាញផងដែរថា ដោយសារតែការអភិវឌ្ឍនៃបរិស្ថានក្រាហ្វិកលីនុច អ្នកអភិវឌ្ឍន៍ត្រូវតែធ្វើការសម្របសម្រួលមួយចំនួន។ អ្នក​ប្រើ​ខ្លះ​ប្រហែល​ជា​ចង់​មើល​កម្មវិធី​គ្រប់គ្រង​វិនដូ​ធម្មតា ដោយសារ​ពួកគេ​ផ្តល់​នូវ​ការ​កាត់​បន្ថយ ping យ៉ាង​សំខាន់។ ជាអកុសល វាមិនអាចវាស់វែងភាពយឺតយ៉ាវសម្រាប់ Wayland បានទេ៖ កម្មវិធី Typometer ដែលខ្ញុំបានប្រើត្រូវបានបង្កើតឡើងសម្រាប់អ្វីដែល Wayland ត្រូវបានរចនាឡើងដើម្បីការពារ៖ ការធ្វើចារកម្មនៅលើបង្អួចផ្សេងទៀត។ ខ្ញុំសង្ឃឹមថាការតែងនិពន្ធ Wayland ដំណើរការបានល្អជាង X.org ហើយខ្ញុំក៏សង្ឃឹមថានៅពេលអនាគតនរណាម្នាក់នឹងស្វែងរកវិធីដើម្បីវាស់ស្ទង់ភាពយឺតយ៉ាវនៅក្នុងបរិយាកាសនេះ។

ប្រភព: www.habr.com