yes kbin.melroy.org (sorry about the kbin subdomain name, but changing the domain name will cause federation issues...) is indeed from me (Melroy). And since I wasn't creative the m in Mbin stands indeed for Melroy. Which is my first name. I was also a very active contributor of /kbin on Codeberg before the fork.
Disclaimer: Anyways, since I'm also developing, I sometimes do test some patches or run the latest greatest bleeding edge version from the main branch. Just saying :). Which might not always be the most stable haha. BUT!! You can you run & test the latest features, that is for sure. Haha.
This is indeed all true. Mbin is named after Melroy (I know, I wasn't creative). And by introducing the C4 spec, I made sure the project isn't in hands by a single maintainer and multiple people are already and can become full maintainers of the Mbin project. Hence the reason I also describe it as: "By community, for the community".
We welcome any developer to join us and help if you would like to contribute (in any way or form you like). You can find us at Matrix chat.
Like people already mentioned below, a fork was created after kbin development halted. And the project maintainer was absent but at the same time didn't delegated the work fully. Hence the creation of the fork: Mbin.
I wasn't creative, so the M in Mbin stands for my name: Melroy. xd
Thanks. I do indeed a lot of open source projects in parallel. Besides mbin I also contribute and maintain dozens of open source projects and packages.
Alternatively, setup your own instance is my best advice. If you have some technical skills to setup one. That would help decentralizing the most of course. If you need to help. We are happy to help.
Apparently so. And I don't even get paid to do development. I also have a full-time job at the same time. So Mbin development takes a lot time and effort. And people don't see that.
@jerry@fedia.io is helping us a lot! And the Mbin devs are in close contact with him to keep the server up and running as stable as possible. Both parties are trying to respond quickly. And we all appreciate that a lot! I can't thank Jerry and the Mbin community enough for this.
When I created the Mbin fork, I got a lot of hate without any reason. The reason the fork was created was simply because the kbin development was stopping their development. And the project was a bit trapped by a single maintainer. Hence also the reason I introduced C4 spec: https://github.com/MbinOrg/mbin/blob/main/C4.md.
Since C4 spec is in place, I'm not the only maintainer. Multiple people have full rights of the project. But I'm also tired about all the sh*ttalk about us.
If you have any follow-up questions to me personally (I can only speak on my own behalf). Just post them below my comment.
I'm part of the Mbin team (and created the fork), why are you calling us dickheads? You don't even know the dev team. You don't even know me.
If you want to join Mbin you can just join a Mbin server. If you want to join the community and help out, join the Matrix chat. I don't understand where all the fuzz is about.
@BentiGorlich@gehirneimer.de is also part of the Mbin team (thank you!), and he is also tired about all the negative talking about us, without any foundation of truth.
Yea, so mainly one situation that isn't explained here. Is that the moment you introduce a different language besides C, you now need to talk between C and this other language. This is called language bindings.
The problem with this, is the moment something is changing in C, and this method or interface is used by some Rust code, the Rust binding to C or C to Rust binding is failing, cause all kinds of issues.
Long story short, is that by introducing this additional language you created this technical issue of language bindings. And people who just want to work with C code, now suddenly also need to think about Rust bindings, while they previously didn't need to think about that. As if the Linux kernel isn't complicated enough, introducing this language binding issue is cause more (unwanted) work for some people.
In the end the "C" people are blaming Rust if something fails. And the "Rust" people are trying to explain and help the "C" people to introduce those bindings. waaaahhhh
Yea that whole Rust drama is a pain. Linus unfortunately brought this upon himself. I believe he is also the guy that can fix it be either: Let's remove Rust from the kernel again or... Saying: Just deal with it, we also support Rust, but Rust isn't mandatory.
yes kbin.melroy.org (sorry about the kbin subdomain name, but changing the domain name will cause federation issues...) is indeed from me (Melroy). And since I wasn't creative the m in Mbin stands indeed for Melroy. Which is my first name. I was also a very active contributor of /kbin on Codeberg before the fork.
Disclaimer: Anyways, since I'm also developing, I sometimes do test some patches or run the latest greatest bleeding edge version from the main branch. Just saying :). Which might not always be the most stable haha. BUT!! You can you run & test the latest features, that is for sure. Haha.