On Sat, Jun 11, 2016 at 11:11 AM, Daniel Curran-Dickinson <dan...@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 _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
