Maybe just a list of the packages and automatically set them to some sort of "installation pending" status during backupfile restore ?
Sounds quite nice.
Or do you think it has to be the actual package files?
installation pending would suffice but also include a button to just then automatically install all the packages in the pending list.
1 Like
to be clear....the backup archive need only contain the meta data for the packages. The button just executes the fetch command.
I like it very much.
That is technically impossible.
Disclaimer: Please don’t interpret this as a defense. We’ve been aware of this issue for a long time, and we’re committed to improving. That said, we’d appreciate your suggestions or, even better, any direct help in addressing it. Developers naturally focus on development and tend to deprioritize public relations. 
Regarding the apk transition, I’ve been following it closely—it’s a recent change, so let’s discuss it further.
Here’s my understanding of the communication efforts so far:
- A pull request had been open for several years
- There was a forum topic about the upcoming switch
- Loads of commits supporting
apkwere added to the codebase - A pull request was created prior to the actual switch
- Several email threads were exchanged before the transition
Questions for improvement:
- What specific aspects of communication did you feel were lacking?
- Are there preferred channels or methods that could make announcements more effective?
- How can we balance transparency with development priorities?
We’d love to hear your ideas!
3 Likes
Could you elaborate on why unbound should be the default? What advantages would it bring over dnsmasq in this context?
On a related note, this seems similar to other ongoing discussions, such as mbedTLS vs. OpenSSL or dropbear vs. OpenSSH. Perhaps this ties into the broader concept of grand-flash targets, which aim to prioritize features over flash space constraints?
3 Likes
I am not an expert on DNS lookups, and so my thoughts below should be taken with a pinch of salt incase of inaccuracy.
Surely dnsmasq - an efficient forwarder, leveraging the low-latency, caching benefit associated with using public resolvers like Cloudflare - is the better default? Unbound is primarily a recursive resolver, requiring slower initial full recursive lookups, which is not going to be what most users want. To elaborate, any initial lookup to a public resolver like Cloudflare has a high likelihood of benefitting from a cache hit, and hence a low latency response, whereas such an initial lookup using a full recursive resolver is going to be a slow, higher latency response, albeit m subsequent lookups can benefit from local caching. Clearly the caching benefit associated with public resolver use is going to result in overall lower latency.
I believe dnsmasq plus stubby offers a lower footprint in terms of storage and memory than unbound, and that this combination is very performant.
And finally, dnsmasq offers highly efficient advert blocking. Now users can block a ton of domains on even very meagre hardware.
3 Likes
Automatic updates. The reason I use Turris routers/APs is the automatic update functionality. When I first got a Turris Omnia, I planned to replace TurrisOS with OpenWrt to avoid bloat. However, the automatic updates are so good that I decided to keep TurrisOS. Now, Turris devices are the only routers/APs I’m willing to buy.
This is false. Unbound can be configured as a caching/forwarding server as well, through the forward-addr configuration directive. See, e.g., https://www.redhat.com/en/blog/forwarding-dns-2
1 Like
I guess you missed the word primarily there. Doesn’t unbound have a larger footprint than dnsmasq (plus stubby?). And even though there appears to be some advert blocking capability, there appear to be a fair few reports about very high memory use.
So I’m dubious that it’s a better tool for the job, in the general case.
Rather I think it offers an interesting alternative - as a departure from the sensible default - for those who want recursive resolving.
There are three key differences between TurrisOS and OpenWrt:
- cz.nic only needs to support (and test) 3(?) different hardware models (and a few variations of those), OpenWrt ships for over 1000 different devices, it is impossible to test all of them before deploying an automated upgrade (whole targets are unlikely to see regular testing by developers, because they simply don't have the hardware, nor time and opportunity for testing, even if there were automated testing -somehow- it would be very basic at best and a major undertaking). So if there were fully automated upgrades, we would see bricked devices, often - all on the same day.
- cz.nic chose a SOC with rather reliable 'last resort' recovery over serial (kwboot) and they chose a full-featured u-boot with nicer means of recovery on top. On the typical plastic router supported by OpenWrt, you have to make do with ancient and crippled OEM bootloaders, with varying means of recovery
- cz.nic designed their hardware and went to the top shelf in terms of specs (and pricing), they have the luxury to have plenty of flash in their devices (which is essential for snapshotting) and relatively good flash technologies. OpenWrt has to deal with everything the vendors throw at us, from 8 MB spi-nor, over various NAND types, eMMC, sdhc, SSDs, anything.
Unless you want to throw away device support for anything but x86_64, ARM SBCs and perhaps a dozen of high-end routers (most 3-figure wifi6/ wifi7 routers will not meet the bar) and do a complete paradigm change for OpenWrt development, this is unrealistic (at least not a good idea).
Reality sucks.
11 Likes
I agree, it is sad but that is how it looks realistically. That said, having timely (email) notifications
that updates exist might already be a noticeable improvement...
At least can we use the Image Builder to build custom firmware that supports extroot by default? So we don't have to reformat the external storage every time?
@sirizha just for clarification:
As long as you only ever installed software from the regular OpenWRT repository, the ASU server will give you an updated image for your device that includes the base image as well as all those packages you installed afterwards.
So ASU does not reset your device to the one distribution image that you can download from downloads.openwrt.org/releases.
Apart from mishaps (packages lose some components you might depend on, due to restructuring of package contents, which makes base packages smaller and allows you to not install them if you don't like them, but requires you to install them manually when updating a major version), you should end up with a fully functional router that contains all the stuff you had before, just with newer versions after running the ASU procedure.
Currently, no.
Imaginable, not reaalllyyyy. The problem is, the overlay is an overlay filesystem, it works as delta to the known underlying filesystem, but those vary a lot between versions - and binary compatibility is a no-go altogether (things would crash badly, if you'd keep your old extroot overlay).
1 Like
Well, the firmware selector could use a size option for squashfs builds.
So those with more space can opt to use it (or a bigger part) 
2 Likes
No, uci-defaults is not "sort of similar" to remote management of downstream AP.
What features are you looking for?
More user friendly GUI. I'd like to see Luci closer to commercial routers interface if possible.
Ok I know openwrt is much more but I'd like to see Luci improved.