Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


RHEL is closing down the distribution of CentOS Stream source code - Page 3
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

RHEL is closing down the distribution of CentOS Stream source code

13

Comments

  • raindog308raindog308 Administrator, Veteran

    "Finally, to IBM, here’s a big idea for you. You say that you don’t want to pay all those RHEL developers? Here’s how you can save money: just pull from us. Become a downstream distributor of Oracle Linux."

    LOL

    Thanked by 2steny varwww
  • MechanicWebMechanicWeb Member, Patron Provider

    @raindog308 said: "Finally, to IBM, here’s a big idea for you. You say that you don’t want to pay all those RHEL developers? Here’s how you can save money: just pull from us. Become a downstream distributor of Oracle Linux."

    LOL

    Oracle's whole statement seems like a marketing stunt. They didn't mention the elephant in the room even once, that is, RHEL's largest target is Oracle itlself, not Alma or Rocky.

    And so much for serving communities. None of them would care if there wasn't big bucks involved with contracts.

  • spareksparek Member

    @emgh said:

    @omelas said: not sure at move to Debian/Ubuntu reaction. doesn't centos stream still support 5 year, just like ubt and Debian does?

    https://www.redhat.com/en/resources/centos-stream-checklist

    "CentOS Stream may seem like a natural choice to replace CentOS Linux, but it is not designed for production use."

    A Debian or Ubuntu variant with a 10 year life cycle is essentially what is missing. I know you can get Ubuntu Pro for 10 years of support - but you have to pay for it. And if you're going to pay for 10 years of support, you might as well pay RHEL.

    The web hosting industry - which I'll admit is not the only industry for an Enterprise Linux - really doesn't need commercial support, there's enough community support to carry it on. But the web hosting industry does need about a 10 year life cycle.

    I don't know about everyone else, but for me with CentOS, I generally avoided new versions of CentOS for a year or two, in order for any bugs or issues to be identified and resolved. Then about 2 or 3 years before that version of CentOS went end of life, I would start to migrate servers to the new servers with the new version of CentOS. A 10 year life cycle worked perfectly for this.

    With a 5 year life cycle, say you wait a year to allow for bugs and issues to get worked out, then you get 2 years of life before you have to start looking at upgrading or migrating to a newer version of Debian. That just doesn't work in an industry that needs a bit more stability.

  • varwwwvarwww Member

    SUSE statement https://www.suse.com/news/SUSE-Preserves-Choice-in-Enterprise-Linux/

    TL;DR SUSE is forking RHEL. Plans to invest more than $10 million into this project.
    SUSE plans on contributing their RHEL-forked project to an open-source foundation and to ensure ongoing free access to this alternative source code.

  • raindog308raindog308 Administrator, Veteran

    @varwww said:
    SUSE statement https://www.suse.com/news/SUSE-Preserves-Choice-in-Enterprise-Linux/

    TL;DR SUSE is forking RHEL. Plans to invest more than $10 million into this project.
    SUSE plans on contributing their RHEL-forked project to an open-source foundation and to ensure ongoing free access to this alternative source code.

    So they're saying people should use that instead of SUSE Linux Enterprise Server? 🤔

  • varwwwvarwww Member

    @raindog308 said:

    @varwww said:
    SUSE statement https://www.suse.com/news/SUSE-Preserves-Choice-in-Enterprise-Linux/

    TL;DR SUSE is forking RHEL. Plans to invest more than $10 million into this project.
    SUSE plans on contributing their RHEL-forked project to an open-source foundation and to ensure ongoing free access to this alternative source code.

    So they're saying people should use that instead of SUSE Linux Enterprise Server? 🤔

    I am a Debian user watching this drama unfold with popcorn.

    No idea what SUSE's end game is. From what I have noticed in distro pkg maintenance in other distros - keeping track of open source pkg updates (multiple thousands) by scraping with regex, archiving and mirroring src code, changelogs, backporting all those CVE fixes to an older version, maintaining those hacky patches for a long time without breaking ABI/API is a full time mind draining work. Seems like all the RHEL forks were indeed leeching RHEL employees work and doing business by undercutting and selling cheaper "support" services directly. Maybe now SUSE wants to collaborate with Rocky linux devs according to their statement and reduce their burden to maintain SUSE Linux Enterprise packages. Several distros seem to pull patches from Fedora packages src (mostly maintained by RHEL employees) . Example (void linux since their git repo is easy to understand and navigate): https://github.com/void-linux/void-packages/tree/master/srcpkgs/unzip/patches

    Seems like the end is nigh for RHEL based forks and open source in general due to IBM's greed.

    Thanked by 2MechanicWeb Peppery9
  • varwwwvarwww Member

    https://almalinux.org/blog/future-of-almalinux/

    AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 bug-for-bug compatibility with RHEL. AlmaLinux OS will instead aim to be Application Binary Interface (ABI) compatible.
    ABI compatibility in our case means working to ensure that applications built to run on RHEL (or RHEL clones) can run without issue on AlmaLinux. Adjusting to this expectation removes our need to ensure that everything we release is an exact copy of the source code that you would get with RHEL.

    Thanked by 2angstrom jonathanspw
  • angstromangstrom Moderator

    @varwww said:
    https://almalinux.org/blog/future-of-almalinux/

    AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 bug-for-bug compatibility with RHEL. AlmaLinux OS will instead aim to be Application Binary Interface (ABI) compatible.
    ABI compatibility in our case means working to ensure that applications built to run on RHEL (or RHEL clones) can run without issue on AlmaLinux. Adjusting to this expectation removes our need to ensure that everything we release is an exact copy of the source code that you would get with RHEL.

    Without access to the exact same source packages, 1:1 bug-for-bug compatibility was an unrealistic aim anyway

    Thanked by 1varwww
  • rcy026rcy026 Member

    @sparek said:

    @emgh said:

    @omelas said: not sure at move to Debian/Ubuntu reaction. doesn't centos stream still support 5 year, just like ubt and Debian does?

    https://www.redhat.com/en/resources/centos-stream-checklist

    "CentOS Stream may seem like a natural choice to replace CentOS Linux, but it is not designed for production use."

    A Debian or Ubuntu variant with a 10 year life cycle is essentially what is missing. I know you can get Ubuntu Pro for 10 years of support - but you have to pay for it. And if you're going to pay for 10 years of support, you might as well pay RHEL.

    The web hosting industry - which I'll admit is not the only industry for an Enterprise Linux - really doesn't need commercial support, there's enough community support to carry it on. But the web hosting industry does need about a 10 year life cycle.

    I don't know about everyone else, but for me with CentOS, I generally avoided new versions of CentOS for a year or two, in order for any bugs or issues to be identified and resolved. Then about 2 or 3 years before that version of CentOS went end of life, I would start to migrate servers to the new servers with the new version of CentOS. A 10 year life cycle worked perfectly for this.

    With a 5 year life cycle, say you wait a year to allow for bugs and issues to get worked out, then you get 2 years of life before you have to start looking at upgrading or migrating to a newer version of Debian. That just doesn't work in an industry that needs a bit more stability.

    The problem is that the industry (low end webhosting) that wants a 10 year life cycle is not willing to pay for that stability.
    The industries where the money is, the actual "Enterprise" part of it, do not have a 10 year life cycle. They usually replace all hardware at 3 or 5 years and when you replace all hardware it's easy to do a software upgrade at the same time, so a 5 year life cycle is enough for them. So companies like RHEL is left with paying enterprise customers that have no interest in a 10 year life cycle, and a community of non-paying users that demands it. They can try to force the enterprise customers to pay more for something they do not want and risk losing them, or they can make the non-paying community dissatisfied.
    Not that I like RHEL's move but they are a company with 19.000 employees that needs to get paid, so I kind of understand it.

  • raindog308raindog308 Administrator, Veteran

    @varwww said:
    https://almalinux.org/blog/future-of-almalinux/

    AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 bug-for-bug compatibility with RHEL.

    So I guess they don't have faith in the Rocky approach.

  • raindog308raindog308 Administrator, Veteran

    I tried to summarize each of the cloners' approaches to IBM's announcement:

    https://lowendbox.com/blog/clone-wars-how-every-major-rhel-clone-is-reacting-to-ibm-from-counter-exploiting-legal-loopholes-to-rhel-semi-clones/

    I call dibs on the term RHEL++.

    Thanked by 1varwww
  • spareksparek Member

    @raindog308 said:
    I tried to summarize each of the cloners' approaches to IBM's announcement:

    https://lowendbox.com/blog/clone-wars-how-every-major-rhel-clone-is-reacting-to-ibm-from-counter-exploiting-legal-loopholes-to-rhel-semi-clones/

    I call dibs on the term RHEL++.

    The way I understand things, basically AlmaLinux, SUSE Linux, and Oracle Linux are all forking out of RHEL. They will still be RPM based but the level of which they depend on RHEL is undetermined and as yet unknown.

    I think what remains to be seen is just how compatible all 3 remain with each other and RHEL. And then the question becomes, does it really matter?

    I know AlmaLinux is a top choice for the shared web hosting industry. I don't know what other industries it is involved in. But from a shared web hosting server standpoint, none of the LAMP stack really depends that much on the OS provided binaries (save for MySQL/MariaDB?).

    This may be where RHEL overplayed their hand (or not, since they weren't see any money out of it anyway). I've preached ever since the CentOS 8 decision that shared web hosting server administrators just want longevity in their OS - or at least I do. As long as the control panel of choice works on that OS, there's not really a lot of OS specific functions that are needed.

    The question would be, can AlmaLinux, SUSE Linux, and Oracle Linux continue to maintain their OS independent of RHEL? All 3 have at least some commercial Enterprise funding to back them up (although, I'd say AlmaLinux with their CloudLinux funding source would be the lowest funded of the three).

    My argument before was for a Debian based alternative to come out of this. To use an example, if AlmaLinux was based on Debian but repackaging the Debian packages to provide a 10 year life cycle, then the heavy lifting of maintaining those packages would already be being done by the Debian community. But if AlmaLinux thinks they can do this within the RPM model - it's essentially the same thing.

    Thanked by 1raindog308
  • Plot twist: Microsoft forks their own RHEL and pledges support for 10 years... (I guarantee you that Microsoft already spends way more than $10 million a year on Linux already.)

    I'm curious whether this change was more business model required it or emotional decision.

  • varwwwvarwww Member

    @TimboJones said:
    Plot twist: Microsoft forks their own RHEL and pledges support for 10 years... (I guarantee you that Microsoft already spends way more than $10 million a year on Linux already.)

    I'm curious whether this change was more business model required it or emotional decision.

    It already exists - https://github.com/microsoft/CBL-Mariner Not sure what the EOL is for their distro.

  • jonathanspwjonathanspw Member, Host Rep

    @MechanicWeb said: They clearly don't have the same testing capability as RHEL does.

    We literally wrote the OpenQA stuff that exists for EL distros.

    https://news.opensuse.org/2023/05/30/almalinux-contributes-to-openqa-addes-support-features/

  • @varwww said:

    @TimboJones said:
    Plot twist: Microsoft forks their own RHEL and pledges support for 10 years... (I guarantee you that Microsoft already spends way more than $10 million a year on Linux already.)

    I'm curious whether this change was more business model required it or emotional decision.

    It already exists - https://github.com/microsoft/CBL-Mariner Not sure what the EOL is for their distro.

    That's what I was referring to. But it's not intended for public, general use. Intel's Clear Linux is more general and intended for public use and not just Intel hardware.

    Thanked by 1varwww
  • jonathanspwjonathanspw Member, Host Rep

    @raindog308 said:
    I tried to summarize each of the cloners' approaches to IBM's announcement:

    https://lowendbox.com/blog/clone-wars-how-every-major-rhel-clone-is-reacting-to-ibm-from-counter-exploiting-legal-loopholes-to-rhel-semi-clones/

    I call dibs on the term RHEL++.

    There some factual inaccuracies in your post. AlmaLinux is partially funded by CloudLinux, along with many other sponsors. CloudLinux != AlmaLinux.

    It's pretty well known and accepted that RH made this poor choice on their own and wasn't influenced by IBM.

  • raindog308raindog308 Administrator, Veteran

    @jonathanspw said: It's pretty well known and accepted that RH made this poor choice on their own and wasn't influenced by IBM.

    What? IBM bought RedHat in 2019, one year before CentOS Stream. If IBM didn't want this to happen, it wouldn't have happened.

  • raindog308raindog308 Administrator, Veteran

    @jonathanspw said: There some factual inaccuracies in your post. AlmaLinux is partially funded by CloudLinux, along with many other sponsors. CloudLinux != AlmaLinux.

    Fixed.

  • MechanicWebMechanicWeb Member, Patron Provider

    @jonathanspw said: We literally wrote the OpenQA stuff that exists for EL distros.

    I am not trying to take anything away from Alma. But writing code and having QA capacity + capability are two different things, and industries. AlmaLinux is still a very small initiative. Most of their dev work involved rebranding RHEL to Alma.

    They came to focus only because RHEL dropped CentOS, not because of something Alma accomplished. The industry was somewhat forced to use them as there was literally no alternative other than Alma.

    To their credit, CloudLinux identified a perfect opportunity to grab a ready made client base with practically zero investment or effort that was created and left by CentOS. They were already forking RHEL, they just needed to do another fork and brand it AlmaLinux, which they quickly did.

    The result, they took over an entire community, and folks that never heard of CloudLinux knew their name - an unprecedented marketing advantage they gained that wasn't achievable even after spending millions.

    It was a business decision, which was later proved by their actions, which subsequently led to RHEL blocking access to source code.

  • MechanicWebMechanicWeb Member, Patron Provider
    edited July 2023

    @varwww said: From what I have noticed in distro pkg maintenance in other distros - keeping track of open source pkg updates (multiple thousands) by scraping with regex, archiving and mirroring src code, changelogs, backporting all those CVE fixes to an older version, maintaining those hacky patches for a long time without breaking ABI/API is a full time mind draining work. Seems like all the RHEL forks were indeed leeching RHEL employees work and doing business by undercutting and selling cheaper "support" services directly.

    Exactly.

    @varwww said: AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 bug-for-bug compatibility with RHEL.

    In the process they lost some of their credibility. Folks questioned them when they claimed they would be able to maintain 1:1 compatibility even after RHEL blocked the source code. They should have known better and maintained transparency. To their credit, they have now changed their position publicly.

  • MechanicWebMechanicWeb Member, Patron Provider

    @rcy026 said: The industries where the money is, the actual "Enterprise" part of it, do not have a 10 year life cycle. They usually replace all hardware at 3 or 5 years

    It's not that simple, as @sparek explained elsewhere.

    Though I would not agree that all enterprises replace relevant hardware at 3-5 years, you need a 10 year lifecycle to do that.

    It's not when you replace the hardware, the lifecycle of an OS begins. But you usually replace hardware in the middle of the OS's lifecycle. You need that 5 years in its lifecycle before you can replace the hardware again.

    If you are an enterprise, you are likely to wait one or two years after an OS is released for them to discover and furnish out any bugs. Then deploy, wait a few years before preparing for upgrade. You can't do all these within 5 years.

    @sparek said: This may be where RHEL overplayed their hand (or not, since they weren't see any money out of it anyway).

    As I understand, no one in the OS industry (except CloudLinux) cares about hosting providers. Hosting providers pay them exactly zero bucks. What's the incentive to care?

  • MikePTMikePT Moderator, Patron Provider, Veteran
    edited July 2023

    @MechanicWeb said:

    @jonathanspw said: We literally wrote the OpenQA stuff that exists for EL distros.

    I am not trying to take anything away from Alma. But writing code and having QA capacity + capability are two different things, and industries. AlmaLinux is still a very small initiative. Most of their dev work involved rebranding RHEL to Alma.

    They came to focus only because RHEL dropped CentOS, not because of something Alma accomplished. The industry was somewhat forced to use them as there was literally no alternative other than Alma.

    To their credit, CloudLinux identified a perfect opportunity to grab a ready made client base with practically zero investment or effort that was created and left by CentOS. They were already forking RHEL, they just needed to do another fork and brand it AlmaLinux, which they quickly did.

    The result, they took over an entire community, and folks that never heard of CloudLinux knew their name - an unprecedented marketing advantage they gained that wasn't achievable even after spending millions.

    It was a business decision, which was later proved by their actions, which subsequently led to RHEL blocking access to source code.

    I can tell you that both CloudLinux and AlmaLinux have some of the best engineers and kernel developers.

    CloudLinux CEO is also present here. @iseletsk

  • raindog308raindog308 Administrator, Veteran

    @MechanicWeb said: It's not when you replace the hardware, the lifecycle of an OS begins. But you usually replace hardware in the middle of the OS's lifecycle. You need that 5 years in its lifecycle before you can replace the hardware again.

    Compared to software, replacing hardware is easy. Move the desks (either physically or virtually) and often you're done...OK, slight exaggeration but you can reconfigure some OS stuff and the app keeps working.

    Now try upgrading the database, the middleware, etc. Particularly in big environments where the HRIS is linked to the timekeeping system which feeds an analytics package which updates the accounting system which replicates to...just keeping the compatibility matrix straight is a full-time job.

    Most big enterprise vendors give a 10-year lifecycle on their software. They'd like you to upgrade regularly, and you may have to pay for extended support past 5 or 7 years, but they don't stop support until 10 years. And then there are still shops that will run it past that on a wing and a prayer on a "just don't touch it" basis.

    Thanked by 1Peppery9
  • rcy026rcy026 Member

    @MechanicWeb said:

    @rcy026 said: The industries where the money is, the actual "Enterprise" part of it, do not have a 10 year life cycle. They usually replace all hardware at 3 or 5 years

    It's not that simple, as @sparek explained elsewhere.

    Actually, it is. I've worked within enterprise for 30 years, no serious enterprise runs 10 year old os versions.
    Of course there are some companies that do, but I would not call them serious and they are not the ones paying the big bucks to software providers. Lets face it, if you run 10 year old software you obviously do not care, so there is no way you pay for anything unless you really have to.

    Though I would not agree that all enterprises replace relevant hardware at 3-5 years, you need a 10 year lifecycle to do that.

    The kind of enterprise that pays millions for support do, and they are the ones that matter.
    If you run a 10 year life cycle on software you will not get the support anyway, very few companies support 10 year old versions of their software.

    It's not when you replace the hardware, the lifecycle of an OS begins. But you usually replace hardware in the middle of the OS's lifecycle. You need that 5 years in its lifecycle before you can replace the hardware again.

    Usually you lift in brand new hardware with the latest os already deployed, and that's when the life cycle begins. Within 5 years you do it again and the life cycle starts from zero again, both hardware and software.

    If you are an enterprise, you are likely to wait one or two years after an OS is released for them to discover and furnish out any bugs.

    Most enterprise level software has already been tested for years when it is released.
    Of course bugs happen, but look at enterprise level software and it is very rare. Also, if you are enterprise and under support contract, you keep up with the patches or you will not get the support you are paying the big bucks for.

    For desktops and workstations I would agree with you, you wait a few years when something new comes along and you postpone the next version for as long as you can. But that's windows and mac clients, not servers. On servers, any serious enterprise level organisation would run the latest patch level recommended by their provider or they will not get the support they are paying for.

  • mustafamw3mustafamw3 Member, Host Rep
  • I use that for my personal stuff and it's great, but you can't really run a business with that license. Plus it doesn't renew after a year so you kind of have to get a brand new subscription every year which I guess is OK for personal projects.

    Thanked by 1mustafamw3
  • omelasomelas Member

    @rcy026 said:

    @MechanicWeb said:

    @rcy026 said: The industries where the money is, the actual "Enterprise" part of it, do not have a 10 year life cycle. They usually replace all hardware at 3 or 5 years

    It's not that simple, as @sparek explained elsewhere.

    Actually, it is. I've worked within enterprise for 30 years, no serious enterprise runs 10 year old os versions.
    Of course there are some companies that do, but I would not call them serious and they are not the ones paying the big bucks to software providers. Lets face it, if you run 10 year old software you obviously do not care, so there is no way you pay for anything unless you really have to.

    Though I would not agree that all enterprises replace relevant hardware at 3-5 years, you need a 10 year lifecycle to do that.

    The kind of enterprise that pays millions for support do, and they are the ones that matter.
    If you run a 10 year life cycle on software you will not get the support anyway, very few companies support 10 year old versions of their software.

    It's not when you replace the hardware, the lifecycle of an OS begins. But you usually replace hardware in the middle of the OS's lifecycle. You need that 5 years in its lifecycle before you can replace the hardware again.

    Usually you lift in brand new hardware with the latest os already deployed, and that's when the life cycle begins. Within 5 years you do it again and the life cycle starts from zero again, both hardware and software.

    If you are an enterprise, you are likely to wait one or two years after an OS is released for them to discover and furnish out any bugs.

    as OS release and new server provision isn't align, you need more than 5 years for 5 year life cycle. if you provision Ubuntu server now it'd be 22.04 and while it is 5 year support it will eol at 2027, 3.5 years from now

  • angstromangstrom Moderator

    @rcy026 said: I've worked within enterprise for 30 years, no serious enterprise runs 10 year old os versions.
    Of course there are some companies that do, but I would not call them serious and they are not the ones paying the big bucks to software providers. Lets face it, if you run 10 year old software you obviously do not care, so there is no way you pay for anything unless you really have to.

    So why do RHEL offer 10 years of support plus 2 years of "extended lifecycle support"? Someone serious must be paying them in order for this effort to be worthwhile for them

    If the serious companies aren't paying them for this effort, and the non-serious companies aren't paying them for this effort, then why do they do it?

    In any case, it would be nice to have reliable data about this

  • MechanicWebMechanicWeb Member, Patron Provider
    edited July 2023

    @MikePT said: I can tell you that both CloudLinux and AlmaLinux have some of the best engineers and kernel developers.

    I have no doubt about that. That doesn't negate the benefit they got.

    @raindog308 said: Most big enterprise vendors give a 10-year lifecycle on their software.

    @omelas said: Ubuntu server now it'd be 22.04 and while it is 5 year support it will eol at 2027, 3.5 years from now

    Exactly.

    @rcy026 said: Actually, it is. I've worked within enterprise for 30 years

    That's not the experience I had. But hey, possible I guess.

Sign In or Register to comment.