Tmux is worse-is-better
Tmux’s popularity as a terminal multiplexer is defended here against criticism from the Kitty terminal author, who argues that tools like tmux are inefficient “middlemen” that duplicate parsing work and slow modern terminals. Many engineers counter that tmux’s remote persistence, workspace management, and portability across servers far outweigh any performance overhead, especially for long-running or fragile SSH sessions. Alternatives such as screen, Zellij, Byobu, terminal-native multiplexing (e.g., iTerm2 and WezTerm), and editor-based terminals are mentioned, but most commenters treat tmux-like persistence as the indispensable feature.
Core value of tmux / screen
- Many see basic tmux/screen knowledge (start, split, detach/attach) as essential for anyone doing SSH work.
- Primary practical value: remote persistence and workspace persistence, not just splitting panes.
- Users like having a long‑lived “remote desktop” where shells, editors, and layouts survive disconnects, reboots, and laptop sleep.
Remote persistence & workflows
- Common pattern: always start work inside tmux on remote servers; detach instead of exit; reattach from anywhere.
- Used for long‑running jobs, debugging sessions, kernel upgrades, and multi‑service dev environments.
- Some combine tmux with mosh and sometimes VPN/WireGuard for resilient, stealthier remote work.
- Critics note you can script long jobs via
at,nohup, services, or Emacs/Tramp instead; supporters argue tmux persistence is simpler and more general.
tmux vs screen and other tools
- screen and tmux are functionally similar; several long‑time screen users switched due to truecolor, Unicode, hyperlinks, better scrollback, and plugins.
- Others stick with screen for stability and decades‑old muscle memory.
- Byobu wraps tmux/screen with friendlier keys and mouse menus; dtach/abduco+dvtm offer “persistence only” with minimal features.
- Zellij is praised for saner defaults and UX, but criticized for visual clutter and some job‑control issues.
Terminal multiplexers vs terminal‑built features
- Some modern terminals (kitty, WezTerm, iTerm2) provide their own multiplexing or tmux integration, claiming better performance and UX.
- Pro‑tmux side: works everywhere (including bare consoles), is editor/terminal‑agnostic, and its remote persistence cannot be fully replaced by local Tab/Pane features.
- Pro‑terminal side: multiplexers double parsing of all bytes, complicate new terminal features, and can be replaced where you control both client and server.
Usability, config, and UX pain points
- Complaints: arcane defaults, awkward keybindings, mouse quirks, copy/paste difficulties, nested sessions confusion, and occasional backward‑incompatible config changes.
- Defenders say: you rarely touch config after initial setup; keybindings and mouse support are fully customizable; minimal config can work fine.
Performance, “worse is better”, and standards
- One camp argues tmux’s extra parsing and pipes halve throughput and add latency, and that multiplexers are a “hack” distorting the simple TTY model.
- Others counter that on modern hardware this overhead is negligible versus the practical gains, calling this a classic “worse is better” trade‑off.
- Debate extends to terminal standards: some emphasize compatibility with existing escape‑sequence conventions; others push new protocols even if multiplexers lag.