After their killing of CentOS, I hope anyone who reasonably can avoids RHEL. I'm positive they're going to change policies again in the future and fuck over people who decided to go with this zero monetary cost RHEL offering.
> When we announced our intent to transition to CentOS Stream, we did so with a plan to create new programs to address use cases traditionally served by CentOS Linux.
This is a load of bullshit. If that was their plan they would have announced both of these changes together. It's not like they were under time pressure to get the announcement out.
>This is a load of bullshit. If that was their plan they would have announced both of these changes together. It's not like they were under time pressure to get the announcement out.
I work for Red Hat, opinions are my own, etc. I don't know why they decided to announce the CentOS plans before announcing at least some of the expanded RHEL offerings, and many people are just as confused as myself. However, whatever the reason was, it's absolutely true that expanding access to no-cost and low-cost RHEL was always the plan, and the original announcement effectively stated as much.
You've obviously made the choice to hate, but for anyone else reading this comment, the CentOS announcement specifically mentioned at the time that an announcement like this was coming regarding expanded RHEL options. Not sure what more evidence is needed that it was the plan. If you're a conspiracy person go look at archive.org's version. If you believe archive.org is in on the conspiracy, well, I'm not sure what to tell you.
Not the OP, and I have no doubt they had plans to "expand" RHEL options
I also have no doubts they wanted to see how much bad PR the announcment made before figuring out that those expanded options where
It was from be beginning a Monetary Grab, Redhat did a global scream test to see how much they would have to give away to take the screams down to a dull roar and stop the bleeding just enough to not lose any market share
They have landed on 16 as the magic number for now, but like the OP I have visions of Darth Vader saying “I am altering the deal. Pray I don't alter it any further.” while wearing a RedHat
It does not fill me with confidence that I should make use of that 16 server license...
RH was under time pressure to announce the CentOS 8 EOL dates. Because we did not want more people to move to CentOS 8 during the holidays. The programs weren't ready and we felt it was important to get the CentOS Linux announcement out as soon as possible. We had many long discussions about this in the Red Hat internal memolist when CentOS news were announced. Please search the internet for Red Hat's memolist. It takes a lot of time to come up with free programs like this, thats the simple truth. You can choose not to believe this and wait for few years to see how these turns out. It is not about immediate revenue growth but how to make RHEL evolve as the next generation OS. If RHEL does not change it will be become obsolete sooner or later.
I appreciate the thought, but am still miffed at the "embrace, extend, extinguish" that caught me off guard here. I can't exactly pull out too many pitch forks because CentOS did let me enjoy some of their packaging labor for free.
It's obvious in retrospect that their intention was to pull this when they acquired the CentOS project - plotting to turn CentOS into a RHEL on-ramp while dressing it as an embrace of the community feels like a kick in the groin.
Also, 16 servers is barely enough for tech companies caught by this, and is less of a good will gesture, and more subscription growth hacking.
Honestly these seem like pretty generous and useful offerings. I appreciate the commitment they make to not use them as a sales channel as well. Will be interesting to see what else is offered in the coming February announcement.
It's generous as long as you ignore the fact that CentOS used to cover all of these usecases without any restrictions on what you could use it for or how many servers you could use it on, for free, with no licensing or registration.
But since we aren't entitled to any free product at all, it seems unkind to criticize someone for not giving as much for free as they once did. It's still generous, even if previously it was more so.
We are as entitled to it as we are to the Linux kernel on which it's based.
That's the cost of building a product on GPL2 licensed software.
The CentOS project itself wasn't started by Red Hat. It was given to them with the expectation that they would be good stewards of it. In killing its core mission, they haven't been.
> We are as entitled to it as we are to the Linux kernel on which it's based.
Are you claiming they are in violation of the GPL license? I believe they still are 100% in compliance.
> The CentOS project itself wasn't started by Red Hat. It was given to them with the expectation that they would be good stewards of it. They haven't.
They stepped in to stewardship of the product quite naturally, with the full backing of the previous stewards. Nobody was forced into that agreement. It wasn't given to them as a gift, Red Hat has sponsored the project for the last 6+ years. The fact that you disagree with the direction it has since gone, does not mean it's wrong. It may be the difference between having something more modest, and having nothing at all.
And if you want something closer to the original CentOS check out:
> Are you claiming they are in violation of the GPL license?
I'm not, they are indeed compliant, and Red Hat is not obligated to directly maintain CentOS. They are only obligated to provide the source to customers under the terms of the GPL.
However, if Red Hat no longer wants to maintain CentOS in the spirit in which it was founded and taken over, I'd argue the ethical thing to do would be to spin the project back out of Red Hat.
> But since we aren't entitled to any free product at all, it seems unkind to criticize someone for not giving as much for free as they once did.
Like... sorta? On the other hand, they went on the record saying that they would support CentOS 8 through 2029 [0], so I think it's reasonable to be unhappy with them for going back on that even in the absence of a monetary relationship.
Yes, I can understand being upset about it, but think such anger should be tempered by no fee being paid and no contractual obligation being breeched. It seems to me if you're in a situation where you truly depend on such a commitment, you should be paying for a contract with someone, not hoping for the best. Had Red Hat not been supporting CentOS for over 6 years, it may have fallen apart even sooner. Who knows.
So while this is disruptive and bound to be upsetting, Red Hat are still being quite generous with their new offerings. And as far as I know, they are not standing in the way of CentOS replacements such as Rocky[0] or Lenix[1].
It's not a matter of whether a contract was breached. People tend to get upset when trust is broken. I suppose your argument is that people shouldn't have trusted RedHat because no money was exchanged but that's not really how trust works in real life.
My argument is that people should have more reasonable expectations from a free project. That it is unreasonable for a free project that is shutting down to continue to operate until all EOL's are reached, especially til 2029. It's quite nice of them to keep things going for a full year in order that people can make other arrangements.
Once the unfortunate decision was made to shut down CentOS, it would be very nice if the public outrage was tempered with a little appreciation for the 6 years of support that Red Hat gave to it, and also an appreciation for the new options for free access to RHEL they are providing.
First, they should have announced this when they killed CentOS.
Second, this is only of value to the teeny tiny companies and individual users with a single server in their home. Small companies with any expectation of growth should probably just use Rocky instead from the get go.
I have a single server in my home running CentOS 7. I gain nothing by using RHEL over Rocky in the future, except with RHEL I have to accept ToS, do some subscription checks, and run the risk that Red Hat cancels this programme down the road. I only see this of value for someone who actually runs real RHEL in prod, and needs to test/validate hardware/software. For anyone just wanting 'free' RHEL, they should just use Rocky.
> First, they should have announced this when they killed CentOS.
I agree.
>Second, this is only of value to the teeny tiny companies and individual users with a single server in their home. Small companies with any expectation of growth should probably just use Rocky instead from the get go.
Without saying too much - stay tuned for further announcements.
yeah, stop playing games, redhat? just say what you're going to say already. i have no idea why you're trying to focus so hard on building mindshare, building a mystery around it like you're a sarah mclachlan tribute band, but you already blew it. go back to what you're good at, please.
I understand as an RH employee you're likely not in a position to make decisions about what you can disclose when, but... (I'm sure you're aware) your first answer contradicts your second.
There's no contradiction, only an acknowledgement that (in my personal opinion) the piecemeal way these plans are being announced is understandably frustrating, but that they are legitimately serious about making RHEL easier to use across a spectrum of use cases (which the official post is pretty clear about).
It's worse than frustrating, it's damaging for Red Hat.
It doesn't matter much to me anymore, I've already migrated my small business internal server that was running Centos 7 to Debian. We had basically just a fileserver, FTP box, and a couple VMs for some time clock, wiki, and building security systems, so nothing we were running yet was CentOS specific.
But in case it can be useful to you, please share with your team that the writing they're putting on the wall looks pretty bad. Knowing I'd have to update eventually, I just took the safe option, which is no longer any distro controlled by Red Hat. I didn't want to leave our server in a state where we could be building dependencies on a platform that was likely to be pulled out from under us, and while RHEL isn't too expensive to just buy for one server, and we might have qualified for something free or something you've not yet announced, my test was surprisingly painless and the migration was easier than I anticipated.
RedHat seems to forget the for the majority of CentOS users STABLITY was the driving factor in the choice to use CentOS.
I am not sure what internal metrics they have, or if I am missing a glaring use case somewhere but from where I sit RedHat seems to completely miss the boat as to who is using CentOS in the real world.
I want STABLE UNCHANGING SECURE systems, not the latest and greatest features, or some new shiny "cloudy" technology...
I dont drive those decisions butI will say if they had better "no support" options my org probably would buy it. We have no desire for RHEL support, they had had bad experiences in the past which was one of the driving reason to drop RHEL for CentOS, why pay for support if it sucks?
That's fine, but it would be negligent of a company to wait and hope that Red Hat pulls a rabbit out of a hat. The plan for most companies is going to be a new distro, and they're not going to reconsider when RH announces something new because by then decisions have been made and trust has been lost.
Red Hat was not expecting the reaction to killing CentOS.
The need to expand the developer program into production seats could not have been anticipated.
I don't know of any other vendor that wraps developer accounts into production licenses.
Notice that this access is in no way promised to the end of support for RHEL 8.
I will say again, Red Hat has terminated two major Linux platforms over the last two decades - the original Red Hat Linux, which was terminated at v9, and now CentOS.
Oracle has "somewhat" terminated a Linux platform, Oracle Linux for SPARC, which was only supported for two minor releases. Oracle Linux for ARM64 and AMD64/x86 seem reasonably healthy.
There is other baggage in and between these corporations, but the track record on Linux OS platforms between these two is demonstrably different.
The free converters between them should be used fluidly.
I see the decision to convert to CentOS stream as driven by two motivations, cost containment, and facilitating outside contributions by pushing CentOS towards Fedora (and away from RHEL stability).
I might be misreading these motivations.
With this management perspective, the CentOS community reaction to the retraction of the end of life date, and potential reduction in stability, was likely not anticipated.
> pushing CentOS towards Fedora (and away from RHEL stability)
CentOS streams is literally RHEL with fixed major version and rolling minor versions. So, in the past, you got CentOS 7.1, then 7.2, etc., with streams, you get CentOS 8.x.
Saying that this is moving away from RHEL stability sounds highly disingenuous. Are you saying you've seen RHEL 7.X to break as opposed to 7.(X-1) version, and your solution was to wait for RHEL 7.(X+1)?
Are we not reading this correctly? If not, could you get Red Hat's CTO to retract this [mis]information?
'Another official part of it is, as [Chris] Wright [RedHat CTO] said, is that CentOS Stream as a "rolling preview" of what's next in RHEL, both in terms of kernels and features can be used in today's containerized, cloud-native IT world.'
> CentOS streams is literally RHEL with fixed major version and rolling minor versions. So, in the past, you got CentOS 7.1, then 7.2, etc., with streams, you get CentOS 8.x.
> Saying that this is moving away from RHEL stability sounds highly disingenuous.
If it were so great, they'd do the same for paying customers. That they don't move RHEL to being just 8.X makes me think that Red Hat does in fact understand that that undermines the stability of the platform.
> Without saying too much - stay tuned for further announcements.
It's a horrible way to treat users.
They aren't paying customers, so whatever for RH short-term bottom line. But amount of community backslash approach like that is bringing can have negative long term impact.
RH pulled the rug from under the people, and is telling them to stay tuned. I wouldn't base my infra on a system like that.
But that's good for overall Linux community - RH has way too much power there.
I manage a "tiny company", but we have 10-ish production CentOS 7/8 servers and this sounds interesting. Although my web-app use case is probably fine with Stream, I don't know why everyone is assuming Stream will be completely broken and useless.
It's not that the expectation is that it will be broken and useless. It's that the reason to choose CentOS was for the fact that it has slow release cycles which allow for long support periods.
> I don't know why everyone is assuming Stream will be completely broken and useless.
It probably wont be completely broken and useless, but they replaced a stable OS with a beta, which is particularly galling to many users who picked that OS specifically because it was so stable.
I think you're digging in the wrong place, and focusing on the label. This shouldn't be kicking fedora down. It has a place, as does stream.
The point is that with CentOS you expect a super stable release. Red Hat replaced that with what is clearly a less stable project. And as was said before, if you used CentOS, it's probably precisely because you want something super stable with long term support. Those are not the sorts of users who'll want to use Stream.
To me, Fedora is a desktop environment (my preferred one!) and absolutely an alpha/early-beta server option at best.
CentOS Stream seems like "Fedora, again" and does not do what CentOS did. And now, the willingness to blow up CentOS with so little warning means there is a massive trust deficit here.
There's a pretty big difference. While I'm very much not an expert on the RHEL QE process, my understanding is that Fedora is pretty much its own thing that is used to rebase RHEL on major revs. Whereas Stream is RHEL builds that have passed CI testing in the RHEL dev/test process.
Slightly detached because of their processing/release process (Fedora X never quite matched to RHEL Y even if there was some derivation), but yes, Fedora is absolutely the alpha for RHEL. It gets changes, including breaking changes, on a fast track (IIRC, Fedora frequently goes toe-to-toe with Arch for having the most recent packages), has a 13-month lifecycle with a strong expectation that you'll `dnf system-upgrade` regularly, and doesn't shy away from pushing on tech that they believe to be desirable even if it's not (yet) widely used (Wayland, BTRFS, CGroupsV2).
> Did you consider RHEL to be a beta for CentOS previously?
Now that's an interesting point that actually makes me stop and consider:) It is true that previously CentOS could legitimately claim to be even more stable/slow-moving than RHEL. I think the distinction that I would make is that RHEL had its own betas that were called betas, and that each point release was frozen/stable until the next one came along, while Stream is explicitly unfrozen all the time. So yes, I suppose a person could have described RHEL as CentOS's beta, although probably only jokingly because it still had Red Hat supporting it and feature freezes to control changes.
Funny to read this because Fedora is definitely beta, because their distribution doesn't seem very stable. I switched away from Fedora because it seemed to break more than my Arch installation. There are a lot of things they are doing that no other distros are doing right now. Cgroups v2, for instance.
The benefit of Fedora was that they handled a lot of things that were a pain to configure. The biggest culprit being fonts. But now that TrueType patents have expired, and it's included in Arch automatically it's one less reason to use Fedora.
Those are probably the users that RedHat is trying to nudge onto RHEL. "Enterprise" software is normally quite expensive, so the marginal cost of some RHEL Server licenses is probably a small fraction of the total cost of deploying the software in most cases.
More generally, orgs that are running "Enterprise" software are already set up to pay for software. Going from spending $X to spending $X+Y is often not a big deal ("Ok, I'll run that through the same process I used to get approval for buying FooSoftWorks"), while going from $0 to $Y can be very hard ("I don't even know who I'd need to ask to get purchase approval for that").
> Going from spending $X to spending $X+Y is often not a big deal
Except when $Y == $1000X. Then it really is a big deal.
When you only have a tiny minority of RHEL hosts that you have full support contracts on, and an overwhelming majority of CentOS hosts that you administer in-house, it really isn't trivial.
It's almost certainly cheaper to migrate to Oracle or Rocky. Migrations aren't cheap either.
Okay but I can't help but think about the social security in my country which I know runs likely to be more than hundreds of CentOS servers ... It's not like social security is a company making any profits, it's even the opposite, and now they are in such situation.
We are a smallish company with six CentOS 8 servers. Seems we fit into the profile of this new Developer program. To be honest, I can see us paying for full RHEL subscriptions before we would change distributions.
Go ahead and buy licenses as a show of support, but I strongly suggest that you exercise the converter scripts in both directions, partially to know what will cause them to fail, and partially to have an option when the vendor misbehaves.
Red Hat offers a "no support" server license for $350/year, which is the lowest licensing tier. Tiers with more capability and support are available for $800, and $1300.
Oracle has a larger range of tiers. The "no support" license is $120/year. Tiers with more capability and support are available for $500, $1200, $1400, and $2300.
Oracle Linux can be used in production without a paid license of any kind; Red Hat Linux cannot be used in this way for large deployments (excepting the new 16-seat license for a developer account).
Red Hat is aggressive with software audits; I have seen one.
Both Oracle and Red Hat now have complete toolsets to convert support between an installed CentOS/RedHat/Oracle OS.
Red Hat can now convert an installed CentOS or Oracle Linux to RHEL; previously a wipe and reinstall was required ("have fun reinstalling your system" is still on Oracle's CentOS site). The description looks much more thorough in replacing all possible packages with Red Hat versions:
When running "yum update" the packages are pulled from the registered repository, found in the /etc/yum.repos.d directory.
When switching the provider of package updates, the old repository must be disabled, and a new one substituted, among other changes that the new provider requires to switch support.
Oracle makes (by default) modest changes for such a switch. Red Hat essentially rewrites your whole operating system, and has added a warning that consultants should be retained for such conversions in case of trouble.
Take a look at Oracle's "CentOS to Oracle Linux" (and other similar) scripts to see how they work and what they do (sorry, I don't have a link handy as I'm on a mobile device at the moment).
If memory serves, the process consists of, basically, installing the <distro>-release package for the "new" distro (which includes the files in the /etc/yum.repos.d/ (or whatever) directory that defines the package repositories), enabling the repositories it just added, disabling the "old" distribution's repositories, then running a "yum update" to replace the "old" distributions packages (including the kernel) with the (nearly identical) ones from the "new" distribution. After all that is done, you reboot the host so that the new kernel is loaded and that's pretty much it.
Mostly out of curiosity, I tried out Oracle's "centos2ol.sh" (or something like that) script ~8 years ago on a new CentOS 6 VM I had set up for just that purpose and it was as easy as they claim that it is. I don't recall encountering any issues and I suspect that, by now, they've ran into most of the potential issues and have devised ways to resolve them automatically.
Note that while CentOS 8 is a clone of RHEL 8, the CentOS packages are rebuilt versions of the RHEL ones. Most of them are built from the exact same source code but some packages do have minor changes made to them before they are rebuilt (for trademarks, etc.).
It's easy enough to suggest "just use Rocky" but Rocky doesn't exist beyond a collective promise. What about production now, or in the next few months?
This seems more and more to be the reality we are moving towards. Been dabbling with FreeBSD lately and it just works. Also, ports are updated or new submitted quite often making it feel less out of date.
That's not a decision you make and then train staff + switch in a short time. At least not beyond trivial deployments. People used CentOS so they don't have to deal with this and they will have other less-extreme options before CentOS EOL.
As I remarked to a RH employee when the CentOS 8 discontinuation came out - do you have any idea how much trust you have to burn that people are considering Oracle as the good option?
What's the specific difference between Oracle and IBM/RedHat in this regard? As far as I can tell Oracle has burned a lot of people because they don't do license checks in their software (no DRM of any kind), which is usually what the HN crowd wants. But the flip side is they have to check you in some other way, leading to audits, and audits are very painful.
Is the difference that RHEL does subscription checks so they don't need to audit customers so much?
In terms of open source contributions, RH certainly do more, but Oracle are no slouch. They're doing actually exciting stuff with GraalVM and I don't really remember the last time I saw Red Hat do anything describable as research, their Java stewardship has been pretty responsible, they publish quite a lot of useful tools and stuff.
... you know, I had actually forgotten about that as an actual option. Yes, some people would probably be fine running Stream. I personally would avoid it because you're sacrificing stability by beta-testing Red Hat's software for them, but it is free, it is close to CentOS 8 (RIP), and it is likely to be good enough™ for many uses.
You could say the same about CentOS 8. There is no contract guaranteeing support-just a collective promise that was broken in a single day.
At the end of the day, you are looking for a free distro and this is what you can get. If you want a guarantee, pay for a contract. You have the right to sue if it is broken.
they didn't have this when they announced the death of centos. this is what they scrambled to come up with when they realized how much of an "oops" move messing with centos really was.
as a peace offering to prevent mindshare from fleeing the redhat ecosystem, i am underwhelmed. i don't think that redhat really realizes yet how cheesed off this made a lot of people.
being shrewish about money is one thing; we can deal with that (see: oracle, IBM). it's really the complete unpredictability and how arrogantly hamfisted this centos debacle was. I can put up with a lot of shit in my job, but what i especially don't like or need is more unreliable unpredictable shit.
Scientific Linux (sponsored by Fermilab) is a CentOS-like rebuild of RedHat Enterprise Linux and might also be worth a look. https://scientificlinux.org/
>CERN and Fermilab acknowledge the recent decision to shift focus from CentOS Linux to CentOS Stream, and the sudden change of the end of life of the CentOS 8 release. This may entail significant consequences for the worldwide particle physics community. We are currently investigating together the best path forward. We will keep you informed about any developments in this area during Q1 2021.
What RedHat provides is an enormous development effort and an extremely long lived LTS platform. That doesn't come for free.
Many seem to want RHEL for free, but there are free alternatives. You can run: Debian, Ubuntu or Slackware, if the cost is such a huge issue.
I won't argue that RedHat has handled the change to CentOS in a good way, they clearly haven't. On the other hand I don't free sorry for those companies how want all the benefits provided by RedHat, but not pay to keeping RedHat in business. Open source isn't about free, it's about giving you the option to make changes to the code yourself, or pay others to do it for you. RedHat would like to get paid for their work, if you don't want to do that, that's fine to, but then you need to do the work yourself.
There has been a freely downloadable Red Hat available for the past 20 years, either in the form of CentOS, or before it good old classic Red Hat Linux. That got them this far, where they are now. So you can understand how people feel bit miffed, especially now that they have Big Blue backing them they should be financially more stable than before.
I can certainly understand people being "miffed", but that was a risk when choosing to base your infrastructure on RedHat. Again the handling was extremely poor. Had they announced this new program along with the changes to CentOS, I don't think as many would have been upset.
But gambling that a for profit company will always provide you with a free alternative to they commercial offering is a calculated risk. In this case it might not have paid of.
I mean although this sounds like an absolutely outlandish ask for a company this was very literally what we had with CentOS so I'm surprised at all the comments saying it's impossible.
For context, CentOS was a popular Linux distro that tracked RHEL, being mostly identical except for not requiring a support package. Red Hat stopped supporting it, which put a lot of its users in a bind. This is intended to replace it.
Red Hat Enterprise Linux. RHEL is a stable platform for businesses to run their apps on; they port upstream code fixes to their kernel and distribution and offer support for a price.
Now that Centos and RHEL will no longer be in lockstep, some people are looking for alternatives. The upgrade from 1 RHEL license to 16 is a way for Red Hat to try and retain small projects and let home labbers and evangelists legally replace Centos rather than switch.
That is an interesting move. But with more and more organizations moving to dockerized services the real servers operating system is no longer that relevant.
I do know that rhel provides free access to a subset of rhel packages for docker image building but so many packages are missing that you can‘t reslly use it.
So next step for rhel, allowing dockerized rhel images would be nice. That is a real hurting point you created by your centos change!
As someone who started testing things with UBI images, I have found them to not be that great in terms of predicting how things behave installed under CentOS or RHEL. There are a lot of seemingly minor packaging differences that cause annoying issues when you go to deploy the same stuff on a real RHEL box.
As someone not running these small to medium sized businesses, this is an honest question. I quickly looked at the pricing for RHEL. It didn't seem outlandish. Can anyone comment on this?
Its really not especially compared to Microsoft or even IBM itself. My problem has been really crappy ability of Red Hat to answer any questions and the general friction of the purchase.
They seem to have some company blindness about answering specific technical pre-sale questions with "I will have X call you." and that call never ever comes. So the next person calls you and you ask again and the cycle repeats.
They are another company that likes you to go through partners and some of their partners aren't exactly quick about it.
It seems reasonable to me, I could sell management on the value of paying it. I would like to hear more from people with experience with Red Hat support.
Until they change their minds in a few months/years.
I really wish they would just go 100% paid and stop pretending they care about anything free at this point.
RH isn't the company that it once was anymore.
Edit: I'm sure this is not a popular opinion but it is what it is.
>I really wish they would just go 100% paid and stop pretending they care about anything open/free at this point.
As a Red Hat employee for ~5 years, every line of code I've ever written professionally has been open source and licensed under the GPL. The same is generally true across the entire company (with the exception of contributions to external projects licensed Apache / MIT / BSD).
Can you explain what you mean by "open/free"? Perhaps "free beer" rather than "freedom"?
>Can you explain what you mean by "open/free"? Perhaps "free beer" rather than "freedom"?
You installed 16 systems and a half year later RH says, and in 1 year you have to pay for these or change to CentOS Stream, i think it's a very founded consideration after the CentOS debacle.
But not sure what he means that RH does not care about Opensource...
That was more a nod to the whole CentOS debacle and the way RH is doing business the last few years, plus this article relating to the free part. Not really related to opensource as i doubt they'll be able to escape that aspect, if they could they would have probably done that already as well.
To be honest it broke my heart a bit when they where sold to IBM. But hey there is SLES and in my opinion a much better option with the free tumbleweed, leap and the paid SLES and all the free services like OBS, openQA and Kiwi....and no i don't use BTRF...XFS all the way down ;) But if i have the freedom to choose the solution it nearly always choose is FreeBSD, one exception...OracleDB where i use OracleLinux.
Licensed under the GPL is one thing -- intentionally obfuscated to make actual compilation difficult is compatible in letter but not in spirit of the license. Red Hat's citizenship in the FLOSS community varies from "savior" to "nuisance" depending on the project...
I have been a Red hat employee for more than 8 years and we never ever intentionally made projects difficult to consume by users outside of RH. More people using the open source projects works better for us as it provides free mind share, testing and feedback. For RH selling subscription for a popular/stable open source project is a way easier problem than a project which has no mind share. That being said sometimes it is very difficult to maintain projects and branches for external contribution depending upon the scope of project and the development workflow we use for it. It is very common scene in open source projects where contributors does not maintain the documentation etc properly for easy on boarding. I can go on for long time why it is not easy to do and we should improve on it for sure.
Percent-wise I don't think there is any other company that contributes as much to open source software, I do think it was a dick move from them but let's not conflate the things.
My comment wasn't really related to opensource, but in general to their new way of doing business.
Nothing wrong with changing the company's direction and trying to go full profit mode, just don't try to pretend everything's the same as before.
The change in company culture is probably real. Just an anecdata but I feel like over the years radhatters are behaving more and more corporatish compared with how it was years ago, then again that can be just the "climate" of the Internet nowadays.
Hey, I like that I can play around with RHEL without too much of a hassle.
Nevertheless for me that is not a replacement for what CentOS was: easy to deploy for small or personal projects without requiring registration/sign-up and you could leave it (mostly) alone for 10 years or so. Though for now I'm fairly happy with CentOS Stream, we'll see where it goes.
> Additionally the length of support, Ubuntu LTS gets close but RHEL will sell you support FOREVER.
A question is whether that is truly positive. A long cycle means that each update becomes a project in itself disrupting whatever else you are doing. (After 10 years so many things changed everywhere, that you need to bring so many things together ...) With frequent updates it is part of the ongoing process.
(And yes, there are cases for which one can make an argument)
There's absolutely an argument that, for many companies, if you're dependent on a long-term stable release for everything (especially in the absence of actual paid support) you're probably doing it wrong.
I am not a linux guy but had the same question and found out by googling a bit that it was because of software support. Major Linux vendors support only enterprise distros (like Redhat, CentOS and Suse)
in my experience, systems such as Debian and Gentoo for servers have an entirely different market than RHEL, z/OS or SUSE: the former seems to be more so used by i.t. companies themselves that of course also need to run an i.t. infrastructure, and the latter more so by companies whose primary services are not i.t., but that need such infrastructure nonetheless.
Looking at Red Hat's customer list, most of them are based in finance, transportation, retail, hotel, and other such sectors.
Looking at Debian's statistics of use per sector, the plurality is companies that develop computer software, though retail comes second, but after that it's i.t. again.
This is primarily the difference and the gap that RHEL attempts to bridge through it's extensive inclusive support, which is what one is really paying for. The target of RHEL has never been i.t. companies.
RHEL documentation is second-to-none. It's akin to old UNIX documentation, or the pre-10 offerings from Microsoft.
As an example, I wanted to set up kerberos. Red Hat had a guide on setting up IdM, covering every step in the process, often with two alternates depending on desired final state and having an intro paragraph to choose between them, full command line docs for every command ran, steps to test this was ran correctly, and troubleshooting steps for commonly-encountered errors. In contrast, the Ubuntu docs for setting up a IdM client were a wiki, half of which was for the old version, and a detailed stackoverflow response. Server and client setups took the same amount of time; the client should have been much faster.
Last i checked (2 years ago), when it comes to linux, Oracle Database officially supported only RHEL and OEL. I don’t think CentOS ever made it to the various support matrices, although of course its close compatibility with RHEL meant it likely worked just fine.
Other then what has been already mentioned (chiefly commercial 3rd party software support), I enjoyed the set-up time. Now there are better provisioning methods, particularly when setting up hundreds of hosts, but when doing it naïvely for a single or few hosts using the interactive installation software, I preferred RedHat/CentOS. That got me to a booting system in some ten, fifteen minutes, while the dreaded installation in Debian used to take easily 1.5h. Once installed, I found Debian easier to maintain and upgrade in place, but initial installation was a time-sink for many years.
To also comment here: every red hat system boots from dracut. There's no separate PXE for netboot: provisioning is consistent whether your boot medium is local, LAN, or ephemeral. It ships netboot-capable out of the box, and this is huge.
1. SELinux. It's configured for all packages in RHEL distribution and it works. It's an additional layer of defense and think that's the most important denominator from other Linux distributions. I saw recent Ubuntu distributions shipped with AppArmor, but I'm not sure that it's as good.
2. First-class support for systemd. Well, I'm not sure that's a fair point.. But with Debian I'm always seeing some messages about sysv scripts, even when I'm using systemctl. It feels like some scripts were not fully ported to systemd or something like that. Some people don't like systemd, but I, personally, think that it's a good solution. AFAIK systemd development is sponsored by Redhat and its support is very good, all services are shipped with proper systemd units.
3. First-class support for NetworkManager, Firewalld. I think that those packages are available for Debian, but it's nice to have them installed and configured from the start, they're very convenient to use.
4. Documentation. Most of that documentation is hidden behind loginwall, but http://access.redhat.com/ contains plenty of information.
There are some drawbacks of RHEL. The major one for me is limited software selection. You need to enable EPEL even for some basic software like Strongswan, Certbot or OpenDKIM. And EPEL is not RHEL (although it's quite good).
For anyone who might be interested in Fedora-family, namely systemd, SELinux, and firewalld bits I am writing a book now about deploying with Fedora and CentOS Stream[0] and I am almost finished. With this announcement I might add RHEL support directly - the difference is just in running a subscription manager.
Also, if you are using Vagrant, you can use RHEL with a vagrant-registration plugin that automatically subscribe you (disclaimer: I made the plugin when working for Red Hat and packaging Vagrant for Fedora).
I've gone back and forth on selinux (and a bunch of other in-house stuff that RHEL makes). Yes, it has improved over the years, but it still breaks a lot. The thing with RHEL is that you really need to be paying for the support to get any value out of it. With CentOS or this beggar subscription level, you are better off using Debian or Ubuntu, because when shit breaks, all you'll do is create a bug report in any OS. With Debian or Ubuntu, you have a slightly better chance at recovery. RHEL has a strict demarcation between support levels, features, release timelines, etc. So if you report a bug to RHEL, they may not backport the fix even if it fixed upstream. And then you are just stuck.
> RHEL has a strict demarcation between support levels, features, release timelines, etc. So if you report a bug to RHEL, they may not backport the fix even if it fixed upstream. And then you are just stuck.
This is changing with CentOS Stream. Bugs can be filed against CentOS Stream in the Red Hat Bugzilla and they will do something with that bug report. Additionally, if you know what to backport to fix it, you can submit pull requests on any package in CentOS Stream to have it reviewed and merged to fix your issue. The fix would then be built and released within days of merging your fix.
From my perspective, that's pretty golden for an Enterprise Linux platform. The only other that's like that is openSUSE Leap/SUSE Linux Enterprise.
Stream is a bit closer than Fedora, but the larger point of needing paid support remains. The slow cadence of RHEL means that unless you are paying for support, things get kind of frozen around the .5 release. After that, they just won't backport fixes, not even regressions, unless a) You are paying, b) It's really a critical security bug. I don't think that will change with Stream.
To summarize, the RHEL model of releasing an OS every 5 years with these staggered upstreams is really not that great. It creates immense inertia and pain down the road. RedHat itself hasn't been able to port its own offerings like Satellite to RHEL 8. I would rather have the Ubuntu cadence of LTS releases every 2 years so that you are at most 2 years away from any fixes you need.
The big difference to me is that Red Hat family distros have been a lot better suited to managing a large fleet of servers that I want to treat as cattle, not pets. I've finally managed to get away from Debian derivatives a few years back, but here are some specific complaints I can remember from my last job, managing about 1k Ubuntu servers.
- Installing a package on RH is always non-interactive. To install packages reliably on Ubuntu, we had to set three separate "Please just install the package, don't try to ask questions" options for different layers of the stack, and still occasionally ran into buggy packages that would hang the installation waiting for a nonexistent user to type something.
- On RH, when I try to install or upgrade an RPM that's missing dependencies, it gives me an error and refuses to break my system unless I specify --force. With debian, there's no way to query "Are the dependencies for this .deb satisfied" that I could ever find, and "dpkg -i foo.deb" will instead leave it "half-installed", and your package database is broken until you manually fix it.
- I really missed an equivalent of `rpm -V` (list files in an installed RPM that have been modified since installation). Asking Google now, I see that there's `debsums` which can handle some of this; I don't recall whether I failed to find that before, or if there was some other reason I didn't use it at the time.
- On RH, automated installation with kickstart is fantastic and comprehensive. It's well-documented, and has just worked for every configuration I've thrown at it. Debian's preseed is severely under-documented, and many combinations of features are just unimplemented and silently didn't work. For example, you can reserve unallocated disk space from a raw partition, but that's ignored for LVM, so to keep space free for snapshots in my volume group, I had to configure a "delete_me" volume, and then later delete it.
- Red Hat's SELinux support is fantastic. Ubuntu's choice of apparmor and deficient SELinux support has been annoying.
- I've personally found Red Hat's packages to be higher-quality. The biggest defect I remember finding in Ubuntu's repos was a service whose init script was literally copied from Red Hat, which didn't work, as it tried to source a file of init script utility functions which doesn't exist on Ubuntu, among other issues.
- Red Hat's documentation is fantastic. Ubuntu's documentation is, uh... sometimes present.
- I've found building RPMs to be much simpler and much-better-documented than the process of building debian packages. I vaguely remember being repeatedly frustrated at debian packaging that felt like "this magic thing just interferes and does special stuff when this case is detected", vs RPM's "it just does what the spec file says to do", but I can't remember any details or examples.
- I've had a much easier time building yum repositories than building debian repositories. Just dump a bunch of RPMs in a directory, run createrepo, serve over HTTP. I failed to find something similarly-simple for apt repos.
- Red Hat family had systemd way earlier, and with way better support and integration, than Debian family. While I do agree that there are some implementation issues with systemd, it's been a huge usability and quality-of-life improvement for me professionally.
To me, Debian has always felt like it's designed for someone administering a small number of long-lived pets with a variety of special circumstances, which really isn't what I want professionally. Red Hat has felt like it's engineered for use-cases I care about.
Last workplace had a storage array. Tested on Red Hat, supported on Red Hat. The same is true for lots of other things. Enterprise databases, drivers for hardware, CAD software, that sort of stuff.
Once you have it in place, you are guaranteed not to have to change it a decade. All security fixes is backported. They also vet upstream changes to minimize nasty surprises. You do pay handsomely for the privilege.
The production licenses for RHEL are certainly expensive, but it's not my job to decide whether they are worth it. My job is to develop and ship software to customers that used to run Ubuntu, CentOS, and sometimes RHEL. To compile/build/package that software we use docker containers, which provide nice isolation and hygiene and also guarantee user-space ABI compatibility to the target system. What I'd like to know: How can I user containers to develop for RHEL now? Is there some "short-lived" clause I could depend on or do I have to buy a license for every container I might want to spin up?
No, the Red Hat Universal Base Images and all associated content can be used for development and deployment without the need for a Red Hat subscription. However, for a fully supported operational experience and access to an expanded list of non-UBI tools, containers built on UBI must be deployed on a Red Hat platform such as OpenShift or RHEL.
Accessing non-UBI content does require a Red Hat subscription.
Red Hat offers a "no support" server license for $350/year, which is the lowest licensing tier. Tiers with more capability and support are available for $800, and $1300.
Oracle has a larger range of tiers. The "no support" license is $120/year. Tiers with more capability and support are available for $500, $1200, $1400, and $2300.
Oracle Linux can be used in production without a paid license of any kind; Red Hat Linux cannot be used in this way for large deployments (excepting the new 16-seat license for a developer account).
Red Hat is aggressive with software audits; I have seen one.
Both Oracle and Red Hat now have complete toolsets to convert support between an installed CentOS/RedHat/Oracle OS.
Red Hat can now convert an installed CentOS or Oracle Linux to RHEL; previously a wipe and reinstall was required ("have fun reinstalling your system" is still on Oracle's CentOS site). The description looks much more thorough in replacing all possible packages with Red Hat versions:
Red Hat has terminated two major platforms over the last two decades - the original Red Hat Linux, which was terminated at v9, and now CentOS.
Oracle has "somewhat" terminated a platform, Oracle Linux for SPARC, which was only supported for two minor releases. The Linux for ARM64 and AMD64/x86 seem reasonably healthy.
There is other baggage in and between these corporations, but the track record on Linux OS platforms between these two is demonstrably different.
>Oracle has "somewhat" terminated a platform, Oracle Linux for SPARC, which was only supported for two minor releases. The Linux for ARM64 and AMD64/x86 seem reasonably healthy.
You're forgetting:
* They killed OpenSolaris by making it proprietary again
* They effectively killed Solaris (formerly OpenSolaris) without the formality of making it official dtrace.org/blogs/bmc/2017/09/04/the-sudden-death-and-eternal-life-of-solaris/
> I will grant you that Solaris has contracted under Oracle.
Not to defend Oracle, but I am pretty sure all proprietary unix have contracted over the last 10 years. AIX, HP-UX and whatever other flavors don't seem to be doing well regardless of who is controlling it. If Sun remained in control I am not sure how much better Solaris would actually be doing.
My previous employer from 2017 was paying around $68 per license from Red Hat and it didn't include support. It wasn't a massive volume deal either, had less than 50 RHEL servers in the environment.
We shifted a bunch of Red Hat licenses to a hosting provider, and Red Hat auditors showed up.
Oracle does the same thing, but they don't care about OS licensing. One thing that they do care about is the extended support (RPM updates after end of life).
I have a SOX requirement that all of our corporate software is licensed.
For a license "in name only," either the $120 Oracle or $350 Red Hat tier will suffice.
I don't see the need to waste any more than $120 on support that I largely don't use. My Oracle Linux licenses expired several years ago, and I don't see any point in renewing them.
I have had to use alternate Oracle CSI support to fix some of their own self-inflicted brain damage. Oracle managed to disable microcode updates in the UEKR4, killing spectre/meltdown remediation. They would not listen to me on the forums, and insisted that I file an SR, so I used a general corporate CSI to get that fixed (and it still took several months).
I think they will come to regret this move in the long run. With Amazon signing up to sponsor rocky linux, it's only a matter of time before the user base moves there vs. dealing with all the headaches of "free" RHEL.
Especially given that they won't make any commitments to long term availability beyond "we have no intent".
16 servers in a data center is probably a medium sized business, if not a larger small business that does zero virtualization. 16 servers in the cloud that are rightly sized sounds incredibly small.
I can't imagine this will sell many people much less attract former CentOS users. Given the fact that they've changed course so quickly on CentOS stream I can't imagine there's much good user faith to go around.
To me, this was much bigger than just a shot in the foot.
i've got more than 16 "right-sized" VMs on the VMware cluster in my homelab. Between the other half-dozen physical servers, there's probably another 40+ "OS instances".
Besides, I've had a RHEL developer account (which allowed me to register 16 hosts) for a few years now and it's been unused. Having to request it be renewed annually is a pain in the ass too.
meh if you don't want to use centos stream then I would just switch to openSUSE Leap. Zypper is very similar to yum/dnf, so it's not like your switching to apt/apt-get or alpine apk and learning completely different package manager.
Thumbs up for OpenSUSE, RH should have taken an example from how closely SUSE operates with the community, sadly I think Red Hat is too big and too corporate to give a damn now.
I would say they are the same (LEAP and Centos (not stream)), you can change instantly to SLES if you need too. Leap15 = SLES15, Leap15.1 = SLES15sp1 and so on.
Yeah, I'm not running anything with some weird contingent license if I'm running Linux. Completely defeats the purpose. Also, now more than ever, after last month's big hacks I think building things from source makes more sense.
I'll be sticking with gentoo for my mission-critical bare metal installs when I need Linux.
I would not trust the community of volunteers that maintain Gentoo in their free time for anything mission critical. I would use Ubuntu or Red Hat, which are backed by companies.
I've got bad news for you - most of Ubuntu is repackaged Debian which is from a community of volunteers that maintains the packages. Besides that Ubuntu used to be sloppy in backporting important patches and doing some NIH here and there... not sure about Redhat but they source heavily from Fedora which is also community-based.
It doesn’t matter that Ubuntu packages originally came from Debian. At the end of the day, Canonical employees are being paid to make sure they are up to date. I trust that over a bunch of volunteers who do it out of the goodness of their heart.
I’m not sure I can agree with this concern. All Linux distros work by repackaging upstream code, the majority of which is written by volunteers. For Debian, they’re repackaging directly from upstream. Ubuntu repackages from Debian.
The value of going through a company is that you can choose to write a check to Canonical or RedHat and say “I’m hitting this issue with the software you repackaged, here is money, fix the problem”. There’s no similarly direct pay-to-win for Fedora or Debian. You can shop around for a consultancy or engineer and pay them to try to debug the issue, but they’re always going to be coming in as a 3rd party, which has an impact on the levers they can pull to resolve an issue.
Most Linux software is written by Red Hat. GNOME, Wayland, and systemd are all Red Hat projects. They are even a major contributor to the kernel itself.
> Most Linux software is written by Red Hat.. even a major contributor to the kernel itself.
Oh! I didn't realize Red Hat had hired RMS. :-/
Setting aside the controversial nature of those three specific projects (and the fact that this statement is demonstrably false), this statement demeans the contributions of thousands of coders, even from before Linux existed.
(let alone before Red Hat was a gleam on Bob Young's head.)
It's not a concern but just an observation that things in universe in Ubuntu get rarely if at all backports. It's okay. I agree about having a company especially regarding timely security updates.
Red Hat sponsors Fedora big time. I was part of the packagers team for Ruby. Next to us were sitting Perl guys (you would never believe how many Perl packages are still there...!) and somewhere else folks doing Python packaging.
Source: Formal Red Hat packager working on Fedora.
That just shows a lack of knowledge of the quantinty of commercial OSes available out there.
Were are the volunteers for Sony and Nintendo console OSes, Android, ChromeOS, Fuchsia, IBM i, IBM z/OS, INTEGRITY, QNX,Unisys ClearPath, Solaris, HP-UX, Aix, vxWorks.....?
If a developer gets a hold of a RHEL copy[legally] regardless of its subscriptions terms, he have all the rights to re-distribute it due to the nature of GPL2 licensing, only thing is he cannot claim to be IP/copyright owner of redhat assets like logo.
Red Hat has provided free RHEL downloads and licences for development use through their developer programme for nearly five years now. They do require that you sign up for an account on their website.
Cmon, drop the requirement to activate it with an account already, what year is this? No one is going to use this over Ubuntu, even if it is free, if there’s that extra step in there.
I'd love to support RHEL financially, both on the server and on the development laptop. But I just don't trust that any of this extra cash flow they may see will go towards anything but 5% IBM dividends, obscene executive and sales salaries, with nothing left over for R&D and especially continued American jobs (IBM is basically an Indian company, now).
I hope my large government customers ditch RHEL for something else - maybe a derivative that's home grown.
267 comments
[ 16.0 ms ] story [ 836 ms ] thread> When we announced our intent to transition to CentOS Stream, we did so with a plan to create new programs to address use cases traditionally served by CentOS Linux.
This is a load of bullshit. If that was their plan they would have announced both of these changes together. It's not like they were under time pressure to get the announcement out.
I work for Red Hat, opinions are my own, etc. I don't know why they decided to announce the CentOS plans before announcing at least some of the expanded RHEL offerings, and many people are just as confused as myself. However, whatever the reason was, it's absolutely true that expanding access to no-cost and low-cost RHEL was always the plan, and the original announcement effectively stated as much.
I also have no doubts they wanted to see how much bad PR the announcment made before figuring out that those expanded options where
It was from be beginning a Monetary Grab, Redhat did a global scream test to see how much they would have to give away to take the screams down to a dull roar and stop the bleeding just enough to not lose any market share
They have landed on 16 as the magic number for now, but like the OP I have visions of Darth Vader saying “I am altering the deal. Pray I don't alter it any further.” while wearing a RedHat
It does not fill me with confidence that I should make use of that 16 server license...
It's obvious in retrospect that their intention was to pull this when they acquired the CentOS project - plotting to turn CentOS into a RHEL on-ramp while dressing it as an embrace of the community feels like a kick in the groin.
Also, 16 servers is barely enough for tech companies caught by this, and is less of a good will gesture, and more subscription growth hacking.
That's the cost of building a product on GPL2 licensed software.
The CentOS project itself wasn't started by Red Hat. It was given to them with the expectation that they would be good stewards of it. In killing its core mission, they haven't been.
EDIT: Clarify sentence.
Are you claiming they are in violation of the GPL license? I believe they still are 100% in compliance.
> The CentOS project itself wasn't started by Red Hat. It was given to them with the expectation that they would be good stewards of it. They haven't.
They stepped in to stewardship of the product quite naturally, with the full backing of the previous stewards. Nobody was forced into that agreement. It wasn't given to them as a gift, Red Hat has sponsored the project for the last 6+ years. The fact that you disagree with the direction it has since gone, does not mean it's wrong. It may be the difference between having something more modest, and having nothing at all.
And if you want something closer to the original CentOS check out:
https://rockylinux.org/
Which was created by the CentOS founder.
I'm not, they are indeed compliant, and Red Hat is not obligated to directly maintain CentOS. They are only obligated to provide the source to customers under the terms of the GPL.
However, if Red Hat no longer wants to maintain CentOS in the spirit in which it was founded and taken over, I'd argue the ethical thing to do would be to spin the project back out of Red Hat.
>That's the cost of building a product on GPL2 licensed software.
You are only entitled to the GPL code if it is distributed to you (as in you are a customer).
Like... sorta? On the other hand, they went on the record saying that they would support CentOS 8 through 2029 [0], so I think it's reasonable to be unhappy with them for going back on that even in the absence of a monetary relationship.
[0] https://web.archive.org/web/20201101131417/https://wiki.cent...
So while this is disruptive and bound to be upsetting, Red Hat are still being quite generous with their new offerings. And as far as I know, they are not standing in the way of CentOS replacements such as Rocky[0] or Lenix[1].
[0] https://rockylinux.org/ [1] https://www.projectlenix.org/
Once the unfortunate decision was made to shut down CentOS, it would be very nice if the public outrage was tempered with a little appreciation for the 6 years of support that Red Hat gave to it, and also an appreciation for the new options for free access to RHEL they are providing.
People seem awfully entitled in their outrage.
Second, this is only of value to the teeny tiny companies and individual users with a single server in their home. Small companies with any expectation of growth should probably just use Rocky instead from the get go.
I have a single server in my home running CentOS 7. I gain nothing by using RHEL over Rocky in the future, except with RHEL I have to accept ToS, do some subscription checks, and run the risk that Red Hat cancels this programme down the road. I only see this of value for someone who actually runs real RHEL in prod, and needs to test/validate hardware/software. For anyone just wanting 'free' RHEL, they should just use Rocky.
> First, they should have announced this when they killed CentOS.
I agree.
>Second, this is only of value to the teeny tiny companies and individual users with a single server in their home. Small companies with any expectation of growth should probably just use Rocky instead from the get go.
Without saying too much - stay tuned for further announcements.
It doesn't matter much to me anymore, I've already migrated my small business internal server that was running Centos 7 to Debian. We had basically just a fileserver, FTP box, and a couple VMs for some time clock, wiki, and building security systems, so nothing we were running yet was CentOS specific.
But in case it can be useful to you, please share with your team that the writing they're putting on the wall looks pretty bad. Knowing I'd have to update eventually, I just took the safe option, which is no longer any distro controlled by Red Hat. I didn't want to leave our server in a state where we could be building dependencies on a platform that was likely to be pulled out from under us, and while RHEL isn't too expensive to just buy for one server, and we might have qualified for something free or something you've not yet announced, my test was surprisingly painless and the migration was easier than I anticipated.
RedHat seems to forget the for the majority of CentOS users STABLITY was the driving factor in the choice to use CentOS.
I am not sure what internal metrics they have, or if I am missing a glaring use case somewhere but from where I sit RedHat seems to completely miss the boat as to who is using CentOS in the real world.
I want STABLE UNCHANGING SECURE systems, not the latest and greatest features, or some new shiny "cloudy" technology...
When your house is on fire, and you have a very short time to save your prized possessions, haste easily leads to observable contradictory actions.
The need to expand the developer program into production seats could not have been anticipated.
I don't know of any other vendor that wraps developer accounts into production licenses.
Notice that this access is in no way promised to the end of support for RHEL 8.
I will say again, Red Hat has terminated two major Linux platforms over the last two decades - the original Red Hat Linux, which was terminated at v9, and now CentOS.
Oracle has "somewhat" terminated a Linux platform, Oracle Linux for SPARC, which was only supported for two minor releases. Oracle Linux for ARM64 and AMD64/x86 seem reasonably healthy.
There is other baggage in and between these corporations, but the track record on Linux OS platforms between these two is demonstrably different.
The free converters between them should be used fluidly.
I don't follow. Are you suggesting that RH actually didn't realize that people were running CentOS at scale in production?
I might be misreading these motivations.
With this management perspective, the CentOS community reaction to the retraction of the end of life date, and potential reduction in stability, was likely not anticipated.
CentOS streams is literally RHEL with fixed major version and rolling minor versions. So, in the past, you got CentOS 7.1, then 7.2, etc., with streams, you get CentOS 8.x.
Saying that this is moving away from RHEL stability sounds highly disingenuous. Are you saying you've seen RHEL 7.X to break as opposed to 7.(X-1) version, and your solution was to wait for RHEL 7.(X+1)?
Are we not reading this correctly? If not, could you get Red Hat's CTO to retract this [mis]information?
'Another official part of it is, as [Chris] Wright [RedHat CTO] said, is that CentOS Stream as a "rolling preview" of what's next in RHEL, both in terms of kernels and features can be used in today's containerized, cloud-native IT world.'
https://www.zdnet.com/article/why-red-hat-dumped-centos-for-...
> Saying that this is moving away from RHEL stability sounds highly disingenuous.
If it were so great, they'd do the same for paying customers. That they don't move RHEL to being just 8.X makes me think that Red Hat does in fact understand that that undermines the stability of the platform.
It’s funny how everyone still says Red Hat when we mean IBM.
It's a horrible way to treat users.
They aren't paying customers, so whatever for RH short-term bottom line. But amount of community backslash approach like that is bringing can have negative long term impact.
RH pulled the rug from under the people, and is telling them to stay tuned. I wouldn't base my infra on a system like that.
But that's good for overall Linux community - RH has way too much power there.
It probably wont be completely broken and useless, but they replaced a stable OS with a beta, which is particularly galling to many users who picked that OS specifically because it was so stable.
Just trying to see how you define "beta"
The point is that with CentOS you expect a super stable release. Red Hat replaced that with what is clearly a less stable project. And as was said before, if you used CentOS, it's probably precisely because you want something super stable with long term support. Those are not the sorts of users who'll want to use Stream.
CentOS Stream seems like "Fedora, again" and does not do what CentOS did. And now, the willingness to blow up CentOS with so little warning means there is a massive trust deficit here.
Slightly detached because of their processing/release process (Fedora X never quite matched to RHEL Y even if there was some derivation), but yes, Fedora is absolutely the alpha for RHEL. It gets changes, including breaking changes, on a fast track (IIRC, Fedora frequently goes toe-to-toe with Arch for having the most recent packages), has a 13-month lifecycle with a strong expectation that you'll `dnf system-upgrade` regularly, and doesn't shy away from pushing on tech that they believe to be desirable even if it's not (yet) widely used (Wayland, BTRFS, CGroupsV2).
> Did you consider RHEL to be a beta for CentOS previously?
Now that's an interesting point that actually makes me stop and consider:) It is true that previously CentOS could legitimately claim to be even more stable/slow-moving than RHEL. I think the distinction that I would make is that RHEL had its own betas that were called betas, and that each point release was frozen/stable until the next one came along, while Stream is explicitly unfrozen all the time. So yes, I suppose a person could have described RHEL as CentOS's beta, although probably only jokingly because it still had Red Hat supporting it and feature freezes to control changes.
The benefit of Fedora was that they handled a lot of things that were a pain to configure. The biggest culprit being fonts. But now that TrueType patents have expired, and it's included in Arch automatically it's one less reason to use Fedora.
More generally, orgs that are running "Enterprise" software are already set up to pay for software. Going from spending $X to spending $X+Y is often not a big deal ("Ok, I'll run that through the same process I used to get approval for buying FooSoftWorks"), while going from $0 to $Y can be very hard ("I don't even know who I'd need to ask to get purchase approval for that").
Except when $Y == $1000X. Then it really is a big deal.
When you only have a tiny minority of RHEL hosts that you have full support contracts on, and an overwhelming majority of CentOS hosts that you administer in-house, it really isn't trivial.
It's almost certainly cheaper to migrate to Oracle or Rocky. Migrations aren't cheap either.
Crucially, though, most entities who are running their own "enterprise" software deployments will need way more than 16 servers.
Small shops do use "enterprise" software, of course, but they usually just pay somebody else to run it for them.
Red Hat offers a "no support" server license for $350/year, which is the lowest licensing tier. Tiers with more capability and support are available for $800, and $1300.
https://www.redhat.com/en/store/red-hat-enterprise-linux-ser...
Oracle has a larger range of tiers. The "no support" license is $120/year. Tiers with more capability and support are available for $500, $1200, $1400, and $2300.
https://www.oracle.com/linux/
Oracle Linux can be used in production without a paid license of any kind; Red Hat Linux cannot be used in this way for large deployments (excepting the new 16-seat license for a developer account).
Red Hat is aggressive with software audits; I have seen one.
Both Oracle and Red Hat now have complete toolsets to convert support between an installed CentOS/RedHat/Oracle OS.
Red Hat can now convert an installed CentOS or Oracle Linux to RHEL; previously a wipe and reinstall was required ("have fun reinstalling your system" is still on Oracle's CentOS site). The description looks much more thorough in replacing all possible packages with Red Hat versions:
https://access.redhat.com/articles/2360841
Oracle does not replace CentOS or RedHat RPMs in their conversion (AFAIK), so it is much less violent on the platform changes.
https://github.com/oracle/centos2ol
https://linux.oracle.com/switch/centos/
https://blogs.oracle.com/linux/reasons-for-switching-centos-...
Apologies if a dumb question, but I assumed CentOS 8 was a clone of RHEL 8. What would change?
When switching the provider of package updates, the old repository must be disabled, and a new one substituted, among other changes that the new provider requires to switch support.
Oracle makes (by default) modest changes for such a switch. Red Hat essentially rewrites your whole operating system, and has added a warning that consultants should be retained for such conversions in case of trouble.
If memory serves, the process consists of, basically, installing the <distro>-release package for the "new" distro (which includes the files in the /etc/yum.repos.d/ (or whatever) directory that defines the package repositories), enabling the repositories it just added, disabling the "old" distribution's repositories, then running a "yum update" to replace the "old" distributions packages (including the kernel) with the (nearly identical) ones from the "new" distribution. After all that is done, you reboot the host so that the new kernel is loaded and that's pretty much it.
Mostly out of curiosity, I tried out Oracle's "centos2ol.sh" (or something like that) script ~8 years ago on a new CentOS 6 VM I had set up for just that purpose and it was as easy as they claim that it is. I don't recall encountering any issues and I suspect that, by now, they've ran into most of the potential issues and have devised ways to resolve them automatically.
Note that while CentOS 8 is a clone of RHEL 8, the CentOS packages are rebuilt versions of the RHEL ones. Most of them are built from the exact same source code but some packages do have minor changes made to them before they are rebuilt (for trademarks, etc.).
Pay for RHEL, use CentOS 7, or switch to Ubuntu.
Is the difference that RHEL does subscription checks so they don't need to audit customers so much?
In terms of open source contributions, RH certainly do more, but Oracle are no slouch. They're doing actually exciting stuff with GraalVM and I don't really remember the last time I saw Red Hat do anything describable as research, their Java stewardship has been pretty responsible, they publish quite a lot of useful tools and stuff.
i like oracle i need to pay the bills
[0] https://almalinux.org/
At the end of the day, you are looking for a free distro and this is what you can get. If you want a guarantee, pay for a contract. You have the right to sue if it is broken.
Edit: grammar.
as a peace offering to prevent mindshare from fleeing the redhat ecosystem, i am underwhelmed. i don't think that redhat really realizes yet how cheesed off this made a lot of people.
being shrewish about money is one thing; we can deal with that (see: oracle, IBM). it's really the complete unpredictability and how arrogantly hamfisted this centos debacle was. I can put up with a lot of shit in my job, but what i especially don't like or need is more unreliable unpredictable shit.
https://devops.com/centos-rebellion-against-red-hat-gains-mo...
https://www.infoworld.com/article/3601202/red-hats-crime-aga...
https://arstechnica.com/gadgets/2020/12/centos-linux-is-gone...
It’s possible they could choose to restart work on Scientific Linux, but nothing has been announced yet.
>CERN and Fermilab acknowledge the recent decision to shift focus from CentOS Linux to CentOS Stream, and the sudden change of the end of life of the CentOS 8 release. This may entail significant consequences for the worldwide particle physics community. We are currently investigating together the best path forward. We will keep you informed about any developments in this area during Q1 2021.
https://news.fnal.gov/2020/12/joint-cern-fermilab-statement-...
What RedHat provides is an enormous development effort and an extremely long lived LTS platform. That doesn't come for free.
Many seem to want RHEL for free, but there are free alternatives. You can run: Debian, Ubuntu or Slackware, if the cost is such a huge issue.
I won't argue that RedHat has handled the change to CentOS in a good way, they clearly haven't. On the other hand I don't free sorry for those companies how want all the benefits provided by RedHat, but not pay to keeping RedHat in business. Open source isn't about free, it's about giving you the option to make changes to the code yourself, or pay others to do it for you. RedHat would like to get paid for their work, if you don't want to do that, that's fine to, but then you need to do the work yourself.
But gambling that a for profit company will always provide you with a free alternative to they commercial offering is a calculated risk. In this case it might not have paid of.
For context, CentOS was a popular Linux distro that tracked RHEL, being mostly identical except for not requiring a support package. Red Hat stopped supporting it, which put a lot of its users in a bind. This is intended to replace it.
Now that Centos and RHEL will no longer be in lockstep, some people are looking for alternatives. The upgrade from 1 RHEL license to 16 is a way for Red Hat to try and retain small projects and let home labbers and evangelists legally replace Centos rather than switch.
https://www.servethehome.com/red-hat-goes-full-ibm-and-says-...
I'd still prefer CentOS lived, this is probably meant to keep people from grabbing pitchforks.
Doesn't engender a bunch of trust.
So next step for rhel, allowing dockerized rhel images would be nice. That is a real hurting point you created by your centos change!
Is that setup still 16 systems or do they count the number of virtual machines?
Btw. I did not check, it's possible it's based on number of CPUs or smth.
I don't really have a good rationale hah, but I was working for Red Hat and it could be cool to finally run my side project on RHEL.
They seem to have some company blindness about answering specific technical pre-sale questions with "I will have X call you." and that call never ever comes. So the next person calls you and you ask again and the cycle repeats.
They are another company that likes you to go through partners and some of their partners aren't exactly quick about it.
Edit: I'm sure this is not a popular opinion but it is what it is.
As a Red Hat employee for ~5 years, every line of code I've ever written professionally has been open source and licensed under the GPL. The same is generally true across the entire company (with the exception of contributions to external projects licensed Apache / MIT / BSD).
Can you explain what you mean by "open/free"? Perhaps "free beer" rather than "freedom"?
You installed 16 systems and a half year later RH says, and in 1 year you have to pay for these or change to CentOS Stream, i think it's a very founded consideration after the CentOS debacle.
But not sure what he means that RH does not care about Opensource...
Nevertheless for me that is not a replacement for what CentOS was: easy to deploy for small or personal projects without requiring registration/sign-up and you could leave it (mostly) alone for 10 years or so. Though for now I'm fairly happy with CentOS Stream, we'll see where it goes.
Additionally the length of support, Ubuntu LTS gets close but RHEL will sell you support FOREVER.
A question is whether that is truly positive. A long cycle means that each update becomes a project in itself disrupting whatever else you are doing. (After 10 years so many things changed everywhere, that you need to bring so many things together ...) With frequent updates it is part of the ongoing process.
(And yes, there are cases for which one can make an argument)
https://nvd.nist.gov/ncp/checklist/811
Looking at Red Hat's customer list, most of them are based in finance, transportation, retail, hotel, and other such sectors.
Looking at Debian's statistics of use per sector, the plurality is companies that develop computer software, though retail comes second, but after that it's i.t. again.
This is primarily the difference and the gap that RHEL attempts to bridge through it's extensive inclusive support, which is what one is really paying for. The target of RHEL has never been i.t. companies.
As an example, I wanted to set up kerberos. Red Hat had a guide on setting up IdM, covering every step in the process, often with two alternates depending on desired final state and having an intro paragraph to choose between them, full command line docs for every command ran, steps to test this was ran correctly, and troubleshooting steps for commonly-encountered errors. In contrast, the Ubuntu docs for setting up a IdM client were a wiki, half of which was for the old version, and a detailed stackoverflow response. Server and client setups took the same amount of time; the client should have been much faster.
I would at least say it is more consistent, without having a split between the man and info commands.
2. First-class support for systemd. Well, I'm not sure that's a fair point.. But with Debian I'm always seeing some messages about sysv scripts, even when I'm using systemctl. It feels like some scripts were not fully ported to systemd or something like that. Some people don't like systemd, but I, personally, think that it's a good solution. AFAIK systemd development is sponsored by Redhat and its support is very good, all services are shipped with proper systemd units.
3. First-class support for NetworkManager, Firewalld. I think that those packages are available for Debian, but it's nice to have them installed and configured from the start, they're very convenient to use.
4. Documentation. Most of that documentation is hidden behind loginwall, but http://access.redhat.com/ contains plenty of information.
There are some drawbacks of RHEL. The major one for me is limited software selection. You need to enable EPEL even for some basic software like Strongswan, Certbot or OpenDKIM. And EPEL is not RHEL (although it's quite good).
For anyone who might be interested in Fedora-family, namely systemd, SELinux, and firewalld bits I am writing a book now about deploying with Fedora and CentOS Stream[0] and I am almost finished. With this announcement I might add RHEL support directly - the difference is just in running a subscription manager.
Also, if you are using Vagrant, you can use RHEL with a vagrant-registration plugin that automatically subscribe you (disclaimer: I made the plugin when working for Red Hat and packaging Vagrant for Fedora).
[0] https://deploymentfromscratch.com/
This is changing with CentOS Stream. Bugs can be filed against CentOS Stream in the Red Hat Bugzilla and they will do something with that bug report. Additionally, if you know what to backport to fix it, you can submit pull requests on any package in CentOS Stream to have it reviewed and merged to fix your issue. The fix would then be built and released within days of merging your fix.
From my perspective, that's pretty golden for an Enterprise Linux platform. The only other that's like that is openSUSE Leap/SUSE Linux Enterprise.
To summarize, the RHEL model of releasing an OS every 5 years with these staggered upstreams is really not that great. It creates immense inertia and pain down the road. RedHat itself hasn't been able to port its own offerings like Satellite to RHEL 8. I would rather have the Ubuntu cadence of LTS releases every 2 years so that you are at most 2 years away from any fixes you need.
Matthew Miller (@mattdm) tweeted out the "Fedora->RHEL formula": https://twitter.com/mattdm/status/1349037318200561665
- Installing a package on RH is always non-interactive. To install packages reliably on Ubuntu, we had to set three separate "Please just install the package, don't try to ask questions" options for different layers of the stack, and still occasionally ran into buggy packages that would hang the installation waiting for a nonexistent user to type something.
- On RH, when I try to install or upgrade an RPM that's missing dependencies, it gives me an error and refuses to break my system unless I specify --force. With debian, there's no way to query "Are the dependencies for this .deb satisfied" that I could ever find, and "dpkg -i foo.deb" will instead leave it "half-installed", and your package database is broken until you manually fix it.
- I really missed an equivalent of `rpm -V` (list files in an installed RPM that have been modified since installation). Asking Google now, I see that there's `debsums` which can handle some of this; I don't recall whether I failed to find that before, or if there was some other reason I didn't use it at the time.
- On RH, automated installation with kickstart is fantastic and comprehensive. It's well-documented, and has just worked for every configuration I've thrown at it. Debian's preseed is severely under-documented, and many combinations of features are just unimplemented and silently didn't work. For example, you can reserve unallocated disk space from a raw partition, but that's ignored for LVM, so to keep space free for snapshots in my volume group, I had to configure a "delete_me" volume, and then later delete it.
- Red Hat's SELinux support is fantastic. Ubuntu's choice of apparmor and deficient SELinux support has been annoying.
- I've personally found Red Hat's packages to be higher-quality. The biggest defect I remember finding in Ubuntu's repos was a service whose init script was literally copied from Red Hat, which didn't work, as it tried to source a file of init script utility functions which doesn't exist on Ubuntu, among other issues.
- Red Hat's documentation is fantastic. Ubuntu's documentation is, uh... sometimes present.
- I've found building RPMs to be much simpler and much-better-documented than the process of building debian packages. I vaguely remember being repeatedly frustrated at debian packaging that felt like "this magic thing just interferes and does special stuff when this case is detected", vs RPM's "it just does what the spec file says to do", but I can't remember any details or examples.
- I've had a much easier time building yum repositories than building debian repositories. Just dump a bunch of RPMs in a directory, run createrepo, serve over HTTP. I failed to find something similarly-simple for apt repos.
- Red Hat family had systemd way earlier, and with way better support and integration, than Debian family. While I do agree that there are some implementation issues with systemd, it's been a huge usability and quality-of-life improvement for me professionally.
To me, Debian has always felt like it's designed for someone administering a small number of long-lived pets with a variety of special circumstances, which really isn't what I want professionally. Red Hat has felt like it's engineered for use-cases I care about.
Last workplace had a storage array. Tested on Red Hat, supported on Red Hat. The same is true for lots of other things. Enterprise databases, drivers for hardware, CAD software, that sort of stuff.
Once you have it in place, you are guaranteed not to have to change it a decade. All security fixes is backported. They also vet upstream changes to minimize nasty surprises. You do pay handsomely for the privilege.
https://www.redhat.com/en/blog/introducing-red-hat-universal...
https://developers.redhat.com/articles/ubi-faq#introduction
re: licensing, the FAQ says:
No, the Red Hat Universal Base Images and all associated content can be used for development and deployment without the need for a Red Hat subscription. However, for a fully supported operational experience and access to an expanded list of non-UBI tools, containers built on UBI must be deployed on a Red Hat platform such as OpenShift or RHEL.Accessing non-UBI content does require a Red Hat subscription.
https://www.redhat.com/en/store/red-hat-enterprise-linux-ser...
Oracle has a larger range of tiers. The "no support" license is $120/year. Tiers with more capability and support are available for $500, $1200, $1400, and $2300.
Oracle Linux can be used in production without a paid license of any kind; Red Hat Linux cannot be used in this way for large deployments (excepting the new 16-seat license for a developer account).
Red Hat is aggressive with software audits; I have seen one.
https://www.oracle.com/linux/
Both Oracle and Red Hat now have complete toolsets to convert support between an installed CentOS/RedHat/Oracle OS.
Red Hat can now convert an installed CentOS or Oracle Linux to RHEL; previously a wipe and reinstall was required ("have fun reinstalling your system" is still on Oracle's CentOS site). The description looks much more thorough in replacing all possible packages with Red Hat versions:
https://access.redhat.com/articles/2360841
Oracle does not replace CentOS or RedHat RPMs in their conversion (AFAIK), so it is much less violent on the platform changes.
https://github.com/oracle/centos2ol
https://linux.oracle.com/switch/centos/
https://blogs.oracle.com/linux/reasons-for-switching-centos-...
Red Hat has terminated two major platforms over the last two decades - the original Red Hat Linux, which was terminated at v9, and now CentOS.
Oracle has "somewhat" terminated a platform, Oracle Linux for SPARC, which was only supported for two minor releases. The Linux for ARM64 and AMD64/x86 seem reasonably healthy.
There is other baggage in and between these corporations, but the track record on Linux OS platforms between these two is demonstrably different.
You're forgetting:
* They killed OpenSolaris by making it proprietary again
* They effectively killed Solaris (formerly OpenSolaris) without the formality of making it official dtrace.org/blogs/bmc/2017/09/04/the-sudden-death-and-eternal-life-of-solaris/
However, there is a long list of platforms that would never have survived elsewhere. JD Edwards, Peoplesoft, and Siebel are prime examples.
And I am still using the Oracle RDB database platform.
Red Hat would have euthanized all of these long, long ago.
I do not consider it unfair.
Not to defend Oracle, but I am pretty sure all proprietary unix have contracted over the last 10 years. AIX, HP-UX and whatever other flavors don't seem to be doing well regardless of who is controlling it. If Sun remained in control I am not sure how much better Solaris would actually be doing.
Oracle does the same thing, but they don't care about OS licensing. One thing that they do care about is the extended support (RPM updates after end of life).
1. It clearly states "Not for Production" on the license
2. It says it can not be stacked with other license, I am not sure if that means you can only have this license and not others in the environment
3. the biggest is Physical hardware Only, no VM's.
> Oracle Linux can be used in production without a paid license of any kind
So... what offers this $120/year "no support" license when you can use it with no cost at all for production?
For a license "in name only," either the $120 Oracle or $350 Red Hat tier will suffice.
I don't see the need to waste any more than $120 on support that I largely don't use. My Oracle Linux licenses expired several years ago, and I don't see any point in renewing them.
I have had to use alternate Oracle CSI support to fix some of their own self-inflicted brain damage. Oracle managed to disable microcode updates in the UEKR4, killing spectre/meltdown remediation. They would not listen to me on the forums, and insisted that I file an SR, so I used a general corporate CSI to get that fixed (and it still took several months).
Especially given that they won't make any commitments to long term availability beyond "we have no intent".
https://arstechnica.com/gadgets/2021/01/centos-is-gone-but-r...
>We have no intent to end this program and we’ve set it up to be sustainable
https://rockylinux.org/
I can't imagine this will sell many people much less attract former CentOS users. Given the fact that they've changed course so quickly on CentOS stream I can't imagine there's much good user faith to go around.
To me, this was much bigger than just a shot in the foot.
Besides, I've had a RHEL developer account (which allowed me to register 16 hosts) for a few years now and it's been unused. Having to request it be renewed annually is a pain in the ass too.
1, OpenSUSE Leap cannot do full version upgrades 2, They use AppArmor instead of SELinux 3, Support is shorter than CentOS Stream[0]
[0] https://nts.strzibny.name/how-long-will-be-centos-stream-sup...
The value of going through a company is that you can choose to write a check to Canonical or RedHat and say “I’m hitting this issue with the software you repackaged, here is money, fix the problem”. There’s no similarly direct pay-to-win for Fedora or Debian. You can shop around for a consultancy or engineer and pay them to try to debug the issue, but they’re always going to be coming in as a 3rd party, which has an impact on the levers they can pull to resolve an issue.
Except for software that was written in-house or the packaging itself, RH or Canonical would also always be coming in as a third party.
... whereas your consultant might be the original author of the upstream code.
Oh! I didn't realize Red Hat had hired RMS. :-/
Setting aside the controversial nature of those three specific projects (and the fact that this statement is demonstrably false), this statement demeans the contributions of thousands of coders, even from before Linux existed.
(let alone before Red Hat was a gleam on Bob Young's head.)
https://www.debian.org/consultants/
Source: Formal Red Hat packager working on Fedora.
Were are the volunteers for Sony and Nintendo console OSes, Android, ChromeOS, Fuchsia, IBM i, IBM z/OS, INTEGRITY, QNX,Unisys ClearPath, Solaris, HP-UX, Aix, vxWorks.....?
Those listings are required by the license.
Also they aren't Linux or BSD derivatives, rather their own OSes.
https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-d...
Also 16 is actually not a small number, people with Kubernetes orchestration sometimes forget how much you can run on a single machine :).
I am even considering adding and marketing RHEL for my book[0] since the difference is just the registration.
Speaking of which, if you use Vagrant, have a look at vagrant-registration. It can register your box automatically (I am the original author).
[0] https://deploymentfromscratch.com/
I hope my large government customers ditch RHEL for something else - maybe a derivative that's home grown.