Back to FreeBSD – Part 2 – Jails

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.

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"

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.

I'll bite: how do we take advantage of ZFS layering if not via the docker-style layering?

I find dockerfile layering to be unsatisfying because step 5 might depend on step 2 but not 3 or 4... the linearisation of a DAG makes them harder to maintain and harder to cache cleanly (with us also having monster single-line CMDs all in the main of image results).

So is there a better way that people are using?

Failed to verify your browser

Code 11

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?

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.