The biggest user-visible piece of GNOME 3 will be the GNOME Shell, which manages the
desktop experience. At GUADEC, Owen Taylor updated the assembled GNOME
hackers on the current status of GNOME Shell and the work still to be done.
demonstrated some of the new functionality and compared the Shell with
where it was when he presented at the Gran Canaria Desktop Summit (GCDS) in
Since GCDS, "we wrote code", Taylor said, consisting of some
1362 commits, 1174 of which were code along with 188 translation commits.
The project has also added new contributors and four of the top ten
contributors since GCDS were new to the project. He was happy to see that
those new contributors were not only prolific, but also added "very
significant" new features.
In preparing for his talk, Taylor went back to the version from GCDS
and was "surprised that it still built". The user interface
has been redesigned since then and, in some cases, things have been
rewritten three or four times in the interim. He found it interesting that
certain features that he thought were there from the start were missing,
while others that he thought were newer actually appeared in the year-old
The Shell now sports a "sleeker, black look" that fades into
the background because it blends into the monitor bezel, he said. The
"mess in the upper right hand corner" has been cleaned up, and
the task list from last year is gone. In addition, the menus are not
GTK-based, but are instead styled with the Shell, giving them a more
Switching between applications and workspaces has also undergone some major
changes. Alt-Tab now groups all of the windows for an application into a
single entry, so that you choose between applications, rather than
individual windows. Last year, activities were represented by a grid of
workspaces with a dashboard to launch new applications. Now it is
"slicker", with a linear view of the workspaces that can be
scrolled horizontally to view additional workspaces.
The application browser has switched from a "straight
reimplementation from GNOME 2" to a gridded view with fewer
categories. Searching has also been integrated into the dashboard. The
message tray now slides up from the bottom and you no longer have to
dismiss each notification as you did in GNOME 2. It is also integrated
with Empathy so that replying to a message no longer requires switching to
the application itself—the reply can be typed into the message
The "hot corner"—simply moving the mouse to the upper left corner of
the screen—is another new feature. Moving there brings up the
activities overview that shows workspaces, places, and recent documents.
It's very useful, Taylor said, so much so that "if you go back to
GNOME 2, you
will keep going to the hot corner".
which acts like "Firebug for the Shell". Taylor did a live
titles, scale them to different sizes, and even have them run the scaling
as a transition so that the text continuously grew in size.
GNOME Shell is based on the Clutter toolkit, but because "Clutter
itself only has four actors that are useful" for the Shell, it uses
the Shell toolkit (St) atop Clutter. St is descended from Moblin's MX
toolkit, but is more focused on the needs of the Shell. St emphasizes CSS
with transitions, property inheritance, shadows, rounded corners, and so
on, which make for a "pretty powerful set of capabilities".
MX has many more widgets and is more powerful overall. The separate evolution of
St and MX is "not a good thing long-term" and the team aims
to reunite them at some later point.
Taylor also talked about the development process for GNOME Shell, which is
very reliant on code review. The normal GNOME model is "code
ownership" he said, but the Shell does "code review of
everything". There is no formal structure to the review process,
but they get two pairs of eyes on all code changes. The process has its
"good parts and not-so-good parts", but overall it works well
because it spreads out the knowledge of the code among multiple people in
the project. It can lead to bottlenecks, where "patches sit around
for a while", but he definitely recommends that development model
for other projects.
GNOME Shell is in "good shape" for basic functionality, like
window switching and launching applications, Taylor said, though there are
still bugs and other things to fix. It makes for a "pretty coherent
whole" that can be used on a day-to-day basis. The status area in
the upper right hand corner is still a work in progress as is the
integration of the Shell with the rest of the system. He pointed to the
log out and lock screen dialogs as things that were not yet rendered in the
Shell style, and still look like the GNOME 2 versions.
Those changes will come relatively soon, but there are some other things
that are a bit further out. The "recently used documents" in the
activities overview is just a placeholder right now. There are no
customization options for those who want to change the styles or behavior
of the Shell. The plan is to add an extension API like Firefox has, but
other than some basic infrastructure, that isn't nearly ready. In
addition, there is no fall-back support if 3D graphics—required by
Clutter—are not available. Some way to fall back to the GNOME 2 look
in that case is desired.
Based on the status, it was probably fairly obvious to those in the room
that GNOME Shell might not be completely ready for the September
release—foreshadowing the next presentation, which was by Vincent
Untz and the release team
delaying GNOME 3.0. GNOME
Shell definitely looks like more than an incremental change to the desktop
experience, and Taylor's demo with Looking Glass showed the latent
potential for theming and other customization that underlies the Shell.
With an additional six months to work on it, focusing on completing a
coherent whole, GNOME Shell seems quite likely to impress.
Comments (15 posted)
It seems like longer, but it's only been six months since Intel and
that they'd be joining the Maemo and Moblin communities into MeeGo. A lot has happened in the interim, and
MeeGo community manager Dawn Foster was on hand at LinuxCon to provide an
update about the state of MeeGo and its community.
Foster started the presentation talking about the basics of MeeGo, its history and reasons for the merger. MeeGo's scope is everything from IVI (in-vehicle) systems to handsets and netbooks. MeeGo releases have been staggered so far, with the netbook developer release coming first, followed by the handset and then IVI release. However, Foster says that this is not the long-term plan. The MeeGo project is moving to a "cadence" of six-month releases starting in November.
Foster talked, in general terms, about the MeeGo focus on contributing back to upstream as part of the project goals. She said that goal was to contribute all work back to upstream projects used by MeeGo.
Why the merger? Intel and Nokia realized they had similar projects with
similar ideas and goals, so it didn't make sense to pursue the two projects separately. The decision was made from a technical perspective, and Foster acknowledged that it was an internal decision between Intel and Nokia and not a community driven decision.
The MeeGo merger was not, shall we say, universally
well-received. Development communities on both sides were surprised by the
move and unhappy with some technical decisions. Foster noted some of the
challenges that the project has had since its inception, including
architectural issues like the packaging format (choosing RPM over Debian
packages), governance challenges, and figuring out who would be responsible
for various tasks. With Maemo and Moblin, people had well-defined areas of
responsibility on each side, and Foster noted (without specifics) that,
after the merger, it was necessary to choose one person from either MeeGo or Maemo to take responsibility.
This has brought on significant social and community challenges. The
Maemo project had many interested users of mobile devices, while Moblin was
focused on netbooks. Foster said that it's taken a lot of adjustment on
both sides. "You have a new community that is different than the original
communities. And there was frustration [...] early on with all these things and the timeline required to do this."
Foster then ran through the timeline of MeeGo development since its
announcement in February. March 31st was "day one code" for the core
operating system — everything below the user experience. May 25th was the
netbook project code release that included the user experience for
netbooks. June 30th was the release of handset day one code, targeted for developers. August 2nd MeeGo made the first IVI release. Now MeeGo will be moving to regular six-month update and release schedules with the 1.1 release coming in November where all the releases will converge. The only reason for the staggered releases initially, says Foster, is that the project is on an aggressive schedule.
MeeGo has been solving technical challenges quickly but social and
community challenges take more time. Foster talked about the community
growth and tools that have been put into place since its inception like
mailing lists, forums, bugzilla, and so on. Foster noted that the community
has been frustrated with the time required to determine the governance
model and resolve other issues, but that has been mitigated with the code releases and having more clarity around the roles in MeeGo. Still, she says that there's a lot of work yet to be done.
Looking at the numbers, the MeeGo community does seem to be growing at a
reasonable clip. The community now has more than 11,000 members, which is
up from 9,626 in June. There have been about 7,400 posts on the developer
mailing lists since project started in March, and more than 7,000 wiki
edits and nearly 7,000 forum posts since the start a few months ago. Foster
also said that there were about 430 people in the #meego IRC channel on the
morning of the talk. Metrics are public, and can be found on the MeeGo wiki where Foster puts up monthly statistics.
Next, Foster focused on where MeeGo needs help and is looking to recruit contributors. In particular, Foster said that the "best" contributions were applications and noted that they need to get people "excited" about building applications for MeeGo. MeeGo does start with a fair base of applications. When Foster demonstrated MeeGo for the audience, she pointed out that she'd had pretty good success just installing things using RPMs. For instance, OpenOffice.org. However, the handset and IVI editions of MeeGo are unlikely to run random RPMs or applications like OpenOffice.org.
Foster talked briefly about the MeeGo Software
Development Kit (SDK) to point out that developers could work on MeeGo apps on Linux and Windows.
Foster also stressed non-development contributions and noted that MeeGo could use people to update and edit the wiki, report bugs, write documentation and FAQs, and work on translations and localization.
What about core contributions? I asked whether MeeGo had any core or significant contributions outside developers employed by Intel and Nokia. So far, not much. Foster did mention that Novell had been "very active" and that a few developers from other companies had been involved but not very many.
Another question about MeeGo from the audience was the state of open
source drivers. Foster says that MeeGo can't control the drivers from OEMs,
but "the goal is to have an environment that is fully functional from an
OSS perspective, but we can't control that." What about drivers from Intel
or Nokia? Foster, and another Intel employee in the audience, noted that
they were making a good effort to ensure that hardware from Intel came with
open drivers. However, Foster says that MeeGo is run by a software unit
inside Intel, while the bulk of Intel is (of course) focused on
hardware. Thus, it requires negotiation with other business units to try to
make sure that hardware is always released with open
drivers. Unfortunately, they don't always succeed, and can't guarantee 100%
success in the future.
Foster demonstrated a MeeGo system for the audience, taking about 10 minutes to walk through the interface and features on a Toshiba that had originally shipped with Windows. Overall, the interface is looking pretty good. Some details need to be ironed out, however. For example, MeeGo currently does not expose any way to turn the system off or reboot through software. Foster says this is an area of contention within the MeeGo community, with some passionately arguing for or against the presence of power controls in software versus only featuring a hardware button for power off. This can be very confusing when software updates prompt the user to reboot.
Contributors interested in working on MeeGo can join the meetings on
IRC, and should consider attending the first MeeGo conference to be held in
Dublin, Ireland. The conference is to be held November 15 through 17,
though apparently it will end early on the 17th to make way for a football
(or "soccer" as recognized by those in the U.S.) match. A tour of the
Guinness facility is also in the offing. The conference is capped at 600
people, and travel sponsorship may be available for those with significant
contributions beyond just employees of Intel and Nokia. Proposals are welcome through August 23rd.
Overall, the update shows a community that is still in a nascent
stage. Foster signaled willingness to address community issues and try to
include developers outside Nokia and Intel's walls, though specifics were a
bit lacking. It would have been interesting to hear more details about MeeGo's governance and plans to include contributors outside the corporate walls, which is going to be fairly important if MeeGo is going to succeed as a legitimate community project. As it stands, it does seem that MeeGo has taken some reasonable steps toward addressing community concerns and trying to include external contributors in the long term.
Comments (3 posted)
A common event at conferences is a panel of developers with reporters
listening from the audience; your editor moderated just this kind of panel at
LinuxCon 2010. This time around, though, we also saw the tables turned:
there was a panel of journalists facing the developers that they write
about. The panelists were Joe "Zonker" Brockmeier, Jason Brooks, Sean
Michael Kerner, Ryan Paul, and Steven Vaughan-Nichols; it was an
interesting opportunity to see how things look from the other side of the
The opening question was simple: what was the most significant
Linux-related story in the last ten years? Sean wasted no time in naming
the SCO case - it is, he says, "the story that keeps on giving"; seven
years later and he's still writing about it. Steven, instead, cited IBM's
endorsement of Linux and statement that it would be investing
$1 billion in the platform. That announcement, he says, legitimized
the platform and made it possible for people in companies worldwide to
consider using it without getting into trouble. Jason pointed at the birth
of Red Hat Enterprise Linux, while Ryan talked about the onset of "mobile
ubiquity" and the near dominance that Linux has in that area. Ryan also
mentioned MeeGo as an example of how large companies have come to
appreciate the value of collaboration.
Zonker, instead, nominated the rise of Ubuntu. He said that Ubuntu forced
the other distributors to focus on community, something they had not been
doing well before; this is a claim which was not universally accepted by
the audience. At this point, Sean jumped in to say that Ubuntu only took
off because of the seemingly unending delays in the Debian Sarge release.
Had Sarge gone out on time, he says, we would not be hearing so much about
Ubuntu now. Steven added that Ubuntu succeeded because it was an attempt
at commercializing Debian from the outside; earlier attempts from the
inside (he mentioned Ian Murdock in particular) were seriously attacked by
the community and didn't get very far.
Moving on: what is the big story for Linux today? The consensus answer
seemed to be "Android." Steven claims that ChromeOS is going to be a big
deal. He also mentioned the license compliance program just announced by
the Linux Foundation which, he says, will speed Linux adoption.
The reporters were then asked about numbers from analysts, which, when it
comes to Linux, are somewhat controversial. How do they cope with that
uncertainty? Ryan responded that these numbers (covering Linux adoption
and such) are not really illustrative and are missing a lot of context.
Beyond that, they are the product of companies with conflicts of interest;
analyst firms have paying customers who have an interest in how those
numbers come out, so the result is not objective. Sean said he does not
trust the numbers; they are always wrong, so he does not use them. Jason
wished for better numbers on enterprise subscription sales, while Zonker
criticized analyst firms for refusing to come up with a solid methodology
for counting unpaid Linux use. Steven asked simply: who cares about these
It was asked: it seems to be harder to get reporters' attention for
Linux-related stories in recent years, what are reporters looking for?
Sean suggested that there are really only ten Linux stories that he writes and
repeatedly; one of them is "Mark Shuttleworth said..." He also said that
he always covers what the big vendors are doing, but news of the form
"application X now runs on Linux" is not really interesting. Zonker
noted that, while more reporters (with less expertise) are covering Linux
due to its increasingly mainstream nature, a lot of reporters have also
been laid off in recent years. Steven said that we're seeing a natural
progression; like the radio magazines of the 1920's or the Internet
magazines of the 1990's, much Linux news has simply become mundane and
Steven also said that there is little interest by publishers in "serious"
stories about Linux, a statement that Zonker seconded. It is necessary to
write "popular" stories that will draw advertisers. Linux companies, it
seems, are not big buyers of online advertising; that affects coverage too.
Several of the panelists said that there is still a firm wall between advertising and
editorial, but that claim (in your editor's opinion) seems somewhat
contradicted by the fact that they have a hard time pitching stories which
do not appeal to advertisers. Jason said that the publishing business
model is, in general, in trouble and hasn't yet figured out the changes
that have come with the Internet.
As an aside, Zonker asked how many members of the audience run AdBlock
(quite a few hands were raised). Those people were told that they are
"killing publishing, seriously."
Next question: who is the audience for what the panelists are writing?
Ryan said that ars technica has a highly diverse audience, since it is not
just a Linux-related site. Their readers are technology enthusiasts who
(advertisers are told) will take what they learn to the workplace. Jason
writes for enterprise information technology workers, while Zonker writes
for a number of different publications (including LWN) with a variety of
audiences. Steven, too, writes for many audiences.
What about companies becoming their own publishers? Steven claimed that
people are becoming confused by publications which really just carry the
company line, as opposed to what a real reporter would say. Readers are
not asking often enough where a particular bit of news comes from. Ryan
noted that open source companies are much more transparent than many
others, so information tends to be more accessible; community members can
use that information to get the word out, reducing the need for traditional
journalism. But Steven noted that these companies always have something
that they are not saying - he mentioned silent fixes in Mozilla releases -
so there is still a need for people who will dig through stuff. Zonker
said that what's often missing is context; he suggested that people will
wander into (for example) the GNOME census story without understanding all
that's going on.
At that point, time ran out for this standing-room-only session. In your
editor's opinion, it was an interesting look at how the more traditional
media sees our community and the pressures that reporters are working
under. Those people, too, are operating in a rapidly changing world; they
have the challenging task of documenting those changes while being very
much in the middle of them.
Comments (29 posted)
Page editor: Jonathan Corbet
Next page: Security>>