Removing official support for Red Hat enterprise Linux | Hacker News Reader

Removing official support for Red Hat enterprise Linux

jeffgeerling.com

166 pointspetercooper61 comments

Totally reasonable reaction. I'm not on the anti-Red Hat bus, I feel like they have every right to walk the path they're walking right now.

I don't think Red Hat gets enough credit for its work carrying wood and chopping water to produce RHEL from users who get to sit by the fire and have clean water. Even if that water isn't in the fancy RHEL bottle and they don't get the closest spot to the fire.

But other maintainers also get to decide how they react. Geerling is also contributing and if he thinks that Red Hat has gone too far, he doesn't owe anybody contributions either.

> Geerling is also contributing and if he thinks that Red Hat has gone too far, he doesn't owe anybody contributions either.

Like, even if one thinks Red Hat's totally in the right—why volunteer time helping out RHEL, now? Completely rational to stop doing that whether or not one thinks what they're doing is ethically OK.

(Other Red Hat software/projects—sure, maybe still makes sense to keep contributing to and supporting those with volunteer time, it's just a whole lot less appealing to do free work for RHEL itself, now)

> even if one thinks Red Hat's totally in the right—why volunteer time helping out RHEL, now?

Because a paid Linux is the correct way to building an incredible seventh wonder of the world.

- As opposed to Windows, it’s still open-source. You can recompile it, send it to friends, and more importantly, maintain it if RedHat dies. Linux will stay 70 years while Windows will die with Microsoft.

- Linux is truely the most marvellous act of humans. Name another OS which landed on Mars… nevermind took off from Mars. Name another engineering piece on Earth that was the result of the generous contribution of hundreds of thousands of people.

Today, RH wants money. It doesn’t remove the other positive aspects of OSS, and it will help build better bigger companies with more marketing power and thus, more weight in this world.

Which can also be a good thing. I totally see why, even though a contributor can choose, it’s still worth helping a private company on OSS.

This doesn't change much IMHO.

Already when you report a bug for some years-old piece of software (as is the case for LTS distros), upstream projects will first ask you to reproduce with the latest version or even straight from git master.

As far as they are concerned, you are always running the latest upstream release.

I also have never seen any project step out of their way and try to reproduce an issue on a specific distribution. That burden is usually on the reporter.

We always spent a bit of time doing extra infra for the RHEL corner of the world to make lives a bit better for IT teams at our banking & gov customers, and the licensing stuff was weird but ok. But when rhel8 came out with heavy marketing of podman as a docker replacement (compose, ..), despite it not being ready, and then making it hard for rhel8 air gap users to keep using docker vs the incomplete podman stack... we lost a lot of hours for nothing but the leadership's greed.

That ended any good will I had left for the broader community. Individuals and bits of tech may be great, but it's against-the-grain as an infrastructure partner. Instead of being proactive, we're much more reactive. We're a small player, but it adds up over time. Ending of an era =/

I’ve never heard of the author before so I poked around their GitHub to understand if this is significant. Their account has many repos of Ansible roles, some with hundreds of stars like https://github.com/geerlingguy/ansible-role-mysql

I’ve never used Ansible, can someone familiar with it tell us if this person is a cornerstone of the ecosystem or something?

Jeff is both an open-source contributor, as well as a fairly popular YouTuber[1]. His more popular repositories are more beginner friendly and not supporting RHEL means that it's unlikely that new users may end up choosing it as their Distro-of-choice.

[1]: https://www.youtube.com/c/jeffgeerling

Initially, before 2020, I would often build examples equally for CentOS and Debian (sometimes Ubuntu, if it was a more GUI-heavy thing).

After 2020, I slowed introducing CentOS examples, and converted all my CentOS usage to Rocky Linux.

At this point, I will not be creating any more examples building on RHEL-like OSes, but I might still maintain some of my examples on Rocky Linux, we'll see.

I'll second that commenter on your blog — thank you for taking a stance on this. This is much more likely to put some fire under Red Hat's asses than a bunch of no-names like myself whining on internet forums.

I doubt hobbyists would have chosen RHEL anyway though :) After all why pay when you can get excellent distros for free?

But those same hobbyists might eventually get a job at a place where they need to decide between Debian or RHEL, or influence the decision.

As a RHEL fan, using/preferring it since entering corporate environments forever ago -- I don't think new users are really a concern

They've done decently to lock down the sort of places that tell you what's being used, not chosen.

I say this with pain on my face, I don't want it going this way

To me, Jeff Geerling is the Raspberry Pi guy, since he pushes them in all kinds of crazy ways, like trying to get a high-end GPU working on a Pi.

https://www.jeffgeerling.com/blog/2022/external-graphics-car...

That's interesting, to me he's the Ansible role guy. He has hundreds of roles, and I've used dozens for F500 clients on RHEL. Him moving away from it means RedHat in all likelyhood will have to pickup the slack and start creating hundreds of supported Ansible roles for RHEL OSes. Wonder if they'll release the source, or require the subscription level with Ansible/Tower to get access to them heh

I trust Jeff is making decent choices in his modules to support the distributions he's offering (including very similar derivatives)

By doing this, there's certainty that a lot of what's written will work just fine on RHEL. It's a huge Python library with the express purpose of abstracting away annoying OS quirks

CentOS Stream <-> RHEL is basically point releases. You're generally well past this stage by using Ansible.

At most you want to care about the OS family, treating the derivatives as part -- Debian, Red Hat, etc. Focusing mostly on binary/config file path quirks

There may be certain traits about RHEL users that will bring some issues

eg: more likely actually using SELinux, have forgotten to tend to their subscriptions, or are aiming for more strict compliance

Maybe not a _cornerstone_ per se, but Jeff's active in a number arenas (Ansible, Docker, general programming, ...) and has gained a level of name recognition. I think he's taking a reasonable stand here and contributing whatever weight his reputation carries to the discussion.

Jeff is probably the most famous "face" of Ansible, being a prolific contributor and a producer of learning content.

I don't know about now but he used to be. He basically wrote the first handful of Ansible books and maintains a ton of the roles people use.

Ironically Ansible (the company) was acquired by RedHat so Ansible is part of RedHat.

Yes, that's the point.

He's prominent, but cornerstone might be a bit much. It's almost as flooded as Python.

I know of him through his Ansible 'roles'. Definitely one of the few people I could name in the space. Note: roles are reusable sets of config tasks

Regarding the stance, I'm a little bewildered.

Some background on Ansible: the entire point of it is to reduce how much you care about the target OS... and he's supporting very-similar derivatives.

What little effort is required, will largely be there. Very rarely, dare I say never, do you care about point releases. Something silly is afoot if so.

Being selective with your modules deals with a considerable part the abstraction. For example, use 'package' instead of apt/dnf/something specific.

I write/test on Fedora, deploy to Ubuntu, and have been migrating to RHEL -- with no serious effort. Some dictionaries to hold different binary/config file paths.

Anyway, this is all to say - I see this as somewhat performative, but I don't disagree with it either.

I don't believe much will happen in the end. Good, bad, or otherwise.

The roles very likely will work in 'unsupported' land. Yet, the path IBM is taking with Red Hat is clear (while annoying)... and probably not changing

Calling it now, the majority of the incompatibility will be:

  - subscription-manager (which can/should be done before roles you get from others)
  - FIPS (a niche, where I would fully support the response being a support contract request)

Add a dash of irony (maybe?) because he's still supporting Red Hat indirectly by working with/on Ansible and close-enough environments.

He is the Pi guy.

Recent and related. Others?

Dear Red Hat: Are you dumb? - https://news.ycombinator.com/item?id=36436786 - June 2023 (383 comments)

Impact of RHEL Changes to AlmaLinux - https://news.ycombinator.com/item?id=36436375 - June 2023 (43 comments)

Red Hat cutting back RHEL source availability - https://news.ycombinator.com/item?id=36420259 - June 2023 (299 comments)

Red Hat Now Limiting RHEL Sources to CentOS Stream - https://news.ycombinator.com/item?id=36419586 - June 2023 (27 comments)

> For all of my open source projects, effective immediately, I am no longer going to maintain 'official' support for Red Hat Enterprise Linux.

> I will still support users of CentOS Stream, Rocky Linux, and Alma Linux, as I am able to test against those targets.

Open Source projects cannot afford to support (post-IBM-acquisition) RedHat RHEL license terms. How does that change developers' (coders, actual merge maintainers) and maybe also influencers' valuation of an acquired Linux distribution (with a new Stream model)?

This seems like a reasonable position: if you can't test a target, you have to assume you've broken it in the latest change.

I think more accurately, you can't assume you've broken it, or that it works because you can't test it. It's just an unknown. Which is bad enough, IMHO.

I always assumed it was possible to spin up an AWS instance or DO droplet with RHEL and licensing was baked into the hourly rate. Is that not the case?

Why would anybody put even one second of volunteer effort into helping RHEL, let alone pay to do it, when Red Hat's locked off access to their system? If they're taking and not contributing, what possible reason would anyone have for doing stuff for them for free, or voluntarily paying to help them out? Let them test it, if they care.

I dont want to shill for redhat, but stating they are taking and not contributing is quite unfair. At least in the context of open source.

If you don't make your stuff available for free to the public, then you don't deserve for members of the public to do free work on your stuff.

Are you aware the amount that Red Hat contributes to the kernel? Red Hat has more contributions to the upstream linux kernel (which every distro benefits from, RHEL or not) than just about any other corporation. The amount of testing and stability effort that goes into the kernel would be dramatically reduced without Red Hat, not to mention the code changes themselves.

Just to get a basic idea, [1] has some stats of kernel contributions for the 4.20 kernel, Red Hat had second most changesets accepted. Intel was first, although if you combined Red Hat + IBM then that would push Intel to second. And looking at the core kernel commits (ie ignoring things like device drivers, where hardware companies are making contributions solely for the purpose of supporting the hardware that they sell), the difference was even more skewed towards Red Hat (and interestingly, IBM as well).

And that's just the kernel itself, they're also the primary force behind plenty of other widely used projects (fedora is one of my favorite distros, systemd, for better or worse, it's still used by most distros, and as much as people like to hate on gnome, I have to say I've found it more stable and worry free compared to other options including modern KDE, and the list goes on). Maybe they are not the perfect role model but don't pretend they aren't giving a bunch back to the entire community in many ways.

[1] https://lwn.net/Articles/775440/

Isn’t this kind of what the RHEL clones were doing? Taking a snapshot of RHEL and then repackaging it, and in the case of Rocky Linux selling support. All without actually making any contributions back to the community. Almalinux actually contributes patches so I feel they will end up coming to an agreement with Red Hat but the likes of Rocky Linux seemed to be largely exploitive. Red Hat seems to be saying “hey you can have the code but we aren’t going to make the distribution for you. Here is a link to Stream feel free to make your own distribution”

RHEL specifically is no longer contributing back. Helping that particular distro is just giving them free labor and getting nothing in return.

That's an absurd generalization. They contribute upstream. They aren't forking every project and keeping changes for themselves and customers. Just the sheer amount of development and testing RedHat puts into the kernel alone, funded by RHEL, should be sufficient to disprove this argument.

There's nuance here. TFA has a legit complaint that supporting RHEL puts extra hassle on you as an open source contributor. RedHat is also fully in their right to strictly adhere to the license of the software they distribute.

Supporting RHEL as a distribution for your software means access to users on that distribution. That might mean nothing, but that depends from project to project. For the article's author that has little worth and that's a cost-benefit analysis for him. That might not be the case for other projects.

Red Hat contributes a ton.

Companies like Oracle basically sponge off of their work.

RHEL specifically is now fenced off. Supporting it's barely any different than supporting macOS or Windows—do it if you are targeting it in particular or personally use it, sure, then you get benefits, but otherwise, why give them free labor?

Contribute to projects Red Hat uses on which they contribute back, sure, by why straight-up work for them for free? That's what supporting RHEL on a volunteer basis is, now (again, unless you personally use it or care about specifically supporting some users who do).

Why should you have to spin a VM for Redhat up in the cloud with the associated cost if no one is paying you for supporting it? If you already ahve the hardware at home to run other Linux distributions I understand not wanting to jump through hoops to support Redhat if you don't have a contract with anyone to do so.

Probably. It's also possible just to outsource the whole testing process to to someone else.

He could even contract RedHat to do it. I'm pretty sure even Microsoft would test it for him if the money is right.

Yes, he can even use the free RHEL Dev licenses, he just doesnt want to bother with any kind of licensing system.

I do the RedHat side of support for our open source project. And when I do have to spin up real RedHat for something, it’s always a pain of fixing up some licensing or another.

If it is any comfort, while I was at Red Hat... I used CentOS for testing, for this exact reason.

Alas, this was before Red Hat bought CentOS :(.

Isn't he trying to make a stand against the silliness that Red Hat is doing?

He is but should be more honest about it instead of claiming that the reason is not being able to test.

Not being able to test conveniently is enough of a reason. The guy did free work for their platform.

It can still be conveniently tested. He is making a statement and should be more clear that is what is happening here.

He didn't do free work for their platform. He did work using their platform which he made freely available to further his own situation. I don't say that in a judgemental way. There is nothing wrong with that, but let's not misrepresent it.

To be fair dealing with subscription-manager is agony

Perhaps relevant - how's Ansible doing these days, given that it's a Red Hat tool now?

Ansible is still the best for tactical automation tasks. The syntax is also approachable for people who don't use it often, e.g. developers.

Ansible has poor performance on larger tasks. Idempotency checks to see whether an action needs to be executed require manual work to set up and time to execute. This also makes it slow to work with cloud resources.

I switched to Terraform years ago for low-level resource provisioning and cloud automation. I still occasionally use it in conjunction with Packer to create AMIs.

The shift to containerized application deployment makes Ansible much less relevant in general.

Dockerfiles are bad at idempotency, but the solution is probably not Ansible.

Definitely a fair take; I think Ansible still has a place in containerized environments, but the nice thing is it can play a large or small role depending on how much you want to learn other tools which might be better at a specific automation segment (like Terraform for infra resources).

Thanks for your service supporting the Ansible community. Your books are also great, and I highly recommend them to anyone learning Ansible.

As slow to execute as ever. Salt was the better future.

I went with Ansible way back when all these were fairly new, because it was not just possible, but considered "culturally", if you will, normal, in that ecosystem, to run it agentless. Having to run a config agent on the target system always felt like a smell, and begging for trouble.

But yaml's friggin' terrible, that's simply true.

Agreed. Puppet Bolt has been better to me than Ansible, especially around Playbook YAML vs the Puppet DSL. Puppet seemed to fall out of the limelight when Ansible made it big, then Bolt got little love.

I find it ok as long as you're using persistent connections (which also significantly reduce connection time for all other SSH sessions). Add something like this to ~/.ssh/config:

  ControlMaster    auto
  ControlPath      ~/.ssh/persist/%r@%h:%p
  ControlPersist   15m

What happened to Salt? I felt like it was everywhere in 2015, but I almost never hear of it anymore. Even their official documentation site has an ad promoting "SaltConf 2021", a conference from nearly two years ago.

We're using it to provision the Vms hosting our container platform besides some terraform/packer for allocating the VMs and such. It works, and doesn't suck much more or less than other configuration systems.

A big discussion point internally is just speed at even medium scales. I don't know why something like Mitogen is not built-in, as Mitogen is the difference between 12 - 15 minute runs vs 3 minutes flat, even though it has enough other problems.This is growing into some degree of resentment against the tool in the team. There is some murmuring that puppet might just be better to maintain the solid foundation of a fleet of linux systems, after chef was monetized and such. I'm going to send a colleague the idea of persistent connections to test though.

Terraform and Docker have been eating Ansibles lunch for some time now. Even OpenShift stopped using it as an installation method

Been using Red Hat (or clones) for 20+ years, the writing was on the wall and still is.

Enterprise Linux needs to move on from these cowbots.

Now the list of nonsense is too long!

at this rate RHEL 9.x won't reach 2025...

What is a "cowbot" ?

cowboys == cowbots... :D

Interesting how this will turn out in the future.

I think longterm, Rocky and Alma Linux will have to switch to the (oh so unstable) CentOS Stream sources. I just don't see anything else feasible for them.

In the end their users will run de facto Centos Stream - Just what Redhat intended in the first place!

On a serious note, this model will allow users to contribute back more effectively. With the current "bug-for-bug compatible" model this was completely out of the question.

Reply on news.ycombinator.com