twin: a text-mode windowing environment with networked displays

What a text-mode window system actually is

twin is described as a text-based windowing environment, and the comparison in the repository description is the fastest way to understand it: a text-mode equivalent of an X11 server plus a VNC server. That means two things at once. There is a server that owns the screen state, the window tree, the input routing and the drawing, and there are clients that connect to it. The clients are programs that draw into their own window and receive keyboard and mouse events, and they do not need to be on the same machine as the display. On top of that sits a window manager, so you get overlapping, movable, resizable windows in a text grid rather than a single full-screen program. This is a different idea from a terminal multiplexer. A multiplexer such as tmux manages sessions of shell processes on one machine, while twin is a display server for text, and its own documentation presents a tutorial as a quite complete tour of the features including the user interface, how to use twin clients, compression, attaching and detaching displays, and fonts.

The display backends are the interesting engineering decision

The list of supported displays is where twin stops being a toy. It runs on plain text terminals, which means the Linux console, twin's own terminal emulator, or any termcap or ncurses compatible terminal. It runs under X11, where it is used as a multi-window xterm. It runs inside itself, so you can display a twin on another twin, which is the kind of recursion that usually breaks a display protocol. And there is twdisplay, a general network-transparent display client, whose purpose is to attach and detach more displays on the fly. The architecture splits into a server/ directory for the display server, clients/ for the client programs, and libs/ for the shared libraries, with include/ holding the public headers. The protocol is documented for programmers in docs/libtw.txt for C clients and docs/libtw++.txt for C++ clients, and both are marked INCOMPLETE in the tree, which is worth knowing before you plan to write a client. The practical consequence of the network-transparent design is that a session survives the display going away, which is the property that makes twin usable over a flaky link or on a device that sleeps.

Compiling it: autotools, a C++ compiler, and a set of warnings

twin is built with the classic GNU autotools flow, and the repository shows it plainly with configure.ac, Makefile.am, aclocal.m4, acinclude.m4, a configure script already generated in the tree, and an m4/ directory. The impatient path is three commands, and the last one needs root:

  ./configure
  make

followed by running as root:

  make install

On Linux you then also run ldconfig as root, and on FreeBSD the equivalent is ldconfig -R. The build needs a Bourne-shell or compatible such as bash, dash or ash, make, an ANSI C compiler such as gcc or clang, and a C++ 98 compiler such as g++ or clang++. The packages the documentation strongly recommends before compiling are x11-dev, xft-dev, ncurses-dev and zlib-dev, with the names varying by distribution, and on Linux also gpm-dev, which is the Linux mouse daemon interface. The warning about manual configuration is emphatic: if you enable options that ./configure disabled, the build will almost certainly fail, so the docs/Configure file, which describes every single configuration option, is a reference rather than a place to start. There is a separate README.porting with tips for compiling on unsupported systems, and README.git for building from a git checkout.

Configuration lives in twinrc, and the docs are honest about its size

The configuration model is one file, and the repository treats it as an artifact worth reading. twinrc at the root is described as a detailed example of a look and feel configuration file for ~/.config/twin/twinrc. The documentation set is well organised by audience. The tutorial covers the user interface, clients, compression, attaching and detaching displays, fonts, and the caveats for system administrators, and it is also where the detailed compiling and installing instructions live in sections 3 and 4. The Configure document explains the meaning of every single configuration option. For developers there are the two client API references, and a Changelog.txt plus a TODO/ directory in the tree. The fonts/ directory is there because font handling is part of the feature set rather than an afterthought, which matters for a system whose whole point is rendering text well on a grid.

The licence is split between the core and its libraries

The licensing is a two-part arrangement and it is stated precisely in the README. The COPYING file covers the twin server and clients as GPL'ed software, while COPYING.LIB covers the libraries libtutf and libtw, which are LGPL'ed. Both files are in the repository root, so the distinction is visible rather than buried. For most users this matters only if you intend to link against libtw or libtw++ in your own program, because the LGPL is the more permissive of the two and is the licence the client API is published under. The core, which is the bulk of the code, is GPL-2.0. There is also a BUGS file at the root, and the tree includes an admin/ directory for administrative tooling and a contrib/ directory for contributed extras, plus scripts/ and a test/ directory, so the project has the supporting material of a maintained project even though the release cadence is slow.

The version numbers disagree, and that is a signal about the project

The repository lists a single release, v1.0.0, dated 2026-01-03, while the README header still says Version 0.9.1. That mismatch is not a bug report, it is a description of the project's state. The author writes in the first person in the README, notes that twin has been tested on Linux across i386, x86_64, arm, arm64, PowerPC, Alpha and Sparc, on macOS on x86_64 and arm64, on FreeBSD on i386 and x86_64, and on Android on arm64 both on termux and UserLand, and then says plainly that there has not yet been a chance to seriously test it on other systems. The last push to the repository was on 2026-08-03. So the code is still being touched, but not on a release rhythm, and the documentation has drifted from the version numbering. For an evaluator that means twin is a working, long-lived project with a low and irregular update rate rather than a stalled one.

Where twin is the wrong tool, and what to use instead

The obvious limit is that this is a text-mode system. If the goal is a graphical desktop, twin under X11 is a multi-window xterm, which is a thin thing to build on, and the honest comparison is with a real display server rather than with another terminal multiplexer. The second limit is the shape of the deliverable. twin is a C project with an autotools build, a documented but INCOMPLETE client API, and a large configuration file, so adopting it means compiling it, tuning twinrc, and probably writing your own client, which is a different commitment from installing a package. The third limit is where the termcap and ncurses world stops: on a display that does not speak those conventions, twin needs one of its other backends. The realistic alternative for many of these cases is a terminal multiplexer such as tmux or screen, which manage multiple detachable sessions without twin's windowing or its attach/detach display model. The choice is between a multiplexer that manages sessions and a display server that manages screens, and the deciding factor is whether you need a program to own a rectangular region of the terminal and survive the terminal going away.

Editorial conclusion

Adopt twin if you need a windowing environment on plain text terminals, on a serial or embedded console, or across a network where attaching and detaching displays matters, and if you are prepared to compile from source and tune a configuration file. Do not adopt it as a general desktop: this is a text-mode system, and the graphical path is X11 where twin behaves as a multi-window xterm. Before you build, read the tutorial's caveats for system administrators and check the dependency list, in particular ncurses, zlib, X11 and Xft development packages, since the manual configure path is explicitly warned against, and note the licensing split where the server and clients are GPL-2.0 while libtutf and libtw are LGPL.

Frequently asked questions

Official sources

1. cosmos72/twin on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases