As I am the one responsible for the creation of this thread, I am gonna expand on the original points from the other thread. I see three main issues with maintaining a router and these are the reasons I would not recommend anyone I know to use OpenWRT unless they are technically advanced: I do not have time to maintain everyone's router and this is not a router that an average person can maintain even if it is properly installed by someone who knows how to do that.
Configuration changes between minor & major releases and due to bug fixes.
Be that new regex in Adblock or a new parameter in uhttp, there is no way of knowing about them. Well, besides spending tons of time in this forum, but that is not for everyone. I see several possible solutions
For novice & advanced users: a Luci app (installed by default) that allows them to see a side by side and file by file diff between default config (left panel), their local config (right panel), and an editable view of the local file itself (bottom panel). The file could be edited by copying and pasting lines from the diff above. The comparison view would refresh as the file is being edited. There is no need to do any automatic merge or re-implement meld here; the file is only saved at the end.
A new policy for the apps to not store runtime configuration in the config file. Adblock's regex is executable and enabling/disabling a filter is configuration. These must not be in the same file as the user should not need to know what regex is and when properly separated the regex could be deployed independently from config (like recently happened Adblock needed to fix adguard source: it required merging the changes form the default config file).
A longer term solution is for each feature to become responsible for upgrading their configuration either quietly. Having said that, if #1 and #2 above are both properly implemented, this might not be necessary.
Releases
I saw a proposal to generate upgrade images two or three times a year. I can tell you right away, that that will not be an easy sell as a good security practice. The argument will go like this: everyone else is releasing upgrades every month and that means they are more secure! Perception matters a lot and infrequent releases will be perceived as less secure. I think there should be a dot or dot-dot release/build once or twice a month. Sun Microsystems did refuse to play the perception game (CPU frequency) and look where that got them
Asking users to use daily release snapshots will be perceived as the having to use unreliable and untested firmware. They will always chose an easy and familiar way.
Upgrade/Release Images
The entire industry has conditioned the users that firmware is a single file and going against that is futile. No-one wants to have to mess with figuring out what packages to install to get some functions. I also think that trying to address this by reinstalling packages individually is very error prone. Turris Omnia failed to handle all corner cases by using opkg (for two years) and they totally changed their approach now.
It would be simpler and more beneficial to generate a few standard images with all the basic packages already built-in for the routers from the easy list. The default feature set can be taken from one of the mainstream routers. I personally like ASUS routers and maybe Synology. The configs should be created based on a specific use case and I only see three of those for home use so far:
A router appliance only (and my personal choice): Adblock, DDNS, SQM, Statistics, Bandwidth Monitor, BCP38, maybe a few more basic packages.
#1 + NAS
#2 + Media Streaming Server
Everything else (including VPN) should be delegated to advanced users who know what they are doing. None of the off the shelves routers can provide good performance over VPN with OpenWRT anyway.
P.S. I do have some thoughts to share about the pain of the initial config, but I hope there is gonna be a dedicated thread for that.
Forgot to mention, that auto upgrade or one-click upgrades are also very important. This should not be as big deal to implement for the predefined bundles upgrading to the new version of the same bundle. But I know there are a lot of people who will tell me all the reasons why that is a bad idea
Do you see a non-technical person appreciating this process and also knowing what to do with a tar ball? Adding more steps to the setup will turn some people away. More steps, more people will not complete the procedure. To be usable it got to be a wizard within the default firmware file. But this discussion should be in a separate thread.
Upload it to the LuCI restore backup function... that'd be spelled out with screenshots.
The point of what I'm thinking of is to dramatically lower the number of steps needed to get a more sophisticated level of function. Imagine if you could go to a site and click a few buttons to say "I want a main LAN and 2 separate guest LANs, with ports 3 and 4 part of guest LAN2 and port 1 a port that will connect to a further AP (ie. become a tagged trunk port) ... etc etc. The questions would be goal oriented rather than technology oriented (like whether you want tags on port 3).
But yes, this should go to a separate thread: how to get started, slightly different from maintaining
And until a dedicated thread is created I see no reason for this not to be included in the firmware as a module or embedded into a page. Doing so will eliminate the need to upload any files at all.
It all depends on the back end technology you need, if it's lightweight fine. I imagined using some more heavy hitting tech than what you might want embedded.
I do not have a link, but I did quite an extensive research recently and came across a remark from a frustrated Turris team member about how many corner cases opkg could not handle and so on. You can search forum about all the auto update issues.
There are also a lot of posts about the nightmare of configuration merge during the upgrade. These are big issues to solve.
Another way to handle configuration merge during an upgrade would be to redefine how the configuration is managed and used. Let’s say a uhttpd installed a default version of its config file under /etc/config (for backwards compatibility the same location should be used). This file cannot be modified anymore. All user changes go into uhttpd.user file in the same location and the runtime merges the config via inheritance.
This way a new parameter added to limit the concurrency of scripts that it runs will be delivered as a part of the default config and user settings will not have to be overritten. When the router reboots it will merge the new default config into the user file and the upgraded config will be the latest.
Adblock could change its regex anytime and it is delivered the same way in the default config file while the adblock.user stays unchanged.
No, if your an advanced user with many demands then just edit the config files yourself.
If your a novice and just want a wizard like experience then a user interface that keeps your settings in a database to be used for generating config files now or after an upgrade seems like a reasonable approach.
Especially now that low memory devices are getting phased out and newer devices have more resources to include nice UI features.
Yes. I just updated the OP to say that I would only insist that these improvements be available to Recommended devices. (People using "limited" or "difficult" routers will have been forewarned, and any niceties that come to OpenWrt may not be available to them.)
OpenWrt is primarily intended for power users, networking enthusiasts, wireless communities, and embedded device developers.
OpenWrt's default configuration, with the luci web interface, is a big improvement over the stock firmware of most wireless routers and similar devices. It provides all of the functionality most people will need. Additional packages can be installed with just a few clicks, to provide extended functionality if needed. A command line interface is also available.
I dare to say that “most consumers” don’t fall into that category. The group of people that do fall into this category still might need help/support but it will be on a completely different level.
Handling kernel updates, package updates etc while keeping all the configurations might just be to much for “embedded devices”. If you start targeting the high end devices for these features that would leave an even bigger group of people / devices behind than just cutting the 4/32 devices as discussed in another thread.
Doing a full update might only be suitable for those “dual boot” devices where the configuration can be (automatically) copies & pasted from the “other partition”. With a failsafe in place should this fail. Any package updating/adding settings should have its own script to handle those changes.
I believe we should aspire to have our basic secure router be broadly usable - to the consumer (or a "pro-sumer"). We are almost all the way there: we work on lots of devices, the installation process from Vendor GUI to OpenWrt is smooth and well-tested, and the base installation is as secure, robust and reliable as an vendor firmware.
As for updates, we can do better (of course). But I also suspect that an 18.06 OpenWrt install (even if un-upgraded) is more secure than most vendor firmwares.
So we must never be ashamed of our progress - there's a huge amount to be proud of. I think what we're talking about here is our next steps to make OpenWrt better. Thanks.
@richb-hanover-priv I feel like you are a little offended by my last post (maybe I’m reading to much into it). Nobody said that the project hasn’t come a long way. And nobody implied that there is not a lot to be proud of.
But: The first problem here: maintaining a router. Updating / upgrading package or the kernel “in place” is complicated given the limited resources on our embedded devices. I’m afraid that it will add to much “bloat”, which needs to be compensated by using higher end devices (with more flash / ram).
Second problem: if you want to make it more available to consumers vs pro-sumers, maybe there is a need for a “full” installation image vs “minimal” and the end user adds his/her own packages. A “full” installation will have all the features like Adblock, guest-network, file-share, OpenVPN, maybe WireGuard, SQM etc.
That will make it more “friendly” for many consumers, but is moving away from the original intention of this project: making everything user customizable.
In the end it is even related to the 4/32 question: those will never be able to have all the eye-candy and features AND be very user friendly in terms of updates (without basically flashing a clean install and reconfigure). So which group do you want to leave “behind”. Or, like I mentioned: make a “full featured” image available for those devices that could handle that (still leaving the 4/x behind).
Another option (not sure how workable it would be)...copy all relevant config files to the end users PC, do all the reconfiguration on that PC with a “tool”, which needs to be created for that. Merge everything back together into a “final” image, which in turn can be flashed as “full configured custom-update”.
I see no reason for this not to be included in the firmware as a module or embedded into a page. Doing so will eliminate the need to upload any files at all.