Edit: nvm I read it wrong
Edit2: https://www.dd-wrt.com/wiki/index.php/Supported_Devices just for reference since it talks about hardware requirements
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.
1 Like
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.
4 Likes
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.).
1 Like
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
2 Likes
Please don't. Currently, it is easy to fit an unmodified LEDE (IPv6, no stripping etc) + LUCI + OpenVPN + mbedTLS in 4MB.
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.
Healthy debate here, but what is really missing is someone from DEV to chime in and tell us what the real effort is to support these devices.
My point above was that I do not think that users coming from stock devices even know that memory plays a part in any of this, so why would they look for it. Most vendors do not include this spec.
1 Like
When I try to find out if given router/ap is supported I go to supported hardware page.
This location should point out if there are any caveats such as limited functionality due to flash/ROM size, etc. I suggest to also make note which devices are most popular or most actively supported.
If 4/32 devices have support you can rest assured the customer service department will need additional staffing.
You can also be certain that 4/32 support will be dropped in the future...maybe as early as 18.01 ?
There will be no shortage of HELP!!! I can't install luci on my JUNK-13b.
Most readers of "For Developers" will not have much trouble making said JUNK-13b work OK.
But that type of user doesn't complain much either.
Even if JUNK-13b has absolutely no official support ... most of us could still build it ourselves and share if desired.
My point here is user satisfaction.
Typical end users will just NOT be happy unless their device has a web interface...and we will certainly hear ALL about it.
OpenWrt has a reputation as being difficult for beginners...I wonder why?
First you download ... then upload ... you upgrade ... then you ssh to 192.168.1.1
Huh? What you lost me there what is ssh how do I do that?
If you want gain happy NEW users ... LEDE will come with luci installed and WiFi enabled then still have space left over for luci-app-xyz.
That's not going to happen with 4MB Flash
Say Y here if you want to work in the complaint department.
Say N here if you are not interested in listening to numerous complaints.
As slh points out it is just a matter of time and 4MB Flash simply won't be enough ... same goes for 32MB RAM.
By the same logic, it's just a matter of time before 8M flash won't be enough,
same with 16M, 32M, etc.
you can't argue that some hardware spec won't be enough forever, so we should
abandon it now.
It's very reasonable to give a warning for 4M devices that we are currently
approaching the point where they can't run a 'standard build'. And for
individual systems it's fair to add a warning that they have hit it.
But if the codebase runs on them now, we should not be doing any work to remove
support from the codebase.
If the standard default config stops fitting on the
system, switch to a minimal config that builds enough to do a 'hello world' test
to make sure the hardware drivers work and flag it as 'experts only' from that
point.
When the 'hello world' build gets too big for a device, then it's time to
finally drop support for it, but that's a lot further off.
David Lang
2 Likes
I certainly agree the day will come when 8M and 16M are not enough.
However the days left for 4M seem to be nearing the end.
An experts only tag or something similar may be the way to go.
A "standard" build won't have nearly as many 4M devices if you include luci as it did say with a 3.0 kernel....
They'll be dropping dead soon enough anyway.
This discussion has significant overlap with the one about "unsupported devices" (stuff that is listed in ToH but is not truly fully supported), and imho it has the same solution, just add a "for experts only" tag and show a big fat warning to newbies.
The same tag can be used for devices that have wonky installation instructions (involving soldering or manual SPI flashing, and there are a few), or that aren't suited for newbies for other reasons.
Already there, on the very similar page:
I think it should be stated in all ToHs.
What other popular and flash / ram hungry packages are there that could be mentioned?
VPNs and any other package requiring encryption libraries, Samba (shared folders), 3G dongle support, filesystem drivers/tools for formatting and checking a filesystem for extroot.
4MiB devices can't fit anything noteworthy unless you use Imagebuilder (that requires a Linux system and some mild experience).
what is really missing is someone from DEV to chime in and tell us what the real effort is to support these devices.
I'm a half-dev (a "contributor"), I see the activity enough to report on this.
4 MiB device setups are already done (basically they disable some kernel options in these devices to shrink the kernel so there is more space to fit the rest of the firmware), and most of other stuff is shared with other devices with the same SoC (drivers, SoC-specific stuff, whatever) so it has to be done anyway.
The firmwares are built the same way, by the same tools used by all other devices.
I don't think there is any significant effort required to keep them supported.
There were talks about dropping support of some devices and it was not (directly) because of their flash sizes, but because they required specific hacks that are annoying to maintain, AND they were somewhat obsolete/rare AND they had low flash so they were not fun to work with.
Working on it.
As I suspected, so the impact is really CPU time and disk space for the buildbots.
Any thoughts on this?[quote="RangerZ, post:35, topic:1018"]
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.
[/quote]
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 should be easy to make extroot-ready images (as it's just a configuration for buildbots, "add package X, Y and Z, and they do this for luci in release builds), it would probably require some more logic in builders (so they don't build extroot images for devices lacking USB for example) though.
But I think this approach should not be followed.
I think the future of these devices (and LEDE firmwares in general) should be more towards using a web application that controls the imagebuilder tool, so everyone could make his own firmware with the packages he wants (on top of defaults) already integrated. As I already said in other places, integration of packages at build time or with imagebuilder places them in a highly-compressed partition which is much better use of the low storage space on most embedded devices. For 4MiB ones they won't fit much more than basic extroot setup OR luci OR VPN anyway, but for devices with 8 and 16 MiB it's a godsend.
So it would kill 3-4 birds with the same stone.
Freifunk (a german mesh wifi project using OpenWRT/LEDE) has already made one of such applications and it is open-sourced, so it should be just a matter of setting it up in a server or a Virtualbox "appliance" (a VM packaged for distribution) that people can use by connecting to a LEDE site or run on their PC with Virtualbox. See here http://lists.infradead.org/pipermail/lede-dev/2017-January/005050.html
Would be cool if there is someone that volunteers to do this, as otherwise I'll have to do it myself after i'm done with the Table of Packages in the wiki.