Stream is still a bit unclear for me, I have started looking into it.
How do they handle new software versions that can cause issues with existing configurations? What do you do when a new version is incompatible with your needs, you just stop updating and receiving security fixes until you figure out your configs for the new version?
I had this problem with samba going from centos 6(samba3) to 7(samba4) there were a lot of config differences and performance issues with the new version. It didn’t work well with the client software, took us a few months of guesswork to figure something out. It delayed our migration to c7 a lot, luckily samba3 was still receiving security fixes. So something like this happens on stream I’m just left with potentially unpatched version of given software?
That’s a big positive, it makes my job a lot easier if I can just run a command and I’m on the next version. Sometimes it’s a big issue for companies to have a few hours server downtime. Tried to do it with c6 but almost everything was different between the two systems, reinstalling was easier.
Yeah I can, and my argument is that none of those are a real option when you look at technical debt, in house levels of expertise,the planned vs actual time spent moving to a completely new platform, and the lack of real RBAC and MAC.
Just to clear this up, I do not work for Redhat in case that was not clear.
This works if and ony if you are holding onto equipment after the warranty expires, and wanting to upgrade in place with a VM makes zero sense if you have an appropriate configuration management infrastructure in place. Also upgrading in place is a great way to create new and exciting issues to troubleshoot in a production environment.
@mihalycsaba only you know the situatioin you are really dealing with, my point was do your due diligence, and thoroughly research the issue. Good luck.
I don’t think this thing with new software versions that indtroduce breaking changes is particular to me, I’m just asking you because you seem like you know more than me and until now I didn’t find much useful info about this issue. If there’s no way to receive bugfixes and security fixes that are available for older rhel versions, it makes centos not a good choice for production use.
Yeah we use a lot of old hardware. Most clients don’t have a budget, understanding or willingness to pay for servers that still work well in their eyes.
This will be same as what you got with CentOS, this is the actual value of paying for RHEL. You can freeze at a minor version while still receiving security updates. I understand why that is not an option here.
I will expand on this later. You should get security fixes and bug fixes you just don’t get them first.
Sorry maybe I’m a bit dense, you’re saying that if I’m on Centos Stream and I decide that I want to stay on a certain minor version I can get the same fixes as the corresponding rhel version, without messing up my system? I don’t mind if I get them a bit later, not months, but like a week or two later is okay.
How can that be if you consider that CentOS is fully free and the basis of the next RHEL. Does that mean CentOS is only good for 30 % of RHEL? What are the other 70 % of RHEL?
This is just FUD. If the source code is under GPL they have no case. The distribution of the source code by their customers or developers can not be stopped.
“You may copy and distribute verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty”
he is saying that you can do that with the paid RHEL, not with Stream.
nope that is the US legal system. RHEL licensing forbids it, so the case in court will be RHEL licensing vs GPL. And the more money you can throw at it, the longer the whole thing will take.
Of course Rocky and Alma can just take the upstream packages and distribute them directly, but that does not qualify for being an RHEL clone or being even RHEL-based.
That’s a very good thesis, it’s matter of slowly shifting reality of copyleft licenses in favor of walled garden control like Ubuntu with their snaps centralized sources, just see it over time.
Of course they’re not as stupid as to start direct fight bashing against the wall and legalities of things…They’ll just wash it away like they already did for years before.
And the end of the day, the question is whether Red Hat can prevent the distribution of the source code. My opinion is, that they can not prevent this from happening. It is simply not feasible. The source code will end up in public.
And this reason why I believe that this whole move from Red Hat is stupid.
that would only be the next step in the direction they have already started to take. They started it with pulling the plug on CentOS 8 and 9 and now continued in that direction with the closing of the source code because others that they don’t own stepped up to fill the void.
Your assumption that they are not going to do that is based on Red Hat / IBM thinking that what they are doing is wrong. But the exact opposite is the case, they firmly believe what they are doing is right.
Of course it will! That’s why they will take legal action against those taking advantage of that leaked source code. That will make it impossible for ANY serious company to use the product that the redistributors provide.
Here is the tricky part, access to the Redhat source is being provided as part of a subscription or support agreement. That agreement can(and I believe does) have language preventing redistribution.
I don’t think there is much of a case for Redhat to sue Rocky/Alma. However, they can terminate the access to the source of anyone who shares that source with them or others.
they can forbid the redistribution, at least if it is done in the way that Rocky and Alma are doing it. There are several cases that can prove as precedence where sales bans and court orders to stop distribution got enforced. The only way out would be some shadow company that can’t be legally accessed, but that would eliminate any serious company from using that product.
Practically speaking, I don’t see a way for them to legally enforce this via a lawsuit. Moreover, I don’t think they would take this path. It would have far more negative consequences than positive ones.
What they could do fairly easily is create an endless cat and mouse game where they perpetually shutdown whatever method is being used to access the code. Because their agreements can prevent redistribution giving them the right to terminate those agreements.
They don’t need or want to sue Rocky and Alma out of existence. All they need to do here is lower the trust in those products to the point where companies choose to pay for support instead of using a free alternative.
No matter what absurd reasons RH chooses to paste on this, it is a revenue grab for them.
It’s not only companies using Rocky/Alma, I use Rocky on my personal vpses as well and no way I’m paying for RHEL because I don’t need technical support and I don’t trust them at some point to not start charging money for the personal developer subscription.
