The way you describe it, it seems that SUSE is equivalent to CentOS Stream.
The discrepancy between RHEL and CentOS Stream comes from the fact that RHEL has multiple additional branches one for each minor releases.
Thus on RH side, when you bring the patches from branched minor releases of RHEL to the RHEL mainline, which is the CentOS stream, they may get rearranged.
@bookwar As I understand it, it's a little backwards from RHEL/CS. OpenSUSE Leap gets the minor versions where SUSE calls them service packs, so OpenSUSE Leap 15.5 == SLES 15 SP5 and they have different repository targets between the minor versions. They both pull from the same "factory".
@bookwar 15.6 isn't out yet. 15.4 is still supported. On Leap, you zypper dup to update to the new minor version. It's an intentional thing. OpenSUSE Tumbleweed, however, is the one that doesn't have those version distinctions and you just do a regular system update to stay up to date.
@bookwar There are a number of nuanced differences between the Red Hat and SUSE release models, so saying one is the equivalent to Stream doesn't quite fit.
Leap in some ways is like CS and in some ways is more like CentOS Linux. OpenSUSE is both upstream and downstream of SLES, but built from the same (public) factory sources.
@bookwar Also, trust anything @Conan_Kudo tells you over what I'm saying. I'm about one week into this and not at all a definitive source. This is my current understanding of how it works.
@vwbusguy@bookwar There is a 6 month overlapping support period between minor versions. So now that 15.5 is out, 15.4 will be supported until December.
SLE support periods for a service pack are not mimicked in openSUSE Leap.
@Conan_Kudo@bookwar That's a very helpful clarification. Do patches to SLES after Leap goes EOL still make it back to factory?
Honestly, I kind of like this - stay on top of your lifecycle management or pay the #SLES tax 😂, but would still love to know that the sources for those patches still come back for the sake of being an #opensource community player, even if they don't get a binary release in Leap. I assume that's a yes based on the BCI stuff I looked at yesterday.
@bookwar@Conan_Kudo Again, it isn't and it isn't. Leap and CS don't exactly overlap. Backports hit Leap's source tree first, but the actual Leap release itself is identical to SLES (except for branding), not maybe-future-SLES.
@bookwar@Conan_Kudo And AFAIK, you can't linger on a minor version point and still get any updates with CentOS, especially now with Stream since there are no minor versions, but this was also true for CentOS 7. You can still get updates for OpenSUSE Leap 15.4 right now even though 15.5 is out.
@bookwar@Conan_Kudo For the record, I'm not telling you or anyone else to run SUSE instead. My org is now adding it as a supported platform and so I'm now here learning it. The decision point on whether or not to just stick with RHEL and similar has largely passed, but what workloads will get migrated or freshly deployed is still getting worked out. I imagine stuff that has no reason to be migrated won't be migrated, but newer stuff or fresh redeployments might be a different story.
@vwbusguy@bookwar@Conan_Kudo And that's the way our market should work. Depending on your needs and requirements you can chose between different solutions. If we at Red Hat miss your expectations but SUSE does, you switch. That's just the way it should work.
@jwildeboer@bookwar@Conan_Kudo To be clear, it wasn't my decision and I'm not asking anyone to change my mind and I'm not trying to change anyone else's. I (now-awkwardly) posted this to make a point before it came down that we're going to pick up SUSE support and now I'm more focused on actually learning SUSE than comparing it to RHEL.
@jwildeboer@bookwar@Conan_Kudo To be clear, I don't want Red Hat to fail and lose business. I'm concerned that this decision is not one that is good for Red Hat, its most loyal customers, or the broader open source community. I would much rather see Red Hat's reputation restored and its general sales to continue to do well as a result.
@jwildeboer@bookwar@Conan_Kudo In short, I want #RedHat to still be the company that sold me on their vision decades ago. This move and messaging are at odds with your generally great record and history - a history that includes moments of humility, owning mistakes, and doing better for the sake of the broader community. A great example: Merging Core and Extras in Fedora and giving leadership over to the community. A move that has literally paid off well for Red Hat and RHEL.
The landscape today is dramatically different. The competition is different. Expecting an unchanging strategy from Red Hat no matter what the market and its competitors do is not fair or reasonable.
@jzb@jwildeboer@bookwar@Conan_Kudo It's the apparent changing of values that is difficult to process. A dissonance of "what I thought the company was about" versus what it appears to be saying and doing now, and admittedly wanting and not finding the latter to not be true.
@jzb@jwildeboer@bookwar@Conan_Kudo As you yourself pointed out, Red Hat has always had commercial downstreams. What is so dramatically new this time around? Is anything happening now more of an egregious threat than Oracle Linux (who isn't apparently impacted by this)?
Computing models have changed dramatically since 2014. Less on-prem, more cloud, more by the hour and all that.
Increasing number of companies willing to "risk" a clone due to perceived stability / identical bits to RHEL. They want RHEL, don't want to pay, and increasingly feel clones are "good enough."
It gets more expensive to make + support RHEL every year. (e.g. costs go up, what's included goes up.)
Red Hat is held to a higher standard but other companies get more kudos for doing less with open source. Survey the Fortune 500 and ask which companies do more, you'd be surprised what you find.
Today's announcement of a 4-year ELS for RHEL 7 might be a hint. A lot of EL7 organizations trying to chart a path forward after EL7, Red Hat doesn't want Rocky or Alma as attractive options.
@jzb@jwildeboer@bookwar@Conan_Kudo I didn't expect "ELevate works too well" to be a factor behind this, especially when you can also use it to upgrade RHEL, IIRC. I definitely had better luck with Alma's tool than leapp directly from Red Hat.
I agree, instead of providing a continuous flow you get the ladder with steps which slightly overlap.
But principle is the same.
Mainline is open, minor branches - under subscription.
And you have choices - either not care and simply update when you like it (which is a lot of CentOS Linux users did jumping from one step to the other) or care and then setup an upgrade process properly with tests and gates.
@bookwar@Conan_Kudo Again, OpenSUSE Leap has concurrent, supported minor versions and CentOS Stream does not. If you blur it up enough you can get to some semblance but you're losing significant technical nuance in the process. Might be better to think of Open/SUSE more on its own terms instead of comparing everything to Red Hat as it is a different beast. Like, the minor versions generally land a year apart rather than 3 months.
That's how I ended my talk on CentOS stream as well :)
For any new thing we learn we tend to map it on the closest object we know. Which is helpful to build some additional understanding, but may also be misleading.
I think I understand the "ladder part" on the SUSE side now. So thanks for the explanation.
@vwbusguy@bookwar@Conan_Kudo "maybe-future" is IMHO an overstatement for CentOS Stream. Builds that get into Stream are ready for production, nothing like "we push it to Stream and will see if it's going to stick". I don't remember from top of my head if we've ever changed a component after Stream and before next RHEL. It may happen, but it's rather rare.
@sesivany@bookwar@Conan_Kudo "It may happen" is part of your answer to why many others have preferred the rebuilds. I'm using Stream, RHEL, and AlmaLinux all in my dayjob. In fairness, even when we have plenty of RHEL seats, AlmaLinux is often picked just so we don't have to deal with RHSM 😅.
@vwbusguy@bookwar@Conan_Kudo yeah, I know. I once got 18k RHEL subscriptions for Brno University of Technology. They had been using CentOS and even though they had all those subscriptions except for a few critical servers they kept using it because they didn't want to deal with the subscription manager.
@bookwar@sesivany@Conan_Kudo I'll grant you that, but it's still more work than not having to deal with it at all. I had Ansible playbooks that ran through all our RHEL hosts to try to detect and fix various RHSM problems at our last job, like a terrible game of whack-a-mole. (And I've frankly still had quirks with RHEL9.)
@vwbusguy Thats true. I think RedHat is probably more targeting Oracle Linux for profiting off their work and contributing nothing back with Alma and Rocky getting caught in the crossfire.
@keyboardg Oddly enough, Oracle Linux appears to not be affected and AlmaLinux and Rocky might be pulling from public Oracle Linux sources. Amazing day when #Oracle upstages #RedHat for being a better #opensource#Linux community player.
Add comment