Live data from Hacker News

Red Hat cutting back RHEL source availability

lwn.net

331–339 of 339 posts

Re: Red Hat cutting back RHEL source availability

#331

Earlier quoted context omitted.

Yeah... had it not been for CentOS, I would've never touched anything in the RHEL-side of things after I discovered Ubuntu in the 10/12 era. Because CentOS existed, I made sure most of my open source work would run just as well on all RHEL derivatives as it does on Debian. If Rocky didn't exist, I would quickly drop all my RHEL support because operating thousands of test machines and containers based on UBI and havin…

I'd have to check if it is still the case but RHEL has provided free developer licenses for RHEL for years (decades?). EDIT: checked and it still exist and allow usage of up to 16 physical or virtual nodes for development " to develop software (including open source software), perform prototyping or quality assurance testing and/or for demonstration purposes.

You can also use them for production. Scroll to the bottom of https://sso.redhat.com/auth/realms/redhat-external/protocol/... and follow the link to the terms & conditions:

> The Individual Developer Subscriptions allow you (as an individual, natural person) to use certain Red Hat Subscription Services in connection with Red Hat Software for Individual Development Use and for Individual Production Use subject to these Program Terms at no cost.

> “Individual Production Use” means any use other than for Individual Development Use including, but not limited to, using the Software (a) in a production environment, (b) with live data and/or applications and/or (c) for backup instances

Red Hat also have a no-cost Developer Subscription for Teams agreement for organizations.

Re: Red Hat cutting back RHEL source availability

#332

Earlier quoted context omitted.

There is notting in Jeff Geerling's project list[1] that warrant hundred's of rhel machines and containers at any given time. Containers are mostly ephemerals when used for build and test purpose. [1] https://www.jeffgeerling.com/projects

The fact that I have to spend more than 5 seconds considering how to integrate my Red Hat Subscription into my test builds (for dozens of projects) means I won't do it. That's why I stuck with Rocky Linux instead of just dropping all RHEL support entirely. And there are _a lot_ of test runs where I have more than 20-30 test containers running simultaneously with Rocky Linux 8 and 9. Do I have to write new software th…

FYI containers aren't their own entity for subscription management purposes. A subscribed host can run as many containers as it wants, the host's subscriptions work inside the containers.

(That said I agree that dealing with subscription-manager at all is a lot more annoying than ... not having to do so with RHEL derivatives!)

Re: Red Hat cutting back RHEL source availability

#333
post #212

Earlier quoted context omitted.

Rocky can offer support on helping you install it. But they can't offer real support. They can't fix bugs or do any real work on RHEL beyond requesting that Red Hat accept a fix. If Red Hat declines, Rocky can't even ship their own fix.

Doesn't Rocky offer their own repositories, where if they had an upstream fix that was important enough, they could just include it in their own repositories?

They can't do so while claiming to be bug-for-bug compatible with RHEL.

Re: Red Hat cutting back RHEL source availability

#334

Earlier quoted context omitted.

> I wish this encourages companies to look for more alternatives to RHEL and its clones. The issue is that there is no alternative. I'm not aware of any distro with its base and all its packages working seamlessly with SELinux enabled. Setting up SELinux in any other distro is, in my experience, an uphill battle. You need to become an SELinux expert to do so. > The worst part about the packaging work is, the tools us…

This (SELinux) is why I started using RH-family OSs more and more, and one of a few reasons why I stick with it, even though Debian's minimalism is incredibly nice. I have a book (as yet unopened) on my desk about SELinux administration, but it's huge and CentOS, Fedora, RHEL, et al. Just Work (okay, with the occasional small tweak to policies or booleans).

Same here. I never want to go back to another distribution where all of the services on a system, including containers, are not segregated from one another by SELinux.

Re: Red Hat cutting back RHEL source availability

#335

Earlier quoted context omitted.

This is not entirely true; some packages have been removed from RHEL7 to 8 to 9, because the interpretation of "if we ship it we support it" has become stricter. RHEL9 is as new or sometimes newer than Debian 11 (bullseye).

RedHat also backports fixes, security patches, and (occasionally) features to existing RPMs without incrementing the minor version. For example fuzzywhatsit-3.0 in RHEL could be functionally equivalent to 3.5 in another distro.

They even rebase packages to new upstream versions in point releases (where doing so maintains backwards compatibility, of course).

Re: Red Hat cutting back RHEL source availability

#336

Something worth mentioning, is that RHEL has a free Developer subscription, which includes 16 free dedicated devices. The only issue is that many cloud providers don't have RHEL as an OS option, so you can't use it on your average cheap VPS. That assumes you trust them not to do another rug pull (CentOS 8)

You can always download the RHEL ISO and upload it to J. Random Cloud Provider. I do that with Hetzner for instance.

Re: Red Hat cutting back RHEL source availability

#339
post #294

Earlier quoted context omitted.

Many companies just needed some linux. So, choosing between Debian and Centos was pretty much choosing between rpm and apt. Many companies were not choosing between the commercial RHEL and Centos to begin with. Now they are just fine with just containers.

And those companies should be just fine with Stream or some other option, right?

They are fine with Alpine tbh. And something that allows to host k8s.
Post reply on HN