On 11/03/17 00:43, Daniel Golle wrote:
Hi!
Good to see that lime is still alive after all.
I thought about some things which need to be taken care of and would
like to get some feedback and opinions:
* wouldn't it be great to finally use LEDE's SDK + ImageBuilder
instead of lime-build (which is hard to maintain)?
LEDE does rolling-release for packages and promissed regular
maintainace cycle for their releases. 17.01 just came out, 17.01.0
is already in the pipe, 17.01.1 will come in May/June, and so on.
suggestion: drop lime-build in favour of using the lime-packages
feed with the SDK to provide packages to be used with the
ImageBuilder.
If there is any real reason to fork LEDE and/or use custom builds,
please speak up, I'll be your advocate on board of the LEDE team
to resolve those issues.
I don't see a big difference between using the SDK and the standard
buildroot. So far the arguments in favor for using lime-build are the
same in my opinion. You can see lime-build as a configuration template
repository where we store different kind of profiles. So for instance
the ar71xx-mini target can have its own striped kernel configuration
file. And the different flavors of libremesh (like FreiFunk or Guifi)
can have their own set of packets predefined.
In the other side, IMO until LEDE does not demonstrate that we don't
need to froze a repository for releasing, I won't believe it. The
current (not yet confirmed!) dnsmasq problem for instance is an example,
it breaks everything in LiMe.
In any case, lime-build is used by many users in LibreMesh and I don't
see the point for dropping it. Using the SDK or the buildroot are
already possibilities that anyone can choose (this procedure is
documented on the README and also the web page). So feel free to use
whatever you feel more comfortable, we are not dogmatic people :)
About Imagebuilder, we are already using it on Chef and the ImageBuilder
binaries are available for downloading on our firmware repository.
* lime-config currently re-writes UCI configuration.
ie. if I mess
up /etc/config/network, running lime-config will not necessarily
fix it. There are also situations which make re-running lime-config
impossible as that would break the config completely. To resolve
that mess I suggest to refrain from re-writing UCI configuration and
rather generate it from scratch every time by using the new
/bin/config_generate script.
If anything is missing in that new board-config aka. uci-defaults
approach, then we should add it and discuss with upstream, ie. make
sure that all board-specific details needed to generate the entire
configuration are covered.
That sounds good to me. Let's open a GitHub issue to have this task on
the queue.
Hence I'd like to re-write lime-config from
scratch. And maybe use
Shell instead of Lua. I know, this may sound terrible, but I'm sure
it'd be a great step towards reusability of the code for other
projects (which may not use all the rest of LiMe, maybe not even
use Lua at all) and also make the lime firmware more robust and
cover more use-cases (such as re-configuring images on the go
rather than using CHEF or imagine changing things in the field
using some remote mass-management tools, I'm thinking of OpenWISP)
Here I fully disagree. One of the agreements we made on 2013 when we
joined our efforts was to not use bash anymore. We'd spent so many hours
maintaining a horrible bash based system... We don't want to do it
anymore. LUA is nice and small. The libremesh code is quite clean,
structured, modular and well done. So far I think that is one of the
strongest points of libremesh.
Furthermore lime-config is not only a script file named "lime-config" it
is also the set of libraries stored under /usr/lib/lua/lime. Those
libraries can also be used now for developing the new
websockets+rpc+json web interface and Android APP. And they would be
also used if we implement a central controller system or a console CLI
(like mikrotik or cisco).
About the re-usability of the code I think the current LUA code (mainly
the set of libraries) is much more reusable than a bash script monster
able to configure everything. In any case (IMO) the way to involve more
people and communities is to make LibreMesh flexible and modular so they
can base their firmware projects on LibreMesh. That was the idea from
the begging, make a OpenWRT/Lede meta distribution for mesh firmwares,
so anyone can have its own LiMe flavor. To this end a modular and clean
code and API are necessary.
To finish this point, I don't want to stop you for doing anything. If
you feel like you want to develop this bash script, go ahead and lets
see if we can integrate it somehow with the rest of components. But IMO
it is like starting a project from scratch.
* speaking about CHEF: what's happening on that
scene? I find CHEF
very complicated, but I'm not a web guy :( I saw it finally found
someone willing to maintain it. Is there a roadmap or something?
And how can people contribute documentation, localization and all
that? And will it move to github?
I agree. We need to put more efforts on chef. The problem is that no one
in the core team wanted to touch web stuff... However now it looks like
we have the guy :) So I'm pretty sure there will be improvements soon.
* hardware support: I think we should support more
hardware targets,
not just ar71xx, x86 and mt7621 (I do appreciate that mt7621 made
it to the current release!). I'm working a lot on MT7620 lately,
there are a terrible lot of devices out there and though this
chip (or driver...) does not allow combining Ad-Hoc + AP, it
apparently does allow combining 802.11s + AP!
I found this also when playing with a Nodewrt device. However, is
802.11s stable enough on mt7620 for using in a real mesh network? I
would like to know.
suggested additional hardware platforms, in random
order, high-
priotity is marked with an '!': !mvebu, !ramips/rt305x,
ramips/rt3883, !ramips/mt7620, !ramips/mt7628, !ramips/mt7688,
!ipq806x, !lantiq/xrx200, !lantiq/xway, octeon, !x86/generic,
x86/geode, !x86/64, arm64, armvirt, sunxi, mediatek,
brcm2708/bcm2708, brcm2708/bcm2709, brcm2708/bcm2710
(ie. all up-to-date platforms with good support in LEDE)
I don't know enough about the bcm53xx, brcm47xx and brcm63xx
targets to tell if any of those could be useful, but most likely
they can, especially those with brcmsmac or brcmfmac wifi.
For all others, especially those marked to be high-priority in
the list above, I'm more than willing to help and contribute
whatever is needed to get going.
Thanks for the list, very useful. The only reason why we have not
published binaries for this platforms is because we don't have hardware
to test them. But if you have access to all this hardware would be very
helpful if you could keep a repository of libremesh binaries (in
addition or together with
downloads.libremesh.org). We have server space
to create such repository (compile and publish) and can give you SSH
access. Using LEDE SDK for such task would work for me if you feel more
comfortable.
* speaking about 802.11s: should we switch to use the
802.11s MAC
by default? Ad-Hoc/IBSS has many known problems and nobody among
the people hacking the drivers seems to really care about it as
it's broken by design...
I also agree here. The main problem is that the first release based on
802.11s will break compatibility with the old releases and that would
make users angry. However the latter we do it the worst would be...
We have to discuss it with all the team and get a consensus.
Cheers
Cheers!
Daniel
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
--
./p4u