Hi everyone,
As some of you may be aware, kbin’s development effort has stalled significantly in the past month or so. I’ve made the decision (for now) to move kbin.run’s codebase to a fork of kbin called mbin. I’ve already completed the migration and users should experience no adverse side effects other than some default visualization changes that can be reverted in the settings menu on the right hand side of the page (click on the gear icon).
I am closely monitoring the situation with kbin, but the enhanced security of mbin alone (a version bump in the dependencies) was enough to convince me to make this change in order to maintain the security of my system. NO domain changes will take place and functionality is 100% compatible with kbin in its current state.
Constructive feedback is always welcome, thank you for the continued support and utilization of kbin.run.
Have a great weekend,
-debounced
Now that Kbin has received some updates, I am wondering if we will continue to stay on Mbin or if we will migrate back to Kbin.
I guess I’m a little biased since I’m one of the Mbin maintainers, but we’ve had two significant releases with over 200 PRs that are not part of /kbin. We’re selectively picking /kbin enhancements/code changes that we want in Mbin (and rewriting the ones we don’t like or doing something completely different), but I think the damage is done and our vision for Mbin is not compatible with /kbin. I’m not going to go into all the drama behind the scenes, but I think it’s best if Mbin and /kbin go their separate ways.
https://github.com/MbinOrg/mbin/releases