My impression is that it did not get into latest Ubuntu, they were in the process of trying though.
The end goal seems to have been to get it into the LTS releases of rhel and Ubuntu. Since this was a valuable it's probably something kept around for when other methods fail. I doubt it would be used before the really valuable systems are compromised (rhel and Ubuntu in cloud and governments)
They were probably running RHEL5, but even in 2014 they would have been in the Production 3 phase which is really should only be used for legacy purposes, and that's definitely not the sort of system you push new software to. Red Hat even pushes those customers towards virtualization because a) hardware rarely lasts 7 years and b) they won't bother backporting drivers for new hardware to the old kernel at that point.
I still use a few RHEL5 machines but nobody would ever dream of pushing new software to them.
Partly it is, but there wasn't much hope to convert those to RHEL. The plan was:
1) to offload the production of the releases (effectively what is now Alma Linux). Because there's so much use of CentOS, it was pretty much a given that somebody would pick up the slack. Most of those companies weren't running stock CentOS anymore, they had their own downstream repositories
2) to give more insight into the making of RHEL minor release to CentOS SIGs and to companies that run CentOS derivatives
Facebook for example does not use the RHEL kernel and was one of the early adopters of CentOS Stream even before CentOS Linux 8 was terminated.
RHEL 7 came out 6 years ago with Linux 3.10 and is still getting patched. Somebody has to manage and integrate all those security fixes in all those packages without breaking the old codebases.
The primary point the author makes is that this version of Ubuntu LTS has a kernel and init system that only it is going to be supporting for most of the lifetime of the release. Bringing up RHEL's use of kernel versions no longer supported upstream isn't really relevant - RHEL has a proven track record of supporting a kernel with patches and backports single-handedly.
Nope, it wouldn't have been in RHEL 10 or any of the rebuilds. CentOS Stream 10 already branched from Fedora / ELN. The closest it would have gotten is a Fedora ELN compose, and it's doubtful it would have remained undiscovered long enough to end up in CentOS Stream 11.
I wouldn't count on it unless you add some extra repo. RHEL releases are historically behind when it comes to software, which is claimed to provide more stability, but often older kernels in RHEL simply will not support the new underlying functionality. I am hopeful that if Podman ever has to make the decision to adapt at a modern pace with new software releases, or constantly try to backport fixes and code for old software, that they'll choose the modern approach.
I know nothing about the reasons it was dropped (apart from what I've read on HN, ironically) but keep in mind this was years ago, when it was still deeply, deeply troubled and there was a lot of churn going on. "Churn" and "stable" kernels like RHEL don't mix well.
An LTS distribution based on Fedora (and NOT RHEL) is something I've been wanting for a long time, but I don't think this is really gonna be for the non-cloud general use case?
The end goal seems to have been to get it into the LTS releases of rhel and Ubuntu. Since this was a valuable it's probably something kept around for when other methods fail. I doubt it would be used before the really valuable systems are compromised (rhel and Ubuntu in cloud and governments)
reply