NetBSD's jail feature is based on kauth, a decent designed capabilities system, informed by an Apple technical paper. Having jails backed by kauth puts NetBSD's well above FreeBSD's, if NetBSD can reach feature parity. The earlier implementation struggled with a networking feature that NetBSD did not have.
Also, this work is made with AI:
"For context: this is my first serious work inside the NetBSD kernel. I am not an experienced NetBSD kernel developer. To better understand complex code paths and trade-offs, I use AI-based tools for analysis and occasionally for draft implementations. However, everything that goes into my working tree is manually reviewed, adjusted, or discarded by me. I only integrate changes that I believe are technically sound and that I can explain and defend, and I am working towards a clean and auditable tree structure."
More like assisted with AI, in a way that seems perfectly reasonable.
It’s awesome to see Unix descendants still alive and active. NetBSD has been doing some really cool stuff lately, like PVH boot support.
Kudos to the SmolBSD team, a really fun project that made NetBSD PVH boot support, allowing it to boot a microVM on QEMU in ~10 ms https://smolbsd.org
I'm a little surprised; I guess I would have assumed that if netbsd got jails they'd be an outgrowth of rump kernels with improved security properties. No big deal, just unexpected.
> Jails share the host network stack by design.
> This keeps routing, firewalling, and interface management simple on the host.
> Listening ports can be reserved per jail.
> Port ownership is enforced by the kernel, preventing accidental conflicts while preserving a straightforward host-centric network model.
It's perfectly reasonable to have a different approach, but on Linux I'll say I really prefer that each container has its own view of ports; it is specifically useful that I can run multiple copies of the same app and they can all bind :8000 or whatever and that just works.
I'll make the same comment I did on the other post about this. Either document how it differs from FreeBSD jails or give it some other name. Anything else is asking for confusion.
It's not a port of FreeBSD jails ?
That some other name: 'cells' (or 'tiles'), in the compositional sense of leaf and tree, forest, framework is more inviting for creative work than 'jails'.
Does the third entry of the FAQ not suffice?
No. A feature table would help. An abstraction/layer diagram. A lot more.
Could bastille port to it as-is? How about podman?
> Could bastille port to it as-is? How about podman?
He wrote things like these are out of scope.
Just light and robust jails without further external dependencies.
so it's useless then as you can't run anything you'd want to there
Besides the fact it isn't even ready yet, of course you could run everything which runs on NetBSD in there. Just not the ways you're used to.
IMO anything which makes NetBSD's base more complete is good.
When it is ready, it remains to be seen which external tools may be ported to make use of the newly available internals. If ever.
Uh; not the same as FreeBSD jails? But name conflict? That's just silly.
"jail" is a generic term for any sort of isolation. I've heard a simple chroot called a "jail"
It would have been more interesting have they released something compatible with Open Container Initiative. Most people use Docker containers and having Docker compatible containers would have helped with improved adoption of BSDs.
No thanks. I prefer my jails just the way they are and think Docker sucks.
The OCI work mentioned upthread is about interface, not implementation.
Most people who think "Docker sucks" are talking about it's somewhat questionable network layer on Linux and the poor security isolation of the daemon. Non-docker alternatives like Podman don't have that characteristic.
But no one (at least no one reasonable) thinks Dockerfile's building docker images for download from docker-compatible repositories are a bad thing. That stuff runs the world. And the FreeBSD refusal to make a real attempt at interoperability is a confusing wart on what otherwise is pretty good tech.
I believe it’s a “bad thing” and prefer my FreeBSD + jails setup and installing my packages using the FreeBSD package manager.
Docker sucks and only exists because after all these years, Linux STILL doesn’t have a great way to handle third party applications.
Unlike FreeBSD, which has both the excellent ports and package systems.
FWIW I am not married to FreeBSD. I use Arch Linux as well.
> Docker sucks and only exists because after all these years, Linux STILL doesn’t have a great way to handle third party applications.
That's... not at all a correct characterization of where Docker found its purchase or what it's used for. Easy containerization dead-to-rights solved the version hell problem of shipping software at scale from vendors and upstreams that can't agree on dependency management. That's not something you can fiat away with "excellent ports and package systems" unless you imagine a world where literally every tiny microservice or cloud backend gadget ends up as a port in a single tree.
Basically you're saying "Docker sucks because I don't do anything that needs containers for anything but security". Well... yeah. I guess it would seem that way.
OCI is kinda layer above whatever solution is used for separation
I have used jails and I still say it is far easier to maintain, lighter and more secure that what Linux has. The only good thing I can say about docker is it is easier to setup.
Also the way I read the document, NetBSD's Jail is going to be very close to what FreeBSD does.
I’ve found Bastille really simple and great for creating and managing jails https://bastillebsd.org/
Zones from Solaris is a nice name.
NetBSD's jail feature is based on kauth, a decent designed capabilities system, informed by an Apple technical paper. Having jails backed by kauth puts NetBSD's well above FreeBSD's, if NetBSD can reach feature parity. The earlier implementation struggled with a networking feature that NetBSD did not have.
Also, this work is made with AI:
"For context: this is my first serious work inside the NetBSD kernel. I am not an experienced NetBSD kernel developer. To better understand complex code paths and trade-offs, I use AI-based tools for analysis and occasionally for draft implementations. However, everything that goes into my working tree is manually reviewed, adjusted, or discarded by me. I only integrate changes that I believe are technically sound and that I can explain and defend, and I am working towards a clean and auditable tree structure."
https://mail-index.netbsd.org/tech-kern/2026/03/01/msg030854...
> Also, this work is made with AI:
More like assisted with AI, in a way that seems perfectly reasonable.
It’s awesome to see Unix descendants still alive and active. NetBSD has been doing some really cool stuff lately, like PVH boot support. Kudos to the SmolBSD team, a really fun project that made NetBSD PVH boot support, allowing it to boot a microVM on QEMU in ~10 ms https://smolbsd.org
I'm a little surprised; I guess I would have assumed that if netbsd got jails they'd be an outgrowth of rump kernels with improved security properties. No big deal, just unexpected.
> Jails share the host network stack by design.
> This keeps routing, firewalling, and interface management simple on the host.
> Listening ports can be reserved per jail.
> Port ownership is enforced by the kernel, preventing accidental conflicts while preserving a straightforward host-centric network model.
It's perfectly reasonable to have a different approach, but on Linux I'll say I really prefer that each container has its own view of ports; it is specifically useful that I can run multiple copies of the same app and they can all bind :8000 or whatever and that just works.
I'll make the same comment I did on the other post about this. Either document how it differs from FreeBSD jails or give it some other name. Anything else is asking for confusion.
It's not a port of FreeBSD jails ?
That some other name: 'cells' (or 'tiles'), in the compositional sense of leaf and tree, forest, framework is more inviting for creative work than 'jails'.
Does the third entry of the FAQ not suffice?
No. A feature table would help. An abstraction/layer diagram. A lot more.
Could bastille port to it as-is? How about podman?
> Could bastille port to it as-is? How about podman?
He wrote things like these are out of scope.
Just light and robust jails without further external dependencies.
so it's useless then as you can't run anything you'd want to there
Besides the fact it isn't even ready yet, of course you could run everything which runs on NetBSD in there. Just not the ways you're used to.
IMO anything which makes NetBSD's base more complete is good.
When it is ready, it remains to be seen which external tools may be ported to make use of the newly available internals. If ever.
Uh; not the same as FreeBSD jails? But name conflict? That's just silly.
"jail" is a generic term for any sort of isolation. I've heard a simple chroot called a "jail"
It would have been more interesting have they released something compatible with Open Container Initiative. Most people use Docker containers and having Docker compatible containers would have helped with improved adoption of BSDs.
No thanks. I prefer my jails just the way they are and think Docker sucks.
The OCI work mentioned upthread is about interface, not implementation.
Most people who think "Docker sucks" are talking about it's somewhat questionable network layer on Linux and the poor security isolation of the daemon. Non-docker alternatives like Podman don't have that characteristic.
But no one (at least no one reasonable) thinks Dockerfile's building docker images for download from docker-compatible repositories are a bad thing. That stuff runs the world. And the FreeBSD refusal to make a real attempt at interoperability is a confusing wart on what otherwise is pretty good tech.
I believe it’s a “bad thing” and prefer my FreeBSD + jails setup and installing my packages using the FreeBSD package manager.
Docker sucks and only exists because after all these years, Linux STILL doesn’t have a great way to handle third party applications.
Unlike FreeBSD, which has both the excellent ports and package systems.
FWIW I am not married to FreeBSD. I use Arch Linux as well.
> Docker sucks and only exists because after all these years, Linux STILL doesn’t have a great way to handle third party applications.
That's... not at all a correct characterization of where Docker found its purchase or what it's used for. Easy containerization dead-to-rights solved the version hell problem of shipping software at scale from vendors and upstreams that can't agree on dependency management. That's not something you can fiat away with "excellent ports and package systems" unless you imagine a world where literally every tiny microservice or cloud backend gadget ends up as a port in a single tree.
Basically you're saying "Docker sucks because I don't do anything that needs containers for anything but security". Well... yeah. I guess it would seem that way.
OCI is kinda layer above whatever solution is used for separation
I have used jails and I still say it is far easier to maintain, lighter and more secure that what Linux has. The only good thing I can say about docker is it is easier to setup.
Also the way I read the document, NetBSD's Jail is going to be very close to what FreeBSD does.
I’ve found Bastille really simple and great for creating and managing jails https://bastillebsd.org/