A new user interface

One of the most obvious changes is the user interface. The ARM version of Ubuntu’s previous release, Karmic Koala, booted to the default Ubuntu desktop. For some this was fine but typically today’s ARM devices tend to be different. At present, they tend to have smaller screens, less resources and little in the way of graphics acceleration. To overcome some of these limitations in the x86 netbook world, the netbook-launcher user interface was created. Based on Clutter, netbook-launcher could not run on the ARM devices Ubuntu was targeting due to a lack of 3D acceleration. Enter netbook-launcher-efl, a 2D version of the x86 netbook interface written using EFL packages.

Read more about the 2D EFL based launcher.

Faster Live CD boots

Booting a Live CD is something that most new Ubuntu users do (and many existing users too). Its often their first experience of an Ubuntu release and should give a good impression. Well, on some ARM hardware, booting this Live CD image took over 3 minutes, not exactly the impression we would hope. So investigations happened into what was causing this slowness. In the end the final boot time was reduced by around 35% on all Ubuntu Live images, not just ARM ones.

Read more about the Live CD boot time improvements.

Web Office and Web Mail integration

Open Office on a resource limited platform isn’t the greatest experience and to make matters worse, on the ARM architecture there are issues building it correctly. A new way of viewing, editing and saving office documents was needed and for the Lucid cycle a web-based solution was integrated into the desktop called webservice-office-zoho.

Read more about the web office integration.

Similarly, Evolution could be considered too heavy-weight for ARM device needs. A solution was implemented to enable integration with several online mail providers.

Read more about the web mail integration.

Optimized Tool Chain Defaults

This release includes a complete archive rebuild using more modern tool chain defaults that the latest ARM hardware can take advantage of. As of Lucid Lynx, packages are built using Thumb-2 to reduce code size and improve performance, NEON for accelerate multimedia and signal processing, and are optimized for ARMv7A based chips. Although this means that some older hardware will not work with the latest Ubuntu release it does mean that the images perform much better on modern hardware.

Other Improvements

Much bug fixing went on this cycle. The fail to build list (FTBFS), a list of packages that fail to build on a given architecture, was a focal point of activity. For the first time ever, the number of packages that failed to build on ARM from the main archive was zero (apart from libx86 which refuses to leave the build queue for ARM due to a bug), a great achievement.

The Chromium browser now works on ARM, rootstock, the tool to build ARM rootfs tarballs gained a gui frontend, we added support for the very popular OMAP platform (beagle board) and many small improvements were implemented, making this the best Ubuntu ARM release ever.

We here at Canonical are very proud of the Lucid Lynx on ARM and are extremely excited at what future releases will bring.

Vendors are trying to work around it, especially as there is the expectation of a ramp-up in the availability of ARM based hardware. Super long-life netbooks, low powered touch based computers, and even a flurry of smaller embedded devices are forecast to hit the market this year, many of which will be based on the Linux operating system. Ubuntu would be a great match for this.

Ubuntu and ARM

Ubuntu runs very well on some ARM based platforms and there is a sustained effort to make it work more ubiquitously across many more. To that end our goal is to have Ubuntu running on any ARM based device (as long as there is hardware available). A lofty goal but one which we would like to see happen.

So what can we do about the 3D graphics licensing issue? Legally not very much. The companies that own the IP (Intellectual Property) rights to these drivers often want large licensing fees for their technology. This is a model for single product lines (take the Nokia N900 for instance) but for Ubuntu where we are targeting a more broad approach, this isn’t ideal.

So when you buy your new, ARM based netbook that has an obscene amount of battery life and you just want to install the 3D clutter based, wonderfully rich UI that Ubuntu Netbook Edition offers, what do you do?

Well Ubuntu recognizes this problem and as part of the Lucid Lynx release there is an effort to bring a similarly wonderfully rich UI to non-3D-accelerated hardware.

The new 2D EFL based Launcher

Above you can see the default UI for Ubuntu’s ARM based releases starting from Lucid (10.04). It’s a direct clone of the UI found in the 9.10 Karmic release on i386 although this one is based on EFL (Enlightenment Foundation Libraries) meaning that its fast on non-accelerated platforms. If there is 3D hardware available it can use that but it works perfectly fine without.

Another great thing about the 2D launcher is that isn’t not restricted to ARM hardware only, in fact if you have Lucid installed now, getting the launcher couldn’t be simpler. At the command prompt just type the following (make sure you have the universe repository enabled):

sudo apt-get install netbook-launcher-efl

and voila, your UI switches to the new launcher. Of course a simple:

sudo apt-get remove netbook-launcher-efl

will remove it if you decide its not what you want.

Beyond Netbook Launcher

Another of the great things about this launcher, as apposed to the 3D launcher shipped with Karmic, is that its extremely theme-able. The theme file is contained in:

/usr/share/netbook-launcher-efl/data/themes/default.edj

Theme files use the edje declarative layout format. By changing this file you can completely change the way the UI looks. For example, see the alternate UI screenshot above, both are based on the same code, the only difference is that they have a different theme file.

So if you have ARM based hardware but no 3D acceleration, fear not, you can get the same great user experience that your i386 cousins have in Ubuntu Netbook Remix.

How do you boot a live cd session?

The first thing to do was find out why it was slow. There are a few ways to do this but I chose to first use simple time-stamping methods and afterwards, the much prettier bootchart package.

A bit of background on how the live cd session is booted. There are two broad steps in the process of booting a live cd, the first is setting up the environment ready for the session, and the second, you guessed it, is actually booting into the session. Initial hunches were that the first step, setting up the session, was the major cause of slowness so investigations started there.

Casper

Setting up the session is the responsibility of a project called casper. Casper is a set of scripts that are run on boot to do such things as unpack the initial filesystem, add a dummy user, setup languages and keyboard layouts and so forth. Its mainly written in perl.

The time-stamping stage of investigates confirmed that casper was indeed slower than it should be. I’ll skip ahead to the bootchart part of the story as thats much more visually interesting.

Casper before

Above you can see the casper section of the live cd boot process. I’ve highlighted the bits that immediately stand out. The overall boot was 3 minutes and 15 seconds with casper responsible for around 2 minutes of that.

The highlighted bits seemed to have one thing in common, they all interacted with the debconf database. From the debconf programmers tutorial document:

“debconf is a backend database, with a frontend that talks to it and presents an interface to the user. There can be many different types of frontends, from plain text to a web frontend. The frontend also talks to a special config script in the control section of a debian package, and it can talk to postinst scripts and other scripts as well, all using a special protocol. These scripts tell the frontend what values they need from the database, and the frontend asks the user questions to get those values if they aren’t set.”

So communicating with the debconf database was slowing the boot. Initiating the call, sending the data and receiving a response, was taking up to 4 seconds at a time and when there are many of these calls, they all soon add up.

After many a head-scratching moment it was decided that the best way to solve this would be to initiate the communication once and keep it open so that when debconf was needed, the overhead in setting it up was removed. The implementation details are all in the code history but the results are much easier to show.

Casper after

With a couple of other tweaks besides the debconf one, the boot is now down to 1 minute 53 seconds and casper takes just under 50 seconds of that. There is more room for improvement, pre-generating a default locale (although which locale that would be is a tough choice), pre-generating fonts and looking into SSL, but for now, this is a big win.

The bootcharts above are for the ARM based iMX51 device made by Freescale which is only just beginning to proliferate onto the market. Intel/AMD based machines show an equivalent speed-up.

Conclusion

So there you have it. The next time you boot into a Lucid live cd session it shouldn’t take quite so long, and now you know why.

This is going to get an instant dismissal from the Nokia faithful, but bear with me and I guarantee you will see what I see in some capacity.

Lets get one thing straight first, I love what Nokia have done for Linux, from their first offerings pre-770 to what they do today, they do a great job. I know many of the current (and past) team that care so much about how Linux will someday become the default smart-phone choice that I somewhat feel a little sorry that they pioneered a route that may be occupied by others.

Nokia was there way before Google decided to bring Linux to a phone-sized device, Nokia was there long before Internet tablets were considered a cool technology, and Nokia continue to fund many of the projects that matter for Linux users so its with a heavy heart that I declare my dislike for the n900.

When Nokia had a Linux based tablet, it was consider unique and very cool for the geeks that used Linux. It was a great playground for developers and a marketing tool to inform people just what could be done with innovation and a lot of hard work. Fast forward to today and we have Google bringing a Linux based phone OS to the mass market, ARM challenging for supremacy using Linux, and even Palm resurrected their business based on Linux, so what is Nokia’s reply, the n900.

Lets not doubt that the device is a great attempt to bring a full operating system to a smart phone. But it fails so miserably on many occasions. Nokia had such a head start that the likes of Google and Palm should of gone to Nokia to license their stack because of their years of maturity, but no, they thought 9 to 12 months of in house R&D could better what Nokia had to offer and guess what, that turned out right.

So when Nokia bring out something resembling a phone that plays in the Google Android, Apple iPhone, Palm Pre and even other “dumb phone” eco-sphere you instantly compare them. I really want to like this phone but at every opportunity it does something that isn’t what I want. Email (modest) is terrible (bugs, slowness, imap headaches), the browser is fast but back navigation is form over function and zoom in/out tends to be random, the calendar app never syncs past my initial Google calendar sync, screen presses are hit and miss … I have a list longer than both my arms [1]. Software faults, hardware incumbency, complete failure in some cases leave this device not on a par with its predecessors but behind because of its lofty ambitions.

Some things are great, the keyboard is surprisingly good, the screen has a great resolution, media playback is excellent, the camera is second to none for a phone but I simply can’t use it as a day to day device, and believe me I’ve tried. I’ve put my sim in the the n900 more than a dozen times and kept it there for periods of time but I have to swap it back out every time. Coming from a professional Linux developer (an ARM developer at that) this isn’t good and on more than a few occasions people have asked me whether or not they should purchase a n900. I have had to say “not yet”.

I know what Nokia and Maemo are capable of but the n900 fall’s frustratingly short. Its a step too far for Nokia and I’m sure that the next iteration of devices will be great, but will that be too late?

[1] Some bugs/problems I’ve encountered:

• imap folders not cached so each mail check takes *minutes*
• modest email client capitalizes inbox to INBOX randomly on one of my accounts making the folder inaccessable
• imap changes not registered sometimes, i.e. I read an email on the n900, its still unread when I check with another client.
• n900 is practically impossible to use one-handed
• lack of portrait mode really is a problem
• maps application is near useless, often can’t find the current location and its really slow
• some calls get routed straight to answer phone even though I have a signal
• some calls don’t connect (i.e. I get network failure) and checking the number with another phone is fine
• browser back button (not keyboard back button) brings up a UI history of your browsing which is form over function, makes going back a frustrating experience
• device is heavy and sometimes cumbersome to use (try lying on your back and operating it with keyboard open)
• screen touches sometimes don’t register even though you get the ‘click’ sound of a press being made
• zoom on the browser (little circles with your finger) can be quite random
• scroll bars are not shown by default meaning options that are off the screen can be difficult to spot (I have to always try to scroll just in case there are more option)
• Google calendar can sync via the exchange setting, I find it sync’s once and never again
• …

A future conquer?

Well its obvious that this platform has some serious potential. The promise of an embedded Linux platform that is tailored for the mobile, MID and even the net book markets gives a sense of the scale of what Android is trying to achieve. It can look very slick, it can do some really cool things but yet it is distinctly lacking in key areas.

So whats the problem?

There are three major area’s where Android falls behind the likes of the iPhone platform (discounting the terrible state of the Android Market but that’s something else entirely), they are documentation, a stable API, and development tools.

Documentation

Lets face it, the documentation for the Android SDK is poor to say the least. There is a shortage of example code (see my next point) and whist the official documentation looks pretty good on the surface, it too is missing key parts. Books quickly become out of date and the internet is full of potential android developers stumbling at every hurdle whist they try to figure out the way to achieve what they need.

One notable example here is the online books from CommonsWare. The online nature of these publications means that they can be constantly updated and CommonsWare do a great job of ensuring that their text is still relevant. Which leads me on to …

A stable API

The Android platform is very much in its infancy. Parts of the SDK change at a rate of knots and the poor developers have to keep pace if their apps are to work on the latest releases. This may be fine for a seasoned Android developer who will quickly come up to speed with the new changes, but the developer just starting out ends up falling into the trap of obsolete code.

There are a lot of code snippets, example programs and forums talking about how to use the Android SDK but so much of it is out of date. The rapidly changing SDK makes these once valuable resources a hurdle for the new developer, tripping them up until they realize that the way to do what they wanted has now changed.

Development tools

Now I’m not saying that XCode is the greatest development environment out there, it has its own problems, but for the developer just starting out, XCode becomes immensely valuable. Contrast this to the Eclipse integration that Android has. The editor is slow, the ‘interface builder’ (the bit you use to graphically layout screens) is pretty useless and the somewhat temperamental nature when compiling and running the app make it the bucking bronco of development environments. Some parts of the tool are just great, code completion, the vast amount of plugin’s you can use and auto insertion of dependencies make it something that you have to use but never really enjoy.

So whats the answer?

Being an open source developer, one never likes to complain about something without either fixing it ones self of suggesting a way of doing it. Well, this is a tough one.

Google have a tight hold on the official release of the Android platform so the rapid SDK changes aren’t going to go away. Eclipse has performance issues that I would have no idea how to fix so that leaves documentation, something I can change.

From now on there will be an Android section on this blog that will try to keep pace with the rapidly changing development side of Android whist providing some tutorials that the beginner will find helpful. So, stay tuned for more.