This is sso support as the client. So you could use any backend that supports the oauth backend (I assume, didn’t look at it yet).

So you could use a forgejo instance, immediately making your git hosting instance a social platform, if you wanted.
Or use something as self hostable like hydra.

Or you can use the social platforms that already exist such as Google or Microsoft. Allowing faster onboarding to joining the fediverse. While allowing the issues that come with user creation to be passed onto a bigger player who already does verification. All of these features are up for your instance to decide on.
The best part, if you don’t agree with what your instance decides on, you can migrate to one that has a policy that coincides with your values.

Hope that gives you an idea behind why this feature is warranted.

Yeah that’s why I included the other “main posts”… Their technical details really didn’t say anything technical

Ah. I see you too enjoy the debian approach

Oh I was wrong, after further reading this looks to be a lot better than what I was thinking.

I must have been thinking about another methodology of attempted privacy over a dataset.

Before I start reading, if this has anything to do with differential privacy, I’m going to be disappointed.

https://reddthat.com/signup

2nd best reporting in.

A faster db. Just the regular performance benefits, https://www.postgresql.org/about/news/postgresql-16-released-2715/

Also, Lemmy is built against v16 (now) so at some point it will eventually no longer JustWork

The script will be useless to you, besides for referencing what to do.

Export, remove pg15, install pg16, import. I think you can streamline with both installed at once as they correctly version. You could also use the in place upgrade. Aptly named: pg_upgradeclusters

But updating to 0.19.4, you do not need to go to pg16… but… you should, because of the benefits!

The downvotes you can see (on this post) are from accounts on your instance then. As this post is semi inflammatory it is highly likely to have garnered some downvotes.

Edit: I guess I was wrong regarding the logic of how downvotes work when we block them. As the http request (used too?) return an error when responding to a downvote. I’ll have to look at it again. As the only way it was/is 15, is if:

• we kept track of downvotes and sent out the activities notification
• your instance got the notifications from other instances about our post, (which is not how Lemmy works unless I’m seriously misunderstanding it.)

That awkward moment when you are the person they are talking about when running beta in production!

Right? Such a good vibe.

Since the 11th @ 9am UTC, LW has seen a 2 fold increase of activities. If my insider knowledge is right (and math) it’s 7req/s average up from 3req/s.

Lucky for both of us we are not subbed to every community on LW but I think we are subbed just enough to be affected.

Relevant: https://reddthat.com/comment/8316861 tl;dr. The current centralisation results in a lemmy-verse theoretical maximum for of 1 activity per 0.3 seconds, or 200 activities per minute. As total transfer of packets is just under 0.3 seconds between EU -> AU and back.

Edit: can’t math when sleepy

Should be already fixed. I’ve logged out and in on Jerboa.

We rebuilt the Lemmy container with an extra logging patch. Seems build docs need some work? as that’s the only difference in the past 1-2 days, except for moving to postgres 16…

Thanks for the ping.

I’ve gone back to mainline Lemmy. @Morpheus@lemmy.today check now please

Bah! I totally forgot that they have the new “efficiency” cores…

Performance Cores: 6 Cores, 12 Threads, 2.5 GHz Base, 4.8 GHz Turbo
Efficient Cores: 8 Cores, 8 Threads, 1.8 GHz Base, 3.5 GHz Turbo

Hmmm, I’d still say its totally worth it because the 12500 only has 6 core (12 threads) total. You are getting 8 extra core/threads.

Linux/docker/anyOS will make use of 8 extra cores regardless of the workload. Sure they might not be as performent on the lower end but a process running 12 threads vs a process running 20 threads will always be more performant.

I’m always look at ongoing costs rather than upfront and mostly thats the TDP, which is exactly the same. So I would agree with your sentiment. The major cost is performing it.

Single thread has a small increase 5% or so, but you have double the amount of threads. So your two dozen (24) docker containers could have a thread per container! Thid could benefit you a lot if you were running anywhere near 100% or have long running multithread jobs.

If I had the disposable money and I thought I could sell the 12th gen CPU then maybe. But i’m still rocking some old E3-12xx v3 Xeons which probably costs me more per year than what you will pay to upgrade!

Make sure to read the side bar. Support questions go to !askandroid@lemdro.id

Pity those that lost their money will probably not get it returned. What really happens with the 200M worth of liquid funds?