[Aboriginal] Refactoring/recycling

Tristan Van Berkom tristan.vanberkom at codethink.co.uk
Mon Sep 12 20:32:22 PDT 2016

Hi Rob,

Thanks for clarifying and answering some of my questions.

If Aboriginal cannot continue in it's present form (or at least not for
the immediate future), it still has been a great demonstration of how
an OS should ideally be bootstrapped and built deterministically.

Thank you for this.

Few comments in line...

On Mon, 2016-09-12 at 13:02 -0500, Rob Landley wrote:
> On 09/12/2016 06:41 AM, Tristan Van Berkom wrote:
> > 
> > On Fri, 2016-09-09 at 19:28 -0500, Rob Landley wrote:
> > > 
> > > I've been breaking aboriginal linux down for parts. It's just too
> > > much
> > > of a giant hairball, despite my attempts to separate it into
> > > layers.
> > > 
> > Hi Rob,
> > 
> > So just to understand, since I have some interesting work based on
> > this
> > by now, what is going to be the end result of using the musl-cross-
> > make 
> > approach in Aboriginal ?
> The project  has been mothballed for several months while I tried to
> decide how to move forward, and now I've got an approach I want to
> try.
> So what this means is development is resuming, albeit in a different
> direction.
> The fundamental constraints are:
> 1) I will NEVER host GPLv3 binaries anywhere on my own dime
> 2) my old toolchain is now far enough behind the kernel build is
> breaking badly every release
> 3) LLVM (especialy lld, without which you're stuck using GPLv3
> binutils)
> isn't ready yet
> When LLVM becomes ready, I may reassemble something like the original
> aboriginal linux. But for now, I _have_ to break it up into packages
> I
> can develop and packages I passively consume (I'll send back bug
> reports
> but not code). And if I'm going to break it up anyway, I might as
> well
> reexamine the design and see what belongs where.
> Note: if my aversion to GPLv3 was the kind of thing I "got over", I
> would be a Windows developer. This is a "hell no, death first" kind
> of
> thing. It's 2016 and I don't have a Facebook account because I don't
> _want_ one. I'll read a facebook page somebody links me to if it lets
> me
> without a login, I'll sit down at somebody else's windows machine to
> web
> surf or play a game. But I won't create an account or write code that
> only runs on windows the platform (it can be ported _to_ it).
> Similarly
> I won't host GPLv3 binaries on a site I control or write GPLv3 code
> in a
> hobbyist context (but an employer can pay me to).


Rob, I am getting the sense that you misread me as hostile in some way,
I really hope not, its was not my intention to be provocative. I really
just wanted to get the bottom line of the Aboriginal story and how it
can affect end users like myself.

When I started my work you made it clear that you would not distribute
GPLv3 binaries on infrastructure under your control - It seems this
stance of yours has changed, and that now you are unwilling to
incorporate and host scripts (under any license) which they themselves
provide a mechanism for *building* GPLv3 code.

This is your choice and I *really* don't blame you for it, really.

I will say though, honestly I find it frustrating that a few times (not
every time) I try to have a technically constructive conversation, it
seems to side track into a GPL discussion, which frankly does not
interest me (I have had my share of heated discussion with rms and this
is just not my kind of thing, sorry).

> My compiler was GPLv2. I will never ship GPLv3 binaries. (This is
> part
> of the reason I'm slowly switching my interest to Android from
> conventional Linux: GPLv3 is a proprietary license and I'd only work
> on
> code under that license if paid to do so by a large corporation whose
> legal department stood between me and the FSF loonies. So far, the
> corporations all feel the same way about it I do.)
> Your GPLv3 fork is just that: a fork. It's part of the reason I
> mothballed Aboriginal Linux, I assumed that the userbase would
> fragment
> and half the people wouldn't be using my code so why bother fixing up
> the old toolchains?

To be frank here, a large part of my motivation for doing this work in
public was due to your stating to me on irc that you would consider
including an optional GPLv3 toolchain build in Aboriginal proper, while
conceding that the GPLv2 toolchain was bitrotting and users need
something more modern.

It was certainly _not a fork_ in the traditional sense (only a "fork"
as far as github has bastardized the actual meaning of the word).

It is in fact only a proposed patch to Aboriginal which you are free to
accept or not. Were it a fork, I would not have went to such lengths to
allow builds of both toolchains and the scripts would be cleaner this
way of course.

> > Honestly there are a variety of reasons why I prefer using an LFS
> > type
> > of build (but automated) based on aboriginal over using the yocto
> > approach of cross compiling all the way up the stack, but I think
> > openembedded have come a long way in terms of configuring the base
> > kernel/compiler/qemu and it would be great to leverage that. It
> > also
> > has a similar approach to aboriginal here (inasmuch as it uses a
> > machine conf, like aboriginals target files).
> If you prefer openembedded, feel free to use it?

I think I just plainly stated above that I prefer a from scratch
approach based on an Aboriginal bootstrap over cross compiling all the
way up the stack, sorry if I was not clear enough: I'm only mentioning
the openembedded stuff because I think there is some valuable knowledge
which can be salvaged from the yocto train wreck while creating a
superior solution (to put things a bit more plainly).

In any case, I'm *really* not bitter about not landing my patches in
Aboriginal proper, and I look forward to seeing what comes together
with musl-cross-make and the next generation of Aboriginal, I'm sure it
will be great.

Best Regards,

More information about the Aboriginal mailing list