Interesting. In the past few months, I've added an EU50G and an E62iUGS-2axD5axT, both of which have 128MG of flash storage. I looked for only-16MB models, and they seem to be all very low-end.
But, I also tried to find the size of the current ROS v7 image, and I came up with 13MB+, so, yeah, 16MB seems too small. I can't imagine that the manufacturing cost of giving a bit more future ROS growth headroom to even low-end devices' flash storage would raise the price enough to justify putting such a squeeze on available storage. Odd decision by MikroTik, in my limited view.
From today's perspective they might seem to be low-end. But back when they were released, hAP ac2 or cAP ac were very much top-end of SoHo line of APs. Same goes for a few CRS3xx switches (I'm not going to look for tgem, but I do seem to remember there are a few). And yes, community was very loud when this happened for the first time but MT kept releasing more 16 MB flash models after that.
It has been only very recently that MikroTik finally admitted (internally) that 16MB just isn't enough, and the recently introduced devices again have more memory. I cannot imagine how much effort has been wasted on keeping RouterOS within that 16MB footprint. Even 128MB is not that much nowadays. Even pure accesspoints from the competition have 512MB-2GB of flash.
With storage like that, you can just copy/paste standard software into the system and do not have to write everything yourself, wasting development time and irritating customers with a re-run of all the bugs that others have already solved.
Unifi u6 lite has 32mb flash. the better model go 64mb and more. Don't know for the u7 line though.
When cap ac was released with it's 16mb in 2017 (?) it was okay. Unifi had models with 8mb flash back then. Mikrotik kept using 16mb flash until end of 2023 (!) in Chateau 5G r16. Even on ATL lte18 - not the cheapest device. Only starting recently to use 32mb flash in newer revisions like the 5g r17, the Chateau lte12 2025 model, LAMP 5g, new ATL 5g r16. 32mb is the minimum to be future proof. 16mb line will rather soon or later not fit the routeros package anymore.
A little. If you look at how many ac2 owners complain about having 0 bytes of free space, MikroTik seems to be doing very little about it.
There is still quite a bit of space that could be freed by not including unnecessary drivers, firmware, or other binaries in the RouterOS package that the ac2 does not use. The same applies to other models.
The simplified architecture approach (arm,arm64,mmips,etc) works well when there is enough storage and some space can be wasted. But with only 16 MB, you eventually reach a point where model-specific builds become necessary. That alone could free up a significant amount of space.
Model centric, or more fragmented deployment, like OpenWRT where just about everything seems to be an add-on item . . . Does anyone typically use all the VPN tools, ipv6, MPLS, the vast selection of routing protocools and all that in an ac2 (or, frankly, anywhere)? Seems like a base (still "generic") ROS base load and (as noted) just adding the options needed (still generic) could get an ac2 (and similar) to run with a lot of headroom in 16MB.
The "giant blob" ROS image certainly simplifies things for the user though . . . and both solutions have some merit.
And, considering the overall charge to larger and larger footprints across the electronics industry (i guess nobody cares about performance snd bloat any longer, when you can just throw hardware at the issue), it makes me wonder how much longer 16MB parts will be available.
In the old days, there was a base package and some additional packages that you could or could not install, saving a lot of space. However, inter-dependencies of the packages slowly developed, and you could not install some packages without also installing the other, and vice-versa. So it became more complicated both for users and developers. At one point the whole basic stuff was gathered together into a single "combined package" where you could still disable parts but without any space advantage.
But then in v7 that also disappeared and there is just that single large routeros package plus packages for wireless and some niche uses. But now in v7 they also added the long-demanded feature to install packages directly from the UI and the update servers, instead of having to download a .zip, extract the package, upload that to the router in order to add some not-yet-installed package. I guessed that would open the way to again split the base routeros package into smaller parts, however it probably is a nightmare to convert configurations between monolytic and split packages on upgrade and downgrade (we have seen the mess when wireless packages changed) so not a step they would easily take.
It would again be more work spent on the 16MB situation.
Not having seen the MikroTik ROS source code, unless they have stated that, it may be just an assumption . . .
My point was mainly that OpenWRT, also Linux based and with similar functionality has been doing this forever, and is open source, so it's not like that path would be starting from scratch. (They appear to solve the cross dependencies with separate packages that a component install can simply request.)
Good idea or worth it? I don't know, but between the ability to continue to support otherwise viable hardware, and to improve the architecture, it has merit. It could also open the door to incremental patching, if desired rather than making bug fixes wait for a release. (Or, issue "ROS Lite" for AP use where a lot of the more advanced stuff will almost never be used . . . and those who need that stuff on an AP type device likely need/want more processor anyhow, so could get something more suitable.) It all depends on how easy it is to just totally omit stuff in this case . . . )
There is also the issue than basically unlimited resources can tend to encourage sloppy coding and stupid bloaty things like the Windows paperclip
It all comes down to code cleanliness, dev resources, and a heaping helping of bean counter bull$h1t . . . .
(They could also offer enough detail on these older devices to the open source community such that projects like OpenWRT could support them . . . I'd much rather run OpenWRT on something like a MikroTik than third world junk . . .)
There is a big difference between Linux distributions with package management and RouterOS with packages.
A Linux system is running on a versatile filesystem where files can be created and overwritten independently. A package manager can add or modify files in random places.
RouterOS packages are like disk images. They get copied into a single file on the device, and then get "loop mounted" on the filesystem. Just like how you can mount a .ISO file you have downloaded and look inside it. So they can only add extra files, not overwrite existing files (unless the system knows about this requirement beforehand and elaborate tricks with symlinks are used).
This was very useful in the days of NOR FLASH, where a filesystem with full read/write capability is difficult to implement. I remember that from other Linux-running devices as well: there would be some image with all the software, and there would be a separate partitiion mounted as /var which contains all the data that can be modified. On the running system one could not modify files outside of /var. When a file was known to be required to modify, the filesystem had a symlink e.g. from /etc/resolv.conf to /var/conf/resolv.conf and the resolv.conf file would be modified there.
In a system running on NAND FLASH this is not really required anymore, but still doing it enables the filesystem to be compressed (saving valuable space), with very good compression factor. But it still is not possible to replace individual files.
This means a restricted environment to work in, but it also has advantages: less possibility for trojan code to modify software. Another advantage is that installing a package is a simple operation that can easily be validated: just copying the package file to the flash, and check its checksum after that. There is no intricate process of unpacking an archive into individual files that can be interrupted halfway, or running of config scripts afterwards that can fail or hang. Just copy the images and reboot.
And that is quite useful in a closed device like a router that impatient customers will just powercycle during your upgrade procedure.
Who said Linux distro? I said OpenWRT which is embedded Linux as well for router/AP deployments, and the package management is NOT Linux - it's in OpenWRT itself . . . (Saw/used this on a GLINet Mango . . . Makes an AC2 look advanced!)
In that OpenWRT environment, you clearly CAN add modules to a flash based device without a full rewrite (heck, in a lot of cases, without even a reboot . . . so it's clearly possible.)
Every package noted is capable of being added/dropped individually (and that's just the base install) . . . and no Linux distro in sight. (The "how" is largely irrelevant . . . the point being that it is being done on an open platform, from whih MikroTik could borrow . . . )
Same 16MB flash architecture as MikroTik . . . they just found a way to do it. Perhaps they suck the FS image into RAM, modify and rewrite flash . . . Again, not terribly pertinent to my point. Even if ROS is a binany blob at thjs point, it still needs to load to run, and a direct image vs. a compressed image may change the mechanism, but not the result, but yes, there would be other work to do, obviously.
Yet another one who cannot read, apparently (or just enjoys bashing too much . . . ) I said that OpenWRT had mastered fragmenting it's features, and was an open platform, so that if MikroTik wanted to do something similar, it a) has been done on similar hardware, b) Is definitely possible and c) Is open source, so they would not need to reinvent the process. I offered a screenshot to verify what I had stated. That's it.
It had absolutely nothing to do with what MikroTik is currently doing. It was purely about what they could be doing, and the precedent set by others.
What part of that did you not get? It was SUPPOSED to be an OpenWRT screenshot, showing it being done, despite the off-topic, unrelated, irrelevant spew about Linux distros from others.
Just wanted to leave this here, I've sent a ticket to support and after a few days of back and forth with them got this as answer, I'm glad they're aware of it and fixing it, just to give u guys an update on it.
Serhii T.
1 hour ago
Thank you for the report.
Our developers have already considered this issue, and it will be fixed in future releases, but unfortunately, I cannot share any ETA yet.
I remember using OpenWRT White Russion very long time ago, so I know what OpenWRT is. It was running either on my WRT54GL or on some Motorola AP (can't recall the model) I had flashed by JTAG back then. And yes, OpenWRT had "mastered" a package manager (I think it was opkg already or ipkg?) which worked differently to RouterOS solution. And now? 20 years went by and OpenWRT now uses apk. So what? RouterOS does not need to master anything. These are technical design decisions. And as pe1chl already said, RouterOS way of mounting read-only images has some advantages.
...and what has the package manager discussion to do with routerboard upgrade? I'm out.
Well, the actual OpenWRT firmware selector is very useful.
It is almost impossible to use without a lot of patience and some knowledge (please read as a lot of research), but it allows to "tailor" an image to the exact intended uses of the device.
The default choices are (IMHO) largely "wrong" (though I understand how they try to be a "good for all" compromise) but having the tool available solves a lot of headaches connected to compiling or re-compiling.
This said, I come out of a few days tinkering with OpenWRT on a couple of old routers I can re-use as Access Points and while the "base" is solid, the GUI and even some CLI mechanisms are so badly implemented that they make me want to cry and - strange as it may seem - make me think that Winbox 4 is acceptable and that the layout of RouterOS is logical.
It was relevant to the 16MB limit, excess features in RouterOS and possible ways to improve that situation, as well as to show those saying it wasn't possible on flash based devices a case of it being done (and open source).
Right over that target!
(Never really has an issue with OpenWRT or Luci, but it does have it's quirks . . . )
