Will there be newer versions of CentOS? We have heard rumors that version 8 will be the last one. We are concerned with using an OS that will loose support in the future. Thank you.
Not just rumours. CentOS 8 dies at the end of this year. CentOS 7 has until the end of 2024. RH are introducing “CentOS Stream” which is what will be in RHEL in the next release. It has been unkindly referred to as beta software.
The traditional rebuild of RHEL will continue under other guises. There has been a long standing release at Springdale. Since RH’s announcement Cloud have produced the Alma release. There is also a new project called Rocky that hasn’t yet released a full version but is working on it.
Thank you for your response Rich. I have heard that Stream is beta releases of RH — rather distressing. Is this a proper characterization?
Thank you for your response Martin. We should probably consider moving to the alternatives that you mentioned or Ubuntu. CentOS was no longer a Community effort after RH was bought by a propriatory company.
Stream is effectively a rolling early release of the next point release of RHEL. The packages in stream are fully tested and have gone through QA. They are not beta releases.
The disadvantage of Stream is that it doesn’t have the full 10 year support of RHEL and doesn’t have the full binary compatibility to RHEL.
P.
No, it is not a “beta”. That said, getting people to stop saying that has been unproductive. Mostly, therefore, I’d encourage you to try it and draw your own conclusions.
CentOS Stream is more directly integrated into the RHEL development cycle than CentOS Linux was, getting fixes faster, and providing an actual contribution model that didn’t exist before.
Thank you for your response Pete. I prefer to avoid working under the unbrela of propriatory companies.
“Proprietary company” sounds like a nonsense. All companies do work for profit. This is true about current owner of RedHat, as well as it was true about RedHat as a company before it was sold to current owner.
The moment CentOS team started being paid by RedHat (long before RedHat was bought by current owner) was the moment _I_ should have told myself about CentOS “this now will not last long”. Luckily for me I already fled my servers to FreeBSD, – from Linux in general, not from CentOS in particular. But that is long different story.
Just my $0.02
Valeri
—
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
With all due respect, – and avoiding the names to not scratch against
“release,…” definitions, he is more correct in his feelings (that what you say) which I would formulate as “stream users are sort of Guinea pigs for RedHat releases”.
And mind that I have no emotions about it as my servers are FreeBSD for over a decade. And new number crunchers and workstations going Debian since CentOS ceased to be RedHat Enterprise binary replica was such a minor change…
Just my $0.02.
Valeri
You would be hard pressed to find many FUNCTIONAL differences between Stream and CentOS Linux // just as you would be hard pressed to find many differences between RHEL 8.2 and RHEL 8.3, for example.
Are there some differences? Sure.
If people don’t want stream, then by all means , use something else.
CentOS 7 Linux will be around until the RHEL 7 EOL .. CentOS 8 Linux will be around until 31 Dec 2021 and CentOS Stream will be around for %
years after the RHEL 8 Release. CentOS Stream 9 will be around until for 5 years after the RHEL 9 release.
It is what it is .. all the negative comments are not going to change it.
For people who can not accept this and live with it .. life is too short for so much negative emotions. Go places and use things that make you happy.
Thanks Johnny for calmly stating what is what. This exactly is where all statements about CentOS should end.
My comment was just to balance Pete’s as the truth between Pete’s statement and Carlos feelings is where I’m sure my comment pointed… No negative intended, just stating of the facts as they are perceived by some (many? – not many if to discount these who fled totally).
And as always: thank you personally and the whole CentOS team, everyone who worked on this project during last two decades to make it as great as we know and used it – as “binary replica of RedHat Enterprise Linux”. Your effort can not be overestimated, as well as the way to say it: a
“binary replica of RedHat Enterprise Linux” was always quenching any doubts in everyone I had to talk to – both technical people and non-technical ones. (Not anymore, sigh).
Valeri
—
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
Out of interest, do you think my statement is factually incorrect? If so, in what way?
P.
I guess I have to hide behind my “imperfect command of English language” ;-)
Though it most likely is factually correct, while being an opposing to Carlos’s statement of feelings, it did ask for a comment why Carlos’s feeling have the grounds to be such, and and thus it warrantied in me my addition of comment.
In other words, both of the following are true (IMHO):
A. Johnny’s rigorous statement of what CentOS now is (or yours, it doesn’t actually matter who rigorously states it, but Johnny’s seemed to really cover all aspects – maybe it’s just my reading though)
B. “CentOS is binary replica of RedHat Enterprise Linux” statement is not true as far as new releases are concerned, i.e. not true to build one’s future on it
But as everyone is agreed it is counter productive to ponder these things, I will end my side of it by reiterating:
As always: thanks to the whole CentOS team, everyone who worked on this project during last two decades to make it as great as we know and used it – as “binary replica of RedHat Enterprise Linux”. Your effort can not be overestimated, as well as the way to say it: a “binary replica of RedHat Enterprise Linux” was always quenching any doubts in everyone I
had to talk to – both technical people and non-technical alike. (Not anymore, sigh).
Valeri
That is a conflicting statement. What would you then use these days without having a “entity” to back the service up? Anyway its OT …
No, I don’t think so. I think a better characterization would be:
Rawhide is a development (beta?) release. Fedora is a stable release.
CentOS Stream is a stable LTS release. RHEL is a stable LTS release with semantic versioning of the distribution as a whole (and point releases which are themselves branches of the main release).
Once upon a time, Carlos Oliva said:
The vast majority of open source software is developed by companies like Red Hat/IBM (IBM was a significant Linux contributor long before they bought Red Hat; the original SCO lawsuit was about code IBM contributed to the Linux kernel). That’s not just true of Linux; a lot of FreeBSD
development is done by a few companies (sometimes imperfectly, as seen with the VPN mess just before FreeBSD 13 release).
I would love to get to the point where I feel comfortable saying that Fedora Rawhide is a perpetual beta. The current status is more like “perpetual alpha” — in fact, Fedora dropped our “alpha releases” in favor of applying the same criteria to Rawhide continuously, so it’s not just an analogy. But we do branch from there for a stabilization period, from which we have beta and then final releases of Fedora Linux.
—
Matthew Miller
Fedora Project Leader
Il 2021-04-27 15:05 J Martin Rushton via CentOS ha scritto:
Hi, I am not sure this is the place to ask, but lets try… If the Springdale release is a 100% RH clone, why do different teams
(Alma and Rocky) are trying to re-package the same 100%
binary-compatible RH clone?
Thanks.
Simply because each one of these projects obviously wants to remain independent from the others, otherwise it would request to join forces with one of them.
Why they want to remain independent? Due to their vision and internal structure. Check each project’s details.
Each project’s future will be judged by team responsiveness, prompt release availability, product reliability and eventually user adoption.
All that, in turn, are very much dependent on community involvement and project management & financing.
Cheers, Nick
By the way, I think that CentOS, before it was “absorbed” by Redhat, could/might have addressed the community for fund raising, rather than abandoning the project to RH, which, as others have mentioned, was an unmistakable sign of upcoming CentOS EOL as we had come to know it.
If the financing need was communicated correctly, I am very confident that financing would have been secured, e.g. by using a public fund raising platform, due to CentOS huge install base and community.
Any of those current (or future) projects that might prove successful enough to become CentOS successor (as a RHEL binary twin, and not as Stream), should use the community financing model, in order to avoid CentOS fate.
My 0.01$ :)
Nick
So CentOS when it was brought into Red Hat was not a company or organization. It was much more like some sort of libertarian anarchy where a group of people came together in an IRC channel and did what they wanted to get an OS out. Many of these people were consultants who had daily clients and did this as a night gig to help those clients and others but it wasn’t a single company which could accept funding. Things like the domain name, trademark, etc were in the name of one person due to a past historical problem.
That problem was that CentOS did once have an organization to collect funds, but it had been mismanaged. This caused all kinds of problems with the community and groups which had given funding and there were legal and tax problems due to it. In those cases, it is better to ‘walk’ away from the organization as resetting it up usually triggers audits and additional paperwork to show the people involved now are no way the same ones before. So instead things were set up with most of the items owned by individuals.
—
Stephen J Smoogen.
you think you can fund something like that with a bake sale or so?, maintaining a separate distro for the same thing is VERY expensive
Speaking of financing, it’s common for non-profits such as churches and other organizations to have an annual budget review that is put together to lay out the budget, and expenses to see how each cost is broken down.
Is there an equivalent budget page that annual review of expenses for CentOS / Stream?
If there isn’t then perhaps it would be beneficial to have such a page, something that lists out the line by line expenses, so that everyone is aware of how expensive that maintaining a distro truly is.
I agree, of course, yet it seems that those who decide to maintain a separate distro are decided to do so and obviously are confident that they can handle funding somehow.
Nick
I think the budget needed would be in the millions, 10’s of millions…
that is hard to do with a gofundme page or a bake sale on an annual basis. if it only was a 100k or couple of 100k, IBM and others wouldn’t care to keep it going I think, besides funding, there were organizational reasons too I believe.
This is true within the narrow scope of just CentOS/RHEL, but if, for example, you rely on ELrepo for kmods for hardware that Red Hat dropped support for, you’ll be sadly unable to use those kmods on Stream (elrepo isn’t supporting Stream[1]). There will also be inconsistencies with other third party repos and commercial software that focus exclusively on RHEL when Stream gets major version bumps ahead of RHEL. Certainly it will be an opportunity for those vendors to get their product working on Stream, so they’ll be prepared for the next RHEL release. But this is why people are calling it a beta test for RHEL. Yes, Steam running with only their core repos and software from within CentOS is tested and QA’d. But if you want to use Stream in a larger software context, be prepared for missing support and unexpected breakages. The only use I will consider Stream for will be as a test for upcoming RHEL releases, not as something I will ever want actual users to touch. (And maybe that’s ok)
The other concern for me is security. I’ve not had time to track CVE’s in detail, but even a cursory look shows there are CVE’s which have been fixed in RHEL8.3 kernel releases which are still not fixed in the latest Stream release [1] (which if truly upstream of RHEL should presumably get the fixes first before they are backported to the RHEL point releases), and others where the fixes eventually appeared weeks or months later [2]. I know CentOS makes no claims as to security fixes etc, but at least with RHEL->CentOS Linux rebuild, one could reasonably expect that when a security issue was fixed in RHEL, CentOS would have the same release and fix out the door within 24-48h. With Stream we are seeing delays of months for security fixes in the kernel that have been released in RHEL. The only time the Stream kernel is comparable to the RHEL kernel from a security fix viewpoint is once every six months on the day the next point release fork occurs. This all indicates Stream is not of production quality and hence why people associate / use the term beta software.
[1] CVE-2020-25705
[2] CVE-2020-29661
As was stated at Red hat summit though .. while Stream will not be a copy of the downstream RHEL code anymore .. it WILL BE extreamly similar to RHEL + a couple months. In fact at 8.4 release .. Stream is very similar t0 RHEL 8.4 with NO WAITING. CentOS Linux 8 getting upgraded to the 8.4 source code, tested, isos created, etc .. will take a month or so, Stream already has all that content in it RIGHT NOW.
I think that is a positive , not a negative.
CentOS NEVER made security fix claims :)
The kernel dies currently lag behind slightly .. but this is something that will be fixed when the full process is implemented for stream.
Right now, because of secure boot signing not being automated completely
.. and because of different keys for CentOS and RHEL .. the kernel process is manual, not automated.
But, this process is being worked on. How many people actually really update their kernels and reboot on the day those updates come out .. or the 1 or 2 days later that CentOS currently takes to build them?
But yes, one does need to look for how to fix those issues.
Yes, this all sounds nice, but not good enough if you put yourself in my shoes when I suggest my user:
A. “I am going to install CentOS which is binary replica of RedHat Enterprise”, so whatever works on RedHat Enterprise will work on CentOS
[implying my reputation behind merely an ability to install binary packages and common sense of what binary files are there on both systems in questions]
B. There is CentOS which is promised (I am borrowing your phrasing here)
“WILL BE extreamly similar to RHEL + a couple months”
but in the second case I can not put my reputation at stake and finish my phrase with “whatever works on RedHat Enterprise will work on CentOS”.
So my latest phrasing to my users/machine owners – which I can put my reputation behind – is:
I am going to install Debian for you, and as in the past whatever works on some Linux I should be able to make work on your Debian machine.
The last I can put my reputation behind, and my user knows it might not be as simple as installing binary packages known to work on RedHat Enterprise, and knows there will be some effort/time on my side involved.
My apologies for breaking my promise to stop pondering the issue ;-(
Valeri
And as I have said several times .. if you (or anyone else) thinks something works better or Stream does not work for you, that is fine. Use what you want or like.
We make what we make. If one can use it, great. If not, that’s great as well.
This is opening up the RHEL creation process in an unbelievable way to community involvement. I an proud to have been involved in mkae this process so open.
I think CentOS Stream is a much more community project that CentOS Linux ever was. I also think it is better for the open source community and Linux distros in general. For people whole don’t think this, we can agree to disagree. it does not make either of us right or wrong.
Maybe I am miss reading this sentence. Could you rephrase the “while Stream will not … anymore” please? Did something changed recently?
Thanks, Leon
Quite agree. For me, not too knowledgeable in these things person, this looks exactly what Fedoraa while ago was: huge opening of RedHat to wide open source community. Maybe Fedora didn’t live up to the expectation, then good luck to CentOS to live up to this expectation.
I hope, no one is offended by my – restricted – view of this, personal perception is just that and bound to be restricted to person’s knowledge ;-)
Valeri
—
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
Stream as compared to CentOS Linux is not RHEL source code downstream is what I should have said .. so what is released as CentOS (Steam now)
will no longer be a downstream build.
It will be released packages and very close to 8.4 content and right now.
I believe you are citing Johnny’s write-up, not mine, so your question should be directed to Johnny. Your mailer somehow messed the citation depth to appear what Johnny said as if it was I who said it.
Valeri
—
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
I don’t think that is the case, quite the opposite. Fedora is way more bleeding edge than RHEL/Stream, Fedora leads to a version that will form the basis of the next major version of RHEL. My feeling (without any real knowledge) is that the community involvement with Fedora was seen as a benefit and now they are doing the same thing with RHEL –
that community input into RHEL is via Stream.
It has been said a few times that Stream is, in effect, the distro that RH develops on: it used to be internal to RH, now it’s not. It was RH’s own internal rebuild of RHEL. Opening up this to the outside world allows other people (SIGs, spins etc.) to produce code on a level playing field with RH developers.
P.
You are right, my hand coordination is not so good anymore. it cutted one line too few :-)
—
Leon
Ah, okay. Thanks to clarifying it.
—
Leon
Why do you think that? Are RHEL (and CentOS) point releases backward compatible or not? If you trust point releases to work, why would you hesitate to trust a distribution that resembles an upcoming point release?
(And if you don’t trust point releases, why would you use the OS at all?)
Il 2021-04-30 06:55 Gordon Messmer ha scritto:
Because it very often break kABI compatibility, with 3rd party module heavily affected.
Don’t get me wrong: I understand that Stream is the way forward and that things are not going to change, and this is fine. But trying to ignore the key differences (shorter support, unknown upgrade from Stream-8 to Stream-9, broken kABI, etc) is not useful to anyone.
Stream is a *different* product, because is avoid (for the good or the bad) basically *all* things that make RHEL so special. And lets face it:
kABI and long/quality support from RedHat are the only two things which make RHEL special. Stripping them from CentOS will produce a very different product. And, as a side note, things break more often on Stream-8 then CentOS8. Maybe Stream only needs to mature, but it still a different product.
My personal opinion is that RH created Stream to give cloud vendors a place to experiment/repackage *before* adding that to the main RHEL
distro. Stream really does not seem targeted at small sites / “normal”
sysadmins, rather at large cloud vendors.
Which, again, is perfectly fine unless trying to disguise it as an
“almost-RHEL” distro. Regards.
Why do, you, people use “creative editing”? Cite the whole piece I said, and place your question there, don’t tear single phrase out of context.
Valeri
Sure .. so block kernels and build your own in that situation. Or use something else. There are always edge cases. There are millions of CentOS users. What percentage use 3rd party modules (other than nvidia drivers). There are some, and this would be a problem for those people.
So, IF another downstream distro works for you .. use it. Or use Debian or Ubuntu, or BSD. Use Alma or Rocky Linux. Buy RHEL.
Any number of solutions.
Il 2021-04-30 16:26 Johnny Hughes ha scritto:
As stated above, if this is the vision of Stream, fine. I am not arguing about the vision: while I don’t like it, my opinion is irrelevant.
But disguising Stream as “almost-RH” (a mantra repeated many times both here and in various blog) is plain wrong, and I genuinely don’t think it will be good for Stream.
And you know better than me that what you wrote above regarding the kernel is a double-edge sword: as you cope with security patches if the kernel is blocked? How do you cope with HP/DELL/Lenovo kmod needed to configure the RAID subsystem if using a rolling kernel? Did you notice that even RH-sponsored modules as kvdo were broken multiple times on Stream? If you are using VDO to access your storage and it suddenly is not usable anymore, how would you feel? What about ZFS on Linux users?
Do you realize this drastically reduces Stream fitness to bare-metal install (one of the main CentOS usage was as hypervisor)?
The correct answer is to buy RH: fine. But do not let Stream touch anything which require a kABI compatible modules. As said above, the Stream move is squarely addresses *cloud* vendor requests and needs. Again, fine. But please leave apart the RH comparison, this is not going to help Stream.
Again, don’t let me wrong: I wishes the best to Stream, and I will use it where appropriate. But “where” is much smaller today than yesterday. But this aside, I really thank you all CentOS maintainer for your monumental work, and I really hope Stream will be a success.
CentOS support was not nearly as good as some people make it out to be.
(I don’t mean to denigrate the work of the CentOS maintainers, at all.
I don’t think this is a fault of theirs, only a realistic assessment of the consequences of the downstream placement of CentOS relative to RHEL.) Each CentOS minor version was supported for (on average) five months. At the end of that five months, there was (on average) no support for one month until the next minor release was ready and updates resumed. Compare that to RHEL, in which every major release had continuous support without gaps for ~10 years and additionally, many minor releases had support for two years. I will happily take Stream’s uninterrupted life cycle over CentOS’s longer but discontinuous life cycle.
Criticism of Stream on this point rests entirely on the idea that CentOS’s life cycle was the same as RHEL’s, but that has never been true.
Red Hat does have *limited* support for in-place upgrades, but that is fairly recent.
Again, criticism of Stream on this point rests on the idea that CentOS’s upgrade path was the same as RHEL’s, but that is not the case.
3: kABI changes
kABI changes in CentOS with every minor release, and the best solution here is probably to treat all kernel updates the same way you treat CentOS minor update today. Use DKMS. Build reproducible package sets with Katello, or Pulp, or reposync, or Spacewalk. Test them. Promote those to production when they’re ready.
That’s the same thing that we do, today, in enterprise environments.
CentOS has *never* had support from Red Hat. If you want to run a stable, supported production environment while you complete testing of a new minor release, you can get that from RHEL but not CentOS. If you want to apply only security updates to a production environment to reduce risk (in the sense of both security and stability risks), you can get that from RHEL but not CentOS. If you want to call an engineer for support when you have a problem in production, you can get that from RHEL, but not CentOS.
So, I will agree with you on one point: Support is the thing that makes RHEL valuable. The product is excellent, but it’s not the product that Red Hat’s really selling, it’s the support. It’s the things that their engineers do so that you don’t have to, as their customer. And CentOS
has never offered that.
Of course, you can fill some of those gaps with your own engineering, but if you’re filling those gaps with local engineering today, you should be able to fill them using Stream, too.
Why do you think that? Are RHEL (and CentOS) point releases backward compatible or not? If you trust point releases to work, why would you hesitate to trust a distribution that resembles an upcoming point release?
(And if you don’t trust point releases, why would you use the OS at all?)
.
.
.
%<
So what is it you expect?, get an enterprise quality OS for free, and also expect highly paid, expensive, engineers to support your need for assistance on a whim for free too? Of course RHEL is very good at supporting their distros/releases, I use it often enough, because it is paid for (by my employer). You get what you pay for, and I have the impression that you using CentOS and the support you DID get, probably didn't cost you a penny. I used both for the longest while, RHEL at work, CentOS at home. CentOS, as the (free) RHEL 'twin', is going away, so be it. Now I switched to RHEL both at home and of course still at work, RHEL even supports that, both.
No, I think you’ve completely missed the point that I was making, which was simply that criticism of CentOS Stream often mistakenly argues that because of the change, users of CentOS lose things that they never had to begin with.
I don’t know for sure if that argument was ever made, but if it was, they are entirely correct. Again, it was for free, it is up to ‘them’
to do something else if they wish, what ever the circumstances of their decisions. It was your choice to use it, for free, and your choice doesn’t mean an obligation on their part, they don’t owe you anything
… so yes, you never had it to begin with.
As you can see in all what I said above, I’m “selling” to my user one or another distribution. Meaning I offer them particular distribution, and tell them what to expect. With old CentOS, i.e. in case A, “binary replica” tells even non-technical users, all will work as on famous expensive product, including stability…
Now case B, namely “stream” incarnation of CentOS, I can not promise the same simply put expectation in my user’s minds.
Do I trust that I will be able to install all they need in Stream? –
absolutely.
Can I promise all will work during [even shorter] life cycle of stream without “glitches”? – With all honesty, no. And I will not jeopardize my reputation in front of my users by not mentioning “expect glitches”. Pardon my non-technical language which I prefer to use with my users.
As others said, this architecture of this new “stream” composition, –
let me say theoretically as I don’t want to go into details of how extremely well you do your technical part, which I am in no position to question – theoretically one can imagine problems happen time to time which one will not encounter using “binary replica” of RedHat Enterprise.
In other words, when talking to me, please, consider me a layman, who can understand simple logic, and rely on reputation earned by distribution during it long existence. So for me in my layman suite:
1. RedHat, including Enterprise: yes, by all means
2. “binary replica of RedHat Enterprise” CentOS which existed for over a couple of decades as such, – yes by all means
3. other binary replicas I didn’t observe carefully long enough, so can not offer any judgement. Except for Scientific Linux which by several reasons I turned down as something one can built future based on, and it didn’t last long, so I thanked myself for staying away from it…
4. CentOS “stream”, sorry this modus operandi does not exists long enough to earn “long standing brilliant reputation” of [and put here what you faithfully are saying about Stream] – not in my book though, and not that I with all faith in it can say to anyone whom I will be installing system on their machine.
Which all leaves me with option:
5. I know this [Debian, FreeBSD, or place there whichever distribution
_you_ know long history of] system is a “rolling release”, so what is installed may change version (and some software internals!) time to time during the life of the system, and things may break occasionally because of that. But this distro exists since forever and I can promise I will be there to see things are fixed when necessary. And this way of maintaining things exists for long time, and many people live with its negative sides, so we will be in a big good company of others like us.
I probably can faithfully say the same as 5 about CentOS Stream, though I should strike “long existence” thus you [addressing my user here] will not see statistics over past life. But then, I have less to offer as expectation compared to other alternative systems.
And as someone mentioned at the beginning of this whole thing that shook our – CentOS users’ worls -: the reputation lies on long positive performance. And changing suddenly something just negates all past great reputation. Even worse: now people [take that as all crowd of layman ones] know something can be changed on whim, and it will take a decade to regain the reputation.
This skews grossly out of subject, and I am reluctant to move up my writing and find the place where to put my “rant begins” tag, so I’ll just continue as is. If the reputation that “this existed since forever”
and it will not change (not on my watch as some will say) mattered for decision makers, then things could be done differently:
the “precursor” distribution of RedHat E… is necessary; Well, let’s set up new project that is being such. Its operational principles are different from those of CentOS (as in “binary replica…”), so the name should be absolutely different, no hint about “CentOS”.
CentOS (as on “binary replica…”), either stays alive, or dies depending of variety of factors.
And having all done this way would prevent anyone from having even a shadow of suspicion that new project (which CentOS Stream is) is attempting to take advantage by using ling lasting reputation of old project (CentOS as on “binary replica…”).
And this exactly is a psychology new CentOS team sees from many directions.
My apologies for expressing humble view that may not chime with feelings of people, especially hard working CentOS team.
Valeri
—
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
I think we’re still talking past each other, but I’ll try one last time:
Critics of Stream often argue that CentOS users are losing support that CentOS never had to begin with. Their argument implies that CentOS has aspects of RHEL that it does not. They are not correct.
Does that make sense? Please, go back and read my earlier message again. You seem to think I am complaining that CentOS is not supported, but I am not.
Il 2021-04-30 21:16 Gordon Messmer ha scritto:
From here [1]:
“Since March 2004, CentOS Linux has been a community-supported distribution derived from sources freely provided to the public by Red Hat. As such, CentOS Linux aims to be functionally compatible with RHEL. We mainly change packages to remove upstream vendor branding and artwork. CentOS Linux is no-cost and free to redistribute.”
Does it means that CentOS was appropriate on all scenario? No. Was CentOS making hard promises about their support or existence? No. So it is *fine* for classical CentOS to disappear if the developer / owner want that. Long live Stream!
But stating that Stream is functionally equivalent to CentOS is not correct. Fact is that the CentOS team did a wonderful work at repackage RHEL, so 99.9% of times it just worked. And it worked for all the time the corresponding RHEL was supported (7 or 10 years). In return, RedHat
(and so CentOS) got much testing and bug-report (I alone reported my fair share of bugs, some with hours/days spent try to reliably reproduce and tracking down them).
Now, with a moving kernel, you simply can’t provide this level of confidence. DKMS is not a silver bullet. See here [2] for an example. Rebooting your kernel and finding you can’t access your storage is a quite a significant problem, no? And when I migrated a test machine to Stream some months ago, even something as basic as dnf had its issues. While I hope that now the situation is better, I hardly can see Stream equivalent to old CentOS.
I re-visit this thread, since it is crucial for CentOS 8 users.
RESF / Rocky Linux is gaining worldwide recognition and sets itself as the primary organization / platform to become the CentOS 8 heir /
successor in the future.
Google and Microsoft become RESF sponsors/partners:
And so IBM/RH lose the tremendous advantage they had by owning the CentOS project, which – it seems – never evaluated correctly.
From now on, it is clear that hundreds of thousands of CentOS
installations will be migrating to Rocky Linux.
I also wish the best of success to CentOS Stream, but this is not what the CentOS community expected.
My 2c. Nick
There’s also Alma, which is where I’ve gone after being with CentOS
since 5.3
—
J Martin Rushton MBCS
AlmaLinux is a great project too, IMHO, but things show that the new industry standard (replacing CentOS) will probably be Rocky Linux.
(Yes, RHEL **AND** CentOS have indeed been industry standards – the point of reference -, IMHO, and this is what IBM/RHEL have failed to realize: You don’t alter a point of reference.)
It is interesting to see what Service Providers will do with their (huge numbers of) CentOS installations, when they migrate…
From the users/admins’ perspective it is to their interest to have robust and healthy alternatives.
In our org, I am now using Rocky Linux on new installations (without issues) and will be migrating several CentOS 8 boxes to Rocky Linux as well.
Cheers, Nick
It should not be forgotten that Rocky Linux will be a 1:1 rebuild, also in the future. So, to shape this future everyone is invited to participate at CentOS Stream. This is a great future or not?
Il 2021-07-07 11:44 Nikolaos Milas ha scritto:
Yeah, I share this view.
As a side note, I evaluated Oracle Linux because it has working secure boot, but I am somewhat afraid of using it (due to corporate practices). This probably is an irrational feeling (after all, I do not exclusively use MariaDB, but MySQL also), but I prefer to stay on the safe side.
Anyway, I strongly feel that IBM/RH miscalculated the move. Regards.
Le 07/07/2021 à 11:44, Nikolaos Milas a écrit :
Rocky Linux is the New Kid On The Block and gets all the attention.
Whereas Oracle Linux (the best RHEL clone in terms of maintenance reactivity)
has been around since 2006, free as in beer since 2012, and nobody wants to touch it.
Fashion, and Oracle’s past practices. I evaluated
Alma Linux
Fedora
Mint
Open SuSE
Oracle Linux
Springdale Linux and settled on Alma. Rocky was still vapourware when Alma was stable. I’ve seen how Oracle promise no change in the long term, then change their charging model in the past. We got badly burned at work when they took over DEC RDB.
I like Alma’s independence built on Cloud’s experience over many years building RHEL clones.
Just my 2d worth.
—
J Martin Rushton MBCS
It’s simply that Oracle has such a bad reputation in dealing with Open source. Many people doubt them, and doubt that they won’t change things in the future if they think they have a good chance at making money from it.
I think that right now, many are either going to use Rocky or Alma. I suspect that over time, one of them, will be far more used than the other, and become the next CentOS, in the sense that while there were a few RH clones, almost everyone chose CentOS.
A few months after the CentOS 8.x deprecation news was released, Oracle Sales reached out to my organisation and reminded us that OEL was free to use, with migration scripts available.
We briefly considered migrating from CentOS to OEL, but ultimately decided against it since, as Danti indicates above, Oracle has a questionable history, and we feared that their “free as in beer” approach may change to more of a RHEL approach once their user base was sufficiently expanded.
Rocky is community-driven with substantial sponsorship from large, respected enterprises, whereas Alma and OEL are both tied at the hip to corporations. While noone really knows what the future holds, enough of us have been burned by what has been done to CentOS 8.x that we frankly know the stove is hot, and don’t really want to touch it again, if it can be helped.
As others have stated, I appreciate and respect Red Hat’s vision for CentOS
Stream, and I do wish the project all the best. (I’m running 8-Stream on most of my laptops and workstations now, in fact. — It is nice to know what is in the EL pipeline!) I think there’s a great argument for using Stream on DEV systems, etc., provided there is a plan to move corresponding PROD machines to the new EL release by the end of the Full Support window. The decision to abandon Stream 8 in 2024 (vs. 2029) makes broad use of it in my environment a non-starter, in most cases.
As many have observed, the Stream change would’ve been much more welcome were it announced beginning with EL 9.x, but pulling the rug out from beneath CentOS 8.x with a year’s notice, right after so many of us had just finished migrating workloads to it in anticipation of EL 6.x EOL was a very poor decision, imho.
*J. Adam Craig*
Lead Linux Operating Systems Analyst VCU Infrastructure Services <https://www.ucc.vcu.edu/>
Technology Services Department
804.828.4886 jacraig@vcu.edu
In our stables it is Debian that replaces CentOS. (And it is closer to FreeBSD in several aspects, the last is what the servers run).
Valeri
I hadn’t seen that one, but I do notice that it aims to be “minimalist”
whereas my main machine is the network server (DNS, DHCP etc), a server
(Wiki, Cloud, storage) and my workstation.
BTW, anyone know who the “Navy Foundation” are? Is this an arm of the US government?
Navy Linux has a bad taste already, for me. They are aiming too big, even trying to replicate EPEL for themselves. And their attitude isn’t good. They had a tweet disparaging “new unstable vendors” of EL distros that they only deleted after being called out for it, despite being one of those themselves.
They used to say they were founded by “Unixlab”. Which Unixlab? We don’t know. Now they say they are a non-profit Foundation that founded the project. https://webcache.googleusercontent.com/search?q
That furthers what I wrote earlier. That says:
> Date of formation: June 14, 2021
Yet the about page ( https://navylinux.org/about/ ) was changed to say:
founded by Navy Foundation on January 4, 2021.
They don’t have a straight story, and they’ve been changing it inconsistently. That’s not how you build trust.
+1
The Division of Corporations in DELAWARE shows:
Formation Date: 6/14/2021 (mm/dd/yyyy)
Anyway, in the context of ongoing attacks to the supply chain. This situation where CentOS is running EOL will motivate new black hats to step into the place. Imagine a massive deployed OS that is trojanized?!
So trust is here king and despite all adversity (that also hits me hard) we should thinks twice before running away into foreign arms.
—
Leon
+1
And I feel safe running (and planning to run for long future to come)
quite reputable ones with long history of such: FreeBSD (servers), Debian (number crunchers, workstations).
Valeri
—
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
For completeness, here’s a WayBackMachine link to the deleted tweet. Luckily it got archived.
CentOS 7 not need to move forward to new unstable vendors, wait and watch Upcoming changes. already on CentOS 8 wait until a stable reslease ready for upgrad.@GuyLinux @CentOSannounce #Linux
I’m not affiliated with Navy Linux but it seems to me there’s nothing inconsistent there. They say it was set up as a community project on January 4, 2021 and a foundation (a common component of community projects) was formed on June 14, 2021.
That’s all perfectly straight and consistent. Rocky, for example, followed the same process didn’t it: The community was formed and then a foundation followed soon afterwards.
—
Mark Rousell
P.S. Despite my comment above, I do agree that the disappearing of their reference to “Unixlabs” on their website is not confidence-inspiring. And not making it clear which/who this Unixlabs is, is even more frustrating.
—
Mark Rousell
I feel totally safe and confident with the fully community-driven effort of Rocky Linux, lead by the former founder of the original CentOS
project. (I am not affiliated with them in any way.)
As has already been mentioned, Rocky Linux has managed to gain quickly support from major players in the industry (including Google and Microsoft), and is committed to never drop its independent/community status. It is well structured and organized, and embraces a good number of open-source volunteer specialists.
We want to keep up with RHEL ecosystem and Rocky Linux is – for us – the best option.
If some people want to leave the RHEL ecosystem for Debian or FreeBSD, that’s OK. But for those who want to stay in the RHEL world, Rocky Linux stands as a rock-solid solution. This opinion does not reject other CentOS clones, but emphasizes the fact that Rocky Linux appears to be a solid option for now and the years to come.
Cheers, Nick
Il 2021-07-08 13:22 Nikolaos Milas ha scritto:
While true, I also feel that RH is trying to actively shape its distribution away from small enterprise needs. For example, common packages are deprecated and/or removed (eg: virt-manager, screen, kernel-side DRBD, pam_mysql, etc) and EPEL 8 (which is fundamental to my CentOS/Rocky installations) is in a bad state.
My impression is that RH is following cloud vendors & hyperscale needs –
with Stream as a clear example. This is not an inherently bad thing, but it quite different from what the small and medium businesses I service need.
So, while closely watching RH/CentOS/Rocky, I am going to steer new deployments on Ubuntu LTS or Debian. Regards.
Soon, we will all have to find a way to work with other distributions, or work together to create and maintain new distributions that focus on micro/small/medium business. Eventually, this will be the only way to keep virtualization and hybrid cloud available. Everyone smells money and RedHat is now controlled by IBM, so little by little, we can start seeing the changes, reducing packages, dismantling, re-architecting, re-branding. It’s only a matter of time. Greed is worse than cancer.
Well, I fled servers from CentOS to FreeBSD almost a decade ago. And actually not From CentOS per se, but from Linux. One of the reasons was: every 45 days on average: glibc or kernel update —> reboot. One of my friends started using word “Lindoze”. Linux is perfect for number crunchers and workstations. FreeBSD is waaay better for servers. In my book that is.
Just straightening small nuance.
Valeri
If you aren’t rebooting your FreeBSD systems regularly, you’re just as vulnerable.
Maybe “we” could fill this gap? Describe this state of EPEL? Did you requested such missing packages? From the early on (EL8.0) I requested such EPEL packages, some fedora maintainers branched there packages into EPEL8. Even a request for a devel package was honored and the rpm was included by RH later in 8.1. This is a community, so communicate!
Everything else is a product in ready state that must be paid.
That original reason to flee for us (one of several as it turned out to be) is dated 10 years back. Not quite fair to apply today’s counter-argument to it. Still a year or two ago when I checked last, and it was about 2 reboots a year required for FreeBSD, whereas <= 45 days is still was a fact for Linux.
But as you have said yourself, we live differently today, and several things (like one or few services per jail - the last having read-only base system to mention one) still make FreeBSD much simpler to maintain for servers. Not to mention, switching from Linux (10 years ago) to FreeBSD was quite smoother learning curve than adjusting to systemd and friends ;-) (I'm cheating a bit: I did run UNIXes in the past - waaay back).
Of course, tastes differ, but still, only those who tasted both things can have fairly say what is better to one's own taste. Saying not to Jonathan, of course, who I bet runs several UNIXes, FreeBSD included.
(of course, not all of them can strictly be called UNIX, - re no loyalties to AT&T).
But even as part of our infrastructure fled to FreeBSD, workstations and number crunchers stayed with most adequate for them system: Linux. CentOS until recently, Debian once CentOS stopped being "binary replica"
of RedHat Enterprise. Gionatan Danti mentioned another important reason...
Valeri
--
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
As a side note:
l never used FreeBSD, even though I’ve heard good things about it. Frankly, I loathe its devil logo. I know it’s probably derived from the Unix “daemons”, yet I fail to get reconciled with it. It’s simply appalling to me (even if it’s smiling) :(
I don’t require any reply on my above comment (I might even be called naive or whatever). It’s some kind of personal confession which I feel I
need to express somehow. I simply wish FreeBSD people changed this logo at some point…
I wonder whether FreeBSD users are expressing similar concerns… I am not following any FreeBSD activity or discussion.
Cheers, Nick
I _can_ understand religious person’s attitude to some images.
I for one consider FreeBSD mascot as created with quite some sense of humor. No more no less.
Being not religious myself, I do agree with what region [Christian?]
says, almost all or it: you shouldn’t steal, you shouldn’t kill, you should be kind to others,… The only thing I disagree with is: they say God created people, I believe it is other way around: people created God for themselves. But as neither can be proven experimentally, the last in my book is really minor disagreement ;-)
Valeri
—
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
THAT must have been part of the reason for mscot. Also, they call mascot Beasty (as in diminutive from :”beast”). And if you pronounce the abbreviation of Berkeley Software Distribution (the one FreeBSD is successor of): BSD, and then “beasty” they sound not that different from one another ;-)
Valeri
—
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
Le 2021-07-08 17:38, Nikolaos Milas a écrit :
I *love* the FreeBSD logo.
But then I listen to Nine Inch Nails and Marilyn Manson while working, so I guess I’m not much of a reference.
Niki
—
Microlinux – Solutions informatiques durables
7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32
Mob. : 06 51 80 12 12
Personally, I have always been a fan of the BSD distributions and have always kept at least 1 virtual machine running a flavor of BSD. However, I am not religious, and have no attachment to anything supernatural or metaphysical or any other pseudo-spiritual thing. I just think with the changes happening at RedHat, we will see some effects soon, including Fedora as well. It is a shame, CentOS has been a rock solid workhorse, perfect for testing, for proofing, for prototyping and all sorts of infrastructural experimentation.
That makes things even worse… :( x 2
Nick
+1
In a lot of circumstances we do not invest a bit of time to participate in such community joint efforts and this has a significant cost for all of us in the long run.
Let’s all be more active in our communities if we want them to remain strong, as Leon suggests.
Cheers, Nick
*chuckle*
I’m reminded of a column in SysAdmin, a long time ago. Seems the woman who wrote? contributed? to the column Daemons and Dragons was wearing a t-shirt with the logo, and she was traveling with some folks in the US
South. She went in to pick up some bbq… and by the time she had the food and was walking out, was afraid that she might be attacked by one or more of the “Real Christians” in the shop, from the comments they made, because of the shirt.
That said, lets face in: current CentOS is not really a community, at least in the sense that a community can steer the project direction. Nobody polled for Stream or asked about it. Stream simply happened due to an unilateral Red Hat decision. *Which is PERFECTLY fine*, unless trying to masking it behind the “community” word.
My view is that RH/CentOS would be relatively inadequate for many roles without the outstanding work done by EPEL and the rest of the CentOS
community, unless you are an hyperscaler who can do its own internal package additions. Red Hat failing to recognize the enormous value of EPEL and former CentOS model really baffles me.
Regards.
Exactly so.
So, this enormous and invaluable effort should not be wasted and abandoned, but should continue and thrive within full community-driven projects like Rocky Linux.
This is what I mean by community effort. CentOS is no more a community-driven project, but others emerge. Yet, currently the only one with true community characteristics is probably Rocky Linux.
Cheers, Nick
The motivations behind Rocky Linux are noble indeed, altruistic and back to community. But, accepting support from Amazon, Google, and especially Microsoft tastes like vomit in my mouth. Nothing in the world I despise and disrespect more than anything related to Microsoft.
Get better sponsors, get community funding!
They are the 3 largest cloud services there are. That’s what the support is for. They are working with the platforms that will be running their OS on potentially millions of instances. Welcome to the 21st century of computing.
Understood….. like all previous trends in technology, that too will change, the landscape is always changing…… I’m an idealist, there is no way in hell I would ever accept anything from Amazon or Microsoft, never…would rather fail than surrender principles
Good phrased. I see it exactly like this but let me take a dialectic position just for the sake of insights. CentOS Linux (or Rocky Linux)
is a downstream rebuild, right? So, the fences are already set. Right now, I am seeing a lot of requests in the Rocky forum, to add new shiny stuff to the distribution and the answer to most of this is (more or less); “we (Rocky) are a 1:1 rebuild of upstream and we can not add new stuff in an arbitrary way”. So, when talking about a community then we have different concepts behind it. A RH ecosystem community is not the same as a Debian community. It was never and it will never be the same.
I see the RH ecosystem as a hybrid opportunity (perspective from the outside), so not all “directions” can be influenced but there is enough room to contribute to directions especially with Stream now.
PS: Do not get me wrong; the whole communication from RH about this
“CentOS Change” is catastrophically.
Well said. It is worth pointing out also that, while Kurtzer and other Rocky community leads are devoted to keeping Rocky 1:1 with upstream, they are also committed to engaging with the CentOS Stream community themselves
(if they find a bug in upstream code and they can fix it, Kurtzer and others have stated multiple times that they will contribute the fix into Stream), and to encouraging such engagement among those who desire to see improvements with upstream. In other words, if we are uncomfortable with the direction Stream is going, the preferred approach is mobilisation within and engagement with the Stream community to have those changes realised there, so that they flow into Enterprise Linux and everyone benefits.
Le 08/07/2021 à 22:53, mario juliano grande-balletta a écrit :
I started with Linux back in 2001, the year where Microsoft CEO Steve Ballmer called Linux “a cancer that attaches itself to intellectual property”, so my views on Microsoft are about the same as yours.
This being said, things have changed, and Microsoft is now – amongst other things – the most important contributor to the Linux kernel in sheer terms of lines of code.
Microsoft has, infrequently, appeared in the top 5 for specific releases. Mostly, as I understand it, those were due to large dumps of Hyper-V related code. Overall, Microsoft doesn’t appear to be active in the Linux kernel, though they do have a large number of Open Source projects of their own.
In general, Intel and Red Hat seem to be pretty consistently the top two corporate contributors to the Linux kernel.
Il 2021-07-08 23:21 J. Adam Craig ha scritto:
While I fully understand & agree on the motivation for keeping Rocky
(and other clones) 1:1 with Red Hat, it should be understood that current RHEL packages selection itself is drifting away from small/medium business needs. So the core issue is a more fundamental one: Red Hat, our upstream, is walking away from traditional server needs.
So while I wish Rocky all the best (and I am actively using it!), I am looking toward Ubuntu and Debian for new deployments. Regards.
IMHO, this is a more fundamental discussion, which is beyond future CentOS versions and alternative RHEL-compatible projects and it deserves a separate thread.
In any case, I think that the existence and continuous availability /
maintenance of external RHEL / CentOS-compatible repositories probably provides a solution for most use scenarios. Of course, I cannot possibly know all actual needs, so I may be wrong.
I need to recognize the fact that it appears there is still a shortage of packages for CentOS 8, even though it is active for quite long already. Maybe this is mainly due to EPEL difficulties.
Like any commercial product, RHEL exists for Red Hat’s customers… so if you want to see something specific from RHEL, you need to be a customer to give input.
Thanks! That’s exactly the one I was thinking of.
mark
Any extensions beyond rebuilding TUV provided code are why CentOS, and now Rocky, have SIGs. There is an appropriate place for these requests, but it is not in the main project.
106 thoughts on - CentOS Versions In The Future?
We will continue to produce CentOS Stream for the foreseeable future. There’s some details about the announced changes here –
https://blog.CentOS.org/2020/12/future-is-CentOS-stream/
Not just rumours. CentOS 8 dies at the end of this year. CentOS 7 has until the end of 2024. RH are introducing “CentOS Stream” which is what will be in RHEL in the next release. It has been unkindly referred to as beta software.
The traditional rebuild of RHEL will continue under other guises. There has been a long standing release at Springdale. Since RH’s announcement Cloud have produced the Alma release. There is also a new project called Rocky that hasn’t yet released a full version but is working on it.
Thank you for your response Rich. I have heard that Stream is beta releases of RH — rather distressing. Is this a proper characterization?
Thank you for your response Martin. We should probably consider moving to the alternatives that you mentioned or Ubuntu. CentOS was no longer a Community effort after RH was bought by a propriatory company.
CentOS mailing list CentOS@CentOS.org https://lists.CentOS.org/mailman/listinfo/CentOS
You heard wrong.
Stream is effectively a rolling early release of the next point release of RHEL. The packages in stream are fully tested and have gone through QA. They are not beta releases.
The disadvantage of Stream is that it doesn’t have the full 10 year support of RHEL and doesn’t have the full binary compatibility to RHEL.
P.
No, it is not a “beta”. That said, getting people to stop saying that has been unproductive. Mostly, therefore, I’d encourage you to try it and draw your own conclusions.
CentOS Stream is more directly integrated into the RHEL development cycle than CentOS Linux was, getting fixes faster, and providing an actual contribution model that didn’t exist before.
Thank you for your response Pete. I prefer to avoid working under the unbrela of propriatory companies.
“Proprietary company” sounds like a nonsense. All companies do work for profit. This is true about current owner of RedHat, as well as it was true about RedHat as a company before it was sold to current owner.
The moment CentOS team started being paid by RedHat (long before RedHat was bought by current owner) was the moment _I_ should have told myself about CentOS “this now will not last long”. Luckily for me I already fled my servers to FreeBSD, – from Linux in general, not from CentOS in particular. But that is long different story.
Just my $0.02
Valeri
—
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
With all due respect, – and avoiding the names to not scratch against
“release,…” definitions, he is more correct in his feelings (that what you say) which I would formulate as “stream users are sort of Guinea pigs for RedHat releases”.
And mind that I have no emotions about it as my servers are FreeBSD for over a decade. And new number crunchers and workstations going Debian since CentOS ceased to be RedHat Enterprise binary replica was such a minor change…
Just my $0.02.
Valeri
You would be hard pressed to find many FUNCTIONAL differences between Stream and CentOS Linux // just as you would be hard pressed to find many differences between RHEL 8.2 and RHEL 8.3, for example.
Are there some differences? Sure.
If people don’t want stream, then by all means , use something else.
CentOS 7 Linux will be around until the RHEL 7 EOL .. CentOS 8 Linux will be around until 31 Dec 2021 and CentOS Stream will be around for %
years after the RHEL 8 Release. CentOS Stream 9 will be around until for 5 years after the RHEL 9 release.
It is what it is .. all the negative comments are not going to change it.
For people who can not accept this and live with it .. life is too short for so much negative emotions. Go places and use things that make you happy.
Thanks Johnny for calmly stating what is what. This exactly is where all statements about CentOS should end.
My comment was just to balance Pete’s as the truth between Pete’s statement and Carlos feelings is where I’m sure my comment pointed… No negative intended, just stating of the facts as they are perceived by some (many? – not many if to discount these who fled totally).
And as always: thank you personally and the whole CentOS team, everyone who worked on this project during last two decades to make it as great as we know and used it – as “binary replica of RedHat Enterprise Linux”. Your effort can not be overestimated, as well as the way to say it: a
“binary replica of RedHat Enterprise Linux” was always quenching any doubts in everyone I had to talk to – both technical people and non-technical ones. (Not anymore, sigh).
Valeri
—
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
Out of interest, do you think my statement is factually incorrect? If so, in what way?
P.
I guess I have to hide behind my “imperfect command of English language” ;-)
Though it most likely is factually correct, while being an opposing to Carlos’s statement of feelings, it did ask for a comment why Carlos’s feeling have the grounds to be such, and and thus it warrantied in me my addition of comment.
In other words, both of the following are true (IMHO):
A. Johnny’s rigorous statement of what CentOS now is (or yours, it doesn’t actually matter who rigorously states it, but Johnny’s seemed to really cover all aspects – maybe it’s just my reading though)
B. “CentOS is binary replica of RedHat Enterprise Linux” statement is not true as far as new releases are concerned, i.e. not true to build one’s future on it
But as everyone is agreed it is counter productive to ponder these things, I will end my side of it by reiterating:
As always: thanks to the whole CentOS team, everyone who worked on this project during last two decades to make it as great as we know and used it – as “binary replica of RedHat Enterprise Linux”. Your effort can not be overestimated, as well as the way to say it: a “binary replica of RedHat Enterprise Linux” was always quenching any doubts in everyone I
had to talk to – both technical people and non-technical alike. (Not anymore, sigh).
Valeri
That is a conflicting statement. What would you then use these days without having a “entity” to back the service up? Anyway its OT …
Maybe this is of interest:
https://arstechnica.com/gadgets/2021/01/CentOS-is-gone-but-rhel-is-now-free-for-up-to-16-production-servers/
Leon
No, I don’t think so. I think a better characterization would be:
Rawhide is a development (beta?) release. Fedora is a stable release.
CentOS Stream is a stable LTS release. RHEL is a stable LTS release with semantic versioning of the distribution as a whole (and point releases which are themselves branches of the main release).
Once upon a time, Carlos Oliva said:
The vast majority of open source software is developed by companies like Red Hat/IBM (IBM was a significant Linux contributor long before they bought Red Hat; the original SCO lawsuit was about code IBM contributed to the Linux kernel). That’s not just true of Linux; a lot of FreeBSD
development is done by a few companies (sometimes imperfectly, as seen with the VPN mess just before FreeBSD 13 release).
I would love to get to the point where I feel comfortable saying that Fedora Rawhide is a perpetual beta. The current status is more like “perpetual alpha” — in fact, Fedora dropped our “alpha releases” in favor of applying the same criteria to Rawhide continuously, so it’s not just an analogy. But we do branch from there for a stabilization period, from which we have beta and then final releases of Fedora Linux.
—
Matthew Miller
Fedora Project Leader
Il 2021-04-27 15:05 J Martin Rushton via CentOS ha scritto:
Hi, I am not sure this is the place to ask, but lets try… If the Springdale release is a 100% RH clone, why do different teams
(Alma and Rocky) are trying to re-package the same 100%
binary-compatible RH clone?
Thanks.
Simply because each one of these projects obviously wants to remain independent from the others, otherwise it would request to join forces with one of them.
Why they want to remain independent? Due to their vision and internal structure. Check each project’s details.
Each project’s future will be judged by team responsiveness, prompt release availability, product reliability and eventually user adoption.
All that, in turn, are very much dependent on community involvement and project management & financing.
Cheers, Nick
By the way, I think that CentOS, before it was “absorbed” by Redhat, could/might have addressed the community for fund raising, rather than abandoning the project to RH, which, as others have mentioned, was an unmistakable sign of upcoming CentOS EOL as we had come to know it.
If the financing need was communicated correctly, I am very confident that financing would have been secured, e.g. by using a public fund raising platform, due to CentOS huge install base and community.
Any of those current (or future) projects that might prove successful enough to become CentOS successor (as a RHEL binary twin, and not as Stream), should use the community financing model, in order to avoid CentOS fate.
My 0.01$ :)
Nick
So CentOS when it was brought into Red Hat was not a company or organization. It was much more like some sort of libertarian anarchy where a group of people came together in an IRC channel and did what they wanted to get an OS out. Many of these people were consultants who had daily clients and did this as a night gig to help those clients and others but it wasn’t a single company which could accept funding. Things like the domain name, trademark, etc were in the name of one person due to a past historical problem.
That problem was that CentOS did once have an organization to collect funds, but it had been mismanaged. This caused all kinds of problems with the community and groups which had given funding and there were legal and tax problems due to it. In those cases, it is better to ‘walk’ away from the organization as resetting it up usually triggers audits and additional paperwork to show the people involved now are no way the same ones before. So instead things were set up with most of the items owned by individuals.
—
Stephen J Smoogen.
you think you can fund something like that with a bake sale or so?, maintaining a separate distro for the same thing is VERY expensive
Speaking of financing, it’s common for non-profits such as churches and other organizations to have an annual budget review that is put together to lay out the budget, and expenses to see how each cost is broken down.
Is there an equivalent budget page that annual review of expenses for CentOS / Stream?
If there isn’t then perhaps it would be beneficial to have such a page, something that lists out the line by line expenses, so that everyone is aware of how expensive that maintaining a distro truly is.
—
Christopher Wensink IS Administrator Five Star Plastics, Inc
1339 Continental Drive Eau Claire, WI 54701
Office: 715-831-1682
Mobile: 715-563-3112
Fax: 715-831-6075
cwensink@five-star-plastics.com http://www.five-star-plastics.com
I agree, of course, yet it seems that those who decide to maintain a separate distro are decided to do so and obviously are confident that they can handle funding somehow.
Nick
I think the budget needed would be in the millions, 10’s of millions…
that is hard to do with a gofundme page or a bake sale on an annual basis. if it only was a 100k or couple of 100k, IBM and others wouldn’t care to keep it going I think, besides funding, there were organizational reasons too I believe.
This is true within the narrow scope of just CentOS/RHEL, but if, for example, you rely on ELrepo for kmods for hardware that Red Hat dropped support for, you’ll be sadly unable to use those kmods on Stream (elrepo isn’t supporting Stream[1]). There will also be inconsistencies with other third party repos and commercial software that focus exclusively on RHEL when Stream gets major version bumps ahead of RHEL. Certainly it will be an opportunity for those vendors to get their product working on Stream, so they’ll be prepared for the next RHEL release. But this is why people are calling it a beta test for RHEL. Yes, Steam running with only their core repos and software from within CentOS is tested and QA’d. But if you want to use Stream in a larger software context, be prepared for missing support and unexpected breakages. The only use I will consider Stream for will be as a test for upcoming RHEL releases, not as something I will ever want actual users to touch. (And maybe that’s ok)
1. http://elrepoproject.blogspot.com/2021/01/elrepo-and-CentOS-stream.html?m=1
—
Jonathan Billings
The other concern for me is security. I’ve not had time to track CVE’s in detail, but even a cursory look shows there are CVE’s which have been fixed in RHEL8.3 kernel releases which are still not fixed in the latest Stream release [1] (which if truly upstream of RHEL should presumably get the fixes first before they are backported to the RHEL point releases), and others where the fixes eventually appeared weeks or months later [2]. I know CentOS makes no claims as to security fixes etc, but at least with RHEL->CentOS Linux rebuild, one could reasonably expect that when a security issue was fixed in RHEL, CentOS would have the same release and fix out the door within 24-48h. With Stream we are seeing delays of months for security fixes in the kernel that have been released in RHEL. The only time the Stream kernel is comparable to the RHEL kernel from a security fix viewpoint is once every six months on the day the next point release fork occurs. This all indicates Stream is not of production quality and hence why people associate / use the term beta software.
[1] CVE-2020-25705
[2] CVE-2020-29661
As was stated at Red hat summit though .. while Stream will not be a copy of the downstream RHEL code anymore .. it WILL BE extreamly similar to RHEL + a couple months. In fact at 8.4 release .. Stream is very similar t0 RHEL 8.4 with NO WAITING. CentOS Linux 8 getting upgraded to the 8.4 source code, tested, isos created, etc .. will take a month or so, Stream already has all that content in it RIGHT NOW.
I think that is a positive , not a negative.
CentOS NEVER made security fix claims :)
The kernel dies currently lag behind slightly .. but this is something that will be fixed when the full process is implemented for stream.
Right now, because of secure boot signing not being automated completely
.. and because of different keys for CentOS and RHEL .. the kernel process is manual, not automated.
But, this process is being worked on. How many people actually really update their kernels and reboot on the day those updates come out .. or the 1 or 2 days later that CentOS currently takes to build them?
But yes, one does need to look for how to fix those issues.
Yes, this all sounds nice, but not good enough if you put yourself in my shoes when I suggest my user:
A. “I am going to install CentOS which is binary replica of RedHat Enterprise”, so whatever works on RedHat Enterprise will work on CentOS
[implying my reputation behind merely an ability to install binary packages and common sense of what binary files are there on both systems in questions]
B. There is CentOS which is promised (I am borrowing your phrasing here)
“WILL BE extreamly similar to RHEL + a couple months”
but in the second case I can not put my reputation at stake and finish my phrase with “whatever works on RedHat Enterprise will work on CentOS”.
So my latest phrasing to my users/machine owners – which I can put my reputation behind – is:
I am going to install Debian for you, and as in the past whatever works on some Linux I should be able to make work on your Debian machine.
The last I can put my reputation behind, and my user knows it might not be as simple as installing binary packages known to work on RedHat Enterprise, and knows there will be some effort/time on my side involved.
My apologies for breaking my promise to stop pondering the issue ;-(
Valeri
And as I have said several times .. if you (or anyone else) thinks something works better or Stream does not work for you, that is fine. Use what you want or like.
We make what we make. If one can use it, great. If not, that’s great as well.
This is opening up the RHEL creation process in an unbelievable way to community involvement. I an proud to have been involved in mkae this process so open.
I think CentOS Stream is a much more community project that CentOS Linux ever was. I also think it is better for the open source community and Linux distros in general. For people whole don’t think this, we can agree to disagree. it does not make either of us right or wrong.
Maybe I am miss reading this sentence. Could you rephrase the “while Stream will not … anymore” please? Did something changed recently?
Thanks, Leon
Quite agree. For me, not too knowledgeable in these things person, this looks exactly what Fedoraa while ago was: huge opening of RedHat to wide open source community. Maybe Fedora didn’t live up to the expectation, then good luck to CentOS to live up to this expectation.
I hope, no one is offended by my – restricted – view of this, personal perception is just that and bound to be restricted to person’s knowledge ;-)
Valeri
—
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
Stream as compared to CentOS Linux is not RHEL source code downstream is what I should have said .. so what is released as CentOS (Steam now)
will no longer be a downstream build.
It will be released packages and very close to 8.4 content and right now.
I believe you are citing Johnny’s write-up, not mine, so your question should be directed to Johnny. Your mailer somehow messed the citation depth to appear what Johnny said as if it was I who said it.
Valeri
—
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
I don’t think that is the case, quite the opposite. Fedora is way more bleeding edge than RHEL/Stream, Fedora leads to a version that will form the basis of the next major version of RHEL. My feeling (without any real knowledge) is that the community involvement with Fedora was seen as a benefit and now they are doing the same thing with RHEL –
that community input into RHEL is via Stream.
It has been said a few times that Stream is, in effect, the distro that RH develops on: it used to be internal to RH, now it’s not. It was RH’s own internal rebuild of RHEL. Opening up this to the outside world allows other people (SIGs, spins etc.) to produce code on a level playing field with RH developers.
P.
You are right, my hand coordination is not so good anymore. it cutted one line too few :-)
—
Leon
Ah, okay. Thanks to clarifying it.
—
Leon
Why do you think that? Are RHEL (and CentOS) point releases backward compatible or not? If you trust point releases to work, why would you hesitate to trust a distribution that resembles an upcoming point release?
(And if you don’t trust point releases, why would you use the OS at all?)
Il 2021-04-30 06:55 Gordon Messmer ha scritto:
Because it very often break kABI compatibility, with 3rd party module heavily affected.
Don’t get me wrong: I understand that Stream is the way forward and that things are not going to change, and this is fine. But trying to ignore the key differences (shorter support, unknown upgrade from Stream-8 to Stream-9, broken kABI, etc) is not useful to anyone.
Stream is a *different* product, because is avoid (for the good or the bad) basically *all* things that make RHEL so special. And lets face it:
kABI and long/quality support from RedHat are the only two things which make RHEL special. Stripping them from CentOS will produce a very different product. And, as a side note, things break more often on Stream-8 then CentOS8. Maybe Stream only needs to mature, but it still a different product.
My personal opinion is that RH created Stream to give cloud vendors a place to experiment/repackage *before* adding that to the main RHEL
distro. Stream really does not seem targeted at small sites / “normal”
sysadmins, rather at large cloud vendors.
Which, again, is perfectly fine unless trying to disguise it as an
“almost-RHEL” distro. Regards.
—
Danti Gionatan Supporto Tecnico Assyoma S.r.l. – http://www.assyoma.it email: g.danti@assyoma.it – info@assyoma.it GPG public key ID: FF5F32A8
Why do, you, people use “creative editing”? Cite the whole piece I said, and place your question there, don’t tear single phrase out of context.
Valeri
Sure .. so block kernels and build your own in that situation. Or use something else. There are always edge cases. There are millions of CentOS users. What percentage use 3rd party modules (other than nvidia drivers). There are some, and this would be a problem for those people.
So, IF another downstream distro works for you .. use it. Or use Debian or Ubuntu, or BSD. Use Alma or Rocky Linux. Buy RHEL.
Any number of solutions.
Il 2021-04-30 16:26 Johnny Hughes ha scritto:
As stated above, if this is the vision of Stream, fine. I am not arguing about the vision: while I don’t like it, my opinion is irrelevant.
But disguising Stream as “almost-RH” (a mantra repeated many times both here and in various blog) is plain wrong, and I genuinely don’t think it will be good for Stream.
And you know better than me that what you wrote above regarding the kernel is a double-edge sword: as you cope with security patches if the kernel is blocked? How do you cope with HP/DELL/Lenovo kmod needed to configure the RAID subsystem if using a rolling kernel? Did you notice that even RH-sponsored modules as kvdo were broken multiple times on Stream? If you are using VDO to access your storage and it suddenly is not usable anymore, how would you feel? What about ZFS on Linux users?
Do you realize this drastically reduces Stream fitness to bare-metal install (one of the main CentOS usage was as hypervisor)?
The correct answer is to buy RH: fine. But do not let Stream touch anything which require a kABI compatible modules. As said above, the Stream move is squarely addresses *cloud* vendor requests and needs. Again, fine. But please leave apart the RH comparison, this is not going to help Stream.
Again, don’t let me wrong: I wishes the best to Stream, and I will use it where appropriate. But “where” is much smaller today than yesterday. But this aside, I really thank you all CentOS maintainer for your monumental work, and I really hope Stream will be a success.
Regards.
—
Danti Gionatan Supporto Tecnico Assyoma S.r.l. – http://www.assyoma.it email: g.danti@assyoma.it – info@assyoma.it GPG public key ID: FF5F32A8
1: shorter support
CentOS support was not nearly as good as some people make it out to be.
(I don’t mean to denigrate the work of the CentOS maintainers, at all.
I don’t think this is a fault of theirs, only a realistic assessment of the consequences of the downstream placement of CentOS relative to RHEL.) Each CentOS minor version was supported for (on average) five months. At the end of that five months, there was (on average) no support for one month until the next minor release was ready and updates resumed. Compare that to RHEL, in which every major release had continuous support without gaps for ~10 years and additionally, many minor releases had support for two years. I will happily take Stream’s uninterrupted life cycle over CentOS’s longer but discontinuous life cycle.
Criticism of Stream on this point rests entirely on the idea that CentOS’s life cycle was the same as RHEL’s, but that has never been true.
2: Unknown upgrade path
https://wiki.CentOS.org/FAQ/General#How_do_I_upgrade_from_one_major_release_to_another.3F
“Upgrades in place are not supported nor recommended by CentOS”
https://access.redhat.com/solutions/21964
Red Hat does have *limited* support for in-place upgrades, but that is fairly recent.
Again, criticism of Stream on this point rests on the idea that CentOS’s upgrade path was the same as RHEL’s, but that is not the case.
3: kABI changes
kABI changes in CentOS with every minor release, and the best solution here is probably to treat all kernel updates the same way you treat CentOS minor update today. Use DKMS. Build reproducible package sets with Katello, or Pulp, or reposync, or Spacewalk. Test them. Promote those to production when they’re ready.
That’s the same thing that we do, today, in enterprise environments.
CentOS has *never* had support from Red Hat. If you want to run a stable, supported production environment while you complete testing of a new minor release, you can get that from RHEL but not CentOS. If you want to apply only security updates to a production environment to reduce risk (in the sense of both security and stability risks), you can get that from RHEL but not CentOS. If you want to call an engineer for support when you have a problem in production, you can get that from RHEL, but not CentOS.
So, I will agree with you on one point: Support is the thing that makes RHEL valuable. The product is excellent, but it’s not the product that Red Hat’s really selling, it’s the support. It’s the things that their engineers do so that you don’t have to, as their customer. And CentOS
has never offered that.
Of course, you can fill some of those gaps with your own engineering, but if you’re filling those gaps with local engineering today, you should be able to fill them using Stream, too.
Why do you think that? Are RHEL (and CentOS) point releases backward compatible or not? If you trust point releases to work, why would you hesitate to trust a distribution that resembles an upcoming point release?
(And if you don’t trust point releases, why would you use the OS at all?)
.
.
.
%< So what is it you expect?, get an enterprise quality OS for free, and also expect highly paid, expensive, engineers to support your need for assistance on a whim for free too? Of course RHEL is very good at supporting their distros/releases, I use it often enough, because it is paid for (by my employer). You get what you pay for, and I have the impression that you using CentOS and the support you DID get, probably didn't cost you a penny. I used both for the longest while, RHEL at work, CentOS at home. CentOS, as the (free) RHEL 'twin', is going away, so be it. Now I switched to RHEL both at home and of course still at work, RHEL even supports that, both.
No, I think you’ve completely missed the point that I was making, which was simply that criticism of CentOS Stream often mistakenly argues that because of the change, users of CentOS lose things that they never had to begin with.
I don’t know for sure if that argument was ever made, but if it was, they are entirely correct. Again, it was for free, it is up to ‘them’
to do something else if they wish, what ever the circumstances of their decisions. It was your choice to use it, for free, and your choice doesn’t mean an obligation on their part, they don’t owe you anything
… so yes, you never had it to begin with.
As you can see in all what I said above, I’m “selling” to my user one or another distribution. Meaning I offer them particular distribution, and tell them what to expect. With old CentOS, i.e. in case A, “binary replica” tells even non-technical users, all will work as on famous expensive product, including stability…
Now case B, namely “stream” incarnation of CentOS, I can not promise the same simply put expectation in my user’s minds.
Do I trust that I will be able to install all they need in Stream? –
absolutely.
Can I promise all will work during [even shorter] life cycle of stream without “glitches”? – With all honesty, no. And I will not jeopardize my reputation in front of my users by not mentioning “expect glitches”. Pardon my non-technical language which I prefer to use with my users.
As others said, this architecture of this new “stream” composition, –
let me say theoretically as I don’t want to go into details of how extremely well you do your technical part, which I am in no position to question – theoretically one can imagine problems happen time to time which one will not encounter using “binary replica” of RedHat Enterprise.
In other words, when talking to me, please, consider me a layman, who can understand simple logic, and rely on reputation earned by distribution during it long existence. So for me in my layman suite:
1. RedHat, including Enterprise: yes, by all means
2. “binary replica of RedHat Enterprise” CentOS which existed for over a couple of decades as such, – yes by all means
3. other binary replicas I didn’t observe carefully long enough, so can not offer any judgement. Except for Scientific Linux which by several reasons I turned down as something one can built future based on, and it didn’t last long, so I thanked myself for staying away from it…
4. CentOS “stream”, sorry this modus operandi does not exists long enough to earn “long standing brilliant reputation” of [and put here what you faithfully are saying about Stream] – not in my book though, and not that I with all faith in it can say to anyone whom I will be installing system on their machine.
Which all leaves me with option:
5. I know this [Debian, FreeBSD, or place there whichever distribution
_you_ know long history of] system is a “rolling release”, so what is installed may change version (and some software internals!) time to time during the life of the system, and things may break occasionally because of that. But this distro exists since forever and I can promise I will be there to see things are fixed when necessary. And this way of maintaining things exists for long time, and many people live with its negative sides, so we will be in a big good company of others like us.
I probably can faithfully say the same as 5 about CentOS Stream, though I should strike “long existence” thus you [addressing my user here] will not see statistics over past life. But then, I have less to offer as expectation compared to other alternative systems.
And as someone mentioned at the beginning of this whole thing that shook our – CentOS users’ worls -: the reputation lies on long positive performance. And changing suddenly something just negates all past great reputation. Even worse: now people [take that as all crowd of layman ones] know something can be changed on whim, and it will take a decade to regain the reputation.
This skews grossly out of subject, and I am reluctant to move up my writing and find the place where to put my “rant begins” tag, so I’ll just continue as is. If the reputation that “this existed since forever”
and it will not change (not on my watch as some will say) mattered for decision makers, then things could be done differently:
the “precursor” distribution of RedHat E… is necessary; Well, let’s set up new project that is being such. Its operational principles are different from those of CentOS (as in “binary replica…”), so the name should be absolutely different, no hint about “CentOS”.
CentOS (as on “binary replica…”), either stays alive, or dies depending of variety of factors.
And having all done this way would prevent anyone from having even a shadow of suspicion that new project (which CentOS Stream is) is attempting to take advantage by using ling lasting reputation of old project (CentOS as on “binary replica…”).
And this exactly is a psychology new CentOS team sees from many directions.
My apologies for expressing humble view that may not chime with feelings of people, especially hard working CentOS team.
Valeri
—
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
I think we’re still talking past each other, but I’ll try one last time:
Critics of Stream often argue that CentOS users are losing support that CentOS never had to begin with. Their argument implies that CentOS has aspects of RHEL that it does not. They are not correct.
Does that make sense? Please, go back and read my earlier message again. You seem to think I am complaining that CentOS is not supported, but I am not.
Il 2021-04-30 21:16 Gordon Messmer ha scritto:
From here [1]:
“Since March 2004, CentOS Linux has been a community-supported distribution derived from sources freely provided to the public by Red Hat. As such, CentOS Linux aims to be functionally compatible with RHEL. We mainly change packages to remove upstream vendor branding and artwork. CentOS Linux is no-cost and free to redistribute.”
Does it means that CentOS was appropriate on all scenario? No. Was CentOS making hard promises about their support or existence? No. So it is *fine* for classical CentOS to disappear if the developer / owner want that. Long live Stream!
But stating that Stream is functionally equivalent to CentOS is not correct. Fact is that the CentOS team did a wonderful work at repackage RHEL, so 99.9% of times it just worked. And it worked for all the time the corresponding RHEL was supported (7 or 10 years). In return, RedHat
(and so CentOS) got much testing and bug-report (I alone reported my fair share of bugs, some with hours/days spent try to reliably reproduce and tracking down them).
Now, with a moving kernel, you simply can’t provide this level of confidence. DKMS is not a silver bullet. See here [2] for an example. Rebooting your kernel and finding you can’t access your storage is a quite a significant problem, no? And when I migrated a test machine to Stream some months ago, even something as basic as dnf had its issues. While I hope that now the situation is better, I hardly can see Stream equivalent to old CentOS.
Regards.
[1]
https://web.archive.org/web/20200721184556/https://www.CentOS.org/about/
[2]
https://listman.redhat.com/archives/vdo-devel/2021-January/msg00005.html
—
Danti Gionatan Supporto Tecnico Assyoma S.r.l. – http://www.assyoma.it email: g.danti@assyoma.it – info@assyoma.it GPG public key ID: FF5F32A8
I re-visit this thread, since it is crucial for CentOS 8 users.
RESF / Rocky Linux is gaining worldwide recognition and sets itself as the primary organization / platform to become the CentOS 8 heir /
successor in the future.
Google and Microsoft become RESF sponsors/partners:
https://rockylinux.org/news/community-update-june-2021/
And so IBM/RH lose the tremendous advantage they had by owning the CentOS project, which – it seems – never evaluated correctly.
From now on, it is clear that hundreds of thousands of CentOS
installations will be migrating to Rocky Linux.
I also wish the best of success to CentOS Stream, but this is not what the CentOS community expected.
My 2c. Nick
There’s also Alma, which is where I’ve gone after being with CentOS
since 5.3
—
J Martin Rushton MBCS
AlmaLinux is a great project too, IMHO, but things show that the new industry standard (replacing CentOS) will probably be Rocky Linux.
(Yes, RHEL **AND** CentOS have indeed been industry standards – the point of reference -, IMHO, and this is what IBM/RHEL have failed to realize: You don’t alter a point of reference.)
It is interesting to see what Service Providers will do with their (huge numbers of) CentOS installations, when they migrate…
From the users/admins’ perspective it is to their interest to have robust and healthy alternatives.
In our org, I am now using Rocky Linux on new installations (without issues) and will be migrating several CentOS 8 boxes to Rocky Linux as well.
Cheers, Nick
It should not be forgotten that Rocky Linux will be a 1:1 rebuild, also in the future. So, to shape this future everyone is invited to participate at CentOS Stream. This is a great future or not?
Il 2021-07-07 11:44 Nikolaos Milas ha scritto:
Yeah, I share this view.
As a side note, I evaluated Oracle Linux because it has working secure boot, but I am somewhat afraid of using it (due to corporate practices). This probably is an irrational feeling (after all, I do not exclusively use MariaDB, but MySQL also), but I prefer to stay on the safe side.
Anyway, I strongly feel that IBM/RH miscalculated the move. Regards.
Le 07/07/2021 à 11:44, Nikolaos Milas a écrit :
Rocky Linux is the New Kid On The Block and gets all the attention.
Whereas Oracle Linux (the best RHEL clone in terms of maintenance reactivity)
has been around since 2006, free as in beer since 2012, and nobody wants to touch it.
Go figure.
—
Microlinux – Solutions informatiques durables
7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32
Mob. : 06 51 80 12 12
Fashion, and Oracle’s past practices. I evaluated
Alma Linux
Fedora
Mint
Open SuSE
Oracle Linux
Springdale Linux and settled on Alma. Rocky was still vapourware when Alma was stable. I’ve seen how Oracle promise no change in the long term, then change their charging model in the past. We got badly burned at work when they took over DEC RDB.
I like Alma’s independence built on Cloud’s experience over many years building RHEL clones.
Just my 2d worth.
—
J Martin Rushton MBCS
It’s simply that Oracle has such a bad reputation in dealing with Open source. Many people doubt them, and doubt that they won’t change things in the future if they think they have a good chance at making money from it.
I think that right now, many are either going to use Rocky or Alma. I suspect that over time, one of them, will be far more used than the other, and become the next CentOS, in the sense that while there were a few RH clones, almost everyone chose CentOS.
—
Scott Robbins PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg –keyserver pgp.mit.edu –recv-keys EB3467D6
Here is another one:
https://navylinux.org/
—
Leon
Agreed re OEL.
A few months after the CentOS 8.x deprecation news was released, Oracle Sales reached out to my organisation and reminded us that OEL was free to use, with migration scripts available.
We briefly considered migrating from CentOS to OEL, but ultimately decided against it since, as Danti indicates above, Oracle has a questionable history, and we feared that their “free as in beer” approach may change to more of a RHEL approach once their user base was sufficiently expanded.
Rocky is community-driven with substantial sponsorship from large, respected enterprises, whereas Alma and OEL are both tied at the hip to corporations. While noone really knows what the future holds, enough of us have been burned by what has been done to CentOS 8.x that we frankly know the stove is hot, and don’t really want to touch it again, if it can be helped.
As others have stated, I appreciate and respect Red Hat’s vision for CentOS
Stream, and I do wish the project all the best. (I’m running 8-Stream on most of my laptops and workstations now, in fact. — It is nice to know what is in the EL pipeline!) I think there’s a great argument for using Stream on DEV systems, etc., provided there is a plan to move corresponding PROD machines to the new EL release by the end of the Full Support window. The decision to abandon Stream 8 in 2024 (vs. 2029) makes broad use of it in my environment a non-starter, in most cases.
As many have observed, the Stream change would’ve been much more welcome were it announced beginning with EL 9.x, but pulling the rug out from beneath CentOS 8.x with a year’s notice, right after so many of us had just finished migrating workloads to it in anticipation of EL 6.x EOL was a very poor decision, imho.
*J. Adam Craig*
Lead Linux Operating Systems Analyst VCU Infrastructure Services <https://www.ucc.vcu.edu/>
Technology Services Department
804.828.4886
jacraig@vcu.edu
<https://adminmicro2.questionpro.com/?t_340030260=J.%20Adam%20Craig&u_65977055=351791134>
*Don’t be a phishing victim — VCU and other reputable organisations will never use email to request that you reply with your password, social security number or confidential personal information. For more details, visit **https://ts.vcu.edu/about-us/information-security/common-questions/what-is-phishing
<https://ts.vcu.edu/about-us/information-security/common-questions/what-is-phishing>*
CentOS mailing list CentOS@CentOS.org https://lists.CentOS.org/mailman/listinfo/CentOS
In our stables it is Debian that replaces CentOS. (And it is closer to FreeBSD in several aspects, the last is what the servers run).
Valeri
I hadn’t seen that one, but I do notice that it aims to be “minimalist”
whereas my main machine is the network server (DNS, DHCP etc), a server
(Wiki, Cloud, storage) and my workstation.
BTW, anyone know who the “Navy Foundation” are? Is this an arm of the US government?
Martin
—
J Martin Rushton MBCS
Hi
What about https://rockylinux.org ?
Best regards Pat
—–Message d’origine—
Navy Linux has a bad taste already, for me. They are aiming too big, even trying to replicate EPEL for themselves. And their attitude isn’t good. They had a tweet disparaging “new unstable vendors” of EL distros that they only deleted after being called out for it, despite being one of those themselves.
Deleted tweet link:
https://twitter.com/NavyLinux/status/1408429562472677381
They used to say they were founded by “Unixlab”. Which Unixlab? We don’t know. Now they say they are a non-profit Foundation that founded the project. https://webcache.googleusercontent.com/search?q
See https://navylinux.org/news/legal/
Simon
That furthers what I wrote earlier. That says:
> Date of formation: June 14, 2021
Yet the about page ( https://navylinux.org/about/ ) was changed to say:
founded by Navy Foundation on January 4, 2021.
They don’t have a straight story, and they’ve been changing it inconsistently. That’s not how you build trust.
+1
The Division of Corporations in DELAWARE shows:
Formation Date: 6/14/2021 (mm/dd/yyyy)
Anyway, in the context of ongoing attacks to the supply chain. This situation where CentOS is running EOL will motivate new black hats to step into the place. Imagine a massive deployed OS that is trojanized?!
So trust is here king and despite all adversity (that also hits me hard) we should thinks twice before running away into foreign arms.
—
Leon
+1
And I feel safe running (and planning to run for long future to come)
quite reputable ones with long history of such: FreeBSD (servers), Debian (number crunchers, workstations).
Valeri
—
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
For completeness, here’s a WayBackMachine link to the deleted tweet. Luckily it got archived.
https://web.archive.org/web/20210625141924/https://twitter.com/NavyLinux/status/1408429562472677381
CentOS 7 not need to move forward to new unstable vendors, wait and watch Upcoming changes. already on CentOS 8 wait until a stable reslease ready for upgrad.@GuyLinux @CentOSannounce #Linux
I’m not affiliated with Navy Linux but it seems to me there’s nothing inconsistent there. They say it was set up as a community project on January 4, 2021 and a foundation (a common component of community projects) was formed on June 14, 2021.
That’s all perfectly straight and consistent. Rocky, for example, followed the same process didn’t it: The community was formed and then a foundation followed soon afterwards.
—
Mark Rousell
P.S. Despite my comment above, I do agree that the disappearing of their reference to “Unixlabs” on their website is not confidence-inspiring. And not making it clear which/who this Unixlabs is, is even more frustrating.
—
Mark Rousell
I feel totally safe and confident with the fully community-driven effort of Rocky Linux, lead by the former founder of the original CentOS
project. (I am not affiliated with them in any way.)
As has already been mentioned, Rocky Linux has managed to gain quickly support from major players in the industry (including Google and Microsoft), and is committed to never drop its independent/community status. It is well structured and organized, and embraces a good number of open-source volunteer specialists.
We want to keep up with RHEL ecosystem and Rocky Linux is – for us – the best option.
If some people want to leave the RHEL ecosystem for Debian or FreeBSD, that’s OK. But for those who want to stay in the RHEL world, Rocky Linux stands as a rock-solid solution. This opinion does not reject other CentOS clones, but emphasizes the fact that Rocky Linux appears to be a solid option for now and the years to come.
Cheers, Nick
Il 2021-07-08 13:22 Nikolaos Milas ha scritto:
While true, I also feel that RH is trying to actively shape its distribution away from small enterprise needs. For example, common packages are deprecated and/or removed (eg: virt-manager, screen, kernel-side DRBD, pam_mysql, etc) and EPEL 8 (which is fundamental to my CentOS/Rocky installations) is in a bad state.
My impression is that RH is following cloud vendors & hyperscale needs –
with Stream as a clear example. This is not an inherently bad thing, but it quite different from what the small and medium businesses I service need.
So, while closely watching RH/CentOS/Rocky, I am going to steer new deployments on Ubuntu LTS or Debian. Regards.
Soon, we will all have to find a way to work with other distributions, or work together to create and maintain new distributions that focus on micro/small/medium business. Eventually, this will be the only way to keep virtualization and hybrid cloud available. Everyone smells money and RedHat is now controlled by IBM, so little by little, we can start seeing the changes, reducing packages, dismantling, re-architecting, re-branding. It’s only a matter of time. Greed is worse than cancer.
Well, I fled servers from CentOS to FreeBSD almost a decade ago. And actually not From CentOS per se, but from Linux. One of the reasons was: every 45 days on average: glibc or kernel update —> reboot. One of my friends started using word “Lindoze”. Linux is perfect for number crunchers and workstations. FreeBSD is waaay better for servers. In my book that is.
Just straightening small nuance.
Valeri
If you aren’t rebooting your FreeBSD systems regularly, you’re just as vulnerable.
https://www.freebsd.org/security/advisories/
I see one less than 45 days ago that requires a reboot because of a kernel security measure bypass.
Long uptimes are a thing of the past. Build redundancy into your infrastructure so you can handle reboots.
—
Jonathan Billings
+1
Beyond building redundancy, I’d suggest building the culture that sees regular maintenance windows as a provider of, not a drag on, value.
—
Paul Heinlein heinlein@madboa.com
45.38° N, 122.59° W
Maybe “we” could fill this gap? Describe this state of EPEL? Did you requested such missing packages? From the early on (EL8.0) I requested such EPEL packages, some fedora maintainers branched there packages into EPEL8. Even a request for a devel package was honored and the rpm was included by RH later in 8.1. This is a community, so communicate!
Everything else is a product in ready state that must be paid.
That original reason to flee for us (one of several as it turned out to be) is dated 10 years back. Not quite fair to apply today’s counter-argument to it. Still a year or two ago when I checked last, and it was about 2 reboots a year required for FreeBSD, whereas <= 45 days is still was a fact for Linux. But as you have said yourself, we live differently today, and several things (like one or few services per jail - the last having read-only base system to mention one) still make FreeBSD much simpler to maintain for servers. Not to mention, switching from Linux (10 years ago) to FreeBSD was quite smoother learning curve than adjusting to systemd and friends ;-) (I'm cheating a bit: I did run UNIXes in the past - waaay back). Of course, tastes differ, but still, only those who tasted both things can have fairly say what is better to one's own taste. Saying not to Jonathan, of course, who I bet runs several UNIXes, FreeBSD included. (of course, not all of them can strictly be called UNIX, - re no loyalties to AT&T). But even as part of our infrastructure fled to FreeBSD, workstations and number crunchers stayed with most adequate for them system: Linux. CentOS until recently, Debian once CentOS stopped being "binary replica" of RedHat Enterprise. Gionatan Danti mentioned another important reason... Valeri -- ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
As a side note:
l never used FreeBSD, even though I’ve heard good things about it. Frankly, I loathe its devil logo. I know it’s probably derived from the Unix “daemons”, yet I fail to get reconciled with it. It’s simply appalling to me (even if it’s smiling) :(
I don’t require any reply on my above comment (I might even be called naive or whatever). It’s some kind of personal confession which I feel I
need to express somehow. I simply wish FreeBSD people changed this logo at some point…
I wonder whether FreeBSD users are expressing similar concerns… I am not following any FreeBSD activity or discussion.
Cheers, Nick
I _can_ understand religious person’s attitude to some images.
I for one consider FreeBSD mascot as created with quite some sense of humor. No more no less.
Being not religious myself, I do agree with what region [Christian?]
says, almost all or it: you shouldn’t steal, you shouldn’t kill, you should be kind to others,… The only thing I disagree with is: they say God created people, I believe it is other way around: people created God for themselves. But as neither can be proven experimentally, the last in my book is really minor disagreement ;-)
Valeri
—
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
THAT must have been part of the reason for mscot. Also, they call mascot Beasty (as in diminutive from :”beast”). And if you pronounce the abbreviation of Berkeley Software Distribution (the one FreeBSD is successor of): BSD, and then “beasty” they sound not that different from one another ;-)
Valeri
—
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
Le 2021-07-08 17:38, Nikolaos Milas a écrit :
I *love* the FreeBSD logo.
But then I listen to Nine Inch Nails and Marilyn Manson while working, so I guess I’m not much of a reference.
Niki
—
Microlinux – Solutions informatiques durables
7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32
Mob. : 06 51 80 12 12
Personally, I have always been a fan of the BSD distributions and have always kept at least 1 virtual machine running a flavor of BSD. However, I am not religious, and have no attachment to anything supernatural or metaphysical or any other pseudo-spiritual thing. I just think with the changes happening at RedHat, we will see some effects soon, including Fedora as well. It is a shame, CentOS has been a rock solid workhorse, perfect for testing, for proofing, for prototyping and all sorts of infrastructural experimentation.
That makes things even worse… :( x 2
Nick
+1
In a lot of circumstances we do not invest a bit of time to participate in such community joint efforts and this has a significant cost for all of us in the long run.
Let’s all be more active in our communities if we want them to remain strong, as Leon suggests.
Cheers, Nick
*chuckle*
I’m reminded of a column in SysAdmin, a long time ago. Seems the woman who wrote? contributed? to the column Daemons and Dragons was wearing a t-shirt with the logo, and she was traveling with some folks in the US
South. She went in to pick up some bbq… and by the time she had the food and was walking out, was afraid that she might be attacked by one or more of the “Real Christians” in the shop, from the comments they made, because of the shirt.
mark
First thing I thought of too.
https://www.netfunny.com/rhf/jokes/new89/satan.773.html
Cheers, Zube
There was a contest to change the logo a while (10-12-ish years) ago, and the official logo is now that:
https://freebsdfoundation.org/about-us/about-the-foundation/project/
However, that logo wasn’t universally liked by some core-members and it looks like the „Daemon“ is thus still in use.
The „Daemon“ is IMO somehow more approachable and „cute“ if you want to say that.
Il 2021-07-08 16:46 Leon Fauster via CentOS ha scritto:
For what it is worth, I opened various RH bugzilla enhancement request in the 10+ years of using CentOS. One of the last:
https://bugzilla.redhat.com/show_bug.cgi?id02781
That said, lets face in: current CentOS is not really a community, at least in the sense that a community can steer the project direction. Nobody polled for Stream or asked about it. Stream simply happened due to an unilateral Red Hat decision. *Which is PERFECTLY fine*, unless trying to masking it behind the “community” word.
My view is that RH/CentOS would be relatively inadequate for many roles without the outstanding work done by EPEL and the rest of the CentOS
community, unless you are an hyperscaler who can do its own internal package additions. Red Hat failing to recognize the enormous value of EPEL and former CentOS model really baffles me.
Regards.
Exactly so.
So, this enormous and invaluable effort should not be wasted and abandoned, but should continue and thrive within full community-driven projects like Rocky Linux.
This is what I mean by community effort. CentOS is no more a community-driven project, but others emerge. Yet, currently the only one with true community characteristics is probably Rocky Linux.
Cheers, Nick
The motivations behind Rocky Linux are noble indeed, altruistic and back to community. But, accepting support from Amazon, Google, and especially Microsoft tastes like vomit in my mouth. Nothing in the world I despise and disrespect more than anything related to Microsoft.
Get better sponsors, get community funding!
They are the 3 largest cloud services there are. That’s what the support is for. They are working with the platforms that will be running their OS on potentially millions of instances. Welcome to the 21st century of computing.
Understood….. like all previous trends in technology, that too will change, the landscape is always changing…… I’m an idealist, there is no way in hell I would ever accept anything from Amazon or Microsoft, never…would rather fail than surrender principles
Good phrased. I see it exactly like this but let me take a dialectic position just for the sake of insights. CentOS Linux (or Rocky Linux)
is a downstream rebuild, right? So, the fences are already set. Right now, I am seeing a lot of requests in the Rocky forum, to add new shiny stuff to the distribution and the answer to most of this is (more or less); “we (Rocky) are a 1:1 rebuild of upstream and we can not add new stuff in an arbitrary way”. So, when talking about a community then we have different concepts behind it. A RH ecosystem community is not the same as a Debian community. It was never and it will never be the same.
I see the RH ecosystem as a hybrid opportunity (perspective from the outside), so not all “directions” can be influenced but there is enough room to contribute to directions especially with Stream now.
PS: Do not get me wrong; the whole communication from RH about this
“CentOS Change” is catastrophically.
Well said. It is worth pointing out also that, while Kurtzer and other Rocky community leads are devoted to keeping Rocky 1:1 with upstream, they are also committed to engaging with the CentOS Stream community themselves
(if they find a bug in upstream code and they can fix it, Kurtzer and others have stated multiple times that they will contribute the fix into Stream), and to encouraging such engagement among those who desire to see improvements with upstream. In other words, if we are uncomfortable with the direction Stream is going, the preferred approach is mobilisation within and engagement with the Stream community to have those changes realised there, so that they flow into Enterprise Linux and everyone benefits.
Le 08/07/2021 à 22:53, mario juliano grande-balletta a écrit :
I started with Linux back in 2001, the year where Microsoft CEO Steve Ballmer called Linux “a cancer that attaches itself to intellectual property”, so my views on Microsoft are about the same as yours.
This being said, things have changed, and Microsoft is now – amongst other things – the most important contributor to the Linux kernel in sheer terms of lines of code.
Cheers,
Niki
—
Microlinux – Solutions informatiques durables
7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32
Mob. : 06 51 80 12 12
Embrace, extend, and extinguish. https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish
Remember the leopard never changes his spots.
Martin
—
J Martin Rushton MBCS
I don’t think that’s true.
Microsoft has, infrequently, appeared in the top 5 for specific releases. Mostly, as I understand it, those were due to large dumps of Hyper-V related code. Overall, Microsoft doesn’t appear to be active in the Linux kernel, though they do have a large number of Open Source projects of their own.
In general, Intel and Red Hat seem to be pretty consistently the top two corporate contributors to the Linux kernel.
Il 2021-07-08 23:21 J. Adam Craig ha scritto:
While I fully understand & agree on the motivation for keeping Rocky
(and other clones) 1:1 with Red Hat, it should be understood that current RHEL packages selection itself is drifting away from small/medium business needs. So the core issue is a more fundamental one: Red Hat, our upstream, is walking away from traditional server needs.
So while I wish Rocky all the best (and I am actively using it!), I am looking toward Ubuntu and Debian for new deployments. Regards.
IMHO, this is a more fundamental discussion, which is beyond future CentOS versions and alternative RHEL-compatible projects and it deserves a separate thread.
In any case, I think that the existence and continuous availability /
maintenance of external RHEL / CentOS-compatible repositories probably provides a solution for most use scenarios. Of course, I cannot possibly know all actual needs, so I may be wrong.
I need to recognize the fact that it appears there is still a shortage of packages for CentOS 8, even though it is active for quite long already. Maybe this is mainly due to EPEL difficulties.
Nick
Il 2021-07-09 13:57 Nikolaos Milas ha scritto:
Sure.
This is my impression also. Regards.
—
Danti Gionatan Supporto Tecnico Assyoma S.r.l. – http://www.assyoma.it email: g.danti@assyoma.it – info@assyoma.it GPG public key ID: FF5F32A8
Once upon a time, Gionatan Danti said:
Like any commercial product, RHEL exists for Red Hat’s customers… so if you want to see something specific from RHEL, you need to be a customer to give input.
Thanks! That’s exactly the one I was thinking of.
mark
Any extensions beyond rebuilding TUV provided code are why CentOS, and now Rocky, have SIGs. There is an appropriate place for these requests, but it is not in the main project.
https://git.rockylinux.org/sig