ภาพรวมของเทอร์มินัลอีมูเลเตอร์

ข้อความบางส่วนจากสำนักแปลของเรา: โดยปกติแล้วทุกคนจะพยายามแปลสื่อและสิ่งตีพิมพ์ล่าสุด และเราก็ไม่มีข้อยกเว้น แต่เทอร์มินัลไม่ใช่สิ่งที่อัปเดตสัปดาห์ละครั้ง ดังนั้นเราจึงแปลบทความโดย Antoine Beaupré ซึ่งตีพิมพ์ในฤดูใบไม้ผลิปี 2018 ให้คุณ: แม้จะมี "อายุ" มากตามมาตรฐานสมัยใหม่ แต่ในความเห็นของเรา เนื้อหาก็ไม่ได้สูญเสียความเกี่ยวข้องเลย นอกจากนี้ เดิมทีนี่เป็นชุดบทความสองบทความ แต่เราตัดสินใจรวมบทความเหล่านั้นเป็นโพสต์ขนาดใหญ่เดียว

เทอร์มินัลมีส่วนพิเศษในประวัติศาสตร์คอมพิวเตอร์ แต่ในช่วงไม่กี่ทศวรรษที่ผ่านมา เทอร์มินัลถูกบังคับให้ดำรงอยู่ควบคู่ไปกับบรรทัดคำสั่ง เนื่องจากอินเทอร์เฟซแบบกราฟิกแพร่หลายมากขึ้น เทอร์มินัลอีมูเลเตอร์ แทนที่พวกเขาเอง พี่น้องฮาร์ดแวร์ซึ่งในทางกลับกันเป็นการดัดแปลงระบบโดยใช้การ์ดเจาะและสวิตช์สลับ การแจกแจงสมัยใหม่มาพร้อมกับเทอร์มินัลอีมูเลเตอร์ที่หลากหลายทุกรูปทรงและสี และในขณะที่หลายคนพอใจกับเทอร์มินัลมาตรฐานที่สภาพแวดล้อมการทำงานของตนมีให้ แต่บางคนก็ภาคภูมิใจที่ใช้ซอฟต์แวร์แปลกใหม่เพื่อรันเชลล์หรือโปรแกรมแก้ไขข้อความที่พวกเขาชื่นชอบ แต่ดังที่เราจะเห็นจากบทความนี้ ไม่ใช่ว่าเทอร์มินัลทั้งหมดจะถูกสร้างขึ้นในภาพเดียวกัน: เทอร์มินัลเหล่านี้มีความแตกต่างกันอย่างมากในด้านฟังก์ชันการทำงาน ขนาด และประสิทธิภาพ

เทอร์มินัลบางตัวมีช่องโหว่ด้านความปลอดภัยที่น่าประหลาดใจมาก และเทอร์มินัลส่วนใหญ่มีชุดฟังก์ชันที่แตกต่างไปจากเดิมอย่างสิ้นเชิง ตั้งแต่การรองรับอินเทอร์เฟซแบบแท็บไปจนถึงการเขียนสคริปต์ แม้ว่าเรา ดูเทอร์มินัลอีมูเลเตอร์ในอดีตอันไกลโพ้นบทความนี้เป็นการอัปเดตเนื้อหาก่อนหน้านี้ซึ่งจะช่วยให้ผู้อ่านพิจารณาว่าจะใช้เทอร์มินัลใดในปี 2018 ครึ่งแรกของบทความจะเปรียบเทียบคุณลักษณะต่างๆ และครึ่งหลังจะประเมินประสิทธิภาพ

นี่คือเทอร์มินัลที่ฉันตรวจสอบ:

สิ่งเหล่านี้อาจไม่ใช่เวอร์ชันล่าสุด เนื่องจากฉันถูกจำกัดไว้เฉพาะบิลด์ที่เสถียรในขณะที่เขียน ซึ่งฉันสามารถเผยแพร่บน Debian 9 หรือ Fedora 27 ได้ ข้อยกเว้นเพียงอย่างเดียวคือ Alacritty มันเป็นลูกหลานของเทอร์มินัลที่เร่งด้วย GPU และเขียนด้วยภาษาที่ไม่ธรรมดาและใหม่สำหรับงานนี้ - Rust ฉันแยกเว็บเทอร์มินัลออกจากการตรวจสอบของฉัน (รวมถึงเว็บเทอร์มินัลด้วย อิเล็กตรอน) เนื่องจากการทดสอบเบื้องต้นแสดงให้เห็นว่ามีประสิทธิภาพต่ำมาก

การสนับสนุนยูนิโค้ด

ฉันเริ่มการทดสอบด้วยการรองรับ Unicode การทดสอบครั้งแรกของเทอร์มินัลคือการแสดงสตริง Unicode จาก บทความวิกิพีเดีย: “é, Δ, И, ק, م, ๗, あ, 叶, 葉 และ 말” การทดสอบง่ายๆ นี้แสดงให้เห็นว่าเครื่องสามารถทำงานได้ทั่วโลกอย่างถูกต้องหรือไม่ เทอร์มินัล xterm ไม่แสดงอักขระอารบิก Mem ในการกำหนดค่าเริ่มต้น:

ตามค่าเริ่มต้น xterm จะใช้แบบอักษร "คงที่" แบบคลาสสิกซึ่งเป็นไปตาม วิกกี้ยังเหมือนเดิมมี "การครอบคลุม Unicode ที่สำคัญตั้งแต่ปี 1997" มีบางอย่างเกิดขึ้นในแบบอักษรนี้ซึ่งทำให้อักขระปรากฏเป็นกรอบว่าง และเมื่อแบบอักษรข้อความเพิ่มขึ้นเป็น 20+ จุดเท่านั้นที่อักขระจะเริ่มแสดงได้อย่างถูกต้องในที่สุด อย่างไรก็ตาม “การแก้ไข” นี้จะทำให้การแสดงอักขระ Unicode อื่นๆ หยุดชะงัก:

ภาพหน้าจอเหล่านี้ถ่ายใน Fedora 27 เนื่องจากให้ผลลัพธ์ที่ดีกว่า Debian 9 ซึ่งเทอร์มินัลเวอร์ชันเก่าบางเวอร์ชัน (โดยเฉพาะ mlterm) ไม่สามารถจัดการแบบอักษรได้อย่างถูกต้อง โชคดีที่ปัญหานี้ได้รับการแก้ไขแล้วในเวอร์ชันหลังๆ

ตอนนี้สังเกตว่าบรรทัดนั้นแสดงเป็น xterm อย่างไร ปรากฎว่าสัญลักษณ์ Mem และกลุ่มเซมิติกต่อไปนี้ qoph อ้างถึงสคริปต์สไตล์ RTL (จากขวาไปซ้าย) ดังนั้นในทางเทคนิคแล้ว ควรแสดงจากขวาไปซ้าย เว็บเบราว์เซอร์เช่น Firefox 57 จัดการบรรทัดด้านบนได้อย่างถูกต้อง ข้อความ RTL เวอร์ชันที่เรียบง่ายกว่าคือคำว่า "Сара" ในภาษาฮีบรู (สา). หน้า Wiki เกี่ยวกับข้อความแบบสองทิศทาง พูดว่าต่อไปนี้:

“โปรแกรมคอมพิวเตอร์จำนวนมากไม่สามารถแสดงข้อความแบบสองทิศทางได้อย่างถูกต้อง ตัวอย่างเช่น ชื่อภาษาฮีบรู "ซาราห์" ประกอบด้วยอักขระ sin (ש) (ซึ่งปรากฏทางด้านขวา) จากนั้น resh (ר) และสุดท้ายคือเขา (ה) (ซึ่งควรปรากฏทางด้านซ้าย)"

เทอร์มินัลจำนวนมากไม่ผ่านการทดสอบนี้: เทอร์มินัล Alacritty, Gnome ที่ได้มาจาก VTE และเทอร์มินัล XFCE, urxvt, st และ xterm แสดง "Sara" ในลำดับย้อนกลับ ราวกับว่าเราเขียนชื่อเป็น "Aras"

ปัญหาอีกประการหนึ่งของข้อความแบบสองทิศทางก็คือ จำเป็นต้องจัดเรียงข้อความเหล่านั้นให้ตรงกัน โดยเฉพาะอย่างยิ่งเมื่อต้องผสมข้อความ RTL และ LTR สคริปต์ RTL ควรทำงานจากด้านขวาของหน้าต่างเทอร์มินัล แต่จะเกิดอะไรขึ้นกับเทอร์มินัลที่ใช้ค่าเริ่มต้นเป็น LTR English ส่วนใหญ่ไม่มีกลไกพิเศษใด ๆ และจัดข้อความทั้งหมดไปทางซ้าย (รวมถึงใน Konsole ด้วย) ข้อยกเว้นคือ pterm และ mlterm ซึ่งเป็นไปตามมาตรฐานและจัดบรรทัดดังกล่าวให้ชิดขวา

การป้องกันการแทรก

คุณลักษณะสำคัญถัดไปที่ฉันระบุคือการป้องกันการแทรก แม้ว่าจะเป็นที่รู้จักกันอย่างแพร่หลายว่าคาถาเช่น:

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

เป็นคำสั่งพุชการเรียกใช้โค้ด มีเพียงไม่กี่คนที่รู้ว่าคำสั่งที่ซ่อนอยู่สามารถแอบเข้าไปในคอนโซลได้เมื่อคัดลอกและวางจากเว็บเบราว์เซอร์ แม้ว่าจะตรวจสอบอย่างระมัดระวังแล้วก็ตาม เว็บไซต์ตรวจสอบ Gianna Horna แสดงให้เห็นอย่างชาญฉลาดว่าคำสั่งดูไม่เป็นอันตรายเพียงใด:

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 ต้องการการสนับสนุนจากเชลล์หรือแอปพลิเคชันที่ทำงานบนเทอร์มินัล เช่น การใช้ซอฟต์แวร์ อ่านบรรทัด GNU (Bash เดียวกัน) ต้องการไฟล์ ~/.inputrc:

set enable-bracketed-paste on

น่าเสียดายที่ไซต์ทดสอบของ Horn ยังแสดงวิธีเลี่ยงการป้องกันนี้ผ่านการจัดรูปแบบข้อความและจบลงด้วยการใช้โหมด Bracketed ก่อนเวลาอันควร วิธีนี้ใช้ได้ผลเนื่องจากเทอร์มินัลบางตัวกรองลำดับ Escape ไม่ถูกต้องก่อนที่จะเพิ่มของตัวเอง ตัวอย่างเช่น ในตัวฉัน ฉันไม่สามารถทำการทดสอบ Konsole ได้สำเร็จเลยแม้ว่าจะมีการกำหนดค่าที่ถูกต้องก็ตาม .inputrc ไฟล์. ซึ่งหมายความว่าคุณสามารถทำให้การกำหนดค่าระบบของคุณเสียหายได้อย่างง่ายดายเนื่องจากแอปพลิเคชันที่ไม่รองรับหรือเชลล์ที่กำหนดค่าไม่ถูกต้อง สิ่งนี้เป็นอันตรายอย่างยิ่งเมื่อเข้าสู่ระบบเซิร์ฟเวอร์ระยะไกล ซึ่งงานการกำหนดค่าอย่างระมัดระวังนั้นพบได้น้อย โดยเฉพาะอย่างยิ่งถ้าคุณมีเครื่องระยะไกลดังกล่าวจำนวนมาก

ทางออกที่ดีสำหรับปัญหานี้คือปลั๊กอินยืนยันการวางสำหรับเทอร์มินัล urxvtซึ่งเพียงแค่ขออนุญาตเพื่อแทรกข้อความที่มีการขึ้นบรรทัดใหม่ ฉันไม่พบตัวเลือกที่ปลอดภัยกว่านี้สำหรับการโจมตีด้วยข้อความที่ Horn อธิบายไว้

แท็บและโปรไฟล์

คุณลักษณะที่ได้รับความนิยมในขณะนี้คือการรองรับอินเทอร์เฟซแบบแท็บ ซึ่งเราจะกำหนดให้เป็นหน้าต่างเทอร์มินัลเดียวที่มีเทอร์มินัลอื่นๆ อีกหลายเทอร์มินัล ฟังก์ชันนี้จะแตกต่างกันไปในเทอร์มินัลต่างๆ และถึงแม้ว่าเทอร์มินัล xterm แบบดั้งเดิมจะไม่รองรับแท็บเลย แต่เทอร์มินัลสมัยใหม่ เช่น Xfce Terminal, GNOME Terminal และ Konsole ก็มีฟังก์ชันนี้ Urxvt รองรับแท็บด้วย แต่เฉพาะเมื่อคุณใช้ปลั๊กอินเท่านั้น แต่ในแง่ของการรองรับแท็บ Terminator เป็นผู้นำที่ไม่มีปัญหา: ไม่เพียงแต่รองรับแท็บเท่านั้น แต่ยังสามารถจัดเรียงเทอร์มินัลตามลำดับใดก็ได้ (ดูภาพด้านล่าง)

คุณสมบัติอีกประการหนึ่งของ Terminator คือความสามารถในการ "จัดกลุ่ม" แท็บเหล่านี้เข้าด้วยกัน และส่งการกดแป้นพิมพ์เดียวกันไปยังเทอร์มินัลหลายเครื่องพร้อมกัน ถือเป็นเครื่องมือดิบสำหรับการดำเนินการจำนวนมากบนเซิร์ฟเวอร์หลายเครื่องพร้อมกัน คุณลักษณะที่คล้ายกันนี้ถูกนำมาใช้ใน Konsole ด้วย หากต้องการใช้คุณสมบัตินี้ในเทอร์มินัลอื่น คุณต้องใช้ซอฟต์แวร์บุคคลที่สาม เช่น คลัสเตอร์ SSH, เอ็กซ์แอลเอ็กซ์ หรือ tmux.

แท็บต่างๆ จะทำงานได้ดีเป็นพิเศษเมื่อจับคู่กับโปรไฟล์ เช่น คุณสามารถมีแท็บหนึ่งสำหรับอีเมล อีกแท็บหนึ่งสำหรับการแชท และอื่นๆ สิ่งนี้ได้รับการสนับสนุนอย่างดีจาก Konsole Terminal และ GNOME Terminal ทั้งสองอนุญาตให้แต่ละแท็บเปิดโปรไฟล์ของตัวเองโดยอัตโนมัติ Terminator ยังรองรับโปรไฟล์ด้วย แต่ฉันไม่พบวิธีเปิดโปรแกรมบางโปรแกรมโดยอัตโนมัติเมื่อคุณเปิดแท็บใดแท็บหนึ่ง เทอร์มินัลอื่นๆ ไม่มีแนวคิดเรื่อง "โปรไฟล์" เลย

รัฟเฟิล

สิ่งสุดท้ายที่ฉันจะกล่าวถึงในส่วนแรกของบทความนี้คือรูปลักษณ์ของเทอร์มินัล ตัวอย่างเช่น GNOME, Xfce และ urxvt รองรับความโปร่งใส แต่เมื่อเร็ว ๆ นี้ ได้ยกเลิกการรองรับภาพพื้นหลัง ทำให้ผู้ใช้บางคนต้องเปลี่ยนไปใช้เทอร์มินัล Tilix. โดยส่วนตัวแล้วฉันพอใจกับมันและเรียบง่าย xresourcesซึ่งตั้งค่าชุดพื้นฐานของสีพื้นหลังสำหรับ urxvt อย่างไรก็ตาม ธีมสีที่ไม่ได้มาตรฐานก็สามารถสร้างปัญหาได้เช่นกัน ตัวอย่างเช่น, solarized ไม่ทำงาน ด้วยแอพพลิเคชั่น htop и IPtrafเนื่องจากพวกเขาใช้สีของตัวเองอยู่แล้ว

เทอร์มินอล VT100 ดั้งเดิม ไม่รองรับสี และสีใหม่มักจำกัดอยู่ที่ชุดสี 256 สี สำหรับผู้ใช้ขั้นสูงที่จัดรูปแบบเทอร์มินัล คำสั่งเชลล์หรือแถบสถานะด้วยวิธีที่ซับซ้อนอาจเป็นข้อจำกัดที่น่ารำคาญได้ ส่วนสำคัญ ติดตามว่าเทอร์มินัลใดที่รองรับ "True Color" การทดสอบของฉันยืนยันว่าเทอร์มินัลที่ใช้ st, Alacritty และ VTE รองรับ True Color ได้อย่างสมบูรณ์แบบ เทอร์มินัลอื่นๆ ทำงานได้ไม่ดีนักในเรื่องนี้ และในความเป็นจริง ไม่สามารถแสดงสีได้ 256 สีด้วยซ้ำ ด้านล่างนี้ คุณจะเห็นความแตกต่างระหว่างการรองรับ True Color ในเทอร์มินัล GNOME, st และ xterm ซึ่งทำงานได้ดีด้วยชุดสี 256 สี และ urxvt ซึ่งไม่เพียงแต่ทดสอบไม่สำเร็จ แต่ยังแสดงอักขระกะพริบแทนด้วย

เทอร์มินัลบางตัวยังวิเคราะห์ข้อความสำหรับรูปแบบ URL เพื่อให้สามารถคลิกลิงก์ได้ สิ่งนี้ใช้กับเทอร์มินัลที่ได้รับจาก VTE ทั้งหมด ในขณะที่ urxvt ต้องใช้ปลั๊กอินพิเศษที่จะแปลง URL เมื่อคลิกหรือใช้แป้นพิมพ์ลัด เทอร์มินัลอื่นๆ ที่ฉันได้ทดสอบ URL ที่แสดงด้วยวิธีอื่น

สุดท้าย เทรนด์ใหม่ในเทอร์มินัลคือทางเลือกของบัฟเฟอร์เลื่อน ตัวอย่างเช่น st ไม่มีบัฟเฟอร์การเลื่อน สันนิษฐานว่าผู้ใช้จะใช้เทอร์มินัลมัลติเพล็กเซอร์เช่น tmux และ หน้าจอ GNU.

Alacritty ยังขาดบัฟเฟอร์ย้อนกลับ แต่ จะถูกเพิ่มเร็ว ๆ นี้ การสนับสนุนเนื่องจาก "ข้อเสนอแนะอย่างกว้างขวาง" ในหัวข้อนี้จากผู้ใช้ นอกเหนือจากการเริ่มต้นใหม่เหล่านี้ ทุกเทอร์มินัลที่ฉันทดสอบพบว่าสามารถรองรับการเลื่อนแบบย้อนกลับได้

ผลรวมย่อย

ในส่วนที่สองของวัสดุ (ในต้นฉบับมีสองบทความที่แตกต่างกัน - ประมาณ เลน) เราจะเปรียบเทียบประสิทธิภาพ การใช้หน่วยความจำ และเวลาแฝง แต่เราเห็นแล้วว่าเทอร์มินัลบางตัวที่เป็นปัญหามีข้อบกพร่องร้ายแรง ตัวอย่างเช่น ผู้ใช้ที่ทำงานกับสคริปต์ RTL เป็นประจำอาจต้องการพิจารณา mlterm และ pterm เนื่องจากพวกเขาสามารถจัดการงานที่คล้ายกันได้ดีกว่าผู้อื่น คอนโซลก็เล่นได้ดีเช่นกัน ผู้ใช้ที่ไม่ทำงานกับสคริปต์ RTL อาจเลือกอย่างอื่น

ในแง่ของการป้องกันการแทรกโค้ดที่เป็นอันตราย urxvt มีความโดดเด่นเนื่องจากมีการใช้งานพิเศษในการป้องกันการโจมตีประเภทนี้ ซึ่งดูเหมือนสะดวกสำหรับฉันอย่างแน่นอน สำหรับผู้ที่มองหาสิ่งที่น่าสนใจ Konsole ก็คุ้มค่าที่จะดู สุดท้ายนี้ เป็นที่น่าสังเกตว่า VTE เป็นฐานที่ดีเยี่ยมสำหรับเทอร์มินัล ซึ่งรับประกันการรองรับสี การจดจำ URL และอื่นๆ เมื่อมองแวบแรก เทอร์มินัลเริ่มต้นที่มาพร้อมกับสภาพแวดล้อมที่คุณชื่นชอบอาจตรงตามข้อกำหนดทั้งหมด แต่เราจะปล่อยให้คำถามนี้เปิดไว้จนกว่าเราจะเข้าใจประสิทธิภาพ

เรามาสนทนากันต่อ

โดยทั่วไป ประสิทธิภาพของเทอร์มินัลในตัวมันเองอาจดูเหมือนเป็นปัญหาที่ลึกซึ้ง แต่ปรากฏว่า เทอร์มินัลบางตัวมีความหน่วงสูงอย่างน่าประหลาดใจสำหรับซอฟต์แวร์ประเภทพื้นฐานดังกล่าว ต่อไปเราจะดูสิ่งที่เรียกกันทั่วไปว่า "ความเร็ว" (อันที่จริงนี่คือความเร็วในการเลื่อน) และการใช้หน่วยความจำของเทอร์มินัล (โดยมีข้อแม้ว่าสิ่งนี้ไม่สำคัญเท่ากับเมื่อหลายสิบปีก่อน)

ความล่าช้า

หลังจากการศึกษาประสิทธิภาพของเทอร์มินัลอย่างละเอียด ฉันสรุปได้ว่าพารามิเตอร์ที่สำคัญที่สุดในเรื่องนี้คือเวลาแฝง (ping) ในบทความของเขา “เราพิมพ์ด้วยความยินดี” Pavel Fatin พิจารณาเวลาแฝงของโปรแกรมแก้ไขข้อความต่างๆ และบอกเป็นนัยว่าเทอร์มินัลในเรื่องนี้อาจช้ากว่าโปรแกรมแก้ไขข้อความที่เร็วที่สุด คำแนะนำนี้เองที่ทำให้ฉันต้องดำเนินการทดสอบและเขียนบทความนี้ในท้ายที่สุด

แต่เวลาแฝงคืออะไร และเหตุใดจึงสำคัญมาก ในบทความของเขา Fatin ให้คำจำกัดความว่าเป็น "ความล่าช้าระหว่างการกดปุ่มและการอัปเดตหน้าจอที่เกี่ยวข้อง" และยกมา “คู่มือปฏิสัมพันธ์ระหว่างมนุษย์กับคอมพิวเตอร์”ซึ่งระบุว่า: "ความล่าช้าในการตอบรับด้วยภาพบนจอแสดงผลคอมพิวเตอร์มีผลกระทบสำคัญต่อพฤติกรรมและความพึงพอใจของพนักงานพิมพ์ดีด"

Fatin อธิบายว่าการ Ping นี้มีผลกระทบที่ลึกซึ้งมากกว่าแค่ความพึงพอใจ “การพิมพ์ช้าลง เกิดข้อผิดพลาดมากขึ้น และความตึงเครียดของดวงตาและกล้ามเนื้อเพิ่มขึ้น” กล่าวอีกนัยหนึ่ง ความล่าช้าอย่างมากอาจนำไปสู่การพิมพ์ผิดและทำให้คุณภาพของโค้ดลดลง เนื่องจากจะนำไปสู่ภาระการรับรู้ในสมองเพิ่มเติม แต่สิ่งที่แย่กว่านั้นก็คือการ ping "ทำให้ดวงตาและกล้ามเนื้อตึงขึ้น" ซึ่งดูเหมือนจะบอกเป็นนัย การพัฒนาการบาดเจ็บจากการทำงาน ต่อไปในอนาคต (เห็นได้ชัดว่าผู้เขียนหมายถึงปัญหาเกี่ยวกับกล้ามเนื้อตา หลัง แขน และแน่นอน การมองเห็น - ประมาณ เลน) เนื่องจากความเครียดซ้ำๆ

ผลกระทบบางอย่างเหล่านี้ทราบกันมานานแล้วและผลลัพธ์ก็เช่นกัน การวิจัยซึ่งตีพิมพ์ย้อนกลับไปในปี 1976 ในวารสาร Ergonomics กล่าวว่าความล่าช้า 100 มิลลิวินาที "ทำให้ความเร็วในการพิมพ์ลดลงอย่างมาก" ล่าสุดได้มีการเปิดตัวคู่มือผู้ใช้ GNOME เวลาตอบสนองที่ยอมรับได้ ภายใน 10 มิลลิวินาที และถ้าคุณไปไกลกว่านี้ วิจัยไมโครซอฟท์ แสดงว่า 1 มิลลิวินาทีนั้นเหมาะสมที่สุด

Fatin ทำการทดสอบกับโปรแกรมแก้ไขข้อความ เขาได้สร้างเครื่องดนตรีพกพาที่เรียกว่า ไทโพมิเตอร์ซึ่งฉันใช้ทดสอบ ping ในเทอร์มินัลอีมูเลเตอร์ โปรดทราบว่าการทดสอบดำเนินการในโหมดจำลอง: ในความเป็นจริง เราต้องคำนึงถึงทั้งความล่าช้าของอินพุต (แป้นพิมพ์ ตัวควบคุม USB ฯลฯ) และเอาต์พุต (บัฟเฟอร์ของการ์ดวิดีโอ จอภาพ) ตามข้อมูลของ Fatin ในการกำหนดค่าทั่วไปจะใช้เวลาประมาณ 20 ms หากคุณมีอุปกรณ์เล่นเกม คุณสามารถบรรลุเป้าหมายนี้ได้ภายในเวลาเพียง 3 มิลลิวินาที เนื่องจากเรามีฮาร์ดแวร์ที่รวดเร็วเช่นนี้อยู่แล้ว แอปพลิเคชันจึงไม่จำเป็นต้องเพิ่มเวลาแฝงของตัวเอง เป้าหมายของ Fatin คือการทำให้เวลาแฝงของแอปพลิเคชันอยู่ที่ 1 มิลลิวินาที หรือแม้กระทั่งบรรลุการโทรออกโดยไม่ต้อง ความล่าช้าที่วัดได้อย่างไรใน IntelliJ IDEA 15.

นี่คือผลลัพธ์ของการวัดของฉัน รวมถึงผลลัพธ์บางส่วนของ Fatin เพื่อแสดงให้เห็นว่าการทดลองของฉันสอดคล้องกับการทดสอบของเขา:

สิ่งแรกที่ทำให้ฉันทึ่งคือเวลาตอบสนองที่ดีกว่าของโปรแกรมรุ่นเก่า เช่น xterm และ mlterm ด้วยเวลาแฝงในการลงทะเบียนที่แย่ที่สุด (2,4 ms) พวกเขาทำงานได้ดีกว่าเทอร์มินัลสมัยใหม่ที่เร็วที่สุด (10,6 ms สำหรับ st) ไม่มีเทอร์มินัลสมัยใหม่ใดที่ต่ำกว่าเกณฑ์ 10 มิลลิวินาที โดยเฉพาะอย่างยิ่ง Alacritty ไม่สามารถตอบสนองข้อเรียกร้อง "เทอร์มินัลอีมูเลเตอร์ที่เร็วที่สุดที่มีอยู่" แม้ว่าคะแนนจะดีขึ้นนับตั้งแต่การตรวจสอบครั้งแรกในปี 2017 แท้จริงแล้วผู้เขียนโครงการ ตระหนักถึงสถานการณ์ และกำลังดำเนินการปรับปรุงการแสดงผล ควรสังเกตว่า Vim ที่ใช้ GTK3 นั้นมีลำดับความสำคัญช้ากว่า GTK2 จากนี้เราสามารถสรุปได้ว่า GTK3 สร้างความหน่วงเพิ่มเติม และสิ่งนี้สะท้อนให้เห็นในเทอร์มินัลอื่นๆ ทั้งหมดที่ใช้งาน (Terminator, Xfce4 Terminal และ GNOME Terminal)

อย่างไรก็ตามความแตกต่างอาจไม่สามารถมองเห็นได้ด้วยตา ดังที่ Fatin อธิบาย “คุณไม่จำเป็นต้องตระหนักถึงความล่าช้าจึงจะส่งผลต่อคุณ” Fatin ยังเตือนเกี่ยวกับค่าเบี่ยงเบนมาตรฐาน: “การรบกวนใดๆ ในเวลาแฝง (กระวนกระวายใจ) จะทำให้เกิดความเครียดเพิ่มเติมเนื่องจากไม่สามารถคาดเดาได้”

กราฟด้านบนถ่ายบน Debian 9 ล้วนๆ (ยืด) ด้วย ตัวจัดการหน้าต่าง i3. สภาพแวดล้อมนี้ให้ผลลัพธ์ที่ดีที่สุดในการทดสอบเวลาแฝง ปรากฎว่า GNOME จะสร้าง Ping เพิ่มเติมอีก 20 มิลลิวินาทีสำหรับการวัดทั้งหมด คำอธิบายที่เป็นไปได้สำหรับสิ่งนี้คือการมีอยู่ของโปรแกรมที่มีการประมวลผลเหตุการณ์อินพุตแบบซิงโครนัส ฟาตินยกตัวอย่างสำหรับกรณีเช่นนี้ Workraveซึ่งเพิ่มความล่าช้าโดยการประมวลผลเหตุการณ์อินพุตทั้งหมดพร้อมกัน ตามค่าเริ่มต้น GNOME จะมาพร้อมกับตัวจัดการหน้าต่างด้วย พูดพึมพำซึ่งสร้างชั้นบัฟเฟอร์เพิ่มเติม ซึ่งส่งผลต่อการ 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

Dickey อธิบายว่าประสิทธิภาพที่แตกต่างกันนั้นเกิดจากการออกแบบบัฟเฟอร์การเลื่อนในเทอร์มินัลต่างๆ โดยเฉพาะอย่างยิ่งเขากล่าวหาว่า rxvt และเทอร์มินัลอื่น ๆ ของ "ไม่ปฏิบัติตามกฎทั่วไป":

“ต่างจาก xterm ตรงที่ rxvt ไม่ได้พยายามแสดงการอัปเดตทั้งหมด หากล้าหลัง ระบบจะปฏิเสธการอัปเดตบางอย่างเพื่อติดตามให้ทัน สิ่งนี้มีผลกระทบต่อความเร็วการเลื่อนที่ชัดเจนมากกว่าการจัดระเบียบหน่วยความจำภายใน ข้อเสียประการหนึ่งคือแอนิเมชั่น ASCII ค่อนข้างไม่ชัดเจน"

เพื่อแก้ไขความเฉื่อยชาของ xterm ที่รับรู้นี้ Dickey แนะนำให้ใช้ทรัพยากร รวดเร็วเลื่อนทำให้ xterm ละทิ้งการอัปเดตหน้าจอบางส่วนเพื่อให้ทันกับกระแส การทดสอบของฉันยืนยันว่า fastScroll ปรับปรุงประสิทธิภาพและทำให้ xterm ทัดเทียมกับ rxvt อย่างไรก็ตาม นี่เป็นไม้ยันที่ค่อนข้างหยาบ ดังที่ Dickey อธิบายเองว่า: "บางครั้ง xterm - เหมือน konsole - ดูเหมือนจะหยุดนิ่งเนื่องจากรอการอัปเดตหน้าจอชุดใหม่หลังจากที่บางส่วนถูกลบออกไป" ในลักษณะนี้ ดูเหมือนว่าเทอร์มินัลอื่นๆ จะพบการประนีประนอมที่ดีที่สุดระหว่างความเร็วและความสมบูรณ์ของการแสดงผล

การใช้ทรัพยากร

ไม่ว่าการพิจารณาความเร็วในการเลื่อนเป็นหน่วยวัดประสิทธิภาพจะสมเหตุสมผลหรือไม่ การทดสอบนี้ช่วยให้เราจำลองโหลดบนเทอร์มินัลได้ ซึ่งจะช่วยให้เราวัดพารามิเตอร์อื่นๆ เช่น หน่วยความจำหรือการใช้งานดิสก์ได้ เมตริกได้มาจากการรันการทดสอบที่ระบุ หมายเลข ภายใต้การตรวจสอบกระบวนการ Python เขารวบรวมข้อมูลมิเตอร์ ได้รับความเดือดร้อน() สำหรับ ru_maxrss, จำนวน ru_oublock и ru_inblock และตัวจับเวลาง่ายๆ

ในการทดสอบนี้ ST เกิดขึ้นอันดับหนึ่งโดยใช้หน่วยความจำเฉลี่ยต่ำสุดที่ 8 MB ซึ่งไม่น่าแปลกใจเมื่อพิจารณาว่าแนวคิดหลักของการออกแบบคือความเรียบง่าย mlterm, xterm และ rxvt กินพื้นที่เพิ่มอีกเล็กน้อย - ประมาณ 12 MB ผลลัพธ์ที่โดดเด่นอีกประการหนึ่งคือ Alacritty ซึ่งต้องใช้พื้นที่ 30 MB ในการทำงาน จากนั้นก็มีเทอร์มินัลตระกูล VTE ที่มีขนาดตั้งแต่ 40 ถึง 60 MB ซึ่งค่อนข้างมาก ปริมาณการใช้นี้สามารถอธิบายได้ด้วยข้อเท็จจริงที่ว่าเทอร์มินัลเหล่านี้ใช้ไลบรารีระดับที่สูงกว่า เช่น GTK Konsole มาพร้อมกับการใช้หน่วยความจำมากถึง 65MB ในระหว่างการทดสอบ แม้ว่าสิ่งนี้สามารถพิสูจน์ได้ด้วยคุณสมบัติที่หลากหลายมากก็ตาม

เมื่อเทียบกับผลลัพธ์ก่อนหน้านี้เมื่อสิบปีที่แล้ว ทุกโปรแกรมเริ่มใช้หน่วยความจำมากขึ้นอย่างเห็นได้ชัด Xterm เคยต้องการ 4 MB แต่ตอนนี้ต้องการ 15 MB เมื่อเริ่มต้นระบบ ปริมาณการใช้ rxvt เพิ่มขึ้นเช่นเดียวกัน ซึ่งตอนนี้ต้องใช้พื้นที่ 16 MB เมื่อแกะกล่อง เทอร์มินัล Xfce ใช้พื้นที่ 34 MB ซึ่งมากกว่าเดิมถึง 20 เท่า แต่เทอร์มินัล GNOME ต้องการเพียง 32 MB แน่นอนว่าการทดสอบก่อนหน้านี้ทั้งหมดดำเนินการกับสถาปัตยกรรม 2012 บิต ที่ LCA XNUMX Rusty Russell ผมบอกมีเหตุผลลึกซึ้งอีกมากมายที่สามารถอธิบายการเพิ่มขึ้นของการใช้หน่วยความจำได้ ต้องบอกว่าตอนนี้เราอยู่ในยุคที่เรามีหน่วยความจำกิกะไบต์ ดังนั้นเราจะจัดการอย่างไร

อย่างไรก็ตาม ฉันอดไม่ได้ที่จะรู้สึกว่าการจัดสรรหน่วยความจำเพิ่มเติมให้กับบางสิ่งที่เป็นพื้นฐานเนื่องจากเทอร์มินัลเป็นการสิ้นเปลืองทรัพยากร โปรแกรมเหล่านี้ควรเป็นโปรแกรมที่เล็กที่สุดควรจะสามารถทำงานบน “กล่อง” ใดก็ได้ แม้แต่กล่องรองเท้า ถ้าเรามาถึงจุดที่จำเป็นต้องติดตั้งระบบ Linux (และคุณก็รู้ว่ามันจะเป็นเช่นนั้น ) . แต่ด้วยตัวเลขเหล่านี้ การใช้หน่วยความจำจะกลายเป็นปัญหาในอนาคตในสภาพแวดล้อมใดๆ ที่ใช้เทอร์มินัลหลายเครื่อง นอกเหนือจากความสามารถที่เบาที่สุดและจำกัดที่สุดบางส่วน เพื่อชดเชยสิ่งนี้ Terminal GNOME, Konsole, urxvt, Terminator และ Xfce Terminal มีโหมด Daemon ที่ช่วยให้คุณควบคุมเทอร์มินัลหลายเครื่องผ่านกระบวนการเดียว โดยจำกัดการใช้หน่วยความจำ

ในระหว่างการทดสอบ ฉันพบผลลัพธ์ที่ไม่คาดคิดอีกอย่างหนึ่งเกี่ยวกับการอ่าน-เขียนดิสก์: ฉันคาดว่าจะไม่เห็นอะไรเลยที่นี่ แต่ปรากฎว่าเทอร์มินัลบางตัวเขียนข้อมูลจำนวนมากที่สุดลงดิสก์ ดังนั้นไลบรารี VTE จะเก็บบัฟเฟอร์การเลื่อนไว้บนดิสก์จริงๆ (คุณลักษณะนี้ สังเกตเห็นย้อนกลับไปในปี 2010และสิ่งนี้ยังคงเกิดขึ้น) แต่ต่างจากการใช้งานแบบเก่า อย่างน้อยตอนนี้ข้อมูลนี้ได้รับการเข้ารหัสโดยใช้ AES256 GCM (จากเวอร์ชัน 0.39.2). แต่มีคำถามที่สมเหตุสมผลเกิดขึ้น: มีอะไรพิเศษเกี่ยวกับไลบรารี VTE ที่ต้องการแนวทางการใช้งานที่ไม่ได้มาตรฐาน...

ข้อสรุป

ในส่วนแรกของบทความ เราพบว่าเทอร์มินัลที่ใช้ VTE มีชุดคุณลักษณะที่ดี แต่ตอนนี้เราพบว่าสิ่งนี้มาพร้อมกับต้นทุนด้านประสิทธิภาพบางประการ ขณะนี้หน่วยความจำไม่ใช่ปัญหา เนื่องจากเทอร์มินัล VTE ทั้งหมดสามารถควบคุมผ่านกระบวนการ Daemon ซึ่งจะจำกัดความอยากอาหาร อย่างไรก็ตาม ระบบเก่าที่มีข้อจำกัดทางกายภาพเกี่ยวกับจำนวน RAM และบัฟเฟอร์เคอร์เนลอาจยังต้องการเทอร์มินัลเวอร์ชันก่อนหน้า เนื่องจากใช้ทรัพยากรน้อยกว่ามาก แม้ว่าเทอร์มินัล VTE จะทำงานได้ดีในการทดสอบปริมาณงาน (การเลื่อน) แต่เวลาแฝงในการแสดงผลจะสูงกว่าเกณฑ์ที่กำหนดไว้ในคู่มือผู้ใช้ GNOME นักพัฒนา VTE น่าจะคำนึงถึงเรื่องนี้ด้วย หากเราคำนึงว่าแม้แต่ผู้ใช้ Linux มือใหม่ที่ต้องเผชิญกับเทอร์มินัลก็เป็นสิ่งที่หลีกเลี่ยงไม่ได้ พวกเขาก็สามารถทำให้เป็นมิตรกับผู้ใช้มากขึ้น สำหรับผู้ที่ชื่นชอบประสบการณ์สูง การเปลี่ยนจากหน้าจอเทอร์มินัลเริ่มต้นอาจช่วยลดอาการปวดตา และช่วยให้หลีกเลี่ยงการบาดเจ็บและความเจ็บป่วยจากการทำงานในอนาคตอันเนื่องมาจากการทำงานที่ยาวนานได้ น่าเสียดายที่มีเพียง xterm และ mlterm แบบเก่าเท่านั้นที่พาเราไปที่ขีดจำกัดการ ping ของเวทมนตร์ที่ 10 มิลลิวินาที ซึ่งหลายคนยอมรับไม่ได้

การวัดเกณฑ์มาตรฐานยังแสดงให้เห็นว่าเนื่องจากการพัฒนาสภาพแวดล้อมกราฟิก Linux นักพัฒนาจึงต้องทำการประนีประนอมหลายประการ ผู้ใช้บางรายอาจต้องการดูตัวจัดการหน้าต่างทั่วไปเนื่องจากช่วยลดค่า Ping ได้อย่างมาก น่าเสียดายที่ไม่สามารถวัดเวลาแฝงสำหรับ Wayland ได้: โปรแกรม Typometer ที่ฉันใช้ถูกสร้างขึ้นสำหรับสิ่งที่ Wayland ได้รับการออกแบบมาเพื่อป้องกัน นั่นคือ การสอดแนมบนหน้าต่างอื่น ฉันหวังว่าการประกอบ Wayland จะทำงานได้ดีกว่า X.org และฉันก็หวังว่าในอนาคตจะมีใครสักคนพบวิธีวัดเวลาแฝงในสภาพแวดล้อมนี้

ที่มา: will.com