[Aboriginal] Fwd: Re: greetings!

[Rob Landley]

And the next bit. Caught up now, I think.

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

On 07/18/2012 08:13 AM, David Henderson wrote:
> Just following-up, I know you're a busy person. :)
> 
> Dave

Do you mind if I copy this to the aboriginal mailing list? People keep
emailing me off-list and I really should cc: the list to keep the
cobwebs and tumbleweeds down...

> On Thu, Jul 12, 2012 at 10:24 AM, David Henderson
> <dhenderson at digital-pipe.com <mailto:dhenderson at digital-pipe.com>> wrote:
> 
>     Wow and I often complain about my schedule! :)  Seems like you're
>     working on 28 hour work days! lol  This might be a good opportunity
>     for you to possibly offload some work then - at least on the distro
>     creation/maintenance side.

I'd love to. Did you ever read the presentation I have linked from the
left edge of http://landley.net/aboriginal ? The "html" version is
probably the most easily legible. (The PDF is the same but it's 90 megs
thanks to Apple impress being inefficient. The raw text one is harder to
follow, It think.)

It's a bit stale, but describes the design goals pretty well. Not just
what I did, but more importantly _why_.

>     My replies are in-line below to prevent confusion...
...
>     Their "work" would be anything the user normally does during the
>     day: email, word processing, listen to music, watch videos, program,
>     etc.

That's a full distro. As the presentation I mentioned covers, there are
a lot of distros out there already, which maintain enormous package
repositories with dependency information and build recipes and install
information and all that, and it's a full-time team of a dozen or more
people for each distro. Fedora and SuSE and Mandrivia do RPM, Debian and
Ubuntu do dpkg, Gentoo does Portage, Slackware does its tarballs, arch
linux has pacman, openembeded has its bitbake recipes, and so on.

Buildroot fell into the trap of doing that, and it pretty quickly took
up all their time. I made the explicit decision _not_ to do that. I
produced a native build environment on target and then _stopped_.

Separately, there's the control images:

  http://landley.net/hg/control-images
  http://landley.net/aboriginal/control-images

But that's designed to be as orthogonal as possible, I just haven't had
_time_ for that recently. (You'll notice the automated linux from
scratch build is a couple versions behind already, 6.8 I think.)

What I _wanted_ to do was natively bootstrap distros under the target
build environment, but it turns out that Fedora assumes it's building on
Fedora, and Debian assumes it's building on Debian, and even Gentoo
adamantly _refuses_ to build under anything but gentoo and how you
bootstrap from a bare environment is undocumented black magic you have
to reverse engineer. I was doing that, but wandered off to do toybox,
and until toybox goes 1.0 I'm unlikely to have time to work on control
images. I'm not really properly keeping up with kernel, busybox, and
uClibc package releases in the base system...

>  While the distro won't contain all of the software for
>     everyones "work" (e.g. CAD users), it'll start with a set of
>     software to perform the most common tasks.  As time elapses, more
>     and more can be added to include users with more rare "work".  This
>     software, however, will be installed with their "personal data" as
>     mentioned below.

I found it to be a can of worms.  Read the presentation for details.

>     Wow thats pretty interesting!  Currently XiniX uses grub, which I
>     don't think has an option like that.  Also, XiniX has the "firmware"
>     and Kernel separated (I didn't even know those two could be
>     combined).  I suppose the integration of the two can help maintain
>     system stability since everything is tested and released
>     together...  Did you ever run into any negative aspects when working
>     like this?  The only one I can see off the top of my head is that if
>     the distro isn't updated routinely, the kernel will get dated and
>     present exploitable bugs to crackers.

You can have the same problem with userspace.

It was just a packaging method. I could do it with the current stuff,
It's just qemu renders it less interesting, so I ship tarballs instead.

But that's what got me into initramfs, and why I wrote the initramfs
documentation (because I was an early adopter in the days you had to
read the code and ask the developers to see how to get it to work). I
needed some userspace code to run when the kernel came up to find and
mount the root filesystem and switch_root into it. (It's also why I
wrote a switch_root that wound up in busybox.)

>     Currently XiniX is CLI only, but hopefully by the end of next month
>     the graphical side will be up and running.

I got a gui running on the Qualcomm Hexagon natively built under
aboriginal by following the beyond linux from scratch instructions in
2010. (Alas, the scripts I wrote to do it were written on company time,
and stayed with Qualcomm. I haven't gotten around to recreating open
source versions yet...)

>  In order to keep the
>     size down while maintaining flexibility, the GUI is entirely
>     web-based so it works with head and headless devices in a uniform,
>     consistent way.  Also it does have software such as QT and/or GTK
>     installed for software that currently doesn't have a
>     web-interface-only alternative (and is also required for the webkit
>     backend).

I keep meaning to test more stuff out with uClibc++.  Especially since
that's being actively developeda gain...

But I also mean to switch gradually over from uClibc to musl...

>     Maintaining stability for various aspects such as the drivers
>     mentioned above can be a pain.  While there will have to be testing
>     and such for third party hardware, the business will release
>     "official" hardware that will obviously be tested with the XiniX
>     distro so that these issues won't be a factor as often.

I keep reading that as "Xilinx" and wondering how fast microblaze is
these days...

>         > 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?
> 
> 
>     Yeah something like that. :)  For example XiniX actually doesn't
>     have a /usr directory at all, but instead software is considered
>     "system" (which will be added to the firmware /bin, /sbin),
>     "personal" (~/.bin, ~/.sbin), or "community" (/home/public/.bin,
>     /home/public/.sbin).  This is done, again, to separate the system
>     from the user/userbase and is necessary for some of the design
>     goals.  There are a few other non-traditional aspects of the system too.

Sigh.

  http://landley.net/writing/hackermonthly-issue022-pg33.pdf

There's a corollary to Moore's Law, which applies it to software. It
says that 50% of what you know is obsolete every 18 months.

I have a corollary to that corollary, which says "The great thing about
Unix is it's the same 50% cycling out over and over." This is how it
gradually builds a userbase, because you can wander away from it for 5,
7, even 10 years and come back and still find your way around the basic
stuff (posix-2001 still more or less applies), whereas over in
windows-land they obsoleted Visual Basic and replaced it with .net, and
then obsoleted .net (whatever that was, they were never quite clear) in
favor of programming windows 8 in HTML5...

[google how microsoft lost the API war, by joel spolsky]

>         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.
> 
> 
>     That simple system would be ideal for a VM server though, don't you
>     think?  After all, that system should *not* contain anything but the
>     necessities to boot and run whatever, more complex systems via VM's
>     right?

The idea behind the control images is you run one within a system-image
for your target, it copies the read only filesystem into a chroot,
builds and installs packages into it, and when it's done tars up the
result and uploads the tarball to the host.

So you can automate any delta you like on top of the base system: I
don't have to care.

Probably I should document the control image stuff more thoroughly...

>     So are you trying to accomplish the goal of developing an SDK with
>     aboriginal Linux?  What are your goals and intended audience with
>     that distro?

It was in the presentation.html, but I should probably write up
something more _concise_.

I keep trying to do about.html but it's like trying to describe the uses
for a knife. It cuts, it spreads, you can whittle, it can be used for
self defense, you can throw it, you can clean your nails with it, it's a
basic flexible tool with minimal assumptions about its eventual use cases.

It's really easy to describe what a vegetable peeler is for. It peels
vegetables. That's about it.

>         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.
> 
> 
>     Looking at your signature, it reminded me of another questions I
>     wanted to ask you.  If I were to guess, I'd say that you were more
>     of a GPLv2 guy.  Having said that, and I know this could take up
>     pages worth of information, but as an overview why the dislike for
>     the GPLv3?  Perhaps 'dislike' isn't the right word, but I'm sure you
>     understand what I'm asking.

Heh.

Lemme do a separate email for that one.

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.

 1342847152.0