[Aboriginal] Fwd: greetings!
Rob Landley
rob at landley.net
Mon Aug 20 07:01:04 PDT 2012
A week or so back somebody suggested I drop toybox to focus on qcc. But
that's not what I want to do...
Rob
On 08/16/2012 08:50 AM, David Henderson wrote:
> No problem, I know how it is to get backed up once in a while. Perhaps
> you need to get rid of any non-essential responsibilities to give you
> some more "free time". :)
>
>
> On Thu, Aug 16, 2012 at 7:20 AM, Rob Landley <rob at landley.net
> <mailto:rob at landley.net>> wrote:
>
> 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>
> > <mailto: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.
>
>
> Nice to know! That would explain why they're missing from the BB help. :)
>
>
>
> > 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...
>
>
> If dropbear doesn't have security without a wrapper such as stunnel,
> then I'd say there really isn't any cost savings by using it. Briefly
> looking into stunnel informed me that it relies on OpenSSL (which would
> already need to be installed to get shttp working). Plus it looks like
> dropbear is only "ssh", not scp or sftp, providing 1/3 of the benefits.
> Thoughts?
>
>
>
> > > - 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.
>
>
> cURL actually looks like it's more lightweight than wget too. :)
>
>
>
> > > - 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.
>
>
> Ah, gotcha! I'll look into it when I get to that point...
>
>
>
> > > * 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.
>
>
> GTK will have to be installed for minimal local GUI since one of the
> main packages relies on it. QT should just be made available as a
> installable package via the software repository. As a side note, what
> do you think of wxWidgets? It's the lightest of all the GUI toolkits,
> but does have some disadvantages too...
>
>
>
> > 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.
>
>
> I don't think those distros have the same design goals as XiniX though... :)
>
>
>
> > 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...
>
>
> Dave
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
1345471264.0
More information about the Aboriginal
mailing list