So the user actually found a memory leak in #curl (using a fuzzer) and reported it correctly. All good.
Then, in a follow up comment the user makes the ugly choice of trying to "help" us with this bug by asking an AI for help and proposing that as a solution.
And again it broke horribly and the AI made up a broken patch that did not even fix the problem.
Now that reporter is banned.
Here's a silly-looking – but not frivolous – program I wrote yesterday. (I tooted about it deep in a thread yesterday, but I think it deserves sharing more widely.)
It runs a subprocess (by default a shell) inside a pty, similarly to 'script' or 'ttyrec' or 'luit' or other wrapper programs. In the output stream, it intercepts terminal control sequences that set the foreground and background colour, and rewrites them to select different colours.
So you get to remap your colours however you like without having to hack on your actual terminal program – the colour rewriter is a separate tool sitting in between your shell and the terminal.
In the screenshot, the demo application for this technology is a silly one: it just permutes the R,G,B channels of all the colours, to prove it's doing _something_.
But the purpose isn't frivolous at all. It's intended as a test bed for experimenting with colour remapping rules that improve readability: you can rewrite fg and bg colours as a pair, with awareness of each other, so you can improve contrast in whatever way your particular colour vision finds useful. All you have to do is decide what remapping you want to do.
This is an experimental test bed, so for the moment, you have to implement a rewriting rule by editing a function inside the C program and recompiling. An obvious extension would be to make that easier, via a plugin system or an embedded DSL or something, but I threw this together in a couple of hours yesterday evening, and haven't done anything that complicated. (Yet.)

Relief printing using Lego. This is lots of fun. Designs are pretty quick and easy to try out.
#Lego #printmaking

Re this from @rotnroll666, Java is a great example of what I’m talking about upthread:
https://mastodon.social/@rotnroll666/114374427369696039
I was writing Java as early as 1997 and as recently as 2024. Observations:
(1) Modern Java can feel •very• different from the language of 1997, or even 2010. You can do really nice work with the language.
(2) The language is still weighed down by some essential design decisions that would be •very• hard to unroll at this point. It’s also weighed down somewhat by culture. (Ask me about either if you care.)
(3) Its long-term stability is unparalleled. Code that takes longer to write but still runs without modification 20 years later? That’s a •fantastic• tradeoff for a lot of projects out there!
Achieving (1) while navigating the constraints of (2) and holding on to (3)? That’s a real achievement — and the kind of work that just chokes up and dies in the sea of information pollution of a “vibe-coded” future.