It has now been three months since your editor posted his experience with GNOME 3
GNOME Shell. Much of the intervening time has been spent gaining more
experience with the system; it even included getting a better video card to
enable the full GNOME Shell experience. The time has now come to start
playing with the GNOME Shell extension mechanism. Some interesting things
can be done with extensions, but
it has also come out that parts of the project are hostile to the very idea of
GNOME Shell extensions. In the end, one may well wonder: who controls our
For the most part, your editor must conclude that GNOME 3 works well
enough - though with some glitches. Moving the pointer too close to the
upper-left-corner minefield and getting an unwanted overview mode experience still
happens several times per day. It's still annoying to have to go through
extra steps to get a second terminal or browser window. Workspaces must be
with care to ensure that windows end up where they are expected to be.
The top panel (the black bar at the top of
the screen) still represents wasted space that could be put to better use.
But, as a whole, things work well enough for a dot-zero release; one
assumes that things will get better. GNOME 3 is not that bad.
One thing that is happening is that the number of extensions for
GNOME Shell is growing. The Rawhide repository now includes a number of
them. One extension puts a music player controller into the black bar;
a nice idea, but it seemingly does not work with audacious. Another claims
to remove the accessibility menu, but that one does not work at all.
There are others your editor has not tried, adding a "places" menu,
restoring the "shutdown" option, adding a dock-style task switcher, and
The "GNOME Shell
frippery" extensions are not currently packaged by Rawhide, but your
editor decided to give them a try anyway. With the full set installed,
the down side
of extensions quickly became clear; they simply crashed the shell
altogether. The GNOME system was very helpful: the message read "Something
went wrong, please log out and try again." One assumes that these
extensions have fallen behind the current state of GNOME Shell. As it
happens, there is no real mechanism (yet) for ensuring that the shell and
extensions match; it seems likely that a number of extension users will run
into this particular trap in the coming years.
Happily, one of the extensions in that package works just fine: the one
which adds the "favorite" applications to the top panel. Clicking on the
terminal icon there simply yields a new terminal, just as $DEITY intended.
That one little change has helped to make your editor's GNOME Shell
experience quite a bit more productive.
The extension mechanism built into GNOME Shell is quite flexible, so one
could imagine that quite a few useful extensions will show up in the coming
months and years. In a normal world, one would expect that the GNOME
developers would welcome this development - others are making use of the
capabilities provided to make the platform better. In the world we
inhabit, the community has been somewhat less welcoming. Consider the
discussion that ensued after Jasper St. Pierre outlined his plans for a web site where users
could find (and post) their extensions. Allan Day,
for the GNOME Foundation under contract, a former GNOME marketing
Facilitating the unrestricted use of extensions and themes by end
users seems contrary to the central tenets of the GNOME 3
design. We've fought long and hard to give GNOME 3 a consistent
visual appearance, to make it synonymous with a single user
experience and to ensure that that experience is of a consistently
high quality. A general purpose extensions and themes distribution
system seems to threaten much of that.
He did admit that extensions can be "valuable as a crutch for our
traditional users" and, perhaps, for experimenting with features.
But, in general, it seems that, in his view, GNOME Shell users should
accept what they are given and not seek to change the experience.
Otherwise, all that design effort will have gone to waste, and,
horrifyingly, the project's marketing might be
The point is that it decreases our brand presence. That particular
user might understand what it is that they are running, but the
person who sees them using their machine or even sees their
screenshots on the web will not. The question we have to ask
ourselves is: how do we make sure that people recognise a GNOME
install when they see one?
This is the point where one needs to ask what the purpose of the project
is: to enable its users to be maximally productive and happy in front of
their computers, or to increase the project's brand presence? One might
actually think that those two goals should not conflict with each other,
but, should that come to pass, one would hope that the users would win.
The fact that they might not is cause for concern.
Allan is not alone in his views, but
neither are those views unanimously held; others have understood that extensions are going to happen
Those who are satisfied with original design won't even care about
extensions. Those who are not, well, you can't stop them
anyway. Why making it just harder? If the majority of users are
happy with original design, consistence will be there. If not, we
may need to reconsider the design.
Owen Taylor has also agreed that there will be extensions
out there regardless of the project's wishes; he seems to feel that a
central web site might help to bring some order and
quality control to the situation:
An extension website *potentially* allows us to influence what
changes an extension can make by guidelines, requirements to be
listed as "featured", etc, though that's something we have to be
very careful about, because the whole idea of extensions is that
they allow people to try arbitrary things.
A certain amount of order and control will be wanted; among other things,
extensions are unconstrained code that can do anything the user is allowed
to do on the system. A way to collect useful extensions, review them, and
provide access to those known not to be malicious could make life a lot
easier for everybody involved. This model has worked fairly well for the
Firefox browser's extension mechanism; it could probably be made to work
for GNOME Shell too.
In the end, this is not an Apple-style walled garden; we're the free
software community, so chances are that the hackers will win out. We're
not accustomed to letting others tell us how the software on our systems
should work. That is doubly true when the system in question has an
extension mechanism built into it. If the GNOME project does not create a
mechanism by which extensions can be gathered, vetted, and distributed to
users, somebody else will. One way or another, GNOME Shell will evolve in
the directions its users want it to go.
Comments (230 posted)
In development since 2008, SIP Witch,
the call server developed by the GNU
Telephony project, made its stable 1.0 release in May. In conjunction with that milestone, GNU Telephony has also unveiled its next major project, GNU Free Call — a free, peer-to-peer routed voice calling network.
Thanks to the differences between SIP (Session
Initiation Protocol) and other communication protocols, it can be
confusing to explain exactly what SIP Witch does. SIP Witch is designed to
be a low-resource connection router, maintaining the actual network
location of active clients, and negotiating routes between clients whenever
a call is made. Because SIP addresses are URIs, a router like SIP Witch is
needed to map the URI to the actual endpoint where the user can receive a
call. Establishing the connection also involves tasks such as NAT
traversal. However, once the connection between the endpoints is set up,
the client applications communicate directly with one another. In that
respect, SIP is similar to XMPP (aka Jabber), where the "reachability" of the user is distinct from the call contents.
In contrast, full-blown call servers such as Asterisk or Bayonne handle the audio and video media streams between endpoints (including, potentially, transcoding between different formats), and run applications such as voicemail and various menu-driven interactive systems. SIP Witch can route calls to an Asterisk server, but also to standalone soft-phone applications, or to hardware devices like IP telephones or analog telephone adapters (ATAs). It can be used to manage SIP accounts provided by third-party service providers, to provide extensions within a LAN, or any combination of the two.
Ding-dong, the witch is calling
The 1.0 release does not add many features over the previous few
milestones. According to the changelogs, most of the work has been on
improving the build process, ensuring cross-platform compatibility, and
stabilizing IPC hooks for integration with desktop environments. Since SIP
Witch is a GNU
project, source code releases are available directly from the GNU
Project servers, but lead developer David Sugar has also made a special
effort to ensure that SIP Witch is well-integrated with both the Ubuntu
On a desktop system, SIP Witch can act as a proxy for local soft-phone
clients, alleviating the need to individually manage network address
translation (NAT), firewall traversal, and other settings. Although at the
moment running multiple SIP clients is probably not commonplace, it is easy
to imagine a few scenarios in which it would be useful. For example, since it is
up to the individual client to determine which media payload to use, a user might have a preferred open source client, but
also keep a back-up client installed in order to handle incoming calls
using older or proprietary codecs. SIP Witch does not care what codecs are
used between the call endpoints, since the media connection is made
directly between the clients.
A useful side effect of that feature is that SIP Witch is automatically
compatible with Phil Zimmermann's ZRTP end-to-end voice over IP
encryption scheme because the key exchange and encrypted data streams exist
outside of the SIP call set-up process. On the other hand, SIP Witch is
also compatible with applications that use SIP for instant messaging, but
because it does not handle the media payload, it does not queue or store
any SIP IMs that arrive when the application is not running.
Where SIP Witch gets more interesting is in its routing functionality. First, more than one endpoint "device" can register with SIP Witch under the same ID. Thus, SIP Witch can ring multiple hardware or software phones for any incoming connection request. Second, SIP Witch supports peer-to-peer routing. Multiple SIP Witch instances can be set up to redirect calls to each other, a technique that can be used to provide fail-over, or simply to connect two or more locations into a single SIP "realm" as if they were a single site.
GNU Free Call
This sense of "peer-to-peer" routing is rather limited, but the project has loftier goals in mind. Namely, Sugar plans to add peer-to-peer SIP URI discovery to the code in the future, so that SIP Witch servers can automatically collect and cache the addresses of reachable SIP call endpoints. At the moment, any SIP user can call any other SIP user (including those on remote networks), but only if he or she already has the other party's SIP URI. There is no built-in way in SIP to discover another person's (or business's) URI.
Adding that peer-to-peer discovery functionality to SIP Witch would be
straightforward from a technical perspective, but it very quickly escalates
into a human interface issue. Once SIP Witch can discover the URIs of
users on nearby nodes, the user must be pulled in to select the right John
Doe out of a potentially long list of possible matches. That, in turn,
means SIP Witch will need a GUI, and if SIP Witch has a GUI, new users are
likely to expect it to provide them with an account (just as the
proprietary alternative Skype does).
Consequently, GNU Telephony is not only planning to extend SIP Witch in the post-1.0 development cycle, but it is also launching a free calling network called GNU Free Call. In its official announcement, the project describes its goal as making GNU Free Call as ubiquitous and usable as Skype, including support on "all platforms" for use by the general public. In addition, it highlights goals of providing secure calls for both known and anonymous callers, but without requiring a central service provider, secret binary protocols, or network "control points" that could be exploited.
There is a basic roadmap sketched out in the announcement, starting with adding peer-to-peer discovery to SIP Witch as described earlier. The initial plan is to start by adding the caching of SIP URIs to the server, then to build a mechanism for publishing routes to connected peers — which is similar to the way peer-to-peer file-sharing services have operated. Sketches for the GUI front-end (based on the OLPC Sugar interface) are on the GNU Telephony wiki, with mock-ups that show local URI discovery, existing contacts, and tag-based searching.
Beyond the decentralized address-location problem, the other big
challenge presented in GNU Free Call is providing secure communications.
Although ZRTP is supported by a growing number of soft-phone clients (and
indeed there is a GNU Telephony implementation of it), it cannot be added
after the fact to most hardware devices, which leaves those users without a
secure option. The project plans on supporting these users by adding a
GnuPG public-key exchange step to SIP itself. That will allow security to
be handled during the call set-up phase (as handled by SIP Witch), by
establishing a secure SRTP
channel between the endpoints, and using the GPG keys to mutually verify
signed hashes of the session keys created.
Generally speaking, the project has frowned on security systems that rely on certificate authorities or public key infrastructure. This scheme has yet to be documented in detail, however it could be implemented with locally-generated key pairs. The traditional wisdom is that public key cryptography is too complicated for lay people to use, but perhaps the SIP use case will prove simpler to understand than has email encryption.
The bigger question is whether or not GNU Free Call can produce a system that is easily as usable as Skype. Several other free software projects have set the same grand goal over the years, but for the most part they relied on duplicating Skype's business model, but with a different network (based on SIP). Ekiga, WengoPhone/QuteCom, and the others all produced standalone SIP clients that were designed to connect to centralized SIP networks run by the provider (even though they could still call other SIP users).
At the very least, GNU Free Call is taking a markedly different approach. SIP Witch allows the user to choose any client application, and the wiki and archived conference presentations show strong ties to mobile devices (including the possibility of an oFono-based cellular back-end), as well as a desire to integrate with existing desktop services such as address books, D-Bus signaling, and notification frameworks. Automatic node-discovery and peer-to-peer routing may be associated with difficult-to-use file-sharing services in many users' minds, but those networks were centered around broad searches and multiple active connections. SIP Witch's interest in point-to-point communication may not share much in common with them at all. None of those factors guarantees its success, but the GNU Free Call team is certainly in it for the long term.
Furthermore, the small-and-light SIP Witch code base is much easier to manage than the heavier GUI soft-phone clients, and free from the headaches of media codec and transcoding support (the 1.0 release weighs in at just 480K, compared to 10MB for Ekiga). In addition to the GUI interface needed for searching or filtering discoverable URIs, SIP Witch will also need to build a more user-friendly configuration system. Right now, it uses XML configuration files which, although they are well documented, might be intimidating to inexperienced users. SIP comes with its own vocabulary, some of which is not immediately intuitive to those who do not deal in real-time network communications.
GNU Free Call is not scheduled to roll out its actual service until
"later this [northern hemisphere] summer." It will be an
interesting debut to watch. It is sure to garner support from
security-conscious free software types, but is aiming for a much wider audience.
Comments (2 posted)
Android handsets may get a lot of attention, but they are far from the only
Linux-based devices on the market. HP's webOS is also very much a
Linux-based system; it can be found on a handful of handsets and an
upcoming tablet product. The folks at HP were kind enough to send your
editor a Pre 2
handset to play with; what follows are some impressions from that
experience. In summary: the Pre 2 is an open device and webOS is an
interesting alternative, but webOS devices will have a hard
time pushing Android handsets aside.
The Pre 2 is a smallish device with a somewhat rounded shape. Your editor's
wife described it as "girlish," pointing out that it even has a mirror on
the back side of the slider. The phone slides vertically when it is held
in the portrait orientation, exposing a small QWERTY keyboard. Actually,
it must be said that the keyboard is very small; it is difficult for
your fat-fingered editor to use. Use of the keyboard is obligatory,
though; there is no on-screen keyboard provided with the device. Charging
is via a standard micro-USB port. One nice feature is a separate switch
for putting the phone into a silent mode; the switch, unlike the profiles
on many other handsets, is difficult to change accidentally.
The handset has an ARM OMAP processor with a mighty 300 bogomips of
performance; it has 512MB of main memory and 16GB of flash storage. The
screen is 320x480 - on the small side for contemporary devices, but the
Pre 2 is a small device. The unlocked GSM version of the device has,
in addition to the four standard GSM bands, support for 3G at both 850MHz
and 1900MHz. 850MHz support, of course, is nice for those of us using a
certain US-based carrier which, despite its size and appetite for competing
carriers, tends to be overlooked by unlocked Android devices.
The webOS interface takes some getting used to, but it has its good
points. The "home" screen is called the "card view"; it contains five
application icons at the bottom. Whenever a new application is run, it
is placed on the card view much like playing cards on a table. Each
application's "card" tracks the current state of its screen, so it is
possible to scroll through the card view and see what every running
application is up to.
WebOS makes heavy use of gestures for control, to the point that the device
wants first-time users to go through a tutorial (with tests at the end)
before doing much of anything else. There is no "back" button; that
functionality comes with a right-to-left swipe along the bottom of the
screen. An upward swipe from the bottom goes to the card view; a second
swipe pulls up the application menu. Running applications are stopped by
flinging their cards off the top of the display. It takes a bit of
practice to get used to the interface, but, before long, it feels quick and
Other aspects of the interface are a little harder to get used to. A
depth-first traversal of the Android settings menu will expose the user to
almost every option the device has; webOS, instead, tends to hide things.
A user wishing to turn off mobile data use, for example, will search for
vain in the system settings menus; one must, instead, pull up the dialer
application and hit the button in the upper left which contains the current
mobile carrier's name. The "location services" screen controls access to a
number of location-based options, but not whether GPS is enabled - that
option is under a separate "preferences" menu. There may be some
consistent philosophy behind the placement of these options but, to your
editor, it seems somewhat arbitrary and confusing.
In some ways, the interoperability of the device is quite nice; contacts
and calendar data, for example, can be obtained from a variety of sources
and integrated on the phone.
An Android user wanting to make the switch to webOS will find that much of
the information stored in the Google mothership is equally accessible. In
other places it falls down; it was not possible to test the email
application because LWN's self-signed IMAP server certificate was not
"trusted." Your editor, who created that certificate, trusts it just fine;
it should be possible to impress that trust upon a phone. There is an
involved series of steps said to force that trust; it would be much
easier if the application simply asked.
Naturally enough there is a market for add-on applications; there is a fair
amount of stuff there, but nowhere near as many applications as Android
offers. Android users may be surprised at the lack of permissions
questions; webOS seems to lack the set of privileges that Android
provides. There is exactly one exception: users will be warned
about applications which will request location data. It is also possible
to configure the phone to ask before providing location information to any
application, yielding an experience similar to that of configuring a web
browser to ask about every cookie. But any other sort of
access - network access, for example - seems to be entirely uncontrolled.
Various other little things seem to be missing. The camera hardware seems
reasonable, but the associated application is minimal. The music player
cannot play Ogg files. There's no indication when GPS or mobile data are
in use. The Pre 2 cannot simultaneously function as a phone and as a
USB storage device. The web browser lacks the semi-magic "format the page
for the screen" mode that works so well on Android. There is no word
completion or typo correction for keyboard input.
And so on. Fans of webOS say that the system is more tightly
integrated and consistent than Android, and that it handles multitasking in
a more natural way. All of these may be true. Had your editor come to
webOS directly from less-smart phones, he would certainly have been much
impressed. As it is, it is hard not to conclude that this platform needs
some work to become truly competitive in today's market.
Hackability and community
If one opens the phone while it is in the card view and types
"upupdowndownleftrightleftrightbastart" (a spelled out version of the
Code), the result is a new icon offering to put the phone into developer
mode. That turns out to be the key to what is a nicely open and hackable
device. There's little that will get in the way of anybody wanting to make
their Pre 2 do a number of interesting things.
The first step is to get and build novacom, a tool
which is the webOS analog to Android's adb. Plugging the phone to a
computer's USB port, putting it into developer mode, and running
novacom will yield a root shell on the device. From this point of
view, webOS looks like a straightforward Debian-derived distribution
(correction: it's actually based on OpenEmbedded); it is
much easier to move around in and inspect than Android's minimal shell. It
actually feels like Linux.
After that, there's a lot to be found on webos-internals.org,
starting with Preware,
a sort of alternative application repository. Through Preware, one can
install application tweaks, useful features, and more. Your editor started
with the "developer mode" button which took away the pain of typing the
Konami Code on the Pre 2 keyboard. There is an on-screen keyboard
(though, alas, it was not yet working with webOS 2.1.0) and a WiFi
tethering application which, unlike the official one, works regardless of
whether one's mobile carrier has blessed it. Some of what's in Preware
looks more useful than the rest, but, as a whole, it's a repository that
serious webOS users are likely to want to enable.
The device comes with a 2.6.24 kernel. HP has put up a nice page where
source for all of its open-source components can be found; they provide
original tarballs and the patches they have applied as separate files. The
webOS 2.1.0 kernel patch is a daunting 10MB monster which touches almost 1200
files and adds nearly 350,000 lines of code. Much of that code is
clearly post-2.6.24 backports, some of it is board support for the handset,
and some is drivers. There is also a custom cpufreq governor.
There are instructions for
building and installing kernels on the device, but it's not possible to
build the whole thing: webOS includes a small number of binary-only modules
for wireless networking, graphics, and more. As a result, there are a lot
of tweaked 2.6.24 kernels out there for webOS devices, but no current
The binary-only modules are unfortunate, even if the Pre 2 is far from unique
in requiring them. The same could be said of the mostly proprietary
application space. WebOS also has a development process which is even less
open than Android's; source for shipped code is thrown over the wall, but
there is no repository, no associated open source project, and no way for
others to even try to add changes. That makes the generation of a high
level of enthusiasm in the development community hard; that may explain why
there does not
appear to be an equivalent to CyanogenMod in the WebOS world.
That is a bit of a shame; the Pre 2 otherwise is a remarkably open
device; one can get into it and hack away without having to go through any
cumbersome rooting rituals. WebOS is a Linux-based handset (and, soon,
tablet) platform that actually looks like Linux; unlike MeeGo, it is
actually available on current handsets. It is an interesting platform
which, one hopes, will continue to survive. Given the strength of the
competition - Android has a much larger user base, more features, many more
handsets, and many more applications - one might think that webOS could use
all the help it can get. WebOS seems to have a crowd of dedicated users
and developers who would likely provide that help if HP would just let them.
Comments (64 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: UEFI and "secure boot"; New vulnerabilities in ConsoleKit, java, NetworkManager, sudo, ...
- Kernel: CMA reworked; Debating overlayfs; The videobuf2 API.
- Distributions: Fedora, systemd, and changes; dyne:bolic, Fedora, openSUSE, Tin Hat, ...
- Development: KDE Frameworks; Apache Traffic Server, Kontact, Upstart, ...
- Announcements: Android, patents, linux.conf.au domain, Stallman interview, ...