टर्मिनल एमुलेटर का अवलोकन

हमारे अनुवाद ब्यूरो से कुछ शब्द: आमतौर पर हर कोई नवीनतम सामग्रियों और प्रकाशनों का अनुवाद करने का प्रयास करता है, और हम कोई अपवाद नहीं हैं। लेकिन टर्मिनल कोई ऐसी चीज़ नहीं है जिसे सप्ताह में एक बार अपडेट किया जाता है। इसलिए, हमने आपके लिए एंटोनी ब्यूप्रे के एक लेख का अनुवाद किया है, जो 2018 के वसंत में प्रकाशित हुआ था: आधुनिक मानकों द्वारा इसकी काफी "उम्र" के बावजूद, हमारी राय में, सामग्री ने अपनी प्रासंगिकता बिल्कुल नहीं खोई है। इसके अलावा, यह मूल रूप से दो लेखों की एक श्रृंखला थी, लेकिन हमने उन्हें एक बड़े पोस्ट में संयोजित करने का निर्णय लिया।

कंप्यूटर के इतिहास में टर्मिनलों का एक विशेष स्थान है, लेकिन हाल के दशकों में ग्राफिकल इंटरफेस सर्वव्यापी हो जाने के कारण उन्हें कमांड लाइन के साथ-साथ जीवित रहने के लिए मजबूर होना पड़ा है। टर्मिनल अनुकरणकर्ता अपना स्थान बदल लिया हार्डवेयर भाई, जो बदले में, छिद्रित कार्ड और टॉगल स्विच पर आधारित सिस्टम का एक संशोधन था। आधुनिक वितरण सभी आकार और रंगों के विभिन्न प्रकार के टर्मिनल एमुलेटर के साथ आते हैं। और जबकि कई लोग अपने कार्य वातावरण द्वारा प्रदान किए गए मानक टर्मिनल से संतुष्ट हैं, कुछ गर्व से अपने पसंदीदा शेल या टेक्स्ट एडिटर को चलाने के लिए बिल्कुल विदेशी सॉफ़्टवेयर का उपयोग करते हैं। लेकिन, जैसा कि हम इस लेख से देखेंगे, सभी टर्मिनल एक ही छवि में नहीं बनाए गए थे: वे कार्यक्षमता, आकार और प्रदर्शन में बहुत भिन्न हैं।

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

यहां वे टर्मिनल हैं जिनकी मैंने समीक्षा की:

ये नवीनतम संस्करण नहीं हो सकते हैं, क्योंकि लेखन के समय मैं स्थिर बिल्ड तक ही सीमित था, जिसे मैं डेबियन 9 या फेडोरा 27 पर रोल आउट करने में सक्षम था। एकमात्र अपवाद अलाक्रिटी है। यह GPU-त्वरित टर्मिनलों का वंशज है और इस कार्य के लिए एक असामान्य और नई भाषा में लिखा गया है - रस्ट। मैंने अपनी समीक्षा से वेब टर्मिनलों को बाहर कर दिया (इनमें वे भी शामिल हैं)। इलेक्ट्रान), क्योंकि प्रारंभिक परीक्षणों ने उनका बेहद खराब प्रदर्शन दिखाया।

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

मैंने अपने परीक्षण यूनिकोड समर्थन के साथ शुरू किये। टर्मिनलों का पहला परीक्षण यूनिकोड स्ट्रिंग को प्रदर्शित करना था विकिपीडिया लेख: "é, Δ, И, ק, م, ๗, あ, 叶, 葉 और 말।" यह सरल परीक्षण दिखाता है कि टर्मिनल दुनिया भर में सही ढंग से काम कर सकता है या नहीं। xterm टर्मिनल अरबी वर्ण प्रदर्शित नहीं करता है मेम डिफ़ॉल्ट कॉन्फ़िगरेशन में:

डिफ़ॉल्ट रूप से, xterm क्लासिक "निश्चित" फ़ॉन्ट का उपयोग करता है, जिसके अनुसार अब भी वही विकी, के पास "1997 से पर्याप्त यूनिकोड कवरेज" है। इस फ़ॉन्ट में कुछ ऐसा चल रहा है जिसके कारण वर्ण एक रिक्त फ़्रेम के रूप में दिखाई देने लगता है और यह केवल तभी होता है जब पाठ फ़ॉन्ट को 20+ अंक तक बढ़ाया जाता है कि वर्ण अंततः सही ढंग से प्रदर्शित होना शुरू हो जाता है। हालाँकि, यह "फिक्स" अन्य यूनिकोड वर्णों के प्रदर्शन को तोड़ देता है:

ये स्क्रीनशॉट फेडोरा 27 में लिए गए थे, क्योंकि इसने डेबियन 9 की तुलना में बेहतर परिणाम दिए थे, जहां टर्मिनलों के कुछ पुराने संस्करण (विशेष रूप से एमएलटर्म) फ़ॉन्ट को ठीक से संभाल नहीं सके थे। सौभाग्य से इसे बाद के संस्करणों में ठीक कर दिया गया।

अब ध्यान दें कि xterm में लाइन कैसे प्रदर्शित होती है। यह पता चला है कि प्रतीक मेम और निम्नलिखित सेमेटिक Qoph RTL शैली स्क्रिप्ट देखें (दाएं से बाएं), इसलिए तकनीकी रूप से उन्हें दाएं से बाएं प्रदर्शित किया जाना चाहिए। फ़ायरफ़ॉक्स 57 जैसे वेब ब्राउज़र उपरोक्त पंक्ति को सही ढंग से संभालते हैं। RTL टेक्स्ट का एक सरल संस्करण "शब्द हैसारा"हिब्रू में (सारा). द्विदिशात्मक पाठों पर विकी पृष्ठ निम्नलिखित कहता है:

“कई कंप्यूटर प्रोग्राम द्विदिशात्मक पाठ को सही ढंग से प्रदर्शित नहीं कर सकते हैं। उदाहरण के लिए, हिब्रू नाम "सारा" में अक्षर पाप (ש) (जो दाईं ओर दिखाई देता है), फिर रेश (ר) और अंत में वह (ה) (जो बाईं ओर दिखाई देना चाहिए) शामिल हैं।

कई टर्मिनल इस परीक्षण में विफल हो जाते हैं: अलाक्रिट्टी, वीटीई-व्युत्पन्न गनोम और एक्सएफसीई टर्मिनल, यूआरएक्सवीटी, सेंट और एक्सटर्म "सारा" को उल्टे क्रम में प्रदर्शित करते हैं, जैसे कि हमने नाम "अरास" लिखा हो।

द्विदिशात्मक पाठों के साथ एक और समस्या यह है कि उन्हें किसी तरह संरेखित करने की आवश्यकता होती है, खासकर जब आरटीएल और एलटीआर पाठों को मिलाने की बात आती है। आरटीएल स्क्रिप्ट टर्मिनल विंडो के दाईं ओर से चलनी चाहिए, लेकिन उन टर्मिनलों के लिए क्या होना चाहिए जो एलटीआर अंग्रेजी में डिफ़ॉल्ट हैं? उनमें से अधिकांश के पास कोई विशेष तंत्र नहीं है और सभी पाठ को बाईं ओर संरेखित करते हैं (कॉनसोल सहित)। अपवाद 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

यह काम किस प्रकार करता है? ब्लॉक में दुर्भावनापूर्ण कोड शामिल है , जिसे सीएसएस का उपयोग करके उपयोगकर्ता के दृश्य से बाहर ले जाया जाता है।

ब्रैकेटेड पेस्ट मोड स्पष्ट रूप से ऐसे हमलों को बेअसर करने के लिए डिज़ाइन किया गया है। इस मोड में, टर्मिनल पाठ की उत्पत्ति के बारे में शेल को बताने के लिए चिपकाए गए पाठ को विशेष एस्केप अनुक्रमों की एक जोड़ी में संलग्न करते हैं। यह शेल को बताता है कि वह चिपकाए गए पाठ में शामिल विशेष वर्णों को अनदेखा कर सकता है। आदरणीय xterm के सभी टर्मिनल इस सुविधा का समर्थन करते हैं, लेकिन ब्रैकेटेड मोड में चिपकाने के लिए टर्मिनल पर चल रहे शेल या एप्लिकेशन से समर्थन की आवश्यकता होती है। उदाहरण के लिए, सॉफ़्टवेयर का उपयोग करना जीएनयू रीडलाइन (वही बैश), एक फ़ाइल की आवश्यकता है ~/.inputrc:

set enable-bracketed-paste on

दुर्भाग्य से, हॉर्न की परीक्षण साइट यह भी दिखाती है कि टेक्स्ट फ़ॉर्मेटिंग के माध्यम से इस सुरक्षा को कैसे बायपास किया जाए और समय से पहले ब्रैकेटेड मोड को लागू किया जाए। यह काम करता है क्योंकि कुछ टर्मिनल अपना स्वयं का जोड़ने से पहले एस्केप अनुक्रमों को सही ढंग से फ़िल्टर नहीं करते हैं। उदाहरण के लिए, मेरे यहां मैं कभी भी सही कॉन्फ़िगरेशन के साथ भी कंसोल परीक्षणों को सफलतापूर्वक पूरा नहीं कर पाया .inputrc फ़ाइल। इसका मतलब यह है कि आप किसी असमर्थित एप्लिकेशन या गलत तरीके से कॉन्फ़िगर किए गए शेल के कारण आसानी से अपना सिस्टम कॉन्फ़िगरेशन दूषित कर सकते हैं। दूरस्थ सर्वर में लॉग इन करते समय यह विशेष रूप से खतरनाक होता है, जहां सावधानीपूर्वक कॉन्फ़िगरेशन कार्य कम आम है, खासकर यदि आपके पास ऐसी कई दूरस्थ मशीनें हैं।

इस समस्या का एक अच्छा समाधान टर्मिनल के लिए पेस्ट पुष्टिकरण प्लगइन है urxvt, जो बस किसी भी पाठ को सम्मिलित करने की अनुमति मांगता है जिसमें नई पंक्तियाँ हों। मुझे हॉर्न द्वारा वर्णित टेक्स्ट हमले के लिए अधिक सुरक्षित विकल्प नहीं मिला है।

टैब और प्रोफ़ाइल

अभी एक लोकप्रिय सुविधा टैब्ड इंटरफ़ेस के लिए समर्थन है, जिसे हम कई अन्य टर्मिनलों वाली एक टर्मिनल विंडो के रूप में परिभाषित करेंगे। यह फ़ंक्शन अलग-अलग टर्मिनलों के लिए अलग-अलग होता है, और हालांकि पारंपरिक xterm टर्मिनल बिल्कुल भी टैब का समर्थन नहीं करते हैं, अधिक आधुनिक टर्मिनल अवतार जैसे Xfce टर्मिनल, GNOME टर्मिनल और Konsole में यह फ़ंक्शन होता है। Urxvt टैब का भी समर्थन करता है, लेकिन केवल तभी जब आप प्लगइन का उपयोग करते हैं। लेकिन टैब समर्थन के मामले में, टर्मिनेटर निर्विवाद नेता है: यह न केवल टैब का समर्थन करता है, बल्कि किसी भी क्रम में टर्मिनलों को व्यवस्थित भी कर सकता है (नीचे छवि देखें)।

टर्मिनेटर की एक अन्य विशेषता इन टैब को एक साथ "समूहित" करने और एक ही समय में कई टर्मिनलों पर एक ही कीस्ट्रोक्स भेजने की क्षमता है, जो एक साथ कई सर्वरों पर बड़े पैमाने पर संचालन करने के लिए एक कच्चा उपकरण प्रदान करता है। इसी तरह की सुविधा कोनसोल में भी लागू की गई है। अन्य टर्मिनलों में इस सुविधा का उपयोग करने के लिए, आपको तृतीय-पक्ष सॉफ़्टवेयर का उपयोग करना होगा जैसे क्लस्टर एसएसएच, xlax या tmux.

प्रोफाइल के साथ जोड़े जाने पर टैब विशेष रूप से अच्छी तरह से काम करते हैं: उदाहरण के लिए, आपके पास एक टैब ईमेल के लिए, दूसरा चैट के लिए, इत्यादि हो सकता है। यह कोनसोल टर्मिनल और गनोम टर्मिनल द्वारा अच्छी तरह से समर्थित है। दोनों प्रत्येक टैब को स्वचालित रूप से अपनी प्रोफ़ाइल लॉन्च करने की अनुमति देते हैं। टर्मिनेटर प्रोफाइल का भी समर्थन करता है, लेकिन जब आप एक विशिष्ट टैब खोलते हैं तो मुझे कुछ प्रोग्रामों को स्वचालित रूप से लॉन्च करने का कोई तरीका नहीं मिल सका। अन्य टर्मिनलों में "प्रोफ़ाइल" की अवधारणा बिल्कुल नहीं है।

झमेलें

इस लेख के पहले भाग में मैं जिस आखिरी चीज़ पर चर्चा करूँगा वह है टर्मिनलों का स्वरूप। उदाहरण के लिए GNOME, Xfce और urxvt पारदर्शिता का समर्थन करते हैं, लेकिन हाल ही में पृष्ठभूमि छवियों के लिए समर्थन बंद कर दिया है, जिससे कुछ उपयोगकर्ताओं को टर्मिनल पर स्विच करने के लिए मजबूर होना पड़ा है Tilix. निजी तौर पर, मैं इससे खुश हूं और यह सरल है xसंसाधन, जो urxvt के लिए पृष्ठभूमि रंगों का आधार सेट सेट करता है। हालाँकि, गैर-मानक रंग थीम भी समस्याएँ पैदा कर सकती हैं। उदाहरण के लिए, सोलराइज़्ड काम नहीं कर रहा है अनुप्रयोगों के साथ htop и आईपीट्राफ, क्योंकि वे पहले से ही अपने स्वयं के रंगों का उपयोग करते हैं।

मूल VT100 टर्मिनल रंगों का समर्थन नहीं करता था, और नए रंग अक्सर 256-रंग पैलेट तक सीमित थे। उन्नत उपयोगकर्ताओं के लिए जो अपने टर्मिनलों को स्टाइल करते हैं, शेल प्रॉम्प्ट या स्टेटस बार जटिल तरीकों से एक कष्टप्रद सीमा हो सकते हैं। सार ट्रैक करता है कि किन टर्मिनलों में "ट्रू कलर" समर्थन है। मेरे परीक्षण इस बात की पुष्टि करते हैं कि st, Alacritty और VTE-आधारित टर्मिनल ट्रू कलर का पूरी तरह से समर्थन करते हैं। अन्य टर्मिनल इस संबंध में बहुत अच्छा प्रदर्शन नहीं करते हैं और वास्तव में, 256 रंग भी प्रदर्शित नहीं करते हैं। नीचे आप GNOME टर्मिनलों, st और xterm में ट्रू कलर सपोर्ट के बीच अंतर देख सकते हैं, जो अपने 256 कलर पैलेट और urxvt के साथ अच्छा काम करते हैं, जो न केवल परीक्षण में विफल रहता है, बल्कि उनके बजाय कुछ ब्लिंकिंग कैरेक्टर भी दिखाता है।

कुछ टर्मिनल लिंक को क्लिक करने योग्य बनाने के लिए यूआरएल पैटर्न के लिए टेक्स्ट का विश्लेषण भी करते हैं। यह सभी वीटीई-व्युत्पन्न टर्मिनलों पर लागू होता है, जबकि यूआरएक्सवीटी को एक विशेष प्लगइन की आवश्यकता होती है जो एक क्लिक पर या कीबोर्ड शॉर्टकट का उपयोग करके यूआरएल को बदल देगा। अन्य टर्मिनलों पर मैंने अन्य तरीकों से प्रदर्शन यूआरएल का परीक्षण किया है।

अंत में, टर्मिनलों में एक नया चलन स्क्रॉल बफ़र की वैकल्पिकता है। उदाहरण के लिए, st में कोई स्क्रॉल बफ़र नहीं है; यह माना जाता है कि उपयोगकर्ता tmux और जैसे टर्मिनल मल्टीप्लेक्सर का उपयोग करेगा जीएनयू स्क्रीन.

अलाक्रिट्टी में बैकस्क्रॉल बफ़र्स का भी अभाव है, लेकिन जल्द ही जोड़ा जाएगा इसका समर्थन उपयोगकर्ताओं से इस विषय पर "व्यापक प्रतिक्रिया" के कारण है। इन अपस्टार्ट के अलावा, प्रत्येक टर्मिनल जिसका मैंने परीक्षण किया है, मुझे रिवर्स स्क्रॉलिंग का समर्थन मिल सकता है।

उप-योगों

सामग्री के दूसरे भाग में (मूल में ये दो अलग-अलग लेख थे - लगभग। गली) हम प्रदर्शन, मेमोरी उपयोग और विलंबता की तुलना करेंगे। लेकिन हम पहले ही देख सकते हैं कि विचाराधीन कुछ टर्मिनलों में गंभीर कमियाँ हैं। उदाहरण के लिए, जो उपयोगकर्ता नियमित रूप से आरटीएल स्क्रिप्ट के साथ काम करते हैं, वे mlterm और pterm पर विचार करना चाह सकते हैं, क्योंकि वे दूसरों की तुलना में समान कार्यों को संभालने में बेहतर हैं। कंसोल ने भी अच्छा प्रदर्शन किया. जो उपयोगकर्ता आरटीएल स्क्रिप्ट के साथ काम नहीं करते वे कुछ और चुन सकते हैं।

दुर्भावनापूर्ण कोड प्रविष्टि के खिलाफ सुरक्षा के मामले में, urxvt इस प्रकार के हमले के खिलाफ सुरक्षा के अपने विशेष कार्यान्वयन के कारण खड़ा है, जो मुझे निश्चित रूप से सुविधाजनक लगता है। जो लोग कुछ घंटियों और सीटियों की तलाश में हैं, उनके लिए कंसोल देखने लायक है। अंत में, यह ध्यान देने योग्य है कि वीटीई टर्मिनलों के लिए एक उत्कृष्ट आधार है, जो रंग समर्थन, यूआरएल पहचान आदि की गारंटी देता है। पहली नज़र में, आपके पसंदीदा वातावरण के साथ आने वाला डिफ़ॉल्ट टर्मिनल सभी आवश्यकताओं को पूरा कर सकता है, लेकिन जब तक हम प्रदर्शन को समझ नहीं लेते तब तक इस प्रश्न को खुला छोड़ दें।

आइये बातचीत जारी रखें

सामान्य तौर पर, टर्मिनलों का प्रदर्शन अपने आप में एक दूर की समस्या जैसा लग सकता है, लेकिन जैसा कि यह पता चला है, उनमें से कुछ ऐसे मौलिक प्रकार के सॉफ़्टवेयर के लिए आश्चर्यजनक रूप से उच्च विलंबता प्रदर्शित करते हैं। इसके अलावा आगे हम पारंपरिक रूप से "गति" कहलाने वाली चीज़ (वास्तव में, यह स्क्रॉलिंग गति है) और टर्मिनल की मेमोरी खपत (इस चेतावनी के साथ कि यह आज उतनी महत्वपूर्ण नहीं है जितनी दशकों पहले थी) पर गौर करेंगे।

देरी

टर्मिनल प्रदर्शन के गहन अध्ययन के बाद, मैं इस निष्कर्ष पर पहुंचा कि इस संबंध में सबसे महत्वपूर्ण पैरामीटर विलंबता (पिंग) है। उनके लेख में "हम ख़ुशी से छापते हैं" पावेल फ़ैटिन ने विभिन्न पाठ संपादकों की विलंबता को देखा और संकेत दिया कि इस संबंध में टर्मिनल सबसे तेज़ पाठ संपादकों की तुलना में धीमे हो सकते हैं। यह वह संकेत था जिसने अंततः मुझे अपना परीक्षण चलाने और यह लेख लिखने के लिए प्रेरित किया।

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

फ़ैटिन बताते हैं कि इस पिंग के केवल संतुष्टि से अधिक गहरे परिणाम होते हैं: "टाइपिंग धीमी हो जाती है, अधिक त्रुटियां होती हैं, और आंख और मांसपेशियों में तनाव बढ़ जाता है।" दूसरे शब्दों में, बड़ी देरी से टाइप संबंधी त्रुटियां हो सकती हैं और कोड की गुणवत्ता भी कम हो सकती है, क्योंकि इससे मस्तिष्क पर अतिरिक्त संज्ञानात्मक भार पड़ता है। लेकिन इससे भी बुरी बात यह है कि पिंग "आंख और मांसपेशियों में तनाव बढ़ाता है", जिसका अर्थ यह प्रतीत होता है व्यावसायिक चोटों का विकास भविष्य में (जाहिरा तौर पर, लेखक का मतलब आंखों, पीठ, बाहों और निश्चित रूप से, दृष्टि की मांसपेशियों की समस्याओं से है - लगभग। गली) बार-बार तनाव के कारण।

इनमें से कुछ प्रभाव और परिणाम लंबे समय से ज्ञात हैं अनुसंधान1976 में एर्गोनॉमिक्स जर्नल में प्रकाशित, में कहा गया था कि 100 मिलीसेकंड की देरी से "टाइपिंग गति में काफी कमी आती है।" अभी हाल ही में, GNOME उपयोगकर्ता गाइड पेश किया गया स्वीकार्य प्रतिक्रिया समय 10 मिलीसेकंड में, और यदि आप आगे बढ़ते हैं, तो माइक्रोसॉफ्ट रिसर्च दर्शाता है कि 1 मिलीसेकंड आदर्श है।

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

यह दिखाने के लिए कि मेरा प्रयोग उसके परीक्षणों से सहमत है, यहां मेरे माप के परिणाम, साथ ही फातिन के कुछ परिणाम हैं:

पहली चीज़ जिसने मुझे प्रभावित किया वह पुराने कार्यक्रमों जैसे कि xterm और mlterm का बेहतर प्रतिक्रिया समय था। सबसे खराब रजिस्टर विलंबता (2,4 एमएस) के साथ, उन्होंने सबसे तेज़ आधुनिक टर्मिनल (एसटी के लिए 10,6 एमएस) से बेहतर प्रदर्शन किया। कोई भी आधुनिक टर्मिनल 10 मिलीसेकंड सीमा से नीचे नहीं आता है। विशेष रूप से, अलाक्रिट्टी "सबसे तेज़ टर्मिनल एमुलेटर उपलब्ध" दावे को पूरा करने में विफल रहता है, हालांकि 2017 में इसकी पहली समीक्षा के बाद से इसके स्कोर में सुधार हुआ है। दरअसल, परियोजना के लेखक स्थिति से अवगत और डिस्प्ले को बेहतर बनाने के लिए काम कर रहे हैं। यह भी ध्यान दिया जाना चाहिए कि जीटीके 3 का उपयोग करने वाला विम अपने जीटीके 2 समकक्ष की तुलना में धीमी गति का क्रम है। इससे हम यह निष्कर्ष निकाल सकते हैं कि GTK3 अतिरिक्त विलंबता बनाता है, और यह इसका उपयोग करने वाले अन्य सभी टर्मिनलों (टर्मिनेटर, Xfce4 टर्मिनल और GNOME टर्मिनल) में परिलक्षित होता है।

हालाँकि, अंतर आँखों पर ध्यान देने योग्य नहीं हो सकता है। जैसा कि फातिन बताते हैं, "आप पर इसका प्रभाव पड़ने के लिए आपको देरी के बारे में जागरूक होने की आवश्यकता नहीं है।" फ़ैटिन मानक विचलन के बारे में भी चेतावनी देते हैं: "विलंबता (घबराहट) में कोई भी गड़बड़ी उनकी अप्रत्याशितता के कारण अतिरिक्त तनाव पैदा करती है।"

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

स्क्रोल गति

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

यहां हम आरएक्सवीटी और एसटी को प्रतिस्पर्धा में आगे बढ़ते हुए देखते हैं, इसके बाद बहुत नया अलाक्रिटी है, जिसे प्रदर्शन पर ध्यान केंद्रित करने के साथ डिजाइन किया गया है। इसके बाद Xfce (VTE परिवार) और Konsole हैं, जो लगभग दोगुने तेज़ हैं। अंतिम है xterm, जो rxvt से पांच गुना धीमा है। परीक्षण के दौरान, xterm भी बहुत तरंगित हो गया, जिससे पासिंग टेक्स्ट को देखना मुश्किल हो गया, भले ही वह एक ही पंक्ति हो। कंसोल तेज़ था, लेकिन कभी-कभी मुश्किल था: डिस्प्ले समय-समय पर रुक जाता था, आंशिक पाठ दिखाता था या बिल्कुल नहीं दिखाता था। अन्य टर्मिनलों ने स्ट्रिंग्स को स्पष्ट रूप से प्रदर्शित किया, जिनमें st, Alacritty, और rxvt शामिल हैं।

डिकी बताते हैं कि प्रदर्शन में अंतर विभिन्न टर्मिनलों में स्क्रॉल बफ़र्स के डिज़ाइन के कारण होता है। विशेष रूप से, उन्होंने आरएक्सवीटी और अन्य टर्मिनलों पर "सामान्य नियमों का पालन नहीं करने" का आरोप लगाया:

“Xterm के विपरीत, rxvt ने सभी अपडेट प्रदर्शित करने का प्रयास नहीं किया। यदि यह पीछे रह जाता है, तो यह कुछ अद्यतनों को पकड़ने से इंकार कर देगा। इसका आंतरिक मेमोरी संगठन की तुलना में स्पष्ट स्क्रॉलिंग गति पर अधिक प्रभाव पड़ा। एक कमी यह थी कि ASCII एनीमेशन कुछ हद तक सटीक नहीं था।"

इस कथित एक्सटर्म सुस्ती को ठीक करने के लिए, डिकी संसाधन का उपयोग करने का सुझाव देता है फास्टस्क्रॉल, प्रवाह को बनाए रखने के लिए xterm को कुछ स्क्रीन अपडेट को त्यागने की अनुमति देता है। मेरे परीक्षण पुष्टि करते हैं कि fastScroll प्रदर्शन में सुधार करता है और xterm को rxvt के बराबर लाता है। हालाँकि, यह एक कठिन बैसाखी है, जैसा कि डिकी स्वयं बताते हैं: "कभी-कभी xterm - कंसोल की तरह - रुक जाता है क्योंकि यह कुछ हटाए जाने के बाद स्क्रीन अपडेट के नए सेट की प्रतीक्षा करता है।" इस प्रकार, ऐसा लगता है कि अन्य टर्मिनलों ने गति और प्रदर्शन अखंडता के बीच सबसे अच्छा समझौता पाया है।

संसाधन उपभोग

भले ही स्क्रॉलिंग गति को प्रदर्शन मीट्रिक के रूप में मानने का कोई मतलब हो, यह परीक्षण हमें टर्मिनलों पर लोड का अनुकरण करने की अनुमति देता है, जो बदले में हमें मेमोरी या डिस्क उपयोग जैसे अन्य मापदंडों को मापने की अनुमति देता है। निर्दिष्ट परीक्षण चलाकर मेट्रिक्स प्राप्त किए गए थे seq पायथन प्रक्रिया निगरानी के तहत। उन्होंने मीटर डेटा एकत्र किया getrusage() के लिए ru_maxrss, मात्रा ru_oublock и ru_inblock और एक साधारण टाइमर.

इस परीक्षण में, एसटी 8 एमबी की सबसे कम औसत मेमोरी खपत के साथ पहले स्थान पर है, जो यह देखते हुए आश्चर्य की बात नहीं है कि डिजाइन का मुख्य विचार सादगी है। mlterm, xterm और rxvt थोड़ी अधिक खपत करते हैं - लगभग 12 एमबी। एक और उल्लेखनीय परिणाम अलाक्रिट्टी है, जिसे चलाने के लिए 30 एमबी की आवश्यकता होती है। फिर 40 से 60 एमबी के आंकड़े वाले वीटीई परिवार के टर्मिनल हैं, जो काफी है। इस खपत को इस तथ्य से समझाया जा सकता है कि ये टर्मिनल उच्च-स्तरीय पुस्तकालयों का उपयोग करते हैं, उदाहरण के लिए, जीटीके। परीक्षणों के दौरान कॉनसोल 65 एमबी की भारी मेमोरी खपत के साथ अंतिम स्थान पर आता है, हालांकि इसे इसकी सुविधाओं की विस्तृत श्रृंखला द्वारा उचित ठहराया जा सकता है।

दस साल पहले प्राप्त पिछले परिणामों की तुलना में, सभी प्रोग्राम काफ़ी अधिक मेमोरी का उपभोग करने लगे। Xterm के लिए पहले 4 एमबी की आवश्यकता होती थी, लेकिन अब इसे स्टार्टअप पर 15 एमबी की आवश्यकता होती है। आरएक्सवीटी की खपत में समान वृद्धि हुई है, जिसके लिए अब बॉक्स से 16 एमबी की आवश्यकता होती है। Xfce टर्मिनल 34 एमबी लेता है, जो पहले से तीन गुना बड़ा है, लेकिन गनोम टर्मिनल को केवल 20 एमबी की आवश्यकता होती है। बेशक, पिछले सभी परीक्षण 32-बिट आर्किटेक्चर पर किए गए थे। एलसीए 2012 में रस्टी रसेल बताया, कि कई और सूक्ष्म कारण हैं जो मेमोरी खपत में वृद्धि की व्याख्या कर सकते हैं। ऐसा कहने के बाद, अब हम ऐसे समय में रहते हैं जहां हमारे पास गीगाबाइट मेमोरी है, इसलिए हम किसी तरह प्रबंधन कर लेंगे।

हालाँकि, मैं मदद नहीं कर सकता लेकिन महसूस करता हूँ कि टर्मिनल जैसी मौलिक चीज़ के लिए अधिक मेमोरी आवंटित करना संसाधनों की बर्बादी है। ये प्रोग्राम सबसे छोटे से छोटे होने चाहिए, किसी भी "बॉक्स" पर चलने में सक्षम होने चाहिए, यहां तक ​​कि एक शूबॉक्स पर भी, अगर हम कभी उस बिंदु पर आते हैं जहां उन्हें लिनक्स सिस्टम से लैस करने की आवश्यकता होती है (और आप जानते हैं कि यह ऐसा होगा) ) . लेकिन इन नंबरों के साथ, भविष्य में कुछ सबसे हल्के और सबसे सीमित क्षमताओं के अलावा कई टर्मिनलों को चलाने वाले किसी भी वातावरण में मेमोरी का उपयोग एक मुद्दा बन जाएगा। इसकी भरपाई के लिए, GNOME टर्मिनल, कंसोल, urxvt, टर्मिनेटर और Xfce टर्मिनल में एक डेमॉन मोड है जो आपको एक ही प्रक्रिया के माध्यम से कई टर्मिनलों को नियंत्रित करने की अनुमति देता है, जिससे उनकी मेमोरी खपत सीमित हो जाती है।

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

निष्कर्ष

लेख के पहले भाग में, हमने पाया कि वीटीई-आधारित टर्मिनलों में सुविधाओं का एक अच्छा सेट है, लेकिन अब हम देखते हैं कि यह कुछ प्रदर्शन लागतों के साथ आता है। अब मेमोरी कोई समस्या नहीं है क्योंकि सभी वीटीई टर्मिनलों को डेमॉन प्रक्रिया के माध्यम से नियंत्रित किया जा सकता है, जो उनकी भूख को सीमित करता है। हालाँकि, पुराने सिस्टम जिनमें रैम और कर्नेल बफ़र्स की मात्रा पर भौतिक सीमाएँ हैं, उन्हें अभी भी टर्मिनलों के पुराने संस्करणों की आवश्यकता हो सकती है, क्योंकि वे काफी कम संसाधनों का उपभोग करते हैं। हालाँकि वीटीई टर्मिनलों ने थ्रूपुट (स्क्रॉलिंग) परीक्षणों में अच्छा प्रदर्शन किया, लेकिन उनकी डिस्प्ले विलंबता गनोम उपयोगकर्ता गाइड में निर्धारित सीमा से ऊपर है। वीटीई डेवलपर्स को संभवतः इसे ध्यान में रखना चाहिए। यदि हम इस बात को ध्यान में रखें कि नौसिखिए लिनक्स उपयोगकर्ताओं के लिए भी टर्मिनल का सामना करना अपरिहार्य है, तो वे इसे और अधिक उपयोगकर्ता के अनुकूल बना सकते हैं। अनुभवी गीक्स के लिए, डिफ़ॉल्ट टर्मिनल से स्विच करने का मतलब आंखों पर कम तनाव और लंबे कार्य सत्रों के कारण भविष्य में काम से संबंधित चोटों और बीमारियों से बचने की क्षमता भी हो सकती है। दुर्भाग्य से, केवल पुराने xterm और mlterm ही हमें 10 मिलीसेकंड की जादुई पिंग सीमा तक लाते हैं, जो कई लोगों के लिए अस्वीकार्य है।

बेंचमार्क मापों से यह भी पता चला कि लिनक्स ग्राफिकल वातावरण के विकास के कारण, डेवलपर्स को कई समझौते करने पड़े। कुछ उपयोगकर्ता नियमित विंडो प्रबंधकों को देखना चाह सकते हैं क्योंकि वे महत्वपूर्ण पिंग कमी प्रदान करते हैं। दुर्भाग्य से, वेलैंड के लिए विलंबता को मापना संभव नहीं था: मैंने जिस टाइपोमीटर प्रोग्राम का उपयोग किया था वह वेलैंड को रोकने के लिए डिज़ाइन किया गया था: अन्य विंडो पर जासूसी। मुझे उम्मीद है कि वेलैंड कंपोज़िटिंग X.org से बेहतर प्रदर्शन करेगी, और मुझे यह भी उम्मीद है कि भविष्य में कोई इस वातावरण में विलंबता को मापने का एक तरीका ढूंढ लेगा।

स्रोत: www.habr.com