Storage space is one issue. Bandwidth (how many TB/mo goes out the server) is another. And for any "serious" use case transcoding would also be important (so you can keep the other two down for everyone except Apple users who are stubborn to adopt VP9/AV1, and to provide multiple quality options), which unlike the other two requires powerful hardware most instances do not have.
eh
It uses WebTorrent for distribution between viewers watching at the same time which can temporarily help with the load on popular videos, but there still needs to be at least one source instance that's sharing the video "regularly" (for unpopular or old stuff), which ends up having the same bandwidth issues you'd get with any other video platform.
You have to actually toggle to see it but IMO it massively improves how scrolling feels.
There are a few more scrolling-related options out there on the net if there's a particular "feel" you want to go for. https://github.com/yokoffing/Betterfox/blob/main/Smoothfox.js provides a couple you can try out, and most of these custom scrolling options use msdPhysics as a baseline.
Not obscure but general.smoothScroll.msdPhysics.enabled
=true is a must have IMO.
Again - I have no idea how well it's hardware support is. I assume 3d accel and whatnot would be fine because it's widely used, but dunno if anyone tried running ROCm on it.
Just let some bees loose on your system for a while and they'll sort that out.
Also depending on how good your CPU is btrfs compression would also save a fair bit. AFAIK shared libraries are pretty well compressible.
I wonder how well it integrates with hardware. Arch with the pacman packages has been the only distro where I could get ROCm working reliably. I'd love to make a "ROCm container" and dump all that mess into it's own sandbox.
In fact, the thing I really want is more of a "Qubes but not for security tryhards" (aka I can actually use Wayland AND game on it) where everything gets it's own container mainly for organizational purposes, but something like this sounds like a fair compromise.
There are signing keys involved, so if someone puts up a new server but uses different keys then all sorts of federation trouble will await them.
That said it shouldn't affect the general network, just that individual server (both the communities and the users of it)
Edit: As for switching domains on an existing server, that would be equally troublesome as ActivityPub kinda relies on domains for all sorts of IDs.
It's possible by having the webfinger endpoints at the "root" while keeping the rest of Lemmy on a subdomain. The main thing that determines the domain in your username is webfinger.
No clue if Lemmy or kbin support this config though, but quite a bit of the microblog-only parts of fedi do, and it's a widely used thing.
jsyk, with how ActivityPub works changing the software that's running from under it will break federation with you in all sorts of subtle ways. When you pick a thing to run under a domain you're effectively locked into running that software under that domain. And of course there is some cryptographic verification as well so you change the keys (or you wipe or forget to back up the database) you may as well burn that domain from federating ever again.
All of these are "root" mounts. I don't explicitly mount any subvolumes (they get "implicitly" mounted as folders though)