Hi, the MikroTik equipment is really nice, but the increased requirements of version 7 wrt flash space are being a significant blocker on devices that otherwise have enough RAM and CPU but still on 16mb flash. Such devices are sill sold today and the inability to reliably upgrade them without physical presence and ability to netboot. It is just not practical.
So I propose a "lite" version of routeros, for these 16mb flash devices that removes certain features:
remove all of ppp, pptp, pppoe, l2tp, sstp, openvpn, client and server functionality and authentication for those (keep wireguard)
remove bridge port extensions, bridge MST, bridge NAT, bridge MSTP
remove switch
remove mesh
remove vxlan, vrrp, macsec (802.1AE)
maybe remove macvlan and veth
remove detect internet functionality and tools
remove routing BFD, filters, GMP, IGPM proxy, RIP, RPKI, isis, all mpls-only related functionality (keep VRF)
remove ntp server
remove auto upgrade client
remove all the resource utilities
remove queues except queue tree
remove radius
remove ftp server
maybe remove ssh server
remove telnet server
remove bandwidth test server and client
remove email send
remove ip scan
remove mac server
remove profiler
remove netwatch
remove romon
remove sms (it's broken anyway)
remove the cloud backup sync
remove speedtest
remove traffic generator
remove traffic monitor
remove wol
remove hotspot
remove kid control
remove socks (it's mostly broken anyway)
remove tftp
remove tr069
remove web proxy (it's mostly broken anyway)
remove smb
remove dot1x client and server
remove iot
A call for a "lite" version of routeros 7 (image size reduction)
Last edited by i4ko on Thu Mar 14, 2024 7:08 am, edited 1 time in total.
Re: A call for a "lite" version of routeros 7 (image size reduction)
I get the "16MB problem". And it is a problem.
But not sure a "Lite" version help. I think just add more complexity & features don't so neatly correspond to the disk size is the other problem. And some of the code for features is in the kernel, or bundled into larger processes.
The issue is any "bigger" features (in terms of file & without dependancies) should be moved out, so folks can better mix-and-match. For example, I sometimes need some extra-packages (gps, zerotier, container) but often don't need IPv6 or hotspot (those two were possible to remove in V6, so not sure what changed in V7).
I extracted the ARM package below, you can kinda see how things are not so cleanly mapped from feature to files. But you can kinda see how IPv6, hotspot, snmp, and smb all look like better "targets" for packages, and likely more like the "proxy things" all looks kinda separate too. But the routing stuff looks pretty bundled IMO. Now using multiple packages costs space too – something Mikroitk has pointed out on this topic – but there has to be somethings that can pulled out that overwhelm any add'l size from the packaging.
Also, I'm not saying necessarily that smb etc made into packages needs to go to "extra-packages" – it could be in a default install. But if it was a package, it could be removed to add something else. That's the problem, not a "Lite" version.
So the "menu" to cut looks more like this in reality (sizes are the UNCOMPRESSED size):
And if you look for just big files over 100KB it looks like this:
But not sure a "Lite" version help. I think just add more complexity & features don't so neatly correspond to the disk size is the other problem. And some of the code for features is in the kernel, or bundled into larger processes.
The issue is any "bigger" features (in terms of file & without dependancies) should be moved out, so folks can better mix-and-match. For example, I sometimes need some extra-packages (gps, zerotier, container) but often don't need IPv6 or hotspot (those two were possible to remove in V6, so not sure what changed in V7).
I extracted the ARM package below, you can kinda see how things are not so cleanly mapped from feature to files. But you can kinda see how IPv6, hotspot, snmp, and smb all look like better "targets" for packages, and likely more like the "proxy things" all looks kinda separate too. But the routing stuff looks pretty bundled IMO. Now using multiple packages costs space too – something Mikroitk has pointed out on this topic – but there has to be somethings that can pulled out that overwhelm any add'l size from the packaging.
Also, I'm not saying necessarily that smb etc made into packages needs to go to "extra-packages" – it could be in a default install. But if it was a package, it could be removed to add something else. That's the problem, not a "Lite" version.
So the "menu" to cut looks more like this in reality (sizes are the UNCOMPRESSED size):
Code: Select all
cd nova/bin; ls -lh | awk '{print $5, $9}' | sort -hr
1.4M route
1.2M net
703K sys2
576K parser
267K bridge2
210K lcdstat
199K cerm
178K snmp
166K smb
166K diskd
139K wproxy
139K login
138K graphing
134K quickset
118K cloud
106K www
106K upnp
102K ssld
102K resolver
98K trafficgen
98K dot1x
86K crossfig
82K vrrp
82K romon
74K user
74K mesh
74K loader
71K mproxy
70K ntp
70K moduler
70K letsencrypt
66K ptp
66K log
66K led
66K fileman
66K detnet
66K btest
62K socks
62K sniffer
62K installer
62K discover
54K mtget
50K radius
46K portman
46K natpmp
46K logmaker
46K kidcontrol
46K keyman
46K igmpproxy
42K mode
38K ping
38K mactel
38K email
34K tftpd
34K profiler
34K partd
34K ftpd
30K watchdog
30K traceroute
30K sertcp
26K undo
26K sstore
26K sermgr
26K mepty
26K ippool
26K agent
25K poeupdatefwv3
22K trafflow
22K macping
21K telnet
18K backup
17K rtrace
13K arpd
9.2K telser
9.2K panicsl
5.1K havecardbus
5.1K convertbr
7B modprobed
4B cerm-worker
And if you look for just big files over 100KB it looks like this:
Code: Select all
find . -type f -exec ls -lh {} + | awk '{print $5, $9}' | sort -hr
1.9M ./nova/lib/console/1073741824.mem
1.4M ./nova/bin/route
1.2M ./nova/bin/net
1.1M ./lib/libcrypto.so.1.0.0
703K ./nova/bin/sys2
673K ./lib/modules/5.6.3/drivers/net/prestera_dx_mac.ko
634K ./bndl/wifi/nova/bin/ww2
576K ./nova/bin/parser
480K ./bndl/ppp/nova/bin/ppp
449K ./bndl/security/nova/bin/ipsec
411K ./lib/modules/5.6.3/kernel/fs/ext4/ext4.ko
407K ./lib/modules/5.6.3/kernel/net/ipv6/ipv6.ko
393K ./lib/libumsg.so
267K ./nova/bin/bridge2
234K ./lib/libc.so
227K ./bndl/hotspot/nova/bin/hotspot
211K ./lib/libucrypto.so
210K ./nova/bin/lcdstat
201K ./lib/modules/5.6.3/kernel/drivers/usb/mu3h/mu3h-xhci-hcd.ko
199K ./nova/bin/cerm
178K ./nova/bin/snmp
176K ./lib/modules/5.6.3/kernel/drivers/ata/libata.ko
175K ./bndl/dhcp/nova/bin/dhcp
173K ./lib/modules/5.6.3/kernel/drivers/usb/core/usbcore.ko
171K ./bndl/security/nova/bin/ssh
171K ./bndl/ipv6/nova/lib/console/1212153856.mem
169K ./nova/etc/pciinfo/system.x3
166K ./nova/bin/smb
166K ./nova/bin/diskd
166K ./bndl/wifi/nova/lib/console/1275068416.mem
162K ./lib/modules/5.6.3/drivers/net/packet_hook.ko
155K ./lib/modules/5.6.3/net/bridge/bridge2.ko
148K ./lib/modules/5.6.3/drivers/net/quectel_mhi.ko
139K ./nova/bin/wproxy
139K ./nova/bin/login
138K ./nova/bin/graphing
138K ./lib/librappsup.so
134K ./nova/bin/quickset
131K ./bndl/ppp/nova/lib/console/1090519040.mem
124K ./nova/etc/leds/system.x3
121K ./lib/modules/5.6.3/kernel/drivers/net/bonding/bonding.ko
121K ./etc/license
118K ./nova/bin/cloud
116K ./lib/modules/5.6.3/kernel/drivers/scsi/scsi_mod.ko
115K ./lib/modules/5.6.3/kernel/net/netfilter/nf_conntrack.ko
106K ./nova/bin/www
106K ./nova/bin/upnp
103K ./lib/modules/5.6.3/kernel/drivers/mmc/core/mmc_core.ko
102K ./nova/bin/ssld
102K ./nova/bin/resolver
101K ./lib/modules/5.6.3/drivers/net/usb/mbim.ko
100K ./lib/modules/5.6.3/kernel/drivers/usb/serial/option.ko
100K ./lib/modules/5.6.3/kernel/drivers/usb/host/xhci-hcd.koRe: A call for a "lite" version of routeros 7 (image size reduction)
Of course to save space many utilities are in a somewhat monolithic binaries, even if those are dynamically linked they still contain the code to do all the extra functionality. Separating into extra packages will only add more complexity and may not end up saving any space. That is why my suggestion is to remove functionality (macro it so the compilers don't include it into the binaries) from the binaries already there, and remove just some of the binaries altogether. Even if some binaries of those I propose removed are small, it accumulates, and with being able to slim the fat ones a bit of space will be reclaimed. Point being - if you want full functionality you should not expect to do so on 16mb devices. But the way it is now, MTK are kind of trying to shoehorn all of that into these devices as well, functions that 99.999% of those using the small devices will not ever be using.
Last edited by i4ko on Thu Mar 14, 2024 6:52 am, edited 1 time in total.
Re: A call for a "lite" version of routeros 7 (image size reduction)
Remember that in other posts, MikroTik pointed out that it would actually make file sizes larger to split some things out.
Over half what the OP requested be removed is part of the stock Linux kernel (ppp, ipsec, wireguard, etc.). ppp, for example, is required for pppoe, a standard still used by ISPs large and small across the world. And who knows how many integrators and operators worldwide aren't doing some kind of fancy thing with 5 of the 50 things you list? (And not the same 5 things...)
I have probably 600-700 MikroTik devices deployed throughout my network. While most of the radios and switches do bridging only, it's nice to know that I can turn some of them into formidable routers, should the need arise (and it has on occasion). And while most of my customers don't knowingly make use of IPv6, when it works properly, it's a lifesaver for gamers stuck behind CGNAT.
If we're going to play this game, I would say SMB/DLNA, if it's feasible package-wise, would be the stuff I split out from 16MB devices. Zero of the 300+ home routers (hAP AC2/AC3/AX3) I have deployed and manage are using the USB port for anything, let alone storage. (The AX3 is certainly a good candidate for that, though.) But again, the problem is if that's split out, how much larger does it make the package for the people who might want to add SMB back on a hAP AC2 (because they've been able to up to this point)?
Bottom line is, you're going to make somebody mad no matter what you cut out. To this point though, the complaining has to be more than the Same Ten People here on the forums.
Over half what the OP requested be removed is part of the stock Linux kernel (ppp, ipsec, wireguard, etc.). ppp, for example, is required for pppoe, a standard still used by ISPs large and small across the world. And who knows how many integrators and operators worldwide aren't doing some kind of fancy thing with 5 of the 50 things you list? (And not the same 5 things...)
I have probably 600-700 MikroTik devices deployed throughout my network. While most of the radios and switches do bridging only, it's nice to know that I can turn some of them into formidable routers, should the need arise (and it has on occasion). And while most of my customers don't knowingly make use of IPv6, when it works properly, it's a lifesaver for gamers stuck behind CGNAT.
If we're going to play this game, I would say SMB/DLNA, if it's feasible package-wise, would be the stuff I split out from 16MB devices. Zero of the 300+ home routers (hAP AC2/AC3/AX3) I have deployed and manage are using the USB port for anything, let alone storage. (The AX3 is certainly a good candidate for that, though.) But again, the problem is if that's split out, how much larger does it make the package for the people who might want to add SMB back on a hAP AC2 (because they've been able to up to this point)?
Bottom line is, you're going to make somebody mad no matter what you cut out. To this point though, the complaining has to be more than the Same Ten People here on the forums.
Re: A call for a "lite" version of routeros 7 (image size reduction)
Agree, that is why my suggestion is for a lite version, but in addition to the full version. Lite version prioritizes stability, better guarantee that remote/schedules updates will succeed, no lost configuration on restart, no worry that you need to travel to location to netboot, ship replacement etc. If at any point you need to use any of the extra functionality just load the full version (if it works) and be prepared to face the consequences (not able to upgrade, parts of configuration lost on restart, dead routers you need to physically go to netboot, ship replacements etc.) but it is a choice. Having packages is additional complexity that should not be needed.Bottom line is, you're going to make somebody mad no matter what you cut out. To this point though, the complaining has to be more than the Same Ten People here on the forums.
I understand that pppoe may be used somewhere, but these days I don't see it anywhere but on some DSL lines, and even on those the provider's modem can terminate it just fine. With IPv6 it is not even a problem for CGNAT, but who is going to run full fledged routing protocols, especially on CPE/edge where these devices belong today. Anyway, asking Mikrotik to consider just a lite and a full version both with set capabilities, you make your choice.
Re: A call for a "lite" version of routeros 7 (image size reduction)
Well, there is your problem. What seems unimportant to you, is top priority for me. We DO REQUIRE PPPoE, it is used on all lines.I understand that pppoe may be used somewhere, but these days I don't see it anywhere but on some DSL lines, and even on those the provider's modem can terminate it just fine.
I do not want to use a provider router between MikroTik and line. So PPPoE has to stay.
And there are probably a lot of features that are important to people, or that are not so easily split off.
I think "application" level services can all be removed. SMB, proxy, hotspot, speedtest, cloud backup, that kind of thing.
But it is not sure that this will gain enough space.
An alternative approach would be to keep maintaining 7.12.1 for some time, adding security fixes and fixing important bugs, and keep that as a final version for the affected devices.
Re: A call for a "lite" version of routeros 7 (image size reduction)
You won't ever have a "lite" version making everyone happy.
The "solution" would be to "modularize" the ROS, having a "base" system and installable modules for each non-base function.
You know, like - in the (good ?) ol' days - there was Windows XP embedded, you built your OS adding to it only the subsystems that you wanted, being able to create "reduced" systems for low power devices such as PoS' or access control devices, or the way we built BartPE's and similar reduced systems.
Whether this is technically feasible or it is an impossible with RoS is another thing, and even if possible it has to be seen if it can become part of Mikrotik future plans..
The "solution" would be to "modularize" the ROS, having a "base" system and installable modules for each non-base function.
You know, like - in the (good ?) ol' days - there was Windows XP embedded, you built your OS adding to it only the subsystems that you wanted, being able to create "reduced" systems for low power devices such as PoS' or access control devices, or the way we built BartPE's and similar reduced systems.
Whether this is technically feasible or it is an impossible with RoS is another thing, and even if possible it has to be seen if it can become part of Mikrotik future plans..
Re: A call for a "lite" version of routeros 7 (image size reduction)
RouterOS has the capability to install optional modules, but there is no resolution of inter-dependencies.
So, when one module requires another module to function, it is upon the user to install both modules.
This caused some issues in v6 because there were many low-level modules (like PPP, DHCP) that were required by other functions (e.g. VPN tunnels).
So I would propose not to modularize to that level, but only use modules for "application level" functions that require only the OS functionality and not eachothers functionality. Like the ones I mentioned above.
An issue, however, is that the total size occupied by a base system and all optional modules is more than that of a larger base system that already has these optional functions included (due to overhead in the package installation system). So when they would now go back to making all those applications a module, you could not make an install that is similar to the current (7.13/7.14) situation that "just fits" (but fails over time due to config database expansion etc).
So, when one module requires another module to function, it is upon the user to install both modules.
This caused some issues in v6 because there were many low-level modules (like PPP, DHCP) that were required by other functions (e.g. VPN tunnels).
So I would propose not to modularize to that level, but only use modules for "application level" functions that require only the OS functionality and not eachothers functionality. Like the ones I mentioned above.
An issue, however, is that the total size occupied by a base system and all optional modules is more than that of a larger base system that already has these optional functions included (due to overhead in the package installation system). So when they would now go back to making all those applications a module, you could not make an install that is similar to the current (7.13/7.14) situation that "just fits" (but fails over time due to config database expansion etc).
Re: A call for a "lite" version of routeros 7 (image size reduction)
I don't know, but right now if I were professionally using a number of the "at risk" devices I wouldn't sleep well with 16 Mb (or 15.2 or 15.3) devices running with a few hundreds of Kb free, as you say config database expansion, a backup file left accidentally on the device storage, a lot of things can botch for good a system that is "on the border" .
The ones that I believe can still run those devices "safely" are those that are not using the wireless, because there isn't any on the device or because they are using a wireless device as a non-wireless one.
Surely when/if there will be a modularized system users will need to discard some functionalities (or upgrade to a new device with more storage) but such an approach would give more time for the transition (if needed) or allow for existing devices that do not need *all* the functionalities to continue working reliably.
The issue - as I see it - is not so much for amateurs/home users that may well survive (say) an AP that bricks itself unexpectedly and that it takes a couple of days to revive or a week to be replaced, or that all in all can continue running an older ROS version, it is the professionals that manage many of these devices that will suffer the most for downtime and fixes/replacements.
BTW (sorry I don't want to go offtopic but it has to be said) Mikrotik should celebrate those that take the risk of updating their devices often and thus - through their bug reports/tickets - contribute to fix all the issues of new releases.
The ones that I believe can still run those devices "safely" are those that are not using the wireless, because there isn't any on the device or because they are using a wireless device as a non-wireless one.
Surely when/if there will be a modularized system users will need to discard some functionalities (or upgrade to a new device with more storage) but such an approach would give more time for the transition (if needed) or allow for existing devices that do not need *all* the functionalities to continue working reliably.
The issue - as I see it - is not so much for amateurs/home users that may well survive (say) an AP that bricks itself unexpectedly and that it takes a couple of days to revive or a week to be replaced, or that all in all can continue running an older ROS version, it is the professionals that manage many of these devices that will suffer the most for downtime and fixes/replacements.
BTW (sorry I don't want to go offtopic but it has to be said) Mikrotik should celebrate those that take the risk of updating their devices often and thus - through their bug reports/tickets - contribute to fix all the issues of new releases.
Re: A call for a "lite" version of routeros 7 (image size reduction)
remove wireguard tooremove all of ppp, pptp, pppoe, l2tp, sstp, openvpn, client and server functionality and authentication for those (keep wireguard)
maybe remove ssh server
remove winbox support
remove API support
remove ssh/telnet/mactelnet client
LEAVE ssh server
Just my ¢2
I'd love to see RouterOS Lite (well more like "RouterOS (C)AP edition").
Re: A call for a "lite" version of routeros 7 (image size reduction)
Likely more can be gained by removing webfig than by removing winbox support...
-
-
gigabyte091
Forum Guru
- Posts: 1205
- Joined:
- Location: Croatia
Re: A call for a "lite" version of routeros 7 (image size reduction)
Or... Mikrotik just put 32 or more MB of flash into your devices for f... sake. It's 2024...
Re: A call for a "lite" version of routeros 7 (image size reduction)
I don't think that would affect existing devices...
-
-
gigabyte091
Forum Guru
- Posts: 1205
- Joined:
- Location: Croatia
Re: A call for a "lite" version of routeros 7 (image size reduction)
Ofcourse it wouldn't but all future device won't be affected by low flash space.
Re: A call for a "lite" version of routeros 7 (image size reduction)
Current (and likely future) devices already have more flash space... except for some pure switches, were it is not required so much.
Of course that would still mean a "lite" version of routeros for switches (not switchos) would have to be released, which does not include all those features that are only required in a wireless router.
For now, just omitting the wireless package works, but of course in the future the base routeros image will again grow beyond 16MB.
Of course that would still mean a "lite" version of routeros for switches (not switchos) would have to be released, which does not include all those features that are only required in a wireless router.
For now, just omitting the wireless package works, but of course in the future the base routeros image will again grow beyond 16MB.
Re: A call for a "lite" version of routeros 7 (image size reduction)
It might become a problem if you upgrade such switches from pre-7.13 and all of a sudden wireless package gets pushed in, totally unnecessary !Current (and likely future) devices already have more flash space... except for some pure switches, were it is not required so much.
If your device is hosting some other stuff on that flash, you might end up with a failed install. Or worse... bricked.
Re: A call for a "lite" version of routeros 7 (image size reduction)
That's not really true. I mainly use MT's LTE routers & there are NO options >16MB flash. Labor cost more than the hardware in my case, so rather replace the router than potentially have outages/costs because of 16MB flash. Problem is the wAPacR is my only choice today (and for several years now too)Current (and likely future) devices already have more flash space... except for some pure switches, were it is not required so much.
e.g. ARM has ZT/BTH but 16MB & MIPSBE has more storage but no VPNs for CGNAT & new "ax" LTE devices don't have miniPCIe (or bands for US/CA). But potential of "bricked routers" would kill the value of Mikrotik...and staying at 7.12.2 is not tenable as there will likely be some security patch needed.
Still not a fan of "lite" version — "most people" want what was working, to continue to work & updates not having a potential to brick the router. But striping out features is the wrong way to go. Plenty of routers with great UI and limited feature set out there, it's the flexibility I'm guessing why most folks use Mikrotik. Where MT drops the ball on flexibility... is picking what software you want running. e.g. everyone has different use cases for RouterOS.
Perhaps some "split" in ARM package might be a solution. e.g. two packages, one for 16MB and another >16MB. Or, even by CPU-type or specific devices – likely some difference in drivers/modules/etc within the ARM family. But IDK the solution. I just hope Mikrotik realize they have problem – that be step #1.
Re: A call for a "lite" version of routeros 7 (image size reduction)
Ok, good note on pppoe @pe1chl, my reasoning was that it is high time we move away from anything ppp. It is a holdout from the era before ikev2. Only case where you should still use pppoe v.s. ikev2 is devices/modems that have hardware framing based on ppp. The comment was good though, this type of discussion is why I started this thread.
Wireguard v.s. openvpn - wireguard is much easier on CPUs, much more lightweight and much smaller footprint. Many less technical uses would prefer one of those over ikev2 (sadly), but it is much more easier to understand (as routeros does not crate a virtual interface for ipsec policies and many home users won't be able to run gre inside ipsec with public vpn services). That's was the reasoning there (and that in many cases it is a working replacement for ppp use cases). Even the old anemic hap lites run wireguard at 40mbps just fine.
Keeping API (but removing the winbox images resources and building them in the winbox) would save a lot more space over keeping webfig. Removing graphing though may be a good way to reduce a bit of space.
Yep - WAP R AC with LTE modules is where 16mb hurts a lot, but also Hex 750Gr3.
Reason why packages won't work - the (squashfs) compression relies on commonality (what's in there plus in the npk is over 32mb already). Two packages will always be bigger than single package because each of them will only compress the common data inside each package, but there will be duplication of the common data between the packages. More packages would take even more space (even more duplication of common data), a single squashfs/package offers much better size management. The only feasible way left (short of inventing a new type of compressed file system images that can mount over each other - and that would be a waste of effort) to reduce size is to reduce features, there is just too much data already. MTK should have used 64mb parts since 2014, but they didn't (other vendors were doing it just fine).
Wireguard v.s. openvpn - wireguard is much easier on CPUs, much more lightweight and much smaller footprint. Many less technical uses would prefer one of those over ikev2 (sadly), but it is much more easier to understand (as routeros does not crate a virtual interface for ipsec policies and many home users won't be able to run gre inside ipsec with public vpn services). That's was the reasoning there (and that in many cases it is a working replacement for ppp use cases). Even the old anemic hap lites run wireguard at 40mbps just fine.
Keeping API (but removing the winbox images resources and building them in the winbox) would save a lot more space over keeping webfig. Removing graphing though may be a good way to reduce a bit of space.
Yep - WAP R AC with LTE modules is where 16mb hurts a lot, but also Hex 750Gr3.
Reason why packages won't work - the (squashfs) compression relies on commonality (what's in there plus in the npk is over 32mb already). Two packages will always be bigger than single package because each of them will only compress the common data inside each package, but there will be duplication of the common data between the packages. More packages would take even more space (even more duplication of common data), a single squashfs/package offers much better size management. The only feasible way left (short of inventing a new type of compressed file system images that can mount over each other - and that would be a waste of effort) to reduce size is to reduce features, there is just too much data already. MTK should have used 64mb parts since 2014, but they didn't (other vendors were doing it just fine).
Re: A call for a "lite" version of routeros 7 (image size reduction)
Actually MikroTik's RB333 released almost 20 years ago had a 64MB NAND chip. However, while every other manufacturer took a step forward and uses a 2GB eMMC nowadays, MikroTik took a step backwards and releases new hardware with 16MB flash chips.MTK should have used 64mb parts since 2014, but they didn't (other vendors were doing it just fine).
Re: A call for a "lite" version of routeros 7 (image size reduction)
Sure: more packages are less efficient for compression. But possible split things based on what [/I]does NOT cause duplications[/i], which may not neatly cut along features. Why I keep reiterating that the focus on "removing features" as "only solution" is misplaced and wrong. It's /lib/module is where there is some fat I think, at least on a device-by-device basis.but there will be duplication of the common data between the packages.
[...]
The only feasible way left (short of inventing a new type of compressed file system images that can mount over each other - and that would be a waste of effort) to reduce size is to reduce features, there is just too much data already.
But all I know is the answer for 16MB devices CANNOT be dropping long-standing features/protocols. Adding entirely new features is how this mess got created. Things do fit today — only recently has that changed and made upgrade "sketchy". So fixable – one way or another – without telling customers "we give up! here is a Lite version".
Re: A call for a "lite" version of routeros 7 (image size reduction)
Now..... I can only laugh at how some theorized "Lite Version" play out. e.g.
How?:@normis "Hey we solved the 16MB flash issue that we created for you!"
When?:"Simple, re-write in Rust and cut half the features"
What features?"Soon! But in Latvia...soon means years."
I use Foo protocol?"Don't worry we added bunch of new features to lite version — to make up for the delay"
"You shouldn't be! We asked the forum for their favorite protocols."
Re: A call for a "lite" version of routeros 7 (image size reduction)
Simple solution that MT needs to address
Stop advertising devices with 16MB storage (2024 ffs) - and stop degrading/deprecating newish devices that had factory installed version of ROS 7.03 (Chateaux LTE 12 - am looking at you - factory software cites 7.0.3)
MT needs to own it and to stop piling on crap features that a raspberry pi could handle (DLNA, SMB etc)
just stop compiling crap into kernel modules and bundling it in just because marketing heads say so and leaving us those who have 16MB devices in the lurch and forcing us to either a) uninstall the wireless module for the sake of upgrades b) netinstall to previous version v7.13
Simply, if MT cannot deal with that, the least they could do, is offer an alternative (unlock the bootloader, allow us with 16MB flash storage to install an alternative such as openwrt etc) - in fairness, if MT pushes devices in marketing strategy with 16MB - they have lost out.
Stop advertising devices with 16MB storage (2024 ffs) - and stop degrading/deprecating newish devices that had factory installed version of ROS 7.03 (Chateaux LTE 12 - am looking at you - factory software cites 7.0.3)
MT needs to own it and to stop piling on crap features that a raspberry pi could handle (DLNA, SMB etc)
just stop compiling crap into kernel modules and bundling it in just because marketing heads say so and leaving us those who have 16MB devices in the lurch and forcing us to either a) uninstall the wireless module for the sake of upgrades b) netinstall to previous version v7.13
Simply, if MT cannot deal with that, the least they could do, is offer an alternative (unlock the bootloader, allow us with 16MB flash storage to install an alternative such as openwrt etc) - in fairness, if MT pushes devices in marketing strategy with 16MB - they have lost out.
Re: A call for a "lite" version of routeros 7 (image size reduction)
Noremove wireguard too
remove winbox support