OpenWrt development directions

sorry for OT ...but ...
looks like OWRT rolling to full blown distro path
whole idea of OWRT was to

  1. squeeze kernel + some useful stuff in [2,4] / [16,32]
  2. bring freedom of choosing alternate FW against closed factory FW

since this is considered as "hacking into HW", it was normal that anyone who want to try OWRT will have dirty hands
learning, compiling, flashing, desoldering chips, etc

now, with stuff like APK,ASU etc, this whole story started to looks like user friendly distro
and the price to pay ?
no more old devices, even 8/64 is obsolete?

only to some self claimed guru who never saw network equipment could say to his friend: yess, i am a big boy, i pushed the update button and woow, everything is working ... updated to latest xxxx version, without knowing what he is doing, and why hi is doing that

so ... maybe i am wrong, but with this path, OWRT will lose advanced users and community knowledge based on advanced users

4/16 was supported (until 2012), 2/8 or 2/16 have never been.

I think you're overestimating the impact of apk here, for the simple reason that even a better package manager will not immediately improve the packaging itself, nor the hardware- and bootloader constraints (in-place upgrades will remain impossible for the same reasons as with opkg, not enough flash, kernel-, libc- and other libraries not co-installable based on sonames, etc.).

While I'm not a fan of ASU either, albeit probably for different reasons (I do think that it's a high attack surface service (server side), high maintenance and high system requirements - and I fear it makes shooting yourself into the foot a bit too easy, especially when upgrading between major releases (with their often considerable changes in default packages); I have just observed similar smart helper tools in other distros being too smart for their own and and causing more grief long term, than teaching the users how to do things 'properly'), the bulk work is done server side, the on-client infrastructure is rather minimal.

We are on ~7.1-7.2 with 23.05 already, kernel upgrades (v5.15 --> v6.6) alone will grow the images by ~400 KB alone, so you see a problem there. So the days for 8 MB are kind of numbered, yes there is still some lee way for feature reduced images, but it's tight already.

At the same time hardware (and user requirements) are changing, fortunately system specs are also improving - not as much as many would like, but mt7621 is rare to find below 16/128 (and often NAND with 128/256; vendors are increasingly keen on a/b firmware upgrading).


My whole motivation behind working on ASU and ASU-adjacent projects (see my owut announcement thread) is purely selfish. I maintain/consult-on OpenWrt installations on family and friends devices, some of which are 10,000+ kilometers away from me or any other tech-savvy helper. I want to make sure that keeping these devices up-to-date is as robust and seamless as possible. It would be fruitless to tell some of the remote users "sure, that's easy, just ssh into the router and run tcpdump and tell me what's going on over port 67..."

I don't see any of this is interfering in any way with hardware/networking/kernel hackers who don't want to deal with it. How does the existence of a solid updating system impact your life? Same question about apk, it's about as minimal as opkg, but without certain bugs...


Hi @efahl
hope you don't feel offended
since it is Open(project)Wrt, and Open(forum)Wrt, hope that people are Open to other opinions

i will try to make it short
with comfort, you lose the sharpness !
minimalistic approach have benefit of bringing the best out of devs and users
something like (rude compare, linux vs windows) users who know how to use PC, they use Linux, users who think they know how to use PC they use Win (no offense) because Win is smooth and less to think about compared to Linux

yes, it is mostly philosophic thinking ATM, but i am afraid that trend i see on forum is indicative. many user expect magic buttons for wizard like things because they try to use devices/technology/network without knowing what they doing ( drop me with stone, but feels like Windows users, no offense )
Again, it is not about ASU,APK, or any other single package
it is more about how OWRT started, and where it is right now

1 Like

OpenWrt is far from a general purpose OS, and your comparison of where it started to where it is now is not really a strong argument. If you stick with "where it started", you wouldn't have support for any wifi standards beyond 802.11g (Wifi 3) and 100Mbps networking, no modern VPNs, not to mention that you'd have lots of unpatched security vulnerabilities.

At the core, OpenWrt has maintained a remarkably small footprint -- growing mostly in response to the underlying kernel (which is an upstream development path, necessary to support new hardware, security, and the like). Along the way, the UX has improved, too. The project obviously has a large contingent of enthusiast users, but there is no reason not to make it inviting to a broad audience, so giving it a modern, user friendly interface makes that possible. This serves to improve individual users' network security posture while reducing e-waste for older devices, introduces people to open source software, and gives them an easy way to learn CLI and linux if they so desire, but without forcing it upon them as a prerequisite. In fact, I started to learn linux most effectively when Mac OS X (10.0) was released in 2001 -- I had a nice UI I could use for day to day tasks and the ability to use Linux whenever I had time to learn.

Beyond the core, tons of optional packages are available for all sorts of purposes... these are, in fact, the result of "bringing the best out of devs" -- the platform is super extensible, but very much optionally. Anybody who want's the 'core' experience can get it, but those who needs additional functionality and/or a touch of convenience can absolutely use the tools available to them.

All that said, I think that this thread is moving way off topic (and I'm guilty of contributing now).


me to :slight_smile:

Don't worry, I'm not offended at all. It takes a lot more than differing opinions to get a geezer like me to get riled up. :grin:

My view is that the more the merrier. If we get a lot of noobs who are interested, that's great. My take is that "the noobs" are usually people who are concerned with privacy and/or security, rarely as a badge of honor ("Hey, look at me, I use OpenWrt!"), so those you help through the rough bits are making the world a better place.

My strong feeling is that easy, robust, seamless updating is a key component of keeping OpenWrt devices private and secure. If it helps the N% of OpenWrt users that are not developers, but only here because of those concerns, wonderful!


Haha, yeah, a long time ago. Move those last 10 or so to "OpenWrt Directions" or something?

1 Like

Done... split thread.

That said, @NPeca75 - if you search around, you will find other people who have had views on the direction OpenWrt has gone.... but it seems that on the whole, the project grows more useful and more popular as it evolves, so on balance, it's a positive trajectory. But if you have specific concerns (rather than just general ones), feel free to describe them so that qualified developers can respond as to why a given decision/path was made and why it benefits the project, or conversely why it might be worth revisiting.

1 Like

well, my first idea is APK
Reading on forum, some of advanced user always said: DO NOT update/upgrade individual packages. stop
there is numerous reason for this, flash size, kernel incompatibilty, changed application settings, etc
opkg was scarry enough to keep most of users far from updating
yes, there are several who think, if i update package, my old YUGO45 (ahahaha) will became Ferrari :slight_smile:
then brick, panik, how to reset, pleaseeeeee heeeeelp, i am novice :frowning:

and since OWRT is invented for very specific set of devices, closed HW, no terminal, small flash, etc, it was good thing to avoid scary opkg :slight_smile:
then came firmware selector, which give a "power" to users, but, to be honest, it is (no offense) almost useless on 8/x devices since it is not compiling, only packaging things, leaving many unneeded stuff on flash
users with "big" devices will benefit, but others ... only false feeling of power
and now, in similar manner, APK
let's replace silly opkg with advanced apk, so users could press update button with smile on their face :slight_smile:
it will not change fact that updating package on embedded system is out of mind
again, false feeling of "power" in user hands

before anybody take this offending
i am admire/respect devs who try to write any code for community. stop
they free time committed to free project is valuable

it is, again, about direction of project
and giving users power to do something without knowing what they do
is APK bigger than opkg? yes
it will impact [4,8] devices? yes
oh, yes, i see that first reply will be, [4,8] devices are not supported any more

but then

this if opposite :slight_smile:

ok, again, respect the devs, respect the whole project, using OWRT for many years

my biggest concern is: if you make it user friendly, then user does not learn anything
forum is full of missconfirured firewalls, vlans, etc

again, very opposite

and the summary of this long writing is:

devs spending time for gui/wizzards/one-click-solve-it-all things, which involve dependencies which again, grew footprint to be unusable on older devices, only to give users false feeling of knowledge/power/security.

... and every PC/Network/Home/whatever is secure maximum as they owners (non existent) knowledge.

Did you actually check?
I only did a quick and dirty ipq806x build yesterday (and didn't even flash&boot it), without too much investigating (there are some remaining conflicts and luci-app-opkg skews results (meaning I couldn't easily completely omit opkg from my build, despite using apk). Both images (following my normal configuration) came out at 14 MB.

You do know about the -package syntax, right? This allows you to remove packages using the firmware selector and strip down the image. (Just like using imagebuilder, because in fact that's all that auc, owut, LuCI Attended Sysupgrade and Firmware Selector do via the ASU build server's API to image builders.)

1 Like

If you just look at the bin files, apk is smaller (I'm assuming apk-mbedtls is going to be smaller than apk-openssl...)

$ opkg update && opkg install apk-mbedtls

$ ll /bin/opkg /usr/bin/apk
-rwxr-xr-x    1 root     root        155131 Jun  2 13:43 /bin/opkg*
-rwxr-xr-x    1 root     root        105787 Jun 11 14:58 /usr/bin/apk*

Let's check dependencies.

$ opkg depends opkg
opkg depends on:

$ opkg depends apk-mbedtls
apk-mbedtls depends on:

libc and uclient-fetch are standard, ignore those. If you have luci installed, you'll probably have something that depends on libpthread, so ignore it. Same holds for libubox, its use is ubiquitous.

zlib might be interesting, who uses it?

$ opkg whatdepends zlib
Root set:
What depends on root set
        nmap 7.93-3     depends on zlib

Ok, we'll count that against apk.

$ opkg files zlib
Package zlib (1.3.1-r1) is installed on root and has the following files:

$ ll /usr/lib/
-rw-r--r--    1 root     root         81923 Jun  2 13:43 /usr/lib/

That leaves libmbedtls:

What depends on root set
        wpad-basic-mbedtls 2023-09-08-e5ccbfc6-6        depends on libmbedtls12
        px5g-mbedtls 10 depends on libmbedtls12
        libustream-mbedtls20201210 2023-02-25-498f6e26-1        depends on libmbedtls12
        luci-ssl git-23.035.26083-7550ad6       depends on libustream-mbedtls20201210

Assuming you want wpad to work on a wifi router, we can also ignore this one.

We've got an extra ~80kB of libs to consider as "part of apk", so 155 vs (106+81)=187 => same size as far as I'm concerned.

1 Like

Well, my observation of devs' behavior is the opposite, they constantly try to eliminate dependencies and reduce footprint (that's why, for example, all the core scripting is done in busybox ash, sed and awk, not bash, gnu sed or gawk).

I personally will go out of my way in my projects to avoid using non-standard utilities and try to reduce the size of code. Just last night I was working on means for stripping comments and extra white space from the owut source at install time, because its raw code is 30k bigger than the auc binary that it might someday replace.


I use the firmware selector, first and foremost, to search for the standard downloads for a device. Yes, the firmware selector can be used to customize the image (by both adding and removing packages as needed/desired), but at its core, it is just a tool to find the downloads.

If a user adds packages, they are doing this at their option, and it is more space efficient than post-flash installations for any systems with squashfs because it is compressed. Obviously it still needs to fit inside the available memory footprint, but if it's too big, one can remove unneeded packages very easily. So, take for example a situation where someone wants to perform extroot but can't fit the requisite packages... if they don't use PPPoE, they could easily remove the PPP packages and recover the space accordingly. In this way, users of older, more resource constrained devices also benefit greatly.

While they are different under the hood, the user experience will be largely similar, so this is a weak argument aside from potentially the size of the binaries associated with the two package managers (I haven't checked the sizes).

Let's take a popular 8/128 device as an example (I could find 8/64 if I looked a bit harder)... TP-Link's Archer C7v1 is such a device. Although it will fall off the train with the next major release due to limited flash, it runs the current version of OpenWrt (23.05). Contrast that with the last firmware upgrade available from TP-Link: December 2014. So, that's basically a full decade of additional firmware availability that provides up-to-date security and additional extensibility. Eventually, all hardware phases out due to the progression of technology, although please forgive me if you're reading this an original IBM XT with an 8088 processor.

This is a silly and flawed statement. A more complex interface or just a CLI without any GUI options will still not necessarily help prevent users from misconfiguring things. In fact, one advantage of LuCI is that it ensures proper config file syntax (with a few notable exceptions), which can prevent a whole bunch of issues. Pretty interface or not, nothing is going to stop a user from setting their wan firewall zone's Input policy to ACCEPT. The system does what it's told, it doesn't know, nor should it presume to know, the goals and reasons that the user may change a given setting. Further, there are two largely unrelated things to learn here: 1) Networking concepts, and 2) Linux and OpenWrt specific syntax and methods. You can have someone who is an expert in one and has no idea about the other -- they'll still need to learn stuff and they may still misconfigure things badly until they do learn it.

An up-to-date firmware with the latest security patches will improve their posture when compared to using firmware that is 10 years old from the vendor. And a powerful and flexible firewall means that they can further harden their systems with very granular rules if they want. But, obviously they can misconfigure things and make it worse, but that's true with any advanced firewall solution regardless of the vendor (OpenWrt, DD-WRT, OpenSense/PFsense, Unifi, EdgeMax, ... the list goes o).

There are very few 'wizards' within OpenWrt.... in fact, none by default. And the one you're commenting about is simply about making upgrades easier (installed optionally by the user). Seems like an odd reason to complain.

Not sure what this means, but my comments above apply. A user will have a more secure setup with OpenWrt in a default (or nearly default) state than an ancient vendor firmware.

One should not punish advanced users by dumbing down the system and removing features that make the platform so useful in the hopes of 'saving' those who are novices and might make mistakes. Nor should one punish the novice who either wants a secure and easy solution with largely default configurations and/or the ability to learn more advanced concepts. IMO, OpenWrt really does a good job at serving both novices and advanced users, although there is always room for improvement.


Yeah, proper device identification remains a big sore point, doesn't it? Evidence is that we get "I bricked my router by installing/upgrading with xxxV2 instead of xxxV3, I thought they were the same."

Which is a big reason why LuCI ASU and auc are such nice tools, they just do the right thing...


I finally wrote the tool:

$ pkg-size --packages opkg,apk-mbedtls
'opkg' files:
    155,131 /bin/opkg
        108 /etc/opkg.conf
        103 /etc/opkg/customfeeds.conf
        298 /etc/uci-defaults/20_migrate-feeds
         16 /lib/upgrade/keep.d/opkg
      1,079 /usr/sbin/opkg-key
'uclient-fetch' files via 'opkg':
     24,595 /bin/uclient-fetch
    181,330 bytes used by 'opkg' and its unique packages

'apk-mbedtls' files:
    105,787 /usr/bin/apk
    197,075 /usr/lib/
    302,862 bytes used by 'apk-mbedtls' and its unique packages

$ pkg-size --packages opkg,apk-mbedtls --all --ignore libc,libgcc1
'opkg' files:
    155,131 /bin/opkg
        108 /etc/opkg.conf
        103 /etc/opkg/customfeeds.conf
        298 /etc/uci-defaults/20_migrate-feeds
         16 /lib/upgrade/keep.d/opkg
      1,079 /usr/sbin/opkg-key
'libubox20240329' files via 'opkg' (shared with 31 other packages):
     57,452 /lib/
'uclient-fetch' files via 'opkg' (shared with 0 other packages):
     24,595 /bin/uclient-fetch
'libuclient20201210' files via 'uclient-fetch' (shared with 1 other package):
     28,674 /usr/lib/
    267,456 bytes used by 'opkg' and all dependent packages

'apk-mbedtls' files:
    105,787 /usr/bin/apk
    197,075 /usr/lib/
'libmbedtls21' files via 'apk-mbedtls' (shared with 2 other packages):
    438,667 /usr/lib/
    163,874 /usr/lib/
     81,923 /usr/lib/
'zlib' files via 'apk-mbedtls' (shared with 8 other packages):
     81,923 /usr/lib/
  1,069,249 bytes used by 'apk-mbedtls' and all dependent packages

There are indications that APK may not be part of 24.xx, so it may not even make it into release until the time after that [4,8] devices are not supported due to the size of the kernel/radio-related packages. Also, if you're making an image for [4,8] devices, it may not be a worst idea to not include neither opkg nor apk in it anyways. So moot point.