So far I have used Konsole to manage multiple shell sessions but I haven't tried Byobu, GNU Screen, and tmux, which offer better support for multiple shells. They all share one main feature, which is to allow detaching the current session and later reattaching to that old session.

To help me pick a tool to learn, I'd like to know: how do they differ in the following respects?

  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. Learning curve
  4. Availability in different platforms. If I learn a tool, I'd like to be able to use it on a FreeBSD server, SuSE desktop, or Ubuntu.
  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 did someone create Byobu instead of contributing to the GNU screen project and adding new features? Why is Byobu 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 transfer this knowledge to use GNU Screen without Byobu if a certain machine only has GNU Screen?

  • 1
    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, 2012 at 12:34
  • 2
    Because byobu is just a fork of screen with extra features, so the gnu-screen tag applies. May 11, 2012 at 12:40
  • 2
    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, 2012 at 12:48
  • 1
    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). May 11, 2012 at 12:55
  • 29
    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. May 11, 2012 at 15:54

4 Answers 4


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.


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

  • 25
    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, 2012 at 1:45
  • 15
    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, 2013 at 1:09
  • 3
    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, 2013 at 18:42
  • 1
    Now that screen has got a new maintainer and development seems to have picked up steam, do things change?
    – muru
    Nov 4, 2014 at 7:29
  • 1
    @user2707671 The OP said explicitely "I've had a much easier time contributing fixes to upstream Tmux and discussing topics on the mailing list."
    – leogama
    Jun 7, 2020 at 1:58

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.

  • 5
    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, 2013 at 18:55
  • 7
    if you are facing frequent disconnections, I suggest looking into mosh which can recover automatically from lost signal, unlike ssh Apr 2, 2017 at 15:25

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.

  • 9
    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, 2013 at 19:16

Not the answer you're looking for? Browse other questions tagged .