so reckless
Updated da smol homenet to 7.11.2, today as well “Little Butterfly” 
(I call the mAP-lite so) - no issues:
@Guscht Impressive! The MT Force is strong with this one!!
sigh FML 
I'm tired of complaining about Tik software Q/A issues. I'm now proactively looking to replace all MikroTiks at work with ONIE at the very least and maybe Juniper or Arista for heavy-duty.
I mean just look at 7.11.1 and then the immediate release of .2, what?
Let’s be clear about where the insanity lays.
MikroTik has laid down a consistent track record; they are not an enterprise vendor.
Everyone sets their expectation; repeatedly expecting enterprise results from MikroTik is insane.
Marry the enterprise vendor that provides what you really want, whatever the cost, and don’t look back.
I freely admit my MikroTik marriage is troubled but I find them charming and I have more time than money.
I guess you never heard of CI/CD with constant incremental updates with gradual rollout in waves, automatic rollbacks and integration testing.
Let’s be clear about reality.
MikroTik, VyOS, Cumulus Linux are in the same segment of whatever “enterprise” means for you.
Yet VyOS and Cumulus, both Linux based just like MikroTik has:
- Latest kernel base compared to ROS
- LTS/Stable channel that’s actually “stable”
- Works without any massive/major Q/A issues like ROSv7.
If VyOS and Cumulus Linux can deliver stable OS, why can’t Tik do with ROSv7? ROSv6 didn’t have this much stability issue.
“Enterprise” - high margin, high reliability, high testing vendors requiring never ending licensing and support agreements but with enforceable service levels.
I disagree with grouping MikroTik (hardware) with VyOS and Cumulus Linux (software). MikroTik lives; Cumulus Networks is no longer an independent concern.
I do cut MikroTik some slack; in their business model software is the loss leader; something they can fix later whereas the hardware has to be correct the first time.
Thank you, I didn’t know. I do agree producing reliable Linux based software products is quite often done. My favorite is Debian.
And in a perfect world MikroTik is doing the same. But we don’t live in that world. IMO lobbying for improvement is worthwhile; I do so.
I just suggest conducting such a lobbying campaign and maintaining serenity are both feasible just by maintaining realistic expectations.
In effect MikroTik has been granted undeserved great power over the community’s emotional and mental state. Is such a thing healthy?
My selfish interest here is encouraging the community onto the serene path to set the “bad drama” aside and enjoy the elevated discourse.
“Enterprise” - high margin, high reliability, high testing vendors requiring never ending licensing and support agreements with enforceable service levels.
I disagree with grouping MikroTik (hardware) with VyOS and Cumulus Linux (software). MikroTik lives; Cumulus Networks is no longer an independent concern.
I do cut MikroTik some slack; in their business model, software is the loss leader; something they can fix later whereas the hardware has to be correct the first time.
Thank you, I didn’t know. I do agree producing reliable Linux based software products is quite often done. My favorite is Debian.
And in a perfect world MikroTik is doing the same. But we don’t live in that world. IMO lobbying for improvement is worthwhile; I do so.
I just suggest conducting such a lobbying campaign and maintaining serenity are both feasible just by maintaining realistic expectations.
In effect MikroTik has been granted undeserved great power over the community’s emotional and mental state. Is such a thing healthy?
My selfish interest here is encouraging the community onto the serene path to set the “bad drama” aside and enjoy the elevated discourse.
The solution is simple: “stable” channel should be renamed to Beta (as it is actually beta, regardless of what mikrotik marketing team says).
Why don’t you pull the 7.11.1 release from downloads if it has a serious flaw?
Naming is not the problem IMO. When Mikroitk uses “stable”, I take it to mean it had no serious known bugs when promoted from a “testing” release. The problem is there is not release channel (aka cisco train / git branch) that has a lower rate of changes – like “long-term” used to work in V6 (which wasn’t actually very long-term sometimes, but reflected a “more stable” release).
I’ve long accepted the looser definition of “stable” than most vendors. But having “three choices” on the “stability curve” used to solve this. Just “testing” and almost “stable” doesn’t seem to be enough. Whether it’s called “long-term” or “more-stable” or whatever, a 3rd choice for a release channel is what’s missing.
MT problem is simple they don’t have at all or lack of sufficient unit test coverage in the code base, look at how brittle the SFP and Bridging code section where every release they claim improvement on this areas so frequently, I hate to say this I hope ROS v7 wasn’t design by bunch of drunk engineers from MT thinking that it’s really OK as a customers can be their guinea pig to test their code.
Please fix your definition or world view of what is “stable” really means, don’t make us your UAT department and offload QA task to us, it’s not good at all
The first thing I heard in my MTCNA was “long-term is stable, stable is beta”!
Unfortunately I have to say thats so 100% true. ROSv7 is sooooooooooooooo far away from a production-ready stable. Its like they fix 2 bugs and introduce 10 new bugs with each release.
A real nasty thing is, they (how stupid can a company be!!!) retired the CCR1036 and replaced them with the CCR2116. Those come with a factory v7 pre-installed, which is NOT production-ready, which means those devices are a useless paperweight. I hope the CCR1072 is longer maintaned!
@Guscht: You didn’t hear the news?
http://forum.mikrotik.com/t/closing-of-the-beta-forum/168623/1
v7 is stable for a long time now.
updated about 20 devices (10 different types) without issues
I just hope someone is looking at the various upgrade issues that seeming stem from this change:
There quite of few post littered in the forum about issues with upgrades after this change, some requiring netinstall in what appear to be “stable” to “stable” upgrade. Most recently here:
http://forum.mikrotik.com/t/netinstall-on-linux-stalls-with-wap-ac-lte6/169280/1
but there are others.
The stupid thing in this entire work, is question “WHY?” Mikrotik limit this devices to work only with RoS 7, which is not perfect, and not production ready yet, when have very stable RoS v6 that works perfectly for decades before… Why MTK not allow user to choise what RoS version and build will use for their paid hardware. Once again, when RoS 7 will be really really production ready, can discount RoS 6 for new devices.
V7 is required for newer hardware. Has been sad before.
Running v7 in production requires knowledge of RouterOS and its limitations.
It’s likely RouterOS 6 Linux kernel doesn’t have new hardware support.
Back port v6 or new kernel v7 or both?
Can MikriTik afford both?