I am going to go out on a limb and say this article has little to no content. I am surprised that it has 69 points despite being very light on content.
More over, the comments here are mostly tangential to the article (except in the sense that they involve the word tmux).
Am I totally wrong? Can everyone else see into this article where I can't?
More often than not, I upvote submissions only to influence what's discussed on the front page. Many comments are far more in-depth than the original article however tangential they may be, but the topic has to be brought up.
He says he switched from screen to tmux, then describes very shortly a use case in which tmux does not bring any benefit over screen (sharing a vim session).
This post got me thinking about building a remote dev system using tmux running on EC2 or some other cheap VPC host. I like the idea of pulling up a fully configured dev system from anywhere. Mainly so I can pick up the same session from home or work for hacking on my own projects, rather than keeping two separate systems in sync.
I've got a linode box running arch. I configured it with all my dev needs. I'm currently in university and I spend a good amount of time at school, bouncing between labs and then also working from home.
Right now the process is simply:
ssh me@mydomain.com
tmux attach
Up comes a familiar |- split console with vim running in a window, a terminal at the root of whatever project I'm working on and the server output of that project below it. If I have to leave suddenly, Ctrl+A+D and walk away. It'll be there when you log in next time.
It also has huge advantages if you're working remotely with teams or just want to launch stuff. I have nginx already configured and running. When I need to launch a new project:
1) Go to the Linode DNS Manager and setup a new subdomain
That's exactly what I want, a remove dev box for working on and serving up web projects. I'm setting this up on an EC2 micro instance right now, slowly getting a feel for the tmux key bindings. Thanks for those links, great stuff!
I do this a lot, particularly with projects that use a database that might be hard to configure (and the configuration isn't fully scripted). Just get the development version of the DB right once, and then make a copy of the machine in case you mess things up later and need to revert. It's saved me a lot of DB rebuilds, and I don't have to do DB migrations on both my laptop and desktop to keep them up-to-date so that I can run tests from either.
Yup - I do exactly this for about the last year, and it works as you describe. Long-lived IRC sessions, all of my editing windows open as I like them. You can have nice monitor/chair/keyboard setups at work and home. I find I don't have much use for a laptop any more. If your Windows/ubuntu desktop install breaks, you can reinstall quickly and get back to where you were.
What I mean is - whatever is driving your graphics card, monitors and local network. Sometimes I do a dist upgrade and my video drivers go to junk. Or family install something to my workstation and I find that it has added junk to the boot sector, and I want to get rid of it for sure. Or my mac laptop just starts being really slow for reasons I can't be bothered to investigate. These things are no longer an issue because your desktop install is expendable.
I do this on a linode and have been quite pleased. I've found TMUX/git/Vim to be an awesome way to keep an environment up to work/play with from anywhere, while not having to worry about leaving a machine constantly running at home.
I've also experimented with Cloud9 to some success, but it will depend on the nature of what you're doing.
tmux and screen both have upsides and downsides for pair programming. Ones that I know of:
1. screen requires itself to be setuid root for session sharing. This is security issue to say the least. The frustrating part of this is that screen explicitly checks that that uid == 0. This means that, even if you can iron out all of the permissions issues between you and your partner without needing root access, screen will only accept suid root as the solution.
2. When you are screen sharing in tmux, the configuration used is the configuration of the person hosting the session. This can suck if you have a lot of non-standard bindings, because it forces the person you're pairing with to know them too. screen allows you to both use your own configurations while being connected to the same session.
Remote pair programming sucks. I don't know why there isn't a higher level protocol that would send simple tab changes, text highlights, text deletion, and other high level common tasks. This way the two connected programmer could actually be using different editors but still experience the same editor actions. And each user could maintain their own separate key bindings.
Who cares if I press cmd-t to open a file or my pair prefers to open a file with cmd-shift-n? Just send me the action that a file was opened.
I wrote up my detailed thoughts on fixing remote pair programming here.
> Who cares if I press cmd-t to open a file or my pair
> prefers to open a file with cmd-shift-n? Just send
> me the action that a file was opened.
I don't think that this was an affirmative design decision. I think it has to do with the architecture of software, and is merely a side-effect of that architecture. Pair programming isn't the main use-case for terminal multiplexers.
3. Both pairs get access to whatever user starts tmux. This may or may not be a problem, but it was with me as we were pairing on my personal machine and I didn't feel comfortable giving complete access like that.
What we came up with is creating a new "pair user" and running tmux within that.
The configuration wasn't a problem for us since one of us hadn't ever used tmux and had therefore had no opinion.
> Both pairs get access to whatever user starts tmux
IIRC, if you 'host' a (gnu) screen session, then your pair will create new shells as your user. This is not a tmux-only issue.
> What we came up with is creating a new
> "pair user" and running tmux within that.
That's an idea that I had, but hadn't attempted to look into yet. This also gets around the screen suid root issue (though not necessarily the config issue), if you're both logged in as the same user. How has this been working, any caveats?
> The configuration wasn't a problem for us
> since one of us hadn't ever used tmux and
> had therefore had no opinion.
I use ` instead of C-a/C-b in both screen and tmux, so it could be a bit jarring to others.
> That's an idea that I had, but hadn't attempted to look into yet. This also gets around the screen suid root issue (though not necessarily the config issue), if you're both logged in as the same user. How has this been working, any caveats?
I'm not sure why you need to set suid on tmux. Before we created the pair user I just used the -S option to specify a socket path and then chmoded the created socket so my pair could access it.
So far so good with the new pair user. The only thing that's different is that to push our changes up to the main repo we need ssh keys and we haven't gone through the trouble of creating a new ssh key for the pair user and adding it to our teams github repo, so we have to git push and pull from a non-pair login. That can be fixed when it gets annoying but so far I'm always logged in to that machine as myself as well as the pair user so I can just switch tabs and git push/pull when needed.
> I use ` instead of C-a/C-b in both screen and tmux, so it could be a bit jarring to others.
I use C-\ myself since C-a and C-b are both prominent Emacs keys.
3) Tmux sessions are restricted to the size of the smallest client connected to the session. We've recently started using it at work and it works fine for 2 of us, but 2 others found that the resolution differences between their 13" and 15" macbooks means that the 13" sets the tmux session size so the 15" doesn't use the whole screen.
I'm pretty sure this would also be an issue with screen. The pair maybe able to operate on separate 'windows' at different sizes, but would not be able to view the same window at two different sizes at the same time.
Actually Screen is even worse; it sets the size to whoever joined last. So if someone with a big screen joins a session of someone with a small screen, portions of the window will be invisible to the person who started it.
Regarding #1: if you are doing software development on a system with any security requirements at all, you have already lost. Maybe I can see bending that rule for debugging a live system in extremis, but not for "pair programming".
A box under development can and will have all sorts of terribly insecure behavior. It shouldn't be on the internet. I'm not saying you "lose" anything by trying to secure it, I'm saying that you already "lost the [security] game" when you put the box on the unfiltered internet in the first place. Your goal should be limiting exposure when it is compromised, not trying to lock down hatches on a leaky hull.
Specifically: dickering over whether or not to make screen suid root on your dev boxes is an exercise in needless optimization.
One way we are going to get around this is that we plan to have a golden .tmux.conf that we will all use at DockYard, so that any non-standard bindings will be standard to us
For #2 - there is WeMux (https://github.com/zolrath/wemux), a shell script wrapper over tmux. I am not an expert, so cannot point out how (in)effective it is in terms of applicability or security.
I've used tmux and screen on occasion, but I can't get past the fact that they don't fit well with GUI terminals. I love having "GUI" scroll-back, which I can go through with mouse scroll-wheel, or just dragging the scroll bar up and down.
Except you can't natively select text for copy/paste anymore.
When you click-drag you're now triggering a tmux selection, not the native terminal-emulator highlight. This is a big problem because the emulated variant is slow and behaves nothing like the real thing.
To my understanding this is also a problem that can't be solved without further terminal emulator support. As it stands the remote application (tmux) can either receive all mouse-events or none of them.
This means you have to choose between scroll-wheel support plus broken text-selection - or no scroll-wheel support.
I tried the mouse integration and turned it back off for the same reason as you. Not having copy-paste at the terminal level is a non-starter as far as I'm concerned. Learning the vim movement commands better eliminated most needs for the mouse-pointing ability anyway.
This is cool and something I didn't know about tmux:
"The one disadvantage of everyone at DockYard working remotely is that you can't just turn around and ask someone to come to your desk to pair up. Tmux allows multiple users to connect to a specific session. With a bit of dynamic DNS magic, port forwarding, and ssh tunneling, multiple people can connect to the same tmux session, work in the same vim window, and see the same development server."
...
"With a tmux, ssh port forwarding, and Google+ Hangout, you can create a useful pair programming environment with your remote coworkers. We find this setup very effective and use it often to work together and tackle an issue."
I do, having used screen for a couple of years before switching. It has vertical splits, a saner config, and was easier to get colors working the way I wanted them to. I can also appreciate that it has a more modern codebase with less legacy baggage, even if the benefits of that aren't readily apparent to end-users.
I've still not run into a `screen' installed anywhere that has vertical split support compiled in. Yes, you can get a version of screen that does -- but EVERY version of tmux has vertical splits.
I used screen for five years and could never internalize the copy/paste key bindings for scrollback, and screen doesn't let you configure them. I was more comfortable in tmux after an hour than after years of screen due to it being able to just work with Emacs bindings.
Apart from this, most of the advantages are only noticeable in a multi-user setup. The socket-based session sharing is great, (it just uses unix permissions) and the fact that it automatically resizes to the smallest display is a huge usability improvement. When we paired with screen we would always have to jump through hoops to make sure the guy with the smaller display joined last or he'd be unable to see everything.
I've been trying out the iTerm2 author George Nachman's mod[1] to tmux that allows integration with terminal emulators (currently only iTerm2). Practically this means that when I reconnect to a server I get a window full of tabs for that tmux server. Now I don't need to know any of the tmux commands. I can switch/open/close tabs using the standard OS tab control keys. I can use two finger scroll to view the history. I can search the history using the usual OS key. I've been dreaming of doing this for gnome-terminal/tmux for years. Someone beat me to it and it's as nice as I had hoped. Of course you can still attach in the usual way if needed.
1. tmux does not require suid root for multi-user. Even if you solve all of the permissions issues for screen, there is an explicit check for uid == 0 when you attempt to enable multi-user.
2. tmux has vertical splits. Yes, screen has these, but they require you to patch/build your own screen. I've yet to come across a patched screen that has vertical split support.
3. tmux can integrate scrolling with iTerm2 (IIRC, there may also be some urxvt integration, but you'd have to verify that).
4. In tmux, splits are first-class citizens. You can do "C-b <space>" to switch between 'layouts' much in the way that you would in a tiling window manager like xmonad.
5. tmux remembers your splits/layouts when you detach/reattach. Screen doesn't last I checked.
6. tmux has a 'show-messages' command that has a log of all messages that it showed at the bottom, so that you can view them if something popped up that you missed.
7. I like the config format better. I was able to convert my highly modded screen config to tmux in an hour or so, and the config file is much smaller/simpler.
8. When scrolling in copy mode it tells you where you are in the scrollback buffer (e.g. "0/32").
9. tmux has this (from the manpage):
has-session [-t target-session]
(alias: has)
Report an error and exit with 1 if the
specified session does not exist. If it
does exist, exit with 0.
10. Also this:
respawn-window [-k] [-t target-window] [shell-command]
(alias: respawnw)
Reactivate a window in which the command has exited (see the
remain-on-exit window option). If shell-command is not given, the
command used when the window was created is executed. The window
must be already inactive, unless -k is given, in which case any
existing command is killed.
Going to once again pimp this book and it's delectable goodness. It's a wonderful book, well written, clear, concise, and in just a few pages, gives you a lot to work with. Highly recommended.
We had an article recently about (technical) books being blown up to fill pages - this obviously wasn't.
I don't doubt that this might be a great work, but I have to admit that I felt the '88 pages?' thought coming up. The price isn't too bad. I just found out, while checking out the pragprog site, that I fell for the 'Seems thin' thing. Maybe a conditioning I need to correct - I don't know.
They aren't really competing products. Tmux is a Screen rewrite. Screen isn't going to be receiving major revisions going forward, it's (supposedly, I don't play with that code) in an unmaintainable state. That's the only reason tmux was ever created.
Are you in two separate locations connected to two different networks at the same time? The author is talking about telecommuting. Sure dynamic dns is not needed but timsbox.dyndomain.com is a lot easier to work with than whatever IP he has today.
Does Mosh (posted yesterday) support multiple connections? I know it can suspend resume like screen/tmux. Seems like it would be preferable if it does.
More over, the comments here are mostly tangential to the article (except in the sense that they involve the word tmux).
Am I totally wrong? Can everyone else see into this article where I can't?