نظرة عامة على المحاكيات الطرفية

بضع كلمات من مكتب الترجمة لدينا: عادةً ما يسعى الجميع إلى ترجمة أحدث المواد والمنشورات ، ولسنا استثناءً. لكن المحطات ليست شيئًا يتم تحديثه مرة واحدة في الأسبوع. لذلك ، قمنا بترجمة مقال بقلم أنطوان بوبر ، نُشر في ربيع عام 2018: على الرغم من "العصر" المحترم بالمعايير الحديثة ، في رأينا ، لم تفقد المادة أهميتها على الإطلاق. بالإضافة إلى ذلك ، في الأصل ، هذه سلسلة من مقالتين ، لكننا قررنا دمجهما في منشور واحد كبير.

تتمتع المحطات الطرفية بمكانة خاصة في تاريخ الكمبيوتر ، ولكن في العقود الأخيرة تم "إجبارها" على البقاء حرفيًا جنبًا إلى جنب مع سطر الأوامر على خلفية الواجهات الرسومية في كل مكان. المحاكيات الطرفية استبدلت بهم نظرائهم في الأجهزة، والتي كانت بدورها عبارة عن تعديل للأنظمة على البطاقات المثقوبة ومفاتيح التبديل. التوزيعات الحديثة تأتي مع عدد كبير من المحاكيات الطرفية بجميع الأشكال والألوان. وبينما يكتفي الكثيرون بالمحطة القياسية التي تأتي مع بيئة عملهم ، يفخر البعض باستخدام برامج غريبة بصراحة لإطلاق محرر النصوص أو المحرر المفضل لديهم. ولكن ، كما سنرى من هذه المقالة ، لم يتم إنشاء جميع المحطات الطرفية بالطريقة نفسها: فهي تختلف اختلافًا كبيرًا في الوظائف والحجم والأداء.

تحتوي بعض المحطات على ثغرات أمنية مذهلة ، بالإضافة إلى أن معظمها يحتوي على مجموعة مختلفة تمامًا من الميزات ، من دعم الواجهة المبوبة إلى البرمجة النصية. على الرغم من أننا تعتبر محاكيات نهائية في الماضي البعيد، هذه المقالة هي تحديث للمادة السابقة التي ستساعد القراء على تحديد المحطة التي يجب استخدامها في عام 2018. يقارن النصف الأول من المقالة الميزات ، بينما يقيّم النصف الثاني الأداء.

فيما يلي المحطات الطرفية التي قمت بمراجعتها:

قد لا تكون هذه هي أحدث الإصدارات ، حيث كنت مقيدًا بالبنيات المستقرة وقت كتابة هذا التقرير ، والتي تمكنت من طرحها على دبيان 9 أو فيدورا 27. الاستثناء الوحيد هو Alacritty. إنه سليل من المحطات الطرفية المتسارعة بواسطة GPU وهو مكتوب بلغة جديدة غير عادية لهذه المهمة - Rust. لقد استبعدت أجهزة الويب الطرفية من مراجعتي (بما في ذلك تلك الموجودة على الإلكترون) ، لأن الاختبارات الأولية أظهرت أدائها السيئ للغاية.

دعم يونيكود

لقد بدأت اختباراتي بدعم Unicode. كان الاختبار الأول للمحطات هو عرض سلسلة حول unicode عليها مقالات على ويكيبيديا: "é, Δ, й, ק, م, ๗, あ, 叶, 葉 and 말". يوضح هذا الاختبار البسيط ما إذا كان الجهاز يمكن أن يعمل بشكل صحيح في جميع أنحاء العالم. لا تعرض محطة xterm الأحرف العربية م في التكوين الافتراضي:

بشكل افتراضي ، يستخدم xterm خطًا كلاسيكيًا "ثابتًا" ، وفقًا لـ نفس الويكي، "تغطية يونيكود كبيرة منذ 1997". هناك شيء ما يحدث في هذا الخط يؤدي إلى ظهور الحرف كإطار فارغ ، وفقط عندما يتم زيادة خط النص إلى 20+ نقطة يبدأ الحرف أخيرًا في العرض بشكل صحيح. ومع ذلك ، فإن مثل هذا "الإصلاح" يكسر عرض أحرف Unicode الأخرى:

تم التقاط لقطات الشاشة هذه في Fedora 27 ، لأنها أعطت نتائج أفضل من Debian 9 ، حيث لا يمكن لبعض الإصدارات القديمة من المحطات الطرفية (تحديدًا mlterm) أن تعمل بشكل صحيح مع الخطوط. لحسن الحظ تم إصلاح هذا في الإصدارات الأحدث.

انتبه الآن إلى عرض السلسلة في xterm. اتضح أن رمز Mem متبوعًا بالسامية كوف الرجوع إلى نصوص الكتابة اليدوية من اليمين إلى اليسار (من اليمين الى اليسار) ، لذلك يجب تقنيًا تحويلها من اليمين إلى اليسار. متصفحات الويب مثل Firefox 57 تتعامل مع السلسلة أعلاه بشكل صحيح. نسخة أبسط من نص RTL هي كلمة "سارة" في العبرية (שרה). صفحة ويكي على ثنائي الاتجاه يقول ما يلي:

"العديد من برامج الكمبيوتر لا يمكنها عرض نص ثنائي الاتجاه بشكل صحيح. For example, the Hebrew name Sarah consists of the characters sin (ש) (which appears on the right), then resh (ר), and finally heh (ה) (which must appear on the left).”

تفشل العديد من المحطات الطرفية في هذا الاختبار: المحطات الطرفية المشتقة من VTE من Alacritty و Gnome's و XFCE و urxvt و st و xterm تعرض "Sarah" بترتيب عكسي ، كما لو قمنا بتهجئة الاسم كـ "Aras".

هناك مشكلة أخرى في النصوص ثنائية الاتجاه وهي أنها تحتاج إلى محاذاة بطريقة ما ، خاصة عندما يتعلق الأمر بمزج نصوص RTL و LTR. يجب تشغيل نصوص RTL النصية من الجانب الأيمن من النافذة الطرفية ، ولكن ما الذي يجب أن يحدث للمحطات الطرفية التي تشغل LTR English افتراضيًا؟ معظمهم ليس لديهم أي آليات خاصة ويقومون بمحاذاة كل النص إلى اليسار (بما في ذلك في Konsole). الاستثناءات هي pterm و mlterm ، والتي تلتزم بالمعايير وتقوم بمحاذاة هذه الأسطر.

أدخل الحماية

الميزة المهمة التالية التي حددتها لنفسي هي حماية اللصق. على الرغم من أنه من المعروف على نطاق واسع أن نوبات مثل:

$ curl http://example.com/ | sh

هي أوامر دفع لتنفيذ التعليمات البرمجية ، قلة من الناس يعرفون أن الأوامر المخفية يمكن أن تتسلل إلى وحدة التحكم عند النسخ واللصق من مستعرض الويب ، حتى بعد الفحص الدقيق. موقع التحقق من جان هورن يوضح ببراعة كيف يبدو الأمر غير ضار:

git clone git: //git.kernel.org/pub/scm/utils/kup/kup.git

يتحول إلى مثل هذا الإزعاج عند اللصق من موقع Horn على الويب في المحطة:

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 الموقر هذه الميزة ، لكن الإدخال في الوضع Bracketed يحتاج إلى دعم من الغلاف أو التطبيق الذي يعمل على الجهاز. على سبيل المثال ، البرامج التي تستخدم خط قراءة جنو (نفس Bash) ، يحتاج إلى ملف ~/.inputrc:

set enable-bracketed-paste on

لسوء الحظ ، يوضح موقع اختبار Horn أيضًا كيفية تجاوز هذه الحماية من خلال تنسيق النص نفسه وإنهاء وضع Bracketed قبل الأوان عليه. يعمل هذا لأن بعض المحطات الطرفية لا تقوم بتصفية تسلسلات الهروب بشكل صحيح قبل إضافة تسلسلها. على سبيل المثال ، بالنسبة لي ، لم أتمكن مطلقًا من إكمال اختبارات Konsole بنجاح حتى مع التكوين الصحيح. .inputrc ملف. هذا يعني أنه يمكنك بسهولة الحصول على تلف تكوين النظام بسبب تطبيق غير مدعوم أو خطأ في تكوين shell. هذا أمر خطير بشكل خاص عند تسجيل الدخول إلى الخوادم البعيدة ، حيث يكون عمل التكوين الدقيق أقل شيوعًا ، خاصة إذا كان لديك الكثير من هذه الأجهزة البعيدة.

حل جيد لهذه المشكلة هو Paste Confirmation Plugin for Terminal urxvt، الذي يطلب الإذن ببساطة للصق أي نص يحتوي على أسطر جديدة. لم أجد خيارًا أكثر أمانًا للهجوم النصي الذي وصفه هورن.

علامات التبويب والملفات الشخصية

الميزة الشائعة الآن هي دعم الواجهة المبوبة ، والتي سنعرّفها على أنها نافذة طرفية واحدة تحتوي على عدة محطات طرفية. تختلف هذه الميزة من محطة إلى أخرى ، وعلى الرغم من أن محطات xterm التقليدية لا تدعم علامات التبويب على الإطلاق ، فإن التجسيدات الطرفية الأكثر حداثة مثل Xfce Terminal و GNOME Terminal و Konsole تفعل ذلك. يحتوي Urxvt أيضًا على دعم لعلامات التبويب ، ولكن فقط في حالة استخدام المكون الإضافي. ولكن فيما يتعلق بدعم علامات التبويب في حد ذاتها ، فإن Terminator هو القائد بلا منازع: فهو لا يدعم علامات التبويب فحسب ، بل يمكنه أيضًا وضع المحطات الطرفية بترتيب تعسفي (انظر الصورة أدناه).

ميزة أخرى لـ Terminator هي القدرة على "تجميع" علامات التبويب هذه معًا وإرسال نفس ضغطات المفاتيح إلى محطات طرفية متعددة في نفس الوقت ، مما يوفر أداة بدائية لإجراء عمليات مجمعة على خوادم متعددة في نفس الوقت. يتم أيضًا تنفيذ ميزة مماثلة في Konsole. لاستخدام هذه الوظيفة في محطات طرفية أخرى ، تحتاج إلى استخدام برنامج طرف ثالث مثل الكتلة SSH, xlax أو tmux.

تعمل علامات التبويب بشكل جيد مع الملفات الشخصية: على سبيل المثال ، قد يكون لديك علامة تبويب للبريد الإلكتروني وأخرى للدردشة وما إلى ذلك. هذا مدعوم جيدًا من قبل Konsole و GNOME Terminal. كلاهما يسمح لكل علامة تبويب بتشغيل ملف التعريف الخاص بها تلقائيًا. يدعم Terminator أيضًا ملفات التعريف ، لكن لم أتمكن من العثور على طريقة لتشغيل برامج معينة تلقائيًا عند فتح علامة تبويب معينة. لا تملك المحطات الطرفية الأخرى مفهوم "الملف الشخصي" على الإطلاق.

الكشكشة

آخر شيء سأقوم بتغطيته في الجزء الأول من هذه المقالة هو مظهر المحطات. على سبيل المثال ، تدعم GNOME و Xfce و urxvt الشفافية ، ولكنها أسقطت مؤخرًا دعم صور الخلفية ، مما أجبر بعض المستخدمين على التبديل إلى الجهاز Tilix. أنا شخصياً راضٍ وعادل xresources، والتي تحدد المجموعة الأساسية من ألوان الخلفية لـ urxvt. ومع ذلك ، يمكن أن تؤدي نُسق الألوان غير القياسية إلى حدوث مشكلات. على سبيل المثال، solarized عليه لا يعمل مع التطبيقات HTOP и IPTraf، لأنهم يستخدمون بالفعل ألوانهم الخاصة.

محطة VT100 الأصلية لا تدعم الألوان ، وغالبًا ما كانت الألوان الجديدة تقتصر على 256 لونًا. بالنسبة لمستخدمي الطاقة الذين يصممون أجهزتهم الطرفية ، يمكن أن تكون مطالبات shell أو أشرطة الحالة بطريقة معقدة قيدًا سيئًا. جوهر يتتبع المحطات الطرفية التي تدعم "اللون الحقيقي". تؤكد اختباراتي أن المحطات الطرفية القائمة على st و Alacritty و VTE تدعم True Color بشكل مثالي. لا تعمل المحطات الطرفية الأخرى بشكل جيد في هذا الصدد ، وفي الواقع لا تعرض حتى 256 لونًا. أدناه ، يمكنك أن ترى الفرق بين دعم True Color في محطات جنوم الطرفية ، st و xterm ، اللذان يقومان بعمل جيد جدًا باستخدام لوح الألوان 256 لونًا ، و urxvt ، الذي لا يفشل في الاختبار فحسب ، بل يُظهر أيضًا بعض الأحرف الوامضة بدلاً من ذلك. .

تقوم بعض المحطات أيضًا بتحليل النص لأنماط عناوين URL لجعل الروابط قابلة للنقر عليها. ينطبق هذا على جميع المحطات الطرفية المشتقة من VTE ، بينما يتطلب urxvt مكونًا إضافيًا خاصًا من شأنه تحويل عناوين URL عند النقر أو باستخدام اختصار لوحة المفاتيح. محطات أخرى لقد اختبرت عناوين URL المعروضة بشكل مختلف.

أخيرًا ، هناك اتجاه جديد في المحطات وهو المخزن المؤقت التمرير الاختياري. على سبيل المثال ، لا يحتوي st على مخزن مؤقت للتمرير ؛ من المفترض أن يستخدم المستخدم معدد إرسال طرفي مثل tmux و جنو الشاشة.

يفتقر Alacritty أيضًا إلى مخازن backscroll ، ولكن ستضاف قريبا دعمها بسبب "التعليقات المكثفة" حول هذا الموضوع من المستخدمين. بصرف النظر عن هذه الشركات الناشئة ، فإن كل محطة قمت بفحصها يمكنني العثور عليها تدعم التمرير العكسي.

المجاميع الفرعية

في الجزء الثاني من المادة (في الأصل ، كان هذان مقالان مختلفان - تقريبًا. لكل.) سنقارن الأداء واستخدام الذاكرة والكمون. لكننا نرى بالفعل أن بعض المحطات المعنية بها عيوب خطيرة. على سبيل المثال ، قد ينتبه المستخدمون الذين يعملون مع نصوص RTL النصية بشكل منتظم إلى mlterm و pterm ، لأنهم أفضل من الآخرين في مثل هذه المهام. كان أداء كونسول جيدًا أيضًا. يمكن للمستخدمين الذين لا يتعاملون مع البرامج النصية من اليمين إلى اليسار اختيار شيء آخر.

من وجهة نظر الحماية ضد إدخال التعليمات البرمجية الخبيثة ، فإن urxvt يقف بعيدًا بسبب تنفيذه الخاص للحماية ضد هذا النوع من الهجوم ، والذي أجده مناسبًا بالتأكيد. أولئك الذين يبحثون عن بعض الأجراس والصفارات يجب عليهم التحقق من كونسول. أخيرًا ، تجدر الإشارة إلى أن VTE هي قاعدة رائعة للأجهزة الطرفية ، والتي تضمن دعم الألوان والتعرف على عنوان URL وما إلى ذلك. للوهلة الأولى ، قد تناسب المحطة الافتراضية التي تأتي مع بيئتك المفضلة الفاتورة ، لكننا سنترك هذا السؤال مفتوحًا حتى نصل إلى أدنى مستوى من الأداء.

نواصل الحديث

بشكل عام ، قد يبدو أداء المحطات الطرفية في حد ذاته مشكلة بعيدة المنال ، ومع ذلك ، كما اتضح ، فإن بعضها يُظهر وقت استجابة مرتفعًا بشكل مفاجئ لبرامج من هذا النوع الأساسي. علاوة على ذلك ، سننظر أيضًا في ما يُسمى تقليديًا "السرعة" (في الواقع ، هذه هي سرعة التمرير) واستهلاك ذاكرة الجهاز (مع مراعاة حقيقة أن هذا اليوم ليس بالغ الأهمية كما كان قبل عقود).

تأخير

بعد دراسة شاملة لأداء المحطات ، توصلت إلى استنتاج مفاده أن أهم عامل في هذا الصدد هو حجم التأخير (ping). في مقالته "نطبع بكل سرور" نظر بافل فاتن في زمن انتقال العديد من محرري النصوص وألمح إلى أن المحطات الطرفية قد تكون أبطأ في هذا الصدد من أسرع برامج تحرير النصوص. كان هذا التلميح هو الذي دفعني في النهاية إلى إجراء اختباراتي الخاصة وكتابة هذا المقال.

ولكن ما هو وقت الاستجابة ، ولماذا هو مهم جدًا؟ في مقالته ، عرّفها فاتن على أنها "التأخير بين الضغط على مفتاح وتحديث الشاشة المقابل" ونقلت عنه "دليل التفاعل بين الإنسان والحاسوب"، والتي تنص على أن: "التأخير في التعليقات المرئية على شاشة الكمبيوتر له تأثير مهم على سلوك الطابعات ورضاهم."

يوضح فاتن أن مثل هذا الاختبار له عواقب أعمق من مجرد الرضا: "تصبح الكتابة أبطأ ، وتحدث المزيد من الأخطاء ، ويزداد إجهاد العين والعضلات". بمعنى آخر ، يمكن أن يؤدي التأخير الكبير إلى أخطاء إملائية ، فضلاً عن انخفاض جودة الشفرة ، حيث يؤدي إلى عبء معرفي إضافي على الدماغ. ولكن لجعل الأمور أسوأ ، فإن ping "يزيد من إجهاد العين والعضلات" ، وهو ما يبدو أنه يعني ذلك تطور إصابات العمل في المستقبل (على ما يبدو ، يشير المؤلف إلى مشاكل في عضلات العينين والظهر والذراعين وبالطبع الرؤية - تقريبًا. لكل.) بسبب الإجهاد المتكرر.

بعض هذه التأثيرات معروفة منذ زمن طويل ونتائجها بحث، الذي نُشر في عام 1976 في مجلة Ergonomics ، يقول إن التأخير لمدة 100 مللي ثانية "يقلل بشكل كبير من سرعة الطباعة." في الآونة الأخيرة ، تمت إضافة دليل مستخدم جنوم وقت استجابة مقبول في غضون 10 مللي ثانية ، وإذا ذهبت إلى أبعد من ذلك ، فحينئذٍ مايكروسوفت للبحوث يشير إلى أن القيمة المثالية هي 1 مللي ثانية.

أجرى فاتن اختباراته على محرري النصوص. ابتكر أداة محمولة تسمى الطباعيالذي اعتدت عليه لاختبار ping في المحاكيات الطرفية. ضع في اعتبارك أن الاختبار تم تشغيله في وضع المحاكاة: في الواقع ، نحتاج إلى مراعاة كل من زمن انتقال الإدخال (لوحة المفاتيح ، وحدة تحكم USB ، وما إلى ذلك) وزمن انتقال الإخراج (المخزن المؤقت لبطاقة الفيديو ، والشاشة). وفقًا لفاتن ، في التكوينات النموذجية ، تبلغ حوالي 20 مللي ثانية. باستخدام معدات الألعاب ، يمكنك تحقيق رقم 3 مللي ثانية فقط. نظرًا لأن لدينا بالفعل مثل هذه الأجهزة السريعة ، يجب ألا يضيف التطبيق أي زمن انتقال. هدف فاتن هو رفع زمن انتقال التطبيق إلى 1 مللي ثانية ، أو حتى تحقيق الاتصال بدونه تأخير قابل للقياس، كيف في IntelliJ IDEA 15.

وإليكم نتائج قياساتي بالإضافة إلى بعض نتائج فاتن لتوضيح أن تجربتي متوافقة مع اختباراته:

أول ما أدهشني هو أوقات الاستجابة الأفضل للبرامج القديمة مثل xterm و mlterm. مع أسوأ زمن انتقال للتسجيل (2,4 مللي ثانية) ، كان أداؤهم أفضل من أسرع محطة حديثة (10,6 مللي ثانية للشارع). لا توجد محطة حديثة تنخفض عن عتبة 10 مللي ثانية. على وجه الخصوص ، لا ترقى Alacritty إلى ادعاء "أسرع محاكي طرفي في الوجود" ، على الرغم من تحسن درجاتها منذ أن تمت مراجعتها لأول مرة في عام 2017. في الواقع ، مؤلفو المشروع على علم بالوضع ويعملون على تحسين العرض. وتجدر الإشارة أيضًا إلى أن Vim الذي يستخدم GTK3 هو ترتيب من حيث الحجم أبطأ من نظيره GTK2. من هذا المنطلق يمكننا أن نستنتج أن GTK3 يخلق زمن انتقال إضافي ، وهذا ينعكس في جميع المحطات الطرفية الأخرى التي تستخدمه (Terminator و Xfce4 Terminal و GNOME Terminal).

ومع ذلك ، قد لا تكون الاختلافات ملحوظة للعين. كما توضح فاتن ، "ليس عليك أن تكون على دراية بالتأخير حتى يكون له تأثير عليك." كما تحذر فاتن من الانحراف المعياري: "أي مخالفات في مدة التأخير (الارتعاش) تخلق عبئًا إضافيًا بسبب عدم القدرة على التنبؤ بها".

الرسم البياني أعلاه مأخوذ من دبيان 9 (امتداد) نظيف مع مدير نافذة i3. تعطي هذه البيئة أفضل النتائج في اختبارات زمن الوصول. كما اتضح ، يولد جنوم 20 مللي ثانية بينغ لكل القياسات. التفسير المحتمل لهذا هو وجود برامج مع معالجة متزامنة لأحداث الإدخال. فاتن تعطي مثالاً على مثل هذه الحالة Workrave، مما يضيف زمن انتقال من خلال معالجة جميع أحداث الإدخال بشكل متزامن. يأتي جنوم أيضًا مع مدير نوافذ افتراضيًا. أم، مما يؤدي إلى إنشاء طبقة إضافية من التخزين المؤقت الذي يؤثر على اختبار ping ويضيف ما لا يقل عن 8 مللي ثانية من وقت الاستجابة.

سرعة التمرير

الاختبار التالي هو اختبار "السرعة" أو "النطاق الترددي" التقليدي ، والذي يقيس مدى سرعة تمرير الجهاز الطرفي للصفحة أثناء عرض قدر كبير من النص على الشاشة. تختلف آليات الاختبار ؛ كان الاختبار الأصلي هو إنشاء نفس السلسلة النصية باستخدام الأمر seq. تشمل الاختبارات الأخرى اختبارًا أجراه Thomas E.Dickey (مشرف xterm) مرارًا وتكرارًا تم إلغاء تحميل ملف terminfo.src. في مراجعة أخرى لأداء المحطة دن لو يستخدم سلسلة base32 المشفرة من وحدات البايت العشوائية التي يتم إخراجها إلى المحطة الطرفية باستخدام cat. يعتبر Luu مثل هذا الاختبار "عديم الفائدة كمعيار يمكن تخيله" ويقترح استخدام استجابة المحطة كمقياس رئيسي بدلاً من ذلك. كما وصف ديكي اختباره بأنه مضلل. ومع ذلك ، يقر كلا المؤلفين بأن عرض النطاق الترددي للإطار الطرفي يمكن أن يكون مشكلة. وجد Luu أن Emacs Eshell معلقًا عند عرض ملفات كبيرة ، وقام Dickey بتحسين الجهاز للتخلص من التباطؤ البصري لـ xtrerm. لذلك ، لا يزال هناك بعض المزايا في هذا الاختبار ، ولكن نظرًا لأن عملية التقديم مختلفة جدًا من محطة إلى أخرى ، فيمكن أيضًا استخدامها كمكون اختبار للتحقق من المعلمات الأخرى.

هنا نرى rxvt و st يتصدران المنافسة ، يليهما Alacritty الأحدث كثيرًا ، والذي يتم تطويره مع التركيز على الأداء. يأتي بعد ذلك Xfce (عائلة VTE) و Konsole ، والتي تكاد تكون أسرع بمرتين. يأتي الأخير xterm ، وهو أبطأ بخمس مرات من rxvt. أثناء الاختبار ، تموج xterm أيضًا كثيرًا ، وكان من الصعب رؤية النص ، حتى لو كان نفس السطر. كان Konsole سريعًا ، ولكنه كان أحيانًا "ماكرًا": كان العرض معلقًا من وقت لآخر ، يعرض النص جزئيًا أو لا يعرضه على الإطلاق. عرضت المحطات الطرفية الأخرى السلاسل بوضوح ، بما في ذلك st و Alacritty و rxvt.

يوضح ديكي أن اختلافات الأداء ترجع إلى تصميم مخازن التمرير في محطات مختلفة. على وجه الخصوص ، يتهم rxvt والمحطات الأخرى بعدم "اتباع القواعد العامة":

"بخلاف xterm ، لم يحاول rxvt عرض كافة التحديثات. إذا تأخر ، فسوف يسقط بعض الترقيات للحاق بالركب. كان لهذا تأثير على سرعة التمرير الظاهرة أكثر من تأثيره على تنظيم الذاكرة الداخلية. كان أحد العوائق هو أن الرسوم المتحركة ASCII كانت غير دقيقة إلى حد ما ".

لإصلاح هذا البطء الظاهر في xterm ، يقترح ديكي استخدام المورد التمرير السريع، مما يسمح لـ xterm بتجاهل بعض تحديثات الشاشة لمواكبة التدفق. تؤكد اختباراتي أن fastScroll يحسن الأداء ويجعل xterm على قدم المساواة مع rxvt. ومع ذلك ، يعد هذا اختراقًا فظًا إلى حد ما ، كما يشرح ديكي نفسه: "في بعض الأحيان يبدو أن xterm - مثل konsole - يتوقف أثناء انتظار مجموعة جديدة من تحديثات الشاشة بعد إزالة بعضها." في هذا السياق ، يبدو أن المحطات الطرفية الأخرى قد وجدت أفضل حل وسط بين السرعة وسلامة العرض.

استهلاك المصدر

بغض النظر عن فائدة النظر في سرعة التمرير كمقياس للأداء ، يسمح لنا هذا الاختبار بمحاكاة الحمل على المحطات ، والذي بدوره يسمح لنا بقياس المعلمات الأخرى مثل الذاكرة أو استخدام القرص. تم الحصول على المقاييس عن طريق إجراء الاختبار المحدد يليها تحت مراقبة عملية بايثون. قام بجمع بيانات العداد getrusage() إلى ru_maxrss، مجموع ar_oublock и en_inblock وجهاز توقيت بسيط.

في هذا الاختبار ، يحتل الطراز ST المرتبة الأولى بأقل متوسط ​​استهلاك للذاكرة يبلغ 8 ميجابايت ، وهو أمر لا يثير الدهشة نظرًا لأن الفكرة الرئيسية للمشروع هي البساطة. يستهلك عدد أكبر قليلاً من mlterm و xterm و rxvt - حوالي 12 ميغا بايت. نتيجة أخرى ملحوظة هي Alacritty ، والتي تتطلب 30 ميغابايت للتشغيل. ثم هناك محطات لعائلة VTE بمؤشرات من 40 إلى 60 ميجابايت ، وهو عدد كبير جدًا. يمكن تفسير هذا الاستهلاك من خلال حقيقة أن هذه المحطات تستخدم مكتبات ذات مستوى أعلى ، مثل GTK. يأتي Konsole أخيرًا بذاكرة ضخمة تبلغ 65 ميجابايت أثناء الاختبارات ، على الرغم من أنه لا يزال من الممكن تبرير ذلك من خلال مجموعة الميزات الواسعة جدًا.

مقارنة بالنتائج السابقة التي تم الحصول عليها قبل عشر سنوات ، بدأت جميع البرامج في استهلاك ذاكرة أكبر بشكل ملحوظ. كانت Xterm تتطلب 4 ميغا بايت ، لكنها الآن 15 ميغا بايت فقط عند بدء التشغيل. هناك زيادة مماثلة في استهلاك rxvt ، والتي تتطلب الآن 16 ميغابايت خارج الصندوق. تستهلك Xfce Terminal 34 ميجابايت ، أي ثلاثة أضعاف ما كانت عليه من قبل ، بينما تتطلب محطة جنوم 20 ميجابايت فقط. بالطبع ، تم إجراء جميع الاختبارات السابقة على بنية 32 بت. في LCA 2012 رستي راسل قيل ليأن هناك العديد من الأسباب الدقيقة التي يمكن أن تفسر الزيادة في استهلاك الذاكرة. مع كل هذا ، نحن نعيش الآن في وقت لدينا فيه غيغابايت كاملة من الذاكرة ، لذلك يمكننا بطريقة ما التعامل معها.

ومع ذلك ، لا يسعني الشعور بأن تخصيص المزيد من الذاكرة لمثل هذه البرامج الأساسية مثل المحطة الطرفية يعد إهدارًا للموارد. يجب أن تكون هذه البرامج أصغر من أصغرها ، ويجب أن تكون قادرة على العمل على أي "صندوق" ، حتى صندوق الأحذية ، إذا وصلنا إلى النقطة التي يجب أن تكون مجهزة بأنظمة Linux (وأنت تعلم أنها ستكون كذلك ). ولكن مع هذه الأرقام ، سيصبح استخدام الذاكرة مشكلة في المستقبل في أي بيئة عند تشغيل محطات طرفية متعددة ، باستثناء عدد قليل من الأخف وزناً والأكثر محدودية في القدرات. للتعويض عن ذلك ، فإن GNOME Terminal و Konsole و urxvt و Terminator و Xfce Terminal لديها وضع Daemon الذي يسمح لك بالتحكم في محطات متعددة من خلال عملية واحدة ، مما يحد من استهلاكها للذاكرة.

أثناء اختباراتي ، توصلت إلى نتيجة أخرى غير متوقعة تتعلق بقراءة القرص وكتابته: لم أتوقع ألا أرى أي شيء هنا على الإطلاق ، ولكن اتضح أن بعض المحطات تكتب أكبر البيانات على القرص. لذلك ، تحتفظ مكتبة VTE في الواقع بمخزن تمرير مؤقت على القرص (هذه الميزة تم رصده مرة أخرى في عام 2010وما زال هذا يحدث). ولكن على عكس التطبيقات القديمة ، يتم الآن تشفير هذه البيانات على الأقل باستخدام AES256 GCM (منذ الإصدار 0.39.2). ولكن هناك سؤال منطقي يطرح نفسه ، ما الذي يميز مكتبة VTE لدرجة أنها تتطلب مثل هذا النهج غير القياسي للتنفيذ ...

اختتام

في الجزء الأول من المقالة ، وجدنا أن المحطات المستندة إلى VTE لها مجموعة ميزات جيدة ، لكننا الآن نرى أن هذا يأتي مع بعض الأداء الزائد. الآن الذاكرة ليست مشكلة ، لأنه يمكن التحكم في جميع VTEs من خلال عملية Daemon التي تحد من شهيتهم. ومع ذلك ، فإن الأنظمة القديمة المحدودة فعليًا من حيث ذاكرة الوصول العشوائي ومخزن النواة المؤقت قد لا تزال بحاجة إلى محطات طرفية قديمة لأنها تستهلك موارد أقل بشكل ملحوظ. على الرغم من أن المحطات الطرفية VTE تعمل بشكل جيد في اختبارات الإنتاجية (التمرير) ، إلا أن زمن انتقال العرض لديهم أعلى من الحد المعين في دليل مستخدم جنوم. ربما يجب على مطوري VTE أخذ ذلك في الاعتبار. إذا أخذنا في الاعتبار أنه حتى بالنسبة لمستخدمي Linux المبتدئين الذين يواجهون محطة طرفية أمر لا مفر منه ، فيمكنهم جعله أكثر سهولة في الاستخدام. بالنسبة للمهوسين ذوي الخبرة ، يمكن أن يؤدي التبديل من الجهاز الافتراضي إلى تقليل إجهاد العين وتجنب الإصابات والأمراض المهنية في المستقبل بسبب جلسات العمل الطويلة. لسوء الحظ ، فقط xterm و mlterm القديمان يجلباننا إلى عتبة ping السحرية البالغة 10 مللي ثانية ، وهو أمر غير مقبول بالنسبة للكثيرين.

أظهرت المعايير أيضًا أنه نظرًا لتطوير بيئات Linux الرسومية ، كان على المطورين تقديم عدد من التنازلات. يجب على بعض المستخدمين إلقاء نظرة على مديري النوافذ العاديين حيث أنهم يقدمون تقليلًا ملحوظًا في اختبار الاتصال. لسوء الحظ ، لم يكن هناك قياس زمن الوصول لـ Wayland: تم تصميم برنامج Typometer الذي استخدمته للقيام بما صمم Wayland لمنعه - التجسس على النوافذ الأخرى. آمل أن يكون أداء تركيب Wayland أفضل من X.org ، وآمل أيضًا أن يجد شخص ما في المستقبل طريقة لتقدير مستوى زمن الانتقال في هذه البيئة.

المصدر: www.habr.com