چند کلمه از دفتر ترجمه ما: معمولاً همه تلاش می کنند تا آخرین مطالب و نشریات را ترجمه کنند و ما نیز از این قاعده مستثنی نیستیم. اما پایانه ها چیزی نیستند که هفته ای یک بار به روز شوند. بنابراین ، ما مقاله ای از آنتوان بوپر را برای شما ترجمه کرده ایم که در بهار سال 2018 منتشر شده است: با وجود "سن" قابل توجه آن طبق استانداردهای مدرن ، به نظر ما ، این مطالب به هیچ وجه اهمیت خود را از دست نداده است. علاوه بر این، این در ابتدا یک سری از دو مقاله بود، اما ما تصمیم گرفتیم آنها را در یک پست بزرگ ترکیب کنیم.
ترمینال ها جایگاه ویژه ای در تاریخ کامپیوتر دارند، اما در دهه های اخیر با فراگیر شدن رابط های گرافیکی مجبور شده اند در کنار خط فرمان زنده بمانند. خود را جایگزین کردند ، که به نوبه خود اصلاحی در سیستم های مبتنی بر کارت های پانچ و سوئیچ های ضامن بودند. توزیع‌های مدرن با انواع شبیه‌سازهای ترمینال در هر شکل و رنگ عرضه می‌شوند. و در حالی که بسیاری از ترمینال استاندارد ارائه شده توسط محیط کار خود راضی هستند، برخی با افتخار از نرم افزارهای عجیب و غریب برای اجرای پوسته یا ویرایشگر متن مورد علاقه خود استفاده می کنند. اما، همانطور که از این مقاله خواهیم دید، همه پایانه ها در یک تصویر ایجاد نشده اند: آنها از نظر عملکرد، اندازه و عملکرد بسیار متفاوت هستند.
برخی از پایانه‌ها دارای حفره‌های امنیتی کاملاً شگفت‌انگیزی هستند، به‌علاوه اکثر آنها مجموعه‌ای از عملکردهای کاملاً متفاوت، از پشتیبانی از یک رابط زبانه‌دار گرفته تا اسکریپت‌نویسی دارند. اگرچه ما ، این مقاله به روزرسانی مطالب قبلی است که به خوانندگان کمک می کند تا در سال 2018 از کدام ترمینال استفاده کنند. نیمه اول مقاله ویژگی ها را مقایسه می کند و نیمه دوم عملکرد را ارزیابی می کند.
این ترمینال هایی است که من بررسی کردم:
این ممکن است آخرین نسخه ها نباشد ، زیرا من در زمان نوشتن به ساختهای پایدار محدود شدم ، که توانستم به Debian 9 یا Fedora 27 بپردازم. تنها استثناء Alacritty است. این یک نسل از ترمینال های شتاب دهنده GPU است و به زبانی غیرمعمول و جدید برای این کار نوشته شده است - Rust. من پایانه های وب را از بررسی خود حذف کردم (از جمله آنهایی که در آن قرار دارند ، زیرا آزمایشات اولیه عملکرد بسیار ضعیف آنها را نشان داد.
پشتیبانی از یونیکد
من تست هایم را با پشتیبانی یونیکد شروع کردم. اولین آزمایش پایانه ها نمایش رشته یونیکد از آن بود : "é، Δ، И، ק، م، ๗، あ، 叶، 葉 و 말." این تست ساده نشان می دهد که آیا ترمینال می تواند در سراسر جهان به درستی کار کند. ترمینال xterm کاراکتر عربی را نمایش نمی دهد در پیکربندی پیش فرض:
به‌طور پیش‌فرض، xterm از فونت کلاسیک «ثابت» استفاده می‌کند که با توجه به ، "از سال 1997 پوشش یونیکد قابل توجهی دارد". چیزی در این فونت رخ می دهد که باعث می شود کاراکتر به صورت یک قاب خالی ظاهر شود و تنها زمانی که فونت متن به 20+ نقطه افزایش یابد، در نهایت کاراکتر شروع به نمایش صحیح می کند. با این حال، این "اصلاح" نمایش سایر کاراکترهای یونیکد را خراب می کند:
این اسکرین شات ها در فدورا 27 گرفته شده اند، زیرا نتایج بهتری نسبت به دبیان 9 ارائه می دهد، جایی که برخی از نسخه های قدیمی تر پایانه ها (مخصوصا mlterm) نمی توانند فونت ها را به درستی مدیریت کنند. خوشبختانه در نسخه های بعدی این مشکل برطرف شد.
حال توجه کنید که خط در xterm چگونه نمایش داده می شود. معلوم می شود که نماد مم و سامی زیر است به اسکریپت های سبک RTL مراجعه کنید (، بنابراین از نظر فنی باید از راست به چپ نمایش داده شوند. مرورگرهای وب مانند فایرفاکس 57 خط فوق را به درستی مدیریت می کنند. یک نسخه ساده تر از متن RTL کلمه " است."در عبری (). زیر می گوید:
بسیاری از برنامه های کامپیوتری نمی توانند متن دو جهته را به درستی نمایش دهند. به عنوان مثال، نام عبری "سارا" از نویسه های sin (ש) (که در سمت راست ظاهر می شود)، سپس رش (ר) و در نهایت he (ה) (که باید در سمت چپ ظاهر شود) تشکیل شده است."
بسیاری از ترمینال ها در این تست مردود می شوند: پایانه های Alacritty، Gnome و XFCE مشتق از VTE، urxvt، st و xterm "Sara" را به ترتیب معکوس نمایش می دهند، گویی نام را به صورت "Aras" نوشته ایم.
یکی دیگر از مشکلات متون دو جهته این است که آنها باید به نحوی تراز شوند، به خصوص وقتی صحبت از ترکیب متون RTL و LTR می شود. اسکریپت‌های RTL باید از سمت راست پنجره ترمینال اجرا شوند، اما برای پایانه‌هایی که به‌طور پیش‌فرض به زبان انگلیسی LTR هستند، چه اتفاقی باید بیفتد؟ اکثر آنها مکانیسم خاصی ندارند و تمام متن را در سمت چپ (از جمله در 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 ارجمند از این ویژگی پشتیبانی می کنند ، اما چسباندن در حالت براکت نیاز به پشتیبانی از پوسته یا برنامه اجرا در ترمینال دارد. برای مثال استفاده از نرم افزار (همان Bash)، به فایل نیاز دارد ~/.inputrc:
set enable-bracketed-paste onمتأسفانه، سایت تست هورن همچنین نشان می دهد که چگونه می توان از طریق قالب بندی متن از این محافظت عبور کرد و در نهایت حالت Bracketed را برای آن اعمال کرد. این کار به این دلیل کار می‌کند که برخی از پایانه‌ها قبل از اضافه کردن دنباله‌های خود، توالی‌های فرار را به درستی فیلتر نمی‌کنند. به عنوان مثال، در من هرگز نتوانستم تست های Konsole را حتی با پیکربندی صحیح با موفقیت انجام دهم. inputrc فایل. این بدان معنی است که شما به راحتی می توانید پیکربندی سیستم خود را به دلیل یک برنامه پشتیبانی نشده یا یک پوسته پیکربندی نادرست خراب کنید. این امر به ویژه هنگام ورود به سرورهای راه دور خطرناک است، جایی که کار پیکربندی دقیق کمتر رایج است، به خصوص اگر چنین ماشین های راه دور زیادی دارید.
یک راه حل خوب برای این مشکل ، افزونه تأیید خمیر برای ترمینال است urxvt، که به سادگی اجازه درج هر متنی که حاوی خطوط جدید است را می خواهد. من گزینه ایمن تر برای حمله متنی که توسط هورن توضیح داده شده است، پیدا نکرده ام.
برگه ها و پروفایل ها
یک ویژگی محبوب در حال حاضر پشتیبانی از یک رابط زبانه ای است که ما آن را به عنوان یک پنجره ترمینال حاوی چندین ترمینال دیگر تعریف می کنیم. این عملکرد برای پایانه‌های مختلف متفاوت است، و اگرچه پایانه‌های xterm سنتی اصلاً از تب‌ها پشتیبانی نمی‌کنند، تجسم‌های ترمینال مدرن‌تر مانند Xfce Terminal، GNOME Terminal و Konsole این عملکرد را دارند. Urxvt از تب ها نیز پشتیبانی می کند، اما فقط در صورتی که از افزونه استفاده کنید. اما از نظر پشتیبانی از تب، ترمیناتور رهبر بلامنازع است: نه تنها از برگه ها پشتیبانی می کند، بلکه می تواند پایانه ها را به هر ترتیبی ترتیب دهد (تصویر زیر را ببینید).
یکی دیگر از ویژگی های ترمیناتور امکان "گروه بندی" این تب ها و ارسال کلیدهای یکسان به چندین ترمینال به طور همزمان است که ابزاری خام برای انجام عملیات انبوه روی چندین سرور به طور همزمان ارائه می دهد. ویژگی مشابهی نیز در Konsole پیاده سازی شده است. برای استفاده از این قابلیت در پایانه های دیگر باید از نرم افزارهای شخص ثالث مانند , یا .
برگه ها هنگام جفت شدن با نمایه ها به خوبی کار می کنند: برای مثال، می توانید یک برگه برای ایمیل، برگه دیگری برای چت و غیره داشته باشید. این به خوبی توسط Konsole Terminal و GNOME Terminal پشتیبانی می شود. هر دو به هر برگه اجازه می‌دهند به طور خودکار نمایه خود را راه‌اندازی کند. Terminator همچنین از پروفایل ها پشتیبانی می کند، اما من نتوانستم راهی برای راه اندازی خودکار برنامه های خاص در هنگام باز کردن یک برگه خاص پیدا کنم. پایانه های دیگر اصلاً مفهوم "پروفایل" را ندارند.
رافل
آخرین چیزی که در قسمت اول این مقاله به آن می پردازم ظاهر پایانه ها است. به عنوان مثال GNOME، Xfce و urxvt از شفافیت پشتیبانی می‌کنند، اما اخیراً پشتیبانی از تصاویر پس‌زمینه را کاهش داده‌اند و برخی از کاربران را مجبور کرده‌اند به ترمینال سوئیچ کنند. . من شخصا از آن راضی هستم و ساده است منابع، که مجموعه پایه رنگ های پس زمینه را برای urxvt تنظیم می کند. با این حال، تم های رنگی غیر استاندارد نیز می توانند مشکلاتی ایجاد کنند. مثلا، با برنامه های کاربردی и ، زیرا آنها قبلاً از رنگ های خود استفاده می کنند.
از رنگ ها پشتیبانی نمی کرد و رنگ های جدید اغلب به یک پالت 256 رنگ محدود می شدند. برای کاربران پیشرفته ای که به پایانه های خود استایل می دهند، اعلان های پوسته یا نوارهای وضعیت به روش های پیچیده می تواند یک محدودیت آزاردهنده باشد. آهنگ هایی که پایانه ها از "رنگ واقعی" پشتیبانی می کنند. تست های من تأیید می کنند که پایانه های ST ، Alacritty و VTE مبتنی بر رنگ واقعی از رنگ واقعی پشتیبانی می کنند. پایانه های دیگر در این زمینه خیلی خوب عمل نمی کنند و در واقع حتی 256 رنگ را نمایش نمی دهند. در زیر می‌توانید تفاوت بین پشتیبانی True Color در پایانه‌های گنوم، st و xterm را مشاهده کنید، که با پالت رنگی ۲۵۶ خود این کار را به خوبی انجام می‌دهند، و urxvt که نه تنها در تست مردود می‌شود، بلکه حتی برخی از کاراکترهای چشمک‌زن را به جای آنها نشان می‌دهد.
برخی از پایانه ها همچنین متن را برای الگوهای URL تجزیه و تحلیل می کنند تا پیوندها را قابل کلیک کنند. این برای تمام پایانه‌های مشتق شده از VTE اعمال می‌شود، در حالی که urxvt به یک پلاگین خاص نیاز دارد که URLها را با یک کلیک یا با استفاده از یک میانبر صفحه کلید تغییر می‌دهد. پایانه های دیگری که من آزمایش کرده ام URL ها را به روش های دیگری نمایش می دهند.
در نهایت، یک روند جدید در پایانه ها، اختیاری بودن بافر اسکرول است. به عنوان مثال، st هیچ بافر اسکرول ندارد. فرض بر این است که کاربر از یک مالتی پلکسر ترمینال مانند tmux و استفاده خواهد کرد .
Alacritty همچنین فاقد بافرهای backscroll است، اما پشتیبانی آن به دلیل "بازخورد گسترده" در مورد این موضوع از سوی کاربران. جدا از این شروع‌ها، هر پایانه‌ای که من تست کردم و پیدا کردم، از اسکرول معکوس پشتیبانی می‌کند.
کل حجم
در قسمت دوم مطالب (در اصل این دو مقاله متفاوت بود - تقریبا. مسیر) عملکرد، استفاده از حافظه و تأخیر را با هم مقایسه خواهیم کرد. اما در حال حاضر می‌توانیم ببینیم که برخی از پایانه‌های مورد بحث دارای کاستی‌های جدی هستند. به عنوان مثال، کاربرانی که به طور منظم با اسکریپت های RTL کار می کنند، ممکن است بخواهند mlterm و pterm را در نظر بگیرند، زیرا آنها در انجام کارهای مشابه بهتر از سایرین هستند. کنسول نیز عملکرد خوبی داشت. کاربرانی که با اسکریپت های RTL کار نمی کنند ممکن است چیز دیگری را انتخاب کنند.
از نظر محافظت در برابر درج کد مخرب ، URXVT به دلیل اجرای ویژه محافظت در برابر این نوع حمله ، که به نظر می رسد برای من راحت است ، برجسته می شود. برای کسانی که به دنبال چند زنگ و سوت هستند، Konsole ارزش دیدن دارد. در نهایت، شایان ذکر است که VTE یک پایه عالی برای پایانه ها است که پشتیبانی از رنگ، تشخیص URL و غیره را تضمین می کند. در نگاه اول ، ترمینال پیش فرض که با محیط مورد علاقه شما همراه است ممکن است تمام شرایط را برآورده کند ، اما بیایید این سؤال را باز کنیم تا اینکه عملکرد را درک کنیم.
گفتگو را ادامه می دهیم
به طور کلی، عملکرد پایانه ها به خودی خود ممکن است مشکلی دور از ذهن به نظر برسد، اما همانطور که مشخص است، برخی از آنها تأخیر بسیار زیادی را برای نرم افزارهایی از این نوع اساسی نشان می دهند. همچنین در ادامه به آنچه که به طور سنتی "سرعت" نامیده می شود (در واقع این سرعت پیمایش است) و مصرف حافظه ترمینال (با این اخطار که امروزه به اندازه دهه های قبل حیاتی نیست) خواهیم دید.
تاخیر انداختن
پس از مطالعه کامل عملکرد ترمینال به این نتیجه رسیدم که مهمترین پارامتر در این زمینه تاخیر (پینگ) است. در مقاله خود پاول فاتین به تأخیر ویرایشگرهای متن مختلف نگاه کرد و اشاره کرد که پایانه ها در این زمینه ممکن است کندتر از سریع ترین ویرایشگرهای متن باشند. این اشاره بود که در نهایت باعث شد آزمایش های خودم را اجرا کنم و این مقاله را بنویسم.
اما تأخیر چیست و چرا اینقدر مهم است؟ فاتین در مقاله خود آن را به عنوان "تأخیر بین فشار دادن یک کلید و به روز رسانی صفحه مربوطه" تعریف کرد و نقل کرد. ، که بیان می کند: "تأخیر در بازخورد بصری در صفحه نمایش رایانه تأثیر مهمی بر رفتار و رضایت تایپیست دارد."
فاتین توضیح می‌دهد که این پینگ پیامدهای عمیق‌تری نسبت به رضایت دارد: «تایپ کردن کندتر می‌شود، خطاهای بیشتری رخ می‌دهد و تنش چشم و ماهیچه‌ها افزایش می‌یابد». به عبارت دیگر، تاخیر زیاد می تواند منجر به اشتباهات املایی و همچنین کیفیت کد پایین تر شود، زیرا منجر به بار شناختی اضافی بر روی مغز می شود. اما بدتر این است که پینگ "فشار چشم و عضله را افزایش می دهد" که به نظر می رسد دلالت بر آن دارد در آینده (ظاهراً منظور نویسنده مشکلات عضلات چشم، پشت، بازوها و البته بینایی - تقریباً. مسیر) به دلیل استرس مکرر.
برخی از این اثرات برای مدت طولانی شناخته شده است، و نتایج که در سال 1976 در مجله Ergonomics منتشر شد، گفت که تأخیر 100 میلی ثانیه ای "به طور قابل توجهی سرعت تایپ را مختل می کند." اخیراً راهنمای کاربر GNOME معرفی شده است در 10 میلی ثانیه، و اگر جلوتر بروید، پس نشان می دهد که 1 میلی ثانیه ایده آل است.
فاتین آزمایش های خود را بر روی ویرایشگرهای متن انجام داد. او یک ابزار قابل حمل به نام ، که من برای آزمایش پینگ در شبیه سازهای ترمینال استفاده می کردم. به خاطر داشته باشید که این آزمایش در حالت شبیه سازی انجام شده است: در واقعیت ، ما باید هر دو ورودی (صفحه کلید ، کنترل کننده USB و غیره) و خروجی (بافر کارت ویدیو ، مانیتور) را در نظر بگیریم. به گفته فاتین ، در تنظیمات معمولی حدود 20 میلی ثانیه است. اگر تجهیزات بازی دارید ، می توانید فقط در 3 میلی ثانیه به این رقم برسید. از آنجا که ما قبلاً چنین سخت افزاری سریع داریم ، برنامه لازم نیست تأخیر خود را اضافه کند. هدف فاتین این است که تأخیر برنامه را به 1 میلی ثانیه برساند ، یا حتی بدون دستیابی به شماره گیری همانطور که در .
در اینجا نتایج اندازه گیری های من و همچنین برخی از نتایج فاتین آمده است تا نشان دهم آزمایش من با آزمایش های او مطابقت دارد:
اولین چیزی که نظر من را جلب کرد زمان پاسخگویی بهتر برنامه های قدیمی تر مانند xterm و mlterm بود. با بدترین تأخیر ثبت (2,4 میلی ثانیه)، آنها بهتر از سریع ترین ترمینال مدرن (10,6 میلی ثانیه برای st) عمل کردند. هیچ ترمینال مدرنی کمتر از آستانه 10 میلی ثانیه ای نیست. به طور خاص، Alacritty نتوانست ادعای "سریع ترین شبیه ساز ترمینال موجود" را برآورده کند، اگرچه امتیازات آن از اولین بررسی در سال 2017 بهبود یافته است. در واقع، نویسندگان پروژه و در حال تلاش برای بهبود نمایشگر هستند. همچنین لازم به ذکر است که Vim با استفاده از GTK3 یک مرتبه کندتر از همتای GTK2 خود است. از این طریق می توان نتیجه گرفت که GTK3 تأخیر اضافی ایجاد می کند ، و این در تمام پایانه های دیگر که از آن استفاده می کنند منعکس می شود (Terminator ، ترمینال XFCE4 و ترمینال GNOME).
با این حال، تفاوت ها ممکن است برای چشم قابل توجه نباشد. همانطور که فاتین توضیح می دهد، "شما نباید از تاخیر آگاه باشید تا روی شما تاثیر بگذارد." فاتین همچنین در مورد انحراف معیار هشدار می دهد: "هر گونه اختلال در تاخیر (جتر) به دلیل غیرقابل پیش بینی بودن آنها استرس بیشتری ایجاد می کند."
نمودار بالا روی دبیان 9 خالص (کشش) با . این محیط بهترین نتایج را در تست های تاخیر ایجاد می کند. همانطور که مشخص است، GNOME یک پینگ اضافی 20 میلی ثانیه برای همه اندازه گیری ها ایجاد می کند. توضیح احتمالی برای این وجود برنامه هایی با پردازش همزمان رویدادهای ورودی است. فاتین برای چنین موردی مثال می زند ، که با پردازش همزمان همه رویدادهای ورودی تاخیر اضافه می کند. به طور پیش فرض، گنوم با یک مدیر پنجره نیز همراه است ، که یک لایه اضافی از بافر ایجاد می کند که بر پینگ تأثیر می گذارد و حداقل 8 میلی ثانیه تأخیر اضافه می کند.
سرعت اسکرول
تست بعدی یک تست سنتی "سرعت" یا "پهنای باند" است که میزان سرعتی را که ترمینال می تواند یک صفحه را در حین نمایش مقادیر زیادی متن روی صفحه نمایش دهد، اندازه گیری می کند. مکانیک آزمون متفاوت است. آزمایش اولیه این بود که به سادگی همان رشته متنی را با استفاده از دستور seq تولید کند. تست های دیگر عبارتند از تست توماس ای دیکی (xterm نگهدارنده) که به طور مکرر انجام می شود . در بررسی دیگری از عملکرد ترمینال از یک رشته رمزگذاری شده base32 از بایت های تصادفی استفاده می کند که با استفاده از cat به ترمینال خروجی می شود. لو چنین آزمایشی را "به اندازه ای که می توان تصور کرد یک معیار بی فایده" می داند و به جای آن استفاده از پاسخ پایانی را به عنوان معیار اولیه پیشنهاد می کند. دیکی همچنین آزمایش خود را گمراه کننده می نامد. با این حال، هر دو نویسنده اذعان دارند که پهنای باند پنجره ترمینال می تواند مشکل ساز باشد. لو متوجه انجماد Emacs Eshell هنگام نمایش فایل‌های بزرگ شد، و Dickey ترمینال را بهینه‌سازی کرد تا از کندی بصری xtrerm خلاص شود. بنابراین هنوز امتیازاتی برای این تست وجود دارد، اما از آنجایی که فرآیند رندرینگ از ترمینال به ترمینال بسیار متفاوت است، می‌توان از آن به عنوان یک مؤلفه آزمایشی برای آزمایش سایر پارامترها نیز استفاده کرد.
در اینجا شاهد جلو افتادن rxvt و st از رقبا هستیم و به دنبال آن Alacritty بسیار جدیدتر است که با تمرکز بر عملکرد طراحی شده است. Xfce (خانواده VTE) و کنسول بعدی هستند که تقریباً دو برابر سریعتر هستند. آخرین xterm است که پنج برابر کندتر از rxvt است. در طول تست، xterm نیز موج‌های زیادی داشت و عبور متن را دشوار می‌کرد، حتی اگر همان خط باشد. کنسول سریع بود، اما گاهی اوقات دشوار بود: صفحه نمایش هر از گاهی یخ می زد، متن جزئی را نشان می داد یا اصلاً نشان نمی داد. پایانه های دیگر رشته ها را به وضوح نشان می دهند، از جمله st، Alacritty، و rxvt.
دیکی توضیح می دهد که تفاوت عملکرد به دلیل طراحی بافرهای اسکرول در پایانه های مختلف است. به ویژه، او rxvt و سایر پایانه ها را به "عدم رعایت قوانین کلی" متهم می کند:
برخلاف xterm، rxvt تلاشی برای نمایش همه به‌روزرسانی‌ها نداشت. اگر عقب بیفتد، از برخی به روز رسانی ها خودداری می کند. این تأثیر بیشتری بر سرعت پیمایش ظاهری نسبت به سازماندهی حافظه داخلی داشت. یک اشکال این بود که انیمیشن ASCII تا حدودی نادقیق بود."
برای رفع این کندی درک شده xterm، دیکی استفاده از منبع را پیشنهاد می کند ، به xterm اجازه می دهد تا برخی از به روز رسانی های صفحه را کنار بگذارد تا با جریان همگام شود. آزمایشات من تأیید می کند که fastScroll عملکرد را بهبود می بخشد و xterm را با rxvt همتراز می کند. با این حال، همانطور که خود دیکی توضیح می دهد، این یک عصای زیر بغل نسبتاً خشن است: "بعضی اوقات xterm - مانند کنسول - به نظر می رسد که در انتظار مجموعه جدیدی از به روز رسانی های صفحه نمایش پس از حذف برخی از آنها متوقف می شود." در این راستا، به نظر می رسد که پایانه های دیگر بهترین سازش را بین سرعت و یکپارچگی نمایشگر پیدا کرده اند.
مصرف منابع
صرف نظر از این که آیا در نظر گرفتن سرعت پیمایش به عنوان یک متریک عملکرد منطقی است ، این آزمایش به ما امکان می دهد بار را روی پایانه ها شبیه سازی کنیم ، که به نوبه خود به ما امکان می دهد پارامترهای دیگر مانند حافظه یا استفاده از دیسک را اندازه گیری کنیم. معیارها با اجرای آزمون مشخص شده به دست آمد SEQ تحت نظارت بر فرآیند پایتون او داده های متر را جمع آوری کرد برای 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 بیتی انجام شده است. در LCA 2012 Rusty Russell ، که دلایل ظریف بسیاری وجود دارد که می تواند افزایش مصرف حافظه را توضیح دهد. با این حال، ما اکنون در زمانی زندگی می کنیم که گیگابایت حافظه داریم، بنابراین به نحوی مدیریت خواهیم کرد.
با این حال، نمی‌توانم احساس کنم که تخصیص حافظه بیشتر به چیزی اساسی مانند ترمینال، اتلاف منابع است. این برنامه‌ها باید کوچک‌ترین از کوچک‌ترین‌ها باشند، باید بتوانند روی هر «جعبه» اجرا شوند، حتی یک جعبه کفش، اگر به نقطه‌ای برسیم که باید به سیستم‌های لینوکس مجهز شوند (و می‌دانید که اینطور خواهد بود. ) . اما با این اعداد، استفاده از حافظه در آینده در هر محیطی که دارای ترمینال‌های متعددی است، به جز تعدادی از سبک‌ترین و محدودترین ترمینال‌ها، به یک مشکل تبدیل خواهد شد. برای جبران این موضوع، ترمینال گنوم، کنسول، urxvt، ترمیناتور و ترمینال Xfce دارای یک حالت Daemon هستند که به شما امکان می دهد چندین ترمینال را از طریق یک فرآیند واحد کنترل کنید و مصرف حافظه آنها را محدود کنید.
در طول آزمایش‌هایم، به نتیجه غیرمنتظره دیگری در مورد خواندن و نوشتن دیسک رسیدم: انتظار داشتم اصلاً چیزی در اینجا نبینم، اما معلوم شد که برخی از پایانه‌ها حجیم‌ترین داده‌ها را روی دیسک می‌نویسند. بنابراین، کتابخانه VTE در واقع یک بافر اسکرول را روی دیسک نگه می دارد (این ویژگی ، و این هنوز هم در حال وقوع است). اما بر خلاف پیاده سازی های قدیمی، اکنون حداقل این داده ها با استفاده از AES256 GCM رمزگذاری می شوند.). اما یک سوال منطقی مطرح می شود: چه چیزی در مورد کتابخانه VTE آنقدر خاص است که به چنین رویکرد غیر استانداردی برای پیاده سازی نیاز دارد ...
نتیجه
در قسمت اول مقاله متوجه شدیم که پایانه‌های مبتنی بر VTE مجموعه‌ای از ویژگی‌های خوبی دارند، اما اکنون می‌بینیم که این امر با برخی هزینه‌های عملکرد همراه است. اکنون حافظه مشکلی نیست زیرا تمام پایانه های VTE را می توان از طریق یک فرآیند Daemon کنترل کرد که اشتهای آنها را محدود می کند. با این حال، سیستم‌های قدیمی‌تری که محدودیت‌های فیزیکی در مقدار RAM و بافرهای هسته دارند، ممکن است همچنان به نسخه‌های قبلی ترمینال‌ها نیاز داشته باشند، زیرا آنها منابع بسیار کمتری را مصرف می‌کنند. اگرچه پایانه‌های VTE در تست‌های توان عملیاتی (پیمایش) عملکرد خوبی داشتند، اما تأخیر نمایش آنها بالاتر از آستانه تعیین‌شده در راهنمای کاربر GNOME است. توسعه دهندگان VTE احتمالاً باید این را در نظر بگیرند. اگر در نظر بگیریم که حتی برای کاربران تازه کار لینوکس نیز مواجهه با ترمینال اجتناب ناپذیر است، می توانند آن را کاربر پسندتر کنند. برای گیک‌های با تجربه، تغییر از ترمینال پیش‌فرض حتی ممکن است به معنای کاهش فشار چشم و توانایی جلوگیری از آسیب‌ها و بیماری‌های مرتبط با کار در آینده به دلیل جلسات کاری طولانی باشد. متأسفانه فقط xterm و mlterm قدیمی ما را به آستانه پینگ جادویی 10 میلی ثانیه می رساند که برای بسیاری غیرقابل قبول است.
اندازه‌گیری‌های بنچمارک همچنین نشان داد که با توجه به توسعه محیط‌های گرافیکی لینوکس، توسعه‌دهندگان مجبور به انجام تعدادی مصالحه شدند. برخی از کاربران ممکن است بخواهند به مدیران پنجره معمولی نگاه کنند زیرا آنها کاهش قابل توجهی پینگ را ارائه می دهند. متأسفانه ، اندازه گیری تأخیر برای Wayland امکان پذیر نبود: برنامه Typometer که من استفاده کردم برای آنچه Wayland برای جلوگیری از: جاسوسی از پنجره های دیگر طراحی شده است ، ایجاد شده است. امیدوارم که آهنگسازی Wayland عملکرد بهتری نسبت به X.org داشته باشد ، و همچنین امیدوارم که در آینده کسی راهی برای اندازه گیری تأخیر در این محیط پیدا کند.
منبع: www.habr.com