<div>why not just remove this plugin,..<br></div><div><br></div><div>Markus</div><br><div class="gmail_quote">On Thu, Feb 9, 2012 at 5:35 PM, Hans-Christoph Steiner <span dir="ltr"><<a href="mailto:hans@guardianproject.info">hans@guardianproject.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On 02/07/2012 11:37 AM, Bernd Petrovitsch wrote:<br>
> On Die, 2012-02-07 at 10:11 -0500, Hans-Christoph Steiner wrote:<br>
>> On Feb 4, 2012, at 7:51 AM, Bernd Petrovitsch wrote:<br>
> [....]<br>
>>> Perhaps Andreas T. - from which I more or less took over maintainership<br>
>>> ages ago - knows how/when/why the LUA interpreter ended up in there.<br>
>><br>
>> Its easy enough to make it build against an external version of Lua,<br>
>> and Lua is included in Debian, Ubuntu, Fedora, Mac OS X/Fink,<br>
>> MacPorts, Cygwin, etc.  Its also easy to build using MinGW.<br>
><br>
> Very probably - that is really not the problem.<br>
> But not the whole world is some well-known Linux distro on a<br>
> IBM-compatible PC (and from the pure deployed numbers of systems they<br>
> are actually not really that relevant. Yes, the PC world doesn't know or<br>
> fail to accept that. But that's another story ...).<br>
><br>
>> I think the path of least resistance would be to remove the lua<br>
>> sources and just build against external sources.  I can do the build<br>
>> part.<br>
><br>
> Strategically olsrd never used external libs (except of course libc but<br>
> that is always a special case).<br>
> One reason was that there were no real tempting candidates for anything,<br>
> e.g.<br>
> - glib, liboop or something similar for the main-loop.<br>
> - APR or something similar to "ease porting"</salesdroid> is<br>
>   IMHO for olrsd far more work to integrate, use and maintain then the<br>
>   gain because olsrd is quite small and compact anyways.<br>
> - a lib for the Dijkstra algo: I don't know if such a beast actually<br>
>   exists.<br>
><br>
> The next reason is that that lib should exist/work/be ported on all<br>
> supported platforms - at that time Linux distros, openwrt, *BSD, CygWin.<br>
><br>
> In an ideal world, you have cooperative people with sufficient know-how<br>
> and interest to work with who - at least - try new versions out and help<br>
> to nail bugs - both build time and run-time.<br>
> Well, the world was (much) less then ideal (and many thanks once more<br>
> for those who tried to make the world more ideal and who sent not only<br>
> bug reports but also patches fixing it locally for them at least).<br>
><br>
> The 3rd reason is that using external libs usually<br>
> a) implies run-time bloat because it is quite unlikely that a daemon<br>
>    needs really all of it.<br>
>    IIRC we actually avoided libm explicitly.<br>
>    So think twice about it in the embedded world.<br>
>    And you very probably get the run-time bloat even if you link the<br>
>    lib statically hoping the linker removes all unused parts (because<br>
>    most libs tend to have lots internal stuff which is not trivially<br>
>    avoidable).<br>
>    Try that with GNU-libc and see how much code is pulled in ....<br>
> b) implies another abstraction layer (the API of the lib) and at that<br>
>    time olsrd already had (far) too many of them internally (and Hannes<br>
>    Gredler and I tried to kill some of them mainly because the didn't<br>
>    buy anything and just costs performance and source code and run-time<br>
>    code bloat).<br>
>    Don't know about today.<br>
> c) you have to cope with their API - which maybe easy or not.<br>
> d) possibly handle with a changing API - both feature-wise and bug-wise.<br>
>    Compile-testing is easy, but that won't catch all changes -<br>
>    especially not the semantic ones.<br>
>    In the Linux distro area, the distributor handles updates etc. here,<br>
>    but who does it for openwrt, CygWin or *BSD?<br>
>    And there people actually update there systems once in a while too.<br>
><br>
> And the main issue with external libs is that historically openwrt<br>
> running on Linksys with 16 MB RAM[0] and other (somewhat) embedded stuff<br>
> were the main platform - and some not some random "PC Linux distro".<br>
> I don't know how that is today - Henning should know.<br>
><br>
> IMHO it's the maintainers opinion that counts and, consequently,<br>
> decision - the above is just my experience with (real) embedded Linux<br>
> systems[1] and view on that issue (and I purposely do not write (more<br>
> about;-) what I should have done ages ago or what I would do today if I<br>
> were in that position;-).<br>
><br>
> Kind regards,<br>
>       Bernd<br>
><br>
> [0]: That was - later on - the "L" edition. A stripped down version of<br>
>      openwrt (no webinterface or other bells and whistles) actually ran<br>
>      on the newer, smaller ones with smaller ones - 8 MB RAM.<br>
> [1]: Hardware with 128 MB RAM and 1 GB Flash-RAM is easy - just run some<br>
>      stripped down Linux distro on them. But there was hardware with 4<br>
>      MB Flash-RAM and and 16 MB RAM.<br>
<br>
</div></div>Thanks for the thorough explanation, I agree it makes perfect sense for<br>
a project like olsrd to avoid all libraries.  My essential point was not<br>
that olsrd should only target systems that include Lua, but rather when<br>
a system includes Lua, olsrd should use that one over the included one.<br>
 This is Debian policy, for example.<br>
<br>
Removing the Lua code from olsrd is much less important, its fine by me<br>
if the Lua sources stay there.  But Lua is a program that was built to<br>
be embedded, so its easy to build on just about any platform.<br>
Therefore, it would be easy for someone to download lua and included it<br>
into olsrd.  Having the sources there means that people will likely use<br>
the old version included with olsrd, security bugs and all, rather than<br>
get an up-to-date release.<br>
<br>
For a fun diversion, I've done a fair amount of work on very limited<br>
platforms, for example, I helped port Pure Data, a synthesis engine, to<br>
1st gen iPods, so 83Mhz ARM with 8MB RAM.  This was a Linux kernel with<br>
not much else but a super simple GUI, and the version of Pd was ported<br>
to use ints as much as possible, where normally the synthesis is all floats:<br>
<a href="http://www.youtube.com/watch?v=bMtOKvJFetk" target="_blank">http://www.youtube.com/watch?v=bMtOKvJFetk</a><br>
<span class="HOEnZb"><font color="#888888"><br>
.hc<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
--<br>
Olsr-dev mailing list<br>
<a href="mailto:Olsr-dev@lists.olsr.org">Olsr-dev@lists.olsr.org</a><br>
<a href="https://lists.olsr.org/mailman/listinfo/olsr-dev" target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-dev</a><br>
</div></div></blockquote></div><br>