ผู้ใช้ tmux มายาวนานได้จุดประกายการถกเถียงอย่างเข้มข้นในชุมชนนักพัฒนาโดยการบันทึกเส้นทางการเปลี่ยนจาก terminal multiplexer ยอดนิยมตัวนี้ หลังจากใช้ tmux มา 7 ปีทุกวัน พวกเขาได้เปลี่ยนไปใช้การรวมกันระหว่าง shpool สำหรับการคงอยู่ของ session และการจัดการหน้าต่าง terminal แบบดั้งเดิม โดยอ้างถึงปัญหาด้านประสิทธิภาพและความซับซ้อน
ข้อโต้แย้งต่อ Terminal Multiplexers
ข้อโต้แย้งหลักมุ่งเน้นไปที่ปัญหาสถาปัตยกรรมพื้นฐาน: terminal multiplexers อย่าง tmux ทำหน้าที่เป็นตัวกลางที่ต้องแปลและปรับเปลี่ยน escape codes เพื่อให้ทำงานกับแนวคิดของหน้าต่างและ session สิ่งนี้สร้างสิ่งที่นักวิจารณ์เรียกว่า complexity cascade - ชั้นเพิ่มเติมที่อาจทำให้เกิดปัญหาการแสดงผลสี ปัญหา scrollback และปัญหาความเข้ากันได้กับฟีเจอร์ terminal ใหม่ๆ นักพัฒนา terminal Kitty ได้แสดงความคิดเห็นอย่างชัดเจนเกี่ยวกับเรื่องนี้ โดยโต้แย้งว่า multiplexers ทำให้นวัตกรรมในระบบนิเวศ terminal ทั้งหมดช้าลงด้วยการกำหนดให้ทุกฟีเจอร์ใหม่ต้องทำงานผ่านชั้นการแปลของพวกมัน
นักพัฒนาหลายคนได้ประสบปัญหาเหล่านี้โดยตรง ชุดสีที่ดูสมบูรณ์แบบใน terminal แบบเดี่ยวอาจดูซีดจางหรือไม่ถูกต้องเมื่อดูผ่าน tmux การเลือกด้วยเมาส์บางครั้งเสียหายข้ามแผง split ทำให้การดำเนินการ copy-paste น่าหงุดหงิด ปัญหาเหล่านี้ไม่ใช่ปัญหาที่ทำลายการใช้งานสำหรับผู้ใช้ส่วนใหญ่ แต่แสดงถึงประเภทของความเสียดสีที่สะสมตลอดเวลา
โซลูชันทางเลือกและการแลกเปลี่ยน
การค้นหาทางเลือกของ tmux ได้นำไปสู่แนวทางที่น่าสนใจหลายอย่าง เครื่องมืออย่าง dtach, abduco และ shpool มุ่งเน้นเฉพาะการคงอยู่ของ session - ความสามารถในการแยกออกและเชื่อมต่อกลับไปยังกระบวนการที่กำลังทำงาน แนวทางปรัชญา Unix นี้หมายถึงการสละฟีเจอร์การจัดการหน้าต่างของ tmux แต่ได้รับ scrollback ของ terminal แบบดั้งเดิมและหลีกเลี่ยงปัญหาการแปล escape code
อย่างไรก็ตาม ความเป็นจริงนั้นยุ่งเหยิงกว่าทฤษฎี ทางเลือกส่วนใหญ่เหล่านี้ต่อสู้กับฟังก์ชันพื้นฐานที่ tmux จัดการได้ดี ผู้เขียนพบว่าเครื่องมือหลายตัวไม่สามารถแยกออกได้อย่างถูกต้องเมื่อทำงานภายใน Neovim ซึ่งจะเป็นปัญหาใหญ่สำหรับนักพัฒนาหลายคน มีเพียง shpool เท่านั้นที่ให้วิธีแก้ไขผ่านกลไกการแยกออกแบบคำสั่ง ทำให้สามารถผสานรวมกับ keybindings ของ editor ได้
การเปรียบเทียบทางเลือกอื่นของ tmux
เครื่องมือ | วัตถุประสงค์ | ข้อดี | ข้อเสีย |
---|---|---|---|
dtach | การคงอยู่ของเซสชัน | เรียบง่าย น้ำหนักเบา | ฟีเจอร์จำกัด การแยกตัวมีปัญหา |
abduco | การคงอยู่ของเซสชัน | หลักปรัชญา Unix | ปัญหาการทำงานพื้นฐาน |
shpool | การคงอยู่ของเซสชัน | การแยกตัวแบบคำสั่ง การเล่นบัฟเฟอร์ย้อนหลัง | ไม่สามารถคืนสถานะเทอร์มินัลได้อย่างเหมาะสม |
WezTerm | เทอร์มินัลเต็มรูปแบบพร้อมการทำงานหลายช่อง | ฟีเจอร์ดั้งเดิม ไม่มีปัญหารหัสหลีก | ต้องการการกำหนดค่า ไม่สามารถใช้ได้ทั่วไป |
Ghostty | โปรแกรมจำลองเทอร์มินัลสมัยใหม่ | เร็ว ฟีเจอร์ดั้งเดิม | ฟีเจอร์การทำงานหลายช่องยังจำกัดในปัจจุบัน |
ความท้าทายของ SSH และการพัฒนาระยะไกล
สำหรับนักพัฒนาที่ทำงานผ่านการเชื่อมต่อ SSH เป็นหลัก คำถามเรื่องการจัดการหน้าต่างกลายเป็นเรื่องซับซ้อนมากขึ้น แท็บ terminal ในเครื่องและฟีเจอร์ window manager ไม่ช่วยอะไรเมื่องานทั้งหมดของคุณเกิดขึ้นภายใน SSH session เดียว โซลูชันที่เสนอเกี่ยวข้องกับการใช้เทคนิคการกำหนดค่า SSH เพื่อเชื่อมต่อกับ shpool sessions ที่มีชื่อโดยอัตโนมัติ รวมกับ autossh สำหรับการเชื่อมต่อใหม่อัตโนมัติ
แนวทางนี้สร้างการจัดการ session ของ tmux ขึ้นใหม่ในระดับ SSH โดยใช้การเชื่อมต่อเองเป็นกลไก multiplexing แม้จะฉลาด แต่ต้องการการตั้งค่าและการกำหนดค่ามากกว่าการรัน tmux บนเครื่องระยะไกลอย่างง่ายดาย
การกำหนดค่า SSH สำหรับการผสานรวม shpool
Host *
ServerAliveInterval 60
ServerAliveCountMax 3
Host vm
HostName 192.168.88.xxx
User erock
IdentityFile ~/.ssh/id_ed25519
RemoteCommand shpool attach -l %k
RequestTTY yes
ControlPath ~/.ssh/cm-%r@%h:%p
ControlMaster auto
ControlPersist 10m
การกำหนดค่านี้ช่วยให้สามารถเชื่อมต่อไปยัง shpool sessions ที่มีชื่อเฉพาะได้โดยอัตโนมัติ โดยใช้คำสั่งเช่น ssh d.chat
หรือ ssh d.dot
ปฏิกิริยาของชุมชนและการใช้งานในโลกจริง
การตอบสนองของชุมชนนักพัฒนามีทั้งแบบผสมผสานแต่เต็มไปด้วยความหลงใหล ผู้ใช้ tmux มายาวนานหลายคนตั้งคำถามว่าทางเลือกที่เสนอนั้นแก้ปัญหาจริงหรือแค่สร้างปัญหาใหม่ การตั้งค่าที่อธิบายในบทความต้องการไฟล์การกำหนดค่าหลายไฟล์ การตั้งค่า SSH แบบกำหนดเอง และวิธีแก้ไขสำหรับฟังก์ชันพื้นฐานที่ tmux ให้มาทันที
นี่เขียนสำหรับกลุ่ม Linux-on-the-Desktop และดีสำหรับพวกเขา แต่ tmux เปล่งประกายจริงๆ สำหรับคนที่ใช้ MacBooks กับ iTerm2 การผสานรวม tmux ของมันดีมากจนหายไปในเวิร์กโฟลว์ของฉัน
ผู้ใช้บางคนชี้ไปที่ terminal emulators สมัยใหม่อย่าง WezTerm และ Ghostty เป็นทางเลือกที่ดีกว่า โดยเสนอฟีเจอร์ multiplexing ในตัวโดยไม่มีปัญหาการแปล escape code terminals เหล่านี้สามารถให้ฟังก์ชันคล้าย tmux แบบดั้งเดิม แม้ว่าจะต้องเรียนรู้เครื่องมือใหม่และอาจไม่พร้อมใช้งานในทุกระบบ
ภาพรวมใหญ่
การถกเถียงนี้สะท้อนความตึงเครียดที่กว้างขึ้นในการพัฒนา terminal ระหว่างความเข้ากันได้แบบย้อนหลังและนวัตกรรม Terminal multiplexers ตอบสนองความต้องการจริง - การคงอยู่ของ session การจัดการหน้าต่าง และความสามารถในการเขียนสคริปต์ - แต่สถาปัตยกรรมของพวกมันสร้างข้อจำกัดในสิ่งที่ terminal emulators สามารถดำเนินการได้ คำถามไม่ใช่ว่า tmux ดีหรือแย่ แต่ประโยชน์ของมันมีน้ำหนักมากกว่าต้นทุนของระบบนิเวศหรือไม่
สำหรับนักพัฒนาส่วนใหญ่ tmux ยังคงเป็นตัวเลือกที่เป็นจริง มันทำงานได้ทุกที่ มีระบบนิเวศที่เป็นผู้ใหญ่ และแก้ปัญหาจริงด้วยการกำหนดค่าขั้นต่ำ ทางเลือกที่อธิบายต้องการเวลาตั้งค่าอย่างมากและอาจไม่ให้ฟังก์ชันเทียบเท่า อย่างไรก็ตาม สำหรับผู้ใช้ที่เต็มใจลงทุนในการกำหนดค่าและที่ทำงานในสภาพแวดล้อมที่ควบคุมได้เป็นหลัก แนวทางดั้งเดิมสามารถเสนอประสบการณ์ที่สะอาดกว่าด้วยการสนับสนุนฟีเจอร์ terminal ที่ดีกว่า
การอภิปรายเน้นให้เห็นว่าแม้แต่เครื่องมือที่เป็นผู้ใหญ่และได้รับการยอมรับอย่างกว้างขวางก็สามารถมีข้อจำกัดทางสถาปัตยกรรมพื้นฐานที่เห็นได้ชัดเฉพาะเมื่อเทคโนโลยีพัฒนา ระบบนิเวศ terminal จะเลื่อนไปเกิน multiplexers ในที่สุดหรือไม่ยังคงต้องรอดู แต่การสนทนาได้ทำให้นักพัฒนาตระหนักถึงการแลกเปลี่ยนที่เกี่ยวข้องในการเลือกเครื่องมือของพวกเขามากขึ้นอย่างแน่นอน
อ้างอิง: YOU MIGHT NOT NEED TMUX