LWN.net Weekly Edition for August 6, 2009

A default desktop for openSUSE?

The choice of a Linux desktop environment, typically between the "big two": GNOME and KDE, is one that inspires enthusiastic advocacy—some might even say religious fervor—among the supporters of each choice. So, it should come as no surprise that a distribution's default choice of desktop—the one that most new users will end up running—can be contentious, as the supporters of each desktop jockey for recognition of their choice. That battle is currently playing out for openSUSE after a proposal to make KDE the default desktop was made in the openFATE feature tracker; since then, a number of rather lengthy threads on the opensuse-project mailing list, as well as postings on various web logs, have made for a lively debate.

The first argument for choosing a default desktop generally centers around new users. Most seasoned Linux users will have already chosen a desktop suited to their needs; as long as that desktop is supported, they should have no trouble installing the distribution. New users, on the other hand, are generally not even aware that there is a choice of desktops for Linux. By choosing a default desktop, a distribution can ease the path for a new Linux user.

Unlike most of the major distributions, openSUSE has no default desktop, so users are presented with the choice of GNOME or KDE as part of the installation process. The other major distributions default to GNOME—with the exception of Mandriva—but support KDE users with a separate distribution of some kind (e.g. Kubuntu or the Fedora KDE spin).

The lack of a default for openSUSE is, to some extent, a historical artifact. When Novell bought SuSE Linux a few months after it bought Ximian, there was a bit of a culture clash. SuSE was KDE-based, but Ximian was a sponsor of GNOME (and Mono) development. According to a blog posting by KDE's Sebastian Kügler, Novell wanted to move both enterprise and desktop distributions to a GNOME default—or perhaps remove KDE entirely—but eventually decided to only do that for the enterprise releases; for desktops, there would be no default.

For a while, KDE was listed ahead of GNOME in the openSUSE installation dialog, but at some point, the order of the two desktops in the installation dialog was reversed. That makes sense, at least alphabetically, but, to some, it still felt like a KDE demotion. That dialog has a short blurb associated with each desktop choice, but neither is selected, so the user must choose.

The openSUSE community is largely made up of KDE users; something like two-thirds of users run either KDE 3.5 or KDE 4 according to the openSUSE 11.0 user survey [PDF]. That leads some, especially KDE fans, to suggest that openSUSE default to the desktop used by a significant majority of its users. The proposal was quickly voted as the highest rated feature request in openFATE, with roughly 90% approval, according to openSUSE board chair Michael Löffler's blog posting.

KDE-default advocates note that in addition to its potential to reduce confusion for new users, making KDE the default would raise openSUSE's profile within the KDE community, which might well lead to more users, developers, and packagers for the distribution. Part of the argument is that openSUSE makes default decisions for most kinds of applications (web browsers, email readers, etc.), but leaves the desktop choice to the user, so, instead, openSUSE should make a default decision there as well. By putting KDE on an equal footing with GNOME, openSUSE is actually treating KDE as a second-class citizen. As KDE and SUSE developer Lubos Lunak puts it:

There is also a political subtext to making KDE the default. For much of its history, openSUSE was completely controlled by Novell, but more recently it has been opening up to become more of a community-led distribution—following a similar path to that taken by Fedora a few years earlier. To some, changing to a KDE default is seen as a way to show that openSUSE has moved out from under Novell's thumb. In some ways, openSUSE has been tainted by the patent deal that Novell made with Microsoft—at least to some—so, some distancing from Novell would be welcome as Will Stephenson points out: "This would go a long way to undoing the 'Novell is evil' smell that we can't shake off."

Community manager Joe "Zonker" Brockmeier is sympathetic to the idea that openSUSE show that it can "make decisions independent of Novell", but doesn't agree that changing to a KDE default is the right choice for the project. He is concerned that elevating KDE to a position above GNOME might alienate users and developers of the latter, while not providing much in the way of a boost to the numbers of openSUSE KDE folks:

Lunak suggests that there be guidelines to help determine what default choices openSUSE will make. As he has noted several times in the threads, there aren't choices for text editor or web browser, so why is the desktop treated differently? He also points out that the current default web browser—firefox for both GNOME and KDE—might need to change at some point:

Some guidelines, at least for the desktop case, have been proposed by former openSUSE board chair Andreas Jaeger. In his proposal—which seems to be gaining some support—he suggests that desktops be listed in alphabetical order and that the most popular be selected by default. He also suggests that the desktop choice screen should "explain that both GNOME and KDE are first class desktops and the default is based on popularity". How ties or near-ties would be broken is not specified, but there would have to be a fairly sizable shift in the openSUSE community for that to be a problem—GNOME users account for roughly 26% of those surveyed.

This is not the first time distributions have struggled with this problem; Fedora went through a similar exercise back in April. The initial suggestion, made by Jóhann Guðmundsson, was to change references to "default desktop" or "Fedora desktop" to "GNOME desktop", so that the desktop choice made by the project was clear. His point was not change the default, but just to call it out so that other desktops and their users would be on an equal footing.

That led to a lengthy thread—sound familiar?—discussing how to handle desktop choices at installation time (among other things). The problem is that there is no "right" decision that a distribution can make. Forcing the user to choose is bad for new users; as Naheem Zaffar put it: "Choice is only good if you are informed enough to exercise it." Distributions are expected to make these choices, and, in the end, they have to. When booting a Live CD of some distribution, the last thing a potential new Linux user wants to do is make an uninformed decision about which desktop to use.

As an aside, it is interesting to note a complaint made by Josephine Tannhäuser who was unhappy to see that KDE 4.3 will be coming to Fedora 10 and 11, without a similar upgrade for GNOME (to 2.26) in Fedora 10. The stability required for GNOME as the default desktop may be part of the resistance to a major GNOME upgrade for a distribution that is getting towards the end of its lifecycle. There may be other reasons as well—the GNOME 2.26 upgrade may be more intrusive than KDE 4.2.4 to 4.3 for example—but it is likely that non-default desktops are afforded more flexibility.

Clearly, some in the KDE community would like to see there be a high-profile distribution that defaults to that desktop. There are undoubtedly some who are still smarting from the perceived—or real—slight when SUSE moved from KDE to GNOME/neutral after the Novell acquisition. At some level, openSUSE seems like a good candidate for that distribution, but it could conflict with the stated goal to be "the distribution with the best GNOME desktop and the best KDE desktop", as Jaeger described.

With two full-featured desktop solutions—as well as more minimal choices for those who want them—Linux can certainly meet the needs of most users. There is a hurdle to get over, though, one that the proprietary alternatives don't require. The best long-term solution is likely to involve raising the profile of the desktop choice to new users, so that they can make a reasonably informed decision—similar to the distribution choice they already have to make. How they get that information is an open question, but that question once existed for the various distributions as well. It would seem that the desktop projects may need to get better at educating users—and potential users—about the strengths of their solution. If that happens, the default desktop choice will likely become less politicized and lead to fewer lengthy mailing list threads.

Comments (51 posted)

Clutter 1.0 brings stability, new animation API

Version 1.0 of the Clutter graphics library was released on July 29, sporting a stable application program interface (API) and binary interface (ABI), an animation framework, and an OpenGL abstraction library that should prove useful to developers. With Clutter set to take on a more prominent role in the GNOME 3.x series, the announcement should prove to be welcome news to application developers.

Clutter is used to build user interfaces, but unlike traditional toolkits such as GTK+ or Qt, it uses a flexible "scene graph" model with "actors" and "stages" instead of the customary widgets and containers. The free-form actor elements can be placed with fixed positioning on the stage or use managed layout, and they can be easily moved, deformed, and even animated. Clutter is designed to use OpenGL as a back-end, so applications can benefit from hardware accelerated rendering. OpenGL for Embedded Systems (OpenGL ES) is supported, making Clutter a popular choice on slim-CPU mobile devices such as Nokia's Maemo tablets and Moblin's netbook Linux distribution.

The project was started in 2006 at embedded Linux development firm Opened Hand, which was acquired by Intel in late 2008. Clutter has been selected as an official part of the Maemo GUI stack, beginning with the upcoming 5.0 release, called "Fremantle." Following Opened Hand's acquisition by Intel, however, more effort went into integrating Clutter as a core UI library for Moblin, which prior to April 2009, was an Intel-owned effort. The toolkit is also growing in popularity on desktop Linux systems, where it is used by GNOME games, the Mutter window manager, and the GNOME Shell project set to be featured prominently in GNOME 3.0.

Although Clutter is written in C, bindings are available for a wide variety of languages, including C++, C#, Python, Ruby, Vala, JavaScript, and Perl. In addition, applications can embed traditional GTK+ elements, GStreamer video content and Cairo 2-D canvases as Clutter actors. Clutter is developed primarily for usage under X with the GLX extension, but can also use Simple DirectMedia Layer (SDL) or the Linux frame buffer if necessary. Ports to Windows and Mac OS X are also available. Using ClutterScript, Clutter applications can store and load full or partial scene graphs in JavaScript Object Notation (JSON) format.

Changes in 1.0

The Clutter API has undergone several important changes since the last stable series, 0.8, but the development team has declared the 1.0 API frozen for all subsequent 1.x releases. Apart from stabilizing the API, Clutter 1.0 includes a new animation framework, unified handling of all text widgets with Pango, performance improvements based on better tracking which actors in the scene graph will be painted, debugging facilities for application developers, and improvements to the Clutter OpenGL abstraction library COGL. The Clutter and COGL documentation also underwent extensive revision, including a migration guide for developers needing to port their code from Clutter 0.8 to Clutter 1.0.

The Animation API has received the most attention of the changes in 1.0, being the subject of several conference talks this summer. In prior versions of Clutter, animation of actors was handled through two separate features: Behaviors and Effects. Behaviors were to be used when both the starting and ending states of the actor were known (such as moving from one predetermined position to another), and Effects could be used at any time, regardless of the state of the actor. The Effects API proved to be kludgy and difficult for application developers to use, as well as difficult for the Clutter developers to extend, so it has been dropped in favor of the Animation API.

The new API is both simpler and shares base classes, such as Timeline, with the Behaviors API, which should simplify its adoption. Whereas in Effects each transformation was a separate function (e.g., rotate, fade, translate), Animation requires only specifying the desired final state of the actor with a single function call; the animation itself is performed implicitly, with all of the intermediate steps interpolated. This "tweening" behavior is similar to what is possible with JavaScript animation. The Clutter 1.0 migration guide provides some side-by-side example code demonstrating the difference between using Effects and Animation.

COGL is also significant; it began as a purely internal layer for Clutter to abstract away the differences between OpenGL, OpenGL ES 1.1, and OpenGL ES 2.0, but it has since evolved into a library useful for other OpenGL-based projects. COGL attempts to make OpenGL usage as fast as possible by maintaining its own internal store of the scene rather than sending every update to the GPU separately, caching as much as possible, and minimizing the number of validations and state changes.

1.x, 2.0, and more

The Clutter team has expressed its desire to further develop COGL into a more flexible GPU-programming library, providing a modern, object-oriented API for OpenGL programming. As for Clutter itself, the plan is to adopt a six-month release cycle, as used by other projects in the GNOME ecosystem. There will be further 1.x stable releases to improve performance and efficiency, but the guarantee is that no changes made during the 1.x cycle will break API compatibility.

GNOME will reportedly ship Clutter with its 2.28 release in September, but Clutter-based tools like GNOME Shell are not scheduled to arrive until the 3.0 release six months later. The API stability guarantee is more likely to please developers with mobile platform projects like Maemo and Moblin, however, who count on longer product life cycles than those of a typical desktop Linux distribution.

Independent application developers may have to wait a few more weeks before they can begin working with Clutter 1.0, though. The dependent libraries that allow embedding GTK+ widgets, GStreamer content, and Cairo canvases are a bit behind the core Clutter release, as are some of the language bindings. Fortunately, the official packages are built to be installable in parallel with Clutter 0.8, and with the documentation in place — including the migration guide — no one has an excuse to sit idly by in the meantime.

Comments (2 posted)

CentOS turbulence and enterprise Linux tradeoffs

CentOS has never been the most transparent of projects; its lists do not carry the kind of open discussion that can be found with Debian, Fedora, or (increasingly) openSUSE. Most CentOS users perhaps worry little about where their software comes from, but there are those who have tried to help the project and bring its workings more into the open. One of those, well-known RPM packager Dag Wieers, threw in the towel in June:

Problems within the project became more public on July 30, when a disturbing open letter was posted on centos.org. The immediate issue was the disappearance of project founder Lance Davis, whose last post on the centos-devel mailing list was in April, 2008. Evidently Lance hadn't been heard from for some time in other parts of the project as well. A missing founder can be a problem, but it gets worse: when Lance vanished from sight, he took with him control over the project's domain name and IRC channels.

Lance also had control over the project's finances. There has been a lot less noise concerning this part of the problem, but the fact remains: nobody seems to know where the money which has flowed into the project (via donations and web advertising) has gone. Quoting Dag Wieers again:

Naturally enough, this issue failed to resolve itself; eventually the other key CentOS contributors were forced to go public with their concerns. The move appears to have been entirely effective: Lance was flushed out from wherever he was hiding and met with the team. Ownership of the domain name has been transferred. The CentOS project appears to be back on track, and, perhaps, headed toward a more democratic mode of operation.

Little is being said about the financial side, beyond this:

So the management of future revenue into the project should be handled in a more open sort of way.

One could argue that CentOS users had little to worry about. In the worst possible scenario, the active CentOS developers could have forked the distribution and moved to a new domain, perhaps without even changing the name of the project. Such a move could certainly be successful. But users who have picked a distribution known for stability might just feel a little concerned about being told to change their repository pointers to a different location run by a group claiming to be the "real" CentOS. A certain amount of disruption would have been guaranteed.

There is a lesson here: use of a distribution like CentOS has its risks. A system running CentOS is relying on the efforts of a relatively small group of volunteers; these volunteers are not obligated to continue to provide support to anybody. The project's governance and processes are on the murky side - even if it looks like things are about to get better. CentOS is fully dependent on Red Hat for security updates, and it necessarily imposes a delay between the release of Red Hat's fix (which discloses any vulnerability which wasn't already in the open) and the availability of a fix for CentOS. For the curious: here is the observed delay time a few recent updates:

Package	Delay (days)
seamonkey	1
bind	1
python	2
tomcat	8
firefox	7
libtiff	7
dhcp	1
httpd	5

Sometimes updates pass through the CentOS system quickly, but other times the performance is not quite as good; the "critical" firefox update languished for a full week.

The point of the above text is not to criticize CentOS: that project has done an outstanding job of providing a highly stable and well-supported distribution to the community for free. How can anybody criticize that? The point, instead, is that there are tradeoffs associated with any distribution choice. A Linux user who feels the need for contractually-assured service backed up by a well-funded support operation and faster security updates would be well advised to consider purchasing support from one of the companies operating in that area.

For those who do not need that level of support, instead, distributions like CentOS provide great value. A more open CentOS looks like it should be able to provide greater value yet. Also encouraging are the suggestions that CentOS could work more closely with Scientific Linux, another RHEL rebuild with very similar goals. All told, there appears to be a good chance that the recent turbulence will lead to a more solidly founded CentOS which will continue to be a firm platform for many thousands of deployed systems well into the future.

Comments (47 posted)

Page editor: Jonathan Corbet

Security

SSL flaws revealed at Black Hat

The annual Black Hat security conference in Las Vegas is probably the premier security event each year—at least for the disclosure of new vulnerabilities. The event usually has one or more high-profile disclosures that often lead to software vendors and projects scrambling to fix the vulnerable code. This year was no exception, with Secure Sockets Layer (SSL) taking center stage. Two of the vulnerabilities led to Mozilla security updates, while others showed flaws in the certificate authority (CA) infrastructure and browser handling of Extended Validation (EV) SSL certificates.

The most serious problem would seem to be a disconnect between CAs and browsers on how to handle certificates with NUL (i.e. '\0') bytes in the domain name. CAs have been willing to issue certificates for host/domain names containing NULs, but browsers were handling them in ways that made certificate spoofing much easier. Moxie Marlinspike and Dan Kaminsky independently discovered the problem and both presented about it at Black Hat. Marlinspike's example was a certificate issued for www.paypal.com\0.thoughtcrime.org, which would appear to be a legitimate PayPal certificate to the browser user.

It has been argued that the CAs should not be issuing certificates of that sort, especially given that C-based programs interpret NUL as the end of string, but the browsers have a certain amount of responsibility here as well. It's hard to see a legitimate use for a certificate with a NUL byte as part of the domain name, but browsers could and should have used the string length, which is specified in the certificate to determine how to display and handle the domain name. The CAs should also stop signing such certificates, and revoke those that they have already issued, but that, of course, doesn't stop anyone from self-signing a certificate with a NUL byte in the domain name.

The flaw could be exploited to do a man-in-the-middle attack against users. An attacker who could intercept network traffic—via a compromised, or just maliciously configured, wireless router for example—could present one of these certificates when a victim visited PayPal. Because the browser only looked at the host name information before the NUL, the user would believe they had a secure session with PayPal, when, in fact, they were talking to a host under the attacker's control.

Marlinspike found another problem, which only seems to have affected the Firefox 3.0 series, in how wildcards were handled in the host names presented in certificates. Wildcard certificates are meant to solve the problem of multiple hosts in a given domain that need to share certificates. So, a CA could sign a single certificate that would work for webhost00.example.com through webhost99.example.com. Firefox 3.0 and earlier supported a non-standard Netscape regular expression syntax which Marlinspike found a way to exploit.

That exploit would cause a heap overflow that could allow arbitrary code execution—another particularly nasty outcome. According to the Mozilla advisory: "With version 3.5 Firefox switched to the more limited industry-standard wildcard syntax instead and is not vulnerable to this flaw."

Kaminsky's talk also covered a number of other issues with SSL certificate handling. Red Hat's director of security response Mark Cox summarized those problems along with their impact on various free software packages. For the most part, they had much less impact than the NUL-byte spoofing attack, which Cox notes as having been fixed in April for Firefox 3.5 in RHEL.

Another presentation on SSL came from Alexander Sotirov and Mike Zusman. They showed that EV certificates can be replaced with valid, conventional (aka Domain Validated or DV) certificates without changing the browsers display to reflect the potentially reduced security. Browsers display sites using EV certificates in green in the address bar to denote the supposed higher security. By using a man-in-the-middle attack, and a valid DV certificate for the domain, they were able to send the second certificate, which caused the browser to switch encryption keys to that contained in the DV certificate. So the session was secured with the "lesser" DV certificate, which the attacker controlled, but still showed the green address bar.

Zusman also gave a presentation at DefCon (which follows Black Hat) on the reliability of the web applications that CAs use for handling certificate requests. As might be guessed, they turn out to be vulnerable to the usual web application suspects: cross-site scripting and SQL injection, but he found additional problems as well. He was able to circumvent the domain name validation used by some CAs so that he could get certificates for domains that he did not control.

It is rather worrisome that the CAs, who are supposedly guarding the safety of web traffic, are so lax about the security of their own applications. As Zusman noted in the article: "If you can game a CA's validation mechanism, they don't get hurt — they might even make some money. [Those] who suffer are those who use the Internet."

SSL is an important part of the web infrastructure that users must rely on daily to protect their communications with sensitive sites. It is not surprising that it would be targeted by security researchers, nor is it all that surprising that problems were found. While attacks against these specific problems may be difficult to pull off in practice, they represent holes that clearly need to be filled. If security researchers are finding these kinds of problems, it's pretty likely that attackers are finding them as well—but the attackers are much less likely to tell us about it at Black Hat.

Comments (5 posted)

Brief items

SquirrelMail plugins compromised

Full Story (comments: 6)

New vulnerabilities

django: file request forgery

Comments (none posted)

drupal-date: cross site scripting

Comments (none posted)

firebird: denial of service

Comments (none posted)

firefox: integer overflow

Comments (none posted)

firefox: heap overflow in certificate regexp parsing

Comments (none posted)

firefox: compromise of SSL-protected communication

Comments (none posted)

firefox: address spoofing

Comments (none posted)

firefox: multiple vulnerabilities

Comments (none posted)

flash-plugin: multiple vulnerabilities

Comments (none posted)

kernel: denial of service

Comments (none posted)

nspr, nss:weak hash signatures

Comments (none posted)

pdfedit: multiple vulnerabilities

Comments (none posted)

php4-eaccelerator: arbitrary code execution

Comments (none posted)

sssd: privilege escalation

Comments (none posted)

wordpress: cross-site scripting

Comments (none posted)

xml-security-c: authentication bypass

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current stable kernel is 2.6.30.4, released (along with 2.6.27.29) on July 30. Both updates contain another long list of important fixes.

Comments (none posted)

Kernel development news

Quotes of the week

Comments (4 posted)

In brief

Regressions. Rafael Wysocki has posted the 2.6.31-rc5 known regressions list. A total of 76 regressions have been reported in this development cycle; 28 of those remain unresolved. For this stage in the process, that is about normal, or, perhaps, just a bit better than average. Less encouraging, perhaps, is the fact that the 2.6.30 regression list still shows 39 unresolved problems.

make V=1. Once upon a time, building a kernel filled the screen with vast amounts of output, including the full command line for each compilation command. Needless to say, it was hard to get much information out of that much noise; in more recent times, the kernel build system emits much more concise information about what it's doing. Sometimes, though, one needs to see what's really going on; in such cases, running "make V=1" will cause the build system to output everything it's doing.

Except that, as Dave Airlie discovered, it doesn't; some commands are still hidden from view even when V=1 is specified. Build system maintainer Sam Ravnborg explained: "The problem is that V=1 is already too chatty, so people sometimes hide their stuff - as in this case." His suggestion is to implement multiple levels of verbosity, so that "V=2" could be used to view the truly full stream of commands. There's a minor problem in that "V=2" is already used to get make to print out which file caused a particular rebuild to happen. But, as Sam puts it, few people ever use that option, so maybe it could be replaced with a "be more verbose" mode. Unless somebody objects soon, that's likely to be how it goes.

devtmpfs. Greg Kroah-Hartman, evidently not feeling sufficiently challenged by the TTY layer, has reposted the devtmpfs patch, suggesting that it's ready for merging into the mainline. Greg says:

It would be fair to say, though, that the development community is not yet sold on the desirability of merging this patch; expect some interesting discussion in the near future.

Xtables2. The future of Linux packet filtering might be nftables, but Jan Engelhardt isn't holding his breath. He has, instead, put together an immense patch set massively reworking the existing iptables mechanism. The internal data structures have been torn out and reimplemented as a more flexible linked list, setting the stage for easier single-rule changes in the future. Perhaps the biggest payoff, though, is in the unification of the IPv4, IPv6, and ARP versions of the packet-filtering engine; that, he says, enables the removal of about 50% of the code.

The initial responses suggested that potential reviewers were overwhelmed by the magnitude of the change. Jan has posted a more detailed explanation of what various groups of patches do, which has helped. Eventual merging of this code will probably require breaking the sequence up into multiple steps, though.

Montreal Linux power management mini-summit notes have been posted by Len Brown; they give a good (if terse) summary of recent developments in the area and what is being worked on now.

Comments (none posted)

AlacrityVM

While virtualization has been a boon for many users and data centers, it tends to suffer from performance problems, particularly I/O performance. Addressing that problem is the goal of a newly announced project, AlacrityVM, which has created a hypervisor based on KVM. By shortening the I/O path for guests, AlacrityVM seeks to provide I/O performance near that of "bare metal" hardware.

The project is in a "pre-alpha" stage, according to the web page, but it is already reporting some fairly impressive results from a proof-of-concept network driver. Both for throughput and latency, the AlacrityVM guest performance compared favorably to that of 2.6.28 and 2.6.29-rc8 hosts. It also clearly out-performed the virtio drivers in a KVM guest.

The major change that allows AlacrityVM to achieve those gains come from a new kernel-based virtual I/O scheme known as Virtual-Bus (or vbus). Currently, KVM guests use emulated devices—implemented in user space by QEMU—in order to handle I/O requests. That leads to multiple kernel-to-user-space transitions for each I/O operation. The idea behind vbus is to allow guests to directly access the host kernel driver, thus reducing the overhead for I/O.

Using vbus, a host administrator can define a virtual bus that contains virtual devices—closely patterned on the Linux device model—which allow access to the underlying kernel driver. The guest accesses the bus through vbus guest drivers and will only be able to use those devices that the administrator explicitly instantiates on that vbus. The vbus interface supports only two "verbs": call() for synchronous requests, and shm() for asynchronous communication using shared memory.

A document [PDF] by AlacrityVM developer Gregory Haskins describes how to configure and use vbus. Vbus provides a sysfs interface that an administrator can use to create container-like objects that will constrain guests so that they can only access those devices specifically configured for their use. That helps alleviate one of the potential problems with guests accessing kernel drivers more-or-less directly: security.

The vbus web page has a look at the security issues and how they are handled. The main concerns are ensuring that guests cannot use the vbus mechanism to escape their isolation from other guests and processes, as well as making sure that guests cannot cause a denial of service on the host. The bus can only be created and populated on the host side, and each lives in an isolated namespace, which reduces or eliminates the risk of a cross-bus exploit to violate the isolation. In addition, each task can only be associated with one vbus—enforced by putting a vbus reference in the task struct—so that a guest can only see the device ids specified for that bus.

Care was taken in the vbus implementation to punish guests for any misbehavior, rather than the host. The two areas mentioned are for guests that, maliciously or otherwise, mangle data structures in the shared memory or fail to service their ring buffer. A naïve implementation could allow these conditions to cause a denial of service by stalling host OS threads or by creating a condition that might normally be handled by a BUG_ON(). Vbus takes steps to ensure that the host to guest path is resistant to stalling, while also aborting guests that write garbage to the ring buffer data structures.

Haskins has posted a series of patches to add the vbus infrastructure, along with a driver for accelerated ethernet. So far, the patches seem to be fairly well-received, though there are not, yet, very many comments. The web page makes it clear that the project's goal is "to work towards upstream acceptance of the project on a timeline that suits the community". The flexibility shown in that goal should serve the project well in getting mainline acceptance down the road.

The project sums up its status and future plans on the web page as well: "we have a working design which includes the basic hypervisor, linux-guest support, and accelerated networking. We will be expanding this to include other areas of importance, such as accelerated disk-io, IPC, real-time extensions, and accelerated MS Windows guest support." As one might guess, the web page also has mailing lists for users and developers as well as kernel and user-space git trees available for interested folks.

AlacrityVM and vbus both look to be interesting projects, that are probably worth investigating as potential virtualization solutions sometime in the future. The performance gains that come with vbus make it likely to be useful to other projects as well.

Comments (24 posted)

The realtime preemption endgame

The point of the realtime preemption project is to enable a general-purpose Linux kernel to provide deterministic response times to high-priority processes. "Realtime" does not (necessarily) mean "fast"; it means knowing for sure that the system can respond to important events within a specific time period. It has often been said that this cannot be done, that the complexity of a full operating system would thwart any attempt to guarantee bounded response times. Of course, it was also said that free software developers could never create a full operating system in the first place. The realtime hackers believe that both claims are equally false, and they have been working to prove it.

One of the long-term realtime features was threaded interrupt handlers. A "hard" interrupt handler can monopolize the CPU for as long as it runs; that can create latencies for other users. Moving interrupt handlers into their own threads, instead, allows them to be scheduled like any other process on the system. Thus, threaded interrupt handlers cannot get in the way of higher-priority processes.

Much of the threaded interrupt handling code moved into the mainline for the 2.6.30 release, but in a somewhat different form. While the threading of interrupt handlers is nearly universal in a realtime kernel, it's an optional (and, thus far, little-used) feature in the mainline, so the APIs had to change somewhat. Realtime interrupt handling has been reworked on top of the mainline threaded interrupt mechanism, but it still has its own twists.

In particular, the kernel can still be configured to force all interrupt handlers into threads. If a given driver explicitly requests a threaded handler, behavior is similar to a non-realtime kernel; the driver's "hard" interrupt handler runs as usual in IRQ context. Drivers which do not request threaded handlers get one anyway, with a special hard handler which masks the interrupt line while the driver's handler runs. Interrupt handler threads are per-device now (rather than per-IRQ line). All told, the amount of code which is specific to the realtime tree is fairly small now; the bulk of it is in the mainline.

Software interrupt handling is somewhat different in the realtime tree. Mainline kernels will normally handle software interrupts at convenient moments - context switches or when returning to user space from a system call, usually. If the software interrupt load gets too heavy, though, handling will be deferred to the per-CPU "ksoftirqd" thread. In the realtime tree (subject to a configuration option), all software interrupt handling goes into ksoftirqd - but now there is a separate thread for each interrupt line. So each CPU will get a couple of ksoftirqd threads for network processing, one for the block subsystem, one for RCU, one for tasklets, and so on. Software interrupts are also preemptable, though that may not happen very often; they run at realtime priority.

The work which first kicked off the realtime preemption tree was the replacement of spinlocks with sleeping mutexes. The spinlock technique is difficult to square with deterministic latencies; any processor which is spinning on a lock will wait an arbitrary period of time, depending on what code in another CPU is doing. Code holding spinlocks also cannot be preempted; doing so would cause serious latencies (at best) or deadlocks. So the goal of ensuring bounded response times required the elimination of spinlocks to the greatest extent possible.

Replacing spinlocks throughout the kernel with realtime mutexes solves much of the problem. Threads waiting for a mutex will sleep, freeing the processor for some other task. Threads holding mutexes can be preempted if a higher-priority process comes along. So, if the priorities have been set properly, there should be little in the way of the highest-priority process being able to respond to events at any time. This is the core idea behind the entire realtime preemption concept.

As it happens, though, not all spinlocks can be replaced by mutexes. At the lowest levels of the system, there is still a need for true (or "raw") spinlocks; the locks which are used to implement mutexes are one obvious example. Over the years, a fair amount of effort has gone into the task of figuring out which spinlocks really needed to be "raw" locks. At the code level, the difference was papered over through the use of some rather ugly trickery in the spinlock primitives. Regardless of whether a raw spinlock or a sleeping lock was being used, the code would call spin_lock() to acquire it; the only difference was where the lock was declared.

This approach was probably useful during the early development phases where it was often necessary to change the type of specific locks. But ugly compiler trickery which serves to obfuscate the type of lock being used in any specific context seems unlikely to fly when it comes to merger into the mainline. So the realtime hackers have bitten the bullet and split the two types of locks entirely. The replacement of "spinlocks" with mutexes still happens as before, for the simple reason that changing every spinlock call would be a massive, disruptive change across the entire kernel code base. But the "raw" spinlock type, which is used in far fewer places, is more amenable to this kind of change.

The result is a new mutual exclusion primitive, called atomic_spinlock_t, which looks a lot like traditional spinlocks:

    #include <linux/spinlock.h>

    DEFINE_ATOMIC_SPINLOCK(name)
    atomic_spin_lock_init(atomic_spinlock_t *lock);

    void atomic_spin_lock(atomic_spinlock_t *lock);    
    void atomic_spin_lock_irqsave(atomic_spinlock_t *lock, long flags);
    void atomic_spin_lock_irq(atomic_spinlock_t *lock);
    void atomic_spin_lock_bh(atomic_spinlock_t *lock);
    int atomic_spin_trylock(atomic_spinlock_t *lock);    

    void atomic_spin_unlock(atomic_spinlock_t *lock);
    void atomic_spin_unlock_irqrestore(atomic_spinlock_t *lock, long flags);
    void atomic_spin_unlock_irq(atomic_spinlock_t *lock);
    void atomic_spin_unlock_bh(atomic_spinlock_t *lock);

These new "atomic spinlocks" are used in the scheduler, low-level interrupt handling code, clock-handling, PCI bus management, ACPI subsystem, and in many other places. The change is still large and disruptive - but much less so than changing ordinary "spinlock" users would have been.

[PULL QUOTE: One might argue that putting atomic spinlocks back into the kernel will reintroduce the same latency problems that the realtime developers are working to get rid of. END QUOTE] One might argue that putting atomic spinlocks back into the kernel will reintroduce the same latency problems that the realtime developers are working to get rid of. There is certainly a risk of that happening, but it can be minimized with due care. Auditing every kernel path which uses spinlocks is clearly not a feasible task, but it is possible to look very closely at the (much smaller) number of code paths using atomic spinlocks. So there can be a reasonable degree of assurance that the remaining atomic spinlocks will not cause the kernel to exceed the latency goals.

(As an aside, Thomas Gleixner is looking for a better name for the atomic_spinlock_t type. Suggest the winning idea, and free beer at the next conference may be your reward.)

Similar changes have been made to a number of other kernel mutual exclusion mechanisms. There is a new atomic_seqlock_t variant on seqlocks for cases where the seqlock writer cannot be preemptable. The anon_semaphore type mostly appears to be a renaming of semaphores and their related functions; it is a part of the continuing effort to eliminate the use of semaphores in any place where a mutex or completion should be used instead. There is also a rw_anon_semaphore type as a replacement for rw_semaphore.

Quite a few other realtime-specific changes remain in the -rt tree. The realtime code is incompatible with the SLUB allocator, so only slab is allowed. There is also an interesting problem with kmap_atomic(); this function creates a temporary, per-CPU kernel-space address mapping for a given memory page. Preemption cannot be allowed to happen when an atomic kmap is active; it would be possible for other code to change the mapping before the preempted code tries to use it. In the realtime setting, the performance benefits from atomic kmaps are outweighed by the additional latency they can cause. So, for all practical purposes, kmap_atomic() does not exist in a realtime kernel; calls to kmap_atomic() are mapped to ordinary kmap() calls. And so on.

As for work which is not yet even in the realtime tree, the first priority would appear to be clear:

At this point, the remaining BKL-removal work comes down to low-level audits of individual filesystems and drivers; for the most part, it has been pushed out of the core kernel.

Beyond that, of course, there is the little task of getting as much of this code as possible into the mainline kernel. To that end, a proper git tree with a bisectable sequence of patches is being prepared, though that work is not yet complete. There will also be a gathering of realtime Linux developers at the Eleventh Real-Time Linux Workshop this September in Dresden; getting the realtime work into the mainline is expected to be discussed seriously there. As it happens, your editor plans to be in the room; watch this space in late September for an update.

Comments (31 posted)

Flexible arrays

Kernel programmers will sometimes respond to this problem by allocating pages with vmalloc(). Memory allocated this way is virtually contiguous, but physically scattered. So, as long as physically-contiguous pages are not needed, vmalloc() looks like a good solution to the problem. It's not ideal, though. On 32-bit systems, memory from vmalloc() must be mapped into a relatively small address space; it's easy to run out. On SMP systems, the page table changes required by vmalloc() allocations can require expensive cross-processor interrupts on all CPUs. And, on all systems, use of space in the vmalloc() range increases pressure on the translation lookaside buffer (TLB), reducing the performance of the system.

So it would be nice to have a mechanism which could handle the allocation of large arrays in a manner which (1) is reliable, and (2) does not use vmalloc(). To date, any such mechanisms have generally been pieced together by developers solving a specific problem; there has been nothing designed for more general use. That has changed, though, with the merging of the "flexible array" mechanism, written by Dave Hansen, for 2.6.31-rc5.

A flexible array holds an arbitrary (within limits) number of fixed-sized objects, accessed via an integer index. Sparse arrays are handled reasonably well. Only single-page allocations are made, so memory allocation failures should be relatively rare. The down sides are that the arrays cannot be indexed directly, individual object size cannot exceed the system page size, and putting data into a flexible array requires a copy operation. It's also worth noting that flexible arrays do no internal locking at all; if concurrent access to an array is possible, then the caller must arrange for appropriate mutual exclusion.

The creation of a flexible array is done with:

    #include <linux/flex_array.h>

    struct flex_array *flex_array_alloc(int element_size, int total, gfp_t flags);

The individual object size is provided by element_size, while total is the maximum number of objects which can be stored in the array. The flags argument is passed directly to the internal memory allocation calls. With the current code, using flags to ask for high memory is likely to lead to notably unpleasant side effects.

Storing data into a flexible array is accomplished with a call to:

    int flex_array_put(struct flex_array *array, int element_nr, void *src, gfp_t flags);

This call will copy the data from src into the array, in the position indicated by element_nr (which must be less than the maximum specified when the array was created). If any memory allocations must be performed, flags will be used. The return value is zero on success, a negative error code otherwise.

There might possibly be a need to store data into a flexible array while running in some sort of atomic context; in this situation, sleeping in the memory allocator would be a bad thing. That can be avoided by using GFP_ATOMIC for the flags value, but, often, there is a better way. The trick is to ensure that any needed memory allocations are done before entering atomic context, using:

    int flex_array_prealloc(struct flex_array *array, int start, int end, gfp_t flags);

This function will ensure that memory for the elements indexed in the range defined by start and end has been allocated. Thereafter, a flex_array_put() call on an element in that range is guaranteed not to block.

Getting data back out of the array is done with:

    void *flex_array_get(struct flex_array *fa, int element_nr);

The return value is a pointer to the data element, or NULL if that particular element has never been allocated.

Note that it is possible to get back a valid pointer for an element which has never been stored in the array. Memory for array elements is allocated one page at a time; a single allocation could provide memory for several adjacent elements. The flexible array code does not know if a specific element has been written to; it only knows if the associated memory is present. So a flex_array_get() call on an element which was never stored in the array has the potential to return a pointer to random data. If the caller does not have a separate way to know which elements were actually stored, it might be wise, at least, to add GFP_ZERO to the flags argument to ensure that all elements are zeroed.

There is no way to remove a single element from the array. It is possible, though, to remove all elements with a call to:

    void flex_array_free_parts(struct flex_array *array);

This call frees all elements, but leaves the array itself in place. Freeing the entire array is done with:

    void flex_array_free(struct flex_array *array);

As of this writing, there are no users of flexible arrays in the mainline kernel. The functions described here are also not exported to modules; that will probably be fixed when somebody comes up with a need for it.

Comments (4 posted)

Patches and updates

Kernel trees

• Linus Torvalds: Linux 2.6.31-rc5 . (August 1, 2009)

• Thomas Gleixner: 2.6.31-rc4-rt1 . (July 30, 2009)

• John Kacur: linux-2.6.31-rc5-rt1.1 . (August 5, 2009)

• Greg KH: Linux 2.6.30.4 . (July 30, 2009)

• Greg KH: Linux 2.6.27.29 . (July 30, 2009)

Core kernel code

• Peter Zijlstra: fcntl: F_[SG]ETOWN_TID . (July 31, 2009)

• Balbir Singh: Help Resource Counters scale better . (August 3, 2009)

• Stefani Seibold: new kfifo API . (August 3, 2009)

• Peter Zijlstra: fcntl: F_[SG]ETOWN_TID . (August 3, 2009)

Development tools

• Frederic Weisbecker: bkl ftrace events + filter regex support . (August 1, 2009)

• Subrata Modak: The Linux Test Project has been Released for JULY 2009 . (August 3, 2009)

• Lai Jiangshan: [ANNOUNCE][RFC][PATCH] Crash-utility, tracing: enable crash to analyze tracing from core-file (make tracing can act as a flight recorder) . (August 3, 2009)

• Josh Stone: SystemTap release 0.9.9 . (August 5, 2009)

• Amerigo Wang: Implement crashkernel=auto . (August 5, 2009)

Device drivers

• Ohad Ben-Cohen: sdio: add CD disable support . (July 31, 2009)

• Roger Quadros: regulator: Add GPIO enable control to fixed voltage regulator driver . (July 31, 2009)

• Robert Love: Open-FCoE Features for 2.6.32 . (August 3, 2009)

• Linus Torvalds: [PATCH 0/2] proper tty-ldisc refcounting (was Re: WARNING at: drivers/char/tty_ldisc.c) . (August 4, 2009)

• Greg K-H: [ANNOUNCE] VME Bus drivers and framework for Linux . (August 4, 2009)

• Luis R. Rodriguez: ath9k: add initial ar9271 support . (August 4, 2009)

• Tejun Heo: chrdev: implement __[un]register_chrdev() . (August 5, 2009)

• Jean Delvare: Convert i2c adapters from class devices to bus devices . (August 5, 2009)

Filesystems and block I/O

• Ryo Tsuruta: dm-ioband-v1.12.2: I/O bandwidth controller . (July 30, 2009)

• Jens Axboe: Per-bdi writeback flusher threads v13 . (July 31, 2009)

• Frederic Weisbecker: Reiserfs/kill-bkl tree v2 . (July 31, 2009)

• Christoph Hellwig: XFS status update for July 2009 . (August 4, 2009)

• Greg KH: Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev . (August 5, 2009)

• David Woodhouse: RAID[56] with arbitrary numbers of "parity" stripes. . (August 5, 2009)

Memory management

• Hugh Dickins: ksm: stats, oom, doc, misc . (August 3, 2009)

• Roland Dreier: ummunotify: Userspace support for MMU notifications . (August 3, 2009)

• Jim Paradis: Dirty Page Tracking & on-the-fly memory mirroring . (August 3, 2009)

• Lee Schermerhorn: hugetlb: V3 constrain allocation/free based on task mempolicy . (August 3, 2009)

• Lee Schermerhorn: hugetlb: V1 Per Node Hugepages attributes . (August 3, 2009)

• KAMEZAWA Hiroyuki: ZERO_PAGE again v5. . (August 5, 2009)

Networking

• Jan Engelhardt: Xtables2 snapshot 20090804 . (August 4, 2009)

Architecture-specific

• Andi Kleen: [0/15] HWPOISON: Intro . (August 5, 2009)

• Gautham R Shenoy: cpu: idle state framework for offline CPUs. . (August 5, 2009)

Security-related

• David Howells: KEYS: Deal with dead-type keys appropriately . (August 5, 2009)

• Paul Moore: The Long Lost TUN LSM Hooks . (August 5, 2009)

Virtualization and containers

• Ben Blum: CGroups: cgroup memberlist enhancement+fix . (July 31, 2009)

• Gregory Haskins: AlacrityVM hypervisor project . (August 3, 2009)

• Gregory Haskins: AlacrityVM guest drivers . (August 3, 2009)

Benchmarks and bugs

• Rafael J. Wysocki: 2.6.31-rc5: Reported regressions from 2.6.30 . (August 3, 2009)

• Rafael J. Wysocki: 2.6.31-rc5: Reported regressions 2.6.29 -> 2.6.30 . (August 3, 2009)

Miscellaneous

• Mark Lord: hdparm-9.17 released, with experimental trim/wiper scripts for SSDs . (August 3, 2009)

Page editor: Jonathan Corbet

Distributions

News and Editorials

A tale of two shells: bash or dash

A reoccurring topic on Debian lists is the use of dash (Debian Almquist Shell) as opposed to bash (GNU Bourne-Again Shell). Currently /bin/sh defaults to bash on a Debian system, but some would like the default to be dash.

Ubuntu made this switch three years ago, with the release of Ubuntu 6.10. Note that the default login shell remains bash, only the default /bin/sh used in shell scripts has been changed. Why did Ubuntu make this change?

The Debian EeePC project also notes that dash provides faster boot times. So why hasn't Debian already made this switch? In fact this was a release goal for Lenny.

Part of the problem is "bashisms" - use of non-standard bash features - in shell scripts. There is a lengthy list of bugs tagged with goal-dash that contain bashisms. These are being worked on, package by package. While some users report that they have already made the switch without problems, others will find many of their user scripts will have bashisms.

checkbashisms' output:
> possible bashism in ./usr/bin/apertium-preprocess-corpus-lextor line 47
> ('((' should be '$(('): if ((length(w)>0) && (index(w,"^")>0)) {
> possible bashism in ./usr/bin/apertium line 9 ('function' is useless):
> function message

Examples of bashisms include use of $RANDOM, the select, let, and source keywords, shell arithmetic, the -e option to echo, and many other things.

Debian policy looks at SUSv3 Shell Command Language and states:

This raises the issue of whether dash should be "essential" [see Debian policy section 3.8]. bash is "essential" meaning that it must be installed on every Debian system. If dash does not become "essential" then every script with /bin/sh as its interpreter must depend on dash to insure that it is installed and usable by /bin/sh (once the change is made).

That this change will be made is mostly not under debate, it is more a matter of when it will be fully implemented. Those that oppose the move simply want a choice, which exists using dpkg-reconfigure dash. Meanwhile users should be looking at their own scripts to see if they will break once /bin/sh defaults to dash.

Comments (19 posted)

New Releases

Announcing NetBSD 5.0.1

Full Story (comments: none)

Mandriva Linux 2010 alpha 2 is available

Full Story (comments: none)

KDE Four Live 1.3.0

Full Story (comments: none)

Distribution News

Debian GNU/Linux

Some backpedaling on Debian freeze dates

Full Story (comments: 9)

Shuttleworth: On cadence and collaboration

Full Story (comments: 30)

news.debian.net launches

Comments (5 posted)

Fedora

Fedora Board Recap

Full Story (comments: none)

Recent Fedora IRC Classes

Full Story (comments: none)

Ubuntu family

Ubuntu Patent Policy

Full Story (comments: 1)

Other distributions

Bootable Yellow Dog Linux USB drive for PLAYSTATION3

Full Story (comments: 1)

Distribution Newsletters

Arch Linux Newsletter

Comments (none posted)

DistroWatch Weekly, Issue 314

Comments (none posted)

Fedora Weekly News 187

Full Story (comments: none)

The Mint Newsletter - issue 90

Comments (none posted)

OpenSUSE Weekly News/82

Comments (none posted)

Ubuntu Weekly Newsletter #153

Full Story (comments: none)

Interviews

Interview Gentoo Developer Robin H. Johnson

Comments (none posted)

Page editor: Rebecca Sobol

Development

Mutter: a window manager for GNOME 3

GNOME 3 is the GNOME project's ambitious effort to take its desktop into the future. A key component of the desktop is the window manager, which defines much of the overall feel of the system. Thomas Thurman, the maintainer of Metacity—GNOME's current window manager—is looking ahead to "Mutter" as the window manager for GNOME 3. Metacity 2 will gradually be phased out in favor of Mutter; in GNOME 2.28 it will be an alternative window manager, while in GNOME 3, it will take over the reins from Metacity.

The GNOME Shell, responsible for the new user experience in GNOME 3, runs as a plugin for Mutter. Started as a fork of Metacity, Mutter uses the Clutter toolkit. Clutter does its rendering using OpenGL or OpenGL ES, so using it in Mutter makes hardware acceleration for the window manager possible. Meanwhile, Clutter has just announced its 1.0 release.

500 bugs to squash

With Mutter becoming the new kid in town for GNOME 3, Metacity 2 will not be actively developed any more, except for bug fixes. This makes Mutter essentially Metacity 3. Of course people who would like Metacity 2 to continue because they don't like the Clutter backend may fork it, but it remains to be seen if that would happen. On his blog, Thurman welcomes anybody to do that and offers them "as much support in doing so as possible", but he will switch to working on Mutter himself. Besides all the work that has been done over the years on Metacity, Mutter has 12 contributors with at least three commits. The project is maintained by Owen Taylor and Tomas Frydrych.

This fork, however, has one big problem: what to do with the more than five hundred bugs open against Metacity? As Thurman describes on his blog, "this is more than one maintainer can humanly tackle." The simplest "solution" is to close them all, a mistake that GNOME has made in the past with the switch from GNOME 1.4 to GNOME 2. Jamie Zawinski called this the cascade of attention-deficit teenagers model.

Thurman proposes a better solution: work through all the bug reports, then decide what to do with each bug. Enhancement requests will not be fixed, unless Mutter or GNOME Shell could use it. Bugs that can be reproduced in Mutter should be reassigned. Bugs that are already fixed in Mutter, such as enhancement requests, should be marked as already fixed. Thurman kindly asks his readers to help him with this painstaking work, for which no volunteers seem to have stepped up yet.

New directions for a window manager

The development of GNOME 3 seems to be bringing new ideas from many different directions. Thurman has been doing some investigation into switching to a CSS-based format for Metacity themes; as Mutter is just the new incarnation of Metacity, many of these considerations directly carry over into Mutter:

Thurman is proposing a switch to CSS, or at least the use of CSS as an alternative format. He sees several advantages of this approach:

• The Metacity/Mutter developers will be able to use existing libraries for layout rather than doing it all with custom code in the window manager.
• Theme designers will be able to use their existing knowledge of CSS rather than having to learn a complicated new format.
• CSS's box model is far more amenable to a simple drag-and-drop editor program than Metacity's current expression-based system.

Thurman is also imagining a theme designer, with a simple mode that is a wizard: it would ask the user a series of questions and would then produce some CSS code. An advanced mode would let the user edit each CSS rule individually, and reflect the changes on the screen. He is also working on a wiki, which he'll announce soon, that allows users to enter CSS and render it to an image of the window borders:

Owen Taylor explains another new direction: Mutter will get application-aware window management. More specifically it will get knowledge about tabs:

Another developer, Sam Hoffstaetter, is working on letting the user group together arbitrary windows as tabs, something that so-called tabbed window managers offer. Each application would think it had multiple windows open, but the user would see them as tabs. The reasoning, which your author is very sympathetic to, is as follows:

Some issues with Mutter

Interesting as the new directions may be, some people fear that Mutter will not run on older hardware. For example, the Sugar developers didn't choose Mutter, and went for Metacity instead, exactly because of this fear. However, Taylor puts that in perspective:

Another fear that has been expressed is that Mutter will be too tightly coupled with GNOME 3. As GNOME Shell is a Mutter plugin, it depends on it, so users will not be able to use another window manager with GNOME Shell. According to Taylor, this integration is not coincidental but by design. For example, supporting Compiz instead of Mutter would require a window management abstraction layer that "greatly increases the amount of work".

However, this approach is problematic for some use cases, as Sam Spilsbury, one of the Compiz developers, pointed out a few months ago:

Of course it will perfectly be possible to create a GNOME desktop using another window manager, but then the user would miss out on the new desktop experience of GNOME Shell. For example, users will not be able to swap GNOME's window manager with a flexible window manager such as xmonad and still leave all GNOME functionality intact.

Accessibility growing pains

The fact that GNOME Shell and Mutter use Clutter directly makes support for accessibility features such as AT-SPI (Assistive Technologies Service Provider) tricky, because Clutter has no accessibility support at the moment. GTK applications, on the other hand, have ATK (Accessibility Toolkit) which talks with the AT-SPI daemon. However, there's no inherent reason that a switch to a Clutter-based composited user interface should pose any problem for accessibility. The switch in toolkits will need a certain amount of reimplementation. That said, Taylor maintains that some accessibility features such as good magnification could become much easier in Mutter.

An active project to provide accessibility interfaces for Clutter is Cally (the name stems from Clutter + a11y), originally funded by Nokia that uses Clutter in Maemo 5. The main developer, Alejandro Piñeiro Iglesias, explains the work he has done:

Cally would be useful to implement accessibility support in Mutter and GNOME Shell, but Iglesias says he should check the code first and see what he needs to implement and how. He presented Cally [PDF.GZ] at the recent Gran Canaria Desktop Summit.

A fresh start

According to Taylor, Mutter is not that exciting in isolation, but it is meant to provide a platform for building exciting user interfaces like Moblin and GNOME Shell: "I'm personally pretty interested in getting applications and the compositor properly synchronized so the user sees everything drawn as smoothly and cleanly as possible." Thurman is excited about the opportunity to get a fresh start and rethink how to interact with the user:

The new directions of CSS-based themes and application-aware window management finally make GNOME's window manager more than a dull but necessary component. However, the developers have made some decisions under the hood that will not be popular in some circles. There is no fallback option for those that cannot or do not want to use compositing, and the integration of GNOME Shell with Mutter shuts out alternative window managers. But maybe this is the price that must be paid for innovation.

Comments (47 posted)

System Applications

Database Software

Firebird 2.1.3 RC2 released

Comments (none posted)

MySQL Server 5.1.37 has been released

Full Story (comments: none)

PostgreSQL Weekly News

Full Story (comments: none)

Embedded Systems

BusyBox 1.14.3 released

Comments (none posted)

Filesystem Utilities

Tahoe 1.5 released

Full Story (comments: none)

Interoperability

Samba 3.3.7 is available

Comments (none posted)

Miscellaneous

upstart 0.6.3 released

Full Story (comments: none)

Desktop Applications

Desktop Environments

GNOME 2.27.5 released

Full Story (comments: none)

RunPON 0.3 released

Full Story (comments: none)

GNOME Software Announcements

• clutter-gst 0.10.0 (stable release, documentation work)
• Clutter-GTK 0.10.2 (new features, bug fixes and documentation work)
• GENIUS 1.0.7 (new features, bug fixes and translation work)
• gnome-packagekit 2.27.5 (bug fixes)
• GNOME Power Manager 2.26.4 (new features and bug fixes)
• GNOME Power Manager 2.27.5 (new features, bug fixes and translation work)
• gtk-css-engine 0.3 (new features)
• libchamplain 0.3.4 (new features and bug fixes)
• libchamplain 0.3.6 (new feature and bug fixes)
• Libgee 0.3.0 (new features)
• Nautilus-Actions 1.11.2 (new features, bug fixes and translation work)
• Nemiver 0.7.1 (bug fixes and translation work)
• Vala 0.7.5 (new features and bug fixes)

Comments (none posted)

KDE 4.3.0 Released: Caizen

Full Story (comments: 20)

KDE Software Announcements

• 2ManDVD 0.9 (bug fixes and translation work)
• Cirkuit 0.2 (new features)
• Cirkuit 0.2.1 (new feature and bug fix)
• eric4 4.3.6 (bug fixes)
• eXaro 1.90.0 (new features and bug fixes)
• FlashQard 0.13.1 (new features, bug fixes, documentation and translation work)
• KAlarm 2.3.0 (new features and bug fixes)
• KDE Partition Manager 1.0.0-RC1 (bug fixes)
• KdeSudo 3.4.2 (bug fixes)
• kdesvn 1.4.0 (unspecified)
• Konversation 1.2-alpha5 (new features, bug fixes and performance improvements)
• OkularSlideShow 0.1 (initial release)
• QMediaBibliothek 0.2.0 (unspecified)
• QTeXEngine 0.1 (initial release)
• rkward 0.5.1 (new features and bug fixes)
• rekonq Web Browser 0.1.95 (bug fixes and translation work)
• Simple Root Actions Menu 2.1.1 (new feature and translation work)
• SparkleMedia 0.1 (initial release)

Comments (none posted)

Xorg Software Announcements

• libX11 1.2.99.901 (new features and bug fixes)
• rstart 1.0.3 (bug fix and code cleanup)
• xf86-input-evdev 2.2.3 (new features, bug fixes and documentation work)
• xf86-input-synaptics 1.1.3 (bug fix)
• xf86-video-apm 1.2.2 (bug fixes and code cleanup)
• xf86-video-ast 0.89.9 (new features and code cleanup)
• xf86-video-cirrus 1.3.2 (code cleanup)
• xf86-video-fbdev 0.4.1 (new features, code cleanup and documentation work)
• xf86-video-glint 1.2.4 (code cleanup)
• xf86-video-i128 1.3.3 (code cleanup)
• xf86-video-i740 1.3.2 (bug fixes and code cleanup)
• xf86-video-mach64 6.8.2 (new features, code cleanup and documentation work)
• xf86-video-mga 1.4.11 (code cleanup and documentation work)
• xf86-video-neomagic 1.2.4
• xf86-video-r128 6.8.1 (code cleanup)
• xf86-video-s3 0.6.3 (bug fixes and code cleanup)
• xf86-video-s3virge 1.10.4 (code cleanup)
• xf86-video-savage 2.3.1 (new features and code cleanup)
• xf86-video-siliconmotion 1.7.3 (bug fixes and code cleanup)
• xf86-video-sisusb 0.9.3 (new features and code cleanup)
• xf86-video-sis 0.10.2 (new features, bug fixes and code cleanup)
• xf86-video-tdfx 1.4.3 (code cleanup)
• xf86-video-trident 1.3.3 (code cleanup)
• xf86-video-vesa 2.2.1 (bug fixes and code cleanup)
• xf86-video-voodoo 1.2.3 (new features and code cleanup)
• xinput 1.4.99.2 (bug fixes and documentation work)
• xmag 1.0.3 (bug fixes)
• xorg-server 1.6.3 (new features and bug fixes)
• xrx 1.0.3 (bug fixes and code cleanup)
• xtrans 1.2.4 (bug fixes)

Comments (none posted)

Games

pygame 1.9.0 released

Full Story (comments: none)

GUI Packages

PyQwt 5.2.0 released

Full Story (comments: none)

Multimedia

Miro 2.5 released

Comments (none posted)

Music Applications

Guitar-ZyX-0.3 LiveOS announced

Full Story (comments: none)

Office Applications

Leo 4.6.2 released

Full Story (comments: none)

Pyspread 0.0.12 released

Full Story (comments: none)

Web Browsers

Firefox 3.5.2 and 3.0.13 fix SSL security problems

Full Story (comments: 8)

Miscellaneous

FLiP 1.0 released

Full Story (comments: none)

Languages and Tools

C

GCC 4.3.5 Status Report

Full Story (comments: none)

GCC 4.5 Status Report

Full Story (comments: none)

Editors

Emacs 23.1 released

Full Story (comments: 11)

Test Suites

pylib/py.test 1.0.0 released

Full Story (comments: none)

Page editor: Forrest Cook

Linux in the news

Recommended Reading

Don Becker On The State Of HPC

Comments (1 posted)

1 Million Linux Kernels Booted for Vast Botnet Simulation (Linux Insider)

Comments (5 posted)

Companies

Canonical Expands Ubuntu Linux Landscape (InternetNews.com)

Comments (19 posted)

Mentor unveils Android, Linux strategy at DAC (EDN)

Comments (7 posted)

Motorola Pledges Cheaper Android Phones (PCMag)

Comments (none posted)

Legal

Company Receives Patent for Podcasting (ReadWriteWeb)

Comments (17 posted)

A Jesuit's Guide to Open Standards (Computerworld UK)

Comments (2 posted)

Interviews

Is free the new pay? (BBC News)

Comments (2 posted)

Resources

Will Geolocation Find a Home on Linux Desktops? (Datamation)

Comments (none posted)

Reviews

A first look at KDE 4.3 (ComputerWorld)

Comments (none posted)

Hands-on: Linux appliances made easy with SUSE Studio (ars Technica)

Comments (4 posted)

Waddling Past The Windows (Linux Journal)

Comments (4 posted)

Miscellaneous

GNOME Decides to Ditch Drawings (Linux Journal)

Comments (15 posted)

The White House Sends an Invitation: PCAST Meeting Aug. 6 and 7 (Groklaw)

Comments (none posted)

Page editor: Forrest Cook

Announcements

Non-Commercial announcements

Coalition launches petition over Amazon/Kindle DRM

Full Story (comments: none)

The FSF launches a "freedom to read" petition

Comments (19 posted)

OpenBTS injunction lifted

Full Story (comments: 3)

Commercial announcements

Canonical to Offer Ubuntu Desktop support and services

Full Story (comments: 2)

Linux Foundation introduces Linux-branded credit card

Comments (1 posted)

MIPS makes Android source code public

Full Story (comments: none)

MUSA Technology Partners introduces Linux/Open Source service desk

Comments (none posted)

New Books

Head First Data Analysis--New from O'Reilly

Full Story (comments: none)

O'Reilly publishes book excerpts

Comments (none posted)

Resources

Linux Gazette #165 is out

Full Story (comments: none)

Linux on the Intel iMac - Triple booting

Comments (none posted)

ODBMS.org publishes panel discussion

Full Story (comments: none)

Contests and Awards

PHP TestFest 2009 winners announced

Comments (none posted)

Red Hat awards Fedora Scholarship

Comments (none posted)

Surveys

Ongoing Oxygen Icons Usability Survey: KDevelop (KDEDot)

Comments (none posted)

Meeting Minutes

Minutes for GNOME+KDE meeting at GUADEC

Comments (none posted)

Calls for Presentations

5th European Conference on Computer Network Defence CFP

Full Story (comments: none)

Upcoming Events

Feds to host NHIN software code-a-thon (Health IT)

Comments (none posted)

OpenSource World: we got r0ml

Full Story (comments: none)

openSUSE Conference Keynote announcement

Full Story (comments: none)

Events: August 13, 2009 to October 12, 2009

If your event does not appear here, please tell us about it.

Web sites

New KDE Buzz (KDEDot)

Comments (none posted)

Audio and Video programs

Embedded Linux Conference videos posted

Comments (5 posted)

Page editor: Forrest Cook