The difference is that the container libc version and kernel version don't have to correspond to each other in any way on Linux (unless your kernel is like 20 years older, in which case it wouldn't support Docker anyway).
The end result is that you're matching the executable to the libc variant instead of to the kernel. In practice it's not much of a difference, if at all. If you need to use older binaries, install the compatibility shims (or use a base jail based on the older version of FreeBSD). In terms of a support matrix there are two major versions of FreeBSD that are given active support, which is less than over in Linux land.
All in all of all the concerns I'd have about using jails in a production environment, dealing with different major versions is not on that list.
In FreeBSD the userland and kernel move in unison, and with the backwards compatibility there's nothing stopping you from running a jail based on a previous version of FreeBSD. The compatX packages are only there to provide the older libraries if you want to run an older application on a newer jail/install.
As was pointed out, you can run binaries from a FreeBSD version (4) that's probably older than most posters here. Still not seeing what the big fuss is about.
the hangup is because half the point is to be able to take a random userland and run it on your current system without changing it. As soon as your userland bitrots because the kernel ABI changed, you've lost a lot of the benefit.
And to be clear, you can not take a complete userland from 4.x. You have to reinstall your application on a newer userland with compat shims when you change the kernel.
Ironically enough, the Linux syscall compat layer in FreeBSD may give you more stability here.
You have to reinstall your application on a newer userland with compat
shims when you change the kernel.
No, you don't. You can absolutely take a jail based on a previous version of FreeBSD and run it on a newer version. I've not tried going as far back as 4.x, but I've done jail images of 9 and 10 on 11 and 12 hosts as part of a CI system.
The shims you're talking about are not shims at all, just packages of the older libraries that a program built for an older version of FreeBSD would expect. You can go ahead and look at the package manifests if you don't believe me. They're literally just a handful of older shared libraries.
Honestly, I can't remember a time when the syscall table changed in a backwards incompatible manner. The compat packages are only needed if you're trying to run an older program with a newer userland. If you're running an older jail in a newer freebsd host, you can run your program as-is because those libraries have already been installed.
> If the kernel version differs from the one that the system utilities have been built with, for example, a kernel built from -CURRENT sources is installed on a -RELEASE system, many system status commands like ps(1) and vmstat(8) will not work. To fix this, recompile and install a world built with the same version of the source tree as the kernel. It is never a good idea to use a different version of the kernel than the rest of the operating system.
Just stop already, you don't know what you're talking about. ps works just fine. The jail itself picks up the version of the host because it's calling the newer kernel, but otherwise works as one would expect. In fact it's probably worth noting that between 10 and 12 the libc major version wasn't even bumped. For all the bellyaching you're missing that each major version is supported for five years, and that unlike RHEL you'll get up-to-date ports with that (instead of the half-assed cobbled together ancient versions that linger with the RHEL model) so there's less incentive to upgrade until you're ready. That's a lot of hand waving over a non fucking issue.
If you were making a more earnest argument you'd probably have looked at the current version of the documentation and noted that it doesn't have the warning you quoted.
Note that FreeBSD 10.0 was released in January 2014, over nine years ago. 10.4, which is the oldest base jail image I have kicking around, was released in 2017. So the userland-kernel interfaces you're wringing your hands over have remained stable for nearly a decade across three or four different major releases.
Of all the concerns I'd have about running FreeBSD and/or jails in a prod environment, dealing with binary compatibility across different major versions is not even on my radar and not even remotely an advantage for docker.
# uname -rv
12.4-RELEASE-p1 FreeBSD 12.4-RELEASE-p1 GENERIC
# ldd /bin/ps
/bin/ps:
libm.so.5 => /lib/libm.so.5 (0x800254000)
libkvm.so.7 => /lib/libkvm.so.7 (0x80028b000)
libjail.so.1 => /lib/libjail.so.1 (0x80029e000)
libxo.so.0 => /lib/libxo.so.0 (0x8002a6000)
libc.so.7 => /lib/libc.so.7 (0x8002c5000)
libelf.so.2 => /lib/libelf.so.2 (0x8006b9000)
libutil.so.9 => /lib/libutil.so.9 (0x8006d4000)
# md5sum /bin/ps
ad8b5c8966c71e31cdc9603967860fa7 /bin/ps
# objdump -p /lib/libc.so.7 | tail -12
Version definitions:
1 0x01 0x0865f4e7 libc.so.7
2 0x00 0x077a28b0 FBSD_1.0
3 0x00 0x077a28b1 FBSD_1.1
4 0x00 0x077a28b2 FBSD_1.2
5 0x00 0x077a28b3 FBSD_1.3
6 0x00 0x077a28b4 FBSD_1.4
7 0x00 0x077a28b5 FBSD_1.5
8 0x00 0x077a28b6 FBSD_1.6
9 0x00 0x0f1efaa0 FBSDprivate_1.0
# iocage create -r 10.4-RELEASE
e950694e-6182-410d-bc70-1a8f6e340516 successfully created!
# iocage start e950694e-6182-410d-bc70-1a8f6e340516
* Starting e950694e-6182-410d-bc70-1a8f6e340516
+ Started OK
+ Using devfs_ruleset: 1007 (iocage generated default)
+ Using IP options: ip4.saddrsel=1 ip4=new ip6.saddrsel=1 ip6=new
+ Starting services OK
+ Executing poststart OK
# iocage console e950694e-6182-410d-bc70-1a8f6e340516
FreeBSD 12.4-RELEASE-p1 GENERIC
Welcome to FreeBSD!
Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories: https://www.FreeBSD.org/security/
FreeBSD Handbook: https://www.FreeBSD.org/handbook/
FreeBSD FAQ: https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums: https://forums.FreeBSD.org/
Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with: pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.
Show the version of FreeBSD installed: freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages: man man
FreeBSD directory layout: man hier
Edit /etc/motd to change this login announcement.
# ldd /bin/ps
/bin/ps:
libm.so.5 => /lib/libm.so.5 (0x800827000)
libkvm.so.6 => /lib/libkvm.so.6 (0x800a50000)
libjail.so.1 => /lib/libjail.so.1 (0x800c59000)
libc.so.7 => /lib/libc.so.7 (0x800e5e000)
# objdump -p /lib/libc.so.7 | tail -16
Version definitions:
1 0x01 0x0865f4e7 libc.so.7
2 0x00 0x077a28b0 FBSD_1.0
3 0x00 0x077a28b1 FBSD_1.1
FBSD_1.0
4 0x00 0x077a28b2 FBSD_1.2
FBSD_1.1
5 0x00 0x077a28b3 FBSD_1.3
FBSD_1.2
6 0x00 0x077a28b4 FBSD_1.4
FBSD_1.3
7 0x00 0x077a28b5 FBSD_1.5
FBSD_1.4
8 0x00 0x0f1efaa0 FBSDprivate_1.0
FBSD_1.5
# md5 /bin/ps
MD5 (/bin/ps) = 8a9c364705d29beb98503415428067cc
# ps
PID TT STAT TIME COMMAND
80454 39 IJ 0:00.01 login [pam] (login)
80455 39 SJ 0:00.03 -csh (csh)
80593 39 R+J 0:00.00 ps
You are 100% factually right and I shared the same level of frustration as it seems you had with GP. I just wanted to 1) say thanks for sharing knowledge!, but also 2) suggest taking a deep breath or a walk before replying to folks like GP. I’m often guilty of it myself, but trying to get better.
The point at which it becomes clear (e.g. digging up outdated documentation) that the argument is not being made in earnest is the point at which I stop taking the poster seriously. My comment was meant more for anyone else who might stumble on this thread than as a reply to OP.
That said, I wouldn't look to run FreeBSD in a production environment without a good reason and 13 looks to be where I'll jump ship to Debian for homelab stuff. The big thing holding me back before was ZFS, but that's essentially a non-issue now.
