LWN.net Weekly Edition for January 9, 2014

Emacs moving to Git

Back in 2008, the Emacs project was looking to move away from CVS and onto a new version control system. At that time, the three main distributed version control system (DVCS) choices, Git, Mercurial, and Bazaar, seemed roughly equivalent, so Richard Stallman chose Bazaar because it was a GNU project. That choice was always controversial, but Stallman has been steadfast in his support for Bazaar—until now.

The topic of switching has come up a number of times in the intervening years, but a decision was always deferred, usually because Stallman was unconvinced that Bazaar (aka bzr) was a demonstrably worse choice than the others. But his opinion seems to have changed. In response to a recent call for a switch to Git from Eric S. Raymond, Stallman indicated a different view:

The last time the subject of switching to Git came up was in March 2013, when John Wiegley broached the subject. He mentioned major Bazaar bugs that had remained unfixed for years, some of which affected Emacs directly. That problem is "significant enough that I think it justifies us switching over to Git all by itself". He addressed his argument to Stallman, who replied that he had contacted the maintainer about a specific bug (also reported here) and was hopeful that a solution would be found soon.

The problem was eventually solved in Bazaar 2.6, which was released in July 2013. But it had originally been reported in 2011 and evidently required a poke from Stallman to get it fixed—not good indicators of a lively project. In addition, as Karl Fogel pointed out, the 2.6 release process got stuck between a beta that was released in July 2012 and a planned full 2.6 release in August of that year. It was still languishing in that state in March 2013, without any news or updates to the status or plans, Fogel said. His internal "project health meter [...] is hovering down near the low end of the dial". The release delay is particularly worrisome:

At that time, Stallman was still hopeful that the bugs could get fixed and, furthermore, that it would be shown that Bazaar was being maintained. Several in the thread were convinced that even if the bugs got fixed at Stallman's behest, it would not indicate that the project was actively maintained. But, Stallman was adamant that the Bazaar maintainers be given some time:

In the intervening ten months or so, Stallman has evidently come around to recognize that the Bazaar project is, sadly, not keeping up with the maintenance that the code requires. His declaration in response to Raymond set off an immediate call by Fogel to move to Git "now that RMS [Stallman] has dropped the bzr requirement" though Fogel did recognize that there might be other DVCS preferences.

Raymond's original message offered a few reasons for moving away from Bazaar, for example "escaping the gravitational pull of bzr's failure" and making Emacs development friendlier for new hackers who wouldn't have to learn a different DVCS than they are used to. He also is in the Git camp, albeit reluctantly:

As part of the message, Raymond offered to help with any technical hurdles in converting from Bazaar to Git, but it turns out that is not really needed. Andreas Schwab maintains a Git mirror of the Emacs Bazaar repository that has already handled the cleanups and other problems that Raymond expected to find in the conversion process. So it would seem that migrating is largely a matter of switching to using Git and pointing it at the existing repository—at least from a technical perspective.

The only voice in support of staying with Bazaar was provided by Eli Zaretskii. In a sub-thread, he outlined his reasons for liking Bazaar and, perhaps more importantly, for disliking Git. Other than Zaretskii, though, little support for staying with Bazaar was heard. Some said they liked Bazaar far better than Git, but would be concerned if Emacs were to stick with an unmaintained VCS.

There is another alternative, though, of course: Mercurial (aka hg). Jordi Gutiérrez Hermoso raised that possibility. Part of his reasoning is that Mercurial is more aligned with the GNU project philosophically—its GPLv2+ license is more in line with GNU aims than Git's GPLv2-only license, for example. It is, he said, not really a technical argument, but rather a social one.

Several felt like they had heard some of that before: back in 2008 when the switch to Bazaar was made. While support for Mercurial seems a bit higher than that for Bazaar, and Mercurial is much more actively maintained, it suffers from one of the same problems as Bazaar: it isn't Git. Like it or not—and many of the biggest proponents of moving to Git did not like it—Git has a larger mindshare, bigger developer community, and is more popular than Mercurial. Git reasonably fills the hole, even if it is not the best social match. As David Kastrup put it:

The best social match was Bazaar when it was chosen and folks are leery of making that mistake again. Stephen J. Turnbull, who maintains XEmacs (which uses Mercurial), described at length why he thinks Git is right choice of Emacs:

Fogel also piled on with a handful of bullet points that explained Git's superiority—without really knocking Mercurial. So a switch to Git for Emacs would seem to be coming, even though that choice seems somewhat reluctantly made. How soon Emacs will switch is up in the air; Raymond's call for an immediate switch has been rebuffed by maintainer Stefan Monnier. There may not be a huge amount to do, but there are steps that need to be taken before a switch can be made. In particular, the 24.4 release should be completed before switching to Git, Monnier (and others) said.

Switching to a new VCS should clearly not be taken lightly. The Emacs project didn't, either now or in 2008, but there were, perhaps, additional considerations that were not looked at when the switch to Bazaar was made. It might have been difficult to predict the fate of the Bazaar project back then but, given where things are today, that fate will make Bazaar an unlikely choice for any new projects. Unfortunately, Mercurial may also be something of a casualty of Git's success (and popularity). One hopes not, as there should be room for more than one open-source DVCS.

Comments (32 posted)

Firefox OS fanning out from phones

Mozilla unveiled the first Firefox OS phones less than one year ago, but already the browser-maker is branching out into other classes of device. In a series of blog posts the first week of January, Mozilla announced that the lightweight, Web-centric platform would soon be available on smart TVs, tablets, and desktops, as well as on higher-powered smartphone hardware, and that the organization would be starting a developer program intended to accelerate development of the OS.

The first blog post was from Jay Sullivan, Mozilla's chief operating officer (COO), on January 6. He noted first that at the end of 2013, three different Firefox OS phone models were available in fourteen separate markets. Those numbers, he said, exceeded Mozilla's expectations. But, he continued, while Mozilla itself will continue to focus its Firefox OS efforts on "developing markets"—where supporting lower-end phone hardware has the biggest impact—hardware vendors have expressed interest in deploying it elsewhere. The first such example is phone vendor ZTE (who released the Firefox OS developer phones in 2013); Sullivan said to expect the announcement of higher-end Firefox OS phones within the week.

Targeting a high-end device is indeed a deviation from Firefox OS's initial plan, which sought to pair up the lower overhead of a minimal OS running only Web applications with less expensive hardware. But an even bigger departure is Panasonic's announcement that it would be using Firefox OS for a line of smart TVs.

Panasonic's press release is (as is typical) short on details, but says that "basic functions, such as menus and EPGs (Electronic Program Guide) which are currently written as embedded programs, will be written in HTML5, making it possible for developers to easily create applications for smartphones or tablets to remotely access and operate the TV." The press release also says that Panasonic is partnering with Mozilla to develop the products, which is undoubtedly good news to those who are wary of Mozilla's historic dependence on Google's search-engine placement fee as the organization's only significant source of revenue.

The second blog post addressing Firefox OS's next steps appeared (without a byline) on the official Mozilla Blog, shortly after Sullivan's. It repeats the information about Panasonic's smart TV plan and ZTE's higher-end phones, adding the detail that the new ZTE phones will include "dual core options like the Open C and Open II" (which are reputed to be ZTE product names).

Perhaps more interestingly, the post also announces that Mozilla is working with motherboard manufacturer VIA on a "nettop"-style desktop device powered by Firefox OS. The device in question comes from VIA's "APC" line, which initially marketed a $49 motherboard designed to run Android on the desktop. The new revision includes a bit more branding—a newer motherboard called the APC Rock is available based on the ARM Cortex-A9 processor, as is the APC Paper, which includes the same motherboard inside a diminutive case that looks like a hardbound book (down to the book-like cardboard cover). No word, so far, on anything called Scissors. VIA's own press release about the product includes a link to the source code for the Firefox OS image shipped on the Paper and Rock, hosted at GitHub, and notes that developers who fix known issues (tagged with the "Free APC" label in the GitHub repository's issue list) will be rewarded with a free device.

The final nugget of Firefox OS expansion news is Mozilla's own contributor program, which was outlined on the Mozilla Hacks blog. The program is aimed at adapting Firefox OS for the tablet form factor. The initial tablets (which will be seeded to accepted developers) will be 10-inch devices built by Foxconn. Sign up is not yet open for the program, but will be announced later on Mozilla Hacks. Notably, the post specifies that not just core Firefox OS contributors, but other participants including localization and translation contributors and bug fixers, will all be accepted.

Foxes, foxes everywhere

Expanding to tablets, TVs, and desktops all at once certainly sounds like rapid growth, perhaps even to the point where one might worry that the Firefox OS team could be spreading itself a bit too thin if it is not careful. On the other hand, some of these form factors are arguably a more natural fit for the Firefox OS model—where all applications are implemented in HTML5 and the rest of the operating system is bare bones—than they are for a full-fledged, traditional distribution.

Take smart TVs, for instance: despite the name "smart," the vast majority of the apps and services that run on current smart TV products are pretty minimal, concerned as they are with pushing content one way from a service provider directly to the screen. Rendering a video stream is usually handled by dedicated hardware, most apps do little but perform authentication and provide a content-selection UI, and generally only one app is run at a time—all factors that argue in favor of a lightweight OS. The South Korean electronics manufacturer LG, for one, licensed webOS (which is similarly low on resource consumption and tailored for HTML5 apps) from HP in February 2013, and has been shipping webOS smart TVs since. Tablets are much more similar to phones of course, but there, too, there is proven demand for less-interactive apps. As much as developers may (rightly) bemoan the consumption-only model that Apple has pushed with the iPad, there is little doubt that most consumer tablets are used primarily for accessing web services, read-only apps, and other CPU-un-intensive tasks.

VIA's Rock and Paper are certainly an oddity—even more so when one considers the cardboard case—but that does not mean that they will be unsuccessful. When Firefox OS was first announced, a lot of commentators dismissed it as untenable, particularly when compared to the smartphone juggernauts of iOS and Android. But the project has survived, is shipping, and even seems to be growing. That is good news for fans of web technology, as well as for fans of Mozilla, since success with Firefox OS will presumably enable the project to undertake still more work in the months and years to come.

Comments (5 posted)

Deciphering Google's automotive Android plan

On January 6, "press day" at the Consumer Electronics Show (CES) in Las Vegas, Google announced the Open Auto Alliance (OAA), a new consortium of companies with the mission of improving Android for use in cars. That makes OAA the third industry coalition focused around getting Linux into automobiles (after the GENIVI Alliance and Automotive Grade Linux), which complicates the picture somewhat for fans of free software—particularly since there are several companies that participate in more than one group.

A fork in the road

The official Android blog carried the initial announcement, which points readers to the OAA site, where a lengthier press release can be found. The announcement of an Android-in-cars effort had been anticipated for several weeks; in December The Wall Street Journal predicted a partnership with Audi (the original article is paywalled, but others reference it), a prediction buoyed by Audi's adoption of Google Earth for its existing in-vehicle infotainment (IVI) systems.

Indeed, Audi was the most visible carmaker in the OAA announcement, and it later demonstrated an Android tablet that will ship with some of its future cars. But OAA surprised many onlookers who expected a bilateral deal between Google and Audi; in particular OAA was surprising for the fact that there were other automakers involved—General Motors, Honda, and Hyundai—as well as graphic chip vendor NVIDIA.

The announcement itself is light on detail; it notes that "there’s still an important device that isn’t yet connected as seamlessly to the other screens in our lives – the car" and promises "accelerating auto innovation with an approach that offers openness, customization and scale." As for the form this innovation takes, the announcement notes that a lot of people already take their Android phone or tablet with them in the car, but that it is "not yet a driving-optimized experience".

Wouldn't it be great, the announcement says, to "bring your favorite apps and music with you, and use them safely with your car's built-in controls and in-dash display". Google and the OAA will "enable new forms of integration with Android devices, and adapting Android for the car", the announcement says. The press release is similar in tone, albeit augmented with a quote from each of the companies mentioned.

Strictly speaking, though, none of that text actually says that OAA will be adapting Android to run as the operating system of the IVI system. In fact, it sounds much like the phone/IVI-head-unit integration already found in many current cars: the phone can be paired to the head unit with Bluetooth or connected over USB, then use the car's dash display, audio system, and inputs to control applications running on the phone. The OAA site FAQ does say that the group is "also developing new Android platform features that will enable the car itself to become a connected Android device", but puts the priority on better integration with existing Android devices.

On January 7, Audi previewed an Android tablet designed for use specifically inside the car. It connects to the car's IVI system over WiFi, and offers controls for the entertainment system and a digital instrument cluster display.

OAA's initial focus, therefore, seems to be on improving the tethering experience between Android handheld devices and IVI units—perhaps making IVI tethering a built-in feature, rather than requiring a custom app for each car, as is largely the case today. The announcement and the site also highlight driver safety and an "experience" optimized for driving, which might imply some sort of "car mode" intended to reduce the odds of distracting the user behind the steering wheel. There are also IVI products that implement Android app support by running Android inside a sandboxed virtual machine, so it is possible that Google is interested in improving that experience.

Nevertheless, a lot of the CES coverage given to the OAA announcement focused on the prospect of Android-powered IVI head units; perhaps that is simply the more exciting side of the equation, or perhaps the terse announcement and newly minted OAA site simply do not provide enough detail.

Consortia galore

On the other hand, if the OAA is primarily focused on improving handheld-device tethering and integration, that would explain several peculiarities surrounding the announcement. For starters, GM, Honda, and Hyundai are also members of the GENIVI Alliance, which is focused on designing a Linux-based IVI platform. GENIVI's chief deliverable is its compliance program, which certifies products against a fairly detailed specification. Some bits of GENIVI's specification are "functional" requirements that specify only an API, but others mandate specific components—including PulseAudio, GStreamer, FUSE, and systemd—for which Android has specific alternatives.

Focusing on device integration also explains the statement in the press release from GM's Mary Chan: "We see huge opportunities for the Android platform paired with OnStar 4G LTE connectivity in future Chevrolet, Buick, GMC and Cadillac vehicles." The wording in a press-release quote is not accidental; GM is being careful to say that it looks forward to seeing Android work with GM's own OnStar platform. That makes sense; it would, after all, be quite a surprise for GM (on any other carmaker) to put financial resources toward developing two separate IVI platforms at the same time.

On the other hand, there are still several lingering questions about OAA. First, there is the absence of several automakers who already ship an Android-based IVI platform in their vehicles: Renault (with its R-Link system, which includes a full-fledged "app store"), Kia (with its Uvo platform), and Volvo (with Sensus). There is also the question of whether or not Audi is (as was predicted) adopting Android as its own IVI OS. Audi's own IVI platform, called Multi Media Interface (MMI), is based on QNX. The tablet demonstration, notably, did not indicate that Audi was migrating its head units to Android.

For developers, the biggest unanswered question remains just what Google has in mind to improve the in-car Android experience. There is an existing standard called MirrorLink, for instance, that is devoted entirely to tethering phones to IVI head units. MirrorLink is maintained by yet another industry alliance, the Car Connectivity Consortium (CCC), and it already supports Android. Direct WiFi connectivity like that demonstrated in the Audi tablet is also existing technology, for instance in the Wi-Fi Alliance's Miracast standard.

Using an Android device to control the IVI system in the car, as in Audi's demonstration, is more original, but the implementation challenge there is primarily one of work on the IVI unit side, rather than changes to Android itself on the device. That is, the Android tablet does not need new APIs just because the app it runs is connecting to a vehicle.

Changing lanes

The biggest mystery about the OAA announcement, however, is why Google felt the need to start an industry consortium to improve Android for automotive usage, rather than simply joining the CCC, GENIVI, or other groups. Many CES bloggers (and blog commenters) drew immediate comparisons to Google's Open Handset Alliance (OHA), the organization Google launched in 2007 as the nominal vendor-neutral alliance backing Android. Although it is mostly forgotten now, OHA was initially touted as a collaborative project focused on the principle of improving the smartphone world through open source, of which Android was merely the first joint project. In practice, though, OHA is essentially just Google's partner program, and Android today is developed within Google and then delivered to hardware vendors.

And whether or not joining OHA is beneficial to Android device-makers is a matter of debate. Google has been criticized in the past for tightly controlling what OHA device makers are allowed to do, and there are precious few device makers building products on the Android source code without participating in Google's official partner program. R-Link and Uvo are both heavily customized forks of Android, so perhaps one of the reasons for launching OAA is to rein in incompatible Android derivatives in favor of an "official" flavor. The OAA announcement and press release both invite other companies to join; time will tell whether existing automotive Android system builders will take the offer.

GENIVI's community manager Jeremiah Foster posted some brief comments about the announcement on Google+. Although he welcomes Google's foray into the automotive space, he bemoans the lack of detail. Ultimately, he says, "this seems to be much more of a reactive, defensive approach which will likely fracture the marketplace a bit more rather than rally it behind a common standard." From the mobile side, Foster makes a good point about the defensive uses of OAA. Apple announced its own "iOS in the Car" initiative in June 2013, aiming to provide access to iPod and iPad devices from IVI head units.

As ars technica (and many others) have noted in the past, Google's real interest in maintaining control over Android is not in preventing competing forks of the OS itself, but in building business for the services it integrates, from search to GMail to Hangouts. If nothing else, Google taking an active interest in the burgeoning IVI space indicates that the company wants to be sure users can still access their Google accounts when behind the wheel. Precisely what effect that will have on the products released by carmakers and automotive suppliers remains to be seen.

Comments (10 posted)