[Aboriginal] Fwd: greetings!

[Rob Landley]

My inbox got out of control and I'm catching up, but about half a month
behind. If I answer some duplicates, now you know why.

On 08/02/2012 09:52 AM, David Henderson wrote:
> On Wed, Aug 1, 2012 at 7:12 AM, Rob Landley <rob at landley.net
> <mailto:rob at landley.net>> wrote:
> 
>     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.
> 
> I did a quick look at the busybox mount help, but didn't see any -o
> parameters for specifying certain values (e.g. user,pass,dom,etc) to
> mount network shares.  Perhaps some testing is in order! :)

it worked fine circa 2006, which is when I stopped banging on it.  user=
and pass= are kernel level options. Any unrecognized options are (or at
least should be) passed to the kernel as a comma-separated string for
parsing by the filesystem driver. Only the VFS flag options should get
spliced out, and I've been re-examining those doing research for toybox
mount.

http://lists.landley.net/pipermail/toybox-landley.net/2012-August/000628.html

The problem with pass is you don't want to say "pass=" on the command
line or other users on the same system could see it, which is why you
have a helper prompt you for the password from stdin. But if you don't
mind that, supplying it from the command line should work. Not sure the
escape syntax for commas, might need to be the last option in the list.

The other problem is the kernel can't (sanely) do DNS lookup, so you
need to resolve names to IPs after recognizing such in the mount URL
format, which is the other thing a mount helper does.

>  The XiniX
> "firmware" already has several external mount binaries included
> (mount.cifs and mount.ntfs), so it shouldn't be a problem either way. :)

Good luck with it then.

>     > - ssh
> 
>     I've got static dropbear binaries up at
>     http://landley.net/aboriginal/bin natively built by a control-image.
> 
> Have you run into any problems with dropbear over openSSH?  Aside from
> the small size, are there any benefits of using dropbear?

Not really. The big frustration is that dropbear doesn't supply ssl.
I've poked at adding stunnel but it's one of my 8 gazillion "if I had a
spare summer" things...

>     > - 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?)
> 
> Shouldn't this be installed for (optional) secured headless web
> interfaces?  As an alternative to wget, curl can be used (which can be
> used with openSSL).  Any advantage either way?

In theory wget could be used with stunnel.

I generally find curl to be overcomplicted, but most people don't care
and just use what's provided. Neither is in SUSv4 or LSB.

>     > - ssmtp (or similar) for automated outbound communication of device
> 
>     busybox has had a "sendmail" command for a while now.
> 
> How easy is it to get the BB sendmail working?  I was able to get sSMTP
> up and running in a few minutes...

Not a clue, never used it. Just noting it's there.

>     > * 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"...
> 
> Yes, the "graphics software for *headed* devices" is somewhat general,
> but will include things like GTK, QT, Awesome WM, etc).

gtk _and_ qt.

> This area is
> device-specific, but can be setup easily via the installation of the
> "firmware" for the device.

*shrug* Good luck.


>     > 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.
> 
> I take it you don't think that will be the case. :)

Let's say I'm unlikely to believe it before seeing it.

> How many libraries
> will be used with the basic set of software listed above?  It should be
> far less than a typical distro, thus reducing the number of libraries
> required to run XiniX and as a result changes to "mainstream" libs won't
> have any bearing affect since they're not used.

I remember alpine linux, ubuntu jeos, and puppy linux...

The problem is there doesn't seem to be an obvious small set here.

>     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.
> 
> Wow what a mess!

*shrug* Bernard's doing his best, and it's nice to see it maintained again.

>     > 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.
> 
> How often is your software used with those other architectures? 

How often does anybody use sparc for anything?

http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg01238.html

> Obviously the most used are already covered under musl and with
> continued development with it instead of the stagnant uClibc, you could
> expand your coverage of the desired architectures in probably the same
> amount of time! :)

They're adding more, and qemu helps.

>     > 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.)
> 
> 
> Speed may not be a primary reason, but it sure is a nice benefit of a
> switch! :)  Your points above would seem to make my point even more
> valid about the switch from uClibc to musl.

I want to replace cross compiling with native development either on
target hardware or under emulation, but I also want to make cross
compiling to a new target as easy as possible to do.

Cross compiling busybox instead of a dozen random gnu packages is the
obvious way to go there: once you're on target you can bootstrap up to
LFS (which I have a script for, which desperately needs updating because
it's already a couple LFS releases behind).

I want the libc equivalent of busybox: simple, self contained, does its
job without too much fuss, doesn't necessarily handle ever corner case
in the universe.

Just the "there are three complete threading implementations in this
library and I don't know which ones work on which targets" part of
uClibc would have me looking around...

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.

 1345116056.0