[Aboriginal] Fwd: greetings!

Rob Landley rob at landley.net
Wed Jul 25 12:10:46 PDT 2012

On 07/23/2012 07:41 AM, David Henderson wrote:
> On Wed, Jul 18, 2012 at 10:09 PM, Rob Landley <rob at landley.net
>     >     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.
> Combined, you're right that is a full distro, however, XiniX is just the
> "firmware" to get the user to the point where (s)he can do the "work",
> but doesn't include the software to actually do the "work".

That line turns out to be hard to draw, or at least I found it so.

> Basically
> our goal will be to create XiniX and a base set of weblications to
> perform basic tasks - surfing the Internet, communication (email, IM,
> IRC, etc), and office tasks (Word Processing, Spreadsheets, etc) as well
> as some common "at home" tasks like watching movies, playing music,
> etc.

There's an old problem in computer science: users only use 20% of your
app's features. But they can't agree on which 20%.

> Programs outside of our "official" umbrella will be left to the
> community to add to (and maintain) the software repositories.

There are literally hundreds of linux distributions trying to do this
already. Just this week I bumped into

>     >  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.
> Which aspect - adding software "on demand" or combining software as part
> of the users "personal data"?

Figuring out which software to include, and maintaining the build
recipes when some library decides to change its API again and two
different packages need different versions of glib and so on...

>     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...)
> What were you using as the graphics backend?  X11, DirectFB, etc?

The board didn't have a graphics card so we exported the display to
other machines through the net. (We tried getting the vnc plugin of
x.org running but there was some problem, possibly not enough memory? I
forget. Might just have been not enough time.)

>     But I also mean to switch gradually over from uClibc to musl...
> Looking over the comparison chart at
> http://www.etalabs.net/compare_libcs.html, I can see that it looks like
> the developer of musl shares your design and coding philosophies.  How
> long will the transition to musl take?

No idea, but the real limiting factor (other than my shortage of time)
is when ports to the architectures I want to support show up.

uClibc has been stagnant for half a decade. It's unblocked a bit
recently but it's still impossible to bisect a problem between two
releases (trivial problem: they branch-then-tag. Bigger problem:
interstitial versions don't even compile.)

>     >     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
> Great article!  I actually wondered where all those directories came
> from. lol  I know it sounds like I'm no better than the others in the
> article that re-arrange the FS layout, but instead of having all these
> symlinked directories and crazy list of mounts, wouldn't it make more
> sense to just provide a common structure between the various aspects of
> the system?  To me, it also provides an easy way to store all user data
> (personal and community) under a single mount (/home).  For example:

The qwerty keyboard layout is universally acknowledged to suck.

Everybody can sit down at a qwerty keyboard and type on it.

The value _is_ that it's standardized. Not that the standard makes
sense. Thus the only way to get any sort of momentum behind an
alternative is to have somebody like Apple or Google behind it, and to
be consistent for about 5 years before anybody starts to care about the
new layout.

>     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]
> Joel's article was absolutely fascinating!  Thanks for sharing it!

The web not only has cool things on it now, it had cool things on it
before now. :)

> I've
> actually been telling people about the transition into the webosphere
> for many years now.  That's actually why I see XiniX being valuable to
> people and organizations!

The "transition to the webosphere" is what Google's Chromebooks were
trying to address, and they're still dinking at it:


It's what html5 is targeting. HTML5 fragmentation is fun to watch:


Even Windows 8 is requiring everything to be html5...

>     >     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.

I keep writing up _bits_ of it in various places.  I wrote up a couple
facets of "why busybox shouldn't move to gplv3 only" back in 2006:


The most recent two are here, talking about splitting the community and
undermining the network effects we'd benefitted from:


A quick search brought up a bunch of random blog entries that wing the
topic in passing.  I need to go through these too:


I'm assembling a list of topics at
http://landley.net/toybox/oldlicense.txt that I should cover in a once
and for all writeup.

(Oh, and
is really good, even if he's on the other side.)

> I'll be interested to read it! :)

Above is the slush pile. (And not even the _entire_ slush pile.) I need
to digest that into something manageable.

> Dave
> _______________________________________________
> Aboriginal mailing list
> Aboriginal at lists.landley.net
> http://lists.landley.net/listinfo.cgi/aboriginal-landley.net

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


More information about the Aboriginal mailing list