Redhat Iso
Shari Alvine
You are at the right place. We rely on this design system to create consistent Red Hat digital experiences. Using Red Hat brand standards and PatternFly as our foundational design language, we enable designers and developers to concurrently build branded experiences across redhat.com, Red Hat Customer Portal, and beyond.
I don't contribute to CentOS or Red Hat development much, if at all. But I have, for over a decade, provided software and tools that were compatible with RHEL, Debian, Ubuntu, Fedora, Arch, and sometimes other more exotic distros.
I could test my stuff against CentOS Stream... or UBI... or Fedora. Those are mostly like RHEL. Or I could try linking a Red Hat Developer subscription to my test runners and build tools so I could use a licensed copy of Red Hat Enterprise Linux, because that would be required for... actually ensuring compatibility.
At this point I'm determining whether I want to continue supporting just Fedora, or just dropping all support for RHEL and RHEL-like distributions on my open source projects. It's not worth the hassle if I'm not even sure projects like Rocky or Alma Linux can fill in the gap left by CentOS's demise for users like me.
It pains me to write this, because there are many people within Red Hat who are amazing folks who I respect greatly. And Red Hat still supports and promotes a ton of great OSS work. I am just mystified by the direction they've taken their bread-and-butter Linux distribution and the community around it.
It's not greed to try to support your shareholders who financed your over $30B acquisition. But it's also not a wise move yet again by IBM. Awaiting what the other evil empire (Oracle) does here with their RHEL clone....
Oh yes it IS greed indeed, a LOT of it! This whole thing has quite obviously been motivated by nothing but pure greed. Some beancounters at Big Blue have figured that if they'll try and force everyone into their (rather ridiculously overpriced) subscriptions then they'll earn $$$. Those with higher-than-room-temperature IQ and a sound mind however probably knew that this would backfire spectacularly.
For versions past their published public LTS window of 5 years. Right now Ubuntu 18.04 is just fell off support and would need these commercial subscription if you're not ready to upgrade to 20.04 (or 22.04).
I'm very disappointed but nor surprised. RH was early to the game and made good moves to become a PROFITABLE Linux company through authority over time. But this is also why I don't USE Red Hat, the management makes weird decisions sometimes that are very much user-hostile, like this, the CentOS purchase, etc. I have no doubt they'll be around for a long time, and they'll continue to do good work on OSS and make money, but as a USER I can't trust them.
I'm as serious as a heart attack. When you compare Red Hat's "engineers" with SGI and Sun kernel engineers, well, the Red Hat boys are amateurs at best. They'd rather argue with their paying customers than actually solve problems, because most of the time, they have no clue where in that haphazardly hacked-together mess of patches upon patches the problem actually is. There can be no discussion about kernel engineering when it comes to Linux because there is no engineering to speak or write of. It's all hacking. So yeah: idiots, and whoever runs that mess in production is an idiot as well, for not knowing any better and not caring to find out if there is anything better, and how it all works.
CentOS stream is beta software. It's not deemed stable, and is not bug to bug compatible with RHEL. What Alma and Rocky are bug-for-bug, drop-in replacements for RHEL, and they are being used by pretty serious infrastructures maintained by people who know what they are doing and need no support.
If you've ever had to audit the CVEs on Rocky, you wouldn't say that. To Rocky's credit, they've long admitted they have a long way to go. Their web site and OVAL are not their focus. They are far, far worse than what CentOS was prior. Alma is in the same boat.
We've had to blacklist Rocky at our partners and subs for this reason. It's not Rocky's fault. It's people overselling their CVE tracking. Again, Rocky has been honest they have a long way to go in being able to track CVEs. And now with Red Hat cutting off the Source RPMs, other than Stream, I don't know if there is any reason.
BTW, please stop saying things like unstable/experimental. Facebook and Twitter were the big pushers to get Red Hat Engineering to release Stream publicly under the CentOS(TM) trademark. Yes, Stream has always been around, but only for internal, major accounts and partners.
Stream is all backported customer bugfixes and all security patches. Normally RHEL only gets high/important/critical security patches and nothing else, until the next Update Y+1 (RHEL X.Y+1) comes out.
E.g., if there is a memory leak in a package in RHEL 8 -- currently Update 8 (RHEL 8.8) -- reported by a Red Hat customer, and Red Hat reproduces it, and backports the fix to the RHEL package, and builds it as a hotfix, Stream will also take the patch, build it, and push it through the full IHV/ISV unit, integration and regression test suite. RHEL won't get it, not until Update 9 (RHEL 8.9).
REAL WORLD: I literally ran into a serious memory leak taking down RHEL7.7 & 7.8 systems on our Data Lake cluster, one of our most important systems at a top 25 US Bank. There were 2 issues that were found at 2 different customers, and I had to wait until RHEL 7.9, and keep us on an older, pre-RHEL 7.9 package. Had I had access to Stream, I would have gotten both customer hotfixes instead of having to wait a year.
Think about it this way. That same bug that you found in 7.9 was in Stream long before it was pushed down to RHEL (and it made it all the way through "testing"). So in reality you would have probably had the bug even earlier if you were on Stream.
I've been a huge supporter & user of CentOS for nearly 2 decades. I've also been a supporter of Rocky linux since they were announced.. But I no longer use Fedora/CentOS in my home labs. I've switched over to Ubuntu.
My new parent company has even switched to Oracle linux over RHEL because of their crazy behavior. So even people who used to use direct RHEL have switched over to Oracle which I dislike. But there's nothing I can do.
I honestly cannot believe people are holding up Oracle as an option here. I could go through the last 15 years of that mess! Oracle even admits they break a lot when you corner them on support tickets.
I was taken by surprise as well, this was not discussed internally (at least not that I was aware). Someone already noticed Jeff's post and called it fallout. This personally pisses me of the wrong way.
How bad is this from a marketing point of view, that's not for me to understand since I don't work at RedHat... That's a reminder that corporation behind free/open source projects its always dangerous compared with community driven projects like Debian
Stream is for when you want all customer bugfixes and all security fixes as they exit the Red Hat build & unit-integration-regression test system.that feed all RHEL packages as well, but are not held back.
Can't have it both ways. But I agree it's wrong for Red Hat to cut off the SRPMS. But I wouldn't use LTS as an example against Stream. Stream stands on its own very, very well, right down to the backporting and kABI of the RHEL release. It just doesn't wait for the next update to release bugfixes and lower risk security patches.
Your answer is kinda dishonest about the fact that fanbois are whining regardless of what RedHat does. No, enterprise-grade distros really do NOT want bleeding-edge (i.e. barely tested) bugfixes, because they use those servers for production and would lose big if they encountered problems after minor version upgrades. Thus no, they don't want "all customer bugfixes and all security fixes as they exit the Red Hat build & unit-integration-regression test system" and now some of them are left with no choice but to switch to some completely different distro.
At DEC we had different types of releases. Many of our customers *never* installed a "major release" (2.0, 3.0, 4.0, etc) but only instated "big fix releases" with little or no new functionality. We also had "new hardware support" releases, with *no* bug fixes in them (since customers paid for bug fixes) and customers wanted their software "bug for bug compatible".
Huh? Stream is *backported* fixes to *stable* RHEL releases. They just go out as they pass the IHV/ISV test suite, instead of Red Hat 'holding back' until the next Update Y+1 (RHEL X.Y+1). E.g., when a customer gets a backported bugfix, it is also patched into Stream 8, but not the current RHEL Update 8 (RHEL 8.8). It won't go into RHEL 8 until Update 9 (RHEL 8.9). Please don't give me the 'barely tested' BS. It is literally a backported customer bugfix.
I'd more than lost faith along the way with RH (Linux user since 2000) once the hard sell began for RHEL vs. CentOS began long before Stream, and Fedora was just always some bastard cousin of theirs to me. The IBM acquisition just signaled doom, where anyone that's been around this industry any amount of time knows no good will come from that. IBM will never innovate, they'll simply squeeze the rock harder to bleed it for pension payments.
Given the effect the decision by IBM to cut access to the source has on the market, which effectively considers RH clones as public infrastructure, why hasn't the USA Federal Trade Commission stepped in, especially given the lock in through the OEM agreements with Microsoft & RH?
The main problem is that OEMs test & even validate server/workstation/desktop/laptop hardware for both Microsoft & RedHat OSs on the OEM provided hardware, under agreements which MAY have caveats that effect competition.
Currently you can get around this by when you purchase, lease or collocate OEM hardware originally purchased with the NO-Operating-System option or more likely second hand, but if the hardware has been tested with Red Hat Enterprise Linux it should work as expected under CENTOS clones.