Long time Ars reader, looking forward to your article (and have a few DOS games to reverse in mind already)!

Is this with a Ghidra MCP or some other technique? And why two models - did you try using Qwen3.6-35B-A3B for everything? (Or 27B or a bigger model since you have the RAM for it)

I haven't paired it with Ghidra MCP; because the games are relatively tiny (I'm starting with one of my personal favorites, Karl Buiter's Sentinel Worlds I: Future Magic, which is like <700KB all in), I made a first baseline pass with Fable a couple of days ago while it was still working and it created a bunch of tiny python tools with Capstone. Qwen picked those right up and has had equal success with them. I might try adding Ghidra into the mix, but it seems overkill at the moment.

I went with a pair of models primarily just to see if I could make it work. It's been fine, but I'm going to rip out the smaller coder model today and try it with just the bigger thinking Qwen model wearing both planner & coder hats in the same loop, just with only the bigger model running.

I'm learning a lot, and primarily what I'm learning is that I'm not a developer and this stuff gets real complex real fast, especially in chasing down all the details needed to make sure I'm taking advantage of the spark hardware!

I'm running Qwen3.6-35B-A3B on a very ordinary desktop PC (32GB DDR5, 8GB Radeon 6600XT) and getting a useful 15-20 tok/sec out of it. The MoE architecture and auto offloading from system to VRAM is just fantastic. Unsloth Q4_K_XL.

The Qwen3.6-27B is unbearably slow as it doesn't fit in VRAM, though, i think the MoE is very easy to run.

It is also extremely nice that you can just `apt install llama.cpp libggml0-backend-vulkan` now too.

I wonder what parent poster means with „useful” and what he actually tried? Feels like he was just comparing some benchmarks.

Yesterday I downloaded Gemma4-26B with Ollama on quite rusty desktop with 1070 8gb and 32gb of ram and Core i5-9400.

I drop photo of my water meter and tell it to read the value and serial number. It was far from instant but it was also easily under 3 minutes and result was correct.

Earlier like in February I was trying the same photo with Gemma3 on the same hardware and results were bad.

I used to love Descent 2!

People say this a lot about Linux and it somewhat rubs me the wrong way - sure, the Windows binary works if you install its library dependencies (wine). Likewise (OK, ever since libc5/glibc2 changeover in 2001) the Linux binary should work if you have its library dependencies (SDLv1 it looks like?). So what's really the problem? Your distribution stopped distributing the dependencies, making them harder to find? "DLL Hell" was a thing too.

I didn't see any binary downloads for Linux on that website, only source code.

I gave it a try anyway, the dependencies were actually not a problem for me, Debian has libsdl-{net,image}1.2-dev, libglew-dev, and so on, and if your distro does not have SDLv1 there is libsdl1.2-compat. But after the dependencies, there was a problem with the source code doing something involving bitfield packing that does not compile on x86_64.

I do see the source code has lived on, i can `apt install d2x-rebirth` on Debian 13 which has a comment about https://www.dxx-rebirth.com/ ...is that helpful?

> the Windows binary works if you install its library dependencies (wine).

Yes but all it takes is an `apt-get install wine` or `zypper install wine` or `pacman -S wine` or your distro equivalent and if you are using a Linux distro with any sort of desktop functionality, 99% of the time wine will be there.

> Your distribution stopped distributing the dependencies, making them harder to find?

Yes, this is a big problem because these dependencies not only are harder to find but even if you track all of them (there is a chance they too have their own dependencies) you still need to figure out how to build and install them. And if they are old enough for distros to drop them, then chances are building them isn't going to be a straightforward `./configure && make && make install` ("straightforward" is very relative here :-P). And woe is you if there are conflicts with newer (yet API/ABI incompatible) versions of these libraries and/or their dependencies.

Of course since you have the source, technically you can make things work, but that doesn't make the process any less of a major PITA.

Syscalls on macOS aren't guaranteed to be stable - Go found out the hard way and in 1.12 they changed to call libSystem.dylib instead.

In general, stable syscall numbers are just a Linux thing. Everyone else uses blessed system libraries

Yeah, I know MacOS syscalls aren't stable. Interesting point about Go, I hadn't heard about that. Unfortunately I'm a masochist though, and want to avoid libSystem.dylib as much as possible. The only reason I link against it at all is because MacOS requires it for executables to run, I never actually call into it. Figured I'd just update the syscall numbers if/when they change.

You could also do a trick some Windows stuff does - parse syscall indices from said dylib.

I was pleasantly surprised to learn the architecture for this - a minimal backend that does a PAM auth and gives you a shell over websocket, with only your own Linux user credentials - and then everything else (from managing files to apache to VMs) is done in frontend javascript.

Keeps the server-side backend minimal and auditable.

Intel Ispc is a compiler for a C superset language that targets CPU SIMD and GPUs.

A beautiful find! It’s what 12+ years old at this point?

Definitely the closest thing so far (doesn’t do multiprocessing) but does seem to do SIMD / multithreading and GPU auto parallelizing!

Any idea why it’s so little known?

This is not true - it's actually all the same VM if you check hcsdiag.

WSL2 distros only use Linux namespaces, same as docker, and the WSL2 --system distro can see PIDs from all running WSL2 distros.

A few release cycles back, Swiss Maps became popular (i think, particular thanks to CockroachDB) as a replacement for standard Go map[K]V.

Later, Go's stdlib map implementation was updated to use Swiss Maps internally and everyone benefited.

Do you think the xsync.Map could be considered for upstreaming? Especially if it outperforms sync.Map at all the same use cases.

There are multiple GH issues around better sync.Map. Among other alternatives, xsync.Map is also mentioned. But Golang core team doesn't seem interested in sync.Map (or a generic variant of it) improvements.

Gaseous form is a problem, but have you seen the Fraunhofer POWERPASTE? I was optimistic when the news was first announced, but that was a decade ago and of course it's not widely used.

At that point you're just building a weird battery storage system again though.

Go can create C ABI shared libraries, I think OpenSSL-compatible C bindings to Go's crypto/tls would be a really interesting option.

Do you want garbage collection in your SSL?

Clearing of the secrets is a separate issue from memory allocation mechanism. It must be done all the way from the encryption layer to the program to avoid the leaks.

This is typically not done, only certain parts such as handling of the crypto keys. That's because it's pervasive and requires reworking everything with that in mind (TLS library, web framework, application).

On the other hand the centralization and global usage of GC in the process allows to modify it to always zero out the memory that it deallocated and to do GC at regular intervals so it can have advantage here (it's very easy to inadvertly leak the secrets to some string).

Where do you see the problems? Because of memory that was not cleaned up and leaks secrets?

There the new runtime/secret could help.

Better than no memory safety, sure. Also a kernel should be memory safe, so garbage collected.

Garbage collection is not required for memory safety.

Languages that have garbage collection are not all memory safe.