Well, it appears that MikroTik is moving from the small-ISP-backbone world to the home consumer world, offering equipment for home usage with features targeted to home users, some of them pre-configured with appropriate default settings for that market.
It would seem natural to have protocols like BGP, OSPF and MPLS disabled by defauit on such devices, to reduce confusion for daddy who wants to make a small change to the config and should not be distraced by a menu called “Routing” which has nothing to do with what he needs but may sound familiar (it is called a Router, what does it do: Routing, probably I need to set something there).
It would seem natural to me when those home boxes come with a couple of packages pre-installed that run the functionality that the particular model offers (like having Wireless/Hotspot only when the device has a wireless interface, BGP/OSPF/MPLS only when it is like a CCR or RB1100 and maybe not even then, and have an easy way under System->packages to add packages from the available packages list without having to fiddle with zipfiles and uploading.
I don’t see what advantages a “Bundle package” brings, except for the side-effect that you can install packages simply by enabling the subpackage from the bundle package.
But it seems like a difficult way of achieving that, and it does not scale well (when packages are added to the Bundle all the time, it grows too big for the smallest devices. has already happened!).
The default enabled/disabled status of the subpackages needs to be considered. To me, it appears that routing and mpls should be disabled by default, ipv6 enabled by default.
i might rephrase this a bit: extending instead of moving. but that’s just my feeling.
if you ask me, webfig (even with that hideous quickset) ain’t for the faint hearted. i deliberately did not mention winbox. people nowadays are “simple”. i saw folks getting around on the GUI of OpenWRT but freaking out from webfig on mikrotik. and this also applies to the Tikapp: it is not a consumer tool. i’d say a true home customer friendly solution would be a separate - airport utility like - app for quick setup and no webfig. or a drastically simplified webfig. i doubt that any of the forum visitors should be taken for a role model for the “random home consumer from the 'hood”. what seems obvious and simple to us, for the everyday guy is like quantum physics.
Don’t have a spare ARM, so can’t test V7. But one thing I’d like to see is UTF8 support. I want to be able to write comments on my own language with all its characters available.
I know it isn’t critical, but would be nice to have…
@doneware: I wouldn’t go into how consumers can or can not handle RouterOS. You can’t solve that, either we can have nice and configurable system as we know it, or it can be user friendly for them. But hardly both at the same time. It’s for different discussion.
For packages, IMHO bundle was a mistake, when it was still like individual packages, only glued together. But it does make sense to merge some packages into one (for start at least system, security, ipv6, dhcp, possibly others) to avoid dependency problems and necessary conditional code (so it would not be bundle, but one new package with stuff from previous individual ones). Is there a reason to not have security or ipv6 in 2019? No. Dhcp may be a little different, but since it’s already required by security…
And for the rest, I wouldn’t mind to have everything, if those components can be disabled, i.e. they would be present but not running, so not exploitable. On the other hand, seeing home stuff in their routers does annoy enterprise people, and enterprise stuff may confuse home users (not that much really, if they can deal with the rest), so having separate optional packages for those wouldn’t hurt either. Another matter is 16MB flash, for that it would be best to have even more smaller packages, but it’s the opposite direction than MikroTik wants to take.
There are no set release schedules for the next beta releases. We will release beta2 once were done fixing current bugs that were found in beta1 and once we expanded the current feature set (and maybe beta on another platform, who knows!).
Thanks, I would presume the beta version of V6 would slow down now and more resources allocated to the v7 dev team. No point in flogging a dead horse essentially.
I would hope that by now the infrastructure is in place to work on both versions in parallel without duplicating all the effort… after all, there is still a long period of parallel maintenance ahead before v6 can be buried and forgotten.
Any chanfs of the sfp tab on interfaces appear on x86 with this new version? Important information is not reported to sfp card users. What tasks are ready for multiprocessing today in v6? and what happened to be in v7? what is the implementation order for them?