Byobu vs. GNU Screen vs. tmux — usefulness and transferability of skills [closed]

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?

For Tmux vs GNU Screen, read

• tmux vs. screen [SU]
• tmux vs. GNU Screen [Unix.SX]

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

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.