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

[Dave Taht]

On Sat, Jun 11, 2016 at 11:11 AM, Daniel Curran-Dickinson
<daniel at daniel.thecshore.com> 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