https://jasone.github.io/2025/06/12/jemalloc-postmortem/
As far as I am concerned, “upstream” jemalloc development has concluded.
https://jasone.github.io/2025/06/12/jemalloc-postmortem/
As far as I am concerned, “upstream” jemalloc development has concluded.
TBH, I thought I’d see the opposite. Good design for war games require access to secret documents, while events in the public space get documents leaked and published all the time, or even documentaries being released. For example, I would expect events like the 2008 market crash or Brexit to have enough content for a simple board game at this point. I mean, I’m not expecting Campaign For North Africa level of details ;-)
I agree development time is necessary though.
TBH, I see events in the public space get documents leaked and published all the time, or even documentaries being released. I would expect events like the 2008 market crash or Brexit to have enough content for a simple board game at this point. I mean, I’m not expecting Campaign For North Africa level of details ;-)
I agree development time is necessary though.
It is cumbersome to discover all these places on lemmy :/ Honestly, by the list of communities my instance shows, this one looks the most active. Thank you!
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/
Plenty of them on various sites, like this one I found yesterday.
Try dmraid, it's been designed to take over various formats of hardware RAID cards.
Kernel is not a monolithic application, and you cannot develop it like one. There are tons of actors: independent developers, small support companies (like Collabora), corporations, all with different priorities. There is a large number of independent forks (e.g. for obscure devices), that will never be merged, but need to merge e.g. security patches from the mainline. A single project management tool won't do, not your typical business grade tracking&reporting tool.
CI is already there. Not a central one—again, distributed across different organizations. Different organizations have different needs for CI, e.g. supporting weird architectures that they need to develop against.
There is a reason Torvalds created git—existing tools just wouldn't work. There might be a place for a similar revolution regarding a bugtracker…
This plea for help is specifically for non-coding, but still deeply technical work.