Personally I think child processes are the right approach for this. Launch a new process* for each query and it can (if you choose to go that route) dynamically load in compiled code. Exit when you’re done, and the dynamically loaded code is gone. A side benefit of that is memory leaks are contained, since all memory you allocate is about to be removed anyway.

I’d probably be fine with hundreds or thousands of these hanging in memory. I suspect the generated code for a single query would be in hundreds of kilobytes, maybe a megabyte. But yeah, this is one of those technical details I’d worry about.

Honestly, I wonder if you could just use an actual HTTP server for this? They can handle hundreds or even thousands of simultaneous requests. They can handle requests that complete in a fraction of a millisecond or ones that run for several hours. And they have good tools to catch/deal with code that segfaults, hits an endless loop, attempts to allocate terabytes of swap, etc. HTTP also has wonderful tools to load balance across multiple servers if you do need to scale to massive numbers of requests.

Not sure how a HTTP server would solve the CPU bottleneck of scanning terabytes of data per query?

I somehow didn’t think a regular JIT solution might be applicable here, but it is. Thank you! There seems to be a number of projects doing JIT for C++, will look at them.

So far I’ve been following recommendations from this person: https://old.reddit.com/r/NewMaxx/comments/16xhbi5/ssd_guides_resources_ssd_help_post_your_questions/

Try dmraid, it’s been designed to take over various formats of hardware RAID cards.

This plea for help is specifically for non-coding, but still deeply technical work.

As of May 2023, 65% of the Ukrainian refugees that left Ukraine starting February 2022 and decided to stay in Poland found a job—so, within around a year, as opposed to 5-6 years as in the article. Cultural similarity here is likely making it much, much simpler. For those who want to read more about the situation of Ukrainian refugees in Poland, this report by Polish National Bank (Narodowy Bank Polski, NBP) might be useful: https://nbp.pl/wp-content/uploads/2023/05/Raport_Imigranci_EN.pdf (in English!), there is a lot of interesting details.

lemmy.ml is hosted in EU, and lemmynsfw.com uses CloudFlare, which operates in EU. Worst case, issue a GDPR request to both.

I do not have notes from that time anymore, sorry. I do recall though that after following a chain of citations I ended up at the paper in the center of this controversy. Nobody sane would cite in now except to point out its flaws, but if there’s a modern paper that cites a 10 year old paper that cites a 30 year old paper that cites it—people usually won’t notice.

From my experience, despite all the citogenesis described in other comments here, Wikipedia citations are still better vetted than in many, many scientific papers, let alone regular journalism :/ I recall spending days following citation links in already well-cited papers to basically debunk basic statements in the field.

I’m surprised federation isn’t based on asymmetric cryptography. Let the public/private keys identify instances, as opposed to domains that risk being blocked by governments or bought by malicious third parties if the instance owner forgets to prolong it.

With that, implementing a change in domain names would be simple.

Last job, we started writing mixing bits of Kotlin in an otherwise mostly-Java in a monolithic Spring-based service. Good experience.

Indeed. Most of the web is broken under GDPR’s privacy requirements.

GDPR believes an IP address is a private information. This can be used to mount a legal attack on EU-hosted lemmy instances.

I’m not a person who’d be loyal to a brand. Yet Motorola consistently produces devices that turn out to be the best trade-offs (price to functionality) for me. And, so far, all these devices were pretty durable as well, though it’s not that I really put smartphones into lots of use. That’s all I can say.