Love, hate, and tmux(robots.thoughtbot.com)
robots.thoughtbot.com
Love, hate, and tmux
http://robots.thoughtbot.com/post/2166174647/love-hate-tmux
4 comments
This article is pretty superficial, but I've been using tmux lately and my primary complaint is that you can't attach to the same session without syncing them. Well, something I've been doing with screen for 10 years because I find it handy is to attach to different windows within the same screen session from different terminals. I might split them across the same screen, put them on different workspaces, or even run from different machines. Why would I even want to have multiple views of exactly the same thing?
I recently switched from screen to tmux; this is the killer feature for me. We use tmux to pair program with remote employees, and this allows us to stay in sync automatically. With screen, we constantly had to tell the other pair which window we were looking at, which was a constant distraction. It also makes it easy to 'screencast' with multiple remote people.
Okay, that sounds neat. What happens if multiple people type at the same time? Can you split the frame and somehow still have multiple people typing? Why tmux instead of a more featured remote desktop? Just curious, but now that I understand your use case, I think both modes are important.
> Why tmux instead of a more featured remote desktop?
tmux has usable levels of latency.
> Just curious, but now that I understand your use case, I think both modes are important.
tmux supports both modes; the sharing one is just the one that's enabled by default.
tmux has usable levels of latency.
> Just curious, but now that I understand your use case, I think both modes are important.
tmux supports both modes; the sharing one is just the one that's enabled by default.
Thanks, I just reread the manual page and found tmux new-session -t which behaves similarly to screen -x. When I asked on IRC, I was told that tmux did not support this mode so I didn't pursue it further.
If you include a window list in your caption, I believe there is a specific flag that shows up (I want to say it's an asterisk), which indicates "other user viewing this window."
Ugh.
I was so happy, because I finally thought that this would be a direct comparison of screen and tmux from someone who was very experienced in one or the other.
But, no. It was someone to whom even common features between the two were novel. I'm not saying that this is a bad article or that you shouldn't read it or that the author shouldn't have written it, but damn it, I've been using screen for years, and everywhere I turn, I see tmux, too!
But so far, the only thing anyone has been able to offer in terms of concrete differences is "tmux can do vertical splits," which will be true of the next big version of screen as well, if they ever release it.
I am officially declaring shenanigans on anyone who blurts "tmux is better" without linking me to a @#)&@#%ing objective and thorough comparison of the two apps that actually makes it seem like tmux is worth using instead. Even the very first result on Google comes up with nothing more than "tmux has some kind of client/server thing," which seems exactly the same as screen -X.
Edit: I upvoted the article to solidify that my problem is not with it, but with the context in which I read it.
I was so happy, because I finally thought that this would be a direct comparison of screen and tmux from someone who was very experienced in one or the other.
But, no. It was someone to whom even common features between the two were novel. I'm not saying that this is a bad article or that you shouldn't read it or that the author shouldn't have written it, but damn it, I've been using screen for years, and everywhere I turn, I see tmux, too!
But so far, the only thing anyone has been able to offer in terms of concrete differences is "tmux can do vertical splits," which will be true of the next big version of screen as well, if they ever release it.
I am officially declaring shenanigans on anyone who blurts "tmux is better" without linking me to a @#)&@#%ing objective and thorough comparison of the two apps that actually makes it seem like tmux is worth using instead. Even the very first result on Google comes up with nothing more than "tmux has some kind of client/server thing," which seems exactly the same as screen -X.
Edit: I upvoted the article to solidify that my problem is not with it, but with the context in which I read it.
> which will be true of the next big version of screen as well, if they ever release it.
"if they ever release it" is a perfectly valid reason to move away from Screen.
But since you're asking for technical reasons:
* vertical splits in screen are unusably slow given high throughput.
* tmux's default key bindings actually make sense, and if you don't like them you can change them. screen only lets you change a few of the bindings; there's no way to make copy/paste match something like Emacs style. I used and loved screen for years, but I never used copy/paste because I just couldn't internalize the bindings. tmux made sense on day one.
* screen actually requires suid for multiuser support, which is atrocious, while tmux simply communicates over a socket, and whoever has the permissions for the socket can join the session.
"if they ever release it" is a perfectly valid reason to move away from Screen.
But since you're asking for technical reasons:
* vertical splits in screen are unusably slow given high throughput.
* tmux's default key bindings actually make sense, and if you don't like them you can change them. screen only lets you change a few of the bindings; there's no way to make copy/paste match something like Emacs style. I used and loved screen for years, but I never used copy/paste because I just couldn't internalize the bindings. tmux made sense on day one.
* screen actually requires suid for multiuser support, which is atrocious, while tmux simply communicates over a socket, and whoever has the permissions for the socket can join the session.
I agree that "if they ever release it" is a powerful point against screen. Is tmux actually better in that respect?
I feel like your critique of screen's customization is a little inaccurate; you said that "screen only lets you change a few of the bindings," but actually, copy/paste are the only ones it does not let you change.
I agree that they're rather unintuitive. As a vim user, I have less cognitive dissonance, but I do dislike the way that the bindings are almost vim. I think you did yourself a disservice, though, by never figuring out copy/paste at all--it's quite usable once you get the hang of it.
I think that hand-wringing over using suid for shared sessions is premature; while I agree that any experienced sysadmin should flinch at the overall concept, it's important to remember that the screen binary itself is still writable only by root, and that while you run it with setuid, the resulting shell child process is not run as root. So, to the extent that there are no "screen injection exploits," running it with setuid is a non-issue.
I feel like your critique of screen's customization is a little inaccurate; you said that "screen only lets you change a few of the bindings," but actually, copy/paste are the only ones it does not let you change.
I agree that they're rather unintuitive. As a vim user, I have less cognitive dissonance, but I do dislike the way that the bindings are almost vim. I think you did yourself a disservice, though, by never figuring out copy/paste at all--it's quite usable once you get the hang of it.
I think that hand-wringing over using suid for shared sessions is premature; while I agree that any experienced sysadmin should flinch at the overall concept, it's important to remember that the screen binary itself is still writable only by root, and that while you run it with setuid, the resulting shell child process is not run as root. So, to the extent that there are no "screen injection exploits," running it with setuid is a non-issue.
"if they ever release it" is a perfectly valid reason to move away from Screen.
I disagree, since we're talking about open source, here. More to the point, this is a marketing reason[1], not a technical one.
screen actually requires suid for multiuser support, which is atrocious, while tmux simply communicates over a socket, and whoever has the permissions for the socket can join the session.
This is an important distinction, though, to me, it doesn't make one better or worse than the other, in general, just for specific circumstances. This kind of detail is why I crave objective comparisons, like the OC, though perhaps from different motivation.
[1] Which I, personally, don't consider valid, though I wouldn't suggest it isn't to you.
I disagree, since we're talking about open source, here. More to the point, this is a marketing reason[1], not a technical one.
screen actually requires suid for multiuser support, which is atrocious, while tmux simply communicates over a socket, and whoever has the permissions for the socket can join the session.
This is an important distinction, though, to me, it doesn't make one better or worse than the other, in general, just for specific circumstances. This kind of detail is why I crave objective comparisons, like the OC, though perhaps from different motivation.
[1] Which I, personally, don't consider valid, though I wouldn't suggest it isn't to you.
> This is an important distinction, though, to me, it doesn't make one better or worse than the other
setuid I could handle if it were just that, but screen reimplements its own internal permissions model, while tmux simply uses unix permissions, which everyone already understands. Composability wins.
setuid I could handle if it were just that, but screen reimplements its own internal permissions model, while tmux simply uses unix permissions, which everyone already understands. Composability wins.
screen reimplements its own internal permissions model
That's exactly my point. This is neither categorically good nor bad. It doesn't reinvent permissions gratuitously, but, rather, as a way of increasing flexibility.
It allows per-window permissions and fairly arbitrary permissionsetting, for any user, without resorting to groups (the membership of which a regular user does not control) or universal permissions.
That's exactly my point. This is neither categorically good nor bad. It doesn't reinvent permissions gratuitously, but, rather, as a way of increasing flexibility.
It allows per-window permissions and fairly arbitrary permissionsetting, for any user, without resorting to groups (the membership of which a regular user does not control) or universal permissions.
It wasn't really meant to be a comparison, just sharing our practices as we normally do. I used screen before hand, and tmux just feels nicer. Having vertical splits is a HUGE win, especially for a big monitor.
We're planning on follow up posts to this one, hopefully with screencasts to help visualize it better.
We're planning on follow up posts to this one, hopefully with screencasts to help visualize it better.
One substantial difference between the two projects: screen's license is the GPLv3, tmux's is BSD-derived.
That's really not a reason to use one over the other, only a reason to contribute to one over the other, and tbh, can be a benefit in either direction depending on who you are.
tmux FAQ: "How is tmux different from GNU screen?"
http://tmux.cvs.sourceforge.net/viewvc/tmux/tmux/FAQ
http://tmux.cvs.sourceforge.net/viewvc/tmux/tmux/FAQ
I'm a fan of tmux (when I use a multiplexer, I'll choose it over screen). It has a 3 clause BSD license. It was integrated into the OpenBSD source tree, which is great: http://archives.neohapsis.com/archives/openbsd/cvs/2009-06/0...
If you have trouble accessing the site just use:
cache:http://robots.thoughtbot.com/post/2166174647/love-hate-tmux
in Google.
cache:http://robots.thoughtbot.com/post/2166174647/love-hate-tmux
in Google.