[Olsr-dev] lua in olsrd sources

[Markus Kittenberger]

why not just remove this plugin,..

Markus

On Thu, Feb 9, 2012 at 5:35 PM, Hans-Christoph Steiner <
(spam-protected)> wrote:

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