# HG changeset patch
# User Rob Landley
(Note: the goal of the 2.0 release is to migrate +from busybox, uClibc, and gcc/binutils to toybox, musl-libc, and +lvm/lld.)
+Each system image tarball contains a wrapper script ./run-emulator.sh @@ -117,7 +121,7 @@ and for new releases.
Questions about Aboriginal Linux should be addressed to the project's -maintainer (rob at landley dot net), who has a +mailing list, or to the maintainer (rob at landley dot net) who has a blog that often includes notes about ongoing Aboriginal Linux development.
@@ -288,14 +292,85 @@
|
Now that we've got a simple development environment working, we can make +it simpler by moving to better packages. Most of this project's new +development effort is going into the upstream versions of those packages +until they're ready for use here. In the meantime we're maintaining what +works, but only really upgrading the kernel version and slowly switching +from busybox to toybox one command at a time.)
+ +uClibc: The uClibc project's chronic development problems resulted in multiple +year-long gaps between releases, and after the may 2012 release more +than three years went by without a release during which time +musl-libc went +from "git init" to a 1.0 release. At this point it doesn't matter +if uClibc did get another release out, it's over, musl is the more interesting +project. (Its limitations are lack of target support, but it's easy to +port musl to new targets and very hard to clean up the mess uClibc has +become.)
+ +toybox: The maintainer of Aboriginal Linux used to maintain +busybox, but left that project +and went on to create toybox for +reasons explained at length elsewhere +(video, outline, +merged into Android).
+ +The toybox 1.0 release should include a shell capable of replacing +bash, and may include a make implementation (or in qcc, below). This +would eliminate two more packages currently used by Aboriginal Linux.
-llvm: When gcc and binutils went GPLv3, Aboriginal Linux froze +on the last GPLv2 releases, essentially maintaining its own fork of +those projects. Several other projects did +the same but most of those have since +switched to llvm.
+ +Unfortunately, configuring and building llvm is +unnecessarily hard (among +other things because it's not just implemented in C++ but the 2013 +C++ spec, so you need gcc 4.7 or newer to bootstrap it), and nobody seems +to have worked out how to canadian cross native compilers out of it yet. +But other alternatives like pcc +or tinycc are both less capable and less +actively developed; since the FSF fell on its sword with GPLv3, +the new emerging standard is LLVM.
+ +qcc: In the long run, we'd like to put together a new compiler, +qcc, +but won't have development effort to spare for it before toybox's 1.0 +release. Its goal is to combine tinycc and QEMU's Tiny Code Generator into +a single multicall binary toolchain (cc, ld, as, strip and so on in a single +executable replacing both the gcc and binutils packages) that supports all +the output formats QEMU can emulate. (As a single-pass compiler with +no intermediate format it wouldn't optimize well, but could bootstrap +a native compiler that would.)
+ +Additional goals for qcc would be to absorb ccwrap.c, grow built-in +distcc equivalent functionality, and an updated rewrite of cfront to +compile C++ code (and thus natively bootstrap LLVM). + +
Finishing the full development slate would bring the total number of +Aboriginal Linux packages down to four: linux, toybox, musl, and qcc.
+ +(Yes, reducing dependency on GPL software and avoiding GPLv3 entirely +is a common theme of the above package switches, there's a reason for +that: audio, +outline, see also +Android self-hosting below.)
+ + +The goal here is to separate what packages you can build from where and how you can build them.
@@ -422,10 +497,11 @@ none of which are administered by a competent sysadmin. So for security reasons, Android is locked down with minimal functionality outside the Java VM sandbox, providing less of an attack surface for viruses and trojans. -In theory the Linux Containers infrastructure -may eventually provide a solution for sandboxing applications, but the -base OS needs to be pretty bulletproof if a billion people are going to -run code they don't deeply understand connected to broadband internet 24/7. +In theory the Linux Containers +infrastructure may eventually provide a solution for sandboxing applications, +but the base OS needs to be pretty bulletproof if a billion people are going +to run code they don't deeply understand connected to broadband internet +24/7.Thus replacement packages for the C library and posix command line should be clean simple code easy to audit for security concerns. But it