टर्मिनल इमुलेटरहरूको सिंहावलोकन

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

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

केही टर्मिनलहरूमा एकदमै अचम्मलाग्दो सुरक्षा प्वालहरू छन्, साथै धेरैजसोसँग ट्याब गरिएको इन्टरफेसको लागि समर्थन देखि स्क्रिप्टिङसम्म पूर्ण रूपमा फरक प्रकार्यहरू छन्। यद्यपि हामी टाढाको विगतमा टर्मिनल इमुलेटरहरू हेर्यो, यो लेख अघिल्लो सामग्रीको अद्यावधिक हो जसले पाठकहरूलाई 2018 मा कुन टर्मिनल प्रयोग गर्ने भनेर निर्धारण गर्न मद्दत गर्नेछ। लेखको पहिलो आधा सुविधाहरू तुलना गर्दछ, र दोस्रो आधा कार्यसम्पादन मूल्याङ्कन गर्दछ।

मैले समीक्षा गरेको टर्मिनलहरू यहाँ छन्:

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

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

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

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

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

अब ध्यान दिनुहोस् कि रेखा कसरी xterm मा प्रदर्शित हुन्छ। यो बाहिर जान्छ कि प्रतीक मेम र निम्न सेमिटिक qoph RTL शैली लिपिहरू सन्दर्भ गर्नुहोस् (दाँया-देखि-बाँया), त्यसैले प्राविधिक रूपमा तिनीहरू दायाँबाट बायाँ देखि प्रदर्शित हुनुपर्छ। फायरफक्स 57 जस्ता वेब ब्राउजरहरूले माथिको लाइनलाई सही रूपमा ह्यान्डल गर्दछ। RTL पाठको सरल संस्करण शब्द हो "Сара"हिब्रूमा (सारा). द्विदिशात्मक पाठहरूमा विकी पृष्ठ निम्न भन्छन्:

"धेरै कम्प्युटर प्रोग्रामहरूले द्विदिशात्मक पाठ सही रूपमा प्रदर्शन गर्न सक्दैनन्। उदाहरणका लागि, हिब्रू नाम "Sarah" मा 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 ले ट्याबहरूलाई पनि समर्थन गर्छ, तर यदि तपाईंले प्लगइन प्रयोग गर्नुहुन्छ भने मात्र। तर ट्याब समर्थनको सन्दर्भमा, टर्मिनेटर निर्विवाद नेता हो: यसले ट्याबहरूलाई मात्र समर्थन गर्दैन, तर कुनै पनि क्रममा टर्मिनलहरू मिलाउन सक्छ (तलको छवि हेर्नुहोस्)।

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

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

रफल्स

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

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

केही टर्मिनलहरूले लिङ्कहरूलाई क्लिक गर्न मिल्ने बनाउन URL ढाँचाहरूको लागि पाठ विश्लेषण पनि गर्छन्। यो सबै VTE-व्युत्पन्न टर्मिनलहरूमा लागू हुन्छ, जबकि urxvt लाई विशेष प्लगइन चाहिन्छ जसले URL लाई क्लिकमा वा किबोर्ड सर्टकट प्रयोग गरेर रूपान्तरण गर्छ। अन्य टर्मिनलहरू मैले अन्य तरिकामा प्रदर्शन URL हरू परीक्षण गरेको छु।

अन्तमा, टर्मिनलहरूमा नयाँ प्रवृति भनेको स्क्रोल बफरको वैकल्पिकता हो। उदाहरण को लागी, st, कुनै स्क्रोल बफर छैन; यो मानिन्छ कि प्रयोगकर्ताले टर्मिनल मल्टिप्लेक्सर जस्तै tmux र GNU स्क्रिन.

अलाक्रिटीमा ब्याकस्क्रोल बफरहरूको पनि अभाव छ, तर चाँडै थपिनेछ प्रयोगकर्ताहरूबाट यस विषयमा "व्यापक प्रतिक्रिया" को कारणले यसको समर्थन। यी अपस्टार्टहरू बाहेक, मैले परीक्षण गरेको प्रत्येक टर्मिनलले रिभर्स स्क्रोलिङलाई समर्थन गर्दछ।

उप-योग

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

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

कुराकानी जारी राखौं

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

ढिलाइ

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

तर विलम्बता के हो, र यो किन महत्त्वपूर्ण छ? आफ्नो लेखमा, फटिनले यसलाई "कुञ्जी थिच्ने र सम्बन्धित स्क्रिन अपडेट बीचको ढिलाइ" भनेर परिभाषित गरे र उद्धृत गरे। "मानव-कम्प्युटर अन्तरक्रियाको लागि गाइड", जसले यसो भन्छ: "कम्प्यूटर डिस्प्लेमा भिजुअल प्रतिक्रियामा ढिलाइले टाइपिस्टको व्यवहार र सन्तुष्टिमा महत्त्वपूर्ण प्रभाव पार्छ।"

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

यी प्रभावहरू मध्ये केही लामो समयदेखि ज्ञात छन्, र परिणामहरू अनुसन्धान, 1976 मा जर्नल Ergonomics मा प्रकाशित, भने कि 100 मिलिसेकेन्ड को ढिलाइले "टाइपिङ गतिलाई उल्लेखनीय रूपमा कम गर्छ।" हालसालै, GNOME प्रयोगकर्ता गाइड प्रस्तुत गरियो स्वीकार्य प्रतिक्रिया समय १० मिलिसेकेन्डमा, र यदि तपाईं अगाडि जानुहुन्छ भने, त्यसपछि माइक्रोसफ्ट रिसर्च 1 मिलिसेकेन्ड आदर्श हो भनेर देखाउँछ।

फटिनले पाठ सम्पादकहरूमा आफ्नो परीक्षणहरू सञ्चालन गरे; उसले एउटा पोर्टेबल इन्स्ट्रुमेन्ट सिर्जना गर्यो टाइपोमिटर, जुन मैले टर्मिनल इमुलेटरहरूमा पिंग परीक्षण गर्न प्रयोग गरेको छु। ध्यान राख्नुहोस् कि परीक्षण सिमुलेशन मोडमा सञ्चालन गरिएको थियो: वास्तवमा, हामीले दुवै इनपुट (किबोर्ड, USB नियन्त्रक, आदि) र आउटपुट (भिडियो कार्ड बफर, मनिटर) विलम्बतालाई ध्यानमा राख्न आवश्यक छ। Fatin को अनुसार, सामान्य कन्फिगरेसन मा यो लगभग 20 ms छ। यदि तपाइँसँग गेमिङ उपकरण छ भने, तपाइँ यो संख्या मात्र 3 मिलिसेकेन्डमा प्राप्त गर्न सक्नुहुन्छ। हामीसँग पहिले नै यस्तो द्रुत हार्डवेयर भएकोले, अनुप्रयोगले यसको आफ्नै विलम्बता थप्नु पर्दैन। फ्याटिनको लक्ष्य भनेको एप्लिकेसन लेटन्सीलाई १ मिलिसेकेन्डमा ल्याउनु हो, वा बिना डायलिङ हासिल गर्नु हो। मापन योग्य ढिलाइ, कसरी भित्र IntelliJ IDEA २०१.15.२.२.

यहाँ मेरो मापनको नतिजाहरू छन्, साथै फ्याटिनका केही नतिजाहरू, मेरो प्रयोग उसको परीक्षणहरूसँग सहमत छ भनेर देखाउनको लागि:

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

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

माथिको ग्राफ शुद्ध डेबियन 9 (स्ट्रेच) मा लिइएको छ i3 विन्डो प्रबन्धक। यो वातावरणले विलम्बता परीक्षणहरूमा उत्कृष्ट परिणामहरू उत्पादन गर्दछ। यो बाहिर जान्छ, GNOME ले सबै मापनहरूको लागि थप 20 ms पिंग सिर्जना गर्दछ। यसको लागि सम्भावित व्याख्या इनपुट घटनाहरूको सिंक्रोनस प्रशोधन संग कार्यक्रम को उपस्थिति हो। Fatin यस्तो मामला को लागी एक उदाहरण दिन्छ वर्क्रेभ, जसले सिंक्रोनस रूपमा सबै इनपुट घटनाहरू प्रशोधन गरेर ढिलाइ थप्छ। पूर्वनिर्धारित रूपमा, GNOME सञ्झ्याल प्रबन्धकसँग पनि आउँछ Mutter, जसले बफरिङको अतिरिक्त तह सिर्जना गर्छ, जसले पिङलाई असर गर्छ र कम्तीमा ८ मिलिसेकेन्ड विलम्बता थप्छ।

स्क्रोल गति

अर्को परीक्षण एक परम्परागत "गति" वा "ब्यान्डविथ" परीक्षण हो, जसले स्क्रिनमा ठूलो मात्रामा पाठ प्रदर्शन गर्दा टर्मिनलले पृष्ठ स्क्रोल गर्न कति चाँडो मापन गर्छ। परीक्षणको मेकानिक्स फरक हुन्छ; मूल परीक्षण seq आदेश प्रयोग गरेर समान पाठ स्ट्रिङ उत्पन्न गर्न थियो। अन्य परीक्षणहरूमा Thomas E. Dickey's (xterm maintener) परीक्षण समावेश छ, जुन बारम्बार हुन्छ terminfo.src फाइल डाउनलोड गरिएको छ। टर्मिनल प्रदर्शन को अर्को समीक्षा मा डेन लुउ अनियमित बाइटहरूको आधार 32 इन्कोड गरिएको स्ट्रिङ प्रयोग गर्दछ, जुन cat प्रयोग गरेर टर्मिनलमा आउटपुट हुन्छ। Luu ले यस्तो परीक्षणलाई "कसैले कल्पना गर्न सक्ने बेन्चमार्कको रूपमा बेकार" मान्छ र यसको सट्टामा प्राथमिक मेट्रिकको रूपमा टर्मिनल प्रतिक्रिया प्रयोग गर्न सुझाव दिन्छ। डिकीले आफ्नो परीक्षणलाई भ्रामक पनि भने। यद्यपि, दुबै लेखकहरूले टर्मिनल सञ्झ्याल ब्यान्डविथ एक मुद्दा हुन सक्छ भनेर स्वीकार गर्छन्। Luu ले ठूला फाइलहरू प्रदर्शन गर्दा Emacs Eshell फ्रिजिङ पत्ता लगाए, र Dickey ले xtrerm को दृश्य सुस्तताबाट छुटकारा पाउन टर्मिनललाई अनुकूलित गर्यो। त्यसैले यस परीक्षणमा अझै केही योग्यता छ, तर रेन्डरिङ प्रक्रिया टर्मिनलदेखि टर्मिनलमा धेरै फरक भएकोले, यसलाई अन्य प्यारामिटरहरू परीक्षण गर्न परीक्षण घटकको रूपमा पनि प्रयोग गर्न सकिन्छ।

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

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

"xterm को विपरीत, rxvt ले सबै अद्यावधिकहरू प्रदर्शन गर्ने प्रयास गरेन। यदि यो पछाडि पर्यो भने, यसले समात्नका लागि केही अद्यावधिकहरूलाई अस्वीकार गर्नेछ। यसले आन्तरिक मेमोरी संगठनमा भन्दा स्पष्ट स्क्रोलिङ गतिमा ठूलो प्रभाव पारेको थियो। एउटा कमजोरी थियो कि ASCII एनिमेसन केही हदसम्म अशुद्ध थियो।"

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

स्रोत उपभोग

कार्यसम्पादन मेट्रिकको रूपमा स्क्रोलिङ गतिलाई विचार गर्नु अर्थपूर्ण भए तापनि, यो परीक्षणले हामीलाई टर्मिनलहरूमा लोड सिमुलेट गर्न अनुमति दिन्छ, जसले हामीलाई मेमोरी वा डिस्क प्रयोग जस्ता अन्य प्यारामिटरहरू मापन गर्न अनुमति दिन्छ। मेट्रिक्स निर्दिष्ट परीक्षण चलाएर प्राप्त गरियो seq पाइथन प्रक्रिया निगरानी अन्तर्गत। उनले मिटरको तथ्यांक संकलन गरे getrusage() लागि 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-बिट वास्तुकलामा गरिएको थियो। LCA 2012 Rusty Russell मा भन्यो, कि त्यहाँ धेरै अधिक सूक्ष्म कारणहरू छन् जसले मेमोरी खपतमा वृद्धिको व्याख्या गर्न सक्छ। यसो भनिसकेपछि, हामी अब यस्तो समयमा बाँचिरहेका छौं जहाँ हामीसँग गीगाबाइट मेमोरी छ, त्यसैले हामी कुनै न कुनै रूपमा व्यवस्थापन गर्नेछौं।

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

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

निष्कर्षमा

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

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

स्रोत: www.habr.com