हमारे अनुवाद-ब्यूरो से कुछ शब्द: आमतौर पर हर कोई नवीनतम सामग्रियों और प्रकाशनों का अनुवाद करना चाहता है, और हम कोई अपवाद नहीं हैं। लेकिन टर्मिनल एक ऐसी चीज नहीं है जिसे सप्ताह में एक बार अपडेट किया जाता है। इसलिए, हमने आपके लिए 2018 के वसंत में प्रकाशित एंटोनी बोपरे के एक लेख का अनुवाद किया है: आधुनिक मानकों द्वारा ठोस "उम्र" के बावजूद, हमारी राय में, सामग्री ने पूरी तरह से अपनी प्रासंगिकता नहीं खोई है। इसके अलावा, मूल दो लेखों की एक श्रृंखला है, लेकिन हमने उन्हें एक बड़ी पोस्ट में संयोजित करने का निर्णय लिया।
कंप्यूटर के इतिहास में टर्मिनलों का एक विशेष स्थान है, लेकिन हाल के दशकों में उन्हें सर्वव्यापी ग्राफिकल इंटरफेस की पृष्ठभूमि के खिलाफ कमांड लाइन के साथ-साथ सचमुच "जीवित" रहने के लिए मजबूर किया गया है।
टर्मिनल एमुलेटर ने उनके
हार्डवेयर समकक्षों को बदल दिया, जो बदले में, पंच कार्ड और टॉगल स्विच पर सिस्टम का एक संशोधन था। आधुनिक वितरण सभी आकार और रंगों के टर्मिनल एमुलेटर के एक मेजबान के साथ आते हैं। और जबकि कई चुपचाप अपने काम के माहौल द्वारा प्रदान किए गए मानक टर्मिनल के साथ संतुष्ट हैं, कुछ अपने पसंदीदा खोल या पाठ संपादक को लॉन्च करने के लिए खुलकर विदेशी सॉफ्टवेयर का उपयोग करने पर गर्व करते हैं। लेकिन, जैसा कि हम इस लेख से देखेंगे, सभी टर्मिनल एक छवि और समानता में नहीं बनाए गए थे: वे कार्यक्षमता, आकार और प्रदर्शन में बहुत भिन्न हैं।
कुछ टर्मिनलों में अद्भुत सुरक्षा छेद हैं, साथ ही, अधिकांश में फ़ंक्स्ड इंटरफ़ेस समर्थन से लेकर स्क्रिप्टिंग तक पूरी तरह से अलग कार्य हैं। यद्यपि हमने
दूर के अतीत में टर्मिनल एमुलेटरों को देखा , यह लेख पिछली सामग्री के लिए एक अद्यतन है जो पाठकों को यह निर्धारित करने में मदद करेगा कि 2018 में किस टर्मिनल का उपयोग करना है। लेख की पहली छमाही कार्यों की तुलना करती है, और दूसरी छमाही प्रदर्शन का मूल्यांकन करती है।
यहाँ मेरे द्वारा समीक्षा किए गए टर्मिनल हैं:
शायद ये नवीनतम संस्करण नहीं हैं, क्योंकि मैंने लेखन के समय खुद को स्थिर बिल्ड तक सीमित कर लिया था, जिसे मैं डेबियन 9 या फेडोरा 27 पर रोल आउट करने में सक्षम था। एकमात्र अपवाद अलाक्रिट्टी है। वह GPU त्वरण के साथ टर्मिनलों का एक वंशज है और इस कार्य के लिए एक असामान्य और नई भाषा में लिखा गया है - जंग। मैंने अपनी समीक्षा (
इलेक्ट्रॉन सहित) से वेब टर्मिनलों को बाहर कर दिया, क्योंकि प्रारंभिक परीक्षणों ने उनके बेहद खराब प्रदर्शन को दिखाया।
यूनिकोड समर्थन
मैंने यूनिकोड समर्थन के साथ अपने परीक्षण शुरू किए। पहला टर्मिनल टेस्ट
एक विकिपीडिया लेख से यूनिकोड स्ट्रिंग प्रदर्शित करने के लिए था: "é, test ,,, ק, م, あ, to, to, 葉 और to।" यह सरल परीक्षण दिखाता है कि क्या टर्मिनल दुनिया भर में सही तरीके से काम कर सकता है। Xterm टर्मिनल डिफ़ॉल्ट कॉन्फ़िगरेशन में अरबी
मेम प्रतीक प्रदर्शित नहीं करता है:
डिफ़ॉल्ट रूप से, xterm क्लासिक "फिक्स्ड" फ़ॉन्ट का उपयोग करता है, जो कि
विकी के अनुसार, 1997 से "महत्वपूर्ण यूनिकोड कवरेज" है। इस फॉन्ट में कुछ ऐसा होता है जिसके कारण चरित्र एक खाली फ्रेम के रूप में प्रकट होता है और केवल जब टेक्स्ट फ़ॉन्ट 20+ अंक तक बढ़ जाता है तो चरित्र आखिरकार सही ढंग से प्रदर्शित होने लगता है। हालाँकि, ऐसा "फिक्स" अन्य यूनिकोड वर्णों के प्रदर्शन को तोड़ता है:
ये स्क्रीनशॉट फ़ेडोरा 27 में लिए गए थे, क्योंकि यह वह था जिसने डेबियन 9 की तुलना में बेहतर परिणाम दिए, जहां कुछ पुराने संस्करण (विशेष रूप से एमएलटर्म) फोंट के साथ ठीक से काम नहीं कर सके। सौभाग्य से, यह बाद के संस्करणों में तय किया गया है।
अब xterm में स्ट्रिंग मैपिंग पर ध्यान दें। यह पता चला है कि मेम प्रतीक और उसके बाद के सेमिटिक
Qoph RTL (
दाएं से बाएं ) लिपियों के हैं, इसलिए तकनीकी रूप से उन्हें दाएं से बाएं प्रदर्शित किया जाना चाहिए। वेब ब्राउज़र, जैसे कि फ़ायरफ़ॉक्स 57, उपरोक्त पंक्ति को सही ढंग से संभालता है। RTL पाठ का एक सरल संस्करण हिब्रू ()
רה ) में "
सारा " शब्द है।
द्वि-दिशात्मक विकी पृष्ठ निम्नलिखित कहता है:
“कई कंप्यूटर प्रोग्राम द्विदिश पाठ को सही ढंग से प्रदर्शित नहीं कर सकते हैं। उदाहरण के लिए, हिब्रू नाम "सारा" में प्रतीक पाप (() (जो दाईं ओर दिखाई देता है), फिर रेश (ר) और अंत में, हेह (धुंध) (जो बाईं ओर दिखाई देना चाहिए) शामिल हैं। "
कई टर्मिनल इस परीक्षण में विफल होते हैं: एलेक्रिट्टी, वीटीई-व्युत्पन्न टर्मिनलों गनोम और एक्सएफसीई, यूरैक्साव, सेंट और ज़्टर्म, रिवर्स ऑर्डर में "सारा" को प्रदर्शित करते हैं, जैसे कि हमने इस नाम को "अरास" के रूप में लिखा था।
द्विदिश ग्रंथों के साथ एक और समस्या यह है कि उन्हें किसी भी तरह से संरेखित करने की आवश्यकता होती है, खासकर जब यह आरटीएल और एलटीआर ग्रंथों को मिलाकर आता है। RTL स्क्रिप्ट को टर्मिनल विंडो के दाईं ओर चलना चाहिए, लेकिन डिफ़ॉल्ट रूप से LTR अंग्रेजी का उपयोग करने वाले टर्मिनलों के लिए क्या होना चाहिए? उनमें से अधिकांश के पास कोई विशेष तंत्र नहीं है और पूरे पाठ को बाईं ओर (कॉन्सोल सहित) संरेखित करता है। अपवाद pterm और mlterm हैं, जो मानकों का पालन करते हैं और दाईं ओर ऐसी रेखाओं को संरेखित करते हैं।
सम्मिलन सुरक्षा
अगली महत्वपूर्ण विशेषता जो मैंने खुद के लिए निर्धारित की है, सम्मिलन के खिलाफ सुरक्षा है। हालांकि यह व्यापक रूप से जाना जाता है कि मंत्र:
$ curl http://example.com/ | sh
पुश कोड निष्पादन कमांड हैं; कुछ लोगों को पता है कि छिपे हुए कमांड वेब ब्राउजर से कॉपी और पेस्ट करते समय कंसोल को भेद सकते हैं, यहां तक कि गहन निरीक्षण के बाद भी।
Gianna Horne का परीक्षण स्थल शानदार ढंग से दिखाता है कि टीम कितनी हानिरहित है:
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
यह कैसे काम करता है? दुर्भावनापूर्ण कोड
<span> ब्लॉक में रखा गया है, जिसे सीएसएस का उपयोग करके उपयोगकर्ता के दृष्टि क्षेत्र से स्थानांतरित किया गया है।
ब्रैकेटेड पेस्ट मोड स्पष्ट रूप से ऐसे हमलों को बेअसर करने के लिए डिज़ाइन किया गया है। इस मोड में, इस पाठ की उत्पत्ति के बारे में शेल को सूचित करने के लिए टर्मिनलों ने विशेष एस्केप अनुक्रमों की एक जोड़ी में सम्मिलित पाठ को संलग्न किया है। तो शेल को एक संकेत मिलता है कि यह विशेष वर्णों को अनदेखा कर सकता है जो सम्मिलित पाठ में हो सकते हैं। आदरणीय एक्सटर्म तक सभी टर्मिनल, इस फ़ंक्शन का समर्थन करते हैं, लेकिन ब्रैकेटेड मोड में प्रविष्टि के लिए टर्मिनल पर चल रहे शेल या एप्लिकेशन के लिए समर्थन की आवश्यकता होती है। उदाहरण के लिए,
GNU Readline (उसी बैश) का उपयोग करने वाले सॉफ़्टवेयर को
~ / .inputrc फ़ाइल की आवश्यकता होती है।
set enable-bracketed-paste on
दुर्भाग्य से, हॉर्न परीक्षण साइट यह भी दिखाती है कि पाठ को प्रारूपित करके इस सुरक्षा को कैसे प्राप्त किया जाए और समय-समय पर इसे ब्रैकेटेड मोड पर लागू किया जाए। यह काम करता है क्योंकि कुछ टर्मिनल अपने आप को जोड़ने से पहले भागने के क्रम को सही ढंग से फ़िल्टर नहीं करते हैं। उदाहरण के लिए, खदान में, मैं
कोनसोल परीक्षणों को सफलतापूर्वक पूरा नहीं कर सका, यहां तक कि
.inputrc फ़ाइल के सही कॉन्फ़िगरेशन को ध्यान में रखते हुए। इसका मतलब है कि आप असमर्थित एप्लिकेशन या अनुचित तरीके से कॉन्फ़िगर किए गए शेल के कारण आसानी से सिस्टम कॉन्फ़िगरेशन क्षति प्राप्त कर सकते हैं। रिमोट सर्वर में प्रवेश करते समय यह विशेष रूप से खतरनाक है, जहां कॉन्फ़िगरेशन का सावधानीपूर्वक अध्ययन कम आम है, खासकर यदि आपके पास ऐसी कई दूरस्थ मशीनें हैं।
इस समस्या का एक अच्छा समाधान
urxvt टर्मिनल के लिए पेस्ट
कंफर्मेशन प्लग है, जो किसी भी टेक्स्ट को नई लाइनों को पेस्ट करने की अनुमति मांगता है। हॉर्न द्वारा वर्णित पाठ हमले के लिए मुझे अधिक सुरक्षित विकल्प नहीं मिला।
टैब और प्रोफाइल
एक लोकप्रिय विशेषता अब टैब्ड इंटरफ़ेस का समर्थन करना है, जिसे हम एक टर्मिनल विंडो के रूप में परिभाषित करेंगे जिसमें कुछ और टर्मिनल होंगे। विभिन्न टर्मिनलों के लिए, यह फ़ंक्शन अलग है, और हालांकि xterm जैसे पारंपरिक टर्मिनल बिल्कुल भी टैब का समर्थन नहीं करते हैं, Xfce Terminal, GNOME टर्मिनल और कॉनसोल द्वारा प्रस्तुत अधिक आधुनिक टर्मिनल अवतार में यह फ़ंक्शन है। Urxvt में टैब समर्थन भी है, लेकिन केवल अगर प्लगइन का उपयोग किया जाता है। लेकिन इस तरह समर्थन टैब के संदर्भ में, टर्मिनेटर निर्विवाद नेता है: यह न केवल टैब का समर्थन करता है, बल्कि किसी भी क्रम में टर्मिनलों की व्यवस्था भी कर सकता है (नीचे दी गई छवि देखें)।
टर्मिनेटर की एक अन्य विशेषता इन टैब को एक साथ "समूह" करने और एक ही समय में कई टर्मिनलों पर एक ही कीस्ट्रोक्स भेजने की क्षमता है, जो एक साथ कई सर्वरों पर थोक संचालन करने के लिए एक मोटा उपकरण प्रदान करता है। इसी तरह की सुविधा कोनो कंसोल में भी लागू की गई है। इस फ़ंक्शन को अन्य टर्मिनलों में उपयोग करने के लिए, आपको थर्ड-पार्टी सॉफ़्टवेयर जैसे
क्लस्टर SSH ,
xlax या
tmux का उपयोग करना होगा।
टैब विशेष रूप से प्रोफाइल के साथ मिलकर अच्छी तरह से काम करते हैं: उदाहरण के लिए, आपके पास ईमेल के लिए एक टैब, चैट के लिए दूसरा और इतने पर हो सकता है। यह अच्छी तरह से कॉनसोल और GNOME टर्मिनल द्वारा समर्थित है। दोनों प्रत्येक टैब को स्वचालित रूप से अपनी प्रोफ़ाइल लॉन्च करने की अनुमति देते हैं। टर्मिनेटर प्रोफाइल का भी समर्थन करता है, लेकिन जब मैं एक निश्चित टैब खोलता हूं तो मुझे स्वचालित रूप से कुछ प्रोग्राम लॉन्च करने का तरीका नहीं मिल पाता। अन्य टर्मिनलों में एक प्रोफ़ाइल की अवधारणा बिल्कुल नहीं है।
थिंगी
इस लेख के पहले भाग में अंतिम बात जिस पर मैं विचार करूंगा वह है टर्मिनलों की उपस्थिति। उदाहरण के लिए, GNOME, Xfce, और urxvt पारदर्शिता का समर्थन करते हैं, लेकिन हाल ही में पृष्ठभूमि छवियों के लिए समर्थन को चरणबद्ध किया है, जिससे कुछ उपयोगकर्ताओं को
तिलिक्स टर्मिनल पर स्विच करने के लिए मजबूर किया गया है। व्यक्तिगत रूप से, मैं सिर्फ
एक्सरे स्रोत से खुश
हूं , जो कि urxvt के लिए पृष्ठभूमि रंगों का मूल सेट निर्धारित करता है। हालाँकि, कस्टम रंग थीम समस्याएँ पैदा कर सकते हैं। उदाहरण के लिए,
Solarized htop और
IPTraf अनुप्रयोगों के साथ
काम नहीं करता है , क्योंकि वे पहले से ही अपने रंगों का उपयोग करते हैं।
मूल VT100 टर्मिनल रंगों का समर्थन नहीं करता था, और नए अक्सर एक 256-रंग पैलेट तक सीमित थे। उन्नत उपयोगकर्ताओं के लिए जो अपने टर्मिनलों, शैल अनुरोधों या स्टेटस बार को कुछ जटिल तरीकों से स्टाइल करते हैं, एक अप्रिय सीमा हो सकती है।
Gist का ध्यान रखता है कि किन टर्मिनलों में True Color सपोर्ट है। मेरे परीक्षण इस बात की पुष्टि करते हैं कि सेंट, अल्क्रीटी और वीटीई-आधारित टर्मिनल पूरी तरह से ट्रू कलर का समर्थन करते हैं। इस संबंध में अन्य टर्मिनल बहुत अच्छी तरह से महसूस नहीं करते हैं और वास्तव में 256 रंगों को भी प्रदर्शित नहीं करते हैं। नीचे आप GNOME, St और xterm टर्मिनलों में True Color समर्थन के बीच अंतर देख सकते हैं, जो उनके 256-रंग पैलेट और urxvt के साथ एक अच्छा काम करते हैं, जो न केवल परीक्षण को विफल करता है, बल्कि यहां कुछ ब्लिंकिंग वर्ण भी दिखाता है उन्हें।
कुछ टर्मिनल लिंक को क्लिक करने योग्य बनाने के लिए URL पैटर्न के लिए पाठ का विश्लेषण भी करते हैं। यह सभी VTE- व्युत्पन्न टर्मिनलों पर लागू होता है, जबकि urxvt को एक विशेष प्लग-इन की आवश्यकता होती है जो URL को एक क्लिक या कीबोर्ड शॉर्टकट से बदल देता है। अन्य टर्मिनलों को मैंने अन्य तरीकों से प्रदर्शन URL का परीक्षण किया।
अंत में, टर्मिनलों के लिए एक नया चलन स्क्रॉल बफर विकल्प है। उदाहरण के लिए, सेंट में कोई स्क्रॉल बफर नहीं है; यह माना जाता है कि उपयोगकर्ता tmux और
GNU स्क्रीन जैसे टर्मिनल मल्टीप्लेक्स का उपयोग करेगा।
एलाक्रिटी में रिवर्स स्क्रॉल बफ़र्स का भी अभाव है, लेकिन उपयोगकर्ताओं से इस विषय पर "व्यापक प्रतिक्रिया" के कारण
जल्द ही समर्थन
जोड़ा जाएगा । इन अपस्टार्ट के अलावा, प्रत्येक टर्मिनल जिसका मैंने परीक्षण किया कि मुझे बैकवर्ड स्क्रॉलिंग का समर्थन मिल सकता है।
उप-योगों
सामग्री के दूसरे भाग में (
मूल में, ये दो अलग-अलग लेख थे, - लगभग। प्रति। ) हम प्रदर्शन, स्मृति उपयोग और विलंब की तुलना करेंगे। लेकिन हम पहले से ही देखते हैं कि प्रश्न के कुछ टर्मिनलों में गंभीर कमियां हैं। उदाहरण के लिए, जो उपयोगकर्ता नियमित रूप से RTL स्क्रिप्ट के साथ काम करते हैं, वे एमएलटर्म और पॉटरम पर ध्यान दे सकते हैं, क्योंकि वे दूसरों की तुलना में ऐसे कार्यों का बेहतर सामना करते हैं। कोनसोल ने भी अच्छा प्रदर्शन किया। जो उपयोगकर्ता RTL स्क्रिप्ट के साथ काम नहीं करते हैं वे कुछ और चुन सकते हैं।
दुर्भावनापूर्ण कोड के सम्मिलन के खिलाफ सुरक्षा के दृष्टिकोण से, urxvt इस प्रकार के हमले के खिलाफ सुरक्षा के अपने विशेष कार्यान्वयन के कारण अलग है, जो मुझे निश्चित रूप से सुविधाजनक लगता है। जो लोग किसी भी घंटी और सीटी की तलाश में हैं, उन्हें कोनोलास को देखना चाहिए। अंत में, यह ध्यान देने योग्य है कि वीटीई टर्मिनलों के लिए एक बड़ा आधार है, जो रंग समर्थन, यूआरएल मान्यता और इसी तरह की गारंटी देता है। पहली नज़र में, डिफ़ॉल्ट टर्मिनल जो आपके पसंदीदा वातावरण के साथ आता है, वह सभी आवश्यकताओं को पूरा कर सकता है, लेकिन जब तक हम प्रदर्शन का पता नहीं लगाते हैं, तब तक इस प्रश्न को खुला छोड़ दें।
बातचीत जारी रखें
सामान्य तौर पर, अपने आप में टर्मिनल प्रदर्शन एक दूर की समस्या की तरह लग सकता है, हालांकि, जैसा कि यह निकला, उनमें से कुछ इस मौलिक प्रकार के सॉफ्टवेयर के लिए आश्चर्यजनक रूप से बड़ी देरी का प्रदर्शन करते हैं। हम आगे भी देखेंगे कि पारंपरिक रूप से "गति" कहा जाता है (वास्तव में, यह स्क्रॉल गति है) और टर्मिनल द्वारा मेमोरी की खपत (यह मानते हुए कि आज यह दशकों पहले जितनी महत्वपूर्ण नहीं है)।
विलंब
टर्मिनल प्रदर्शन के गहन अध्ययन के बाद, मैं इस निष्कर्ष पर पहुंचा कि इस संबंध में सबसे महत्वपूर्ण पैरामीटर देरी का आकार (पिंग) है। अपने लेख
"हम खुशी के साथ प्रिंट करते हैं" में, पावेल फतिन ने विभिन्न पाठ संपादकों की देरी की जांच की और संकेत दिया कि इस संबंध में टर्मिनलों सबसे तेजी से पाठ संपादकों की तुलना में अधिक धीरे-धीरे काम कर सकते हैं। यह वह संकेत था जिसने मुझे, अंततः अपने स्वयं के परीक्षण शुरू करने और इस लेख को लिखने के लिए प्रेरित किया।
लेकिन देरी क्या है, और यह इतना महत्वपूर्ण क्यों है? अपने लेख में, फतिन ने इसे "एक कुंजी और संबंधित स्क्रीन अपडेट दबाने के बीच की देरी" के रूप में परिभाषित किया और
"मानव-कंप्यूटर इंटरैक्शन पर मैनुअल" के रूप में कहा: "कंप्यूटर डिस्प्ले पर दृश्य प्रतिक्रिया में देरी का टाइपिस्ट के व्यवहार और उसकी संतुष्टि पर महत्वपूर्ण प्रभाव पड़ता है। "।
फतिन बताते हैं कि इस तरह के पिंग से केवल संतुष्टि की तुलना में अधिक गहरे परिणाम होते हैं: "टाइपिंग धीमी हो जाती है, अधिक त्रुटियां होती हैं, आंख और मांसपेशियों में तनाव बढ़ जाता है।" दूसरे शब्दों में, एक बड़ी देरी से टाइपोस हो सकता है, साथ ही कोड की गुणवत्ता में कमी हो सकती है, क्योंकि यह मस्तिष्क पर एक अतिरिक्त संज्ञानात्मक भार की ओर जाता है। लेकिन इससे भी बदतर, पिंग "आंखों और मांसपेशियों के तनाव को बढ़ाता है", जो जाहिर है, भविष्य में
पेशेवर चोटों के
विकास का अर्थ है (
जाहिर है, लेखक का अर्थ है आंखों की मांसपेशियों, पीठ, हथियार और, निश्चित रूप से, दृष्टि की समस्याओं के साथ,) - लगभग। ) दोहराए जाने वाले तनाव के कारण।
इनमें से कुछ प्रभाव एक लंबे समय के लिए जाने जाते हैं, और 1976 में जर्नल एर्गोनॉमिक्स में प्रकाशित एक
अध्ययन के परिणाम कहते हैं कि 100 मिलीसेकेंड की देरी "डायल करने की गति को काफी खराब कर देती है।" अभी हाल ही में, 10 मिलीसेकंड का
स्वीकार्य प्रतिक्रिया समय GNOME उपयोगकर्ता गाइड में पेश किया गया था, और यदि हम आगे बढ़ते हैं, तो
Microsoft अनुसंधान से पता चलता है कि 1 मिलीसेकंड आदर्श है।
फतीन ने पाठ संपादकों पर अपने परीक्षण किए; उन्होंने
टाइपोमीटर नाम का एक पोर्टेबल टूल बनाया, जिसका इस्तेमाल मैंने टर्मिनल एमुलेटर में पिंग टेस्ट करने के लिए किया। ध्यान रखें कि परीक्षण सिमुलेशन मोड में आयोजित किया गया था: वास्तव में, हमें इनपुट देरी (कीबोर्ड, यूएसबी नियंत्रक, आदि) और आउटपुट (वीडियो कार्ड बफर, मॉनिटर) पर भी विचार करने की आवश्यकता है। Fatin के अनुसार, विशिष्ट विन्यास में यह लगभग 20 ms है। यदि आपके पास गेमिंग उपकरण हैं, तो आप केवल 3 मिली सेकेंड का एक संकेतक प्राप्त कर सकते हैं। चूंकि हमारे पास पहले से ही ऐसे तेज़ उपकरण हैं, इसलिए आवेदन में देरी नहीं होनी चाहिए। Fatin का लक्ष्य 1 मिलीसेकंड तक के आवेदन में देरी करना है, या
InteliJ IDEA 15 के अनुसार , बिना किसी
देरी के डायलिंग प्राप्त करना है।
और यहाँ मेरे माप के परिणाम हैं, साथ ही साथ फतिन के कुछ परिणाम भी हैं ताकि यह दिखाया जा सके कि मेरा प्रयोग उनके परीक्षणों के अनुरूप है:
पहली चीज जिसने मुझे मारा, वह पुराने कार्यक्रमों जैसे कि xterm और mlterm के लिए सबसे अच्छा प्रतिक्रिया समय था। सबसे खराब रजिस्टर विलंबता (2.4 एमएस) के साथ, उन्होंने सबसे तेज आधुनिक टर्मिनल (सेंट के लिए 10.6 एमएस) की तुलना में बेहतर परिणाम दिखाया। एक भी आधुनिक टर्मिनल 10 मिलीसेकंड की सीमा से नीचे नहीं आता है। विशेष रूप से, अल्क्रीटी "सबसे तेज़ मौजूदा टर्मिनल एमुलेटर" के लिए आवश्यकताओं को पूरा नहीं करता है, हालांकि 2017 में पहली जांच के बाद से इसके परिणामों में सुधार हुआ है। दरअसल, परियोजना के लेखक
स्थिति से अवगत हैं और प्रदर्शन को बेहतर बनाने के लिए काम कर रहे हैं। यह भी ध्यान दिया जाना चाहिए कि GTK3 का उपयोग करने वाला विम अपने GTK2 समकक्ष की तुलना में परिमाण धीमा का एक क्रम है। इससे हम यह निष्कर्ष निकाल सकते हैं कि GTK3 एक अतिरिक्त देरी पैदा करता है, और यह अन्य सभी टर्मिनलों में परिलक्षित होता है जो इसका उपयोग करते हैं (टर्मिनेटर, Xfce4 टर्मिनल और GNOME टर्मिनल)।
हालांकि, अंतर आंख को दिखाई नहीं दे सकता है। जैसा कि फतिन बताते हैं: "इसके लिए आप पर प्रभाव पड़ने के लिए देरी के बारे में पता होना आवश्यक नहीं है।" फतिन एक मानक विचलन की चेतावनी भी देते हैं: "देरी (घबराना) की लंबाई में कोई भी अनियमितता उनकी अप्रत्याशितता के कारण एक अतिरिक्त बोझ पैदा करती है।"
ऊपर का ग्राफ
i3 विंडो मैनेजर के साथ शुद्ध डेबियन 9 (खिंचाव) पर लिया गया है। यह वातावरण विलंब परीक्षणों में सर्वोत्तम परिणाम देता है। जैसा कि यह निकला, गनोम सभी आयामों के लिए 20 एमएस का एक अतिरिक्त पिंग बनाता है। इसके लिए एक संभावित स्पष्टीकरण इनपुट घटनाओं के तुल्यकालिक प्रसंस्करण के साथ कार्यक्रमों की उपस्थिति है। Fatin इस मामले के लिए एक
Workrave उदाहरण का हवाला देता है, जो सभी इनपुट घटनाओं को समकालिक रूप से संसाधित करके विलंब जोड़ता है। डिफ़ॉल्ट रूप से, गनोम में एक
मुटर विंडो मैनेजर भी होता है जो बफरिंग का एक अतिरिक्त स्तर बनाता है, जो पिंग को प्रभावित करता है और न्यूनतम 8 मिलीसेकेंड की देरी जोड़ता है।
स्क्रॉल गति
अगला परीक्षण पारंपरिक "स्पीड" या "बैंडविड्थ" टेस्ट है, जो मापता है कि स्क्रीन पर बड़ी मात्रा में पाठ प्रदर्शित करते हुए टर्मिनल पृष्ठ पर कितनी जल्दी स्क्रॉल कर सकता है। परीक्षण के यांत्रिकी अलग-अलग होते हैं; मूल परीक्षण सिर्फ seq कमांड के साथ एक ही टेक्स्ट स्ट्रिंग उत्पन्न करना था। अन्य परीक्षणों में थॉमस ई। डिके (xterm
अनुचर ) द्वारा एक परीक्षण शामिल है, जो बार-बार
termfo.src फ़ाइल डाउनलोड करता है । एक अन्य टर्मिनल प्रदर्शन की समीक्षा में,
डेन लुयू यादृच्छिक बाइट्स के एक बेस 32 एनकोडेड स्ट्रिंग का उपयोग करता है, जो बिल्ली का उपयोग करके टर्मिनल के लिए आउटपुट है। लुओ इस तरह की परीक्षा को "बेकार मानती है क्योंकि इसकी कल्पना की जा सकती है" और टर्मिनल की प्रतिक्रिया को मुख्य संकेतक के रूप में उपयोग करने का सुझाव देती है। डिकी अपने परीक्षण को भ्रामक भी कहता है। हालांकि, दोनों लेखकों ने स्वीकार किया कि टर्मिनल विंडो बैंडविड्थ एक समस्या हो सकती है। लुओ ने बड़ी फ़ाइलों को प्रदर्शित करते समय Emacs Eshell को फ्रीजिंग पाया, और डिक्सी ने xtrerm के दृश्य सुस्ती से छुटकारा पाने के लिए टर्मिनल को अनुकूलित किया। इसलिए, इस परीक्षण के लिए अभी भी कुछ कारण है, लेकिन चूंकि प्रतिपादन प्रक्रिया टर्मिनल से टर्मिनल तक बहुत अलग है, इसलिए इसे अन्य मापदंडों की जांच के लिए परीक्षण घटक के रूप में भी इस्तेमाल किया जा सकता है।
यहाँ हम देखते हैं कि rxvt और st प्रतिस्पर्धा में आगे हैं, इसके बाद बहुत नए अल्क्रिट्री हैं, जिन्हें गति पर ध्यान केंद्रित करके विकसित किया जा रहा है। इसके बाद Xfce (VTE परिवार) और कॉनसोल आते हैं, जो लगभग दोगुनी तेजी से काम करते हैं। पिछले एक xxm है जिसमें rxvt की तुलना में पाँच गुना धीमा सूचकांक है। परीक्षण के दौरान, xterm भी तरंगित हो गया, पासिंग टेक्स्ट को देखना मुश्किल था, भले ही वह एक ही पंक्ति हो। कॉनसोल तेजी से निकला, लेकिन कई बार यह "मुश्किल" था: प्रदर्शन समय-समय पर लटका दिया गया, पाठ को आंशिक रूप से दिखा रहा था या इसे बिल्कुल भी प्रदर्शित नहीं कर रहा था। अन्य टर्मिनलों ने स्ट्रिंग्स को स्पष्ट रूप से प्रदर्शित किया, जिसमें सेंट, अल्क्रिटरी और आरएक्सएवीटी शामिल हैं।
डिक्की बताती हैं कि प्रदर्शन अंतर विभिन्न टर्मिनलों में स्क्रॉल बफ़र्स के डिज़ाइन से संबंधित हैं। विशेष रूप से, वह rxvt और "सामान्य नियमों का पालन नहीं करने" के अन्य टर्मिनलों पर आरोप लगाता है:
“Xterm के विपरीत, rxvt ने सभी अपडेट प्रदर्शित करने का प्रयास नहीं किया। यदि वह पीछे पड़ता है, तो वह पकड़ने के लिए कुछ अपडेट छोड़ देगा। आंतरिक मेमोरी के संगठन की तुलना में काल्पनिक स्क्रॉल गति पर इसका अधिक प्रभाव पड़ा। एक कमी यह थी कि ASCII एनीमेशन कुछ हद तक गलत था। ”
Xterm की इस प्रतीत होने वाली सुस्ती को ठीक करने के लिए, डिके
फास्टसक्रोल रिसोर्स का उपयोग करने का सुझाव देता है, जो कि स्ट्रीम को बनाए रखने के लिए xterm को कुछ स्क्रीन अपडेट को छोड़ने की अनुमति देता है। मेरे परीक्षण इस बात की पुष्टि करते हैं कि फास्टस्क्रॉल प्रदर्शन में सुधार करता है और xterm को rxvt के समान स्तर पर लाता है। यह, हालांकि, बल्कि एक क्रूड बैसाखी है, जैसा कि डिक्की खुद बताती है: "कभी-कभी एक्सटर्म - जैसे कोनोलास - बंद करना लगता है, क्योंकि यह उनमें से कुछ को हटाए जाने के बाद स्क्रीन अपडेट के एक नए सेट की उम्मीद करता है।" इस नस में, ऐसा लगता है कि अन्य टर्मिनलों ने गति और प्रदर्शन अखंडता के बीच सबसे अच्छा समझौता पाया है।
संसाधन की खपत
स्क्रॉल गति को प्रदर्शन के संकेतक के रूप में विचार करने की उपयुक्तता के बावजूद, यह परीक्षण आपको टर्मिनलों पर भार का अनुकरण करने की अनुमति देता है, जो बदले में, हमें स्मृति या डिस्क उपयोग जैसे अन्य मापदंडों को मापने की अनुमति देता है। पायथन प्रक्रिया की निगरानी में निर्दिष्ट
seq परीक्षण चलाकर मेट्रिक्स प्राप्त किए गए थे। उन्होंने
ru_maxrss ,
ru_oublock और
ru_inblock का योग
, और एक साधारण टाइमर के लिए
getrusage () काउंटर डेटा एकत्र किया।
इस परीक्षण में, एसटी 8 एमबी की सबसे छोटी औसत मेमोरी खपत के साथ पहला स्थान लेता है, जो आश्चर्य की बात नहीं है जब आप समझते हैं कि परियोजना का मुख्य विचार सादगी है। Mlterm, xterm और rxvt थोड़ा अधिक उपभोग करते हैं - लगभग 12 एमबी। अल्क्रिट्री का एक और उल्लेखनीय परिणाम है, जिसे काम करने के लिए 30 एमबी की आवश्यकता होती है। फिर 40 से 60 एमबी तक के संकेतकों के साथ वीटीई परिवार के टर्मिनल हैं, जो काफी है। इस तरह की खपत को इस तथ्य से समझाया जा सकता है कि ये टर्मिनल उच्च-स्तरीय पुस्तकालयों का उपयोग करते हैं, उदाहरण के लिए, जीटीके। कोंसोल परीक्षणों के दौरान 65 एमबी मेमोरी की भारी खपत के साथ आता है, हालांकि यह अपने कार्यों की एक विस्तृत श्रृंखला द्वारा उचित ठहराया जा सकता है।
दस साल पहले प्राप्त पिछले परिणामों की तुलना में, सभी कार्यक्रमों ने काफी अधिक मेमोरी का उपभोग करना शुरू कर दिया। पहले, Xterm को 4 एमबी की आवश्यकता थी, लेकिन अब - 15 एमबी सिर्फ चलाने के लिए। Rxvt की खपत में समान वृद्धि हुई है, जिसके लिए अब बॉक्स से 16 एमबी की आवश्यकता होती है। Xfce टर्मिनल में 34 MB है, जो पहले की तुलना में तीन गुना अधिक है, लेकिन GNOME टर्मिनल को केवल 20 एमबी की आवश्यकता है। बेशक, पिछले सभी परीक्षण 32-बिट आर्किटेक्चर पर किए गए थे। 2012 LCA में, रस्टी रसेल
ने कहा कि कई और सूक्ष्म कारण हैं जो स्मृति की खपत में वृद्धि की व्याख्या कर सकते हैं। इस सब के साथ, हम अब ऐसे समय में रह रहे हैं जब हमारे पास पूरी गीगाबाइट मेमोरी है, इसलिए हम इसे किसी भी तरह से संभाल सकते हैं।
फिर भी, मैं यह महसूस करने में मदद नहीं कर सकता कि टर्मिनल के रूप में ऐसे मूलभूत सॉफ़्टवेयर को अधिक मेमोरी आवंटित करना संसाधनों की बर्बादी है। , «», , - , Linux- ( , ). , . , GNOME Terminal, Konsole, urxvt, Terminator Xfce Terminal Daemon-, , .
-: , , . , VTE (
2010 , ). , , , AES256 GCM (
0.39.2 ). , VTE, …
निष्कर्ष
, VTE , , . , VTE- Daemon-, . , , , - , . VTE (), GNOME. , VTE . , Linux , . - . , xterm mlterm 10 , .
, - Linux . , . , Wayland : Typometer, , , Wayland — . , Wayland , X.org, , - .