The jails vs containers framing is interesting but I think it misses why Docker actually won. It wasn't the isolation tech. It was the ecosystem: Dockerfiles as executable documentation, a public registry, and compose for local dev. You could pull an image and have something running in 30 seconds without understanding anything about cgroups or namespaces.
FreeBSD jails were technically solid years before Docker existed, but the onboarding story was rough. You needed to understand the FreeBSD base system first. Docker let you skip all of that.
That said, I've been seeing more people question the container stack complexity recently. Especially for smaller deployments where a jail or even a plain VM with good config management would be simpler and more debuggable. The pendulum might be swinging back a bit for certain use cases.
Jails were never going to 'win' because they're only on an OS with 0.1% marketshare.
But it's not a competition. FreeBSD does its thing and Linux does another. That's why I use FreeBSD.
What is your use case for BSD?
I love several things about it:
- Stable OS coupled with rolling packages. I am on the previous FreeBSD version (14.3-RELEASE, while 15 is out) but I have the very latest KDE.
- A ports collection where you can recompile packages whenever you're not happy with the default settings. Strict separation between packages and core OS. Everything that is from packages is in /usr/local (and this separation is also what makes the above point possible).
- ZFS on root as first-class citizen. Really great. It has some really nice side tooling too like sanoid/syncoid and bectl (the latter is part of the core OS even).
- jails for isolation (I don't really use it like docker for portability and trying things out)
- Clear documentation because there are no different distros. Very good handbook. I like the rc.conf idea.
- Common sense mentality, not constantly trying to reinvent the wheel. I don't have to learn a new init system and I can still use ifconfig. Things just work without constantly being poked around.
- Not much corporate messing around with the OS. Most of the linux patches come from big tech now and are often related to their goals (e.g. cloud compatibility). I don't care about those things and I prefer something developed by and for users, not corporate suits. No corporates trying to push their IP onto the users (e.g. canonical with their Mir, snaps etc)
- Not the same thing as everyone else has. I'm not a team player, I hate going with the flow. I accept that sometimes comes with stuff to figure out or work around.
I think that's about it.
ZFS boot+root on Linux is amazing as well. It's kind of sad to see Linux Mint has moved away from supporting this in their installer, but it probably could still be done manually I guess. After upgrade, if something goes wrong? zfs rollback both to a snapshot made just before the upgrade and reboot.
I don't use freebsd full time, only in a VM, but all these things sound positive to me.
*everything. I've really been using it since 4.x. Imagine this: being able to upgrade a system in-place with freebsd-update from minor to major to minor version without everything breaking or having to say a prayer before. And that's just one thing I love about it. Clear separation of userland (/usr/local/etc), rock-solid stability in networking, zfs on root.
I had to do 'bonded' interfaces on Debian the other day. It's what, 5 different config files depending on which 'network manager' you use. In FreeBSD it's 5 lines in /etc/rc.conf and you're done.
And don't even get me started on betting which distribution (ahem CentOS) will go away next.
Centos didn’t go away. It changed. Rocky (et. al.) took the old centos role, and I see this as a win/win for everybody.
Ubuntu is the disaster Linux distro, I won’t touch Ubuntu if I have any other option.
I actually laughed out loud. Try upgrading CentOS to Rocky vs FreeBSD 11 to 15 ( that's FOUR major versions from 2017 I think ), and tell me again how good it is.
In LTS environments where I need to upgrade OS's, FreeBSD is a no-brainer.
> I actually laughed out loud. Try upgrading CentOS to Rocky vs FreeBSD 11 to 15 ( that's FOUR major versions from 2017 I think ), and tell me again how good it is.
I laughed out loud, there is no in-place upgrade mechanism for that in those distros and never has been, that is the nature of those distros. They release patch/security updates until they go EOL, which is measured in units closer to decades than years.
I don’t have a problem with BSDs. That’s cool you like upgrading in place.
The best and most laugh-inducing part of your whole point is that centos now not only allows you to do in-place upgrades, that’s the whole fucking point.
So then what's the point of mentioning Rocky as CentOS's successor ? In what way is it 'succeeding' ? That you can do a fresh install of Rocky ? And those stuck on CentOS can't upgrade ? Really useful those decades of support if your distro goes belly up
You don’t know this ecosystem, clearly. I’m not going to explain it to you much more than I did.
Centos was the free version of red hat. Like redhat, centos never fucking ever offered in-place upgrades. Centos moved to stream as a sandbox for redhat, and rocky took over as the free redhat.
Ask an LLM or something, this level of ignorance is unbecoming.
> the container stack complexity
I'm using either Docker Compose or Docker Swarm without Kubernetes, and there's not that much of it, to be honest. My "ingress" is just an Apache2 container that's bound to 80/443 and my storage is either volumes or bind mounts, with no need for more complexity there.
> The jails vs containers framing is interesting but I think it misses why Docker actually won. It wasn't the isolation tech. It was the ecosystem: Dockerfiles as executable documentation, a public registry, and compose for local dev. You could pull an image and have something running in 30 seconds without understanding anything about cgroups or namespaces.
So where's Jailsfiles? Where's Jail Hub (maybe naming needs a bit of work)? Where's Jail Desktop or Jail Compose or Jail Swarm or Jailbernetes?
It feels like either the people behind the various BSDs don't care much for what allowed Docker to win, or they're unable to compete with it, which is a shame, because it'd probably be somewhere between a single and double digit percent userbase growth if they decided to do it and got it right. They already have some of the foundational tech, so why not the UX and the rest of it?
I think Jails started as a tool of it's time, it's about the same thing as virtualization in making isolated systems when dependencies start to diverge, but aimed at the issues of sysadmins that had to manage their own systems, not a quick developer experience.
Even if "jailsfiles" were created the ecosystem would need to start from scratch and sometimes it feels like people in the FreeBSD ecosystem have a hard enough time keeping ports somewhat up to date, let alone create something new.
Luckily Podman seems to support FreeBSD these days for docker images, but the Linux emualation might be a bit of a blocker so not a 100% solution.
> I'm using either Docker Compose or Docker Swarm without Kubernetes, and there's not that much of it, to be honest.
On the outside. But that's a lot of complexity hidden from view there, easily a couple of million lines of code on top of the code that you wrote.
I never used this, but noticed it in some docs back when I was using Nomad and thought it was an intriguing idea: https://github.com/cneira/jail-task-driver
Docker's client/server design also allowed for things like Docker Desktop, which made the integration seamless with non-linux systems. Jails have nothing like that, so the only system that will ever run jails is FreeBSD. Also, I'm not up to speed enough to know, but do jails even have a concept of container images?
It’s just files on the filesystem. So tar for imaging?
Plus a script to unpack the tarball somewhere and launch some entry point in a jail. Not conceptually hard, but the OCI spec has a bit more to it than that, and now we're into "write dropbox with rsync" territory...
I did some looking around, and I see that ocijail is a thing, so that's probably what I was looking for.
(edited, sorry, I didn't see your reply)
What do you mean”launch an entry point”? The rc script would naturally be included.
I don't think article misses it, it's exactly the point it makes
> Jails solve the isolation problem beautifully, but they don't have a native answer to shipping. That gap is real, and it's one of the main reasons the ecosystem around jails feels underdeveloped compared to Docker's world.
The link literally uses the term ecosystem. Several times actually.
You can also run Linux containers on FreeBSD
https://youtu.be/HV-wUUzRCMo
I've tried this ... I've haven't got much mileage on this, sadly.
Many Linux syscalls are unemulated and things like /proc/<pid>/fd/NN etc are not "magic symlinks" like on Linux so execve on them fails (i.e there is rudimentary /proc support, it's not full fleshed out).
TL;DR Linux containers on FreeBSD via the podman + linuxulator feel half baked.
For example, try using the alpine container... `apk upgrade` will fail due to the /proc issue discussed above. Try using the Fedora container `dnf upgrade` will fail due to some seccomp issue.
The future of containers on FreeBSD is FreeBSD OCI containers, not (emulated) Linux containers. As an aside, podman on FreeBSD requires sudo which kinda defeats the concept but hopefully this will be fixed in the future.
Maybe FreeBSD doesn't want a jails "ecosystem"?
> You could pull an image and have something running in 30 seconds without understanding anything
Fixed that for you ;)