avsm

I'm glad to hear that DfD's repo is still the piñata!!! Congrats on the Docker sandbox launch as well, great to see it integrated now.

I am having a blast working on environmental science these days, and we’re long overdue a beer next in SF!

Am firing up Dagger to give it a try on our geospatial workflows for the first time just now; it’s got the same attention to CLI detail as Docker 1.0 did :-)

(Unikernel cofounder here)

When acquiring our company, Solomon took us to a remote farm in France for a week for an offsite, fed us fantastic food and wine, and the first prototype of that Docker for Mac VM was working by the end of the week! It took a few months to hack together the shell. There's a video of Solomon and the pinãta launch party on my blog ;-) https://anil.recoil.org/notes/cacm-docker-cover#getting-invo...

There was a whole other slice of work we did for project Piñata too in the form of datakit (https://github.com/moby/datakit) that was well ahead of its time. I was looking at this archived code again just last week while thinking about agentic git workflows!

> Docker Linux have not been using microVMs for a decade.

You sure could. Kata containers have been around for a long time; I remember putting them into production back in 2017 or so (and dealing with filesystem forwarding issues). https://lwn.net/Articles/755230/

For the nostalgia seekers, I uploaded the OG Docker for Mac beta video: https://crank.recoil.org/w/3re5G972kkqjzzujxHQ3E6

I do think this was well ahead of its time. Under the hood, we designed a Linux distro called LinuxKit (https://github.com/linuxkit/linuxkit) which ran every process in its own mount namespace (including the init process), and had a deterministic build with hashes. As far as I can tell, it's still pretty hard to get this experience even with Nix in 2026.

The boot time was also quick enough to be entirely in parallel and so not be noticeable (the 'bounce time' of the application on Mac was one bounce!)

OCaml (the language I use in the post) is an extremely memory safe language, but there are plenty of higher level logic issues that spring up.

LLMs are extremely good at finding corner-case vulnerabilities in C bindings even within a memory safe language; see for example the fixes in an OCaml crypto library here: https://discuss.ocaml.org/t/the-series-of-mirage-crypto-rele...

Custom infrastructure; I use my site as a playground for various things over the years. It ran as the first MirageOS unikernel for many years, and recently it's been running on a zero-allocation OxCaml webserver https://anil.recoil.org/notes/oxcaml-httpz to help me get to grips with the new extensions.

There's a full terminal implementation of Bonsai as well. I actually use it in my personal workflow these days to manage my contacts database! https://anil.recoil.org/notes/aoah-2025-9

Fun is, by far, the biggest reason I can identify why I work on some open source projects and not others these days! I think it was also true in the past, but to a lesser extent. Docker circa 2015 never felt like a job at all and the early Dockercons werre a thing of legendary entertainment!

A couple of things have possibly conspired to make more established projects less fun in the past few years:

- we're getting older; as maintainers age, I find it's just harder to make time to go to hackathons and socialise with the younger generation, much as I would love to. Too much real life stuff on. The pandemic also established a 'before/after' and conferences just haven't been the same level since for me. I'm not sure if I changed or the conferences did.

- obviously LLMs, since they add a layer of interferences between both the demands on my maintainer time (LLM generated PRs) but also how much I need to interact with other people to solve a problem. I made plenty of online friends over the past three decades figuring stuff out together over some obscure library, but group debugging seems less important now if you can chuck it at Fable.

yep, I host two separate Tangled knots; one for my personal use and another for work at the Cambridge Computer Science department. Having large git repos on a server near me is great, and because I can sync the bare git repos it’s easy to run a local forge as well.

I looked at this last year when it came out in Tahoe: https://anil.recoil.org/notes/apple-containerisation and this looks like more of the same.

They've now added a WSL-style virtual machine layer, but there's no x86 container story (Apple's killing Rosetta) so I imagine some qemu shimming will be required.

There's still no equivalent to VPNKit or GVisor for networking so you'll be bridging I think. See: https://cacm.acm.org/research/a-decade-of-docker-containers/ for how Docker for Mac does this

I can't spot any support for dynamic memory ballooning to prevent the hypervisor from gobbling up too much memory. We've had this in Xen since forever! https://xenproject.org/blog/ballooning-rebooting-and-the-fea...

And, most obviously: NO SUPPORT FOR MACOS. This is the single feature that only Apple can do, and they're choosing not to implement it deliberately, and it's so stupid given the pains we all have to go through to implement CI for macOS. In the land of OCaml, we were forced to implement a custom ZFS snapshotter to get reasonably cost effective macOS CI for our package repository: https://tarides.com/blog/2023-08-02-obuilder-on-macos/. This was fun to build, but it sucks to have to maintain it.

Also, I'm really curious what the GPU passthrough story here is for LLMs, since the Apple Silicon -> Linux kernel support is gated on Asahi's support, but that's been lagging beyond M2 due to the efforts of reverse engineering.

Do better for your developers, Apple. This is a half-baked sweep across third-party software without addressing the core needs around your own operating system.

Nice work! Did you ever open any open source any of it? Looking at your OCaml wishlist from back in 2017, some stuff has improved and some is on its way:

- Support for read-only BigArrays (or sections) : we're starting to switch to just using bytes/string in OCaml 5+ now, since the larger allocations go into malloc'ed pools and do not relocate, so they can be used as part of an FFI (without the Bigarray C value overhead)

- More support for floating-point numbers (exceptions, representation exploration): OxCaml has some of this now! https://oxcaml.org/documentation/miscellaneous-extensions/sm...

- Syntax for extended BigArray indexing: now supported in OCaml https://ocaml.org/manual/5.4/indexops.html#ss:multiindexing

- LaCaml remains too low-level (non-functional) and unreadable: still remains the case, but OxCaml's got initial support for SIMD https://oxcaml.org/documentation/simd/intro

- BigArray and floating-point I/O remains difficult (we would like: I/O to channels, efficient representation retrieval): much easier now with OCaml effects to build custom fast serialisers (see https://github.com/ocaml-multicore/eio)

- Native top-level: ocamlnat is (I think) shipped in OxCaml, but you can also run a wasm toplevel

I must confess to also using agents to do most of my OxCaml annotations: https://github.com/avsm/ocaml-claude-marketplace/tree/main/p...

There's not that much downside since the annotations only change the performance characteristics of the program, and the static type system rejects inconsistent annotations.

Do you have a link to your talk? I'm also curious if you did any GHG measurements, or it was part of the control stack. We wrote the XenServer stack in OCaml back in 2004, and that made it into orbit in 2017 (I think it did, anyway: https://www.theregister.com/offbeat/2017/05/12/space-upstart...)

Yeah; all the really dangerous extensions are gated behind flags. But there's still a very significant number of optimisations available by default that just work well. I've taken to compiling my normal OCaml code with OxCaml these days to get a free speed boost (but buyer beware: the dependency management can be tricky; I have a giant monorepo to help out https://github.com/avsm/oxmono)

The TL;DR here (https://ccsds.org/Pubs/350x9g2.pdf) seems to be "AES GCM", but with lots of lots of legacy protocols due to older birds in the sky. DTLS or HTTP3 would seem to be a better choice these days...

The big win here is having a GC by default, with the ability to reduce heap allocations (via stack) just by adding in more typing annotations.

    Switching to OxCaml with exclave_ stack_ annotations drops 
    p99.9 latency from 29 ns to 9 ns per packet on the dispatch
    hot path, and removes GC pressure entirely (394 minor GCs to
    zero over 25 million packets). Throughput is comparable [...]

I got a similar result with my 'httpz' stack a few months ago (https://anil.recoil.org/notes/oxcaml-httpz) which my website's been running on without drama. And, I gotta say, OxCaml's a surprisingly robust compiler for being packed full of bleeding edge extensions: not a single crash on my infra is attributable to a compiler bug (plenty of bad OCaml code, but not due to a compilation bug)

The elephant in the room here is that there are hundreds of millions of embedded devices that cannot be upgraded easily and will be running vulnerable binaries essentially forever. This was a problem before of course, but the ease of chaining vulnerabilities takes the issue to a new level.

The only practical defense is for these frontier models to generate _beneficial_ attacks to innoculate older binaries by remote exploits. I dubbed these 'antibotty' networks in a speculative paper last year, but never thought things would move this fast! https://anil.recoil.org/papers/2025-internet-ecology.pdf

> If the write ups are any useful, it generally appears here or reddit and I often link back those discussions in the articles

Totally agree, I do the same as well on my site; e.g.: https://anil.recoil.org/notes/tessera-zarr-v3-layout

There are quite a few useful linkbacks:

- The social urls (bluesky, mastodon, twitter, linkedin, hn, lobsters etc) are just in my Yaml frontmatter as a key

- Then there's standard.site which is an ATProto registration that gets an article into that ecosystem https://standard-search.octet-stream.net

- And for longer articles I get a DOI from https://rogue-scholar.org (the above URL is also https://doi.org/10.59350/tk0er-ycs46) which gets it a bit more metadata.

On my TODO list is aggregating all the above into one static comment thread that I can render. Not sure it's worth the trouble beyond linking to each network as I'm currently doing, since there's rarely any cross-network conversations anyway.

From another comment below, it's just a nice short title to convey that we're going back in time and not one to set your watch by.

    We first submitted the article to the CACM a while ago.
    The review process takes some time and "Twelve years of
    Docker containers" didn't have quite the same vibe.

(The CACM reviewers helped improve our article quite a bit. The time spent there was worth it!)

It's not as easy; a block device has to be bootable and so usually bundles a kernel (large). And because the filesystem inside is opaque, you can't do layering like Docker does easily via overlayfs and friends. libguestfs does a heroic job of making VM images easier to manipulate from code, but it's an uphill battle...

cool! What services have you shipped as unikernels? Docker doesn't have to be an alternative; it can help with the build/run pipeline for them too: https://www.youtube.com/watch?v=CkfXHBb-M4A (Dockercon 2015!)

> but omission from the article stands out.

(article author here)

Apple containers are basically the same as how Docker for Mac works; I wrote about it here: https://anil.recoil.org/notes/apple-containerisation

Unfortunately Apple managed to omit the feature we all want that only they can implement: namespaces for native macOS!

Instead we got yet another embedded-Linux-VM which (imo) didn't really add much to the container ecosystem except a bunch of nice Swift libraries (such as the ext2 parsing library, which is very handy).

> I don't think SLIRP was originally for palm pilots, given it was released two years before.

That's a mistake indeed; "popularised by" might have been better. Before my beloved Palmpilot arrived one Christmas, I was only using SLIRP to ninja in Netscape and MUD sessions onto a dialup connection which wasn't a very mainstream use.

And those lightweight VM base images are possible because Docker applied a downward pressure on OS base image sizes! Alpine Linux doesn't get enough credit for this; in addition to being a great base image, it was also the first distro to prioritise fast and small image creation (Gentoo and Arch were small, but not fast to create).

Those are global to the machine; generally not an issue and seccomp rules can filter out undesirable syscalls to other containers. But GPU kernel/userspace driver matching has been a huge headache; see https://cacm.acm.org/research/a-decade-of-docker-containers/... in the article for how the CDI is (sort of) helping standardise this.

Thanks for the kind words! I've been prodding @justincormack to resurrect the single most fun OS unconference I've ever attended -- New Directions in Operating Systems (last held back in 2014). https://operatingsystems.io

Some of those talks strangely make more sense today (e.g. Rump Kernels or unikernels + coding agents seems like a really good combination, as the agent could search all the way through the kernel layers as well).