I did an OpenWRT image built for TP LINK WR940 V3, the WR940 V3 and V4 versions uses the same length 4M flash memory, but when I did an LEDE image built for TP LINK WR940 V4 the LEDE Image Builder say
[mktplinkfw] kernel length aligned to 1356624
[mktplinkfw] *** error: images are too big by 1118 bytes
In the /include/target.mk file and the packages listed in the make image PROFILE=tl-wr940n-v4 PACKAGES="pkg1 pkg2 pkg3 -pkg4 -pkg5 -pkg6" are the same in LEDE and OpenWRT.
I did an OpenWRT image for TP LINK WR940 V3 without problems or too big errors.
Did I something wrong or Is LEDE more heavier than OpenWRT?
Be careful to compare the right things. I doubt that you'd see a significant difference between current OpenWrt trunk (pre-DD) and LEDE, if you compare LEDE 17.01-rc1 it to a 2 year old versions (CC 15.05.1), LEDE will of course be larger than OpenWrt, not because of LEDE itself, but because of the updated upstream packages growing slowly but steady.
If you check Should LEDE support devices with only 4MB Flash?, you'll notice that the growths relative to OpenWrt CC/ 15.05.1 is actually quite small compared to prior size bumps, but given that 4 MB flash devices are hard on their limit, every tiny change is more noticeable than before.
Well, LEDE has one year newer kernel 4.4.46 instead of 4.4.14.so it is quite possible that the size has just grown over a 64 kB block size causing a size jump. You got 1100 bytes too much, which is not much.
Similarly, most core packages have got updates during the year, while Openwrt has been stuck. So possibly small size increases here and there.
I did again an LEDE image built for TP LINK WR940 V4 with the LEDE Image Builder (17.01.0-ar71xx-generic), and OpenWrt and LEDE image are almost identical lenght, so I think was a problem in LEDE 17.01-rc1.
Part of the design decision I think contributed to this is that new binaries was created to serve new services.
Drawback of this is
-More running processes less CPU time for each processes on Single Core CPU
-Each running process has process overhead penalty
1)consume additional RAM
2)consume additional Flash
It would be better if LEDE developers consolidate similar functions and put them in the same binaries
I have a few 32m ram devices, some with 4m flash and others with 8m flash. Regardless of the design decisions the 32m ram/4m flash devices are starting to reach the end of their lives with the newer software. Tweaking things a little here and there does allow them to do a bit more but it's really only delaying the inevitable. Kind of like we've all done with pc's and laptops over the years. Sometimes you've just got to take them off to the old hardware home
I would say End Of Life only applies when you encounter physical limitations.
For example you need 1000Mbps Ports but the device only has 100/10Mbps
or your wireless is stucked to 54Mbps Wireless G because of your old router so you cannot stream HD videos even though your computer supports 300Mbps Wireless N.
yes this is considered real end of life because the alternative is to BGA resolder a Wireless N chip on it and it is infeasible.
Increase system resource consumption as a result of design decisions is an artificial thing not physical.
FYI there are still new consumer routers with 32MB RAM and 4MB chips still supporting IPv6 etc with full fledge Wireless PSK Enterprise Mode.
Are you going to call them end-of-life when they are just getting started?
I have also resolder all my 32MB/4MB Routers to 64MB/16MB, they have no problems supporting LEDE yet I still think that in the business of embedded system optimization for size is always preferred.
Lastly there is no old hardware home.
Old hardware ends up as electronic waste where it is dumped into less developed country where people who live near those dumpsites absorbed all the toxic chemicals and metals.
Just as 32MB/4MB isn't good enough for you it isn't good enough for someone else too so it ends up in the scrapheap
We all have different opinions on things. I stand by my comments. If you want to keep updating the firmware to the latest and greatest then it is going to require more flash/ram. If someone sells new hardware with limited storage then good luck to them. Doesn't make it 'future proof'.
Storage (or lack there of) is also a physical limitation.
Not sure why this is causing such angst. If the current firmware is starting to hit the limits then constantly tweaking the firmware will extend it's life for a period of time but not forever. So how long before it's end of life.
Writing embedded compact code is an art that is difficult to practice when so much code is reused from other platforms and with so many contributors.
I'm just grateful for the time and effort that the existing developers have put into the firmware.
Chill dude. I'm not suggesting polluting the world by chucking old electronic gear into the wilderness.
Feel free to fork a super compact firmware system to support small memory devices. No one i stopping you.
Spare a thought for the 2M flash devices that are already gathering dust.
If it's going to salve the wouund, use some older firmware and make a decision about how to backport any security patches/features that may be warranted.
