Releasing 2.0

After 54 mini-releases of screen-profiles-1, I’m pleased to declare a 2.0 release! I believe that the project is more stable, more feature-filled, and better performing than ever. screen-profiles has become much more than a fun little hack… I believe that it is ready for general usage.

Changing the Name of the Project

In conjunction with the 2.0 release, I am also renaming the project. The new name of the project and packages is byobu.

Byobu is a Japanese term for decorative, multi-panel screens that serve as folding room dividers. I think this is a fitting description of this project–an elegant enhancement of otherwise functional, plain, practical screens.

The pronunciation, as I understand it, is something like: beeyo-boo.

Update: A reader, Fumihito YOSHIDA, has provided me with a WAV file of byobu being pronounced by his friend, Nobuto MURATA, under the Creative Commons Attribution 3.0 Unported license.

Update: Micah Cowan, a GNU Screen developer, also provided a pronunciation of byobu at Thanks!

Explaining the Name Change

So why am I changing the name? I’ll enumerate a few reasons…

  1. I have never really liked the term screen-profiles as a permanent project name. It has always been sort of a “working title.” (Think Star Wars: Episode VI’s original title, Revenge of the Jedi)
  2. Like screen itself, the name screen-profiles is functional and descriptive, but perhaps a little bland.
  3. At the birth of the project, it really did provide simply a static set of profiles. But these are far more dynamic, and configurable now. The vast majority of the code is no longer in the profile itself, but in the configuration utilities and status gathering scripts that customize screen.
  4. The project is in the process of being packaged for at least Debian, Fedora, and OpenSUSE, and Ubuntu’s Karmic Koala has not yet entered Alpha1. The timing for a name change is as good as it is going to get.
  5. byobu is such an appropriate name! It expresses elegance, color, multiple panels, and function. Like Ubuntu, it’s an interesting word in a foreign tongue. It also rhymes with GNU. Try saying: Byobu is new GNU fu in Ubuntu, 10 times fast 🙂

Looking Forward

What’s next for byobu?

I believe that GNU Screen can and should be used as a window manager on Linux servers (or at least command-line-only environments) in the same way that Gnome, KDE and XFCE are used on Linux desktops. Following this analogy, you might look at Byobu as providing a functionality similar to a compositing window manager like Compiz or Beryl. Something like Compiz is certainly not for everyone, and is easy to disable. However, it is useful to some people and can certainly enhance the overall desktop experience. And that’s really my goal for byobu — to enhance the experience and usability of screen, and the command line in general.

In the byobu 2.x series, I hope to implement:

  • Additional toggle-able status items in the bottom status panel
  • Detailed callouts for each status item
  • Better interaction with various terminals
  • Additional keybinding sets
  • Configurable support for external notifiers, like notify-osd
  • Internationalization of the text

Updating Links

I’ve made most of the necessary changes in the source code, though I’m still in the process of updating the various links and documentation. The most important ones are:


I am in touch with both Reinhard Tartler, who is handling the Debian packaging, and David Duffey who is handling the Fedora packaging. I should have the new package uploaded to Karmic later this week, and make packages available for Hardy, Intrepid, and Jaunty in the byobu PPA.


Ryan Paul attended yesterday’s Ubuntu Open Week talk on screen-profiles, and wrote an excellent article about it for Ars Technica.

Thanks, Ryan!


I led an Ubuntu Open Week session earlier this morning on screen-profiles.

As part of the session, I setup a demo on an Amazon EC2 instance running Ubuntu 9.04. In that shared screen session, I as the “teacher” had read/write access to the instance, and 50+ “students” had read-only access. This proved incredibly handy for doing such a demonstration!

I did, however, have to configure a number of things manually to enable screen to operate safely and securely in such a shared environment.

A number of people asked me how I did this, so I thought I’d document those steps here…

  1. The screen binary must be setuid root. There are plenty of reasons why we don’t do this by default in Ubuntu! However, this is absolutely required to use the multiuser feature of screen:
    $ sudo chmod 6755 /usr/bin/screen.real
  2. Once we’ve changed this, we must now change the permissions on the shared run space:
    $ sudo chmod 755 /var/run/screen
  3. Now, launch screen, title it “class”, and select the light profile:
    $ screen -S class
  4. Next, add the following screen configuration parameters in your ~/.screenrc:
    # Ensure that permissions are propagated to all new windows
    aclumask guest+r guest-w guest-x
    # Give your guests read, but not write or execute permissions
    aclchg guest +r-w-x “#?”
    # Allow your guests to switch among windows, and detach
    aclchg guest +x “prev,next,select,detach”
    # Enable multiuser
    multiuser on
  5. And reload your profile with F5
  6. Next, edit /etc/ssh/sshd_config, and add this to the very end, to ensure that our guest user can login with a password, no forward ports, and only launch this one command:
    PasswordAuthentication yes
    AllowTcpForwarding no
    Match User guest
    ForceCommand screen -x ubuntu/class
  7. Also, if this is Amazon EC2, you’ll need to enable password authentication in /etc/ssh/sshd_config with:
    PasswordAuthentication yes
  8. Now, let’s add our guest user, set a password, and ensure that your guest users cannot mess with one another:
    $ sudo adduser guest
    $ sudo chown -R root:root /home/guest
    $ sudo touch /home/guest/.screenrc
  9. And restart sshd to get your configuration changes to apply:
    $ sudo service ssh restart

At this point, you should be able to direct your guests to ssh into your Ubuntu server instance. Upon login, they should immediately be connected to your shared screen session, and should only have access to:

  • F3 (previous window)
  • F4 (next window)
  • F6 (detach)

For more information, see the resources I used to compile this information:


My Canonical Ubuntu Server Team colleagues, Soren Hansen and Thierry Carrez, have recently published manifestos on what they would like to see the Ubuntu Server become. Accordingly, here are my thoughts on the matter…

What I Want The Ubuntu Server To Be…


Security is the most important element of a server to me. Kees, Jamie, and Marc on the Ubuntu Security team do a fabulous job keeping the Ubuntu packages updated, and our servers safe from published CVE’s and known security bugs. They have hardened the Ubuntu toolchain in such a way that protects Ubuntu binaries from vast classes of vulnerabilities.

But, I believe that security goes far beyond fixing bugs in code. I believe that Security also consists of feature development. I believe that we’ve done a decent job integrating some really useful security features, such as:

  • AppArmor
  • Encrypted-Home and Encrypted-Private directories
  • ufw

I hope that we expand this list tremendously over our next releases.

I think every Ubuntu user (desktop and server) should automatically have an Encrypted Private directory where they can store their most sensitive information, with an easy option to encrypt all of $HOME.

I think we should use swap files, rather than partitions, by default, with supporting applications to automatically and manually resize it when your memory availability and requirements change. And I think you should be able to easily enable/disable swap encryption at your discretion–encrypted swap is essential for encrypted-private and encrypted-home directories.

I would like to see us move toward having ufw enabled and running by default. I think this means that all services would need appropriate hooks to open the necessary ports for operation–something that needs to be implemented carefully and over time.

I would like AppArmor and/or SELinux profiles for everything! This is a lot of very expert-level work, that I don’t really want to do myself 😉 I want to run my servers with fully enforcing MAC protection, but I don’t even want to know it’s there. Yes, this is a tough one, I agree. I was an SELinux developer working on Fedora and Red Hat when they first turned SELinux ‘on’. It was painful. Maybe it still is? (I don’t know.) This is a lot of work, but totally worth it in my opinion.

Easy To Use

I would like the Ubuntu Server to be the easiest, friendliest Linux server on the market.

To some people, this means having a graphical desktop. For those people, I’d like to expose a simple option to basically:
$ sudo apt-get install –no-install-recommends ubuntu-desktop
Which would install a graphical desktop manager without some of the desktop addons like Evolution and OpenOffice, but continue to use the server flavor kernel. It might even be worth using XFCE rather than Gnome…

I don’t think graphical desktops should be installed on the majority of servers, however. Most people don’t need a graphical desktop manager, they simply need a window manager. For that, we have the command-line utility ‘screen’. I’ve blogged several times about a new package I created with help from Nick Barcet: ‘screen-profiles’. I think one of the screen-profiles configurations should be configured by default for each user on the server, and automatically launched on login. I believe that a shell running inside of a screen-profiles configuration for ‘screen’ should be the face of the Ubuntu server.

I would also like to see an ever growing set of tasksel package sets, for creating Ubuntu servers with stacks of applications configured and working well together. I have been installing Tomcat on Linux servers since the Summer of 2000, and it’s been a huge pain for almost 8 years. Thierry’s work on Ubuntu’s Tomcat packaging (and all the Java dependencies) has finally made this a one-step operation… sudo apt-get install tomcat6. Beautiful! I would like to see the same quality for other complex application stacks (eg, alfresco, sugarcrm).

Also, a complete “collaboration server” stack would be phenomenal, containing servers for a wiki, irc, document editing, listserv, pastebin, etc. Any small business using open tooling should be able to get all of these in a box, up and running in a matter of minutes or hours.


We added LVM-by-default for Ubuntu servers in Jaunty. And Soren had the brilliant idea of always installing Ubuntu Servers with a degraded RAID-1. This would make it really easy to add a second disk to a server sometime later. Great idea. I’ve done this before with my servers (actually, created a mirrored RAID on a server that was not setup for it). There was a painstaking set of very specific steps that had to be executed perfectly. We would need some additional tooling in userspace (beyond just the installer) to make the feature practical. But this is quite doable.

I hope we take a close look at ksplice for Ubuntu servers. For non-ABI-changing kernel updates, ksplice can actually roll out kernel changes to a running kernel, merely by compiling some code and inserting a module. Scary, I know. And it needs some heavy testing and security review. But in the interest of uptime, this could be an incredible feature. I met the developers at the Linux Foundation Collaboration Summit, and it seems that they do much of their testing and development already on Ubuntu. I think this would be pretty cool.

Also, I’m a big fan of Thierry’s work on putting /etc under revision control. This is a great idea, very easy to use, minimal overhead. I’m hoping we’ll see this on Ubuntu servers by default very soon, and possibly on the desktop too.


I would like the Ubuntu server to be the ‘greenest’ Linux server distribution on the planet. We took a couple of steps in this direction in Jaunty (ondemand cpu frequency scaling on by default, server suspend/hibernate/resume working, powerman & pwrkap packaged). But there’s a lot more to do!

Cloud computing and virtualization presents us with new opportunities and challenges with respect to power management. I’m hoping to keep Ubuntu on top of these, with integrated functionality for migrating and consolidating workloads to the minimum number of virtualization hosts required to do the job, placing the rest in a suspended or hibernated state, and dynamically resuming hot-spare hardware when dictated by load.


I’m quite interested in btrfs. I don’t know that we’re quite ready to default to btrfs (for stability reasons), but I’m quite interested in heavily testing btrfs in Karmic, as there are some tremendous performance benefits available.


[UPDATE: The screen-profiles project has been renamed, ‘byobu’. The functionality described in this article is now supported there.]

2009 is shaping up to be the Year of Cloud Computing!

Ubuntu Jaunty Jackalope is set to release next month (9.04) and introduce Eucalyptus as an important building block for establishing cloud capabilities in your data center using entirely open source technologies within the Ubuntu distribution.

Meanwhile, the Canonical Server Team is also working diligently to deliver Hardy, Intrepid, and Jaunty images for Amazon EC2, for cloud computing beyond your local data center.

And looking a bit further out, Mark Shuttleworth has an ambitious vision for Ubuntu Karmic Koala, making it easy to deploy applications to the cloud, ready-to-run cloud applicances, and image creation utilities.

We’re hoping to position Ubuntu as an ideal platform for your cloud computing needs.

I believe many system adminstrators and IT departments will soon ask themselves:

  • When Amazon’s EC2 is appropriate for our workload?

I have written a small utility, called ec2-cost that can help you analyze this question. It is included in Ubuntu in the screen-profiles package.

If you’re running Jaunty, simply:

  • sudo apt-get install screen-profiles

Otherwise, you can grab the package for Hardy or Intrepid from:

Then, run:

  • screen
  • touch $HOME/.screen-profiles/ec2-cost
  • Hit F5, then ENTER

In the status bar across the bottom of your screen, you’ll see several bits of system status, including an approximate running total cost of your current system. This estimation accounts for the current system uptime, number of processors, inbound, and outbound network activity. It does not yet account for S3 storage charges, or the 10% hike in European instance pricing, but such patches are welcome 😉 You can find the code in:

  • /var/lib/screen-profiles/ec2-cost

Here are a few screen shots…

This little test machine, which lived a total of 4 hours, would be quite affordable in EC2 at ~$0.41:

Let’s imagine that I used this system to do some heavy duty number crunching overnight. ~$14.73 might be a pretty good deal. In fact, if the application I’m running is parallelizes well, it might even be less costly (in time or money) to use one of the 8-CPU large instances:

On the other hand, I have determined that EC2 would not be a good model for my always-up production website,, which has some 400+ days of uptime, at ~$967.13 and counting:

If you want to run the utility outside of screen-profiles, that’s possible too:

kirkland@living:~$ /var/lib/screen-profiles/ec2-cost --detail
Estimated cost in Amazon's EC2 since last reboot
Network sent: 7.918646 GB @ $0.10/GB
Network recv: 68.167842 GB @ $0.17/GB
Network cost: $8.162954
Uptime: 303 hr @ $0.200000/hr
Uptime cost: $60.600000
Total cost: ~$68.76

There are certainly other factors that you may need to consider, such as the privacy of your data and whether that belongs in a remote cloud, the scalability of your own hardware versus Amazon’s, your own heating/cooling/bandwidth costs, etc. before you can make a fully informed decision.

But hopefully this little utility can help with the initial analysis. And like watching your system load, or memory utilization, it might help you better understand the nature of your server’s workloads.


As requested, there is now an ubuntu-dark theme for Ubuntu’s screen-profiles. This allows you to choose between light-on-dark, or dark-on-light colors for the window panel and the status panel across the bottom of your screen.

Make sure you have at least screen-profiles_1.15-0ubuntu1, which you can retrieve from:

And then run:

$ select-screen-profile

Select a screen profile:
1. plain
2. ubuntu-light ---- recommended
3. ubuntu-dark

Choose: 1-3 [2]: 3

If your terminal is also configured for light-on-dark, or if you’re on a tty console, your screen should look something like this:

Thanks to Tyler Willingham for the suggestion and the patch/branch in Launchpad.


On December 14, 2008, I posted about screen – the window manager for the Ubuntu Server.

A lot has happened since then, mostly over the Christmas and New Year’s holidays.

With the help of Nick Barcet (and contributions from several others, including Dave Walker, Jamie Strandboge, Nicolas Valcarcel, and Marc Deslauriers), we have a new package in Ubuntu Universe for Jaunty: screen-profiles.

I’m quite proud of what we’ve accomplished thus far with the package–we’re bringing some bling to the Ubuntu Server.

Across the bottom, we have panel displaying a three-color logo, the Ubuntu release, a notification that a reboot is required (@), 77! updates are available, the current system load is 0.27, the system has 2 cpu’s, currently running at 800MHz, 3.9GB of memory, the current date and time. All of this in less than 80 characters.

Above the status panel is another panel, showing the open windows in the current screen session. You can see that I have 4 windows dedicated to: root, screenbin, screen-profiles, and Daemon.

This is intended to communicate some of the same information available in the upper and lower panels on your Ubuntu desktop.

Nick has created the excellent screen-profiles configuration utility, accessible by pressing F9.

From the Help screen, you can see the hotkeys we have defined within this custom screen profile, to help navigate among your windows.

Beyond the Help screen, there are several other functions available on the main Menu.

These are intended to help you customize and improve your screen experience.

I find the last option most interesting. Here, you can toggle screen-by-default. If you turn this on, each time you ssh into your system, or open a new terminal on your desktop system, you automatically launch into a screen session (reconnecting to an existing one if available). I’m enjoying this feature quite a bit!

Call for testing!

At this point, we’re looking for some testing and feedback. Please file bugs at:

Based on that feedback, I’m going to push a Main Inclusion Report for screen-profiles, and add screen-profiles to the Ubuntu Server Seed.