4 ms·

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

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

mmt 16y ago
"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.
- technomancy 16y ago
  > 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.
  - mmt 16y ago
    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.
mcantor 16y ago
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.

mmt 16y ago

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

technomancy 16y ago
> 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.
- mmt 16y ago
  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.

mcantor 16y ago

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.