Leading items

Directions for GNOME 3.0

Earlier this year at the Gnome Users and Developers Conference, it was announced that there would be a Gnome 3.0 and discussions about how to make the transition are now open. Since then, there has been another gathering of Gnome developers, discussing and making plans about how they would like to modernize the interface. Over the past few days, a number of blog posts have appeared on Planet Gnome discussing some of the happenings at this five day event, and I felt a summary of the ideas so far might be useful to everyone concerned.

The Journal

The idea that has perhaps received the clearest exposition, along with some concrete work on beginning to make it a reality, is a refreshed way to handle day to day file management based on the OLPC's journal concept. Federico Mena-Quintero posted to his blog reporting his teams brainstorming session. What's wrong with how we handle file management today? Federico says:

So, programs contribute to having files scattered around everywhere, and there is no easy way to look at everything together.

To solve this problem, they began from the premise that humans are fairly good at knowing when they did things: "I started typing my homework last Monday, because I knew it was due on my Thursday class" and "I mailed you that photo two weeks ago, right after my birthday party" were the examples given. From here, the argument is that if we can present users with a journal view of what they did, they can forget about where they put a file and just browse through a time line to find what they were looking for.

The journal would not only keep track of files you created, but websites you visited, IM conversations you had, and even allow you to make notes about particular entries. An example of this final kind of functionality might be noting down reference numbers from receipts or customer service representatives.The other two major features of the journal would be the ability to star important items, so they're kept in a separate section, along with the ability to create files from directly within the journal, allowing it to act as a kind of scrap book.

As well as Federico's own proof of concept implementation, you can also find similar ideas in Mayanna's timeline, a fork of Gimmie, and the Nemo file manager.

Task Orientation

This post didn't arise out of the User Experience Hackfest, but from GUADEC earlier in the year. Karl Lattimer has posited that the application centric workflow is broken, and that people don't use a computer with the intention of using a particular application, but with the intention of completing a particular task. Obviously tasks rarely stand on their own, but often form part of a larger project.

Karl comments that he believes Federico is making moves in the right direction with the journal, providing users with the capacity to track what they did and when - perhaps a kind of project management framework - but he believes that we also need to provide users with the ability to track why things were done, gathering metadata about the tasks and building a picture of the relationships between them. The example he uses is that of an email received from a colleague asking us to update a file by a certain deadline: from this we could extract the file, the deadline, who sent it to us, and possibly even what needs doing to the file, all of which could be fed into the journal or other interface. This obviously has some practical challenges when it comes to considering how it could be implemented, but if realized could deliver an automated task list that's closely linked with templates for commonly performed tasks, doing away with the idea of static workspaces and applications for ever.

Karl sums up his thoughts nicely in this paragraph:

The Desktop Shell

During this hackfest session, the team tried to forget about the current Gnome interface and focus on what makes sense for users; ironically, Vincent Untz decided to start his post, about how the team forgot about the current Gnome interface, with some observations of the current Gnome interface. The problems he identified in the current interface were four-fold. Firstly, finding the window you want can be difficult when using the default applet, particularly if you have more than a few windows open, and particularly if you have a smaller screen. Secondly, few people make use of the multiple workspaces idea, largely because they were just unaware of their existence. Thirdly, application menus are a slow and inefficient way to open up new applications; some take advantage of launchers or the run dialog to improve on this, but most don't know how to do this. And finally, the current panel is certainly very powerful, but its power is wasted in unneeded flexibility such as being able to position the panel in the middle of the screen.

Perhaps the most controversial proposal to fix these problems so far is to restrict Gnome to a single static panel: by removing one panel we'd be saving valuable screen real estate, and by having a layout we can depend on we'd be able to use "hot corners" more effectively, allowing users to easily set their presence, as well as to launch a new "activities overlay mode". While the idea of a single panel hasn't raised too much concern, the static point has: Mathias Hasselmann responds with "Static Panel Nonsense", suggesting that many Gnome users, himself included, as well as Mac OS and Windows users, heavily customize the layout of their panels with custom launchers, and to improve something by removing existing functionality is not a good approach.

The most promising proposal from my point of view, and what seems to be a common OLPC inspired train of thought amongst Gnome's community, is the notion of activities. An activity is essentially what Karl Lattimer described as a project, made up of individual tasks, and what many Gnome users organize into separate work spaces in the current environment. In the current Gnome environment, Vincent argues, activities and work spaces are static: a user configures 8 desktops and sticks with them. His proposal is that activities should be far more flexible, and if a user wants to start a new one then we should help them by creating a new desktop automatically.

Where Next

Reportedly the release team are busy preparing a plan for how we can move from Gnome 2.x to 3.0, with the current plan appearing to be that what would have been called 2.30 will become 3.0. In this time frame, the very least of what we can expect to see is a revamped Gtk+, but what changes the user can expect to see is far harder to tell as there are no known plans for a radical interface overhaul like that seen during the development of KDE 4. Instead, it appears that the Gnome release team are planning on sticking to their current principles with regard to what features will become a core part of the desktop stack: adoption by popular distributions, stability, and a proven track record will all be required for features to make it in. This may seem like it rules out huge amounts of innovation, but there are a number of existing frameworks in Gnome that are very exciting (PolicyKit, PackageKit, Clutter, GVFS, desktop search, D-Conf, online desktop), and perhaps the 3.0 development cycle will see these mature and finally deliver on their promise of revolutionizing the user experience, with many of these technologies forming the backbone of the ideas discussed in this article.

Comments (45 posted)

Debian's election season: old firmware and new contributors

Longtime LWN readers will be aware of your editor's tendency toward the publishing of wild predictions at the beginning of each year. The 2007 predictions irritated some Debian developers and users by suggesting that, after getting the Etch release out the door, the project would go back to arguing about firmware issues. At the end of the year, it became necessary to acknowledge that this prediction, like so many others, had failed to come to pass. In retrospect, the error in this prediction was obvious: the Debian Project traditionally saves the firmware argument for the end of the release process. After all, they need to find some way to delay a release once it's looking close to ready.

The problem with firmware, of course, is that it is a binary blob lacking the corresponding source, and, sometimes, even a license allowing its distribution. Many developers and users see that blob as being part of the hardware; as long as the blob is distributable, it does not bother them. Others, though, regard firmware blobs as proprietary software and their incorporation into the kernel as a GPL violation. The Debian Project, which promises to deliver a 100% free distribution to its users, houses many developers from the latter camp. These developers, who see firmware distribution as a violation of the project's social contract, can be counted upon to raise the issue each release cycle.

In 2004, the project responded by passing a general resolution suspending some social contract provisions through September 1 of that year on the reasoning that it would be long enough to get the Sarge release done. Putting a date on a Debian release tends to be a mistake, though; Sarge was not finished until June, 2005. By unspoken consensus, that date was somehow deemed to have fallen before September 1, 2004. In 2006, the project voted again on firmware. Having learned from experience, the exception they allowed this time lacked a date, simply saying that the presence of binary-only firmware in the Etch release was something the project was willing to tolerate.

The 2008 discussion started when Ben Finney pointed out that a number of firmware-related entries in the Debian bug tracking system had been quietly marked "lenny-ignore" - not relevant to the upcoming Lenny release. This action, many have subsequently argued, runs counter to the social contract and constitution, which do not allow the shipping of non-free software to be swept under the carpet in this way. They would, instead, like to see the kernel team remove the (relatively few) firmware blobs remaining in the kernel. Such a change, it is said, should be relatively easy; recent changes within the kernel are helpful in this regard - though said changes became available in 2.6.27, which is not the kernel expected to be shipped with the Lenny release. For the 2.6.26 kernel used by Lenny, Ben Hutchings reports that he has done the necessary work to excise the remaining firmware.

On the other side, there are developers who are more concerned about (1) getting the Lenny release out as quickly as possible, and (2) making sure that hardware Just Works for Lenny users. They would rather that the process of removing firmware continue independently of (and without delaying) the Lenny release.

This is Debian that we're talking about, so the issue will probably be decided by way of a general resolution. There are currently two sets of resolutions being circulated, though neither has reached a final state for voting. The first set addresses the Lenny question, providing two options: either delay Lenny until the firmware removal work is complete, or accept that - just once more, really this time, honest - a major Debian release will include some firmware in its kernel. (The "ship Lenny" option is actually two options, one allowing firmware and one allowing Debian Free Software Guidelines violations in general). What the project will decide once this resolution comes to a vote is unclear - but Debian's developers have always voted to get the release out in the past.

The second proposal addresses what happens after the Lenny release; it says that any package which violates the Debian Free Software Guidelines for more than 180 days will be forced into the non-free repository. The clear hope here is to ensure that this tiresome discussion doesn't happen yet again in the next release cycle. By the time the next release is getting close to ready, any non-compliant packages will have long since been banished to the non-free wasteland. If it ever comes down to moving the kernel to non-free, though, one can assume that the discussion will resume with a vengeance.

Developers, Members, Maintainers, and Contributors

Meanwhile, a different disagreement is headed toward - you guessed it - a general resolution. Long-time Debian watchers have noted that another recurring topic of debate is the acceptance of new developers. The new maintainer process involves long delays, tests of ideological purity, and more. Even when it works smoothly (which seems to generally be the case in recent years) it requires a certain amount of patience and determination on the part of an aspiring Debian Developer.

The difficulty of the process is a design feature; Debian developers occupy a position of some trust, and the project wants to make sure that applicants are serious. Over time, though, it has become clear that this process is costing the project the time and energy of talented contributors who do not wish to jump through all the hoops. In response, the project created a "Debian maintainer" designation which allows the uploading of packages, but withholds many of the other privileges enjoyed by full developers. This change appears to have been successful in enabling a larger group of developers to contribute to Debian.

More recently, Joerg Jaspert has proposed lowering the bar to certain types of contribution even further. The proposal reads:

To that end, Joerg would create a new "Debian Contributor" classification. Contributors would be those doing translations or documentation; the proposal doesn't say that contributors don't touch code, but one gets that sense. Contributors would still have to jump through some hoops, but they would be fewer. They would not be able to upload packages on their own. The proposal also changes the Debian Maintainer standards, making that designation a little bit harder to get. Finally, the proposal states that all new applicants to the project would become Contributors or Maintainers. Only after a six-month period would they be able to apply for full Debian Developer or Debian Member status -- "Debian Member" being another new category that, while being equivalent to Debian Developer in almost all respects, would not have package upload privileges.

Interestingly, there has not been much discussion of the substance of this proposal. But there has been a fair amount of debate over how it is being done. It would appear that some developers see this change as being imposed by a single project official without the debate that Debian changes normally require. Martin Krafft has further asserted that this kind of change goes beyond Joerg's authority as Debian account manager, a claim that Joerg denies.

So now there are proposed general resolutions being circulated. An early version simply decreed that the proposed changes were "suspended" in favor of changes to be made through a more consensus-oriented process. Later versions soften the language somewhat, and thank Joerg for his effort in this area - but still require a "consensus or general resolution" before changes are adopted. In any form, the clear point of the resolution is to slow down the process and open it up for a wider discussion.

Again, voting has not begun on any specific resolution, so we don't yet know what will even be voted on, much less how it will come out. But we can expect that, as a certain presidential election process finally (thankfully) comes to a close, activity will be picking up on a different set of votes.

Comments (11 posted)

Networking change causes distribution headaches

A seemingly innocuous change to the networking code that went into the 2.6.27 kernel is now causing trouble for various distributions. Ubuntu, Fedora, and openSUSE are all buttoning up their packages for a release in the near future—with Ubuntu's due this week—so kernel changes are not particularly welcome. Unfortunately, if the problem is not addressed, some users may never be able to download a fix because their TCP/IP won't interoperate with some broken equipment on the internet.

The problem stems from changes that were made to clean up the TCP option code that were merged back in July as part of the 2.6.27 merge window. TCP options are a mechanism to expand the functionality of the protocol as conditions change. There are a handful of commonly used options that the two endpoints of a connection can agree to use, for things like maximum segment size (MSS), window scaling, selective acknowledgment (SACK), and timestamps. Options have been added over time to provide more internet robustness and performance as well as to support higher-bandwidth physical connections.

A perfectly reasonable, if unintended, consequence of the code change was that the the options were put into the header in a slightly different order. According to the relevant RFCs, options can appear in any order in the option section of the TCP header. But, some home and/or internet routers seem to expect a fixed order; refusing to make connections if the order is "wrong". In particular, it would seem that the MSS option needs to appear before the SACK option.

The bug was reported to Ubuntu Launchpad in early September, but not a lot of progress was made until it was added to the kernel.org bugzilla in early October. It seems to have only affected a relatively small number of users—Red Hat's Dave Jones said that there were no reports from users of the rawhide 2.6.27 kernel—as it was rather hardware-specific. This made it difficult to track down for the majority of folks who couldn't reproduce it. Ubuntu user Aldo Maggi, who filed the kernel bug, sets a marvelous example of how to work with the kernel hackers to track down the problem as can be seen in the bugzilla entry.

Eventually, the option re-ordering problem was discovered and a patch was submitted by Ilpo Järvinen that restored the order of the options. Along the way, with help from Mandriva, it was discovered that turning off TCP timestamps by way of:

    sysctl -w net.ipv4.tcp_timestamps=0

worked around the problem without changing the kernel—at the cost of losing the TCP timestamp functionality.

So it would seem that the problem has been solved—the patch has been merged into Linus Torvalds's tree for 2.6.28—but there are still a few unresolved issues. The three distributions that are preparing new releases are all based on 2.6.27, but as yet, there has not been a -stable kernel release that picks up the patch, though it is likely to come fairly soon.

In the meantime, Fedora has added the patch to its kernel in rawhide, so Fedora 10 (and eventually Fedora 9 when it gets rebased on 2.6.27) will have the fix. openSUSE is waiting a bit to see what gets submitted by the kernel networking developers to the -stable team. As Novell/SUSE kernel hacker Greg Kroah-Hartman puts it: "We still have a while to go before the final 11.1 kernel is released, so we feel no pressure here." Unfortunately, Ubuntu got caught very late in its release cycle as 8.10 (or Intrepid Ibex) is due on October 30.

The original plan as outlined by Debian/Ubuntu hacker Steve Langasek was to note the problem in the release notes for 8.10, but not address the underlying problem until after the release:

That led many in the Launchpad bug thread to note that it was going to be a real mess, especially for the least technical of users. Nick Lowe sums up the problem:

Certainly, the release notes are not the first place an affected user would go if they ran into the problem. More than likely, they would just decide that Ubuntu—by extension Linux—is simply broken, so it is a relief to see that Ubuntu eventually relented. For 8.10, the procps package has been changed to work around the problem by turning off timestamps. Once a new kernel package is released with the re-ordering patch included, timestamps can presumably be restored.

This kind of problem—where affected users may not be able to retrieve an update to fix it—should really be part of the definition of a show-stopping (i.e. release date slipping) problem. It was rather galling to some that Ubuntu would consider shipping with this known issue, simply to make its 8.10 release in the 10th month of 2008 (which is how Ubuntu releases are numbered).

Ubuntu is justifiably proud of its record of shipping releases on time, but it cannot do that at the expense of its users. While the workaround that was implemented was suboptimal, perhaps, it does ensure that users—especially non-technical users—won't find that web surfing doesn't work in Linux. It should also allow Ubuntu to release on schedule.

[ Thanks to Nick Lowe for giving us a heads-up about this issue. ]

Comments (62 posted)

Page editor: Jonathan Corbet
Next page: Security>>