Live data from Hacker News

Rocky Linux shares how they may continue to obtain the RHEL source code

phoronix.com

71–80 of 104 posts

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#71
post #23

Red Hat currently releases all sources as if they were GPL sources, but that may stop in the future. EG, an Apache 2 licensed project, they're under no obligation to release the source, but they currently choose to. That will be the next move for the RHEL sources IMO. They'll probably stop releasing all non-GPL licensed code from RHEL proper.

RedHat is unlikely to do that. After all, why would anyone still use RedHat if their competetive advantage (i.e. open source) is lost? As a RedHat customer i want to be able to take their packages (which include the open source software and their changes to it) and rebuild them from source with both their and my patches whenever i feel like doing so.

>After all, why would anyone still use RedHat if their competetive advantage (i.e. open source) is lost?

Who do you think finds that a competitive advantage? What company is saying "You know what, we can use Red Hat spend millions and worst case we just hire some devs to continue the work?" I doubt any are.

Their competitive is what support so many packages and companies can not worry about issues. Open source has no part in that.

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#72
post #23

Red Hat currently releases all sources as if they were GPL sources, but that may stop in the future. EG, an Apache 2 licensed project, they're under no obligation to release the source, but they currently choose to. That will be the next move for the RHEL sources IMO. They'll probably stop releasing all non-GPL licensed code from RHEL proper.

RedHat is unlikely to do that. After all, why would anyone still use RedHat if their competetive advantage (i.e. open source) is lost? As a RedHat customer i want to be able to take their packages (which include the open source software and their changes to it) and rebuild them from source with both their and my patches whenever i feel like doing so.

If you are a paying customer you can get the SRPMs, so nothing has/will change for you.

This will definitely be one of their possible next steps, as they seem bent on locking down RHEL.

I see people frequently disparage the GPL here in HN and promote less encumbered alternatives. Well, _this_ is why the GPL is important, and it will become even more relevant in the future.

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#73

Earlier quoted context omitted.

Its not like that Debian is completely drama free. Ubuntu and Canonical happily provides that mess.

Ubuntu and Canonical are downstream. So yes, Debian is more or less drama free. I run Debian on all my servers and, knock on wood, I have not had an issue in over 15 years of usage. It quite literally is the most rock solid and trouble-free OS I have ever used. I have a ton of experience with Ubuntu, too, but these days there is no compelling reason to use their stuff. The contrary actually - considering all the tele…

I've used every major distro at one time or another, and I agree -- Debian is the best of the bunch in most ways.

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#74
post #3

Not sure these "options" are going to satisfy business risk analysis. We are looking into moving away from all things CentOS, RHEL, or projects like Rocky. It was going to be Rocky, but no more. Red Hat got blue washed and is now ruining their reputation

My impression from being somewhat involved in the (early) communities of Rocky and Alma, is that the Rocky people are quite a bit looser with violating EULAs, ToS, etc. Sometimes that is the superior approach, but with something like RHEL rebuilt it makes me nervous. Alma by contrast are very professional. Rocky also has an antagonistic view toward Red Hat, while Alma views Red Hat as partners. People can hate on Red Hat, but without them none of the rebuilds would even be possible. There's still a lot that Red Hat could do to kill them if they wanted to.

Anyway my main point, I'm not worried about Alma getting wiped out, or about them making a bad decision that ends them in legal hot water and jeopardizes the project.

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#75
post #52
post #35

Earlier quoted context omitted.

I don't understand all these CentOS forks: you're still dealing with Red Hat and reinforcing their ecosystem for free. What if those forks poured the effort behind Debian? A truly democratic distro that cannot pull rugs from under your feet.

Debian LTS only has 5 years of support, without guarantees, on a volunteer basis. RHEL has 10 years of support, with the option of 13 years. I like debian, but sometimes you have to have long term support. And I fully understand why you wouldn't support 13 year old software without getting paid for it.

> RHEL has 10 years of support, with the option of 13 years.

The problem here is that the people who need 13 years of support are perfectly OK with paying Red Hat for that. No one is saying that doesn't have great value if you need it... problem is you don't need it for an awful lot use cases.

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#76
post #3

Not sure these "options" are going to satisfy business risk analysis. We are looking into moving away from all things CentOS, RHEL, or projects like Rocky. It was going to be Rocky, but no more. Red Hat got blue washed and is now ruining their reputation

My impression from being somewhat involved in the (early) communities of Rocky and Alma, is that the Rocky people are quite a bit looser with violating EULAs, ToS, etc. Sometimes that is the superior approach, but with something like RHEL rebuilt it makes me nervous. Alma by contrast are very professional. Rocky also has an antagonistic view toward Red Hat, while Alma views Red Hat as partners. People can hate on Red…

Agree, Alma's response has been way less hacky.

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#77

I think the cloud instance is a pretty good option, and is effectively what the old-gangsta CentOS team was doing, with more or different steps. Back in the old days the RPMs were manually imported, there was no RH provided pipeline to get unbranded RPM sources. So it's really not a big deal to go back to the bad old ways, and if they want to ignore the new shiny CentOS stream way of things, well they are free to be…

I think in those old days of CentOS, they had direct access to the srpms from an ftp server. This is marginally harder.

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#78
post #52
post #35

Earlier quoted context omitted.

I don't understand all these CentOS forks: you're still dealing with Red Hat and reinforcing their ecosystem for free. What if those forks poured the effort behind Debian? A truly democratic distro that cannot pull rugs from under your feet.

Debian LTS only has 5 years of support, without guarantees, on a volunteer basis. RHEL has 10 years of support, with the option of 13 years. I like debian, but sometimes you have to have long term support. And I fully understand why you wouldn't support 13 year old software without getting paid for it.

> Debian LTS only has 5 years of support, without guarantees, on a volunteer basis.

Less than that if you care about security patches. Debian's Security team stop after ~18-24 months, at which point it transitions off to, quote, "Debian LTS is not handled by the Debian Security team, but by a separate group of volunteers and companies interested in making it a success.".

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#79
post #38
post #20

Earlier quoted context omitted.

The "problem" with Debian is the lifecycle. You get about a 12-24 months at most of security patches, and that's effectively it (the patching model after that is unreliable). That means you've got to allocate resources for upgrading/validating far more regularly than you would with other distributions. Depending on the size of your business, that could get really expensive and disruptive, for negligible benefit. Cano…

That's simply not true. All Debian releases have been LTS since 2014, for the following architectures : i386, amd64, armhf and arm64. All Debian releases get 1 year of full updates after the new release, and at least 5 years of updates in total from their initial publication.

After the first couple of years, Debian Security stops patching it. "Debian LTS is not handled by the Debian Security team, but by a separate group of volunteers and companies interested in making it a success.",from https://wiki.debian.org/LTS. It is not the same thing, and the time scales and patching consistency is not on the same scale.

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#80
post #52

Earlier quoted context omitted.

Debian LTS only has 5 years of support, without guarantees, on a volunteer basis. RHEL has 10 years of support, with the option of 13 years. I like debian, but sometimes you have to have long term support. And I fully understand why you wouldn't support 13 year old software without getting paid for it.

> RHEL has 10 years of support, with the option of 13 years. The problem here is that the people who need 13 years of support are perfectly OK with paying Red Hat for that. No one is saying that doesn't have great value if you need it... problem is you don't need it for an awful lot use cases.

Red Hat didn't get to a billion dollar business on the back of not "needing it for an awful lot of use cases". We may not see it since we're developers reading HN, where it's all about the latest tech stack, but those 13 years if support are a huge money maker for Red Hat. They'd do 15 and 20 if their engineers wouldn't revolt. Outside of sexy tech is companies that want really really really stable, don't ever want to upgrade, and can afford to pay not to, until the very end. Hence that whole Y2K rush to update software.

There's a ton of Python 2 code still out there that won't get updated to 3 if it can be helped.

It doesn't look big, but it's like an iceberg. 9/10ths of it is invisible, and just sits there, raking in money.

Post reply on HN