اسان جي ترجمي واري اداري مان ڪجھ لفظ: عام طور تي هرڪو ڪوشش ڪندو آهي ترجمي جي جديد مواد ۽ اشاعتن جو، ۽ اسان ڪو به استثنا نه آهيون. پر ٽرمينل ڪجهه نه آهن جيڪي هفتي ۾ هڪ ڀيرو اپڊيٽ ڪيا وڃن. تنهن ڪري، اسان توهان لاء هڪ مضمون ترجمو ڪيو آهي Antoine Beaupré جو، 2018 جي بهار ۾ شايع ٿيل: ان جي باوجود "عمر" جديد معيارن جي لحاظ کان، اسان جي راء ۾، مواد ان جي لاڳاپي کي وڃائي ڇڏيو آهي. ان کان علاوه، ھي اصل ۾ ٻن مضمونن جو ھڪڙو سلسلو ھو، پر اسان انھن کي ھڪڙي وڏي پوسٽ ۾ گڏ ڪرڻ جو فيصلو ڪيو.
ٽرمينلز کي ڪمپيوٽر جي تاريخ ۾ هڪ خاص مقام حاصل آهي، پر تازن ڏهاڪن ۾ انهن کي ڪمانڊ لائن سان گڏ زنده رهڻ تي مجبور ڪيو ويو آهي جيئن گرافيڪل انٽرفيس هر جڳهه بڻجي ويندا آهن. پنهنجو پاڻ کي تبديل ڪيو ، جنهن ۾، موڙ ۾، پنچڊ ڪارڊ ۽ ٽوگل سوئچز جي بنياد تي سسٽم جي تبديلي هئي. جديد تقسيم سڀني شڪلن ۽ رنگن جي مختلف ٽرمينل ايموليٽرن سان گڏ ايندا آهن. ۽ جڏهن ته ڪيترائي پنهنجي ڪم جي ماحول پاران مهيا ڪيل معياري ٽرمينل سان مواد آهن، ڪجهه فخر سان استعمال ڪن ٿا سڌي طرح ڌار ڌار سافٽ ويئر پنهنجي پسنديده شيل يا ٽيڪسٽ ايڊيٽر کي هلائڻ لاء. پر، جيئن اسان هن مضمون مان ڏسندا سين، نه سڀئي ٽرمينل ساڳي تصوير ۾ ٺاهيا ويا آهن: اهي ڪارڪردگي، سائيز ۽ ڪارڪردگي ۾ تمام گهڻو مختلف آهن.
ڪجھ ٽرمينلز ۾ بلڪل حيران ڪندڙ حفاظتي سوراخ آھن، ان سان گڏ گھڻن وٽ مڪمل طور تي مختلف سيٽ آھن، ھڪڙي ٽيب ٿيل انٽرفيس جي سپورٽ کان وٺي اسڪرپٽنگ تائين. جيتوڻيڪ اسان ، هي آرٽيڪل پوئين مواد جي هڪ تازه ڪاري آهي جيڪا پڙهندڙن کي اهو طئي ڪرڻ ۾ مدد ڪندي ته 2018 ۾ ڪهڙو ٽرمينل استعمال ڪيو وڃي. مضمون جو پهريون اڌ خاصيتن جو مقابلو ڪري ٿو، ۽ ٻيو اڌ ڪارڪردگي جو جائزو وٺندو آهي.
هتي اهي ٽرمينل آهن جن جو مون جائزو ورتو:
اهي شايد جديد نسخا نه هجن، ڇاڪاڻ ته مان لکڻ جي وقت تي مستحڪم تعميرات تائين محدود هو، جنهن کي آئون ڊيبين 9 يا فيڊورا 27 تي رول ڪرڻ جي قابل ٿي چڪو آهيان. صرف استثنا آهي Alacritty. اهو GPU-تيز رفتار ٽرمينل جو اولاد آهي ۽ هن ڪم لاء هڪ غير معمولي ۽ نئين ٻولي ۾ لکيو ويو آهي - Rust. مون پنهنجي جائزي مان ويب ٽرمينلز کي خارج ڪيو (بشمول انهن تي )، ڇاڪاڻ ته ابتدائي ٽيسٽ انهن جي انتهائي خراب ڪارڪردگي ڏيکاري ٿي.
يونيڪوڊ سپورٽ
مون يونيڪوڊ سپورٽ سان پنهنجا ٽيسٽ شروع ڪيا. ٽرمينلز جو پهريون امتحان يونيڪوڊ اسٽرنگ مان ڊسپلي ڪرڻ هو : "é، Δ، И، ק، م، ๗، あ، 叶، 葉 ۽ 말." هي سادو ٽيسٽ ڏيکاري ٿو ته ڇا ٽرمينل سڄي دنيا ۾ صحيح طريقي سان ڪم ڪري سگهي ٿو. xterm ٽرمينل عربي اکر ڏيکاري نه ٿو ڊفالٽ ترتيب ۾:
ڊفالٽ طور، xterm کلاسک "مقرر" فونٽ استعمال ڪري ٿو، جنهن جي مطابق ، 1997 کان وٺي "خاص يونيڪوڊ ڪوريج" آهي. هن فونٽ ۾ ڪا اهڙي شيءِ آهي جنهن جي ڪري ڪردار کي خالي فريم طور ظاهر ٿئي ٿو ۽ اهو صرف تڏهن آهي جڏهن ٽيڪسٽ فونٽ کي 20+ پوائنٽس تائين وڌايو وڃي ته اهو ڪردار آخرڪار صحيح نموني ظاهر ٿيڻ شروع ٿئي ٿو. بهرحال، هي "فيڪس" ٻين يونيڪوڊ اکرن جي ڊسپلي کي ٽوڙي ٿو:
اهي اسڪرين شاٽ Fedora 27 ۾ کنيا ويا هئا، ڇاڪاڻ ته اهو Debian 9 کان بهتر نتيجا ڏئي ٿو، جتي ٽرمينل جا ڪجهه پراڻا ورجن (خاص طور تي mlterm) فونٽ کي صحيح طرح سان سنڀالي نٿا سگهن. خوشقسمتيءَ سان هن کي بعد جي نسخن ۾ مقرر ڪيو ويو.
ھاڻي نوٽ ڪريو ته لائين ڪيئن ڏيکاريل آھي xterm ۾. اهو ظاهر ٿئي ٿو ته علامت ميم ۽ هيٺيون سامي RTL طرز اسڪرپٽ جو حوالو ڏيو ()، تنهنڪري ٽيڪنيڪل طور انهن کي ساڄي کان کاٻي طرف ڏيکاريو وڃي. ويب برائوزر جهڙوڪ فائر فاڪس 57 مٿي ڏنل لائن کي صحيح طور تي سنڀاليندا آهن. RTL متن جو هڪ آسان نسخو لفظ آهي "عبراني ۾ (). هيٺين چوي ٿو:
"ڪيترائي ڪمپيوٽر پروگرامن کي ٻه طرفي متن صحيح نموني ڏيکاري نه سگھندا آھن. مثال طور، عبراني نالو "Sarah" اکرن تي مشتمل آهي sin (ש) (جيڪو ساڄي پاسي ظاهر ٿئي ٿو)، پوءِ resh (ר) ۽ آخر ۾ he (ה) (جيڪو کاٻي پاسي ظاهر ٿئي ٿو)."
ڪيترائي ٽرمينلز ھن ٽيسٽ ۾ ناڪام ٿين ٿا: Alacritty، VTE-derived Gnome ۽ XFCE ٽرمينل، urxvt، st ۽ xterm "سارا" کي ريورس آرڊر ۾ ڏيکاري ٿو، ڄڻ ته اسان نالو لکيو ھو "اراس".
ٻه طرفي متنن سان هڪ ٻيو مسئلو اهو آهي ته انهن کي ڪنهن به طريقي سان ترتيب ڏيڻ جي ضرورت آهي، خاص طور تي جڏهن اهو اچي ٿو RTL ۽ LTR نصوص کي گڏ ڪرڻ. RTL اسڪرپٽ ٽرمينل ونڊو جي ساڄي پاسي کان ھلڻ گھرجي، پر انھن ٽرمينلز لاءِ ڇا ٿيڻ گھرجي جيڪي ڊفالٽ LTR انگريزي ۾ آھن؟ انھن مان گھڻن وٽ ڪو خاص ميکانيزم ناھي ۽ سڀني متن کي کاٻي طرف ترتيب ڏيو (بشمول ڪنسول ۾). استثنا آهن pterm ۽ mlterm، جيڪي معيار تي عمل ڪن ٿا ۽ اهڙيون لائينون ساڄي طرف ترتيب ڏين ٿا.
داخل ٿيڻ جي حفاظت
ايندڙ نازڪ خصوصيت جنهن جي مون سڃاڻپ ڪئي آهي اها آهي داخل ڪرڻ مخالف تحفظ. جيتوڻيڪ اهو مشهور آهي ته منتر جهڙوڪ:
$ curl http://example.com/ | shڪوڊ ايگزيڪيوشن پش ڪمانڊز آهن، ٿورا ماڻهو ڄاڻن ٿا ته لڪيل ڪمانڊز ڪنسول ۾ داخل ٿي سگهن ٿا جڏهن ويب برائوزر تان ڪاپي ۽ پيسٽ ڪري رهيا آهن، محتاط چڪاس کان پوءِ به. شاندار طور تي ڏيکاري ٿو ته ڪيئن معصوم ڏسڻ وارو حڪم آهي:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitاهڙي تڪليف ۾ بدلجي ٿو جڏهن هورن جي ويب سائيٽ تان ٽرمينل ۾ پيسٽ ڪيو وڃي:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust!
Here'"'"'s the first line of your /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitاهو ڪيئن ڪم ڪري ٿو؟ خراب ڪوڊ بلاڪ ۾ شامل آهي ، جيڪو CSS استعمال ڪندي صارف جي ڏيک کان ٻاهر منتقل ڪيو ويو آهي.
واضح طور تي اهڙن حملن کي غير جانبدار ڪرڻ لاء ٺهيل آهي. ھن موڊ ۾، ٽرمينل پيسٽ ٿيل متن کي ھڪڙي خاص فرار جي ترتيبن ۾ ڳنڍيندا آھن شيل کي متن جي اصليت بابت ٻڌائڻ لاءِ. هي شيل کي ٻڌائي ٿو ته اهو خاص ڪردارن کي نظرانداز ڪري سگهي ٿو جيڪي پيسٽ ٿيل متن تي مشتمل هجن. سڀ ٽرمينل واپس معزز xterm ڏانھن ھن خصوصيت جي حمايت ڪن ٿا، پر برڪيٽڊ موڊ ۾ پيسٽ ڪرڻ لاء ٽرمينل تي هلندڙ شيل يا ايپليڪيشن جي مدد جي ضرورت آھي. مثال طور، سافٽ ويئر استعمال ڪندي (ساڳي بش)، هڪ فائل جي ضرورت آهي ~/.inputrc:
set enable-bracketed-paste onبدقسمتي سان، هورن جي ٽيسٽ سائيٽ پڻ ڏيکاري ٿي ته ڪيئن هن تحفظ کي ٽيڪسٽ فارميٽنگ ذريعي پاڻ کي نظرانداز ڪيو وڃي ۽ وقت کان اڳ ختم ٿي وڃي ان تي بریکٹڊ موڊ لاڳو ڪرڻ. اهو ڪم ڪري ٿو ڇاڪاڻ ته ڪجهه ٽرمينلز پنهنجو پاڻ کي شامل ڪرڻ کان پهريان فرار جي ترتيبن کي صحيح طور تي فلٽر نٿا ڪن. مثال طور، مون ۾ مان ڪڏھن به ڪاميابيءَ سان مڪمل ڪرڻ جي قابل نه ٿي سگھيس ڪانسول ٽيسٽ جيتوڻيڪ صحيح ترتيب سان .inputrc فائل. ان جو مطلب اهو آهي ته توهان آساني سان حاصل ڪري سگهو ٿا توهان جي سسٽم جي ترتيب خراب ٿيڻ جي ڪري هڪ غير معاون ايپليڪيشن يا غلط ترتيب واري شيل جي ڪري. اهو خاص طور تي خطرناڪ آهي جڏهن ريموٽ سرورز ۾ لاگ ان ٿيو، جتي محتاط ترتيب ڏيڻ جو ڪم گهٽ عام آهي، خاص طور تي جيڪڏهن توهان وٽ ڪيتريون ئي اهڙيون ريموٽ مشينون آهن.
ھن مسئلي جو ھڪڙو سٺو حل آھي پيسٽ جي تصديق واري پلگ ان ٽرمينل لاءِ urxvt، جيڪو صرف ڪنهن به متن کي داخل ڪرڻ جي اجازت طلب ڪري ٿو جنهن ۾ نيون لائينون شامل آهن. مون کي هارن پاران بيان ڪيل ٽيڪسٽ حملي لاءِ وڌيڪ محفوظ اختيار نه مليو آهي.
ٽيب ۽ پروفائلز
هن وقت هڪ مشهور خصوصيت هڪ ٽيب ٿيل انٽرفيس لاءِ سپورٽ آهي، جنهن کي اسين هڪ ٽرمينل ونڊو طور بيان ڪنداسين جنهن ۾ ٻيا ڪيترائي ٽرمينل هوندا. هي فنڪشن مختلف ٽرمينلز لاءِ مختلف آهي، ۽ جيتوڻيڪ روايتي xterm ٽرمينل ٽيب کي سپورٽ نٿا ڪن، وڌيڪ جديد ٽرمينل اوتارن جهڙوڪ Xfce ٽرمينل، GNOME ٽرمينل ۽ ڪنسول ۾ هي فنڪشن آهي. Urxvt ٽيب کي پڻ سپورٽ ڪري ٿو، پر صرف ان صورت ۾ جيڪڏهن توهان پلگ ان استعمال ڪريو. پر ٽيب جي مدد جي لحاظ کان پاڻ، ٽرمينٽر هڪ اڻڄاتل اڳواڻ آهي: اهو نه رڳو ٽيب کي سپورٽ ڪري ٿو، پر ڪنهن به ترتيب ۾ ٽرمينل کي ترتيب ڏئي سگهي ٿو (هيٺ ڏنل تصوير ڏسو).
ٽرمينيٽر جي هڪ ٻي خصوصيت انهن ٽيب کي گڏ ڪرڻ جي صلاحيت آهي ۽ هڪ ئي وقت ڪيترن ئي ٽرمينلز ڏانهن هڪ ئي ڪي اسٽروڪ موڪلڻ جي صلاحيت آهي، ڪيترن ئي سرورن تي هڪ ئي وقت تي بلڪ آپريشن ڪرڻ لاءِ هڪ خام اوزار مهيا ڪري ٿي. ساڳي خصوصيت ڪنسول ۾ پڻ لاڳو ڪئي وئي آهي. ھن خصوصيت کي ٻين ٽرمينل ۾ استعمال ڪرڻ لاء، توھان کي استعمال ڪرڻ گھرجي ٽئين پارٽي سافٽ ويئر جهڙوڪ , يا .
ٽيب خاص طور تي سٺو ڪم ڪن ٿيون جڏهن پروفائلز سان جوڙيو وڃي: مثال طور، توهان وٽ هجي هڪ ٽيب اي ميل لاءِ، ٻيو چيٽ لاءِ، وغيره. هي ڪنسول ٽرمينل ۽ GNOME ٽرمينل جي چڱيءَ طرح سپورٽ آهي. ٻئي کي اجازت ڏين ٿا ته هر ٽيب کي خودڪار طور تي پنهنجي پروفائل کي لانچ ڪرڻ لاء. ٽرمينيٽر پڻ پروفائلز کي سپورٽ ڪري ٿو، پر مون کي ڪجھ پروگرامن کي خودڪار طور تي لانچ ڪرڻ جو ڪو طريقو نه ڳولي سگھي ٿو جڏھن توھان ھڪڙي مخصوص ٽيب کوليو. ٻين ٽرمينلز وٽ ”پروفائل“ جو تصور ئي ڪونهي.
رفلس
آخري شيء جيڪا آئون هن مضمون جي پهرين حصي ۾ ڍڪيندس، ٽرمينلز جي ظاهري آهي. مثال طور GNOME، Xfce ۽ urxvt شفافيت جي حمايت ڪن ٿا، پر تازو ئي پس منظر جي تصويرن لاءِ سپورٽ ختم ڪري ڇڏيا آهن، ڪجهه صارفين کي ٽرمينل تي سوئچ ڪرڻ تي مجبور ڪيو. . ذاتي طور تي، مان ان سان خوش آهيان ۽ اهو سادو آهي ايڪسرسورسز، جيڪو urxvt لاءِ پس منظر جي رنگن جو بنيادي سيٽ سيٽ ڪري ٿو. بهرحال، غير معياري رنگ موضوعات پڻ مسئلا پيدا ڪري سگھن ٿا. مثال طور، ايپليڪيشنن سان и ، ڇاڪاڻ ته اهي اڳ ۾ ئي پنهنجا رنگ استعمال ڪندا آهن.
رنگن کي سپورٽ نه ڪيو، ۽ نوان اڪثر ڪري 256-رنگ پيليٽ تائين محدود هئا. ترقي يافته استعمال ڪندڙن لاءِ جيڪي پنھنجي ٽرمينل کي اسٽائل ڪن ٿا، شيل پرامپٽس يا اسٽيٽس بار پيچيده طريقن سان ھڪ اذيت ڏيندڙ حد ٿي سگھي ٿو. ٽريڪ جيڪي ٽرمينل "سچو رنگ" جي حمايت ڪن ٿا. منهنجون ٽيسٽون تصديق ڪن ٿيون ته st, Alakritty ۽ VTE-based ٽرمينلز صحيح رنگ کي مڪمل طور تي سپورٽ ڪن ٿا. ٻيا ٽرمينل هن سلسلي ۾ تمام سٺو نه ٿا ڪن ۽ حقيقت ۾، 256 رنگ به نه ڏيکاريندا آهن. هيٺ توهان GNOME ٽرمينلز، st ۽ xterm ۾ True Color support جي وچ ۾ فرق ڏسي سگهو ٿا، جيڪي پنهنجي 256 رنگ پيليٽ، ۽ urxvt سان هن جو سٺو ڪم ڪن ٿا، جيڪو نه رڳو ٽيسٽ ۾ ناڪام ٿئي ٿو، پر انهن جي بدران ڪجهه چمڪندڙ ڪردارن کي پڻ ڏيکاري ٿو.
ڪجھ ٽرمينل لنڪس کي ڪلڪ ڪرڻ جي قابل بنائڻ لاءِ URL نمونن لاءِ متن جو تجزيو پڻ ڪن ٿا. اهو لاڳو ٿئي ٿو سڀني VTE مان نڪتل ٽرمينلز تي، جڏهن ته urxvt کي هڪ خاص پلگ ان جي ضرورت آهي جيڪا URLs کي هڪ ڪلڪ تي يا ڪي بورڊ شارٽ ڪٽ استعمال ڪندي تبديل ڪري. ٻيا ٽرمينل مون آزمايا آھن ڊسپلي URLs ٻين طريقن سان.
آخرڪار، ٽرمينلز ۾ هڪ نئون رجحان اسڪرول بفر جي اختياري آهي. مثال طور، st ۾ ڪو به اسڪرول بفر ناهي. اهو فرض ڪيو ويو آهي ته صارف هڪ ٽرمينل ملائيڪسر استعمال ڪندو جهڙوڪ tmux ۽ .
اليڪٽرٽي ۾ به پٺتي پيل بفرن جي کوٽ آهي، پر ان جي حمايت "وسيع موٽ" جي ڪري هن موضوع تي صارفين کان. ان کان علاوه، هر ٽرمينل مون آزمايو آهي ته مان ڳولي سگهان ٿو سپورٽ ريورس اسڪرولنگ.
ذيلي ٽوٽل
مواد جي ٻئي حصي ۾ (اصل ۾ اهي ٻه مختلف مضمون هئا - تقريبن. لين) اسان ڪارڪردگي، ياداشت جي استعمال ۽ ويڪرائي جو مقابلو ڪنداسين. پر اسان اڳ ۾ ئي ڏسي سگهون ٿا ته سوال ۾ ڪجهه ٽرمينل سنگين نقص آهن. مثال طور، صارف جيڪي باقاعده RTL اسڪرپٽ سان ڪم ڪن ٿا شايد mlterm ۽ pterm تي غور ڪرڻ چاهيندا، جيئن اهي ٻين جي ڀيٽ ۾ ساڳي ڪم کي سنڀالڻ ۾ بهتر آهن. ڪنسول پڻ سٺي ڪارڪردگي ڏيکاري. استعمال ڪندڙ جيڪي RTL اسڪرپٽ سان ڪم نٿا ڪن، شايد ٻيو ڪجهه چونڊيو.
بدسلوڪي ڪوڊ داخل ڪرڻ جي خلاف تحفظ جي لحاظ کان، urxvt ان قسم جي حملي جي خلاف تحفظ جي خاص عمل جي ڪري بيٺو آھي، جيڪو يقيني طور تي مون لاءِ آسان لڳي ٿو. انهن لاءِ جيڪي ڪجهه گھنٽيون ۽ سيٽيون ڳولي رهيا آهن، ڪنسول هڪ نظر جي لائق آهي. آخرڪار، اهو قابل ذڪر آهي ته VTE ٽرمينلز لاء هڪ بهترين بنياد آهي، جيڪو رنگ جي حمايت، URL جي سڃاڻپ، ۽ انهي جي ضمانت ڏئي ٿو. پهرين نظر ۾، ڊفالٽ ٽرمينل جيڪو توهان جي پسنديده ماحول سان اچي ٿو شايد سڀني گهرجن کي پورو ڪري، پر اچو ته هن سوال کي کليل ڇڏي ڏيو جيستائين اسان ڪارڪردگي کي سمجھندا آهيون.
اچو ته گفتگو جاري رکون
عام طور تي، ٽرمينلز جي ڪارڪردگي پاڻ ۾ هڪ تمام گهڻي تڪليف وانگر لڳي سگهي ٿي، پر جيئن اهو نڪتو، انهن مان ڪجهه اهڙي قسم جي بنيادي قسم جي سافٽ ويئر لاء حيرت انگيز طور تي اعلي ويڪرائي ڏيکاري ٿو. ان کان علاوه اڳتي اسان ڏسنداسين ته روايتي طور تي "رفتار" (حقيقت ۾، اهو اسڪرولنگ اسپيڊ آهي) ۽ ٽرمينل جي يادگيري جو استعمال (اها احتياط سان ته اهو اڄ به ايترو نازڪ ناهي جيترو ڏهاڪن اڳ هو).
دير
ٽرمينل ڪارڪردگيءَ جي مڪمل مطالعي کان پوءِ، مان ان نتيجي تي پهتو آهيان ته ان سلسلي ۾ سڀ کان اهم پيرا ميٽر ويڪرائي (پنگ) آهي. هن جي مضمون ۾ Pavel Fatin مختلف ٽيڪسٽ ايڊيٽرن جي ويڪرائي کي ڏٺو ۽ اشارو ڏنو ته ان سلسلي ۾ ٽرمينل تيز ترين ٽيڪسٽ ايڊيٽرن جي ڀيٽ ۾ سست هوندا. اهو اهو اشارو هو جنهن آخرڪار مون کي پنهنجي ٽيسٽ هلائڻ ۽ هي مضمون لکڻ جي هدايت ڪئي.
پر ويڪرائي ڇا آهي، ۽ اهو ڇو ضروري آهي؟ هن جي آرٽيڪل ۾، فاٽين ان جي وضاحت ڪئي ته "هڪ چاٻي کي دٻائڻ ۽ لاڳاپيل اسڪرين اپڊيٽ جي وچ ۾ دير" ۽ حوالو ڏنو ويو آهي. ، جيڪو چوي ٿو: "ڪمپيوٽر ڊسپلي تي بصري موٽ ۾ دير جو ٽائپسٽ جي رويي ۽ اطمينان تي هڪ اهم اثر آهي."
Fatin وضاحت ڪري ٿو ته هي پنگ صرف اطمينان کان وڌيڪ گہرا نتيجا آهن: "ٽائپنگ سست ٿي ويندي آهي، وڌيڪ غلطيون ٿينديون آهن، ۽ اکين ۽ عضلات جي تڪرار وڌندي آهي." ٻين لفظن ۾، هڪ وڏي دير ٽائيپ جي ڪري سگھي ٿي ۽ ڪوڊ جي معيار کي به گهٽائي سگھي ٿي، ڇاڪاڻ ته اهو دماغ تي اضافي سنجيدگي وارو لوڊ ڪري ٿو. پر ڇا وڌيڪ خراب آهي ته پنگ "اکين ۽ عضلات جي دٻاء کي وڌائي ٿو،" جنهن جو مطلب لڳي ٿو مستقبل ۾ (بظاهر، ليکڪ جو مطلب آهي اکين جي عضون، پوئتي، هٿن ۽، يقينا، خواب - تقريبن. لين) بار بار دٻاء جي ڪري.
انهن مان ڪجهه اثرات هڪ ڊگهي وقت تائين معلوم ٿي چڪا آهن، ۽ نتيجا ، جرنل Ergonomics ۾ 1976 ۾ واپس شايع ٿيو، چيو ته 100 ملي سيڪنڊن جي دير "خاص طور تي ٽائپنگ جي رفتار کي متاثر ڪري ٿو." وڌيڪ تازو، GNOME يوزر گائيڊ متعارف ڪرايو 10 ملي سيڪنڊن ۾، ۽ جيڪڏھن توھان اڳتي وڌو، پوء ڏيکاري ٿو ته 1 millisecond مثالي آهي.
فاٽين ٽيڪسٽ ايڊيٽرن تي پنهنجا تجربا ڪيا؛ هن هڪ پورٽبل اوزار ٺاهيو جنهن کي سڏيو ويندو آهي ، جنهن کي مان ٽرمينل ايموليٽرز ۾ پنگ کي آزمائيندو هو. ذهن ۾ رکو ته امتحان سميوليشن موڊ ۾ ڪيو ويو: حقيقت ۾، اسان کي ان پٽ (ڪي بورڊ، يو ايس بي ڪنٽرولر، وغيره) ۽ آئوٽ پُٽ (وڊيو ڪارڊ بفر، مانيٽر) جي دير جي حساب ۾ رکڻ جي ضرورت آهي. فتن جي مطابق، عام ترتيبن ۾ اهو اٽڪل 20 ايم ايس آهي. جيڪڏهن توهان وٽ گيمنگ جو سامان آهي، ته توهان هن انگ کي صرف 3 ملي سيڪنڊن ۾ حاصل ڪري سگهو ٿا. جيئن ته اسان وٽ اڳ ۾ ئي تيز هارڊويئر آهي، ايپليڪيشن کي پنهنجي دير سان شامل ڪرڻ جي ضرورت ناهي. فاٽين جو مقصد آهي ايپليڪيشن جي دير کي 1 ملي سيڪنڊ تائين آڻڻ، يا ان کان سواءِ ڊائلنگ حاصل ڪرڻ ، ڪيئن ۾ .
هتي منهنجي ماپ جا نتيجا آهن، انهي سان گڏ ڪجهه فاٽين جا نتيجا، اهو ڏيکارڻ لاءِ ته منهنجو تجربو هن جي تجربن سان متفق آهي:
پهرين شيء جيڪا مون کي متاثر ڪيو پراڻن پروگرامن جهڙوڪ xterm ۽ mlterm جو بهتر جواب وقت هو. بدترين رجسٽري دير سان (2,4 ms)، انهن تيز ترين جديد ٽرمينل کان بهتر ڪارڪردگي ڏيکاري (10,6 ms for st). ڪوبه جديد ٽرمينل 10 مليسيڪنڊ جي حد کان هيٺ نٿو اچي. خاص طور تي، Alacritty "تيز تيز ترين ٽرمينل ايموليٽر دستياب" دعوي کي پورو ڪرڻ ۾ ناڪام ٿيو، جيتوڻيڪ ان جي اسڪور 2017 ۾ ان جي پهرين جائزي کان بهتر ٿي چڪا آهن. درحقيقت، منصوبي جا ليکڪ ۽ ڊسپلي کي بهتر ڪرڻ لاء ڪم ڪري رهيا آهن. اهو پڻ ياد رکڻ گهرجي ته GTK3 استعمال ڪندي Vim ان جي GTK2 هم منصب کان سست رفتار جو حڪم آهي. ان مان اسان اهو نتيجو ڪري سگھون ٿا ته GTK3 اضافي ويڪرائي پيدا ڪري ٿو، ۽ اهو ٻين سڀني ٽرمينلز ۾ ظاهر ٿئي ٿو جيڪي ان کي استعمال ڪن ٿا (ٽرمنيٽر، Xfce4 ٽرمينل ۽ GNOME ٽرمينل).
تنهن هوندي به، اختلافن کي نظر ۾ نه ٿي سگھي. جيئن Fatin وضاحت ڪري ٿو، "توهان کي دير کان آگاهي ٿيڻ جي ضرورت ناهي ته اهو توهان تي اثر پوي." فتن پڻ معياري انحراف بابت خبردار ڪري ٿو: "تخريب (جٽر) ۾ ڪا به خرابي انهن جي غير متوقع هجڻ جي ڪري اضافي دٻاءُ پيدا ڪري ٿي."
مٿي ڏنل گراف خالص ديبين 9 تي ورتو ويو آهي (اسٽيچ) سان . هي ماحول ويڪرائي ٽيسٽ ۾ بهترين نتيجا پيدا ڪري ٿو. جيئن ته اهو نڪتو، GNOME سڀني ماپن لاء 20 ms جو اضافي پنگ ٺاهي ٿو. ان لاءِ هڪ ممڪن وضاحت آهي پروگرامن جي موجودگي ان پٽ واقعن جي هم وقت سازي سان. Fatin اهڙي صورت لاء هڪ مثال ڏئي ٿو ، جيڪو سڀني انپٽ واقعن کي هم وقت سازي سان پروسيس ڪندي دير شامل ڪري ٿو. ڊفالٽ طور، GNOME پڻ ونڊو مينيجر سان گڏ اچي ٿو ، جيڪو بفرنگ جو هڪ اضافي پرت ٺاهي ٿو، جيڪو پنگ کي متاثر ڪري ٿو ۽ گهٽ ۾ گهٽ 8 ملي سيڪنڊن جي دير سان شامل ڪري ٿو.
ڇڪڻ جي رفتار
ايندڙ ٽيسٽ هڪ روايتي "رفتار" يا "بينڊوڊٿ" ٽيسٽ آهي، جيڪو ماپ ڪري ٿو ته ٽرمينل ڪيتري جلدي هڪ صفحي کي اسڪرال ڪري سگهي ٿو جڏهن اسڪرين تي وڏي مقدار ۾ متن ڏيکاري ٿو. امتحان جا ميڪيڪل مختلف آهن؛ اصل ٽيسٽ صرف seq ڪمانڊ استعمال ڪندي ساڳي ٽيڪسٽ اسٽرنگ ٺاهڻ لاءِ هئي. ٻين ٽيسٽن ۾ ٿامس اي ڊڪيز (xterm maintener) ٽيسٽ، جيڪو بار بار ڪيو وڃي ٿو . ٽرمينل ڪارڪردگي جو هڪ ٻيو جائزو بي ترتيب بائيٽ جو بنيادي 32 انڪوڊ ٿيل اسٽرنگ استعمال ڪري ٿو، جيڪو ٻلي استعمال ڪندي ٽرمينل ڏانهن ٻاھر آھي. Luu اهڙي ٽيسٽ کي سمجهي ٿو "جيئن بيڪار هڪ معيار جيئن ڪو تصور ڪري سگهي ٿو" ۽ ان جي بدران ٽرمينل جواب کي بنيادي ميٽرڪ طور استعمال ڪرڻ جو مشورو ڏئي ٿو. ڊڪي پڻ پنهنجي ٽيسٽ کي گمراهه ڪندڙ سڏيندو آهي. بهرحال، ٻئي ليکڪ تسليم ڪن ٿا ته ٽرمينل ونڊو بينڊوڊٿ هڪ مسئلو ٿي سگهي ٿو. Luu دريافت ڪيو Emacs Eshell منجمد ٿي رهيو آهي جڏهن وڏيون فائلون ڏيکاري ٿي، ۽ ڊڪي ايڪسٽرم جي بصري سستي کان نجات حاصل ڪرڻ لاءِ ٽرمينل کي بهتر ڪيو. تنهن ڪري اڃا تائين هن ٽيسٽ ۾ ڪجهه قابليت آهي، پر جيئن ته رينجرنگ عمل ٽرمينل کان ٽرمينل کان بلڪل مختلف آهي، ان کي پڻ استعمال ڪري سگهجي ٿو ٽيسٽ جزو طور ٻين پيٽرولن کي جانچڻ لاء.
هتي اسان ڏسون ٿا rxvt ۽ st پل مقابلي کان اڳ، بعد ۾ تمام گهڻو نئون Alacritty، جيڪو ڪارڪردگي تي ڌيان ڏيڻ سان ٺهيل آهي. اڳيان آهن Xfce (VTE خاندان) ۽ ڪنسول، جيڪي لڳ ڀڳ ٻه ڀيرا تيز آهن. آخري آهي xterm، جيڪو rxvt کان پنج ڀيرا سست آهي. ٽيسٽ دوران، xterm پڻ تمام گهڻو ڦيرايو، متن کي پاس ڪرڻ ڏکيو ڏسڻ ۾ اچي ٿو جيتوڻيڪ اها ساڳي لائن هئي. ڪنسول تيز هو، پر اهو ڪڏهن ڪڏهن مشڪل هوندو هو: ڊسپلي وقت بوقت منجمد ٿي ويندي هئي، جزوي متن ڏيکاريندي هئي يا نه ڏيکاريندي هئي. ٻيا ٽرمينل واضح طور تي ڏيکاريل اسٽرنگ، جن ۾ st، Alacritty، ۽ rxvt.
ڊڪي وضاحت ڪري ٿو ته ڪارڪردگي فرق مختلف ٽرمينلز ۾ اسڪرول بفرن جي ڊيزائن جي ڪري آهي. خاص طور تي، هن rxvt ۽ ٻين ٽرمينلز تي "عام قاعدن تي عمل نه ڪرڻ" جو الزام لڳايو:
"xterm جي برعڪس، rxvt سڀني اپڊيٽ کي ڊسپلي ڪرڻ جي ڪوشش نه ڪئي. جيڪڏهن اهو پوئتي پوي ٿو، اهو پڪڙڻ لاء ڪجهه تازه ڪاريون رد ڪندو. اهو اندروني ياداشت جي تنظيم جي ڀيٽ ۾ ظاهري اسڪرولنگ جي رفتار تي وڏو اثر پيو. هڪ خرابي اها هئي ته ASCII انيميشن ڪجهه حد تائين غلط هئي.
هن سمجھي xterm سستگي کي درست ڪرڻ لاء، ڊڪي وسيلن کي استعمال ڪرڻ جو مشورو ڏئي ٿو , xterm کي اجازت ڏئي ٿو ته وهڪري سان گڏ رهڻ لاءِ ڪجهه اسڪرين اپڊيٽ کي رد ڪري. منهنجون ٽيسٽون تصديق ڪن ٿيون ته فاسٽ اسڪرول ڪارڪردگي بهتر ڪري ٿو ۽ xterm کي rxvt سان برابر ڪري ٿو. اهو، بهرحال، هڪ بلڪه خام ڪرچ آهي، جيئن ڊڪي پاڻ وضاحت ڪري ٿو: "ڪڏهن ڪڏهن xterm - جهڙوڪ ڪنسول - اسٽال ٿيڻ لڳي ٿو جيئن ڪجهه هٽائڻ کان پوء اسڪرين اپڊيٽ جي نئين سيٽ جو انتظار ڪري." هن رڳ ۾، اهو لڳي ٿو ته ٻين ٽرمينلز کي رفتار ۽ ڊسپلي جي سالميت جي وچ ۾ بهترين سمجھوتا مليو آهي.
وسيلن جي استعمال
قطع نظر ته ڇا اهو سمجهه ۾ اچي ٿو ته طومار ڪرڻ جي رفتار کي ڪارڪردگي ميٽرڪ جي طور تي غور ڪيو وڃي، هي امتحان اسان کي ٽرمينلز تي لوڊ ڪرڻ جي اجازت ڏئي ٿو، جنهن جي نتيجي ۾ اسان کي ٻين پيٽرولن کي ماپڻ جي اجازت ڏئي ٿي جهڙوڪ ميموري يا ڊسڪ استعمال. ميٽرڪ مخصوص ٽيسٽ هلائڻ سان حاصل ڪيا ويا ايس Python عمل جي نگراني جي تحت. هن ميٽر ڊيٽا گڏ ڪئي لاء ru_maxrss، رقم ru_oublock и ru_inblock ۽ هڪ سادي ٽائمر.
ھن ٽيسٽ ۾، ST 8 MB جي گھٽ ۾ گھٽ اوسط ميموري واپرائڻ سان پھرين جاءِ وٺي ٿي، جنھن ۾ حيرت جي ڳالھھ ناھي ته ڊزائن جو بنيادي خيال سادگي آھي. mlterm، xterm ۽ rxvt ٿورو وڌيڪ استعمال ڪن ٿا - اٽڪل 12 MB. ٻيو قابل ذڪر نتيجو آهي Alacritty، جنهن کي هلائڻ لاء 30 MB جي ضرورت آهي. ان کان پوء وي ٽي اي خاندان جا ٽرمينل 40 کان 60 ايم بي جي انگن اکرن سان گڏ آهن، جيڪو تمام گهڻو آهي. هي واپرائڻ حقيقت جي وضاحت ڪري سگهجي ٿو ته اهي ٽرمينل اعلي سطحي لائبريريون استعمال ڪندا آهن، مثال طور، GTK. Konsole آخر ۾ اچي ٿو 65MB ميموري جي استعمال سان ٽيسٽن دوران، جيتوڻيڪ ان کي جائز ثابت ڪري سگھجي ٿو ان جي تمام وسيع رينج جي خصوصيتن سان.
ڏهه سال اڳ حاصل ڪيل اڳوڻي نتيجن جي مقابلي ۾، سڀني پروگرامن کي خاص طور تي وڌيڪ يادگيري استعمال ڪرڻ شروع ڪيو. Xterm کي 4 MB جي ضرورت پوندي هئي، پر هاڻي ان کي صرف شروعاتي وقت ۾ 15 MB جي ضرورت آهي. rxvt لاءِ واپرائڻ ۾ ساڳيو اضافو آهي، جنهن لاءِ هاڻي 16 MB دٻي جي ضرورت آهي. Xfce ٽرمينل 34 MB وٺي ٿو، جيڪو اڳي کان ٽي ڀيرا وڏو آهي، پر GNOME ٽرمينل صرف 20 MB جي ضرورت آهي. يقينن، سڀ پوئين تجربا 32-bit فن تعمير تي ڪيا ويا. LCA 2012 ۾ Rusty Russell , ته اهڙا ڪيترائي ذهين سبب آهن جيڪي ميموري جي استعمال ۾ واڌ جي وضاحت ڪري سگھن ٿا. اهو چوڻ کان پوء، اسان هاڻي هڪ وقت ۾ رهندا آهيون جتي اسان وٽ گيگا بائيٽ ياداشت آهي، تنهنڪري اسان ڪنهن به طريقي سان منظم ڪنداسين.
بهرحال، مان مدد نه ٿو ڪري سگهان پر محسوس ڪري ٿو ته وڌيڪ ميموري مختص ڪرڻ بنيادي طور تي بنيادي طور تي ٽرمينل وسيلن جو ضايع آهي. انهن پروگرامن کي تمام ننڍڙو هجڻ گهرجي، ڪنهن به "باڪس" تي هلائڻ جي قابل هجڻ گهرجي، جيتوڻيڪ هڪ جوتا باڪس، جيڪڏهن اسان ڪڏهن ان نقطي تي پهچي سگهون ٿا جتي انهن کي لينڪس سسٽم سان ليس ٿيڻ جي ضرورت آهي (۽ توهان کي خبر آهي ته اهو ٿيندو. ) . پر انهن انگن سان، يادگيري جو استعمال مستقبل ۾ هڪ مسئلو بڻجي ويندو ڪنهن به ماحول ۾ هلندڙ ڪيترن ئي ٽرمينلز کان سواءِ ڪجھ ہلڪي ۽ تمام محدود صلاحيتون. ان لاءِ معاوضو ڏيڻ لاءِ، GNOME ٽرمينل، ڪنسول، urxvt، ٽرمينيٽر ۽ Xfce ٽرمينل وٽ هڪ ڊيمون موڊ آهي جيڪو توهان کي اجازت ڏئي ٿو ڪيترن ئي ٽرمينلز کي هڪ واحد عمل ذريعي ڪنٽرول ڪري، انهن جي ميموري جي استعمال کي محدود ڪري.
منهنجي تجربن دوران، مون کي ڊسڪ پڙهڻ جي حوالي سان هڪ ٻيو اڻڄاتل نتيجو آيو: مون کي هتي ڪجهه به ڏسڻ جي اميد نه هئي، پر اهو ظاهر ٿيو ته ڪجهه ٽرمينل ڊسڪ تي تمام گهڻي ڊيٽا لکندا آهن. تنهن ڪري، VTE لائبريري اصل ۾ ڊسڪ تي اسڪرول بفر رکي ٿي (هي خصوصيت ، ۽ اهو اڃا تائين ٿي رهيو آهي). پر پراڻن عملن جي برعڪس، ھاڻي گھٽ ۾ گھٽ ھي ڊيٽا انڪريپٽ ٿيل آھي AES256 GCM (). پر هڪ معقول سوال پيدا ٿئي ٿو: VTE لائبريري بابت ڇا خاص آهي ته ان کي لاڳو ڪرڻ لاءِ اهڙي غير معياري طريقي جي ضرورت آهي ...
ٿڪل
مضمون جي پهرين حصي ۾، اسان ڏٺو ته VTE-بنياد ٽرمينلز وٽ خاصيتون آهن، پر هاڻي اسان ڏسون ٿا ته اهو ڪجهه ڪارڪردگي جي قيمتن سان گڏ اچي ٿو. ھاڻي ميموري ڪو مسئلو نه آھي ڇو ته سڀ VTE ٽرمينل کي ڊيمن جي عمل ذريعي ڪنٽرول ڪري سگھجن ٿا، جيڪو انھن جي بھوت کي محدود ڪري ٿو. بهرحال، پراڻا سسٽم جيڪي جسماني حدون آهن رام جي مقدار تي ۽ ڪنيل بفر اڃا تائين ٽرمينلز جي اڳوڻي نسخن جي ضرورت هونديون آهن، ڇاڪاڻ ته اهي خاص طور تي گهٽ وسيلن کي استعمال ڪن ٿا. جيتوڻيڪ VTE ٽرمينلز ٿرو پُٽ (اسڪرولنگ) ٽيسٽن ۾ سٺي پرفارمنس ڏني، انهن جي ڊسپلي ليٽيسي GNOME يوزر گائيڊ ۾ مقرر حد کان مٿي آهي. VTE ڊولپرز کي شايد هن کي حساب ۾ رکڻ گهرجي. جيڪڏهن اسان اهو خيال رکون ٿا ته نوان لينڪس استعمال ڪندڙن لاءِ به ٽرمينل سان منهن ڏيڻ ناگزير آهي، اهي ان کي وڌيڪ صارف دوست بڻائي سگهن ٿا. تجربيڪار گيڪسن لاءِ، ڊفالٽ ٽرمينل مان مٽجڻ جو مطلب شايد اکين جي گھٽتائي ۽ مستقبل جي ڪم سان لاڳاپيل زخمن ۽ بيمارين کان بچڻ جي صلاحيت به ٿي سگھي ٿي. بدقسمتي سان، صرف پراڻي xterm ۽ mlterm اسان کي 10 مليسيڪنڊ جي جادو پنگ جي حد تائين آڻين ٿا، جيڪو ڪيترن ئي لاء ناقابل قبول آهي.
معيار جي ماپ پڻ ڏيکاري ٿي ته لينڪس گرافڪ ماحول جي ترقي جي ڪري، ڊولپرز کي ڪيترن ئي سمجھوتن کي ڪرڻو پيو. ڪجهه استعمال ڪندڙ شايد باقاعده ونڊو مينيجرز کي ڏسڻ چاهيندا آهن جيئن اهي اهم پنگ گهٽتائي فراهم ڪن ٿيون. بدقسمتي سان، اهو ممڪن نه هو Wayland لاءِ ويڪرائي ماپڻ: ٽائپوميٽر پروگرام جيڪو مون استعمال ڪيو اهو ان لاءِ ٺاهيو ويو هو ته Wayland کي روڪڻ لاءِ ٺاهيو ويو آهي: ٻين ونڊوز تي جاسوسي. مون کي اميد آهي ته Wayland compositing X.org کان بهتر ڪارڪردگي ڏيکاري ٿي، ۽ مان پڻ اميد ڪريان ٿو ته مستقبل ۾ ڪو ماڻهو هن ماحول ۾ ويڪرائي کي ماپڻ جو طريقو ڳولي سگهندو.
جو ذريعو: www.habr.com