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". :)<br><br><br><div class="gmail_quote">On Thu, Aug 16, 2012 at 7:20 AM, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My inbox got out of control and I'm catching up, but about half a month<br>
behind. If I answer some duplicates, now you know why.<br>
<div class="im"><br>
On 08/02/2012 09:52 AM, David Henderson wrote:<br>
> On Wed, Aug 1, 2012 at 7:12 AM, Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a><br>
</div><div class="im">> <mailto:<a href="mailto:rob@landley.net">rob@landley.net</a>>> wrote:<br>
><br>
> On 07/26/2012 08:17 AM, David Henderson wrote:<br>
> > This email thread has started to become soup! So... I'll start a new<br>
> > paragraph so we can start over. :)<br>
> ><br>
> > Going back to the software included in the "firmware", the list should<br>
> > be very small and only allow the device to get to the point for user<br>
> > interaction. For example,<br>
> ><br>
> > - busybox (later toybox) for core functionality including user<br>
> > management, scheduling, etc<br>
> > - bash<br>
> > - clAPI (our own software)<br>
> > - the appropriate mount binaries for ext, ntfs, nfs, and smb/cifs<br>
><br>
> Once upon a time I wrote the busybox mount. (Well, rewrote it 3 times<br>
> until there was nothing left of the original.)<br>
><br>
> smb and nfs shouldn't need mount binaries, you can mount them with the<br>
> right -o command line. All the mount binary would do is prompt you for<br>
> password so you don't have to say pass= in the -o line in plaintext.<br>
><br>
> ext? shouldn't need a special mount binary, just the standard one and<br>
> the kernel module (if it's not static).<br>
><br>
> ntfs I'm not familiar with.<br>
><br>
> I did a quick look at the busybox mount help, but didn't see any -o<br>
> parameters for specifying certain values (e.g. user,pass,dom,etc) to<br>
> mount network shares. Perhaps some testing is in order! :)<br>
<br>
</div>it worked fine circa 2006, which is when I stopped banging on it. user=<br>
and pass= are kernel level options. Any unrecognized options are (or at<br>
least should be) passed to the kernel as a comma-separated string for<br>
parsing by the filesystem driver. Only the VFS flag options should get<br>
spliced out, and I've been re-examining those doing research for toybox<br>
mount.<br>
<br>
<a href="http://lists.landley.net/pipermail/toybox-landley.net/2012-August/000628.html" target="_blank">http://lists.landley.net/pipermail/toybox-landley.net/2012-August/000628.html</a><br>
<br>
The problem with pass is you don't want to say "pass=" on the command<br>
line or other users on the same system could see it, which is why you<br>
have a helper prompt you for the password from stdin. But if you don't<br>
mind that, supplying it from the command line should work. Not sure the<br>
escape syntax for commas, might need to be the last option in the list.<br>
<br>
The other problem is the kernel can't (sanely) do DNS lookup, so you<br>
need to resolve names to IPs after recognizing such in the mount URL<br>
format, which is the other thing a mount helper does.<br></blockquote><div><br>Nice to know! That would explain why they're missing from the BB help. :)<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> The XiniX<br>
> "firmware" already has several external mount binaries included<br>
> (mount.cifs and mount.ntfs), so it shouldn't be a problem either way. :)<br>
<br>
</div>Good luck with it then.<br>
<div class="im"><br>
> > - ssh<br>
><br>
> I've got static dropbear binaries up at<br>
> <a href="http://landley.net/aboriginal/bin" target="_blank">http://landley.net/aboriginal/bin</a> natively built by a control-image.<br>
><br>
> Have you run into any problems with dropbear over openSSH? Aside from<br>
> the small size, are there any benefits of using dropbear?<br>
<br>
</div>Not really. The big frustration is that dropbear doesn't supply ssl.<br>
I've poked at adding stunnel but it's one of my 8 gazillion "if I had a<br>
spare summer" things...<br></blockquote><div><br>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?<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> > - ssl (for secured headless devices or other communication)<br>
><br>
> How do you get anything else to use it? Dropbear is self-contained the<br>
> busybox web server and wget don't link against eternal libraries. (I<br>
> thought about makign them use stunnel but never got around to it. Did<br>
> that happen in my absence?)<br>
><br>
> Shouldn't this be installed for (optional) secured headless web<br>
> interfaces? As an alternative to wget, curl can be used (which can be<br>
> used with openSSL). Any advantage either way?<br>
<br>
</div>In theory wget could be used with stunnel.<br>
<br>
I generally find curl to be overcomplicted, but most people don't care<br>
and just use what's provided. Neither is in SUSv4 or LSB.<br></blockquote><div><br>cURL actually looks like it's more lightweight than wget too. :)<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> > - ssmtp (or similar) for automated outbound communication of device<br>
><br>
> busybox has had a "sendmail" command for a while now.<br>
><br>
> How easy is it to get the BB sendmail working? I was able to get sSMTP<br>
> up and running in a few minutes...<br>
<br>
</div>Not a clue, never used it. Just noting it's there.<br></blockquote><div><br>Ah, gotcha! I'll look into it when I get to that point...<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> > * optional alsa (for sound enabled devices)<br>
> > * optional graphics software for headed devices (headless will already<br>
> > be handled via clAPI)<br>
><br>
> Those were always very device-specific to me, but I've never understood<br>
> the various incarnations of the linux sound layer all that well (just<br>
> enough to really hate pulseaudio), and the phrase "graphics software for<br>
> headless devices" reads like "hats for the headless horseman"...<br>
><br>
> Yes, the "graphics software for *headed* devices" is somewhat general,<br>
> but will include things like GTK, QT, Awesome WM, etc).<br>
<br>
</div>gtk _and_ qt.<br></blockquote><div><br>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...<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> This area is<br>
> device-specific, but can be setup easily via the installation of the<br>
> "firmware" for the device.<br>
<br>
</div>*shrug* Good luck.<br>
<div class="im"><br>
<br>
> > Items such as mplayer, samba, rdesktop, okular, perl, rsync, etc<br>
> will be<br>
> > outside the scope of the "firmware" because they aren't required<br>
> to turn<br>
> > on a device, login, and get to either the prompt or blank desktop<br>
> > (GUI). The list above should enable a device to communicate/interact<br>
> > with other devices on the most basic level, but nothing beyond.<br>
> > Because the "firmware" is kept to an absolute minimum, I think any<br>
> > library API changes will not really disrupt the device from working.<br>
><br>
> Well, good luck with it.<br>
><br>
> I take it you don't think that will be the case. :)<br>
<br>
</div>Let's say I'm unlikely to believe it before seeing it.<br>
<div class="im"><br>
> How many libraries<br>
> will be used with the basic set of software listed above? It should be<br>
> far less than a typical distro, thus reducing the number of libraries<br>
> required to run XiniX and as a result changes to "mainstream" libs won't<br>
> have any bearing affect since they're not used.<br>
<br>
</div>I remember alpine linux, ubuntu jeos, and puppy linux...<br>
<br>
The problem is there doesn't seem to be an obvious small set here.<br></blockquote><div><br>I don't think those distros have the same design goals as XiniX though... :)<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> The upshot is that uClibc is no longer _simple_, and the "first mostly<br>
> works" version (0.9.24) was in 2003, and was the _eighth_ release that<br>
> year. There were then 2 releases in 2004, one in 2005, and NONE in the<br>
> whole of 2006. (Hence the sending of cakes.) The project still hasn't<br>
> recovered from that.<br>
><br>
> Wow what a mess!<br>
<br>
</div>*shrug* Bernard's doing his best, and it's nice to see it maintained again.<br>
<div class="im"><br>
> > Why wouldn't the switch to musl be more critical?<br>
><br>
> musl currently supports x86, x86-64, and arm. I currently have mips,<br>
> sh4, sparc, and powerpc working under uClibc.<br>
><br>
> There's a lot more potential in musl, but it's not fleshed out yet.<br>
><br>
> How often is your software used with those other architectures?<br>
<br>
</div>How often does anybody use sparc for anything?<br>
<br>
<a href="http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg01238.html" target="_blank">http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg01238.html</a><br>
<div class="im"><br>
> Obviously the most used are already covered under musl and with<br>
> continued development with it instead of the stagnant uClibc, you could<br>
> expand your coverage of the desired architectures in probably the same<br>
> amount of time! :)<br>
<br>
</div>They're adding more, and qemu helps.<br>
<div class="im"><br>
> > Not only would you get actively developed software, but the speed<br>
> > increases as shown in one of the links below.<br>
><br>
> I'm not doing it to speed up code, I'm doing it so that if I post a bug<br>
> report to the mailing list (and follow up repeatedly) it won't get<br>
> ignored for a year and a half.<br>
><br>
> I'd also like to switch to a libc implementation that hasn't got THREE<br>
> separate threading implementations.<br>
><br>
> <a href="http://lists.busybox.net/pipermail/uclibc/2008-September/041023.html" target="_blank">http://lists.busybox.net/pipermail/uclibc/2008-September/041023.html</a><br>
><br>
> And one where x86-64 support isn't a buggy afterthought:<br>
><br>
> <a href="http://lists.uclibc.org/pipermail/uclibc/2011-October/045835.html" target="_blank">http://lists.uclibc.org/pipermail/uclibc/2011-October/045835.html</a><br>
><br>
> (And no, glibc isn't even in consideration. It requires perl to build.)<br>
><br>
><br>
> Speed may not be a primary reason, but it sure is a nice benefit of a<br>
> switch! :) Your points above would seem to make my point even more<br>
> valid about the switch from uClibc to musl.<br>
<br>
</div>I want to replace cross compiling with native development either on<br>
target hardware or under emulation, but I also want to make cross<br>
compiling to a new target as easy as possible to do.<br>
<br>
Cross compiling busybox instead of a dozen random gnu packages is the<br>
obvious way to go there: once you're on target you can bootstrap up to<br>
LFS (which I have a script for, which desperately needs updating because<br>
it's already a couple LFS releases behind).<br>
<br>
I want the libc equivalent of busybox: simple, self contained, does its<br>
job without too much fuss, doesn't necessarily handle ever corner case<br>
in the universe.<br>
<br>
Just the "there are three complete threading implementations in this<br>
library and I don't know which ones work on which targets" part of<br>
uClibc would have me looking around...<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote></div><br>Dave<br>