ພາບລວມຂອງຕົວຈຳລອງເຄື່ອງໝາຍປາຍທາງ

ສອງສາມຄໍາຈາກຫ້ອງການແປພາສາຂອງພວກເຮົາ: ປົກກະຕິແລ້ວທຸກຄົນພະຍາຍາມແປເອກະສານແລະສິ່ງພິມຫລ້າສຸດ, ແລະພວກເຮົາບໍ່ມີຂໍ້ຍົກເວັ້ນ. ແຕ່ terminals ບໍ່ແມ່ນສິ່ງທີ່ມີການປັບປຸງຫນຶ່ງຄັ້ງຕໍ່ອາທິດ. ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ແປໃຫ້ທ່ານບົດຄວາມໂດຍ Antoine Beaupré, ຈັດພີມມາໃນພາກຮຽນ spring ຂອງ 2018: ເຖິງວ່າຈະມີ "ອາຍຸ" ຢ່າງຫຼວງຫຼາຍໂດຍມາດຕະຖານທີ່ທັນສະໄຫມ, ໃນຄວາມຄິດເຫັນຂອງພວກເຮົາ, ອຸປະກອນການບໍ່ໄດ້ສູນເສຍຄວາມກ່ຽວຂ້ອງຂອງມັນທັງຫມົດ. ນອກຈາກນັ້ນ, ໃນເບື້ອງຕົ້ນນີ້ແມ່ນຊຸດຂອງສອງບົດຄວາມ, ແຕ່ພວກເຮົາໄດ້ຕັດສິນໃຈລວມພວກມັນເຂົ້າໄປໃນບົດຄວາມຂະຫນາດໃຫຍ່ຫນຶ່ງ.

Terminals ມີສະຖານທີ່ພິເສດໃນປະຫວັດສາດຄອມພິວເຕີ, ແຕ່ໃນທົດສະວັດທີ່ຜ່ານມາພວກເຂົາເຈົ້າໄດ້ຖືກບັງຄັບໃຫ້ຢູ່ລອດຄຽງຄູ່ກັບເສັ້ນຄໍາສັ່ງເນື່ອງຈາກວ່າການໂຕ້ຕອບຮູບພາບໄດ້ກາຍເປັນຢູ່ທົ່ວທຸກແຫ່ງ. Terminal emulators ແທນ​ທີ່​ເຂົາ​ເຈົ້າ​ເອງ ອ້າຍນ້ອງຮາດແວ, ເຊິ່ງ, ໃນທາງກັບກັນ, ແມ່ນການດັດແກ້ຂອງລະບົບໂດຍອີງໃສ່ບັດ punched ແລະສະຫຼັບສະຫຼັບ. ການແຜ່ກະຈາຍທີ່ທັນສະ ໄໝ ມາພ້ອມກັບຕົວຈຳລອງຈຸດທີ່ຫຼາກຫຼາຍຂອງທຸກຮູບຮ່າງແລະສີ. ແລະໃນຂະນະທີ່ຫຼາຍຄົນມີເນື້ອໃນກັບມາດຕະຖານທີ່ສະຫນອງໂດຍສະພາບແວດລ້ອມການເຮັດວຽກຂອງເຂົາເຈົ້າ, ບາງຄົນພູມໃຈໃຊ້ຊອບແວ exotic downright ເພື່ອດໍາເນີນການ shell favorite ຂອງເຂົາເຈົ້າຫຼືຕົວແກ້ໄຂຂໍ້ຄວາມ. ແຕ່, ດັ່ງທີ່ພວກເຮົາຈະເຫັນຈາກບົດຄວາມນີ້, ບໍ່ແມ່ນທຸກ terminals ໄດ້ຖືກສ້າງຂື້ນໃນຮູບດຽວກັນ: ພວກມັນແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍໃນການເຮັດວຽກ, ຂະຫນາດແລະການປະຕິບັດ.

ບາງຈຸດມີຂຸມຄວາມປອດໄພທີ່ຫນ້າປະຫລາດໃຈແທ້ໆ, ບວກກັບສ່ວນໃຫຍ່ມີຫນ້າທີ່ທີ່ແຕກຕ່າງກັນຫມົດ, ຈາກການສະຫນັບສະຫນູນສໍາລັບການໂຕ້ຕອບແບບແທັບໄປຫາການຂຽນສະຄິບ. ເຖິງແມ່ນວ່າພວກເຮົາ ໄດ້ເບິ່ງຕົວຈຳລອງເຄື່ອງໝາຍປາຍທາງໃນອະດີດທີ່ຫ່າງໄກ, ບົດຄວາມນີ້ເປັນການປັບປຸງຂອງອຸປະກອນການທີ່ຜ່ານມາທີ່ຈະຊ່ວຍໃຫ້ຜູ້ອ່ານກໍານົດທີ່ terminal ທີ່ຈະນໍາໃຊ້ໃນປີ 2018. ເຄິ່ງທໍາອິດຂອງບົດຄວາມປຽບທຽບລັກສະນະ, ແລະເຄິ່ງທີສອງປະເມີນການປະຕິບັດ.

ນີ້ແມ່ນຈຸດທີ່ຂ້າພະເຈົ້າໄດ້ທົບທວນຄືນ:

ເຫຼົ່ານີ້ອາດຈະບໍ່ເປັນສະບັບຫລ້າສຸດ, ເນື່ອງຈາກວ່າຂ້າພະເຈົ້າຖືກຈໍາກັດໃນການກໍ່ສ້າງທີ່ຫມັ້ນຄົງໃນເວລາທີ່ຂຽນ, ເຊິ່ງຂ້າພະເຈົ້າສາມາດເປີດຕົວໃນ Debian 9 ຫຼື Fedora 27. ມີຂໍ້ຍົກເວັ້ນພຽງແຕ່ Alacritty. ມັນເປັນລູກຫລານຂອງ GPU-accelerated terminals ແລະຖືກຂຽນເປັນພາສາທີ່ຜິດປົກກະຕິແລະໃຫມ່ສໍາລັບວຽກງານນີ້ - Rust. ຂ້ອຍບໍ່ໄດ້ລວມເອົາຕົວເຊື່ອມຕໍ່ເວັບຈາກການທົບທວນຂອງຂ້ອຍ (ລວມທັງສິ່ງທີ່ຢູ່ໃນ Electron), ເນື່ອງຈາກວ່າການທົດສອບເບື້ອງຕົ້ນສະແດງໃຫ້ເຫັນການປະຕິບັດທີ່ບໍ່ດີທີ່ສຸດຂອງພວກເຂົາ.

ຮອງຮັບ Unicode

ຂ້ອຍເລີ່ມການທົດສອບຂອງຂ້ອຍດ້ວຍການຮອງຮັບ Unicode. ການທົດສອບຄັ້ງທໍາອິດຂອງ terminals ແມ່ນເພື່ອສະແດງ string Unicode ຈາກ ບົດຄວາມ Wikipedia: “é, Δ, И, ק, م, ๗, あ, 叶, 葉 ແລະ 말.” ການທົດສອບງ່າຍໆນີ້ສະແດງໃຫ້ເຫັນວ່າ terminal ສາມາດເຮັດວຽກໄດ້ຢ່າງຖືກຕ້ອງທົ່ວໂລກຫຼືບໍ່. xterm terminal ບໍ່ສະແດງຕົວອັກສອນ Arabic ເມັມ ໃນ​ການ​ຕັ້ງ​ຄ່າ​ເລີ່ມ​ຕົ້ນ​:

ໂດຍຄ່າເລີ່ມຕົ້ນ, xterm ໃຊ້ຕົວອັກສອນ "ຄົງທີ່" ຄລາສສິກ, ເຊິ່ງ, ອີງຕາມ ຍັງເປັນ Vicki ຄືກັນ, ມີ "ການຄຸ້ມຄອງ Unicode ຢ່າງຫຼວງຫຼາຍນັບຕັ້ງແຕ່ 1997". ມີບາງສິ່ງບາງຢ່າງເກີດຂຶ້ນໃນຕົວອັກສອນນີ້ທີ່ເຮັດໃຫ້ຕົວອັກສອນປາກົດເປັນກອບຫວ່າງເປົ່າແລະພຽງແຕ່ໃນເວລາທີ່ຕົວອັກສອນຕົວຫນັງສືເພີ່ມຂຶ້ນເຖິງ 20+ ຈຸດທີ່ຕົວອັກສອນສຸດທ້າຍເລີ່ມສະແດງຢ່າງຖືກຕ້ອງ. ຢ່າງໃດກໍຕາມ, "ການແກ້ໄຂ" ນີ້ທໍາລາຍການສະແດງຕົວອັກສອນ Unicode ອື່ນໆ:

ພາບຫນ້າຈໍເຫຼົ່ານີ້ຖືກປະຕິບັດໃນ Fedora 27, ຍ້ອນວ່າມັນໃຫ້ຜົນໄດ້ຮັບທີ່ດີກວ່າ Debian 9, ບ່ອນທີ່ບາງສະບັບເກົ່າຂອງ terminals (ໂດຍສະເພາະ mlterm) ບໍ່ສາມາດຈັດການຕົວອັກສອນຢ່າງຖືກຕ້ອງ. ໂຊກດີນີ້ໄດ້ຖືກແກ້ໄຂໃນສະບັບຕໍ່ມາ.

ໃນປັດຈຸບັນສັງເກດເຫັນວິທີການສະແດງເສັ້ນໃນ xterm. ມັນ turns ໃຫ້​ເຫັນ​ວ່າ​ສັນ​ຍາ​ລັກ Mem ແລະ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້ Semitic​ ໂຄບ ອ້າງເຖິງສະຄຣິບແບບ RTL (ຂວາຫາຊ້າຍ), ດັ່ງນັ້ນທາງດ້ານເຕັກນິກພວກເຂົາຄວນຈະຖືກສະແດງຈາກຂວາຫາຊ້າຍ. ຕົວທ່ອງເວັບເຊັ່ນ Firefox 57 ຈັດການເສັ້ນຂ້າງເທິງຢ່າງຖືກຕ້ອງ. ສະບັບທີ່ງ່າຍດາຍຂອງຂໍ້ຄວາມ RTL ແມ່ນຄໍາວ່າ "Сара" ໃນ​ພາສາ​ເຮັບເຣີ (.רה). ຫນ້າ Wiki ໃນບົດເລື່ອງສອງທິດທາງ ເວົ້າຕໍ່ໄປນີ້:

“ໂປລແກລມຄອມພິວເຕີຈໍານວນຫຼາຍບໍ່ສາມາດສະແດງຂໍ້ຄວາມສອງທິດທາງໄດ້ຢ່າງຖືກຕ້ອງ. ຕົວຢ່າງ, ຊື່ພາສາເຮັບເຣີ "Sarah" ປະກອບດ້ວຍຕົວອັກສອນ sin (sh) (ທີ່ປາກົດຢູ່ເບື້ອງຂວາ), ຫຼັງຈາກນັ້ນ resh (ר) ແລະສຸດທ້າຍແມ່ນ (ha) (ເຊິ່ງຄວນຈະປາກົດຢູ່ເບື້ອງຊ້າຍ).

terminals ຈໍານວນຫຼາຍລົ້ມເຫລວການທົດສອບນີ້: Alacritty, VTE-derived Gnome ແລະ XFCE terminals, urxvt, st ແລະ xterm ສະແດງ "Sara" ໃນຄໍາສັ່ງປີ້ນກັບກັນ, ຄືກັບວ່າພວກເຮົາໄດ້ຂຽນຊື່ເປັນ "Aras".

ບັນຫາອີກປະການຫນຶ່ງທີ່ມີບົດເລື່ອງ bidirectional ແມ່ນວ່າພວກເຂົາຕ້ອງໄດ້ຮັບການສອດຄ່ອງ somehow, ໂດຍສະເພາະໃນເວລາທີ່ມັນມາກັບການປະສົມບົດເລື່ອງ RTL ແລະ LTR. ສະຄຣິບ RTL ຄວນແລ່ນຈາກດ້ານຂວາຂອງປ່ອງຢ້ຽມ terminal, ແຕ່ສິ່ງທີ່ຄວນເກີດຂຶ້ນສໍາລັບ terminals ທີ່ເປັນຄ່າເລີ່ມຕົ້ນຂອງ LTR English? ພວກມັນສ່ວນໃຫຍ່ບໍ່ມີກົນໄກພິເສດໃດໆ ແລະຈັດວາງຂໍ້ຄວາມທັງໝົດໄປທາງຊ້າຍ (ລວມທັງໃນ Konsole). ຂໍ້ຍົກເວັ້ນແມ່ນ pterm ແລະ mlterm, ເຊິ່ງປະຕິບັດຕາມມາດຕະຖານແລະວາງສາຍດັ່ງກ່າວຢ່າງຖືກຕ້ອງ.

ການປ້ອງກັນການໃສ່

ລັກສະນະທີ່ສໍາຄັນຕໍ່ໄປທີ່ຂ້ອຍໄດ້ກໍານົດແມ່ນການປ້ອງກັນການໃສ່. ເຖິງແມ່ນວ່າມັນເປັນທີ່ຮູ້ຈັກຢ່າງກວ້າງຂວາງວ່າການສະກົດຄໍາເຊັ່ນ:

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

ແມ່ນຄໍາສັ່ງຊຸກຍູ້ການປະຕິບັດລະຫັດ, ມີຄົນຈໍານວນຫນ້ອຍທີ່ຮູ້ວ່າຄໍາສັ່ງທີ່ເຊື່ອງໄວ້ສາມາດເຂົ້າໄປໃນ console ໃນເວລາທີ່ຄັດລອກແລະວາງຈາກຕົວທ່ອງເວັບ, ເຖິງແມ່ນວ່າຫຼັງຈາກການກວດສອບຢ່າງລະມັດລະວັງ. ສະຖານທີ່ຢັ້ງຢືນ Gianna Horna brilliantly ສະ​ແດງ​ໃຫ້​ເຫັນ​ວິ​ທີ​ການ innocuous​-ເບິ່ງ​ຄໍາ​ສັ່ງ​ແມ່ນ​:

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

ກາຍເປັນສິ່ງລົບກວນດັ່ງກ່າວເມື່ອວາງຈາກເວັບໄຊທ໌ຂອງ Horn ເຂົ້າໄປໃນ terminal:

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.

ໂໝດວາງວົງເລັບ ໄດ້​ຖືກ​ອອກ​ແບບ​ຢ່າງ​ຈະ​ແຈ້ງ​ເພື່ອ​ລົບ​ລ້າງ​ການ​ໂຈມ​ຕີ​ດັ່ງ​ກ່າວ. ໃນຮູບແບບນີ້, terminals ກວມເອົາຂໍ້ຄວາມທີ່ວາງໄວ້ໃນຄູ່ຂອງລໍາດັບ escape ພິເສດເພື່ອບອກ shell ກ່ຽວກັບຕົ້ນກໍາເນີດຂອງຂໍ້ຄວາມ. ອັນນີ້ບອກ shell ວ່າມັນສາມາດບໍ່ສົນໃຈຕົວອັກສອນພິເສດທີ່ຂໍ້ຄວາມທີ່ວາງໄວ້ອາດຈະມີ. terminals ທັງຫມົດກັບຄືນໄປບ່ອນ xterm venerable ສະຫນັບສະຫນູນຄຸນນະສົມບັດນີ້, ແຕ່ການວາງໃນໂຫມດ Bracketed ຮຽກຮ້ອງໃຫ້ມີການສະຫນັບສະຫນູນຈາກ shell ຫຼືຄໍາຮ້ອງສະຫມັກທີ່ເຮັດວຽກຢູ່ໃນ terminal. ສໍາລັບຕົວຢ່າງ, ການນໍາໃຊ້ຊອບແວ GNU Readline (Bash ດຽວກັນ), ຕ້ອງການໄຟລ໌ ~/.inputrc:

set enable-bracketed-paste on

ແຕ່ຫນ້າເສຍດາຍ, ເວັບໄຊທ໌ທົດສອບຂອງ Horn ຍັງສະແດງວິທີການຂ້າມການປົກປ້ອງນີ້ຜ່ານການຈັດຮູບແບບຂໍ້ຄວາມຂອງມັນເອງແລະສິ້ນສຸດກ່ອນໄວອັນຄວນທີ່ຈະນໍາໃຊ້ຮູບແບບ Bracketed ກັບມັນ. ອັນນີ້ໃຊ້ໄດ້ເພາະວ່າບາງ terminals ບໍ່ໄດ້ກັ່ນຕອງລໍາດັບ escape ຢ່າງຖືກຕ້ອງກ່ອນທີ່ຈະເພີ່ມຂອງຕົນເອງ. ຕົວຢ່າງ, ໃນຂອງຂ້ອຍຂ້ອຍບໍ່ສາມາດເຮັດສໍາເລັດການທົດສອບ Konsole ໄດ້ເຖິງແມ່ນວ່າຈະມີການຕັ້ງຄ່າທີ່ຖືກຕ້ອງ .inputrc ໄຟລ໌. ນີ້ຫມາຍຄວາມວ່າທ່ານສາມາດເຮັດໃຫ້ການຕັ້ງຄ່າລະບົບຂອງທ່ານເສຍຫາຍໄດ້ຢ່າງງ່າຍດາຍເນື່ອງຈາກຄໍາຮ້ອງສະຫມັກທີ່ບໍ່ສະຫນັບສະຫນູນຫຼື shell ທີ່ຖືກຕັ້ງຄ່າບໍ່ຖືກຕ້ອງ. ນີ້ແມ່ນອັນຕະລາຍໂດຍສະເພາະໃນເວລາທີ່ເຂົ້າສູ່ລະບົບເຄື່ອງແມ່ຂ່າຍຫ່າງໄກສອກຫຼີກ, ບ່ອນທີ່ການເຮັດວຽກຂອງການຕັ້ງຄ່າລະມັດລະວັງແມ່ນຫນ້ອຍ, ໂດຍສະເພາະຖ້າທ່ານມີເຄື່ອງຫ່າງໄກສອກຫຼີກຫຼາຍ.

ການແກ້ໄຂທີ່ດີຕໍ່ກັບບັນຫານີ້ແມ່ນ plugin ຢືນຢັນການວາງສໍາລັບ terminal urxvt, ເຊິ່ງພຽງແຕ່ຂໍການອະນຸຍາດໃຫ້ໃສ່ຂໍ້ຄວາມໃດໆທີ່ມີແຖວໃຫມ່. ຂ້ອຍບໍ່ພົບທາງເລືອກທີ່ປອດໄພກວ່າສໍາລັບການໂຈມຕີຂໍ້ຄວາມທີ່ອະທິບາຍໂດຍ Horn.

ແຖບ ແລະໂປຣໄຟລ໌

ຄຸນສົມບັດທີ່ເປັນທີ່ນິຍົມໃນປັດຈຸບັນແມ່ນການສະຫນັບສະຫນູນສໍາລັບການໂຕ້ຕອບຂອງແຖບ, ເຊິ່ງພວກເຮົາຈະກໍານົດເປັນປ່ອງຢ້ຽມ terminal ຫນຶ່ງທີ່ປະກອບດ້ວຍຫຼາຍ terminals ອື່ນໆ. ຟັງຊັນນີ້ແຕກຕ່າງກັນສໍາລັບ terminal ທີ່ແຕກຕ່າງກັນ, ແລະເຖິງແມ່ນວ່າ terminal xterm ແບບດັ້ງເດີມບໍ່ສະຫນັບສະຫນູນແຖບທັງຫມົດ, incarnations terminals ທີ່ທັນສະໄຫມຫຼາຍເຊັ່ນ Xfce Terminal, GNOME Terminal ແລະ Konsole ມີຫນ້າທີ່ນີ້. Urxvt ຍັງສະຫນັບສະຫນູນແຖບ, ແຕ່ວ່າພຽງແຕ່ຖ້າທ່ານໃຊ້ plugin. ແຕ່ໃນແງ່ຂອງການສະຫນັບສະຫນູນແຖບຕົວມັນເອງ, Terminator ແມ່ນຜູ້ນໍາທີ່ບໍ່ມີການໂຕ້ຖຽງ: ມັນບໍ່ພຽງແຕ່ສະຫນັບສະຫນູນແທັບ, ແຕ່ຍັງສາມາດຈັດແຈງ terminals ໃນຄໍາສັ່ງໃດໆ (ເບິ່ງຮູບຂ້າງລຸ່ມນີ້).

ຄຸນສົມບັດອື່ນຂອງ Terminator ແມ່ນຄວາມສາມາດໃນການ "ຈັດກຸ່ມ" ແຖບເຫຼົ່ານີ້ຮ່ວມກັນແລະສົ່ງການກົດປຸ່ມດຽວກັນໄປຫາຫຼາຍ terminals ໃນເວລາດຽວກັນ, ສະຫນອງເຄື່ອງມືທີ່ຂີ້ຮ້າຍສໍາລັບການປະຕິບັດການຈໍານວນຫຼາຍຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຫຼາຍຄັ້ງໃນເວລາດຽວກັນ. ຄຸນສົມບັດທີ່ຄ້າຍຄືກັນຍັງຖືກປະຕິບັດຢູ່ໃນ Konsole. ເພື່ອໃຊ້ຄຸນສົມບັດນີ້ຢູ່ໃນຈຸດອື່ນ, ທ່ານຕ້ອງໃຊ້ຊອບແວພາກສ່ວນທີສາມເຊັ່ນ: Cluster SSH, xlax ຫຼື tmux.

ແຖບເຮັດວຽກໄດ້ດີໂດຍສະເພາະເມື່ອຈັບຄູ່ກັບໂປຣໄຟລ໌: ຕົວຢ່າງ, ທ່ານສາມາດມີແຖບຫນຶ່ງສໍາລັບອີເມລ໌, ແຖບອື່ນສໍາລັບການສົນທະນາ, ແລະອື່ນໆ. ອັນນີ້ໄດ້ຮັບການສະຫນັບສະຫນຸນຢ່າງດີໂດຍ Konsole Terminal ແລະ GNOME Terminal. ທັງສອງອະນຸຍາດໃຫ້ແຕ່ລະແຖບເປີດໂປຣໄຟລ໌ຂອງຕົນເອງໂດຍອັດຕະໂນມັດ. Terminator ຍັງສະຫນັບສະຫນູນໂປຣໄຟລ໌, ແຕ່ຂ້ອຍບໍ່ສາມາດຊອກຫາວິທີທີ່ຈະເປີດຕົວບາງໂປຼແກຼມໂດຍອັດຕະໂນມັດເມື່ອທ່ານເປີດແຖບສະເພາະ. terminals ອື່ນໆບໍ່ມີແນວຄວາມຄິດຂອງ "ໂປຣໄຟລ໌" ເລີຍ.

ເສື້ອກັນໜາວ

ສິ່ງສຸດທ້າຍທີ່ຂ້ອຍຈະກວມເອົາໃນສ່ວນທໍາອິດຂອງບົດຄວາມນີ້ແມ່ນຮູບລັກສະນະຂອງ terminals. ຕົວຢ່າງເຊັ່ນ GNOME, Xfce ແລະ urxvt ສະຫນັບສະຫນູນຄວາມໂປ່ງໃສ, ແຕ່ບໍ່ດົນມານີ້ໄດ້ຫຼຸດລົງການສະຫນັບສະຫນູນສໍາລັບຮູບພາບພື້ນຫລັງ, ບັງຄັບໃຫ້ຜູ້ໃຊ້ບາງຄົນປ່ຽນໄປຫາເຄື່ອງໃຊ້ໄຟຟ້າ. Tilix. ສ່ວນບຸກຄົນ, ຂ້າພະເຈົ້າມີຄວາມສຸກກັບມັນແລະມັນງ່າຍດາຍ ແຫຼ່ງຂໍ້ມູນ, ເຊິ່ງກໍານົດຊຸດພື້ນຖານຂອງສີພື້ນຫລັງສໍາລັບ urxvt. ຢ່າງໃດກໍຕາມ, ຫົວຂໍ້ສີທີ່ບໍ່ແມ່ນມາດຕະຖານຍັງສາມາດສ້າງບັນຫາ. ຍົກ​ຕົວ​ຢ່າງ, ແສງແດດ ບໍ່ເຮັດວຽກ ກັບຄໍາຮ້ອງສະຫມັກ htop и IPTraf, ເນື່ອງຈາກວ່າພວກເຂົາໃຊ້ສີຂອງຕົນເອງແລ້ວ.

ຕົ້ນສະບັບ VT100 terminal ບໍ່ຮອງຮັບສີ, ແລະອັນໃໝ່ມັກຈະຖືກຈຳກັດໃຫ້ຢູ່ໃນສີ 256 ສີ. ສໍາລັບຜູ້ໃຊ້ຂັ້ນສູງທີ່ສ້າງຮູບແບບເຄື່ອງໃຊ້ຂອງພວກເຂົາ, ການເຕືອນຂອງ shell ຫຼືແຖບສະຖານະໃນແບບສະລັບສັບຊ້ອນສາມາດເປັນຂໍ້ຈໍາກັດທີ່ຫນ້າລໍາຄານ. Gist ຕິດຕາມຈຸດໃດທີ່ມີ "ສີແທ້". ການທົດສອບຂອງຂ້ອຍຢືນຢັນວ່າ st, Alacritty ແລະ VTE-based terminals ສະຫນັບສະຫນູນ True Color ຢ່າງສົມບູນ. terminals ອື່ນບໍ່ fare ດີຫຼາຍໃນເລື່ອງນີ້ແລະ, ໃນຄວາມເປັນຈິງ, ບໍ່ສະແດງ 256 ສີ. ຂ້າງລຸ່ມນີ້ທ່ານສາມາດເບິ່ງຄວາມແຕກຕ່າງລະຫວ່າງການສະຫນັບສະຫນູນ True Color ໃນ GNOME terminals, st ແລະ xterm, ເຊິ່ງເຮັດວຽກໄດ້ດີກັບ palette ສີ 256 ຂອງພວກເຂົາ, ແລະ urxvt, ເຊິ່ງບໍ່ພຽງແຕ່ເຮັດໃຫ້ການທົດສອບລົ້ມເຫລວ, ແຕ່ຍັງສະແດງໃຫ້ເຫັນບາງລັກສະນະກະພິບແທນພວກມັນ.

ບາງຈຸດເຊື່ອມຕໍ່ຍັງວິເຄາະຂໍ້ຄວາມສໍາລັບຮູບແບບ URL ເພື່ອເຮັດໃຫ້ການເຊື່ອມຕໍ່ສາມາດຄລິກໄດ້. ນີ້ໃຊ້ກັບທຸກຈຸດທີ່ມາຈາກ VTE, ໃນຂະນະທີ່ urxvt ຕ້ອງການປລັກອິນພິເສດທີ່ຈະປ່ຽນ URL ດ້ວຍການຄລິກ ຫຼືໃຊ້ທາງລັດແປ້ນພິມ. terminals ອື່ນໆທີ່ຂ້ອຍໄດ້ທົດສອບການສະແດງ URL ໃນທາງອື່ນ.

ສຸດທ້າຍ, ແນວໂນ້ມໃຫມ່ໃນ terminals ແມ່ນທາງເລືອກຂອງ buffer ເລື່ອນ. ຕົວຢ່າງ, st ບໍ່ມີ buffer ເລື່ອນ; ມັນສົມມຸດວ່າຜູ້ໃຊ້ຈະໃຊ້ multiplexer terminal ເຊັ່ນ tmux ແລະ ໜ້າ ຈໍ GNU.

Alacritty ຍັງຂາດ backscroll buffers, ແຕ່ ຈະຖືກເພີ່ມໃນໄວໆນີ້ ການສະຫນັບສະຫນູນຂອງມັນເນື່ອງຈາກ "ຄໍາຄຶດຄໍາເຫັນຢ່າງກວ້າງຂວາງ" ກ່ຽວກັບຫົວຂໍ້ນີ້ຈາກຜູ້ໃຊ້. ນອກເຫນືອຈາກການເລີ່ມຕົ້ນເຫຼົ່ານີ້, ທຸກໆສະຖານີທີ່ຂ້ອຍໄດ້ທົດສອບວ່າຂ້ອຍສາມາດຊອກຫາການສະຫນັບສະຫນູນການເລື່ອນແບບປີ້ນກັບກັນ.

ທັງໝົດຍ່ອຍ

ໃນ​ພາກ​ສ່ວນ​ທີ​ສອງ​ຂອງ​ອຸ​ປະ​ກອນ (.ໃນຕົ້ນສະບັບເຫຼົ່ານີ້ແມ່ນສອງບົດຄວາມທີ່ແຕກຕ່າງກັນ - ປະມານ. ເລນ) ພວກເຮົາຈະປຽບທຽບການປະຕິບັດ, ການໃຊ້ຫນ່ວຍຄວາມຈໍາແລະການ latency. ແຕ່ພວກເຮົາສາມາດເຫັນໄດ້ວ່າບາງຈຸດທີ່ຢູ່ໃນຄໍາຖາມມີຂໍ້ບົກຜ່ອງທີ່ຮ້າຍແຮງ. ຕົວຢ່າງ, ຜູ້ໃຊ້ທີ່ເຮັດວຽກເປັນປົກກະຕິກັບສະຄິບ RTL ອາດຈະຕ້ອງການພິຈາລະນາ mlterm ແລະ pterm, ຍ້ອນວ່າພວກເຂົາດີກວ່າໃນການຈັດການວຽກງານທີ່ຄ້າຍຄືກັນກວ່າຄົນອື່ນ. Konsole ຍັງປະຕິບັດໄດ້ດີ. ຜູ້ໃຊ້ທີ່ບໍ່ໄດ້ເຮັດວຽກກັບສະຄິບ RTL ອາດຈະເລືອກອັນອື່ນ.

ໃນແງ່ຂອງການປ້ອງກັນການໃສ່ລະຫັດທີ່ເປັນອັນຕະລາຍ, urxvt ໂດດເດັ່ນຍ້ອນການປະຕິບັດພິເສດຂອງການປ້ອງກັນການໂຈມຕີປະເພດນີ້, ເຊິ່ງເບິ່ງຄືວ່າສະດວກສະບາຍສໍາລັບຂ້ອຍ. ສໍາລັບຜູ້ທີ່ຊອກຫາສຽງລະຄັງແລະ whistles, Konsole ແມ່ນມີມູນຄ່າເບິ່ງ. ສຸດທ້າຍ, ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າ VTE ເປັນພື້ນຖານທີ່ດີເລີດສໍາລັບ terminals, ເຊິ່ງຮັບປະກັນການສະຫນັບສະຫນູນສີ, ການຮັບຮູ້ URL, ແລະອື່ນໆ. ຢູ່ glance ທໍາອິດ, terminal ເລີ່ມຕົ້ນທີ່ມາພ້ອມກັບສະພາບແວດລ້ອມທີ່ທ່ານມັກອາດຈະຕອບສະຫນອງຄວາມຕ້ອງການທັງຫມົດ, ແຕ່ປ່ອຍໃຫ້ຄໍາຖາມນີ້ເປີດຈົນກ່ວາພວກເຮົາເຂົ້າໃຈປະສິດທິພາບ.

ໃຫ້ສືບຕໍ່ການສົນທະນາ

ໂດຍທົ່ວໄປແລ້ວ, ການປະຕິບັດຂອງ terminals ໃນຕົວຂອງມັນເອງອາດຈະເບິ່ງຄືວ່າເປັນບັນຫາໄກ, ແຕ່ຍ້ອນວ່າມັນຫັນອອກ, ບາງສ່ວນຂອງພວກມັນສະແດງເຖິງຄວາມແປກໃຈທີ່ສູງທີ່ຫນ້າປະຫລາດໃຈສໍາລັບຊອບແວປະເພດພື້ນຖານດັ່ງກ່າວ. ຕໍ່ໄປພວກເຮົາຈະເບິ່ງສິ່ງທີ່ເອີ້ນວ່າ "ຄວາມໄວ" ແບບດັ້ງເດີມ (ໃນຄວາມເປັນຈິງ, ນີ້ແມ່ນຄວາມໄວເລື່ອນ) ແລະການບໍລິໂພກຫນ່ວຍຄວາມຈໍາຂອງສະຖານີ (ໂດຍຄໍາເຕືອນວ່ານີ້ບໍ່ສໍາຄັນເທົ່າທີ່ມັນເປັນເວລາຫລາຍສິບປີກ່ອນ).

ການຊັກຊ້າ

ຫຼັງຈາກການສຶກສາຢ່າງລະອຽດກ່ຽວກັບການປະຕິບັດຢູ່ປາຍຍອດ, ຂ້າພະເຈົ້າໄດ້ສະຫຼຸບວ່າຕົວກໍານົດການທີ່ສໍາຄັນທີ່ສຸດໃນເລື່ອງນີ້ແມ່ນ latency (ping). ໃນບົດຄວາມຂອງລາວ "ພວກເຮົາພິມດ້ວຍຄວາມຍິນດີ" Pavel Fatin ເບິ່ງຄວາມລ່າຊ້າຂອງຕົວແກ້ໄຂຂໍ້ຄວາມຕ່າງໆແລະຊີ້ໃຫ້ເຫັນເຖິງຈຸດຫມາຍປາຍທາງໃນເລື່ອງນີ້ອາດຈະຊ້າກວ່າຕົວແກ້ໄຂຂໍ້ຄວາມທີ່ໄວທີ່ສຸດ. ມັນແມ່ນ ຄຳ ແນະ ນຳ ນີ້ທີ່ເຮັດໃຫ້ຂ້ອຍແລ່ນການທົດສອບຂອງຂ້ອຍເອງແລະຂຽນບົດຄວາມນີ້.

ແຕ່ຄວາມລ່າຊ້າແມ່ນຫຍັງ ແລະເປັນຫຍັງມັນຈຶ່ງສຳຄັນຫຼາຍ? ໃນບົດຄວາມຂອງລາວ, Fatin ໄດ້ກໍານົດມັນເປັນ "ຄວາມລ່າຊ້າລະຫວ່າງການກົດປຸ່ມແລະການປັບປຸງຫນ້າຈໍທີ່ສອດຄ້ອງກັນ" ແລະອ້າງອີງ. "ຄູ່ມືການພົວພັນກັບມະນຸດກັບຄອມພິວເຕີ", ເຊິ່ງກ່າວວ່າ: "ຄວາມລ່າຊ້າຂອງຄໍາຄຶດຄໍາເຫັນທີ່ເບິ່ງເຫັນໃນຈໍສະແດງຜົນຄອມພິວເຕີມີຜົນກະທົບທີ່ສໍາຄັນຕໍ່ພຶດຕິກໍາແລະຄວາມພໍໃຈຂອງຜູ້ພິມ."

Fatin ອະທິບາຍວ່າ ping ນີ້ມີຜົນສະທ້ອນທີ່ເລິກເຊິ່ງກວ່າພຽງແຕ່ຄວາມພໍໃຈ: "ການພິມຊ້າລົງ, ຄວາມຜິດພາດຫຼາຍເກີດຂື້ນ, ແລະຄວາມເຄັ່ງຕຶງຂອງຕາແລະກ້າມເນື້ອເພີ່ມຂຶ້ນ." ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ການຊັກຊ້າຂະຫນາດໃຫຍ່ສາມາດນໍາໄປສູ່ການພິມຜິດແລະຄຸນນະພາບຂອງລະຫັດຕ່ໍາ, ຍ້ອນວ່າມັນນໍາໄປສູ່ການໂຫຼດມັນສະຫມອງເພີ່ມເຕີມ. ແຕ່ສິ່ງທີ່ຮ້າຍແຮງກວ່າເກົ່າແມ່ນວ່າ ping "ເຮັດໃຫ້ຕາແລະກ້າມເນື້ອເພີ່ມຂຶ້ນ", ເຊິ່ງເບິ່ງຄືວ່າຫມາຍຄວາມວ່າ ການພັດທະນາການບາດເຈັບຂອງອາຊີບ ໃນ​ອະ​ນາ​ຄົດ (ປາກົດຂື້ນ, ຜູ້ຂຽນຫມາຍຄວາມວ່າບັນຫາກ່ຽວກັບກ້າມຊີ້ນຂອງຕາ, ກັບຄືນໄປບ່ອນ, ແຂນແລະ, ແນ່ນອນ, ວິໄສທັດ - ປະມານ. ເລນ) ເນື່ອງ​ຈາກ​ຄວາມ​ກົດ​ດັນ​ທີ່​ຊ​້​ໍາ​.

ບາງສ່ວນຂອງຜົນກະທົບເຫຼົ່ານີ້ເປັນທີ່ຮູ້ຈັກເປັນເວລາດົນນານ, ແລະຜົນໄດ້ຮັບ ການຄົ້ນຄວ້າ, ຈັດພີມມາກັບຄືນໄປບ່ອນໃນ 1976 ໃນວາລະສານ Ergonomics, ກ່າວວ່າການຊັກຊ້າຂອງ 100 milliseconds "ຢ່າງຫຼວງຫຼາຍ impairs ຄວາມໄວການພິມ." ບໍ່ດົນມານີ້, ຄູ່ມືຜູ້ໃຊ້ GNOME ໄດ້ນໍາສະເຫນີ ເວລາຕອບສະຫນອງທີ່ຍອມຮັບໄດ້ ໃນ 10 ມິນລິວິນາທີ, ແລະຖ້າທ່ານໄປຕື່ມອີກ, ຫຼັງຈາກນັ້ນ Microsoft Research ສະແດງໃຫ້ເຫັນວ່າ 1 millisecond ແມ່ນເຫມາະສົມ.

Fatin ໄດ້ດໍາເນີນການທົດສອບຂອງຕົນກ່ຽວກັບບັນນາທິການຂໍ້ຄວາມ; ລາວ​ໄດ້​ສ້າງ​ເຄື່ອງ​ມື​ແບບ​ພົກພາ​ທີ່​ເອີ້ນ​ວ່າ ເຄື່ອງວັດແທກຕົວພິມດີ, ທີ່ຂ້ອຍໃຊ້ເພື່ອທົດສອບ ping ໃນ terminal emulators. ຈົ່ງຈື່ໄວ້ວ່າການທົດສອບໄດ້ຖືກດໍາເນີນໃນຮູບແບບການຈໍາລອງ: ໃນຄວາມເປັນຈິງ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຄໍານຶງເຖິງທັງສອງ input (keyboard, USB controller, ແລະອື່ນໆ) ແລະ output (buffer ບັດວີດີໂອ, ຈໍພາບ) latency. ອີງຕາມ Fatin, ໃນການຕັ້ງຄ່າປົກກະຕິມັນແມ່ນປະມານ 20 ms. ຖ້າທ່ານມີອຸປະກອນເກມ, ທ່ານສາມາດບັນລຸຕົວເລກນີ້ໃນເວລາພຽງແຕ່ 3 milliseconds. ເນື່ອງຈາກພວກເຮົາມີຮາດແວໄວດັ່ງກ່າວແລ້ວ, ແອັບພລິເຄຊັນຈຶ່ງບໍ່ຈຳເປັນຕ້ອງເພີ່ມເວລາແພັກເກັດຂອງມັນເອງ. ເປົ້າໝາຍຂອງ Fatin ແມ່ນເພື່ອນຳເອົາຄວາມລ່າຊ້າຂອງແອັບພລິເຄຊັ່ນມາເປັນ 1 ມິນລິວິນາທີ, ຫຼືແມ່ນແຕ່ການໂທຫາໂທລະສັບໂດຍບໍ່ຕ້ອງໃຊ້. ຄວາມລ່າຊ້າທີ່ສາມາດວັດແທກໄດ້, ວິທີການໃນ IntelliJ IDEA 15.

ນີ້ແມ່ນຜົນຂອງການວັດແທກຂອງຂ້ອຍ, ເຊັ່ນດຽວກັນກັບບາງຜົນຂອງ Fatin, ເພື່ອສະແດງໃຫ້ເຫັນວ່າການທົດລອງຂອງຂ້ອຍເຫັນດີກັບການທົດສອບຂອງລາວ:

ສິ່ງທໍາອິດທີ່ຕີຂ້ອຍແມ່ນເວລາຕອບສະຫນອງທີ່ດີກວ່າຂອງໂປຼແກຼມເກົ່າເຊັ່ນ xterm ແລະ mlterm. ມີການຊັກຊ້າລົງທະບຽນທີ່ຮ້າຍແຮງທີ່ສຸດ (2,4 ms), ພວກເຂົາປະຕິບັດໄດ້ດີກວ່າສະຖານີທີ່ທັນສະໄຫມທີ່ໄວທີ່ສຸດ (10,6 ms ສໍາລັບ st). ບໍ່ມີສະຖານີທີ່ທັນສະໄຫມຕົກຕໍ່າກວ່າເກນ 10 millisecond. ໂດຍສະເພາະ, Alacritty ລົ້ມເຫລວໃນການຮຽກຮ້ອງ "ຕົວຈໍາແນກທີ່ໄວທີ່ສຸດທີ່ມີຢູ່", ເຖິງແມ່ນວ່າຄະແນນຂອງມັນໄດ້ຮັບການປັບປຸງນັບຕັ້ງແຕ່ການທົບທວນຄືນຄັ້ງທໍາອິດໃນປີ 2017. ແທ້ຈິງແລ້ວ, ຜູ້ຂຽນຂອງໂຄງການ ຮັບຮູ້ສະຖານະການ ແລະກໍາລັງເຮັດວຽກເພື່ອປັບປຸງຈໍສະແດງຜົນ. ມັນຄວນຈະໄດ້ຮັບການສັງເກດເຫັນວ່າ Vim ການນໍາໃຊ້ GTK3 ແມ່ນຄໍາສັ່ງຂອງຂະຫນາດຊ້າກ່ວາຄູ່ຮ່ວມງານ GTK2 ຂອງຕົນ. ຈາກນີ້ພວກເຮົາສາມາດສະຫຼຸບໄດ້ວ່າ GTK3 ສ້າງ latency ເພີ່ມເຕີມ, ແລະນີ້ແມ່ນສະທ້ອນໃຫ້ເຫັນຢູ່ໃນທຸກ terminal ອື່ນໆທີ່ໃຊ້ມັນ (Terminator, Xfce4 Terminal ແລະ GNOME Terminal).

ຢ່າງໃດກໍຕາມ, ຄວາມແຕກຕ່າງອາດຈະບໍ່ສັງເກດເຫັນກັບຕາ. ດັ່ງທີ່ Fatin ອະທິບາຍວ່າ, "ທ່ານບໍ່ ຈຳ ເປັນຕ້ອງຮູ້ເຖິງຄວາມລ່າຊ້າເພື່ອໃຫ້ມັນມີຜົນກະທົບກັບທ່ານ." Fatin ຍັງເຕືອນກ່ຽວກັບການບິດເບືອນມາດຕະຖານ: "ການລົບກວນໃດໆໃນ latency (jitter) ສ້າງຄວາມກົດດັນເພີ່ມເຕີມເນື່ອງຈາກຄວາມບໍ່ສາມາດຄາດເດົາໄດ້."

ເສັ້ນສະແດງຂ້າງເທິງນີ້ໄດ້ຖືກປະຕິບັດຢູ່ໃນອັນບໍລິສຸດ Debian 9 (stretch) ກັບ ຜູ້ຈັດການປ່ອງຢ້ຽມ i3. ສະພາບແວດລ້ອມນີ້ຜະລິດຜົນທີ່ດີທີ່ສຸດໃນການທົດສອບການຕອບສະໜອງ. ດັ່ງທີ່ມັນອອກມາ, GNOME ສ້າງ ping ເພີ່ມເຕີມຂອງ 20 ms ສໍາລັບການວັດແທກທັງຫມົດ. ຄໍາອະທິບາຍທີ່ເປັນໄປໄດ້ສໍາລັບການນີ້ແມ່ນມີໂຄງການທີ່ມີການປະມວນຜົນ synchronous ຂອງເຫດການປ້ອນຂໍ້ມູນ. Fatin ໃຫ້ຕົວຢ່າງສໍາລັບກໍລະນີດັ່ງກ່າວ ເຮັດວຽກ, ເຊິ່ງເພີ່ມຄວາມລ່າຊ້າໂດຍການປະມວນຜົນເຫດການປ້ອນຂໍ້ມູນທັງໝົດແບບ synchronously. ໂດຍຄ່າເລີ່ມຕົ້ນ, GNOME ຍັງມາພ້ອມກັບຕົວຈັດການປ່ອງຢ້ຽມ Mutter, ເຊິ່ງສ້າງ layer buffering ເພີ່ມເຕີມ, ເຊິ່ງມີຜົນກະທົບ ping ແລະເພີ່ມຢ່າງຫນ້ອຍ 8 milliseconds ຂອງ latency.

ຄວາມໄວເລື່ອນ

ການທົດສອບຕໍ່ໄປແມ່ນການທົດສອບ "ຄວາມໄວ" ຫຼື "ແບນວິດ" ແບບດັ້ງເດີມ, ເຊິ່ງວັດແທກຄວາມໄວຂອງ terminal ສາມາດເລື່ອນຫນ້າໃນຂະນະທີ່ສະແດງຂໍ້ຄວາມຈໍານວນຫລາຍໃນຫນ້າຈໍ. ກົນໄກຂອງການທົດສອບແຕກຕ່າງກັນ; ການທົດສອບຕົ້ນສະບັບແມ່ນພຽງແຕ່ສ້າງສາຍຂໍ້ຄວາມດຽວກັນໂດຍໃຊ້ຄໍາສັ່ງ seq. ການທົດສອບອື່ນໆລວມມີການທົດສອບ Thomas E. Dickey (xterm ບໍາລຸງຮັກສາ), ເຊິ່ງຊ້ໍາກັນ ໄຟລ໌ terminfo.src ຖືກດາວໂຫຼດແລ້ວ. ໃນການທົບທວນຄືນອື່ນຂອງການປະຕິບັດຢູ່ປາຍຍອດ ແດນລູ ໃຊ້ສະຕຣິງເຂົ້າລະຫັດ base32 ຂອງໄບຕ໌ສຸ່ມ, ຊຶ່ງເປັນຜົນອອກໄປຫາເຄື່ອງໃຊ້ cat. Luu ພິຈາລະນາການທົດສອບດັ່ງກ່າວເປັນ "ບໍ່ມີປະໂຍດເປັນມາດຕະຖານທີ່ຄົນເຮົາສາມາດຈິນຕະນາການໄດ້" ແລະແນະນໍາໃຫ້ໃຊ້ການຕອບໂຕ້ຢູ່ປາຍຍອດເປັນຕົວຊີ້ວັດຕົ້ນຕໍແທນ. Dickey ຍັງເອີ້ນວ່າການທົດສອບຂອງລາວເຂົ້າໃຈຜິດ. ຢ່າງໃດກໍຕາມ, ຜູ້ຂຽນທັງສອງຍອມຮັບວ່າແບນວິດຂອງປ່ອງຢ້ຽມຢູ່ປາຍຍອດສາມາດເປັນບັນຫາ. Luu ຄົ້ນພົບ Emacs Eshell freezing ໃນເວລາສະແດງໄຟລ໌ຂະຫນາດໃຫຍ່, ແລະ Dickey ໄດ້ປັບປຸງ terminal ເພື່ອກໍາຈັດຄວາມຊ້າສາຍຕາຂອງ xtrerm. ດັ່ງນັ້ນຍັງມີບາງປະໂຫຍດຕໍ່ການທົດສອບນີ້, ແຕ່ເນື່ອງຈາກຂະບວນການສະແດງຜົນແມ່ນແຕກຕ່າງກັນຫຼາຍຈາກ terminal ກັບ terminal, ມັນຍັງສາມາດຖືກນໍາໃຊ້ເປັນອົງປະກອບການທົດສອບເພື່ອທົດສອບຕົວກໍານົດການອື່ນໆ.

ໃນທີ່ນີ້ພວກເຮົາເຫັນ rxvt ແລະ st ດຶງລ່ວງຫນ້າຂອງການແຂ່ງຂັນ, ຕິດຕາມມາດ້ວຍ Alacritty ໃຫມ່ຫຼາຍ, ເຊິ່ງໄດ້ຖືກອອກແບບໂດຍສຸມໃສ່ການປະຕິບັດ. ຕໍ່ໄປແມ່ນ Xfce (VTE ຄອບຄົວ) ແລະ Konsole, ເຊິ່ງໄວກວ່າເກືອບສອງເທົ່າ. ສຸດທ້າຍແມ່ນ xterm, ເຊິ່ງຊ້າກວ່າ rxvt ຫ້າເທົ່າ. ໃນລະຫວ່າງການທົດສອບ, xterm ຍັງ rippled ຫຼາຍ, ເຮັດໃຫ້ການຖ່າຍທອດຂໍ້ຄວາມຍາກທີ່ຈະເຫັນເຖິງແມ່ນວ່າມັນເປັນເສັ້ນດຽວກັນ. Konsole ແມ່ນໄວ, ແຕ່ມັນເປັນເລື່ອງຍາກໃນບາງຄັ້ງ: ຈໍສະແດງຜົນຈະຄ້າງເປັນບາງເວລາ, ສະແດງຂໍ້ຄວາມບາງສ່ວນຫຼືບໍ່ສະແດງມັນເລີຍ. terminals ອື່ນໆສະແດງ strings ຢ່າງຊັດເຈນ, ລວມທັງ st, Alacritty, ແລະ rxvt.

Dickey ອະທິບາຍວ່າຄວາມແຕກຕ່າງຂອງການປະຕິບັດແມ່ນຍ້ອນການອອກແບບຂອງ scroll buffers ໃນ terminals ທີ່ແຕກຕ່າງກັນ. ໂດຍສະເພາະ, ລາວກ່າວຫາ rxvt ແລະຈຸດອື່ນໆຂອງ "ບໍ່ປະຕິບັດຕາມກົດລະບຽບທົ່ວໄປ":

"ບໍ່ຄືກັບ xterm, rxvt ບໍ່ໄດ້ພະຍາຍາມສະແດງການປັບປຸງທັງຫມົດ. ຖ້າມັນຕົກຢູ່ຫລັງ, ມັນຈະປະຕິເສດການປັບປຸງບາງຢ່າງເພື່ອໃຫ້ທັນ. ອັນນີ້ມີຜົນກະທົບຫຼາຍຕໍ່ຄວາມໄວການເລື່ອນທີ່ເຫັນໄດ້ຊັດເຈນກວ່າໃນການຈັດຕັ້ງໜ່ວຍຄວາມຈຳພາຍໃນ. ຂໍ້ບົກຜ່ອງອັນຫນຶ່ງແມ່ນວ່າພາບເຄື່ອນໄຫວ ASCII ແມ່ນບໍ່ແນ່ນອນ.

ເພື່ອແກ້ໄຂຄວາມຊ້າ xterm ທີ່ຮັບຮູ້ນີ້, Dickey ແນະນໍາໃຫ້ໃຊ້ຊັບພະຍາກອນ ເລື່ອນໄວ, ອະນຸຍາດໃຫ້ xterm ຍົກເລີກການປັບປຸງຫນ້າຈໍບາງຢ່າງເພື່ອຮັກສາການໄຫຼເຂົ້າ. ການທົດສອບຂອງຂ້ອຍຢືນຢັນວ່າ fastScroll ປັບປຸງການປະຕິບັດແລະນໍາເອົາ xterm ເທົ່າກັບ rxvt. ນີ້ແມ່ນ, ຢ່າງໃດກໍຕາມ, ເປັນ crutch ຍາກຫຼາຍ, ເປັນ Dickey ຕົນເອງອະທິບາຍ: "ບາງຄັ້ງ xterm - ຄ້າຍຄື konsole - ເບິ່ງຄືວ່າຈະຢຸດເຊົາຍ້ອນວ່າມັນລໍຖ້າສໍາລັບຊຸດໃຫມ່ຂອງການປັບປຸງຫນ້າຈໍຫຼັງຈາກບາງໄດ້ຖືກໂຍກຍ້າຍອອກ." ໃນເສັ້ນກ່າງນີ້, ມັນເບິ່ງຄືວ່າຈຸດອື່ນໆໄດ້ພົບເຫັນການປະນີປະນອມທີ່ດີທີ່ສຸດລະຫວ່າງຄວາມໄວແລະຄວາມສົມບູນຂອງການສະແດງ.

ການບໍລິໂພກຊັບພະຍາກອນ

ໂດຍບໍ່ສົນເລື່ອງວ່າມັນມີຄວາມສົມເຫດສົມຜົນທີ່ຈະພິຈາລະນາຄວາມໄວການເລື່ອນເປັນຕົວວັດແທກການປະຕິບັດ, ການທົດສອບນີ້ຊ່ວຍໃຫ້ພວກເຮົາສາມາດຈໍາລອງການໂຫຼດຢູ່ໃນຈຸດ, ເຊິ່ງເຮັດໃຫ້ພວກເຮົາສາມາດວັດແທກຕົວກໍານົດການອື່ນໆເຊັ່ນ: ຫນ່ວຍຄວາມຈໍາຫຼືການໃຊ້ແຜ່ນ. metrics ໄດ້ມາໂດຍການແລ່ນການທົດສອບທີ່ກໍານົດໄວ້ seq ພາຍໃຕ້ການຕິດຕາມຂະບວນການ Python. ລາວເກັບກໍາຂໍ້ມູນແມັດ getrusage() ການ ru_maxrss, ຈໍາ​ນວນ ru_oublock и ru_inblock ແລະເຄື່ອງຈັບເວລາງ່າຍດາຍ.

ໃນການທົດສອບນີ້, ST ໃຊ້ເວລາທໍາອິດທີ່ມີການບໍລິໂພກຫນ່ວຍຄວາມຈໍາສະເລ່ຍຕ່ໍາສຸດຂອງ 8 MB, ເຊິ່ງບໍ່ແປກໃຈທີ່ພິຈາລະນາວ່າແນວຄວາມຄິດຕົ້ນຕໍຂອງການອອກແບບແມ່ນຄວາມງ່າຍດາຍ. mlterm, xterm ແລະ rxvt ບໍລິໂພກຫຼາຍກວ່າເລັກນ້ອຍ - ປະມານ 12 MB. ຜົນໄດ້ຮັບທີ່ໂດດເດັ່ນອີກອັນຫນຶ່ງແມ່ນ Alacritty, ເຊິ່ງຕ້ອງການ 30 MB ເພື່ອດໍາເນີນການ. ຫຼັງຈາກນັ້ນ, ມີຈຸດເຊື່ອມຕໍ່ຂອງຄອບຄົວ VTE ທີ່ມີຕົວເລກຈາກ 40 ຫາ 60 MB, ເຊິ່ງແມ່ນຂ້ອນຂ້າງຫຼາຍ. ການບໍລິໂພກນີ້ສາມາດອະທິບາຍໄດ້ໂດຍຄວາມຈິງທີ່ວ່າເຄື່ອງໃຊ້ເຫຼົ່ານີ້ໃຊ້ຫ້ອງສະຫມຸດລະດັບສູງ, ຕົວຢ່າງ, GTK. Konsole ມາໃນສຸດທ້າຍດ້ວຍການບໍລິໂພກຄວາມຊົງຈໍາ 65MB ໃນລະຫວ່າງການທົດສອບ, ເຖິງແມ່ນວ່ານີ້ສາມາດໄດ້ຮັບການ justified ໂດຍລະດັບຄວາມກ້ວາງຂອງຄຸນນະສົມບັດຂອງຕົນ.

ເມື່ອປຽບທຽບກັບຜົນໄດ້ຮັບທີ່ຜ່ານມາໄດ້ຮັບເມື່ອສິບປີກ່ອນ, ທຸກໂຄງການເລີ່ມບໍລິໂພກຄວາມຊົງຈໍາຫຼາຍກວ່າເກົ່າ. Xterm ເຄີຍຕ້ອງການ 4 MB, ແຕ່ຕອນນີ້ມັນຕ້ອງການ 15 MB ພຽງແຕ່ໃນຕອນເລີ່ມຕົ້ນ. ມີການເພີ່ມຂຶ້ນທີ່ຄ້າຍຄືກັນໃນການບໍລິໂພກສໍາລັບ rxvt, ເຊິ່ງໃນປັດຈຸບັນຕ້ອງການ 16 MB ອອກຈາກກ່ອງ. Xfce Terminal ໃຊ້ເວລາເຖິງ 34 MB, ເຊິ່ງໃຫຍ່ກວ່າສາມເທົ່າກ່ອນ, ແຕ່ GNOME Terminal ຕ້ອງການພຽງແຕ່ 20 MB. ແນ່ນອນ, ການທົດສອບທີ່ຜ່ານມາທັງຫມົດໄດ້ຖືກປະຕິບັດກ່ຽວກັບສະຖາປັດຕະຍະກໍາ 32-bit. ທີ່ LCA 2012 Rusty Russell ບອກ, ວ່າມີຫຼາຍເຫດຜົນ subtle ຫຼາຍທີ່ສາມາດອະທິບາຍການເພີ່ມຂຶ້ນຂອງການບໍລິໂພກຄວາມຊົງຈໍາ. ໂດຍກ່າວວ່າ, ດຽວນີ້ພວກເຮົາອາໄສຢູ່ໃນຊ່ວງເວລາທີ່ພວກເຮົາມີຄວາມຊົງ ຈຳ gigabytes, ສະນັ້ນພວກເຮົາຈະຈັດການບາງຢ່າງ.

ແນວໃດກໍ່ຕາມ, ຂ້ອຍບໍ່ສາມາດຊ່ວຍໄດ້ແຕ່ຮູ້ສຶກວ່າການຈັດສັນຄວາມຊົງຈໍາຫຼາຍຂຶ້ນໃຫ້ກັບບາງສິ່ງບາງຢ່າງທີ່ເປັນພື້ນຖານຍ້ອນວ່າເຄື່ອງໃຊ້ຈ່າຍແມ່ນເສຍຊັບພະຍາກອນ. ໂປລແກລມເຫຼົ່ານີ້ຄວນຈະເປັນຂະຫນາດນ້ອຍສຸດຂອງຂະຫນາດນ້ອຍທີ່ສຸດ, ຄວນຈະສາມາດດໍາເນີນການໃນ "ກ່ອງ" ໃດກໍ່ຕາມ, ແມ້ແຕ່ກ່ອງເກີບ, ຖ້າພວກເຮົາມາຮອດຈຸດທີ່ພວກເຂົາຕ້ອງຕິດຕັ້ງລະບົບ Linux (ແລະເຈົ້າຮູ້ວ່າມັນຈະເປັນດັ່ງນັ້ນ. ). ແຕ່ດ້ວຍຕົວເລກເຫຼົ່ານີ້, ການໃຊ້ຄວາມຊົງຈໍາຈະກາຍເປັນບັນຫາໃນອະນາຄົດໃນສະພາບແວດລ້ອມໃດໆທີ່ແລ່ນຫຼາຍ terminals ນອກເຫນືອຈາກຄວາມສາມາດທີ່ເບົາທີ່ສຸດແລະຈໍາກັດຫຼາຍທີ່ສຸດ. ເພື່ອຊົດເຊີຍສໍາລັບການນີ້, GNOME Terminal, Konsole, urxvt, Terminator ແລະ Xfce Terminal ມີໂຫມດ Daemon ທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດຄວບຄຸມຫຼາຍ terminals ຜ່ານຂະບວນການດຽວ, ຈໍາກັດການບໍລິໂພກຫນ່ວຍຄວາມຈໍາຂອງພວກເຂົາ.

ໃນລະຫວ່າງການທົດສອບຂອງຂ້ອຍ, ຂ້ອຍໄດ້ພົບກັບຜົນໄດ້ຮັບທີ່ບໍ່ຄາດຄິດອີກອັນຫນຶ່ງກ່ຽວກັບ disk read-write: ຂ້ອຍຄາດວ່າຈະບໍ່ເຫັນຫຍັງເລີຍຢູ່ທີ່ນີ້, ແຕ່ມັນປາກົດວ່າບາງ terminals ຂຽນຂໍ້ມູນ voluminous ທີ່ສຸດໃນແຜ່ນ. ດັ່ງນັ້ນ, ຫໍສະຫມຸດ VTE ຮັກສາ buffer ເລື່ອນຢູ່ໃນແຜ່ນ (ຄຸນນະສົມບັດນີ້ ໄດ້​ສັງ​ເກດ​ເຫັນ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​ໃນ​ປີ 2010​, ແລະນີ້ຍັງເກີດຂຶ້ນ). ແຕ່ບໍ່ເຫມືອນກັບການປະຕິບັດເກົ່າ, ໃນປັດຈຸບັນຢ່າງຫນ້ອຍຂໍ້ມູນນີ້ຖືກເຂົ້າລະຫັດໂດຍໃຊ້ AES256 GCM (ຈາກເວີຊັນ 0.39.2). ​ແຕ່​ມີ​ຄຳ​ຖາມ​ທີ່​ສົມ​ເຫດ​ສົມ​ຜົນ: ສິ່ງ​ທີ່​ພິ​ເສດ​ກ່ຽວ​ກັບ​ຫໍສະໝຸດ VTE ນັ້ນ​ແມ່ນ​ຕ້ອງ​ມີ​ວິທີ​ທີ່​ບໍ່​ໄດ້​ມາດຕະຖານ​ໃນ​ການ​ປະຕິບັດ...

ສະຫລຸບ

ໃນສ່ວນທໍາອິດຂອງບົດຄວາມ, ພວກເຮົາໄດ້ພົບເຫັນວ່າຈຸດທີ່ໃຊ້ VTE ມີຊຸດຄຸນສົມບັດທີ່ດີ, ແຕ່ຕອນນີ້ພວກເຮົາເຫັນວ່າມັນມາພ້ອມກັບຄ່າໃຊ້ຈ່າຍໃນການປະຕິບັດບາງຢ່າງ. ໃນປັດຈຸບັນຄວາມຊົງຈໍາບໍ່ແມ່ນບັນຫາເພາະວ່າທຸກ terminals VTE ສາມາດຄວບຄຸມໄດ້ໂດຍຜ່ານຂະບວນການ Daemon, ເຊິ່ງຈໍາກັດຄວາມຢາກອາຫານຂອງພວກເຂົາ. ຢ່າງໃດກໍຕາມ, ລະບົບເກົ່າທີ່ມີຂໍ້ຈໍາກັດທາງດ້ານຮ່າງກາຍກ່ຽວກັບຈໍານວນ RAM ແລະ kernel buffers ອາດຈະຍັງຕ້ອງການ terminals ຮຸ່ນກ່ອນຫນ້າ, ເພາະວ່າພວກເຂົາໃຊ້ຊັບພະຍາກອນຫນ້ອຍລົງ. ເຖິງແມ່ນວ່າສະຖານີ VTE ປະຕິບັດໄດ້ດີໃນການທົດສອບຜ່ານ (ເລື່ອນ), ຄວາມແຝງຂອງການສະແດງຜົນຂອງພວກມັນແມ່ນສູງກວ່າເກນທີ່ກໍານົດໄວ້ໃນຄູ່ມືຜູ້ໃຊ້ GNOME. ນັກພັດທະນາ VTE ອາດຈະພິຈາລະນາເລື່ອງນີ້. ຖ້າພວກເຮົາຄໍານຶງເຖິງວ່າເຖິງແມ່ນວ່າສໍາລັບຜູ້ໃຊ້ Linux ຈົວທີ່ພົບຢູ່ປາຍຍອດກໍ່ເປັນສິ່ງທີ່ຫຼີກລ່ຽງບໍ່ໄດ້, ພວກເຂົາສາມາດເຮັດໃຫ້ມັນເປັນມິດກັບຜູ້ໃຊ້ຫຼາຍຂຶ້ນ. ສໍາລັບ geeks ທີ່ມີປະສົບການ, ການປ່ຽນຈາກ terminal ເລີ່ມຕົ້ນເຖິງແມ່ນວ່າອາດຈະຫມາຍຄວາມວ່າຄວາມເມື່ອຍຕາຫນ້ອຍແລະຄວາມສາມາດໃນການຫຼີກເວັ້ນການບາດເຈັບແລະພະຍາດທີ່ກ່ຽວຂ້ອງກັບການເຮັດວຽກໃນອະນາຄົດອັນເນື່ອງມາຈາກການເຮັດວຽກຍາວ. ແຕ່ຫນ້າເສຍດາຍ, ພຽງແຕ່ xterm ແລະ mlterm ເກົ່ານໍາພວກເຮົາໄປສູ່ຂອບເຂດ magic ping ຂອງ 10 milliseconds, ເຊິ່ງບໍ່ສາມາດຍອມຮັບໄດ້ສໍາລັບຫຼາຍໆຄົນ.

ການວັດແທກ Benchmark ຍັງໄດ້ສະແດງໃຫ້ເຫັນວ່າເນື່ອງຈາກການພັດທະນາສະພາບແວດລ້ອມກາຟິກຂອງ Linux, ນັກພັດທະນາຕ້ອງເຮັດການປະນີປະນອມຈໍານວນຫນຶ່ງ. ຜູ້ໃຊ້ບາງຄົນອາດຈະຕ້ອງການເບິ່ງຜູ້ຈັດການປ່ອງຢ້ຽມປົກກະຕິຍ້ອນວ່າພວກເຂົາສະຫນອງການຫຼຸດຜ່ອນ ping ຢ່າງຫຼວງຫຼາຍ. ແຕ່ຫນ້າເສຍດາຍ, ມັນບໍ່ສາມາດວັດແທກຄວາມລ່າຊ້າສໍາລັບ Wayland: ໂປຣແກຣມ Typometer ທີ່ຂ້ອຍໃຊ້ໄດ້ຖືກສ້າງຂື້ນສໍາລັບສິ່ງທີ່ Wayland ຖືກອອກແບບມາເພື່ອປ້ອງກັນ: spying ໃນປ່ອງຢ້ຽມອື່ນໆ. ຂ້າພະເຈົ້າຫວັງວ່າ Wayland compositing ປະຕິບັດໄດ້ດີກວ່າ X.org, ແລະຂ້າພະເຈົ້າຍັງຫວັງວ່າໃນອະນາຄົດຜູ້ໃດຜູ້ຫນຶ່ງຈະຊອກຫາວິທີທີ່ຈະວັດແທກ latency ໃນສະພາບແວດລ້ອມນີ້.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com