CentOS Project shifts focus to CentOS Stream

[Ron McLeod]

Looks like CentOS is changing direction - from being a stable binary-compatible RHEL distribution to leading-edge distribution which track Fedora.  I guess this is part of IBM's strategy after purchasing of RedHat earlier this year, wanting to eliminate CentOS as competition to their paid-for subscription-based RHEL.

CentOS Project shifts focus to CentOS Stream – Blog.CentOS.org

[Tim Holloway]

CentOS started out as an free spin of RHEL because not all of use felt the need to pay $500 to Red Hat for hand-held support. I did buy the pre-RHEL Linux releases, but they were much less expensive. Never called for support, though.

CentOS wasn't actually the only such product. I believe that Scientific Linux also did that, but gradually everyone settled on CentOS.

Then Red Hat acquired the CentOS project and I had misgivings, since it's almost inevitable that a commercial concern has different priorities than a mostly-volunteer team.

Then IBM acquired Red Hat, and I became concerned because IBM comes from an era where they had executive washrooms and Linus post-dates that sort of thing, And now, I think we're beginning to see the result.

I would not be surprised to see history repeat itself and a new independent RHEL-clone foundation gets formed. Since this is IBM, I don't expect RHEL to go closed-source as it likely would under, say, Oracle, and in the Linux world, problems tend to find solutions where they can.

[Peter Rooke]

a new independent RHEL-clone

Rocky Linux which is to be a red hat enterprise fork by the original creator of CentOS (Gregory M. Kurtzer).  This will of course surprise nobody outside of the IBM senior management folk

[Ron McLeod]

I like in the article where is says:
    Rocky Linux is a community enterprise Operating System designed to be 100% bug-for-bug compatible with Red Hat Enterprise Linux ...

[Ron McLeod]

CentOS replacement distro Rocky Linux’s first general release is out

Rocky Linux—one of at least two new distributions created to fill the void left when CentOS Linux was discontinued by parent corporation Red Hat—announced general availability of Rocky Linux 8.4 today. Rocky Linux 8.4 is binary-compatible with Red Hat Enterprise Linux 8.4, making it possible to run apps designed and tested only for RHEL without RHEL itself.

[Ron McLeod]

I'm testing Rocky Linux (RHEL 8.4 equivalent) in a dev environment and all is well.  The distribution includes Podman 3.X - a daemonless replacement for Docker which supports rootless pods/containers, and has good integration with systemd.

[Tim Holloway]

I've used Podman under Fedora and it's pretty decent. Although porting the results to actual Docker on my CentOS 7 servers was a problem. Mainly because the Docker "export" format drops key metadata (not a problem specific to PodMan).

[Ron McLeod]

Tim Holloway wrote:... Although porting the results to actual Docker on my CentOS 7 servers was a problem. Mainly because the Docker "export" format drops key metadata (not a problem specific to PodMan).

Out of interest, I did try move an image from Podman to Docker using podman save and docker load and it worked fine, but attempting to export a container from Podman and import into Docker failed.  I didn't bother to try and understand what the issue was since I won't be using Docker anyway; Podman + systemd fulfill my needs.

[Ron McLeod]

Tim Holloway wrote:... Although porting the results to actual Docker on my CentOS 7 servers was a problem. Mainly because the Docker "export" format drops key metadata (not a problem specific to PodMan).

Out of interest, I did try move an image from Podman to Docker using podman save and docker load and it worked fine, but attempting to export a container from Podman and import into Docker failed.  I didn't bother to try and understand what the issue was since I won't be using Docker anyway; Podman + systemd fulfill my needs.

[Tim Holloway]

As I said, it's not really a Podman/Docker problem. You'll enounter the same thing with Docker-to-Docker.

The "docker export" function exports the various layers of the image filesystem as a ZIP file (or was it tar?) But it doesn't include the dockerfile or any equivalent and there's critical information that's lost. IIRC you lose the image launch commands.

At any rate, once you do a Docker import from Podman, you have to manually edit things to make the imported image execute properly. Bleah.