Differences between Tmux vs Screen (2015)
wtanaka.com
wtanaka.com
These two terminal multiplexers are really an end-run around unfulfilled wants in the way that the console subsystem should work by default. Want to be able to arbitrarily detach from a session? Well, then we should have OS-level APIs exposed that allow for that. Instead, what happened is the whole thing gets reimplemented in user space two levels deep (one for your GUI terminal emulator, then once again for the TUI terminal emulator you run inside that—either tmux or screen). And we've hobbled along on top of that for decades.
To me, this is strongly reminiscent of software hematomas that Kiczales writes about. So I don't understand how anyone could be passionate about it, except maybe to passionately question why we're fine with continuing to do things this way, instead of stepping back and after a sober thought concluding that this whole thing is pretty silly.
Graphical IDEs moved the idea of a session away from terminals, and the ephemeral nature of containers discouraged attaching sessions to them at all.
So things like screen and tmux are now popular only with a niche crowd. Granted, it's one that has strong representation here on HN.
What I'm talking about is running an IDE as a server and being able to connect to the same session e.g. from different machines which do not run a copy of IDE.
Imagine running all the real-time code analysis tools on a beefy corporate server while the editor component runs on your laptop. Imagine attaching to someone else's session to collectively debug a problem or review code, right in the IDE. Imagine your laptop losing connectivity / running out of power, being reconnected and recharged, and connecting right back to the IDE that never lost its state. Imagine running the IDE, or parts of it, in preconfigured and isolated containers / VMs.
The alternative, and maybe a better way to do this, is a FUSE-like system, like Expandrive. Lazily fetches files from remote.
> The most mature usage scenario that eclim provides, is the running of a headless eclipse server and communicating with that server inside of vim.
I've occasionally had X crash. After waiting for my desktop to reappear, I can reattach to my dtached DVTM session, spawn new emacsclient windows and be back to exactly where I was. The main application I use which doesn't do this is my browser, which is tied to the X session.
I do all of this locally, but at an old job I had to use a Windows desktop. Since we had Linux servers for development, I used them to run emacs-server. Each day I'd boot my Windows machine and use Cygwin/X to spawn a fresh Emacs window, picking up right where I left off the previous day. Just make sure to avoid GTK+ for the GUI, since there's a longstanding bug which prevents reattaching after an X server quits. I just used the Lesstif GUI instead.
I warmly recommend xpra, although it is another screen/tux/not-a-builtin
But it does allow one to attach to running X applications, unlike screen or tmux.
We could be using an app-centric XML-like language¹ for the UI, and an app-centric protocol versus a stateless² one where we apply hacks like cookies and WebSockets to. Instead we're hacking on top of a document-oriented system, and the hacks feel like they're 10 layers deep now.
¹ Similar to XAML or XUL, in concept and example.
² Statelessness is a great default, but when you need it, it shouldn't be an awful hack.
All of those things are significantly different than a mainframe/term setup
It's not actually true (unicode alone is a big improvement), but even if it was, so what? If a technology already fulfilled those needs pretty well, why would you expect major improvements to arise? The improvements come from the fact that you don't have to restrict yourself to text and labels.
Maybe not, but you certainly shouldn't expect a regression, which is exactly what we're witnessing.
And there's a fair bit of truth to that.
You can: just write a C# or whatever app, and use some stateful protocol.
In any case, I find the whole "layers deep" to be a major overstatement. WebSockets are essentially framed TCP sockets, with a single initial handshake that looks like HTTP. They are not a "layer" over HTTP or anything like that.
The uglier part is that screen needs to communicate the UI state to a terminal emulator. Theoretically, you could have screen expose an API and have a client-side GUI client directly display a UI, and that is even probably a good idea (I'll like a Qt tmux client that can talk to a remote tmux with JSON over SSH), but nobody bothered to implement it yet, and a "VT100 over serial" client can be used without running new software at the "user endpoint".
Telnet was just a protocol for serving whatever you'd get by connecting to the serial port, but multiplexed and over IP. Users got PTYs for their "session" and then login(8) was [usually] invoked.
Then, we got IPSec, to layer your telnet PTY tunnel inside an encrypted tunnel.
But SSH kind of turned things inside-out: it encapsulated a PTY inside an auth'ed login session which it managed itself, inside a carrier (e.g. TCP) which it also managed itself. It threw out the whole PTY-as-session concept (with PTY-managed-by-a-shell job control with Ctrl+Z, multiple PTY's-stdout writers to watch background jobs, etc.), creating its own sessions in the form of SSH "channels", and allowing the user to invoke arbitrary programs on the remote (with its own sshd_config specifying what is allowed) rather than handing off to the centralized PTY "terminal server" of login(8) to decide what to do with this session based on its origin device.
Until SSH, screen(1) and tmux(1)—and script(1) and nohup(1) and watch(1) and... were all just "enhancements" you'd run on top of a PTY as basically different shells that manage the PTY's jobs differently. Like different desktop environments manage windows differently. They might use additional PTYs to do this, but it was an implementation detail, and even then mostly only a hack—added later, not in the original designs—to ensure libcurses programs would work inside these.
But with SSH, since you lost the single encapsulating PTY session-group concept, we now saw things like tmux(1) and screen(1)'s PTYs as multiple root sessions. Now it was more like SSH was the terminal server, and screen/tmux was virtual desktops. Completely different paradigm, losing the thread of what PTYs were "for" in the process.
Are we talking about SSH? Because that's SSL, not ipsec.
The original point of SSH was that it didn't expect the client and the server to be part of the same administrative domain—i.e. it didn't expect a sysadmin to have been involved in advance to pair the devices and define a tunnel. This is why SSH's auth didn't, for the longest time, support any kind of centralized certificate-based PKI: it was for the cases where there wasn't a central authority in common, but rather just two peers that happened to want to talk securely—perhaps without the consent of their respective sysadmins; perhaps even despite the policies of their respective sysadmins.
SSH's "on the spot, look at my keys" auth has become so ubiquitous that sysadmins seem to have forgotten that, most of the time, they do control the administrative domain both devices are under, and can in fact just pair them using e.g. client certificates issued by a private X.509 CA. Fingerprint-based auth should be seen as a last resort, not a first resort; and, likewise, Telnet shouldn't be seen as a last resort, but rather a core tool serving a core purpose in a layered design: enhancing a "local-equivalent" (LAN or VPN) IP link into being a PTY session, upon which any number of things can be run. (For example, "dial-in" MUDs, of which a number still exist.)
In a way, but ptys both don't do the "UI state" thing well, and don't do the "server" thing well - you can't really "take over" the controlling side of a pty easily.
> Now it was more like SSH was the terminal server, and screen/tmux was virtual desktops.
In the normal use of SSH+screen (`ssh -t foobaz screen -r`), SSH just tunnels the VT100-over-serial over the network, and provides the needed authentication and routing.
That's what PTYs are.
> Instead, what happened is the whole thing gets reimplemented
No, that's a feature. The fact that you can use "neutral" OS services in different ways is a good sign. They provide PTYs and others build Screen, Tmux, dtach, ... and I'm sure others have come up with creatives uses for them too.
> in user space two levels deep (one for your GUI terminal emulator, then once again for the TUI terminal emulator you run inside that—either tmux or screen
I don't think so. We have GUI terminal emulators because there isn't much terminals around anymore, so the second "level" is accidental, not essential.
As for the first "level", this is the VT100 (or something like that) specification, which is used by tons of other programs, not just Tmux and Screen.
Furthermore, the greatness of separating "levels" is that I can run those programs from anywhere. For instance, Windows Putty + GNUScreen allows me to temporary use my Windows machine which is next my Linux machine as a second screen.
If I wanted to do the opposite (use my Linux machine as a second screen for my Windows machine), I think the solution would probably a lot more heavy, or simply impossible given how old is this machine.
> So I don't understand how anyone could be passionate about it, except maybe to passionately question why we're fine with continuing to do things this way, instead of stepping back and after a sober thought concluding that this whole thing is pretty silly
In fact, at day-job I work with 3 Linux servers. I have a screen session for each, each in one full screen terminal window on its own virtual desktop. All this from a 15 years old machine running a Mandrake so outdated that I can't update it anymore (don't ask).
This software you call "silly" provides a lot of services for very cheap. From network failure protection to session sharing. Not acknowledging this is the silly thing, if you ask me.
Most systems programmers are bought all the way into the Unix/worse-is-better mindset and are too afraid to ever question whether things could be designed with proper abstractions.
That's fairly arrogant. Have you ever considered that we simply looked at the alternatives, observed the hell that followed, and beat a hasty retreat to well-tested abstractions that have withstood generations of change? It's not like nobody's ever tried anything else: NT, Haiku, parts of Darwin, various experimental research systems... really, if you want the anti-unix, go use Microsoft's stuff. OLE, COM, etc; nothing's a file, everything does more than one thing (poorly), they gave up on the legacy of teletype long ago.
But no, we're not huddled in the corner afraid of the world because our stuff sucks so terribly, we're relying on simple, composable layers because everything else breaks when you try to scale it up.
There are systems which take the good parts of the Unix philosophy (composability, uniformity) but abandon the bad parts (text, hierarchical files, mutability, the name based permission model, etc.).
There are various research crowds such as the FP and capabilities people are usually at the forefront of this but the research to production cycle is very long since Unix is entrenched. In my experience a lot of systems programmers are reactionaries and make this cycle longer than it should be, but that is the subjective part.
"The terminal" ... isn't. A TTY is a device, not an application. A terminal emulator provides access to an emulated terminal, and the beauty of screen and tmux is that you can drop these on any emulator (xterm, rxvt, konsole, gnome-terminal, xfce-terminal, etc., etc.) and have it Just Work. Or run either outside or inside (or both, if you're a masochist) an SSH session.
For another example of such modularity, there's rlwrap, a readline wrapper. If you're used to the functionality of readline integration with your shell (bash, korn, zsh, etc., etc.), and suddenly find yourself using a tool that lacks this (Oracle's client comes to mind), you have the option of wrapping the command in a utility which offers that missing functionality.
There's something to be said for modularity.
Another is that if screen, or tmux, offers a feature set you prefer, you're welcome to use whichever better suits your needs (or muscle memory).
Kernel development is much harder, and in-kernel applications increase the attack surface area of kernels.
EDIT: One important aspect of the difference in development difficulty of user- vs. kernel-land is that we would not get as much diversity of solutions if they had to be in-kernel.
I beg to differ. These aren't an end-run around anything, but rather a continuation of a long-standing tradition of isolating terminal events from processes. The fact of existence of a multi-variate number of tools to modify the application-execution environment shouldn't really be a critical point in ones evaluation; this is like complaining about window managers existing, because no true window manager exists.
I would encourage you to give them a serious shot. You might be surprised!
I use it for tailing the logs of multiple servers in the same window, which is especially nice because ctrl-b,space will rotate the layouts if I need to see more horizontal or vertical for a second, and ctrl-b,z will full-window a pane enabling complete drill-down on one server
A related project is tmuxinator https://github.com/tmuxinator/tmuxinator#tmuxinator but it didn't work exactly right for my use-case (I don't recall the specifics without being in front of my work machine)
Top pane is for git stuff.
Bottom left is where webpack/npm/react stuff runs - if I save and see errors, I know something is wrong.
Bottom right is an ssh tunnel to a server the local dev environment depends on. (Or I can run that dependency locally, too, but meh.)
For me, it's pretty intuitive - splitting, switching panes, etc. I know it's effectively the same, but I can't imagine going to back to one-tab-per-process. If nothing else, the ability to see multiple logs scrolling by in a single window is A+.
Each window in the top-level session runs tmux anew-session or attach-session. Window names correspond to session names.
My top-level session is the default session and uses ^T as the prefix. All others use ^A.
I also have a $CSCOPE_EDITOR that runs the real $EDITOR in new window (named after the basename of the file to be edited) in the same session and then exits, letting cscope get control back. I strongly recommend this.
I also have a pid2mux script that takes a pid and tells me which window of which session has that process (if it has a controlling tty).
I live as much as possible in a tmux world. Though I still use screen keybindings as much as possible also.
License: Screen is GPL, Tmux is BSD.
Screen has built in support for serial ports.
Tmux adds a status bar by default, screen does not.
That is what exactly? I stopped using screen a few months ago, tmux offers a set of default key bindings that are adjusted to modern software, a new biding for copy and paste (so you can control what machine gets the command), and... I still didn't find anything more that is relevant.
If he is used to screen, the key bindings will be more a problem than a solution¹, and the copy and paste thing is very niche. I don't think one has any good reason to migrate from one to the other. I did it to get to know tmux better, and really, that's exactly as much as I got.
1 - Unless you need to keep setting the bindings again and again.
The biggest advantage of screen to me is that you can more easily fix the dumb prefix key (e.g. screen -e^z^z to use ^Z). This is handy for remote servers wherem you don't have your config files etc.
Vertical split panes was the biggest reason, but for myself, the end comes down to a config file I can actually read and unlike screen, tends to not have things like this in the man page:
> Attach here and now. Whatever that means, just do it.
Thats the main reason myself and a number of people I know ditched screen around that time. But I'd hardly call 4 years a long time.
Besides the fact, that screen can also do that, I think this should be implemented at the Window Management Layer anyway - tiling WMs do that.
This is actually the main reason, why I do not use tmux or screen at the moment. I used to work with screen, because I liked the terminal splitting, but since using a tiling WM, I get that for free. However I have to admit, that I sometimes miss session management.
Genuine question, why? I run my terminal in one giant full screen window, or emacs. Emacs splits itself fine, I just switch to a different screen with my terminal and tmux and i'm good. No need for the window manager to be involved.
Furthermore I like to switch between "windows" (rectangles in a tiling - e.g. vertical/horizontal splits - context) or in general rearranging the layout using input controls on the WM layer, so that it works the same across all applications and not just in a terminal emulator context. In the end it's personal choice, however it has some benefits, as the same workflow works across applications. Obviously this requires a WM itself and does not work in a Linux console context (which is supported by tmux and screen), but I mostly run X11 with a WM anyway.
What about copying text from one split to another (at least without having to use the mouse)?
For me, it is that I have a package like https://github.com/christoomey/vim-tmux-navigator
I can seamlessly move across splits in either vim or tmux without worrying which program started the splits.
http://www.tedunangst.com/flak/post/openbsd-changes-of-note-...
and subsequent updates.
"Give tmux clients names. There have been lots of small improvements to tmux over the past six months which haven’t seemed notable in isolation, but shoutout to all the little fixes, too."
- you can configure screen at runtime. Ctrl-A :<command>
- you can have multiple "sessions" in screen, although it calls it windows: Ctrl-A C
There might be other mistakes, but I'm not advanced enough to say.
The Tenex line of operating systems from DEC had built-in session management in the 1970s. Unix still doesn't have it. All non-trivial terminal handling was kept in user-space. Therefore, programs had to make assumptions that are now hard-coded in their very design.
To this day, the Linux and BSD kernels assume that they're talking to a VT100 with a few frills. The commercial Unix kernels were worse; I used a SunOS tutorial in the mid-90s that started me off on ed (yes, the standard editor; the man page even called it that without qualification) because Sun started out with an older version of BSD that assumed teletypes.
This has had consequences. The major reason why microcomputers took off was because an Apple ][ running VisiCalc could do things that a terminal connected to a mini/mainframe computer could not do.
Here we are, living in the future, where wristwatches have true color displays, and household appliances run webservers, but the correct, macho, hipster-approved user interface would be shamed by an Amiga 1000.
/rant
The reality of modern times is more nuanced and I don't fully agree with you (for instance there has been movement in i.e. SCO UNIX in the late '80s, now fb/drm based terminals for linux/bsd but it is pretty slow going because most people embrace two distinct modalities with the terminal being a lowest common denominator and everything else being graphics (or even WWW). So in effect, most people use *nix as a personal minicomputer or distributed minicomputers, and the text interface is a lower level thing while they pump out X11 or Wayland or WWW for "modern" experience. In this role, tmux is about the ideal session manager I can imagine.. but that may be more of an "unknown unknown" than me knowing it is ideal.
I use an ssh alias at work to always log me into my tmux session if tmux exists on the server
ssh -t 'tmux new-session -A -s mySessionName || exec $SHELL -l'
I shared this with a workmate and he just changed the session name and we both have our own tmux sessions.
I am able to have tmux setup and working in OSX locally using reattach to user-namespace. However, I am struggling with a setup that works on remote machine. What do you do when you want to copy and paste between remote and local machine in tmux?