[Aboriginal] Fwd: greetings!

[David Henderson]

On Wed, Jul 18, 2012 at 10:09 PM, Rob Landley <rob at landley.net> wrote:

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

Sure!  It never hurts to hear what others have to say right? :)


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

No I didn't, but did started to early this morning.  I'll have to come back
to it however, as I was more interested in the other referenced material
below.  I'll see about completing it over the weekend.


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


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".  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.  Programs outside
of our "official" umbrella will be left to the community to add to (and
maintain) the software repositories.


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

Which aspect - adding software "on demand" or combining software as part of
the users "personal data"?


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

What were you using as the graphics backend?  X11, DirectFB, etc?


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

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?


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

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:

* FIRMWARE (prefix is /) *
bin - stores publicly accessible binaries like mount, grep, tar, etc
etc - stores firmware configurations
lib - stores firmware shared libraries
sbin - stores administrator/system binaries mkfs, hdparam, ifconfig, etc
var - stores data like firmware logs, pid files, etc

* PERSONAL (prefix is /home/$USER) *
.bin - stores software specific for the user (e.g. pidgin, chatzilla, etc)
.etc - stores personal configuration for personal AND community software
.lib - stores shared libraries for personal software
.var - stores logs, pid files, etc for personal AND community software
NOTE: there's no .sbin since there really shouldn't be unusable binaries
for personally (or community) installed software

* COMMUNITY (prefix is /home/Public) *
.bin - stores software for all the users of the device so that one instance
of software isn't installed and maintained per user (e.g. OpenOffice.org),
plus it can save space
.etc - stores general configuration for community software (e.g. firefox)
.lib - stores shares libraries for community software
.var - stores logs and other info for community software (e.g. mplayer,
firefox, etc)
NOTE: there's no .sbin since there really shouldn't be unusable binaries
for personally (or community) installed software


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


>
> >         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.
>
>
I'll be interested to read it! :)

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal-landley.net/attachments/20120723/8f7d2773/attachment-0002.htm>