Cost/manufacturing complexity. If you are country struggling to defend your self you don't think problems in 30 years if today problem is does the country exists or not. Might be difficult to put your self to a small defending countries shoes which is absolute running our of resources.

I get it, I don’t think a timer really adds that much cost and complexity. "If he wanted to, he would" scenario.

The costs of the self-destructs and failsafes exceed the cost of the rest of the landmine. One of the reason mines are used is that they are exceedingly cheap and simple to build at scale. No batteries or electronics. Even a relatively primitive industrial base can produce them.

In practice, only wealthy countries are willing to pay for mines with reliable self-destruct and target discrimination technology.

If you don't have workflows which repeat in inet you don't need openClaw. - Messages from school where to react - Getting payments from someone and tracking that you get them - Summary of news the way you like it from sources you like it every day - Integrated task lists reminders - Drafting taxation reports based on spending etc etc.

I just don't trust "the claw" so I build following system - Docker 1: * Locked up Claw docker - user level priv. Access outside to "one port" only.

- Docker 2: * Tool gateway with pre-baked commands - openclaw can only index what command to execute * Keys are here * Telegram hook to approve all "post" commands i.e. sending email or posting something somewhere.

- Docker 3: * LLM gateway keeping track of cost and routing

So you need to approve all actions that actually do something, individually?

No as you could have multiple examples of expected output in single prompt. You should just "ask" - that's zero shot. If you "ask + provide" examples then you are in the n+1 shot realm. But I suppose terminology is shifting from this...

What confused me is the fact that in the paper all logical steps are give. It basically check that when all relevant facts are provided explicitly as links , how far and how complex a chain can the model correctly follow before it breaks down?

So it's simpler than "reasoning". This is not necessarily a bad thing as it boils down the reasoning to a simpler, more controlled sub problem.

Is this just buttering the cost of switches by crippling the optimization options compiler have?

If this was done the classical C way, you would always have to stack-save a number of registers, even if they are not really needed. The only difference here is that the compiler will do the save for you, in whatever way fits the context best. Sometimes it will stack-save, sometimes it will decide to use a different option. It's always strictly better than explicitly saving/restoring N registers unaware of the context. Keep in mind, that in Zig, the compiler always knows the entire code base. It does not work on object/function boundaries. That leads to better optimizations.

This is amazing to me that you can do this in Zig code directly as opposed to messing with the compiler.

See https://github.com/alibaba/PhotonLibOS/blob/2fb4e979a4913e68... for GNU C++ example. It's a tiny bit more limited, because of how the compilation works, but the concept is the same.

To be fair, this can be done in GNU C as well. Like the Zig implementation, you'd still have to use inline assembly.

> If this was done the classical C way, you would always have to stack-save a number of registers

I see, so you're saying that GCC can be coaxed into gathering only the relevant registers to stack and unstack not blindly do all of them?

Yes, you write inline assembly that saves the frame pointer, stack pointer, and instruction pointer to the stack, and list every other register as a clobber. GCC will know which ones its using at the call-site (assuming the function gets inlined; this is more likely in Zig due to its single unit of compilation model), and save those to the stack. If it doesn't get inlined, it'll be treated as any other C function and only save the ones needed to be preserved by the target ABI.

I wonder how you see it. Stackful coroutines switch context on syscall in the top stack frame, the deeper frames are regular optimized code, but syscall/sysret is already big context switch. And read/epoll loop has exactly same structure, the point of async programming isn't optimization of computation, but optimization of memory consumption. Performance is determined by features and design (and Electron).

What do you mean by "buttering the cost of switches", can you elaborate? (I am trying to learn about this topic)

I think it is

> buttering the cost of switches [over the whole execution time]

The switches get cheaper but the rest of the code gets slower (because it has less flexibility in register allocation) so the cost of the switches is "buttered" (i.e. smeared) over the rest of the execution time.

But I don't think this argument holds water. The surrounding code can use whatever registers it wants. In the worst case it saves and restores all of them, which is what a standard context switch does anyway. In other words, this can be better and is never worse.

I would focus on lowest of the axis. It does not help if some of the axis are at 100% if one of the axis is lacking.

My point is that the axes chosen are important, and if this is a good rating system, we ought to see those radial charts for the different models and systems available.

Really really nice. Thanks for this!

Are the rules versioned somehow? I didn't see that.

Good to note that OpenAI solved 12/12 and DeepMind 10/12.