
Differences between Tmux vs Screen (2015) - 0x54MUR41
https://wtanaka.com/node/8136
======
carussell
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.

[http://pbfcomics.com/comics/skub/](http://pbfcomics.com/comics/skub/)

~~~
Slackwise
Exact same feeling I have about web apps.

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.

~~~
tyingq
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.

~~~
icebraining
_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.

~~~
kmicklas
> why would you expect major improvements to arise?

Maybe not, but you certainly shouldn't expect a regression, which is exactly
what we're witnessing.

~~~
icebraining
I would. A more general system will (almost?) always be less efficient than a
single-purpose system, at that specific purpose.

~~~
kmicklas
I don't think modern CRUD apps are necessarily more general. They're just
built on top of many more layers of broken abstractions.

~~~
icebraining
You don't think that modern CRUD apps do anything besides showing text and
labels?

------
whack
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.

~~~
jamesbvaughan
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!

~~~
43224gg252
You can even enable the mouse to resize splits and switch between tabs in
tmux/byobu:

[https://gfycat.com/SmallComplexGreatargus](https://gfycat.com/SmallComplexGreatargus)

~~~
pthreads
Now, that is quite useful! I am going to try tmux just for that. Have been a
screen user so far.

------
willvarfar
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!

------
tyingq
A few more differences not covered in the article....

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.

------
pthreads
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.

~~~
colordrops
Change the tmux keybinding from ctrl-b to ctrl-a and it will feel mostly like
screen, but you will get all the extra tmux functionality.

~~~
marcosdumay
> 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.

~~~
mitchty
> That is what exactly?

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.

~~~
zeptomu
> 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.

~~~
mitchty
> 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.

~~~
zeptomu
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.

------
AlphaWeaver
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.

------
sverige
Tmux has been getting lots of improvements lately; see e.g.

[http://www.tedunangst.com/flak/post/openbsd-changes-of-
note-...](http://www.tedunangst.com/flak/post/openbsd-changes-of-note-620)

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."

------
Aissen
I only consider myself a newbie screen user, but I can see that the comparison
has a few mistakes:

\- 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.

~~~
wnoise
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.

------
winestock
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.

/rant

~~~
kev009
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.

------
sirfz
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.

~~~
Graziano_M
You can do this easily in tmux by having them work in separate sessions. This
allows them to have their own set of windows.

~~~
sirfz
I understand it's possible, but not as easy as screen -x.

~~~
joobus
tmux new-session -A -s mySessionName

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.

~~~
sirfz
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.

------
edibleEnergy
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.

------
rasengan0
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

------
SakiWatanabe
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?

------
blazespin
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.

~~~
iopuy
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.

------
iopuy
It is possible to configure Screen to have automatic window renaming although
it requires modification of the PS1 environment variable.

