[Aboriginal] My dreams about Aboriginal

[Rob Landley]

On 04/07/2011 03:03 PM, Alessio Igor Bogani wrote:
> Hi All,
> 
> What follows are my dreams about the future of Aboriginal Linux:
> 
> 1) Switch to klibc (already hosted on kernel.org)

I looked at klibc, but Peter Anvin went crazy a few years ago and
inserted perl into the build of every single project he had anything to
do with, including the Linux kernel, syslinux, and klibc.  He seems to
think that packages which do NOT require perl to build are somehow
defective.

(I've patched it back out of the kernel, but haven't touched his other
stuff.)

My general approach to other C libraries is "build a chroot using them
natively".  I could try working up a bootstrap-klibc.hdc if you'd like.

> 2) Migrate toybox to kernel.org and use it for replace busybox

I spent years working on that, but haven't had time for it in a while.
You're welcome to grab it and run with it if you'd like.  Personally I
much prefer the design of toybox to busybox, but the practical effect is
I can't stand to work on busybox anymore.  (I tried pusing my "all
config in one file" approach to Denys, and you saw what he did with
that.  Nice guy, good engineer, I disagree with his aesthetic
sensibilities.)

> 3) Integrate linux-tiny patchset to provide the best and light Linux
> embedded system (easy to study, fast to build)

Um, which linux-tiny patchset?  Matt Mackall stopped doing it a while
back, and I thought the CELF guys were feeding theirs upstream?

For years I've wanted to create a "hello world" kernel, chopping down
Linux to just the boot wrapper and startup code necessary to switch to
C, and then just enough of the early_printk() stuff to print "hello
world" and then halt.

I ranted about that here once upon a time:

  http://www.mentby.com/rob-landley/what-happened-to-linux-tiny.html

Yet another thing I haven't had time for.  (I should really be working
on rpc.lockd and rpc.statd containerization right now.)

> 4) Integrate KVM and use it when possible instead of QEMU (KVM or
> Native KVM: http://thread.gmane.org/gmane.linux.kernel/1121307 not
> matter)

I've used kvm on x86-64, it worked fine.  All you have to do is tweak
run-emulator.sh to replace "qemu-system-x86_64" with "kvm".  (The way
that's generated is the system-image.sh script calls emulator_command()
out of sources/targets/$ARCH/settings so you could alternately edit
sources/targets/x86_64/settings to replace qemu-system-x86_64 with kvm.)

In theory _qemu_ should be doing this automatically.  In practice, the
qemu and kvm trees were only merged fairly recently and most distros
still treat them as separate packages.

> Could these dreams become reality?

Sure.  If nothing else, I try not to get in people's _way_ when they
want to do stuff.  (My goals are fairly generic, and I know where my
project _stops_.  I provide infrastructure for people to build on.  I
try to make it as easy as possible for them to do so.)

> Ciao,
> Alessio
> 
> P.s.
> About my last email:
> I'm not interested in Ubuntu bootstrap at all. In fact I'm not
> interested in any big distro bootstrap. What I meant:
> 
> sudo apt-get install aboriginal-linux-{arm,mips,powerpc,x86}

I ship prebuilt binary tarballs under GPLv2.  You can download and
extract 'em into your home directory.  Nothing stops people from making
.deb or .rpm files out of 'em, but I'm unlikely to do it because that
involves judgement calls.  (Such as "where should they be installed".)

I tried to explain how to set them up in the FAQ:

  http://landley.net/aboriginal/FAQ.html#where_start

But there's a tension between "here's the minimum you need to know" and
"here's a thousand interesting tangents you could follow" that makes
documenting this stuff really hard.  (People need a linear narrative to
learn, and this is a big tangled matrix-graph-thing.)

Basically you extract a system image tarball and a cross compiler
tarball, add the cross compiler's "bin" directory to your $PATH, cd into
the system image and run dev-environment.sh.  Then play.

Building from source is for us crazy people who want to try out new
package versions and such, which will break and need to be debugged.

Rob

 1302220661.0