The point is that this is a stupid decision. It will turn people off Red Hat, and at the same time it’s incredibly annoying and inconvenient for a large number of Rocky/Alma/etc users.
> It will turn people off Red Hat Will it turn paying customers off Red Hat? (Honest question)
Not directly but it might cause some upstream vendors and projects to rethink weather they want to recommend Red Hat as preferred platform and if the hosting vendors turn off the Red Hat clones that's going to ripple back to Red Hat, as a lot of corporate linux users will gravitate to the distro that's recommended by the application vendors.
Part of how canonical challenged Red Hat is that they deliberately made it really easy for a developer to run Ubuntu on their workstation and test environments.
Don't underestimate the impact that even someone using CentOS and not contributing back can still have. It's still a person or group of people learning the Red Hat way. Lots of people (myself included) started on CentOS, and later bought RHEL when the need came up because I was already super familiar with RHEL because of my years on CentOS. Increasing proliferation of usage is a huge factor in driving growth.
Based on what I can tell Red Hat agrees with that and has gone through great efforts to invest in and evolve the CentOS project. The current state of the project is CentOS stream which is still a LTS enterprise distribution and has an efficient dev cycle that prevents the delays seen in years past. Doesn’t centos stream fill the niche you are describing?
It comes close, but doesn't fill the niche because according to Red Hat, CentOS Stream should not be used in production. People do and for the most part they have no issues, but as long as the maintainers themselves are telling people not to run it in production, I would never recommend somebody to use it for serious workloads. And if you can't use it for serious workloads, then you should invest your time into a different ecosystem that can be used for serious workloads.
> Debian has decades old versions of packages that they'll backport security fixes into till pretty much the end of time I don't know what filthy corner of the internet you get this misinformation from, but it is completely wrong. Please stop.
To be clear, I have nothing against them doing that, I'm just saying that this is how Debian generally operates. Their extended support model still allows for backporting fixes into jessie of all things, which released almost 8 years ago. It's really good that they do that, I respect the niche they work in, but Debian has the nasty knock-on effect of having a lot of guides made for it by third parties that recommend…
> Their extended support model still allows for backporting fixes into jessie of all things, which released almost 8 years ago.
So your evidence that they don't update things is that they backport new fixes to an EOL version? Even if that made sense, 8 years is 0.8 decades; I think a lot of the pushback is that you said "decades old versions", which is to say "versions of packages that are at least 20 years old", which is wildly out of line with reality.
IANAL, but that doesn't mean that Red Hat does have to give you the source code. They only have to provide the source code to customers to which they distribute the binaries. Of course, for GPL code, their customers could redistribute the source code. AFAIK, the current kerfuffle is about providing RHEL source packages through git.centos.org. They currently only provide RHEL through a subscription and they fulfill th…
>Of course, for GPL code, their customers could redistribute the source code. The fact that the subscription agreement does not allow this is exactly what we're discussing here.
The GPL does not say that they are obligated to sell you the next version.
The entire point of the GPL is to let you own the software you have bought and, examine, learn and change.
The rule Red Hat have brought in is that if you exercise that right then they don't want to continue selling their software to you. That is totally within their rights, it's not like they are suing you for illegal distribution.
Based on what I can tell Red Hat agrees with that and has gone through great efforts to invest in and evolve the CentOS project. The current state of the project is CentOS stream which is still a LTS enterprise distribution and has an efficient dev cycle that prevents the delays seen in years past. Doesn’t centos stream fill the niche you are describing?
It comes close, but doesn't fill the niche because according to Red Hat, CentOS Stream should not be used in production. People do and for the most part they have no issues, but as long as the maintainers themselves are telling people not to run it in production, I would never recommend somebody to use it for serious workloads. And if you can't use it for serious workloads, then you should invest your time into a dif…
If you’re running something in production you’re almost certainly making money off of it, so maybe you should send some of that money to RedHat for licenses?
They could also shrink down to a more manageable business unit... except IBM paid $34 billion for Red Hat, and you can't ever decrease revenues or the axe drops :(
Well, remember too that IBM didn't pay $34b for just RHEL - a big part of the purchase was OpenShift which has been coming up in revenue and has RHEL as its underpinning. And I have a lot more to write and say about that in a series for my own blog, but certainly IBM isn't looking for RHEL revenue to go down... And to be very fair to all involved, that's not even remotely unique to IBM. IBM is a public company and th…
Yeah, and regarding OpenShift, I wonder how well that play has been working for IBM. My guess is they were expecting to 10x or 100x OpenShift revenues as giant corporations standardized on containerized infrastructure...
...but then Kubernetes (sans OpenShift) seemed to do the 10x'ing while OpenShift was just what RH customers used if they weren't already exploring Kubernetes through some other cloud provider's offering.
Probably because Canonical does promise to make their software freely available to the whole world.
Hmmm. "freely available to the whole world". Is that really the wording they use? Asking because their recent advertising added to the apt cli is promoting some kind of security packages. Seems like people need to pay for those?
I believe that was for Ubuntu Pro.
Ubuntu Pro provides some extra support (five more years) for packages in Ubuntu's existing (gratis) Long Term Support (LTS) releases of Ubuntu.
To be clear, I have nothing against them doing that, I'm just saying that this is how Debian generally operates. Their extended support model still allows for backporting fixes into jessie of all things, which released almost 8 years ago. It's really good that they do that, I respect the niche they work in, but Debian has the nasty knock-on effect of having a lot of guides made for it by third parties that recommend…
> Their extended support model still allows for backporting fixes into jessie of all things, which released almost 8 years ago. So your evidence that they don't update things is that they backport new fixes to an EOL version? Even if that made sense, 8 years is 0.8 decades; I think a lot of the pushback is that you said "decades old versions", which is to say "versions of packages that are at least 20 years old", whi…
It's just rhetorical hyperbole, you're reading too much into it.
RHEL has a major ecosystem advantage related to drivers that they may not be aware of. They risk ruining this, as I will try to explain. At the time industry started to take Linux seriously, RHEL was the dominant distro. As a result, and by accident, RHEL+derivs became the primary target for commercial hardware drivers. As an example - it's easier to get obscure low-latency network and packet-capture cards working on…
If you don't mind, what makes more niche hardware drivers work / build better against RHEL? I suppose RHEL uses basically the same kernel, with patches that don't alter its interface too substantially. So I presume that a driver in source form, or even partly in binary blob form, should build and work approximately equally well with any stock kernel. Beside the driver developers apparently using RHEL / CentOS (so on…
Targeting a RHEL kernel version is quite different than targeting the same official kernel version as they backport a huge number of features, resulting in drivers that may work in RHEL but not upstream, or the reverse