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
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
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
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
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
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
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)
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
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:
I used to think that we would need an IP unencumbered file system,
given issues around TomTom and Microsoft, but these days, given how
quickly Linux has taken over the embedded and mobile landscape
for all but the most tiniest of devices, I don't think that's as
important of an issue, since we can just simply use a native linux
file system. In the time that it would take to get some other new
file system adopted across the industry, it's likely Linux will
have enough market share to perhaps compel the other OS vendors to
provide interoperability solutions.
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:
There will be patches very soon for a new file system from a major
flash vendor that I'm cooperating with. I haven't seen the patches
myself yet, but the design is similar to a prototype that was done
thesis I supervised
. I hope that the new implementation is
similarly simple to this design, and also able to provide optimum
performance on most flash media.
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)
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
that Google has filed a case against Apple with the US International
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:
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.
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.
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.
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.
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.
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.
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
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
Inside this week's LWN.net Weekly Edition
- Security: Forward secure sealing; New vulnerabilities in emacs, gdb, gimp, glibc, ...
- Kernel: Power-aware scheduling; Link-time optimization; Ask a kernel developer: maintainer workflow.
- Distributions: Debian looks at OpenRC; AV Linux, Firefox OS.
- Development: GNOME development; Git; grep and coreutils; MariaDB; ...
- Announcements: Help Ken Starks, A Generation Lost in the Bazaar, lots of events, ...