Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

2016-06-19 Thread Daniel Curran-Dickinson 
On Sun, 2016-06-19 at 12:35 -0700, David Lang wrote: 
> On Sun, 19 Jun 2016, Daniel Curran-Dickinson wrote:
> 
> > On Thu, 2016-06-16 at 10:34 -0400, Aaron Z wrote:
> >> On Thu, Jun 16, 2016 at 4:03 AM, David Lang  wrote:
> >>> With Imagebuilder and things pre-compiled, what does it take to create an
> >>> image? I'm wondering if this is something that can be converted to a web 
> >>> UI
> >>> where we could have someone select stuff (or upload a config file) and 
> >>> have
> >>> the system spit out a custom tailored image a few seconds later.
> >>>
> >>> Something like this could do wonders to move people away from the 'base
> >>> image must contain what I need' mentality.
> >> Personally, I would like that (and wouldn't have a problem with
> >> waiting a half hour or an hour for a build to be done).
> >> For example, I don't need PPOE support on any of the hardware I use,
> >> many of the devices don't have a USB port, so I don't need USB
> >> support, its internal on an IPV4 network, so I don't need IPV6
> >> support, it would be nice to have Nano installed by default (hard to
> >> use vi over ssh from a phone that doesn't have an escape key :D).
> >> But that's just the perspective of a end user/sysadmin who has been
> >> using OpenWrt (and now LEDE) for 7-10 years.
> >
> > TBH I think the biggest reasons this hasn't already is:
> >
> > 1) People who want it don't care enough to work on it, or are the people
> > who don't know how to work it and and can't/don't fund someone who does.
> > 2) Infrastructure:  You need a server to host on and storage etc, and
> > this costs money or donations.
> 
> or don't know how to contribute funds to make something like this work.

That's what I meant by can't (and I agree that having some means of
hooking up community funders with community developers would be helpfu;
kind of like prpl but for community).

> 
> the LEDE home page under the "how can I help" talks about development and the 
> mailing list. I says nothing about how to contribute money or equipment.
> 
> David Lang
> 




___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

2016-06-19 Thread Daniel Curran-Dickinson 
On Thu, 2016-06-16 at 10:34 -0400, Aaron Z wrote: 
> On Thu, Jun 16, 2016 at 4:03 AM, David Lang  wrote:
> > With Imagebuilder and things pre-compiled, what does it take to create an
> > image? I'm wondering if this is something that can be converted to a web UI
> > where we could have someone select stuff (or upload a config file) and have
> > the system spit out a custom tailored image a few seconds later.
> >
> > Something like this could do wonders to move people away from the 'base
> > image must contain what I need' mentality.
> Personally, I would like that (and wouldn't have a problem with
> waiting a half hour or an hour for a build to be done).
> For example, I don't need PPOE support on any of the hardware I use,
> many of the devices don't have a USB port, so I don't need USB
> support, its internal on an IPV4 network, so I don't need IPV6
> support, it would be nice to have Nano installed by default (hard to
> use vi over ssh from a phone that doesn't have an escape key :D).
> But that's just the perspective of a end user/sysadmin who has been
> using OpenWrt (and now LEDE) for 7-10 years.

TBH I think the biggest reasons this hasn't already is:

1) People who want it don't care enough to work on it, or are the people
who don't know how to work it and and can't/don't fund someone who does.
2) Infrastructure:  You need a server to host on and storage etc, and
this costs money or donations.


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

2016-06-16 Thread David Lang 

On Thu, 16 Jun 2016, Aaron Z wrote:


it would be nice to have Nano installed by default (hard to
use vi over ssh from a phone that doesn't have an escape key :D).


If you are using Android, look at the hacker keyboard

https://play.google.com/store/apps/details?id=org.pocketworkstation.pckeyboard

it gives you a traditional keyboard (including escape)

David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

2016-06-16 Thread Aaron Z 
On Thu, Jun 16, 2016 at 4:03 AM, David Lang  wrote:
> With Imagebuilder and things pre-compiled, what does it take to create an
> image? I'm wondering if this is something that can be converted to a web UI
> where we could have someone select stuff (or upload a config file) and have
> the system spit out a custom tailored image a few seconds later.
>
> Something like this could do wonders to move people away from the 'base
> image must contain what I need' mentality.
Personally, I would like that (and wouldn't have a problem with
waiting a half hour or an hour for a build to be done).
For example, I don't need PPOE support on any of the hardware I use,
many of the devices don't have a USB port, so I don't need USB
support, its internal on an IPV4 network, so I don't need IPV6
support, it would be nice to have Nano installed by default (hard to
use vi over ssh from a phone that doesn't have an escape key :D).
But that's just the perspective of a end user/sysadmin who has been
using OpenWrt (and now LEDE) for 7-10 years.

Aaron Z

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

2016-06-16 Thread Jo-Philipp Wich 
Hi,

> With Imagebuilder and things pre-compiled, what does it take to create
> an image? I'm wondering if this is something that can be converted to a
> web UI where we could have someone select stuff (or upload a config
> file) and have the system spit out a custom tailored image a few seconds
> later.
> 
> Something like this could do wonders to move people away from the 'base
> image must contain what I need' mentality.

Such technology exists already and is used by some Freifunk communities
in Germany, see https://meshkit.freifunk.net/

It is not hard to wrap the IB into a gui, scheduling builds and
distributing resources (storage etc.) is the only difficult task about it.


~ Jo

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

2016-06-16 Thread David Lang 

On Tue, 14 Jun 2016, Daniel Curran-Dickinson wrote:


On Tue, 2016-06-14 at 11:05 -0700, David Lang wrote:

On Mon, 13 Jun 2016, Daniel Curran-Dickinson wrote:


On Mon, 2016-06-13 at 11:17 +0200, Jo-Philipp Wich wrote:

Hi,


Again I think you read too much into what I said (admittedly I do the
same myself, at times, as you well know)


fair enough, now we've both clarified and find that we are pretty much in 
agreement.



, but I wasn't saying there is
no use case for it, only that it's not the 'primary', or 'default' use
case.

By all means, I'm game for maximum flexibility that doesn't hurt the
primary use case.

In the case the 2TB+ drives, I was concerned that such support would come
*at the expense of* the primary use; fortunately it doesn't, but if it did,
I would argue against kernel options (for example) for making the support
the *default* (e.g. in buildbot builds), except maybe for something like x86
boards/use cases (in the case of x86 I'm not sure that limiting hardware
support to save space is in most cases necessary; other cases like default
userspace I'd argue should be kept consistent and changes from default
management with things like ImageBuilder.

In general I'm a fan of ImageBuilder because, provided the kernel support is 
there,
you can use the SDK and build whatever packages you want to add on, and use
ImageBuilder to generate images that use those packages (along with the standard
ones you still want), without getting in the way of the primary use case.


I generally compile my own images because I am tweaking even kernel options 
(disabling connection tracking on any build that's not a firewall for example), 
but getting better images and image generation would be very good.


With Imagebuilder and things pre-compiled, what does it take to create an image? 
I'm wondering if this is something that can be converted to a web UI where we 
could have someone select stuff (or upload a config file) and have the system 
spit out a custom tailored image a few seconds later.


Something like this could do wonders to move people away from the 'base image 
must contain what I need' mentality.



To a certain extent though, I question the need for something as restricted as 
OpenWrt
for the new bigger devices anyway; there are elements like netifd that would be 
good to
see continue, but I'm not sure that most of OpenWrt really makes as much sense 
when you're
not needing to squeeze maximum use out of very erase block, and that therefore, 
while it
may be a smaller market/mindshare, that focussing on the the true embedded type 
scenario,
seems to be more of what LEDE's niche is.


LEDE/OpenWRT is a good fit for any device that operates on raw flash instead of
a hard drive or ssd with wear leveling. Once you have storage that you don't
worry about wearing out and is large enough to hold a normal Linux Distro, it
makes sense to move to such a distro and update packages individually.


Hmmm...the wear levelling thing is confusing.  I was told by someone who I 
thought knew
what they were talking about, that flash chips included some form of 
hardware-based
wear levelling built in already.  Apparently that is was inaccurate 
(hardware-level
support is something I only having minor knowledge of; it's not the part the 
interests me,
nor where I have worked on it for any length of time; I'm more interested in 
what you can
do with existing hardware support combined with software rather developing the 
core support
itself).


raw flash chips like we have in a router have nothing.

flash chips packaged in SD cards, USB drives, etc commonly have very primitive 
wear leveling (in many cases only targeted at the places that the FAT filesystem 
is going to use)


flash chips packaged into SSD drives or anything more sophisticated tend to have 
very extensive wear leveling setups, and will move existing, unmodified data if 
needed to balance things.


I haven't looked recently, but a couple years ago the idea of having an 
in-kernel flash wear leveling capability was getting a lot of discussion on the 
kernel mailing list. I din't remember seeing what finally happened with that.


For the very tiny devices, it doesn't make sense to try and make use of 
something like that (it takes more space ond isn't going to apply to a static, 
pre-build compressed filesystem)


But for the overlay filesystem where new stuff may get added on newer devices 
that have the much larger NAND flash, it may be something to look into, even 
though it complicates the base config for such systems.


David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

2016-06-16 Thread Daniel Curran-Dickinson 

On Tue, 2016-06-14 at 11:05 -0700, David Lang wrote: 
> On Mon, 13 Jun 2016, Daniel Curran-Dickinson wrote:
> 
> > On Mon, 2016-06-13 at 11:17 +0200, Jo-Philipp Wich wrote:
> >> Hi,
> >>
> >> no need to overreact :)  I think parts of the topics are about the
> >
> > Hope you're referring to Pinney and not me!  I was concerned because
> > Dave Taht's email and David Lang's post) seemed to me to imply changing the
> > defaults to suit bigger iron as the default rather than simply making
> > it a supported option.
> 
> I think you misunderstood our comments and concerns. We want the bigger 
> hardware 
> to be a supported option, and don't like the response that this initially got 
> of 
> "that's something only needed for bigger hardware, we shouldn't have it as an 
> option in LEDE"

I think you misunderstood my reaction.  I didn't mean that I didn't
think bigger hardware/VMs should be supported - in fact I have some
patches in queue for exactly that kind of scenario - I just was
concerned that it appeared to be a request to alter the defaults, not
just allow the support.

> 
> Both of us play with very small hardware as well, we don't want to close out 
> the 
> low end devices.
> 
> > I also think that talking about a 5-10 plan as
> > the basis if making decision of what to include by default in *current* 
> > builds
> > is rather foolish thinking.  Yes planning for the future is important but to
> > it reminds of a quote from when I was religious: "Don't be so 
> > heavenly-minded
> > you're no earthly good".  Basically here and now needs not to be forgotten 
> > in
> > dreams of future wonders.
> 
> Agreed, but at the same time you shouldn't ignore support for the larger 
> hardware.
> 
> Remember, this thread started with the request to support hard drives >2TB 
> and 
> the reaction was "we don't need that routers only have a few tens of KB of 
> flash" (even though it turned out that the support has already been included)

Again I think you read too much into what I said (admittedly I do the
same myself, at times, as you well know), but I wasn't saying there is
no use case for it, only that it's not the 'primary', or 'default' use
case.

By all means, I'm game for maximum flexibility that doesn't hurt the
primary use case. 

In the case the 2TB+ drives, I was concerned that such support would come
*at the expense of* the primary use; fortunately it doesn't, but if it did,
I would argue against kernel options (for example) for making the support
the *default* (e.g. in buildbot builds), except maybe for something like x86
boards/use cases (in the case of x86 I'm not sure that limiting hardware
support to save space is in most cases necessary; other cases like default
userspace I'd argue should be kept consistent and changes from default
management with things like ImageBuilder.

In general I'm a fan of ImageBuilder because, provided the kernel support is 
there,
you can use the SDK and build whatever packages you want to add on, and use
ImageBuilder to generate images that use those packages (along with the standard
ones you still want), without getting in the way of the primary use case.

> >
> > To a certain extent though, I question the need for something as restricted 
> > as OpenWrt
> > for the new bigger devices anyway; there are elements like netifd that 
> > would be good to
> > see continue, but I'm not sure that most of OpenWrt really makes as much 
> > sense when you're
> > not needing to squeeze maximum use out of very erase block, and that 
> > therefore, while it
> > may be a smaller market/mindshare, that focussing on the the true embedded 
> > type scenario,
> > seems to be more of what LEDE's niche is.
> 
> LEDE/OpenWRT is a good fit for any device that operates on raw flash instead 
> of 
> a hard drive or ssd with wear leveling. Once you have storage that you don't 
> worry about wearing out and is large enough to hold a normal Linux Distro, it 
> makes sense to move to such a distro and update packages individually.

Hmmm...the wear levelling thing is confusing.  I was told by someone who I 
thought knew
what they were talking about, that flash chips included some form of 
hardware-based
wear levelling built in already.  Apparently that is was inaccurate 
(hardware-level
support is something I only having minor knowledge of; it's not the part the 
interests me,
nor where I have worked on it for any length of time; I'm more interested in 
what you can
do with existing hardware support combined with software rather developing the 
core support
itself).

> But when you have a limited amount of boot/OS storage that does not have wear 
> leveling in place, then the OpenWRT/LEDE approach of a complete filesystem 
> image 
> that gets updated as a whole still makes sense.
> 
> Even when we have a few Gb of flash storage available, we will still want to 
> use 
> compressed, read-only filesystems for the main OS packages.

Actually I'm rather a fan of the squashfs / overlay, or

Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

2016-06-13 Thread Jo-Philipp Wich 
Hi,

no need to overreact :)  I think parts of the topics are about the
general availability of choices and not necessarily making them the default.

Imho most parts of CeroWrt can be replicated by using the ImageBuilder
to repack images with various components swapped (e.g. lighttpd vs.
uhttpd) and kernel features such as Cake and Codel are integrated and
default nowadays and other stuff is available in the form of packages.

For the remaining things that require compile time changes we need to
take a deeper look and figure out if they can be implemented directly in
LEDE or if it is feasible to simply drop them.

~ Jo

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

2016-06-12 Thread Dave Taht 
On Sat, Jun 11, 2016 at 11:11 AM, Daniel Curran-Dickinson
 wrote:
> Hi Dave,
>
> I don't speak for the LEDE team, but it looks to me a lot of your
> problem is that you are using LEDE/openwrt for far bigger iron than the
> primary target (standard routers, including pre-AC non-NAND ones, which
> are really quite small and low powered).  2 TB+ storage for example, or
> using lighttpd instead of uhttpd are really things that don't affect the
> primary use case and if you want to support this, you need to find a way
> to do that does not negatively affect your typical router (without
> external storage).

The context of the original question was more about being able to
access large amounts of external storage easily at all and if an
optional package needed to go upstream or not. Subsequent emails
resolved that.

The meta questions are: defining what lede's use cases will be 5-10
years in the future.

...

CeroWrt targetted routers, starting 5 years ago, with 8-16MB flash and
wedged quite a lot into that. One core feature was shipping a regular
build with an operable gui, which I hope lede starts doing, in
addition to the basic build, for devices with sufficient flash, as it
lowers the basic barriers to entry for new users considerably.

I think that lede sits atop a shrinking space, where - while very
small routers will continue to exist -  it is getting hard to get
flash chips as small as 4Mbytes these days for new products, and there
are other spaces growing at a rapid rate, notably IoT.

Most of the new routers ship with tons more flash than that.

Also, the latest generations of hackerboards, the getchip.com one, for
example, costs 9 dollars and comes with 512MB of flash, with a default
OS of debian. Nearly all the hackerboards (rpi, odroids, etc) have
been debian based, which while that does have the innate advantage of
local compilation, lacks the industrial strength characteristics of
lede (smaller footprint, well integrated key/value store in uci and
the gui, almost never writing to local flash, a good firewall).

Ledes willingness to be on the bleeding edge means it will continue to
gain valuable new features more rapidly than anything else (the
original bufferbloat and ongoing make-wifi-fast work being my own
cases in point), but to some extent that's also a disadvantage as long
term stability has been tough to get.

Another area of growth (I hope) will be in the "distributed web" space
where we start sharing data across the edges of the internet better,
and where the most "always on" box - like a lede router - would be one
of the best places to host and route such replicated content. The
tools that are creating that world have thus far tended to be written
in higher level languages (ipfs is written in go, for example), and
yet the added cpu horsepower required to manipulate a blockchain or do
DNS via a DHT is somewhat trivial for the next generation of embedded
devices.

http://www.decentralizedweb.net/schedule/ was very inspiring.

http://www.nytimes.com/2016/06/08/technology/the-webs-creator-looks-to-reinvent-it.html?_r=0

I personally don't make much distinction between "host" and "router"
anymore - a lot of the cerowrt related work on hncp (hnetd), babeld,
and source specific routing tried to make (primarily ipv6) devices
reachable no matter where or what network (or vpn) they were on, and
everyone in the above spaces is doing it with DHTs, and trying to go
the next mile past Tor. The CCN folk even go so far as to redefine a
router always having a ton of local storage.

There will always be a need for small cost effective, extremely
reliable and long term stable, routing devices, with good (and soon to
be *great*)  wifi, admittedly.

> Regards,
>
> Daniel
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

2016-06-12 Thread Dave Taht 
On Sat, Jun 11, 2016 at 3:07 PM, Lars Kruse  wrote:
> Hi Dave,
>
>> D) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/nanom5poe
>>
>> I don't know what landed upstream to control poe for the nano-m5
>> radios, if anything?
>
> I submitted a patch (that was accepted) for GPIO-based POE control - at least
> for Nanostations XM/XW and for TP-Link CPE210 and CPE510:
>  
> https://git.lede-project.org/?p=source.git;a=commitdiff;h=d65916047b44d6d157d88d15e8e3d92555c5e6f8

Groovy. There are quite a few other devices that have POE (edgerouter
is the first that comes to mind), perhaps this can be built on
generically?

> Only the luci interface is missing ...

noted

>
> Cheers,
> Lars
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

2016-06-11 Thread Aaron Z 
On Sat, Jun 11, 2016 at 8:56 PM, David Lang  wrote:
> Even low-end devices now include a USB port, and it's really easy to plugi
> in an external USB drive that's >2TB. 3TB drives are now <$100
>
> Now, if support for larger drives really does add a lot to the system
> footprint, it should be optional. But how much space are we talking about
> here? It should at least be an easy-to-select option.
I would have to agree with this. While I dont do it (I got a good deal
on a dedicated NAS and I dont want an accidental mis-configuration or
bug to make my private data publicly available), I know several people
who have a good sized (500GB or larger) external HDD plugged into
their router to use as a NAS.
Might be worth at least including as a separate package if it is too
big to replace the stock program.

Aaron Z

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

2016-06-11 Thread David Lang 

On Sat, 11 Jun 2016, Daniel Curran-Dickinson wrote:


Hi Dave,

I don't speak for the LEDE team, but it looks to me a lot of your
problem is that you are using LEDE/openwrt for far bigger iron than the
primary target (standard routers, including pre-AC non-NAND ones, which
are really quite small and low powered).  2 TB+ storage for example, or
using lighttpd instead of uhttpd are really things that don't affect the
primary use case and if you want to support this, you need to find a way
to do that does not negatively affect your typical router (without
external storage).


While CeroWRT has expanded it's aim to be able to support today's faster network 
connections (up to and including the 1G connections now available), that's not 
really the issue here.


Even low-end devices now include a USB port, and it's really easy to plugi in an 
external USB drive that's >2TB. 3TB drives are now <$100


Now, if support for larger drives really does add a lot to the system footprint, 
it should be optional. But how much space are we talking about here? It should 
at least be an easy-to-select option.


David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

2016-06-11 Thread Daniel Curran-Dickinson 
Hi Dave,

I don't speak for the LEDE team, but it looks to me a lot of your
problem is that you are using LEDE/openwrt for far bigger iron than the
primary target (standard routers, including pre-AC non-NAND ones, which
are really quite small and low powered).  2 TB+ storage for example, or
using lighttpd instead of uhttpd are really things that don't affect the
primary use case and if you want to support this, you need to find a way
to do that does not negatively affect your typical router (without
external storage).

Regards,

Daniel


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

2016-06-11 Thread Dave Taht 
happy to see cake working today! thx all!

In https://github.com/dtaht/ceropackages-3.10:

A) We have flent's tc-iterate.c as a fast, lightweight means of
polling fq_codel, pie, cake stats (as the shell in openwrt doesn't
support a subsecond sleep) for openwrt.

(However this package and code is in need of iteration to support
polling the new stats presented in the fq_codel for wifi sysfs code.)

Having something like this working is essential to analyze the real
performance and correctness of the new implementations on the low end
hardware.

B) I am probably the only user of the gnugol package. :(

C) I really need to sync the isochronous code with what avery has upstream

D) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/nanom5poe

I don't know what landed upstream to control poe for the nano-m5
radios, if anything?

E) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/gdisk

The principal problem with fdisk nowadays is that very large (> 2TB, I
think) devices are not supported by it, and require a GPT capable
tool. Is there a replacement in lede that handles GPT? If not - this
is an old gdisk port to openwrt that I used to use.

F) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/cerowrt-scripts
was a tool we used to measure latency under load directly on the
router...

some other packages that might be worth upstreaming, or putting in
another repo or updating in ceropackages

owamp: lets us measure ping times very precisely. (requires good ntp)
ntpsec - a vastly hardened full fledged ntp fork https://www.ntpsec.org/
scamper - two other measurement tools
shaperprobe

?

G) We used lighttpd in cerowrt as it was tons faster than uhttpd and
flexible enough to also do local web serving. can it (or ngnix) be
substituted for uhttpd? Or has uhttpd got faster?

H) Anyone working on go or rust for lede? hugo and ipfs and all the
other blockchain related distributed web bits looks like fun...

It looks like the static linking in go is a deal-killer

https://github.com/GeertJohan/openwrt-go/issues/2

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev