The article mentions vocal advocates (for tmux, although which doesn't matter). Meanwhile, I've always thought it was unfortunate that tmux and screen even exist.
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.
> Well, then we should have OS-level APIs exposed that allow for that
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.
You need some sort of "terminal server" to maintain the session and station state, and I think screen's server does that thing quite well - I don't see a good reason to integrate the "terminal server" with the OS. You could split "UI session management" and "process management" somewhat (e.g. have Docker manage the process swarm and pass stdio to screen), but that's even more splitting.
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".
PTYs are "terminal servers"—they're just sucky ones from a time when a terminal had fewer expected capabilities. But, indeed, you can connect a TTY directly to e.g. a serial modem, and then the person dialling your modem will get a TTY and login(8) will accept(2) on that descriptor and serve them a login prompt.
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.
> PTYs are "terminal servers"—they're just sucky ones from a time when a terminal had fewer expected capabilities. But, indeed, you can connect a TTY directly to e.g. a serial modem, and then the person dialling your modem will get a TTY and login(8) will accept(2) on that descriptor and serve them a login prompt.
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.
No, I was talking about two separate time periods. Sysadmins were defining IPSec transports to protect port 23 traffic between mainframes and their terminals for years before SSH appeared. Allowing Telnet sessions to traverse the public Internet was one of the original motivations for 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.)
There are advantages of putting functionality into other elements.
"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).
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.
It is funny how we've regressed. For CRUD apps that don't do anything graphical, the current crop of web apps don't do anything better than a mainframe and a 3270 terminal did 50+ years ago. And the man-hours required to produce and maintain them is much higher.
That is an extreme simplification. Modern crud apps run from essentially any network in the world on hardware of every conceivable form factor and vendor. The protocol is open and so obvious it is routinely taught to middle school children.
All of those things are significantly different than a mainframe/term setup
I disagree. TN3270 runs on essentially any network in the world, and has existed for quite some time. I am scoping this down to CRUD apps that are text and labels.
I'm currently on my phone on a streetcar in San Francisco. I'm pretty confident there's one of those platforms I could access now with the greatest of ease, and the other would take some doing.
For CRUD apps that don't do anything graphical, the current crop of web apps don't do anything better than a mainframe and a 3270 terminal did 50+ years ago.
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.
Can't argue with you there, I have no idea how much time it took on a 3270. That said, are you thinking about the time to build and maintain it from scratch? Because there are plenty of CRUD frameworks to remove 90% of the work. Of course, those have to be built and maintained as well, but then again, so did the 3270 terminals.
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.
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.
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.
I have a system service for Emacs, which starts up headless and invokes emacs-server. When I want an Emacs window, I just run `emacsclient -c` (I usually have one for programming and one for email).
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.
Tramp mode in emacs is the closest I have seen to something like this. The dream is a beefed up cloud server hosting and executing code, while you just use your local resources to run emacs
It is much, much easier to develop application features in user-land than in kernel-land. PTYs are fine, and the fact that multiple screen-ish solutions exist is proof of this and a fantastic result.
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.
>These two terminal multiplexers are really an end-run around unfulfilled wants in the way that the console subsystem should work by default.
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.
As far as I know Byobu is just a nice wrapper on top of screen/tmux to make it more user-friendly for beginners. How would that relate to concerns raised by the OP?
> 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.
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.
> 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.
By criticizing Unix I did not mean look at Windows etc....
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.
I'll be honest. I use tmux everyday as an integral part of my workflow, but I find this whole idea of Windows and panes extremely cumbersome and complex. I just stick to a one-server-one-window/pane model, and create a new server for every new "window" that I want. I then connect to these multiple servers using multiple tabs on my terminal app, which I can then freely drag-drop-resize to my heart's content. If someone's looking for an entry-drug into screen/tmux, this is the easiest way to get started.
This is exactly what I did for a long time, but after seeing so many friends and coworkers using panes effectively, I decided to finally jump in and commit some time to learning and customizing all the keybindings, and it has definitely paid off. Using panes and windows has become an integral part of my workflow.
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)
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.
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+.
I recommend xpra, which is like screen but for X apps (and the apps they launch, i.e. Start xterm and launch stuff from there and the whole
Constellation of Windows is like a screen session you can attach and detach from), and you can view the sessions remotely and even in the browser!
I found this quite useful. I have been using screen for a while but my friends use tmux. They love it and couldn't be bothered to switch to screen and me vice versa. Based on the post I don't seen any strong reason for either to switch unless there are other reasons not mentioned in the comparison.
> but you will get all the extra tmux functionality
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.
Yes, I'd really love to have a linux version of that.
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.
For those confused, the linked patch page[1] has says that the patch got integrated into Debian (and Ubuntu) from 4.0.3-10, which means it would have been available since Lenny (2009).
> Vertical split panes was the biggest reason, [...]
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.
> 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.
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.
I think it's just a prettier architecture - obviously both ways work, but if the WM has good splitting, applications don't have to bother with windows and layout implementations.
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.
Because the window manager gives your the same consistent experience for non-terminal windows as well, and I'm pretty sure you use at least a web browser. Of course it's all a matter of taste (and habit).
The article didn't seem to address customization. Every tmux tutorial I've seen recommends changing the keybindings for the prefix, splitting screens, and other frequently-used features. I haven't used screen, so I don't know how hard it is to do that with it. tmux works well enough for my needs.
Something else interesting is the program byobu, which acts as a wrapper for either tmux OR screen, depending on your preference, and makes session management and configuration easier.
"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."
Yes for the first, no for the second. He means something quite different by session -- a stack of windows. And it does support it, by having multiple screen servers running at the same time.
All of this goes to show that the Unix-haters were right.
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.
Sad to see this downvoted, you make valid points about the importance of bitmapped display being a boon to microcomputers vs character or block oriented systems like minis and mainframes.
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.
We usually have multiple people working in the same screen, each in a different window (on a remote server). Last I checked, this was not straight-forward in tmux (where everyone is switched to the same window whenever someone switches) and it seems to be still the case from what I see in the comparison table. This makes GNU Screen the preferred tool for us, for now.
The point is to be able to work in different windows in the same session, not have two different sessions. I can see how something similar can be achieved in tmux but it would require getting used to a different workflow.
Screen binding to ctrl-a and tmux users binding to ctrl-a so it feels more like screen is a bad idea imho. Ctrl-a (move to start of line) is one of the most convenient key combos on the command line. I bind my tmux key to ctrl-s, because I have never needed to freeze my screen.
First I started with screen but quickly switched to the tmux-vim workflow. Then Comodo AV at work killed any chances of upgrading/building from source (long story) so I had to switch back to screen which i hadn't used in years. Now the only thing i really miss from tmux is the panes. screen splits is just not the same, but the productivity gains are still there. Oh and I miss that big clock too! C-b t
Does anyone have the copy/paste working properly 100 %? I am unable to find a solution of copy/paste setup that allows seamless integration with local clipboard.
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?
Can you copy across scrollback in tmux? When I see an error and I scroll back to copy it to the clipboard I can't do this on screen (and scroll at the same time). Plus it conflicts with my emacs keyboard bindings.
Do you mean can you copy from the scrollback buffer switch to a new session and paste the results? If so then the answer is yes. Ctrl-Escape to enter, scroll up and find the string, space to start highlighting, then space to stop highlighting and you have copied it into the buffer. Then ctrl-[ to paste wherever.
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.
http://pbfcomics.com/comics/skub/