Just another Swedish programming sysadmin person.
Coffee is always the answer.

And beware my spaghet.

  • 8 Posts
  • 46 Comments
Joined 3 years ago
cake
Cake day: June 11th, 2023

help-circle
  • Been using Yggdrasil for quite a while at this point, both for encrypted service communication and also as unbreakable VPN links to various places where I don’t want to have to mess about with NAT traversal.

    It’s been nice to be able to just drop it onto my router, add an ALFIS DNS entry, and have all my devices just work with Yggdrasil with no additional configuration.


  • I’m holding off on Fluxer until they decide how they’re going to implement federation, since the designs they’ve communicated publicly so far have all seemed like they prioritize siloing and putting excessive load on self-hosted nodes.
    Their first proposed solution would’ve required each self-hosted server to be able to handle every user on every other server in the network - a proposal which they’ve since scrubbed from their page.
    The latest proposal I can find at least speaks about aggregating connections through the users server, so it’s not as insane (Only requiring each self-hosted server to be able to handle requests from every other server on the network). But it still forbids intelligent caching, and instead seems to consider recommending the use of cloudflare to reduce the load from their design to be a good solution.
















  • 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.





  • 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.