changeset 1120:34fb47276e30

Fluff up the "about" page a bit.
author Rob Landley <>
date Wed, 16 Jun 2010 18:08:10 -0500
parents 25b47a72fd70
children 3c5eb21262af
files www/about.html
diffstat 1 files changed, 111 insertions(+), 26 deletions(-) [+]
line wrap: on
line diff
--- a/www/about.html	Wed Jun 16 18:07:54 2010 -0500
+++ b/www/about.html	Wed Jun 16 18:08:10 2010 -0500
@@ -1,26 +1,80 @@
+<title>About Aboriginal Linux</title>
 <!--#include file="header.html" -->
-<p>Aboriginal Linux is a set of tools for building custom virtual
-machines.  It lets you boot virtual PowerPC, ARM, MIPS and other
-exotic systems on your x86 laptop, and do development in them.</p>
-<p>Aboriginal Linux was written to serve the embedded community, but it
-has other uses as well - portability auditing and cross-platform
-regression testing, for starters.</p>
 <b><h1><a href=documentation.html>What is Aboriginal Linux?</a></h1></b>
-<p>Aboriginal Linux is a build system for creating bootable system
-images to be run under virtualization, intended to reduce or even
-eliminate the need for cross compiling.</p>
+<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>
+<p>Aboriginal Linux was written to serve the embedded community, but it
+has other uses as well:</p>
+<li><p><b>Allow package maintainers to reproduce and fix bugs on architecures
+they don't have access to or experience with.</b></p>
+<p>Bug reports can include a link to a prebuilt Aboriginal 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
+<li><p><b>Build arbitrarily complex Linux distributions without messing with
+cross compiling.</b></p>
-<p>The build system is a series of bash scripts which create a small native
-Linux development environment for each target, runnable on real hardware or
-under emulators such as <a href=>QEMU</a>.</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><p><b>Automated 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.</p></li>
-<p>For a list of currently supported targets, see <a href=screenshots>the
-screenshots page</a>.</p>
+<li><p><b>Stay up to date with current packages in unmodified "vanilla" form,
+with easy upgrades and the ability to push your own changes
+<p>Non-x86 targets often receive less testing than common desktop and server
+hardware, 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.</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>For more information, see <a href=documentation.html>the documentation
@@ -29,22 +83,53 @@
 <b><h1><a href=downloads>Downloading Aboriginal Linux</a></h1></b>
-<b><h2><a href=downloads>Source Code</a></h2></b>
-<p>The <a href=downloads>Aboriginal Linux source code</a> is
-a series of shell scripts which run to create the various binary
-images.  See the <a href=downloads/README>README</a> for usage instructions,
-and the <a href=news.html>release notes</a>.</p>
+<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>
-<p>Several <a href=downloads/binaries>prebuilt binary images</a>
-are available, based on the current Aboriginal Linux release.  The
-<a href=downloads/README>README</a> describes each tarball.  The
-release notes on the <a href=news.html>news page</a> explain recent
+<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
 <b><h1><a href=>Development</a></h1></b>
+<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 "./"
+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>
+<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=>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 "" script invokes the other
+stages in the correct order, but the stages are designed to run individually.
+(Nothing itself does is actually important.)</p>
+<p>Aboriginal Linux is designed as a series of orthogonal layers (the stages
+called by, 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=>development repository</a>
 using the Mercurial source control system.  This includes RSS feeds for
 <a href=>each checkin</a>