What’s next in Red Hat Enterprise Linux (part 1)

This is the first in a two-part series from Summit presenter and Red Hat/Fedora engineer Bill Nottingham. It is based on the talk he gave at this year’s Red Hat Summit. Part two will be published later this week.

One of the most-asked questions in the software world is:

“What’s coming in the next release?”

Red Hat® Enterprise Linux® is no different. You can wait for the beta, and pore over the release notes and the package changelogs. You can corner a product manager at the right moment. But the easiest and best way to get the scoop on what’s coming up in future Red Hat Enterprise Linux releases? Take a look at Fedora.

Fedora, for those that don’t know, is a freely available and distributable Linux-based operating system that showcases the latest in free and open-source software. It’s developed globally within the Fedora project community, and is where Red Hat innovates. Read on as we describe some of the innovations in Fedora that will be headed for future Enterprise Linux releases.

Handling of displays

Have you ever tried to configure a projector on your Linux box? How much swearing was involved?

On Red Hat Enterprise Linux 5, configuring a projector can be complicated. It might involve editing your Xorg configuration file to add archaic configuration directives, and then restarting your session, losing anything you have open.

Fedora improves on this with the introduction of the new XRandr extension. XRandR stands for X Resize and Rotate, and it’s a mechanism for dynamically changing the screen’s resolution and orientation at runtime. What’s more, it includes support for dynamically changing the attached displays at runtime. So all you need to do is attach your projector, open up the Screen Resolution utility in the Hardware Preferences menu, and you’re ready to go. You can configure the displays to be mirror images, or arrange them in any configuration you like.

Package management

If you’ve used Fedora lately, you may have noticed the ‘bug’ icon in the notification area. This is part of PackageKit, a new distribution-neutral package management system that abstracts away the machine’s packaging system (in our case, yum and RPM) to provide a simple, usable, interface for the user.

PackageKit is implemented in a client-server fashion–all the package installations and removals are done in a privileged backend, while the user interface code runs unprivileged, and talks to the backend over d-bus. Fedora (and later Enterprise Linux) uses a yum backend for PackageKit; other backends (for Debian or Ubuntu packages, for example) also exist.

If I click on the applet, I can easily review what updates are available, and which bugs each update will fix. I can then choose the ones I want and apply them.

Not only will PackageKit notify me when updates are available, but it can be configured to automatically install updates. This is especially useful for security updates.

PackageKit also comes with a general software installation tool. With it, I can browse the software on my system, and pick out packages to install. Once I select a package, I can check which files are included, what the package depends on (or what depends on it), and even visit the package’s homepage for more information.

In the future, we’re working on refining and cleaning up the PackageKit UI, and extending its use. New features might include automatically finding available codecs needed for multimedia files, or finding and installing office software like OpenOffice when you’re sent an office document. For more information on PackageKit, see the PackageKit website.

Privileged apps for non-privileged users

In Red Hat Enterprise Linux, you may be familiar with this dialog:

This dialog is part of userhelper, a graphical authentication system. However, it’s a system that has various issues:

• It’s rather inflexible
  • The only configurations available are root or user password
  • It cannot be reconfigured so that only certain users or groups are authorized
• Once they are authorized, any commands run as root
  • This is obviously bad. One of the fundamental tenets of computer security is to limit the amount of code running with elevated privileges. For some of the apps launched by userhelper, the code running as root can include entire graphical toolkits.

In Fedora 9, we set out to solve this with PolicyKit. PolicyKit is a framework for defining system policy to allow unprivileged apps (such as end-user UIs) to talk to privileged code (such as application installers, or configuration systems).

Let’s look at an example. If I right-click on the clock applet, I see the option to ‘Adjust Date and Time.’ If I choose that, and adjust the time, I see a PolicyKit authorization dialog. Once I enter the proper authorization, PolicyKit then invokes the privileged backend with the necessary data, and sets the clock. This was all done without running any part of the clock applet as root.

Now, to the user, the interface is much the same as before. For the administrator, however, PolicyKit opens up a wealth of new possibilities. This can be seen in the ‘Authorizations’ tool in the System Preferences menu. If I choose ‘Setting the system time’, we can see the authorization I just used. I can edit it, or add new authorizations for other users. I can even add implicit authorizations–for example, I could set it so that any user in an active console session can reset the clock.

Of course, to edit these also requires authorization via PolicyKit. And the package update we did earlier? That was authenticated via PolicyKit, too.

In Fedora 9, we have a limited number of tools authorizing via PolicyKit, but in future releases, we intend to expand this across the OS. For more information on PolicyKit, see the PolicyKit reference manual or David Zeuthen’s LCA talk (PDF).

Power management

Another issue we’ve been working on is power management. A recent article in NetworkWorld showed that Red Hat Enterprise Linux 5 used as much as 12% less power than Microsoft® Windows® on identical hardware. But we didn’t stop there–we’ve made it even better in Fedora.

The first improvement is the tickless kernel. One of the best ways to save power is to keep the CPU as idle as possible. In older kernels like the one used by Enterprise Linux, there is a timer that ticks a certain number of times per second. When that timer fires, the kernel looks around to see if there’s anything to do. Generally, this timer runs anywhere from 100 to 1000 times per second. Obviously, the kernel waking up that often isn’t very conducive to staying idle. With the recently-introduced tickless kernel, it only wakes up if prompted by something that needs attention.

Obviously, that won’t help you if you have lots of kernel threads or userspace apps that are keeping the kernel busy. To combat this, we worked with a userspace tool called ‘powertop,’ originally written by Intel. Powertop tracks the number of kernel wake-ups, and associates them with hardware devices, kernel threads, or userspace programs.

Since powertop was introduced in Fedora, we’ve been constantly running it looking for misbehaving applications. Some examples:

• pidgin would ask the X server if it supported the XScreenSaver extension every five seconds… even though the answer would never change
• ntp would wake up more than once per second to do work
• media players would send silence to the sound card after playback was stopped, keeping the sound card active

There have been many more discoveries–like apps that poll much too frequently for changes or kernel drivers that are too busy. We’ve been working on fixing these, and and so far we’vemoved from Enterprise Linux 5 having over 1500 wake-ups per second and consuming over 18W when idle (without wireless) to about 50 wake-ups per second, consuming less than 16W.

Further work to reduce power consumption is being done. For laptops, there are things like backlight control for the LCDs, and X tricks that compress the framebuffer so it takes less juice to refresh the display. But it’s not just laptops–reducing the number of wake-ups and decreasing other unnecessary power usage is just as useful in the datacenter. Less power usage means less heat generated and less cooling needed, lowering energy bills all around.

About the author

Bill Nottingham is an engineer at Red Hat, where he’s worked on Red Hat Linux, Red Hat Enterprise Linux, and Fedora for the past ten years. (yipes!) He currently serves on the Fedora Project Board and the Fedora Engineering Steering Committe, and maintains a variety of packages in Fedora.

This entry was posted by The editorial team on Tuesday, July 29th, 2008 at 5:22 pm and is filed under Fedora, Red Hat Enterprise Linux. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.