סקירה כללית של אמולטורים מסוף

כמה מילים מלשכת התרגום שלנו: בדרך כלל כולם שואפים לתרגם את החומרים והפרסומים העדכניים ביותר, ואנחנו לא יוצאי דופן. אבל מסופים זה לא משהו שמתעדכן פעם בשבוע. לכן, תרגמנו עבורכם מאמר מאת אנטואן בופר, שפורסם באביב 2018: למרות "גילו" ניכר בסטנדרטים מודרניים, לדעתנו, החומר כלל לא איבד מהרלוונטיות שלו. בנוסף, זו הייתה במקור סדרה של שני מאמרים, אבל החלטנו לשלב אותם לפוסט אחד גדול.

לטרמינלים יש מקום מיוחד בהיסטוריית המחשבים, אך בעשורים האחרונים הם נאלצו לשרוד לצד שורת הפקודה כאשר ממשקים גרפיים הופכים לכל מקום. אמולטורים מסוף החליפו את שלהם אחים חומרה, שבתורם, היו שינוי של מערכות המבוססות על כרטיסי אגרוף ומתגים. הפצות מודרניות מגיעות עם מגוון אמולטורים מסוף מכל הצורות והצבעים. ולמרות שרבים מסתפקים במסוף הסטנדרטי שמספק סביבת העבודה שלהם, חלקם משתמשים בגאווה בתוכנה אקזוטית ממש כדי להפעיל את המעטפת או עורך הטקסט המועדף עליהם. אבל, כפי שנראה ממאמר זה, לא כל המסופים נוצרו באותה תמונה: הם שונים מאוד בפונקציונליות, בגודל ובביצועים.

לחלק מהטרמינלים יש חורי אבטחה מפתיעים לחלוטין, ובנוסף לרובם יש סט פונקציות שונה לחלוטין, מתמיכה בממשק עם כרטיסיות ועד סקריפטים. למרות שאנחנו הסתכל על אמולטורים מסוף בעבר הרחוק, מאמר זה הוא עדכון של החומר הקודם שיעזור לקוראים לקבוע באיזה מסוף להשתמש ב-2018. החצי הראשון של המאמר משווה תכונות, והחצי השני מעריך ביצועים.

להלן המסופים שבדקתי:

ייתכן שאלו לא הגירסאות העדכניות ביותר, מכיוון שהייתי מוגבל לגירסאות יציבות בזמן הכתיבה, אותן הצלחתי להפיץ ב-Debian 9 או Fedora 27. היוצא מן הכלל היחיד הוא Alacritty. הוא צאצא של מסופים מואצים ב-GPU והוא כתוב בשפה יוצאת דופן וחדשה למשימה זו - Rust. לא כללתי מסופי אינטרנט מהסקירה שלי (כולל אלה שעל אֶלֶקטרוֹן), מכיוון שבדיקות ראשוניות הראו את הביצועים הגרועים ביותר שלהם.

תמיכה ביוניקוד

התחלתי את הבדיקות שלי עם תמיכת Unicode. המבחן הראשון של המסופים היה להציג את מחרוזת Unicode מ מאמרים בוויקיפדיה: “é, Δ, И, ק, م, ๗, あ, 叶, 葉 and 말.” בדיקה פשוטה זו מראה אם ​​הטרמינל יכול לפעול כהלכה ברחבי העולם. מסוף xterm אינו מציג תו ערבי ממ בתצורת ברירת מחדל:

כברירת מחדל, xterm משתמש בגופן הקלאסי "קבוע", שלפי עדיין אותה ויקי, יש "כיסוי משמעותי של Unicode מאז 1997". קורה בפונט הזה משהו שגורם לדמות להופיע כמסגרת ריקה ורק כשהגופן גדל ל-20+ נקודות התו מתחיל סוף סוף להופיע בצורה נכונה. עם זאת, "תיקון" זה שובר את התצוגה של תווי Unicode אחרים:

צילומי מסך אלה צולמו ב-Fedora 27, מכיוון שהוא נתן תוצאות טובות יותר מדביאן 9, שבה כמה גרסאות ישנות יותר של מסופים (במיוחד mlterm) לא יכלו להתמודד עם גופנים כראוי. למרבה המזל זה תוקן בגרסאות מאוחרות יותר.

כעת שימו לב כיצד השורה מוצגת ב-xterm. מסתבר שהסמל מם והשמי הבא qoph עיין בסקריפטים בסגנון RTL (מימין לשמאל), אז מבחינה טכנית הם צריכים להיות מוצגים מימין לשמאל. דפדפני אינטרנט כגון Firefox 57 מטפלים בשורה שלמעלה בצורה נכונה. גרסה פשוטה יותר של טקסט RTL היא המילה "שרה" בעברית (שרה). דף ויקי על טקסטים דו-כיווניים אומר את הדברים הבאים:

"תוכנות מחשב רבות אינן יכולות להציג טקסט דו-כיווני בצורה נכונה. לדוגמה, השם העברי "שרה" מורכב מהתווים sin (ש) (שמופיע מימין), אחר כך רש (ר) ולבסוף הוא (ה) (שאמור להופיע משמאל)."

מסופים רבים נכשלים במבחן זה: מסופי Alacritty, Gnome ו-XFCE שמקורם ב-VTE, urxvt, st ו-xterm מציגים את "Sara" בסדר הפוך, כאילו כתבנו את השם כ"Aras".

בעיה נוספת עם טקסטים דו-כיווניים היא שהם צריכים להיות מיושרים איכשהו, במיוחד כשמדובר בערבוב של טקסטים 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 (אותו Bash), צריך קובץ ~/.inputrc:

set enable-bracketed-paste on

למרבה הצער, אתר הבדיקה של הורן מראה גם כיצד לעקוף את ההגנה הזו דרך עיצוב הטקסט עצמו ובסופו של דבר להחיל עליו מצב סוגריים בטרם עת. זה עובד מכיוון שחלק מהטרמינלים לא מסננים כראוי רצפי בריחה לפני שהם מוסיפים משלהם. לדוגמה, בשלי מעולם לא הצלחתי להשלים בהצלחה את בדיקות הקונסול אפילו עם התצורה הנכונה .inputrc קוֹבֶץ. משמעות הדבר היא שאתה יכול בקלות לגרום לפגיעה בתצורת המערכת שלך עקב יישום שאינו נתמך או מעטפת מוגדרת שגויה. זה מסוכן במיוחד בעת כניסה לשרתים מרוחקים, שבהם עבודת תצורה קפדנית פחות נפוצה, במיוחד אם יש לך הרבה מכונות מרוחקות כאלה.

פתרון טוב לבעיה זו הוא תוסף אישור ההדבקה למסוף urxvt, שפשוט מבקש רשות להכניס כל טקסט שמכיל שורות חדשות. לא מצאתי אפשרות בטוחה יותר להתקפת הטקסט שתוארה על ידי הורן.

כרטיסיות ופרופילים

תכונה פופולרית כעת היא תמיכה בממשק עם כרטיסיות, אותו נגדיר כחלון מסוף אחד המכיל עוד מספר מסופים. פונקציה זו שונה עבור טרמינלים שונים, ולמרות שמסופי xterm מסורתיים אינם תומכים כלל בכרטיסיות, לגלגולי טרמינלים מודרניים יותר כגון Xfce Terminal, GNOME Terminal ו-Konsole יש את הפונקציה הזו. Urxvt תומך גם בכרטיסיות, אבל רק אם אתה משתמש בתוסף. אבל מבחינת תמיכת הכרטיסיות עצמה, Terminator הוא המנהיג הבלתי מעורער: הוא לא רק תומך בכרטיסיות, אלא גם יכול לסדר טרמינלים בכל סדר (ראה תמונה למטה).

תכונה נוספת של Terminator היא היכולת "לקבץ" את הכרטיסיות הללו יחד ולשלוח את אותן הקשות מקשים למספר מסופים בו זמנית, מה שמספק כלי גס לביצוע פעולות בכמות גדולה במספר שרתים בו זמנית. תכונה דומה מיושמת גם בקונסולה. כדי להשתמש בתכונה זו במסופים אחרים, עליך להשתמש בתוכנות של צד שלישי כגון אשכול SSH, xlax או tmux.

כרטיסיות עובדות טוב במיוחד כשהן משולבות עם פרופילים: לדוגמה, תוכל לקבל כרטיסייה אחת לדוא"ל, לשונית אחרת לצ'אט וכן הלאה. זה נתמך היטב על ידי טרמינל קונסול ומסוף GNOME. שניהם מאפשרים לכל כרטיסייה להפעיל אוטומטית פרופיל משלה. Terminator תומך גם בפרופילים, אבל לא הצלחתי למצוא דרך להפעיל אוטומטית תוכניות מסוימות כשאתה פותח כרטיסייה ספציפית. לטרמינלים אחרים אין כלל את המושג "פרופיל".

סלסולים

הדבר האחרון שאכסה בחלק הראשון של מאמר זה הוא המראה של הטרמינלים. לדוגמה GNOME, Xfce ו-urxvt תומכים בשקיפות, אך לאחרונה הפסיקו את התמיכה בתמונות רקע, מה שאילץ חלק מהמשתמשים לעבור למסוף טיליקס. אישית, אני מרוצה ממנו וזה פשוט מקורות X, אשר מגדיר את ערכת הבסיס של צבעי הרקע עבור urxvt. עם זאת, ערכות נושא צבע לא סטנדרטיות יכולות גם ליצור בעיות. לדוגמה, סולארי לא עובד עם יישומים Htop и IPTraf, מכיוון שהם כבר משתמשים בצבעים משלהם.

מסוף VT100 מקורי לא תמך בצבעים, וחדשים היו מוגבלים לעתים קרובות ללוח של 256 צבעים. עבור משתמשים מתקדמים שמעצבים את הטרמינלים שלהם, הנחיות מעטפת או שורת סטטוס בדרכים מורכבות יכולות להוות מגבלה מעצבנת. גיסט מסלולים שבהם מסופים יש תמיכה ב-"True Color". הבדיקות שלי מאשרות שמסופים מבוססי st, Alacritty ו-VTE תומכים בצורה מושלמת ב-True Color. מסופים אחרים אינם מצליחים במיוחד בהקשר זה, ולמעשה, אפילו אינם מציגים 256 צבעים. למטה תוכלו לראות את ההבדל בין תמיכת True Color במסופי GNOME, st ו-xterm, שעושים עבודה טובה עם פלטת הצבעים 256 שלהם, לבין urxvt, שלא רק נכשלת במבחן, אלא אפילו מציגה כמה תווים מהבהבים במקום אותם.

מסופים מסוימים מנתחים גם טקסט עבור דפוסי כתובות אתרים כדי להפוך קישורים לניתנים ללחוץ. זה חל על כל המסופים שמקורם ב-VTE, בעוד ש-urxvt דורש תוסף מיוחד שישנה כתובות אתרים בלחיצה או באמצעות קיצור מקלדת. מסופים אחרים בדקתי כתובות אתרים לתצוגה בדרכים אחרות.

לבסוף, מגמה חדשה במסופים היא האופציונליות של מאגר הגלילה. לדוגמה, ל-st אין מאגר גלילה; ההנחה היא שהמשתמש ישתמש במרבב טרמינלי כמו tmux ו מסך GNU.

ל-Alacritty חסרים גם מאגרי גלילה לאחור, אבל יתווסף בקרוב התמיכה שלה עקב "משוב נרחב" על נושא זה ממשתמשים. חוץ מהמתקדמים האלה, כל מסוף שבדקתי שיכולתי למצוא תומך בגלילה הפוכה.

תוצאות משנה

בחלק השני של החומר (במקור היו אלה שני מאמרים שונים - בערך. נתיב) נשווה ביצועים, שימוש בזיכרון והשהייה. אבל אנחנו כבר יכולים לראות שלחלק מהטרמינלים המדוברים יש חסרונות רציניים. לדוגמה, משתמשים שעובדים באופן קבוע עם סקריפטים של RTL עשויים לרצות לשקול mlterm ו-pterm, מכיוון שהם טובים יותר בטיפול במשימות דומות מאחרות. גם קונסולה תפקדה היטב. משתמשים שאינם עובדים עם סקריפטים של RTL עשויים לבחור משהו אחר.

מבחינת הגנה מפני החדרת קוד זדוני, urxvt בולטת בגלל היישום המיוחד שלה של הגנה מפני התקפה מסוג זה, מה שנראה לי בהחלט נוח. למי שמחפש כמה פעמונים ושריקות, קונסולה שווה מבט. לבסוף, ראוי לציין ש-VTE מהווה בסיס מצוין למסופים, המבטיח תמיכה בצבע, זיהוי כתובת URL וכדומה. במבט ראשון, מסוף ברירת המחדל שמגיע עם הסביבה המועדפת עליך עשוי לענות על כל הדרישות, אבל נשאיר את השאלה הזו פתוחה עד שנבין את הביצועים.

אנחנו ממשיכים בשיחה

באופן כללי, הביצועים של מסופים בפני עצמם עשויים להיראות כמו בעיה מופרכת, אבל כפי שמתברר, חלק מהם מציגים חביון גבוה באופן מפתיע עבור תוכנות מסוג כה בסיסי. כמו כן, בהמשך נסתכל על מה שנקרא באופן מסורתי "מהירות" (למעשה, זו מהירות הגלילה) וצריכת הזיכרון של הטרמינל (עם הסתייגות שזה לא קריטי היום כפי שהיה לפני עשרות שנים).

העיכוב

לאחר מחקר מעמיק של ביצועים סופניים, הגעתי למסקנה שהפרמטר החשוב ביותר בהקשר זה הוא ה-latency (ping). במאמר שלו "אנחנו מדפיסים בהנאה" פאבל פאטין בחן את ההשהיה של עורכי טקסט שונים ורמז שהטרמינלים בהקשר זה עשויים להיות איטיים יותר מעורכי הטקסט המהירים ביותר. הרמז הזה הוא שבסופו של דבר הוביל אותי להריץ את המבחנים שלי ולכתוב את המאמר הזה.

אבל מה זה חביון, ולמה זה כל כך חשוב? במאמרו הגדיר זאת פאטין כ"ההשהיה בין לחיצה על מקש לעדכון המסך המתאים" וציטט "מדריך לאינטראקציה בין אדם למחשב", אשר קובע: "העיכוב במשוב חזותי על תצוגת מחשב משפיע חשוב על התנהגות הקלדנית ושביעות הרצון."

פאטין מסביר שלפינג הזה יש השלכות עמוקות יותר מסתם שביעות רצון: "ההקלדה נעשית איטית יותר, יותר שגיאות מתרחשות, ומתח העיניים והשרירים גדל." במילים אחרות, עיכוב גדול יכול להוביל לשגיאות הקלדה וגם לאיכות קוד נמוכה יותר, שכן הוא מוביל לעומס קוגניטיבי נוסף על המוח. אבל מה שגרוע יותר הוא שהפינג "מגביר את המאמץ של העיניים והשרירים", מה שנראה מרמז התפתחות פציעות עבודה בעתיד (ככל הנראה, המחבר מתכוון לבעיות בשרירי העיניים, הגב, הידיים וכמובן הראייה - בערך. נתיב) עקב מתח חוזר.

חלק מההשפעות הללו ידועות כבר זמן רב, והתוצאות מחקר, שפורסם עוד ב-1976 בכתב העת Ergonomics, אמר כי עיכוב של 100 אלפיות השנייה "פוגע באופן משמעותי במהירות ההקלדה". לאחרונה, הוצג מדריך למשתמש של GNOME זמן תגובה מקובל תוך 10 אלפיות שניות, ואם אתה הולך רחוק יותר, אז מחקר של מיקרוסופט מראה ש-1 אלפית השנייה היא אידיאלית.

פאטין ערך את הבדיקות שלו על עורכי טקסט; הוא יצר מכשיר נייד בשם טיפומטר, שבו השתמשתי כדי לבדוק פינג באמולטורים מסוף. זכור כי הבדיקה נערכה במצב סימולציה: במציאות, עלינו לקחת בחשבון גם כניסת קלט (מקלדת, בקר USB וכו') וגם פלט (מאגר כרטיס מסך, צג). לפי Fatin, בתצורות טיפוסיות זה בערך 20 אלפיות השנייה. אם יש לך ציוד משחקים, אתה יכול להשיג את הנתון הזה תוך 3 אלפיות שניות בלבד. מכיוון שכבר יש לנו חומרה מהירה כל כך, האפליקציה לא חייבת להוסיף חביון משלה. המטרה של Fatin היא להביא את זמן האחזור של האפליקציה ל-1 אלפית שנייה, או אפילו להשיג חיוג ללא עיכוב מדיד, איך ב IntelliJ IDEA 15.

להלן התוצאות של המדידות שלי, כמו גם כמה מהתוצאות של Fatin, כדי להראות שהניסוי שלי מתאים לבדיקות שלו:

הדבר הראשון שהדהים אותי היה זמן התגובה הטוב יותר של תוכניות ישנות יותר כמו xterm ו-mlterm. עם חביון הרישום הגרוע ביותר (2,4 אלפיות השנייה), הם ביצעו טוב יותר מהטרמינל המודרני המהיר ביותר (10,6 אלפיות השנייה עבור st). אף טרמינל מודרני לא נופל מתחת לסף של 10 אלפיות השנייה. במיוחד, Alacritty לא מצליחה לעמוד בטענת "אמולטור המסוף המהיר ביותר שקיים", למרות שהציונים שלה השתפרו מאז הסקירה הראשונה שלה ב-2017. אכן, מחברי הפרויקט מודעים למצב ופועלים לשיפור התצוגה. יש לציין גם ש-Vim שמשתמש ב-GTK3 הוא איטי בסדר גודל ממקבילה ב-GTK2. מכאן נוכל להסיק ש-GTK3 יוצר חביון נוסף, וזה בא לידי ביטוי בכל שאר המסופים שמשתמשים בו (Terminator, Xfce4 Terminal ו-GNOME Terminal).

עם זאת, ייתכן שההבדלים לא יהיו מורגשים לעין. כפי שפאטין מסביר, "אתה לא צריך להיות מודע לעיכוב כדי שזה ישפיע עליך." פטין גם מזהיר מפני סטיית תקן: "כל הפרעות בהשהיה (ריצוד) יוצרות לחץ נוסף בשל חוסר הניבוי שלהן".

הגרף למעלה צולם על דביאן 9 טהור (מתיחה) עם מנהל חלונות i3. סביבה זו מפיקה את התוצאות הטובות ביותר במבחני חביון. כפי שמתברר, GNOME יוצר פינג נוסף של 20 ms עבור כל המדידות. הסבר אפשרי לכך הוא נוכחותן של תוכניות עם עיבוד סינכרוני של אירועי קלט. פטין נותן דוגמה למקרה כזה עבודה, אשר מוסיף עיכוב על ידי עיבוד כל אירועי הקלט באופן סינכרוני. כברירת מחדל, GNOME מגיע גם עם מנהל חלונות אמא, שיוצרת שכבה נוספת של חציצה, שמשפיעה על הפינג ומוסיפה לפחות 8 אלפיות שניות של חביון.

מהירות גלילה

המבחן הבא הוא מבחן "מהירות" או "רוחב פס" מסורתי, המודד כמה מהר הטרמינל יכול לגלול עמוד תוך הצגת כמויות גדולות של טקסט על המסך. המכניקה של הבדיקה משתנה; הבדיקה המקורית הייתה פשוט ליצור את אותה מחרוזת טקסט באמצעות הפקודה seq. מבחנים אחרים כוללים את המבחן של תומאס א. דיקי (משמר xterm), אשר חוזר על עצמו הורדת הקובץ terminfo.src. בסקירה נוספת של ביצועי הטרמינל דן לו משתמש במחרוזת מקודדת base32 של בתים אקראיים, המופקת למסוף באמצעות cat. Luu מחשיב מבחן כזה כ"מדד חסר תועלת כפי שניתן לדמיין" ומציע להשתמש בתגובה סופנית כמדד ראשי במקום זאת. דיקי גם מכנה את המבחן שלו מטעה. עם זאת, שני המחברים מכירים בכך שרוחב הפס של חלון המסוף יכול להוות בעיה. Luu גילה את Emacs Eshell קופא בעת הצגת קבצים גדולים, ודיקי עשה אופטימיזציה של הטרמינל כדי להיפטר מהאטיות החזותית של xtrerm. כך שעדיין יש טעם לבדיקה זו, אך מכיוון שתהליך העיבוד שונה מאוד ממסוף למסוף, הוא יכול לשמש גם כרכיב בדיקה לבדיקת פרמטרים אחרים.

כאן אנו רואים את ה-rxvt וה-st מושכים את המתחרים, ואחריו את Alacritty החדש הרבה יותר, שעוצב עם התמקדות בביצועים. הבאות הן Xfce (משפחת VTE) ו-Konsole, שהן מהירות כמעט פי שניים. האחרון הוא xterm, שהוא איטי פי חמישה מ-rxvt. במהלך המבחן, ה-xterm גם אדוות רבות, מה שהפך את העברת הטקסט לקשה לראות גם אם זה היה באותה שורה. הקונסולה הייתה מהירה, אבל היא הייתה מסובכת לפעמים: התצוגה הייתה קופאת מדי פעם, מציגה טקסט חלקי או לא מציגה אותו בכלל. טרמינלים אחרים הציגו מחרוזות בצורה ברורה, כולל st, Alacritty ו-rxvt.

דיקי מסביר שההבדלים בביצועים נובעים מהעיצוב של מאגרי גלילה במסופים שונים. בפרט, הוא מאשים את rxvt ומסופים אחרים ב"אי ציות לכללים הכלליים":

"בניגוד ל-xterm, rxvt לא ניסה להציג את כל העדכונים. אם זה יפגר, הוא יסרב לכמה עדכונים להתעדכן. הייתה לכך השפעה גדולה יותר על מהירות הגלילה הנראית לעין מאשר על ארגון הזיכרון הפנימי. חיסרון אחד היה שהאנימציה של ASCII הייתה קצת לא מדויקת."

כדי לתקן את האיטיות הנתפסת ב-xterm, דיקי מציע להשתמש במשאב fastScroll, המאפשר ל-xterm למחוק כמה עדכוני מסך כדי לעמוד בקצב. הבדיקות שלי מאשרות ש-fastScroll משפר את הביצועים ומביא את xterm בשווה ל-rxvt. עם זאת, זהו קב גס למדי, כפי שמסביר דיקי עצמו: "לפעמים נראה ש-xterm - כמו konsole - נתקע בזמן שהוא מחכה לסט חדש של עדכוני מסך לאחר שחלקם הוסרו." ברוח זו, נראה שמסופים אחרים מצאו את הפשרה הטובה ביותר בין מהירות ושלמות התצוגה.

צריכת משאבים

לא משנה אם הגיוני לשקול את מהירות הגלילה כמדד ביצועים, בדיקה זו מאפשרת לנו לדמות את העומס על המסופים, מה שבתורו מאפשר לנו למדוד פרמטרים אחרים כגון שימוש בזיכרון או בדיסק. המדדים הושגו על ידי הפעלת הבדיקה שצוינה seq תחת ניטור תהליך Python. הוא אסף נתוני מונה getrusage() עבור ru_maxrss, כמות ru_oublock и ru_inblock וטיימר פשוט.

במבחן זה, ה-ST תופס את המקום הראשון עם צריכת הזיכרון הממוצעת הנמוכה ביותר של 8 מגה-בייט, וזה לא מפתיע בהתחשב בכך שהרעיון העיקרי של העיצוב הוא פשטות. mlterm, xterm ו-rxvt צורכים קצת יותר - בערך 12 MB. תוצאה בולטת נוספת היא Alacritty, שדורשת 30 MB להפעלה. ואז יש מסופים ממשפחת VTE עם נתונים מ-40 עד 60 מגה-בייט, שזה די הרבה. ניתן להסביר צריכה זו על ידי העובדה שמסופים אלה משתמשים בספריות ברמה גבוהה יותר, למשל, GTK. Konsole מגיעה למקום האחרון עם צריכת זיכרון עצומה של 65MB במהלך בדיקות, אם כי ניתן להצדיק זאת על ידי מגוון רחב מאוד של תכונות.

בהשוואה לתוצאות קודמות שהושגו לפני עשר שנים, כל התוכניות החלו לצרוך יותר זיכרון באופן ניכר. Xterm נדרש בעבר ל-4 מגה-בייט, אך כעת הוא דורש 15 מגה-בייט רק בעת ההפעלה. יש עלייה דומה בצריכה עבור rxvt, שדורשת כעת 16 מגה-בייט מחוץ לקופסה. מסוף Xfce תופס 34 מגה-בייט, שהם פי שלושה מבעבר, אבל מסוף GNOME דורש רק 20 מגה-בייט. כמובן, כל הבדיקות הקודמות בוצעו על ארכיטקטורת 32 סיביות. ב-LCA 2012 ראסטי ראסל рассказал, שיש עוד הרבה סיבות עדינות שיכולות להסביר את העלייה בצריכת הזיכרון. אחרי שאמרנו את זה, אנחנו חיים עכשיו בתקופה שבה יש לנו ג'יגה-בייט של זיכרון, אז נסתדר איכשהו.

עם זאת, אני לא יכול שלא להרגיש שהקצאת יותר זיכרון למשהו בסיסי כמו הטרמינל היא בזבוז של משאבים. תוכניות אלו צריכות להיות הקטנות מבין הקטנות ביותר, צריכות להיות מסוגלות לרוץ על כל "קופסה", אפילו קופסת נעליים, אם אי פעם נגיע לנקודה שבה הן צריכות להיות מצוידות במערכות לינוקס (ואתה יודע שזה יהיה כך ). אבל עם המספרים האלה, השימוש בזיכרון יהפוך לבעיה בעתיד בכל סביבה שמפעילה מספר מסופים מלבד כמה מהיכולות הקלות והמוגבלות ביותר. כדי לפצות על כך, ל-GNOME Terminal, Konsole, urxvt, Terminator ו-Xfce Terminal יש מצב Daemon המאפשר לך לשלוט במספר מסופים באמצעות תהליך אחד, מה שמגביל את צריכת הזיכרון שלהם.

במהלך הבדיקות שלי, הגעתי לתוצאה בלתי צפויה נוספת לגבי קריאה-כתיבה של דיסק: ציפיתי לא לראות כאן כלום, אבל התברר שחלק מהטרמינלים כותבים את הנתונים הכי נפחיים לדיסק. אז, ספריית VTE למעשה שומרת מאגר גלילה בדיסק (תכונה זו הבחינו עוד ב-2010, וזה עדיין קורה). אבל בניגוד ליישומים ישנים יותר, כעת לפחות הנתונים הללו מוצפנים באמצעות AES256 GCM (מגרסה 0.39.2). אבל נשאלת שאלה סבירה: מה כל כך מיוחד בספריית VTE שהיא דורשת גישה כל כך לא סטנדרטית ליישום...

מסקנה

בחלק הראשון של המאמר גילינו שלטרמינלים מבוססי VTE יש סט טוב של תכונות, אבל עכשיו אנחנו רואים שזה מגיע עם כמה עלויות ביצועים. כעת הזיכרון אינו מהווה בעיה מכיוון שניתן לשלוט בכל מסופי ה-VTE באמצעות תהליך Daemon, אשר מגביל את התיאבון שלהם. עם זאת, מערכות ישנות יותר שיש להן מגבלות פיזיות על כמות זיכרון RAM ומאגרי ליבה עדיין עשויות להזדקק לגרסאות קודמות של מסופים, מכיוון שהן צורכות פחות משאבים באופן משמעותי. למרות שמסופי VTE ביצעו ביצועים טובים במבחני תפוקה (גלילה), זמן האחזור של התצוגה שלהם הוא מעל הסף שנקבע במדריך למשתמש של GNOME. מפתחי VTE כנראה צריכים לקחת זאת בחשבון. אם ניקח בחשבון שאפילו עבור משתמשי לינוקס מתחילים להיתקל במסוף הוא בלתי נמנע, הם יכולים להפוך אותו לידידותי יותר למשתמש. עבור גיקים מנוסים, מעבר ממסוף ברירת המחדל עשוי אפילו להיות פחות מאמץ בעיניים ויכולת להימנע מפציעות ומחלות הקשורות לעבודה בעתיד עקב פגישות עבודה ארוכות. לרוע המזל, רק ה-xterm וה-mlterm הישנים מביאים אותנו לסף פינג הקסם של 10 אלפיות השנייה, דבר שאינו מקובל על רבים.

מדידות בנצ'מרק הראו גם שבשל התפתחותן של סביבות גרפיות של לינוקס, מפתחים נאלצו לבצע מספר פשרות. חלק מהמשתמשים עשויים לרצות להסתכל על מנהלי חלונות רגילים מכיוון שהם מספקים הפחתת פינג משמעותית. לרוע המזל, לא ניתן היה למדוד חביון עבור Wayland: תוכנית Typometer שבה השתמשתי נוצרה עבור מה ש-Wayland נועד למנוע: ריגול אחר חלונות אחרים. אני מקווה ש-Wayland compositing מתפקד טוב יותר מ-X.org, ואני גם מקווה שבעתיד מישהו ימצא דרך למדוד חביון בסביבה הזו.

מקור: www.habr.com