So imagine you can do two things, one is buy new $40 devices for each of these, and get improved results due to more power. the other is spend $2 each to reserve one talented developer to maintain this for a year on the existing hardware. It's cheaper to do the maintenance sure, but the functionality is very limited. It seems straightforward to set up the patreon account if a talented developer wants the money. Now, how many people will actually do the donation?
Only the core community itself, mostly not the local restaurant providing his clients a cheap internet access. Rare are those making donations toward us. We get financial aids in many ways too, like donations and sometime from towns/city or state parliament. Law changes might come the next years in germany in regard of volunteering work in matter of Freifunk itself. Advantages like taxes cut help a lot too.
We spend some of the donations toward gluon too, sometime money, sometime buying devices to hack around. Or paying bountys to random devs to fix bugs.
But money should not be the driving force here. Pay the running bills but no more. Money can kill a project like that, see what happened to Cyanogenmod (that thankfully survived as a fork: LineageOS).
1 Like
I agree that chasing ever more money through "monetization schemes" isn't a good plan, but paying for specific development tasks is a good way to focus energy where it otherwise would have little reason to be focused
3 Likes
Time, however, is a driving force. OpenWrt is effectively a volunteer effort as well. I consider it a horrible waste of that effort to try to keep alive every single piece-of-crap device that doesn't have sufficient resources to run a secure kernel and secure software. The bottom of the barrel is now flooded by no-name clones and manufacturers' offerings under the same name that have even less hardware inside than the previously crippled version.
Perhaps a reasonable compromise is to, for a brief period of time, keep a very select list of devices that either don't have at least 8 MB of flash or don't have at least 64 MB of RAM supported. Yes, they'd be EOLed for support too. You can't say you haven't been warned, this comes up every year. So this would be "fair warning" to go out and, for the price of a couple coffees, beers, what have you, buy something decent.
Yes, you can buy a 2.4 GHz router with 16 MB of flash and 128 MB of RAM from a reputable manufacturer for under US$20, delivered, with an unlocked, full-featured U-Boot (including HTTP access) and factory-supported OpenWrt that is current and close to the tree.
I think one way or another, the OpenWrt wiki is doing everyone a disservice by being so wishy-washy on 4/32 devices.
The public information indicates far too clearly that
- 4/32 devices are Supported, by virtue of https://openwrt.org/supported_devices
- 8/64 devices are "Ideal for OpenWrt", after following I want to buy a router which is supported by OpenWrt
Sorry, they're hardly "Ideal for OpenWrt" as they're on the borderline for robust operation on modest speed lines and 8/64 devices are about to follow in the path of 4/32 devices.
I wouldn't buy anything with less than 128 MB of RAM these days, even used. Time to move that up and
- 4/32 warning -- "Not supported" (though firmware may be available, we ain't fixing the bugs or listening to you whine any more)
- 8/64 warning -- "Expect limited support and lack of functionality for any more than basic functions. Expect that device will become obsolete quickly due to limited resources."
- Supported devices only lists 16/128 or higher
- Ideal for OpenWrt devices omit MIPS-based devices and other low-end SoCs. Omit any that do not support 802.11ac. This is "ideal", not "supported" after all
6 Likes
I agree with Jeff about what information we give on the wiki and table of hardware. People should get more easy access to up to date recommendations not just technically it sort of works.
1 Like
I don't see this as a common consensus among the developers.
That will not happen.
3 Likes
In any rational enterprise, there are several different things:
- What expectations are set with customers and prospects
- What the product can do
- What the organization will warrant the product will do
- What the organization will help customers with on a reasonable basis
- What's just not going to happen
The wiki reflects the first -- positioning and marketing
I also see that, at least as I interpret it, multiple supported branches, multiple kernels, or build-time hacks are out, from the next bullet in the quoted post
I think it would be useful to have ideal, well supported, and minimally supported, a binary "supported" vs "ideal" is not enough granularity.
1 Like
Should we support 4MB? Thats the original question. As long as the same target has both 4MB and 8+MB flash there shouldn't be any objection. Development time in terms of getting the linux kernel working / up-to-date / secure for that target will be spend anyway. Giving users the option to create their own (custom) build for that target with less flash should remain. Same goes for 32MB RAM vs 64+MB even if that device has 8MB flash. Let the user (repurpose) an old(er) device, make it a managed switch, range extender etc..
So the question is: "what means support". Support would mean: help the novice end-user to install and basic configure the device. This type of support is not done by most of the developers, but is mostly done by other end-users. As long as there are still people willing to make "small / tiny / custom" builds I don't see the problem.
Lets take the "EdgeRouter Lite" (https://openwrt.org/toh/ubiquiti/edgerouter.lite), dual core MIPS64 512 MB RAM..but 4MB FLASH. It should be able to run circles around most populair TP-LINK / NETGEAR / B-brand lower-end devices...if it wasn't for the small flash.
Sure something like this: https://www.aliexpress.com/item/Fanless-Mini-PC-pFsense-Celeron-J1800-J1900-Quad-Core-4-Gigabit-LAN-Firewall-Router-Windows-10/32884221255.html?spm=2114.10010108.1000023.13.4ce63a6fm8eL1Y would be nice...but even that I wouldn't buy: the J1900 doesn't have AES-NI, the device only has VGA (I don't even have any monitor with that connection anymore).
Long story short: as long as the same target has 8/64 or better it should not make a difference in terms of development time (which is what counts at the end of the day), those 4/32+ devices only take up a little space to accommodate their DTS and some make (type) of files.
Disclaimer: I'm not an OpenWrt developer and can't speak for them.
The question isn't about "should", but "can" - if you look at the ar71xx-tiny target as an example, you see the sysupgrade images currently (18.06.2) have a size of around 3584 KB (and that's not really representative, as 18.06.x is still on kernel 4.9 for ar71xx, for kernel 4.14 you have to add just shy of 192 KB growths - and that's the kernel alone, userspace is growing as well), even on devices that use a very economic partitioning, you lose at least 192 KB to bootloader/ bootloader environment and calibration data, another 192 KB (= three erase blocks) are the bare minimum for the jffs2 overlay to work (and in practice you need at the very least 4 erase blocks (256 KB) for a most basic configuration).
128 KB (u-boot/ u-bootenv)
+ 3584 KB (average 18.06.2 ar71xx-tiny sysupgrade image size)
+ 192 KB (needed on top for kernel 4.14)
+ 192 KB (bare 3 erase blocks required for jffs2)
+ 64 KB calibration data
=========
4160 KB
Oops, even assuming zero growths for the rootfs (userland), this is not going to fit into 4096 KB anymore. Yes, this calculation isn't 100% correct, as compression efficiency might sway the numbers slightly, but the tendency is spot on - and many of the affected devices with 4 MB flash are more wasteful in terms of their partitioning. So unless anyone steps up (very soon, basically it's already to late for that now), providing actual patches, 19.03.0 (as we know it, with opkg, luci, ppp support) won't fit on any 4 MB flash device anymore.
Keep in mind, this is not a fault of the 'evil' OpenWrt developers, on the contrary - they've spent considerable efforts to create the tiny target in the first place, to allow saving as much space as humanly possible (otherwise 18.06.0 wouldn't have existed for just about any of the 4 MB devices). And the estimates above already assume 0 byte growths for the rootfs (which is unlikely). A considerable amount of effort has also been spent to push support for these affected devices to use a dynamic partitioning split, in order to make the growing kernel fit at all (most had a fixed size limit between 1.3 MB and 1.4 MB for the kernel). So please don't assume bad faith or an active unwillingness to keep these devices working, really hard work has gone into supporting these even recently.
Considering this, what are your suggestions here?
The only place where one could (relatively easily) save a few more bytes is not including opkg and luci in the images, will that help in the medium term - no, because kernel 4.19 will grow again (that's not a guess, but a fact based on the already existing 4.19 support for some targets, assume at least a bit over 100 KB there). So all you can get with this alone is maybe another major release.
Just to re-iterate this explicitly, no one has suggested to remove source-level support for the affected 4/32 MB devices so far (on the contrary, you will still find source-level support for 16 MB RAM devices, even though they have no chance to even succeed in booting a release- or snapshot image). This means you will still be able to build firmware images for these devices for quite a while longer, but you will inevitably have to make hard choices about which (basic) features you'll have to cull from your custom images (and this will get increasingly harder over time).
Do you really think supporting novice users to configure their devices using ssh alone (because the webinterface simply isn't going to fit into (remotely) release-style image anymore, pretty much regardless of what you do) would be a raging success? Oh, and opkg or pppd aren't going to fit either, so you'd need to teach them about (at least) imagebuilder and/ or building form source at the same time…
Continued support for these devices really needs very active help, as you can't expect the existing developer base to 'suddenly' find a miracle they haven't been able to find within the last >5 years. It's not as if this would be a surprise, kernel- and userspace components have been slowly growing since the dawn of time, for at least 4½ years (15.05.0) it is becoming glaringly obvious that 4 MB flash has come close to its end (given that most affected devices had 5 erase blocks (320 KB) left at most), with it just being a matter of time until it won't fit anymore. Both 17.01.x and 18.06.x (18.06.x wouldn't have fit at all, without the introduction of the tiny sub-target) showed serious problems with the firmware images fitting already - and unless you do drastic last minute changes to the configuration (removing opkg, luci, etc. from the release images) 19.03.x most likely won't fit on any 4 MB flash device anymore (again, we're talking about release images here, that won't prevent you from building stripped down images yourself!). If you consider that 19.03.0 is pretty much just around the corner (weeks, not months left), it's effectively already too late for them.
Just please don't let your only suggestion be "then don't update the kernel, libc, $userspace_in_general", that's almost the only option that isn't on the table - if you don't care about security issues, bugs or support for newer devices (yes, there has even been support for new 4 MB flash devices added to OpenWrt recently, even though the developers are starting to push back against new additions for these underspec'ed devices), others do very much. The current set of developers simply can't keep track of even more concurrent kernel versions in parallel (even for still supported LTS kernel lines this is a considerable amount of work, with basically zero on-device testing happening).
…and if you don't care about glaring security issues anyways, no one will stop you from using older versions and to become recruited by multiple nefarious botnets - just be aware that this is strongly recommended against.
As you'll notice from the figures above, very little of the image growths stems from active decisions of the OpenWrt developers - it's mostly down to growing space (and RAM!) requirements of the various upstream projects (who generally consider smartphones to be 'embedded' and low-spec, the lowest common denominator they care about), if you want to change anything, that's where you need to start working (with the relevant upstreams). OpenWrt can't diverge from upstream much more, without losing track of current upstream work and the option to support new devices users actually care about.
9 Likes
Hear hear! Thanks for the hard numbers and explanations.
@slh, first of I'm not a developer either. Second, I am not disagreeing with you or your logic. The numbers as you show were already valid a year ago from the 17.x to 18.x and other topics here.
I was "happy" when the Lede-project actually took off. It was splitting the OpenWRT user base from the development part. The Linux Embedded Development Environment would have active development with a more power-user / amateur developer based forum. Then the fruits would benefit the OpenWRT community where the much larger (novice) user base would be able to continue supporting the lower end devices. OpenWRT would be kind-off like the fork from LEDE (and no longer the other way around). Fast-forward to today, we are faced with the remerged OpenWRT/Lede.
Lede development should (my opinion of course) continue development keeping up with the latest Linux development (a few steps behind). The developers should concentrate on development (improve features, security, stability).
So should "LEDE" support those devices. Then I guess if we need a Yes / No answer, I will vote "No". Maybe create a fork for those devices and find some users willing to maintain a 4.4 or 4.9 LTS kernel for another few years.
Thanks all for keeping the conversation respectful, and for the good analysis... Here are my thoughts on the several ideas that came up in the discussion:
-
As OP, I took the liberty of changing the subject to "Should OpenWrt/LEDE support devices with only 4MB Flash?" When I posed the question two years ago, I was asking about the then-current build (LEDE, pre-merger). The question is now relevant for OpenWrt.
-
@drbrains asked the critical question:
So the question is: "what means support". Support would mean: help the novice end-user to install and basic configure the device.
I agree that "our base of support" should be to help novice users get OpenWrt running on their router. Having spent a lot of time writing "get started" documents, it's clear to me that this implies a base system that includes a GUI. (It's already scary enough for newcomers to take their currently-working router with manufacturer firmware, and download and install something new. Making them also use a terminal to get it working again it is a step too far.)
-
I support the effort of anyone that wants to create a community build that addresses specific, popular routers that cannot fit the full 18.06 (or 19.03) release.
-
I also support preserving the full source-level build capability for marginal and unsupported devices, even if that configuration never gets automatically built (or installed or tested.)
-
Finally, the OpenWrt project needs to conserve developer time. As several have pointed out, time spent on fitting firmware into limited resources (4MBytes Flash) takes attention away from security fixes, new packages, features, etc. @slh's calculations of Flash requirements for current/newer kernels make it clear that 19.03 cannot be "supported" (e.g., with GUI) on 4/32 devices.
1 Like
Shows that it is already quite questionable if it was a good idea to provide prebuilt firmware images for 18.06.x already.
3 Likes
Fully agreed.
I'm already thinking about what to do with devices affected by this and how to mark them in the dataentries.
What about marking them "18.06.2 - BYO" (Build Your Own), and removing the download links?
As looking at things from a product-focused perspective, I can get behind a reasonable objective such as that proposed by
With that focusing the objectives of the project, I'm of the opinion, that any devices that require custom or community builds, shouldn't be put forth on the wiki (OpenWrt's "product brochure") as anything even closely related to the word "Supported".
"Novice users" would likely interpret "Supported" to mean that they could get the full OpenWrt experience as they picture it, which almost certainly includes GUI and potentially includes bufferbloat management and various "security" features, such as VPN and various flavors of DNS control/security/obscurity.
I've lost track of the number of times and the number of general functions that new users repeatedly post here something like
But I can do [Repeater, VPN, Guest network, ... ] so easily in the [OEM] browser,
Why can't I do that in Openwrt?
OpenWrt is supposed to be better than [OEM]'s software!
1 Like
It's all a question of how you inform the users.
Is that clear enough?
6 Likes
The problem, as with all documentation / wikis / warnings... people don't really read those. They will first flash (even the wrong image), then panic and seek help.
Not providing pre-build small/tiny (4/32) images would help a lot, but expect a lot of questions why not, where to find and a lot of custom builds of questionable quality. There was already a long discussion about not trusting "any" custom build.
As an alternative, the Kernel 4.4 is LTS until (projected Feb 2022) so at least should be "secure". People could use a Lede 17.x version. After all, there are still a lot of devices running OpenWRT 14.x or 15.x. which are not secure at all anymore.
DD-WRT and Padavan are still on a 3.x kernel (Tomato I didn't check). So keeping the 4.4 (or maybe 4.9) alive with only security update (no features etc) would be a big plus over all those.
2 Likes
Perhaps the ToH could distinguish between the following:
- GUI Support - Full release build, with LuCI, IPv6, and the rest of the bells and whistles, as we do now
- SSH Support - Something like the "tiny" builds today - no GUI, but modern kernel, some ability to support additional packages
- BYO Support - You're on your own with the current build
This is complicated by the fact that GUI/SSH/BYO is a reflection of the ability to jam the firmware into the available Flash memory. Whether there's enough RAM for the device actually to function is an entirely separate question.
1 Like
Might it be simply something like "Only limited support since 18.06.x".
Trying to differentiate between limited supports classes (SSH, BYO etc.) will get cumbersome in the long run.