An app to manage important config and unit files (fstab, hosts, sysctl, systemd units, …), and present them as settings menu or editor with auto completion and tooltips. Kinda like how VSCode handles settings, where you can use the GUI or a context-aware text editor.

Starting your own instance doesn’t solve the problem of big communities being reliant on the one specific instance they are hosted on to not go down or rogue.

I imagine it like friend requests between communities: x@instance.a, all-about-x@instance.b and x-is-great@instance.c could send each other friend requests and merge into one federated meta-community about x. Then if one instance goes down the other two are still there to keep the meta-community alive, and if one goes rogue the others can just unfriend and keep going without it.

The nice thing about manual federation is that the communities don’t have to have exactly the same name, and the mods can keep malicious or troll communities out. And ofc you could still have client-side control if you want to, e.g. add or remove a community just for you locally, or create your own local meta-community.

The database, storage and network are usually the bottlenecks in these kinds of websites, not the programming language. It might add a few ms of latency, but the big lags come from congestion or bad db queries.

Fedora as well, with drivers from RPM Fusion.

I’ve been using Nvidia+Wayland+Gnome with two different monitors for a while now, and never had any problems with this setup. The X11 setup before that had some issues years ago, but worked fine for the last few years before switching to Wayland.

I also connect different external monitors to my Intel-based laptop fairly often, and it works 99.9% of the time.

Multi-monitor is really just plug and play nowadays.

There’s UnifiedPush to let you choose a push provider, including hosting your own.

Most point and click adventures take about 6-10 hours in my experience. My favorites are the Monkey Island and Deponia games.

What comment?

I’ve literally never seen anyone say this except FediPacters as a strawman.

I’ve seen that quite a few times already, mostly in the form of “it’s stupid to preemptively defederate, we can always defederate later”.

If you decide to go down the Synology route, make sure it supports docker. Their cheaper models don’t support it, and it’s the gateway to self-hosting all the services that are not available directly from the package manager.

Not really. Most centralized services are accessible via multiple domains, e.g. for different countries. This would just disable one of them, but users could still use another to log into their accounts. For the Fediverse it “disables” an entire instance, cuts it off from federation and locks out users.

Lets not put a positive spin on a situation that exposes a weakness of the current system. The federation protocol needs to be able to handle these things gracefully, like propagating domain changes and migrating accounts between instances!

A domain takedown was never able to shut a server down, not even with centralized servers. Most big services are accessible via multiple domains of different countries, and this would just disable one of them. But for the Fediverse that means that they also “disabled” an entire instance with all its users.

This actually shows us that relying on domains can be a problem for the Fediverse! Imo we need to upgrade the federation protocol to be able to handle these things, like propagating a domain change or migrating accounts to other instances.

Just leaving this here: Aurora Store

Your right to choose is the same as everybody else’s right to choose. You can decide to post something, and others can decide they don’t want to see it. Decentralized just means there is no one entity to make those decisions for you.

I don’t think it will ever be too late to change things. Look at their current design direction: They changed a system of profession specific boons into a somewhat homogenized alac+quickness system over the course of 1-2 years. They could do something similar again if it doesn’t work out the way they want.

But one other thing came to my mind. I think perma boons you have to spec into might fulfill the offensive support fantasy better than a time-limited boon. With perma boons you associate the boon with your party or the boon provider specifically, while a temporary boon feels more like a property/mechanic of the enounter you’re fighting. With perma boons you have to stay close to your group for example, while a temporary boon would only requires you to stack on boon application, like many other boss mechanics. Maybe that’s just me, but being the boon guy sounds more fun than being the one to press a certain button at some point, provided boon support gameplay is fun as well of course.

Alac and Quickness are not an easy design problem to solve imo. If they aren’t powerful enough then nobody will use them, but if they are then people will want to stack boon supports until they get 100% uptime.

The only other options I see are having them only be worth it during certain phases in the fight, having a forced downtime like BL in WoW, or having the boon supports do virtually no damage so stacking them isn’t worth it. The first makes fights harder to design as every encounter would need a burst phase, and the third is probably not fun to play, so I think WoW’s BL design is the best solution. It also allows you to decide when you want the buff, so it adds a tactical element as well.