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

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



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


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

فيما يلي المحطات التي استعرضتها:



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

دعم يونيكود

بدأت اختباراتي بدعم Unicode. وكان أول اختبار سلسلة محطات عرض onymi من يونيكود من المقالات في ويكيبيديا : «é، Δ، Q، ק، م، 7،あ،叶،葉و말». يوضح هذا الاختبار البسيط ما إذا كان الجهاز يمكن أن يعمل بشكل صحيح في جميع أنحاء العالم. لا يعرض الجهاز xterm رمز Arabic Mem في التكوين الافتراضي:



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



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

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

"لا يمكن للعديد من برامج الكمبيوتر عرض نص ثنائي الاتجاه بشكل صحيح. على سبيل المثال، الاسم العبري "سارة" يتكون من الأحرف SYN (ש) (الذي يظهر إلى اليمين)، ثم resh (ר)، وأخيرا، هيه (ה) (والتي يجب أن تظهر على اليسار) ".

العديد من المحطات تفشل في هذا الاختبار: Alacritty ، المحطات المشتقة من VTE Gnome و 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 

كيف يعمل؟ يتم وضع الشفرة الضارة في كتلة <span> ، والتي يتم نقلها من مجال رؤية المستخدم باستخدام CSS.

تم تصميم وضع لصق بين قوسين بشكل واضح لتحييد مثل هذه الهجمات. في هذا الوضع ، تقوم المحطات الطرفية بتضمين النص المدرج في زوج من تسلسل هروب خاص لإبلاغ shell حول أصل هذا النص. إذن ، يتلقى shell إشارة أنه بإمكانه تجاهل الأحرف الخاصة التي قد يحتوي عليها النص المدرج. تدعم جميع هذه المحطات ، حتى xterm الموقرة ، هذه الوظيفة ، لكن الإدراج في وضع Bracketed يتطلب دعمًا لقذيفة أو تطبيق يعمل على الجهاز الطرفي. على سبيل المثال ، يحتاج البرنامج الذي يستخدم GNU Readline (نفس Bash) إلى ملف ~ / .inputrc :

 set enable-bracketed-paste on 

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

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

علامات التبويب و الملامح

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



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

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

ثينجيس

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

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



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

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

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

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

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

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

استمر في المحادثة

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

تأخير

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

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

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

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

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

وإليكم نتائج قياساتي ، وكذلك بعض نتائج فاتن لإظهار أن تجربتي تتوافق مع اختباراته:



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

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



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

سرعة التمرير

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



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

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

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

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

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

بغض النظر عن مدى ملاءمة التفكير في سرعة التمرير كمؤشر للأداء ، يسمح لك هذا الاختبار بمحاكاة الحمل على الأجهزة الطرفية ، والذي بدوره يسمح لنا بقياس المعلمات الأخرى ، مثل استخدام الذاكرة أو القرص. تم الحصول على المقاييس عن طريق تشغيل اختبار seq المحدد تحت مراقبة عملية بايثون. قام بجمع بيانات عداد getrusage () لـ ru_maxrss ، ومجموع ru_oublock و ru_inblock ، وجهاز توقيت بسيط.



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

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

ومع ذلك ، لا يسعني إلا أن أشعر بأن تخصيص المزيد من الذاكرة لبرامج أساسية مثل الجهاز هو مضيعة للموارد. , «», , - , 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, , - .