Comment by Iolaum | Hacker News Reader

Comment by Iolaum | Hacker News Reader

I m torn about this move. My gut reaction was that this was a bean-counter move. Thinking more about it the key issues I see with this move are:

- CENTOS fills a need, that many users have and superficially it looks like Red Hat (IBM) is now abandoning addressing it. On the other hand Red Hat does offer RHEL for free (gratis) [0] and that should fill the needs of CENTOS users (right?). However it would have been much better if that option was mentioned in the announcement.

- I thought Fedora was upstream of RHEL. However after thinking more about it I realised that RHEL has a significant delta over Fedora. I 'm guessing CENTOS stream will be partway between Fedora and RHEL. It makes sense from Red Hats open development approach to have the delta between Fedora and RHEL happen in the open. Done right that should strengthen RHEL.

- Why the rush to drop support for CENTOS 8? I m sure some people are using it in production and they are unlikely to to want to move to this new CENTOS stream. It's a new OS distribution with a philosophy different to the one that was right for them!

Overall I 'd prefer if the new thing was called RHEL stream and provided for free (gratis) as CENTOS stream is. Also making more explicit the RHEL availability for free instead of having competing brands would be good. Now that there are competing vendors (Amazon Linux, Oracle Linux) trying to entice users it'd be better to strengthen RHEL brand rather than dilute it with multiple offerings. Unless RedHat/IBM plans to pull the plug on option [0].

[0]: https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-d...

The free developer license seems pretty useless for larger organizations and OS licenses aren't managed by developers in general anyway.

>Yes, but only one no-cost Red Hat Developer Subscription can be added to a user account. While it is possible to have each developer register for their own account, this is not ideal from a management or efficiency standpoint. For example, if a company wanted no-cost Red Hat Developer Subscriptions to cover 100 developers, each developer would need to individually register and independently create 100 accounts that need to be tracked and maintained. For enterprises that use Red Hat Satellite to manage multiple systems, all 100 accounts would need to be added individually. Accepting the terms and conditions and renewing the subscription annually would need to be done individually and manually for all 100 accounts. Staff turnover in the development team would create additional management challenges with individual accounts. Therefore in terms of lost productivity, managing individual no-cost subscriptions will not be cost-effective for many groups.

Many development organizations benefit from having Red Hat Developer Support. Cost effective bundles are available that include support with a pack of 25 Developer Suite subscriptions that can be managed from a single account. Each of these subscriptions is based on systems, rather that users.

Stay tuned.

Yea sure, that's the way to handle this kind of announcement. 'We're killing CentOS 8 and you need to wait several months to see the 'supposed' good things this move brings.' Yea right.... All this '1H/1Q 2021' does is let IBM/RedHat determine how bad the fallout is before trying to cover their backsides.

Exactly. It boggles the mind the RH would make the announcement without having the new plans in place.

> On the other hand Red Hat does offer RHEL for free (gratis) [0] and that should fill the needs of CENTOS users (right?)

They offer a no-cost "developer subscription" of RHEL, but I'd wager the majority of users are running CentOS on servers.

Is there a free non-developer, i.e. home version of RHEL without any subscription/registration?

http://yum.oracle.com/oracle-linux-isos.html

Disclaimer: not affiliated with Oracle in any way. This is just the closest thing to a plain RHEL8 clone I know of, other than CentOS8.

I work for Oracle on their cloud platform (including reasonably closely with the Oracle Linux team, as my team is responsible for the main platform images).

Speaking entirely for myself, opinions my own, may not reflect my employer etc. etc:

I came in to this job expecting OL to just be a CentOS clone, and not really expecting much from the kernel they ship with it.

It is both a CentOS clone, and a bunch more. Oracle takes the CentOS packages and applies bug fixes etc. that upstream RedHat has failed or refused to apply, so I've actually found OL to suffer from fewer problems than CentOS, and we've even had to apply mitigations for CentOS 6 for stuff we haven't had to do to any other OS we distribute. For entirely selfish reasons, I was really glad to see CentOS 6 go end of life last month.

On top of that the OL team hires a significant number of upstream kernel developers, including the core maintainers for a number of components, like XFS, Xen, and so on, and produces the Unbreakable Enterprise Kernel (a really curious choice of marketing terminology), that incorporates mainstream bug and security patches, while being closer to mainstream than RHEL/CentOS, and the kernel patches submitted upstream by OL devs.

So is it a drop-in replacement for CentOS 8.x without any nonsense? I.e. same packages, compatibility with upstream, etc.

Should be. It's CentOS packages with rebranding and maybe some custom fixes on top. There are two kernels that ship with it, either the RedHat Compatibility Kernel (RHCK), or the Unbreakable Enterprise Kernel (UEK).

I would point out, I'm not in the OL org, I have absolutely no idea what this change means for Oracle Linux. Oracle Linux is based off the CentOS sources as that's the only way that RedHat was making the source code to their distribution available (there way of meeting the terms of the GPL). RedHat has to make their source code available in one form or another so I can't imagine that this would have any impact on OL, but that's entirely guess work.

I didn't know Oracle builds from CentOS rather than RHEL sources. Nor that RHEL doesn't release sources anymore?

If that's true, I wonder how Oracle got some of their 8.x releases out much earlier than CentOS. (Oracle Linux 8.3 2020-11-13 vs CentOS 8.3 2020-12-08, Oracle Linux 8.0 2019-07-19 vs CentOS 8.0 2019-09-24.) I'm assuming here without verification that both track the RHEL 8 point releases.

if i remember correctly, RHEL source dumps always lacked some machinery to actually produce a working release; that’s where CentOS were doing actual work, painstakingly replicating all the compilation quirks to end up with RPM builds that matched RHEL. That’s likely why another clone might want to start from CentOS rather than RHEL sources.

That doesn't answer my question how Oracle got some 8.x builds released weeks/months earlier than CentOS.

I can't speak to that. I'm not in the OL team and don't know what they do / did. Oracle can/does throw a lot more engineers at development and build than CentOS does (I believe they only have a few engineers). I believe the stuff for building the RPMs lands in the CentOS git repo early on.

It may take a hard sell for people looking for something more open than RHEL after this to use anything from Oracle.

Reply on news.ycombinator.com