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
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
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
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
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
This is actually not asking to make KDE special in any way or to grant KDE
any additional [privilege]. It is the common practice in openSUSE to select
the technically best solution, and in case that is not feasible for whatever
reason, the most popular solution. Therefore GNOME has the special [privilege]
of being presented completely equally (or actually with a slight advantage by
being first) with what in all other cases would be the presented default
selection in a choice or would be used without a choice at all. The feature
asks for applying the common practice to the desktop selection, in other
words, the feature actually asks for removal of the [privilege] that GNOME
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
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:
If the issue was merely sending a pro-KDE message, I'd be quite in
favor. But it's not neutral to GNOME (in my opinion) because we're
effectively choosing one over the other — even if that's not the spirit in
which it's intended (and I like to think that Frank is trying to send a
pro-KDE message, not an anti-GNOME message), I'm concerned that it will be
I appreciate the desire to make openSUSE a welcome home for KDE developers
and users. I just think we could find a better way to accomplish it.
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:
Currently we have Firefox as the clear default and we do not even offer a
choice in any prominent place. I don't think there's anything wrong with
that, but if one day Chrome has 90% users and Firefox 9%, it would be clearly
very stupid to still keep Firefox as the default without any easy way to
change it. [...] According to what we have now with desktops, we should
offer a choice to use Chrome as soon as it gets at least somewhat significant
user base, and after it [is] exceeding about 25%, we should present a page during
installation where there is nothing preselected and the user must choose.
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
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
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)
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
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
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
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
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
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)
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:
It was not an easy decision and I feel sad for having to take it,
but I decided to resign from the CentOS project. I hope the team
can fix the project's leadership, communication and transparency
issues (even within the team), because each is very important for
the health of the CentOS community.
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
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:
For at least three years people were donating money and sponsors
were paying for website ads while the money was not flowing into
the project, where it went to I can only guess. Raising the
question was a risk to the project so everybody stayed quiet for
the sake of the project hoping it would resolve itself.
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:
We will be addressing these issues in the next few weeks, the plan
at this time is to not turn on the donations option or advertising
anywhere on the websites till we have such processes in place.
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:
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
Inside this week's LWN.net Weekly Edition
- Security: SSL flaws revealed at Black Hat; New vulnerabilities in django, firefox, flash-plugin, pdfedit,...
- Kernel: AlacrityVM; The realtime preemption endgame; Flexible arrays.
- Distributions: A tale of two shells: bash or dash; NetBSD 5.0.1; Mandriva Linux 2010 alpha 2; KDE Four Live 1.3.0; Some backpedaling on Debian freeze dates; Shuttleworth: On cadence and collaboration; news.debian.net launches; Ubuntu Patent Policy.
- Development: Mutter: a window manager for GNOME 3, new versions of MySQL, BusyBox, Tahoe, Samba, GNOME, KDE, pygame, Miro, Guitar-ZyX, Firefox, FLiP, Emacs, pylib/py.test.
- Press: Don Becker on HPC, Sandia's Botnet, Canonical's Landscape, Mentor and Motorola use Android, Podcasting patent, patented technology and open standards, Szulik interview, geolocation on the desktop, reviews of KDE 4.3, SUSE Studio Ubuntu/USB.
- Announcements: Amazon/Kindle DRM petition, OpenBTS injunction lifted, Canonical offers support services, Android/MIPS code released, ODBMS.org panel discussion, PHP TestFest winners, Fedora scholarship, GNOME+KDE meeting meeting minutes, EC2ND cfp, NHIN code-a-thon, buzz.kde.org.