I think the benefit of knowing the names publicly might be the public's ability to then no longer elect these people, which cuts off the foreign interference at the root, as far as can be done within the country. It might also act as a deterrent for future MPs knowing their names could be released if they too partake in this behavior. It would accomplish stamping out the problem and publicly shaming these people for the rest of their careers.

Not saying it's realistically feasible or prudent overall to actually release them though.

Can confirm, I'm living there right now. People here tend to take proper personal responsibility for their own garbage and mess.

The good thing about getting one from the start is that you can set it up to your liking from the get-go and won't have to do it later. You'll also get used to using it daily and see how managing two devices works for you.

I know it's been around for a long time, but I just heard about Real Debrid. My current setup is Wasabi + Rclone + Jellyfin, plus all the *arr services. What's the benefit of Real Debrid over this setup, aside from cached torrents?

I use Clipious, an Android client for Invidious, on my phone. I selfhost my own Indivious instance so this is perfect in that my phone never connects to YouTube directly, and I can save all my subscriptions in one place without a YouTube account.

On my Android TV I use Smart Tube Next. If I really need to cast, I also have YouTube ReVanced on my phone for just that, but I barely use it.

As soon as Clipious gets a proper Android TV interface, I'll be set, as both devices can just connect to Invidious and let it do all the work.

Installed Sync as soon as I could, but went back to Jerboa for now due to lack of a one-time purchase option. Not a fan of subscriptions, I need less of those in my life.

I guess they don't really know what they're doing and are learning how load balancing works on the fly, and thinking that'll result in HA without side-effects without further work.

EDIT: Don't really get why this was downvoted. With the proper technical knowledge it's clear to anybody that two instances with different JWT secrets behind a load balancer is going to cause this very issue. So the fact that they set it up that way means they have a knowledge gap ("they don't really know what they're doing"). At the very least they should enable sticky sessions on the load balancer if they insist on going this route, which would mitigate the issue (but depending on client-side configuration would not necessarily prevent it completely).

Don't take this as an insult towards the admins of the instance, I'm just pointing out there's a lack of knowledge, and some trial-and-error going on.

The Linux distro concept is a great analogy.

There's nothing stopping instance owners from incorporating their own security measures into their infrastructure as they see fit, such as a reverse proxy with a modern web application firewall, solutions such as Cloudflare and the free captcha capabilities they offer, or a combination of those and/or various other protective measures. If you're hosting your own Lemmy instance and exposing it to the public, and you don't understand what would be involved in the above examples or have no idea where to start, then you probably shouldn't be hosting a public Lemmy instance in the first place.

It's generally not a good idea to rely primarily on security to be baked into application code and call it a day. I'm not up to date on this news and all of the nuances yet, I'll look into it after I've posted this, but what I said above holds true regardless.

The responsibility of security of any publicly hosted web application or service rests squarely on the owner of the instance. It's up to you to secure your infrastructure, and there are very good and accepted best practice ways of doing that outside of application code. Something like losing baked in captcha in a web application should come as no big deal to those who have the appropriate level of knowledge to responsibly host their instance.

From what this seems to be about, it seems like a non-issue, unless you're someone who is relying on baked in security to cover for your lack of expertise in properly securing your instance and mitigating exploitation by bots yourself.

I'm not trying to demean anyone or sound holier than thou, but honestly, please don't rely on the devs for all of your security needs. There are ways to keep your instance secure that doesn't require their involvement, and that are best practice anyways. Please seek to educate yourself if this applies to you, and shore up the security of your own instances by way of the surrounding infrastructure.

Containers really shine in the selfhosting world in modern times. Complete userspace isolation, basically no worries about dependencies or conflicts since it's all internally shipped and pre-configured, easy port mapping, immutable "system" files and volume mounting for persistent data... And much more. If built properly, container images solve almost all problems you're grappling with.

I can't imagine ever building another application myself without containerization ever again. I can't remember the last time I installed any kind of server-side software directly on a host without containerization, with the exception of packages required by the host that are unavoidable to support containers or to increase security posture.

I'm my (admittedly strong) opinion, it's absolute madness, and dare I say, reckless and incomprehensible, why anybody would ever create a brand new product that doesn't ship via container images in this day and age, if you have the required knowledge to make it happen, or the capacity to get up to speed to learn how to make it happen (properly and following best practices of course) in time to meet a deadline.

I'm sure some would disagree or have special use-cases they could cite where containers wouldn't be a good fit for a product or solution, but I'm pretty confident that those would be really niche cases that would apply to barely anyone.

There's a lot of things that factor into the answer, but I think overall it's gonna be pretty random. Some instances are on domains without "Lemmy" in the name, some don't include "Lemmy" in the site name configuration, and in the case of some like my own instance, I set the X-Robots-Tag response header such that search engines that properly honor the header won't crawl or index content on my instance. I've actually taken things a step further with mine and put all public paths except for the API endpoints behind authentication (so that Lemmy clients and federation still work with it), so you can't browse my instance content without going through a proper client for extra privacy. But that goes off-topic.

Reddit was centralized so could be optimized for SEO. Lemmy instances are individually run with different configuration at the infrastructure level and the application configuration level, which if most people leave things fairly vanilla, should result in pretty good discovery of Lemmy content across most of these kinds of instances, but I would think most people technical enough to host their own instances would have deviated from defaults and (hopefully) implemented some hardening, which would likely mess with SEO.

So yeah, expect it to be pretty random, but not necessarily unworkable.

A spike in subscribers for a period doesn't necessarily mean they're making more money than before, even if the number of new signups offsets the cancellations.

I used to pay for the Premium plan, sharing with my parents, but downgraded to the Basic plan. My parents ended up getting their own Basic plan. So a single account essentially split into two, but the sum of both payments is now less than what it used to be for the single account. So Netflix gained an extra subscriber, but is now making less money from that pool of users.

It's totally possible that some number of these new signups consist of people who did the same thing.

Basically, seeing a spike in new signups isn't itself a measure of success. What matters is how much money they're bringing in monthly going forward compared to previously.