Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A response to the git.centos.org changes

redhat.com

Post reply on HN
Print view View original

151–160 of 184 posts

Re: A response to the git.centos.org changes

#151

Post by bonzini »

prepend wrote: post #144
jacooper wrote: post #103

Earlier quoted context omitted.

If you've read the article, its clearly stated that many more people were just using CentOS as free RHEL, never needing to pay anything because it gives them everything they need for free. It wasn't worth putting up with so many free users for a paid product, just to have a small minority actually pay anything.

> It wasn't worth putting up with so many free users for a paid product, just to have a small minority actually pay anything. It used to be worth it for 20+ years. Now something changed. For my servers I used to use 95% centos, 5% rhel. Now I’ll use 0% rhel. I didn’t need support for most servers but I liked having comparability for when things grew into needing it.

Have you considered the developer team license, the UBI, CentOS Stream? If none of them work for you, either there is a hole that Red Hat would like to be closed or you were already violating the support agreement.

Re: A response to the git.centos.org changes

#152

Post by bonzini »

housemusicfan wrote: post #23
keikobadthebad wrote: post #3

Sounds like they think of Rocky as the enemy, 'under no obligation' to make it easier, 'rebuilding code' is a 'threat'... I have a project in RHEL that they 'rebuild' but I don't see that as a 'threat'. They want to be a little bit more careful with dogma that makes sense to their management, will get them patted on the head there, but is just nonsense seen from other perspectives - like my perspective contributing t…

> I have a project in RHEL that they 'rebuild' but I don't see that as a 'threat'. They address that in the blog post: "We don’t simply take upstream packages and rebuild them." Rest assured they're adding good juju to your upstream code! This is 2000s-era Microsoft-level wordsmithing.

It also address in the blog post that all changes go upstream. We could check what Red Hat does if we knew what package is that.

Re: A response to the git.centos.org changes

#153

Post by bonzini »

cyberpunk wrote: post #70
NovemberWhiskey wrote: post #66

Earlier quoted context omitted.

t.b.h. all this tells me is that your pentesters are bad.

Bingo. We don't get to choose them, though, and they hold the strings on the certifications that our business needs. Sometimes it's easier to bend.

You used to pay Red Hat, did you try passing them the hot potato?

Re: A response to the git.centos.org changes

#154

Post by bonzini »

attentive wrote: post #130
nartz wrote: post #29

Whats said in this blogpost may be 100% true, and of course red hat does do a lot for the community, but unfortunately the damage is done. Its always going to feel like: * Red Hat was a bastion of open source * Red Hat sold out to IBM * Red Hat stopped being Red Hat, and started being IBM by focusing on $$ over open source * Red Hat reputation degrades as $$ are put first, killing off centos, now this, just downhill…

Is it true though? - he says "when we develop fixes for issues in RHEL, we don't just apply them to RHEL - they are applied upstream first, to projects like Fedora, CentOS Stream or the kernel project itself, and we then backport them". That contradicts to reports like https://news.ycombinator.com/item?id=36484207 "Additionally, CentOS Stream updates often lag behind RHEL updates. This is because Red Hat won't commit…

It's true that important or critical fixes (embargoed or not) are applied to RHEL before CentOS Stream. Forgetting to apply it seems unlikely because it would be marked as a regression in the next minor release of RHEL. Usually all the red tape is ready and you only need to "git push" as soon as the RHEL packages are shipped.

If not embargoed, however, they are still applied to Fedora first. But most fixes of that severity are embargoed anyway and therefore the patches simply cannot be applied to public source trees without breaking the embargo rules.

Re: A response to the git.centos.org changes

#155

Post by bonzini »

yjftsjthsd-h wrote: post #71
c0l0 wrote: post #16

Earlier quoted context omitted.

Yet still correct. I am not a Red Hat user or customer (I've been living on Debian and using it at work for nearly 15 years now), but I can perfectly understand their decision to not play along so nicely with EL rebuilders any more. Look at Amazon, who, until very recently at least, simply took what RHEL provided, used that to lure customers into their "RHEL-compatible" cloud platform, far away from any need to compe…

> Look at Amazon, who, until very recently at least, simply took what RHEL provided, used that to lure customers into their "RHEL-compatible" cloud platform, far away from any need to compensate Red Hat in any way, and contributed back into RHEL and its upstreams... what exactly? Yes, let's do look at Amazon! Because if RH is targeting Amazon Linux, they kind of missed the mark; Amazon, like Red Hat , now simply draw…

Obviously Amazon is not part of this, and neither is Facebook who uses CentOS Stream.

Re: A response to the git.centos.org changes

#156

Post by bonzini »

ilyt wrote: post #41
housemusicfan wrote: post #35

Earlier quoted context omitted.

> If you pay them for it, you can't redistribute it. Citation please? I've sat in enough conference rooms full of lawyers to know the GPL explicitly forbids this, so it would be bordering on insane if this is what they're proposing.

Apparently they changed their license so they can cancel it when you request sources.

No change, it's been like that forever. What changed is what was made available for free even without signing the agreement.

Re: A response to the git.centos.org changes

#157

Post by rwmj »

rbanffy wrote: post #116
rwmj wrote: post #113

Earlier quoted context omitted.

RHEL is only a couple of thousand packages, and yes Red Hat absolutely does contribute to many, many packages that we use. Probably not every single one, but most of them and most definitely every one that needs fixes. The principle is called "upstream first".

> The principle is called "upstream first". This really is the Only Sane Way To Go, as you don’t want to support your patches forever. And reapply them on every release.

It's not the way Canonical works though, so it's a clear line between what Red Hat does and what Canonical does. (SUSE is upstream first)

Re: A response to the git.centos.org changes

#158

Post by salawat »

bbatha wrote: post #145
jabl wrote: post #82

Earlier quoted context omitted.

For a somewhat simplistic explanation, RHEL became very successful as a tool to replace proprietary RISC Unix servers (often running Oracle DB) with x86(-64) and Linux, offering a traditional "enterprise" support model those proprietary UNIX customers were used to. So what has changed? 1. The above market is pretty much "saturated" in the sense there aren't many proprietary UNIX systems left to convert to x86+RHEL. S…

This strategy is doubling down on the real reason that 3 is killing them: price. Their pricing structure in fundamentally incompatible with cloud native workloads. We treat workloads like cattle scaling them quickly and on demand to OS counts never dreamed of decades ago.

...And when you graze your Cattle on someone else's fields, you pay through the nose for it!

Best damn business innovation ever, renting people shovels to dig themselves a hole with!

Re: A response to the git.centos.org changes

#159

Post by pabs3 »

c0l0 wrote: post #16
leetrout wrote: post #2

> Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere. This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity. So... completely tone deaf.

Yet still correct. I am not a Red Hat user or customer (I've been living on Debian and using it at work for nearly 15 years now), but I can perfectly understand their decision to not play along so nicely with EL rebuilders any more. Look at Amazon, who, until very recently at least, simply took what RHEL provided, used that to lure customers into their "RHEL-compatible" cloud platform, far away from any need to compe…

The dev stats for Linux 6.4 put Oracle at 10th position by changesets and 14th by changed lines, the numbers are approximately half what RedHat does. So not as good as other companies, but not nothing either. No idea what other things they contribute to.

https://lwn.net/SubscriberLink/936113/7fc3347f0eca8e96/

Re: A response to the git.centos.org changes

#160

Post by pabs3 »

biimugan wrote: post #142

What is the evidence that the proceeds from contracts gained from this change will actually go towards the people doing the work? That's what I always wonder. After all, Red Hat also recently cut hundreds of jobs, similar to other tech companies. Those other tech companies also have their own just-so stories to try to explain why they're making certain decisions. Certainly most of those other companies don't have a l…

RedHat claims they didn't cut any engineering jobs, so probably at least some of it. Of course some will go to IBM shareholders too.
Post reply on HN