Mercurial > hg > aboriginal

<html>
<title>About Aboriginal Linux</title>
<body>
<!--#include file="header.html" -->

<b><h1><a href=documentation.html>What is Aboriginal Linux?</a></h1></b>

<blockquote>
<table border=1><tr><td bgcolor="#C0C0FF">
<p>Aboriginal Linux is a set of tools to build custom virtual machines.
It lets you boot virtual PowerPC, ARM, MIPS and
<a href=screenshots>other exotic systems</a> on
your x86 laptop (using an emulator such as QEMU).  These virtual system
images provide a simple development environment within which you can compile
software and run the result.</p>
</td></tr></table>

<p>Aboriginal Linux has an obvious niche within the embedded community, but
has many other uses as well:</p>

<ul>
<li><p><b>Allow package developers and maintainers to reproduce and fix bugs
on architectures they don't have access to or experience with.</b></p>

<p>Bug reports can include a link to a system image and a
reproduction sequence (wget source, build, run this test).  This provides
the maintainer both a way to demonstrate the issue, and a native
development environment in which to build and test their fix.</p>

<p>No special hardware is required for this, just an open source emulator
(generally QEMU) and a system image to run under it.  Configure and make
your package as normal, using standard tool names (strip, ld, as, etc).
You can even build and test on a laptop in an airplane, without internet
access.</p>
</li>

<li><p><b>Build arbitrarily complex Linux distributions without messing with
cross compiling.</b></p>

<p>The point is to separate _what_ you build from _how_ you build.  Build
systems have enough to do handling package dependencies and configuration
without entangling cross compiling into it.  If one system builds the right
set of packages and another system works on the right type of hardware, life
is much easier if they can work together to produce a single result.</p>

<p>If you need to scale up development, Aboriginal Linux lets you throw
hardware at the scalability problem instead of engineering time, using distcc
acceleration and distributed package build clusters to compile entire
distribution repositories on racks of cheap x86 cloud servers.</p>
</li>

<li><p><b>Automated cross-platform regression testing and portability auditing.</b></p>

<p>Aboriginal Linux lets you build the same package across multiple
architectures, and run the result immediately inside the emulator.  You can
even set up a cron job to build and test regular repository snapshots of a
package's development version automatically, and report regressions when
they're fresh, when the developers remember what they did, and when
there are few recent changes that may have introduced the bug.</p></li>

<li><p><b>Use current vanilla packages, even on obscure targets.</b></p>

<p>Embedded hardware often receives less testing than common desktop and server
platforms, so regressions accumulate.  This can lead to a vicious cycle where
everybody sticks with private forks of old versions because making the new
ones work is too much trouble, and the new ones don't work because nobody's
testing and fixing them.  The farther you fall behind, the harder it is to
catch up again, but only the most recent version accepts new patches, so
even the existing fixes don't go upstream.  Worst of all, working in private
forks becomes the accepted norm, and developers stop even trying to get
their patches upstream.</p>

<p>Aboriginal Linux uses the same (current) package versions across all
architectures, in as similar a configuration as possible, and with as few
patches as we can get away with.  We (intentionally) can't upgrade a package
for one target without upgrading it for all of them, so we can't put off
dealing with less-interesting targets.</p>

<p>This means any supported target stays up to date with current packages in
unmodified "vanilla" form, providing an easy upgrade path to the next
version and the ability to push your own changes upstream relatively
easily.</b></p>
</li>

<li><p><b>Provide a minimal self-hosting development environment.</b></p></li>

<blockquote><p>Perfection is achieved, not when there is nothing more to add,
but when there is nothing left to take away." - Antoine de Saint Exupery</p>
</blockquote>

<p>Most build environments provide dozens of packages, ignoring the questions
"do you actually need that?" and "what's it for?" in favor of offering
rich functionality.</p>

<p>Aboriginal Linux provides the simplest development environment capable
of rebuilding itself under itself.  This currently consists of seven packages:
busybox, uClibc, linux, binutils, gcc, make, and bash.  (We include one more,
distcc, to optionally accelerate the build, but install it in its own
subdirectory which is only optionally added to the $PATH.)</p>

<p>This minimalist approach makes it possible to regression test for
environmental dependencies.  Sometimes new releases of packages simply won't
work without perl, or zlib, or some other dependency that previous versions
didn't have, not because they meant to but because they were never tested in
a build environment that didn't have them, so the dependency leaked in.</p>

<p>By providing a build environment that contains only the bare essentials
(relying on you to build and install whatever else you need), Aboriginal
Linux lets you document exactly what dependencies packages actually require,
figure out what functionality the additional packages provide, and measure
the costs and benefits of the extra code.</p>
</li>

<li><p><b>Document how to put together a development environment.</b></p>

<p>The build system is designed to be readable.  That's why it's written in
Bash (rather than something more powerful like Python): so it can act as
documentation.  Each shell script collects the series of commands you need
to run in order to configure, build, and install the appropriate packages,
in the order you need to install them in to satisfy their dependencies.</p>

<p>The build is organized as a series of orthogonal stages.  These are called
in order from build.sh, but may be run (and understood) independently.
Dependencies between them are kept to a minimum, and stages which depend on
the output of previous stages document this at the start of the file.</p>

<p>The scripts are also extensively commented to explain why they
do what they do, and there's design documentation on the website.</p>
</li>
</ul>

<p>For more information, see <a href=documentation.html>the documentation
page</a>.</p>
</blockquote>

<b><h1><a href=downloads>Downloading Aboriginal Linux</a></h1></b>

<blockquote>
<table border=1><tr><td bgcolor="#c0c0ff">
<p><a href=downloads/binaries>Prebuilt binary images</a> are available
for each target, based on the current Aboriginal Linux release.  This
includes cross compilers, native compilers, root filesystems suitable for
chroot, and system images for use with QEMU.</p>
</td><tr></table>

<p>The <a href=downloads/README>binary README</a> describes each tarball.
The <a href=news.html>release notes</a> explain recent changes.</p>

<p>Even if you plan to build your own images from source code, you should
probably start by familiarizing yourself with the (known working) binary
releases.</p>

</blockquote>

<b><h1><a href=http://landley.net/hg/aboriginal>Development</a></h1></b>
<blockquote>

<table border=1><tr><td bgcolor="#c0c0ff">
<p>To build a system image for a target, download the
<a href=downloads>Aboriginal Linux source code</a> and run "./build.sh"
with the name of the target to build (or with no arguments to list available
targets).  See the "config" file in the source for various environment
variables you can export to control the build.  See the
<a href=README>source README</a> for additional usage instructions, and the
<a href=news.html>release notes</a> for recent changes.</p>
</td></tr></table>

<p>Aboriginal Linux is a build system for creating bootable system images,
which can be configured to run either on real hardware or under emulators
(such as <a href=http://qemu.org>QEMU</a>).  It is intended to reduce or even
eliminate the need for further cross compiling, by doing all the cross
compiling necessary to bootstrap native development on a given target.
(That said, most of what the build does is create and use cross
compilers: we cross compile so you don't have to.)</p>

<p>The build system is implemented as a series of bash scripts which run to
create the various binary images.  The "build.sh" script invokes the other
stages in the correct order, but the stages are designed to run individually.
(Nothing build.sh itself does is actually important.)</p>

<p>Aboriginal Linux is designed as a series of orthogonal layers (the stages
called by build.sh), to increase flexibility and minimize undocumented
dependencies.  Each layer can be either omitted or replaced with something
else.  The list of layers is in the <a href=README>source README</a>.</p>

<p>The project maintains a <a href=http://landley.net/hg/aboriginal>development repository</a>
using the Mercurial source control system.  This includes RSS feeds for
<a href=http://landley.net/hg/aboriginal/rss-log>each checkin</a>
and for <a href=http://landley.net/hg/aboriginal/rss-tags>new releases</a>.</p>

<p>Questions about Aboriginal Linux should be addressed to the project's
maintainer (rob at landley dot net), who has a
<a href=http://landley.net/notes.html>blog</a> that often includes
notes about ongoing Aboriginal Linux development.</p>
</blockquote>

<!--#include file="footer.html" -->
author	Rob Landley <rob@landley.net>
date	Tue, 24 May 2011 02:06:22 -0500
parents	d4eb237dcc6f
children	455f8dec31a0