µbuntu

Revision 17 as of 2005-04-28 00:32:52

Clear message

µbuntu

Status

Introduction

Create an Ubuntu derivative suitable for use on embedded systems and appliances such as home theatre systems.

Rationale

Many appliances are now being powered by Linux. As such, it makes a lot of sense for Ubuntu to target this space.

Scope and Use Cases

There are two different scopes in play:

minu-ubuntu:

  • Appliance level, such as home theatre, PVR
    • Larger footprint
    • Custom applications for each appliance
    • should be maintainable with standard distro tools

µbuntu: (pron myu-buntu"??)

  • Embedded class machines such as ipaq
  • probably not maintained - install once and then leave well alone
  • Target size for base install: 100M
  • Suitable for flash media
    • Separate read-only and read-write data on different filesystems
    • Support read-only root? This is a popular configuration, but what are the use cases?read-write data are strictly separated?)
    • Installation to flash media
    • Cross-installation (e.g., install onto flash media on i386 development system, insert into ARM embedded device)

Implementation Plan

mini-ubuntu

  • Create minimal system seed

µbuntu:

  • use minimal seed from above
  • Investigate cross installation
  • stripping packages of docs etc - hooks in dpkg to do this?
  • create image of system for installation and replication
  • alternative X implementation
  • GPE or qutopia for environment

The minimal seed should consist of the bare minimum of packages required to create a useful system. System integrators and ISVs would then integrate their applications on top of this shell; they could also select other packages as required.

µbuntu requires that we go through some extra steps; we must be able to install from one platform (eg x86) to the target (eg arm) platform, and we must be able to only install the very minimum that a package requires to be useful; eg we strip out documentation. This will require hooks in dpkg to allow this to occur in an automated fashion.

We must also create infrastructure to allow us to create images for automated installation onto embedded systems trivially.

Embedded devices that run X need to use an alternative implementation, such as TinyX or kdrive. We need to investigate the sanest implementation and package it. Also, we should provide an example graphical environment such as GPE for testing purposes.

Data Preservation and Migration

Packages Affected

  • dpkg
  • everything else

dpkg would need to be extended to provide hooks to allow for non-installation of chunks of packages to save space.

Other packages in the minimal seed would need to be modified to provide information to the hooks in question.

User Interface Requirements

Outstanding Issues

  • Find a process that works and document that. Possibly expose it via launchpad.

UDU BOF Agenda

UDU Pre-Work