[Aboriginal] Fwd: Re: greetings!

[Rob Landley]

One of the various relevant conversations taking place offline...

-------- Original Message --------
Subject: Re: greetings!
Date: Wed, 11 Jul 2012 11:42:29 -0500
From: Rob Landley <rob at landley.net>
To: David Henderson <dhenderson at digital-pipe.com>

On 07/10/2012 01:40 PM, David Henderson wrote:
> Desperately short of free time - you're not preparing to move again are
> you?! :)

No, just full-time day job (rather than a contracting thing that ate my
life for 3-9 months and then gave me a few months off to do full-time
open source work; I've only had one month off in the past year and that
was switching from .)

Plus toybox (one person tackling the busybox problem space, implementing
fresh versions of the posix-2008, LSB 4.1, and android commands). And
Aboriginal Linux still needs maintenance (package upgrades break stuff,
distro upgrades break stuff), and could use some more platforms added
(m68k?), and I'd still like to get distro bootstrapping implemented
someday...

Oh, and I became the linux-kernel Documentation maintainer, which is
seriously filling up my inbox.

>  Anyhow... you left me with a pretty open-ended question ("What
> kind of linux distro), so I'll respond by saying:
> 
> 1. A very small distro acting almost like a firmware for the device
> (desktop, laptop, router, DVR, smart phone, etc) just to get the user to
> the point where (s)he can focus on their work.  After all, do one thing
> and do it well!

Define "their work"?

I did "boot to a shell prompt on serial console, with native development
tools", targeting various qemu platforms. This let people build code
natively.

I didn't really tackle "what tools do you need on target", because
everybody's needs are different and if you can build it natively, you've
got wget and a toolchain.

The proliferation of boards is kind of amazing. A half-dozen projects
from buildroot to OpenEmbedded accumulated buckets of board
configurations, but never cleanly separated them out from toolchain and
root filesystem config, and I decided the correct thing to do was get
defconfigs upstream into linus's git.

> 2. Although the OS can be installed and run from a storage device, it's
> intended to take a minimal amount of memory as it's home - RAM based. 
> This should make upgrading as simple as replacing a single file!

I remember ten years ago working out how to combine a kernel and root
filesystem into a single file, and patching lilo to have a "length"
parameter so it would only load the kernel and not the whole root
filesystem into memory.

  http://landley.net/aboriginal/old

I even worked out some unused space in the ELF header (for user mode
linux, the emulator I was using at the time) which was the old floppy
boot sector on real kernels so either way "unused space" that I could
stamp a 4 byte length to say what offset losetup should use creating the
loopback file for the root filesystem. (I used zisofs because squashfs
wasn't merged yet.) Getting an initrd built into the kernel so it could
do the loopback setup and hand off is what got me poking at initramfs in
the first place...

Good times, good times...

> 3. Having an easily usable interface that's common among the various
> devices while being as simplistic and efficient as possible.

Shell prompt?  xfce?  Web gui for headless boxes?

Just getting the _drivers_ right for a wide variety of boards was a huge
pain for me, and I was focusing on qemu. And I have to regression test
them every kernel release and bisect some really nasty stuff sometimes.
(I'm doing a writeup the most recent round of git bisect to teach people
how to bisect bugs under adverse conditions. The one that broke armv5l's
scsi driver was buried several bugs deep behind "the serial console
broke", "build break", and so on...)

> 4. A better, more logical division of the system and user for various
> reasons.

Um, like Apple did with macosx? Like that /usr->/usr/bin move? Like
gobolinux where they just went "screw it" and moved everything for no
apparent reason?

> While those are just a handful of ideas behind the distro, I'm not sure
> if that's what you were looking for.  Currently the distro (named XiniX
> - pronounced "zen ics") uses busybox, but I'd love to replace it with
> toybox once the required binaries are incorporated.

I'm all for it...

> I'd also like to
> say that looking over some of the ideas behind your aboriginal Linux, I
> can easily see it as a server edition used for VM's for a small/medium
> sized organization (or even an SDK via VM's).

I started by trying to provide the simplest system that can rebuild
itself under itself. Over time, that expanded to being able to cross
compile it to an arbitrary target and run it as a build environment
under an emulator.

That's pretty much where I stop. I provide a basic tool, what people do
with it from there I'm intentionally agnostic about because there are a
more use cases for a knife than for nail clippers and vegetable peelers
combined.

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.