Sweet, I can’t wait to see ModAI implementing moderation to further Reddit’s boring echo chamber.

Feeling inspired, I set out to push the limits of recursive emulation myself. My first step was getting a Linux emulator running inside Minecraft. Yes, you heard me right - Linux running inside Minecraft. Once I had achieved that, the natural progression was to install Yuzu on this virtual version of Linux. It took some trial and error, but eventually, I managed to do just that.

At this point, I could hardly contain my excitement. The results were impressive; the performance increase was noticeable compared to previous iterations. But for me, that wasn’t enough. I wanted more. So, in true recursion fashion, I installed another Linux emulator within this Minecraft-embedded Yuzu environment. This new iteration had its own Yuzu setup, and thus the cycle continued.

As layers upon layers of nested Linux environments grew, the performance kept improving exponentially. Every time I upgraded the recursion level, the FPS went through the roof. Eventually, it reached unbelievable heights. Today, with multiple levels of recursion, I am proud to announce that the performance of this nestled setup is now over 9000 FPS!

If the developers’ wants and needs don’t intersect with a given user, there is no way forward for that user, community manager or not.

I suspect the small size of the dev team and the general nature of an OSS project means there aren’t swarms of people around volunteering to be community managers.

Small projects your sway with the project is directly proportional to your ability to submit pull requests. It’s just a sad fact that it’s easier to say “I wish we had feature X” vs. “Here is a pull request that implements feature X”.

At least with OSS you are getting what you paid for (nothing!), vs commercial companies where you pay for the software and they STILL ignore you.

Even “Why don’t you open an issue on our source tracker” will often effectively shut down suggestions from less tech savvy newcomers.

How should developers handle feature requests? Keep in mind there is a need for the whole team to see the suggestion and it’s also good to have a place to gather feedback and further discuss.

Be aware that depending on your workload and/or deployment processes, OpenBSD may or may not be a better choice. For example, OpenBSD has a very secure default install, but containerization tools like Docker are not available. Additionally, if you require specialized hardware (e.g., a specific network card), OpenBSD may not have the required drivers available. However, if you prioritize security and want a system that is less prone to attacks and malware, OpenBSD could be a good option for you. Here’s a checklist of things to consider before making the switch:

• Check whether all necessary hardware and software are supported by OpenBSD.
• Make sure you have a backup plan in case something goes wrong during the migration process.
• Get familiar with the OpenBSD user interface and commands to ensure smooth transition.
• Back up all important data and settings before the migration.
• Update your software sources to ensure you have access to the latest stable versions of software packages.
• Prepare yourself with the knowledge of how to handle any issues that might come up during the migration process.
• Test the system thoroughly after the migration to ensure everything is working as expected.

Overall, switching to OpenBSD can be a rewarding experience if you take the necessary precautions and prepare yourself well. Good luck with your migration! Let me know if you need further assistance or have any other questions related to OpenBSD or Linux operating systems.