The ToH on OpenWRT wiki isn't showing any such warning, https://wiki.openwrt.org/toh/start so I suspect most of the people complaining were looking at that table to see what is supported. @tmomas can you add clear warnings there too?
I think that for these devices (both 4 MiB flash and 32MiB RAM) it would make more sense to eventually drop the default firmware build and redirect users to a freifunk-like imagebuilder webgui so people can build their own firmwares with stuff they need integrated on-demand (using profiles or whatever to help them), as they will likely fail to install packages anyway.
(Yes I have a 32MiB device, and it works fine, only issue is that it can't install packages as opkg triggers OOM killer that goes on and sacrifices children, this is the actual message I get)
Oh I'm wondering if advertising the remaining space will be meaningful to the part of the userbase that doesn't know 4 MB is (too) tight in the first place. You'd also need to have an idea of the size packages are uncompressed (I for one don't). Also, just for storing settings you need a few kB (quite a few I think).
I don't see a better criterion though. But the space needed for configuration settings should be factored in.
I like this idea on the Quick Start Page (and possibly elsewhere) that would include RAM/Flash memory requirements, as well as software requirements (someone pointed out that newcomers may not "know how to ssh...")
The Quick Start Page could say:
This process will not work if your router has less than 8 MBytes of flash memory (see the Supported Device Page to verify). See the "Installing LEDE on Older Routers" page if your router does not have the required RAM or Flash.
devices with more than 4MB* Flash is recommended to install additional packages (ie. GUI, usb support, etc)
*LEDE may be installed on 4MB but please note that you may not be able to install a GUI(link to LUCI) interface and/or additional packages(link to list of packages) due to size limitations. Please refer to ...blah blah links here (maybe link to information regarding UCI commands instructions)
Also when I say "black box" label I'm referring to something similar to this https://lede-project.org/docs/guide-quick-start/start shown under the "Installing LEDE" section, which looks great btw (that term comes from the FDA when indicating warnings for drugs)
An additional page could be set up, containing the essence of:
have >4MB Flash (4M can work, but are no fun to work with. >4M will make you happier than 4M or below.)
have >32MB RAM (32M can work quite well, but 64M are more comfortable to work with, depending on your use case.)
Sufficient Flash to accommodate LEDE firmware image
4MB min (won't be able to install luci) / 8MB better (will fit luci and some other applications)
Sufficient RAM for stable operation
32MB min, 64MB better
Comments like "won't be able to install luci" are very helpful, since this gives the user the clear indication: Forget it, it will not work (at least not easily, i.e. not w/o setting up extroot).
What other popular and flash / ram hungry packages are there that could be mentioned?
It may be fair to say LUCI will not fit but to say these devices are no fun to work with is an odd comment. I run several mesh networks with kmod-batman-adv and openvpn with no problem on tl-841v7-11. Kinda fun to me.
Maybe simply a comment that LEDE targets devices with >4MB flash and >32MB RAM. Devices with less resources may be supported with custom LEDE builds.
I think you should consider this advice to be targetted at the novice user, who (imho rightfully) expects LEDE to be a full featured replacement for the vendor firmware. Under this pretense, a router that won't be able to run the webinterface/ luci (flash size), which ooms when running opkg (RAM) or tends to brick during sysupgrades, if you happen to have packages installed which require a couple of kernel modules (e.g. strongswan, depending on kernel modules needing just a little too much RAM to also fit a full-sized 8 MB firmware file into tmpfs during the upgrade) certainly can't be considered "fun".
This doesn't prevent these devices from being useful to advanced users who know what they're doing, but those probably won't look for this kind of advice anyways.
To extend tmomas' tentative list of potentially problematic (popular) packages for low-end devices, I'd add pretty much any kind of VPN (OpenVPN, strongSwan, wireguard), as well as adblock (RAM required to process the blocklists). While none of these are completely impossible, if you can live with significant tradeoffs (as in eventually not being able to co-install them with luci or special care during sysupgrade), they will pose quite some problems for lower end devices.
It depends on the use case, and your linux background.
If everything you need is already included in the downloadable lede image, perfect, you have fun.
If you need to install more packages, and possibly need to compile an image yourself, it's getting less comfortable, not to say a PITA. I have been through this with a MR3020 4/32MB: Luci + gphoto2 + fswebcam + something else does not fit into 4MB (back then @12.09). Extroot needed. Needless to say that it didn't work out the first time. No fun at all for me, stepping from one mudhole into the next.
My reception of the "wants" of users in the forum: They want to install $firmware, and afterwards they do want to install flash hungry packages like Luci + OpenVPN + .... Compiling own images and press-fitting stuff they need into 4MB or extrooting the device is a hurdle. In the case of extroot: there are devices out there that do not even have USB, so extroot is no option.
Therefore: 8MB = more fun, or more comfortable to work with than 4MB, since you are less restricted, or more free to do $things with the device after flashing it.
Regarding the "Should LEDE support..." discussion:
It almost sounds to me like "Dear developers, please stop supporting devices with only 4MB flash and invest the gained time in working on more important things."
Since the developers are doing all this and are not getting paid for, I think it's totally up to them to do what they like with their spare time.
Btw. I also think you need to distiniguish several different user/ usage scenarios here.
the user who already owns a low(er)-end device for a while and has probably been using LEDE (respectively OpenWrt) for quite a while. These users know what their device is capable of and they do have a hands-on idea about their use-cases and if their device can cope with that load. While the installed package set might vary slightly over time, I'd consider them to primarily update (and thereby potentially get affected by increasing system requirements) because of bugfixes and security reasons; "to stay up to date". They will see their system specs to become more and more of a problem (like a gradual self-deprecation warning), but at the same time they'll probably be more willing to cope (be it not using the webinterface or stripping down the firmware image) with this (keeping the device is free, while finding a new one is both expensive and takes time to find the perfect option - and even after switching to new hardware, the old one probably still remains as a spare or for experimenting) than a new user contemplating to flash LEDE for the first time.
new users, contemplating to buy a low-spec device or considering to flash a non-vendor firmware for the first time (probably because of unfixed (security-) bugs in the vendor firmware or missing features (e.g. IPv6 support)). These users typically rely on a smooth migration path from the vendor firmware to this strange new world, a webinterface is probably crucial for them. Recommending devices which only barely cope with minimum system specifications would be a huge disservice to them and the reputation of the LEDE project.
users with a very defined embedded use case, who might end up buying a device in larger quantities (let's say more than 3 devices). In this scenario price becomes a hard factor and more effort can be spent on customizing a hand-tailored firmware image, without 'optional' features.
Personally I would not want a Google search on "LEDE minimum requirements" to come up with >4MB flash and >32MB ram. I agree for the novice user who wants to play with their home router this makes sense. At the very least they are going to want Luci.
But LEDE does not equal LEDE+Luci and there is a HUGE market for Linux like OS's on embedded devices. Some of these devices are made as cheaply as possible (with as few resources as possible). This is a great market for LEDE and the people searching for OS candidates may not be the developers who are in the end tasked with created them.
The above Google search should not return requirements greater than the true minimum. Ideally not more than the Linux kernel itself. Add whatever caveats you want to that (i.e. GUI, novice user, etc.).
I'm confident that people interested in the project will not be turned away simply by looking at the description shown by a google search. They will click on the link and explore the website to read additional information regarding the hardware requirements
Here I will disagree. The user in this post bought a device they claim was suggested on OpenWrt (WR802N), yet it only has a community supported version available and relatively little documented on the device. I do not think they are reading well.
The existing message does not stand out well. Let's at least make it bold, but I think the message can be stronger and included in other places too. As @slh pointed out it is the novice who gets into trouble. Anyone who can build LEDE probably understand the issue and how to solve it.
I do not know what the feasibility is of reworking the default images on these to include extroot configured for devices with 4mb and USB. Would this not go a long way to addressing the issue for both Trunk and Release? If I understand this, one pretty much would just need to plugin a properly formatted drive and go.
It's really a strange question to me... If we drop support for 4MB flash, what will we benefit from it?
LEDE defined itself as an embedded OS so I believe it's one of the primary targets to keep the firmware as small as possible, no matter it's in a 4mb flash or 4+mb. The major work of LEDE development is on the common thing, not device specific code, especially for the older devices. If we drop support for 4MB, The only difference will just be removed the compile option to include LUCI or not, the real development still be the same, developers do not write less code or do less work. But we will lose some users and use cases because of it. It maybe not a huge loss but it also not a big effort to keep them.
Maybe someday LEDE's functionality grows stronger and itself cannot fit 4MB and these devices disappear in the market, then it will be natural to drop its support. But for now, and in a near future, LEDE without LUCI can definitely fit into 4MB device, I cannot see any reason to exclude them
There is no concerted effort to kill off 4 MB flash/ 32 MB RAM devices, but new upstream software is getting more features and larger/ more demanding. Following upstream, which is very much needed for security fixes and keeping up with changing standards and new features, while keeping the flash and RAM footprint is hard, very hard. And if you both want to retain the flexibility that the enduser can install additional stuff (so you do need to enable more than the bare minimum in the base (kernel-)config and to cater for more capable routers as well, you are pretty much between a rock and a hard place.
What is apparent right now, is that opkg and uhttpd/ luci-ssl are scratching hard at the limits for 32 MB RAM devices - and need additional care to fit into 4 MB flash at all (for some devices more than others, due to the pre-existing mtd partitioning). While it is still possible to dodge the problem "this time" (probably not for all devices in the release images), doing so has its limits and won't continue to work for the longer term (let's say a year down the line).
At first I thought support for minimal spec. devices was a good idea.
However I now believe it just isn't worth the effort required.
If these (usually) older devices need FOSS support older OpenWrt releases are more than adequate.
As slh points out it is just a matter of time and 4MB Flash simply won't be enough ... same goes for 32MB RAM.
I'm in favor of saving SO much trouble and NOT supporting ANY devices with 4 Flash or 32 RAM from DAY ONE.
We do not know what information the that user was referring to (ie. The wiki or another user on the forum). I'm not sure that the OpenWRT wiki makes recommendation on specific hardware models. If that user looked at information on the LEDE wiki (with changes), they would know that a 4MB flash is NOT recommended.
Thats the reason why LEDE has its own wiki, to make its own standards/recommendations compared to the one on OpenWRT
Additionally, If the google search showed "LEDE minimum requirement of >4MB" from the LEDE website, would they not click the link to read on more information on the LEDE wiki pertaining to the warnings of 4MB flash routers?
Yeah, my suggestion is to continue support on 4MB but users should be AWARE that it has limitations due to flash size (make sense logically)
========================
EDIT: In regards to the wiki, on the "Installing Luci" Section (where ever that may be) the warning label should definitely be placed there along with an FAQ so its obvious that they cannot install LEDE and move on.
An experienced users will obviously think otherwise but this is targeted to newcomers
Summary is: Its not a problem to refer them to the hardware support wiki page if a person with a 4MB flash router comes along having problems with LUCI install. This should be known as the future for growth is inevitable
EDIT2: And we shouldn't compare nonexperienced users being unable to install LUCI on a 4MB flash router with experienced users who know how to build a custom firmware to install LUCI on their 4MB router.
I'm wondering if advertising the remaining space will be meaningful to the part of the userbase that doesn't know 4 MB is (too) tight in the first place. You'd also need to have an idea of the size packages are uncompressed (I for one don't). Also, just for storing settings you need a few kB (quite a few I think).