Interesting, that’s definitely not what I’m seeing from regular use. Are you running any added applications? LDAP? SSO? External mounts?

Are you looking at data rates or IO operations? Because this is almost exclusively stat queries, i.e. inode queries.

Oh yeah, CPU usage is basically zero, and memory usage of the PHP code itself is also basically nil compared to other software I run. It’s just the sudden storms of IO requests that causes issues, and since those come over a network pipe it causes issues for other pieces of software as well.

Again, it works until it requires reloading, i.e. the next update of any component or the next restart of the server.

I’m also running an inode cache on the client side, on top of the persistent opcache, but due to the sheer number of files that Nextcloud consists of it still generates a frankly ridiculous amount of calls when it needs to invalidate the cache. If you’re running on local drives then that’s likely much less of an issue, regardless of what kind of drive it is, but this is hosted on machines that do not have any local storage.

Yep, those values are actually somewhat tame compared to my own cache tuning, the issue remains that the code requires reloading PHP files from disk during runtime in order to support applications and updates, which - even if it doesn’t happen often - causes IO storms that temporarily break both Nextcloud as well as other software.

Currently working to move away from Nextcloud myself, it’s PHP nature causes IO storms when it tries to check if it needs to reload any code for incoming requests.

All OpenWRT-based routers have the option of built-in DNS-based adblock, can thoroughly recommend the Turris routers for such things.

It’s worth noting that the ESS suite Chart is absolutely not built to be community-viable, it’s built for the kind of single-purpose deployments that Element offer hosting for, and it also breaks almost all Kubernetes best practices. Which is actually not wrong per-se. Element need to be able to maintain it after all, and since they don’t have the Kubernetes know-how to build generic components, it makes sense to instead bundle a fully integrated solution which they are comfortable with developing and debugging.

They’re definitely slowly but steadily rewriting Synapse in Rust as well, that’s been an open and ongoing project for a while now. You can see that just by looking in the Rust folder in the Synapse sources.
I strongly doubt that they have the “rest” of the application rewritten internally and keeping it hostage for paid hosting though, it’d cost them too much to keep separate codebases for such a thing.

The “Synapse Pro” offering is most likely just the regular Python+Rust Synapse, but with a few additional HA components and some workers written in Rust for efficiency, just like how there’s community workers written in both C# and Go for performance reasons.

If you don’t have a hard requirement for the Helm Chart to be written by Element themselves, I’ve been maintaining some Charts for Matrix components for almost six years - which have also ended up being used as the base for the German BundesMessenger project. Unfortunately free time hasn’t allowed me to do nearly as much as I want with it, especially since it continues to work for the use-cases for my job.

We do have a room on Matrix for dealing with Kubernetes setups though.

I also ended up chatting with one of the core devs of Synapse about ways to improve regular Python Synapse for use with Kubernetes back in the ending of January, so hopefully it’ll improve in that direction when time allows. They have the exact same problems with providing hosted setups after all, so they too want to make the open-source version easier to run.

Default block for incoming traffic is always a good starting point.
I’m personally using crowdsec to good results, but still need to add some more to it as I keep seeing failed attacks that should be blocked much quicker.

Honestly, the two reasons I’ve been sticking with Plex is the federated/shared libraries and watch together.

If they’re starting to axe those then I see no reason to continue using it.

Well, there’s the ALFIS project

Remember to join the !advent_of_code@programming.dev community while you’re at it

GitLab has been working on support for ActivityPub/ForgeFed federation as well, currently only implemented for releases though.

Mercurial does have a few things going for it, though for most use-cases it’s behind Git in almost all metrics.

I really do like the fact that it keeps a commit number counter, it’s a lot easier to know if “commit 405572” is newer than “commit 405488” after all, instead of Git’s “commit ea43f56” vs “commit ab446f1”. (Though Git does have the describe format, which helps somewhat in this regard. E.g. “0.95b-4204-g1e97859fb” being the 4204th commit after tag 0.95b)

Well, one available case you can look at is Uru: Live / Myst Online, currently running under the name Myst Online: Uru Live: Again.

They open-sourced their Dirt/Headspin/Plasma engine, which required stripping out - among other things - the PhysX code from it.

Seems to work with my personal setup at least, with two libraries - the default on ~/.local/share/steam, and one on /mnt/storage/steam - and Stardew Valley installed in the secondary storage library

Factorio is great, I’m also a fan of X4.

It’s somewhat amusing how Itanium managed to completely miss the mark, and just how short its heyday was.

It’s also somewhat amusing that I’m still today helping host a pair of HPE Itanium blades - and two two-node DEC Alpha servers - for OpenVMS development.

Both the rendezvous/mailbox and transport servers are available under an MIT license, though not every client makes it easy to use your own rendezvous.

I personally use the rymdport GUI client and the rust CLI.