4 ms·

Kernels are generally backwards compatible and major versions are explicitly supported for five (5) years. Over in Linux land you'll see builds for the differe

Kernels are generally backwards compatible and major versions are explicitly supported for five (5) years. Over in Linux land you'll see builds for the different libcs and it seems to work just fine.

johncolanduoni 3y ago
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).
- inferiorhuman 3y ago
  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.
  - monocasa 3y ago
    But the half the point of the container is per application libcs/userlands, so the kernel ABI is the only required constant.
    - inferiorhuman 3y ago
      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.
      - monocasa 3y ago
        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.
        inferiorhuman 3y ago
        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.
        monocasa 3y ago
        > The kernel works, but ps(1) does not > 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. https://web.archive.org/web/20180602150408/https://www.freebsd.org/doc/handbook/kernelconfig-trouble.html https://web.archive.org/web/20180602150408/https://www.freeb... It certainly seems like the freebsd userland and kernel are fairly tightly coupled where even basic utilities won't work anymore on a version change.
- bandrami 3y ago
  I thought that too, until the syscall semantics changed between RHEL 6 and RHEL 7. Spent way more time debugging that than I wanted to.

Kernels are generally backwards compatible and major versions are explicitly supported for five (5) years. Over in Linux land you'll see builds for the different libcs and it seems to work just fine.

johncolanduoni 3y ago

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).

inferiorhuman 3y ago
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.
- monocasa 3y ago
  But the half the point of the container is per application libcs/userlands, so the kernel ABI is the only required constant.
  - inferiorhuman 3y ago
    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.
    - monocasa 3y ago
      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.
      - inferiorhuman 3y ago
        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.
        monocasa 3y ago
        > The kernel works, but ps(1) does not > 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. https://web.archive.org/web/20180602150408/https://www.freebsd.org/doc/handbook/kernelconfig-trouble.html https://web.archive.org/web/20180602150408/https://www.freeb... It certainly seems like the freebsd userland and kernel are fairly tightly coupled where even basic utilities won't work anymore on a version change.
bandrami 3y ago
I thought that too, until the syscall semantics changed between RHEL 6 and RHEL 7. Spent way more time debugging that than I wanted to.