[OpenWrt-Devel] [RFC] stop accepting 4/32M board patches

[Jo-Philipp Wich]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20181206/63c114d3/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel