• 3 Posts
  • 16 Comments
Joined 1 year ago
cake
Cake day: July 26th, 2023

help-circle





  • Why should we join?

    If you want to join a small instance hosted in Germany, that’s fast, reliable and run by an experienced system administrator. Or maybe you just like the domain name or something. The great part about federation is that it doesn’t really matter what server you use, join if you want.

    What’s the purpose of this instance?

    It’s a general-purpose instance, there’s no specific topic and can be used for whatever you want, as long as you follow rules.

    What themes will your instance house?

    Default themes. I don’t have any plans to add custom themes.










  • Not really, you should assume anything you post will be public and can’t be deleted. When you delete a post or comment, your server will ask others it’s federating with to also delete it, most of the time they will respect that. However, a server could just ignore the request and keep it anyway, there really isn’t anything that can be done about this unfortunately.

    Edit: Using another image host like imgur could give you more control to delete your images. However, it’s still fairly trivial for a server to just download the image while it’s up and store it locally.



  • Are concurrent migrations actually a problem?

    That might be the case, I wouldn’t be confident reviewing it myself though since I don’t know Rust that well and haven’t used diesel before but I could ask the developers about it.

    A mode in Lemmy to do nothing other than run migrations and exit.

    I don’t think there’s a way to just run migrations like this.

    Create my own DB migration script based on the Lemmy schema diffs from release tag to release tag.

    Yeah maybe this could work?

    Is there a config-flag on Lemmy to enable/disable db migrations?

    There’s a flag to disable scheduled jobs like you described but not for database migrations. I use that flag on all my Lemmy containers that serve requests, I have a separate container to handle the scheduled jobs and since it’s just normal instance of Lemmy it runs database migrations on startup, so maybe one option would be to upgrade the jobs container first, wait for it to finish the migrations and then upgrade the rest. Obviously to do that with no issues or downtime the migration would need to be backwards compatible. The docs seem to indicate that this is possible.

    As you note, run just one Lemmy container for “a while” when upgrading.

    Yeah I feel like it would be a bit cumbersome and it would be nice to be able to do a rolling update with no downtime.