[Aboriginal] Fwd: greetings!

[Rob Landley]

On 07/26/2012 08:17 AM, David Henderson wrote:
> This email thread has started to become soup!  So... I'll start a new
> paragraph so we can start over. :)
> 
> Going back to the software included in the "firmware", the list should
> be very small and only allow the device to get to the point for user
> interaction.  For example,
> 
> - busybox (later toybox) for core functionality including user
> management, scheduling, etc
> - bash
> - clAPI (our own software)
> - the appropriate mount binaries for ext, ntfs, nfs, and smb/cifs

Once upon a time I wrote the busybox mount. (Well, rewrote it 3 times
until there was nothing left of the original.)

smb and nfs shouldn't need mount binaries, you can mount them with the
right -o command line. All the mount binary would do is prompt you for
password so you don't have to say pass= in the -o line in plaintext.

ext? shouldn't need a special mount binary, just the standard one and
the kernel module (if it's not static).

ntfs I'm not familiar with.

> - ssh

I've got static dropbear binaries up at
http://landley.net/aboriginal/bin natively built by a control-image.

> - ssl (for secured headless devices or other communication)

How do you get anything else to use it? Dropbear is self-contained the
busybox web server and wget don't link against eternal libraries. (I
thought about makign them use stunnel but never got around to it. Did
that happen in my absence?)

> - ssmtp (or similar) for automated outbound communication of device

busybox has had a "sendmail" command for a while now.

> * optional alsa (for sound enabled devices)
> * optional graphics software for headed devices (headless will already
> be handled via clAPI)

Those were always very device-specific to me, but I've never understood
the various incarnations of the linux sound layer all that well (just
enough to really hate pulseaudio), and the phrase "graphics software for
headless devices" reads like "hats for the headless horseman"...

> Items such as mplayer, samba, rdesktop, okular, perl, rsync, etc will be
> outside the scope of the "firmware" because they aren't required to turn
> on a device, login, and get to either the prompt or blank desktop
> (GUI).  The list above should enable a device to communicate/interact
> with other devices on the most basic level, but nothing beyond.
> Because the "firmware" is kept to an absolute minimum, I think any
> library API changes will not really disrupt the device from working.

Well, good luck with it.

> Regarding the musl switch over, I had no clue that uClibc has been
> shelved for so long!

Yeah, it got run over by buildroot as I explained here:

  http://landley.net/aboriginal/history.html

(I _really_ need to finish that page at some point.)

In theory uClibc development is unstuck now but its baseline development
rate is way way way slower than it used to be, because the project is
bloated and has decades of history nobody really seems to understand
anymore.

Here's the start of a long "uClibc has a problem" thread from 2007
talking about stagnation _then_ which wasn't fixed for another 3-4 years:

  http://lists.uclibc.org/pipermail/uclibc/2007-September/039215.html

I started sending the maintainer a cake when it had been a year between
releases back in 2005:

http://lists.uclibc.org/pipermail/uclibc/2005-January/010877.html
http://lists.uclibc.org/pipermail/uclibc/2006-December/037750.html

Here's the 2006 OLS paper on NPTL support for uClibc:

  http://kernel.org/doc/ols/2006/ols2006v1-pages-409-420.pdf

It took ~5 years for that to actually get merged and supported on all
targets. What happened was sjhill refused to merge his work until he was
paid for it, and other people got into the habit of doing extensive work
in their own private forks. The maintainer had mostly wandered off to do
other things (buildroot, his own business) and didn't police this, so it
got to the point where they were actively driving _away_ anybody who
committed to the main fork (because it made them do extra work merging
stuff into their private forks).

Towards the end of 2008 I appointed a new uClibc maintainer more or less
by fiat to try to fix this:

http://lists.uclibc.org/pipermail/uclibc/2008-October/041191.html

But they didn't get NPTL support into all architectures and actually
working for something like two years after that. Basically the tree was
such a horrible mess at that point, with at least _three_ independent
NPTL implementations for various architectures (because sjhill wouldn't
show anybody his code), that cleanup work took a long time.

Development finally got moving forward again under that new maintainer a
couple years ago, but it's very slow and there's a huge amount of
inertia. The eglibc project arose because of the vacuum created by
uClibc's stagnation, for example.

The upshot is that uClibc is no longer _simple_, and the "first mostly
works" version (0.9.24) was in 2003, and was the _eighth_ release that
year. There were then 2 releases in 2004, one in 2005, and NONE in the
whole of 2006. (Hence the sending of cakes.) The project still hasn't
recovered from that.

> Why wouldn't the switch to musl be more critical? 

musl currently supports x86, x86-64, and arm. I currently have mips,
sh4, sparc, and powerpc working under uClibc.

There's a lot more potential in musl, but it's not fleshed out yet.

> Not only would you get actively developed software, but the speed
> increases as shown in one of the links below.

I'm not doing it to speed up code, I'm doing it so that if I post a bug
report to the mailing list (and follow up repeatedly) it won't get
ignored for a year and a half.

I'd also like to switch to a libc implementation that hasn't got THREE
separate threading implementations.

  http://lists.busybox.net/pipermail/uclibc/2008-September/041023.html

And one where x86-64 support isn't a buggy afterthought:

  http://lists.uclibc.org/pipermail/uclibc/2011-October/045835.html

(And no, glibc isn't even in consideration. It requires perl to build.)

> I can see your point about standardization in the qwerty keyboard
> example provided, however, because of how Linux has evolved compared to
> the design goals of the XiniX distro, it's easier to manage the OS by
> separating it as I have.  Otherwise, there would be an unwieldy amount
> of mounts to maintain with software and configs going in various places
> (e.g. /bin, /usr/bin, /usr/local/bin, /usr/share, etc).  The layout for
> XiniX is uniform and makes sense where things are located and why.

Good luck reinventing the wheel.

> Thanks for all the articles on the GPLv2 vs GPLv3 - lots of reading to
> do!  I'm sure I'll have more questions for you once I'm done. :)

I need to write up a unified explanation of that. I need to finish the
history page I linked to earlier. I need to write up the
git-bisect-howto follow up I've had half-finished for 3 months. I need
to catch up on my email...

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.