[HN Gopher] June 30th, 2024, will bring the End of Life (EOL) of...
___________________________________________________________________
June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux
(2023)
Author : kristianpaul
Score : 193 points
Date : 2024-01-05 12:56 UTC (10 hours ago)
(HTM) web link (www.redhat.com)
(TXT) w3m dump (www.redhat.com)
| jasoneckert wrote:
| This EOL date is a generous one. Like my organization, most
| others I know have already completed their migration from CentOS
| to RHEL/Fedora/Rocky/Alma/etc during the early part of 2023.
| Thus, these 6 months are mainly for the few outliers who have
| not.
| p_l wrote:
| > already completed their migration from CentOS to
| RHEL/Fedora/Rocky/Alma/etc during the early part of 2023
|
| ahahahahaha....
|
| OTOH, I no longer work there, I get to watch the fireworks
| geerlingguy wrote:
| Heh... I still see CentOS 6 with some regularity.
| p_l wrote:
| That company had few load-bearing CentOS 6 machines that
| barely anyone knew how to operate (as in "where are the SSH
| keys, passwords, where shit is stored on them") and docs
| were in disarray.
|
| The replacement project for remaining CentOS 6 machines was
| going glacially, but at least didn't endanger compliance.
| The replacement project for CentOS 7 got sabotaged by
| management, few people got run out of the company, last I
| heard the replacement project for the replacement project
| was going to just end up with few multimillion cheques to
| OpenLogic so that certain big fat client group doesn't drop
| them like hot potato on EOL day.
| 9659 wrote:
| I wouldn't use the word "regularity", but the pleasure of
| debugging a long standing issue on a RHEL 5 machine came up
| in December.
|
| had to compile git and tcpdump from source.
|
| all in all, a pleasant experience. vi is the same.
| JeremyNT wrote:
| > _This EOL date is a generous one. Like my organization, most
| others I know have already completed their migration from
| CentOS to RHEL /Fedora/Rocky/Alma/etc during the early part of
| 2023. Thus, these 6 months are mainly for the few outliers who
| have not._
|
| I can't disprove your anecdote but do you think this is really
| true? Orgs who ran CentOS likely did so with the idea that
| they'd have a very long time to migrate to something different.
| CentOS 8 nominally had support until something like 2032, so it
| seems like a really major change to go from almost a decade to
| a little over a year to migrate away.
| dralley wrote:
| Long live CentOS Stream
| thesuperbigfrog wrote:
| Rocky Linux is a fine successor to CentOS and was created by one
| of the original founders of CentOS, Gregory Kurtzer.
|
| https://rockylinux.org/
|
| https://rockylinux.org/about/
|
| If you need enterprise support RHEL tends to be a default choice.
|
| If you cannot afford RHEL or do not need enterprise support,
| Rocky Linux fills the role that CentOS once did.
| 0x6c6f6c wrote:
| Another suitable option, which has handled the situation of Red
| Hat source RPM releases[1] quite a bit better imo, is Alma
| Linux.
|
| https://almalinux.org/
|
| Similar goal, but is working more directly upstream with Red
| Hat[2] as opposed to the (as I last had read) undisclosed and
| non-open approach that Rocky Linux has taken.
|
| 1: https://www.redhat.com/en/blog/furthering-evolution-
| centos-s...
|
| 2: https://almalinux.org/blog/future-of-almalinux/
| chasil wrote:
| As I understand it, Alma is following the stream release,
| which is slightly upstream and less stable than RHEL.
|
| https://linux.slashdot.org/story/23/07/29/0214234/almalinux-.
| ..
|
| Rocky and SUSE Liberty Linux aim to be bug-for-bug compatible
| with RHEL, which has become more difficult.
| bityard wrote:
| This is the first time I have heard of SUSE Liberty Linux
| as an alternative to RHEL... when I went searching for
| information on it, all I could find was the product page
| and some press releases.
|
| It's hard to read between the lines of the marketing speak
| but it sounds like it's just a suite of paid support
| options for existing RHEL/CentOS deployments and not a RHEL
| derivative that one can just download and use. Unless I am
| missing something?
| freedomben wrote:
| No it _is_ actually a RHEL derivative, but personally I
| wouldn 't go that direction unless you intend to
| eventually move to other SUSE stuff. They committed a
| chunk of budget initially to maintain it, but I'm sure
| they view it as a stepping stone or bridge SLE.
| iseletsk wrote:
| Alma is not following stream. It sues stream sources but
| selects only the right patches - to be fully binary
| compatible with RHEL
| chasil wrote:
| > It sues stream sources
|
| Beware the Freudian slip.
| heywoodlh wrote:
| > which is slightly upstream and less stable than RHEL
|
| As a user who almost exclusively uses rolling release OS-
| es, is this actually something people care about? CentOS
| Stream is downstream of Fedora -- and Fedora is a rock
| solid base. It's not like CentOS Stream is riddled with
| bugs, broken features, etc.
| orthoxerox wrote:
| Yes, this is something people running servers want. A lot
| of enterprisey software is supported only on LTS releases
| of operating systems.
| josephcsible wrote:
| If you wanted a distro that was similar to but not
| exactly the same as RHEL, then Fedora itself would be a
| way better choice. And if you care that it's exactly the
| same as RHEL, then CentOS Stream doesn't cut it.
| bennyvasquez wrote:
| AlmaLinux matches releases and versions with RHEL. More
| clarification in this 2-minute video:
| https://www.youtube.com/watch?v=DNMnajmyLaA
| dissident_coder wrote:
| Alma Linux is getting their source packages from Stream but
| they are using the exact same versions that are in the
| current Redhat release.
| freedomben wrote:
| Yeah Alma is a much better option if you care about the
| behavior and attitudes of the people behind the project.
|
| The Rocky people are antagonistic toward Red Hat and view
| them as somewhat an enemy (which seems so weird to me as
| without Red Hat, they couldn't possibly exist). They strictly
| want to take what Red Hat sells and rebuild and distribute it
| for free.
|
| The Alma people on the other hand view themselves as partners
| and contributors to Red Hat's ecosystem. They want to make
| their product available for free, but they upstream as much
| as possible and add actual value to the ecosystem.
|
| If you don't care about any of that, it's still better to
| choose Alma IMHO because their approach (following the letter
| and spirit of "the law") is a lot more sustainable than
| Rocky's exploit-the-system approach.
| tux1968 wrote:
| > They strictly want to take what Red Hat sells and rebuild
| and distribute it for free.
|
| I think this is an unfair framing. Rather, they want to
| take all the GPL source code that Red Hat is obligated to
| make available, and distribute it freely. They believe this
| is in accordance with both the law and the software license
| that Red Hat agreed to, when using it as a basis for their
| business in the first place.
|
| Personally, I don't have a dog in the fight, or a strong
| opinion on the matter. But we should at least fairly
| represent each parties position.
| dralley wrote:
| All of the source code is already available, in CentOS
| Stream, from which RHEL is built in the first place.
|
| What they want to do, is do an exact rebuild of RHEL
| without having to go through the effort of putting the
| distribution together themselves, matching the versions
| that are used in a particular version of RHEL against
| what is available via CentOS Stream.
| skybrian wrote:
| And that's perfectly fine under open source licenses. You
| are allowed to build and redistribute your own binaries.
|
| That's both spirit and letter. Don't fall for people
| making up additional terms that aren't in the license.
| dralley wrote:
| It's perfectly fine but it shouldn't be cast as "freeing
| the source code, unjustly locked down by Red Hat",
| because it's not.
| tux1968 wrote:
| But that is pretty much exactly the contention of Rocky
| Linux. Well actually, they don't explicitly accuse Red
| Hat of unjustly locking down the source code, just that
| there are now some extra hurdles required to legally
| obtain it.
|
| They do contend, that they are exercising their legal
| rights as enumerated in the software license that Red Hat
| agreed to, when it started to use and freely redistribute
| the work of others.
|
| If you are denying they have this legal right, then I
| believe it's on you to explain and justify this legal
| position, rather than just asserting it as fact.
| dralley wrote:
| What I am saying is that the code is not "locked down" in
| any meaningful sense, that it is already open source, and
| therefore that Rocky Linux isn't "freeing" it. I'm not
| making any statement about their legal rights.
|
| As I commented elsewhere, "RHEL" isn't GPL licensed, the
| kernel is, and glibc is, and systemd is, etc.
| Individually.
|
| The sources for all of those packages, individually, are
| available via CentOS Stream just as they ever were -
| alongside the sources for packages that aren't GPL
| licensed, for which there is not actually a legal
| requirement to distribute sources.
|
| What Red Hat has stopped doing is providing a git repo
| containing the exact combination of package sources which
| collectively make up one particular version of RHEL.
| Instead, all of the sources are still available, but if
| you want to rebuild the entire distro you need to match
| up the particular versions with RHEL. And that's exactly
| what Alma Linux does.
| tux1968 wrote:
| Okay, so the source is 100% freely available. And with
| that source, and nothing else, you are able to regenerate
| RHEL binaries.
|
| Rocky Linux contends they are not doing anything illegal
| in the methods used to obtain the source code (ie.
| legally renting an RHEL VM from any number of providers,
| and downloading the SRPMS).
|
| Maybe Red Hat wishes this was illegal, but I still
| haven't heard anyone claim that it is.
| dralley wrote:
| I'm not claiming that either, so what's your point. I'm
| just saying that the way Rocky presents it is mostly
| marketing. The cleverness is to save themselves effort,
| not to do something they weren't being allowed to do
| previously.
| tux1968 wrote:
| I'm not sure why you weighed in on the subject then,
| other than to advance your own personal preference. At
| least, I mistook it as an objection to Rocky Linux's very
| existence. As long as what they're doing is legal, then
| let them be. Each distribution will rise and fall based
| on the value it provides.
| Nullabillity wrote:
| But Red Hat _is_ the enemy!
|
| > which seems so weird to me as without Red Hat, they
| couldn't possibly exist
|
| If Red Hat didn't exist, they wouldn't _need_ to exist.
| Nobody would need to test their stuff against RH, and
| nobody would need to run garbage that the upstream vendors
| only bothered to test against RH.
| CodeCompost wrote:
| I would avoid Rocky since it is now resting on very shaky
| foundations.
| keikobadthebad wrote:
| Could you be specific? Else it sounds like you're just
| FUDding it.
| heywoodlh wrote:
| My understanding is that since Red Hat restricted the
| source availability for RHEL, Rocky is using the following
| loopholes to gain binary compatibility with RHEL:
|
| 1. Using OCI images of RHEL (i.e. on Docker Hub)
|
| 2. Using cloud server images of RHEL
|
| They outlined their plans for this in June of 2023[0].
|
| Red Hat's official stance is that downstream distros like
| Rocky or AlmaLinux should be basing off of CentOS Stream --
| that would allow all the EL distributions to contribute and
| use the same OS base[1]. AlmaLinux pivoted to this
| method[2] -- which seems like a more sustainable approach
| to me.
|
| My opinion: blows my mind that people who value Enterprise
| Linux would be willing to continue to use a distro like
| Rocky that actively works against/around the supported
| route its upstream provider suggests.
|
| (Personally, I don't find value in the EL ecosystem, I
| prefer rolling releases everywhere when possible)
|
| [0] https://rockylinux.org/news/keeping-open-source-open/
|
| [1] https://www.redhat.com/en/blog/furthering-evolution-
| centos-s...
|
| [2] https://almalinux.org/blog/future-of-almalinux/
| phpisthebest wrote:
| I fail to see what separates Alma from CentOS Stream at
| this point
|
| The entire Propose of CentOS was Binary Compatibility
| with RHEL, largely for Vendor compliance reasons, if a
| vendor of a commercial software product validated RHEL 7
| for their software running CentOS 7 was also supported
|
| Running CentOS Stream, or now Alma Linux would not be as
| their are no longer binary compatible with RHEL.
|
| the Hostility of IBM and Redhat here has lead me to
| transition 100% of the CentOS Server I managed to Ubuntu
| Last year... The software vendors that i use all quickly
| validated Ubuntu as an alternative to CentOS after the
| original CentOS Stream announcement which made is a easy
| choice for me..
|
| I will never use RHEL or RHEL based distribution again at
| this point so I really do not care about the future of
| Alma or Rocky either
|
| >Personally, I don't find value in the EL ecosystem, I
| prefer rolling releases everywhere when possible
|
| if you are running ERP Systems, LOB Apps, or other
| critical functions that measure their code life in
| decades not weeks then EL systems are required. I do not
| want the system to change as the app i am running has not
| changed. I want Stability, and security not new features
| or more performance or even new hardware
| indigodaddy wrote:
| AFAIK, Alma has committed to continued full RHEL binary
| compatibility.
| heywoodlh wrote:
| Incorrect, according to their FAQ[0] and the original
| article I linked[1]:
|
| > What does ABI/binary compatible with RHEL mean?
|
| > In July of 2023, we announced (opens new window) that
| we were shifting our goal from being a downstream rebuild
| of RHEL to maintaining ABI compatibility with RHEL. For
| the AlmaLinux team that means that everything from
| software applications to kernel modules that work on RHEL
| will work on AlmaLinux, and if they don't we would
| consider that a bug.
|
| TL;DR: they are using CentOS Stream as their upstream.
|
| EDIT: Sorry, you're correct -- I was thinking you meant
| their original goal of "bug-for-bug" compatibility with
| RHEL.
|
| [0] https://wiki.almalinux.org/FAQ.html#what-does-abi-
| binary-com...
|
| [1] https://almalinux.org/blog/future-of-almalinux/
| throw0101d wrote:
| > _For a typical user, this will mean very little change
| in your use of AlmaLinux. Red Hat-compatible applications
| will still be able to run on AlmaLinux OS, and your
| installs of AlmaLinux will continue to receive timely
| security updates. The most remarkable potential impact of
| the change is that we will no longer be held to the line
| of "bug-for-bug compatibility" with Red Hat, and that
| means that we can now accept bug fixes outside of Red
| Hat's release cycle. While that means some AlmaLinux OS
| users may encounter bugs that are not in Red Hat, we may
| also accept patches for bugs that have not yet been
| accepted upstream, or shipped downstream._
|
| * https://almalinux.org/blog/future-of-almalinux/
| bennyvasquez wrote:
| Our primary difference: a 10-year lifecycle, with a focus
| on stability.
|
| I'd say that _your_ use case for CentOS might have been
| vendor compliance, but our user base doesn 't agree
| that's the _only_ use case.
|
| I'd recommend listening to this podcast with Neal Gompa
| about Red Hat vs IBM at this point:
|
| https://hackaday.com/2023/12/27/floss-weekly-
| episode-763-fed...
| heywoodlh wrote:
| > I fail to see what separates Alma from CentOS Stream at
| this point
|
| I believe that AlmaLinux's approach is in-line with Red
| Hat's vision for downstream OS-es. Rocky's is not.
|
| I think a potential benefit to aligning with Red Hat's
| approach is that both AlmaLinux and Red Hat will be
| contributing fixes, improvements, etc. to CentOS Stream
| -- and any other OS-es that base off of CentOS Stream.
| And, nothing is preventing AlmaLinux from snapshotting
| their own stable releases -- which allows the AlmaLinux
| team to test and release stable releases to their users.
|
| > the Hostility of IBM and Redhat here has lead me to
| transition 100% of the CentOS Server I managed to Ubuntu
|
| I completely agree with this perspective. This is why
| Rocky's decisions really baffle me: why use an upstream
| OS like RHEL if you absolutely do not align with its
| objectives? I feel like it would have made much more
| sense for Rocky to make Fedora their upstream instead of
| implementing workarounds to copy RHEL.
|
| > I will never use RHEL or RHEL based distribution again
| at this point so I really do not care about the future of
| Alma or Rocky either
|
| I also do not use any Fedora based distribution
| (typically just running NixOS or Ubuntu), however, I find
| that I _do_ care about these shifts because Red Hat has
| tremendous impact on the trajectory of most Linux
| distributions. And the downstream OS-es ' responses have
| been interesting to observe to me. :)
| throw0101d wrote:
| > _I believe that AlmaLinux 's approach is in-line with
| Red Hat's vision for downstream OS-es. Rocky's is not._
|
| What is in-line with users' vision?
| heywoodlh wrote:
| At this point, I'm not sure why end users who care about
| Red Hat stability don't just use RHEL directly. Red Hat
| has multiple ways to take advantage of RHEL that involve
| no cost (that weren't available when the original CentOS
| project was conceived):
|
| - Free developer licenses[0] (great if you're a home-
| labber, IIRC you can get up to 16, I think?)
|
| - Red Hat UBI images[1]
|
| I feel like most users of AlmaLinux won't see a huge
| difference between just using AlmaLinux's release cycle
| vs RHEL -- especially since AlmaLinux will be ABI
| compatible with RHEL. I.E. apps that work for RHEL should
| work for AlmaLinux.
|
| So, back to your original question, I don't know what
| end-users want more of other than as was said by mrweasel
| in a different comment: "that's not what some people
| want, they specifically want RHEL, but for free".
|
| [0] https://developers.redhat.com/blog/2021/02/10/how-to-
| activat...
|
| [1] https://developers.redhat.com/products/rhel/ubi
| freedomben wrote:
| "users" is such a large category as to be absolutely
| meaningless. It's kind of like saying "what do Americans
| think about big tech?"
| stonemetal12 wrote:
| >I believe that AlmaLinux's approach is in-line with Red
| Hat's vision for downstream OS-es.
|
| As far as I can tell this is logically incorrect
| CentOS/Alma are upstream not downstream and red hat's
| vision of downstream OSes is they don't exist because
| that takes a nickel out of IBM's pocket.
| bennyvasquez wrote:
| AlmaLinux matches releases and versions with RHEL. More
| clarification in this 2-minute video:
| https://www.youtube.com/watch?v=DNMnajmyLaA
| heywoodlh wrote:
| You're correct, I was referring to AlmaLinux's former
| status of being downstream of RHEL. Additionally, from
| Red Hat's perspective, AlmaLinux is still downstream of
| CentOS Stream (and thus a participant of Red Hat's vision
| for CentOS Stream[0]).
|
| > red hat's vision of downstream OSes is they don't exist
| because that takes a nickel out of IBM's pocket
|
| I think CentOS Stream actually contradicts this because
| (I would imagine) it's a lot of work to maintain and
| greatly benefits the community -- and Red Hat still makes
| it freely available for other distributions to base off
| of.
|
| [0] https://www.redhat.com/en/blog/furthering-evolution-
| centos-s...
|
| EDIT: clarified RH's vision for CentOS Stream and added
| my thoughts on CentOS Stream
| jonathanspw wrote:
| Technically code-wise we're a downstream of CentOS Stream
| for the most part, but the end result is more of a hybrid
| because we're targeting RHEL and can match commits to
| RHEL commits from stream for a lot of it...so yeah.
|
| Formerly we were just 100% downstream RHEL with none of
| this nuance, as you mentioned.
| mrweasel wrote:
| > if you are running ERP Systems, LOB Apps, or other
| critical functions that measure their code life in
| decades
|
| That's really what confuses me about the people who use
| CentOS or Rocky, they want or need the stability of RHEL,
| so that they can run these crucial applications, that
| mostly aren't cheap, yet they refuse to pay for the
| development of the operating system they run it them?
|
| I really don't see the point in any of these clones,
| other than as an educational tool. I see the point in
| RHEL and while expensive, that's the price of developing
| this platform. You can buy SuSE, Ubuntu Pro or Oracle
| Linux, if you feel that RedHat is to expensive (perhaps
| not Oracle), but that's not what some people want, they
| specifically want RHEL, but for free.
| mjw1007 wrote:
| The theory that Red Hat users are supposed to be paying
| for development of the system is a recent one. What Red
| Hat used to say is that the software is free and their
| users are paying for support.
|
| That made a great deal of sense, as of course Red Hat
| themselves were shipping a great deal of software written
| by other people without paying for its development.
|
| There's nothing confusing about people declining to go
| along with this change.
| mrweasel wrote:
| > There's nothing confusing about people declining to go
| along with this change.
|
| No, but why stay on a platform from a vendor that has a
| business model you find hostile? I can see the need for a
| transition period, but I'd start looking for another
| vendor that has value and pricing that aligns more with
| my ideals. People seem hellbent on staying on a RHEL-like
| platform.
|
| Also, CentOS isn't/wasn't exactly new, the current
| pricing model from Redhat isn't nearly as old as CentOS.
| orthoxerox wrote:
| > People seem hellbent on staying on a RHEL-like
| platform.
|
| Not really, Ubuntu Server has surged in popularity.
| orthoxerox wrote:
| > That's really what confuses me about the people who use
| CentOS or Rocky, they want or need the stability of RHEL,
| so that they can run these crucial applications, that
| mostly aren't cheap, yet they refuse to pay for the
| development of the operating system they run it them?
|
| Yes. Non-prod (or even prod and non-critical) servers
| usually outnumber critical prod servers, and it makes
| sense to not run RHEL on them and pay for support, but to
| run a 100% compatible distro.
| josephcsible wrote:
| > the people who use CentOS or Rocky, they want or need
| the stability of RHEL, so that they can run these crucial
| applications
|
| No, the people who need the stability of RHEL were
| already paying for it. The people who used CentOS were
| doing so to be able to develop and test software that
| would eventually be used by people running RHEL.
| jacooper wrote:
| To be fair, rocky isn't on its own here.
| https://openela.org (CIQ=Rocky)
| dissident_coder wrote:
| > I fail to see what separates Alma from CentOS Stream at
| this point
|
| Alma is getting their source packages from CentoOS
| Stream, but they are using the specific versions that are
| in the Redhat releases they are targetting. They aren't
| just rebuilding Stream sources from HEAD.
| thesuperbigfrog wrote:
| >> Red Hat's official stance is that downstream distros
| like Rocky or AlmaLinux should be basing off of CentOS
| Stream -- that would allow all the EL distributions to
| contribute and use the same OS base
|
| That stance goes contrary to the "everyone benefits"
| nature of free and open source software. It turns
| "everyone benefits" into "Red Hat / IBM profits". Why
| should the community contribute to Red Hat's bottom line
| if Red Hat refuses to contribute back to the community?
|
| Rocky Linux's "going around Red Hat's back" is only
| necessary because of Red Hat's choice to not contribute
| back to the community.
|
| If IBM wants to expand its AIX
| (https://en.wikipedia.org/wiki/IBM_AIX) business, it can
| do so without tainting Red Hat.
| doublepg23 wrote:
| Accusing Red Hat of not contributing to the wider free
| software community is so off-base I'm not sure how to
| respond.
|
| Is there a single large FOSS project who's git history
| isn't filled with @redhat.com ?
| thesuperbigfrog wrote:
| Oh, so is it okay to share RHEL sources back with the
| original project communities or not?
|
| If you share RHEL sources with the original project
| communities, what happens?
|
| >> Is there a single large FOSS project who's git history
| isn't filled with @redhat.com ?
|
| Does this give Red Hat the right to effectively "close
| source" the code for RHEL despite contributions from the
| rest of the community?
| heywoodlh wrote:
| > Does this give Red Hat the right to effectively "close
| source" the code for RHEL despite contributions from the
| rest of the community?
|
| Legally, yes. Not sure what the point is you're trying to
| make.
|
| I'm not sure why anyone would want to use a downstream
| distribution of Red Hat if they don't like Red Hat's
| trajectory. If you don't like Red Hat's current
| objectives with RHEL, it should be as simple as: stop
| using something downstream of RHEL.
| yjftsjthsd-h wrote:
| > Legally, yes. Not sure what the point is you're trying
| to make.
|
| Legally, no; unless RH is the _only_ copyright holder,
| they get to follow the same rules as everybody else, and
| for GPL packages that means not imposing additional
| restrictions on redistribution of source code.
|
| > If you don't like Red Hat's current objectives with
| RHEL, it should be as simple as: stop using something
| downstream of RHEL.
|
| People are fine with being a downstream of RHEL. It's
| being upstream of RHEL that's the problem; Stream is RHEL
| Beta by another name.
| dralley wrote:
| >Legally, no; unless RH is the only copyright holder,
| they get to follow the same rules as everybody else, and
| for GPL packages that means not imposing additional
| restrictions on redistribution of source code.
|
| And there aren't any. "RHEL Linux" isn't GPL licensed,
| the kernel is, and glibc is, and systemd is, etc.
| Individually.
|
| The sources for all of those packages (and ones that
| aren't GPL licensed, for which there is not actually a
| legal requirement to distribute sources), individually,
| are available via CentOS Stream just as they ever were.
|
| What Red Hat has stopped doing is providing a git repo
| containing the exact combination of package sources which
| collectively make up one particular version of RHEL.
| Instead, all of the sources are still available, but if
| you want to rebuild the entire distro you need to figure
| out which particular versions to use. And that's exactly
| what Alma Linux does.
| yjftsjthsd-h wrote:
| > "RHEL Linux" isn't GPL licensed, the kernel is, and
| glibc is, and systemd is, etc. Individually.
|
| That is why I said "GPL packages", yes.
|
| Okay, so if I buy RHEL, and I download the SRPM for the
| kernel, and I publish it - which I'm legally entitled to
| do, what with the kernel package being GPLv2 - is RH not
| going to terminate my RHEL license?
| dralley wrote:
| Almost certainly not. I don't think that has even
| happened with Rocky, for whom they're not just
| downloading one package.
| dralley wrote:
| Yes, you can. This is something everyone gets mixed up.
|
| RHEL is built from CentOS Stream sources. The changes Red
| Hat made to RHEL source distribution mostly just make it
| more challenging to reconstruct an entire build of RHEL
| from CentOS Stream - because you would have to map
| backwards from all of the different versions of sources
| available in CentOS Stream to the exact versions that a
| particular version of RHEL happens to use. But at the
| scale of any individual project, it's trivial for any
| upstream community to just look at the latest CentOS
| Stream sources for one particular package, if they want
| to look at which patches Red Hat is applying. There are
| no legal or contractual restrictions on this whatsoever.
|
| This is setting aside the fact that most patches are
| backports from one upstream version to another, and
| bugfixes that get submitted "upstream first" to begin
| with, which makes the whole discussion kind of moot. The
| typical scenario for a net-new bugfix would be that a Red
| Hat employee submits the fix upstream and gets it
| reviewed and merged by said upstream months before it
| ever sees the light of day in RHEL, so upstream
| maintainers would never need to look at the RHEL sources
| in the first place.
| dralley wrote:
| Your analysis seems to be ignoring all of the work
| required to create and maintain the CentOS Stream / RHEL
| distribution in the first place, which is substantial.
|
| Prior to CentOS Stream, if you were a CentOS user or
| maintainer who experienced a bug, your only option was to
| file a bug on the RHEL bug tracker and wait for a Red Hat
| employee to fix it for you. It was the Android-esque
| "throw the code over the wall" model of open source.
|
| Post CentOS Stream, a CentOS user or maintainer files the
| bug in the CentOS Stream bug tracker, can write a patch
| and have it reviewed by other users/maintainers/Red Hat
| employees tracking the issue, and then benefit from Red
| Hat QA'ing the fix.
|
| So counter to your claim, I would argue that the CentOS
| Stream model provides more bidirectional / mutual
| benefits.
| thesuperbigfrog wrote:
| >> Your analysis seems to be ignoring all of the work
| required to create and maintain the CentOS Stream / RHEL
| distribution in the first place, which is substantial.
|
| Substantial enough to effectively "close source" RHEL?
|
| Red Hat's changes (https://www.redhat.com/en/blog/red-
| hats-commitment-open-sour...) effectively converted RHEL
| from a fully open source Linux distribution to "source
| available to paying customers only" proprietary product.
|
| The changes are effectively a violation of the GPL by
| prohibiting customers from distributing RHEL sources
| through Red Hat's Terms of Service and EULAs:
|
| https://rockylinux.org/news/keeping-open-source-open/
| dralley wrote:
| RHEL is not "effectively closed source" by any stretch of
| the imagination. The sources are available as CentOS
| Stream -- from which RHEL is built in the first place!!
| It is true that, in order to put together an exact copy
| of RHEL, you would need to do a bit of work to figure out
| exactly what versions RHEL uses, and specifically pick
| those versions out of CentOS Stream. It isn't as simple
| as downloading the entire tree of sources from a single
| git repository anymore. But that's not the same as
| "effectively closed source", either.
| orthoxerox wrote:
| If you provide GPL software to your customers, you have
| to provide everything they need to build this exact
| version yourself, not point them at a repo and tell them
| to figure it out.
| dralley wrote:
| Red Hat does provide all of that to RHEL customers. This
| is a discussion about what non-RHEL customers get.
|
| Even non-customers are provided with all of the sources
| they they could use to build RHEL, given some additional
| effort. It's less trivial than it used to be, but not
| particularly difficult.
|
| Alma takes the approach of reconstructing RHEL using
| these public sources, Rocky takes the approach of buying
| AWS VMs running RHEL for a few minutes at a time so that
| they can download RHEL sources as a "customer" while only
| paying a few dollars a month to do so.
|
| The point is, even non-customers can rebuild RHEL using
| sources made publicly available _by Red Hat_ if they so
| desire. It 's not "effectively closed source", even to
| them.
| josephcsible wrote:
| Prior to CentOS Stream, couldn't you file the bug in the
| upstream project's bug tracker instead, and then still do
| all of the other stuff you said?
| dralley wrote:
| You'd still have to wait for someone at Red Hat to
| backport the fix themselves. There wasn't really a way to
| actually participate in the engineering of CentOS itself.
| josephcsible wrote:
| Won't you still have to wait for someone at Red Hat to
| move the change from Stream into RHEL?
| dralley wrote:
| You'd have to wait on it to be QA'd before it would get
| into Stream officially, but once it's in Stream the
| process of it getting into RHEL is mostly automatic. It
| would just be a matter of waiting, since RHEL only does
| releases every 6 months whereas Stream releases
| constantly.
|
| With CentOS you would have the same problem, except that
| there's no way to make the engineering part happen any
| faster than Red Hat's staffing and priorities allowed.
| phendrenad2 wrote:
| So what? Doesn't matter how convoluted the "loophole" is.
| There will always be a loophole because Red Hat must
| leave one open, because this is open-source software and
| it's impossible for them to truly close all avenues to
| using your RIGHTS under the license.
|
| We should he celebrating people working around DRM, not
| being fearful of it.
| heywoodlh wrote:
| Fair enough! As I stated, I have no personal stake in
| Rocky's approach as I am not a user interested in the
| Enterprise Linux ecosystem. That being said, if I was, I
| would be concerned with the approach as I can't see it
| being sustainable long-term to rely on the workarounds.
|
| (I'd be happy if the Rocky Linux folks prove me wrong --
| the more variety there is with Linux, the better!)
| josephcsible wrote:
| IBM's official route results in a distro that is not bug-
| for-bug compatible with RHEL, at least not without a lot
| of unnecessary work. The route Rocky is taking results in
| a distro that is bug-for-bug compatible.
| heywoodlh wrote:
| > The route Rocky is taking results in a distro that is
| bug-for-bug compatible.
|
| Point taken.
|
| From my perspective, it seems like a short-sighted
| approach to rely on loopholes to obtain bug-for-bug
| compatibility. I know I wouldn't be comfortable running
| anything production-grade on Rocky Linux with their
| current approach.
| jasoneckert wrote:
| If you can't justify the cost of RHEL for your use case, I
| believe Fedora would be the best alternative at this time since
| its development has not been affected by the changes recently
| made to CentOS, and it provides a near identical feature set.
| orev wrote:
| Fedora is a moving target that changes every 6 months. That's
| not suitable for an enterprise application.
| yjftsjthsd-h wrote:
| > and it provides a near identical feature set.
|
| The leading features of CentOS were 1. Absurdly stable; keep
| updating the same version in place for a decade without
| changing it. 2. Drop-in compatible with proprietary drivers
| and applications published for RHEL.
|
| Fedora is not a replacement for CentOS.
| dralley wrote:
| There is no planet on which Fedora makes more sense than
| CentOS Stream as a CentOS replacement.
| bityard wrote:
| Personally it would not be my first choice since I am somewhat
| allergic to anything with the word Oracle in it, but another
| option for those in the enterprise space might be Oracle Linux:
|
| https://www.oracle.com/linux/
|
| They claim full compatibility with RHEL and don't require a
| licence/login to download and install. And they offer paid
| support if you need it.
| chasil wrote:
| They also add btrfs and a bunch of drivers back into their
| custom kernel that RHEL explicitly removes, so it runs on a
| lot more hardware.
| verdverm wrote:
| I'm doing this migration right now, first task of the year.
| paulryanrogers wrote:
| Technically EOL of CentOS 7. Guessing 8 will be supported for a
| while, then one must decide to switch to CentOS Stream, RHEL
| proper, or an alternative like Rocky.
| Nyr wrote:
| CentOS 8 already reached its EOL in December 31st, 2021.
| bpoyner wrote:
| If you moved from CentOS 8 to CentOS Stream 8, Stream 8 is
| basically EOL on May 31st 2024.
| yjftsjthsd-h wrote:
| Okay, but RHEL Beta- er, sorry, "CentOS Stream" isn't
| CentOS.
| highwind wrote:
| Hoping for 10 years of support, I adopted Centos 8 a week before
| the EOL announcement. I never understood why they decided to
| support 7 longer than 8.
| bombcar wrote:
| That was the real rug-pull. Had they supported CentOS 8 for the
| full 10 years, and announced that starting with 9 it would be
| this useless rolling release, people would have been much more
| calm about the whole thing.
| geerlingguy wrote:
| Yep.
|
| It would've been disappointing, but it wouldn't have knocked
| the bee hive off the tree, so to speak. The announcement came
| right after I had switched over all my stuff to target CentOS
| 8. If they had given me the runway to make it feel like all
| that work wasn't for nothing, I would've been okay taking a
| few years to slowly roll to something else.
| freedomben wrote:
| Same. I mostly support what Red Hat has done (after many
| hours of listening to arguments and thinking about them.
| Not the prima facie arguments that they made which were PR
| BS and spin, but the _real_ reasons that were only gotten
| to by podcast hosts that pushed back a bit. But the CentOS
| 8 rug pull was a bad move and IMHO is really hard to defend
| because it came down to a short-term profit grab to try to
| force people to buy RHEL. I think long-term profit motive
| is a _good_ thing (within reason and without compromising
| the open source principles) as it keeps RHEL sustainable,
| but the rug pull of CentOS 8 was wrong.
| bombcar wrote:
| I can't say I wouldn't have done a similar pull on the
| rug, but having a plan before-hand for open source users,
| home users, and even "small business" users would have
| gone a long way to making the pill easier to swallow.
|
| I know for myself, where I could fit into all three of
| those, I just won't use RedHat anything anymore. Whereas
| if there had been a "pay one-time fee of $500" or
| whatever to get "ten years of self-support/no-support"
| our server would be RedHat today.
|
| As it is ....
|
| 5.4.0-169-generic #187-Ubuntu SMP
| klysm wrote:
| Long live Debian
| behnamoh wrote:
| Does `apt` handle packages as cleanly as `dnf` and `yum`? Last
| time I tried `apt`, it would uninstall apps without cleaning
| after itself.
| kstrauser wrote:
| "apt purge" takes no prisoners.
| npteljes wrote:
| Apt purge cleans up user config files after a package, but
| not package dependencies. For complete package removal, apt
| autoremove is needed even after apt purge.
| kstrauser wrote:
| True, but its output suggests that you do that and tells
| you what it would autoremove.
| behnamoh wrote:
| So apt uninstall -> apt purge -> apt autoremove
|
| That looks like an unnecessarily long process to safely
| remove a package. Why isn't that the default behavior on
| Debian?
| Calzifer wrote:
| You can skip the uninstall if you use purge.
|
| And aptitude (alternative package manager) automatically
| removes dependent but not required anymore packages when
| removing/purging a package.
| 8organicbits wrote:
| Do you remember which package, or if it was an official
| Debian package vs third-party? The former is usually pretty
| well written.
|
| Do you have a use-case where packages are regularly
| uninstalled? I usually only install.
| bityard wrote:
| It will not automatically remove dependencies that were
| installed along with a package when that package is removed.
| I'm guessing this is due to some historical ideology about
| how `apt-get` was intended to function. I just typically run
| `apt remove foobar && apt -y autoremove`.
|
| There is also nala, which _does_ automatically remove
| dependencies when you remove a package:
| https://github.com/volitank/nala
| dylan604 wrote:
| Is it aware if another package is using the same
| dependency, so it only removes the dependency if it is not
| being used by anything else?
| sigio wrote:
| Yes, that's what 'apt autoremove' does... remove packages
| that were installed as a dependancy, but are no longer
| needed because packages using it have been removed.
|
| However, the package could of course still be used by
| unpackaged software or local scripts.
| Calzifer wrote:
| aptitude also auto removes dependent packages and is in
| Debian stable.
|
| It has also a useful 'aptitude why package' to say why a
| package is installed and a nice TUI (which is optional; for
| the most part it works very similar to apt).
| stonogo wrote:
| Nowadays you can just pass --autoremove to `apt purge
| <package>` and it will.
| brycewray wrote:
| Apparently there were videos there, but viewing them would
| require allowing _advertising_ cookies. Hmm.
| meisel wrote:
| I don't know much about CentOS, but I've seen a lot of anger
| about the end of CentOS Linux, regardless of CentOS stream,
| Rocky, etc. . Can someone explain the history of this, why CentOS
| is going away, why it's being replaced with these new
| alternatives, and why many seem quite mad about it? Just curious
| to understand the state of it.
| davweb wrote:
| CentOS was created as open source distribution compatible with
| Red Hat Enterprise Linux (RHEL).
|
| It was successful as it gave most of the benefits of RHEL
| without the expense.
|
| RedHat acquired CentOS, saying that it would be good for
| CentOS[1].
|
| RedHat shut CentOS down.
|
| New alternatives are coming along to take the role of a free
| distribution compatible with RHEL.
|
| [1]: https://www.redhat.com/en/about/press-releases/red-hat-
| and-c...
| dralley wrote:
| >RedHat acquired CentOS, saying that it would be good for
| CentOS[1].
|
| >RedHat shut CentOS down.
|
| It should be noted that six years passed between point A and
| point B, during which time Red Hat did invest quite a lot of
| additional resources in CentOS. Red Hat did not acquire
| CentOS and then immediately shut it down.
|
| CentOS Stream is also not a wholly different thing from
| CentOS, although it is obviously not exactly the same thing.
| throwaway562if1 wrote:
| Red Hat had given a lifecycle for CentOS 8 with an EOL in 2029.
| IBM acquired Red Hat, and promptly announced they were reneging
| on this schedule. Given that the primary draw of CentOS/RHEL
| are long-term, reliable, well-supported, stable operating
| systems, users were... displeased.
|
| CentOS stream is primarily intended to onboard users onto RHEL,
| which is undesirable when nobody trusts Red Hat to keep their
| word now.
| op00to wrote:
| > Red Hat had given a lifecycle for CentOS 8 with an EOL in
| 2029
|
| I thought that neither Red Hat nor CentOS foundation gave a
| lifecycle date for CentOS 8. Can you help me find that
| lifecycle statement?
| yjftsjthsd-h wrote:
| https://web.archive.org/web/20201101131417/https://wiki.cen
| t...
| op00to wrote:
| Thanks! Can we see who updated the wiki? If it's some
| random person, then I'm not sure it's quite the smoking
| gun I'm looking for. If they are someone more closely
| associated with the project you'd expect to made
| decisions about this stuff, then that is very useful to
| know. Thank you!
| tuna74 wrote:
| It seems that page was written by Christoph Galuschka
| which was not an Red Hat employee at that time.
| stonogo wrote:
| Christoph is a volunteer, but definitely part of the
| CentOS team, and in fact was a member of the wiki admin
| group: https://web.archive.org/web/20200721015106/https:/
| /wiki.cent....
|
| I suppose people are trying to claim this wasn't actual
| CentOS policy, but it was, and when the project abruptly
| decided to truncate eight years of announced support, at
| no point did anyone involved deny this was a change.
| mardifoufs wrote:
| One of the biggest issue is that they pulled the rug on the
| support window. The last release started out with 10 years of
| support, but they walked back on that when they announced the
| end of regular CentOS and reduced it by more than half.
| op00to wrote:
| > The last release started out with 10 years of support, but
| they walked back on that when they announced the end of
| regular CentOS and reduced it by more than half.
|
| I thought that the "10 years of support" which was customary
| w/ CentOS wasn't applied, but neither Red Hat nor CentOS made
| specific announcements that CentOS 8 would have 10 years of
| support. People believed that CentOS 8 would have 10 years of
| support because of what was done in the past, but that's
| always subject to change.
|
| If, however, there were direct statements from Red Hat or
| CentOS that CentOS 8 would have 10 years of support and then
| they changed that - that's moving the cheese for sure.
| mardifoufs wrote:
| I think you are right. I haven't been able to find any
| direct EOL date from RH even at launch. It seems like it
| was mostly people just assuming (for good reasons, but
| still just assuming) that it had the same EOL.
|
| Though there are some gaps on the Wayback machine that
| makes it hard to find some centos8 related posts at the
| time it launched, but I'd be surprised if the eol wouldn't
| have been announced elsewhere too.
| behnamoh wrote:
| Well, Redhat has to make money somehow, so this decision is
| understandable.
|
| To me, open-source is about the open, transparent "culture" in
| which you commit to develop, not about putting things out there
| for free (as in free beer). Too many companies already benefiting
| from open-source packages (e.g., OpenCV) without giving anything
| back to the community.
| martinky24 wrote:
| "Acquire competitor, just to shut down competitor" is a pretty
| gross (and monopolistic) business practice. So that's a
| relatively crass way of looking at it.
| behnamoh wrote:
| "Not acquire competitor, and have to shut down your own firm"
| is a more crass decision.
| randombits0 wrote:
| Perhaps if you need to acquire and shutdown your
| competitors, you should shut down your own firm, or at
| least pursue a different strategy. Monopolistic business
| strategies are crass.
| RamblingCTO wrote:
| Leave out the "cr" and I agree
| yjftsjthsd-h wrote:
| RH did great financially for many years while CentOS was
| around; do you have some reason to claim that it was an
| existential threat?
| monkeywork wrote:
| because having CentOS lead to Oracle Linux being a thing
| which allowed big competitor to offer what was
| essentially 100% compatible product to your own while
| undercutting your support costs.
|
| I don't think RHEL/IBM cares about the small losses on
| CentOS/Rocky/Alma/etc what they found was hurting them
| was companies like Oracle
| yjftsjthsd-h wrote:
| I don't think that's correct; AFAIK OEL has always pulled
| directly from RHEL sources. That is, they were a sibling,
| not a downstream of CentOS. I am open to the idea that
| CentOS was basically collateral damage as Red Hat
| attempted to block Oracle, but that's not the same thing.
| dralley wrote:
| >"Acquire competitor, just to shut down competitor"
|
| There was 6 years in between those two events, and by all
| accounts CentOS got much better post-acquisition.
|
| There is no "just" here. Originally it was considered a good
| idea, and (years) later they changed their minds.
| jofla_net wrote:
| Agree and wish there was something that could be done against
| such business practices, but it is indeed difficult to
| regulate.
|
| Over the years I became aware that the acquire-extinguish
| pattern was definitely not just a coincidence, specifically i
| remember disney bought up some 'IP' just to litigate against
| some adjacently-related online fan game in the UK in order to
| shut it down and 'acquire' its captives, over to a similar
| product they already owned. Sorry I looked for the exact
| reference but cant find. There are countless other stories if
| you look though.
|
| This all came full circle when I was 'enlightening' a young
| relative who had just finished business school, or rather she
| 'learned' me. Turns out this acquire/extinguish game is like
| a whole 100-level course in <pick-your-business-school-of-
| america>. Who knew.
| bogwog wrote:
| > Well, Redhat has to make money somehow, so this decision is
| understandable.
|
| RedHat has been making money for decades. The Centos rug pull
| was just a way to make more money at the expense of their users
| and the larger open source community.
|
| It is impossible to justify a rug pull. By definition, it is a
| hostile, one-sided, trust-destroying, and underhanded move.
| pksebben wrote:
| I found it notable that the linked RHEL post had zero mention
| of the _why_ of it. Seems like a glaring omission.
| op00to wrote:
| Can you define a rug pull?
| forkicks wrote:
| Promising to support an OS for 10 years then cutting that
| support to just 2 out of the blue?
| op00to wrote:
| The question I'm trying to answer is who promised what,
| where was that published, and when was it published. If a
| squirrel promised me 10 years of support, that's
| different than a CentOS maintainer making that same
| promise on the wiki.
| jahlove wrote:
| The 10 years of support on CentOS 8 was published on
| centos.org's wiki:
|
| https://web.archive.org/web/20201101131417/https://wiki.c
| ent...
|
| Red Hat's explanation was something along the lines that
| it was a wiki and not guaranteed to be accurate? I don't
| think editing was open to to people outside of the CentOS
| org.
| Kaytaro wrote:
| Apparently not an equivalent amount of money to the value
| they feel they've provided. And honestly given the
| communities response, I think they're probably right. I mean
| if you think about it there's no reason someone using Centos
| for a proper use case wouldn't be fine moving to Centos
| Stream, unless they were getting some value out of Centos
| production-friendly releases. Vendor compatibility and LTS
| patches and updates take a big team to maintain, someone has
| to pay for that and I feel like many were just using Centos
| when really they should be using a supported enterprise
| distro.
| nonameiguess wrote:
| Frankly, I think this kind of thinking is short-sighted
| quarterly corporate bullshit almost certainly done by IBM and
| Redhat itself would never have done it (and most of the people
| who were Redhat in those days left to work somewhere else). How
| many corporate environments the world over are running on
| Redhat, paid Redhat, because the engineers there came up in the
| Linux world learning free Redhat and were able to continue
| using CentOS at home or in their dev environments? That sort of
| cradle-to-grave brand identity with people who eventually
| become high-level decision-makers and money controllers is
| invaluable, but the value is also impossible to quantify,
| accountants never se it, and instead just see people trying to
| use all of their hard work for free.
|
| Yet somehow even Pablo Escobar understood this and threw away
| billions just giving money to poor people to keep cities on his
| side. I'm not even going to say IBM's basic business model of
| making shit that works, doing at least some complex things
| reliably and well back when that was very difficult, is
| invalid. But it is fundamentally different to Redhat's business
| model, which was simply cultivating a lifelong love of their
| product in the minds of its users. It's like the Army acquiring
| the Red Cross. They work in a lot of the same places doing
| overlapping work and no doubt a lot of corporate synergy could
| be achieved and administrative overhead eliminated, but it
| would irreparably destroy a century and a half of goodwill and
| brand identity. Exactly the kind of strategy you'd expect from
| people whose decision consequence horizon extends no further
| than the next three reporting periods.
| iseletsk wrote:
| You can get a few more years of CentOS7 supported from TuxCare
| https://tuxcare.com/extended-lifecycle-support/centos-7-exte...
| 8organicbits wrote:
| > Our research has identified numerous critical and high-risk
| vulnerabilities that your vendor hasn't patched.
|
| This sort of language strikes me as fear-mongering. I can't
| tell which issues they have patched in CentOS7 that otherwise
| remain unpatched. Anyone know what they are talking about?
| chasil wrote:
| Does it also mark the end of IBM's RedHat as the OpenELA assumes
| the authoritative role?
|
| That's likely the best possible outcome.
|
| https://openela.org/
| BSDobelix wrote:
| This is really the time to make a decision, do you really need
| support..ehm sorry insurance? Then RedHat/Suse/Oracle if not,
| choose a trusted community distribution like Debian.
| jtriangle wrote:
| We moved everything to debian when Centos moved to a stretch
| release for 8, no regrets whatsoever, zero difference in
| stability, solved some niche hardware support issues.
|
| Writing was on the wall back then tbh. Redhat can enjoy it's
| legacy bubble, I'll continue to enjoy not paying for free
| software.
| BSDobelix wrote:
| >I'll continue to enjoy not paying for free software.
|
| Well we pay for it (the project and different other software
| projects..and even a completely different os) but in
| donations instead to pay stakeholders and "managers". ;)
| dylan604 wrote:
| I am curious about what the expense of support gets you that a
| typical IT person could not find on some forum somewhere
| online.
| nolist_policy wrote:
| Getting someone to actually fixing bugs in the distro,
| without begging on some forum or whatever.
| BSDobelix wrote:
| That's why i wrote insurance, not insurance for the
| installation but your job position AKA someone else has to
| fix the problem ;)
|
| Same as: No one gets fired for buying IBM (if your really
| old...like me)
| dylan604 wrote:
| I thought you just meant insurance as in it's a huge profit
| center, so it's pushed knowingly that the vast majority of
| people will never use it. Notice the word use instead of
| need.
| BSDobelix wrote:
| You need insurance in some businesses, or sht will fall
| exclusively on you...even if it's not your fault (cover
| your as), insurance/financial sectors etc...
| sigio wrote:
| Same here... we were already running lots of Debian and Ubuntu,
| and have made the decision to use Debian by default for
| everything new, and migrate to Debian everything that still has
| to be around in a couple of months. The rest can be killed of
| when it hits the EOL for CentOS of Ubuntu 20.x
| 0xbadcafebee wrote:
| Nobody thinks they need insurance until their house catches
| fire
| BSDobelix wrote:
| Bad comparison, no one will pay for your downtime/leak, but
| you can blame redhat/suse/oracle for it. Aka you don't loose
| your job, but the house is still burned down.
| ebiester wrote:
| My understanding is that the real problem is twofold:
|
| First, some proprietary software only supports a subset of
| distributions. Debian is rarely on that list. RHEL, for some
| time, has been a safe default.
|
| Second, IT organizations only want to support one distribution
| when at all possible.. As such, RHEL and CentOS made a lot of
| sense. RHEL and Debian means twice the work.
|
| That said, it's going to have to change. $349 for every 2
| VMWare images (as I understand it) plus $2499 for every 2
| processor sockets adds up.
| throw929612 wrote:
| Big thanks to the CentOS project, which probably did as much to
| improve the size and health of the EL ecosystem as any other
| single factor, and did much of that work long before any official
| association with Red Hat.
|
| Much respect for the tenacity required to figure out how to
| bootstrap RHEL without its build system.
|
| (Shout out to White Box Enterprise Linux as well!)
| bityard wrote:
| Scientific Linux was one of my favorites for a while. I
| stumbled onto it back when some important CentOS leader went
| missing and the future of the whole project looked uncertain.
|
| SL7 is still supported until June 2024. The maintainers decided
| not to do SL8 and are now contributing to AlmaLinux instead.
| bluedino wrote:
| For better or for worse, this has caused a lot of software
| vendors to drop RHEL/CentOS support. Many have started to offer
| Ubuntu support in it's place.
|
| Most of them didn't even try to support stream. I'm not sure what
| the process behind that was.
|
| CentOS was free, which is why we used it. Sure, our SAP boxes run
| RHEL but the other stuff doesn't. We started moving a lot of
| stuff to Ubuntu as well.
|
| Now, Ubuntu is by no means perfect, snaps are annoying, etc. But
| Red Hat really angers me with their decisions during the last few
| years.
|
| One example is removing OpenLDAP:
|
| _The openldap-servers package was removed in Red Hat Enterprise
| Linux 8. The openldap-clients package is still shipped though.
|
| If you use openldap-servers in Red Hat Enterprise Linux 7
| (RHEL7), you need to consider to change your LDAP server from
| OpenLDAP to Red Hat Directory Server (RHDS) in Red Hat Enterprise
| Linux 8 (RHEL8).
|
| RHDS is provided as an add-on subscription in RHEL8, so you need
| buy the subscriptions in addition to RHEL subscription._
|
| https://access.redhat.com/solutions/3816971
|
| Additionally, Red Hat support is so bad these days. It almost
| reminds me of Microsoft Technet forums of the past. Random
| 'techs' offering copy-paste solutions and the same bad
| information.
| ramesh31 wrote:
| >But Red Hat really angers me with their decisions during the
| last few years.
|
| Probably because Red Hat is no longer making those decisions
| op00to wrote:
| > this has caused a lot of software vendors to drop RHEL/CentOS
| support
|
| Can you list a few? It's good to keep up to date on how this is
| changing. Thanks!
| bluedino wrote:
| Ansys for one
|
| https://www.ansys.com/content/dam/it-solutions/platform-
| supp...
|
| Veeam doesn't support CentOS stream or 9, there's been a
| bunch of things here and there. I notice many are moving to
| Ubuntu. I had to go through all of our vendors last year, and
| the nice thing about CentOS was almost everyone supported it.
| Now there's no 'gold standard'.
| tuna74 wrote:
| It says they support RHEL:
|
| "Red Hat Enterprise Linux (RHEL) 7.8, 7.9, 8.1, 8.2, 8.3,
| 8.4, 8.5, and 8.6 (64-bit)"
| piperswe wrote:
| It supports old RHEL, but not 9.
| fgonzag wrote:
| So not stream (OP never stated RHEL, he stated many
| packages not supporting stream) AND it doesn't support
| RHEL 9 which came out almost 2 years ago.
| bananskalhalk wrote:
| If you kept your RHEL 8.x server updated, it would have
| been on 8.7 for over a year.
| syntheticnature wrote:
| Part of it was that CentOS Stream reversed the CentOS stability
| level vs. Fedora; a lot of the vendors targeting CentOS/RHEL
| were looking for something fairly fixed. CentOS made sure they
| could also support folks who didn't want to pay for RHEL.
| bbarnett wrote:
| I am always baffled by people using ubuntu because "free".
|
| I get the desire if you want the paid stream. EG, an
| alternative to Redhat or SuSE as a paid stream.
|
| But if you're going to use Ubuntu, why put up with the snaps,
| the commercialism, the app store, when you can just use debian?
|
| Every time I hear a reason why, it makes little sense to me.
| Even though 95% of Ubuntu is Debian, and Ubuntu wouldn't exist
| without Debian.... people use it.
|
| Ah well.
| dylan604 wrote:
| If I'm not running a desktop, why would I consider running
| Ubuntu at all? I feel the same about people offering a
| kneejerk suggestion of Ubuntu as when I'm told to use Docker
| without actually knowing anything about my needs. Just
| because I'm wanting to use Linux does not mean I need Ubuntu.
| Just because I'm deploying code doesn't mean Docker is the
| solution. But 99% of the time I talk to people, it's all
| Docker this Docker that.
| michaelt wrote:
| There is a certain practicality in running the same thing
| on the server as on your developers' laptops.
|
| Ubuntu and Debian are pretty similar, and using Debian gets
| rid of things like snap, which I'm glad to be rid of - but
| it adds an extra level of "well it works on my machine"
| which I'm not glad for.
|
| If it's going to be hard to get that special different
| version of Java to work on the server, it should be hard to
| get it to work on the desktop too :)
|
| Of course the rise of containers has made a lot of this
| stuff less relevant.
| dylan604 wrote:
| If the headless server has a UI process running that is
| absolutely wasted resources. Having the same environment
| for the dev's laptop and the server seems like such a
| waste of resources. The two things are not the same, so
| don't try to fit the square peg in the round hole.
| Whatever these differences are, they should be able to be
| determined and accounted for in the deployment.
|
| To me, we've gotten a bit lazy and a bit too focused on
| the wrong things. I feel like this happened when we
| started running javascript on the server. That was such a
| shock to the system and all sorts of things had to be
| done since it just was not the normal way of doing
| things. Someone decided it'd just be easier to clone the
| dev's system and deploy that as a server. Like what the
| actual... I also totally feel the same way about running
| a Windows Server. Like why on gawds good earth would you
| ever think that was a good idea?
| chromakode wrote:
| Ubuntu has a bunch of non-GUI server flavors. It's a
| common base image for cloud VMs, similar to Debian.
|
| https://ubuntu.com/download/server
| claytongulick wrote:
| I've found the Docker discussion is seen through a better
| lense when you talk about the tech it's running.
|
| For polygot/hybrid cases where you have a smattering of
| different languages and supporting technologies/services,
| docker makes a lot of sense.
|
| If you're all in (for example) on nodejs with a monorepo,
| it probably doesn't - you're just an "npm install" away
| from deployment.
|
| Whenever I really dig into the docker passion, I usually
| find devs who are frustrated by having to manage a million
| little details to get the dev environment going.
|
| If the language/stack takes that pain away, docker loses
| most of its value.
| peddling-brink wrote:
| Because 15 years ago Ubuntu shipped them distro CDs in the
| mail for free, and Debian was an entire dvd to download,
| slowly.
|
| Their more clever friends were compiling Arch, but who has
| time for that?
|
| I say this tongue in cheek, as a personal lived experience.
| jzb wrote:
| This isn't wrong, really. Canonical, for all its flaws,
| correctly identified a lot of problems with Linux early on
| -- distribution, usability, application availability -- and
| then solved them. (Or made strides, anyway.)
|
| It also wasn't shy about marketing and made an effort to
| have a welcoming community whereas other communities were
| much less friendly to outsiders.
|
| The free CDs and Canonical's "ground game" in the face of
| the Red Hat Linux diaspora made it much more successful
| than other "Debian, but easier" efforts before it.
| lpapez wrote:
| As a long time Ubuntu user, I figured I'd try Debian a month
| ago for the same reasons you listed. It's supposed to be 95%
| the same, so why not. Fresh install, my bluetooth headphones
| didn't work. Reverted back to Ubuntu and they worked right
| away.
|
| That's my reason for using Ubuntu instead of Debian - I
| simply don't care enough to bother with these small things.
| not2b wrote:
| Yes, Debian prioritizes software freedom, and Ubuntu starts
| from Debian but prioritizes having the hardware actually
| work, so while Debian might be just fine and quite stable
| for servers, probably not the best choice on laptops for
| most.
|
| Edit: perhaps this situation has improved for Debian now
| that non-free firmware support isn't hidden, but it's been
| a while since I installed Debian on a new machine.
| smaudet wrote:
| Except Ubuntu did what Fedora/RH didn't used to do - break
| my shit.
|
| Everything would work great, then _bam_ giant updates,
| everything broken (bluetooth, wifi, video, graphics cards,
| audio), have to start from scratch learning some new fad
| Ubuntu folk had invented.
|
| When I _want_ to tinker or try out cool-new-tech, then
| sure, a platform like Ubuntu is great - semi-stable, half-
| working software.
|
| When I don't, Debian/CentOS are hands down just better.
| Sure, I have to configure my bluetooth, but I have to do it
| _just once_ _and it never breaks_.
|
| Fedora used to be pretty great, then some personalities
| with inflated opinions of themselves started ruining the
| relative stability.
| Thaxll wrote:
| There are many reasons, LTS, security kernel patches etc ...
| Ubuntu is not 95% Debian, as a matter of fact Debian got LTS
| only recently, before that you were out of luck.
|
| I still have bad memories of going to the DC with a USB stick
| with network driver on them because the Dell server with
| Debian on it would not ship with non proprietary firmware /
| drivers.
| squarefoot wrote:
| This is a thing of the past.
|
| From the firmware wiki at debian.org:
|
| "The Debian project took the decision in October 2022 to
| create a new repository component non-free-firmware, and
| include its content on installation media for the upcoming
| Debian 12 release (bookworm) to make things easier for our
| users. This change was implemented in time for the bookworm
| alpha 2 release of debian-installer in February 2023, and
| all d-i releases and daily and weekly images since then all
| include firmware."
|
| Previously one had to either download the needed firmware
| separately, or a bootable image containing it so that it
| was accessible during install. Many users having problems
| with proprietary hardware didn't know they could just grab
| the install image with included firmware at
| https://cdimage.debian.org/cdimage/unofficial/non-free/cd-
| in... But I blame Debian for this because their site
| historically has been excellent at hiding stuff.
| bluedino wrote:
| It's supported, and it's known.
|
| Ubuntu = Linux for a lot of people these days, kind of like
| Red Hat was to us old guys.
| angry_moose wrote:
| > Additionally, Red Hat support is so bad these days. It almost
| reminds me of Microsoft Technet forums of the past. Random
| 'techs' offering copy-paste solutions and the same bad
| information.
|
| Yeah, that's been my experience. We had a bad driver package
| from them completely hose one of our prod systems.
|
| It took 3 days and multiple calls from our CTO to get anyone to
| seriously look at the issue despite being on the top level
| support level and it being a Severity 1 issue. The whole
| "Responses within X hours" thing is a joke when all they give
| you is "Have you tried rebooting?" or "We're still looking into
| it" (technically those are response!).
| yjftsjthsd-h wrote:
| Well that explains a lot. Historically, the basic idea as I
| understood it was that you could have the software for free
| (CentOS) and they didn't really mind because they knew they
| were selling support. If the support is worthless, then they
| have to try and squeeze money out of the software, which
| explains their behavior.
| hinkley wrote:
| Squeezing money out of effectively unsupported software is
| not sustainable.
|
| Sounds like someone is trying to get their investment back
| before dumping the whole thing.
| wpm wrote:
| Dumping? This is IBM we're talking about. They'll ratchet
| up the price to fewer and fewer customers, trying to keep
| themselves in that pocket where they're too useful and
| expensive to move away from, but still able to hold the
| irons to their customers.
| dessimus wrote:
| The SLA is to respond within X hours, not resolve. So when
| the SE sends an email that says: "I'm the owner of the case
| and will reach out after looking at the notes." They have
| complied with the SLA.
| anbotero wrote:
| It is revolting to be blocked and not get any help,
| everyone is anxious, specially when your main product is
| down (money), but seriously, I just think nobody reads
| their SLAs and just complains until someone resolves. I
| suppose it's a rule of life no one reads terms (yet try to
| enforce them somehow), but usually their attitude give me
| the creeps.
| wkat4242 wrote:
| Yep unity too, they only support up to centos 7 and Ubuntu.
|
| I don't really like using snaps for everything so this is a bit
| annoying. But at the moment I'm mainly devving for VR so i need
| to be on Windows anyway.
| palemoonale wrote:
| Why not SAP on SLES? Its a defacto standard on both sides of
| the pond.
| bluedino wrote:
| Because corporate is in bed with IBM? Not sure.
| dwitcher wrote:
| It's interesting to see the different strategies people are
| adopting. I recently came across TuxCare's Extended Support for
| CentOS 7, an interesting stopgap for those not ready for an
| immediate RHEL shift.
|
| https://tuxcare.com/extended-lifecycle-support/centos-7-exte...
|
| Somewhat surprisingly, it's also pretty affordable. It's one of
| the few options like this I've seen, though I'm curious if there
| are others that are around this same price.
| dannyz wrote:
| A lot of package managers that distribute binaries (e.g. conda-
| forge) rely on CentOS 7 because of the relatively old glibc
| version available, I wonder what all of these projects are
| planning on moving on to
| spapas82 wrote:
| This is a very important milestone for us since we have a lot of
| Centos 7 servers and can't go to RHEL. From my point of view,
| there are more or less three solutions:
|
| a. Go to Debian (or ubuntu server etc); probably the most
| difficult since everything will be different b. Go to a fresh
| Almalinux or Rocky 9 installation; also very difficult since
| there's a lot of stuff to be moved c. Try to use in-place upgrade
| using Leapp or something. There are some guides for this
| (https://wiki.almalinux.org/elevate/ELevating-CentOS7-to-Alma...)
| but I'm really not sure how good this would work on a live
| production system.
|
| I'd definitely prefer the solution c, if I can confirm that it
| works of course. Has anybody tried using leapp to upgrade Centos
| 7 to Rocky/Alma ? What was your experience? Do you feel that it's
| worth researching that path or it's probably better to move to a
| greenfield installation?
|
| Thank you for any insights!
| dclaw wrote:
| For what it's worth, we're trying to do a lot of our server
| upgrades with the Elevate scripting to Almalinux, but man can
| it be a pain. We have a 30% success rate in testing, and even
| when it goes right it tends to be 2-3 hours of downtime. The
| alternative though is to rebuild every server on spare hardware
| and manually migrate data and configurations over. So it's
| still a better option once we can figure it out. I'm hoping to
| get downtime <1hr and >90% success rate before we start really
| pushing through these by April.
| bennyvasquez wrote:
| That's a bummer! I know there's a few places that have used
| it on the 50k+ scale, so once the kinks for your environment,
| it should be great. If there's anything that can be done to
| improve the script, we'd love to help! Feel free to join the
| chat and share what's up in ~migrations.
| scruple wrote:
| We briefly looked at it. We decided to just move everything to
| Ubuntu. It's been a lot of work, and taken a lot of time, but
| ultimately we feel that it's been worth it. Ubuntu isn't
| without it's own problems but we're much happier today and feel
| that we're more future-proof for it.
| semessier wrote:
| I believe the CentOS EoL will impact the re-builders albeit this
| complex. Not everything is GPL, they need the sources that may be
| a huge issue. To a lesser extent, probably the build script in
| the source rpem helps.
| thrusong wrote:
| I only have a half dozen web servers, but I used CentOS for
| everything so I'm sad it's the end of the line.
|
| That being said, I've recently completed moving entirely over to
| Debian and there's just something about it I love so much more...
| unethical_ban wrote:
| CentOS stream still exists? So the title should say CentOS 7?
| tuna74 wrote:
| This is the last CentOS, so the title is technically correct.
| CentOS Stream goes on however.
| tb_technical wrote:
| Of course they want to EOL CentOS. It was a serious competitor to
| RHEL
| INTPenis wrote:
| I'm taking this opportunity to migrate a few k8s clusters from
| CentOS 7 to CoreOS instead. Which is a big move because it means
| that instead of using Ansible to setup the k8s services we put
| everything into Terraform and Ignition. Or cloud-init if you want
| to use Talos or Flatcar.
|
| Other than those big clusters we have some CentOS systems spread
| out for minor services and those we're migrating to either RHEL
| or Fedora, depending on circumstances and requirements.
| __s wrote:
| I spent a long time preparing for this because for a managed
| postgres service there's a hiccup:
| https://wiki.postgresql.org/wiki/Locale_data_changes
|
| > in glibc version 2.28, released 2018-08-01, a major update to
| the locale data has been included, which can potentially affect
| the data of many users
|
| Migrating to rhel8 was being considered, but since locale changes
| are inevitable, it made an opportunity to have us pivot to ubuntu
| refracture wrote:
| Was reneging on CentOS 8's support cycle what led to that Red Hat
| developer for individuals license that allows 16 hosts? I haven't
| gotten a good sense of if they introduced that to placate some
| people or if they had planned on it.
| usernamed7 wrote:
| i really liked CentOS - it was definitely my goto distro for
| spinning up a server. Yum is so much saner than what ubuntu is up
| to. Thankfully now, not something i have to do with as much - i
| run a website with DB and don't even know what the distro is - a
| detail i'm glad to leave to abstractions and platforms to manage.
| throwaway0x4 wrote:
| Really end of an era. First CentOS then the anti-White racism
| leak. Couldn't have come at a worst time for RedHat.
___________________________________________________________________
(page generated 2024-01-05 23:01 UTC)