CentOS project changes focus, no more rebuild of Red Hat Enterprise Linux – you'll have to flow with the Stream The CentOS project, a non-commercial Linux distribution that tracks Red Hat Enterprise Linux (RHEL), is changing to become only CentOS Stream, based on a development branch of RHEL and therefore less suitable for production workloads. The implication may be that Red Hat has decided that the availability of CentOS undermines …
Ouch. Well this is going to cause me a lot of work and grief! I suppose I should be vaguely happy that at work we haven't entirely committed to a CentOS 8 rollout yet.
I guess IBM had something to do with this, seeing CentOS as effectively giving away RHEL's lunch. I'm sure some people (well companies) may flip back to RHEL, but others will go elsewhere. So if some at IBM think they'll get a sudden influx of cash they'll be sorely mistaken.
I find it a bit confusing that they'll effectively turn it into not-quite-Fedora. Maybe they just want to turn it into the more experimental bit for server stuff and pivot Fedora to be more workstation stuff?
Overall a bit crap that they commited to CentOS 8 as is (to follow RHEL 8) and are now pulling the rug.
CentOS Stream isn't "not quite Fedora", it's something pretty different (though obviously we haven't explained this very well).
CentOS Stream isn't the development branch for RHEL in the sense that "right now, it's getting stuff destined for RHEL 9". It's where development on *current stable RHEL* happens. So right now, the latest RHEL release is 8.3; CentOS stream is where the bits that will make up RHEL 8.4 are landing.
When RHEL 9 forks from Fedora, CentOS Stream will be where development on RHEL 9.1, 9.2 etc. happen.
tl;dr: they're both "development", but at much different parts of the cycle, and Fedora is much further ahead.
It is still changing from Stable plus a few days to beta. How beta is it? is quite well described by "not quite Fedora".
I think it's lame to make the name CentOS a beta branch. Its disingenuous.
I hope some one tracks RHEL, CentOS users wanted that.
I know redhat cost money, it also sells Linux.
Sure, it's still a change, and whether it makes sense to use the CentOS name for this thing is a legitimate question. I just wanted to highlight there's a substantial delta between CentOS Streams and Fedora. As far as RHEL is concerned they serve different purposes, and will rarely be similar at all.
So since yesterday I found out (from https://www.redhat.com/en/blog/faq-centos-stream-updates#Q6) that we'll actually have one CentOS Stream per stable RHEL branch - there won't be just one. Right now only CentOS Stream 8 exists, but from Q2 2021, CentOS Stream 9 will also exist. Basically as long as a RHEL release is in active support (until 5 years from release), development for it will be done in a numbered "CentOS Stream X" branch. If you're on CentOS Stream 8 when CentOS Stream 9 appears, you don't get kicked over, or anything, you can stay on 8.
If you think about it, though, it should be clear the CentOS Stream branches will usually be quite a way "behind" Fedora, in general terms. Right when RHEL X forks from Fedora, that CentOS Stream X branch will obviously be very similar...but then Fedora will roll along keeping up with stuff while that CentOS Stream X branch will stabilize. CentOS Stream will be where release stabilization and minor release development happen - going from fork to .0, and then from .0 to .1, .1 to .2 and so on. Major feature development won't be happening in CentOS Stream branches. It's just the same as RHEL stable branches today, really - if you think what's in RHEL 8.3 and what you'd expect to be in RHEL 8.4, it's "behind" current Fedora in most ways, for instance. CentOS Stream 8 is where those bits that will make up 8.4 are going. So it's a "development" branch in that sense, but the kinds of development being done there are the changes you get between minor stable releases of RHEL. Not the kinds of changes that go into Fedora Rawhide.
That does make a lot of sense and gives a lot of clarity to what is going on.
Have one distribution name for the real product - RHEL.
Have another name for next minor release development - CentOS.
Have another name for the next major release development - Fedora.
My only concern is given the comments we are seeing is whether it is appropriate to reposition/hijack the CentOS and Fedora distributions or should RH have given these two development distributions new names.
This isn't really a change for Fedora at all - so far as RHEL is concerned, Fedora has *always* been the "far upstream", and that's not changing in any way. (With a Fedora hat on, Fedora is certainly not *just* RHEL's far upstream, but *if you're thinking from a RHEL perspective*, that's what it is to RHEL).
So far as CentOS is concerned, sure, that's a valid question. I've seen some answers to it internally but I dunno if I'm allowed to post them publicly so I'll hold off.
Embrace, extend, extinguish. Oh hang on, wrong company. Perhaps it should be Inspect, Invest, Inhume...
I moved off RedHat 10 years ago. They used to charge a modest fee for their MRG offering, and then they realised it was mostly used by high speed share trading investment companies so they upped the asking price to something like $3,000. Per node. Per year.Ah, bye bye. As all I needed was the "R" bit, we moved to a hybrid of Centos / Scientific Linux (as the names were back then).
Er, SystemD's Future?
This does beg a question though. With CentOS "gone", there's likely a bulk move away to another distro. That'll mean it'll become increasingly hard to find people who "know" the RHEL-style of distribution. So that might in turn diminish interest in outfits willing to pay for RHEL, and that might finish off the company.
Now, if RedHat shut up shop, who the hell takes on the demon spawn SystemD?
Lord knows that if we're to have such a hideous thing such as systemd, there really does need to be a big corporate backer who'll undertake to keep lots of resources focused on it. If dev / bug fixing stops anytime in, say, the next ten years then it's highly likely that there'll still be some catastrophic errors in it, unfound, unfixed.
Support Worth Paying For?
I honestly never saw the point of RedHat's "support". I never once got a good answer out of them, and got the distinct impression all they were doing was thumbing through a set of search results just like I could do myself.
The support from RHEL was no where near the level you had from, say, Sun in the very good old days, where they'd got a ton of detailed technical literature available for literally everything there was to know about their hardware and software. I'm happy to pay for that level of information.
"Lord knows that if we're to have such a hideous thing such as systemd, there really does need to be a big corporate backer who'll undertake to keep lots of resources focused on it"
A snarky post I wrote here a couple of years ago about systemd.
"no where near the level you had from, say, Sun in the very good old days"
Why, thank you! :-)
Of course I can't actually take credit for even a tiny fraction of it all but I spent over 10 years at Sun doing 3rd line support of Solaris and the SPARC + x86 hardware. I can certainly say that it was an incredible place to work and that the vast majority of my colleagues, both in the UK and the ones I got to know in other countries, were really passionate about our products.
It was quite common that we'd get support calls for problems with a certain monolithic relational database where the customers would say that they knew it wasn't our product but we'd be likely to triage the Problem better than the correct support channel (I never experienced said DB's support offering so cannot judge it myself)
And then Sun had a stint at offering RHEL on some of their tin and I distinctly remember customers being less than impressed with their offering.
There was a slightly embarrassing situation where Sun was selling a fairly beefy x86 workstation with an equally beefy NVIDIA GPU in it which required a proprietary driver - when customers choose the RHEL option with support they weren't so impressed when, upon getting kernel "oops" panics, the response from red hat was along the lines of "Propriety driver loaded? Oh, so your kernel is tainted then. Not supported. Bye!". My understanding is that they simply wouldn't even look at it in such a situation, even if the graphics driver had nothing to do the the crash.
I know there were tonnes of cases where we'd do a full crash dump analysis to identify which 3rd party driver had caused the crash an often an outline explaination of why as well. Obviously we'd then have to send the customer back to their other vendor.
It was a thriving, happy place to work in support.
Many of the great minds have moved on or retired but there's still a small core of the original Sun backline techs working at Big Red and still being just as passionate about what they do even though big changes to the product line and support model may make it less likely you'll get to speak to them directly.
A bygone era sadly, but a happy memory for many.
I generally use CentOS to develop an install plan for RHEL deployments as I can do that without having to carry the cost of a licence that's only used on (e.g.) a local VM. Guess I'll have to see what a developer account allows.
Will also have to re-evaluate what I use for non-profit, small scale installs where I would normally just deploy CentOS.
Call ne sentimental, but I was quite attached to IBM for many years. Their x-Series servers were solid like rocks, and at the time this was even more important than it is today. And they were quite early on the "Linux is the default OS for a server" bandwagon. The SCO saga (most of you will remember groklaw) added more respect to that.
But it is not ment to be. They seem to be just are unable to cope with the realities of today, where you can't slap an IBM sticker on something to double its perceived value, where the only ultra-high-margin cashcow remaining is the mainframe, which is going the way of the Dodo. Any of those perky new banks or insurance companies using them? Nope. And DB2 neither.
Instead of adapting, they chose to do more of the same - not good. Bye, IBM, it was nice while it lasted.
It's perfectly normal corporation procedure, but in this instance, more like muscle memory ;-)
[As the Big Blue Eye of Salron focuses]:
"What is this little (opensource) piece of the business?"
"Is it not charging money for our troll's hard toils?"
"Cut it off! Our efforts are better spent on projects that deliver ROI!"
Only when the products it nourishes wither and die, will it become more obvious where the returns were.
Dr Watson might need to complain a bit louder perhaps!
Maybe White Box Linux will be revived. It was another RH clone but discontinued, largely, I think, because Centos covered the same ground. Fermilab also opted for Centos 8 instead of developing a new Scientific Linux 8. Maybe they'll reconsider. It would be surprising if nobody picked this up.
I was thinking the same: bring back Scientific Linux.
There's not much point running CentOS in production if it means you're running beta code (although at least you don't have the 9-month upgrade cycle of Fedora). Ubuntu/Debian looks much more attractive.
However, the fact that there was no in-place upgrade from CentOS 6 to CentOS 7 also put me off it anyway.
On the other hand, a lot of the actual scientist-developer mindshare (cue lightning bolts and "The switch, Igor!") seems to have moved much more to Ubuntu or Debian in recent years, probably because Ubuntu was easier for someone to install and set up a (somewhat flammable) "garden shed" tinkering development environment on their own laptop/desktop, and partly because (in my experience) academics seem obsessed with having the Newest! Shiniest! packages at all costs, mercilessly rolling the boulder forwards and leaving no time for any sort of actually stable moss-based ecosystem to take root for even the briefest moment (watch that cutting edge, you'll cut your fingers, oh, you already have…). If teh shiney toy they wanted to research with also needed any support packages/libraries newer than even 3 or 4 years old, trying to install said packages on RHEL, etc, mostly wasn't a go-er…
Oh, quit being so cynical. They totally are changing focus: Changing focus from being a viable alternative to paying redhat licensing money, to not being that anymore. It's totes just a fortuitous coincidence that the synergies they're leveraging happen to remove a free alternative to the parent companiy's commercial offerings, and not at all an attempt to strong-arm people into paying for their distro. Honest!
Our CentOS 7 to 8 migration work has just come to a screeching halt. On this occasion our corporate love of grinding policies has actually helped and we hadn't gone too far down that road yet. Separately our new HPC system would have been CentOS 8 with a couple of RHEL licences just in case we need support - that plan scrapped while we consider an alternative. It will probably be Debian or Ubuntu, and the same for the rest of the estate come 2024.
Yes, don't terribly like the look of this. Covid got in the way of our moving to RHEL8 and maybe it's just as well. We're currently covered by a site license, but we have to rely on what the community is willing to support, and many of the groups we work with target CentOS and Debian. If this causes them to drop CentOS then license or no it's increasing pain to stay with it. Coupled with the Gnome3 thing I'm wondering what IBM think the RedHat market is, or is this just the embrace, extend, extinguish cycle?
If i were Canonical i'd be popping champagne bottles now. I forsee a massive shift from centos to ubuntu server.
Personally i'll keep using the old and trusty debian in my homelab, but i know that companies that use centos today without any kind of support contract will move to ubuntu.
Fairly recently I used CentOS 7 & 8 to explore various security problems with RHEL 7 & 8: I couldn't use RHEL as I don't have a license, but I was convinced that CentOS was identical enough that I'd see the same behaviour.
Now I can't do that, and much more to the point nor can anyone else. And so the world is a little less secure. Thanks Red Hat: previously I only suspected how much you cared about security, now I know the answer is 'not at all'.
It's IBMs fault those options are no longer available for free.
This change is IBM not giving RHEL free to the community but still expecting the community to give RHEL free to IBM. Identical policy to Microsoft beta testing with consumers.
I wonder how many people out there happily beta test on Fedora in return for stable CentOS. IBM is about to find out.
That is something that sounds like a good option until you think a bit. The reason it's probably not a good option is that it involves signing a license, with terms and conditions which may, but only may, allow the person signing it to disclose vulnerabilities. That would require more careful reading of the agreement, and in particular section 9 of it, than I am competent to do, for sure. Good lawyers are the answer to this, but requiring a good lawyer puts the thing immediately out of the range of things-normal-individuals-can-afford.
And no, I'm not happy, and nor should anyone be happy to just sign the license and not worry in a case where the information I might discover might be seen as harmful to the commercial interests of a very large corporation with very expensive lawyers.
I teach Linux and write training classes on Linux. This is mostly done on CentOS as the customer wants the students to have Red Hat skills as that is what most commercial sites use (read sites that will pay for stuff). As I was eating breakfast this morning I had yet another phone call from Red Hat
"Are you going to renew your subscription...blah blah..."
I'd replied yes, but I'll wait till near the end and renew then rather than paying early thank you.
Then I got to my PC and read this story.
If events had been the other way around the answer to Red Hat would probably have been different.
I pay for Red Hat because I want access to support, I want access to their customer only site. But most of my work is done on CentOS. I've never minded paying for the support. But if there's no CentOS there is probably no need for me to pay for RHEL.
How to lose sales and influence people.
People don't only attend training before they graduate. Since very few commercial sites want to be on the bleeding edge most of the training isn't on there either. Red Hats certification might be concentrating on their latest things but LPIC/CompTIA exams cover stuff that dates back into the dark ages. So whilst you have to give the students a view of where things are heading you also need to show where they've come from and where most sites are currently standing.
Most of the customers (those paying for the training I'm giving to their staff) want people trained on RHEL. Currently I can tell the students "If you want something to play with run CentOS it's all but identical to RHEL but you don't have to pay to play" with this change that comfort factor goes away.
Yes, I thought exactly the same thing. Microsoft don't seem to be that way any more under Satya Nadella, and genuinely seem to have moved on. Shame that Red Hat (well IBM) are becoming the new Microsoft. How weird to be even saying that, but that's 2020 for you.
The Red Hat sales people I've talked to were quite annoyed with CentOS long before the IBM acquisition. Why pay for support - which honestly is not very good unless you are paying millions per year - when CentOS is as good?
The last couple of years RH have been making it harder for others to clone their OS. Taking over CentOS and making it unfit for production use is just the latest step.
We'll see how long they actual stick with the "open source" and GNU licensing when we get a good replacement for CentOS :-D
Redhat cannot abandon GPL for the kernel and command set without risking serious repercussions from the FSF and rest of the community, and possible law suits (although they may have to be crowdfunded, as RH and IBM between them have some quite considerable legal and financial resources).
But the community as a whole would be quite badly affected if Redhat (and, by implication IBM) left. I believe that both RH and IBM have been some of the biggest contributors to kernel development for quite a long time.
What I believe they will do, and there is already a history of this, is to add essential, non GPL code to the RHEL offering (as they do already with Satellite and I believe some other things like Gluster) which make the open source code they publish under GPL not complete enough to build a work-alike.
I always thought this could happen ever since RH started propping up, and then controlling CentOS. I do now worry that IBM may make a power-play to try to reduce the freedom of GNU/Linux. They had been making a lot of progress defending it over the last couple of decades, but we have a different management in control now.
What I believe they will do, and there is already a history of this, is to add essential, non GPL code to the RHEL offering
Oh that's easy. Just replace part of systemd with proprietary code that either links to the LGPL rump, or is "optional" in a way that breaks key functionality without its presence (logging would be a good candidate, or the dns resolver they put in for some stupid reason). Not only does it prevent anyone from cloning redhat, it gives them almost immediate legal control over the entire linux ecosystem. Distros will either have to knuckle under and accept a proprietary blob in the init, or fork and replace it, without being sure whether redhat have snuck a few more landmines in there.
Good example, but so far systemd has not completely taken over the roost. It is not too late to revert this change, but doing so is likely to prevent some other technologies that have become systemd dependent from being deployed.
In fact, I would like to see a systemd dependent OS fork from Linux (while hopefully keeping the Linux name on the non-systemd branch) to enable people to make a real choice, rather than opting for a distro, only to find systemd creeping in as the versions evolve (Debian and downstream distro's, I'm looking at you).
I've been around here long enough to know about Devuan. In fact, I have it in a VM, and am looking to see whether I can switch from Ubuntu to it.
But I would like to see Systemd/Linux to be renamed something other than Linux. If Redhat start hacking around too much, and not, or being prevented from, putting their changes back into the kernel Git, then the Linux rules state that they must stop using "Linux" in the name. You could then allow Redhat Systemd to become it's own OS separate from Linux, and stop corrupting the mainline.
"Linux" refers to the kernel, not the things that run on it (including the startup application)
Distros basically handle everything but the kernel itself. But you knew that, right?
RH may have gotten too big for their britches. Poettering things are not the only problems, as evidenced by this article.
FreeBSD uses things like 'hald' to compensate [in part, anyway] for not having systemd. I can't recall what Devuan does, maybe alternate builds or patches or a combination of all of that. In any case "a mechanism exists" and there's enough demand for it that packages SHOULD be buildable and runnable without systemd being there. If not, time to submit a patch with some '#ifdef' blocks for when the configure script doesn't find systemd.
Devuan does not do anything to compensate for not having systemd. nothing is needed. GNU/Linux still boots happily with systemV. most servers work if it's compiled with a --without-systemd flag, often that just affects boot scripts autogenerated by the build for specific distros.
A few tweaks are needed but nothing structural is needed to "replace" systemd. Nothing in Linux requires systemd.
I use Devuan, and Ubuntu, and I also have frankenstein builds made with Ubuntu repositories _without_ systemd as /sbin/init. Booting a custom /sbin/init (not sysv) . Surprisingly all Ubuntu packages I've needed compiled with systemd run without system installed.
I would not recommend that for a desktop, but for servers, Ubuntu sans systemd is viable. Despite what Pottering will have you believe.
Seconded. I took punt on Devuan on couple of builds (couple of laptops and servers) and can't fault it (at least in situations where I opt for Linux instead of Open/FreeBSD).
When I eventually need to rebuild the boxen running CentOS it'll be bye bye RH and hello Devuan (or FreeBSD).
I'm aware. The problem is, right now, all the big distros have settled on systemd as the default, and enough of the broader ecosystem has made it a hard dependency that replacing it is becoming increasingly difficult.
Which is rather the point I was trying to make.
I beg to differ, people want their apps to work in containers so hard dependencies on systemd are very rare.
Server software that does not run on k8s would be a strange decision. It's certainly not the norm.
k8s will save us from systemd,which is the same thing as saying systemd was a bad idea in the first place.
Ideally software built for containers will have no depencies at all and can run as a statically compiled binary.
I think you mean Poettering about.
The strange thing is that I can see the need to have an altered init system. I'm not so wedded to System V init and it's variants to not see it's flaws. It's just that systemd is not a good replacement IMHO, and is trying to do too much, while not actually achieving it's original primary goals, and making the OS startup almost impossible to understand/debug without black arts knowledge.
At least init, rc and rc.d can be pulled apart, allowing even quite modestly skilled people to follow everything through.
These days, imho, System V's primary selling point is this. I learned about init & felt quite comfortable manipulating /etc/rc* the same day. It is dead-easy to learn.
It also has desperately needed to be replaced for close to twenty years, according to my sysadmin friends at the time.
not complete enough to build a work-alike.
standard practice when you have proprietary things and other stuff you want to protect.
If these things are _CURRENTLY_ open source, time to fork them and remove anything that RH might object to being distributed outside of CentOS or RHEL
Ah, yes, sales.
The 2003 'monetisation' of Red Hat Linux that became RHEL was the direct driver for Scientific Linux/Fermilab Linux i recollect from reading on the Internet. Details hazy but Red Hat sales quoted something like $30 per core. When it was spelled out slowly to the sales operatives that the computers used in particle accelerator labs have thousands of cores a discount was (eventually) offered, something like $15 per core.
The HEP community did the sums and expanded the role of some of their IT staff to include an independent recompile. There used to be a PowerPoint presentation from an HEP conference with the sums floating around the Web.
Once again in 2020 we have the sudden imposition of a new release plan part way through what was stated as a 10 year support lifetime for CentOS Linux 8. I get the impression that is what is annoying people. Had the change been brought in for Centos Linux 9 then perhaps there would have been less jumping up and down. The change would also perhaps have generated less noise if the new non-profit/open source licences for RHEL that have been promised for 'early 2021' had actually been firmed up and announced at the same time as this change.
Springdale Linux is still independently built from the source code that RedHat chuck over the wall, which I have to assume will mirror the state of released RHEL in order to comply with the GPL. Springdale Linux was PUIAS Linux and they do tweak things to suit their installations so perhaps test very carefully before swapping the yum config to point to their repositories. The Springdale Linux 8 boot images are not linked to the main page, they are at
http://springdale.princeton.edu/data/Springdale/8/x86_64/os/images/
The project does not bother with a large DVD image. This is a small project for a couple of academic institutions, but they do have their own build process independent of CentOS I think which might save a possible DentOS project some time.
I have no doubt that CentOS Stream will be fine for non-critical use such as endpoint desktops etc. But as one server farmer pointed out on another forum the updates will dribble over rather than coming in well defined point releases which is problematic for non-commercial large scale server use.
Johnny Hughes is doing a sterling job of trying to clarify/defend/sell this change on the centos-dev and centos mailing lists. Very grateful for his and Karanbir Singh's work over the last decade or so.
Of course, there is always Oracle Linux
http://yum.oracle.com/oracle-linux-isos.html
Ah, my coat.
Remembering when Red Hat 9 became Red Hat Enterprise Linux 2.1 ...
Ever since, Red Hat has been non-free - artwork and other branding meant that you couldn't distribute Red Hat media or give it to other people. The fork by Oracle then meant that they started giving out source in more and more inconvenient packages. I've had huge arguments with work folk who say "Oracle Linux is Free software - look, it says so on their site".
CentOS has always been ideal if you wanted to teach yourself Red Hat-isms / debug problems someone else was having on Red Hat. I realised part way through waiting for CentOS 8.3 and looking at logs for the build process for CentOS 8.3 that the distribution couldn't be correctly built because the Red Hat engineers had pinned the build process to fixed versions of packages that weren't in CentOS and no longer in Fedora - they'd not kept track of dependencies for what is, essentially, a small distribution and effectively jumped the shark.
Now lots of people are jumping up and down and suggesting forks, restarting Scientific Linux to build 8.* - leave the whole mess behind and move to something else that's developed in public. I suggest Debian (as I have done for 25 years) or possibly Ubuntu.
I've seen other people say on things like the Beowulf list - my vendors only support their hardware on Red Hat - respectfully request that the code is properly built for something different or is freely given for you to build it yourself. If the vendor is not prepared to do that, deny list their hardware from all your future procurement and publicise why you will scrap that hardware at your earliest opportunity as a security risk and a poor example of vendor lock-in.
Springdale Linux springdale-users google groups based mailing list has this thread from yesterday...
https://groups.google.com/g/springdale-users/c/Wv1Y23Ky1-I
I'd imagine they need to think it through (Springdale is a small HPC focussed project with a few universities pooling resources). Depends on how RedHat release the RHEL srpms in future as to if there can be stable point releases but that is just my blathering.
FWIW, the official line on this (mmcgrath, who is more or less in charge of this whole thing, has stated it on LWN, so I think I'm OK to state it here too) is that we don't object to clones existing. We apparently (I work for RH, but definitely am not in charge of this whole thing) decided that *owning* one wasn't such a great idea any more, but we do expect that others will (re-)emerge and are not intending to try and stop that or anything. We're just not letting any of them be called CentOS.
Yeah, I'm afraid I can't really answer that, sorry :\ I know that it's a question a ton of people have spent a ton of time cogitating about, and oh the slide decks. But I didn't read them all so I really don't want to try and explain it, because I'd probably just mess it up.
If you can find Rich Bowen or Mike McGrath around the interwebs somewhere, ask 'em. They'd be in a better place to tell you.
Yucky yuck yuck corporate weaseling speak at its worst : why can't they just say "we are doing this to make more people have to pay for it". They're basically saying you can have the Beta test version for free and help fix it, but once we've done a production release when problems have been fixed you have to pay for it. Sure, the community will ensure a free version remains available, but it will be more work and less attractive - obviously IBM's strategy to try and milk cash from its investment.
They've turned it into C*ntOS. Fill in the wildcard yourself.
I recently upgraded my desktop from CentOS 6 to Debian Buster as CentOS 8 had Gnome3 as the desktop - Debian gave me the choice of the Mate desktop. So the lack of a desktop that I like has let me avoid having to upgrade twice in 18 months - phew!
It now looks like me and my customers are going to have to go the same way on servers.
In case you wondered about these decisions the same Ex-CEO whose leadership bled dry the dead horse after whaat was it? 24 Consecutive quarters of losses and probably 30+ quarters losses non-consecutively is still making decisions behind closed doors.... Make what you will of that....
Looks like our next tech. refresh will be onto a different distribution.
Actually, that might not be a bad thing, as RedHat seem to be royally buggering up RHEL by taking away useful, simple and working things and replacing them with new, complicated and broken ones (systemd, ntp, ... ).
it “removes confusion around what ‘CentOS’ means in the Linux distribution ecosystem.”
I've used CentOS for god-knows how many years. No confusion here: it's production Red Hat for those people who don't need the support. Simple.
Goodbye CentOS, I knew you well. Fare thee well in your travels into the sunset.
Very sad. :-(
... working for big corp consultancy, and similarly big corp clients, I often ask myself whether "OMG what about support?" is really the issue it seems to be. It seems to be rather more about having a contract with a company big enough to be sued if something goes wrong rather than access to any specific technical expertise. Most of these support agreements just seem to be money for old rope - they cost so much that if you could put the money in a pot to hire knowledgeable contractors to fix issues when they pop up, you'd be better off doing that.
I've certainly not seen RHEL, Microsoft, Oracle or SAP supply technical help that even matches a good independent specialist in the last 20 years.
Am I just hopelessly naïve?
Where I have been involved with a company that deploys RHEL, it has been more about certification rather than actual support, though our customers seemed to think it was about support (who were we to disagree?). If this (the certification) is the reason for RHEL subscriptions, then CENTOS were not costing IBM/RH a penny. However, removing the current CENTOS-as-a-mirrotr-of-RHEL distro will mean less expertise in the technology out there which will raise the entry barrier to RH subscriptions.
Support for a lot of places is the AA/RAC option - there for the absolute emergency - much more since local expertise + <favorite/least disliked search engine> gets to the bottom of most issues these days?
Don't like paying the AA/RAC, but when your car dies in Cornwall and you need to get you + family back for Xmas...
Start Rescue are much cheaper. Not had to use them yet myself but turned out in an awful rainstorm on the M6 to sort out my daughter's car. I know how bad it was because we were a few miles in front and had to double back to pick up the grandchildren and take them on to Tebay to get dried out.
Don't like paying the AA/RAC, but when your car dies in Cornwall and you need to get you + family back for Xmas...
International Rescue! Thunderbirds Are Go!
Any who find themselves in danger, anywhere in the world, need only put out a call for help - on any frequency - and, from...somewhere...I.R. will hear it, and respond.
Although small in terms of personnel, the services rendered by iR are available throughout the Solar System.
unless Zaphod Beeblebrox has put in a hostile takeover bid on the stockmarket ... you know these interstellar corporations ... there is always the risk that Lord Crumb is not dead, and Crumb's Crunchy Delights hasn't abandoned its efforts ...
(A different AC)
Support is invariably the same anywhere: 1st line are often useless (but with some exceptions, who, if they have any sense/luck should get promoted), and with the brains and memories of goldfishes, but once you get a level or two beyond, hopefully there are people who know what they are talking about and who have good problem diagnosis skills, and, eventually, actual developers who can identify bugs from the reports and implement fixes.
Which brings in the other side of support contracts: it's really a way to sneak "donationware" past your beancounters in order that the distro developers keep getting paid and your distro keeps getting developed. Of course there is a lot of voluntary effort that goes into the whole FOSS ecosystem, but if there weren't also the paid developers as well, has anyone ever crunched the numbers to work out just how much less advanced it would be today without that effort as well?
No, I''m with you on that. "Support" in the big vendor sense of the word is usually useless. Application-specific stuff ends up scattered knowledge between the users on the recieving end or the developers who immediately scatter off to other projects the moment a contract is up.
Build it yourself is the only way and pray you have someone able to work on your code in line to follow.
> Am I just hopelessly naïve?
Not hopelessly, but a little maybe.
My experience of working for a big consultancy (but with software packages rather than the OS) is that if something has gone wrong, and the project is stalled, then being able to say "we've raised a support call and escalated it to priority 1" seems to placate senior management in the sense that they feel they've exhausted their options so have no choice but to wait.
If you were self-supporting then there would be constant, hourly demands as to why it wasn't fixed yet.
To be followed up by hourly conference calls to report progress and understand why it wasn't fixed yet. :-(
"If you were self-supporting then there would be constant, hourly demands as to why it wasn't fixed yet."
In a well-managed business the constant, hourly demands go to somebody who sees it as their job to absorb those calls and keep them away from whoever's doing the work.
In a less-well managed business the reply to "why" is "because I keep answering bloody stupid calls wanting to know why it's not sorted instead of sorting it."
In in ideal world there's be one call - "Let me know when you're finished. If you need anything or anyone gets in your way, call me.".
A small startup is unlikely to license RHEL servers for tasks. The real choice in that scenario is a Debian Stable based distro (including Ubuntu LTS Server) , or Centos. The advantage of Centos is that it is enterprise proven. Deploying it means the admins get used to dnf/yum, rpm and all RedHat quirks, so RedHat benefits from that. If the company wants RHEL support it is a small skip and a jump to RedHat Enterprise Linux.
If this is IBM driven, they are making a big mistake, and IBM should know better. The reason why they went into Linux in the first place (in the 90s) was that their customers Sys Admins ran Linux boxes, and more or less requested IBM do so. To ignore them now is stupid.
It depends on what you’re doing with the servers. We have applications that are not supported on anything other than RHEL. A quick unscientific survey of 6 of the apps we use and only RHEL is common on all. SLES is next, supported for 4 apps, Ubuntu is supported for 3 of them. Now I know we could probably make some of the apps work on something else, but as soon as we hit an issue the vendor will just shrug their shoulders.
"Someone already has - Rocky Linux"
...and I wish them well because they will become what CentOS used to be before the creeping RedHat takeover took place. I would certainly be wiling to donate to this particular worthwhile cause and more can be found here: https://hackaday.com/2020/12/09/centos-is-dead-long-live-centos/#more-451425
Already planning my next swap for Centos, then. I have a minor headache that drivers for a LTO tape drive that were last released officially for RHEL7. Looking at the Quantum website right now, they only have the Windows drivers listed. Though that is only looking very quickly in passing.
I'd not need RHEL/Centos at all (or Windows) if one could easily get LTFS and LTO working without that specific driver RPM. Attempting to repack it as a DEB wasn't successful, though maybe another linux nerd would have better luck than I. Always surprises me that support is so relatively weak for them given they are 99% of the time found in enterprise situations!
Yeah, that's great, if you're running CentOS 6 or 7. I just spent too much time converting from Fedora to CentOS8 just for the long EOL and not having to upgrade every 2 years. Now that's shot all to hell. The Oracle doc for converting CentOS 8 to OL8 is behind the support paywall.
So hell, now I'm just kinda screwed :(
Hopefully Oracle will release a CentOS 8 conversion script soon...FML
It looks like Greg Kurtzer has revitalized the Rocky Linux project. He is one of the original Co-Founders of CentOS and is apparently kind of miffed at RH over this. Rocky Linux has no current release, or release date but is gathering a community to build it out.
Anyone interested in helping out should check the Rocky Linux site at https://rockylinux.org/
Information taken from the ArsTechnica article, https://arstechnica.com/gadgets/2020/12/centos-shifts-from-red-hat-unbranded-to-red-hat-beta/, any inconsistencies are my fault.
"Just what the world needs, another Forked Linux Distro"
Oh, so you are happy to be locked in to a walled garden with no escape route? You would feel more at home with the offerings from Apple I think.
Look, forking a project is the option of last resort. No one takes on forking a project without good reason. Setting up the back-end, repos, recruiting maintainers etc. are not something to be undertaken lightly. Luckily for people using Linux there is an alternative and people dedicated enough to give us the choice. Your example of the OpenOffice LibreOffice is a prime example, LibreOffice has thrived and is present in most distros. It's updated regularly and has a good community. OpenOffice on the other hand...
If you can't beat 'em, don't join 'em, start one of your own.
As long ago as S.u.S.E. they has one development tree, "factory" from which they pulled the Enterprise version and the snapshots now known as Leap and the rolling release "Tumbleweed" Red Hat always seemed a bit tricksy about giving stuff away and SUSE never seem to get the credit for it.
Suse is doing just the opposite. They already had a centos steam (opensuse tumbleweed). Opensuse leap was similar to centos classic (they share source but leap has extra packages). However, updates came from both directions. Now they took a further step with opensuse jump, sharing even binary packages. They are trying to sum maintenance effort while rhel is increasing the same costs trying to drive users to its paying service.
... the happier I am that I chose Slackware on the desktops and BSD on the servers over 25 years ago.
Don't all y'all wish you had done the same? Think of all the time you would have saved!
On the bright side, you still can. Try it, you might like it.
BSD ZFS servers all the way for me. Never really used Slackware, should give it a try. I was an earlyish Ubuntu user after leaving Solaris in academia, and I gave Mint a go when Ubuntu tried their dodgy integration of local and web search. Still looking for the perfect client distro ...
This post has been deleted by its author
This is probably the worst decision I have ever seen from RH (And I have used a RH distro for 22 years):
* We use RHEL exclusively at our company and have a large contract with RH for this. We recommend our users use Centos at home for personal learning of RHEL.
* We make heavy use of third party repos which will likely suffer/disappear now. Centos also provided a fast environment to test things we planned to deploy on RHEL with extra licensing (e.g Clustering). We need these repos to make RHEL a user friendly desktop OS.
* I use Centos for home server use, I likely will in the future switch this to something Debian based. It seems to to make no (business) sense to encourage people to learn other Linux distros, thereby moving them out of the RHEL family. Therefore other distros will be considered in the future for commercial use.
* As a RHEL users we benefited from a large Centos community providing extensive bug analysis, blogs and how-to information, applicable to RHEL.
* So many people run Centos it provides an greater incentive for third party developers to release on RHEL/Centos. What now, less incentive to release on RHEL. This diminishes RHEL as a supported platform by these ISVs so will will diminish it for us. Will Google release Chrome for RHEL without this Centos large community base. Will MS Teams (our corporate solution, rights and wrongs aside) we have relied on this being on RHEL, will MS bother!
Centos Streams is NO replacement. As it's no longer identical we can't use repos generated from it, can't guarantee binary compatibility or provide a recommended learning platform.
I fear I see some MBA thinking this will increase revenue, or the Dead Hand of IBM.
Ubuntu must be delighted.
Maybe can keep a running replica of the Centos streams repo, and snapshot it every time RHEL goes up a point release? Then run your centos update form the snapshot repo, and you effectively get the RHEL point.
Will kill things like EPEL though, and there will be dependency chaos.
Worth remembering that IBM has a huge research organization which generates lots of basic patents.
That resource has allowed IBM to repeatedly blow one-chance-in-a-lifetime opportunities without going under: networking, the personal computer, Internet, etc.
So they've had plenty of practice screwing up. They're good at it.
Well, that's good timing.
I was just about to start testing CentOS 8 for a server upgrade I'd been planning. I've been using RH since... a really long time ago, back when there was just Red Hat Linux. I've still got RH 4 CDs somewhere, I think.
Just downloaded Ubuntu server to start testing.
NOT in the mood for this today.
I think I see "the invisible hand of the market" (er, "IBM suits").
On a more serious note, My employer uses RHEL for all customer-facing production platforms and CentOS for everything else (this includes everything from development, customer acceptance, employee hands-on training, etc). In fact, my employer was using CentOS as an on-ramp for driving projects onto RHEL platforms. It appears that IBM has thrown a monkey-wrench into those plans.
I have no idea what the future holds but history can be instructive. Recall that when Michael Widenius and others didn't like where SUN was taking MySQL, they created MariaDB (that decision seems fortuitous after Oracle acquired SUN; then promised the EU not to kill MySQL; then slowed MySQL bug fixes for more than a year until they noticed that "a lot" of people in the Linux community were preferentially installing MariaDB).
If CentOS just received a death sentence from IBM then perhaps Rocky Linux is the MariaDB equivalent.
In the future, whenever I see one of the perennial arguments about the average user ditching Windows instead of some flavour of Linux, I'll just point them towards this thread.
I mean, really? Just within this conversation, we have references to the following terminology:
CentOS
CentOS 6
CentOS 7
CentOS 8
RHEL 8
RHEL 8.3
RHEL 8.4
Scientific Linux
Scientific Linux 8
Fedora
Fedora Rawhide
SCO
Asterisk
Redhot
Redhot 10
Canonical
White Box Linux
Debian
Devuan
FreeBSD
Ubuntu
Slackware
Wayland
System V
Gentoo
GNU/Linux
snapd
Canonical
Mate
Synaptic
Suse
OpenSuse
Tumbleweed
This is apart from assorted variations that I know and care nothing about from being a techie: Mint; Cinammon; Puppy; Elementary; Arch etc. etc.
Unless you have a relative with a predictably long lifespan who you can trust implicitly to maintain your computer before he pops his clogs, don't do it. Go with Windows. Even Windows 10 *spits in the gutter* which I hate as it's a pile of shite, but at least it's a known pile of shite which other people are familiar with.
Posted from the real world, where people just want to send emails, write documents and get on the Internet.
io_uring is getting more capable, and PREEMPT_RT is going mainstream The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
