Tech —

A hands-on overview of the Access Linux Platform

A the recent LinuxWorld conference, Ars got the chance to test drive a mobile …

A test drive

The ACCESS Linux Platform (ALP) attracted lots of attention at the most recent LinuxWorld, where it impressed third-party software developers and intrigued mobile Linux enthusiasts. During the event, I got some hands-on time with the ALP software on functioning prototype boards, and I took the official SDK for a test drive.

ALP leverages many components of the conventional desktop Linux stack, but it also includes some unique proprietary components developed by ACCESS. The underlying core of the operating system is built on top of a 2.6.14 Linux kernel that has been customized to reduce memory footprint, decrease boot time, and use power more efficiently.

The ALP userspace is closely aligned with the GNOME Mobile and Embedded ecosystem; it uses the Matchbox window manager and a modified version of the GTK+ toolkit. The platform also provides an open source middleware layer called Hiker that contains simple APIs for interfacing with the system's underlying services, including management frameworks for notifications, application launching, global settings, alarms, events, and interprocess communication.

In addition to using GTK+ for native applications, ALP also supports Java and has an integrated Garnet emulator for running legacy Palm software. For a more lightweight development path, ALP includes a widget framework based on the proprietary NetFront web browser, which will make it possible to create simple ALP programs using HTML and JavaScript. ACCESS says that its application bundle system will make it possible to deploy, install, and run ALP programs in a consistent way across all of those technologies.

Another big part of the stack is the data storage system, which has lots of different abstraction layers for easy access. ALP includes SQLFS, which provides a POSIX filesystem interface on top of an embedded SQLite database. It is currently used as the backend for the ALP global settings system, and it can also be used in individual applications that need structured data storage.

ALP is designed to maximize flexibility so that carriers and handset makers will be able to tailor it to their needs and provide some differentiation at various layers of the stack. Another major design consideration was the need to provide strong support for a multitude of form factors and handset designs. ACCESS says that ALP is well-suited for low-end feature phones, business-oriented smartphones, and rich multimedia devices. In the future, it could also be used for set-top boxes, car navigation systems, and a multitude of other devices.

I tested two different flavors of ALP on experimental prototype boards, and, though I encountered a few bugs while testing the software, the overall user experience was relatively impressive. The main ALP user interface clearly has its roots in Palm design philosophy, with a very minimalistic layout that emphasizes ease of use and consistency rather than innovation. It doesn't break any new ground, but it is highly functional. An ACCESS employee walked me through some of the PIM software and I mostly liked what I saw.

I also tested a modified version of ALP that was designed for MID-like devices. It had some additional aesthetic embellishments and a richer user interface that emphasized multimedia functionality. The differences between the two flavors of the platform were a pretty convincing demonstration that ALP can be used across very different kinds of devices.

I tested a technical preview of the ALP SDK at LinuxWorld, and then I later attempted to install it in a virtualized Ubuntu environment on my Linux desktop computer at home. The SDK is distributed as a tarball containing DEB packages that are intended for use on Ubuntu. One might be inclined to assume that it will work right out of the box on Ubuntu, since Ubuntu packages are the primary vector of distribution for the SDK, but that's just wishful thinking.

I ran into several snags and it took me most of an afternoon to get it all running. I don't recommend trying it at this point unless you really know what you are doing. I had to use a few different work-arounds, but I eventually got most of the pieces working.

Channel Ars Technica