Show HN: Shpool, a Lightweight Tmux Alternative

Original Article ↗ Hacker News Discussion ↗

Purpose and Positioning of Shpool

  • Designed as a session persistence tool rather than a full terminal multiplexer.
  • Intended to be “lightweight” mainly in cognitive/feature terms: minimal setup, solve dropped-connection and long-running-job problems, then get out of the way.
  • Philosophy: window/layout management should be handled by the OS/window manager or terminal emulator, not by the persistence layer.

Comparisons to tmux, screen, and related tools

  • Many see it as closer to screen/dtach/abduco/diss than to full tmux, since it doesn’t do panes, splits, or window tiling.
  • Some users mostly want persistence and consider tmux’s layout features “bloat” for that purpose; others rely heavily on panes/windows and don’t see shpool as a real alternative.
  • GNU screen and tmux are noted as roughly equivalent today; shpool omits multiplexing but competes on simplicity.

Scrollback, copy-paste, and performance

  • Key selling point: does not interfere with native terminal scrollback and mouse-based copy-paste, which tmux/screen often alter.
  • Internally keeps an in-memory VT100 terminal state to redraw after reconnect without losing scrollback.
  • Some argue tmux’s separate scrollback is a feature; others find tmux’s mouse/clipboard behavior and latency frustrating.

Networking and session robustness

  • Compared to mosh and EternalTerminal: those operate at the network layer and handle roaming/UDP/TCP; shpool runs only on the remote host.
  • Some people currently stack mosh + tmux and see shpool as a way to reduce duplication.

Installation and platform notes

  • Rust-based; some concern about compatibility with older distro toolchains (e.g., Debian stable), though static binaries or local builds are suggested as workarounds.
  • Systemd user units and Debian packaging are discussed; one user shares build steps.
  • macOS support is not yet available but is mentioned as being worked on.

Limitations, bugs, and edge cases

  • Currently oriented toward reconnecting from the same terminal type; TERM/terminfo changes across clients are described as hard/“unclear” to solve.
  • Does not yet support multiple simultaneous attachments to one session; several commenters want this for pairing or multi-device workflows.
  • One report of severe memory usage (~1.4 GB) after repeated find + detach/attach cycles.
  • Some text-mode-only users note that, for them, tmux alone is still lighter than running a GUI/window manager plus shpool.