Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

So far I have used konsole to manage multiple shell sessions but it seems that byobu, gnu screen, and tmux offer a better support for multiple shells. I have never used neither of them before. One of the features of them that I really need to use is to detach the current session and later reattach to that old session.

I know all tools can do that for me. So my question is: which one to chose? Important aspects are:

  1. Features (obviously)
  2. Project maturity. I do not want to learn a tool that is changing too much. Enhancements are welcome, but I don't like surprises such as disappearing features.
  3. Time spent learning how to use.
  4. Availability in different platforms. I do not want to learn something that I cannot use in many platforms. Let's say I need to manage a FreeBSD server one day and my desktop is Suse, some users on my network use Ubuntu. Anyway, you got the point.
  5. Compatibility with other interactive shell programs. Can I still use "vim" and "emacs -nw" (non-window mode, or text mode) the same way I am used to? Will the keyboard shortcuts conflict with the ones of other tools?

I just tried all of them and byobu looks like a sort of front end for gnu screen and tmux. Then why someone decided to create byobu instead of contributing to the gnu screen project and adding new features? Why byobu is not some sort of advanced interface mode in gnu screen? If I use byobu as my daily tool with gnu screen as the backend, can I use this knowledge to use gnu screen without byobu if a certain machine only has gnu screen?

Thanks in advance!

share|improve this question
    
Commenting my own question. After I posted, I just saw the number of times each tag was used in StackExchange: gnu-screen: 199 times tmux: 125 times byobu: 18 times Does that mean byobu is still not popular? Or that byobu is so intuitive that no one has any question on how to use it? –  Keitai May 11 '12 at 12:34
    
Because byobu is just a fork of screen with extra features, so the gnu-screen tag applies. –  grawity May 11 '12 at 12:40
1  
According to the documentation (manpages.ubuntu.com/manpages/precise/en/man1/byobu.1.html) the default configuration of Byobu is to use tmux as the default backend. If byobu is a fork of gnu screen, does that mean tmux is better than gnu screen? –  Keitai May 11 '12 at 12:48
    
Interesting, I didn't know that it supports tmux now, although it remains just a wrapper script -- not even a fork apparently. But yes, tmux is in some ways better than Screen (at least their FAQ claims so). –  grawity May 11 '12 at 12:55
10  
Byobu is not a fork of anything! It's a layer on top of Screen and Tmux, similar to Gnome/KDE being a layer on top of Xorg. –  Dustin Kirkland May 11 '12 at 15:54

4 Answers 4

up vote 8 down vote accepted

For Tmux vs GNU Screen, read

and several other comparison incarnations that can be found on blogs and such.

Some general terms that are oft repeated:

  • Tmux is newer. This means it is a bit fancier (simple vertical splitting, nice green lines) and a bit less well tested for e.g. compatibility (to negligible extent according to its proponents).
  • Tmux is leaner on resources.
  • GNU Screen is found everywhere and is most probably still more used.

Apart from this, one can look at specific functions for one or the other alternative, and personal preference will dominate the discussion. I personally used to use GNU Screen heavily — now I use Tmux.

I have not found Byobu to have any "killer features" for me. It provides an abstraction where I believe none is needed for my use cases.


Another way to look at it is to note that Byobu can use either of GNU Screen or Tmux as backend, which shows that the differences from a user POV are mostly superficial.

share|improve this answer

Great question! For what it's worth, I'm the author and maintainer of Byobu.

Byobu is a configuration layer, originally written to sit on top of GNU Screen, but now also works on top of Tmux.

I started writing Byobu back in December of 2008, as I met up with a bunch of Screen and Ubuntu Server users at the Googleplex and found that all of us maintained our own bunch of neat/fun/useful hacks in our ~/.screenrc configurations. And we had to manually move those around between the dozens or hundreds of servers we used. We started trading tips and tricks, and I began to collect those into the original GPLv3 project called "screen-profiles". About 6 months later, a whole community had developed around "screen-profiles" and the project became much more than just screen hacks -- we had configuration utilities, live status plugins, and keybindings. So we renamed the project "Byobu", which is a Japanese word for those elegant, folding "screens", and has the added benefit of being able to more successfully Google for "Byobu $FOO" than "Screen $FOO".

With Byobu now in most Linux distributions (Ubuntu, Debian, Fedora, Arch), and functional on most Macs/BSDs and other UNIXes, it give the same look-and-feel, convenient keybindings, dynamic system status information at any terminal you might need to access.

Why not contribute back to the GNU Screen project? A couple of reasons... All of what Byobu works just as well as configuration options. None of it needs to be included in the Screen source base to be functional. Some things might work better or perform nicer if Screen included them by default, but many of the changes are very "opinionated", which are usually difficult or impossible to contribute to a 25-year-old upstream project. Also, the GNU Screen project is moving very slowly, if at all. It's 25+ years old, and hasn't had an official release since August of 2008. Every distribution is carrying huge stacks of patches just to keep your /usr/bin/screen working and secure. e.g., Ubuntu and Debian are currently carrying 19K lines of code in ~48 patches.

I learned of Tmux about 2 years ago, and really fell in love with the source code, design, interface, and active community! I've had a much easier time contributing fixes to upstream Tmux and discussing topics on the mailing list. And as a Byobu user who uses it everywhere, I wanted the same look and feel to my Tmux sessions as what I had come to enjoy in 4+ years of Byobu. So I ported all of the Byobu code to work equally well with Tmux as the backend, as Screen. As of the Byobu 5.0 release, Tmux is now the default backend, with Screen still supported in a legacy mode. Byobu now leverages many of the modern features of Tmux over Screen, including vastly improved 256-color support, UTF8 characters, and horizontal/vertical window splitting.

If you're satisfied with the default settings in Screen or Tmux, or want to write your own configuration files from scratch, then by all means, Screen and Tmux as fantastic utilities that have added many years of efficiency to our lives. If you're interested in a set of configurations that really stretch and extend what Screen and Tmux does out of the box, have a look at Byobu!

Cheers, Dustin

share|improve this answer
5  
Good explanation. Amazing that screen is so heavily patched - does it need a new maintainer or something? And byobu is great - thanks. –  nealmcb May 17 '12 at 1:45
3  
I wish I could up-vote twice. I've been using byobu for years now and have only just recently learned of the complexity that it's been hiding me from all this time. –  Jamie Cook Feb 19 '13 at 1:09
1  
I always use CTRL+` as escape. With screen` and tmux this works like a charm, but not with byobu (Debian 7.1 Wheezy). –  Tino Aug 30 '13 at 18:42

From an actual use case, the biggest difference between screen and tmux is how they handle split windows.

A window in screen is a single pseudo-terminal. When attached to a screen session, you can split your terminal into multiple regions, each of which can display a screen window. Multiple regions can display the same window. The splits are not part of the session; if you detach, your splits are gone.

A window in tmux consists of one or more pseudo-terminals, one per pane. This means that panes persist if you detach and reattach later. It also means that you can display only one window at a time in tmux, and that panes cannot be shared among multiple windows. tmux does allow a window to be shared among multiple sessions, however.

I prefer the model used by tmux, but I couldn't argue that it is better than the model used by screen.

share|improve this answer
    
The argument pro tmux is the Deutsche Bahn. Ride a fast train, try to work over ssh using a mobile connection and you will quickly see that the tmux model is far superior, because after one of the frequent connection breaks you do not need to re-arrange all the panes on your jumphost after relogin. SCNR –  Tino Aug 30 '13 at 18:55

For me, the deal-breaker for tmux was the implementation of session sharing.

In GNU Screen, if you let another user connect to a session, or simply have your session connected to more than one terminal, they can operate independently (switching screens in a session A from terminal B doesn't make terminal A also switch screens in session A).

The above is not the case with tmux (yet?) or I haven't been able to find a way to change the behavior yet.

If someone knows of a way to change this behavior in tmux or if tmux updates to change this behavior or give the option to now change this behavior, please leave a comment.

share|improve this answer
1  
tmux has a notion of "linked" sessions with new-session -t shared. Windows from 'shared' appear in the new session, new windows in one appear in the other, and closing a window in one closes it in the other. However, which window each client sees is specific to the actual session it attaches. –  chepner Aug 30 '13 at 19:16

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.