<div class="gmail_quote">On Wed, Aug 1, 2012 at 7:12 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">

<div>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>
</div>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></blockquote><div><br>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! :)  The XiniX "firmware" already has several external mount binaries included (mount.cifs and mount.ntfs), so it shouldn't be a problem either way. :)<br>

 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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></blockquote><div><br>Have you run into any problems with dropbear over openSSH?  Aside from the small size, are there any benefits of using dropbear?<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><br>
> - ssl (for secured headless devices or other communication)<br>
<br>
</div>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></blockquote><div><br>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?<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><br>
> - ssmtp (or similar) for automated outbound communication of device<br>
<br>
</div>busybox has had a "sendmail" command for a while now.<br></blockquote><div><br>How easy is it to get the BB sendmail working?  I was able to get sSMTP up and running in a few minutes...<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><br>
> * optional alsa (for sound enabled devices)<br>
> * optional graphics software for headed devices (headless will already<br>
> be handled via clAPI)<br>
<br>
</div>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></blockquote><div><br>Yes, the "graphics software for *headed* devices" is somewhat general, but will include things like GTK, QT, Awesome WM, etc).  This area is device-specific, but can be setup easily via the installation of the "firmware" for the device.<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><br>
> Items such as mplayer, samba, rdesktop, okular, perl, rsync, etc will be<br>
> outside the scope of the "firmware" because they aren't required 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>
</div>Well, good luck with it.<br></blockquote><div><br>I take it you don't think that will be the case. :)  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.<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><br>
> Regarding the musl switch over, I had no clue that uClibc has been<br>
> shelved for so long!<br>
<br>
</div>Yeah, it got run over by buildroot as I explained here:<br>
<br>
  <a href="http://landley.net/aboriginal/history.html" target="_blank">http://landley.net/aboriginal/history.html</a><br>
<br>
(I _really_ need to finish that page at some point.)<br>
<br>
In theory uClibc development is unstuck now but its baseline development<br>
rate is way way way slower than it used to be, because the project is<br>
bloated and has decades of history nobody really seems to understand<br>
anymore.<br>
<br>
Here's the start of a long "uClibc has a problem" thread from 2007<br>
talking about stagnation _then_ which wasn't fixed for another 3-4 years:<br>
<br>
  <a href="http://lists.uclibc.org/pipermail/uclibc/2007-September/039215.html" target="_blank">http://lists.uclibc.org/pipermail/uclibc/2007-September/039215.html</a><br>
<br>
I started sending the maintainer a cake when it had been a year between<br>
releases back in 2005:<br>
<br>
<a href="http://lists.uclibc.org/pipermail/uclibc/2005-January/010877.html" target="_blank">http://lists.uclibc.org/pipermail/uclibc/2005-January/010877.html</a><br>
<a href="http://lists.uclibc.org/pipermail/uclibc/2006-December/037750.html" target="_blank">http://lists.uclibc.org/pipermail/uclibc/2006-December/037750.html</a><br>
<br>
Here's the 2006 OLS paper on NPTL support for uClibc:<br>
<br>
  <a href="http://kernel.org/doc/ols/2006/ols2006v1-pages-409-420.pdf" target="_blank">http://kernel.org/doc/ols/2006/ols2006v1-pages-409-420.pdf</a><br>
<br>
It took ~5 years for that to actually get merged and supported on all<br>
targets. What happened was sjhill refused to merge his work until he was<br>
paid for it, and other people got into the habit of doing extensive work<br>
in their own private forks. The maintainer had mostly wandered off to do<br>
other things (buildroot, his own business) and didn't police this, so it<br>
got to the point where they were actively driving _away_ anybody who<br>
committed to the main fork (because it made them do extra work merging<br>
stuff into their private forks).<br>
<br>
Towards the end of 2008 I appointed a new uClibc maintainer more or less<br>
by fiat to try to fix this:<br>
<br>
<a href="http://lists.uclibc.org/pipermail/uclibc/2008-October/041191.html" target="_blank">http://lists.uclibc.org/pipermail/uclibc/2008-October/041191.html</a><br>
<br>
But they didn't get NPTL support into all architectures and actually<br>
working for something like two years after that. Basically the tree was<br>
such a horrible mess at that point, with at least _three_ independent<br>
NPTL implementations for various architectures (because sjhill wouldn't<br>
show anybody his code), that cleanup work took a long time.<br>
<br>
Development finally got moving forward again under that new maintainer a<br>
couple years ago, but it's very slow and there's a huge amount of<br>
inertia. The eglibc project arose because of the vacuum created by<br>
uClibc's stagnation, for example.<br>
<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></blockquote><div><br>Wow what a mess!<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><br>
> Why wouldn't the switch to musl be more critical?<br>
<br>
</div>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></blockquote><div><br>How often is your software used with those other architectures?  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! :)<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><br>
> Not only would you get actively developed software, but the speed<br>
> increases as shown in one of the links below.<br>
<br>
</div>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></blockquote><div><br>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.<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><br>
> I can see your point about standardization in the qwerty keyboard<br>
> example provided, however, because of how Linux has evolved compared to<br>
> the design goals of the XiniX distro, it's easier to manage the OS by<br>
> separating it as I have.  Otherwise, there would be an unwieldy amount<br>
> of mounts to maintain with software and configs going in various places<br>
> (e.g. /bin, /usr/bin, /usr/local/bin, /usr/share, etc).  The layout for<br>
> XiniX is uniform and makes sense where things are located and why.<br>
<br>
</div>Good luck reinventing the wheel.<br></blockquote><div><br>Thanks, hopefully this one will be made of rubber and not stone! :)<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><br>
> Thanks for all the articles on the GPLv2 vs GPLv3 - lots of reading to<br>
> do!  I'm sure I'll have more questions for you once I'm done. :)<br>
<br>
</div>I need to write up a unified explanation of that. I need to finish the<br>
history page I linked to earlier. I need to write up the<br>
git-bisect-howto follow up I've had half-finished for 3 months. I need<br>
to catch up on my email...<br>
<span><font color="#888888"><br>
Rob</font></span><br>
</blockquote></div><br>Dave<br>