End of official support for 4/32 devices

I did not know in which topic to put this, so I put it here.

Rather by accident I stumbled about this Wiki entry about a project meeting where it has been decided to discontinue the official support for the 4/32 devices after version 19.07. Unfortunately it was not made clear what lead to this final decision and also it is a bit sad that the decision has been made in that rather private meeting, without involving the community.

Thus I thought this would be the most fitting place to further discuss this.

For me as a user I obviously don't like to see support ended. And I hope there could be some more elaboration. Why you didn't chose to strip down some features for those devices and continue official builds?

Ping @aparcar @hauke @jow @ldir @lynxis @NeoRaider @pepe2k @richb-hanover @tmomas @ynezz

1 Like

Because this would be additional effort beyond what's currently being done and no developer has shown interest in doing so, so it won't be done.

Apart from dropping LuCI there is not much feature reduction potential without restricting functionality. There is also no interest in maintaining multiple build flavors as the resulting permutation of different build configurations is impossible to support and test.

9 Likes

Nothing "new" here, as the discussion is over two and a half years old (and foreshadowed by warnings about flash size and RAM long before that).

and there has been significant discussion about how those that have a need to continue support of 4/32 devices can proceed for over half a year already

6 Likes

Thanks for your note. I understand that you are disappointed with the constraint that 4/32 devices cannot support modern OpenWrt, but there was significant discussion about six months ago...

I will also point out that it's not a matter of "simply stripping out bits" since that has already happened.

The "newest" 4/32 devices are multiple years old, and very capable 16/128 Mbyte devices are now in the $20-30 range.

Developers have made the rational choice that it isn't a good tradeoff to spend a lot of their time squeezing a few bytes out of a build to save someone else a few bucks.

5 Likes

Ok, completely understandable. Sad to hear no developer is interested in it, but I guess they are not using those devices, so also reasonable. However I guess there would be people in the community willing to continue support?

I am just speaking for me, but I really don't care much about full functionality. What I want is a good and supported firmware for my router. I'd even vote for dropping opkg instead of LuCI.

That is what I think is inevitable at some point. I mean, you already have the tiny builds, I guess? And I think there are probably devices that might benefit from a more feature complete build fully making use of their space. Or do you mean builds for the same device, one with LuCI disabled, one with opkg disabled and so on?

I guess it might be rather hard, but not impossible.


I did not write "new".

The discussion might be, I will read through that thread now, but the decision is new :wink:

Yes, I was just reading that after creating this topic. However that thread was more about doing own custom builds rather than continuing official support.

Disabling official builds doesn't mean that code for already supported 4/32 MB devices will be dropped (at least in case of DTS-enabled targets). Users/community members would still be able to build custom, stripped images for these devices.

4 Likes

Well, it is completely ok for me that not all features of "modern OpenWrt" can be supported, if you mean that. I'd be completely ok with a feature stripped version. All I'd like to have is continued official support.

Stripping out opkg might be an option, although I am not sure whether that will fit for most users.

This is not true afaik. There are currently still devices sold with that spec like some cheap TP Link devices.

I am not asking to painfully squeeze, just strip some features.

For me it is not that much about the money but about keeping hardware instead of needing to throw it away. Plus a bit of convenience. But I should note that I am also trying to get a different device for more features.


I know, but I'd rather prefer "official" support.

I'm curious - what is your current router? What are the essential features you need?

And as pepe2k points out, you're welcome to build your own stripped version - sources will always be available. (And if that's not in your skill set, what would you be willing to spend to have an expert create a build for you?)

5 Likes

maybe 19.07 could be supported for several years, as a compensation for this inconvenient change. e.g untill stable release 2023.

Currently I am using a TP-Link TL-WR841n v9. I had some issues, which currently are still not really routed down. So because of that and because of more features I ordered a stronger router, which unfortunately did not work out due to changed models (Xiaomi Router 3G vs R3Gv2).

So thinking of it again, I probably also created this in favor of other users that are affected of this and because I did not like the decision to drop the support for those devices.

There was also a thread here asking whether OpenWrt still is for embedded devices if it fails to support the rather limited ones.

I'd like to keep LuCI and the ability to set static IPs. I don't really care much about opkg as the space is so limited I cannot really use it at all. One additional nice package would be the updater from @aparcar, but that currently does not install because of lacking space, so it probably won't fit any newer builds either.

I'd like reliable builds for everyone (automated builds on official servers for a variety of devices), not just some custom builds for my own.

Personally, nothing. But there might be others willing to donate some money to the project.


That might be some middle way, although I doubt it is doable or wanted. Shipping stripped down versions of more current releases is probably even easier.

Won't happen, sorry.
Project has to evolve and that means weak/old hardware won't be able to run it any longer. Sad but true.

3 Likes

I think you have stated the nub of the problem.

Open Source Developers work on projects that scratch an itch, fix a (personal) problem, or stroke their egos. That stroking can happen a couple ways: people will do a lot of work to help a personal friend. And it's also true that having 10,000 people using your software is a powerful aphrodisiac, and that's a big draw... In the right setting, developers will work incredibly hard on a project if they get the right return.

But what you're offering is ... nothing.

Maybe there would be some kind words for a developer who put their professional skills and reputation into making an "official" build for a $18 router on Amazon. But it's hard to get motivated when a better router costs only twenty bucks more - and it's fully supported and future-proof right out of the box.

I don't mean to pick on you. But I hope this points out the futility of hoping that "some others might be willing..." to support the project when you're not personally willing to step up.

7 Likes

I have to say that I only skipped to that thread, but imho that is about a different topic, not very much about discontinuing support for the 4/32 devices.


Having a modular design, I am not sure why there cannot be simply some modules removed for weaker devices? What features are you talking about? A more resource hungry LuCI version? I thought that the new version will actually consume less resources on the router, although that might not be true for disk usage or RAM consumption.


That is a bit out of context. I assumed you were asking for some kind of payment from the way you asked that question. It is not really worth that for me to pay for support for devices I don't plan to use for a longer period.

Nothing was maybe the incorrect term and I also knew that it would sound pretty harsh.
For example one thing I actually already did was to raise the awareness of this in hope it might lead to some rethinking. I was trying to start some discussion how to make this possible obviously offering my thoughts on this topic. And I even might offer my help to get those devices officially supported. However in that question you gave me the option to either do community builds or to pay for it, which is not what I wanted.

I know, I am not good at motivating people. But that is probably also mostly because I don't like tricking people into things they wouldn't like to do if they knew the facts. So I try to stay more factual.

Completely understandable. One motivation could be to support an as broad range of devices as possible. I mean why add support for a 8/64 device when there is an already supported 8/64 device for the same price available. One could just tell the users they should buy that instead. Another would be to continue support for existing devices to help probably a lot of people.

That is a bit the problem of Open Source projects, yes. But what I'd like to also note is that it might be better when people who know what they do are doing the support, because it is more time efficient. So I think it is ok to ask for support and to also ask for reasons why it has dropped, even if one does not want to personally step in.

To me it looks rather simple to offer feature stripped down builds by adding some build properties, so I'd ask why not to do that.

Hi @clel - I think you have heard the reasons not to do this from several authoritative people on the project. There isn't the cost-benefit to do any further work to continue with 4/32 hardware.

The beauty of Open Source software is that the software is all available to you. If you wish to spend your time building firmware for your device, we (truly) wish you the best.

But it's verging on trolling us if you continue to insist that, "Surely, there's someone out there who'll help support me." Let's wind up this thread. Thanks.

6 Likes

You should expect that 32 MB of RAM will be a problem, even with stripping out run-time features. If not now, very soon. Like the warnings over the past years around 4 MB of flash reaching its limits, these warnings have been there with sufficient time for someone to budget a couple dollars/euros/... a month to be able to replace them with adequate devices.

Like the WRT54GL and its "generous" 16 MB of RAM before them, asking to run a 32 MB device with current, patched kernels is like wondering why your beloved Pentium 90 can't run Windows 10.

2 Likes

I didn't hear, why not to do builds without opkg, which has been suggested on the Wiki page I linked. Also I asked follow up questions to the replies I got that are currently mostly unanswered. Until now I did not understand the decision properly. And although I don't like it, because I am afraid you will reply to this that this is not your problem if I don't understand this: I really hope to be able to discuss this factual and hope you have enough patience to explain this more detailed to some of you community member.

Probably because the actual build procedures and development insights are not known to me, I cannot really see the costs of doing builds with opkg removed for example. But maybe removing opkg would not be enough. Unfortunately that has not been said, so I don't know the answer to this.

I think I stated that this is not what I want and that I am also asking in favor of other affected people. So doing my own builds won't fix that. However as I already mentioned, I'd be actually up to help you setting up automated builds. That is what I'd like to achieve, not some custom manual builds.

Did I insist? And I thought I made it clear several times that I am not asking for me mainly. So this sounds like a strawman to me. I'd like to keep the discussion factual and polite.

I don't like the tone and how you treat me in this sentence. Let's be polite.


I was talking about the new LuCI version there. But you say that the kernel alone will reach the 32 MB RAM limit? Do you have some references for that statement?

I know, but this is not about money.

I doubt that this comparison is correct. First Windows 10 is a complete OS, not only the kernel. Second you compare lack of RAM with lack of computing power.

1 Like

The 4/32 topic has been discussed before, thoroughly and ad nauseam.
Therefore, please forgive a slightly stressed tone here and there.

3 Likes

With every release the core software gets more demanding. v17 was probably the last version which would let 4/32 users install any useful extra software, and then only on user built versions. v18 is even bigger and for v19 there is hardly free space to let you save the config even when removing everything that is non-essential. For v20 it will probably be next to impossible.

3 Likes

Everything grows... kernel, drivers, security focused features, etc. So, for the last time, sorry but it won't happen. 4/32 MB topic is closed, decisions were made, project moves on.

6 Likes