Having a more "front runner" distro for RHEL (RedHat Enterprise) is great for RedHat. Since bugs will probably be caught in CentOS and don't end up in RHEL. This front runner role was actually intended for Fedora however Fedora contains way too much experimental changes for anyone to seriously try to run it on servers.
I don't want to sound too "tin-foil headed" but I guess now that RedHat has hired the main CentOS dev(s?) this change comes from RedHat. I can't imagine the CentOS user base wants this direction for the CentOS project (or maybe thats just my lack of imagination...). People who use CentOS want a boring Linux distro like RHEL. They just don't want to pay for RHEL subscriptions.
SL never released version 8 (they switched to CentOS8). Amazon (correct me if I'm wrong) does not release installer ISOs. AFAIK, closest to a plain free RHEL8 clone is Oracle Linux.
Not really. You can use Alibaba Cloud Linux 2 like that if you want but why would you do that? Oracle Linux, CloudLinux, Debian or openSUSE Leap are better choices.
CentOS is how RedHat releases their sources in compliance with open source licenses (Presumably they're going back to releasing them as a consequence for this).
My familiarity with Amazon Linux is about 4 years out-of-date these days, but it was a RHEL/CentOS clone with a number of the core libraries like glibc being updated and maintained by Amazon on an independent life cycle.
Is CentOS the upstream for Oracle Linux? Instead of which comes CentOS Stream and then the question is what will Oracle do? Would they even try to keep the old CentOS concept alive?
I'm pretty sure that OEL is derived directly from RHEL, particularly because OEL 8 shipped while CentOS was still figuring out how to deal with streams.
> Having a more "front runner" distro for RHEL (RedHat Enterprise) is great for RedHat. Since bugs will probably be caught in CentOS and don't end up in RHEL.
I thought that Fedora was already serving this role
Not really. RHEL / CentOS is basically a hardened snapshot of Fedora taken every few years, with a few bespoke changes on top. So in that sense you could argue that Fedora is a front-runner for "the next RHEL" but at any point in time it is too far ahead of the current RHEL to be a useful testbed in any respect for those users. Although I guess you could argue that it helps knock down bugs in packages like GNOME that do get updated regularly in RHEL.
CentOS Stream is basically "the next x.y release of RHEL". Some updates, like GNOME updates and new hardware enablement, will be present in CentOS Stream a few months before they are released to RHEL and CentOS as part of a new x.y-release.
Yes, this is exactly it. The conspiracy theories about buying-CentOS-to-kill it are understandable but totally off-base. Red Hat brought CentOS in-house at a time when the company was trying to grow from being a single-product company to a portfolio one, and it became clear that Fedora wasn't working for what at the time RH called "layered products". The hope was that CentOS would provide a more-RHEL-like community place for work like RDO to happen. That was partially successful, but the plan wasn't really realized — and speaking from a Fedora point of view, that "Fedora is failing at a thing we need so we'll turn to CentOS" wasn't a healthy dynamic for either project. CentOS Stream serves the initial purpose better, and now RH's distro ecosystem story is actually linear rather than a crazy MC Escher contortion.
That is only true if CentOS continues to be widely adopted, with this move by RedHat i do not see that continuing, I am sure many org's right now are looking for options to move off CentOS / RHEL stacks.
> People who use CentOS want a boring Linux distro like RHEL. They just don't want to pay for RHEL subscriptions.
I use CentOS a lot for prototyping projects destined to be put on RHEL servers. I like it as a try-before-you-buy version of RHEL, and this change makes that use case a lot less useful.
A group of us was sent to Red Hat for a kernel class (week long, excellent) over 10 years ago. We were moving off HP-UX which offered really excellent real time extensions (disabling interups on a per cpu basis...processor sets, and other fun)
The instructor told us if we wanted to try some of the things we were doing in class to experiment more, we could try it on CentOS. it was the practically the same. This was before Red Hat “ acquired” them.
I wouldn't be surprised if this means that another project will crop up soon-ish which does what CentOS did before, rebuild RHEL so there is a stable, boring distribution for people who want RHEL without wanting or being able to pay RH.
Even some who don't mind commercial will. Oracle has a well-earned reputation of being difficult in licensing negotiations (there was even a Gartner piece on it at some point)... And what they did with the JDK just underscored that.
Wasn't CentOS "adopted" by RedHat because no one else really wanted to do the work?
A revived Scientific Linux could easy suffer the same fate. No one truly want to maintain a RedHat clone for little to no pay, while at the same time dealing request and complaints from companies who wants the benefits of RHEL, but no pay for the development and maintenance works done by RedHat.
Realistically it's some bean counter at IBM who asked why RedHat is giving away the very same thing they're trying to sell. Said bean counter do have a point in my opinion.
So CentOS is no longer relevant for production use. I wonder who stands to benefit. I really don't see it driving more sales to RHEL like the execs probably predict.
> If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options.
...sounds like what they expect
> it removes confusion around what “CentOS” means in the Linux distribution ecosystem
This justification for the change seems like a solution to a problem that doesn't yet exist but probably will soon!
To me it was literally the most straightforward Linux distro: RHEL without the license & trademarked material
I've been leaning on Debian-based distros for my own servers for a while now, but I still use CentOS in the lab. Hopefully RedHat provides an easy way to legally develop on RHEL without messing with a license.
_In the first half of 2021, we will be introducing low- or no-cost programs for a variety of use cases, including options for open source projects and communities, partner ecosystems and an expansion of the use cases of the Red Hat Enterprise Linux Developer subscription to better serve the needs of systems administrators and partner developers._
How about discounts for universities? They could take a page from Microsoft, which introduces students and teachers to its ecosystem with low-cost versions of Windows and Office.
And these licenses and subscriptions come and go at the whim of the corporations that own them. Nobody informed would base their open source project/community/ecosystem on something like this, unless they want to be left out in the cold when the plug gets pulled in the future.
However, if you're in the SMB space and run CentOS as production because money is tight but you wanted a stable LTS distro and have never needed any technical support, this move has just yanked the rug out from under you and there appear to be no provisions in the pipeline to change that.
Your only option is to migrate away from RHEL/CentOS, period. It's likely that Red Hat doesn't care much about us smaller orgs with only 100-200 servers/VMs though. Sad day.
Thanks for the link! Seems like an oversight that it was left out of the CentOS Stream announcement.
Summarizing the FAQ:
- the bits are the same, the differences are the terms of use and the self-support level
- one subscription per user
- allowed to use on 1 physical system (up to 2 processor sockets, 16 VMs)
RedHat will probably get a one time boost in RHEL sales at the expense that the void created by the CentOS project will be filled by some CentOS-fork they have no control over.
Maybe they have some grand scheme I'm not seeing but it feels short sighted.
This sort of cloning effort tend to live in contractual grey areas. Would that community (of people who got together to avoid paying for licenses) be ready to pay to defend developers from expensive lawsuits filed by one of the wealthiest corporates on the planet? Or rather, would developers in charge of such projects believe that? An acqui-hire with fuck-you money on one side, vs years of pain and likely bankruptcy - it’s not really a choice, is it?
...the contractual grey area of assembling a software distribution of open-source software in keeping with the license of that software? What exactly are they going to have a lawsuit over?
There is always something, like Samba and whatnot - some build system you claim copyright to, or some utility with a different license etc etc. It doesn’t need to be a slam dunk, it doesn’t need to win at all, it just has to be enough to keep a lawsuit running for a year or so. The legal system can be used as a DDOS in many, many situations, even when the defendant is spotless.
I am not sure how CentOS Stream makes any sense. CentOS stands for Community Enterprise Operating System, how on earth can CentOS Stream be called an Enterprise operating System?
> CentOS Linux 8, as a rebuild of RHEL 8, will end at the end of 2021
Does this mean that CentOS 8 is EOL come 2021? Weren't maintenance updates meant to go to 2029? What about everybody who built their product on the assumption that there would be a stable CentOS until then?
Oracle already has a clone that performs an in-place conversion of an installed CentOS 7 system.
There is a page describing the conversion: https://linux.oracle.com/switch/centos/
They have a shell script to convert a CentOS install to Oracle Linux, so you can buy support if you want.
The converter only works with versions 5, 6, and 7.
It does not work with CentOS 8. It would be nice if that could get updated.
My god. If it gets to the point that your best option is to migrate to Oracle, I think you need to really question reality itself.
(My opinions are my own, and do not necessarily reflect those of my employer; I'm in support at the moment, so foresee myself having to deal with the aftermath of this CentOS decision a year from now)
> CentOS Linux 8, as a rebuild of RHEL 8, will end at the end of 2021
Does this mean that CentOS 8 is EOL come 2021? Weren't maintenance updates meant to go to 2029? What about everybody who built their product on the assumption that there would be a stable CentOS until then?
Wow.. I literally just migrated my main production mail server to centos8 hoping to let it run for another 10 years...
I guess it is time to study alternatives..
Haha, fair. To be honest, I'm surprised it took this long for it to happen after CentOS joined Red Hat. I wonder if the IBM acquisition had any influence on this.
Funny, but isn't this totally reasonable grounds for an adverse possession claim against RHEL?
If a business claims they're going to keep doing something, and you build your business on that claim, and then they change their mind, you can have grounds to sue. Or, at least, that's what I vaguely remember from reading about AP law.
I think the problem is that it’s not like red hat has a contractual obligation with other businesses since Centos is essentially “free” and likely there isnt an agreement.
Not really. If you depend on CentOS it is reasonable you would contribute to it. There has to be a nonzero number of CentOS users that contributed to the project ("paid") that are now left holding the bag.
There is no real equivalent to CentOS Stream in Debian's release model.
Perhaps the closest is "the DAK upload queue for Debian stable", but that tends to contain mostly security updates, and according to other posts in this thread that is the one case where CentOS Stream is not an upstream of RHEL.
CentOS Stream contains feature backports, which generally don't happen in Debian stable, but it's only very specific backports, not every package gets updated like in Debian testing.
I'd put it like:
Fedora rawhide <=> Debian unstable
Fedora <=> Debian testing
CentOS Stream <=> DAK upload queue for Debian stable
Debian Stable might be more analogous to CentOS, but they don't do major feature backports like RHEL does, so I find stable is often much too old by the time it's actually released.
On the other hand, CentOS systems tend to last much longer due to the 10-year support cycle. So I often encounter wild specimens that are even older than Debian oldstable.
Right now, I've got a bunch of CentOS 6 servers with 2.6.32 kernels that are freshly out of support this month. I was hoping to replace them with 8, but now I'll probably have to settle for 7. At least I can take consolation in the fact that I haven't been called in to troubleshoot any CentOS 5 servers lately.
> CentOS Stream is focused on the next RHEL minor release. This means we are improving and influencing the shipping releases of RHEL. Fedora ELN is a testing area for changes that may occur in the next major release of RHEL.The CentOS Project cannot and does not speak for Fedora
Fedora doesn't like to be put in that particular niche anyway. Yes, Fedora is fast moving and it is what Red Hat uses as the base for major releases, but we're more than "Redhat-unstable" in so many ways.
CentOS Stream will be the upstream for RHEL minor branch development. This is actually a huge thing that I think people are missing: previously, once branched from Fedora, RHEL development did not happen in the public eye. With Stream, it will. This is huge and awesome good news. However, that development will still be entirely Red Hat curated. This is different from Fedora, where we make community decisions with Red Hat's engineering input as a stakeholder but not the decider. (See for example btrfs as the default filesystem.)
It might be "huge and awesome good news" if they keep both CentOS 8.x and CentOS Stream. But they're forcing Stream as a replacement, hence all the pushback. Let's be honest, most people just want to run a gratis released RHEL, not run their betas.
My guess is that Stream turned out way less popular than their sponsored hoped (who cares if it's developed in the public eye if it's entirely RH curated anyway). So CentOS 8.x had to die.
Come on, be serious. You think people who standardized their infrastructure on CentOS 8 under the assumption that they will have 10 years of stable support, are negative about this because they are afraid of change?
And you know that's not the reason for the negativity, so I don't know why you're being so flippant about this. Nobody has a problem with the idea of 'CentOS 8 Stream'. They have a problem with this being the replacement to CentOS 8 Linux because it doesn't fulfill the same use-cases.
In complete seriousness, I think there are three broad categories:
* Use cases which actually despite the fears will be covered just fine by Stream
* Use cases which will be covered by the upcoming expanded no-cost/low-cost RHEL programs
* Use cases which, yeah, aren't covered
It's my estimation that the first two are actually the vast majority. I don't mean to be flippant (it was a long day). understand that people who are mostly in the third case are angry and disappointed, but from what I've seen in talking to people both when Stream was launched and after this announcement, at least some large number who are worried that that's their situation are going to be actually getting something better when the dust settles.
To be honest, I think this is bs. The CentOS community is huge and RH benefits a lot from the discoveries made by the community.
However, doing this will effectively make CentOS as a server OS useless for the most of us. "But Facebook uses it" - well, yes, with thousands of engineers Facebook could run their own distro and still have success if they wanted. Most useless argument ever.
Time to move on and find something else. Maybe good old Debian.
Since Facebook actually uses kernels from Fedora Rawhide (necessary for btrfs support I guess), their systems are nowhere near the CentOS you and I would use.
It must be a classic selling point... a French company (pretty big) told me the same thing to lure me (even if my hypothetical job was not directly related to that fact)
Correct me if I'm wrong, but the way I read this, CentOS Stream will still serve as a stable clone of RHEL just as it always has. The rolling distro will be tagged at a certain point in time for a RHEL release, and you can still choose to use that state as your production base, and be locked at that tag. Presumably there will be a CentOS Stream 9 tag that you can use for production. The difference will be that CentOS will lead rather than follow the RHEL release.
Continuously delivered distro that tracks just ahead of Red Hat Enterprise Linux (RHEL) development, positioned as a midstream between Fedora Linux and RHEL. For anyone interested in participating and collaborating in the RHEL ecosystem, CentOS Stream is your reliable platform for innovation.
That doesn't seem to be what you think it is, at least in my eyes. I'm definitely not looking to run something positioned between Fedora and RHEL. There's already enough updates every month (including multiple kernel updates a month sometimes) that it's hard to keep the fleet updated. I definitely don't need stuff ahead of RHEL where I can assume I'm a bit of a guinea pig to test out the coming RHEL update.
"Q6: Will there be separate/parallel/simultaneous streams for 8, 9, 10, etc?
"A: Each major release will have a branch, similar to how CentOS Linux is currently structured; however, CentOS Stream is designed to focus on RHEL development, so only the latest Stream will have the marketing focus of the CentOS Project.
"Because RHEL development cycles overlap, there will be times when there are multiple code branches in development at the same time.This allows users time to plan migrations and development work without being surprised by sudden changes.
"Specifically, since the RHEL release cadence is every 3 years, and the full support window is 5 years, this gives an overlap of approximately 2 years between one stream and the next."
Also from Q2:
"We will not be producing a CentOS Linux 9, as a rebuild of RHEL 9. Instead CentOS Stream 9 fulfills this role. (See Q6 below regarding the overlap between concurrent streams.)"
So it sounds to me like my assumption is correct: There will be separate streams reflecting each RHEL release.
Read the whole FAQ. This is not what people think it is.
I'm not sure if you don't understand how RHEL/CentOS point releases and bugfixes work, or if you're reading something in the FAQ I'm not.
Right now, in RHEL 8.2, if a package needs a bug fix, it will be back-ported so that you get the fix in the existing running version of that package that was shipped in 8.2. On point releases, RHEL (and thus CentOS) may choose to back-port a feature, functionality, or choose to update the version of the package that is running to a newer version that has those features or functionality (or to bring it in-line with back-patches, I assume). When you update to a new point release, this gives you a single large update set that you can test to make sure functions well in your infrastructure. There have been points in the past where changes in point releases have required us to make changes to our configs or setup to deal with the RHEL/CentOS's point release changes (even though it's supposed to be rare, it happens, but it's mostly contained to these big testable update sets).
CentOS mirrored this exactly, because it mirrored RHEL.
Now CentOS is going to do something different, and these updates that would be relegated to point releases look like they are going to come down continuously. While not as problematic as something like Fedora, this is still something that groups specifically chose CentOS to avoid.
It's nice that Red Hat is offering something to allow people to get fixes and features sooner than at point release times, but to switch CentOS to only providing that is extremely problematic to the very large community that expects otherwise, supported CentOS, and has done both since prior to Red Hat hiring some of the main CentOS developers and effectively controlling the project, and is notably different than what CentOS has always traditionally attempted to provide.
Rolling forward to the head is required to get the most recent security updates. Which isn't that far away from how centos works today. With rhel you get security updates for the point releases (8.1,8.2,etc) for a while after the new point release comes out. With centos, the day that the newer version drops, they don't tend to roll security updates into the older ones.
Q4: How will CVEs be handled in CentOS Stream?
A: Security issues will be updated in CentOS Stream after they are solved in the current RHEL release. Obviously, embargoed security releases can not be publicly released until after the embargo is lifted. While there will not be any SLA for timing, Red Hat Engineers will be building and testing other packages against these releases. If they do not roll in the updates, the other software they build could be impacted and therefore need to be redone. There is therefore a vested interest for them to get these updates in so as not to impact their other builds and there should be no issues getting security updates.
Absolutly not, it's going to be the Fedora version of RHEL. Pretty clear:
"If you are using CentOS Linux 8 in a production environment, and are
concerned that CentOS Stream will not meet your needs, we encourage you
to contact Red Hat about options."
Of course no one want to run CentOS Stream because it's going to be broken / unstable, completely the opposite of what CentOS is.
Fedora is (up to) years ahead of RHEL, and periodically forked. CentOS stream is up to a few months ahead of RHEL, and developed from the same Fedora fork that RHEL is.
Having been a Debian/Ubuntu person for a long time, and being somewhat dissatisfied with that ecosystem, I recently started evaluating CentOS for my use cases instead. I want something with a non-rolling update model, so I don't have to deal with my environment changing out from under me.
CentOS 8 had been mostly working well for me, barring a few missing packages that were easy to port over myself, and I was really thinking of moving all my boxes to CentOS. I'm glad this news came out before I did; I don't know what I'll use instead, but it definitely won't be CentOS/RHEL.
I am a big fan of OpenBSD, but unfortunately I still need some Linux only software. I do try out freeBSD’s Linux emulation layer every couple years, but it isn’t quite there yet for the stuff I need to run.
Checkout openSUSE; I've been running it for the past year or so for my personal projects (and their rolling-release version for longer) and I've been pretty happy with it. It's not quite the same position as CentOS but still very stable and nice to work with.
I think there might be some confusion about "rolling" in the context of CentOS Stream. The updates are continuous and there's not released minor versions, but all changes are changes that are intended to _very shortly_ land in the next every-six-months minor release of RHEL. So you aren't going to suddenly see more "environment changing out from under me" than you would on RHEL or CentOS Linux.
I haven't tried CentOS Stream, but out of curiosity: if it's similar to the RHEL patch releases, how will major (like from RHEL 8 to 9) changes be handled?
OpenSuse, and Suse give you more control over minor release version changes. You have to manually change your repos with some scripts before you patch. The RH way of just rolling you from minor release to minor release invisibly has always kind of irritated me.
Yeah, to me this whole thing sounds like a failure of communication.
Most people (including me) never looked closely at "CentOS Streams"; from what you said, it seems like it's "a preview of the next RHEL 8.x". The announcement today made it appear as if it were "a preview of RHEL 9.0", which is a much bigger change for those who (like me) expect to install a CentOS 8 box somewhere and keep it mostly untouched (just applying the updates) for ten years.
Minor version updates in CentOS usually mean a new kernel ABI and things like ZFS break. I always have to wait to do minor version updates until a new ZFS version lands. Any idea how that’ll work?
When RH bought CentOS, it was clear they would kill it eventually, the question was when. Well, it looks like it's happening just now. Time for a CentOS replacement.
TL;DR: CentOS Linux 8.x will end in 2021, CentOS Stream 8 will be RHEL 8.x plus whatever updates are in the pipeline for it. CentOS 7.x will remain as today until RHEL 7.x reaches EOL.
I'm very pessimistic on what this means for the RHEL ecosystem as a whole...
If I understand correctly, CentOS Stream 8 should be relatively stable just after a RHEL 8.x release, because the pipeline will contain just minor updates. But as the next "x+1" release approaches, the pipeline will contain whatever is being tested for inclusion in it. This makes CentOS Stream unsuitable for the vast majority of people that currently use CentOS in production (i.e. the people that choose CentOS over something else like Debian Stable or Ubuntu LTS).
One can argue that these people can go buy RHEL licenses, but they most likely don't do that already because they see support as the value added by RHEL-proper and they can support themselves just fine. Many will also have RHEL instances along CentOS on systems that need vendor support, but pushing them to license everything may also push them into another direction altogether. Suddenly, standardizing on Ubuntu LTS (with paid support for a subset of instances) starts to make sense.
I think Red Hat (or maybe IBM) is vastly underestimating the value of CentOS in keeping the whole RHEL ecosystem competitive. They may be setting themselves up to be another SUSE.
Yea. I think this is an extremely short-sighted move. Many RHEL customers utilize CentOS. I know CentOS is a community but it is led by Red Hat developers. Suddenly pulling 8 years of support from their community project is not going to be looked at favorably by any IT team.
I share your pessimism about RHEL. I think Canonical could be a big beneficiary, if they can stop shooting themselves in the foot with stuff like upsells for live kernel patches, and snaps for non-desktop apps.
I m torn about this move. My gut reaction was that this was a bean-counter move. Thinking more about it the key issues I see with this move are:
- CENTOS fills a need, that many users have and superficially it looks like Red Hat (IBM) is now abandoning addressing it. On the other hand Red Hat does offer RHEL for free (gratis) [0] and that should fill the needs of CENTOS users (right?). However it would have been much better if that option was mentioned in the announcement.
- I thought Fedora was upstream of RHEL. However after thinking more about it I realised that RHEL has a significant delta over Fedora. I 'm guessing CENTOS stream will be partway between Fedora and RHEL. It makes sense from Red Hats open development approach to have the delta between Fedora and RHEL happen in the open. Done right that should strengthen RHEL.
- Why the rush to drop support for CENTOS 8? I m sure some people are using it in production and they are unlikely to to want to move to this new CENTOS stream. It's a new OS distribution with a philosophy different to the one that was right for them!
Overall I 'd prefer if the new thing was called RHEL stream and provided for free (gratis) as CENTOS stream is. Also making more explicit the RHEL availability for free instead of having competing brands would be good. Now that there are competing vendors (Amazon Linux, Oracle Linux) trying to entice users it'd be better to strengthen RHEL brand rather than dilute it with multiple offerings. Unless RedHat/IBM plans to pull the plug on option [0].
I work for Oracle on their cloud platform (including reasonably closely with the Oracle Linux team, as my team is responsible for the main platform images).
Speaking entirely for myself, opinions my own, may not reflect my employer etc. etc:
I came in to this job expecting OL to just be a CentOS clone, and not really expecting much from the kernel they ship with it.
It is both a CentOS clone, and a bunch more. Oracle takes the CentOS packages and applies bug fixes etc. that upstream RedHat has failed or refused to apply, so I've actually found OL to suffer from fewer problems than CentOS, and we've even had to apply mitigations for CentOS 6 for stuff we haven't had to do to any other OS we distribute. For entirely selfish reasons, I was really glad to see CentOS 6 go end of life last month.
On top of that the OL team hires a significant number of upstream kernel developers, including the core maintainers for a number of components, like XFS, Xen, and so on, and produces the Unbreakable Enterprise Kernel (a really curious choice of marketing terminology), that incorporates mainstream bug and security patches, while being closer to mainstream than RHEL/CentOS, and the kernel patches submitted upstream by OL devs.
Should be. It's CentOS packages with rebranding and maybe some custom fixes on top. There are two kernels that ship with it, either the RedHat Compatibility Kernel (RHCK), or the Unbreakable Enterprise Kernel (UEK).
I would point out, I'm not in the OL org, I have absolutely no idea what this change means for Oracle Linux. Oracle Linux is based off the CentOS sources as that's the only way that RedHat was making the source code to their distribution available (there way of meeting the terms of the GPL). RedHat has to make their source code available in one form or another so I can't imagine that this would have any impact on OL, but that's entirely guess work.
I didn't know Oracle builds from CentOS rather than RHEL sources. Nor that RHEL doesn't release sources anymore?
If that's true, I wonder how Oracle got some of their 8.x releases out much earlier than CentOS. (Oracle Linux 8.3 2020-11-13 vs CentOS 8.3 2020-12-08, Oracle Linux 8.0 2019-07-19 vs CentOS 8.0 2019-09-24.) I'm assuming here without verification that both track the RHEL 8 point releases.
if i remember correctly, RHEL source dumps always lacked some machinery to actually produce a working release; that’s where CentOS were doing actual work, painstakingly replicating all the compilation quirks to end up with RPM builds that matched RHEL. That’s likely why another clone might want to start from CentOS rather than RHEL sources.
I can't speak to that. I'm not in the OL team and don't know what they do / did. Oracle can/does throw a lot more engineers at development and build than CentOS does (I believe they only have a few engineers). I believe the stuff for building the RPMs lands in the CentOS git repo early on.
The free developer license seems pretty useless for larger organizations and OS licenses aren't managed by developers in general anyway.
>Yes, but only one no-cost Red Hat Developer Subscription can be added to a user account. While it is possible to have each developer register for their own account, this is not ideal from a management or efficiency standpoint. For example, if a company wanted no-cost Red Hat Developer Subscriptions to cover 100 developers, each developer would need to individually register and independently create 100 accounts that need to be tracked and maintained. For enterprises that use Red Hat Satellite to manage multiple systems, all 100 accounts would need to be added individually. Accepting the terms and conditions and renewing the subscription annually would need to be done individually and manually for all 100 accounts. Staff turnover in the development team would create additional management challenges with individual accounts. Therefore in terms of lost productivity, managing individual no-cost subscriptions will not be cost-effective for many groups.
Many development organizations benefit from having Red Hat Developer Support. Cost effective bundles are available that include support with a pack of 25 Developer Suite subscriptions that can be managed from a single account. Each of these subscriptions is based on systems, rather that users.
Yea sure, that's the way to handle this kind of announcement. 'We're killing CentOS 8 and you need to wait several months to see the 'supposed' good things this move brings.'
Yea right.... All this '1H/1Q 2021' does is let IBM/RedHat determine how bad the fallout is before trying to cover their backsides.
Seems like that is accurate. I am struck by how cleaner and simpler Debian's naming scheme is. If you don't follow the Red Hat world closely, those names are going to be very confusing.
> I am struck by how cleaner and simpler Debian's naming scheme is
It's just a simple common-sense scheme, it's not the result of deep thought. What you're struck by is how marketing-oriented the RedHat repository naming scheme seems to be...
Oh, wow. My whole extended family has CentOS on their machines for years because of LTS. Not sure what I'm going to replace it with now and how. Perhaps there's going to be Fedora LTS at some point soon. I sure hope Fedora is not the next casualty.
Extended yes. And has been for years without a single issue. Immediate family all on Fedora. Very little maintenance, automated updates. Desktop software installed through flatpaks. Easy remote management. Users don't care about the OS as long as they know how to open the browser, email, word processor, Skype, Zoom, etc.
Fair enough, was just confirming. It didn't occur to me that flatpaks would probably assist in bridging the gap between a "Workstation" OS and a conventional end-user OS where yum repos and EPEL might be lacking.
> Easy remote management.
Just out of curiousity, are you SSHing in directly, or installing the Teamviewer RPM on all of them?
Each house has an single always-on VPN client (RPi) to the central server so I ssh in case something is up. Pretty much never happens, but it's good to know the option is there. Most issues are with a specific software and not the OS, so I need to have a visual to help resolve, e.g. "Where is my contact list in Viber?" or "Why do I see this page?".
Plus, I'm running Pi-Hole in docker and I ssh to upgrade it from time to time, (docker pull, docker-compose down/up, etc.). I haven't bothered automating this because some things change between releases and I still end up doing manual configuration changes.
I'm a little confused by this. Well, first, I'd encourage you to try Fedora Workstation for your family -- we've worked on making upgrades painless, so that they're basically an automated thing that happens while you go for coffee once or twice a year (at your option). But second, if a "Fedora LTS" would fit your needs, why not give CentOS Stream a look? It's not actually going to be that different from CentOS Linux, and almost certainly will have less constant change than a theoretical Fedora LTS would.
Also, I am not one of the highest upptity-ups in the company or anything, but from the inside: I see no evidence whatsoever that this is the result of IBM anything.
Thank you for the reply. While I personally never had a single issue with upgrading between Fedora releases, I also have the skills the resolve any potential ones if I would. I don't want to deal with somebody's computer suddenly being borked halfway across the world with no way to assist. So far CentOS fit that niche beautifully, with seldom major clean reinstalls (i.e. wipe root) when I'm there (7.x > 8.x). I'm going to evaluate CentOS Stream and perhaps you are right and it's a viable replacement.
I don't want to deal with somebody's computer suddenly being borked halfway across the world with no way to assist.
Fedora Silverblue could be interesting alternative to regular Fedora then, since you can boot into or roll back to a previous release. You can also pin a known-good OSTree commit, so that one could always boot that version.
This. Although I 'd suggest running Silverblue in a VM first to learn about package layering and flatpaks. (This was my migration path. Made sure all my use cases were working within the VM before I installed on bare metal.)
(Disclaimer: I am capable of fixing upgrade issues myself.) I've not done a wipe-root reinstall of Fedora since 2013. I've in place upgraded every two versions or so - basically as soon as the version I'm using goes EOL.
> we've worked on making upgrades painless, so that they're basically an automated thing that happens while you go for coffee once or twice a year (at your option)
In my experience (just went through that, F32 -> F33), it's painless but definitely not "an automated thing that happens while you go for coffee"; each machine took a whole day, it's a huge download (many gigabytes) and the install itself seems to be severely fsync-limited (several hours while the progress bar slowly fills and the disk light is lit all the time; after the fact, "journalctl -b -1" shows it was installing/cleaning package by package all that time).
Fedora Silverblue can be an option then - the roots is an immutable snapshots tracked by OSTree It can build an updated OSTree snapshot in the background & only the difference from what you have are downloaded. Then you reboot into that new snapshot, while still having the old one (and ony other you care to keep) available, in case something is not right with the new one.
That should address most of the issues you mention. :)
Silverblue, in my experience, is not really there. I like the idea. As of my latest try at it in August, I wouldn't recommend anybody recommend it unless they're going to be physically standing in front of the machine on a regular basis.
Yeah, it's true that the people I know that use it do so on workstations. Still IMHO the technology (OSTree) is solid & perfect match for various server & mobile use cases. Once mature enough of course. :)
It's essentially no different from how things currently are. RedHat releases updates, CentOS group picks those up and builds CentOS packages from them. They usually lag a day or two.
They really lagged on the PLATYPUS CPU vulnerability for CentOS 7, because they were dealing with a backlog from the 7.9 bump. Took them several days to get the patches out.
Which was expected since CentOS was a free (beer)rebuild of RHEL
CentOS Stream however is not a Free (beer) rebuild of RHEL anymore, it is an "upstream" for RHEL, so it would not be expected that this flow would work like described for an upstream product
Ahh okay, I can see how I didn't communicate myself clearly in initial message in the thread.
I was trying to point out this isn't different from a security perspective. Yes the rest of the distro is going to almost reach a rolling state which is definitely not something I want in production.
Canonical are also fairly actively involved in security fixes and among those brought in to the various security embargoes. They usually ship packages the same day embargoes drop.
It depends on where the vulnerability is. Everything is all ad-hoc, each piece of open source software decides how they want to handle it, attempting to juggle the chances of a leak. The fewer you tell, the more likely the secret is to be kept, and you want to keep these things secret until a patch is done.
The linux kernel maintainers have a private list where they co-ordinate some of this stuff, and every major Linux distribution will have engineers on it.
That's partly why you see things like OpenBSD etc. being left on the margins. Certain maintainers have been quite vocal about not adhering to embargoes, which really doesn't help them. It's an idealist vs pragmatist thing going on there.
Wow. I kind of new this day was coming. I work in engineering / science (not comp. sci or developing) and all our software vendors are Windows or RHEL support only. Although if you know your way around linux any flavor will do, but RHEL is the "standard" for support. It's kind of like "insurance." We expect this to compile / work for RHEL and NOTHING else, because RHEL is stable, predictable, and boring.
I've run most all the flavors of linux and am on the Ubuntu train. Actually, I flirted with the RHEL / Fedora / CentOS workflows as current as last year for a few months. I love the predictability and stability of RHEL on workstations and the thought of something new on a laptop or what not. While I respect the hell out of RH and their products, it just didn't work for me. Fedora is WAY too experimental, lacks supports, and is prone to your system breaking. I know, I know, it is pretty stable and has a lot of support behind it. But after updating via yum and having my WIFI stop working on my 6 year old Thinkpad, that is a deal breaker. I think there is way too much disconnect between their projects. RHEL is super stable, but the packages are severely outdated. Fedora is too experimental, and is pretty much a home operating system and a playground. I know CentOS is free, but depending on your business is paying $300 / year / machine for legitimate support and ticketing really an issue? That's for everyone to decide on their own. I think Ubuntu LTS is the best middle ground for stability and new packages. And if you need paid support and professional help, you can pay Canonical as well.
I could see this coming. CentOS didn't really show a value proposition for RH picking up the tab and supporting it. CentOS was recompiling RHEL and shipping it off; RH needs to keep their PR and image inline and HAD to help, since the whole point of CentOS was "this is RHEL without RH graphics and copyrighted material." IMO, RH felt like they were doing the same thing twice; producing RHEL, then removing RHEL branding and helping package up and compiling CentOS. Due to this, I think the biz folks scratched their on why they needed money, and now we have Centos Stream. I have no doubt another project will spin up taking up the slack of just recompiling RHEL.
Different tools for different jobs. Maybe Centos Stream will be awesome! Maybe it can fill the gap between Fedora and RHEL.
> I could see this coming. CentOS didn't really show a value proposition for RH picking up the tab and supporting it. CentOS was recompiling RHEL and shipping it off; RH needs to keep their PR and image inline and HAD to help, since the whole point of CentOS was "this is RHEL without RH graphics and copyrighted material."
Bear in mind that CentOS was originally an independent project until Red Hat acquired it.
You are correct! I think my point is that when your independent project grows so large that is has effect on the other, the main operator (RH) has to acknowledge it and do something about ti.
I have been using openSUSE. It's been pretty stable on the laptop. On laptop, I use the Tumbleweed (rolling release) and 15.1 or 15.2 on servers. Give it a try.
Packages are RPMS, managed with zypper. You may also use dnf but you will miss some of the advanced features provided by dnf (e. g. the concept of patches vs updates), there was a zypper vs dnf thread recently in the openSUSE mailing lists.
It does support flatpaks.
There is no free openSUSE LTS. The LTS is called SUSE Linux Enterprise Server, costs some money (unless you are a developer, in that case you get free subscriptions) and the LTS lasts for a minimum of 13 years.
On the other hand, dnf/yum downloads repos and packages in parallel while zypper still does everything one at a time, which means every kilobyte-sized package takes a second or two each to download, from setting up and tearing down a new TCP connection each time. It's especially annoying in Tumbleweed because rolling distro == lots of tiny packages updates all the time.
Zypper is awesome. The newest version of LEAP is identical to Suse Enterprise, you can convert with a simple script if you decide you want extended support.
The root filesystem uses btrfs, so it's easy to roll back update problems. There is also a newer version that uses a read-only root filesystem and updates are applied to a new snapshot that takes over when you reboot. It's pretty cool.
I'm also a big fan of opensuse lately especially their tumbleweed microos. it's such a breeze to use transactional-update (automatically) and reboot a fleet with some looking mechanism (even with k8s kured).
suse cured my containerlinux wound. (if suse gets bought by ibm than I will be furious or if they kill microos)
Indeed, typing in “docker” at the Ubuntu 20.04 command line tells you the above “apt-get install docker.io” command; one does not even need to waste time with a 30 second Google/DuckDuckGo search.
(Learning Ubuntu since CentOS went broke their pinky promise to supply security updates until 2029)
> If you are using CentOS Linux 8 in a production environment, and are
concerned that CentOS Stream will not meet your needs, we encourage you
to contact Red Hat about options.
I'm guessing the MBAs at IBM believe that they can covert a chunk of CentOS enterprise users into paying IBM customers. Ooof! CentOS had a good run.
There is a long legacy of EL integration and know-how in various particle physics experiments (and research computing clusters, for that matter...).
If RH doesn't release some "Academic Version" (but who would even trust that at this point?), then I suspect revival of Scientific Linux or adoption of shudders Oracle Linux is more likely than a switch to Debian. FreeBSD is probably a non-starter.
Fedora releases every six months. RHEL has a major release every three years, with minor releases every six months.
The major release of RHEL is usually forked from a Fedora version about a year before the major release, so with some exceptions software versions tend to be about a year behind those in a Fedora release initially, and then as RH backports patches rather than revving versions, drifts further.
It's the patches and smaller updates — and new hardware enablement in the full-support phase — that will be landing in CentOS Stream. Previously, this stuff was developed internally and only released to the world at the minor-release drop every six months. Now, it'll be developed in a shared space. So what you'll have in CentOS Stream is whatever is intended to ship in a RHEL minor update within six months.
There may occasionally be a situation where an update introduces bugs into Stream that would have been caught by QA before a public minor RHEL release and subsequent CentOS Linux rebuild. But I don't actually expect that to happen enough to worry about in any case where you can justify not paying for actual supported RHEL in the first place.
To me this news is at once shocking, and blindingly obvious in hindsight.
Shocking, because I'd never imagined they'd kill off CentOS 8 so early. CentOS 8.0 dates from Sept 2019, so it's killed in just the 3rd year of its presumed 10 year lifespan. I could read the tea leaves when they announced this Stream thingy recently, but I'd thought they would at least hold off till RHEL9 to pull the lever.
Blindingly obvious, of course, because Red Hat bought CentOS, presumably with real $$$, and IBM bought Red Hat for $34bln.
What's going to happen next? Microsoft buying Canonical and all businesses running either IBM Linux or Microsoft Linux? Crazier things have happened...
It's a money grab, pure and simple. They've (Redhat, let alone IBM) done it before (see below).
What happens in practice with this sort of "rolling release" is users end up patching endlessly in production, which no sane person or organization would ever want to do. This was the exact situation for another Redhat acquisition for years now. JBoss EAP and community editions (wildfly now I suppose), everyone who could moved off of JBoss long ago.
Except IBM thinks that this will convert everyone to RHEL licenses and I'm positive that is not what's going to happen.
Ubuntu is already the default for people with ML pipelines and more and more vendors are targeting Ubuntu first for their software.
CentOS will be effectively dead for a lot of companies starting next year (or 2024). (At least we aren't planning on licensing 10^5 systems on RHEL...). I imagine for those same companies, RHEL isn't far behind it.
What's even worse here is that at least for us there are some things that we pay for RHEL for. If we switch all of our other servers, those RHEL licenses won't be continuing either.
Your forgetting Suse, I'll bet they take a big chunk of the customer base. OpenSuse LEAP is now identical to SLES and it can be converted easily if you want support.
That's pretty weak sauce even compared to the five years Debian and Ubuntu offer. And Debian actually supports all their packages, unlike Ubuntu which tricks people into installing unpatched garbage from 'universe'
Yes clearly: we use CentOS at work because it's free (as in beer). If I go to my boss to ask money for a RedHat license he would laugh me out of his office.
This. We run CentOS for non-critical stuff and RHEL for stuff that really needs support. If we need to switch off CentOS we certainly won't be using RHEL either. Doesn't make sense to be running a Debian flavour mixed with RHEL since the two a significantly different.
Just wait when Mark Shuttleworth decides not to sponsor the project any longer.
Ubuntu followed Red-Hat's footsteps away from desktop into the server room, as there is no money to be done there, and it will follow it still, if there is still not enough money on the server.
That's almost true for any project getting acquired. The big EvilCorp will always have it's overbearing corporatey corporateness crush the things that made the project so cool it attracted their attention to it. There are very few projects that actually improved from being acquired.
Serious question: are they? I know they've made a lot of acquisitions over the years, but I don't recall any widely-circulated stories of "Salesforce takes beloved thing and destroys it". The major open-source-friendly company I know of that Salesforce bought was Heroku, and a lot of people seem to use Heroku without even knowing that they are owned by Salesforce (and have been since 2010). It seems like it's too early to say anything definitive about what their purchase of Slack is going to change, although Slack has been making itself quite enterprise-focused all on its own.
I would agree that BSD systems are nicer to look at, and FreeBSD supporting major releases for five years, with forcing people to install point releases once a year is really quite nice.
But I don't see BSD becoming practical as a platform to run (commercial enterprise) Linux software, when it's already a pain to get packages and support for anything that's not RHEL/CentOS.
It's not ideal, but you can run Linux software on FreeBSD. Commercial enterprise tends to be conservative and not need bleeding edge Linux interfaces that may not be available through the linux emulation layer yet.
> Red Hat bought CentOS, presumably with real $$$,
if I remember right technically centos didn't really exist as an entity that could be bought, Red Hat just hired all the developers (there were only ever 3-4 people working on centos). I would guess they are now working on Centos Streams, or have moved on to other things entirely. Its not like Centos has been killed off either, so it didn't cost a lot and this wont really save anything, it's "just" a change of focus.
Microsoft buying ubuntu would be an interesting (and not impossible) move though.
> If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options.
Not exactly unexpected, but disappointing: if you want to continue using something like CentOS, pay for RHEL. Lots of web hosting providers will be quite concerned.
Why exactly is that disappointing? Isn't it more disappointing that some companies expect to be able to run the same OS for 13 years and get security patches backported for free?
I don't think this will hurt RedHat at all. How many RHEL customers are actually generated as a result of providing CentOS for free? Not many I suspect.
Those who want to learn about RHEL can still get Fedora, or CentOS Stream, or a RedHat developer license.
I disagree I think RHEL and CentOS go/went hand in hand. With RHEL being used and licensed depending on the project or the environment. Binary compatibility and the uniformity of managing both being the big selling point.
Now the closest alternative is Canonical with Ubuntu Server which can be installed wherever with no strings and support purchased as required.
I really don't get this fascination with 10 year LTS. Why is it so hard to upgrade in half a decade ? I mean this is such an arbitrary number. If RHEL started offering 50 year support, people will complain that Debian is 1/10th of RHEL.
> I really don't get this fascination with 10 year LTS. Why is it so hard to upgrade in half a decade ?
The ideal situation is never having to upgrade: you buy your computer, install the operating system, and it works the same until you retire it. If your computer has a 5 year warranty, you expect to use it for at least 5 years before retiring it.
A 5 year LTS is only 5 years if you install the moment it's released, but that's not usually the case; for instance, there's a new Ubuntu LTS release every 2 years, so in the worst case your LTS installation will last only 3 years. Now consider the "10 year" RHEL LTS: in the worst case (you installed RHEL 7 just before RHEL 8 was released), your LTS installation will last 5 years, perfectly matching the warranty period.
Imagine you're a web hosting provider who builds their business around automation tools and control panels and whatnot tailored for CentOS 8. You really don't want to have to rewrite it all every couple of years because that's not where your business's value comes from. Also, updating will break a huge number of your customers' sites and apps, which will piss them off and bury your already slender profit margins in support costs.
Most of those hosting customers are not tech companies building fractionally "innovative" CRUD SaaS apps. They're SMEs who use their apps and databases to do real work: organizing their employees, procurement, running payroll, managing delivery routes, order and stock management — boring stuff like that. They very much do not want to have to significantly rewrite the back-office systems their businesses rely on because the OS changed under them. They want it to keep working for decades with as little redevelopment as possible.
Because CentOS was once an independent project and Redhat promissed to keep Centos 8 alive till 2029.
Security patches are not backports, they are security patches that obviously should be for free, Redhat is making loads of money off free software already.
Something like RHEL 6 is running on a 2.6 Linux kernel, all security patches has to be backported. That is an EOL kernel. Almost all versions of the software bundled with RHEL 6 have been EOL from upstream providers during it's ten year lifetime. Of cause you're free to try to attempt to applied any patches yourself, you don't have to pay.
If RedHat promised to keep CentOS 8 around for 9 more years, then yes, that is very disappointing. It was a stupid promise to make in the first place, but still disappointing.
It will hurt indirectly, because a lot of developers/devops/sys admins get skills working on CentOS which are then portable to RHEL. Now they won't. Network effects of being popular are significant.
Agree, "customers" who use CentOS are not paying for Linux and won't pay for any other distro. Somebody has to work to provide a stable distro and supported on many hardwares, hypervisors/clouds and softwares running on top of OS. But the funny things is that usually there is a huge contradiction on people who uses CentOS on production, they are the same people who pays for proprietary software like Windows, Office, Oracle DB, VMware, etc... sometimes spend millions of dollars on these softwares, but save some bucks using a free Linux distro!! But I do respect the ones who are entirely open source, just don't think any big company besides Google for example, would have a huge IT teams to support everything
641 comments
[ 2.6 ms ] story [ 320 ms ] threadI don't want to sound too "tin-foil headed" but I guess now that RedHat has hired the main CentOS dev(s?) this change comes from RedHat. I can't imagine the CentOS user base wants this direction for the CentOS project (or maybe thats just my lack of imagination...). People who use CentOS want a boring Linux distro like RHEL. They just don't want to pay for RHEL subscriptions.
There's a lot of people using CentOS indirectly, through CloudLinux. Whatever happens there, a lot of people will be affected.
My familiarity with Amazon Linux is about 4 years out-of-date these days, but it was a RHEL/CentOS clone with a number of the core libraries like glibc being updated and maintained by Amazon on an independent life cycle.
Is CentOS the upstream for Oracle Linux? Instead of which comes CentOS Stream and then the question is what will Oracle do? Would they even try to keep the old CentOS concept alive?
EDIT: This may be inaccurate; see https://news.ycombinator.com/item?id=25348496
I thought that Fedora was already serving this role
CentOS Stream is basically "the next x.y release of RHEL". Some updates, like GNOME updates and new hardware enablement, will be present in CentOS Stream a few months before they are released to RHEL and CentOS as part of a new x.y-release.
That is only true if CentOS continues to be widely adopted, with this move by RedHat i do not see that continuing, I am sure many org's right now are looking for options to move off CentOS / RHEL stacks.
How dare they want a free operating system?
Note that the announcement blog post points folks to using RedHat instead.
Embrace, Extend, Extinguish succeeded?
I use CentOS a lot for prototyping projects destined to be put on RHEL servers. I like it as a try-before-you-buy version of RHEL, and this change makes that use case a lot less useful.
So you can't make a proof of concept with the RHEL developer license in which you let "the business", customers, etc. toy around for a while.
The instructor told us if we wanted to try some of the things we were doing in class to experiment more, we could try it on CentOS. it was the practically the same. This was before Red Hat “ acquired” them.
A revived Scientific Linux could easy suffer the same fate. No one truly want to maintain a RedHat clone for little to no pay, while at the same time dealing request and complaints from companies who wants the benefits of RHEL, but no pay for the development and maintenance works done by RedHat.
Realistically it's some bean counter at IBM who asked why RedHat is giving away the very same thing they're trying to sell. Said bean counter do have a point in my opinion.
Goodwill. I use CentOS and until now if I had a project were Linux support had been important I would have gone with Redhat. They can rot in hell now.
[1] https://linux.web.cern.ch/
...sounds like what they expect
> it removes confusion around what “CentOS” means in the Linux distribution ecosystem
This justification for the change seems like a solution to a problem that doesn't yet exist but probably will soon!
I've been leaning on Debian-based distros for my own servers for a while now, but I still use CentOS in the lab. Hopefully RedHat provides an easy way to legally develop on RHEL without messing with a license.
_In the first half of 2021, we will be introducing low- or no-cost programs for a variety of use cases, including options for open source projects and communities, partner ecosystems and an expansion of the use cases of the Red Hat Enterprise Linux Developer subscription to better serve the needs of systems administrators and partner developers._
I believe we were one of the first 10 or so, but I don't remember exactly when it started.
Your only option is to migrate away from RHEL/CentOS, period. It's likely that Red Hat doesn't care much about us smaller orgs with only 100-200 servers/VMs though. Sad day.
Summarizing the FAQ:
Maybe they have some grand scheme I'm not seeing but it feels short sighted.
So now it is just "Operating System", maybe they should rename it IBMBetaOS or something like that.
Does this mean that CentOS 8 is EOL come 2021? Weren't maintenance updates meant to go to 2029? What about everybody who built their product on the assumption that there would be a stable CentOS until then?
1. They can start paying RedHat
2. They can hire/delegate someone to maintain patches for them
3. They can migrate to something else ;)
They have a shell script to convert a CentOS install to Oracle Linux, so you can buy support if you want.
The converter only works with versions 5, 6, and 7.
It does not work with CentOS 8. It would be nice if that could get updated.
(My opinions are my own, and do not necessarily reflect those of my employer; I'm in support at the moment, so foresee myself having to deal with the aftermath of this CentOS decision a year from now)
Does this mean that CentOS 8 is EOL come 2021? Weren't maintenance updates meant to go to 2029? What about everybody who built their product on the assumption that there would be a stable CentOS until then?
It used to be this. https://web.archive.org/web/20201101131417/https://wiki.cent...
That page is a Wiki and here is the diff between the current version and the previous: https://wiki.centos.org/action/info/About/Product?action=dif...
They've just eradicated almost all mentions of CentOS 8 from their main website. So: yes.
> What about everybody who built their product on the assumption that there would be a stable CentOS until then?
They just got what they paid for?
Haha, fair. To be honest, I'm surprised it took this long for it to happen after CentOS joined Red Hat. I wonder if the IBM acquisition had any influence on this.
Funny, but isn't this totally reasonable grounds for an adverse possession claim against RHEL?
If a business claims they're going to keep doing something, and you build your business on that claim, and then they change their mind, you can have grounds to sue. Or, at least, that's what I vaguely remember from reading about AP law.
Not really. If you depend on CentOS it is reasonable you would contribute to it. There has to be a nonzero number of CentOS users that contributed to the project ("paid") that are now left holding the bag.
Not really.
Just TRY to "contribute" to CentOS. You can't.
CentOS hasn't been a "community" enterprise operating system for years.
The new CentOS "Stream" sounds like it will be more like Debian Testing.
As stated in https://www.redhat.com/en/blog/centos-stream-building-innova... (linked from the article):
"CentOS Stream now sits between the Fedora Project’s operating system innovation and RHEL’s production stability"
So if we compare to Debian, this means:
Fedora <=> Debian unstable (Sid)
CentOS Stream <=> Debian testing (currently Bullseye)
RHEL <=> Debian stable (currently Buster)
Perhaps the closest is "the DAK upload queue for Debian stable", but that tends to contain mostly security updates, and according to other posts in this thread that is the one case where CentOS Stream is not an upstream of RHEL.
CentOS Stream contains feature backports, which generally don't happen in Debian stable, but it's only very specific backports, not every package gets updated like in Debian testing.
I'd put it like:
Fedora rawhide <=> Debian unstable
Fedora <=> Debian testing
CentOS Stream <=> DAK upload queue for Debian stable
RHEL <=> Debian stable
I guess there are only so many ways to organize a distro.
Right now, I've got a bunch of CentOS 6 servers with 2.6.32 kernels that are freshly out of support this month. I was hoping to replace them with 8, but now I'll probably have to settle for 7. At least I can take consolation in the fact that I haven't been called in to troubleshoot any CentOS 5 servers lately.
> CentOS Stream is focused on the next RHEL minor release. This means we are improving and influencing the shipping releases of RHEL. Fedora ELN is a testing area for changes that may occur in the next major release of RHEL.The CentOS Project cannot and does not speak for Fedora
CentOS Stream will be the upstream for RHEL minor branch development. This is actually a huge thing that I think people are missing: previously, once branched from Fedora, RHEL development did not happen in the public eye. With Stream, it will. This is huge and awesome good news. However, that development will still be entirely Red Hat curated. This is different from Fedora, where we make community decisions with Red Hat's engineering input as a stakeholder but not the decider. (See for example btrfs as the default filesystem.)
My guess is that Stream turned out way less popular than their sponsored hoped (who cares if it's developed in the public eye if it's entirely RH curated anyway). So CentOS 8.x had to die.
So why the negativity at this "huge and awesome good news"?
And you know that's not the reason for the negativity, so I don't know why you're being so flippant about this. Nobody has a problem with the idea of 'CentOS 8 Stream'. They have a problem with this being the replacement to CentOS 8 Linux because it doesn't fulfill the same use-cases.
* Use cases which actually despite the fears will be covered just fine by Stream * Use cases which will be covered by the upcoming expanded no-cost/low-cost RHEL programs * Use cases which, yeah, aren't covered
It's my estimation that the first two are actually the vast majority. I don't mean to be flippant (it was a long day). understand that people who are mostly in the third case are angry and disappointed, but from what I've seen in talking to people both when Stream was launched and after this announcement, at least some large number who are worried that that's their situation are going to be actually getting something better when the dust settles.
However, doing this will effectively make CentOS as a server OS useless for the most of us. "But Facebook uses it" - well, yes, with thousands of engineers Facebook could run their own distro and still have success if they wanted. Most useless argument ever.
Time to move on and find something else. Maybe good old Debian.
Since Facebook actually uses kernels from Fedora Rawhide (necessary for btrfs support I guess), their systems are nowhere near the CentOS you and I would use.
Makes sense commercially from RH's point of view. Boring and stable is now chargeable.
I think the doom and gloom is a misunderstanding.
CentOS Stream
Continuously delivered distro that tracks just ahead of Red Hat Enterprise Linux (RHEL) development, positioned as a midstream between Fedora Linux and RHEL. For anyone interested in participating and collaborating in the RHEL ecosystem, CentOS Stream is your reliable platform for innovation.
That doesn't seem to be what you think it is, at least in my eyes. I'm definitely not looking to run something positioned between Fedora and RHEL. There's already enough updates every month (including multiple kernel updates a month sometimes) that it's hard to keep the fleet updated. I definitely don't need stuff ahead of RHEL where I can assume I'm a bit of a guinea pig to test out the coming RHEL update.
"Q6: Will there be separate/parallel/simultaneous streams for 8, 9, 10, etc?
"A: Each major release will have a branch, similar to how CentOS Linux is currently structured; however, CentOS Stream is designed to focus on RHEL development, so only the latest Stream will have the marketing focus of the CentOS Project.
"Because RHEL development cycles overlap, there will be times when there are multiple code branches in development at the same time.This allows users time to plan migrations and development work without being surprised by sudden changes.
"Specifically, since the RHEL release cadence is every 3 years, and the full support window is 5 years, this gives an overlap of approximately 2 years between one stream and the next."
Also from Q2:
"We will not be producing a CentOS Linux 9, as a rebuild of RHEL 9. Instead CentOS Stream 9 fulfills this role. (See Q6 below regarding the overlap between concurrent streams.)"
So it sounds to me like my assumption is correct: There will be separate streams reflecting each RHEL release.
Read the whole FAQ. This is not what people think it is.
Right now, in RHEL 8.2, if a package needs a bug fix, it will be back-ported so that you get the fix in the existing running version of that package that was shipped in 8.2. On point releases, RHEL (and thus CentOS) may choose to back-port a feature, functionality, or choose to update the version of the package that is running to a newer version that has those features or functionality (or to bring it in-line with back-patches, I assume). When you update to a new point release, this gives you a single large update set that you can test to make sure functions well in your infrastructure. There have been points in the past where changes in point releases have required us to make changes to our configs or setup to deal with the RHEL/CentOS's point release changes (even though it's supposed to be rare, it happens, but it's mostly contained to these big testable update sets).
CentOS mirrored this exactly, because it mirrored RHEL.
Now CentOS is going to do something different, and these updates that would be relegated to point releases look like they are going to come down continuously. While not as problematic as something like Fedora, this is still something that groups specifically chose CentOS to avoid.
It's nice that Red Hat is offering something to allow people to get fixes and features sooner than at point release times, but to switch CentOS to only providing that is extremely problematic to the very large community that expects otherwise, supported CentOS, and has done both since prior to Red Hat hiring some of the main CentOS developers and effectively controlling the project, and is notably different than what CentOS has always traditionally attempted to provide.
Rolling forward to the head is required to get the most recent security updates. Which isn't that far away from how centos works today. With rhel you get security updates for the point releases (8.1,8.2,etc) for a while after the new point release comes out. With centos, the day that the newer version drops, they don't tend to roll security updates into the older ones.
Q4: How will CVEs be handled in CentOS Stream? A: Security issues will be updated in CentOS Stream after they are solved in the current RHEL release. Obviously, embargoed security releases can not be publicly released until after the embargo is lifted. While there will not be any SLA for timing, Red Hat Engineers will be building and testing other packages against these releases. If they do not roll in the updates, the other software they build could be impacted and therefore need to be redone. There is therefore a vested interest for them to get these updates in so as not to impact their other builds and there should be no issues getting security updates.
"If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options."
Of course no one want to run CentOS Stream because it's going to be broken / unstable, completely the opposite of what CentOS is.
Fedora -> RHEL -> CentOS
with the addition of CentOS stream it was becoming
Fedora -> CentOS Stream -> RHEL -> CentOS
now what it is
Fedora -> CentOS Stream -> RHEL
CentOS 8 had been mostly working well for me, barring a few missing packages that were easy to port over myself, and I was really thinking of moving all my boxes to CentOS. I'm glad this news came out before I did; I don't know what I'll use instead, but it definitely won't be CentOS/RHEL.
I haven't tried CentOS Stream, but out of curiosity: if it's similar to the RHEL patch releases, how will major (like from RHEL 8 to 9) changes be handled?
Most people (including me) never looked closely at "CentOS Streams"; from what you said, it seems like it's "a preview of the next RHEL 8.x". The announcement today made it appear as if it were "a preview of RHEL 9.0", which is a much bigger change for those who (like me) expect to install a CentOS 8 box somewhere and keep it mostly untouched (just applying the updates) for ten years.
I'm very pessimistic on what this means for the RHEL ecosystem as a whole...
If I understand correctly, CentOS Stream 8 should be relatively stable just after a RHEL 8.x release, because the pipeline will contain just minor updates. But as the next "x+1" release approaches, the pipeline will contain whatever is being tested for inclusion in it. This makes CentOS Stream unsuitable for the vast majority of people that currently use CentOS in production (i.e. the people that choose CentOS over something else like Debian Stable or Ubuntu LTS).
One can argue that these people can go buy RHEL licenses, but they most likely don't do that already because they see support as the value added by RHEL-proper and they can support themselves just fine. Many will also have RHEL instances along CentOS on systems that need vendor support, but pushing them to license everything may also push them into another direction altogether. Suddenly, standardizing on Ubuntu LTS (with paid support for a subset of instances) starts to make sense.
I think Red Hat (or maybe IBM) is vastly underestimating the value of CentOS in keeping the whole RHEL ecosystem competitive. They may be setting themselves up to be another SUSE.
And we're all worse off for it.
- CENTOS fills a need, that many users have and superficially it looks like Red Hat (IBM) is now abandoning addressing it. On the other hand Red Hat does offer RHEL for free (gratis) [0] and that should fill the needs of CENTOS users (right?). However it would have been much better if that option was mentioned in the announcement.
- I thought Fedora was upstream of RHEL. However after thinking more about it I realised that RHEL has a significant delta over Fedora. I 'm guessing CENTOS stream will be partway between Fedora and RHEL. It makes sense from Red Hats open development approach to have the delta between Fedora and RHEL happen in the open. Done right that should strengthen RHEL.
- Why the rush to drop support for CENTOS 8? I m sure some people are using it in production and they are unlikely to to want to move to this new CENTOS stream. It's a new OS distribution with a philosophy different to the one that was right for them!
Overall I 'd prefer if the new thing was called RHEL stream and provided for free (gratis) as CENTOS stream is. Also making more explicit the RHEL availability for free instead of having competing brands would be good. Now that there are competing vendors (Amazon Linux, Oracle Linux) trying to entice users it'd be better to strengthen RHEL brand rather than dilute it with multiple offerings. Unless RedHat/IBM plans to pull the plug on option [0].
[0]: https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-d...
They offer a no-cost "developer subscription" of RHEL, but I'd wager the majority of users are running CentOS on servers.
Disclaimer: not affiliated with Oracle in any way. This is just the closest thing to a plain RHEL8 clone I know of, other than CentOS8.
Speaking entirely for myself, opinions my own, may not reflect my employer etc. etc:
I came in to this job expecting OL to just be a CentOS clone, and not really expecting much from the kernel they ship with it.
It is both a CentOS clone, and a bunch more. Oracle takes the CentOS packages and applies bug fixes etc. that upstream RedHat has failed or refused to apply, so I've actually found OL to suffer from fewer problems than CentOS, and we've even had to apply mitigations for CentOS 6 for stuff we haven't had to do to any other OS we distribute. For entirely selfish reasons, I was really glad to see CentOS 6 go end of life last month.
On top of that the OL team hires a significant number of upstream kernel developers, including the core maintainers for a number of components, like XFS, Xen, and so on, and produces the Unbreakable Enterprise Kernel (a really curious choice of marketing terminology), that incorporates mainstream bug and security patches, while being closer to mainstream than RHEL/CentOS, and the kernel patches submitted upstream by OL devs.
I would point out, I'm not in the OL org, I have absolutely no idea what this change means for Oracle Linux. Oracle Linux is based off the CentOS sources as that's the only way that RedHat was making the source code to their distribution available (there way of meeting the terms of the GPL). RedHat has to make their source code available in one form or another so I can't imagine that this would have any impact on OL, but that's entirely guess work.
If that's true, I wonder how Oracle got some of their 8.x releases out much earlier than CentOS. (Oracle Linux 8.3 2020-11-13 vs CentOS 8.3 2020-12-08, Oracle Linux 8.0 2019-07-19 vs CentOS 8.0 2019-09-24.) I'm assuming here without verification that both track the RHEL 8 point releases.
>Yes, but only one no-cost Red Hat Developer Subscription can be added to a user account. While it is possible to have each developer register for their own account, this is not ideal from a management or efficiency standpoint. For example, if a company wanted no-cost Red Hat Developer Subscriptions to cover 100 developers, each developer would need to individually register and independently create 100 accounts that need to be tracked and maintained. For enterprises that use Red Hat Satellite to manage multiple systems, all 100 accounts would need to be added individually. Accepting the terms and conditions and renewing the subscription annually would need to be done individually and manually for all 100 accounts. Staff turnover in the development team would create additional management challenges with individual accounts. Therefore in terms of lost productivity, managing individual no-cost subscriptions will not be cost-effective for many groups.
Many development organizations benefit from having Red Hat Developer Support. Cost effective bundles are available that include support with a pack of 25 Developer Suite subscriptions that can be managed from a single account. Each of these subscriptions is based on systems, rather that users.
So if we compare to Debian, this means:
Fedora <=> Debian unstable (Sid)
CentOS Stream <=> Debian testing (currently Bullseye)
RHEL <=> Debian stable (currently Buster)
quote source: https://www.redhat.com/en/blog/centos-stream-building-innova... (linked from the article)
It's just a simple common-sense scheme, it's not the result of deep thought. What you're struck by is how marketing-oriented the RedHat repository naming scheme seems to be...
in debian testing is the next major version, while centos stream is testing for the next minor release.
It is fedora that is testing for next major release.
sid would be similar to fedora rawhide..
sid <=> fedora rawhide
testing (bullseye) <=> fedora, altough not every fedora became a rhel
stable (buster) <=> rhel
centos stream would be likely similar to having stable with the proposed repo fully enabled.
IBM strikes again.
> Easy remote management.
Just out of curiousity, are you SSHing in directly, or installing the Teamviewer RPM on all of them?
Plus, I'm running Pi-Hole in docker and I ssh to upgrade it from time to time, (docker pull, docker-compose down/up, etc.). I haven't bothered automating this because some things change between releases and I still end up doing manual configuration changes.
Also, I am not one of the highest upptity-ups in the company or anything, but from the inside: I see no evidence whatsoever that this is the result of IBM anything.
Fedora Silverblue could be interesting alternative to regular Fedora then, since you can boot into or roll back to a previous release. You can also pin a known-good OSTree commit, so that one could always boot that version.
In my experience (just went through that, F32 -> F33), it's painless but definitely not "an automated thing that happens while you go for coffee"; each machine took a whole day, it's a huge download (many gigabytes) and the install itself seems to be severely fsync-limited (several hours while the progress bar slowly fills and the disk light is lit all the time; after the fact, "journalctl -b -1" shows it was installing/cleaning package by package all that time).
That should address most of the issues you mention. :)
[0]: https://centos.org/distro-faq/
They really lagged on the PLATYPUS CPU vulnerability for CentOS 7, because they were dealing with a backlog from the 7.9 bump. Took them several days to get the patches out.
CentOS Stream however is not a Free (beer) rebuild of RHEL anymore, it is an "upstream" for RHEL, so it would not be expected that this flow would work like described for an upstream product
RHEL security fixes for version X.Y may or may not fix security issues for version Z.A on CO, if the are not in sync.
I'm not sure where I claimed it was?
So you're getting some instability by being first in line for updates, but you're still second fiddle for security fixes.
I was trying to point out this isn't different from a security perspective. Yes the rest of the distro is going to almost reach a rolling state which is definitely not something I want in production.
https://oss-security.openwall.org/wiki/mailing-lists/distros
The linux kernel maintainers have a private list where they co-ordinate some of this stuff, and every major Linux distribution will have engineers on it.
That's partly why you see things like OpenBSD etc. being left on the margins. Certain maintainers have been quite vocal about not adhering to embargoes, which really doesn't help them. It's an idealist vs pragmatist thing going on there.
I've run most all the flavors of linux and am on the Ubuntu train. Actually, I flirted with the RHEL / Fedora / CentOS workflows as current as last year for a few months. I love the predictability and stability of RHEL on workstations and the thought of something new on a laptop or what not. While I respect the hell out of RH and their products, it just didn't work for me. Fedora is WAY too experimental, lacks supports, and is prone to your system breaking. I know, I know, it is pretty stable and has a lot of support behind it. But after updating via yum and having my WIFI stop working on my 6 year old Thinkpad, that is a deal breaker. I think there is way too much disconnect between their projects. RHEL is super stable, but the packages are severely outdated. Fedora is too experimental, and is pretty much a home operating system and a playground. I know CentOS is free, but depending on your business is paying $300 / year / machine for legitimate support and ticketing really an issue? That's for everyone to decide on their own. I think Ubuntu LTS is the best middle ground for stability and new packages. And if you need paid support and professional help, you can pay Canonical as well.
I could see this coming. CentOS didn't really show a value proposition for RH picking up the tab and supporting it. CentOS was recompiling RHEL and shipping it off; RH needs to keep their PR and image inline and HAD to help, since the whole point of CentOS was "this is RHEL without RH graphics and copyrighted material." IMO, RH felt like they were doing the same thing twice; producing RHEL, then removing RHEL branding and helping package up and compiling CentOS. Due to this, I think the biz folks scratched their on why they needed money, and now we have Centos Stream. I have no doubt another project will spin up taking up the slack of just recompiling RHEL.
Different tools for different jobs. Maybe Centos Stream will be awesome! Maybe it can fill the gap between Fedora and RHEL.
Bear in mind that CentOS was originally an independent project until Red Hat acquired it.
It does support flatpaks.
There is no free openSUSE LTS. The LTS is called SUSE Linux Enterprise Server, costs some money (unless you are a developer, in that case you get free subscriptions) and the LTS lasts for a minimum of 13 years.
The root filesystem uses btrfs, so it's easy to roll back update problems. There is also a newer version that uses a read-only root filesystem and updates are applied to a new snapshot that takes over when you reboot. It's pretty cool.
suse cured my containerlinux wound. (if suse gets bought by ibm than I will be furious or if they kill microos)
Don't know if that applies to rhel
my biggest complaint about ubuntu server is that docker is packaged as a snap. But that takes 30s to fix (includding googling for a fix :) )
(Learning Ubuntu since CentOS went broke their pinky promise to supply security updates until 2029)
They also conveniently waited until right after EL6 EOL...
If RH doesn't release some "Academic Version" (but who would even trust that at this point?), then I suspect revival of Scientific Linux or adoption of shudders Oracle Linux is more likely than a switch to Debian. FreeBSD is probably a non-starter.
That has nothing todo with a Distribution, maybe with linux but Redhat...pff....Looong-LTS that was the plus.
Oracle Linux...no one and especially cern would ever risk that.
The major release of RHEL is usually forked from a Fedora version about a year before the major release, so with some exceptions software versions tend to be about a year behind those in a Fedora release initially, and then as RH backports patches rather than revving versions, drifts further.
It's the patches and smaller updates — and new hardware enablement in the full-support phase — that will be landing in CentOS Stream. Previously, this stuff was developed internally and only released to the world at the minor-release drop every six months. Now, it'll be developed in a shared space. So what you'll have in CentOS Stream is whatever is intended to ship in a RHEL minor update within six months.
There may occasionally be a situation where an update introduces bugs into Stream that would have been caught by QA before a public minor RHEL release and subsequent CentOS Linux rebuild. But I don't actually expect that to happen enough to worry about in any case where you can justify not paying for actual supported RHEL in the first place.
Shocking, because I'd never imagined they'd kill off CentOS 8 so early. CentOS 8.0 dates from Sept 2019, so it's killed in just the 3rd year of its presumed 10 year lifespan. I could read the tea leaves when they announced this Stream thingy recently, but I'd thought they would at least hold off till RHEL9 to pull the lever.
Blindingly obvious, of course, because Red Hat bought CentOS, presumably with real $$$, and IBM bought Red Hat for $34bln.
What's going to happen next? Microsoft buying Canonical and all businesses running either IBM Linux or Microsoft Linux? Crazier things have happened...
What happens in practice with this sort of "rolling release" is users end up patching endlessly in production, which no sane person or organization would ever want to do. This was the exact situation for another Redhat acquisition for years now. JBoss EAP and community editions (wildfly now I suppose), everyone who could moved off of JBoss long ago.
Ubuntu is already the default for people with ML pipelines and more and more vendors are targeting Ubuntu first for their software.
CentOS will be effectively dead for a lot of companies starting next year (or 2024). (At least we aren't planning on licensing 10^5 systems on RHEL...). I imagine for those same companies, RHEL isn't far behind it.
What's even worse here is that at least for us there are some things that we pay for RHEL for. If we switch all of our other servers, those RHEL licenses won't be continuing either.
Obvious, but stupid.
Canonical and RedHat are paying the salaries of the people steering the direction of Linux as a whole. They're forcing you to choose between the two.
That's pretty weak sauce even compared to the five years Debian and Ubuntu offer. And Debian actually supports all their packages, unlike Ubuntu which tricks people into installing unpatched garbage from 'universe'
Ubuntu followed Red-Hat's footsteps away from desktop into the server room, as there is no money to be done there, and it will follow it still, if there is still not enough money on the server.
Just installed OpenBSD for the first time the other day, and am loving it.
https://github.com/liv-io/ansible-roles-bsd
But I don't see BSD becoming practical as a platform to run (commercial enterprise) Linux software, when it's already a pain to get packages and support for anything that's not RHEL/CentOS.
Jails are awesome but not containers you're blocked there as well (if you need containers and the tooling around them).
Bhyve performs very well.
>Jails are awesome but not containers you're blocked there as well
What are containers? Ansible with OS-Virtualisation right? So with Jails and Salt/Ansible/puppet or Templates you have your Containers.
OR just take that:
https://bastillebsd.org/
if I remember right technically centos didn't really exist as an entity that could be bought, Red Hat just hired all the developers (there were only ever 3-4 people working on centos). I would guess they are now working on Centos Streams, or have moved on to other things entirely. Its not like Centos has been killed off either, so it didn't cost a lot and this wont really save anything, it's "just" a change of focus.
Microsoft buying ubuntu would be an interesting (and not impossible) move though.
Not exactly unexpected, but disappointing: if you want to continue using something like CentOS, pay for RHEL. Lots of web hosting providers will be quite concerned.
I don't think this will hurt RedHat at all. How many RHEL customers are actually generated as a result of providing CentOS for free? Not many I suspect.
Those who want to learn about RHEL can still get Fedora, or CentOS Stream, or a RedHat developer license.
Now the closest alternative is Canonical with Ubuntu Server which can be installed wherever with no strings and support purchased as required.
I think I'm going back to Debian for my servers. i wish they add 10 years lts though.
If you want guaranteed updates backed by a contract, choose Ubuntu or RHEL.
I really don't get this fascination with 10 year LTS. Why is it so hard to upgrade in half a decade ? I mean this is such an arbitrary number. If RHEL started offering 50 year support, people will complain that Debian is 1/10th of RHEL.
If you want to know more I wrote about it in another comment: https://news.ycombinator.com/item?id=25348914
The ideal situation is never having to upgrade: you buy your computer, install the operating system, and it works the same until you retire it. If your computer has a 5 year warranty, you expect to use it for at least 5 years before retiring it.
A 5 year LTS is only 5 years if you install the moment it's released, but that's not usually the case; for instance, there's a new Ubuntu LTS release every 2 years, so in the worst case your LTS installation will last only 3 years. Now consider the "10 year" RHEL LTS: in the worst case (you installed RHEL 7 just before RHEL 8 was released), your LTS installation will last 5 years, perfectly matching the warranty period.
Most of those hosting customers are not tech companies building fractionally "innovative" CRUD SaaS apps. They're SMEs who use their apps and databases to do real work: organizing their employees, procurement, running payroll, managing delivery routes, order and stock management — boring stuff like that. They very much do not want to have to significantly rewrite the back-office systems their businesses rely on because the OS changed under them. They want it to keep working for decades with as little redevelopment as possible.
Security patches are not backports, they are security patches that obviously should be for free, Redhat is making loads of money off free software already.
If RedHat promised to keep CentOS 8 around for 9 more years, then yes, that is very disappointing. It was a stupid promise to make in the first place, but still disappointing.