HN user
Software engineer, Christchurch, New Zealand.
Spare-time projects wind up here: https://code.ivysaur.me/
This distinction is less a gotcha and more actually immediately obvious in the Windows task manager. It shows cached memory separately and in a different colour. The "in use" part is real in-use excluding the page cache.
On my current Windows 11 install i'm using 7 GB with just this Firefox tab open, and another 18GB of "Cached" RAM.
Same as how `free` on Linux shows it in a different column.
Steve Yegge calls this is the "discernment horizon" - https://steve-yegge.medium.com/the-flat-curve-society-36c8b0...
The off-the-shelf player in this space (structured red-team search) is probably https://github.com/usestrix/strix (no affiliation). But any frontier model, if you tell it "here's how the authentication system works, go looking for bugs" will probably do a good job.
- MiMo (Xiaomi)
Blender has all these curve tools and more, it might be interesting to write an exporter to the Neverball file format if one doesn't exist yet.
In my harness i implemented apply_patch just taking unified diffs for patch -p1. I was shocked to see how bad models are at generating them. I started logging diff failures to analyse -
- All models are terrible at generating line numbers for a proper diff, give up on them
- Some models (Owl-alpha) must have been post-trained on Codex transcripts, because they occasionally push its V4A patch format into any diff tool available
- Codex puts a lot of info in its system prompt about the desired patch style, making larger hunks instead of granular ones, etc
There was some earlier speculation this is the model behind the stealth-released openrouter/owl-alpha model, that's been free for the last month.
There's also this new one: https://github.com/joske/yserver
It was somewhat slow about a decade ago - you can see
- (2015, Go 1.5) Calls cost about 170ns https://www.cockroachlabs.com/blog/the-cost-and-complexity-o...
- (2017, Go 1.8) Cgo speedup by 50% https://go.dev/doc/go1.8#cgoperf
- (2023, Go 1.21) Calls cost about 40ns https://shane.ai/posts/cgo-performance-in-go1.21/
- (2026, Go 1.26) Cgo speedup by another 30% https://go.dev/doc/go1.26#faster-cgo-calls
A current benchmark shows a Cgo function call as costing about 25 ns. https://gist.github.com/DeedleFake/2f50b02c0708484c66d182533...
Cgo is cheap these days, don't worry about it.
It's barely more expensive than a direct function call but, not so you'd notice unless it's in a hot loop. At which point the lack of cross-language inlining is your real problem.
This is all true but is a somewhat Java-flavoured perspective i.e. generations ties you into a moving collector, which ties you into barriers and complicates FFI, which is not always the right tradeoff.
A non-fragmenting allocator goes a long way to alleviating the need for compactions too.
Hold on - 15k GBP?
An ordinary heatpump for an ordinary house should cost something like 3000 NZD including labor for installation. What are we doing differently?
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'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 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?
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
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.
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.
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.
Go can create C ABI shared libraries, I think OpenSSL-compatible C bindings to Go's crypto/tls would be a really interesting option.
You can see the spirit of what they're going for also with the MIT binaries - that's also like saying the whole project is AGPL, but a loosening for using it as-is.
Given their goals seem to be
- Permissive use without modification, even in combined works ("MIT binaries"); but
- Copyleft with modification, including for the Affero "network hole", or commercial terms
could you suggest a clearer license option? AGPL triggers copyleft across combined works, LGPL doesn't cover the network hole, GPL has both problems. Their goals seem really reasonable, honestly, there should be a simple answer. It seems messy but I like it more than the SSPL/BSL/other neo-licenses.
Fun!
126 Intel N5105, gcc -O2 (Debian)
98 Neoverse N1, gcc -O2 (Debian) - Oracle Cloud
63 Snapdragon 8gen3, clang -O2 (Termux) - Xiaomi 14
59 Ryzen 7600, clang -O2 (MSYS2 / Windows 11)
48 Ryzen 7600, clang -O2 (Debian)
45 Ryzen 7600, gcc -O2 (Debian)Dokku user for a decade here, congrats on shipping, love to see more self-hosted PaaS options like this.
Why are binaries checked into the bin/ directory in the repo?
Compared to Dokku, I like how your LE support is builtin instead of a plugin. Is your main www ingress server an nginx that gets externally configured (like Dokku) or are you using net/http or libcaddy directly?
Dokku has a history of trying to compete with Heroku buildpacks - as a non Heroku/non Ruby developer this never resonated with me and there are a lot of vestigal parts (e.g. .web.1) that i would just put in my own Dockerfile directly. So focusing solely on Dockerfiles i personally feel is a good move.
One issue i faced with Dokku is eventually the build process for my Dockerized app was too memory-intensive to run on the VPS. I switched to running docker build locally, sending the container via `docker export | ssh | docker import`, and having a single `FROM myapp` dockerfile in Dokku. This was not particularly ergonomic to set up. Is it possible you can improve the UX of client-side built containers, or will you focus solely on the GitOps deploy?
Cool project!
I would hope "native" means at least either CPU-native code (i.e. not Typescript) or OS-native UI (i.e. not Electron) - what did you mean by it here?
ZLUDA implements CUDA on top of AMD ROCm - they are explicitly targetting vLLM as their PyTorch compatibility test: https://vosen.github.io/ZLUDA/blog/zluda-update-q4-2025/#pyt...
(PyTorch does also support ROCm generally, it shows up as a CUDA device.)
What is ACPI other than a DTB baked into the firmware/bootloader?
Any SBC could buy an extra flash chip and burn an outdated U-Boot with the manufacturer's DTB baked in. Then U-Boot would boot Linux, just like UEFI does, and Linux would read the firmware's fixed DTB, just like it reads x86 firmware's fixed ACPI tables.
But - cui bono?
You need drivers in your main OS either way. On x86 you are not generally relying on your EFI's drivers for storage, video or networking.
It's actually nice that you can go without, and have one less layer.
Crawlers will find everything on the internet eventually regardless of subdomain (e.g. from crt.sh logs, or Google finds them from 8.8.8.8 queries).
REQUIRE_SIGNIN_VIEW=true means signin is required for all pages - that's great and definitely stops AI bots. The signin page is very cheap for Gitea to render. However, it is a barrier for the regular human visitors to your site.
'expensive' is a middle-ground that lets normal visitors browse and explore repos, view README, and download release binaries. Signin is only required for "expensive" pageloads, such as viewing file content at specific commits git history.