I think they understate the importance of accepting OCI and Dockerfile semantics as a path to an external "run one of these" and having it actually emerge as a jail based outcome.<p>I get saying "we don't need these additional layers/abstractions" but what it ignores is me saying "I want to run this code, and what I have is a suite of Docker based behaviour and I want a low friction path to use that Docker compose method, to get where I want"<p>They also haven't yet addressed how things re-scale sideways. Pods, and scaling is why people wind up behind traefik or caddy, fronting a service. It's not because the service lies in RFC1918 (how I wish they had written kubernetes to V6 native) it's because the service is being delivered by multiple discrete runtime states "inside" and scales horizontally.
The main drawback I saw on jails is that they are FreeBSD. The owner doesn’t mention, and I have not researched it, but can you run any Linux distribution in a FreeBSD jail?
FreeBSD has supported Linux emulation for a long time (<a href="https://docs.freebsd.org/en/books/handbook/linuxemu/" rel="nofollow">https://docs.freebsd.org/en/books/handbook/linuxemu/</a>). The emulation is at the syscall level but enough to run most apps.
There is a significant investment in a linux compatible system call layer, and a linux compatible runtime link library suite.<p>It isn't a complete answer, but the position as I understand it (haven't had to care for a long time) is that a LOT of linux binaries can work.
I believe you are asking about bhyve for running Linux on FreeBSD. Jails are for software isolation.
I would like to explore the interoperability/compatibility limits of LXC and OCI support in FreeBSD 15. Both with FreeBSD as an OCI container and Linux OCI containers within FreeBSD.