Hi, > Even standard Luci can be easily and significantly reduced in twice just > by removing images and icons.
I don't think this is true. The few icons bundled with LuCI at are approx 19KB overall while a recent mips 24kc snapshot build of luci-base is 126KB in size. So the images account for less than 10% of the luci-base size. > Luci uses a lot of images but they are not in some optional theme > package but in sources themselves (i.e. in > modules/luci-base/htdocs/luci-static/resources/icons). Note that we're talking about 23 icons with a size of roughly 14KB here. This is not the silver bullet which will magically make 4MB flash devices viable again. > So just by simple remodularization and moving the icons to theme we can > change tiny-theme without icons and full theme with icons. Saving about 20KB before compression, this is less than OpenWrt master consumes in size increase during a few months due to mere package updates. > I see that javascripts are already minimized (previously the wasn't) but > css files aren't yet. Saving about 4KB after squashfs compression. > Even more: we can gzip the files and serve them by Accept-Encoding: > deflate (or brotli) so they will be uncompressed by the browser itself. > I saw a patch for uhttpd that allows this. Note that squashfs performs optimized LZMA compression - shipping precompressed artifacts in rootfs would actually increase the image size due to double compression overhead. > With the ability to serve precompressed static content we can switch > icons from png to svg and this can save up to 10% of space. I doubt that. So far my LZMA compression tests have shown that precompressing content will not really result in an effective size decrease after squashfs/lzma. > All this allows us to decrease luci size at least twice. Not really, at most in a single digit percent range - if at all. > We can go further and rewrite Luci itself i.e. complete the Luci2 > project: get rid off Lua dependency and use JSON-RPC over ubus. Patches for this are very welcome. From what I learned so far, the space required to store all the modern day web framework dependencies will easily outweigh the ~70KB liblua + ~5KB lua runtime footprint. I've seen CSS scaffholdings and JS polyfills requiring more space than the entire Lua runtime. > But even this may be not needed: For Tp-Link recently was released a > mobile app Tether to control a router https://www.tp-link.com/us/tether/ This would imply both tying OpenWrt to a proprietary app and limiting its configuration to whatever settings that happen to be exposed by it - this hardly sounds like a viable solution to me. > We can try to reverse engineer the protocol of the mobile app and > implement it. Given that users can remove Luci and use the app to > configure the router. I don't think that attempting to accommodate proprietary vendor configuration protocols is going to help in significantly reducing the storage footprint in future OpenWrt versions. > So what I trying to say: sometimes the lack of space may mean that > architecture can be improved. Then it's better to fix that or wait until > it will be eventually fixed. LuCI master was recently further modularized to allow installing only the components wanted/needed to support certain functions, this could already help to reduce the footprint in some scenarios. > Smaller software is usually works faster so that's a good property to > keep even for larger devices. I'm with you here, but building small software and actively avoiding all the libraries/bloat floating around takes effort and dedication, which is scarce, especially for the rather uncommon use-cases targeted by OpenWrt. ~ Jo
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel