qhwudbebd
qhwudbebd on Hacker News
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.
Reading and hacking on the Chez Scheme codebase is always a treat and rather inspiring, especially compared with more mainstream compilers and code generators. As well as Kent Dybvig, Andy Keep's contribution (nanopass) is super-impressive. The whole thing is so cleanly designed and beautifully expressed.
And the N150 had mainline linux support from day one, whereas I'm not sure if there's proper support for pi5-family devices in a released mainline kernel even now, two years after the launch.
They used to do an good-to-adequate job of linux support, but nowadays they seem rubbish at it. Nobody wants to be stuck on a downstream kernel full of cobbled-together device support that's too poorly-written to upstream.
This is certainly the reputation but I'm not sure they deserve it. They've always had the horrible closed-source bootloader with threadx running on the gpu, without a free alternative. At least up to pi4 they weren't bad at linux mainlining, but progress on upstreaming pi5 support has been glacial.
Cf. the various Beagle boards which have mainline linux and u-boot support right from release, together with actually open hardware right down to board layouts you can customise. And when you come to manufacture something more than just a dev board, you can actually get the SoC from your normal distributor and drop it on your board - unlike the strange Broadcom SoCs rpi use.
UK perspective here: I've not claimed for $43, but I've used the small claims process to recover £65. They replied to the paperwork sent out by the court indicating they intended to defend it, so I paid the hearing fee to take it to court, where the judge was polite, helpful, very switched-on, and didn't seem remotely annoyed by the size of the claim.
The total costs of making the claim were more than the amount I'd claimed, but I'd been careful to provide all the proper notice and offer to settle for the amount of the claim, so they were awarded against the defaulting client.
It was great fun and I think it would have been fun and educational even if I'd lost. Would definitely do it again.
I came here to mention this too, but saw you'd beaten me to it. It's remarkable how bad non-free OSes are at maintaining basic infrastructure in their kernel and userspace compared to Linux and the BSDs isn't it? Basic bugs get neglected for decades in favour of rearranging the cosmetics - in this case, it's been more than 20 years since I first reported this to Apple's /dev/null service, and I'm sure I wasn't first and I'm only one of many.
I'm really surprised to hear that the slow restore times from tarsnap are still as big a problem now as they were a decade ago when I last used it. I absolutely loved the interface and the security model, and I was willing to pay at the (very) premium price point, but it was just too impractical trying to restore anything from it at the speeds I could achieve. (If I remember right, there was some problem with the design which meant normal latency between the client and the server tanked throughput to crazily low levels.)
I think it's pretty much policy by now that GitHub don't allow features to be disabled by users who dislike them. Those of us with public projects that don't or can't accept contributions through GH PRs (including niche things like torvalds/linux) have been asking to disable PRs since day 1.
Nice to see BSDs up and working on new RPi hardware. Is there even (mainline) linux support for RPi5 and CM5 nowadays? For what seemed like ages they were unsupported (no usable IO) and I avoided using any of the newer boards for projects as a result, but it's years after the hardware release now so I assume most things must finally be upstreamed?
This is true for personal tax, but HMRC has been successfully bribed by Sage et al. not to support web-based returns for partnerships or companies.
Another masterpiece of elegance: v1/images/generations supports only application/json requests, whereas v1/images/edits supports only multipart/form-data. (The keys expected by the two calls are otherwise entirely compatible.)
I hope the images support in the responses API is more competently executed than the mess piling up in the v1/images/generations endpoint.
To pick an example, we have a model parameter and a response_format parameter. The response_format parameter selects whether image data should be returned as a URL (old method) or directly, base64-encoded. The new model only supports base64, whereas the old models default to a URL return, which is fine and understandable.
But the endpoint refuses to accept any value for response_format including b64_json with the new model, so you can't set-and-forget the new behaviour and allow the model to be parameterised without worrying about it. Instead, you have to request the new behaviour with the older models, and not request it (but still get it) with the new one. sigh
Given serial access on an mt7981, you can usually use the UART recovery protocol to boot a bricked device entirely over serial, e.g. with
https://github.com/981213/mtk_uartboot just run something like
mtk_uartboot -s /dev/ttyS0 -a -p bl2.ram -f fip.img
This works even if atf and u-boot are corrupt on the device: it's part of the SoC's boot rom.
This is one of the things that makes the filogic routers nice to hack at, the other being that they're arm64 rather than something weird and legacy.
Thanks. I went to look at bcm2712-rpi-5-b.dts and bcm2712.dtsi in 6.12.x, as it's been a while since I last checked, but it looks like even 14 months after the RPi5, they've still got no further with upstreaming than serial support. No USB, no graphics... possibly SD card working?
They used to be alright (if not stellar) at Linux support so the story with RPi5 has been really disappointing. Hard to choose CM5 for a product when it's stuck in a downstream quagmire.
Do this and the RPi5 run (proper mainline) Linux yet, or are they still only usable on the fork hacked together in-house?
Don't disagree for what it's worth. The non-_RB behaviour for streams is useful too and isn't available at all on Linux. Though it's nowhere near as annoying as Linux having the epoll() mess instead of kqueue().