I see you all over this thread and I want to share something you might find interesting.

You keep mentioning the server can't handle the anti cheat because it needs to trust client data. Here's an interesting thought: how is client anti cheat supposed to work when it needs to trust input data?

Look up direct memory access cheats. TL;DR Two computers are hooked up such that PC 1 runs the game, PC 2 reads memory from PC 1, and can then output keyboard/mouse inputs, as well as wallhacks/esp. How is the client side anti cheat supposed to know that the keyboard and mouse inputs are legitimate? How is the client side anti cheat to know wallhacks are being used when they are being rendered on an entirely different machine?

FWIW: I'm running jellyfin and a whole host of other services on a Beelink with an Intel n95 and 8gb of ram. Runs like a champ.

Maui has zero Linux support. I don't believe there are any plans for it, either.

However, Avalonia is fully supported, and is almost a drop in replacement for WPF.

...What?

Yes, but by editing config files 😐

Uh... What?

GPU you are converting from 265 to 264 and expecting smaller file sizes, but CPU you are going from 264 to 265?

If compression methods/codecs are equal, the hardware shouldn't affect compression

Would absolutely love to have one. I've got a solid connection ready to seed!

I guess I need to refactor for readability. What you just explained is the entire point of the comment I posted. Refactoring is part of the job. Don't give your manager a choice on whether or not it needs done.

This is it, yeah

It's selling itself as more than an IDE. The idea is to have templates for common languages/frameworks. Ideally, this would mean not having to learn how to init a project in a given framework, not having to learn the build tools, not having to learn deployment, ci/cd, etc. Just open this new webapp, pick a framework, develop, and click a "launch" button to have it spin up in GCP.

Ditto. You could also leave Jellyfin as your back end, and link it to Kodi for your front end (if it is just the UI you are bored of)

Again, my knowledge of the Lemmy codebase is very small, and we could possibly host the monolith in microservices style. The point I am making is this (when it comes to scaling monolith vs microservices):

If the federation logic were split out, we could configure it to run on super tiny docker instances on Google Cloud or AWS. Any time we needed it to, it would autoscale to handle the traffic. The configuration for these dockers could be super minimal memory, no storage, and multiple weak CPU cores. This would be super affordable while still being able to handle as much traffic from federation as we ask it to. One of the cool things with Google Cloud Run is that it handles load balancing between docker containers for you (just point the federation traffic at the necessary URL)

IF Lemmy has things like background services, scheduled tasks, etc, this would significantly muddy the water (we would need each service to be able to handle being run on a multitude of instances, or we would need to be able to disable each one instance by instance). And if we just scaled by spinning up more instances of Lemmy, we would also need to ensure that only federation traffic is heading to the weaker instances that we spun up for such purpose, or we would need to ensure that each spun up instance has enough resources to handle federation traffic along with the main application.

I feel like I need to state once more: I don't necessarily think Lemmy needs to move to microservices. Only that scaling monolith vs microservices is not necessarily the same.