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 <[email protected]> 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 --all
should 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
