terminal emulator များ၏ခြုံငုံသုံးသပ်ချက်

ကျွန်ုပ်တို့၏ ဘာသာပြန်ဗျူရိုမှ စကားလုံးအချို့- အများအားဖြင့် လူတိုင်းသည် နောက်ဆုံးထွက်ပစ္စည်းများနှင့် ထုတ်ဝေမှုများကို ဘာသာပြန်ဆိုရန် ကြိုးစားကြပြီး ကျွန်ုပ်တို့သည် ချွင်းချက်မဟုတ်ပါ။ သို့သော် terminals များသည် တစ်ပတ်လျှင် တစ်ကြိမ် အပ်ဒိတ်လုပ်သော အရာမဟုတ်ပါ။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် သင့်အတွက် 2018 နွေဦးတွင်ထုတ်ဝေသော Antoine Beaupré ၏ဆောင်းပါးတစ်ပုဒ်ကို ဘာသာပြန်ထားသည်- ခေတ်မီစံနှုန်းအရ အတော်အတန် "အသက်" ရှိသော်လည်း၊ ကျွန်ုပ်တို့၏အမြင်အရ၊ ပစ္စည်းသည် ၎င်း၏ဆက်စပ်မှုကို လုံးဝဆုံးရှုံးသွားခြင်းမရှိပေ။ ထို့အပြင်၊ ၎င်းသည် မူလက ဆောင်းပါးနှစ်ခုတွဲဖြစ်သော်လည်း ၎င်းတို့ကို ကြီးမားသော ပို့စ်တစ်ခုအဖြစ် ပေါင်းစပ်ရန် ဆုံးဖြတ်ခဲ့သည်။

Terminals များသည် ကွန်ပျူတာသမိုင်းတွင် အထူးနေရာတစ်ခုရှိသော်လည်း မကြာသေးမီဆယ်စုနှစ်များအတွင်း ၎င်းတို့သည် နေရာအနှံ့တွင် ဂရပ်ဖစ်အင်တာဖေ့စ်များ ပျံ့နှံ့လာသဖြင့် အမိန့်ပေးစာကြောင်းနှင့်အတူ ရှင်သန်ရပ်တည်ရန် တွန်းအားပေးခံခဲ့ရသည်။ Terminal emulator များ သူတို့ကိုယ်တိုင် အစားထိုးတယ်။ hardware ညီအစ်ကိုတို့၎င်းသည် punched cards နှင့် toggle switches များကို အခြေခံ၍ စနစ်များ ပြုပြင်ပြောင်းလဲမှုတစ်ခုဖြစ်သည်။ ခေတ်မီဖြန့်ဖြူးမှုများတွင် ပုံသဏ္ဍာန်နှင့် အရောင်အားလုံး၏ terminal emulator အမျိုးမျိုးဖြင့် လာပါသည်။ များစွာသောသူတို့သည် ၎င်းတို့၏အလုပ်ပတ်ဝန်းကျင်မှ ပံ့ပိုးပေးထားသော စံဂိတ်နှင့် ကျေနပ်နေသော်လည်း၊ အချို့က ၎င်းတို့၏အကြိုက်ဆုံး shell သို့မဟုတ် စာသားတည်းဖြတ်ရန် မှန်ကန်သောထူးခြားဆန်းပြားသောဆော့ဖ်ဝဲလ်ကို ဂုဏ်ယူစွာအသုံးပြုကြသည်။ သို့သော်၊ ဤဆောင်းပါးမှ ကျွန်ုပ်တို့ မြင်တွေ့ရမည့်အတိုင်း၊ terminal အားလုံးကို တူညီသောပုံသဏ္ဍာန်ဖြင့် ဖန်တီးထားခြင်းမဟုတ်ပါ- ၎င်းတို့သည် လုပ်ဆောင်နိုင်စွမ်း၊ အရွယ်အစားနှင့် စွမ်းဆောင်ရည်တို့တွင် အလွန်ကွာခြားပါသည်။

အချို့သော terminals များတွင် အံ့သြစရာကောင်းလောက်အောင် လုံခြုံရေးအပေါက်များပါရှိပြီး အများစုတွင် တက်ဘ်ဒ်အင်တာဖေ့စ်ကို ပံ့ပိုးမှုမှ ဇာတ်ညွှန်းရေးသားခြင်းအထိ လုံးဝကွဲပြားသည့်လုပ်ဆောင်ချက်အစုံပါရှိသည်။ ကျွန်တော်လည်း ပါတယ်။ ဝေးကွာသောအတိတ်ရှိ terminal emulator များကိုကြည့်ရှုခဲ့သည်။ဤဆောင်းပါးသည် 2018 တွင် မည်သည့် terminal ကိုအသုံးပြုရမည်ကို စာဖတ်သူများအား ဆုံးဖြတ်ရာတွင် ကူညီပေးမည့် ယခင်အကြောင်းအရာ၏ အပ်ဒိတ်တစ်ခုဖြစ်သည်။ ဆောင်းပါး၏ ပထမနှစ်ဝက်တွင် အင်္ဂါရပ်များကို နှိုင်းယှဉ်ပြီး ဒုတိယပိုင်းတွင် စွမ်းဆောင်ရည်ကို အကဲဖြတ်ပါသည်။

ဤသည်မှာ ကျွန်တော်သုံးသပ်ထားသော terminals များဖြစ်သည်-

ကျွန်တော် ဒီစာရေးနေချိန်မှာ Stable build တွေကိုပဲ အသုံးပြုနိုင်သေးတာကြောင့် ဒါတွေက နောက်ဆုံးထွက်ဗားရှင်းတွေ မဟုတ်လောက်ပါဘူး။ Debian 9 သို့မဟုတ် Fedora 27။ တစ်ခုတည်းသောခြွင်းချက်မှာ Alacritty ဖြစ်သည်။ ၎င်းသည် GPU-accelerated terminal များမှဆင်းသက်လာပြီး ဤတာဝန်အတွက် ထူးခြားပြီး အသစ်ဖြစ်သော Rust ဘာသာစကားဖြင့် ရေးသားထားသည်။ ကျွန်ုပ်၏သုံးသပ်ချက်မှ web terminal များကို ချန်လှပ်ထားပါသည် (ပေါ်ရှိ terminal များအပါအဝင်) အီလက်ထရွန်အဘယ်ကြောင့်ဆိုသော် ပဏာမစမ်းသပ်မှုများသည် ၎င်းတို့၏ အလွန်ညံ့ဖျင်းသောစွမ်းဆောင်ရည်ကို ပြသသောကြောင့်ဖြစ်သည်။

ယူနီကုဒ် ပံ့ပိုးမှု

Unicode ပံ့ပိုးမှုဖြင့် ကျွန်ုပ်၏ စမ်းသပ်မှုများကို စတင်ခဲ့ပါသည်။ Terminals များ၏ ပထမဆုံးစမ်းသပ်မှုမှာ ယူနီကုဒ်စာကြောင်းကို ပြသရန်ဖြစ်သည်။ ဝီကီပီးဒီးယား ဆောင်းပါးများ- "é, Δ, И, ק, م, XNUMX, あ, 叶, 葉 နှင့် 말" ဤရိုးရှင်းသောစမ်းသပ်မှုသည် terminal သည် ကမ္ဘာတစ်ဝှမ်းတွင် မှန်ကန်စွာလည်ပတ်နိုင်သည်ရှိမရှိကို ပြသသည်။ xterm terminal သည် အာရဗီအက္ခရာကို မပြပါ။ မေမေ ပုံသေဖွဲ့စည်းပုံတွင်-

မူရင်းအားဖြင့်၊ xterm သည် အဆိုအရ အဆိုပါ ဂန္တဝင် "ပုံသေ" ဖောင့်ကို အသုံးပြုသည်။ Vicky က အတူတူပါပဲ။"1997 ကတည်းက Unicode လွှမ်းခြုံမှု" ရှိသည်။ ဤဖောင့်တွင် စာလုံးကို အလွတ်ဘောင်တစ်ခုအဖြစ် ပေါ်လာစေသော အရာတစ်ခု ဖြစ်ပေါ်နေပြီး စာလုံးဖောင့်ကို အမှတ် 20+ အထိ တိုးလာမှသာ စာလုံးသည် နောက်ဆုံးတွင် မှန်ကန်စွာပြသနိုင်မည်ဖြစ်သည်။ သို့သော်၊ ဤ “ပြင်ဆင်ချက်” သည် အခြား ယူနီကုဒ် အက္ခရာများ၏ ဖော်ပြမှုကို ချိုးဖျက်သည်-

ဒီ screenshot တွေကို Fedora 27 မှာ ရိုက်ယူထားတာဖြစ်ပြီး ရလဒ်တွေက ပိုကောင်းတာကြောင့်ပါ။ Debian ၉၊ အချို့သော terminal ဗားရှင်းဟောင်းများ (အထူးသဖြင့် mlterm) သည် ဖောင့်များကို ကောင်းမွန်စွာ မကိုင်တွယ်နိုင်ပါ။ ကံကောင်းထောက်မစွာ၊ ၎င်းကို နောက်ပိုင်းဗားရှင်းများတွင် ပြင်ဆင်ပြီးဖြစ်သည်။

ယခု xterm တွင် လိုင်းကို မည်သို့ပြသသည်ကို သတိပြုပါ။ Mem နှင့် အောက်ပါ Semitic သင်္ကေတ ထွက်လာပါသည်။ qoph RTL စတိုင် script များကို ကိုးကားပါ (ညာမှဘယ်သို့) ထို့ကြောင့် နည်းပညာအရ ၎င်းတို့ကို ညာမှဘယ်သို့ ပြသသင့်သည်။ Firefox 57 ကဲ့သို့သော ဝဘ်ဘရောက်ဆာများသည် အထက်ပါစာကြောင်းကို မှန်ကန်စွာ ကိုင်တွယ်သည်။ RTL စာသား၏ ရိုးရှင်းသောဗားရှင်းမှာ "စကားလုံး" ဖြစ်သည်။စာရာသည်" ဟီးဘရူး (၏). ဝီကီ ​​စာမျက်နှာတွင် နှစ်သွယ် စာသားများ အောက်ပါအတိုင်းပြောသည်

“ကွန်ပြူတာ ပရိုဂရမ်များစွာသည် နှစ်လမ်းညွန်စာသားကို မှန်ကန်စွာ မပြနိုင်ပါ။ ဥပမာအားဖြင့်၊ ဟေဗြဲအမည် "Sarah" တွင် sin (sh) (ညာဘက်တွင်ပေါ်လာသည်)၊ ထို့နောက် resh (r) နှင့်နောက်ဆုံးတွင်သူ ( ה) (ဘယ်ဘက်တွင်ပေါ်လာသင့်သည်) တို့ပါဝင်သည်။

terminals အများအပြားသည် ဤစမ်းသပ်မှုတွင် ကျရှုံးသည်- Alacritty၊ VTE မှဆင်းသက်လာသော Gnome နှင့် XFCE terminals၊ urxvt၊ st နှင့် xterm display "Sara" တို့ကို "Aras" ကဲ့သို့ ပြောင်းပြန်အစီအစဥ်ဖြင့် ဖော်ပြသည်။

bidirectional texts များ၏နောက်ထပ်ပြဿနာမှာ အထူးသဖြင့် RTL နှင့် LTR စာသားများကို ရောနှောခြင်းနှင့်ပတ်သက်လာသောအခါ ၎င်းတို့ကို တစ်နည်းနည်းနှင့် ချိန်ညှိရန် လိုအပ်ပါသည်။ RTL scripts များသည် terminal window ၏ညာဘက်ခြမ်းမှ run ရမည်ဖြစ်သော်လည်း၊ LTR English သို့ default ဖြစ်သော terminals များအတွက် ဘာဖြစ်သင့်သနည်း။ ၎င်းတို့အများစုတွင် အထူးယန္တရားများ မပါရှိဘဲ စာသားအားလုံးကို ဘယ်ဘက် (Konsole တွင် အပါအဝင်) သို့ ချိန်ညှိပါ။ ခြွင်းချက်များမှာ pterm နှင့် mlterm ဖြစ်သည်

ထည့်သွင်းကာကွယ်မှု

ကျွန်ုပ်ဖော်ထုတ်ခဲ့သော နောက်ထပ်အရေးကြီးသောအင်္ဂါရပ်မှာ ထည့်သွင်းမှုဆန့်ကျင်ကာကွယ်မှုဖြစ်သည်။ စာလုံးပေါင်းသတ်ပုံများကို လူအများသိကြသော်လည်း၊

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

code execution push commands များဖြစ်သည်၊ သေချာစွာစစ်ဆေးပြီးနောက်တွင်ပင် web browser တစ်ခုမှကူးယူခြင်းနှင့် pasting လုပ်သည့်အခါ ဝှက်ထားသော command များသည် console အတွင်းသို့ ခိုးဝင်နိုင်ကြောင်း လူအနည်းငယ်က သိကြသည်။ အတည်ပြုဆိုက် Gianna Horna အမိန့်ပေးပုံသည် မည်မျှ အပြစ်ကင်းစင်ကြောင်း တောက်ပစွာ ပြသသည်-

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

Horn ၏ ဝဘ်ဆိုဒ်မှ terminal သို့ ကူးထည့်လိုက်သောအခါ ထိုကဲ့သို့ အနှောင့်အယှက် ဖြစ်သွားသည်-

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 ကို အသုံးပြု၍ အသုံးပြုသူ၏ အမြင်မှ ရွှေ့ထားသည်။

ဘောင်ခတ်ထားသော ကူးထည့်မုဒ် ထိုသို့သော တိုက်ခိုက်မှုများကို ချေမှုန်းရန် ထင်ရှားစွာ ဒီဇိုင်းထုတ်ထားသည်။ ဤမုဒ်တွင်၊ terminal များသည် စာသား၏မူလအစကို shell ကိုပြောပြရန် အထူးအလွတ်အစီအစဥ်တစ်စုံတွင် ကူးထည့်ထားသောစာသားကို ဖုံးအုပ်ထားသည်။ ၎င်းသည် ကူးထည့်ထားသော စာသားပါရှိသော အထူးအက္ခရာများကို လျစ်လျူရှုနိုင်သည်ဟု Shell အား ပြောပြသည်။ terminal များအားလုံးသည် venerable xterm သို့ ပြန်သွားရန် ဤအင်္ဂါရပ်ကို ပံ့ပိုးပေးသည်၊ သို့သော် Bracketed မုဒ်တွင် ကူးထည့်ခြင်းသည် terminal ပေါ်တွင် လုပ်ဆောင်နေသော shell သို့မဟုတ် application မှ ပံ့ပိုးမှု လိုအပ်ပါသည်။ ဥပမာအားဖြင့်၊ software ကိုအသုံးပြုသည်။ GNU Readline (တူညီသော Bash) ဖိုင်တစ်ခုလိုအပ်သည်။ ~/.inputrc:

set enable-bracketed-paste on

ကံမကောင်းစွာပဲ၊ Horn ၏ စမ်းသပ်ဆိုက်သည် ဤအကာအကွယ်ကို စာသားဖော်မတ်ချခြင်းမှတစ်ဆင့် ၎င်းကို မည်သို့ကျော်ဖြတ်ရမည်ကို ပြသပြီး ၎င်းတွင် Bracketed မုဒ်ကို အချိန်မတန်မီ အသုံးပြုခြင်းဖြင့် အဆုံးသတ်သွားမည်ဖြစ်သည်။ အချို့သော terminal များသည် ၎င်းတို့၏ကိုယ်ပိုင်မထည့်မီ Escape Sequence များကို မှန်ကန်စွာ စစ်ထုတ်နိုင်ခြင်း မရှိသောကြောင့် ၎င်းသည် အလုပ်လုပ်ပါသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တွင် မှန်ကန်သောဖွဲ့စည်းပုံစနစ်ဖြင့်ပင် Konsole စမ်းသပ်မှုများကို အောင်မြင်စွာ မပြီးမြောက်နိုင်ခဲ့ပါ။ .inputrc ဖိုင်။ ဆိုလိုသည်မှာ ပံ့ပိုးမထားသော အပလီကေးရှင်းတစ်ခု သို့မဟုတ် မှားယွင်းစွာဖွဲ့စည်းထားသော အခွံတစ်ခုကြောင့် သင့်စနစ်ဖွဲ့စည်းပုံအား အလွယ်တကူ ပျက်စီးသွားစေနိုင်သည်ဟု ဆိုလိုသည်။ အထူးသဖြင့် သင့်တွင် ထိုသို့သော အဝေးထိန်းစက်များစွာရှိလျှင် ဂရုတစိုက်ဖွဲ့စည်းမှုလုပ်ဆောင်မှုနည်းပါးသည့် ဝေးလံခေါင်သီသောဆာဗာများသို့ ဝင်ရောက်သည့်အခါ အထူးသဖြင့် အန္တရာယ်ရှိသည်။

ဤပြဿနာအတွက် အဖြေကောင်းတစ်ခုမှာ terminal အတွက် paste confirmation plugin ဖြစ်သည်။ urxvtလိုင်းအသစ်များပါရှိသော မည်သည့်စာသားကိုမဆို ထည့်သွင်းရန် ရိုးရှင်းစွာခွင့်ပြုချက်တောင်းသည်။ Horn မှဖော်ပြထားသော စာသားတိုက်ခိုက်မှုအတွက် ပိုမိုလုံခြုံသောရွေးချယ်ခွင့်ကို ကျွန်ုပ်မတွေ့ပါ။

တက်ဘ်များနှင့် ပရိုဖိုင်များ

ယခု လူကြိုက်များသည့် အင်္ဂါရပ်မှာ အခြား terminals များစွာပါရှိသော terminal window တစ်ခုအဖြစ် ကျွန်ုပ်တို့ သတ်မှတ်ပေးမည့် တဘ်လုပ်ထားသော အင်တာဖေ့စ်အတွက် ပံ့ပိုးမှုဖြစ်သည်။ ဤလုပ်ဆောင်ချက်သည် မတူညီသော terminal များအတွက် ကွဲပြားပြီး ရိုးရာ xterm terminal များသည် တက်ဘ်များကို လုံးဝမပံ့ပိုးသော်လည်း၊ Xfce Terminal၊ GNOME Terminal နှင့် Konsole ကဲ့သို့သော ခေတ်မီ terminal incarnations များတွင် ဤလုပ်ဆောင်ချက်ပါရှိပါသည်။ Urxvt သည် တက်ဘ်များကို ပံ့ပိုးပေးသည်၊ သို့သော် သင်သည် ပလပ်အင်ကို အသုံးပြုမှသာ ဖြစ်သည်။ သို့သော် တက်ဘ်ပံ့ပိုးမှုကိုယ်နှိုက်တွင်၊ Terminator သည် အငြင်းပွားစရာမရှိသော ခေါင်းဆောင်ဖြစ်သည်- ၎င်းသည် တက်ဘ်များကို ပံ့ပိုးပေးရုံသာမက terminals များကို မည်သည့်အစီအစဥ်တွင်မဆို စီစဉ်နိုင်သည် (အောက်ပါပုံကိုကြည့်ပါ)။

Terminator ၏နောက်ထပ်အင်္ဂါရပ်မှာ ဤတဘ်များကို အုပ်စုဖွဲ့ကာ တူညီသောခလုတ်များကို terminals အများအပြားသို့ တပြိုင်နက်တည်း ပေးပို့နိုင်ပြီး ဆာဗာများစွာတွင် အစုလိုက်အပြုံလိုက်လုပ်ဆောင်မှုများကို တပြိုင်နက်လုပ်ဆောင်ခြင်းအတွက် အကြမ်းဖျင်းသောကိရိယာကို ပေးစွမ်းနိုင်သည်။ အလားတူ အင်္ဂါရပ်ကို Konsole တွင်လည်း ထည့်သွင်းထားသည်။ ဤအင်္ဂါရပ်ကို အခြား terminals များတွင် အသုံးပြုရန်၊ သင်သည် ပြင်ပဆော့ဖ်ဝဲကဲ့သို့သော ပြင်ပဆော့ဖ်ဝဲကို အသုံးပြုရပါမည်။ Cluster SSH, xlax သို့မဟုတ် tmux.

ပရိုဖိုင်များနှင့် တွဲထားသည့်အခါ အထူးသဖြင့် တဘ်များသည် ကောင်းမွန်စွာ အလုပ်လုပ်နိုင်သည်- ဥပမာအားဖြင့်၊ သင့်တွင် အီးမေးလ်အတွက် တဘ်တစ်ခု၊ ချတ်အတွက် နောက်တစ်ခု၊ အစရှိသည်တို့ ရှိနိုင်ပါသည်။ ၎င်းကို Konsole Terminal နှင့် GNOME Terminal မှ ကောင်းမွန်စွာ ပံ့ပိုးထားပါသည်။ နှစ်ခုစလုံးသည် တက်ဘ်တစ်ခုစီကို ၎င်း၏ကိုယ်ပိုင်ပရိုဖိုင်ကို အလိုအလျောက်ဖွင့်ရန် ခွင့်ပြုသည်။ Terminator သည် ပရိုဖိုင်များကို ပံ့ပိုးပေးသည်၊ သို့သော် သင်သတ်မှတ်ထားသော တက်ဘ်တစ်ခုကိုဖွင့်သောအခါ အချို့သောပရိုဂရမ်များကို အလိုအလျောက်ဖွင့်ရန် နည်းလမ်းရှာမတွေ့ပါ။ အခြား terminal များတွင် "profile" ၏ သဘောတရား လုံးဝမရှိပါ။

Ruffles

ဤဆောင်းပါး၏ပထမအပိုင်းတွင်ကျွန်ုပ်တင်ပြမည့်နောက်ဆုံးအချက်မှာ terminals များ၏အသွင်အပြင်ဖြစ်သည်။ ဥပမာအားဖြင့် GNOME၊ Xfce နှင့် urxvt သည် ပွင့်လင်းမြင်သာမှုကို ပံ့ပိုးပေးသော်လည်း မကြာသေးမီက နောက်ခံပုံများအတွက် ပံ့ပိုးမှုကို လျှော့ချခဲ့ပြီး အချို့သောအသုံးပြုသူများကို terminal သို့ပြောင်းခိုင်းခြင်း Tilix. ပုဂ္ဂိုလ်ရေးအရ၊ ငါပျော်တယ်၊ ရိုးရှင်းတယ်။ အရင်းအမြစ်များurxvt အတွက် အခြေခံအရောင်များကို သတ်မှတ်ပေးသည်။ သို့သော် စံမမီသော အရောင်အပြင်အဆင်များသည်လည်း ပြဿနာများကို ဖန်တီးနိုင်သည်။ ဥပမာအားဖြင့်, နေရောင်ခြည်စွမ်းအင်သုံး အလုပ်မလုပ်ပါဘူး လျှောက်လွှာများနှင့် htop и IPTrafသူတို့ကိုယ်တိုင် အရောင်တွေ သုံးနေပြီဆိုတော့။

မူရင်း VT100 ဂိတ် အရောင်များကို မပံ့ပိုးဘဲ၊ အသစ်များကို မကြာခဏ 256 ရောင်စုံ palette တွင် ကန့်သတ်ထားသည်။ ၎င်းတို့၏ terminal များကို ပုံစံသွင်းသော အဆင့်မြင့်အသုံးပြုသူများအတွက်၊ shell prompts သို့မဟုတ် status bar များကို ရှုပ်ထွေးသောနည်းလမ်းများဖြင့် စိတ်အနှောင့်အယှက်ဖြစ်စေသော ကန့်သတ်ချက်တစ်ခု ဖြစ်နိုင်သည်။ အကျဉ်းချုပ် မည်သည့် terminals များသည် "True Colour" ကို ပံ့ပိုးပေးသည် ။ ကျွန်ုပ်၏စမ်းသပ်မှုများသည် st၊ Alacritty နှင့် VTE-based terminals များသည် True Color ကို အပြည့်အဝထောက်ခံကြောင်း အတည်ပြုပါသည်။ အခြား terminal များသည် ဤကိစ္စနှင့် ပတ်သက်၍ အလွန်ကောင်းမွန်ပြီး အမှန်တကယ်တွင် အရောင် 256 ရောင်တောင် မပြသနိုင်ပါ။ GNOME terminals၊ st နှင့် xterm တို့တွင် True Color ပံ့ပိုးကူညီမှုကြားတွင် ၎င်းတို့ 256 ရောင်စုံ palette နှင့် urxvt တို့ဖြင့် ကောင်းမွန်စွာလုပ်ဆောင်နိုင်သည့် ကွာခြားချက်ကို အောက်တွင် သင်တွေ့မြင်နိုင်သည်၊ ၎င်းသည် စမ်းသပ်မှုမအောင်မြင်ရုံသာမက ၎င်းတို့အစား မှိတ်တုတ်မှိတ်တုတ်မှိတ်တုတ်စာလုံးအချို့ကိုလည်း ပြသထားသည်။

အချို့သော terminal များသည် လင့်ခ်များကို နှိပ်၍ရနိုင်စေရန် URL ပုံစံများအတွက် စာသားကိုလည်း ပိုင်းခြားစိတ်ဖြာပါသည်။ ၎င်းသည် VTE မှရရှိသော terminal များအားလုံးနှင့် အကျုံးဝင်သော်လည်း urxvt သည် ကလစ်တစ်ချက်နှိပ်ရုံဖြင့် URL များကို ပြောင်းလဲမည့် သို့မဟုတ် ကီးဘုတ်ဖြတ်လမ်းကို အသုံးပြု၍ အထူးပလပ်အင်တစ်ခု လိုအပ်ပါသည်။ အခြားနည်းလမ်းများဖြင့် ပြသထားသော URL များကို ကျွန်ုပ်စမ်းသပ်ပြီးသော အခြားစက်များ။

နောက်ဆုံးတွင်၊ terminals များတွင်လမ်းကြောင်းသစ်တစ်ခုသည် scroll ကြားခံ၏ရွေးချယ်ခွင့်ဖြစ်သည်။ ဥပမာ၊ st တွင် scroll ကြားခံမရှိပါ။ အသုံးပြုသူသည် tmux နှင့် ကဲ့သို့သော terminal multiplexer ကို အသုံးပြုမည်ဟု ယူဆပါသည်။ GNU မျက်နှာပြင်.

Alacritty သည် backscroll buffers လည်းမရှိသော်လည်း၊ မကြာမီ ထပ်ထည့်ပါမည်။ အသုံးပြုသူများထံမှ ဤအကြောင်းအရာအပေါ် "ကျယ်ပြန့်သောတုံ့ပြန်ချက်" ကြောင့် ၎င်း၏ပံ့ပိုးမှု။ ဤအရာများအပြင်၊ ကျွန်ုပ်စမ်းသပ်ထားသော terminal တိုင်းသည် reverse scrolling ကို ပံ့ပိုးပေးပါသည်။

စုစုပေါင်း

ပစ္စည်း၏ဒုတိယအပိုင်းတွင် (မူရင်းတွင် ဤနှစ်ခုကွဲပြားသော ဆောင်းပါးများဖြစ်သည် - အနီးစပ်ဆုံး။ လမ်းသွား) စွမ်းဆောင်ရည်၊ မှတ်ဉာဏ်အသုံးပြုမှုနှင့် latency တို့ကို နှိုင်းယှဉ်ပါမည်။ သို့သော် အချို့သော terminals များတွင် ဆိုးရွားသော ချို့ယွင်းချက်များ ရှိနေသည်ကို ကျွန်ုပ်တို့ မြင်နိုင်နေပြီဖြစ်သည်။ ဥပမာအားဖြင့်၊ RTL script များနှင့် ပုံမှန်အလုပ်လုပ်သော အသုံးပြုသူများသည် အခြားသူများထက် အလားတူလုပ်ဆောင်မှုများကို ကိုင်တွယ်ရာတွင် ပိုကောင်းသောကြောင့် mlterm နှင့် pterm ကို ထည့်သွင်းစဉ်းစားလိုပေမည်။ Konsole လည်း ကောင်းမွန်စွာ စွမ်းဆောင်နိုင်ခဲ့သည်။ RTL script များနှင့်အလုပ်မလုပ်သောအသုံးပြုသူများသည်အခြားတစ်ခုခုကိုရွေးချယ်နိုင်သည်။

အန္တရာယ်ရှိသောကုဒ်ထည့်သွင်းခြင်းမှကာကွယ်ခြင်းဆိုင်ရာစည်းကမ်းချက်များအရ၊ urxvt သည် ကျွန်ုပ်အတွက်ကျိန်းသေအဆင်ပြေပုံပေါ်သော ဤတိုက်ခိုက်မှုမျိုးအား ၎င်း၏အထူးလုပ်ဆောင်မှုမှကာကွယ်ပေးသောကြောင့် ထင်ရှားသည်။ ခေါင်းလောင်းများနှင့် ဝီစီများကို ရှာဖွေနေသူများအတွက် Konsole သည် ကြည့်ရကျိုးနပ်သည်။ နောက်ဆုံးတွင်၊ VTE သည် အရောင်ပံ့ပိုးမှု၊ URL အသိအမှတ်ပြုမှုစသည်ဖြင့် အာမခံသည့် terminals များအတွက် အကောင်းဆုံးအခြေခံတစ်ခုဖြစ်ကြောင်း သတိပြုသင့်ပါသည်။ ပထမတစ်ချက်တွင်၊ သင့်စိတ်ကြိုက်ပတ်ဝန်းကျင်တွင်ပါရှိသည့် မူရင်းဂိတ်သည် လိုအပ်ချက်များအားလုံးကို ဖြည့်ဆည်းပေးနိုင်သော်လည်း စွမ်းဆောင်ရည်ကို နားလည်သည်အထိ ဤမေးခွန်းကို ဖွင့်ထားကြပါစို့။

စကားဝိုင်းကို ဆက်ရအောင်

ယေဘူယျအားဖြင့်၊ terminals များ၏စွမ်းဆောင်ရည်သည် ဝေးလံခေါင်သီသောပြဿနာတစ်ခုကဲ့သို့ထင်ရသော်လည်း၊ အချို့သောအခြေခံအမျိုးအစားဖြစ်သော software အတွက် အံ့သြစရာကောင်းလောက်အောင် ကြာမြင့်ချိန်ကိုပြသထားသည်။ နောက်တွင်လည်း ရှေးယခင်ကတည်းက "အမြန်နှုန်း" ဟုခေါ်သည် (တကယ်တော့၊ ၎င်းသည် ရွေ့လျားသည့်အမြန်နှုန်း) နှင့် terminal ၏ မှတ်ဉာဏ်သုံးစွဲမှု (လွန်ခဲ့သည့်ဆယ်စုနှစ်များကဲ့သို့ ယနေ့ခေတ်ကာလကဲ့သို့ အရေးပါလှသည်မဟုတ်ကြောင်း သတိပေးချက်နှင့်အတူ) ကို ဆက်လက်ကြည့်ရှုပါမည်။

နှောင့်နှေး

terminal စွမ်းဆောင်ရည်ကို စေ့စေ့စပ်စပ်လေ့လာပြီးနောက်၊ ဤကိစ္စတွင် အရေးကြီးဆုံး parameter မှာ latency (ping) ဖြစ်ကြောင်း နိဂုံးချုပ်လိုက်ရပါသည်။ သူ့ဆောင်းပါးထဲမှာ "ကျွန်ုပ်တို့ ပျော်ရွှင်စွာ ပုံနှိပ်ခြင်း" Pavel Fatin သည် အမျိုးမျိုးသော စာသားတည်းဖြတ်သူများ၏ ကြာမြင့်ချိန်ကို ကြည့်ရှုပြီး ဤကိစ္စတွင် terminals များသည် အမြန်ဆုံး စာသားတည်းဖြတ်သူများထက် နှေးကွေးနိုင်ကြောင်း အရိပ်အမြွက်ပြောကြားခဲ့သည်။ နောက်ဆုံးတွင် ကျွန်ုပ်သည် ကျွန်ုပ်၏ကိုယ်ပိုင်စမ်းသပ်မှုများကို လုပ်ဆောင်ပြီး ဤဆောင်းပါးကို ရေးသားရန် ဤအရိပ်အမြွက်ပေးခဲ့ပါသည်။

ဒါပေမယ့် latency ဆိုတာ ဘာလဲ၊ ဘာကြောင့် အရမ်းအရေးကြီးတာလဲ။ ၎င်း၏ဆောင်းပါးတွင် Fatin က၎င်းအား "သော့နှိပ်ခြင်းနှင့်သက်ဆိုင်သည့်မျက်နှာပြင်အပ်ဒိတ်ကြားနှောင့်နှေးမှု" အဖြစ်သတ်မှတ်ပြီးကိုးကားခဲ့သည်။ "လူသား-ကွန်ပြူတာ အပြန်အလှန်ဆက်ဆံမှုလမ်းညွှန်"“ကွန်ပြူတာဖန်သားပြင်ပေါ်ရှိ အမြင်အာရုံတုံ့ပြန်ချက်တွင် နှောင့်နှေးခြင်းသည် စာစီစာရိုက်အပြုအမူနှင့် စိတ်ကျေနပ်မှုအပေါ် အရေးကြီးသောအကျိုးသက်ရောက်မှုရှိသည်။”

Fatin က ဤ ping သည် ကျေနပ်ရုံမျှမက ပိုမိုနက်နဲသော အကျိုးဆက်များရှိကြောင်း ရှင်းပြသည်- "စာရိုက်ခြင်း နှေးကွေးခြင်း၊ အမှားအယွင်းများ ပိုများလာပြီး မျက်လုံးနှင့် ကြွက်သားများ တင်းမာလာပါသည်။" တစ်နည်းအားဖြင့်ဆိုရသော် ကြီးမားသောနှောင့်နှေးမှုသည် typos ကိုဖြစ်ပေါ်စေပြီး ကုဒ်အရည်အသွေးကိုလည်း နိမ့်ကျစေကာ ၎င်းသည် ဦးနှောက်အပေါ် ထပ်လောင်းသိမြင်နိုင်စွမ်းကို တိုးစေသည်။ ဒါပေမယ့် ပိုဆိုးတာက ping က "မျက်လုံးနဲ့ ကြွက်သားတွေကို တင်းအားတိုးစေတယ်" လို့ အဓိပ္ပာယ်ရပါတယ်။ လုပ်ငန်းခွင် ထိခိုက်ဒဏ်ရာရမှု ဖွံ့ဖြိုးတိုးတက်ရေး အနာဂတ္မွာ (စာရေးသူဆိုလိုသည်မှာ မျက်လုံးများ၊ နောက်ကျော၊ လက်မောင်းများနှင့် အမြင်အာရုံဆိုင်ရာ ပြဿနာများကို ဆိုလိုသည်မှာ ထင်ရှားပါသည်။ လမ်းသွား၎) ထပ်ခါထပ်ခါ ဖိစီးမှုတွေကြောင့်။

ဤအကျိုးသက်ရောက်မှုအချို့ကိုအချိန်အကြာကြီးလူသိများပြီးရလဒ်များကို သုတေသန1976 ခုနှစ်တွင် ပြန်လည်ထုတ်ဝေခဲ့သော Ergonomics ဂျာနယ်တွင် 100 milliseconds နှောင့်နှေးခြင်းသည် စာရိုက်မြန်နှုန်းကို သိသိသာသာ ထိခိုက်စေသည်ဟု ဆိုသည်။ မကြာသေးမီက GNOME အသုံးပြုသူလမ်းညွှန်ကို မိတ်ဆက်ခဲ့သည်။ လက်ခံနိုင်သောတုံ့ပြန်မှုအချိန် 10 မီလီစက္ကန့်အတွင်း၊ သင်ဒီထက်ပိုသွားလျှင် microsoft Research 1 မီလီစက္ကန့်သည် စံပြဖြစ်သည်ကို ပြသသည်။

Fatin သည် စာသားတည်းဖြတ်သူများတွင် စမ်းသပ်မှုများ ပြုလုပ်ခဲ့သည်။ သယ်ဆောင်နိုင်သော တူရိယာတစ်မျိုးကို ဖန်တီးခဲ့သည်။ Typometerterminal emulators တွင် ping ကို စမ်းသပ်ခဲ့ဖူးသည်။ စမ်းသပ်မှုကို သရုပ်တူကူးမုဒ်တွင် ပြုလုပ်ခဲ့ကြောင်း မှတ်သားထားပါ- လက်တွေ့တွင်၊ ကျွန်ုပ်တို့သည် ထည့်သွင်းမှု (ကီးဘုတ်၊ USB ထိန်းချုပ်ကိရိယာ စသည်) နှင့် အထွက် (ဗီဒီယိုကတ်ကြားခံ၊ မော်နီတာ) latency နှစ်မျိုးလုံးကို ထည့်သွင်းစဉ်းစားရန် လိုအပ်ပါသည်။ Fatin အရ၊ ပုံမှန်ဖွဲ့စည်းပုံများတွင် ၎င်းသည် 20 ms ခန့်ရှိသည်။ သင့်တွင် ဂိမ်းကိရိယာများရှိပါက၊ သင်သည် ဤကိန်းဂဏန်းကို 3 မီလီစက္ကန့်အတွင်း ရရှိနိုင်သည်။ ကျွန်ုပ်တို့တွင်ထိုကဲ့သို့သောမြန်ဆန်သောဟာ့ဒ်ဝဲရှိပြီးသားဖြစ်သောကြောင့်၊ အပလီကေးရှင်းသည်၎င်း၏ကိုယ်ပိုင် latency ကိုထည့်သွင်းရန်မလိုအပ်ပါ။ Fatin ၏ရည်မှန်းချက်မှာ လျှောက်လွှာတင်နေချိန်ကို 1 မီလီစက္ကန့်အထိ ယူဆောင်လာရန် သို့မဟုတ် ဖုန်းခေါ်ဆိုခြင်းမရှိဘဲ ဖုန်းခေါ်ဆိုမှုအောင်မြင်ရန်ဖြစ်သည်။ တိုင်းတာနိုင်သော နှောင့်နှေးမှုဘယ်လောက် IntelliJ IDEA ၁၅.

ဤသည်မှာ ကျွန်ုပ်၏စမ်းသပ်ချက်သည် သူ၏စမ်းသပ်မှုများနှင့်ကိုက်ညီကြောင်းပြသရန် ကျွန်ုပ်၏တိုင်းတာမှုရလဒ်များအပြင် Fatin ၏ရလဒ်အချို့၊

ပထမအချက်မှာ xterm နှင့် mlterm ကဲ့သို့သော ပရိုဂရမ်အဟောင်းများ၏ ပိုမိုကောင်းမွန်သော တုံ့ပြန်ချိန်ဖြစ်သည်။ အဆိုးဆုံး မှတ်ပုံတင်ချိန်နေချိန် (2,4 ms) ဖြင့် ၎င်းတို့သည် အမြန်ဆုံး ခေတ်မီ terminal (10,6 ms for st) ထက် ပိုမိုကောင်းမွန်သည်။ ခေတ်မီ terminal သည် 10 millisecond အဆင့်ထက် နိမ့်ကျခြင်းမရှိပါ။ အထူးသဖြင့်၊ Alacritty သည် 2017 ခုနှစ်တွင် ၎င်း၏ပထမဆုံးပြန်လည်သုံးသပ်ပြီးနောက် ၎င်း၏ရမှတ်များ တိုးတက်လာသော်လည်း၊ "အမြန်ဆုံး terminal emulator ရနိုင်သော" တောင်းဆိုချက်ကို လိုက်နာရန် ပျက်ကွက်ပါသည်။ အမှန်ကတော့ ပရောဂျက်ကို ရေးသူတွေပါ။ အခြေအနေကို သတိပြုမိသည်။ မျက်နှာပြင်ကို မြှင့်တင်ရန် လုပ်ဆောင်နေပါသည်။ GTK3 ကိုအသုံးပြုသည့် Vim သည် ၎င်း၏ GTK2 အတွဲထက် ပြင်းအားနှေးကွေးသည်ဟုလည်း သတိပြုသင့်သည်။ ယင်းမှနေ၍ GTK3 သည် ထပ်လောင်း latency ကို ဖန်တီးသည်ဟု ကျွန်ုပ်တို့ ကောက်ချက်ချနိုင်ပြီး ၎င်းကို အသုံးပြုသည့် အခြား terminal များအားလုံး (Terminator၊ Xfce4 Terminal နှင့် GNOME Terminal) တွင် ထင်ဟပ်ပါသည်။

သို့သော် ခြားနားချက်များကို မျက်စိတွင် ထင်ရှားစေမည်မဟုတ်ပေ။ Fatin ကရှင်းပြသည့်အတိုင်း "သင့်အပေါ်သက်ရောက်မှုရှိရန် နှောင့်နှေးမှုကို သင်သတိထားနေရန်မလိုအပ်ပါ။" Fatin သည် စံသွေဖည်မှုအကြောင်းလည်း သတိပေးသည်- "ကြာချိန် (တုန်လှုပ်ခြင်း) တွင် အနှောင့်အယှက်များ သည် ၎င်းတို့၏ မှန်းဆမရခြင်းကြောင့် ထပ်လောင်း ဖိစီးမှု ဖြစ်စေသည်။"

အထက်ပါဇယားကို သန့်ရှင်းသောနေရာမှ ရယူထားပါသည်။ Debian ၉ (ဆန့်) s i3 ဝင်းဒိုးမန်နေဂျာ. ဤပတ်ဝန်းကျင်သည် latency စမ်းသပ်မှုများတွင် အကောင်းဆုံးရလဒ်များကို ထုတ်ပေးသည်။ ထွက်ပေါ်လာသည့်အတိုင်း GNOME သည် တိုင်းတာမှုအားလုံးအတွက် 20 ms အပို ping တစ်ခုကို ဖန်တီးသည်။ ဤအတွက် ဖြစ်နိုင်ချေရှိသော ရှင်းလင်းချက်မှာ ထည့်သွင်းသည့် ဖြစ်ရပ်များကို ချိန်ကိုက်လုပ်ဆောင်သည့် ပရိုဂရမ်များ ရှိနေခြင်း ဖြစ်သည်။ Fatin သည် ထိုကဲ့သို့သောကိစ္စအတွက် ဥပမာတစ်ခုပေးသည်။ အလုပ်ခွင်ထည့်သွင်းမှုဖြစ်ရပ်အားလုံးကို တပြိုင်တည်းလုပ်ဆောင်ခြင်းဖြင့် နှောင့်နှေးမှုကို ပေါင်းထည့်သည်။ ပုံမှန်အားဖြင့်၊ GNOME သည်လည်း ဝင်းဒိုးမန်နေဂျာပါရှိသည်။ ပြောတတ်ping ကို ထိခိုက်စေပြီး latency အနည်းဆုံး 8 မီလီစက္ကန့်ကို ထပ်လောင်းပေးသည့် buffering အလွှာတစ်ခု ထပ်မံဖန်တီးပေးပါသည်။

အရှိန်အဟုန်

နောက်စမ်းသပ်မှုသည် သမားရိုးကျ "အမြန်နှုန်း" သို့မဟုတ် "ဘန်းဝဒ်" စမ်းသပ်မှုဖြစ်ပြီး၊ terminal သည် မျက်နှာပြင်ပေါ်တွင် စာအမြောက်အမြားပြသနေစဉ် စာမျက်နှာတစ်ခုကို မည်မျှလျင်မြန်စွာ လှိမ့်နိုင်သည်ကို တိုင်းတာသည်။ စမ်းသပ်မှု၏စက်ပြင်ကွဲပြားသည်။ မူလစမ်းသပ်မှုမှာ seq command ကို အသုံးပြု၍ တူညီသော စာသားစာကြောင်းကို ဖန်တီးရန်ဖြစ်သည်။ အခြားစမ်းသပ်မှုများတွင် Thomas E. Dickey's (xterm ထိန်းသိမ်းသူ) စမ်းသပ်မှု ၊ ထပ်ခါတလဲလဲ ပြုလုပ်သော စမ်းသပ်မှုများ ပါဝင်သည်။ terminfo.src ဖိုင်ကို ဒေါင်းလုဒ်လုပ်ထားသည်။. terminal စွမ်းဆောင်ရည်၏နောက်ထပ်ပြန်လည်သုံးသပ်မှုတွင် Den Luu cat ကိုအသုံးပြု၍ terminal သို့ output ဖြစ်သော base32 encoded string ကိုအသုံးပြုသည်။ Luu သည် ထိုသို့သောစမ်းသပ်မှုကို "စိတ်ကူးနိုင်သလောက် အသုံးမဝင်သောစံနှုန်းတစ်ခုအဖြစ်" ဟုယူဆပြီး terminal တုံ့ပြန်မှုကိုမူလမက်ထရစ်တစ်ခုအဖြစ်အသုံးပြုရန် အကြံပြုထားသည်။ Dickey က သူ့စမ်းသပ်မှုကို အထင်အမြင်လွဲမှားစေတယ်လို့လည်း ခေါ်ဆိုပါတယ်။ သို့သော်လည်း၊ terminal window bandwidth သည် ပြဿနာတစ်ခုဖြစ်နိုင်သည်ကို စာရေးသူနှစ်ဦးစလုံးက အသိအမှတ်ပြုကြသည်။ Luu သည် ကြီးမားသောဖိုင်များကိုပြသသည့်အခါ Emacs Eshell အေးခဲခြင်းကိုတွေ့ရှိခဲ့ပြီး Dickey သည် xtrerm ၏အမြင်အာရုံနှေးကွေးမှုကိုဖယ်ရှားရန် terminal ကိုအကောင်းဆုံးလုပ်ဆောင်ခဲ့သည်။ ထို့ကြောင့် ဤစစ်ဆေးမှုအတွက် အကျိုးကျေးဇူးအချို့ရှိပါသေးသည်၊ သို့သော် rendering process သည် terminal မှ terminal နှင့် အလွန်ကွာခြားသောကြောင့်၊ ၎င်းကို အခြားသော parameters များကို စမ်းသပ်ရန်အတွက် test component တစ်ခုအနေဖြင့်လည်း အသုံးပြုနိုင်ပါသည်။

ဤနေရာတွင် rxvt နှင့် st တို့သည် ပြိုင်ဆိုင်မှု၏ ရှေ့သို့ ဆွဲထုတ်ခြင်းကို တွေ့မြင်ရပြီး စွမ်းဆောင်ရည်အပေါ် အာရုံစိုက်ထားသည့် ဒီဇိုင်းထုတ်ထားသည့် ပိုမိုသစ်လွင်သော Alacritty နှင့်အတူ၊ နောက်တစ်ခုကတော့ Xfce (VTE မိသားစု) နဲ့ Konsole ဖြစ်ပြီး နှစ်ဆနီးပါးမြန်ပါတယ်။ နောက်ဆုံးသည် xterm ဖြစ်ပြီး rxvt ထက် ငါးဆနှေးသည်။ စာမေးပွဲကာလအတွင်း၊ xterm သည် အလွန်တုန်လှုပ်သွားကာ စာသားတစ်ကြောင်းတည်းဖြစ်နေလျှင်ပင် မြင်ရန်ခက်ခဲစေသည်။ Konsole သည် မြန်ဆန်သော်လည်း တစ်ခါတစ်ရံတွင် ခက်ခဲသည်- ဖန်သားပြင်သည် ရံဖန်ရံခါ အေးခဲသွားကာ၊ တစ်စိတ်တစ်ပိုင်း စာသားကို ပြသသည် သို့မဟုတ် ၎င်းကို လုံးဝမပြသပါ။ st၊ Alacritty နှင့် rxvt အပါအဝင် အခြားသော terminal များသည် string များကို ရှင်းလင်းစွာပြသထားသည်။

မတူညီသော terminals များရှိ scroll buffers များ၏ ဒီဇိုင်းကြောင့် စွမ်းဆောင်ရည် ကွာခြားချက်များသည် Dickey မှ ရှင်းပြပါသည်။ အထူးသဖြင့်၊ သူသည် rxvt နှင့် အခြားသော terminals များကို "ယေဘူယျစည်းမျဉ်းများကို မလိုက်နာပါ" ဟုစွပ်စွဲသည်-

“xterm နှင့်မတူဘဲ၊ rxvt သည် အပ်ဒိတ်အားလုံးကိုပြသရန် မကြိုးစားခဲ့ပါ။ နောက်ကျသွားပါက၊ လိုက်မီရန် အချို့သော အပ်ဒိတ်များကို ငြင်းပယ်လိမ့်မည်။ ၎င်းသည် အတွင်းမှတ်ဉာဏ်အဖွဲ့အစည်းထက် ထင်ရှားသော လှိမ့်နှုန်းအပေါ် သက်ရောက်မှုပိုရှိခဲ့သည်။ အားနည်းချက်တစ်ခုမှာ ASCII ကာတွန်းသည် အနည်းငယ် မတိကျသောကြောင့်ဖြစ်သည်။"

ဤယူဆထားသော xterm နှေးကွေးမှုကို ဖြေရှင်းရန် Dickey သည် အရင်းအမြစ်ကို အသုံးပြုရန် အကြံပြုထားသည်။ အမြန်ဆွဲပါ။စီးဆင်းမှုအမီလိုက်နိုင်ရန် xterm သည် အချို့သော မျက်နှာပြင်အပ်ဒိတ်များကို စွန့်ပစ်ရန် ခွင့်ပြုသည်။ ကျွန်ုပ်၏စမ်းသပ်မှုများသည် fastScroll ၏စွမ်းဆောင်ရည်ကိုတိုးတက်စေပြီး xterm ကို rxvt နှင့်တန်းတူရရှိကြောင်းအတည်ပြုသည်။ သို့သော်၊ ၎င်းသည် Dickey ကိုယ်တိုင်ရှင်းပြသကဲ့သို့၊ "တခါတရံ xterm - konsole ကဲ့သို့ - အချို့ကိုဖယ်ရှားပြီးနောက်စခရင်မွမ်းမံမှုအသစ်တစ်ခုကိုစောင့်ဆိုင်းနေစဉ်၎င်းသည်ရပ်တန့်သွားပုံရသည်။" ဤလမ်းကြောင်းတွင်၊ အခြား terminal များသည် အမြန်နှုန်းနှင့် ပြသမှု ခိုင်မာမှုကြားတွင် အကောင်းဆုံး အပေးအယူကို တွေ့ရှိထားပုံရသည်။

သယံဇာတ သုံးစွဲမှု

Scrolling speed ကို စွမ်းဆောင်ရည်မက်ထရစ်အဖြစ် ထည့်သွင်းစဉ်းစားရန် အဓိပ္ပာယ်ရှိမရှိ၊ ဤစမ်းသပ်မှုသည် ကျွန်ုပ်တို့အား terminals ပေါ်ရှိ load ကို အတုယူနိုင်စေကာ ၎င်းသည် ကျွန်ုပ်တို့အား memory သို့မဟုတ် disk အသုံးပြုမှုကဲ့သို့သော အခြားသော parameters များကို တိုင်းတာနိုင်စေပါသည်။ သတ်မှတ်ထားသော စမ်းသပ်စစ်ဆေးမှုကို လုပ်ဆောင်ခြင်းဖြင့် မက်ထရစ်များကို ရယူခဲ့သည်။ seq Python လုပ်ငန်းစဉ်စောင့်ကြည့်မှုအောက်တွင်။ သူက မီတာဒေတာကို စုဆောင်းတယ်။ getrusage() အတွက် ru_maxrss, ပမာဏ ru_oublock и ru_inblock နှင့်ရိုးရှင်းသော timer ။

ဤစမ်းသပ်မှုတွင်၊ ST သည် အနိမ့်ဆုံးပျမ်းမျှမှတ်ဉာဏ်သုံးစွဲမှု 8 MB ဖြင့် ပထမနေရာရရှိထားပြီး ဒီဇိုင်း၏အဓိကအယူအဆမှာ ရိုးရှင်းသည်ဟု ထည့်သွင်းစဉ်းစားခြင်းသည် အံ့သြစရာမဟုတ်ပေ။ mlterm၊ xterm နှင့် rxvt အနည်းငယ်ပိုစားသည် - 12 MB ခန့်။ နောက်ထပ် ထင်ရှားသောရလဒ်မှာ Alacritty ဖြစ်ပြီး အလုပ်လုပ်ရန် 30 MB လိုအပ်သည်။ ထို့နောက်တွင် 40 မှ 60 MB မှကိန်းဂဏန်းများပါရှိသော VTE မိသားစု၏ terminals များရှိပြီး၊ ၎င်းသည်အလွန်များပြားသည်။ ဤ terminals များသည် မြင့်မားသောအဆင့်ရှိ စာကြည့်တိုက်များကို ဥပမာအားဖြင့် GTK ကိုအသုံးပြုခြင်းကြောင့် ဤစားသုံးမှုကို ရှင်းပြနိုင်သည်။ Console သည် စမ်းသပ်မှုများအတွင်း ကြီးမားသော 65MB မမ်မိုရီသုံးစွဲမှုနှင့်အတူ နောက်ဆုံးပါဝင်လာသော်လည်း ၎င်းသည် ၎င်း၏အလွန်ကျယ်ပြန့်သောအင်္ဂါရပ်များဖြင့် မျှတနိုင်ပါသည်။

လွန်ခဲ့သော ဆယ်နှစ်က ရရှိခဲ့သော ယခင်ရလဒ်များနှင့် နှိုင်းယှဉ်ပါက ပရိုဂရမ်အားလုံးသည် မှတ်ဉာဏ်ပို၍ သိသိသာသာ စားသုံးလာသည်။ Xterm သည် 4 MB လိုအပ်သော်လည်း ယခု စတင်ချိန်တွင် 15 MB လိုအပ်ပါသည်။ rxvt အတွက် အလားတူ သုံးစွဲမှု တိုးလာကာ ယခု box မှ 16 MB လိုအပ်ပါသည်။ Xfce Terminal သည် ယခင်ကထက် သုံးဆပိုကြီးသော 34 MB ကိုယူသည်၊ သို့သော် GNOME Terminal သည် 20 MB သာလိုအပ်သည်။ ဟုတ်ပါတယ်၊ ယခင်စမ်းသပ်မှုအားလုံးကို 32-bit ဗိသုကာတွင်လုပ်ဆောင်ခဲ့သည်။ LCA 2012 တွင် Rusty Russell ပြောတယ်မှတ်ဉာဏ်သုံးစွဲမှု တိုးလာမှုကို ရှင်းပြနိုင်သည့် ပိုမိုသိမ်မွေ့သော အကြောင်းပြချက်များစွာ ရှိနေကြောင်း။ အဲဒါကိုပြောပြီးရင်၊ ကျွန်တော်တို့ဟာ မှတ်ဉာဏ် gigabytes ရှိတဲ့ ခေတ်ကြီးမှာ နေထိုင်နေတာမို့ တစ်နည်းနည်းနဲ့ စီမံခန့်ခွဲမယ်။

ဒါပေမယ့် terminal လို အခြေခံ software တွေအတွက် memory ပိုသုံးတာက resource တွေကို အလဟဿဖြစ်စေတယ်လို့ ကျွန်တော် မခံစားဘဲ မနေနိုင်ပါဘူး။ ဒီ program တွေဟာ အသေးဆုံးဖြစ်ပြီး "box" တွေမှာတောင်၊ shoebox မှာတောင် run နိုင်တဲ့ program တွေ ဖြစ်သင့်ပါတယ်။ Linux-systems (ပြီးတော့ အဲဒါဖြစ်လာမယ်ဆိုတာ မင်းသိတယ်မလား)။ ဒါပေမယ့် ဒီနံပါတ်တွေနဲ့ဆိုရင် terminal အများအပြား လည်ပတ်နေတဲ့ မည်သည့်ပတ်ဝန်းကျင်မှာမဆို မှတ်ဉာဏ်အသုံးပြုမှုဟာ ပြဿနာတစ်ခု ဖြစ်လာလိမ့်မယ်၊ အလွန်ပေါ့ပါးပြီး ကန့်သတ်ထားတဲ့ terminal အနည်းငယ်ကလွဲလို့ပေါ့။ ဒီအတွက် GNOME Terminal၊ Konsole၊ urxvt၊ Terminator နဲ့ Xfce Terminal အားလုံးမှာ Daemon mode ပါရှိပြီး terminal အများအပြားကို လုပ်ငန်းစဉ်တစ်ခုတည်းကနေတစ်ဆင့် စီမံခန့်ခွဲနိုင်စေပြီး ၎င်းတို့၏ မှတ်ဉာဏ်သုံးစွဲမှုကို ကန့်သတ်ပေးပါတယ်။

ကျွန်ုပ်၏စမ်းသပ်မှုများအတွင်း၊ ကျွန်ုပ်သည် disk read-write နှင့် ပတ်သက်သော နောက်ထပ်မမျှော်လင့်ထားသောရလဒ်ကို ရရှိခဲ့သည်- ဤနေရာတွင် လုံးဝမတွေ့ရတော့မည်ဟု မျှော်လင့်ထားသော်လည်း အချို့သော terminals များသည် အလွန်တောက်ပသော data များကို disk သို့ ရေးပေးနေသည်ကို တွေ့ရှိရပါသည်။ ထို့ကြောင့်၊ VTE စာကြည့်တိုက်သည် ဒစ်ခ်ပေါ်တွင် scroll buffer ကို အမှန်တကယ် သိမ်းဆည်းထားပါသည် (ဤလုပ်ဆောင်ချက် 2010 မှာ ပြန်သတိထားမိတယ်။၊ ဒါက ဖြစ်ပျက်နေဆဲပါ။) သို့သော် အဟောင်းအကောင်အထည်ဖော်မှုများနှင့်မတူဘဲ ယခု အနည်းဆုံး ဤဒေတာကို AES256 GCM ဖြင့် ကုဒ်ဝှက်ထားသည် (ဗားရှင်း 0.39.2 မှ) ဒါပေမယ့် ကျိုးကြောင်းဆီလျော်တဲ့ မေးခွန်းတစ်ခု ပေါ်လာပါတယ်- အကောင်အထည်ဖော်ဖို့ စံမဟုတ်တဲ့ ချဉ်းကပ်မှုတစ်ခု လိုအပ်တာကြောင့် VTE စာကြည့်တိုက်နဲ့ ပတ်သက်ပြီး ထူးခြားတာက ဘာလဲ...

ကောက်ချက်

ဒီဆောင်းပါးရဲ့ ပထမပိုင်းမှာ VTE-based terminal တွေက ကောင်းမွန်တဲ့ feature set တွေကို ပေးစွမ်းနိုင်တယ်ဆိုတာ ကျွန်တော်တို့ တွေ့ရှိခဲ့ပေမယ့် အခုတော့ ဒါက ကုန်ကျစရိတ်တစ်ခုနဲ့ လာတယ်ဆိုတာ ကျွန်တော်တို့ တွေ့ရှိခဲ့ပါတယ်။ VTE terminal အားလုံးကို မှတ်ဉာဏ်အသုံးပြုမှုကို ကန့်သတ်တဲ့ daemon process တစ်ခုကနေတစ်ဆင့် စီမံခန့်ခွဲနိုင်တာကြောင့် မှတ်ဉာဏ်က လက်ရှိမှာ ပြဿနာမဟုတ်ပါဘူး။ ဒါပေမယ့် RAM နဲ့ kernel buffer space မှာ ရုပ်ပိုင်းဆိုင်ရာ ကန့်သတ်ချက်တွေရှိတဲ့ စနစ်ဟောင်းတွေဟာ အရင်းအမြစ်တွေကို သိသိသာသာ နည်းပါးစွာ သုံးစွဲတဲ့အတွက် terminal ရဲ့ အစောပိုင်းဗားရှင်းတွေကနေ အကျိုးကျေးဇူးတွေ ရရှိနိုင်ပါတယ်။ VTE terminal တွေဟာ throughput စမ်းသပ်မှု (scrolling) မှာ ကောင်းမွန်စွာ လုပ်ဆောင်နိုင်ပေမယ့် သူတို့ရဲ့ display latency ဟာ GNOME user guide မှာ သတ်မှတ်ထားတဲ့ threshold ထက် မြင့်မားပါတယ်။ VTE developer တွေက ဒါကို ထည့်သွင်းစဉ်းစားသင့်ပါတယ်။ အသုံးပြုသူအသစ်များအတွက်ပင် ထည့်သွင်းစဉ်းစားလျှင် Linux terminal နဲ့ ကြုံတွေ့ရတာက မလွဲမသွေဖြစ်တဲ့အတွက် အသုံးပြုရတာ ပိုလွယ်ကူစေပါတယ်။ အတွေ့အကြုံရင့်ကျက်တဲ့ geek တွေအတွက် default terminal ကနေ ပြောင်းသုံးတာက မျက်လုံးညောင်းညာမှုကို လျော့ကျစေပြီး အလုပ်ချိန်ကြာရှည်ခြင်းကြောင့် ဖြစ်ပေါ်လာတဲ့ အနာဂတ် လုပ်ငန်းခွင်ဒဏ်ရာတွေနဲ့ ရောဂါတွေကို ရှောင်ရှားနိုင်ခြေကိုတောင် ဆိုလိုနိုင်ပါတယ်။ ကံမကောင်းစွာပဲ၊ အဟောင်း xterm နဲ့ mlterm တွေပဲ 10 milliseconds ဆိုတဲ့ magical ping threshold ကို ရရှိပြီး လူအများအတွက် လက်မခံနိုင်စရာပါပဲ။

ထိန်းချုပ်မှုတိုင်းတာမှုများကလည်း ဂရပ်ဖစ်ပတ်ဝန်းကျင်များ ဖွံ့ဖြိုးတိုးတက်မှုကြောင့် Linux ဆော့ဖ်ဝဲရေးသားသူများသည် ညှိနှိုင်းမှုများစွာ ပြုလုပ်ခဲ့ရသည်။ အသုံးပြုသူအချို့သည် ပုံမှန်ဝင်းဒိုးမန်နေဂျာများကို အသုံးပြုရန် စဉ်းစားလိုကြပေမည်၊ အဘယ်ကြောင့်ဆိုသော် ၎င်းတို့သည် နှောင့်နှေးမှုကို သိသိသာသာ လျှော့ချပေးသောကြောင့်ဖြစ်သည်။ ကံမကောင်းစွာပဲ၊ Wayland အတွက် နှောင့်နှေးမှုကို တိုင်းတာရန် မဖြစ်နိုင်ခဲ့ပါ- ကျွန်ုပ်အသုံးပြုခဲ့သော Typometer ပရိုဂရမ်သည် Wayland ကာကွယ်ရန် ဒီဇိုင်းထုတ်ထားသည့်အတိုင်း လုပ်ဆောင်ရန် ဒီဇိုင်းထုတ်ထားခြင်းဖြစ်သည်- အခြားဝင်းဒိုးများကို ထောက်လှမ်းခြင်းဖြစ်သည်။ Wayland ၏ compositing သည် X.org ထက် ပိုမိုကောင်းမွန်စွာ လုပ်ဆောင်နိုင်လိမ့်မည်ဟု မျှော်လင့်ပါသည်၊ ထို့အပြင် အနာဂတ်တွင် ဤပတ်ဝန်းကျင်တွင် နှောင့်နှေးမှုကို တိုင်းတာရန် နည်းလမ်းတစ်ခု ရှာတွေ့နိုင်လိမ့်မည်ဟုလည်း မျှော်လင့်ပါသည်။

source: www.habr.com