qhwudbebd

It's reasoning.mode, next to reasoning.effort in the responses API. Set to the string "pro" for pro mode. Sorry, I don't use first-party harnesses so have no idea what it maps to there.

Please can I ask about one parameter you didn't mention here? All of your models have both a reasoning effort setting and also a non-pro vs pro setting. I have some intuitive feel (from experimenting) for the difference a larger vs smaller model makes, and why that's different from adjusting reasoning levels, but I have no real feel for how pro vs non-pro is different in behaviour from adjusting effort.

I remember procps top --help did this. I hated the resulting clunky, inconsistent wording enough to add a local patch in my procps build recipe to rewrite it.

Apparently I'm still carrying the patch, so the current version must still do it.

OpenRouter map this into their API in a slightly different way, making -pro and normal different model slugs, so you have openai/gpt-5.6-luna-pro vs openai/gpt-5.6-luna vs openai/gpt-5.6-sol[-pro], etc. This makes reasoning effort one-dimensional again (albeit with the arbitrary sequence of strings), but now model choice in a given generation is two-dimensional. Either way, it's hard to make any kind of informed decision.

It seems even worse than that: when you're calling the model, you have this strange two-dimensional thing with reasoning effort (specified in a small handful of random strings like "medium", "xhigh", "max") and "pro" vs "not pro" which is also somehow increasing reasoning budget, but with an interaction that is entirely opaque. How does "medium", "pro" compare with "max", "not-pro" for instance?

If you're going to force people to specify manually, at least make it 0.0 - 1.0 normalised such that 0.5 is the default.

Yes, I was going to suggest nat64 encapsulating the customer's v4 network on the wireguard overlay, but their embedded device is presumably a little linux board, and mainline linux still lacks any siit/clat/nat64 in netfilter. So I guess they'd end up in a world of pain with out-of-tree modules like jool or inefficient funnelling through taptun tayga-style.

My impression is that you (very reasonably) treat anything inside the VM as untrusted. If you want trusted rollback, presumably that implies that the VM can't have any ability to tamper with the snapshot?

But maybe you have parts of the stack that don't need to be trusted inside the VM somehow? Looking forward to the article.

AFAIK fly.io run firecracker and cloud-hypervisor VMs. This seems to have a copy-on-write filesystem underneath.

Given their principled take on only trusting full-VM boundaries, I doubt they moved any of the storage stack into the untrusted VM.

So maybe a virtio-block device passing through discard to some underlying CoW storage stack, or maybe virtio-fs if it's running on ch instead of fc? Would be interesting to hear more about the underlying design choices and trade-offs.

Edit: from their website, "Since it's just ext4, you won't run into weird edge cases like you might with NFS or FUSE mounts. You can happily use shared memory files, for example, so you can run SQLite in all its modes." So it's a virtio block device supporting discard that's exposed to the VM. Interesting; fc doesn't support virtio discard passthrough, and support for ch is still in progress...

It claims London E1W for my IPv4 and IPv6 RIPE PI space, and the same location/postcode for my EE home broadband. Generic 'London data centre' postcode? Or the location of the nearest Cloudflare POP, maybe? (Whois on the PI blocks shows a correct postcode some distance from London FWIW.)

[Edit: same location and postcode for a Vodafone UK v4 address too.]

I hack on various C projects on a linux/musl box, and I'm pretty sure I've seen musl's malloc() return 0, although possibly the only cases where I've triggered that fall into the 'unreasonably huge' category, where a typo made my enormous request fail some sanity check before even trying to allocate.

Quite apart from that, an EFI shell that's less awful than the standard UEFI one is an interesting project in its own right...

Whenever I think about writing a central privileged daemon to grant capabilities to other processes, I'm puzzled by the choice to remove the old version of CAP_SETPCAP in 2.6.24: "grant or remove new capabilities to/from an existing running process" - sadly it still exists but means something else in newer kernels with filesystem capabilities.

(In a sense, not having this capability in processes running as root is theatre anyway: you have /dev/kmem access so could just edit the kernel data structures. It's just doing so cleanly that is no longer possible.)

Being able to briefly escalate my editor to have the capabilities to write /etc/wibble.conf when I started editing it as a non-privileged user, then take away the capability again would be more convenient that always needing to run the editor as root. (So convenient, in fact, that people fake this with little editor helpers that do the equivalent of 'really tee FILE-TO-WRITE >/dev/null', but that's an ugly hack.)

    while wait && [[ $SECONDS -lt $1 ]]; do
      read -t $(($1 - SECONDS))
    done <><(:)

although if you're not too concerned about finishing early if a signal interrupts, probably

    { wait; read -t $1; } <><(:)

would be fine. You want the wait because otherwise bash won't reap the zombie from the process substitution until after the read times out.

Interestingly, it does reap on a blocked read without -t, so potentially the behaviour on -t would be considered a bug rather than as-designed.

There's also a loadable sleep builtin supplied with bash which calls into the internal fsleep() so should be reliable and without forking.