Leading items

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 must seem like a dream distribution to many. Its users get the benefit of the massive team of developers that Red Hat has working on the Red Hat Enterprise Linux product without having to pay for any of it. CentOS offers a level of stability that cannot be found in any of the more community-oriented distributions; even Debian Stable requires its users to upgrade more often than CentOS does. Hosting providers have a solid, supported platform to sell to many thousands of customers, and it does not cost them even a single devalued US dollar. Many, many sites depend on CentOS, so anything which threatens the stability of that foundation is certain to raise a number of eyebrows. Unfortunately, that is exactly what happened at the end of July.

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)