Leading items

LCA: The future of the Linux desktop

Bdale Garbee has become a rather well-known presence at linux.conf.au, having attended and spoken at every instance of the conference since 2002. Until his retirement in 2012, he was also the public face of long-time sponsor of the conference, Hewlett-Packard (HP). His keynote speech on the opening day of linux.conf.au 2013 was entitled "The Future of the Linux Desktop". However, given the various interests and projects that he has championed and spoken about during his long involvement with the conference, he also took some time to update the audience on some of those projects.

Bdale, FOSS, LCA, and rockets

Bdale noted that his first personal contribution to what is now called called open source was in 1979. "My suspicion is that a few of you in the audience weren't alive then." The first LCA that he had the "privilege" to attend was in 2002, when was invited to participate in the Debian miniconference. He noted that attending LCA that year had a significant impact on his life thereafter. At the conference, he was encouraged to run once more for the role of Debian Project Leader (DPL), and was this time successful, which had a ripple effect in many other areas of his life.

Thus, for example, as DPL, Bdale was invited to be a keynote speaker at LCA 2003. He was invited to be a keynote speaker again at LCA 2004, and in the same year his employer became a sponsor of the conference. After that, he noted that there was a shift in the content of his talks at LCA. "I had achieved a standing in the company that let me do things like flying at company expense to Australia to talk about my hobbies."

As many people know, one of those hobbies is rockets. "On my last official day of employment at HP, I was in Kansas at a rocket launch". As well as launching his own rockets at great speeds and to great heights, Bdale has also been involved in the creation of the Tripoli Mentoring Program, which allows children as young as twelve to become involved in rocketry. Bdale and Keith Packard have also turned their rocketry hobby into a successful 100% open source small business, Altus Metrum, selling rocketry components.

Bdale remains involved with the FreedomBox project, the subject of one of his talks at LCA 2012. He noted that work on the project was taking longer than hoped, but was moving forward. He leaves LCA on Friday to go straight to FOSDEM in Brussels, where he will present the current state of FreedomBox with Eben Moglen.

How do we define the Linux desktop?

Bdale began his discussion of the Linux desktop with the observation that the metaphor of a desktop is somewhat stale. In most parts of the world, there has been a dramatic transition away from computers as things that sit on desks. A question that follows from that observation is: "When we talk about the 'desktop', are we really just talking about the user interface of the device in front of us?"

Bdale's answer to that question is "no". His fridge and TV may be running Linux, but he does not want a desktop interface for them. Rather, what he sees as the desktop is the interface that is provided by a universal computing device—one that lets him read mail, browse the web, design rocket components, design objects for 3D printing, give presentations, do accounts, develop software, run simulations, and so on.

Will Linux ever displace Windows?

Bdale is frequently asked "when will HP start shipping Linux on desktop systems?". His answer is "a whole bunch of years ago", since HP has for several years been shipping computers running Linux to many parts of the world. However, he acknowledged that the user interface that most people get when they buy their universal computing device is likely to be Microsoft Windows, especially in the developed world.

In "green field deployments", there have been many cases where Linux desktops have been successfully rolled out. Here, Bdale noted a few of the more well-known deployments, such as the deployment of Linux on around 80,000 desktops in the Extremadura school system, and deployments in the city of Munich and the French parliament. But, he noted, if you have an existing body of users who have been using Microsoft Windows, then the cost of change can be pretty high. Reeducating users onto a new computing environment can be a major task.

There are strong disincentives for OEMs such as HP to move away from Windows. People used to ask Bdale whether HP might not save a lot of money on license fees if they moved away from Windows, and instead preinstalled Linux on the machines they sold. He used to ask the same question himself, until he had the experience of spending six months working with HP's netbook and notebook division in 2009 with the goal of helping them develop an open source strategy. He made the mistake of trying to explain to the senior vice president (SVP) with whom he worked that Linux could save the division a lot of money.

However, the SVP explained "You don't understand. This doesn't cost us money. The preinstalled software on a PC is a substantial source of revenue." All of the preinstalled software that is present on new Windows machines is there because two things happen once an OEM starts shipping millions of PCs. First, the OEM starts paying much lower license fees for Windows. Second, the OEM becomes in effect a major software distribution channel. Software producers and providers of network services want, and will pay for, the opportunity to appear in front of millions of users. Thus, the ecosystem of preinstalled Windows-based software subsidizes the cost of a PC; replacing that with Linux would actually increase the price of the system.

In Bdale's opinion, it's difficult to displace Windows as the operating system that is preinstalled on new PCs. Either one has to abandon that idea, or come up with a user experience that is sufficiently compelling that users prefer your system. We've already seen this happening in the mobile device space, he said.

Displacing Windows is also difficult because of the joint-marketing opportunities that companies sometimes engage in. Bdale mentioned the example of the Media Vault, a small personal network-attached storage device that runs Linux and Samba. Microsoft approached HP proposing to build a similar higher-specification device based on Windows. Over time, the two companies invested significant amounts of money in developing and marketing the new device, to the point where it ultimately displaced the earlier free-software-based device from the market. Given the amount of money that companies are prepared to invest in order to create successful products, a result such as this is a natural outcome; it is difficult for individual developers to compete with these sorts of perfectly legitimate company behaviors.

Bdale noted that similar challenges apply when it comes to considering whether Linux could displace Apple. In addition, there are other challenges as well, such as the extent to which Apple's devices and walled gardens "captivate" users.

A few rants regarding the Linux desktop

Bdale then noted that there would be "a few rants that I'd be remiss in not mentioning". One of those rants springs from observing how successful Linux has become (in the form of Android) in the mobile market. One of his frustrations in this area is the amount of energy that has gone into open source mobile projects that didn't succeed. Furthermore, environments like Android use a lot of open source software and employ many developers to work on open source technologies, but the resulting products and ecosystems are not very open.

There is technical work being done in the mobile space (for example, work on the kernel) that is certainly proving useful to the universal Linux desktop, Bdale said. On the other hand, can one user interface really span all sorts of devices? The idea is appealing. But the problem with user interfaces is that the capabilities of devices vary so widely, with a wide range of screen sizes and input models that range from keyboard-centric to touch-centric. These differences have a big impact on the model of how a user interface should work.

"I thought the whole idea of personal computers with free software was to really empower people". Our licensing structures are designed to allow any user to also become a developer. Nevertheless, it's perfectly okay to want to expand the user base of our software to welcome people who don't consider themselves programmers. But the problem is that some desktop projects seem to have become confused about who their target audience is. "The problem is that so much of the work that has gone into some of those projects has left me—and a lot of users like me—feeling abandoned by Linux desktop developers." Any time you think you're designing something for someone else, and not something you want to use yourself, then you are on a slippery slope.

Bdale said that he had had some horrifying experiences over the years with desktop developers who were clearly not eating their own dog food. By way of example, he noted that in conversation with some Evolution developers at GUADEC some years ago, he found that not one of the developers would admit to using Evolution to read their own mail. "They laughed at me for using it to try and read my mail." In this case, one of the fundamental tenets of free software was being cast aside: the developers were not scratching their own itches.

What really matters on the desktop?

Recently, Debian changed its default desktop for the Wheezy release. The problem was that GNOME became so large that it could not fit with the rest of the Debian system on a single installation CD. As a consequence, Joey Hess, one of the Debian maintainers made an arbitrary decision in August 2012 to change the default desktop environment to the smaller Xfce desktop system, which allowed the Debian install system to fit on a single CD. [Note: As commenters (and Bdale) have pointed out, the Xfce switch was never uploaded, so the report is "accurate", but the speaker misspoke. ]

Bdale noted that the decision to change Debian's default desktop generated relatively little heat. One reason for this is likely because the user can change the desktop after installation. But, in his view, there is also another reason: most people care more about applications than desktops. The desktop doesn't matter until it gets in the way. Bdale's key point here was that users are happy as long as they can run any application on any desktop that they choose. Conversely, applications that tie in certain desktop dependencies are a source of frustration for users, who don't want to be forced to include software components they didn't choose.

Another point that really matters to users is inefficiency. When users get a faster computer, they expect their applications to run faster, although this often doesn't turn out to be true in practice. Users also really care about efficiency because of battery life. Bdale's point was that a lot of the things that people get excited about in the desktop world aren't that exciting to him. For example, he is not so interested in compositing and other "bling" graphics features that tend to be expensive in terms of CPU load and energy consumption.

Customization is another thing that really matters to users. For example, when Bdale's then small daughter first encountered Star Office, she wanted to know how to do things such as changing the font type and size. This sort of customization is, he said, part of the process of taking ownership of technology.

The ability to automate repetitive tasks is also important. Scripts are many people's first step toward programming. Providing graphical interfaces to allow common tasks to be quickly executed is fine, but don't hide access to text interfaces that may be useful for scripting repetitive tasks.

The final aspect of the desktop interface that Bdale noted as being important is hackability. The interface should be something that the user can work on and improve. We should be thinking of building a world where the people using our systems want to learn our systems; we have nothing to win by competing with people who are intent on creating appliances that don't require any understanding by the user. "This is why I hope we'll refocus on building things that we really like to use. "

Being able to understand and fix the software we use is important. Bdale ultimately gave up trying to build the Evolution mail client because the build environment was just too complex. That sort of complexity prevents casual contributions to a project, because the effort of trying to understand the system is too great. Bdale noted the Linux kernel as an example of a project that has done a better job of managing complexity in the build environment. He also referred to the statistics on Linux kernel contributions that show a long tail of contributors who make just a single improvement to the kernel during each release cycle. Those long-tail contributions occur because users feel able to master the tools that are needed in order to make a contribution.

What does it all mean?

Bdale finished up with a few summary points. First, it's great to feel good about the success of Linux in the mobile space, in the form of Android. Second, we need to pick realistic goals when developing desktop software for Linux. There are some powerful market forces that make it difficult to unseat Windows on the PC. Instead, we should put all of our time and energy into building the systems that we want to use. Our collaborative model is "awesomely powerful" and allows us to make huge changes in the world. The key to success is that when we choose to differentiate, we should do so in interoperable ways. Finally, we should always empower users to contribute, so that we get the long-tail contribution effect.

Comments (39 posted)

LCA: Various topics from the mobile miniconf

The Serval project accounted for a number of separate talks at linux.conf.au 2013, but it was not the only project focused on free software in mobile computing. Among the others making a showing were OpenPhoenux, which is an ongoing effort to build and support new motherboards for the venerable OpenMoko Freerunner phone, and Mozilla's Firefox OS, whose team had demonstration hardware in tow. But there were also several talks that dealt with that most mainstream of mobile Linux platforms, Android, although in offbeat ways—such as deploying cutting-edge digital radio modes like codec2 on commodity mobile handsets.

OpenPhoenux

Often, new mobile platform projects (such as Jolla with Sailfish OS) spend a considerable amount of time searching for hardware partners interested in building devices, but the Open Pheonux project does just the opposite. It is plowing straight ahead at making its own phone motherboards, with interested hackers committing to pre-orders of small batches. The result of this approach is a more expensive per-unit price, but the hardware reaches the community quickly. Neil Brown presented a session explaining the goals of Open Phoenux and its current status, with hints at what may be coming in the next few months.

In its day, the Openmoko Freerunner was an exceptional device; the hardware was open in addition to the software. But the last motherboards produced by Openmoko were made in 2009; enthusiasts have subsequently been forced to look for old stock on eBay or other second-hand markets—and even when found, the 2009-era hardware shows its age. OpenPhoenux offers a brand new motherboard that fits into the same case as the original Freerunner, but sports a faster CPU (a 1GHz ARM Cortex-A8), more RAM (512MB), a 3G-capable modem, and an assortment of new or updated sensors (GPS, FM transceiver, accelerometer, compass, gyroscope, and altimeter). In addition, the various sensors and components have shrunk enough in size since 2009 that there is even more room today, so the new motherboard can overcome limitations in the original Freerunner design, like the lack of stereo speakers.

The OpenPhoenux motherboard is called the GTA04, and it is currently in revision 4 (denoted as GTA04A4). Brown said there are about 300 of the motherboards in the wild, and users are running a variety of software environments on them (including the Replicant Android distribution, QtMoko, and a derivative of the original GTK+-based Openmoko software), with several users using the GTA04 as their primary phone. Brown devotes most of his time to making sure that the mainline Linux kernel runs on the GTA04, which he described as a work in progress. There are a number of missing drivers at the moment, including the FM transceiver and the altimeter, and there are other sensors which are simply tricky to figure out how to support. For example, he said, what is an accelerometer? In some senses, it is used as an input device, responding to the user's movement, but at the same time, in produces a constant stream of sensor data whether the user is actively using it or not. As a result, there are two interfaces that need to be supported: that of a standard input device, and that of an Industrial IO (IIO) device. The kernel's IIO subsystem has recently moved out of staging and into main, he said, but it is still overly complex and not great to work with.

Keeping the kernel running is a constant challenge, Brown said, as there are always new bugs and old bugs reintroduced. He outlined a dozen or so from the period between kernel 3.5 to 3.7, such as CPU checks that incorrectly assume that cpu_is_omap34xx and cpu_is_omap3630 are mutually exclusive conditions—which they are not, as the GTA04 proves. There is also an ongoing struggle to minimize power consumption on the device, which Brown described as a nebulous challenge that touches many areas of the system at once and can be hard to track down. "If I see a green tinge on the screen, at least I know it is a problem with the video subsystem", he said. Still, it is a fun exercise, he said, and one that he learns from constantly. The next revision of the GTA04 boards (GTA04A5) is tentatively scheduled for March, if enough preorders are made by that time. The exact price depends on the number of orders, but is around the $500 range—there are plenty of cheaper alternatives, he cautioned: the OpenPhoenux's primary selling point is its complete openness. For now, that openness extends beyond the motherboard: users have recently started making their own alternative cases with 3d printers. In the future, some project members are looking for ways to add hardware keyboards, or to put the GTA04 into a tablet form factor with a bigger screen and battery.

Firefox OS and Android

On the subject of soon-to-be-available phone hardware, Mozilla developer Ben Kero presented a demonstration of Firefox OS running on the recently-announced developer phones at the mobile FOSS miniconf on Monday. Users have been able to run Firefox OS in a simulated environment through an add-on for quite some time, but seeing it running on actual devices is far more compelling. The developer phones are modest compared to a cutting edge Android device (the model on hand was the lower-end of the two, with a 1GHz processor), but thanks to the demo it is clear to see that Firefox OS is fast and responsive on them.

The developer phones are slated to be sold through Geekphone, a company that specializes in unlocked, hackable phone hardware, but two models is still not much of a selection. Several people in the audience expressed interest in what other hardware devices Firefox OS would be capable of running on. The good news is that Mozilla evidently tracks the official builds of the CyanogenMod project, and the Firefox OS build system automatically builds images for any device supported by CyanogenMod 9 or later. Firefox OS uses the kernel and hardware adaptation from CyanogenMod, Kero said, "we just tore out the Java". Perhaps predictably, a round of applause from the audience followed that comment.

Which is not to say that Android was a punching bag at the mobile computing talks at LCA 2013; there were in fact several talks that focused on Android specifically. But by and large, Android was seen as the commodity test platform on which other, more interesting work was based. Project Grimlock, for example, is a port of the Rhino JavaScript implementation to Android's Dalvik. Grimlock developer Maksim Lin also presented a session on modifying Android to run as an appliance-like operating system, like one might find in a kiosk or digital sign: a single application, presenting a stripped down interface to the user. As it turns out, running a kiosk-like appliance is relatively straightforward, once one knows where to look for the undocumented privileged APIs that Google apps routinely take advantage of. Lin said that many of the API calls are visible when reading through Android source, but that there are directives in the documentation that hide them whenever the documentation is rendered to HTML for display on a public web site. It was a thought-provoking talk that might make one seriously consider reading the Android source for the first time.

Codec2 and digital voice radio

Pushing boundaries was a common theme outside of the mobile FOSS miniconf as well. David Rowe presented his recent work on an extremely low-bitrate speech codec called codec2 which he has been developing for digital radio in the amateur-licensed HF and VHF bands. Codec2 can encode intelligible human speech in 1400 bits per second, which is a fraction of the bitrate required by analog voice modes in amateur radio. More importantly, it is significantly lower than the 2400 bits per second needed by comparable proprietary codecs. Digital voice modes in radio are a hot topic at the moment, and Rowe cautioned that if proprietary offerings were allowed to be blessed into standards, they would lock out open source, potentially for several decades to come.

The good news is that Rowe's work on codec2 does appear to be gaining traction with ham radio enthusiasts—and that, he said, bodes well for its future, because ham radio groups are influential with police, medical, and emergency services when the latter look to establish standards. At the moment, codec2 is usable immediately with Rowe's FreeDV, a cross-platform GUI application. Rowe demonstrated FreeDV and compared samples encoded with codec2 to other options. The FreeDV GUI is primarily used on Windows, he said, because most ham radio users are Windows-based, "but we are converting them over."

A ham radio codec might sound out of place at first, considering that ham radio is generally associated with hardware transceivers and fixed stations, but therein lies the secret. Following Rowe's talk was a demonstration by Joel Stanley, who showed codec2 running with software defined radio (SDR) on an Android handset. The combination of SDR and today's more powerful digital signal processors have the potential to blur the lines significantly between previously-distinct classes of communication, he said.

Stanley's demo was decidedly "homebrew" in appearance, but much of that stems from limits imposed by trying to create a device-vendor-neutral solution. He would have preferred to build a dongle that could plug directly into an Android phone's microphone port and receive HF radio, but that proved impossible because of the incompatible pinouts used by different phone makers. Instead, Stanley hooked the Android phone into a USB soundcard, but it did indeed serve as a working codec2 receiver. As was the case with the Serval project talks earlier in the event, it is intriguing to see free software used to redefine something so widespread (and taken for granted) as a mobile phone. It is a refreshing reminder that although Linux, through Android, has made enormous waves in the mobile industry, those waves do not stop at the edge of the app store.

Comments (7 posted)

LCA: Serval at the mobile miniconf

Linux on mobile devices is a perpetually hot topic, but the discussion typically centers around Android, webOS, MeeGo, and other commercially backed operating system projects. The Mobile FOSS miniconf at linux.conf.au 2013 offered a decidedly different program, highlighting projects that pushed mobile computing in directions of little interest to phone carriers, such as the Serval project, which focuses on freeing mobile phones from the cellular infrastructure altogether.

Miniconfs are one-day tracks organized by volunteers, separate from the main event schedule. The first two days of LCA featured thirteen miniconfs, with topics ranging from security to open government. Monday's Mobile FOSS miniconf featured eleven talks, although the schedule was dominated—in a friendly way—by a series of interconnected Serval sessions. The project builds a free software mesh networking framework for mobile and embedded devices. These devices can operate over the mesh network without cellular connections, instead using WiFi, or (potentially) any other radio layer. One of the sessions dealt with the project's interest in building specialty phone hardware to use other radio frequency bands, but most of the talks described how Serval runs on current Android devices today.

Haiti and the origin of Serval

Paul Gardner-Stephen of Flinders University explained that the Serval Project had its origin in the 2010 Haiti earthquake, in the wake of which humanitarian relief organizations faced unprecedented logistical challenges—starting with the unavailability of airports, highways, and harbors to even get physical access to the disaster site. Gardner-Stephen likened the telecommunications challenge to that physical access challenge, noting that without the cellular telecom infrastructure, even high-end smartphones were unusable—in spite of the fact that the devices are physically capable of communicating directly to each other. Software, he said, is all that prevents smartphones from offering even the short-range connections offered by cheap walkie-talkies for children. Serval is his attempt to overcome that limitation.

The Serval framework runs on top of Linux; at this time primarily on Android devices, though the project has used routers as well (such as the Mesh Potato) to provide access points or uplinks to the Internet. In theory, phones should be able to connect to one another directly in ad hoc WiFi mode, but the reality is that ad hoc support has long been buggy [Note: this link is broken currently] in Android (and has been disabled in recent versions), and ad hoc mode interoperability between phone vendors is poor enough to be unusable. Consequently, some devices must be run in access point mode, while the others connect to them in client mode. Still, Gardner-Stephen noted, in field trials the project has been able to get phone-to-phone connections working over several hundred meters, which is significantly more range than one sees in an urban environment polluted by microwave oven interference (and by hundreds of conference attendees simultaneously browsing the web).

Design

The Serval software consists of two layers, the servald daemon and the applications that utilize it. The project had freshly-updated Android packages available for installation during the sessions (delivered from one of the speakers' own phones running in access point mode). The main Serval package installed both the servald daemon and Serval BatPhone, an application that provides voice calling, text messaging, and file sharing over the mesh. A second package installed a mapping application intended to let teams keep track of individuals' locations in the field.

The servald layer implements device identification and discovery through a module named Distributed Numbering Architecture (DNA). Voice calls, since they require stricter latency than other applications, are handled by a special module called VoMP. All other services are implemented on top of Rhizome, a file distribution module described as USENET-like because it opportunistically stores-and-forwards every uploaded file to all clients on the mesh. Rhizome can be used to propagate static files to all clients. For example, field workers can take geotagged photos while on survey trips; the photos are automatically propagated to other team members. This protects against data loss, and it rapidly disseminates information about points of interest or concern. But Rhizome can also be used as a "datagram"-like protocol layer on which other applications are built. Serval's text message analogue "MeshMS" is implemented on top of Rhizome in just such a fashion.

Given the humanitarian relief scenarios that first prompted Serval, it should come as no surprise that the network was designed to provide users with security—disasters can put relief workers at risk of harm from criminals or militants in addition to natural dangers. At first run, each Serval client generates a 256-bit Elliptic Curve public-private key pair. The public key is used as the client node's Serval ID (SID); consequently any client that knows the SID of the node it wishes to exchange messages with already has enough information to encrypt and/or cryptographically sign that message.

Various applications are implemented on top of these core services, including the aforementioned BatPhone and Serval Maps. For the phone functions, users select their own "phone number" which is propagated to other clients over the mesh. The phone number is simply easier for users to dial than the SID public key itself, but VoMP and MeshMS are encrypted. The project described some other applications that they have implemented in field tests with humanitarian relief organizations, such as filing structured forms.

In the field

Gardner-Stephen described one of the Serval project's field tests in detail; the project worked with the New Zealand Red Cross (NZRC) on training exercises that placed NZRC teams in realistic disaster relief scenarios. From the exercises, he said, the Serval project learned practical lessons like the need to reduce the amount of chatter that clients produce synchronizing with each other when there are many nodes in close proximity. As he put it, Serval nodes are like ducks: they don't quack much on their own, but when you get a roomful of them together they won't shut up. The project also learned a number of details about real-world relief work that are not directly software driven, like the fact that NZRC has little interest in voice communications, but being able to exchange short data messages is vital.

The NZRC field tests allowed Serval developers to work with Iridium satellite networking equipment as a backbone; in other instances they have worked with OpenBTS to create a micro-cellular network. But Gardner-Stephen said the project was also exploring the possibility of building low-cost cellular phones with an Arduino-like microcontroller "backpack" that could be filled with swappable radio modules. WiFi in open-field conditions has far greater range than it does in crowded cities (or conferences), but unlicensed spectrum like the ISM 900MHz band offers the potential for greater range at lower power consumption. Since the same bands are not available in every region, of course, making the radio modules pluggable is seen as a critical feature.

At several points during the day, the question arose as to why the project had invented its own protocol rather than using an existing one, such as the mesh networking deployed by the One Laptop Per Child (OLPC) project. The project's members indeed had rationales for each case, although most of them boiled down to the same issue: making a decentralized system that could work without any infrastructure. The OLPC mesh network, for example, is based on 802.11s, but that standard is used to build a mesh extension that branches out from a fixed base station: without the base, the clients cannot communicate among themselves. Similarly, early experiments with voice calling revealed that the common SIP protocol found in most VoIP clients was unsuitable for stand-alone mesh calling because it ultimately relies on the certificate authority infrastructure of TLS.

The Serval project has built some impressive mesh networking technologies, although it still has plenty of challenges ahead. The hardware support issue is chief among them; the speakers observed that WiFi antennas in most Android phones are low-priority because phone-to-phone networking is not important to the device-maker. The cellular antenna is positioned to work well, but the assumption is that the WiFi antenna can be tucked in anyplace, since checking email and browsing the web is less critical than making a voice call. Whether Serval will overcome that hurdle by making its own hardware remains to be seen, but it does demonstrate that cellular voice calls are not always the most useful task a phone can perform. That is a notion many smartphone users would likely agree with, but Serval shows that humanitarian work, and entirely new networking topologies, are among the features.

Comments (none posted)