qhwudbebd

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 <><(:)

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

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.

This has prompted me to look at how the Tor Project's Arti reimplementation is going. They've got way further along than I realised:

https://tpo.pages.torproject.net/core/arti/

https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CHAN...

Hosting onion services is apparently still a work-in-progress, though, and turned off by default.

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 real 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.

I'm quite a lot more positive about rp2040 and rp2350, where they've at least partially broken free of that Broadcom ball-and-chain.

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?

In case your first instinct (like mine) was to browse through the implementation, the javascript is at https://github.com/VSRemoter/LuxPDF/blob/main/script.js

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 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().

Indeed. SO_REUSEPORT_LB is the FreeBSD equivalent of SO_REUSEPORT on Linux. SO_REUSEPORT on FreeBSD means something different, as you say. If SO_REUSEPORT_LB exists, we're on FreeBSD and want to use it! :)

Confusingly, on FreeBSD this option is SO_REUSEPORT_LB; SO_REUSEPORT is something different. So I find myself writing

    #if defined SO_REUSEPORT_LB
      setsockopt(fd, SOL_SOCKET, SO_REUSEPORT_LB, &(int) { 1 }, sizeof(int));
    #elif defined SO_REUSEPORT
      setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, &(int) { 1 }, sizeof(int));
    #else
      [do something to avoid reusing sockets]
    #endif
 

The nat64/clat situation on Linux is not brilliant at the moment. There are userspace implementations like Tayga and Tundra. These incur kernel-userspace-kernel transition for each packet so are pretty inefficient and struggle unnecessarily on low-end hardware.

Then there are out-of-tree modules of varying quality, none of those I've looked at being amazingly inspiring code-wise. As out-of-tree modules, they'd need to be rebuilt whenever you rebuild your kernel, but would inconveniently not be built as part of that kernel unless you patch them in.

I'd not seen the eBPF implementation before. That's quite a nice idea. Quite tempted to have a hack at that to fix the minor issues the author identifies.

(What's the story with building eBPF programs nowadays? Are there all kinds of crazy dependencies, or is the situation better than it used to be?)

One of the choices you've made that I really like is sharing the kernel and userspace filesystem code so directly in the form of libbcachefs. I get the impression this means the kernel can do practically everything userspace can, and vice versa. (I think the only exception is initialising devices by writing a superblock, although the kernel can take over the initialisation of the rest of the filesystem from that point onwards? And maybe turning passphrases into keys for encrypted-fs support which does an scrypt thing?)

As well as giving you really powerful userspace tools for manipulating filesystems, this also suggests that a stripped down busybox module for bcachefs could consist of superblock writing and pretty much nothing else? Maybe a few ioctls to trigger various operations. "Just leave it all to the kernel."

Do these give you decent performance DMA-able gpio and spi like you get even on a cheap rpi4? (I'm not claiming they don't/can't, just that it isn't immediately obvious to me that they would.)

For example, spi is an easy hack to bit sample a digital level and stream the results into memory for later processing. You can effortless do this at 20MHz+ plus on an rpi4. When you want to stream multiple digital levels simultaneously (in sync), DMA on gpio is a nice generalisation. (Could perhaps abuse I2S inputs too, which might be present on a more generic x86 board?)

I always wonder about a nice PCIe board supporting good DMAable gpio/spi/i2c/etc on standard x86 machines. I'd probably pay a fair amount of money for a quality one. But it's a product I've never seen on the market. Bodging a USB gpio interfaces with one of the relatively low spec chipsets seem like a pale, inefficient and high-latency imitation.

Actually, given the RP1, maybe the rpi5 has slow/non-DMA gpio too? I haven't been able to check it out yet as these boards still don't have mainlined linux support and I'm not up for buying toys that don't. (Am I imagining it, or did they used to be a lot better at mainlining support for their boards promptly?)