@gnuplusmatt@adamw@Defolos@carlwgeorge Outside of needing certifications and everything that implies, CentOS Stream should suffice as an LTS distribution for the vast majority of users. And most people would prefer updates to be released as soon as they're qualified, rather than waiting for a minor version boundary that's potentially six months away. That particular quirk of Enterprise Linux is the result of needing to qualify stuff for certifications and other things.
@Conan_Kudo@gnuplusmatt@adamw@Defolos@carlwgeorge Most recently we've had issues with ELRepo not being fully compatible with CentOS Stream, but the same issues weren't seen with AlmaLinux. I think it's because CentOS Stream and RHEL kernels don't always line up.
@gnuplusmatt@passthejoe@Conan_Kudo@vwbusguy@adamw@Defolos@carlwgeorge From what I know, CS isn’t deployed in peod because for security updates, the flow is inverted. Which is fair, RH will provide these to their paying customers first, but this is one of the reasons some stay away from CS.
How often they patch is a different issue in and of itself :D
I have noted that my CS boxes are late to get some security updates compared to the RHEL advisories, this makes sense if they are this weird notion of "forward ports" coming from downstream.
A search seems to have some people claiming delays of months? That doesn't seem accurate to me.
@gnuplusmatt the delay is meant to be a small number of days at max (for embargoed security updates, AIUI) but has been longer in some cases due to general competence issues (not conspiracy). basically there isn't a clear system/mechanism for making sure the changes are landed in stream when they're meant to be landed in stream. this is one of the areas that's being prioritized internally as a result of all the feedback on the change.
@gnuplusmatt in general, one of the things we seem to be taking from the feedback is 'stream has several areas where it needs improvement'. which is great, I guess! Kinda wish it had happened earlier, but hey.
While you can force rpm to install a RHEL rpm package on SLES, it will most likely not even install cleanly, let alone run. Oracle Linux is an entirely different story, as it aims to be a 1:1 rebuild of RHEL.
Notably, Oracle does not claim to be a 1:1 rebuild (although they do stress "100% application binary compatible"). They use their own kernel and emphasize being the best Linux on which to run their own applications.
@vwbusguy@mattdm@Defolos@passthejoe@Conan_Kudo@gnuplusmatt@adamw@carlwgeorge OK, maybe my UNIX experience is too broad, going back to 1978 and having done professional work on every side of every schism in every generation of UNIX since then, including things like Regulus and Cromix that weren't based in any way on any UNIX code base and predated by years any attempt at a UNIX standard, but it does all seem a bit bikeshedding to me.
@resuna@mattdm@Defolos@passthejoe@Conan_Kudo@gnuplusmatt@adamw@carlwgeorge I don't agree with what is happening but I greatly respect @mattdm and will vouch for his character and do not read his comments this way. Having had to deal with Oracle Linux in production before, it's not always a drop in replacement. It is an entirely fair point, IMO.
If you're one of the few companies that actually needs to be running a RH family Linux, you're probably doing so because you need to run some industrial or scientific commercial application that only runs on a RH family Linux.
In which case the vendor you're buying the OS (and the servers or workstations that run it) for will tell you if they support SUSE or Oracle, and if they do then you don't need to care.
@Defolos@passthejoe@Conan_Kudo@vwbusguy@gnuplusmatt@adamw@carlwgeorge When I was at HP and Landmark the only Linux we supported were SLES and RHEL and the packages we shipped installed on both. Pretty much every commercial outfit that suppoted RHEL also supported SLES and later Oracle.
@resuna@passthejoe@Conan_Kudo@vwbusguy@gnuplusmatt@adamw@carlwgeorge Could be, but you shouldn't rely on SLES and RHEL being compatible. They might be mostly compatible, but there's enough naming differences, package version mismatches, configuration discrepancies, etc. that I really wouldn't rely on it.
@Defolos@passthejoe@Conan_Kudo@vwbusguy@gnuplusmatt@adamw@carlwgeorge We had customers we contractually guaranteed that we would continue to support SUSE as well as RHEL for some number of years, and since they were buying those computers specifically to run our software I don't see the risk.
Since 2016 though I have been working at a company where all our Linux is servers running debian-based Linux, by now mostly Docker, and the nightmare of RPM is fading.
@gnuplusmatt The closest you're going to get is openSUSE Leap. Which is mostly identical to SLE. (I don't actually know what the fundamental differences are on your basic install)
Add comment