Remember though that butter is only 80% fat. Especially relevant for baking recipes where you have a ton of butter and if you replace that can make it denser and greasier. E.g. 200g butter you should replace with ~160g oil and 40ml water.
I can understand not having the energy to care about long messages from companies enough to notice stuff like this. Everyone is forced to look at tons of text / media from companies every day demanding your attention, "news" about stuff to get you to spend more time with company products, mixed in with ads, fake "updates" just for you personally to trigger reactions in your brain that make you feel like something social is happening. So many buttons you get shown about agreeing to something or acknowledging something or some terms you've never read having changed vaguely with "we care about you", intentionally obfuscating which ones you're legally allowed to deny and which ones are going to be forced down your throat in any case.
They added this feature as an opt-out in order to capitalize on your existing relationship with your friends to redirect that social attention to their corporate interests. I'm happy there's backlash, regardless of whether a user could have theoretically stopped it.
That is exactly what's happening :) better quantization matrix results in 25% smaller files with the same perception-based q which makes webp kinda useless often https://siipo.la/blog/is-webp-really-better-than-jpeg
Try jpeg-xl though. it's amazing.
Hab ich gerade gemerged, wird sich in der nächsten Version ändern :)
If that's what this video is about then it's a lie (I'm not going to watch that bait). Svelte did not move away from Typescript. Svelte just moved from TSs custom syntax to TS-in-JSDoc. They are still using the same types and TS compiler to fully enforce type checking their code.
Their reason isn't that TS is bad, just that the IDE experience is bad redirecting you to .d.ts instead of source files for libraries.
I want to clarify that most/ a lot of the DB work of this release actually came from others e.g. nutomic, RocketDerp, Sh4d, sunarus ;)
it's not really officially supported, but both lemmy.world and lemm.ee are running with this configuration (multiple lemmy-ui and lemmy_server instances, one pg database).
a large part of the queue going unbounded is due to the retry queue and missing checks if the receiving servers are actually available. quick fix is disabling the retry queue which is currently making it not go unbounded on lemmy.world
storing the queue persistently is somewhat of a separate issue since that doesn't much affect whether or not it can be processed in time.
also a ton of the memory use was (and is) due to inefficient sql queries.
server load is too low, everyone upvote more stuff so i can optimize more
edit: guess there is some more work to be done 😁
I want to say that with 0.18 the definition of federation_workers has changed massively due to the improved queue. As in, whatever is good in 0.17 is not necessarily good for 0.18.
On 0.18, it probably makes sense to have it around 100 to 10'000. Setting it to 0 is also be an option (unlimited, that's the default). Anything much higher is probably a bad idea.
On 0.18, retry tasks are also split into a separate queue which should improve things in general.
0 might have perf issues since every federation task is one task with the same scheduling priority as any other async task (like ui / user api requests). So if 10k federation tasks are running and 100 api requests are running then tokio will schedule the api requests with probability 100 / (10k+100) (if everything is cpu-limited). (I think, not 100% sure how tokio scheduling works)
my reddit import code is here for the time being: https://github.com/phiresky/lemmy/tree/reddit-importer
it works but is undocumented
I don't think we found any specific groups of people attacking Lemmy. I personally just saw one or two what looked like individuals trying (and succeeding) to take Lemmy down with a few very simple requests that forced Lemmy to do lots of compute (something like fetching the next million posts from page 10000). The fixes for those were simple because it was just missing limits checking.
I'm not sure if there actually was a larger organized attack. Lots of performance issues in Lemmy simply appeared simultaneously and compunded each other with a rapidly growing number of active users and posts.