IIRC they also had the first native (100% Java) JDBC driver, so you could run from any platform and without weird JNI locking issues when using threads.

I really prefer the 2D pixel graphics of the original Civ. But the middle game can be a slog due to micromanagement, e.g. loading units onto boats. I would love to see a few tweaks, fixing bugs like disappearing units, and a stronger AI that doesn't have to cheat :)

I had one of those 133 MHz 486 chips, think it was AMD. Nice DOS gaming machine.

That's hilarious. I've been following Mario since his work on libGDX and RoboVM.

His blog post on pi is here: https://mariozechner.at/posts/2025-11-30-pi-coding-agent/

You can see some of these objects at Musée des Arts et Métiers: https://www.arts-et-metiers.net/musee/les-objets-inconfortab...

It's not the wrong design; RISC-V is designed around extensions, and they left room in the instruction encoding for them. They don't have a 800-lb gorilla like Intel shoving the ISA down customers' throats (Canonical is the closet thing) so there is some debate on which combination of extensions are needed for desktop apps.

FWIW I wrote this article a while back all about RISC-V extensions and how they work at a low level: https://research.redhat.com/blog/article/risc-v-extensions-w... page 22 in this PDF: https://research.redhat.com/wp-content/uploads/2023/12/RHRQ_...

> They don't have a 800-lb gorilla like Intel shoving the ISA down customers' throats

Nobody really forces you to use x64 if you don't like it, just as nobody forced you to use Itanium — which Intel famously failed to "shove down the customers' throats" btw.

From the docs, I couldn't tell if it had disassembled very much of the EXE. Looks like it extracted most of the assets, the presence of open-source modding tools for this game in training data likely helped a bit.

Realize, though, that just grabbing a frame buffer is not a thing anymore. To render graphics you need GLES support through something like ANGLE, vectors and fonts via Skia, Unicode, etc. A web browser has those things. Any static binary bundling those things is also gonna be pretty large.

And JavaScript is very good at backwards compatibility when you remove the churn of frameworks (unfortunately Electron doesn't guarantee compatibility quite as far back)

And CPUs are only sand powered by electricity.

I do realise the need for abstractions and they do exist, provided there is actually the interest to learn them.

That policy doesn't explicitly disallow writers from using LLMs as part of their process, nor does it mention reviewing submissions for content that could be LLM-generated.

I like some of the ideas in the article but there are some very "it wasn't just A, it was B" sentences in there. IEEE has a higher standard.

I note that Clarion is still being developed, version 12 was released last year. I remember fondly using its screen designer to create drop-shadowed dialogs.