Embuntu

[Kevin Fries]

WARNING: LONG POST!
-------------------
I work a research and development arm of a Japanese phone company.  We
are often asked to build prototypes of new devices, and our first tool
out of the box is nearly always Linux.

Up until this point, most of our prototypes have been built either from
a custom busybox (buildroot) build, or from a scaled down version of
Debian.  For the most part, the buildroot versions are ideal where space
is concerned, and interface is unimportant.  The Debian environment is
ideal when we have a user interface.

Recently we have moved all our development servers and desktops to
Ubuntu Linux (Feisty mostly).  Therefore, we would like to re-apply all
our knowledge in building these trim systems to Ubuntu.  Also, rather
than going it alone as we have been, we would like to extend our
knowledge, into the Ubuntu development universe.  We would also like to
build one environment that may or may not include the UI.

After meeting with Joey Stanford, he suggested that I speak with the
Ubuntu Mobile project.  However, they are not trying to be a general
purpose project, but instead, simply a port of Mameo into the Ubuntu
platform.  Basically, they are trying to build a sub-laptop running
Ubuntu with the Hildon extentions (i.e. Mameo), which has no benefit to
the general embedded marketplace.

I would like to join (or lead if needed) a project that is working on
bringing the Ubuntu platform to embedded devices.  This requires focus
on several areas not being addressed by the "Ubuntu Mobile" project.
Here is my list of the 10 biggest areas not being addressed:

1) Devices without I/O.  Many embedded devices do not have graphical
user interfaces such as Network Attached Storage; Routers; Security
Scanners; etc.  Instead these devices are usually configured via a web
interface.  In short, they are a special purpose server (NAS=Samba;
Router=Zebra; Security Scanner=Nagios or GroundWork Open Source; etc).

2) When a graphical user interface is required, it should incorporate
more than just the Mameo interface.  Many of our devices are kiosks that
run a Opera interface direct against the frame buffer, or against
K-Drive.  Other interfaces are defined by the software requirements.  So
a true embedded platform needs to provide a choice of interfaces: Raw X
(k-drive), DirectX, Qtopia and GTK/e on the low end; to matchbox,
hildon, and fltk on the heavier side.

3) Embedded devices are generally memory constrained devices.
Appliances and kiosks generally need to run on 16M to 64M of ram
depending on what services are being supplied.

4) Embedded devices are generally storage constrained devices.  Often
storage is measured in megabytes, not gigabytes.  Therefore a series of
tools need to be deployed in order to fit the operating system into this
constrained space.  The tools to handle this include cloop file systems,
cramfs, and unionfs.

5) Embedded devices rarely have hard drives, but instead rely upon flash
memory for storage.  This has some real ramifications on reliability.
Tools such as jffs2 and logfs file systems are critical to supporting
commercial grade products with a Linux based OS.  Otherwise, data
storage and retrieval will quickly wear out the storage within the
embedded device.

6) In order to cut down on memory requirements, one of the popular
tricks it to enable XIP (eXecute In Place) in the kernel.  The prevents
the entire kernel, plus all the drivers from having to reside in ram,
saving it for other programs.  Given the scarcity of ram on many
embedded devices, this can create a benefit when used in the correct
way.

7) Embedded devices are generally expected to have much lower startup
times than desktops and servers.  A Linux or Windows desktop that takes
two minutes to startup may be a little slow, but not exactly uncommon.
With embedded devices, anything over 30 seconds is completely
unacceptable, and many people would say that 20 seconds is unacceptable.

8) On most Intel based desktops and laptops, power management is a huge
issue.  On most embedded devices, it is even more important, and less
standardized.  A good general purpose distro aimed at embedded devices
needs to address this.  It can also assist in #7.  But, standard ACPI is
often not available on smaller boards, especially those based on PC104
and/or ARM processors.

9) And in order to adjust the normal (K)Ubuntu environment to handle the
points made above, a more modular kernel needs to be used.  While a raid
driver may make sense in a NAS, it makes no sense in a flash based
handheld device.  The regular environment makes it always available,
because the increase in resources is trivial compared to the entire
system.  But as that system shrinks, that space will become more
critical.

10) I am not going to put my 10th item here, but leave it to your
imagination.  As a company producing devices for a telecommunications
company based in Japan, you can imagine there are several issues I have
yet to address that effect the devices we produce.  How about Japanese
language input on a small screen.  Every company selling small devices
in Japan has to deal with that one.  Or how about PHS networking, or the
pending change to 3G.  Every reader of this list can probably come up
with several issues made more difficult, or are just flat different, on
an embedded or mobile platform, that I did not mention.  Place your own
10th item here.

As I hope I have clearly pointed out, and embedded environment has some
very different trade-offs from a desktop or server environment.  The
Ubuntu Mobile group is completely sidestepping these issues in order to
build Mameo.  They are planing on deploying it on a "Tablet" device.
Much of what they are working on will also apply to embedded devices,
such as touch screens, and onscreen keyboards.  But they are ignoring
anything not Mameo related, and are not building for an embedded device.

Therefore, I would like to see who else is working on these issues, and
work toward getting a real embedded project going.  I will take the
point if need be.

Thanks in advance

-- 
Kevin Fries
Senior Linux Engineer
Computer and Communications Technologies, Inc.
a division of Japan Communications, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20070612/626eb332/attachment.sig>