Hello Greg, thanks for the reply and for following up on this - I really appreciate it. On 3/9/26 23:12, Greg Troxel wrote:
Matthias Petermann <matthias%d2ux.net@localhost> writes:Based on community feedback and a small naming poll, the prototype will move forward under the name “Cells for NetBSD”. The goal and architecture remain unchanged — the rename mainly helps to avoid confusion with FreeBSD Jails and to emphasize that this is intended as a NetBSD-native approach.(Dropping netbsd-users@ as I do not like to send to multiple lists at once.) I was going to ask, and never got around to: How is this different than FreeBSD jails? If so, why? Is something wrong with FreeBSD jails?
The short answer is that it depends on the level you look at it from. The overall goal is similar, but the design differs at several layers.
To your second question: there is absolutely nothing wrong with FreeBSD jails - quite the opposite. They are an excellent and very mature system, but...
From your page, it sounds like you are doing essentially the same thing -- which makes sense. But with renaming, apparently you aren't. I'm trying to figure out if this is just different to be different, or if there is a reason to do other than implement what FreeBSD did and use their code.
...NetBSD already has very solid groundwork in the form of the secmodel framework and kauth. These provide a fairly central decision point for many security-relevant operations. My prototype tries to build on that and enforce isolation policies primarily through those hooks.
FreeBSD has something somewhat analogous with MAC, but from what I have read the jail implementation itself tends to hook directly into many different decision paths throughout the kernel. A FreeBSD developer could certainly explain that better or correct me if I am misunderstanding parts of it. For my own work it simply felt architecturally cleaner to lean on the existing secmodel/kauth infrastructure that NetBSD already provides.
The userland tools for Cells grew out of a slightly different motivation as well. I work professionally in environments where DevOps-style operational workflows are common, so I tried to design the tooling around a very straightforward "out-of-the-box" experience. The layered control plane design is intentional, so that higher-level orchestration tools can be built on top later.
The idea is that a minimal workflow like # cellmgr bootstrap # cellmgr create ... # cellmgr start --allshould already leave you with a production ready service environment derived directly from the base system. So in that sense the userland side is deliberately its own design rather than trying to mirror FreeBSD’s jail tooling or configuration formats.
Your question actually touches on the reason for the rename as well. The term "jails" carries fairly strong associations with the FreeBSD implementation. Depending on who you ask, it may refer either to the basic kernel isolation mechanism or to the entire stack including the surrounding tooling.
That led to expectations that things like configuration formats, command-line interfaces, or runtime behavior would match the FreeBSD model closely. I understand and respect that expectation - if someone had mentioned "jails" to me a few months ago, I would also have immediately thought of FreeBSD.
In that sense the term functions almost like a brand name in the BSD world. Realizing that, it seemed better to rename the project early rather than keep having the same discussion about expectations.
The new name "Cells" came out of that discussion. It was originally suggested by a member of the FreeBSD community and later won a small naming poll I ran on Mastodon. And I must say, it has grown on me.
Best regards Matthias