Leading items

GNOME Shell, extensions, and control

It has now been three months since your editor posted his experience with GNOME 3 and 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 desktop software?

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 set up 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 more.

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, who does marketing work for the GNOME Foundation under contract, a former GNOME marketing contractor, responded:

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 impaired:

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 regardless:

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:

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)

GNU Telephony releases SIP Witch 1.0 and announces Free Call

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 and Fedora distributions.

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 future

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)

WebOS: the other Linux-based mobile platform

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 natural.

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 famous Konami 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 kernels.

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
Next page: Security>>