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.
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.
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.
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.
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.
> 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)?
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.
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.
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”
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.
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.
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.
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.
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).
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.
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.
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.
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.