Much like the convention of prefixing your subject line with [PATCH] messages like this should be required to have a prefix such as [DRIVEL] for effective filtering
lede integration issues ?? I don't see why there IS an issue CeroWrt died for good reason(s) ... such as : Low return on investment by it's corporate sponsorship. Only supported ONE router (and a few subtypes thereof) Let the detrius settle to the bottom where it belongs. I am probably the only user of the gnugol package. :( There is most likely a good reason for that :) fdisk doesn't support GPT ?? >From the lede 'menuconfig' Base system > busybox Linux System Utilities ---> [*] fdisk [*] Write support [ ] Support AIX disklabels (NEW) [ ] Support SGI disklabels (NEW) [ ] Support SUN disklabels (NEW) [ ] Support BSD disklabels (NEW) [*] Support GPT disklabels [*] Support expert mode So what the standard LEDE images don't support fdisk with GPT one can easily format his so called large USB drive on a desktop... Why should a wireless router support this by default? We used lighttpd in cerowrt as it was tons faster than uhttpd. "tons faster" ...really is the readership of LEDE-DEV primarily made of teenage girls? Can you provide evidence to suport this ... Simply put .. It's a memory hog for a typical router ... how well does it work with 32M or even 64M of RAM? Are you suggesting LEDE drop support for 4M flash / 32M RAM routers in favor of using lighttpd as the default? defining what lede's use cases will be 5-10 years in the future Really LEDE should have a five year plan much like the Communist Party of China ? On Sat, Jun 11, 2016 at 12:44 PM, Dave Taht <dave.t...@gmail.com> wrote: > 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 _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
