Leading items

GUADEC: GNOME OS conversations

At GUADEC, the "GNOME OS" concept was discussed off and on several times during the course of the week. The first mention of the subject came in a talk from Igalia's Juan José Sanchez Penas and Xan Lopez on the first day of the event. Their talk A bright future for GNOME dealt largely with what the GNOME project needed to do to address the mobile and embedded space. In that context, GNOME's current build and release system — which is focused solely on the desktop computing experience — offers nothing for mobile device makers to build on.

But, they said, if GNOME were to start producing a bootable OS image as one of its "deliverables," device makers would have a starting point that they could adapt to their own hardware. Although they did not provide specifics, they said that Igalia has spoken to mobile device makers who are not satisfied with the current market offering of Apple's iOS and Google's Android. GNOME has already done a lot of design and technical work to make GNOME Shell and other components touch-screen capable, they observed, but it remains bound to traditional PC hardware. A mobile-friendly GNOME would have a leg up on competing open source projects like Tizen, webOS, and Firefox OS, which have all had to "start from scratch." Their definition of "scratch" is not entirely clear, but it is certainly common for new Linux-based mobile platforms to write their own applications and supporting frameworks.

Although Sanchez and Lopez spoke of the benefits of having an installable GNOME for use as a base platform for mobile device makers, that was not the only reason the GNOME OS buzzword came up over the course of the week. The other — and perhaps more frequently-raised — issue is that GNOME has essentially never been presented as an end-user ready product. The cause is clear enough; as Colin Walters discussed in his talk, most Linux users get their software through a distribution's package manager. The trouble from GNOME's perspective is that distribution packages are typically delivered six months after GNOME drops its stable release, so when bug reports arrive they are almost a full development cycle behind. In addition, every distribution makes enough changes that whatever bug reports users do send in are difficult to triage and diagnose.

Making a bootable GNOME image one of the pieces in each GNOME release would allow users to try the unaltered packages sooner, and provide faster and better feedback to the project. It would also allow GNOME to develop an SDK for application developers who are interested in writing distribution-neutral GNOME code. Sanchez and Lopez proposed setting an "ambitious plan for 3.8 through 3.12" that would culminate in a mobile-capable release for GNOME 4.0. That time frame equates to two years using GNOME's current release schedule — not immediate, but not too far off to plan. Post-4.0, they proposed planning a GNOME SDK and working on application distribution channels and other components that a mobile GNOME ecosystem might require.

The meaning of OS

Allan Day addressed both the improved-testing-and-feedback rationale and the improve-GNOME-for-application-developers goal on his blog shortly after GUADEC. Nevertheless, there are still those who conflate the plan with a desire to transform GNOME into a full-fledged Linux distribution, a confusion that was evident in audience members' questions at GUADEC, too. It ought to be clear that GNOME would need to add a significant number of developers (not to mention packagers and infrastructure) to support a complete distribution, but perhaps "GNOME OS" is simply a poor choice of terminology. Sanchez and Lopez did refer to GNOME OS as a "distribution" in their talk, but when an audience member asked about it, they clarified that use of the term was a slip not meant to be taken absolutely.

Admittedly, there are those in and around the GNOME project who have more ambitious goals (Lennart Poettering had a session I was unable to attend that dealt with integrating GNOME components more directly with the kernel), but they are the exception. At its core, the idea is really about bridging the existing gap between the project and its users — as well as the gap between the project and application developers — in order to collaborate better with them. Given the number of times in recent years that the project has run into end-user backlash over design changes (in particular those instances that seem to revolve around a perceived lack-of-responsiveness to feedback), that would seem to be an admirable goal.

Vision quest

But the GNOME OS discussion has a subtext, which is the perception that GNOME as a project no longer has a long-term goal. On the one hand, that means that the original goal of producing a quality free software desktop environment has largely (or perhaps even completely) succeeded. But it also means that GNOME as a project is searching for a new target. There are plenty of people who feel that mobile devices are the answer; others (like Lionel Dricot) contend that online services are the new frontier, or (like Eitan Isaacson) that believe that targeting high-end workstation users is best.

The vision question also arose at the GNOME Foundation general meeting, which kicked off with the Release Team asking attendees what they wanted the Release Team's role to be. Specifically, the team asked whether or not the project ought to have a Technical Board to set the long-term vision and to make technical decisions. The team reported that it felt like some members of the project expected it to fill such a role, but that driving development was not its mission.

The resulting discussion was an interesting one; GNOME's culture has been "individual maintainers rule their modules" for a long time, but that concept does not extend well into a long-term roadmap. Bastien Nocera pointed out that in years past, it was often a single individual — such as Jeff Waugh — who either set or articulated the vision for GNOME. Since Waugh's departure, no one has replaced him in that function, although Nocera pointed out that Jon McCann's UI demos have served as a de facto substitute in recent years.

Others pointed out that while vision was an important topic on its own, practical matters still dominate, such as making the final call on which version of Python to support. A Technical Board should make such a decision (which affects many modules), but it is hardly a matter of "vision." Clearly individual GNOME developers are producing high-quality work and driving the project forward. But focusing that energy, whether into GNOME OS or toward another goal, is a task that the project is still working out.

[The author would like to thank the GNOME Foundation for travel assistance to A Coruña for GUADEC. The event was deftly organized and smoothly run from start to finish, sported a universally high-caliber program, and an enthusiastic crowd at every turn. Plus, as the photographs in the story above hint, A Coruña was an inspiringly-scenic location in which to spend a week discussing and learning about open source. Thanks to everyone who put in time and energy making the conference a success.]

Comments (31 posted)

On the need for a new removable device filesystem

Removable storage devices, such as the USB "thumb drive," can be a pain. They are slow and often prone to errors, but, perhaps worst of all, they all seem to be designed for the VFAT filesystem. VFAT gets the job done much of the time, but it is showing its age; this filesystem was never meant for the size of contemporary devices or files. There is also the little nagging issue of the patents on the filesystem format and the associated Linux-hostile company that is actively asserting those patents. Despite all of this, removable devices are often the easiest way to ship files between machines. Given that, do we need to come up with a new filesystem to ease the pain of using these devices?

Dan Luedtke's answer is "yes"; he has implemented a new filesystem called "Lanyard" (or "LanyFS") intended for use on removable devices. He claims better performance and scalability than VFAT along with a native Linux implementation. The code shows its early-stage nature — there are a lot of things that would need to be fixed before it could be considered for inclusion into the mainline kernel — but the mainline is clearly where Dan would like it to go. The rest of the development community is not entirely convinced that we need a new filesystem for this use case, though.

The first question is: why not stick with VFAT? For all of its troubles, it has worked well enough for a long time. The biggest motivator for a change, arguably, is the 4GB limit on file size. One can deal with poor performance, especially when the real bottleneck is likely to be the device itself. But if one wants to store a sufficiently large file on the device, VFAT will simply fail. Such files are increasingly common, so users are running into this problem. The exFAT filesystem format is held out as an alternative, but it is far more proprietary than VFAT. Given that VFAT has already been the subject of lawsuits, vendors will think carefully before switching to exFAT; Sharp has licensed the filesystem for Android devices, but there do not appear to be a whole lot of other takers at this time.

Given increasing networking speeds, one could certainly consider just using the network to move a file that is too large for VFAT. On a local network this approach might well be faster than using a removable drive. Setting up network transfers is not always easy, though; most computers are, by default, configured in ways that do not allow random strangers to dump large files on their drives. Getting around that obstacle is likely to be too much even for moderately skillful users. Use of a third-party site to transfer files is workable when the files are small; even if it is possible for very large files, it's not something that will be tolerably fast on most networks.

Removable drives, instead, are easy, so the "sneakernet" approach to file transfer is likely to stay with us for some time. Does that mean that we need a new filesystem format to better support this use? Filesystem developer Ted Ts'o thinks not:

That is an interesting thought: Linux is now strong and prevalent enough that we can simply expect the industry to pick up our way of doing things. That approach has not always worked out in the past, but things might truly be different this time around. Increasingly, devices like music players, handsets, and digital cameras run Linux internally; these gadgets already are, to a first approximation, removable storage devices with a bit of extra hardware. Other devices, such as televisions, also tend to run Linux internally. Supporting a native Linux filesystem on these devices should be a relatively easy thing to do. It would be faster (assuming the underlying storage isn't severely optimized for VFAT only), more feature-rich, and lacking in patent aggressors. There is very little, in other words, not to like.

Well, there would be a few small problems. There are still some pesky users out there with non-Linux systems that might want to access the filesystems on their devices. In many cases, the increasing use of the MTP protocol could sidestep that question altogether; indeed, recent MTP-using Android devices are likely using it to export an ext4 filesystem. There would still be cases where users on these other platforms would want to mount filesystems directly, though, especially on pure storage devices; bringing proper implementations of Linux filesystems to those platforms is, evidently, not as easy as one might think.

Filesystems like ext4 also were not designed with removable devices in mind. They tend not to be all that robust against unexpected removal of the device unless fairly aggressive flushing of data is used (in fairness, VFAT filesystems are also easily corrupted that way). The file ownership model used by Linux filesystems tends not to translate well to removable devices, since one system's user IDs typically have no meaning elsewhere. So something like the user and group mount options patch may be required to make things work well. Most Linux filesystems have not been designed around the very large pages and erase blocks used on flash devices and, thus, do not perform as well as they could; see this article for lots of details. These are issues that can be worked out, certainly, but they remain in need of working out at this time.

There is one other complication: according to Arnd Bergmann there is another filesystem waiting on the wings:

Needless to say, such an entry has the potential to stir things up a bit. A filesystem designed with input from both "a major flash vendor" and a developer like Arnd should work well indeed on small removable devices and should be well integrated into Linux. This manufacturer could also employ the "include a windows driver in a small partition on the device" trick, making interoperability with most Windows systems Just Work. Putting the filesystem code into the Linux kernel would make support readily available on mobile devices. This scheme might just succeed.

So what we may see is not Linux pushing one of its native filesystem formats onto the world. Instead, the world might just adopt a new format that just happened to be well supported in Linux first. That could be the best of all worlds: we would have a way to interoperate on removable drives that is free, scalable, and widely supported. Getting there may well be worth the trouble of adding yet another filesystem type.

Comments (26 posted)

Mobile patent wars: Google goes on the attack

Whenever one looks at the mobile patent wars, it is natural to conclude that everybody is suing everybody else. Thus far, though, that has not actually been true. Google has been on the receiving end of a number of lawsuits, either directly or indirectly via attacks on manufacturers shipping Android devices, but Google has not, itself, launched patent attacks against others. That situation has just changed, though, with the report that Google has filed a case against Apple with the US International Trade Commission.

In short, Google is trying to use seven of its patents (just acquired from Motorola Mobility) to block the import of Apple's products into the US. Those of us who fear the effect of software patents on free software might be forgiven for feeling that it is only just for Apple to be on the receiving end of the sort of attacks it has launched against Android. But Google's transformation into a patent aggressor may not bode well in the long term, regardless of how the current cases end up.

So what is Google claiming? The seven patents asserted against Apple are:

• Geographic-temporal significant messaging (5,883,580). The idea here is accepting messages with an associated location identifier (and maybe a time range). Should the user of the device wander into the specific location, the messages are acted upon. Think "50% off on a latte right now!" as one walks past a coffee shop.

• Apparatus, method and system for multimedia control and communication (5,922,047). This patent seems to cover using a handset as a remote control for external devices, from entertainment through to heating, lighting, and security.

• Apparatus and method for handling dispatching messages for various applications of a communications device (6,425,002). A system that receives "messages," classifies them, and delivers each type of message to the right application. It does not take an overly broad reading of this patent to imagine that it could apply to most networking implementations or to higher-level applications like mail transfer agents, web servers, or IRC clients.

• Markup language for interactive services and methods thereof (6,493,673). This patent covers the use of a markup language to describe user interface elements and the actions to be taken in response to user actions. It could easily describe a Tcl/Tk program or an HTML form, but there is one additional twist: the claims require an attribute enabling audio input by the user. It is clearly being asserted as a direct attack on Apple's "Siri" functionality.

• System for providing continuity between messaging clients and method therefor (6,983,370). This is a mechanism for transferring a user session (in some application) from one device to another.

• Method and apparatus for obtaining and managing wirelessly communicated content (7,007,064). A device receives "content portions"; contained within those portions can be instructions for the removal of previously-received portions. The idea is to push information (news, financial information, sports scores) to a device and automatically clear out old or obsolete information.

• System and method for managing content between devices in various domains (7,383,983). A simple algorithm for pausing content playback on one device and resuming it on another.

(Credit is due to Florian Mueller, who found and posted the specific patents at issue).

As is so often the case, there is not much in these patents that appears to be particularly novel or worthy of protection. Once one concludes that a particular problem (moving video playback from the handset to the television, say) is in need of solution, the form of the solution becomes fairly obvious. The patents asserted by Apple against Android seem trivial, but it is hard to come up with a way to say that Google's patents are less so.

If one is concerned about attacks against Android and other platforms based on free software, one might be tempted to hope that Google will find some success against Apple and, in so doing, deter further attacks on the platform. The mobile patent wars could be declared to be a draw, and the companies involved could get back to their real business: running on the consumer electronics product treadmill and trying to create better products to sell to their customers. Barring real reform of the patent laws in the US, that might well be a best-case outcome.

What seems more likely, though, is that the companies involved, having shown that they can make each other hurt, will come to some sort of understanding involving the sharing of patents and, perhaps, the passing of undisclosed amounts of cash between some of the parties. Such an agreement would presumably make the world safer for Android and for at least some of the manufacturers who use Android in their products. But it's not at all clear that the situation would improve for free software as a whole, or for anybody who is outside of this agreement and who wants to break into the mobile market.

A worst-case scenario could involve Google asserting these patents (and others from the massive pile it acquired from Motorola) against devices based on Tizen, Nemo, Firefox OS, or other free platforms. Unlike some companies, Google has not pledged not to attack free software projects with its patents. Such an attack would certainly be widely considered to be "evil," but the sad fact is that, in an extended fight, one tends to become more like one's enemy. Having found that it can further its goals with patent attacks (assuming that is, indeed, the outcome), Google may find it hard to resist making more of them in the future.

In the end, that may be the environment we are stuck with until the software patent situation can be addressed. Until then, it will be impossible to achieve a certain level of success in the software area and not be subject to patent attacks, either from trolls or from competitors. Given the nature of the game, it is hard to fault Google for playing hardball. Hopefully, the company's recent suggestions that software patents should be eliminated entirely are sincere and we are not witnessing the birth of another patent problem.

Comments (69 posted)

Page editor: Jonathan Corbet
Next page: Security>>