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

Openela releases Red Hat source code on GitHub

github.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: Openela releases Red Hat source code on GitHub

#51

Post by oneplane »

2OEH8eoCRo0 wrote: post #42
oneplane wrote: post #28

Earlier quoted context omitted.

But that's the thing, there is no good thing going. CentOS used to be a community rebuild of RHEL, and you could then use that if you didn't want support from Red Hat. But that is no longer the case since Red Hat killed that. CentOS is now more like a beta version of RHEL and not a binary compatible build. At the same time, patches are made for RHEL that are kept secret and not published for CentOS. And all of this i…

> there is no good thing going. Strong disagree. I benefit greatly from Fedora and CentOS Stream.

Strong disagree. Fedora and CentOS Stream (well, C8 Stream is dead, but the other stream-position I suppose) add no value to me whatsoever and working with it is a net negative. The only reason we're still touching it is because vendors like Manhattan (logistics and warehousing) can't seem to get their head out of their ass.

Re: Openela releases Red Hat source code on GitHub

#52

Post by oneplane »

INTPenis wrote: post #45
oneplane wrote: post #28

Earlier quoted context omitted.

But that's the thing, there is no good thing going. CentOS used to be a community rebuild of RHEL, and you could then use that if you didn't want support from Red Hat. But that is no longer the case since Red Hat killed that. CentOS is now more like a beta version of RHEL and not a binary compatible build. At the same time, patches are made for RHEL that are kept secret and not published for CentOS. And all of this i…

That's not true. CentOS Stream is literally the testing ground for RHEL patches. So CentOS gets patches much earlier now than it ever did as a community project. I relied heavily on CentOS but at least I'm being honest, I relied on CentOS because it was a free version of RHEL. People got so mad when RHEL took away their free OS that they make up all sorts of excuses. Fact is Red Hat have been contributing back to ope…

> That's not true. CentOS Stream is literally the testing ground for RHEL patches. So CentOS gets patches much earlier now than it ever did as a community project.

It definitely is true, in our RHEL subscriptions we get patches that do not exist in CentOS. We also see those differences in fully patched systems where the patch versions run different binary code.

> I relied heavily on CentOS [..]

> Fact is [..]

> So this is why [..]

All those other arguments are not very relevant, they bought CentOS and then broke community trust multiple times to the point where we now have multiple re-incarnations of the CentOS concept and RHEL (or IBM) thought they could prevent that by hiding the sources used for current RHEL builds from the public by default.

Money-wise it's also not relevant because there are only two reasons you pay for support:

1. You actually need support (we never did in the past 15 years)

2. Corporate nonsense (this applies to some of our vendors)

Red Hat is fully leaning into #2 and it's just not having any real value if you don't also fit in #1.

Re: Openela releases Red Hat source code on GitHub

#53

Post by mmcgrath1 »

oneplane wrote: post #52
INTPenis wrote: post #45

Earlier quoted context omitted.

That's not true. CentOS Stream is literally the testing ground for RHEL patches. So CentOS gets patches much earlier now than it ever did as a community project. I relied heavily on CentOS but at least I'm being honest, I relied on CentOS because it was a free version of RHEL. People got so mad when RHEL took away their free OS that they make up all sorts of excuses. Fact is Red Hat have been contributing back to ope…

> That's not true. CentOS Stream is literally the testing ground for RHEL patches. So CentOS gets patches much earlier now than it ever did as a community project. It definitely is true, in our RHEL subscriptions we get patches that do not exist in CentOS. We also see those differences in fully patched systems where the patch versions run different binary code. > I relied heavily on CentOS [..] > Fact is [..] > So th…

>It definitely is true, in our RHEL subscriptions we get patches that do not exist in CentOS.

Citation needed. Source: I work at Red Hat and made the policy that stuff needs to go to CentOS Stream first. The only exceptions should be embargoed or critical/important CVEs, those go to customers before CentOS Stream.

If you find any code, features, or bug sizes in RHEL that aren't in stream, it's a bug, let us know and we will fix it.

Re: Openela releases Red Hat source code on GitHub

#54

Post by p_l »

em-bee wrote: post #36
nolist_policy wrote: post #32

Earlier quoted context omitted.

Redhat doesn't ship btrfs because they don't have any engineers working on it and thus can't provide support for it. Anything that ships in RHEL is comes with a strong support guarantee that they just couldn't hold up for btrfs. The SAS controllers may be a similar thing, maybe they don't have the hardware anymore to regression test against.

rather they don't have any customers demanding it. if they had, hiring engineers to support that should not be the problem. incidentally, i never had a chance to figure out what the big deal was with the centos stream change, because i was already forced to switch to debian because btrfs was removed from the centos kernel.

CentOS being in lock-step with RHEL minus support also included certain certifications that applied to RHEL also applied to CentOS, most importantly if you were in the business of selling to US government or related customer.

Re: Openela releases Red Hat source code on GitHub

#55

Post by oneplane »

mmcgrath1 wrote: post #53
oneplane wrote: post #52

Earlier quoted context omitted.

> That's not true. CentOS Stream is literally the testing ground for RHEL patches. So CentOS gets patches much earlier now than it ever did as a community project. It definitely is true, in our RHEL subscriptions we get patches that do not exist in CentOS. We also see those differences in fully patched systems where the patch versions run different binary code. > I relied heavily on CentOS [..] > Fact is [..] > So th…

>It definitely is true, in our RHEL subscriptions we get patches that do not exist in CentOS. Citation needed. Source: I work at Red Hat and made the policy that stuff needs to go to CentOS Stream first. The only exceptions should be embargoed or critical/important CVEs, those go to customers before CentOS Stream. If you find any code, features, or bug sizes in RHEL that aren't in stream, it's a bug, let us know and…

Well, you already mentioned it: the important updates that already have PoC in the wild that are somehow patched for RHEL but not for CentOS. The lag isn't always huge, but we definitely can't consider CentOS a RHEL bug-for-bug compatible rebuild anymore.

Maybe the issue wasn't highlighted as much in the past where the rebuild compatibility meant that packages could go out without also having the source (in CentOS).

Re: Openela releases Red Hat source code on GitHub

#56

Post by ungamedplayer »

chasil wrote: post #50
ungamedplayer wrote: post #47

Earlier quoted context omitted.

Btrfs was tech preview. There is no support or guarantee that tech previews remain in a release.

And there is no guarantee that we will not use the UEK, because the feature is compelling.

And you have that right. If uek meets your needs of support and gives you what you need and rhel does not you absolutely should use it.

Re: Openela releases Red Hat source code on GitHub

#57

Post by ungamedplayer »

spandextwins wrote: post #49
ungamedplayer wrote: post #46

Earlier quoted context omitted.

Because there is legal complications in giving someone remote admin.

Not if they do it right. Lots of companies did that with us, some required it as part of their contract. We'd give them the ability to control or not, and what we were sharing with them. Way more efficient than sending up a tarball full of /var/log. Id argue THAT was a security and liability issue.

Redhats customers run across the world and many legal jurisdictions, which have their own set of complications.

The flip side of the coin that I have seen is that some customers will rely heavily on redhat to do basic admin work that a system admin would/should be doing. Effectively taking a job with legal liability for work provided.

The sosreport Tarball makes an active effort not to gather private information. If you believe it does, please let support know as they are interested in improving this.

Post reply on HN