Would a 2nd Sandbox Unify the Fragmented Linux Mobile Market?

The Linux desktop has traditionally been a very fragmented and niche market. The mobile Linux space is no different, with various efforts including LiMo.com, Maemo.com, Moblin.com, Ubuntu Mobile, ARM Linux, Mobilinux and others. While choice can be a good thing, fragmentation can be a strong detractor against any one platform gaining traction.

What fragmentation means to developers is one, that they have to make some tough choices about which Linux variants to support — often making lowest-common-denominator choices of available libraries and versions, etc. — and two, that they have to absorb a lot of extra porting and maintenance overhead.

As for Linux users, they want to know they can select from a sizable palette of applications — they really don’t want to hear that product P is available for Linux, but only on distribution D, while product Q is only available on Distribution E. Linux is not the platform — the ecosystem is. Yet there are, maddeningly, hundreds of Linux distributions.

Reaching the Masses

To address the mass consumer market, a very rich, well-thought-out, uniform environment and set of APIs (application programming interfaces) are needed to deal with everything from telephony to media to Web browsing. In particular, to build an ecosystem worthy of mass adoption, an application store must be an integral part.

While many players are contending to offer the environment that ties all of these things together, Android looks to be the one that actually does and is gaining market traction. It has not only received praise for its design, but also boasts quite a who’s who roster of members. Numerous designs are reportedly in the pipeline for release in 2009 and 2010.

What’s at least as exciting about Android is that it can climb up the device food-chain. The first stop is likely to be netbooks, on which an Android port has been shown to work already. Asustek, a big-volume PC manufacturer, has stated it may install Android on low-cost notebooks. Once on netbooks, is there a reason for Android to stop gaining new territory?

Conventional Approaches

Still, as Android ventures further from its always-connected, mobile device roots, there’s the potential downside of not running native Linux applications — gaming, educational and utility apps that people use, but that have not been ported to the Android environment.

A transition path is key to adoption in entrenched markets. A dual-boot would be one way to try to address this, but it would come at the expense of all the always-connected features that a mobile phone offers today, when Android is halted to allow a traditional Linux image to boot. Android needs to be the primary driver of the device, and it’s far more preferable to have it running in an always-on mode.

Another angle would be to use virtualization, but this would also have its downsides. First, running a second kernel and VM (virtual machine), in general, adds more power consumption, burns more CPU (central processing unit) cycles and consumes more memory — not a good thing for a constrained device such as a netbook. Second, current Intel Atom netbook processors do not support hardware virtualization.

An Ideal Approach

A lightweight and closer-to-ideal solution that would allow native Linux apps to run on Android would be to provide a second sandboxed (chroot) Linux application environment, which could cooperate with the Android kernel and stack.

Sandboxing is necessary, because Android has a very specific architecture, with its own libraries and non-X-based GUI (graphical user interface), which are not conducive to running standard Linux/X applications. Even it’s libc version (bionic) omits certain POSIX features, making it not fully compatible. Android apps have to be targeted for and compiled against Android.

The sandboxed Linux environment would provide a separate set of non-kernel components: libraries, configuration and administrative files, applications, etc. As Android drives the hardware, the Linux environment would need to defer to Android for some facilities.

For example, X apps running under the Linux would need to speak with a special X server running on Android. The audio system on the co-Linux would likewise need to redirect to Android’s audio manager. However, the Linux environment would not need any boot files (Android takes care of booting) or its own kernel.

Using a chroot sandbox is nothing new; it’s used by Linux build environments such as the Moblin image creator, and to create a nice, clean 32-bit environment on a 64-bit Linux box (even for X apps). Doing some porting work would take the same concept to an Android environment. Perhaps further work could make the two environments more seamless to the user (UI, disk files, installation, etc.) — much like Seamless mode in VirtualBox, Unity in VMware or Coherence in Parallels.com.

The Opportunity

I would think a co-Linux environment would be a boon for coming netbook platforms, as some users will want access to their native Linux apps. It would be really cool if the Linux environment itself could be bundled as an Android app.

In any case, bundling key native Linux apps as Android apps would be a fantastic way to piggy-back on the Android Market and ecosystem, without building out any new infrastructure. This would also enable one to focus on delivering only those apps that add significant value and not spend time duplicating technical efforts with Android.

In fact, I believe a co-Linux could be the future of the Linux desktop distro, until a time when all apps are available on the cloud. What a perfect use-case for portable Linux packages using Zero Install, which removes vendor-specific headaches and is appropriate for application level packages.

Disruptive play for a new age desktop Linux company?