Embedded Linux Long Term - Part 3

I wrote about long term support for embedded Linux before, a few times, but I'm back for more!

Recently in LWN, there have was another article about various embedded groups, like Linaro and LTSI, maintaining an official policy on long term support kernels. That's cool and all, if you're developing consumer electronics that will get replaced in 2 years (like cell phones in the US), but it's not that helpful for embedded industrial systems that will have lifetimes measured in decades. Especially industrial systems where the customer is scared to death of software upgrades because they've been burned before by past providers that assured them, "Nothing will go wrong." (It did)

Upgrading a kernel at one of these customers' sites will not happen. Security updates for the same kernel version, maybe. Beyond that, NO WAY!

So how does the embedded developer deal with this?

The best way I've thought up so far is to ride coat-tails for as long as possible and do extensive testing when absolutely forced to move to a new kernel version. That means grabbing sources from something like Red Hat or Ubuntu LTS at the beginning of a long term support cycle and riding that as far as it will go (usually 5 years). For example, Ubuntu 12.04 LTS is most likely going to have Linux 3.2 as the kernel for both the desktop and server versions. If your embedded system is supported by 3.2 (most established, non-cutting edge designs will be), grab that and let the Canonical team deal with the security updates for you. Be a good community supporter and send anything you can up-stream but otherwise just ride their coat-tail.

Another thing to keep in mind is your distribution. Although most embedded developers already keep installed packages to a minimum, you'll want to take this as far as you can. Once who ever's coat-tails you're riding for all your software, other than the kernel, goes end-of-life (i.e.: no more security updates for free), you've got two choices: 1) Ask your customer to upgrade (probably not going to happen), or 2) Backport security fixes yourself. Neither is much fun. Minimize this!

Don't pick something targeted towards mobile phones. Historically, everyone making mobile phones (ironically, except Apple) sucks at providing software updates beyond a year or two. The embedded Linux teams working to provide systems to compete with Android aren't much better. You're going to get stuck taking a server distribution and making it work on your embedded system (becoming less of an issue but still not as straight forward as something like OpenEmbedded).

Or you can pay... But that's no fun and you'll still deal with these issues down the road in about the same time frames.

It'd be cool to see a long term support version of Emdebian. Emdebian already has way less packages than real Debian so it's less daunting to apply security fixes. Debian has fairly long release cycles and is community driven. Lenny's already been around for a while and will be supported at least 1 year beyond Wheezy's release. Having a community support project to keep Squeeze and beyond supported for 5+ years would be cool...