pizlonator

Incredible. I had to dig for the source: https://huggingface.co/blog/security-incident-july-2026 section “the asymmetry problem”

Quote: “When we started the log analysis, we first used frontier models behind commercial APIs. This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker. We ran the forensic analysis instead on GLM 5.2, an open-weight model, on our own infrastructure. This had a second benefit: no attacker data, and none of the credentials it referenced, left our environment.”

Yes

The only truth is shipping code

Specs are secondary

They're claiming that it's a cheaper alternative to Fable/Sol

If that's true, then the price makes sense

I use AI all the time

But

I don't want the AI to summarize my email for me.

I don't want the AI to summarize my calendar for me.

I don't want the AI to summarize my Zoom call for me.

Thanks

Maybe for the multi modal?

Yeah

I read a decent chunk of the rewrite.

It’s inaccurate to call it a rewrite. It’s more a transliteration - it matches the original Zig almost exactly but the syntax is different.

And yeah, unsafe blocks anywhere that rust would have complained

So it’s highly likely that the “rewrite” is exactly as reliable as the original.

(It sure feels like this was done for Anthropic marketing reasons, the more I think about it.)

Yeah

But the point is that at any moment, there is friction in switching

That makes sense, but I really do have to emphasize just how gloriously stable my old PC router setup was.

It was the most incredibly hassle free router I've ever had.

Hopefully, the OpenWrt One is like that. But if not, I'm going to go back to killing the planet with my loud ass beater PC.

What a coincidence to see this on the front page!

I just received my OpenWrt One because I’m tired of dealing with the questionable quality of most routers.

And I don’t feel like resurrecting my old PC that I used as a router for a while. I stopped doing that because it’s loud. Pretty sure the power supply fan is about to fly off.

But Qualcomm WiFi pci card with giant antenna in a dirt cheap PC running ancient Ubuntu and a simple hostapd setup is so far the most reliable WiFi router I’ve ever had. I hope openwrt one is even better :-)

How much water AI data centers use feels like the least interesting reason to dislike them.

If I wanted to dislike them for environmental reasons, then I’d focus entirely on the energy consumption and CO2 emission from the generators directly hooked up to the data centers since the grid can’t provide them with enough juice.

If I wanted to dislike them for economic reasons, I’d focus entirely on the weird circular deals and mountain of debt.

If I wanted to dislike them for social reasons, I’d focus on how AI proponents themselves admit that the whole point is to take all of our jobs.

The water thing feels like a weird hill to die on. It doesn’t feel serious. It’s by far not the biggest problem!

I meant descendant. Fixed.

You don’t have to be in the same function as the setkom; you just have to be in a frame that’s deeper in the stack, or the same frame

The point about memory safety is really this: if I allowed you to longjmp but did not guard it adequately then you could escape the Fil-C capability model, and then all of Fil-C’s bets would be off. I can’t have that ;-)

Gotcha, that’s a good list.

It’s true that Fil-C doesn’t try to protect you from those bugs. I just don’t think of those as the worst things that can happen when you misuse these APIs.

I’ve used the copy-stack trick before! It’s really great!

You can work around the pointer relocation issue by always coping the stack back onto the main stack. So you’re always running on the same range of stack in memory and saved stacks are always elsewhere

In comparison, ucontext is very heavy

It's heavy because it switches the signal masks.

Indeed, Fil-C's ucontext logic does this today, because I'm relying on glibc, and that's what glibc does.

But it would be straightforward to teach the internal Fil-C zfiber_context API to not save the sigmasks. It would just mean using some other backend for setcontext/swapcontext. Considering that there are multiple open source projects (including Boost!) that have code that does this, it would be easy to set that up.

But I'm taking baby steps here. And the first step is just to provide a memory safe wrapper around these quite dangerous APIs. Probably the next step is to just write a lot more tests to try to break it. Then, later, I can worry about adding alternative backends to expose the sigmask-free version of this that Boost (and most others) want.

What misuse are you imagining that isn’t a memory safety problem?

You might find that Fil-C prevents those too. It’s pretty strict. You can only use longjmp to pop stack like an exception would

Claude only ever wrote some tests

I have used Kimi K2.6-code and GLM 5.2, but only for things that are easy to verify. I did not use any LLMs for the longjmp/ucontext work.

These functions can easily be misused to corrupt memory, so they very much have something to do with safety. Fil-C goes to great lengths to prevent your use of those functions leading to memory corruption or any violation of the capability model.

Fil-C also makes sigaction memory safe. That protection does allow for signal handlers to longjmp or setcontext or swapcontext

Right

That’s still in the OpenAI charter fwiw

It is super unfair

It creates a two tier system - those who have access and those who do not. Worse, it’s some corpo making the decision

Correct.

Yeah

Also, like, this is the initial implementation so I kept it consistent with the rest of the error checking

If someone wants a compile time diagnostic they can submit a patch

You have to understand that Fil-C primarily exists as a marketing stunt.

What a bitter way to analyze a technology.

under some circumstances Fil-C considers it legal to read a value from a totally different, possibly-inaccessible pointer when dereferencing an unrelated pointer

Fil-C does not consider such a thing to be legal.

You can only access capabilities that you legitimately loaded from the heap, from other capabilities you legitimately loaded, and so on. So, if you access a pointer, it's because you had access to the capability.

You aren't supposed to actually use it.

Wat

Ooh - I thought you meant adding boosts use of assembly to the list of inline asm use cases

I get you now

It’s not inline assembly

It’s module assembly

They’re different

I was able to build it and a lot of it seemed to work

There was some debugging thing where it embeds debug info using module level assembly that you have to disable.

It’s surprisingly hard to define „erroneously”, but that’s not far off from what I did

Example of a bug found most recently was that sahf was allowed without a cc constraint.

Anyway, if you find bugs, file them. Would be fun to see if there’s a case me and my agents missed

Zero, since I made those programs work back when all inline asm was an error.

So currently most of those still have the hacks to go down the no-inlineasm path when building with Fil-C

For the few where I reinstated the inline assembly, there were no bugs found.

It would be a good experiment to try to reinstate the inlineasm paths in all of the programs that had them. I suspect there’s a low chance of finding a bug if it’s in inline assembly that’s on the critical path.

Your godbolt code used atomic_thread_fence

The quote uses atomic_signal_fence.

If you find a way to bypass my checks, file a bug. I tried very hard to break it. My agent loops tried even harder

compliant at scale

The jokes write themselves.